82. IEEE 1471 (ISO/IEC 42010) - 소프트웨어 아키텍처 명세 국제 표준

⚠️ 이 문서는 소프트웨어 시스템을 짓기 전에 그리는 수백 장의 설계도(아키텍처)가 회사마다 부서마다 제멋대로 그려져 의사소통이 붕괴되는 것을 막기 위해, "설계도라는 것은 반드시 이런 구조와 규칙을 지켜서 작성해야 한다"고 IEEE와 ISO가 머리를 맞대고 제정한 '건축 도면(아키텍처 명세) 작성의 전 세계 통일 헌법'인 IEEE 1471 표준을 다룹니다.

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

  1. 본질: 아키텍처 자체(시스템 구조)를 만드는 방법론이 아니다. 아키텍처를 '어떻게 문서로 묘사(Description)하고 설명할 것인가'에 대한 공통어와 메타모델(틀)을 정의한 표준 규격이다.
  2. 가치: 이 표준을 따르면, 집주인(고객), 배관공(DBA), 목수(개발자) 등 각기 다른 이해관계자(Stakeholders)들이 서로 자기들만의 시선(View)으로 그린 도면들을 하나로 묶어 완벽하게 모순 없는 한 권의 책(Architecture Description)으로 묶어낼 수 있다.
  3. 기술 체계: 도면을 읽는 '이해관계자(Stakeholder)', 그들의 가려운 부분인 '관심사(Concern)', 이를 해소하기 위해 특정 앵글로 그린 도면인 '뷰(View)', 그리고 그 뷰를 그리는 템플릿(문법)인 '뷰포인트(Viewpoint)'라는 4대 핵심 어휘가 톱니바퀴처럼 맞물려 돌아간다.

Ⅰ. 바벨탑의 붕괴: 설계도를 읽지 못하는 사람들

모두가 각자의 언어로 도면을 그리면 시스템은 무너진다.

  1. 아키텍처 명세(Description)의 혼돈:
    • 옛날에는 A라는 은행 시스템을 지을 때, 보안팀은 엑셀로 '방화벽 룰'을 그리고, 개발팀은 UML로 '클래스 다이어그램'을 그리고, 사장님은 파워포인트로 '네모 동그라미 조감도'를 그렸다.
    • 문제는 이 세 장의 그림이 모순되는 경우가 수두룩했다는 점이다. 사장님은 구름(클라우드)을 그렸는데 개발자는 로컬 서버를 그리고 앉아있었다. 의사소통의 단절이다.
  2. IEEE 1471의 등장 목적:
    • "도면(아키텍처)을 그릴 때 쓰는 '단어'와 '문서의 목차(뼈대)'를 전 세계가 하나로 통일하자!"
    • 이 표준은 특정한 기술(예: 자바, 클라우드)에 종속되지 않는 아주 순수하고 철학적인 상위 레벨의 개념 모델(Conceptual Model)을 제공한다.

📢 섹션 요약 비유: 건물을 지을 때 한국인, 미국인, 중국인 건축가가 모였습니다. 각자 미터(m), 인치(inch), 척(尺)이라는 다른 단위와 자기 나라 문자로 도면을 그려오니 조립을 할 수가 없습니다. IEEE 1471은 "자, 지금부터 모든 도면은 반드시 '미터(m)' 단위를 쓰고, 첫 장엔 평면도, 둘째 장엔 배관도를 넣는 템플릿 양식(표준)에 맞춰서만 제출해!"라고 강제하여 바벨탑의 언어를 하나로 통일한 위대한 협정입니다.

Ⅱ. IEEE 1471의 4대 핵심 어휘 (메타모델 해부)

이 단어 4개를 정확히 이해하면 표준의 90%를 깨우친 것이다.

  1. 이해관계자 (Stakeholder):
    • 시스템에 숟가락을 얹고 있거나 영향을 받는 모든 사람이다.
    • 고객(사장님), 사용자, 개발자, 보안 관리자, 인프라 엔지니어 등이 모두 각자의 도면을 요구하는 독자적인 이해관계자다.
  2. 관심사 (Concern):
    • 이해관계자들이 도면을 보면서 "가장 딴지를 걸고 싶어 하는(가려워하는) 핵심 질문"이다.
    • 사장님의 관심사: "이거 개발비 얼마나 들고, 돈은 잘 벌리나?"
    • 보안 관리자의 관심사: "해커가 뚫고 들어올 구멍(방화벽)은 안전한가?"
    • 개발자의 관심사: "이 모듈(코드) 재사용 가능한가?"
  3. 뷰포인트 (Viewpoint - 뷰를 그리는 문법/템플릿):
    • 특정 관심사를 해소하기 위해 도면을 그릴 때, "어떤 펜과 어떤 기호를 써서 그려야 하는지"를 정해놓은 **'틀(규칙/양식)'**이다.
    • 예: '보안 뷰포인트'라는 틀에는 "반드시 방화벽은 빨간색 벽돌로 그리고, 암호화 구간은 파란 선으로 그려야 한다"는 템플릿(문법)이 정의되어 있다.
  4. 뷰 (View - 뷰포인트로 찍어낸 진짜 그림):
    • 뷰포인트(틀/문법)를 적용해서, 실제 우리 회사 시스템의 모습을 잉크로 찍어낸 **'완성된 도면 1장'**이다.
    • 하나의 '보안 뷰포인트(양식)'를 들이대면, A 시스템의 '보안 뷰 1장', B 시스템의 '보안 뷰 1장'을 똑같은 규격으로 뽑아낼 수 있다.

📢 섹션 요약 비유: 식당을 짓습니다.

  • 이해관계자: 주방장, 소방관, 인테리어 디자이너.
  • 관심사: 주방장은 "동선이 안 꼬이나요?", 소방관은 "불나면 도망칠 구멍은요?"라고 각자 다른 곳을 가려워합니다.
  • 뷰포인트: 소방관의 가려움을 긁어주기 위해 "비상구는 초록색 사람 모양 기호로 그리고 거리를 미터로 적으시오"라고 법으로 정해둔 **[도면 양식 규정]**입니다.
  • 뷰: 그 규정(뷰포인트)에 맞춰 도화지에 우리 식당의 비상구를 실제로 스케치한 **[소방 대피도면 1장]**입니다.

Ⅲ. 하나의 문서(Architecture Description)로의 융합

모든 뷰(View)가 모여 비로소 하나의 위대한 시스템이 정의된다.

  1. 다중 뷰(Multiple Views)의 필연성:
    • IEEE 1471은 "하나의 도면에 시스템의 모든 것을 때려 넣는 짓은 미친 짓이다"라고 선언한다.
    • 사장님을 위한 뷰 1장, 개발자를 위한 뷰 1장, 보안팀을 위한 뷰 1장 등 쪼개진 여러 장의 뷰(View)를 각자의 시선으로 그려야만 이해가 가능하다.
  2. 아키텍처 명세서 (Architecture Description, AD):
    • 각자의 관심사에 맞춰 그려진 수십 장의 뷰(View)들을 스테이플러로 꽉 찍어 철해놓은 1권의 두꺼운 책이다.
    • 이 책(AD)이 바로 우리가 그토록 원했던 '해당 시스템의 모든 것을 완벽하게 설명하는 궁극의 설계도 모음집'이 된다.
  3. 합치성 (Consistency) 검증:
    • 책으로 묶기 전에 가장 중요한 작업이다. 보안팀이 그린 '보안 뷰'에는 방화벽이 3개인데, 인프라팀이 그린 '배포 뷰'에는 방화벽 기계가 1개밖에 없으면 도면 간에 모순(충돌)이 난다.
    • IEEE 1471 표준은 여러 장의 뷰 사이에 상충하는 내용이 없는지 크로스 체크하여 정합성을 맞추는 절차를 반드시 거치도록 강제한다.

📢 섹션 요약 비유: 사람(시스템)의 몸을 병원에서 진단할 때, 내과 의사를 위한 X-ray 사진 1장, 정형외과 의사를 위한 뼈 사진 1장, 신경과 의사를 위한 MRI 사진 1장(각각의 뷰 View)을 다 따로 찍습니다. 뼈 사진 한 장에 핏줄과 뇌세포를 다 구겨 넣을 수 없으니까요. 이 모든 부위별 사진 수십 장을 모아둔 '김철수 환자의 종합 건강 검진 차트 1권'이 바로 아키텍처 명세(AD)라는 위대한 마스터 설계도입니다.