Ch05 아키텍처 특성의 식별

한 줄 정의

아키텍처 특성의 식별이란 도메인 관심사, 요구사항, 암묵적 도메인 지식이라는 세 가지 출처에서 시스템에 꼭 필요한 아키텍처 특성을 도출하고, 그 수를 최소한으로 제한하여 우선순위를 매기는 과정입니다.

쉽게 말하면

4장에서 아키텍처 특성이 무엇인지 정의했다면, 이 장은 우리 시스템에 필요한 특성을 어떻게 찾아내는가 에 관한 것입니다.

아키텍처 특성은 세 곳에서 찾을 수 있습니다. 이해관계자가 “시장 진입 속도가 중요해요”라고 말하면 그것을 민첩성·테스트성·배포성으로 번역 하고(도메인 관심사), 요구사항 문서에서 “수백만 사용자”라는 문구를 보고 확장성을 추출 하고(명시적 특성), 해당 도메인에서 당연히 필요한 보안·가용성 같은 것을 경험으로 채워 넣습니다(암묵적 특성).

하지만 찾아낸 특성을 전부 지원하려고 하면 설계가 과도하게 복잡해집니다. 그래서 핵심은 가장 중요한 3개로 좁히는 것 입니다. 이해관계자와 함께 우선순위를 정하고, 나머지는 과감히 덜어내야 합니다.

왜 중요한가?

해결하는 문제: 도메인 이해관계자들의 비즈니스 언어를 아키텍처 특성으로 체계적으로 번역하고, 우선순위를 매겨 설계 방향을 결정하는 근거를 마련합니다.
이게 없다면: 모든 아키텍처 특성을 지원하려는 범용 아키텍처(generic architecture) 가 만들어지고, 설계가 복잡해져서 결국 아무것도 잘 지원하지 못하는 시스템이 됩니다. 바사호(Vasa) 사례처럼 과도한 특성 요구가 프로젝트를 침몰시킵니다.

핵심 내용

왜 아키텍처 특성 식별이 어려운가?

아키텍처 특성을 식별하는 것이 어려운 근본적인 이유는 번역 문제 입니다.

아키텍트는 확장성, 가용성, 내결함성 같은 용어를 쓰고, 도메인 이해관계자는 인수합병, 시장 진입 속도, 사용자 만족도 같은 용어를 씁니다. 서로 다른 언어로 말하기 때문에 ‘번역 중 손실(lost in translation)’ 문제가 발생합니다.

이 문제를 해결하려면, 도메인 관심사를 아키텍처 특성으로 번역 할 수 있어야 합니다.

도메인 관심사	아키텍처 특성
인수합병(M&A)	상호운용성, 확장성, 적응성, 확장 능력
시장 진입 속도	민첩성, 테스트성, 배포성
사용자 만족도	성능, 가용성, 내결함성, 테스트성, 배포성, 민첩성, 보안
경쟁 우위	민첩성, 테스트성, 배포성, 확장성, 가용성, 내결함성
시간과 예산	단순성, 타당성

이 표에서 주목할 점은 하나의 도메인 관심사가 여러 개의 아키텍처 특성 에 대응된다는 것입니다. “사용자 만족도”를 “성능”에만 매칭하면 잘못된 등가 관계가 만들어집니다.

잘못된 등가 관계와 복합 아키텍처 특성

이 번역 과정에서 가장 흔한 실수는 도메인 관심사를 하나의 아키텍처 특성에 1:1로 매칭 하는 것입니다. “시장 출시 속도” = “민첩성” 같은 등가 관계를 만드는 것입니다.

이것이 위험한 이유는 민첩성 같은 특성이 복합(composite) 아키텍처 특성 이기 때문입니다. 민첩성 자체는 측정할 수 있는 척도가 없습니다. 민첩성은 배포성, 모듈성, 테스트성 등 따로 측정할 수 있는 하위 특성들로 구성됩니다.

1:1 매칭을 하면 이 하위 특성들이 누락됩니다. 마치 케이크 반죽을 만들면서 밀가루만 빼먹는 것과 같습니다. 한 가지 요소만 다루면 나머지를 놓치게 됩니다.

펀드 기준가 산정 예시: 1:1 매칭의 함정

“장 마감 펀드 기준가 산정(end-of-day fund pricing)을 정해진 시간 내에 완료해야 한다”는 요구를 받았을 때, 가장 눈에 띄는 특성은 성능 입니다. 하지만 성능에만 집착하면 시스템이 실패합니다.

아무리 빨라도 필요한 순간에 사용할 수 없으면 아무 소용 없습니다 → 가용성
펀드 수가 늘어나면 시스템 규모를 키울 수 있어야 합니다 → 확장성
마감 시점에 다운되면 곤란합니다 → 신뢰성
산정 85% 시점에 장애가 나면 처음부터 다시? 중단 시점부터 재개해야 합니다 → 복구성
빠르기만 하면 끝? 기준가가 정확한지 검증해야 합니다 → 감사성(auditability)

비즈니스 목표의 상당수는 이처럼 복합 아키텍처 특성에서 출발합니다. 아키텍트의 역할은 이런 복합 목표를 측정 가능한 개별 특성으로 분해 하는 것입니다.

어떻게 찾는가: 아키텍처 카타

아키텍처 특성을 찾아낼 수 있는 곳은 세 군데입니다. 이 도출 과정을 연습하기 위한 방법으로 아키텍처 카타(Architecture Kata) 가 있습니다.

카타 는 일본 무술에서 올바른 자세와 기술을 반복 훈련하는 방식에서 유래한 용어입니다. 아키텍처 카타는 테드 뉴워드(Ted Neward)가 고안한 것으로, 도메인 설명에서 아키텍처 특성을 도출하는 연습 문제입니다. 소규모 팀이 제한된 시간 내에 카타를 분석하고, 각자의 결과를 공유하면서 아키텍처적 사고를 훈련합니다.

각 카타는 다음 형식으로 구성됩니다.

섹션	설명
설명	시스템이 해결하려는 전반적인 도메인 문제
사용자	예상 사용자 수나 유형 같은 사용자 정보
요구사항	도메인 사용자 및 전문가가 기대하는 시스템 요구사항들
추가 맥락	요구사항에 포함되지 않더라도 설계에 영향을 줄 요소들

아래의 실리콘 샌드위치 카타를 예시로 세 가지 출처에서 아키텍처 특성을 도출하는 과정을 살펴보겠습니다.

카타: 실리콘 샌드위치

설명 전국 규모 샌드위치 전문점이 기존의 전화 주문 서비스 외에 온라인 주문 기능을 제공하려고 합니다.

사용자 현재는 수천 명이지만 언젠가는 수백만 명에 이를 수도 있습니다.

요구사항

사용자가 음식을 주문할 수 있도록 합니다

매장이 배달 서비스를 제공한다면, 사용자가 포장 또는 배달을 선택할 수 있어야 합니다

포장 고객에게는 주문을 수령할 시간과 매장을 찾아오는 방법을 안내합니다 (교통 정보와 외부 지도 서비스의 통합이 필요합니다)

배달 서비스의 경우, 주문된 음식을 배달 기사가 사용자에게 배달합니다

모바일 기기로 접근할 수 있게 합니다

전국 모든 매장에서 일일 판촉/할인 행사를 시행합니다

매장별로 자체 일일 판촉/할인 행사를 시행합니다

온라인 결제, 매장 내 결제, 착불 결제(배달 시 결제)를 모두 허용합니다

추가 맥락

실리콘 샌드위치 매장들은 가맹점 방식(프랜차이즈)으로 운영됩니다. 따라서 매장마다 소유자가 다릅니다

본사는 조만간 해외 진출을 계획하고 있습니다

본사의 목표는 값싼 인력을 고용해서 이윤을 극대화하는 것입니다

요구사항별 아키텍처 영향 분석

아키텍트가 가장 먼저 할 일은 각 요구사항을 하나씩 검토하면서 “이것이 아키텍처에 영향을 주는가?” 를 판단하는 것입니다. 모든 요구사항이 아키텍처 특성을 도출하는 것은 아닙니다 — 상당수는 아키텍처에 아무런 영향이 없습니다.

요구사항	아키텍처 영향	이유
사용자가 음식을 주문할 수 있도록 합니다	없음	핵심 기능이지만 특별한 구조적 지원이 필요하지 않습니다
포장 또는 배달을 선택할 수 있어야 합니다	없음	마찬가지로 특별한 아키텍처 특성을 요구하지 않습니다
포장 고객에게 매장까지의 교통 정보를 안내합니다	신뢰성	외부 지도 서비스와의 통합 지점(integration point) 이 생깁니다. 외부 서비스가 다운되면? 사이트 전체를 장애로 만들 것인지, 교통 정보 없이 안내할 것인지를 결정해야 합니다
배달 기사가 음식을 배달합니다	없음	아키텍처 특성을 요구하지 않습니다
모바일 기기로 접근할 수 있게 합니다	성능 관련	웹 앱 vs 네이티브 앱 결정에 영향을 미치며, 모바일 환경에 민감한 페이지 로딩 시간 등 성능 관련 아키텍처 특성 몇 가지를 명확하게 정의할 필요가 있습니다
전국 매장 일일 판촉 + 매장별 자체 판촉	맞춤성	전국 공통 행동방식 위에 매장별 재정의(overriding)가 필요하므로 구조적 설계 차원의 결정을 요구합니다
온라인/매장/착불 결제를 모두 허용합니다	(상황에 따라)	결제를 서드파티 PG사에 위임하면 아키텍처 영향이 작고, 직접 처리하면 보안 이 아키텍처 수준으로 승격됩니다
프랜차이즈 방식 운영 (추가 맥락)	맞춤성	매장별 판촉과 결합하여 맞춤성의 필요를 강화합니다
해외 진출 계획 (추가 맥락)	국제화(i18n)	아키텍처 구조 변경 없이 다양한 설계 기법으로 대응할 수 있지만, UX 관련 결정에는 영향을 줍니다
값싼 인력으로 이윤 극대화 (추가 맥락)	없음	생산성이 중요하다는 암시이지만 아키텍처 특성과는 직접 거리가 있습니다

이 분석에서 중요한 점은 두 가지입니다. 첫째, 요구사항의 절반 이상이 아키텍처에 영향을 주지 않습니다 — 모든 요구사항에서 억지로 특성을 끌어내려 하면 안 됩니다. 둘째, 영향을 주는 요구사항도 “아키텍처 특성”이라고 직접 쓰여 있지 않습니다 — 아키텍트가 행간을 읽어야 합니다.

이제 이 분석에서 도출된 특성들을 명시적 특성과 암묵적 특성으로 나누어 살펴보겠습니다.

출처 1: 요구사항에서 추출하는 명시적 특성

요구사항 문서에 직접적으로 드러나는 특성입니다. 다만 “확장성을 지원하라”처럼 명시되는 게 아니라, “사용자가 수백만 명에 이를 수도 있다”처럼 도메인 언어로 표현 되므로 아키텍트가 번역해야 합니다.

확장성 vs 탄력성: 비슷해 보이지만 다릅니다

“수백만 사용자”라는 요구에서 확장성 이 도출됩니다. 하지만 여기서 한 발 더 나아가야 합니다 — 샌드위치 매장의 트래픽이 하루 종일 균일할까요? 점심·저녁 시간대에 집중될 것이 거의 확실하므로, 탄력성 도 필요합니다.

이 둘은 흔히 한데 묶이지만 제약조건이 다릅니다.

	확장성(Scalability)	탄력성(Elasticity)
측정 상황	시간에 따라 사용자 수가 꾸준히 증가	트래픽이 순간적으로 급증
패턴	점진적 성장 곡선	스파이크 형태
예시	호텔 예약 시스템 (계절에 따른 예측 가능한 변화)	콘서트 티켓 예매 (판매 시작 시 폭발적 접속)
단독 존재	탄력성 없이 존재 가능	보통 확장성도 함께 필요

이처럼 하나의 요구사항에서 하나가 아니라 여러 특성 이 도출될 수 있다는 점이 중요합니다.

출처 2: 도메인 지식에서 나오는 암묵적 특성

요구사항 문서에 명시되지 않지만 해당 도메인에서 당연히 기대되는 특성입니다. 이것이 위험한 이유는 경험이 부족한 아키텍트가 놓치기 쉽기 때문입니다.

실리콘 샌드위치의 경우:

가용성 — “사이트가 24시간 접속 가능해야 한다”고 요구사항에 쓰여 있지 않지만, 사용자가 접속할 수 없으면 주문도 없습니다
신뢰성 — 외부 지도 서비스에 의존하는데, 그 서비스가 고장 나면? 사이트 전체를 장애로 만들 것인지, 교통 정보 없이 덜 효율적으로 안내할 것인지를 결정해야 합니다
보안 — 결제 처리를 서드파티 PG사에 위임한다면 별도의 아키텍처 구조 없이 기본 수칙만으로 충분할 수 있습니다. 하지만 직접 결제를 처리한다면 보안은 아키텍처 수준의 특성으로 승격됩니다

여기서 핵심적인 판단 기준은 4장에서 다룬 “이 관심사가 특별한 구조적 지원을 필요로 하는가?” 입니다. 보안처럼 같은 관심사라도 설계 결정에 따라 아키텍처 특성이 될 수도 있고 아닐 수도 있습니다.

출처 3: 비즈니스 맥락에서 읽어내는 특성

요구사항도 아니고 순수한 도메인 지식도 아닌, 비즈니스 상황의 행간 에서 읽어내야 하는 특성입니다.

실리콘 샌드위치의 추가 맥락에 “매장들은 프랜차이즈 방식으로 운영되며 매장별 자체 판촉/할인 행사를 시행한다”고 되어 있습니다. 이것은 곧 매장별 재정의(overriding)가 필요하다는 뜻이며, 여기서 맞춤성(customizability) 이 도출됩니다.

맞춤성이 왜 아키텍처 수준의 특성인가? 단순한 설정값 변경이 아니라, 레시피·지역별 판매·매장 방문 경로 안내 등 다양한 도메인에서 매장별 행동방식의 커스텀화를 지원해야 하기 때문입니다. 이것은 마이크로커널 아키텍처의 플러그인 구조나 템플릿 메서드 패턴 같은 구조적 설계 차원 의 결정을 요구합니다.

어떻게 줄이는가: 제한과 우선순위

특성을 찾아내는 것만큼 중요한 것이 줄이는 것 입니다. 아키텍처 특성은 공짜가 아니기 때문입니다 — 특성이 추가될 때마다 설계 복잡도가 올라가고, 특성들 간의 상승작용(시너지) 이 예측하기 어려운 방식으로 복잡성을 증폭시킵니다.

가장 흔한 안티패턴은 범용 아키텍처(generic architecture) — 모든 아키텍처 특성을 지원하려는 시도입니다.

아키텍처에 정답은 없습니다. 값비싼 답이 있을 뿐입니다. — 마크의 유명한 명언 중

바사호(Vasa)의 교훈: 모든 것을 다 하려다 침몰합니다

1626~1628년에 건조된 스웨덴 군함 바사호는 이 안티패턴의 실물 사례입니다. 병력 수송선이면서 동시에 최강의 전투함이 되려고 했습니다 — 보통 배들은 한 가지만 잘했지만, 바사호는 두 배 크기에 두 배의 포를 실었습니다. 결과적으로 위쪽이 무거워져 첫 항해에서 전복, 침몰했습니다.

소프트웨어 프로젝트도 마찬가지입니다. 모든 특성을 다 지원하려고 하면 각 특성이 서로를 제약하면서 설계가 과도하게 복잡해지고, 결국 아무것도 잘 하지 못하는 시스템이 됩니다.

아키텍처 특성 워크시트: 구조적으로 줄이는 도구

이 책에서는 특성의 수를 제한하기 위한 실용적인 도구로 아키텍처 특성 워크시트 를 제안합니다. 아키텍트가 이해관계자들과 함께 실시간 논의에서 사용하는 도구입니다.

구역	내용	역할
왼쪽 열: 핵심 특성	최대 7개 까지 기입	후보 특성 나열
오른쪽 위: 암묵적 특성	타당성, 보안, 유지보수성, 관측성	놓치기 쉬운 것들 체크
오른쪽 아래: 기타 고려사항	새로 추가되는 특성과 충돌하는 요소들	트레이드오프 기록

7개로 제한하는 이유는 목록의 길이를 의도적으로 제한 함으로써 “정말 필요한가?”를 강제하기 위해서입니다.

최종 3개는 이해관계자에게 맡겨라

7개 이하로 좁힌 후, 최종적으로 가장 중요한 3개 를 선정합니다. 이 3개를 뽑는 일을 아키텍트가 단독으로 하는 것이 아니라 도메인 이해관계자에게 맡기는 것 이 핵심입니다.

아키텍트가 처음부터 끝까지 혼자 결정하면 두 가지 문제가 생깁니다. 첫째, 시간 낭비입니다 — 이해관계자들과 불필요한 갈등과 분쟁을 겪게 됩니다. 둘째, 합의가 없으므로 나중에 트레이드오프가 발생했을 때 “왜 이렇게 결정했냐”는 질문에 아키텍트 혼자 답해야 합니다.

이해관계자가 직접 3개를 고르면 합의가 쉬워지고, “진짜 중요한 게 뭔가” 에 대한 생산적인 논의가 시작됩니다. 이 과정과 결과물이 이후 모든 아키텍처적 결정의 핵심 동인(driving force) 이 됩니다.

정리

명시적 특성 vs 암묵적 특성 (식별 관점)

기준	명시적 특성	암묵적 특성
출처	요구사항 문서의 명시적 문구	도메인 지식, 경험
발견 방법	요구사항 분석	도메인 이해 + 아키텍트 경험
예시 (실리콘 샌드위치)	확장성, 탄력성, 성능	가용성, 신뢰성, 보안, 맞춤성
위험	비교적 놓치기 어려움	경험 부족 시 누락될 수 있음

확장성 vs 탄력성

기준	확장성 (Scalability)	탄력성 (Elasticity)
측정 상황	시간에 따라 사용자 수가 꾸준히 증가	트래픽이 순간적으로 급증
패턴	점진적 성장 곡선	스파이크 형태
예시	호텔 예약 시스템 (계절에 따른 예측 가능한 변화)	콘서트 티켓 예매 (판매 시작 시 폭발적 접속)
관계	탄력성 없이 존재 가능	보통 확장성도 함께 필요

범용 아키텍처 vs 제한된 특성의 아키텍처

기준	범용 아키텍처	제한된 특성의 아키텍처
지원 특성 수	가능한 한 많이	최대 7개, 핵심 3개
설계 복잡도	매우 높음	관리 가능
트레이드오프	모든 것을 조금씩 지원 → 아무것도 잘 못함	핵심에 집중 → 명확한 설계 방향
실패 사례	바사호	—

내 생각

번역의 문제 는 실무에서 정말 자주 겪는 일입니다. 기획자가 “빨라야 해요”라고 하면 그것이 성능인지, 배포 속도인지, 시장 진입 속도인지를 구분해야 합니다. 표 5-1 같은 번역 테이블 을 팀 내에서 공유해두면 커뮤니케이션 비용을 크게 줄일 수 있습니다.
복합 아키텍처 특성 의 함정은 실무에서 가장 흔한 실수 중 하나입니다. “성능이 중요하다”고 하면 성능에만 매몰되기 쉬운데, 실제로는 가용성·신뢰성·복구성이 함께 확보되지 않으면 성능만으로는 의미가 없습니다. 펀드 기준가 산정 예시처럼 “그래서 이게 왜 중요한데?” 를 반복하면 숨겨진 특성들이 드러납니다.
아키텍처 카타 는 팀 내에서 아키텍처 역량을 키우는 데 매우 실용적인 방법입니다. 점심시간에 소규모 모임을 조직해서 카타를 함께 풀면, 경험이 많은 아키텍트의 사고 과정을 자연스럽게 배울 수 있습니다.
상위 3개로 좁히는 것 이 핵심입니다. 모든 특성을 지원하려는 욕심은 바사호의 교훈처럼 프로젝트를 침몰시킵니다. 이해관계자에게 우선순위 결정을 맡기면 합의도 쉬워지고, “무엇이 정말 중요한가”에 대한 생산적인 논의가 시작됩니다.
확장성과 탄력성의 구분 은 클라우드 환경에서 특히 중요합니다. Auto Scaling 정책을 설계할 때, 점진적 증가(확장성)와 급격한 스파이크(탄력성)는 완전히 다른 전략을 요구합니다. 이 둘을 혼용하면 비용 낭비나 서비스 장애로 이어질 수 있습니다.

출처

소프트웨어 아키텍처 The Basics, Ch05 아키텍처 특성의 식별

Dev Wiki

탐색기