Introduction

분산 시스템이 뭔지 한 문장으로? Leslie Lamport 말이 정확해 — "당신이 존재조차 몰랐던 컴퓨터의 장애가 당신의 컴퓨터를 못 쓰게 만드는 것." 이 책은 그 혼돈을 다루는 다섯 가지 도전과제를 파트 하나씩 풀어가.

첫 번째는 **통신(Communication)**이야. 브라우저가 서버에 요청 보내는 것처럼 단순해 보이지만, 네트워크는 끊기고, 스위치가 비트를 뒤집고, 패킷이 사라져. "네트워킹 라이브러리가 다 해주겠지" 싶지만, 추상화는 새어나와(abstractions leak). 네트워크 스택을 이해해야 문제가 터졌을 때 대응할 수 있어.

두 번째, 조정(Coordination). 개별 노드가 하나의 목표를 향해 함께 움직여야 하는데, 장애가 있으면 이게 극적으로 어려워져. **"두 장군 문제"**를 생각해봐. 두 장군이 공격 시간에 합의해야 하는데, 메신저가 잡힐 수 있어. 확인 메시지를 보내도 그 확인의 확인이 필요하고... 아무리 라운드를 거쳐도 양쪽 다 확신할 수 없어. 네트워크 위에서의 합의가 근본적으로 어려운 이유야.

세 번째, 확장성(Scalability). 부하가 늘면 시스템은 결국 용량 한계에 도달해. 두 가지 길이 있는데, scale up(더 비싼 하드웨어)은 한계가 있고, scale out(범용 머신 추가)이 AWS 같은 클라우드 덕에 현실적인 해법이 됐어. 성능은 **처리량(throughput)**과 **응답 시간(response time)**으로 측정하고, 부하가 늘어도 성능이 떨어지지 않아야 확장 가능하다고 할 수 있지.

네 번째, 탄력성(Resiliency). 규모가 커지면 잘못될 수 있는 건 다 잘못돼. **가용성(availability)**은 시스템이 살아있는 시간의 비율인데, 99.9%(three nines)는 하루 1.44분 다운타임, 99.99%(four nines)는 8.64초야. 중복성, 장애 격리, 자가 치유가 필수지.

다섯 번째, 유지보수(Maintainability). 소프트웨어 비용의 대부분은 초기 개발이 아니라 유지보수에 쓰여. 테스트, 안전한 배포, 코드 변경 없이 동작을 바꿀 수 있는 능력이 필요해. DevOps 시대에는 만든 팀이 운영도 하니까, 온콜을 서봐야 시스템의 약점을 진짜로 알 수 있어.

그러면 분산 시스템의 해부학은? 세 관점으로 볼 수 있어 — 머신들의 네트워크, 프로세스들의 IPC, 서비스들의 API. 서비스의 핵심엔 비즈니스 로직이 있고, 인바운드 어댑터(HTTP 요청 → 서비스 호출)와 아웃바운드 어댑터(서비스 → 외부 DB)가 감싸고 있어. 이게 포트와 어댑터(ports and adapters) 아키텍처야 — 비즈니스 로직이 기술적 세부사항에 의존하지 않고, 기술적 세부사항이 비즈니스 로직에 의존하는 의존성 역전이지.

---

정리

1장 읽고 기억할 거 세 가지:

1. 분산 시스템의 다섯 도전 — Communication, Coordination, Scalability, Resiliency, Maintainability — 이 책 전체가 이 다섯 파트야.
2. **"두 장군 문제"**가 보여주듯 네트워크 위에서 합의는 근본적으로 어려워 — 메시지 전달을 보장할 수 없으니까.
3. 서비스 아키텍처의 기본은 포트와 어댑터 — 비즈니스 로직을 기술에서 분리하는 의존성 역전이 핵심이야.