부록

A. 용어집

각 용어 뒤의 괄호는 본문에서 처음 제대로 다뤄지는 장이다.

• 아키텍처(architecture) — 시스템에 대한 되돌리기 비싼 결정들과 그 근거. 구조는 그 흔적이다. (Step 01)
• 침식(erosion) / 표류(drift) — 구현이 아키텍처의 의도를 위반하며 무너지는 것 / 위반은 아니나 의도가 흐려지는 것. (Step 01, 12)
• 본질적/우연적 어려움(essence/accident) — 소프트웨어가 무엇인가에서 오는 제거 불가능한 어려움 / 오늘의 도구에서 오는 제거 가능한 어려움. (Step 02)
• 관심사의 분리(separation of concerns) — 한 번에 하나의 관심사만 다룰 수 있게 나누는 원리. (Step 02)
• 정보 은닉(information hiding) — 바뀔 법한 설계 결정을 모듈 뒤에 숨기는 분해 기준. 캡슐화(언어 기능)와 구별. (Step 02)
• 결합도(coupling) / 응집도(cohesion) — 모듈 사이 의존 강도 / 모듈 안 요소들의 관련 정도. 목표는 결합의 제거가 아니라 배치. (Step 02)
• 기술 부채(technical debt) — 현재의 이해로 먼저 출시하고 학습을 반영해 갚는 의도적 차입. 위험은 차입이 아니라 상환의 중단. (Step 02)
• 의존성(dependency) — A의 소스에 B의 이름이 등장하는 것. 변경의 파급은 화살표의 역방향으로 흐른다. (Step 03)
• DIP(의존성 역전 원칙) — 상위·하위 모두 추상에 의존하게 하라. 핵심은 추상의 소유권이 사용자에게 있다는 것. (Step 03)
• SDP/SAP/ADP — 안정된 쪽으로 의존하라 / 안정된 것은 추상적이어야 한다 / 의존성 그래프에 순환 금지. (Step 03)
• 경계(boundary) — 의존성 화살표가 한 방향으로만 건너는 선. (Step 03)
• 품질 속성(quality attribute) — 변경용이성·테스트가능성·가용성 등, 구조가 허락하거나 금지하는 “좋음”의 이름들. 아키텍처를 결정하는 실제 변수. (Step 04)
• 품질 속성 시나리오 — 자극원·자극·환경·대상·응답·측정치의 여섯 조각으로 쓴 검증 가능한 요구. (Step 04)
• 전술(tactics) — 품질 속성 하나의 응답을 담당하는 명명된 설계 수단(이중화, 중개자 삽입 등). (Step 04)
• 전단층(shearing layers) — 변경 속도가 다른 것들을 서로 묶지 말라는 원리. 건축(Brand/Duffy)에서 수입. (Step 05)
• 빈혈 도메인 모델(anemic domain model) — 데이터만 있고 규칙이 없는 도메인 객체. 복잡한 도메인에서만 병이다. (Step 06)
• 싱크홀(architecture sinkhole) — 아무 일도 하지 않고 통과만 시키는 층. (Step 06)
• 유비쿼터스 언어(ubiquitous language) — 도메인 전문가와 개발자가 합의한 하나의 언어가 코드 이름까지 지배하는 규율. (Step 07)
• 바운디드 컨텍스트(bounded context) — 하나의 모델과 언어가 유효한 명시적 경계. (Step 07)
• 애그리거트(aggregate) — 함께 변경되어야 하는 객체 묶음. 불변식의 경계 = 트랜잭션의 경계. (Step 07)
• ACL(안티커럽션 레이어) — 바깥 모델이 내 경계 안으로 새어 들지 못하게 하는 번역 계층. (Step 07)
• 포트/어댑터(port/adapter) — 애플리케이션이 소유한 의도의 계약 / 그 계약과 특정 기술 사이의 번역기. 주도(driving)와 피주도(driven)로 나뉜다. (Step 08)
• 의존성 규칙(dependency rule) — 소스 코드 의존성은 오직 안쪽(정책)을 향해야 한다. (Step 08)
• Conway의 법칙 — 시스템 설계는 조직의 커뮤니케이션 구조를 복제한다. 역으로 이용하는 것이 역 Conway 전략. (Step 09)
• 부분 실패(partial failure) — 분산 호출의 세 번째 상태. 타임아웃은 “실패”가 아니라 “모른다”다. (Step 10)
• CAP — 네트워크 분할이 일어난 동안 일관성과 가용성은 양립 불가하다는 증명된 정리. “셋 중 둘”이 아니다. (Step 10)
• 결과적 일관성(eventual consistency) — 수렴은 보증하되 시점은 약속하지 않는 일관성. (Step 10)
• Saga — 경계를 넘는 업무를 로컬 트랜잭션의 연쇄 + 보상 트랜잭션으로 바꾸는 패턴 (1987년생). (Step 10)
• CQRS / CQS — 쓰기 모델과 읽기 모델의 분리 / 그 뿌리인 메서드 수준 명령-조회 분리(Meyer). 이벤트 소싱과는 독립. (Step 10)
• 모듈러 모놀리스(modular monolith) — 경계의 논리적 이득(모듈성)은 취하고 물리적 비용(분산)은 지불하지 않는 단일 배포 구조. (Step 10)
• 공유 데이터베이스(integration database) — 공통 결합의 왕. 스키마가 암묵적 공용 API로 굳는다. (Step 11)
• 트랜잭셔널 아웃박스(transactional outbox) — 이벤트를 업무 데이터와 같은 DB 트랜잭션으로 커밋하고 릴레이/CDC로 발행해 이중 쓰기를 피하는 패턴. (Step 11)
• 멱등성(idempotency) — 같은 요청이 두 번 처리돼도 효과는 한 번인 성질. “최소 한 번 + 멱등 = 정확히 한 번 효과”. (Step 11)
• 폴리글랏 퍼시스턴스(polyglot persistence) — 저장소를 도메인마다 다르게 고르는 것. 실비용은 저장소가 아니라 동기화 경로다. (Step 11)
• 이벤트 소싱(event sourcing) — 상태 대신 사건의 추가 전용 로그를 저장하고 상태는 재생으로 얻는 저장 전략. 원장·역분개의 소프트웨어 판. (Step 11)
• 대사(reconciliation) — 두 기록을 맞춰보고 차이를 계정으로 관리하는 절차. 결과적 일관성의 오래된 실무. (Step 11)
• 적합도 함수(fitness function) — 아키텍처 특성의 무결성을 객관적으로(자동으로) 평가하는 장치. 품질 속성 시나리오의 실행판. (Step 12)
• 최종 책임 시점(last responsible moment) — 결정을 “더 미루면 선택지가 사라지는 마지막 순간”까지 미루는 원리(Poppendieck). (Step 12)
• 분산 컴퓨팅의 8가지 오류(8 fallacies) — 네트워크는 신뢰할 수 있다·지연은 0이다 등, 분산 시스템이 반복해 위반하는 여덟 개의 거짓 전제(Deutsch·Gosling). (Step 10)
• 추상화 브랜치(branch by abstraction) — 긴 Git 브랜치 대신 코드 안 추상 뒤에서 신·구 구현을 공존시키다 교체하는 이행 전술. DIP의 이행 버전. (Step 14)
• 스트랭글러 무화과(strangler fig) — 가로채고, 기능 단위로 이관하고, 숙주를 제거하는 점진 이행 전략. (Step 14)
• 봉합선(seam) — 그 자리를 편집하지 않고 동작을 바꿀 수 있는 지점. 레거시 수술의 절개선. (Step 14)
• 특성화 테스트(characterization test) — 옳은 동작이 아니라 현재 동작을 박제하는 테스트. (Step 14)
• ADR(아키텍처 결정 기록) — Context/Decision/Consequences로 결정과 근거를 남기는 불변 문서. (Step 15)

B. 아키텍처 문서화 최소 가이드

이 책은 문서화 방법론의 책이 아니므로(그건 다른 책 한 권이다), 실무에 바로 쓸 두 가지만 소개한다.

C4 모델 (Simon Brown). 지도를 그릴 때 축척을 정하듯, 다이어그램을 네 단계의 줌 레벨로 나눈다: Context(시스템과 바깥 세계 — 사용자, 이웃 시스템), Container(배포·실행 단위 — 앱, DB, 큐), Component(컨테이너 안의 주요 부품), Code(클래스 — 대개 생략한다, IDE가 더 잘 그린다). C4의 실용적 교훈은 하나다: 한 장에 여러 축척을 섞지 마라. 회의실 화이트보드의 그림이 매번 싸움이 되는 이유는 대개 누군가는 Context를, 누군가는 Component를 그리고 있어서다.

4+1 뷰 (Kruchten, 1995). 하나의 아키텍처를 네 관점 — 논리(기능 구조), 프로세스(동시성·통신), 개발(코드 조직), 물리(배포) — 으로 나눠 그리고, 시나리오(+1)로 묶는 고전적 틀. 오늘날 C4에 비해 무겁게 느껴지지만, “하나의 그림으로 모든 것을 말하려 하지 마라”는 통찰의 원전으로 기억할 가치가 있다.

문서화의 우선순위는 이 책의 논지대로다: 낡지 않는 것부터. 적합도 함수(낡으면 깨진다) > ADR(불변이므로 낡지 않는다) > 다이어그램(그린 날부터 낡는다). 단, 이 서열은 오직 낡음 저항 기준이다 — 셋은 각각 강제·근거 기록·소통이라는 다른 목적을 맡으므로 서로 대체재가 아니다. 다이어그램은 필요하되, 진실의 원천이 아니라 안내판으로 취급하라.

C. 원전 연표

시대착오 방지 장치. 본문이 인용한 문헌을 시간순으로 — 이 분야는 연도가 틀린 채 유통되는 이야기가 유난히 많다.

D. 참고문헌 (더 읽기)

이 책 다음에 읽을 순서로.

1. Ford & Richards, Fundamentals of Software Architecture (2020) — 이 책의 Part 1을 실무 폭으로 확장한 현대적 개론.
2. Evans, Domain-Driven Design (2003) + Vernon, Implementing DDD (2013) — Step 07을 책 두 권 분량으로. Vernon부터 읽고 Evans로 가는 역순도 좋다.
3. Martin, Clean Architecture (2017) — Step 03·08의 원전. 주장을 다 받아들이기보다 이 책의 렌즈로 비판적으로.
4. Newman, Building Microservices (2판 2021) & Monolith to Microservices (2019) — Step 10·14의 실무 확장.
5. Kleppmann, Designing Data-Intensive Applications (2017) — Step 10·11의 물리학을 제대로 배우는 곳. 이 책이 다루지 않은 깊이의 분산·데이터.
6. Feathers, Working Effectively with Legacy Code (2004) — Step 14의 원전. 브라운필드에서 일한다면 필독.
7. Ford, Parsons & Kua, Building Evolutionary Architectures (2판 2022) — Step 12의 원전.
8. Bass, Clements & Kazman, Software Architecture in Practice (4판 2021) — 품질 속성·전술의 교과서. 사전처럼 곁에.
9. Skelton & Pais, Team Topologies (2019) — Step 09를 조직 설계 실무로.
10. Brooks, The Mythical Man-Month (기념판 1995) — 반세기 전 책이 아직 아픈 이유를 확인하는 것 자체가 공부다.