시스템 디자인 면접은 "설계를 완성하라"는 시험이 아니라 "판단 과정을 보여달라"는 요청이다. 45~60분 안에 정답 아키텍처를 그리는 게 목표가 아니라, 요구사항을 정리하고 규모를 추정하고 트레이드오프를 말로 꺼내는 흐름 자체가 평가 대상이다. 이 흐름을 못 잡으면 설계가 정교해도 신호가 약하게 읽힌다.

시스템 디자인 면접은 도대체 뭘 확인하려는 자리일까?

결론부터 말하면, 이 면접은 문제 해결 순서와 트레이드오프 설명 능력을 확인하는 자리다. 코딩테스트가 구현력을 보고 경험 면접이 협업 패턴을 본다면, 시스템 디자인은 애매한 요구를 정리해서 구조로 옮기는 판단력을 본다.

  • 시스템 디자인은 정답 하나가 아니라 요구사항 정리→규모 추정→구조→트레이드오프로 이어지는 전개 방식을 평가한다.
  • 실전 인터뷰는 보통 45~60분으로 잡히고, 이 시간 배분 자체가 평가 항목이다.
  • 해피패스만 설명하면 신호가 약하고, 장애 모드·병목·일관성-가용성 절충까지 언급해야 신호가 강해진다.
  • 미들 이상 연차에서는 코딩 정확도보다 이 설명력의 비중이 빠르게 커진다.

나도 예전엔 "설계도를 얼마나 크고 정교하게 그리느냐"가 핵심이라고 오해했다. 실제로 면접장에서 겪어보니, 화이트보드에 마이크로서비스 열 개를 늘어놓고도 요구사항 확인을 건너뛴 지원자보다, 캐시-DB 두 컴포넌트만 그리고 왜 그 둘을 골랐는지 설명한 지원자의 신호가 더 강하게 남는 경우가 많았다. 도구를 많이 아는 것과 판단 근거를 말하는 것은 다른 능력이다.

왜 요구사항부터 정리하지 않으면 이후 45분이 꼬일까?

요구사항을 먼저 확정하지 않으면 뒤에 그리는 구조 전체가 흔들리기 때문이다. "URL 단축기를 설계하라"는 문제도 읽기:쓰기 비율이 100:1인지 10:1인지에 따라 캐시 전략과 DB 선택이 완전히 달라진다. 2026년 기준 최신 가이드들도 요구사항 확인을 먼저 한 뒤 상위 구조를 그리는 흐름을 공통으로 권장한다.

실무에서 겪어본 사례를 대면, 사내 알림 시스템 설계 리뷰에서 "실시간이어야 하나, 몇 초 지연은 허용되나"를 먼저 묻지 않고 바로 큐 구조를 제안했다가, 나중에 "사실 1분 지연도 괜찮다"는 답이 나와 설계를 절반 갈아엎은 적이 있다. 면접에서도 똑같다. 기능 요구사항(무엇을 지원하나)과 비기능 요구사항(지연시간, 가용성, 데이터 일관성 수준)을 각각 1~2분 안에 확인하고 넘어가는 습관이, 이후 구조 설명의 정합성을 결정한다.

규모 추정(QPS·저장공간)은 왜 답을 바꿔놓을까?

규모 추정을 숫자로 해보면 컴포넌트 선택 자체가 달라지기 때문이다. 일일 활성 사용자 1천만 명에 초당 요청 5천 건 수준이라면 단일 DB로도 버틸 여지가 있지만, 초당 50만 건 수준이라면 샤딩이나 캐시 레이어를 처음부터 구조에 넣어야 한다. 이 추정 과정 자체가 "숫자 기반으로 결정하는 사람"이라는 신호를 준다.

여기서 흔히 나오는 함정은 숫자를 정밀하게 맞추려고 시간을 쓰는 것이다. 면접관이 보고 싶은 건 정확한 QPS 값이 아니라 "저장공간 추정이 캐시 히트율 논의로 이어지고, 그게 다시 데이터 모델 선택으로 이어지는" 연결 고리다. 숫자는 대략적인 자릿수만 맞아도 되고, 그 숫자를 근거로 다음 결정을 어떻게 내렸는지가 더 중요하게 읽힌다는 점을 실전에서 여러 번 확인했다.

병목과 트레이드오프를 말로 꺼내야 하는 이유는 뭘까?

해피패스만 설명하면 "이 사람이 장애 상황을 겪어본 적이 있나"를 판단할 근거가 사라지기 때문이다. 시스템 디자인 면접의 핵심 신호는 정상 동작 설명이 아니라 실패 모드 논의에 있다고 정리된다. 단일 장애점은 어디인지, 캐시가 죽으면 무슨 일이 생기는지, 강한 일관성을 포기하면 무엇을 얻는지를 구체적으로 짚어야 한다.

트레이드오프를 말로 꺼내는 연습은 생각보다 어렵다. "이 부분은 CAP 정리에서 일관성을 포기하고 가용성을 택했다"처럼 이유가 있는 절충을 말하는 것과, 그냥 "이건 나중에 개선하면 됩니다"라고 얼버무리는 것은 면접관 입장에서 완전히 다른 신호로 읽힌다. 전자는 구조적 사고, 후자는 회피로 읽히기 쉽다.

"정답 하나를 못 찾으면 떨어진다"는 말, 실제로 맞을까?

이 통념은 과장돼 있다. 시스템 디자인은 단일 정답이 있는 시험이 아니라 설명 순서와 의사결정 근거를 보는 절차로 정리된다. 같은 문제에 대해 완전히 다른 두 구조를 제시해도, 각각의 선택 이유와 트레이드오프를 설득력 있게 설명하면 둘 다 합격 신호를 줄 수 있다.

반대로 실제 동작은 이렇다. 모호한 요구를 정리하지 않고 바로 구조를 그리거나, 병목 질문에 "그런 상황은 없을 것 같다"고 답하는 경우가 감점 신호로 이어진다. 즉 "어떤 구조를 골랐나"보다 "고르는 과정에서 무엇을 확인했고 무엇을 포기했나"가 실제 평가축에 가깝다. 이 차이를 모르고 정답 암기식으로 준비하면, 문제 유형이 조금만 바뀌어도 응용이 안 되는 경우를 여러 번 봤다.

연차별로 시스템 디자인 준비 비중을 어떻게 나눠야 할까?

신입·주니어는 코딩테스트와 경험 정리에 우선순위를 두고, 시스템 디자인은 기본 개념(캐시, 로드밸런서, DB 복제 정도) 수준으로 준비하는 편이 효율적이라고 정리된다. 미들 이상으로 갈수록 시스템 디자인 비중이 빠르게 커지고, 코딩 정확도와 함께 트레이드오프 설명 능력이 핵심 평가축이 된다.

적합한 준비 방식은 문제 수를 늘리는 것보다, 3~4개 유형(읽기 위주 서비스, 쓰기 위주 서비스, 실시간 메시징, 검색/추천)을 깊게 반복하며 매번 요구사항-규모추정-구조-트레이드오프 순서를 입으로 말해보는 연습이다. 반대로 부적합한 방식은 유명 아키텍처 다이어그램을 암기해서 그대로 재현하는 것이다. 면접 문제가 조금만 변형돼도 암기한 구조가 안 맞는 경우가 많고, 이때 "왜 이 컴포넌트를 골랐나"라는 꼬리질문에서 신호가 급격히 약해진다.

핵심 정리

  • 시스템 디자인 면접은 정답 하나를 찾는 시험이 아니라 요구사항 정리·규모 추정·구조·트레이드오프로 이어지는 판단 과정을 보는 절차다.
  • 실전은 보통 45~60분 구조이며, 요구사항 확인을 앞에 배치하는 흐름이 이후 설명 전체의 정합성을 결정한다.
  • 규모 추정의 정밀도보다, 추정치가 다음 결정(캐시, 샤딩, 데이터 모델)으로 이어지는 연결 고리가 더 중요한 신호로 읽힌다.
  • 해피패스만 설명하면 신호가 약하고, 단일 장애점·병목·일관성-가용성 절충을 구체적으로 짚어야 신호가 강해진다.
  • 연차가 올라갈수록 시스템 디자인 비중이 커지므로, 준비는 문제 수보다 몇 개 유형을 깊게 반복하는 방식이 효율적이다.