빛과 전파의 한계에서 시작하는 분산 시스템: 피터 도이치의 8가지 오류와 현실

분산 시스템의 진짜 출발점: 피터 도이치의 8가지 오류

단일 서버(Monolith) 환경에서 개발을 할 때는 모든 것이 평화롭습니다. 함수를 호출하면 결과가 즉시 돌아오고, 메모리에 올린 데이터는 안전하며, 디스크나 네트워크 I/O는 대개 순조롭게 흘러갑니다.

하지만 서비스를 확장해 마이크로서비스 아키텍처(MSA)나 대규모 분산 시스템을 구축하는 순간, 이 '당연함'들은 전부 거대한 착각이었음을 깨닫게 됩니다. 도대체 왜 분산 환경은 우리를 괴롭히는 걸까요? 답을 찾으려면 추상화된 코드를 걷어내고, 데이터가 움직이는 물리적 세계로 내려가야 합니다.

이 글은 분산 시스템 시리즈 1편입니다. 1편에서는 물리적 한계 → 개발자들이 무의식적으로 빠지는 8가지 착각 → 이 한계 위에서 살아남는 회복 탄력성 전략까지 다룹니다.

---

1. 랜선 밖의 세계: 데이터는 어떻게 움직이는가?

소프트웨어 엔지니어들은 종종 HTTP 요청이나 JSON 페이로드를 추상적인 개념으로만 다루지만, 전 세계의 컴퓨터는 엄연한 물리 법칙 위에 연결되어 있습니다.

• 광케이블 (빛): 대륙과 대륙, 데이터센터와 데이터센터를 잇는 거대한 고속도로는 유리 섬유 속을 달리는 빛(광 신호)이 담당합니다. 진공 중에서는 초속 약 30만 km로 이동하지만, 광케이블 내부의 유리 매질에서는 굴절률 때문에 실제 속도가 이보다 약 2/3 수준으로 줄어듭니다.
• 유선 랜선 (전기): 사무실이나 서버실 안에서는 구리선 속의 전압 변화(전기 신호)가 0과 1을 나릅니다.
• 무선 전파 (전파): 스마트폰이나 노트북 등 우리 눈앞의 말단(Last Mile) 구간에서는 공기 중을 파도처럼 타고 흐르는 전파가 그 역할을 대신합니다. 장애물, 날씨, 다른 전자기파 간섭에 모두 취약합니다.

음악이나 영상 역시 전파나 빛이 직접 소리를 나르는 것이 아니라, 거대한 0과 1의 디지털 데이터로 쪼개진 뒤 주파수과 진폭의 변조를 거쳐 전송되고, 수신 측에서 이를 다시 복원해 내는 것입니다.

여기서 핵심은 이 모든 매체(빛, 전기, 전파)가 저마다의 물리적 한계를 지닌다는 점입니다. 빛의 속도는 유한하고, 공기 중의 전파는 장애물과 간섭에 취약하며, 구리선은 거리가 멀어질수록 저항을 받습니다. 분산 시스템의 고통은 바로 이 물리적 한계에서 시작됩니다.

---

2. 피터 도이치의 8가지 오류: 로컬 머신의 환상에서 벗어나기

1991년, 선 마이크로시스템즈(Sun Microsystems)의 L. Peter Deutsch는 분산 시스템을 설계할 때 개발자들이 무의식적으로 빠지는 대표적인 착각들을 정리했습니다. 1994~97년에 걸쳐 제임스 고슬링(James Gosling)이 이를 보완해 업계에 널리 퍼뜨린 것이 바로 '분산 컴퓨팅의 8가지 오류(Fallacies of Distributed Computing)' 입니다.

이 8가지는 단순한 "조심해야 할 점"이 아닙니다. 우리가 분산 환경을 대할 때 무의식적으로 믿게 되는 가짜 전제이며, 이 전제들이 무너질 때 모든 종류의 장애가 시작됩니다.

1. 네트워크는 신뢰할 수 있다 (The network is reliable): 패킷은 언제든 유실되고, 회선은 끊어집니다.
2. 지연 시간(Latency)은 0이다 (Latency is zero): 물리적인 거리가 존재하는 이상 빛이나 전파가 이동하는 왕복(RTT) 비용은 피할 수 없습니다.
3. 대역폭은 무한하다 (Bandwidth is infinite): 네트워크 파이프라인은 한정되어 있어 대용량 데이터를 무분별하게 주고받으면 병목이 생깁니다.
4. 네트워크는 안전하다 (The network is secure): 내부망(Intranet)이라도 완벽히 안전하다고 믿는 순간 보안 사고로 이어집니다.
5. 토폴로지는 변하지 않는다 (Topology doesn't change): 서버는 늘어나고 줄어들며 라우팅은 동적으로 바뀝니다.
6. 관리자는 한 명이다 (There is one administrator): 대규모 시스템은 여러 팀과 조직, 클라우드 벤더가 얽혀 있어 설정의 일관성을 유지하기 어렵습니다.
7. 전송 비용은 0이다 (Transport cost is zero): 클라우드 환경의 아웃바운드 트래픽(Egress) 비용 등 실질적인 비용이 발생합니다.
8. 네트워크는 동질적이다 (The network is homogeneous): 다양한 하드웨어와 프로토콜이 섞여 있어 상호 운용성을 고려해야 합니다.

왜 30년이 지난 지금도 유효한가? 단순합니다 — 빛의 속도는 변하지 않았고, 네트워크의 본질도 변하지 않았기 때문입니다. 오히려 클라우드와 MSA 시대에 와서 더더욱 정확해졌습니다.

---

3. 왜 해결할 수 없는가? — 구조적 트레이드오프의 존재

이 8가지 오류가 단순한 '실수'를 넘어 근본적으로 해결될 수 없는 이유는, 분산 시스템이 마주한 구조적 트레이드오프 때문입니다.

네트워크는 언제든 끊어질 수 있고(오류 #1), 지연은 항상 존재하며(오류 #2), 대역폭은 유한합니다(오류 #3). 이 물리적 사실들이 의미하는 바는 명확합니다 — 분산 시스템은 늘 무언가를 포기해야 한다. 모든 것을 다 갖춘 완벽한 분산 시스템은 물리 법칙상 불가능합니다.

이 트레이드오프를 수학적으로 명확히 정의한 이론이 CAP 이론입니다. 네트워크가 끊어지는 상황(Partition, P)에서는 일관성(Consistency, C)과 가용성(Availability, A) 사이에서 반드시 하나를 선택해야 한다는 것이고, 네트워크가 정상일 때(Else, E)에는 지연(Latency)과 일관성 사이에서 또 다른 선택을 해야 한다는 것을 PACELC 이론이 보완합니다.

다음 편(2편)에서는 CAP 이론의 정확한 의미와, "P는 선택사항이 아니라 무조건 감수해야 할 기본 전제"라는 자주 오해받는 핵심을 깊이 파고듭니다.

---

4. 현업에서 마주치는 아찔한 안티 패턴

물리적 현실과 8가지 오류를 무시하고 코드를 짰을 때, 프로덕션 환경에서 실제로 마주하게 되는 대표적인 장애들입니다.

• 타임아웃 없는 동기 API 호출과 연쇄 장애 (Cascading Failure): "네트워크는 빠르고 신뢰할 수 있다"고 믿고 외부 연동 API에 무한정 대기(Blocking) 타임아웃을 걸어두었다가, 외부 서비스 지연으로 내 서버의 커넥션 풀이 고갈되고 전체 시스템이 다운되는 현상.
• 불필요한 트래픽 폭탄과 비용 청구: "대역폭과 전송 비용은 0이다"라는 생각으로 매번 거대한 페이로드를 주고받거나, MSA 환경에서 불필요한 N+1번의 내부 네트워크 호출을 발생시켜 클라우드 트래픽 비용(Egress) 폭탄을 맞는 경우.
• "관리자는 한 명"이라는 환상 아래의 설정 드리프트: 한 서비스는 timeout 3초, 다른 서비스는 30초, 로컬은 1초 — 일관성 없는 기본값이 장애 디버깅 시간을 몇 배로 부풀립니다. 여러 팀과 클라우드 벤더가 관여하는 환경일수록 더 심해집니다.

이 모든 사례는 결국 "분산 시스템은 실패한다"는 사실을 시스템 설계의 출발점으로 받아들이지 않은 대가입니다.

---

5. 백엔드 개발자가 분산 환경에서 살아남는 실천 전략

이 불안정한 물리 세계와 분산 환경 위에서도 무너지지 않는 시스템을 만들려면, 사고의 전환이 먼저입니다.

1. 실패를 기본값으로 두기 (Design for Failure)

시스템이 실패하는 것은 예외가 아니라 정상 상태(Normal state)로 가정합니다. "만약 네트워크가 끊기면?", "만약 응답이 1초 늦으면?", "만약 같은 요청이 두 번 오면?" — 이 질문을 코드를 쓰기 전에 먼저 던져야 합니다.

2. 회복 탄력성(Resilience) 패턴 적용

• Timeout & Retry with Exponential Backoff: 무작정 재시도하는 것이 아니라 지연 시간을 점진적으로 늘리고 Jitter(무작위성)를 섞어 서버 쇄도(Thundering Herd) 현상을 방지합니다.
• Circuit Breaker: 장애가 전파되는 것을 막기 위해 문제가 감지되면 빠르게 실패(Fast-fail) 처리하고, 주기적으로 복구 여부를 살핍니다.

3. 멱등성(Idempotency) 설계

네트워크가 불안정해 재시도(Retry)가 빈번하게 발생하므로, 동일한 요청을 여러 번 보내도 결과가 안전하도록 결제·주문 시스템에는 멱등성 키(Idempotency Key)를 반드시 도입해야 합니다. 이 패턴은 2편의 CAP 이론에서 다시 만나게 됩니다.

4. 트레이드오프 의식 훈련

내 서비스가 "C(일관성)"와 "A(가용성)" 중 무엇을 우선해야 하는지, 평소에는 "L(지연)"과 "C(일관성)" 중 무엇을 우선해야 하는지를 팀 안에서 명시적으로 합의해 두면, 장애 시 "지금 무엇을 포기하기로 한 쪽인가?"를 3초 안에 판단할 수 있습니다. 이 결정의 수학적 배경은 2편 CAP 이론에서 다룹니다.

---

Outro

로컬 개발 환경의 편안함에 익숙해지면 우리는 종종 데이터가 광케이블의 빛을 타고, 공기 중의 전파를 뚫고 날아간다는 엄연한 물리적 사실을 잊어버리곤 합니다.

피터 도이치의 8가지 오류가 경고하듯, 네트워크는 끊어지고, 지연은 존재하며, 비용은 발생합니다. 분산 시스템을 다루는 엔지니어에게 필요한 것은 "절대 실패하지 않는 환상적인 네트워크"를 만드는 것이 아니라, "언제든 실패할 수 있는 물리적 현실 속에서도 무너지지 않는 회복 탄력성(Resilience)"을 설계하는 마인드셋일 것입니다.

---

다음 편 예고 — 2편: CAP 이론, "P를 보장한다"는 것의 진짜 의미

이번 편에서 우리는 "분산 시스템은 트레이드오프가 존재한다"는 사실에 도달했습니다. 2편에서는 그 트레이드오프를 수학적으로 가장 간결하게 정의한 CAP 이론으로 들어갑니다. 특히 "P는 선택사항이 아니라 무조건 감수해야 할 기본 전제"라는, 많은 개발자들이 처음에 오해하는 핵심을 짚고, 1편 §5에서 다룬 회복 탄력성 패턴들이 CAP의 어느 위치에 대응하는지 한 번 더 정리합니다.