90. 아키텍처 드라이버 (Architecture Drivers) - 시스템 설계의 절대 기준

⚠️ 이 문서는 아키텍트(설계자)가 모바일 앱을 만들 때 서버를 1대로 할지 클라우드로 할지, DB를 오라클로 할지 몽고DB로 할지 결정해야 하는 수만 가지 선택의 갈림길에서, **"우리 회사의 이번 프로젝트 아키텍처 방향성을 강제로 한쪽으로 멱살 잡고 끌고 가는 가장 치명적이고 양보 불가능한 핵심 요구사항들의 집합인 '아키텍처 드라이버(Architecture Drivers)'"**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 단순히 "버튼 색깔을 빨갛게 해주세요" 같은 겉절이 요구사항이 아니다. 이걸 못 지키면 프로젝트 자체가 망하고 회사가 문을 닫게 만드는, 아키텍처의 뼈대(모양)를 180도 뒤틀어버리는 '조종대(Driver)' 역할을 하는 극소수의 핵심 조건들이다.
  2. 가치: 세상에 싸고, 1만 명 버티고, 하루 만에 개발 끝나는 마법의 시스템은 없다. 아키텍트는 쏟아지는 백 가지 요구사항 중에서 이 드라이버 5개만 핀셋으로 뽑아내어, 한정된 돈과 시간 안에서 시스템 설계의 최우선 타협점(Trade-off) 잣대로 삼는다.
  3. 기술 체계: 시스템이 제공해야 할 핵심 기능(Primary Functionality), 1초 안에 떠야 한다는 식의 품질 속성(Quality Attributes), 그리고 돈이 1억밖에 없거나 무조건 오픈소스만 쓰라는 제약 사항(Constraints) 이 3박자가 모여 드라이버를 구성한다.

Ⅰ. 아키텍처의 방향키: 왜 모든 요구사항이 평등하지 않은가?

게시판 폰트 크기 변경은 아키텍처를 뒤흔들지 않지만, "10만 명 동시 접속"은 뼈대를 박살 낸다.

  1. 일반 요구사항과 드라이버의 차이:
    • 신규 쇼핑몰을 만든다. 고객이 요구사항 100개를 던졌다.
    • [요구사항 13번]: "장바구니 아이콘은 우측 상단에 놔주세요." $\rightarrow$ 이건 개발자가 그냥 HTML 화면 하나 고치면 끝난다. 아키텍처(서버 뼈대)에는 1%의 타격도 없다. 일반 요구사항이다.
    • [요구사항 45번]: "블랙프라이데이 때 동시 접속자 100만 명의 결제 트래픽이 몰려도 서버가 터지지 않게 해주세요." $\rightarrow$ 이 한마디 때문에 아키텍트는 기존에 짰던 단일 DB(Monolithic) 도면을 갈기갈기 찢어버리고, AWS 오토스케일링과 카프카(Kafka) 비동기 메시지 큐라는 거대한 뼈대 수술을 단행해야 한다. 이것이 바로 아키텍처를 멱살 잡고 끄는 조종대(Driver)다.
  2. 트레이드 오프 (Trade-off)의 강제:
    • 드라이버는 무조건 서로 싸운다(상충).
    • [드라이버 A]: "결제 속도는 무조건 0.1초 내로!(성능)"
    • [드라이버 B]: "모든 결제 내역은 3중 암호화와 3곳의 망분리 DB에 백업해라!(보안/가용성)"
    • 암호화를 3번 하면 속도는 무조건 1초로 느려진다. 아키텍트는 이 드라이버들 사이에서 사장님과 피 터지게 협상하여 "속도를 0.5초로 양보하고 암호화는 2번만 합시다"라는 최적의 타협점(Sweet Spot) 도면을 그려내야 한다.

📢 섹션 요약 비유: 자동차를 주문 제작합니다. "시트 색깔 핑크색으로 해주세요"는 껍데기 주문이라 자동차 프레임 공장(아키텍처)에 영향이 없습니다. 하지만 "시속 300km로 달리게 해주시고(성능 드라이버), 예산은 1,000만 원 이하(제약 드라이버)로 맞춰주세요"라고 하면 공장장은 멘붕에 빠집니다. 값싼 철판을 쓰면 차가 바람에 날아가고, 무거운 철판을 쓰면 300km를 못 달립니다. 이 불가능한 조종대(드라이버) 사이에서 가장 안 터지는 뼈대를 고민하는 것이 아키텍트의 숙명입니다.

Ⅱ. 아키텍처 드라이버의 3대 핵심 뼈대

기능, 품질, 그리고 가장 무서운 '제약 조건'이 도면을 결정한다.

  1. 핵심 기능 (Primary Functionality):
    • 시스템이 존재하는 근본적인 '밥줄' 역할이다.
    • 은행 시스템이라면 "계좌 이체 기능", 우버(Uber)라면 "택시와 승객의 실시간 매칭 기능".
    • 이 핵심 기능들이 도면에 큼지막한 컴포넌트(결제 모듈, 매칭 모듈) 덩어리로 제일 먼저 정중앙에 박히게 된다. (이 핵심 기능 외에 '공지사항 게시판' 같은 겉절이는 드라이버에 끼지 못한다.)
  2. 품질 속성 (Quality Attributes) $\star$:
    • 사실상 아키텍트의 영혼을 가장 많이 갈아 먹는 드라이버 군단이다.
    • 가용성 (Availability): "서버가 불타도 1초의 끊김 없이 옆 서버가 이어받아야 한다" $\rightarrow$ 아키텍트는 액티브-스탠바이(Active-Standby) 이중화 도면을 그린다.
    • 보안성 (Security): "DB가 털려도 개인정보는 절대 못 풀게 하라" $\rightarrow$ 아키텍트는 암호화 모듈과 사설망(Private Subnet) 격리 도면을 추가한다.
    • 확장성 (Scalability): "회원 수가 10배 늘어도 시스템을 갈아엎지 않게 하라" $\rightarrow$ 아키텍트는 마이크로서비스(MSA) 도면을 그린다.
  3. 제약 사항 (Constraints):
    • 돈, 시간, 법률, 회사 정치처럼 "아무리 기술이 좋아도 절대 거역할 수 없는 통제선"이다.
    • 비즈니스 제약: "개발 기한은 딱 3개월, 예산은 5천만 원." $\rightarrow$ 아키텍트는 멋진 클라우드를 포기하고, 이미 만들어둔 낡은 오픈소스를 가져다 쓰는 가성비 도면으로 타협한다.
    • 기술 제약: "우리 회사 인프라팀은 자바(Java)와 오라클밖에 다룰 줄 모른다." $\rightarrow$ 아키텍트가 아무리 파이썬이 좋다고 우겨도 무조건 도면은 자바(Spring) 기반으로 그려져야 한다.

📢 섹션 요약 비유: 식당을 엽니다. 핵심 기능은 "불맛 나는 짬뽕을 제공한다" 입니다(주방에 강력한 화구 배치). 품질 속성은 "주문 후 무조건 5분 안에 나와야 한다(성능)" 입니다(재료를 미리 다 썰어놓는 냉장고 동선 배치). 제약 사항은 "보증금이 5천만 원뿐이고, 식당 평수가 10평밖에 안 된다" 입니다(가게 크기에 맞춰 테이블을 다닥다닥 붙인 타협된 인테리어 도면 작성). 이 3가지 팩폭 요인들이 인테리어 업자(아키텍트)의 도면을 100% 결정짓습니다.

Ⅲ. 드라이버의 도출과 유틸리티 트리 (Utility Tree)

추상적인 헛소리를 구체적인 '측정 가능한 시나리오'로 멱살 잡고 끌어내라.

  1. "시스템이 좀 빨랐으면 좋겠어요"의 붕괴:
    • 사장님이 이렇게 요구사항(품질 속성)을 던지고 가면 아키텍트는 아무 도면도 그릴 수 없다.
    • 빠른 게 1초인지, 0.1초인지 기준이 없기 때문이다. 아키텍트는 이 뭉툭한 요구사항을 뾰족한 숫자로 다듬어내는 과정을 거친다.
  2. 유틸리티 트리 (Utility Tree) 기법:
    • 트리(나무) 구조로 뭉툭한 소원을 구체적 시나리오로 쪼개는 훌륭한 워크샵 기법이다.
    • 최상위 루트: [성능 향상]
    • $\rightarrow$ 중간 가지: [응답 시간]
    • $\rightarrow$ 최하단 잎사귀(시나리오): "평상시(환경), 고객 1만 명이(자극), 결제 버튼을 누르면(사건), 99%의 요청이(측정), 0.5초 이내에 완료되어야 한다(응답)."
  3. 우선순위 매기기 (H/M/L):
    • 이렇게 구체적인 시나리오를 30개 뽑아낸 뒤, 사장님과 모여서 우선순위를 알파벳으로 매긴다.
    • [비즈니스 중요도(H/M/L) / 아키텍처 구현 난이도(H/M/L)]
    • 예: 결제 0.5초 처리 시나리오는 중요도 H(High), 난이도 H(High) 다. $\rightarrow$ 이 녀석이 바로 우리 프로젝트를 멱살 잡고 끌고 갈 핵심 1순위 아키텍처 드라이버로 당당하게 선정되며, 첫 달 개발비의 절반이 이 뼈대를 구축하는 데 쏟아붓게 된다.

📢 섹션 요약 비유: 고객이 인테리어 업자에게 "집이 좀 따뜻했으면 좋겠어요"라고 말하면 망합니다. 업자(아키텍트)는 유틸리티 트리를 통해 "겨울철 영하 10도(환경)일 때, 보일러를 켜면(자극), 거실 온도가 10분 내에(측정), 24도에 도달해야 한다(응답)"는 구체적인 계약서 시나리오를 뽑아냅니다. 그리고 이 '따뜻함'이 '집의 디자인(통창뷰)'보다 중요한지 H/M/L 투표를 붙입니다. 따뜻함이 압도적 1위(드라이버)가 되면, 예쁜 유리 통창뷰는 싹 다 지워버리고(트레이드 오프) 벽돌과 단열재를 3중으로 때려 박는 방향으로 최종 건축 도면이 확정되는 냉혹한 검증 과정입니다.