핵심 인사이트 (3줄 요약)
- 본질: 소프트웨어 아키텍처 평가는 시스템을 본격적으로 만들기 전, 설계도가 비즈니스 목표와 품질 요구사항(보안, 성능 등)을 잘 충족하는지 전문가들이 모여 분석하고 검증하는 활동이다.
- 가치: 나중에 발견하면 수정 비용이 100배가 드는 '구조적 결함'을 초기에 찾아내며, ATAM(품질 중심)과 CBAM(경제적 가치 중심) 기법을 통해 최적의 의사결정을 지원한다.
- 판단 포인트: 특정 설계 선택이 성능을 높이면 보안이 낮아지는 '상충 관계(Trade-off)'와 결과에 큰 영향을 주는 '민감도(Sensitivity)'를 논리적으로 도출했는지 점검한다.
Ⅰ. 개요 및 필요성
"집을 다 지었는데 안방에 문이 없다면?" 혹은 "다 지은 고층 빌딩이 태풍에 흔들린다면?" 기초 공사 단계에서 설계도를 제대로 검토하지 않은 대가다. 아키텍처 평가는 IT 프로젝트의 '사전 설계 심의'다. 단순히 "기능이 잘 된다"를 넘어, "사람이 100만 명 몰려도 안 터질까?", "해킹에 뚫리지는 않을까?" 같은 품질 속성을 꼼꼼히 따져본다. 이 과정에서 아키텍처의 약점을 미리 파악함으로써 프로젝트의 대재앙을 예방한다.
📢 섹션 요약 비유: 아키텍처 평가는 '신차 출시 전 충돌 테스트 및 시뮬레이션'과 같다. 차를 대량 생산하기 전에 설계가 안전한지, 연비는 좋은지 전문가들이 모여 꼼꼼히 따져보고 합격점을 주는 과정이다.
Ⅱ. 아키텍처 및 핵심 원리
1. 주요 평가 모델
- ATAM (Architecture Analysis Method):
- 목적: 품질 속성(Modifiability, Security 등) 사이의 상충 관계를 분석.
- 방법: 품질 속성 시나리오를 작성하고, 아키텍처가 이를 어떻게 해결하는지 검토.
- CBAM (Cost Benefit Analysis Method):
- 목적: 경제적 관점에서 어떤 아키텍처가 가장 돈값을 하는지(ROI) 분석.
- 방법: 각 설계 대안의 비용과 비즈니스 이익을 수치화하여 우선순위 결정.
2. 핵심 분석 로직
- 민감도 (Sensitivity Point): 특정 아키텍처 결정이 품질 속성에 큰 변화를 주는 지점. (예: 암호화 알고리즘을 바꾸면 보안이 확 올라감)
- 상충점 (Trade-off Point): 한쪽을 좋게 하면 다른 쪽이 나빠지는 지점. (예: 보안을 높이면 성능이 떨어짐)
- 리스크 (Risk): 미래에 문제를 일으킬 가능성이 있는 아키텍처 결정 사항.
📢 섹션 요약 비유: ATAM은 '건강검진'이다. 어디가 아플지 미리 찾는 것이다. CBAM은 '재테크 상담'이다. 어떤 약(기술)을 먹는 게 가성비가 제일 좋은지 따지는 것이다.
Ⅲ. 비교 및 연결
ATAM vs CBAM 비교
| 비교 항목 | ATAM (품질 중심) | CBAM (비용 중심) |
|---|---|---|
| 핵심 질문 | "이 설계는 튼튼하고 안전한가?" | "이 설계를 하는 게 이득인가(ROI)?" |
| 분석 대상 | 품질 속성 간의 충돌 및 영향도 | 비용, 이익, ROI 기반 우선순위 |
| 수행 시점 | 아키텍처 설계 중기 | ATAM 이후 의사결정 단계 |
| 결과물 | 민감도, 상충점, 리스크 목록 | 기술 대안별 경제적 순위 |
📢 섹션 요약 비유: ATAM으로 '이 약을 먹으면 몸(품질)이 좋아진다'는 걸 확인했다면, CBAM으로 '그 약값이 너무 비싸지는 않은지(비용 대비 효과)'를 따져보는 순서와 같다.
Ⅳ. 실무 적용 및 기술사 판단
기술사 핵심 포인트 (도출 로직):
- 시나리오 중심 평가: "사용자가 갑자기 10배 늘어날 때" 같은 구체적인 '품질 속성 시나리오'가 평가의 기초가 되어야 함을 강조한다.
- 브레인스토밍과 워크숍: 평가는 혼자 하는 게 아니라 아키텍트, 발주자, 개발자가 모여 의견을 나누는 '합의의 과정'임을 언급한다.
- 감리인의 역할: 감리원은 사업자가 작성한 아키텍처 평가 보고서가 단순히 형식적인지, 아니면 실제 '상충 관계'를 분석하여 설계를 보완했는지 실질적인 내용을 진단한다.
📢 섹션 요약 비유: 아키텍처 평가원은 '베테랑 항해사'다. 배가 출발하기 전에 설계도를 보고 "이 모양은 속도는 빠르지만 큰 파도(부하)에 뒤집힐 수 있습니다(상충점 도출)"라고 미리 경고해주는 역할이기 때문이다.
Ⅴ. 기대효과 및 결론
아키텍처 평가는 소프트웨어 공학의 '예방 의학'이다. 구조적 결함은 나중에 고치려면 시스템 전체를 부수고 다시 지어야 하는 대공사가 필요하기 때문이다. 기술사 시험에서는 ATAM의 9단계 절차나 시나리오 도출 방법을 정확히 기술하고, 기술적 완결성(ATAM)과 비즈니스 경제성(CBAM)이 조화를 이루어야 진정으로 성공한 아키텍처임을 논리적으로 설파해야 한다.
📢 섹션 요약 비유: 아키텍처 평가는 IT 세상의 '지도 검토'다. 목적지(비즈니스 목표)까지 가는 길이 끊겨있지는 않은지, 지름길(최적화)은 어디인지 미리 지도를 보고 상의하여 가장 안전하고 빠른 길을 정하는 지혜다.
📌 관련 개념 맵
| 개념 | 연관 키워드 | 관계 |
|---|---|---|
| Quality Attribute | 보안, 성능, 가용성 | 아키텍처가 달성해야 할 구체적인 목표들 |
| Scenario | 자극, 환경, 응답 | 아키텍처를 테스트하기 위한 가상의 상황 문답 |
| Trade-off | 상충 관계, 선택 | 하나를 위해 하나를 양보해야 하는 엔지니어링의 본질 |
| ADR | 아키텍처 결정 기록 | 평가 결과와 결정 이유를 남겨두는 문서 |
👶 어린이를 위한 3줄 비유 설명
- 집을 짓기 전에 설계도를 보면서 똑똑한 선생님들이 "여기가 무너지면 어쩌지?" 하고 미리 걱정해보는 시간이에요.
- "문을 튼튼하게 하면(보안) 무거워서 열기 힘들지 않을까(성능)?" 같은 고민을 해서 가장 좋은 방법을 정해요.
- 미리 꼼꼼하게 따져보니까, 나중에 집을 다 지었을 때 고장 나거나 다시 부수는 일 없이 완벽한 집이 된답니다.