202. 아키텍처 드라이버 (Architecture Drivers) - 소프트웨어 설계 동인 비즈니스 목표 시스템 제약사항 품질 속성 (Quality Attributes) 트레이드오프

핵심 인사이트: (201번 심화) 아키텍트가 화이트보드 앞에 섰다. "자, 이번 시스템은 마이크로서비스(MSA)로 쪼개고, DB는 클러스터링으로 빵빵하게 분산시키자!" 완벽한 설계다. 그런데 사장님이 한마디 던진다. "근데 우리 개발 예산 1천만 원밖에 없고 서버도 1대밖에 못 사는데?" 순간 화려했던 MSA 설계도는 좍좍 찢겨 쓰레기통에 박힌다. "야! 아키텍처 뼈대를 그릴 때 네 맘대로 예쁘게 상상해서 그리지 마! 사장님의 주머니 사정(제약), 해커가 털면 죽는다는 1순위 조건(품질), 올해 안에 오픈해야 한다는 시장의 압박(비즈니스 목표)... 이 3가지 멱살잡이(드라이버)가 시키는 대로 뼈대가 굽혀지고 깎여나가며 최종 형태가 나오는 거야!" 건축가의 상상력을 짓밟고 현실의 뼈대를 주조해 내는 3대 압박, 아키텍처 드라이버다.

Ⅰ. 아키텍처 드라이버(Architecture Drivers)의 개념 🌟

• 개념: 소프트웨어 아키텍처(뼈대)를 이렇게 그릴까 저렇게 그릴까 고민할 때, 최종적으로 특정 구조를 결정짓도록 멱살을 잡고 끌고 가는(Driving) 핵심적인 압박 요인과 요구사항들의 총합을 말합니다.
• 아무리 뛰어난 분산 아키텍처라도 이 '드라이버'를 만족시키지 못하면 오답이 됩니다.

Ⅱ. 아키텍처를 멱살 잡는 3대 드라이버 (시험 단골) 🌟 핵심 기출 🌟

1. 비즈니스 목표 (Business Goals) - "왜 이걸 만드나?"

• 회사가 이 시스템을 만들어서 얻고자 하는 궁극적인 돈과 전략입니다.
• 예시: "이번 카카오톡 뱅크는 무조건 모바일 결제 시장을 3달 안에 선점해야 해! (Time-to-Market)"
• 아키텍처 파급: "시간이 3달밖에 없다고? ㅆㅂ 그럼 거창한 MSA(마이크로서비스) 설계 다 취소해! 그냥 단일 통짜 서버(Monolithic) 프레임워크로 밤새 찍어내서 당장 3달 안에 오픈부터 한다!" ➜ 비즈니스가 뼈대를 단일 덩어리로 찌그러뜨려 버렸습니다.

2. 품질 속성 (Quality Attributes) 🌟 - "어떻게 돌아가야 하는가?"

기능(덧셈, 뺄셈)이 아니라, 시스템이 지녀야 할 **체력과 맷집(비기능적 요구사항)**입니다.

• 가용성 (Availability): "서버가 불타도 1초도 멈추면 안 돼!" ➜ 아키텍처는 무조건 서버 3대를 평행으로 묶는 다중화(Active-Standby) 뼈대로 강제됩니다.
• 성능 (Performance): "클릭하면 0.1초 안에 떠야 해!" ➜ 앞에 캐시 서버(Redis)를 강제로 박아 넣는 구조를 그려야 합니다.
• 보안성 (Security): "고객 정보 털리면 회사 망함!" ➜ 1079번 물리적 망분리 뼈대를 강제로 설계에 끼워 넣어야 합니다.

3. 제약 사항 (Constraints) - "피할 수 없는 현실의 벽"

아키텍트의 피눈물을 짜내는 가장 잔인한 물리적/법적/자본적 한계입니다.

• 기술적 제약: "사장님이 옛날에 사둔 낡은 오라클 DB 무조건 써야 한대." ➜ NoSQL 기반의 화려한 빅데이터 설계는 불가능해지고, RDBMS 기반의 낡은 구조로 타협해야 합니다.
• 법적 제약: "공공기관이라 무조건 국가망 보안 인증(망분리) 받아야 해."
• 조직적 제약: "우리 회사 개발자들은 자바(Java)밖에 못 해. Go 언어로 된 화려한 뼈대 짜오지 마."

Ⅲ. 아키텍트의 영원한 딜레마: 트레이드오프 (Trade-off) 🌟

드라이버들은 서로 사이가 안 좋습니다.

• 상충 관계: "성능(Performance)"을 올리려고 암호화를 빼자니 "보안성(Security)"이 개박살납니다. 보안성을 빵빵하게 하려고 방화벽을 3중으로 치면, 클릭 딜레이가 3초가 걸려 성능이 죽고, 장비값(제약)이 폭발합니다.
• 결론: 완벽한 아키텍처는 우주에 존재하지 않습니다. 아키텍트는 3대 드라이버 사이에서 피 터지게 싸우는 요소들을 저울질하며, **"지금 우리 회사 비즈니스에서 제일 중요한 1순위 품질(예: 무조건 싼 가격)을 위해 다른 품질(보안)을 눈물을 머금고 포기(Trade-off)하는 가장 아름다운 타협점"**을 도면으로 그려내는 협상의 달인이어야 합니다.

📢 섹션 요약 비유: 아키텍처 드라이버는 집(소프트웨어)을 지을 때 건축가의 화려한 상상력을 짓밟고 멱살을 잡아채는 **'잔인한 3명의 건축주(돈, 시간, 요구사항)'**입니다. 건축가는 100층짜리 전면 유리 통창 성을 그리고 싶었습니다(최고의 아키텍처). 그런데 첫 번째 건축주(제약 사항)가 **"예산은 1억 원뿐이고 땅도 좁아!"**라고 소리칩니다. 유리 성은 즉시 시멘트 1층 집으로 쪼그라듭니다. 두 번째 건축주(비즈니스 목표)가 **"이번 달 말까지 무조건 입주해야 돼!"**라고 채찍질합니다. 정교한 설계는 개나 주고 조립식 컨테이너 뼈대로 도면이 바뀝니다. 세 번째 건축주(품질 속성)가 **"대신 진도 8.0 지진에도 안 무너져야 해!(가용성)"**라며 말도 안 되는 조건을 덧붙입니다. 건축가는 1달 만에 짓는 싸구려 컨테이너 집 바닥에 미친 듯이 두꺼운 H빔 철골을 용접하는 기괴한 도면(트레이드오프 타협안)을 눈물을 머금고 그려냅니다. 이 3명의 미친 압박 요인(드라이버)이 부딪히고 깎여나간 상처투성이 타협의 결과물이 바로 살아 숨 쉬는 진짜 소프트웨어 아키텍처의 뼈대입니다.