시스템 설계 인터뷰: WhatsApp 설계하기
'WhatsApp을 설계하라'는 대규모 실시간 전송, 영속적인 메시지 저장, 상태 표시(온라인/마지막 접속 시각), 그리고 수억 대의 기기를 계속 연결된 상태로 유지하는 연결 관리 문제를 시험합니다. 언제나처럼 면접관은 실제 시스템의 복사본이 아니라 당신의 추론과 트레이드오프를 보고 싶어 합니다.
체계적으로 진행하세요: 요구사항을 명확히 하고, 규모를 추정하고, 연결과 전송 경로를 설계하고, 메시지를 어떻게 저장할지 결정한 다음, 그룹 채팅과 오프라인 전송·순서 보장 같은 어려운 부분을 다루세요. 아래 워크스루는 이 흐름을 따릅니다.
1. 요구사항 명확히 하기
먼저 범위를 정하세요. 핵심은 신뢰할 수 있는 전송을 갖춘 1대1 메시징입니다. 그룹 채팅, 미디어, 종단간 암호화가 이번 라운드의 범위에 포함되는지 명확히 하세요.
- 기능 요구사항: 메시지 송수신, 전송·읽음 확인, 온라인 상태, 그룹 채팅, 수신자가 연결이 끊겼을 때의 오프라인 전송.
- 비기능 요구사항: 낮은 지연, 높은 가용성, 내구성(메시지 손실 없음), 대화 내 순서 보장.
- 명확히 할 점: E2E 암호화와 미디어 처리 — 언급한 뒤 범위에 포함할지 명시적으로 결정하세요.
2. 규모 추정하기
설계를 이끄는 수치를 정하세요. 사용자 약 20억 명, 하루에 수백억 건의 메시지가 있다고 가정하면, 피크 시 초당 수십만 건의 메시지와 동시에 연결된 기기 수억 대가 됩니다 — 연결 관리 자체가 주요 과제가 됩니다.
3. 연결과 전송 경로
메시징에는 요청/응답 폴링이 아니라 지속적인 연결이 필요합니다. 기기는 게이트웨이 서버로의 WebSocket을 열어 둡니다. 중앙 컴포넌트는 각 사용자의 연결을 현재 어떤 게이트웨이가 보유하고 있는지 알아야, 메시지를 올바른 서버로 라우팅할 수 있습니다.
- WebSocket 게이트웨이: 기기의 활성 연결을 유지하고 송수신을 처리한다.
- 세션/상태 레지스트리: 사용자를 현재 게이트웨이 서버에 매핑한다(예: Redis). 연결/연결 해제 시 업데이트된다.
- 메시지 라우팅: 발신자의 게이트웨이가 수신자의 게이트웨이를 조회해 전달한다. 수신자가 오프라인이면 메시지는 큐에 들어간다.
4. 메시지 저장과 오프라인 전송
메시지는 수신자의 연결이 끊겨도 보존되어야 합니다. 각 메시지를 영속적으로 저장하고 수신자별 전송 상태를 추적하세요. 수신자가 온라인이면 즉시 전송하고, 그렇지 않으면 저장 후 재연결 시 전달합니다(스토어 앤 포워드).
대화 단위 키를 사용하는 쓰기 중심 접근 패턴은 단일 관계형 DB보다 Cassandra와 같은 와이드 컬럼 스토어(높은 쓰기 처리량, 수평 확장)에 더 적합합니다. 모든 수신자에게 전송이 확인된 메시지는 삭제하거나 만료시킬 수 있습니다. WhatsApp은 전송된 메시지를 서버 측에 무기한 보관하지 않기 때문입니다.
5. 그룹 채팅
그룹 메시징은 팬아웃입니다: 한 번의 전송이 N번의 전달이 됩니다. 일반적인 그룹 크기에서는 팬아웃-온-라이트(각 멤버의 전송 경로에 밀어넣기)가 단순하고 읽기가 빠릅니다. 트레이드오프를 짚어 두세요 — 매우 큰 그룹에서는 팬아웃-온-라이트가 비용이 커지므로, 거대한 브로드캐스트 그룹은 다른 설계 문제가 됩니다.
6. 언급해야 할 트레이드오프
긴장 관계를 짚으며 마무리하세요: 순서 보장(대화별 시퀀스 번호 대 전역 순서), 확인 응답에 대한 일관성 대 가용성('마지막 접속'에는 최종 일관성으로 충분하지만 전송에는 더 강한 보장이 필요), 그리고 그룹에서의 팬아웃-온-라이트 대 온-리드. 이를 명시적으로 짚는 것이 시니어급 답변을 만듭니다.
실시간 도움으로 WhatsApp 시스템 설계 연습하기
Natively의 시스템 설계 인터뷰 어시스턴트는 실시간 라운드 중에도 당신이 구조를 잃지 않도록 다음에 다뤄야 할 차원을 제안하고 트레이드오프를 실시간으로 보여줍니다. 모든 것이 당신의 기기에서만 이루어집니다.
