L9 아키텍처 & 설계 입구

L9 아키텍처 & 설계 입구

분류: Layer 9 - 아키텍처 & 설계

핵심 질문

요구사항이 바뀌고 프로세스와 서비스가 실패해도, 어디까지 함께 바뀌어야 하고 어떤 약속은 끝까지 지켜야 하는가?

3줄 요약

• L9는 패턴 이름을 외우는 레이어가 아니라 변경 비용, 배포 경계, 분산 실패, 데이터 불변식, 검증 방법을 하나의 설계 판단으로 연결하는 레이어다.
• 첫 회독은 설계 원칙 → Clean Architecture → 도메인 주도 설계(Domain-Driven Design, DDD: 업무 언어와 모델 경계를 맞추는 접근) → Twelve-Factor → 분산 시스템 → 마이크로서비스 아키텍처(Microservices Architecture, MSA: 서비스를 독립 배포 경계로 나누는 구조) → Saga → 명령·조회 책임 분리(Command Query Responsibility Segregation, CQRS: 쓰기와 읽기 모델의 책임을 나누는 패턴) → Testing → API Contract를 중심 줄기로 읽는다.
• 그다음 System Design Cases와 Web Crawler 중 목표에 맞는 케이스로 분기한다. 상세 구현, 운영 명령, 모든 수치 예시는 선택 심화로 미뤄도 된다.

1. 정의 — 아키텍처와 설계는 무엇을 정하는가

소프트웨어 설계(software design) 는 요구사항과 제약 안에서 책임, 데이터, 상호작용을 어떤 구조로 배치할지 결정하는 일이다. 소프트웨어 아키텍처(software architecture) 는 그중에서도 나중에 바꾸기 어렵고 여러 팀·배포·데이터 경계에 오래 영향을 주는 결정을 다룬다. 둘의 경계가 항상 선명한 것은 아니지만, 공통 질문은 같다.

무엇을 반드시 지켜야 하는가
  → 어디를 경계로 나눌 것인가
  → 경계 사이에 어떤 계약을 둘 것인가
  → 실패와 변경이 어디까지 번질 수 있는가
  → 그 판단이 맞는지 무엇으로 검증할 것인가

여기서 경계(boundary) 는 책임이나 변경이 함께 움직이는 범위를 나누는 선이고, 계약(contract) 은 경계 밖에서 관찰할 수 있는 입력·출력·오류·상태 변화의 약속이다. 불변식(invariant) 은 작업 도중이 아니라 완료된 상태에서 반드시 참이어야 하는 업무 규칙이다. 예를 들어 “결제된 주문의 합계는 승인 금액과 일치한다”는 불변식이고, 이를 어느 프로세스와 데이터 경계에서 지킬지는 설계 결정이다.

L9의 목표는 특정 구조를 정답으로 고르는 것이 아니다. 작은 CRUD에는 단순한 구조를 유지하고, 변경·배포·장애·정합성 비용이 실제로 커질 때만 더 강한 경계와 패턴을 선택할 수 있어야 한다.

2. 등장한 문제 — 좋은 코드만으로 시스템 전체를 설명할 수 없다

앞 레이어에서 서버 코드, API, 네트워크, 인프라, 배포, 비동기 처리, 데이터베이스를 각각 배웠다. 이 지식으로 개별 구성 요소는 설명할 수 있지만, 시스템이 커지면 구성 요소 사이의 결정이 서로 충돌한다.

• 비즈니스 규칙을 고치려는데 Controller, ORM, 외부 API 코드가 함께 바뀐다.
• 같은 코드를 배포했는데 환경별 설정과 프로세스 수명 주기가 달라 결과가 달라진다.
• 서비스를 나누자 로컬 트랜잭션 하나로 지키던 불변식이 네트워크와 여러 DB에 걸친다.
• timeout 뒤 성공 여부를 모르는데 재시도하면 중복 처리될 수 있다.
• 읽기 요구와 쓰기 불변식이 충돌하지만 하나의 모델이 둘을 모두 감당한다.
• 테스트는 많지만 실제 DB 의미, 서비스 간 계약, 배포 중 버전 공존, 부분 실패를 검증하지 못한다.
• 시스템 디자인 답안에는 큐와 캐시가 많지만 어떤 요구와 병목 때문에 필요한지 설명하기 어렵다.

이 문제들은 클래스 하나의 품질만으로 풀리지 않는다. 코드 의존성, 도메인 언어, 배포 가능한 프로세스, 네트워크 실패, 데이터 소유권, 외부 계약, 테스트 경계를 함께 봐야 한다.

선행 관점의 한계와 L9의 등장

L0~L8은 런타임부터 데이터베이스까지 시스템을 구성하는 재료와 동작 원리를 제공한다. 그러나 재료를 안다는 사실이 “무엇을 함께 두고 무엇을 분리할지”를 자동으로 정해 주지는 않는다. L9는 이 간극을 변경 이유, 불변식, 경계, 계약, 실패 모델, 검증 증거라는 공통 언어로 메운다. 그 결과 패턴을 먼저 고르는 대신 문제의 크기와 비용에 맞는 가장 단순한 구조를 선택할 수 있다.

3. 핵심 철학 — 패턴보다 힘과 비용을 먼저 본다

L9 문서를 관통하는 철학은 다섯 가지다.

1. 변경 이유가 경계를 드러낸다. 함께 자주 바뀌는 책임은 높은 응집도(cohesion)를 가질 수 있고, 서로의 세부사항을 많이 알아야 하는 책임은 결합도(coupling)가 높다. 응집도는 같은 목적의 코드가 모인 정도이고, 결합도는 한 요소의 변경이 다른 요소에 미치는 의존 정도다.
2. 정책과 메커니즘을 구분한다. 정책(policy)은 주문 확정 조건처럼 업무가 지켜야 할 규칙이고, 메커니즘(mechanism)은 PostgreSQL, 메시지 브로커, HTTP처럼 그 규칙을 실행하는 수단이다. 중요한 정책이 특정 수단의 세부사항에 끌려가지 않게 한다.
3. 분리는 비용을 없애지 않고 이동시킨다. 프로세스나 서비스를 나누면 독립 배포와 장애 격리를 얻을 수 있지만, 네트워크 지연, 중복 메시지, 관측, 데이터 정합성 비용이 생긴다.
4. 실패는 예외가 아니라 입력이다. 분산 시스템에서는 timeout, 중복, 순서 역전, 부분 실패가 정상적으로 들어올 수 있다. 실패 모델(failure model) 은 어떤 실패를 가정하고 어떤 상태까지 허용할지 정한 설명이다.
5. 설계는 증거로 닫는다. 테스트, 계약 검증, 부하 모델, 지표, 실패 신호가 없는 다이어그램은 가설에 머문다. 설계 결정은 어떤 관측으로 유지하거나 되돌릴지까지 포함한다.

4. 사고 모델 — 여섯 질문으로 위치를 잃지 않기

4-1. 무엇이 바뀌었고 어디까지 함께 바뀌는가

기능 요청 하나가 몇 모듈, 몇 서비스, 몇 데이터 저장소, 몇 배포를 건드리는지 본다. 변경이 불필요하게 퍼진다면 경계가 없거나 잘못 놓였을 수 있다. 반대로 항상 함께 바뀌는 코드를 억지로 분리했다면 경계 사이 조정 비용만 늘어난다.

4-2. 반드시 지켜야 하는 불변식은 무엇인가

“데이터가 일관되어야 한다”보다 구체적으로 적는다. 재고가 음수가 되면 안 되는지, 결제 승인과 주문 확정이 같은 순간 보여야 하는지, 몇 초 늦게 수렴해도 되는지를 구분한다. 같은 트랜잭션이 필요한 규칙과 비동기 보상이 가능한 규칙은 여기서 갈린다.

4-3. 경계 밖에서 무엇을 약속하는가

함수 인터페이스, API 스키마, 이벤트, DB 소유권은 모두 계약이지만 검증 방식은 다르다. 계약은 필드 모양만이 아니라 오류 의미, 멱등성, 순서, 하위 호환성, 관찰 가능한 상태 전이를 포함한다.

4-4. 실패했을 때 무엇을 알고 무엇을 모르는가

timeout은 실패 확정이 아니라 결과를 모르는 상태일 수 있다. 한 서비스의 성공과 다른 서비스의 실패가 동시에 존재할 수 있다. 재시도, 보상, 대사, 재처리는 이 불확실성을 제한하는 수단이지 과거를 지우는 마법이 아니다.

4-5. 얻는 독립성이 새 비용보다 큰가

모듈, 프로세스, 서비스, 읽기/쓰기 모델을 나눌 때 독립 변경·배포·확장·장애 격리 중 무엇을 얻는지 적는다. 이어 네트워크 hop, 운영 고정비, 일관성 지연, 디버깅 비용을 적는다. 이득을 설명할 수 없다면 모듈러 모놀리스나 CRUD가 더 나은 기본값이다.

4-6. 어떤 증거가 이 설계를 반증할 수 있는가

테스트가 어느 경계를 검증하는지, 어떤 SLI(Service Level Indicator, 서비스 수준을 나타내는 측정값)를 볼지, 어느 임계에서 구조를 바꿀지 정한다. p99 지연, queue backlog seconds, 계약 호환성 실패, 보상 미완료 수처럼 설계 가정과 직접 연결되는 신호가 필요하다.

5. Canonical order — 저장소의 기준 순서

L9의 learning_order는 사이트와 팟캐스트가 사용하는 canonical order, 즉 저장소가 정한 기준 정렬이다. Design Principles에서 다루는 SOLID는 책임과 의존성 경계를 점검하는 다섯 객체지향 설계 원칙이고, ADR(Architecture Decision Record) 은 중요한 아키텍처 결정의 배경·선택·결과를 남기는 짧은 기록이다.

Order	문서	다음 문서에 주는 기반
10	Design Principles	결합도·응집도·SOLID·ADR로 변경 비용을 말하는 언어
20	Clean Architecture	정책을 외부 세부사항에서 보호하는 의존성 규칙
30	DDD Basics	업무 언어, Bounded Context, Aggregate와 불변식 경계
40	Twelve-Factor App	설정·릴리스·프로세스 수명 주기의 배포 가능성
50	Distributed Systems Basics	부분 실패, 일관성, 복제, 순서, 멱등성의 실패 모델
60	MSA Patterns	서비스 경계·통신·데이터 소유권·회복성의 비용
70	Saga Pattern	여러 로컬 트랜잭션을 보상 가능한 장기 흐름으로 조정
80	CQRS & Event Sourcing	읽기·쓰기 책임 분리와 이벤트를 정본으로 삼는 선택
90	Testing Strategy	위험별로 unit·integration·contract·E2E·분산 흐름 테스트 배치
100	Web Crawler System Design	frontier, politeness, 중복 제거, 재수집의 상태 기계
110	API Design & Contract	OpenAPI, 호환성, 멱등성, 오류·버전 계약
120	System Design Cases	요구→부하→병목→트레이드오프→검증의 6단계 적용

canonical order에서 Web Crawler가 API Contract보다 먼저인 것은 정렬 사실이다. 그러나 Crawler는 L9 API Contract를 선수로 요구하지 않고, System Design Cases는 API Contract를 선수로 요구한다. 따라서 학습 흐름은 하나의 직선이 아니라 분기 그래프로 읽어야 한다.

6. 추천 첫 회독 — 중심 줄기와 케이스 분기

추천 경로는 canonical order를 재정의하지 않는다. 다만 canonical대로 읽으면 Web Crawler(100)를 지난 뒤에야 API Contract(110)를 만나므로, 첫 회독에서는 기본 계약 관점을 놓치기 쉽다. 그래서 Crawler보다 API Contract를 먼저 읽고, 두 케이스 중 하나를 선택한다.

L9 추천 첫 회독

1. 1. Design Principles

   결합도·응집도, SOLID, ADR을 패턴 목록이 아니라 변경 비용과 결정 기록의 언어로 잡는다.

2. 2. Clean Architecture → DDD → Twelve-Factor

   코드 의존성, 도메인 경계, 배포·프로세스 경계를 서로 다른 축으로 분리한다. 셋을 하나의 만능 구조로 합치지 않는다.

3. 3. Distributed Systems → MSA

   로컬 트랜잭션 밖의 부분 실패와 일관성 비용을 먼저 배우고, 그 비용을 감당할 이유가 있을 때만 서비스 경계를 선택한다.

4. 4. Saga → CQRS / Event Sourcing → Testing

   장기 실행 흐름과 읽기·쓰기 모델 분리를 구분한 뒤, 앞에서 만든 경계와 실패 모델을 위험에 맞는 테스트로 검증한다. CQRS가 Saga를 필수로 요구하지는 않는다.

5. 5. API Contract → Cases 또는 Crawler

   Crawler보다 API Contract를 먼저 읽어 오류·멱등성·버전 호환성을 고정한다. 이후 범용 6단계 설계 연습은 Cases, 비동기 상태 기계 추적은 Crawler로 분기한다.

추천 경로에서 API Contract를 앞당기는 이유는 API가 모든 설계의 중심이어서가 아니다. 서비스와 클라이언트가 함께 배포되지 않는 상황에서 오류, 멱등성, 스키마 진화 같은 기본 약속을 모른 채 케이스 설계로 들어가는 일을 막기 위해서다. 반대로 Crawler를 직접 설계하는 것이 목표라면 해당 문서의 hard prerequisite만 충족한 뒤 일찍 분기해도 graph를 어기지 않는다.

7. Fallback — 막힐 때 돌아갈 곳

아래는 모든 hard prerequisite를 대체하는 목록이 아니다. 본문을 읽다가 특정 사고 축이 무너졌을 때 필요한 문서만 보정하고 돌아오는 경로다.

막히는 느낌	보통 부족한 전제	돌아갈 문서
의존성 역전, 추상화, DI가 같은 말처럼 느껴진다	IoC와 구현체 조립의 기본	content/topics/L0/di-ioc.mdx
API의 resource, method, status, idempotency가 흐릿하다	HTTP와 기본 API 의미	content/topics/L1/http-basics.mdx → content/topics/L1/api-design-basics.mdx
queue, event, retry가 서비스 분리와 함께 한꺼번에 어렵다	비동기 실행과 재전달의 기본	content/topics/L6/queue-worker-basics.mdx → content/topics/L6/retry-backoff-idempotency.mdx → content/topics/L6/eda-basics.mdx
로컬 transaction과 분산 transaction의 차이를 모르겠다	atomicity와 commit 경계	content/topics/L8/transaction-basics.mdx
Outbox가 왜 Saga의 발행 경계에 필요한지 모르겠다	DB 변경과 이벤트 발행의 이중 쓰기	content/topics/L8/cdc-outbox.mdx
System Design의 index·cache 선택 근거가 약하다	조회 경로와 Redis 운영 특성	content/topics/L8/db-index-query-optimization.mdx → content/topics/L8/redis-internals.mdx
배포 가능한 프로세스, 이미지, 종료가 낯설다	컨테이너와 배포의 기본 경계	content/topics/L5/docker-basics.mdx → content/topics/L5/cicd-basics.mdx
일관성 모델과 복제 지연이 추상적이다	로컬 transaction과 DB 복제의 차이	content/topics/L8/transaction-basics.mdx → content/topics/L8/db-replication-sharding.mdx

돌아갈 때 선수 문서를 전수 재독할 필요는 없다. 지금 막힌 용어의 정의, 해당 문서의 핵심 흐름, 마지막 요약을 확인한 뒤 L9의 원래 질문으로 복귀한다.

8. 첫 회독과 선택 심화의 경계

첫 회독의 완료 조건은 모든 패턴을 구현하는 것이 아니라 왜 등장했고 어느 경계에서 어떤 비용을 바꾸는지 설명하는 것이다.

문서 묶음	첫 회독에서 붙잡을 질문	선택 심화로 미룰 내용
Design Principles · Clean Architecture	변경이 퍼지는 이유와 의존성 방향을 설명할 수 있는가?	프레임워크별 전체 폴더 구조, import 규칙 자동화
DDD · Twelve-Factor	도메인 경계와 배포·프로세스 경계를 구분할 수 있는가?	Aggregate 세부 모델링, 플랫폼별 설정·종료 명령
Distributed Systems · MSA	부분 실패와 데이터 소유권 비용이 독립 배포 이득보다 작은가?	quorum·clock의 세부 구현, service mesh·플랫폼 운영
Saga · CQRS/Event Sourcing	보상 가능한 흐름과 읽기·쓰기 모델 분리가 각각 필요한가?	orchestrator 구현, event store replay·snapshot 최적화
Testing Strategy	실패 위험을 가장 싼 충분한 테스트 경계에 배치했는가?	모든 도구 실행, mutation·chaos suite 운영 자동화
API Contract	요청·응답·오류·멱등성·호환성을 관찰 가능한 약속으로 말할 수 있는가?	OpenAPI 전체 문법, broker·CI 도구 설정
System Design Cases	요구와 부하가 어떤 병목과 저장·캐시 선택을 만들었는가?	모든 케이스 구현, 공급자별 용량·비용 계산
Web Crawler	URL 하나가 발견에서 재수집까지 어떤 상태와 불변식을 거치는가?	대규모 브라우저 렌더링, Bloom filter 튜닝, 전체 실습

첫 회독에서 꼭 지킬 경계

• Clean Architecture와 DDD는 같은 말이 아니다. 전자는 의존성 방향으로 정책을 보호하고, 후자는 업무 언어와 모델의 유효 범위를 정한다.
• DDD의 Bounded Context와 마이크로서비스는 같은 말이 아니다. Bounded Context는 모델·언어 경계이고, 마이크로서비스는 네트워크·배포·데이터 소유권을 동반한 실행 경계다.
• Twelve-Factor는 분산 일관성을 해결하지 않는다. 교체 가능한 프로세스와 재현 가능한 릴리스를 만들지만 서비스 간 transaction을 제공하지 않는다.
• Saga의 보상은 DB rollback이 아니다. 이미 일어난 업무 효과를 취소·상쇄하는 새 업무 동작이다.
• CQRS와 Event Sourcing은 한 묶음으로 강제되지 않는다. 읽기·쓰기 모델만 분리할 수 있고, 이벤트를 상태의 정본으로 저장하지 않을 수도 있다.
• Contract Test와 API Contract 문서는 범위가 다르다. Testing은 독립 배포 경계를 어떤 테스트에 배치할지 다루고, API Contract는 무엇을 약속하고 어떻게 진화시킬지 다룬다.
• System Design Cases와 Web Crawler는 난이도 순서가 아니라 적용 분기다. 전자는 범용 6단계 프레임, 후자는 하나의 복합 상태 기계를 깊게 추적한다.

9. 준비 상태

L9 readiness check

• 요구사항 변경이 코드, 프로세스, 서비스, 데이터 중 어디까지 퍼지는지 대략 그릴 수 있다.
• 경계, 계약, 불변식을 각각 한 문장으로 구분할 수 있다.
• 로컬 DB transaction이 여러 서비스와 여러 DB를 자동으로 원자적으로 묶지 못한다는 점을 안다.
• timeout이 곧 실패 확정은 아니며 retry에는 멱등성 판단이 필요하다는 점을 설명할 수 있다.
• 모듈 분리와 서비스 분리가 서로 다른 운영 비용을 만든다는 점을 안다.
• canonical order와 추천 첫 회독이 다르며, 추천 경로에서는 Testing 뒤 API Contract를 Crawler보다 먼저 읽는다는 점을 안다.
• System Design Cases와 Web Crawler 중 현재 목표에 맞는 분기를 고를 수 있다.
• 막히면 L0 DI, L1 HTTP/API, L6 Queue/Retry/EDA, L8 Transaction 중 어디로 돌아갈지 고를 수 있다.

모든 항목을 깊게 설명할 필요는 없다. 요청 하나와 상태 변경 하나가 어떤 경계를 지나며, 실패했을 때 어느 약속을 확인할지 질문할 수 있으면 L9를 시작할 준비가 된 상태다.

10. Lineage — 구성 요소 지식에서 시스템 판단으로

L0 런타임·DI
  + L1 HTTP·API
  + L5 배포 가능한 실행 환경
  + L6 queue·retry·event
  + L8 transaction·index·replication
                │
                ▼
변경 이유와 정책을 코드 경계로 보호한다
  → 업무 언어와 불변식의 경계를 정한다
  → 설정·릴리스·프로세스를 교체 가능하게 만든다
  → 부분 실패와 일관성 비용을 모델링한다
  → 필요할 때만 서비스·장기 실행·읽기/쓰기 모델을 분리한다
  → 테스트와 API 계약으로 경계의 약속을 검증한다
  → 시스템 디자인 케이스에서 요구·부하·병목·실패 신호로 판단을 재사용한다

L9 뒤에는 “어떤 패턴을 썼는가”보다 “어떤 문제와 제약 때문에 이 경계를 선택했고, 무엇을 포기했으며, 어떤 증거가 결정을 반증할 수 있는가”를 설명할 수 있어야 한다. 이것이 개별 기술 지식을 아키텍처 판단으로 바꾸는 lineage다.

11. 이 레이어의 핵심 한 문장

아키텍처는 컴포넌트를 많이 그리는 일이 아니라, 변경과 실패가 번지는 범위를 경계로 제한하고 그 경계의 약속을 검증 가능한 계약으로 만드는 일이다.

12. 선택 탐색 지도 — 순서와 선수지식 부록

이 절은 첫 회독의 중심 경로를 다 읽은 뒤, 특정 문서로 바로 이동하거나 실제 prerequisite edge를 확인할 때 사용한다.

12-1. 각 frontmatter의 전체 hard prerequisite

아래 목록은 L9 내부 edge만 요약한 것이 아니라 각 문서 frontmatter가 선언한 내부 선수지식을 모두 포함한다. external_prerequisites도 별도로 표시한다.

• Design Principles: 내부 선수 없음. 외부 전제는 TypeScript 기본 문법과 객체지향 프로그래밍 기초다.
• Clean Architecture: L9 Design Principles.
• DDD Basics: L9 Clean Architecture.
• Twelve-Factor App: 내부 선수 없음.
• Distributed Systems Basics: L8 Transaction Basics.
• MSA Patterns: L1 API Design Basics, L6 EDA Basics, L6 Retry/Backoff/Idempotency, L8 Transaction Basics, L9 DDD Basics, L9 Twelve-Factor App, L9 Distributed Systems Basics.
• Saga Pattern: L6 EDA Basics, L6 Retry/Backoff/Idempotency, L8 CDC & Outbox, L8 Transaction Basics, L9 Distributed Systems Basics, L9 MSA Patterns.
• CQRS & Event Sourcing: L8 Transaction Basics, L9 DDD Basics, L9 Distributed Systems Basics. Saga는 canonical에서 앞서지만 hard prerequisite는 아니다.
• Testing Strategy: L0 DI/IoC, L1 HTTP Basics, L8 Transaction Basics, L9 Distributed Systems Basics, L9 MSA Patterns, L9 Saga Pattern, L9 CQRS & Event Sourcing.
• Web Crawler System Design: L1 HTTP Basics, L6 Queue/Worker Basics, L9 Distributed Systems Basics.
• API Design & Contract: L1 API Design Basics, L1 HTTP Basics.
• System Design Cases: L8 Transaction Basics, L8 DB Index & Query Optimization, L8 Redis Internals, L9 API Design & Contract, L9 Distributed Systems Basics.

이 도입부의 frontmatter에는 위 선수를 복제하지 않았다. 도입부는 지도를 읽는 진입점이고, 각 본문의 hard prerequisite는 실제로 그 문서에 진입할 때 적용한다.

12-2. L9 내부 prerequisite graph

다음 그래프는 L9 문서끼리의 직접 edge만 선수 → 후속 문서 형식으로 표현한다. L0·L1·L6·L8 의존성은 생략한 대신 바로 위 전체 목록에 모두 적었다.

Design Principles → Clean Architecture
Clean Architecture → DDD
DDD → MSA, CQRS / Event Sourcing
Twelve-Factor → MSA
Distributed Systems → MSA, Saga, CQRS / Event Sourcing, Testing, Web Crawler, System Design Cases
MSA → Saga, Testing
Saga → Testing
CQRS / Event Sourcing → Testing
API Contract → System Design Cases

이 그래프에서 인접하지 않는다고 선수 관계가 없는 것은 아니다. 예를 들어 Testing Strategy는 위 그래프의 네 L9 문서뿐 아니라 L0 DI/IoC, L1 HTTP, L8 Transaction도 직접 요구한다. 전체 판정에는 12-1 목록을 사용한다.

12-3. Canonical order와 추천 순서 비교

canonical tail : Testing(90) → Crawler(100) → API Contract(110) → Cases(120)
추천 첫 회독  : Testing(90) → API Contract(110) → Cases(120) 또는 Crawler(100)
빠른 Crawler  : Distributed Systems(50) → Crawler(100)

canonical order는 저장소 정렬이고 추천 순서는 학습 동선이다. 추천 경로는 API Contract를 Crawler보다 먼저 배치해 오류, 멱등성, 스키마 진화의 기본 계약을 놓치지 않게 한다. Crawler는 API Contract를 요구하지 않으므로 목적이 분명하면 Distributed Systems 뒤에서 바로 분기할 수 있다.

12-4. 목적별 선택 경로

모듈러 모놀리스의 구조를 개선하려는 경우

Design Principles → Clean Architecture → DDD → Testing Strategy를 우선한다. 독립 배포와 데이터 소유권 분리의 필요가 확인되기 전에는 모듈 경계 안에서 변경 비용과 불변식을 검증한다. Testing Strategy의 전체 hard prerequisite를 아직 충족하지 않았다면 unit·integration·결정성 절만 먼저 읽고 분산 흐름 절은 나중에 돌아온다.

서비스 분리와 비동기 업무 흐름을 설계하려는 경우

DDD + Twelve-Factor + Distributed Systems → MSA → Saga → CQRS/Event Sourcing → Testing을 따른다. L6 EDA·retry와 L8 transaction·CDC/Outbox가 약하면 먼저 보정한다. 서비스 수보다 데이터 소유권, timeout 뒤 결과 불명확, 중복 전달, 보상 가능성을 먼저 설명한다.

API와 시스템 디자인 역량을 우선하려는 경우

L1 HTTP/API 기초를 확인한 뒤 Design Principles → API Contract → Distributed Systems → System Design Cases로 빠르게 진입할 수 있다. 다만 System Design Cases가 요구하는 L8 transaction·index·Redis 선수지식은 생략할 수 없다.

크롤러·수집 파이프라인을 설계하려는 경우

L1 HTTP + L6 Queue/Worker + L8 Transaction → Distributed Systems → Web Crawler를 따른다. Crawler에서는 crawler와 scraper, URL identity와 content identity, host별 politeness, at-least-once 처리와 멱등 저장, backpressure를 하나의 상태 기계로 연결한다. MSA나 Saga를 먼저 완독할 필요는 없지만 HTTP, retry, queue의 기본 의미는 건너뛰면 안 된다.