실전 화이트보드 면접 가이드 (Whiteboard Interview Guide)

목차

이 문서를 왜 보나

시스템 디자인 문서를 여러 개 읽고도 실제 화이트보드 면접에서 막히는 이유는
“무엇을 아는가”와 “어떤 순서로 설명하는가”가 다른 문제이기 때문입니다.

이 문서는 정답 아키텍처 하나를 외우는 문서가 아니라,
면접 자리에서 문제를 받았을 때 어떤 순서로 구조를 잡고 설명을 전개할지를 보여주는 가이드입니다.

기본 원리와 답변 순서는 시스템 디자인 기초 (System Design Basics),
저장 전략과 API 감각은 데이터베이스 설계 (Database Design), API 설계 (API Design) 와 같이 보면 연결이 좋습니다.
실전 문제에 바로 적용해 보려면 URL 단축기 시스템 설계 예시 (URL Shortener System Design Example), 뉴스 피드 시스템 설계 예시 (News Feed System Design Example), 검색 시스템 설계 예시 (Search System Design Example) 문서를 이어서 보면 좋습니다.

화이트보드 면접에서 보는 것

화이트보드 면접은 정답 그림을 맞히는 시험이 아니라,
제한된 시간 안에 문제를 구조화하고 의사결정을 설명하는 과정을 보는 면접입니다.

면접관이 보려는 포인트는 보통 다음과 같습니다.

  • 범위 통제: 무엇을 이번 답변에 넣고 무엇을 뺄지 정하는가
  • 우선순위 판단: 성능, 일관성, 비용, 개발 속도 중 무엇을 먼저 볼지 설명하는가
  • 구조화 능력: 컴포넌트, 데이터 흐름, 병목, 장애 지점을 구분해 말하는가
  • 트레이드오프 감각: 장점만이 아니라 대가와 한계를 같이 말하는가
  • 후속 질문 대응: 꼬리질문이 나와도 기존 구조를 확장해서 답하는가

화이트보드 문제를 받으면 먼저 할 일

문제를 받자마자 아키텍처 박스를 그리기 시작하면 오히려 답변이 흔들립니다.

보통은 다음 순서가 안전합니다.

  1. 문제 범위를 다시 말한다
  2. 기능적 요구사항과 비기능적 요구사항을 확인한다
  3. 대략적 규모를 짧게 추정한다
  4. 고수준 박스를 먼저 그린다
  5. 핵심 데이터 흐름을 설명한다
  6. 병목과 트레이드오프를 짚는다
  7. 꼬리질문에 따라 한 부분을 깊게 판다

좋은 답변은 처음부터 정교한 그림을 그리는 답변이 아니라
문제를 구조화해서 설명 범위를 통제하는 답변입니다.

요구사항과 범위 고정

화이트보드 면접에서 가장 먼저 해야 할 것은
문제를 작게 다시 정의하는 일입니다.

예를 들어 다음 축을 빠르게 확인하는 편이 좋습니다.

  • 기능적 요구사항: 사용자가 반드시 할 수 있어야 하는 핵심 동작
  • 비기능적 요구사항: latency, availability, consistency, scale 목표
  • 범위 밖 항목: 통계, 관리자 기능, 고급 랭킹, 배치 처리처럼 후속 질문으로 넘길 것
  • 핵심 제약: 읽기 중심인지, 쓰기 중심인지, 강한 일관성이 필요한지

좋은 답변은 “기능은 간단합니다”로 끝나지 않고,
무엇을 이번 범위에 넣고 무엇을 뺄지 먼저 정한다는 점이 중요합니다.

면접관이 바로 그림을 그리라고 해도 한 문장 정도는 다시 확인하는 편이 좋습니다.

규모 추정과 병목 예측

숫자는 정답이 아니지만, 설계 선택을 설명하기 위해 필요합니다.

빠르게 잡을 대표 항목은 다음과 같습니다.

  • QPS / TPS
  • 읽기:쓰기 비율
  • 저장 용량 증가 속도
  • 피크 트래픽 배수
  • latency 목표

여기서 바로 설계 판단으로 연결해야 합니다.

  • 읽기가 많으면 캐시와 읽기 최적화 구조를 먼저 검토
  • 쓰기가 많으면 큐, 파티셔닝, 병렬 처리 경계를 먼저 검토
  • 강한 일관성이 중요하면 비동기화보다 트랜잭션 경계를 먼저 설명

즉, 숫자를 길게 계산하는 것보다
왜 캐시, 복제, 키 생성 이야기를 꺼내는지 근거를 만드는 것이 핵심입니다.

화이트보드에 박스를 그리는 순서

화이트보드에는 처음부터 세부 저장소를 다 그리지 말고, 큰 박스부터 그리는 편이 좋습니다.

권장 순서는 보통 다음과 같습니다.

  1. Client
  2. 진입 계층
  3. Application / Core Service
  4. Cache / Search / Queue 같은 보조 계층
  5. Primary Data Store
  6. 필요하면 Async Worker / Analytics / External Service

아주 단순한 그림은 이런 수준이면 충분합니다.

Client
  -> Load Balancer / API Gateway
    -> Application Service
      -> Cache
      -> Primary DB
      -> Async Worker (optional)

그 다음 각 박스의 역할을 짧게 설명합니다.

  • API / Application: 핵심 비즈니스 로직 처리
  • Cache: 읽기 지연 완화
  • DB / Storage: 원본 사실 저장
  • Worker: 비동기 작업과 부가 처리 담당

좋은 답변은 그림의 복잡함보다
각 박스가 왜 필요한지와 요청 흐름이 자연스러운지가 중요합니다.

트레이드오프 말하는 방법

화이트보드 답변은 구조만 말하면 약합니다.
각 선택이 무엇을 얻고 무엇을 포기하는지 같이 말해야 답변이 단단해집니다.

예를 들어 다음 축을 같이 말하는 편이 좋습니다.

  • 초기 단순성 vs 장기 확장성
  • 강한 일관성 vs 처리량
  • 낮은 latency vs 구현 복잡도
  • 동기 처리 vs 비동기 처리

좋은 답변은
지금 선택과 나중 확장 방향을 같이 말하는 답변입니다.

면접관이 자주 던지는 꼬리질문

화이트보드 문제는 보통 기본 구조를 설명한 뒤 꼬리질문으로 깊이를 봅니다.

대표 예시는 다음과 같습니다.

  • 이 병목이 더 커지면 다음에 무엇을 바꿀 것인가
  • 장애가 나면 어떤 기능을 줄이고 무엇을 지킬 것인가
  • 강한 일관성이 정말 필요한가
  • 왜 이 저장소를 골랐는가
  • 비동기 처리를 넣으면 어떤 대가가 생기는가

좋은 답변은 꼬리질문마다 새 아키텍처를 갈아엎는 것이 아니라,
기존 구조에서 어느 부분을 확장하는지를 이어서 설명하는 것입니다.

화이트보드 답변 템플릿

실전에서는 아래 템플릿대로 말하면 흔들리지 않습니다.

  1. 먼저 요구사항부터 짧게 정리하겠습니다
  2. 읽기/쓰기 비율과 대략적 규모를 이 정도로 가정하겠습니다
  3. 고수준 구조는 client - entry - app - storage 중심으로 먼저 두겠습니다
  4. 핵심 데이터 흐름과 병목 지점을 설명하겠습니다
  5. 이 문제에서 가장 중요한 트레이드오프를 짚겠습니다
  6. 초기 설계와 이후 확장 방향을 나눠 말씀드리겠습니다
  7. 그 다음 꼬리질문에 따라 저장소, 캐시, 비동기 처리 쪽을 더 깊게 보겠습니다

이 템플릿의 장점은
면접관이 중간에 끊어도 답변 구조가 이미 잡혀 있다는 점입니다.

자주 하는 실수

  • 처음부터 샤딩, Kafka, 마이크로서비스를 한꺼번에 꺼냄
  • 요구사항 정리 없이 기술 스택부터 말함
  • 그림은 복잡한데 데이터 흐름 설명이 없음
  • 정상 경로만 설명하고 병목과 장애를 말하지 않음
  • 꼬리질문이 나올 때마다 기존 답변과 충돌하는 새 구조를 말함

좋은 답변은 복잡한 답변이 아니라
점진적으로 깊이를 더해도 앞뒤가 맞는 답변입니다.

같이 볼 예제

가이드를 먼저 읽고 예제를 보면, 같은 답변 프레임이 문제별로 어떻게 달라지는지 비교하기 쉽습니다.

면접 포인트

  • 화이트보드 면접은 정답 아키텍처보다 설명 순서와 우선순위 판단을 본다.
  • 요구사항 확인, 규모 추정, 고수준 박스, 데이터 흐름, 병목, 트레이드오프 순서가 가장 안정적이다.
  • 예시 문제는 단순할수록 좋고, 단순한 문제일수록 꼬리질문 대응이 중요하다.
  • 좋은 답변은 “지금 선택”과 “나중 확장 방향”을 함께 말한다.
  • 꼬리질문은 아키텍처를 뒤엎는 답변보다 기존 구조를 확장하는 방식으로 받는 편이 자연스럽다.

참고 자료