227. 아키텍처 평가 기법 개요 - 소프트웨어 아키텍처 품질 속성 트레이드오프(Trade-off) 이해관계자 요구사항 검증 모델

핵심 인사이트: 1,000억짜리 빌딩(소프트웨어)을 지으려고 아키텍트(설계자)가 청사진(아키텍처 도면)을 가져왔다. 근데 사장님이 묻는다. "이 도면대로 지으면 지진에 안 무너져(가용성)? 10만 명 몰려도 안 느려져(성능)? 보안은 완벽해(보안성)? 이걸 나한테 어떻게 증명할 건데?!" 아키텍트가 땀을 뻘뻘 흘리며 "어... 지어보면 알겠죠?"라고 대답하면 당장 모가지다. "야! 시멘트(코드) 붓기 전에, 네가 그린 종이 도면(아키텍처)만 책상에 딱 펴놓고, 그 위에 온갖 가상의 재난 시나리오(시나리오 기반 평가)를 때려부어 봐!! '만약 DB 서버가 불타면? (가용성 테스트)', '만약 크래커가 침입하면? (보안성 테스트)' 이런 질문들을 던졌을 때 도면이 버텨내는지 종이 위에서 미리 평가(Evaluate)하란 말이야!!" 코드 한 줄 안 짜고 도면의 생존율을 미리 채점해 내는 모의고사, 아키텍처 평가 기법이다.

Ⅰ. 시멘트를 붓기 전의 공포 (평가의 필요성)

아키텍처(뼈대 설계)는 한 번 확정되어 개발(시멘트 붓기)이 시작되면 중간에 뜯어고치는 것이 불가능에 가깝습니다.
요구사항(기능)은 완벽히 반영했더라도, 나중에 접속자가 몰렸을 때 뻗어버리거나(성능 문제), 유지보수가 불가능한 스파게티 뼈대라면 그 프로젝트는 100% 실패합니다.

Ⅱ. 아키텍처 평가 (Architecture Evaluation)의 개념 🌟

개념: 시스템을 본격적으로 코딩하기 전에, 작성된 아키텍처 설계 모델(도면)이 이해관계자(고객, 개발자, 유지보수팀)들이 요구하는 다양한 '품질 속성(Quality Attributes: 성능, 보안, 가용성, 변경 용이성 등)'을 제대로 충족시키고 있는지를 체계적으로 분석하고 검증하는 활동입니다.

Ⅲ. 평가를 관통하는 3가지 절대 키워드 🌟 핵심 기출 🌟

1. 품질 속성 (Quality Attributes) - "채점 기준표"

단순히 "버튼 누르면 결제가 되냐?(기능)"를 평가하는 게 아닙니다. 평가는 **비기능적 요구사항(품질)**을 검증합니다.

성능 (Performance): 10만 명이 몰려도 0.1초 만에 응답하는가?
가용성 (Availability): 1대 서버가 죽어도 무정지로 돌아가는가?
보안 (Security): 해커의 공격을 방어할 뼈대가 있는가?
변경 용이성 (Modifiability): 내년에 디자인 바꿀 때 DB까지 고쳐야 하는가?

2. 트레이드오프 (Trade-off) - "상충 관계의 딜레마"

모든 품질을 다 100점으로 만족시키는 마법의 아키텍처는 우주에 존재하지 않습니다.

보안을 우주 최고로 빡세게(암호화 10번) 만들면? ➜ 암호화 푸느라 성능(속도)이 개박살 납니다.
가용성을 높이려고 서버를 10대로 복제해 두면? ➜ 비용(Cost)이 미친 듯이 폭발합니다.
평가의 목적: "보안을 10점 깎고, 대신 속도를 20점 높이는 것이 우리 회사 비즈니스에 맞는 최적의 황금비율(Trade-off)인가?"를 찾아내고 합의하는 과정입니다.

3. 시나리오 기반 평가 (Scenario-based) - "가상 시뮬레이션"

평가할 때 도면에 대고 "성능 좋나요?"라고 뜬구름 잡는 질문을 하지 않습니다.

구체적인 시나리오: "크리스마스 이브 오후 8시에(자극원), 동시 접속자가 평소의 100배인 100만 명으로 폭주했을 때(자극), 메인 결제 시스템(대상)이, 3초 이내에 결제를 완료(응답 측정)해야 한다."
이 구체적인 가상 시나리오를 도면에 들이밀어 보고 뼈대가 버티는지 시뮬레이션(채점)합니다.

Ⅳ. 4대 평가 기법 (228~230번 스포일러) 🌟

미국 카네기 멜런 대학(SEI)에서 만든 족보들입니다. 이 4개의 알파벳 약자가 시험의 핵심입니다.

SAAM: 최초의 기본 평가 모델 (기능, 변경 용이성 위주)
ATAM 🌟 (가장 중요): SAAM을 발전시켜, '트레이드오프(상충 관계)' 분석에 미친 듯이 집착하는 현대 표준 평가 모델
CBAM: ATAM 다 좋은데 돈(Cost) 생각을 안 하네? '경제적 이익(돈)' 관점까지 추가한 최고급 평가 모델
ARID: 특정 아키텍처 부분만 떼어내서 미리 코드 짜보고(Active) 평가하는 실전 모델

📢 섹션 요약 비유: 아키텍처 평가는 새로 뽑은 자동차 설계도(도면)를 실제 쇳덩어리로 만들기 전에 **'가상 풍동 실험실(시뮬레이션)'**에 집어넣는 작업입니다. 설계도만 보고 "차 이쁘네~" 하고 끝나는 게 아니라, 가상의 비바람 시나리오를 쏩니다. "시속 200km로 달리다가 눈길에서 브레이크를 밟으면(시나리오), 이 뼈대가 안 뒤집히고 버티는가(가용성/안전성)?" 만약 안 버티면 타이어를 무겁게(설계 변경) 바꿉니다. 근데 타이어가 무거워지니 연비(성능)가 떡락합니다. 여기서 아키텍트와 사장님이 머리를 맞댑니다. "안전(가용성)을 위해 연비(성능)를 포기하는 게 우리 차의 컨셉에 맞아!(트레이드오프 합의)" 이렇게 시멘트(코드)를 들이붓기 전에, 도면 위에서 발생할 수 있는 모든 재앙과 딜레마를 미리 끄집어내어 박 터지게 싸우고 가장 완벽한 타협점(아키텍처)을 확정 짓는 필수적인 보험 절차입니다.