83. 아키텍처 주요 요소 (이해관계자, 관심사, 관점/뷰포인트, 뷰)

⚠️ 이 문서는 소프트웨어 시스템을 구축할 때 엉망진창으로 그려지는 도면들의 질서를 잡기 위해 제정된 국제 표준(IEEE 1471 / ISO 42010)에서, '누가 도면을 보는가?', '그들은 무엇이 궁금한가?', '그 궁금증을 해소하기 위해 어떤 양식으로 그릴 것인가?', '그래서 나온 최종 도면은 무엇인가?'라는 설계도의 4대 근본 기둥(메타모델 핵심 요소)의 정확한 개념과 상호 연관성을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 아키텍처 문서는 한 장의 천재적인 그림으로 퉁칠 수 없다. 보는 사람의 입장이 너무나 다르고 원하는 답이 다르기 때문에, 이를 철저히 분해하여 목적에 맞는 여러 장의 도면으로 조립하기 위한 4개의 핵심 명사(어휘) 집합이다.
  2. 가치: "사무실 천장 도면(네트워크)을 가져와 놓고 방바닥 콘센트 위치(DB 연결)를 찾으려 하는" 멍청한 의사소통 단절을 막는다. 각 도면이 도대체 누구를 위해, 어떤 규칙으로 그려졌는지를 명확히 꼬리표 달아 아키텍처의 빈틈(누락)을 100% 잡아낸다.
  3. 기술 체계: 도면을 요구하는 사람인 이해관계자(Stakeholder), 그들의 질문인 관심사(Concern), 그 질문에 대답하기 위한 '도면 작도 템플릿(법칙)'인 관점(Viewpoint), 그리고 그 템플릿으로 실제 우리 회사 시스템을 스케치해 낸 1장의 결과물인 **뷰(View)**가 유기적으로 물려 돌아간다.

Ⅰ. 이해관계자(Stakeholder)와 관심사(Concern)

도면을 그리기 전에, "이 도면을 결재할 사람이 누구인가?"부터 파악하라.

  1. 이해관계자 (Stakeholder) - "누구인가?":
    • 시스템의 탄생부터 폐기까지 직간접적으로 영향을 받거나 권력을 행사하는 모든 인간 또는 외부 시스템이다.
    • 예시: 프로젝트 스폰서(돈 대는 사장님), 최종 사용자(일반 국민), 개발자, 시스템 관리자(인프라 팀), 보안 감사관.
    • 도면을 그릴 때 사장님과 보안 감사관을 똑같은 사람 취급하면 프로젝트는 산으로 간다.
  2. 관심사 (Concern) - "무엇이 가려운가?":
    • 위의 각 이해관계자들이 시스템에 대해 가지고 있는 '근본적인 질문, 요구사항, 불안감, 제약 조건'이다.
    • 사장님의 관심사: "개발 기간은 언제 끝나며, 구축 비용(TCO)은 얼마인가?"
    • 사용자의 관심사: "버튼을 눌렀을 때 1초 안에 화면이 뜨고(성능), 쓰기 편한가(사용성)?"
    • 개발자의 관심사: "이 모듈을 나중에 다른 프로젝트에 재사용(Reusability)할 수 있게 짜여있는가?"
    • 보안관의 관심사: "해커가 DB를 뚫지 못하도록 네트워크 구간 암호화가 되어 있는가?"

📢 섹션 요약 비유: 아파트를 지으려 합니다. 이해관계자는 입주자(엄마), 은행 대출 담당자, 인테리어 업자입니다. 엄마의 관심사는 "거실이 남향인가?(햇빛)"이고, 은행의 관심사는 "이 집이 나중에 10억에 팔릴 담보 가치가 있는가?(돈)"이며, 인테리어 업자의 관심사는 "안방 벽이 시멘트인가 석고보드인가?(시공)"입니다. 각자의 가려운 곳이 다르니, 보여줘야 할 도면(서류)도 완벽하게 달라야 합니다.

Ⅱ. 관점/뷰포인트(Viewpoint)와 뷰(View)의 이분법

관점은 "도면 그리는 규칙책"이고, 뷰는 "규칙에 따라 그린 실제 내 시스템 도화지"다.

  1. 관점 / 뷰포인트 (Viewpoint) - "규칙과 양식":
    • 앞서 말한 '관심사(질문)'를 해소하기 위해, 건축가(아키텍트)가 **'어떤 펜과 기호를 써서 어떤 구도로 도면을 그려야 하는지 정해놓은 템플릿(작도 표준)'**이다.
    • 특정 시스템과 상관없는 보편적인 규칙 덩어리다.
    • 예: [보안 뷰포인트] 규정집 = "이 도면을 그릴 때는 반드시 DMZ 구간을 파란색 점선으로 두르고, 방화벽은 빨간색 벽돌 아이콘으로 그리며, 포트 번호를 텍스트로 꼭 명시할 것."
  2. 뷰 (View) - "실제 그려진 우리 시스템의 도면 1장":
    • 위에서 만든 규정집(뷰포인트)을 들이대서, 백지 도화지에 '실제 우리 회사가 이번에 만들 카카오톡 결제 시스템'의 모습을 잉크로 스케치해 낸 최종 산출물 1장이다.
    • 예: [카카오톡 결제 보안 View] = 뷰포인트 규정에 따라 실제로 카카오톡 시스템의 파란색 점선(DMZ) 안에 방화벽 아이콘 3개가 놓여있고 443 포트라고 적혀있는 생생한 진짜 도면 그림.
  3. 1대 다 (1:N)의 관계:
    • 1개의 뷰포인트(템플릿)를 가지고, A 시스템을 그리면 'A 보안 뷰'가 나오고, B 시스템을 그리면 'B 보안 뷰'가 찍혀 나온다. 즉 붕어빵 틀(Viewpoint)과 붕어빵(View)의 관계다.

📢 섹션 요약 비유: 건축법에서 정한 **[비상 대피도 작성 양식 규정집]**이 바로 **뷰포인트(Viewpoint)**입니다. 이 규정집에는 "비상구는 초록색 달리는 사람으로 그려라"라고 적혀 있습니다. 이 규정집을 보고 강남역 식당 사장님이 벽에 걸어두기 위해 스케치북에 찍어낸 강남 식당 맞춤형 **[피난 안내도 스티커 1장]**이 바로 **뷰(View)**입니다.

Ⅲ. 최종 완성: 아키텍처 명세서 (Architecture Description)

흩어진 뷰(View)들을 모아 한 권의 위대한 바이블로 묶어낸다.

  1. 퍼즐의 조립 (Aggregation):
    • 특정 시스템(예: 모바일 뱅킹)을 묘사하기 위해 아키텍트는 여러 이해관계자의 입맛에 맞게 다양한 뷰포인트를 적용해 수십 장의 도면(View)을 그린다.
    • '네트워크 View', '데이터베이스 논리 View', '클래스 다이어그램 View', '보안 방화벽 View' 등이 쏟아져 나온다.
  2. 아키텍처 명세서 (Architecture Description):
    • IEEE 1471 표준은 이 흩어진 수십 장의 뷰(View)들을 그냥 낱장으로 던져주지 말고, 빳빳한 하드커버 바인더로 철을 해서 [모바일 뱅킹 아키텍처 명세서 총괄본] 이라는 한 권의 책으로 묶어내라고 강제한다.
    • 이 책은 해당 시스템이 도대체 어떻게 생겨 먹었는지를 360도 전방위에서 설명하는 완벽한 종합 해부학 도감이 된다.
  3. 정합성(Consistency) 검증 필수:
    • 책을 제본하기 전에 감리관이 반드시 검사해야 할 것이 있다.
    • "네트워크 View 23페이지에는 DB 서버가 A망에 있다고 그렸는데, 보안 View 45페이지에는 DB 서버가 B망에 있다고 그려져 있네? 서로 뷰끼리 모순(충돌)되잖아!"
    • 이렇게 서로 다른 View들 사이에 겹치는 요소가 충돌하지 않고 100% 앞뒤가 맞는(정합성) 상태여야만 올바른 아키텍처 명세서로 인정받고 공사를 시작할 수 있다.

📢 섹션 요약 비유: 종합 병원의 환자(시스템) 진단 기록입니다. X-ray 사진 1장(뼈 View), MRI 사진 1장(뇌 View), 내시경 사진 1장(위장 View) 등 각 전문의(이해관계자)들이 각자의 기계(Viewpoint)로 환자를 찍은 사진 수십 장이 나옵니다. 이 모든 필름을 순서대로 곱게 모아 끼워 넣은 차트 1권이 바로 **아키텍처 명세서(AD)**입니다. 이 차트 한 권만 있으면 이 환자의 머리끝부터 발끝까지의 모든 상태를 누구든 완벽하게 이해하고 수술대에 올릴 수 있습니다.