Chapter 03

시스템 설계 면접 공략법

4단계 접근법 — 문제 이해 및 설계 범위 확정, 개략적 설계안 제시 및 동의, 상세 설계, 마무리. 면접에서 해야 할 일과 하지 말아야 할 일.

이 면접은 무엇을 보는가

시스템 설계 면접(System Design Interview)은 후보자에게 모호한 문제를 던지고 "45분 동안 어떻게 사고하는지"를 본다. 정답이 하나로 떨어지지 않고, 면접관도 후보자도 처음 보는 문제처럼 같이 탐색해가는 형식이다.

실제로 면접관이 평가하는 항목은 코드가 아니라:

모호함을 다루는 능력 — 모르면 묻고, 추측이면 명시.
트레이드오프 의식 — "이게 정답"이 아니라 "이 상황엔 이게 더 낫다"라는 사고.
협업·소통 — 면접관을 동료로 보고 같이 푸는가.
기술 폭과 깊이 — 큰 그림을 그리되, 한 컴포넌트는 깊이 들어갈 수 있는가.

그래서 이 챕터의 본질은 "답을 외우는 게 아니라, 모호한 문제를 체계적으로 푸는 절차를 익히는 것"이다. 그 절차가 바로 4단계 접근법.

4단계 접근법 — 한눈에

시스템 설계 면접은 대략 45분. 시간을 다음 4단계로 나눠 쓴다. 단계마다 목표·해야 할 일·흔한 실수가 다르다. 막대를 클릭해보세요.

45분 면접 타임라인

단계를 클릭하면 상세를 볼 수 있습니다. 각 단계의 시간 비중이 막대 길이로 표현됩니다.

STEP 1 · 3~10분

문제 이해 및 설계 범위 확정

🎯 목표: 무엇을 만들지 구체화. 가정 대신 질문으로 정답 방향을 좁힌다.

✅ 해야 할 일

어떤 기능을 우선 만들 것인가?
사용자 규모는? (DAU, QPS)
1년 후 예상 규모는?
기술 스택 — 활용 가능한 기존 서비스가 있는가?

⚠ 흔한 실수

묻지 않고 바로 설계 시작
임의로 가정해놓고 면접관 의도와 어긋난 방향으로 진행
기능 요구사항만 묻고 비기능(QPS·지연·가용성)은 빠뜨림

중요한 사실: 이 시간 비중은 절대치가 아니다. 면접관이 "1단계 더 길게 가요"라고 하면 따라가야 한다. 핵심은 "단계를 건너뛰지 않는 것"이다. 특히 1단계와 4단계가 실력자와 보통의 차이를 만든다.

1단계: 문제 이해 및 설계 범위 확정 (3~10분)

면접관이 "트위터 같은 SNS 만들어보세요"라고 하면, 가장 위험한 행동은 바로 박스를 그리기 시작하는 것이다. "트위터"는 천 가지 다른 시스템이 될 수 있다 — 글쓰기 위주? 검색 위주? 알림? DM? 글로벌? 국내? 동영상 포함?

요구사항을 좁히지 않고 그린 설계는 거의 확실히 면접관이 의도한 것과 다르다. 그래서 "올바른 질문을 던져 정답 방향을 좁히는 것"이 1단계의 전부다.

꼭 확인할 4가지 축

① 기능 범위 — 어떤 기능에 집중? 모든 기능을 다 만드는 건 시간상 불가능. 핵심 1~3개에 집중.
② 사용자/트래픽 규모 — DAU 1만 vs 1억은 완전히 다른 시스템. QPS 추정도 여기서 출발.
③ 데이터 특성 — 읽기 위주? 쓰기 위주? 트윗 길이? 저장 기간? 미디어?
④ 기술 제약/자원 — 기존에 쓰는 인프라? 새로 깔 수 있나? 클라우드 어디?

샘플 질문 (트위터 예제)

Q. 핵심 기능은? (트윗 작성, 타임라인, 팔로우, 검색, 알림, DM 중 우선순위)
Q. DAU는 얼마나 가정할까요? (1억으로 가정하시겠어요?)
Q. 트윗에 미디어(이미지/영상) 포함되나요?
Q. 글로벌 서비스인가요, 특정 지역인가요?
Q. 트윗은 영구 보관인가요, 일정 기간 후 삭제인가요?
Q. 1년 후 트래픽이 N배 된다고 가정해도 될까요?

답이 정해진 게 아니라 면접관이 답해주는 대로 가정이 결정된다. 가정은 메모해두고 다음 단계에서 활용. 추측해서 진행한 가정은 반드시 명시 ("DAU 1억으로 가정하겠습니다, 맞나요?").

2단계: 개략적 설계안 제시 (10~15분)

1단계에서 좁힌 요구사항을 바탕으로 박스-화살표 다이어그램으로 큰 그림을 그린다. 이 단계의 핵심은 "그리는 것"이 아니라 "동의를 받는 것"이다.

그려야 할 핵심 컴포넌트

클라이언트 (모바일 앱, 웹)
로드 밸런서
API 서버 (무상태)
데이터베이스 (RDB? NoSQL? 쓰기/읽기 분리?)
캐시 (Redis 등)
CDN (정적 자원, 미디어)
메시지 큐 (비동기 작업, 알림)
외부 의존성 (인증, 결제, 푸시)

back-of-envelope 계산도 함께

DAU 1억 × 사용자당 일평균 트윗 작성 5건 = 5억 건/일 → 약 6,000 QPS. 여기서 평균 QPS가 6,000이면 피크는 약 12,000 QPS. 이런 식으로 큰 단위 숫자를 한두 개 던져두면 면접관이 "이 정도 트래픽 처리할 수 있는 컴포넌트인가?"를 같이 판단할 수 있다.

"이 방향 맞나요?" 질문은 필수

개략 설계 끝나면 반드시 면접관에게 동의를 구한다:

"여기까지 큰 그림인데, 이 방향에 동의하시나요? 어느 컴포넌트를 더 깊게 보면 좋을까요?"

이게 빠지면 면접관 의도와 다른 방향으로 깊이 파다가 시간을 다 쓰는 사고가 발생한다.

3단계: 상세 설계 (10~25분)

가장 시간이 많이 들고, 가장 점수 차이가 크게 벌어지는단계. 면접관이 관심 있는 컴포넌트를 깊이 파고들어 데이터 모델·API· 알고리즘 수준까지 내려간다.

어디를 깊게 팔지는 면접관과 정한다

예: "타임라인 생성 로직", "알림 푸시 시스템", "데이터 샤딩 전략" 등. 후보자가 마음대로 정하지 말고 "이 중 어디부터 보면 좋을까요?"라고 물어 면접관 의도에 맞춘다.

한 컴포넌트를 팔 때 다루는 것들

데이터 모델 — 테이블 스키마, 키-값 구조, 인덱스
API 엔드포인트 — 메서드, 파라미터, 응답 형식
알고리즘·자료구조 — 어떤 자료구조? 시간 복잡도?
병목·확장 — 어디서 병목? 샤딩? 캐시?
장애 시나리오 — 노드 다운? 일관성?
대안 — 다른 접근도 있다는 걸 보여줌

대안 제시는 강력한 시그널

"방법 A는 X 장점, Y 단점. 방법 B는 그 반대. 우리 시스템 특성상 X가 중요하니 A로 가겠습니다." — 이 패턴이 시니어와 주니어를 가른다. 한 가지 해법만 던지면 "다른 거 모르나?"로 의심받는다.

4단계: 마무리 (3~5분)

시간 다 쓰고 "끝났습니다"만 말하면 인상이 약하다. 마지막 3~5분으로 깔끔한 마침표를 찍는다.

마무리에서 할 것

병목 짚기 — "이 시스템의 약점은 X입니다. 트래픽이 더 커지면 Y가 먼저 터질 것 같아요."
개선 제안 — "다음 단계로는 Z를 도입하면 좋겠습니다."
운영 측면 한 마디 — 모니터링·로깅·알림·배포·롤백 전략 같은 시스템 라이프사이클.
1~2분 전체 요약 — "정리하면: 1단계 가정 X, 2단계 큰 그림 Y, 3단계 핵심 Z. 한계는 W."

단점·한계를 숨기지 않는 게 핵심. 오히려 "내 설계의 약점을 내가 안다"는 게 큰 신호다.

해야 할 것 / 하지 말아야 할 것

✅ 해야 할 것

항상 명료화 질문을 던진다 — 가정 없이 추측하지 않는다. 추측이면 그렇게 말한다.
요구사항을 이해했는지 다시 확인 — 1단계 끝에 "이렇게 정리됩니다, 맞죠?" 한 번 물어본다.
큰 그림 → 깊이 순서로 진행 — 박스부터 그리고, 동의 받은 후 깊게.
여러 접근법 제시 — "A 또는 B인데, 우리 상황엔..." 의 패턴.
면접관과 계속 소통 — 그리면서 설명, 막히면 같이 생각.
가정과 트레이드오프를 명시 — 모든 결정엔 비용이 있음을 보여준다.
면접관의 힌트를 잡는다 — "이 부분은요?"라고 물으면 거기에 답이 숨어있다.
막히면 빨리 인정하고 다른 길 — 모르는 척 우기지 않는다.

❌ 하지 말아야 할 것

준비 없이 임함 — 시스템 설계 면접은 즉흥 토크쇼가 아니다. 패턴 연습 필요.
요구사항 안 묻고 바로 설계 — 1단계 건너뛰면 90% 확률로 빗나간다.
혼자 설계 — 면접관 무시 — 보기 싫은 독백이 된다.
한 가지 해법만 고집 — "이게 정답"이라고 박는 건 위험 신호.
침묵 — 생각 중이면 "잠깐 정리해보겠습니다" 라고 말하라. 머릿속을 보여줘야 한다.
면접 끝났다고 마음대로 끝내기 — 4단계 마무리를 안 하면 인상이 약하다.
모르는 걸 아는 척 — 거짓말은 쉽게 들킨다. "써본 적 없지만 X 같은 도구로 해결할 수 있을 것 같아요"가 낫다.
시간 분배 실패 — 1, 2단계에 너무 오래 머물러 3, 4단계를 못 끝냄.

자주 나오는 면접 문제 유형

실제 면접에서 자주 등장하는 문제 유형을 미리 익혀두면 패턴이 보인다.

유형	대표 문제	핵심 트레이드오프
피드/타임라인	트위터, 인스타 피드	읽기 vs 쓰기 fan-out
채팅/메시징	WhatsApp, 슬랙	실시간성 vs 일관성
알림 시스템	푸시, 이메일	처리량 vs 지연
검색/추천	유튜브 검색	인덱스 신선도 vs 비용
스토리지	구글 드라이브, S3	일관성 vs 가용성, 중복 제거
실시간 분산	웹 크롤러, 분산 ID	중복 처리, 순서 보장
처리율 제한	Rate Limiter	정확도 vs 메모리, 분산 동기화

5~9장 그리고 그 이후 챕터들이 정확히 이런 유형들을 다룬다. 챕터별 패턴을 익히면 어떤 문제가 나와도 출발점이 잡힌다.

마무리 — 이 챕터의 진짜 가르침

시스템 설계 면접에서 점수를 내는 사람은 "많이 아는 사람"이 아니라 "모호한 문제를 체계적으로 푸는 사람"이다. 많이 알아도 1단계 건너뛰고 자기 멋대로 가면 떨어지고, 적게 알아도 단계를 지키며 면접관과 함께 가면 합격한다.

그래서 이 챕터에서 가져갈 한 줄은:

4단계는 정답을 만드는 절차가 아니라, 모르는 사람과 함께 정답을 찾아가는 대화의 형식이다.

나머지 챕터들이 이 절차에 채워 넣을 "재료"라면, 이 챕터는 그 재료를 담을 "그릇"이다. 그릇 없이 재료만 잔뜩 쌓아도 면접에선 못 쓴다.