시스템 설계, 기술 면접 대비

실시간 채팅 시스템 설계 면접 퀴즈

무엇을 보장하지 않을지 정하면 확장 경로가 열린다

동시 접속 20만, 최대 5만 명 채널, 전달 지연 300ms 라는 하나의 요구사항으로 팀 메신저를 끝까지 설계합니다. 팬아웃, 연결 계층, 순서 보장과 파티션, 저장과 조회, 오프라인 전달, 읽음 표시, 접속 상태를 같은 제약 안에서 다룹니다.

로그인 없이 풀어보기
16개 문제, 무료

이 설계에 주어진 요구사항

문제는 모두 이 하나의 요구사항 안에서 풉니다.

실시간 채팅 시스템 설계

팀 메신저

팀이 채널에서 대화하는 메신저를 만듭니다. 실시간 전달이 이 설계의 중심입니다.

이번에 만드는 기능

  • 채널에 메시지 보내기
  • 접속한 사람에게 실시간으로 도착하기
  • 지난 메시지 거슬러 보기
  • 읽음 표시와 안 읽은 개수 보기
  • 접속하지 않은 사람에게 알림 보내기
  • 상대의 접속 상태와 입력 중 표시 보기

범위 밖

  • 음성과 영상 통화
  • 파일 미리보기
  • 메시지 검색
  • 종단간 암호화

지켜야 하는 수치

동시 접속
20만
채널 인원
평균 12명, 최대 5만 명
메시지
하루 2억 건
전달 지연
300ms 안에 상대 화면까지

전제로 주어진 것

  • 순서는 채널 안에서만 보장한다. 다른 채널 사이 순서는 보장하지 않는다
  • 접속하지 않은 사람도 다시 열었을 때 놓친 메시지를 볼 수 있어야 한다

학습할 핵심 개념

요구사항 정리와 범위 자르기
팬아웃 전략
연결 계층 분리
순서 보장과 파티션 나누기
메시지 저장과 지난 대화 조회
접속하지 않은 사용자에게 전달하기
읽음 표시와 갱신 비용
접속 상태와 타이핑 표시

핵심 개념 미리보기

실시간 채팅 시스템 설계 면접에서 꼭 나오는 개념을 미리 확인하세요

요구사항 정리와 범위 자르기

핵심

채팅 설계도 요구사항을 기능비기능으로 나누고 범위 밖을 먼저 자르는 것에서 시작합니다. 이 토픽은 아래 하나의 요구사항을 끝까지 풉니다.

항목
서비스팀 메신저
동시 접속20만
채널 크기평균 12명, 최대 5만 명
메시지하루 2억 건
전달 지연300ms 안에 상대 화면까지
순서채널 안에서만 보장한다. 전역 순서는 포기

기능 요구사항과 범위 밖

구분내용
이번에 만든다채널에 메시지 보내기, 실시간 수신, 지난 메시지 조회, 읽음 표시, 접속하지 않은 사람에게 알림, 접속 상태와 입력 중 표시
범위 밖음성과 영상 통화, 파일 미리보기, 메시지 검색, 종단간 암호화

범위 밖을 말하는 것이 실력입니다. 검색을 빼면 저장 구조가 단순해지고, 종단간 암호화를 빼면 서버가 내용을 볼 수 있어 알림 문구를 만들 수 있습니다. 뺀 것이 남은 설계를 바꿉니다.

비기능 요구사항이 설계를 정한다

채팅 비기능 요구사항 네 개가 각각 어떤 설계 결정을 정하는지 비기능 요구 정해지는 설계 동시 접속 20만 연결 계층을 분리한다 채널 최대 5만 팬아웃 방식이 갈린다 지연 300ms 폴링으로는 못 맞춘다 채널 내 순서만 채널로 파티션한다 평균 12명은 반대로 작동한다. 대부분의 채널에 팬아웃은 문제가 아니다
숫자강제하는 것
동시 접속 20만연결 계층 분리연결을 유지하는 일과 메시지를 처리하는 일은 자원 성격이 다르다
채널 최대 5만 명팬아웃 설계한 번 보낸 메시지가 5만 개의 전달로 늘어난다
지연 300ms서버가 밀어주기폴링은 간격만큼 지연이 쌓인다
채널 내 순서만채널 단위 파티션전역 순서를 포기하면 채널별로 나눠 처리할 수 있다

순서를 어디까지 보장할지가 확장을 정한다

전역 순서를 보장하려면 모든 메시지가 한 곳을 지나야 합니다. 그러면 그곳이 상한이 됩니다.

채널 안에서만 보장하기로 정하면 채널을 기준으로 나눠 처리할 수 있습니다. 다른 채널의 메시지가 서로 뒤바뀌어도 사용자는 알 수 없습니다. 한 대화방 안에서만 순서가 맞으면 됩니다.

이것이 요구사항을 읽는 방법입니다. 무엇을 포기해도 되는지 찾으면 확장 경로가 열립니다.

평균값은 반대로 읽는다

평균 12명 이라는 숫자는 과설계를 막는 쪽으로 씁니다. 최대가 5만 명 이라 팬아웃 설계가 필요하지만, 실제 채널 대부분은 12명이라 보낼 때 바로 전달해도 됩니다.

그래서 설계는 하나가 아니라 두 갈래가 됩니다. 작은 채널은 즉시 전달, 큰 채널만 다른 경로로 보냅니다. 최대값만 보고 모든 채널을 무겁게 처리하면 흔한 경우가 느려집니다.

면접에서 이렇게 나옵니다
  • Q.채팅 서비스의 요구사항을 어떻게 정리하시겠습니까
  • Q.메시지 순서를 어디까지 보장해야 하나요
  • Q.이 요구사항에서 가장 먼저 한계에 닿는 곳은 어디인가요

팬아웃 전략

핵심

메시지 하나를 보내면 채널 인원 수만큼 전달이 생깁니다. 이것을 팬아웃이라고 합니다. 채널이 최대 5만 명 이므로 한 번의 전송이 5만 개의 전달로 늘어납니다.

방식은 두 갈래이고, 쓰기와 읽기 중 어디에 비용을 낼지의 선택입니다.

보낼 때 각 수신자에게 복제하는 방식과 읽을 때 채널에서 모으는 방식의 비교 보낼 때 복제 전송 받은함 1 받은함 2 받은함 N 읽기가 빠르다 N 이 크면 쓰기가 터진다 읽을 때 모으기 전송 채널 하나 읽기 쓰기가 한 번이다 읽을 때마다 모아야 해서 조회가 느려진다

두 방식의 대가

항목보낼 때 복제읽을 때 모으기
쓰기수신자 수만큼 늘어난다한 번
읽기자기 받은함만 읽는다. 빠르다채널에서 모아야 한다. 느리다
저장같은 메시지가 N개한 개
터지는 지점큰 채널의 쓰기 증폭많은 채널을 보는 사용자의 읽기 증폭

왜 하나로 통일하지 않나

평균 채널이 12명 이라 대부분은 복제해도 부담이 없습니다. 12개의 받은함에 쓰는 것은 아무 문제가 아니고, 읽기가 빨라지는 이득만 얻습니다.

문제는 소수의 큰 채널입니다. 5만 명 짜리 채널에 메시지 하나가 오면 5만 번의 쓰기가 발생하고, 그 채널이 활발하면 쓰기가 시스템을 밀어버립니다.

그래서 인원 수를 보고 경로를 고릅니다. 작은 채널은 복제하고, 큰 채널은 채널에만 저장해 읽을 때 모읍니다. 사용자 화면에서는 두 결과를 합쳐 보여줍니다.

경계값은 재서 정한다

몇 명부터 큰 채널로 볼지는 추측하지 않습니다. 채널 크기 분포와 채널별 메시지 빈도를 재서 쓰기 증폭이 감당 한계를 넘는 지점을 찾습니다. 인원이 많아도 조용한 채널은 복제해도 되고, 인원이 적어도 초당 수십 건이 오가면 부담이 됩니다.

오프라인 사용자는 다르게 다룬다

접속하지 않은 사용자에게 실시간 전달은 의미가 없습니다. 그 사람 몫의 팬아웃은 미룰 수 있습니다. 접속할 때 못 받은 메시지를 채널에서 가져오면 되고, 알림만 따로 보냅니다.

이렇게 나누면 20만 동시 접속자 몫만 실시간 경로를 타므로 팬아웃 폭이 크게 줄어듭니다.

면접에서 이렇게 나옵니다
  • Q.한 메시지를 채널 인원 전체에게 어떻게 도달시키나요
  • Q.큰 채널과 작은 채널을 가르는 기준은 어떻게 정하나요
  • Q.오프라인 사용자에게도 실시간으로 팬아웃해야 하나요

연결 계층 분리

핵심

동시 접속 20만 이 이 설계의 첫 제약입니다. 연결은 상시 점유입니다. 아무 메시지가 오가지 않아도 메모리와 소켓을 계속 씁니다. 메시지 처리는 순간 부하라 성격이 다릅니다.

자원 성격이 다르면 따로 늘려야 합니다. 그래서 연결을 받는 계층을 떼어냅니다.

연결을 받는 게이트웨이와 메시지를 처리하는 서비스를 분리한 구조 클라이언트 20만 연결이 계속 열려 있다 연결 게이트웨이 연결만 들고 있다 메시지만 채팅 서비스 순서, 저장, 팬아웃 상시 점유. 메모리와 소켓 연결 수로 늘린다 순간 부하. CPU 처리량으로 늘린다 자원 성격이 다르면 따로 늘려야 한다. 한 서버에 두면 둘 중 하나가 낭비된다 게이트웨이는 어느 사용자가 어디 붙어 있는지만 알면 된다

왜 한 서버에 두면 안 되나

한 서버가 연결과 처리를 함께 맡으면 둘 중 하나가 낭비됩니다.

상황결과
접속자는 많고 대화는 조용하다연결 때문에 서버를 늘렸는데 CPU 가 남는다
접속자는 적고 대화가 활발하다CPU 때문에 늘렸는데 연결 수용량이 남는다

배포도 문제가 됩니다. 채팅 로직을 고칠 때마다 서버를 재시작하면 20만 개의 연결이 한꺼번에 끊깁니다. 클라이언트가 동시에 재접속을 시도해 그 자체가 부하가 됩니다.

계층을 나누면 처리 계층만 배포할 수 있고 연결은 유지됩니다.

게이트웨이가 알아야 하는 것

게이트웨이는 채팅 로직을 모릅니다. 어느 사용자가 어느 게이트웨이에 붙어 있는지만 알면 됩니다. 처리 계층이 "이 사용자에게 보내라" 고 하면 해당 게이트웨이로 넘깁니다.

이 접속 위치 정보를 어디에 두느냐가 다음 판단입니다.

방식특징
공유 저장소에 기록어느 처리 노드에서든 조회한다. 조회가 매 전달마다 붙는다
게이트웨이 전체에 뿌린다조회가 없다. 게이트웨이 수가 많으면 낭비가 크다

접속과 종료가 잦으므로 이 정보는 자주 바뀌고 짧게 살아 있습니다. 영구 저장소보다 만료가 있는 캐시가 맞습니다.

연결이 끊기는 것은 정상이다

모바일에서 연결은 수시로 끊깁니다. 그래서 게이트웨이는 끊김을 오류로 다루지 않습니다. 접속 위치를 지우고, 그 사용자에게 갈 메시지는 채널에 남겨 둡니다. 다시 붙으면 못 받은 것부터 가져갑니다.

여기서 접속 상태를 "끊김 즉시 오프라인" 으로 바꾸면 화면이 깜빡입니다. 짧은 유예를 두고 그 안에 다시 붙으면 상태를 유지합니다.

면접에서 이렇게 나옵니다
  • Q.동시 접속 20만을 어떤 구조로 받나요
  • Q.어느 사용자가 어디 접속해 있는지를 어떻게 관리하나요
  • Q.연결이 끊기는 것을 어떻게 다루나요

더 많은 개념과 문제는 가입 후 이용할 수 있어요

먼저 5문제 맛보기

실시간 채팅 시스템 설계 면접 빈출 질문

실제 면접에서 자주 나오는 질문들입니다

Q.

채팅 서비스의 요구사항을 어떻게 정리하시겠습니까

요구사항 정리와 범위 자르기 개념 정리 보기
Q.

메시지 순서를 어디까지 보장해야 하나요

요구사항 정리와 범위 자르기 개념 정리 보기
Q.

이 요구사항에서 가장 먼저 한계에 닿는 곳은 어디인가요

요구사항 정리와 범위 자르기 개념 정리 보기
Q.

채널 최대 인원이 5만 명이면 모든 채널을 같은 방식으로 처리해야 하나요

요구사항 정리와 범위 자르기 개념 정리 보기
Q.

한 메시지를 채널 인원 전체에게 어떻게 도달시키나요

팬아웃 전략 개념 정리 보기
Q.

큰 채널과 작은 채널을 가르는 기준은 어떻게 정하나요

팬아웃 전략 개념 정리 보기
Q.

오프라인 사용자에게도 실시간으로 팬아웃해야 하나요

팬아웃 전략 개념 정리 보기
Q.

두 방식을 섞으면 사용자 화면에서 순서가 어긋나지 않나요

팬아웃 전략 개념 정리 보기

이런 점이 좋아요

포기할 보장을 찾아 확장 경로를 여는 훈련

채널 크기에 따라 기능을 줄이는 판단

잃어도 되는 데이터를 가볍게 다루는 감각

지금 바로 시작하세요

무료로 실시간 채팅 시스템 설계 퀴즈를 풀고, AI 오답 분석으로 실력을 키우세요.