시스템 디자인 면접, 어떻게 준비할까: 답변 틀과 메신저·결제 예시

회사별로 실제 무엇을 묻는지: 확인된 것과 아닌 것

“토스 시스템 디자인 면접”, “쿠팡 시스템 디자인 면접”을 검색하면 후기가 많이 나오지만, 후기는 개인의 경험이고 시기마다 달라집니다. 이 글은 2026년 11월 13일 기준 공식 페이지에서 확인되는 내용만 사실로 적습니다.

• 토스(서버 챕터 FAQ): 코딩테스트는 채용 프로세스에 필요하지 않다고 판단했다고 밝히고, 직무 인터뷰에서 이력서를 바탕으로 프로젝트 경험을 깊이 이야기한다고 설명합니다. 또한 “신규 프로젝트 만들 때 어떤 구조로 서버를 설계하는지”를 파악한다고 적혀 있습니다. 즉 ‘설계 사고’는 확인 대상이지만, 시스템 디자인 면접이라는 별도 형식이 있다고 공식 문서가 밝힌 것은 아닙니다.
• 쿠팡·당근: 이번 조사에서 시스템 디자인 면접 형식이나 질문을 공식적으로 설명한 페이지를 확인하지 못했습니다. 후기 글에 의존하지 말고 채용 공고와 recruiter 안내를 확인하세요.

따라서 특정 회사의 “기출 질문”을 외우는 것보다, 어떤 질문이 와도 쓸 수 있는 틀을 연습하는 쪽이 안전합니다.

시스템 디자인 면접에서 보는 것

• 요구사항 정리: 바로 그리기 시작하지 않고, 기능·비기능 요구사항을 질문으로 좁히는지.
• 규모에 대한 감각: 사용자 수, 요청량, 데이터 크기를 대략적으로 추정하고 설계에 반영하는지.
• 트레이드오프 설명: “이렇게 하면 일관성이 약해지는 대신 응답이 빨라진다”처럼 선택의 이유와 대가를 말하는지.
• 소통: 면접관의 힌트와 반론을 받아 설계를 수정하는지.

연차에 따라 기대 수준이 다릅니다. 신입·주니어는 기본 구성요소(로드밸런서, 캐시, DB, 큐)를 이유와 함께 설명할 수 있으면 충분한 경우가 많고, 시니어는 장애 시나리오와 운영, 비용까지 논의하는 경우가 많습니다. 다만 이는 일반적인 경향이며 회사·직무별로 다릅니다. 기본기 질문은 신입 백엔드 CS 질문 글을 함께 참고하세요.

답변 틀: 40분을 이렇게 쓰세요

1. 요구사항 확인(5분): 핵심 기능 2~3개로 범위를 좁히고, 읽기·쓰기 비율, 지연 시간, 일관성 요구를 묻습니다.
2. 규모 추정(3~5분): DAU, 초당 요청 수, 저장 용량을 대략 계산합니다. 정확한 값이 아니라 자릿수가 중요합니다.
3. API와 데이터 모델(5분): 주요 엔드포인트와 핵심 테이블/컬렉션, 인덱스 기준을 적습니다.
4. 상위 구조(10분): 클라이언트 → 게이트웨이 → 서비스 → 저장소로 큰 그림을 그리고, 각 선택의 이유를 말합니다.
5. 병목과 장애(10분): 어디가 먼저 한계에 닿는지, 캐시·샤딩·비동기 처리·재시도로 어떻게 해결하는지 논의합니다.
6. 정리(5분): 선택한 트레이드오프와 다음에 개선할 점을 요약합니다.

구조화된 틀의 영어 버전은 System design interview framework에서 볼 수 있습니다. 이 글의 예시는 국내 서비스에 맞춰 새로 정리했습니다.

예시 1: 메신저 설계(일러스트 예시)

아래는 면접 답변을 어떻게 풀어 갈 수 있는지 보여주는 예시이며, 특정 회사의 실제 질문이나 모범 답안이 아닙니다.

• 요구사항: 1:1 대화와 그룹 대화, 읽음 표시, 오프라인 푸시. 메시지는 유실되면 안 되고, 순서는 대화방 안에서 보장.
• 연결: 실시간 전달은 WebSocket 같은 지속 연결, 오프라인 사용자는 푸시 알림으로 보완.
• 저장: 대화방 ID 기준으로 메시지를 파티셔닝하고, 방 안에서 증가하는 시퀀스 번호로 순서를 보장.
• 트레이드오프: 그룹이 커질수록 팬아웃 비용이 늘어납니다. 쓰기 시점에 퍼뜨릴지(write fan-out), 읽을 때 가져올지 선택하고 이유를 말합니다.
• 장애: 서버가 재시작되어도 클라이언트가 마지막 시퀀스 번호부터 다시 요청해 누락분을 채우는 방식을 제안할 수 있습니다.

예시 2: 결제 설계(일러스트 예시)

핀테크 직무에서 자주 다루는 주제로 정리한 예시이고, 마찬가지로 특정 회사의 실제 질문이 아닙니다.

• 중복 결제 방지: 같은 요청이 재전송되어도 한 번만 처리되도록 요청마다 멱등 키(idempotency key)를 두고, 처리 결과를 저장해 재요청에는 같은 결과를 돌려줍니다.
• 정합성: 결제 상태(요청, 승인, 실패, 취소)를 상태 머신으로 정의하고, 허용되는 전이만 코드와 DB 제약으로 보장합니다.
• 외부 연동 실패: PG사 응답이 지연되거나 유실될 때를 대비해 조회 API로 상태를 대조하고, 불일치는 정산 배치에서 복구합니다.
• 이중 기록: 원장(ledger)은 수정하지 않고 추가만 하는 방식으로 설계하면 감사와 복구가 쉬워집니다.

이 예시에서 면접관이 보고 싶은 것은 용어가 아니라 “왜 그렇게 하는가”입니다. 한 번 막힌 지점에서 트레이드오프를 말로 풀어내는 연습이 필요합니다.

흔한 실수

• 요구사항을 묻지 않고 바로 아키텍처를 그린다.
• 모든 곳에 Kafka·샤딩·마이크로서비스를 넣는다. 규모가 작다면 단순한 구성이 더 좋은 답입니다.
• 질문을 받으면 침묵한다. 생각하는 과정을 소리 내어 말하세요.
• 숫자 없이 “많은 트래픽”이라고만 말한다.
• 한 가지 선택지만 제시한다. 대안과 비교해야 트레이드오프가 드러납니다.

준비 방법

1. 일주일에 하나씩, 메신저·단축 URL·알림·결제·피드 같은 주제를 40분 안에 말로 설계해 봅니다.
2. 설계를 녹음하거나 친구에게 설명하고, 막힌 곳을 기록합니다.
3. 자신이 만든 서비스의 구조를 “왜 이렇게 했는가”까지 설명할 수 있게 정리합니다. 토스 FAQ가 밝히듯 경험 기반 질문이 많기 때문입니다.
4. 면접 직전에는 새 주제를 공부하지 말고 틀(요구사항 → 추정 → API → 구조 → 병목 → 정리)을 복습합니다.

관련 글: 페어 프로그래밍 면접, 라이브 코딩 면접 도움.

면접 중 막힐 때 도구를 쓴다면

Interview Copilot 같은 오버레이 도구는 통화 소리를 인식해 실시간으로 답변 힌트를 보여줍니다. 무료 플랜은 카드 없이 시작할 수 있습니다(자세히). 다만 면접에서 AI 도구를 써도 되는지는 회사와 전형마다 다릅니다. 채용 공고와 안내문을 확인하고, 불확실하면 면접 전에 recruiter에게 허용 여부를 먼저 물어보세요.

화면 공유 시 보이는지는 OS에 따라 다릅니다. macOS와 Windows에서는 창이 화면 캡처에서 제외되도록 OS에 요청하지만, Linux에서는 창이 보입니다. 결과는 사용하는 화면 공유 앱에 따라 달라지므로, 사적인 공유 테스트로 먼저 확인해야 합니다(자세히).

출처

• 토스 서버 챕터 FAQ — 코딩테스트 미진행 이유, 채용 프로세스, 직무 인터뷰에서 묻는 내용

2026년 11월 13일 확인. 쿠팡·당근은 공식 자료를 확인하지 못해 사실로 적지 않았습니다.

이 상황에서 앱이 돕는 방식

관련 글

다음 글