왜 시스템 디자인 인터뷰는 코딩 테스트와 다른가

코딩 테스트를 잘 보는 사람이 여기서 무너지는 이유

알고리즘 문제는 정답이 있습니다. 배열을 정렬하고, 최단 경로를 찾고, 통과하는 테스트 케이스의 개수로 실력이 증명됩니다. 시스템 디자인 인터뷰는 이 감각을 그대로 들고 오면 첫 5분 만에 어긋납니다. "채팅 시스템을 설계하세요" 라는 질문에는 컴파일러가 채점해 줄 정답이 없습니다. 면접관도 정답을 갖고 있지 않습니다. 그들이 보고 싶은 건 당신이 무엇을 먼저 묻고, 무엇을 나중으로 미루고, 왜 그렇게 결정했는지입니다.

저는 이 형식이 불공평하다고 생각하는 사람들을 많이 봤습니다. 어느 정도는 맞는 말입니다. 같은 답을 해도 면접관에 따라 점수가 갈립니다. 하지만 그 불공평함을 걷어내고 나면, 이 형식이 실제로 측정하려는 것은 실무와 꽤 가깝습니다. 실무에서도 "정답"은 없고, 트래픽·비용·팀 구성·마감일이라는 제약 안에서 그나마 나은 선택을 하는 일의 연속이니까요.

코드 자체는 거의 채점 대상이 아니다

다음은 URL 단축기의 핵심 로직을 가장 단순하게 구현한 코드입니다.

import random
import string

store = {}

def shorten(long_url: str) -> str:
    code = "".join(random.choices(string.ascii_letters, k=7))
    while code in store:
        code = "".join(random.choices(string.ascii_letters, k=7))
    store[code] = long_url
    return code

def resolve(code: str) -> str | None:
    return store.get(code)

코딩 테스트였다면 이 정도로 합격점입니다. 시스템 디자인 인터뷰에서는 정반대입니다. 이 코드는 화이트보드에 적을 필요조차 없을 만큼 자명한 부분으로 취급됩니다. 면접관이 실제로 궁금한 건 store 가 죽으면 어떻게 되는지, 서버가 10대로 늘어나면 code in store 중복 검사를 누가 책임지는지, 초당 요청이 10만 건이 되면 이 딕셔너리 하나로 버틸 수 있는지입니다. 즉 함수 안이 아니라 함수 바깥이 시험 범위입니다.

이 차이를 모르고 들어가면 화이트보드 앞에서 이 코드와 비슷한 것을 정교하게 다듬는 데 20분을 씁니다. 그리고 정작 캐시 계층이나 데이터 파티셔닝 이야기는 꺼내보지도 못한 채 시간이 끝납니다. 실제로 떨어지는 답변의 상당수는 "틀린 설계"가 아니라 "시간 배분을 잘못한 설계"입니다.

정답이 없다는 것과 아무거나 된다는 것은 다르다

"정답이 없다"는 말이 "무엇을 말해도 괜찮다"는 뜻은 아닙니다. 캐시를 어디에 둘지는 논쟁의 여지가 있지만, 캐시 무효화 전략을 아예 언급하지 않고 넘어가는 건 논쟁의 여지가 없는 감점 사유입니다. 좋은 답변과 나쁜 답변을 가르는 건 결론이 아니라 결론에 이르는 과정에서 어떤 질문을 스스로에게 던졌는가입니다.

flowchart LR
  A["모호한 요구사항"] --> B["질문으로 범위를 좁힌다"]
  B --> C["트래픽·데이터 규모를 추정한다"]
  C --> D["구성요소 단위로 설계한다"]
  D --> E["병목을 짚고 트레이드오프를 말한다"]

이 다섯 단계 중 앞의 두 단계를 건너뛰는 지원자가 압도적으로 많습니다. 문제를 듣자마자 로드밸런서와 캐시부터 그리기 시작하는 겁니다. 다음 챕터에서 다루는 요구사항 정리와 추정을 왜 가장 먼저 해야 하는지는, 이 순서를 어겼을 때 뒤에서 반드시 대가를 치르기 때문입니다. 트래픽 규모를 모른 채로 "Redis를 캐시로 씁니다"라고 말하는 건, 사실 아무 말도 안 한 것과 크게 다르지 않습니다.

이 책이 다루는 범위

이 책은 이론서가 아닙니다. 캐싱 이론이나 CAP 정리를 논문 수준으로 파고들지 않습니다. 대신 인터뷰 40~45분 안에 실제로 꺼내 쓸 수 있는 만큼의 깊이로, 자주 나오는 개념과 자주 나오는 문제 네 가지(URL 단축기, Rate Limiter, 채팅 시스템, 뉴스피드)를 끝까지 풀어봅니다. 개념 챕터를 다 읽은 뒤에는 실제로 시간을 재고 문제를 풀어보길 권합니다. 아는 것과 40분 안에 말로 풀어내는 것 사이에는 생각보다 큰 간극이 있습니다.