결론부터 말씀드리겠습니다. 시스템 디자인 면접에서 떨어지는 개발자 대부분은 정답을 몰라서 떨어지는 게 아닙니다. 정답이 있다고 믿어서 떨어집니다. 면접관은 여러분이 그린 다이어그램을 정답지와 대조하지 않습니다. 요구사항을 어떻게 좁히는지, 트레이드오프를 어떻게 판단하는지, 그 판단을 어떻게 소리 내어 설명하는지를 봅니다. 완성된 그림이 아니라 그림을 그려가는 과정이 평가 대상입니다. 오늘은 이 면접이 실제로 무엇을 보는지, 그리고 어떻게 접근해야 하는지 이야기해보겠습니다.
시스템 디자인 면접은 정답을 채점하지 않는다
먼저 오해부터 걷어내겠습니다. 많은 지원자가 시스템 디자인 면접을 지식 시험으로 준비합니다. 유명한 서비스의 아키텍처를 통째로 외우고, 카프카와 레디스와 샤딩을 언제 꺼낼지 암기합니다. 그런데 현장의 면접관들이 반복해서 지적하는 실패 원인은 지식 부족이 아닙니다. 요구사항을 확인하지 않고 곧장 아키텍처로 뛰어드는 것, 그리고 왜 그 선택을 했는지 설명하지 못하는 것입니다.
시스템 디자인 면접이 평가하는 것은 크게 세 가지입니다. 모호한 문제에서 요구사항을 좁혀내는 능력, 선택지 사이의 트레이드오프를 따지는 능력, 그리고 그 사고 과정을 상대가 따라올 수 있게 설명하는 능력입니다. 특히 트레이드오프를 분명하게 논하는 것은 시니어 수준을 가르는 가장 강한 신호로 꼽힙니다. 반대로 말하면, 정답처럼 보이는 다이어그램 한 장은 생각보다 점수가 되지 않습니다. (면접관은 여러분이 몇 년 뒤 팀에서 어떻게 판단할 사람인지를 짧은 시간 안에 보려는 것이지, 암기력을 보려는 게 아닙니다.)
정답이 없는 문제를 다루는 두 가지 관점
왜 정답이 없을까요. 오래된 연구 두 가지가 답을 줍니다.
첫째, 시스템 설계는 본질적으로 난제입니다. 디자인 이론가 호르스트 리텔과 멜빈 웨버는 1973년에 이런 종류의 문제를 wicked problem이라 불렀습니다. 이들의 정의에 따르면 난제의 해답은 참과 거짓으로 나뉘지 않고 더 낫거나 더 나쁠 뿐이며, 언제 다 풀렸다고 말할 명확한 종료 기준도 없습니다. 시스템 설계가 정확히 이렇습니다. 초당 백 건을 처리하는 시스템과 백만 건을 처리하는 시스템의 답이 다르고, 읽기가 많은 서비스와 쓰기가 많은 서비스의 답도 다릅니다. 맥락이 바뀌면 정답도 바뀝니다. 면접관이 도중에 트래픽이 열 배로 늘면 어떻게 하겠냐고 묻는 이유가 여기 있습니다. 조건을 바꿔 여러분의 설계가 무너지는지, 아니면 트레이드오프를 다시 계산하는지를 보는 것입니다.
둘째, 경험 많은 개발자는 주니어보다 더 많이 계산하는 게 아니라 더 잘 알아봅니다. 인지심리학자 윌리엄 체이스와 허버트 사이먼은 1973년 체스 연구에서 흥미로운 사실을 발견했습니다. 체스 마스터는 실제 대국의 판을 5초만 보고도 거의 완벽하게 복기했지만, 말을 무작위로 흩어놓은 판에서는 초보자와 별 차이가 없었습니다. 고수의 힘은 더 빠른 계산이 아니라, 의미 있는 패턴을 덩어리로 알아보는 데서 나온다는 뜻입니다. 시스템 설계도 같습니다. 노련한 엔지니어는 읽기 위주에 일관성 요구가 낮은 문제를 보면 캐시와 복제로 풀리는 익숙한 모양으로 읽습니다. 면접이 확인하려는 것도 여러분이 문제를 어떤 익숙한 모양으로 분해하는가입니다.
면접장에서 실제로 해야 할 네 가지
그러면 어떻게 접근해야 할까요. 알렉스 슈가 정리한 시스템 디자인 면접 프레임워크를 실무 감각으로 다시 풀면 네 단계입니다.
첫째, 요구사항부터 좁힙니다. 문제를 받자마자 그리기 시작하지 마세요. 사용자 규모, 읽기와 쓰기 비율, 지연 허용치, 일관성 요구 수준을 먼저 묻습니다. 이 질문들이 이후의 모든 선택을 결정합니다. 요구사항을 건너뛰고 그린 설계는 대개 엉뚱한 문제를 푼 설계가 됩니다.
둘째, 큰 그림을 먼저 합의합니다. 세부로 들어가기 전에 주요 컴포넌트와 데이터 흐름을 스케치하고 면접관의 동의를 구합니다. 이것은 실제 설계 리뷰가 흘러가는 방식과 같습니다. 혼자 완성해 내미는 게 아니라 대화하며 맞춰갑니다.
셋째, 트레이드오프를 소리 내어 말합니다. 이게 핵심입니다. 강한 정합성을 택하면 가용성이 떨어지고, 반대로 하면 잠깐의 불일치를 감수해야 한다고, 그리고 이 서비스는 잔액이 중요하니 정합성을 택하겠다고 선택의 비용을 함께 말할 때 판단력이 드러납니다. 마이크로서비스로 쪼갤지 모놀리스로 둘지를 정하는 것도 결국 이 트레이드오프 대화입니다.
넷째, 필요 이상으로 짓지 않습니다. 아는 기술을 다 욱여넣는 것은 감점입니다. 도널드 커누스의 오래된 경고처럼, 섣부른 최적화는 대개 해악입니다. 지금 부하에 맞는 가장 단순한 설계에서 시작해, 병목이 보이는 지점만 키우세요. 기술 부채가 갚는 것이 아니라 관리하는 것이듯, 확장성도 미리 다 사두는 게 아니라 필요할 때 사는 것입니다.
네 단계를 표로 정리하면 이렇습니다.
| 단계 | 흔한 실패 | 노련한 접근 |
|---|---|---|
| 요구사항 | 곧장 아키텍처부터 그림 | 규모·읽쓰기 비율·일관성부터 확인 |
| 큰 그림 | 혼자 완성해 제출 | 대화하며 합의한 뒤 진행 |
| 트레이드오프 | 기술을 나열만 함 | 선택의 비용을 소리 내어 설명 |
| 범위 | 아는 기술을 모두 투입 | 부하에 맞는 최소 설계에서 확장 |
실제로, 정답이 없던 설계 하나
예전에 사용자의 감정 기록을 저장하는 서비스를 설계할 때의 일입니다. 데이터 하나는 정형화된 거래 성격이었고, 다른 하나는 형태가 계속 바뀌는 비정형 기록이었습니다. 처음에는 익숙한 관계형 데이터베이스 하나로 다 담으려 했습니다. 단순하니까요. 그런데 비정형 데이터를 억지로 테이블에 욱여넣자 스키마가 자꾸 흔들렸습니다. 결국 정형 데이터는 관계형에, 비정형 기록은 문서형 데이터베이스에 두고, 둘 사이를 이벤트로 잇는 구조로 갔습니다.
여기서 중요한 건 이 구조가 정답이라서가 아닙니다. 데이터베이스를 둘로 나눈 대가로 운영 복잡성과 정합성 관리라는 비용을 새로 떠안았습니다. 트래픽이 작았다면 관계형 하나가 더 나은 선택이었을 겁니다. (솔직히 첫 판단은 틀렸고, 비용을 치른 뒤에야 다시 계산했습니다.) 시스템 디자인 면접이 보려는 게 바로 이 장면입니다. 어떤 모양을 골랐느냐가 아니라, 무엇을 얻고 무엇을 내주는지 알고 골랐느냐입니다.
결론
시스템 디자인 면접은 지식의 양을 재는 시험이 아닙니다. 정답이 없는 문제 앞에서 여러분이 어떻게 사고하는지를 보는 대화입니다. 리텔과 웨버의 말처럼 이런 문제에는 참인 답이 없고 더 나은 답만 있으며, 체이스와 사이먼이 보여줬듯 실력은 계산의 속도가 아니라 패턴을 알아보는 눈에서 나옵니다.
그러니 유명한 아키텍처를 통째로 외우는 데 시간을 쓰기보다, 익숙한 문제 몇 개를 놓고 이 조건이면 무엇을 얻고 무엇을 포기하는가를 소리 내어 설명하는 연습을 하세요. 코드를 짜기 전에 설계와 판단에 시간을 쓰는 습관, 그리고 그 판단을 이력서와 포트폴리오에 성과로 번역하는 일까지 이어지면, 면접은 시험이 아니라 여러분이 이미 하는 일을 보여주는 자리가 됩니다. 같은 개발 면접 안에서도 코딩 테스트를 맞혀도 떨어지는 이유가 정답 코드가 아니라 사고 과정을 보기 때문이라는 점에서 맥이 같고, 이건 개발 직군만의 이야기도 아닙니다. PM 면접이 좋은 아이디어가 아니라 문제를 정의하는 과정을 채점하는 것도 정확히 같은 원리입니다. 완벽한 설계는 없습니다. 더 나은 판단이 있을 뿐입니다.
참고 자료
- Horst W. J. Rittel & Melvin M. Webber, “Dilemmas in a General Theory of Planning,” Policy Sciences (1973) — 난제(wicked problem) 개념, 해답은 참·거짓이 아니라 더 나음·나쁨
- William G. Chase & Herbert A. Simon, “Perception in Chess,” Cognitive Psychology (1973) — 체스 전문성의 청킹과 패턴 인식, 데 흐로트 실험 계승
- Alex Xu, 『System Design Interview – An Insider’s Guide』 (2020) — 요구사항·개략 설계·심화·트레이드오프의 4단계 프레임워크
- System Design Handbook · DesignGurus · IGotAnOffer, “What system design interviews evaluate” (2026) — 요구사항 명료화·트레이드오프·커뮤니케이션 평가 기준
- Donald E. Knuth, “Structured Programming with go to Statements,” Computing Surveys (1974) — 섣부른 최적화 경고
