어떤 책인가
왜 "아키텍처"는 정의부터 어려운가
1장은 다소 도발적인 이야기로 시작한다 - 소프트웨어 아키텍처에는 업계가 합의한 정의가 없다. 기술은 너무 빨리 변하고, "아키텍처"라는 말이 가리키는 범위도 사람마다 다르기 때문이다.
그래서 저자들은 정의를 내리는 대신, 아키텍처를 네 가지 차원(dimension) 의 조합으로 본다.
| 차원 | 의미 |
|---|---|
| 아키텍처 특성 (characteristics) | 시스템이 갖춰야 할 "-성(-ility)" - 확장성, 가용성, 성능, 보안 등 |
| 아키텍처 결정 (decisions) | 시스템 구축의 규칙·제약. 팀이 따라야 할 장기적 방향 |
| 논리 컴포넌트 (logical components) | 시스템이 하는 일의 구성 블록(예: 주문 처리, 결제) |
| 아키텍처 스타일 (architectural style) | 전체 구조의 형태 - 계층형, 마이크로서비스, 마이크로커널 등 |
핵심은 아키텍처가 다이어그램 한 장이 아니라, 위 네 가지가 서로 얽힌 결정의 총합이라는 것이다. 특히 "아키텍처 특성"은 기능 요구사항이 아니라 시스템이 어떻게 잘 동작해야 하는가를 규정한다.
아키텍트에게 기대되는 8가지
1장에서 가장 실용적인 부분. 아키텍트의 역할을 8가지 기대(expectations) 로 정리한다.
- 아키텍처 결정을 내린다 - 구체적 기술을 "지정"하는 게 아니라, 팀이 따를 가이드(방향·경계) 를 제시한다.
- 아키텍처를 지속적으로 분석한다 - 한 번 그리고 끝이 아니라, 구조가 여전히 유효한지 계속 점검한다.
- 최신 트렌드를 놓치지 않는다 - 기술 흐름을 따라가며 판단의 재료를 갱신한다.
- 결정의 준수(compliance)를 보장한다 - 정한 규칙이 실제 구현에서 지켜지는지 확인한다.
- 다양한 경험에 노출된다 - 깊이(depth)보다 폭(breadth). 여러 기술을 얕더라도 넓게 안다.
- 비즈니스 도메인 지식을 갖춘다 - 기술만으로는 부족하고, 사업 맥락을 이해해야 한다.
- 대인 관계 능력 - 팀을 이끌고 조율하는 소프트 스킬.
- 조직 정치를 이해하고 헤쳐 나간다 - 결정이 승인받으려면 협상과 정치적 감각이 필요하다.
개인적으로 5번(깊이보다 폭)이 가장 인상적이었다. 개발자는 한 분야를 깊게 파지만, 아키텍트는 선택지를 넓게 알고 트레이드오프를 비교하는 사람에 가깝다. 6·7·8번이 기술이 아니라 사람·사업·조직에 대한 것이라는 점도, 아키텍트가 순수 기술직이 아님을 분명히 한다.
아키텍처는 어디와 교차하는가
1장은 아키텍처가 홀로 존재하지 않고 여러 영역과 교차(intersection) 한다고 말한다.
- 엔지니어링 프랙티스 - 설계가 구현까지 살아남게 하는, 프로세스와 무관한 실천들(예: 지속적 통합)
- 운영/DevOps - 운영 관심사를 설계에 통합
- 프로세스 - 개발 방법론이 아키텍처에 영향(애자일은 반복적 재구성을 가능케 함)
- 데이터 - 복잡한 시스템일수록 데이터 저장·DB 아키텍처가 핵심
즉 현대의 아키텍트는 "그림 그리는 사람"이 아니라, 엔지니어링·운영·데이터를 아우르는 엔지니어링 실천가에 가깝다는 것이 2판이 강조하는 지점이다.
소프트웨어 아키텍처의 법칙
책 전체를 관통하는 두 가지(그리고 따름정리) 법칙이 1장에 등장한다.
"소프트웨어 아키텍처의 모든 것은 트레이드오프다."
정답인 선택은 없고, 무언가를 얻으면 무언가를 잃는다. 따름정리: 트레이드오프가 안 보인다면 아직 못 찾은 것이다. 그리고 어떤 결정도 한 번으로 끝나지 않는다.
"'어떻게(how)'보다 '왜(why)'가 더 중요하다."
구조를 아는 것보다, 그 구조를 왜 그렇게 정했는지가 훨씬 중요하다. 나중에 결정을 재검토할 때 근거(why)가 없으면 판단이 불가능하기 때문이다.
이 두 법칙은 이후 모든 장의 밑바탕이 된다. "정답 아키텍처"를 찾지 말고, 맥락에 맞는 트레이드오프를 고르고 그 이유를 남겨라 - 1장이 던지는 핵심 메시지다.
실습 1 - 내 프로젝트의 트레이드오프 적어보기
제1법칙을 내 상황에 적용해 보자. 최근 내린 기술 결정 하나를 골라, 얻은 것과 잃은 것을 한 줄씩 적어본다.
"상태 관리를 전역 스토어로 통일했다" → 얻음: 예측 가능한 데이터 흐름, 디버깅 용이. 잃음: 보일러플레이트 증가, 작은 컴포넌트엔 과함. 이렇게 적어보면 "무조건 좋은 선택"이 아니라 맥락 의존적 트레이드오프였음이 드러난다. 트레이드오프가 안 떠오른다면, 아직 대안을 충분히 안 본 것이다(따름정리).
실습 2 - "왜"를 기록으로 남기기
제2법칙을 실천하는 가장 쉬운 방법은 결정의 이유를 문서로 남기는 것이다. 실무에서는 이를 ADR(Architecture Decision Record)이라 부른다.
# ADR-001: 상태 관리 라이브러리 선택
## 맥락 (Context)
여러 화면이 공유하는 서버 상태가 늘어나 prop drilling이 심해짐.
## 결정 (Decision)
서버 상태는 TanStack Query, 클라이언트 전역 상태는 Zustand 사용.
## 이유 (Why) ← 제2법칙의 핵심
- 서버/클라이언트 상태를 분리해 캐싱·동기화를 라이브러리에 위임
- Redux 대비 보일러플레이트가 적어 팀 온보딩 비용 낮음
## 트레이드오프 (Consequences) ← 제1법칙
얻음: 캐싱 자동화, 코드 감소 / 잃음: 라이브러리 2개 학습 부담지금 진행 중인 프로젝트의 핵심 결정 하나를 골라 위 형식으로 ADR을 써 보자. 몇 달 뒤 "이걸 왜 이렇게 했지?"라는 질문에 답할 수 있게 하는 것 - 그게 제2법칙("why가 더 중요하다")의 실천이다.