소프트웨어 공학 100 주제 시리즈의 22번째 글이다. (카테고리: 설계와 아키텍처)

한 줄 요약

ISO/IEC/IEEE 42010 은 “아키텍처를 어떻게 설계하라” 가 아니라 아키텍처를 어떻게 기술(description)하라를 정하는 표준이다. 핵심은 이해관계자 → 관심사(concern) → 관점(viewpoint) → 뷰(view) 의 연결이고, 아키텍처 자체와 아키텍처 문서는 다른 것이라는 구분이다.

왜 필요한가

“우리 시스템 아키텍처 문서 좀 보여 주세요” 라는 요청에 흔히 나오는 것은 박스와 화살표가 섞인 그림 한 장이다. 그 그림이 누구의 어떤 질문에 답하는지 아무도 모른다. 운영팀은 장애 시 어디가 죽는지 알고 싶고, 보안 담당은 개인정보가 어디로 흐르는지 알고 싶고, 신규 개발자는 코드가 어디에 있는지 알고 싶다. 한 장의 그림은 이 질문들을 모두 조금씩 건드리고 어느 것에도 제대로 답하지 못한다.

또 하나의 문제는 정의다. 아키텍처를 “상위 수준 설계” 라고만 하면, 무엇이 아키텍처이고 무엇이 그냥 설계인지 경계가 없다. 경계가 없으면 아키텍트의 역할도, 문서의 범위도, 리뷰의 기준도 사람마다 달라진다. 42010 은 이 두 문제 — 무엇을 아키텍처라 부르는가, 그것을 어떻게 적는가 — 에 대한 국제 합의다.

핵심 개념

계보

표준 공식 사이트 iso-architecture.org/42010의 FAQ가 정리한 이력은 다음과 같다.

연도 문서 비고
2000 IEEE Std 1471-2000 IEEE Architecture Working Group 이 개발, 2000년 9월 IEEE 승인. 범위는 “소프트웨어 집약 시스템”
2007 ISO/IEC 42010:2007 2006년 ISO 채택, 본문은 IEEE 1471 과 동일
2011 ISO/IEC/IEEE 42010:2011 1471 과 2007판을 대체. 범위를 시스템 일반으로 확대
2022 ISO/IEC/IEEE 42010:2022 2판. 사이트 공지 기준 2022년 11월 발행

자매 표준으로 아키텍처 프로세스를 다루는 ISO/IEC/IEEE 42020 과 아키텍처 평가 프레임워크인 42030 이 2019년 7월에 나왔다(같은 사이트 공지).

아키텍처의 정의

2011판은 아키텍처를 이렇게 정의한다(FAQ).

fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

(환경 속에 놓인 시스템의 근본적인 개념 또는 속성으로, 그 요소들과 관계들, 그리고 설계와 진화의 원칙에 구현된 것)

FAQ 는 이 정의의 요점을 세 가지로 설명한다.

  1. 아키텍처는 시스템 전체에 대해 근본적인 것이다. 형태, 기능, 가치, 비용, 위험을 결정하는 본질적 속성의 집합이다.
  2. 아키텍처는 개념이다. 사람의 머릿속에 있고, 적힌 적이 없어도 존재한다. 그래서 표준은 아키텍처(architecture)와 아키텍처 기술서(architecture description, AD)를 구분한다. “지도는 영토가 아니다”.
  3. 아키텍처는 맥락 속에서만 이해된다. “무엇이 근본적인가” 는 “누구에게 근본적인가” 를 모르면 답할 수 없다. 그래서 정의에 “환경 속에 놓인(in its environment)” 이 들어간다.

그리고 FAQ 는 아키텍처가 물리적 구성 요소의 전체 구조만은 아니다라고 못 박는다. 구조가 근본일 수 있지만 반드시 그런 것은 아니다.

다른 정의들과 비교

출처 정의의 초점
Perry & Wolf, “Foundations for the study of software architecture” (1992) 요소(Elements), 형태(Form), 근거(Rationale)
Clements 외, Documenting Software Architectures 2판 (2010) 시스템을 추론하는 데 필요한 구조들의 집합 — 요소, 관계, 그 속성
Ralph Johnson, Fowler 의 Who Needs an Architect? (2003) 에서 인용 전문 개발자들이 공유하는 시스템 설계에 대한 이해 / “중요한 것. 그게 무엇이든”
ISO/IEC/IEEE 42010:2011 환경 속 시스템의 근본 개념·속성

Fowler 는 같은 글에서 아키텍처를 “사람들이 바꾸기 어렵다고 인식하는 것” 으로 정의할 수도 있다고 하며, 아키텍트의 중요한 일 하나는 비가역성(irreversibility)을 줄여 아키텍처 자체를 줄이는 것이라고 말한다. 42010 의 정의가 범위를 규정한다면, Fowler 의 관점은 그 범위 안에서 무엇에 힘을 쏟을지를 알려 준다. 그의 아키텍처 안내 페이지는 나쁜 아키텍처가 이해를 방해하는 군더더기(cruft)를 키우고, 그 결과 기능이 더 느리게, 더 많은 결함과 함께 나온다고 설명한다.

개념 모델: 이해관계자에서 뷰까지

42010:2011 의 개념 모델은 다음 사슬로 요약된다.

 이해관계자(Stakeholder) ──가진다──▶ 관심사(Concern)
                                        │ 틀을 잡는다(frames)
                                        ▼
                         아키텍처 관점(Architecture Viewpoint)
                                        │ 규약을 정한다(governs)
                                        ▼
                         아키텍처 뷰(Architecture View)
                                        │ 구성된다
                                        ▼
                     아키텍처 모델(Architecture Model) ◀── 모델 종류(Model Kind)
용어 표준 사이트의 설명
이해관계자 시스템에 관심사를 가진 개인·집단·조직. 고객, 소유자, 사용자, 공급자, 설계자, 유지보수자, 감사인, 인증 기관, 아키텍트 등
관심사 시스템에 대한 모든 관심. Dijkstra 의 “관심사의 분리” 에서 온 말. 목적, 기능, 구조, 동작, 비용, 안전, 상호운용성 등
관점(viewpoint) 한 종류의 뷰를 만들고, 해석하고, 분석하는 규약의 집합. 모델 종류, 표기법, 모델링 방법, 분석 기법을 포함
뷰(view) 특정 관심사를 다루기 위해, 관점의 규약을 따라 시스템 아키텍처를 표현한 것
대응(correspondence) AD 요소들 사이의 관계(정합성, 추적성, 의존 등)를 표현. 대응 규칙으로 강제 가능
아키텍처 결정·근거 결정은 관심사와 관련되고, 근거(rationale)는 선택하지 않은 대안까지 포함한 이유를 기록

FAQ 의 한 문장이 관점과 뷰의 차이를 가장 잘 요약한다. 관점은 시스템을 보는 방법이고, 뷰는 그 방법으로 보았을 때 보이는 것이다. 표준은 어떤 관점을 써야 하는지 정하지 않는다. 시스템마다 관심사가 크게 다르기 때문이다. SE100 #023 의 4+1 뷰, #024 의 C4 모델은 이 틀 위에 올릴 수 있는 구체적인 관점 묶음이다. 특정 이해관계자 공동체나 도메인을 위해 관점들을 묶어 둔 것을 표준은 아키텍처 프레임워크라 부른다.

2022년 2판에서 바뀐 것

표준 사이트의 개념 모델 페이지는 2판의 변화를 이렇게 요약한다.

  • 기술 대상을 “관심 시스템(System of Interest)” 에서 “관심 엔터티(Entity of Interest)” 로 일반화했다.
  • 뷰를 구성하는 단위 이름이 “아키텍처 모델” 에서 “뷰 컴포넌트(View Component)” 로 바뀌었다.
  • 관심사를 묶어 관점을 조직하는 이해관계자 관점(Stakeholder Perspective) 이 추가됐다.
  • 관심 엔터티의 특성으로서 뷰에 반영되는 아키텍처 측면(Architecture Aspect) 이 추가됐다.
  • UML 기반 메타모델을 표준 본문에서는 버렸다(사이트는 비교를 위해 UML 그림을 제공).

표준 본문은 유료이므로, 이 글의 2판 설명은 위 공식 사이트 요약에 근거한다.

실무 적용

42010 식 아키텍처 문서 뼈대

표준을 “준수” 하지 않더라도, 개념 모델을 목차로 쓰면 문서가 질문 중심으로 바뀐다.

# 결제 시스템 아키텍처 기술서

## 1. 이해관계자와 관심사
| 이해관계자 | 관심사 |
|---|---|
| 운영팀 | 단일 장애점, 장애 시 영향 범위 |
| 보안·컴플라이언스 | 카드 정보가 저장·전송되는 위치 |
| 신규 개발자 | 코드 구조, 로컬 실행 방법 |
| 재무 | 인프라 비용 구조 |

## 2. 관점 목록 (어떤 관심사를 어떤 뷰로 답하는가)
| 관점 | 다루는 관심사 | 표기 |
|---|---|---|
| 배포 관점 | 단일 장애점, 비용 | C4 배포 다이어그램 |
| 데이터 흐름 관점 | 카드 정보 위치 | DFD + 신뢰 경계 |
| 모듈 관점 | 코드 구조 | C4 컴포넌트 + 패키지 규칙 |

## 3. 뷰 (관점마다 하나)
## 4. 뷰 사이 대응 (예: 모든 컴포넌트는 정확히 하나의 컨테이너에 배치된다)
## 5. 아키텍처 결정과 근거 (ADR 목록 링크)
## 6. 알려진 미해결 문제

이 뼈대로 검토하면 “관심사는 있는데 답하는 뷰가 없는” 칸과 “그린 이유를 아무도 모르는 뷰” 가 바로 드러난다. 5번은 SE100 #025(ADR)와 연결된다.

리뷰 체크리스트

  • 모든 뷰에 “이 뷰는 누구의 어떤 관심사에 답하는가” 가 적혀 있는가
  • 모든 주요 이해관계자의 관심사가 최소 하나의 뷰에서 다뤄지는가
  • 각 뷰의 표기(도형·선·색)가 범례로 설명되는가
  • 뷰 사이에 같은 요소가 같은 이름으로 등장하는가(대응)
  • 결정마다 근거와 버린 대안이 남아 있는가

흔한 오해와 함정

  • “42010 은 아키텍처 설계 방법론이다.” 아니다. 표준이 요구하는 것은 아키텍처 기술서의 내용이다. 어떤 아키텍처가 좋은지, 어떤 순서로 설계할지는 다루지 않는다.
  • “문서가 없으면 아키텍처도 없다.” 정의상 아키텍처는 적히지 않아도 존재한다. 문서가 없는 시스템은 아키텍처가 없는 게 아니라, 아무도 합의하지 않은 아키텍처를 가진 것이다.
  • “뷰는 많을수록 좋다.” 관심사에 대응하지 않는 뷰는 유지보수 비용만 늘린다. 관점은 관심사에서 출발해 선택한다.
  • “아키텍처 = 배포 구조 그림.” FAQ 가 명시적으로 부정하는 오해다. 배포 구조는 여러 관심사 중 하나에 답하는 하나의 뷰다.
  • “2011판 용어를 그대로 쓰면 된다.” 2022판은 모델 → 뷰 컴포넌트, 시스템 → 엔터티 등 용어가 바뀌었다. 조직 문서에 표준 용어를 인용할 때는 판을 명시한다.

확인 문제

  1. 42010 이 아키텍처와 아키텍처 기술서를 구분하는 이유는 무엇인가?
  2. 관점(viewpoint)과 뷰(view)의 차이를 한 문장씩으로 설명하라.
  3. 표준이 사용할 관점 목록을 고정하지 않은 이유는?
  4. 정의에 “환경 속에 놓인(in its environment)” 이 들어간 이유는?
  5. 42010:2022 에서 새로 도입된 개념 두 가지를 들라.

풀이

  1. 아키텍처는 사람의 머릿속에 있는 개념이며 적히지 않아도 존재하고, 기술서는 그것을 공유하려는 구체적 작업 산출물이기 때문이다. 표준의 요구사항은 기술서에 대한 것이다.
  2. 관점은 한 종류의 뷰를 만들고 해석·분석하는 규약(표기, 모델 종류, 방법)이다. 뷰는 그 규약에 따라 특정 시스템의 아키텍처를 특정 관심사에 맞춰 표현한 것이다.
  3. 시스템마다 이해관계자와 관심사가 크게 달라서 하나의 관점 묶음을 모든 시스템에 강제할 수 없기 때문이다.
  4. 무엇이 근본적인지는 시스템이 환경과 어떻게 관계 맺는지, 즉 누구에게 근본적인지에 따라 달라지기 때문이다.
  5. 이해관계자 관점(Stakeholder Perspective), 아키텍처 측면(Architecture Aspect). (그 밖에 관심 엔터티, 뷰 컴포넌트로의 용어 변경)

더 읽을거리 (References)