핵심 인사이트 (3줄 요약)
- 본질: IEEE (Institute of Electrical and Electronics Engineers) 1471과 ISO (International Organization for Standardization) 42010은 아키텍처를 "무엇을 그렸는가"가 아니라 "누구의 어떤 질문에 답하는가"로 정의한다.
- 가치: Stakeholder → Concern → Viewpoint → View의 흐름을 지키면 동일한 시스템도 운영, 개발, 보안, 경영 관점에서 충돌 없이 설명할 수 있다.
- 판단 포인트: Concern을 먼저 분리하지 않으면 Viewpoint 선택이 흔들리고, 결국 모든 정보를 하나의 그림에 우겨 넣는 실패로 이어진다.
Ⅰ. 개요 및 필요성
소프트웨어 아키텍처는 복잡한 시스템의 구조와 품질 속성을 설명하는 일이다. 그러나 실제 프로젝트에서는 운영팀, 개발팀, 보안팀, 심사위원, 경영진이 각자 서로 다른 질문을 던진다. 같은 시스템이라도 "장애가 나면 얼마나 빨리 복구되는가", "어디를 바꾸면 영향이 커지는가", "망 분리는 충분한가", "비용은 감당 가능한가"가 모두 다르다. 그래서 아키텍처 문서는 단일 정답 그림이 아니라, 질문별 답을 모은 설명 체계여야 한다.
아키텍처 문서가 필요한 이유는 설계 결과를 남기기 위해서만이 아니다. 누가 무엇을 알고 결정을 내려야 하는지, 어떤 판단이 누구에게 설명되어야 하는지를 남겨야 변경과 운영이 흔들리지 않는다. 문서가 빈약하면 기능 구현보다 해석이 먼저 달라지고, 해석이 달라지면 개발과 운영 기준이 엇갈린다.
┌──────────────┐ 질문이 다름 ┌────────────────┐
│ 운영팀 │──────────────▶│ 가용성/복구시간 │
└──────────────┘ └────────────────┘
┌──────────────┐ ┌────────────────┐
│ 개발팀 │──────────────▶│ 모듈 경계/변경성│
└──────────────┘ └────────────────┘
┌──────────────┐ ┌────────────────┐
│ 보안팀 │──────────────▶│ 인증/권한/감사 │
└──────────────┘ └────────────────┘
위 그림처럼 이해관계자마다 관심사가 다르므로, 문서의 목적은 "모든 질문을 하나로 합치기"가 아니라 "질문을 분리한 뒤 각각 선명하게 답하기"다.
- 📢 섹션 요약 비유: 큰 백화점 안내판 하나로 모든 손님의 길을 설명할 수는 없다. 화장실, 세일, 출구를 찾는 사람에게는 서로 다른 안내가 필요하다.
Ⅱ. 아키텍처 및 핵심 원리
Stakeholder는 시스템에 영향을 주거나 영향을 받는 사람·조직이고, Concern은 그들이 알고 싶어 하는 구체적인 질문이다. Viewpoint는 그 질문을 표현하기 위한 도면 양식, 규칙, 분석 기준이며, View는 그 양식을 실제 시스템에 적용해 만든 산출물이다. 즉, Stakeholder → Concern → Viewpoint → View가 순서대로 이어져야 한다.
| 요소 | 의미 | 실무에서 보는 관점 |
|---|---|---|
| Stakeholder | 이해관계자 | 누가 이 문서를 읽고 판단하는가 |
| Concern | 관심사 | 무엇을 알고 싶어 하는가 |
| Viewpoint | 뷰포인트 | 어떤 양식과 규칙으로 답할 것인가 |
| View | 뷰 | 실제 시스템에 대한 작성 결과물 |
┌──────────────┐
│ Stakeholder │ 사람/조직
└──────┬───────┘
▼
┌──────────────┐
│ Concern │ 질문/요구
└──────┬───────┘
▼
┌──────────────┐
│ Viewpoint │ 표현 규칙
└──────┬───────┘
▼
┌──────────────┐
│ View │ 실제 도면
└──────────────┘
이때 Viewpoint는 단순한 그림 스타일이 아니다. 어떤 이해관계자를 대상으로 하는지, 어떤 품질 속성을 다루는지, 어떤 표기법과 검증 규칙을 쓸지까지 포함하는 "설계된 질문지"다. 반대로 View는 그 질문지에 맞춰 실제 시스템의 구조를 설명한 인스턴스다.
4+1 View Model (Kruchten)은 이런 생각을 실무적으로 묶어 준다. Logical은 기능 분해, Development는 코드/모듈 구조, Process는 실행과 동시성, Physical은 배포와 노드, Scenario는 앞의 네 뷰가 실제 요구를 만족하는지 검증하는 축이다.
| 4+1 뷰 | 주 질문 | 주로 담는 내용 |
|---|---|---|
| Logical | 기능은 어떻게 나뉘는가 | 도메인, 서비스, 기능 흐름 |
| Development | 소스는 어떻게 조직되는가 | 패키지, 모듈, 컴포넌트 |
| Process | 실행 중 무엇이 일어나는가 | 스레드, 통신, 동시성 |
| Physical | 어디에 배치되는가 | 서버, 네트워크, 배포 토폴로지 |
| Scenario | 정말 동작하는가 | 유스케이스, 시나리오 검증 |
아키텍처 문서를 잘 쓰는 핵심은 뷰를 많이 만드는 것이 아니라, 각 뷰가 하나의 Concern을 정확히 대표하게 만드는 데 있다.
- 📢 섹션 요약 비유: 같은 시험지를 모든 학생에게 한 번에 주는 것이 아니라, 수학 문제지와 국어 문제지를 나누어 주는 것과 같다. 질문이 다르면 답안지도 달라져야 한다.
Ⅲ. 비교 및 연결
Viewpoint와 View를 혼동하면 문서는 즉시 무거워진다. Viewpoint는 재사용 가능한 템플릿이고, View는 그 템플릿으로 특정 시스템을 해석한 결과다. 즉, 다른 프로젝트에서도 같은 Viewpoint를 쓸 수 있지만, View는 프로젝트마다 달라진다.
| 비교 대상 | 잘못 보기 쉬운 방식 | 올바른 이해 |
|---|---|---|
| 단일 뷰 vs 다중 뷰 | 한 장짜리 그림이면 충분하다고 생각 | 이해관계자별 질문이 다르므로 뷰를 분리 |
| Viewpoint vs View | 둘 다 그냥 도면이라고 생각 | 템플릿과 결과물의 관계 |
| 4+1 vs ISO 42010 | 서로 다른 경쟁 방법이라고 생각 | 4+1은 실용적 뷰 집합, ISO 42010은 그 전체를 포괄하는 표준 |
| Concern vs 요구사항 | 요구사항과 완전히 같다고 생각 | 아키텍처 수준에서 질문의 초점과 품질 속성을 드러냄 |
또 하나의 연결점은 품질 속성이다. 성능, 가용성, 보안, 변경성 같은 속성은 곧 Concern이 되고, 그 Concern은 적절한 Viewpoint를 고르게 만든다. 그래서 아키텍처 문서는 기능 목록을 예쁘게 정리한 보고서가 아니라, 품질 속성에 대한 의사결정 기록이 된다.
ISO 42010 관점에서 중요한 것은 "설명 가능한 일관성"이다. 같은 시스템을 서로 다른 시각으로 보더라도, 모든 뷰가 같은 사실에서 출발하고 서로의 차이를 설명할 수 있어야 한다.
- 📢 섹션 요약 비유: 같은 도시를 보더라도 지하철 노선도, 도로 지도, 소방 대피도가 모두 다른 이유는 서로 다른 목적이 있기 때문이다. 지도 하나에 모든 정보를 넣으면 오히려 길을 잃는다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서는 이해관계자를 먼저 분류하는 것이 시작점이다. 그다음 Concern을 품질 속성 중심으로 정리하고, 각 Concern에 맞는 Viewpoint를 고른 뒤, 뷰를 작성한다. 마지막으로 시나리오를 통해 "이 뷰들이 정말 같은 시스템을 말하고 있는가"를 확인한다.
| Concern | 잘 맞는 Viewpoint |
|---|---|
| 변경 영향, 코드 소유권 | Development 관점 |
| 장애 대응, 배치 위치 | Physical 관점 |
| 실행 순서, 동시성 | Process 관점 |
| 기능 분해, 도메인 경계 | Logical 관점 |
기술사 답안에서는 다음 판단 문장을 분명히 써 주는 것이 좋다. "모든 이해관계자를 하나의 뷰로 만족시킬 수 없으므로, Concern을 분리하고 각 Concern에 맞는 Viewpoint를 선택해야 한다." 이 문장이 있어야 아키텍처 설명이 단순 도식이 아니라 판단으로 보인다.
적용 체크포인트
- 이해관계자 목록이 실제 의사결정자와 일치하는가?
- Concern이 기능 요구와 품질 속성으로 나뉘어 있는가?
- 각 Viewpoint가 재사용 가능한 규칙으로 정의되어 있는가?
- View마다 무엇을 보여주고 무엇을 숨기는지 명확한가?
- 시나리오로 뷰 간 일관성을 검증하는가?
피해야 할 안티패턴
-
하나의 그림에 배포, 모듈, 시나리오를 모두 우겨 넣기
-
Viewpoint 없이 뷰만 나열하기
-
Concern을 적지 않고 도면만 붙이기
-
이해관계자별 용어가 서로 달라 같은 말을 다른 뜻으로 읽게 만들기
-
📢 섹션 요약 비유: 병원에서 진료과가 다르면 검사표도 다르다. 내과, 외과, 검진센터가 같은 종이를 쓰면 필요한 정보가 빠지거나 너무 많아진다.
Ⅴ. 기대효과 및 결론
이 구조를 따르면 아키텍처 문서는 단순한 설명이 아니라 합의 도구가 된다. 이해관계자별 Concern이 뚜렷해지면 불필요한 논쟁이 줄고, 뷰포인트가 표준화되면 문서 재사용성이 높아진다. 또한 시나리오 검증을 붙이면 "그럴듯한 그림"이 아니라 "검증 가능한 그림"이 된다.
반대로 뷰포인트가 불분명하면 같은 시스템을 놓고도 운영팀은 가용성을, 개발팀은 모듈성을, 보안팀은 통제를 각자 따로 해석한다. 결국 아키텍처 실패는 기술 실패보다 의사소통 실패에서 먼저 시작한다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| Stakeholder | 문서를 읽고 결정하는 대상 |
| Concern | 이해관계자가 궁금해하는 질문 |
| Viewpoint | 그 질문을 표현하는 틀 |
| View | 특정 시스템에 대한 실제 결과물 |
| Scenario | 여러 뷰의 일관성을 검증하는 축 |
| 품질 속성 | Concern을 구체화하는 기준 |
📈 관련 키워드 및 발전 흐름도
이해관계자 식별
│
▼
관심사 정리
│
▼
뷰포인트 선택
│
▼
뷰 작성
│
▼
시나리오 검증
│
▼
아키텍처 합의
이 흐름은 "누구의 질문인가 → 무엇을 답할 것인가 → 어떤 양식으로 보여줄 것인가 → 실제 시스템은 어떤가"로 이어진다.
👶 어린이를 위한 3줄 비유 설명
- 같은 도시라도 엄마는 병원 길, 아빠는 회사 길, 나는 놀이터 길이 궁금해요.
- 그래서 지도도 한 장이 아니라 목적별로 여러 장이 필요해요.
- 아키텍처 문서도 누가 묻는지에 맞춰 다른 답을 준비해야 해요.