분산 시스템 (Distributed Systems)

분산 시스템이란

분산 시스템(Distributed Systems) 은 하나의 컴퓨터가 아니라 여러 노드가 네트워크를 통해 협력해 하나의 서비스처럼 동작하는 시스템입니다.

이 문서는 시스템 설계 관점에서 분산 환경의 실패 모델과 선택 기준을 설명합니다.
트랜잭션 격리 수준, 2PC, Saga, MVCC처럼 데이터베이스 내부 일관성에 더 가까운 내용은 데이터베이스 트랜잭션과 일관성 문서가 더 직접적인 심화 자료입니다.

면접에서는 보통 다음 성질을 같이 설명하는 편이 좋습니다.

여러 노드가 함께 동작한다
부분 실패가 항상 가능하다
네트워크가 느리거나 끊길 수 있다
각 노드가 완전히 같은 시각을 공유하지 않는다

즉, 분산 시스템은 “서버를 여러 대 둔다”는 말보다,
단일 머신에서는 없던 불확실성을 어떻게 다룰지 설계하는 문제에 가깝습니다.

분산 시스템이 어려운 이유

단일 프로세스 안에서는 함수 호출 실패와 네트워크 실패가 다르지 않습니다.
하지만 분산 시스템에서는 다음 상황이 계속 발생합니다.

요청은 보냈는데 응답이 늦는 상황
상대 노드가 죽었는지, 네트워크만 느린지 모르는 상황
일부 노드만 최신 데이터를 가진 상황
각 노드의 시간이 조금씩 다른 상황
한 작업이 중간까지는 성공했지만 전체는 실패한 상황

그래서 분산 시스템에서는 항상 다음이 따라옵니다.

타임아웃
재시도
중복 처리
멱등성
부분 실패 격리

면접에서 이 부분을 짚어주면 답변이 훨씬 실무적으로 보입니다.

timeout budget, retry 위치, circuit breaker 같은 복원력 일반론은 복원력 패턴 (Timeout, Retry, Circuit Breaker) 문서가 더 직접적입니다. 여기서는 왜 이런 패턴이 분산 시스템에서 필수 전제가 되는지에 집중하면 좋습니다.

CAP 이론

CAP 이론(CAP Theorem) 은 네트워크 파티션이 발생했을 때, 분산 시스템이 일관성(Consistency) 과 가용성(Availability) 을 동시에 완벽하게 만족시키기 어렵다는 점을 설명하는 틀입니다.

여기서 핵심은 P(Partition Tolerance) 가 현실의 분산 시스템에서는 사실상 피할 수 없는 전제라는 점입니다.

항목	의미
Consistency	모든 노드가 같은 시점에 같은 데이터를 본다
Availability	모든 요청에 성공 또는 실패 응답을 돌려준다
Partition Tolerance	네트워크가 끊기거나 지연돼도 시스템이 동작을 이어간다

이 이론을 설명할 때 주의할 점은 다음과 같습니다.

CAP은 평상시 모든 특성을 영원히 포기하라는 말이 아닙니다.
파티션이 발생한 순간 어떤 것을 우선할지에 대한 설계 선택에 가깝습니다.
실제 제품은 read/write concern, quorum, replica 설정에 따라 동작이 달라질 수 있습니다.

예를 들면:

금융 거래 는 가용성보다 일관성을 우선할 수 있습니다.
소셜 피드 는 잠시 오래된 데이터를 보여줘도 가용성을 우선할 수 있습니다.

그래서 면접에서는 “이 시스템은 CP입니다”라고 단정하기보다,
어떤 장애 상황에서 무엇을 우선할지를 업무 요구와 함께 설명하는 편이 더 안전합니다.

분산 일관성 관리

분산 시스템에서는 모든 데이터를 항상 즉시 동일하게 맞추기 어렵기 때문에, 일관성을 어디까지 요구할지 먼저 정해야 합니다.

대표 선택지는 다음과 같습니다.

모델	장점	대가	예시
강한 일관성	읽는 즉시 최신 데이터 보장에 유리	지연과 가용성 비용이 커질 수 있음	결제, 재고 차감
최종적 일관성	가용성과 확장성에 유리	잠시 오래된 데이터를 볼 수 있음	피드, 알림, 분석
읽기/쓰기 quorum	일관성과 가용성의 균형을 조절 가능	운영과 튜닝이 복잡함	분산 KV, 다중 replica 구성

실무에서는 보통 다음 방식으로 일관성을 관리합니다.

동기 트랜잭션: 강한 일관성이 중요한 핵심 쓰기
비동기 복제: 읽기 확장과 다중 리전 복제
이벤트 기반 보상: 최종적 일관성이 허용되는 흐름
Idempotency-Key: 재시도 시 중복 처리 방지

예를 들어 주문 시스템에서는:

주문 생성은 강한 일관성으로 처리
이메일 발송과 분석 적재는 비동기로 처리
재시도나 중복 이벤트는 멱등성으로 흡수

이렇게 경계를 나누는 편이 현실적입니다.

관련 세부 내용은 데이터베이스 트랜잭션과 일관성, 메시징 시스템 문서와 함께 설명하면 좋습니다.
멱등 키 저장 전략, 재시도 위치, backoff 같은 설계 디테일은 멱등성과 재시도 (Idempotency and Retry) 문서가 더 직접적인 심화 자료입니다.
즉, 여기서는 업무별 일관성 경계를 어떻게 나눌지에 초점을 두고, DB 내부 보장과 구현 방식은 관련 상세 문서로 넘기는 편이 좋습니다.

분산 ID 생성

분산 시스템에서는 단일 DB의 auto increment만으로는 전역 고유 ID를 만들기 어려운 경우가 많습니다. 이때 자주 나오는 방식이 분산 ID 생성입니다.

대표 선택지는 다음과 같습니다.

방식	장점	주의점
DB auto increment	단순하고 직관적	단일 노드 병목과 전역 확장 한계
UUID	중앙 조정 없이 생성 가능	길고 정렬 친화성이 낮을 수 있음
Snowflake 계열	시간 순서와 분산 생성을 함께 만족	clock skew와 worker id 관리 필요
티켓 서버	순번 제어가 쉬움	중앙 서비스 병목 가능

UUID는 중앙 조정 없이 고유성을 얻기 쉬워 널리 쓰입니다.¹
반면 정렬 가능성과 저장 효율이 더 중요하면 Snowflake 계열 ID를 검토할 수 있습니다.

면접에서는 다음 포인트를 같이 말하면 좋습니다.

고유성만 필요한가
대략 시간 순서도 필요한가
DB 인덱스 locality가 중요한가
중앙 발급 서버를 둘 수 있는가

예를 들어 주문 이벤트 로그처럼 시간 순 정렬이 중요하면 단순 랜덤 UUID보다 시간 기반 정렬 가능 ID가 더 유리할 수 있습니다.

시계 동기화와 순서 문제

분산 시스템에서 자주 놓치는 포인트가 시간(Time) 입니다. 여러 노드가 완전히 같은 시각을 공유하지 않기 때문에, “먼저 일어난 일”을 판단하는 것이 생각보다 어렵습니다.

대표 문제는 다음과 같습니다.

clock skew: 노드마다 시간이 조금씩 다름
timestamp 역전: 늦게 처리된 이벤트가 더 이른 시각으로 찍힘
전역 순서 착시: 서로 다른 노드의 timestamp를 곧바로 전체 순서로 믿기 어려움

이 문제 때문에 다음 오해를 피해야 합니다.

created_at 만으로 항상 진짜 순서를 보장할 수는 없음
분산 트랜잭션 없이 timestamp만 비교해 충돌을 해결하면 위험할 수 있음
여러 리전에서 동시에 쓰는 시스템은 더 조심해야 함

보통 대응 방식은 다음과 같습니다.

NTP 같은 시간 동기화 체계 사용
논리 시계나 버전 번호 활용
Snowflake 같은 시간 + 노드 + 시퀀스 조합 사용
충돌 가능성을 애플리케이션 로직에서 감수하고 보정

Google Spanner는 TrueTime을 이용해 전역적으로 강한 일관성을 지원하는 대표 사례로 자주 언급됩니다.²

면접에서 중요한 것은 “모든 서버 시간이 같다”는 가정을 하지 않는 것입니다.
좋은 답변은 시간이 완벽하지 않다는 전제를 두고 순서와 충돌을 설계한다는 점을 보여줍니다.

분산 시스템의 트레이드오프

장점: 확장성과 가용성을 높이고, 장애를 일부 노드 수준에 가둘 수 있습니다.
단점: 네트워크 지연, 부분 실패, 일관성 저하, 운영 복잡도가 커집니다.
주의점: 단일 시스템의 단순함을 포기하는 만큼, 재시도와 관측성, 멱등성 설계가 필수입니다.

특히 다음을 같이 말하면 답변이 강해집니다.

분산 시스템은 성능 문제만이 아니라 실패 모델이 달라지는 문제
강한 일관성, 낮은 지연, 높은 가용성을 동시에 최대로 얻기 어렵다는 점
ID, 시간, 재시도, 중복 처리까지 같이 설계해야 한다는 점

면접 포인트

분산 시스템은 여러 서버를 두는 것이 아니라, 네트워크와 부분 실패를 전제로 설계하는 문제입니다.
CAP 이론은 파티션 상황에서 무엇을 우선할지 정하는 틀로 설명하는 편이 좋습니다.
분산 일관성은 업무별로 강한 일관성과 최종적 일관성을 나눠서 설명해야 합니다.
분산 ID는 고유성뿐 아니라 정렬 가능성, 운영 방식, 인덱스 효율까지 같이 봐야 합니다.
여러 노드의 시간이 완전히 같다고 가정하면 안 되고, clock skew와 순서 문제를 고려해야 합니다.