3.0 3부 소개: 시스템
아키텍처는 되돌리는 데 비용이 많이 드는 결정의 집합입니다. 시스템을 어떻게 부분으로 나눌 것인가? 그 부분들은 서로 어떻게 대화하는가? 데이터는 어떻게 모델링되는가? 그리고 전체가 부하와 장애 아래서 어떻게 동작하는가? 3부는 이런 판단을 의도적으로 내리는 것에 관한 내용입니다. 작은 팀에서 아키텍처는 몇 사람의 머릿속에 살면서 해 나가는 동안 진화할 수 있습니다. 대규모 조직(수백 명의 엔지니어, 수십 개의 팀, 만드는 사람들의 경력보다 오래 살 시스템)에서는 아키텍처가 모두를 조율하는 것이 됩니다. 아키텍처가 분명하면 팀들이 부딪히지 않고 독립적으로 움직입니다. 모호하면 모든 팀 간 의존성이 협상이 되고 모든 인시던트가 고고학 프로젝트가 됩니다.
이해관계는 기업과 정부에서 가장 높습니다. 세금 엔진, 급여 플랫폼, 국가 건강 기록, 은행의 핵심 원장은 오래 살고, 규제가 심하며, 부서 간에 공유되고, 대중에게 책임을 집니다. 결합도, 데이터 소유권, 품질 속성에 대해 오늘 내리는 결정은 10년 이상 무엇이 가능한지를 제약합니다. 규제 기관과 감사자는 점점 더 문서화되고 방어 가능한 아키텍처를 기대하며, 신뢰성, 보안, 프라이버시, 내구성이 나중에 덧붙인 것이 아니라 설계에 들어 있었다는 실제 증거를 요구합니다. 헤드라인이 되는 실패는 아키텍처의 실패입니다. 출시일에 무너지는 포털, 마감일에 시간 초과되는 신고 시스템, 레코드를 잃거나 이중으로 세는 이전입니다.
이 부는 오래가는 기본기에서 시작해 구체적인 구조적 선택을 거쳐 분산, 데이터, 규모의 현실로 들어가고, 대부분의 대규모 조직이 실제로 마주하는 가장 어려운 문제인 이미 운영 중인 시스템의 현대화로 마무리합니다. 이를 하나로 묶는 가닥은 좋은 아키텍처가 유행하는 기본값이 아니라 의식적인 트레이드오프의 연속이라는 것입니다.
이 부의 장
3.1 아키텍처의 기본. 기술 유행을 넘어 살아남는 오래가는 도구들. 품질 속성(“-ilities”), 아키텍처상 중요한 요구 사항, 피트니스 함수(선택한 아키텍처 품질을 지키는 자동화된 테스트)와 진화적 아키텍처, C4 모델(네 가지 확대 수준의 중첩된 아키텍처 다이어그램)과 arc42(아키텍처 문서화 템플릿)를 이용한 가벼운 문서화, 구조화된 트레이드오프 분석.
3.2 아키텍처 스타일과 패턴. 모놀리스에서 마이크로서비스, CQRS(Command Query Responsibility Segregation, 읽기 모델과 쓰기 모델을 분리)와 이벤트 소싱(상태를 추가 전용 이벤트 로그로 저장)을 갖춘 이벤트 기반 아키텍처, 서비스 메시(서비스 간 통신을 위한 전용 인프라 계층)와 게이트웨이, 서버리스, 헥사고날 및 클린 아키텍처까지 주요 시스템 형태의 개관과 각각이 맞는 때에 대한 지침. 콘웨이의 법칙(시스템은 그것을 만드는 조직의 의사소통 구조를 닮는 경향이 있음)으로 틀을 잡습니다.
3.3 분산 시스템. 네트워크 경계를 넘는 순간 나타나는 어려운 진실(신뢰할 수 없는 네트워크, 부분 실패, 공유 시계 없음)과 표준적인 방어. 일관성 추론, 멱등성(연산을 반복해도 안전하게 만들기), 백오프가 있는 재시도, 서킷 브레이커(실패하는 의존성 호출을 멈춤), 사가(보상 취소 단계를 가진 로컬 트랜잭션의 연속), 분산 관측 가능성.
3.4 데이터 아키텍처와 저장소. 규모에서 데이터가 어떻게 모델링되고, 저장되고, 일관되게 유지되고, 빠르게 제공되는가. 주요 저장 패러다임과 각각을 쓸 때, 폴리글랏 영속성(한 시스템에서 여러 전문 데이터 저장소 사용), 스키마 진화와 이전, 캐싱과 CDN(콘텐츠 전송 네트워크), 부하 아래의 트랜잭션과 동시성.
3.5 확장성, 성능, 복원력. 나중에 덧붙이지 않고 설계에 넣는 세 가지 구별되는 품질. 수평 및 수직 확장, 무상태성과 샤딩(키로 데이터를 기계에 나눔), 로드 밸런싱과 오토스케일링, 성능 예산, 복원력 패턴과 카오스 엔지니어링, RTO(복구 시간 목표)와 RPO(복구 시점 목표)로 틀을 잡은 다중 리전 재해 복구.
3.6 레거시 현대화. 실제로 통하는 점진적 패턴. 교살자 무화과(옛 시스템이 폐기될 수 있을 때까지 그 둘레에 새 시스템을 키움)와 추상화에 의한 분기(개발 주 라인에서 인터페이스 뒤의 구성 요소를 교체), 그리고 레거시 위험 평가, 메인프레임과 COBOL(Common Business-Oriented Language) 관리, 데이터 이전과 이중 운영, 이 분야에서 가장 비싼 실패를 낳는 대규모 재작성의 유혹에 저항하는 방법.
3.7 소프트웨어 유지보수. 소프트웨어 수명의 지배적 단계. 교정, 적응, 완전, 예방 유지보수, 프로그램 이해와 재공학, 오래 사는 시스템이 변경에 감당할 만하게 유지되도록 하는 유지보수성을 위한 설계.
3.8 상호운용성과 오픈 표준. 맞춤형 통합이 아니라 오픈 표준을 통해 상호운용하도록 시스템을 설계하기. 기술적, 구문적, 의미적 상호운용성, 의료의 FHIR 같은 도메인 표준, 독점적 종속의 비용.
3.9 시스템 엔지니어링. 흔히 소프트웨어, 하드웨어, 사람, 프로세스를 결합하는 복잡한 시스템을 처음부터 끝까지 엔지니어링하기. 수명 주기, 요구 사항 할당과 추적성, 인터페이스, 통합, 검증과 확인.
3.10 임베디드와 실시간 시스템. 빡빡한 제약 아래 장치를 위한 소프트웨어. 실시간 동작과 결정성, RTOS나 베어메탈 펌웨어, 제한된 메모리와 전력, 하드웨어 상호작용, 안전이 핵심인 표준.
3.11 클라우드 아키텍처. 데이터 센터를 그대로 옮기는 대신 클라우드를 위해 설계하기. 서비스 모델과 서버리스, 장애 도메인으로서의 리전과 가용 영역, 공동 책임 모델, 관리형 서비스와 종속의 트레이드오프, 복잡성만큼 값을 할 때의 멀티 클라우드와 하이브리드, 비용을 의식하는 잘 설계된 아키텍처.
3.12 이벤트 기반 아키텍처와 메시징. 이벤트를 생산하고 그에 반응하여 소통하는 시스템 만들기. 큐 대 내구성 있는 스트림, 코레오그래피 대 오케스트레이션, 값을 하는 곳의 이벤트 소싱과 CQRS, 분산 트랜잭션을 위한 사가, 전달 보장과 멱등성, 비동기 흐름을 신뢰할 수 있게 유지하는 패턴.
3.13 네트워킹과 연결성. 애플리케이션 엔지니어가 실제로 다루는 네트워킹. DNS, TCP와 HTTP의 진화, TLS 종단, 로드 밸런싱과 리버스 프록시, 콘텐츠 전송과 엣지, 서비스 디스커버리와 서비스 메시, 네트워크의 신뢰할 수 없음을 견딜 수 있게 하는 타임아웃, 재시도, 서킷 브레이커.
3.14 멀티테넌시와 SaaS 아키텍처. 서로를 보거나 굶기지 않게 하면서 하나의 소프트웨어 인스턴스로 많은 고객을 제공하기. 격리 대 효율성의 스펙트럼, 데이터 파티셔닝, 시끄러운 이웃에 대한 테넌트별 할당량, 테넌트 수명 주기, 비용 귀속.
3.15 캐싱과 콘텐츠 전송. 약간의 오래됨을 지연, 부하, 비용의 큰 이득과 맞바꾸기. 캐시 계층(클라이언트, 엣지와 CDN, 리버스 프록시, 애플리케이션, 데이터 저장소)에 걸치며, 캐시 무효화와 스탬피드 방지를 일급 설계로 다룹니다.
3.16 API 게이트웨이와 서비스 메시. API 게이트웨이에서의 남북 트래픽(라우팅, 인증, 속도 제한, 조합)과 서비스 메시를 통한 동서 트래픽(상호 TLS, 트래픽 이동, 재시도, 관측 가능성)을 다루고, 메시가 복잡성만큼 값을 하는 때를 판단하기.
3.17 검색과 정보 검색. 검색을 일급 시스템으로 다루기. 역색인과 관련도 순위에서 질의 이해, 패싯, 벡터 및 하이브리드 검색까지, 추측이 아니라 실제 관련도 평가와 함께.
이 장들이 서로 맞물리는 방식
장들은 순서대로 서로 위에 쌓입니다. 3.1장은 이후 모든 장이 쓰는 어휘(품질 속성과 트레이드오프 분석)를 주며, 거기서 이름 붙인 “-ilities”가 바로 3.4장과 3.5장이 구체화하는 것입니다. 3.2장은 그 기본기를 구조적 선택으로 바꾸고, 그것이 권하는 더 분산된 스타일(마이크로서비스, 이벤트 기반, 서비스 메시)은 3.3장이 관리하는 법을 가르치는 비용을 가져옵니다. 3.3, 3.4, 3.5장은 서로에게 크게 기댑니다. 분산은 데이터 아키텍처의 일관성과 내구성 결정을 강제하고, 분산과 데이터가 함께 실제로 도달할 수 있는 확장성과 복원력을 형성합니다. 3.6장은 고리를 닫습니다. 대부분의 대규모 조직은 백지 위에 짓지 않기 때문입니다. 앞선 장들이 설명하는 모든 선택을 제약하는 기록 시스템을 진화시키고 있습니다.
3부는 바깥으로도 닿습니다. 3.2장은 좋은 서비스 경계를 찾기 위해 2.2장의 설계 원칙과 도메인 주도 설계에 기댑니다. 이런 시스템을 계속 돌리는 운영 규율은 9부에 있습니다. 사이트 신뢰성 엔지니어링(9.1장)과 관측 가능성(9.2장)이 아키텍처의 복원력이 프로덕션에서 입증되는 곳입니다. 규제 기관이 요구하는 보안과 프라이버시 속성은 여기서 설계되지만 4부에서 상세히 다루며, 8부의 플랫폼과 전달 실천이 아키텍처를 많은 팀이 동시에 실제로 출시하고 운영할 수 있는지를 결정합니다.