시스템 디자인 인터뷰, 단계별 진행

naubull2 2025. 7. 16. 23:53

들어가며: 막연함은 끝, 시스템 디자인 인터뷰의 내비게이션!

지난 포스팅에서 시스템 디자인 인터뷰의 중요성과 본질에 대해 이야기했습니다. 이제 실전으로 들어가 볼 시간입니다. 막상 시스템 디자인 인터뷰를 마주하면 어디서부터 시작해야 할지 막막할 수 있습니다.

하지만 걱정하지 마십시오. 시스템 디자인 인터뷰는 마치 거대한 시스템을 설계하는 과정과 같습니다. 복잡한 문제를 한 번에 해결하기보다, 단계별로 쪼개어 접근하면 훨씬 효율적입니다. 면접관들도 여러분이 이 과정을 얼마나 체계적으로 풀어나가는지 보고 싶어 합니다. (사실 어느정도 면접 경험이 쌓이면, 매번 같은 패턴이라는 느낌을 받을 수 도 있습니다.)

이번 포스팅에서는 시스템 디자인 인터뷰의 표준적인 진행 단계와 각 단계에서 여러분이 해야 할 역할에 대해 상세히 알아보겠습니다. 이 가이드는 여러분이 인터뷰라는 낯선 항해를 떠나는 데 적당한 내비게이션이 되어줄 것입니다.

1단계: 요구사항 명확화 및 범위 정의 (Clarify Requirements)

인터뷰의 시작은 문제 정의부터입니다. 면접관이 던진 첫 질문을 듣자마자 무작정 설계부터 시작해서는 안 됩니다. 가장 중요한 것은 요구사항을 명확히 하고, 시스템의 범위를 정의하는 것입니다. (내가 신규 프로젝트를 담당한 리드 엔지니어라고 생각해보시면 편할겁니다. 새로운 프로젝트를 시작하는 첫 미팅에서, 어떤 상황인지 제대로 파악도 안된채로 다짜고짜 설계부터 하진 않겠죠? ㅎㅎ)

문제(프로젝트) 타이틀만 보고도 대충 예상은 되겠지만, 무엇이든 확인하지 않고 넘어가면 절대 안됩니다. 가령, 트위터를 만들라고 했는데 "이용자는 하루에 대충 1억명이라고 봐도 될까요?" 정도는 뻔한 질문이지만 확인을 꼭 해야한다는 이야깁니다. 안물어 보고 진행하면, 고작 하루 이용자 1천명 수준의 서비스가 될지도 모르는데 오버스펙으로 설계 하는 이상한 사람으로 볼 수 있기 때문이죠. (혹은, 주니어라면, 일할때 매사에 혼자 넘겨 짚고 일단 커밋이나 때리는 사람으로 비춰지면.. 같이 일하기 피곤하겠죠??)

무엇을 해야 하는가?:

면접관에게 질문 던지기: "누가, 무엇을, 얼마나, 어떻게 사용할까요?" 이 4가지 질문은 모든 설계의 시작점이 됩니다.
- 사용자: 예상 사용자 수, 동시 접속자 수, 사용자 유형 (일반 사용자, 관리자 등)
- 기능: 핵심 기능 (Must-have), 부가 기능 (Nice-to-have)을 구분하고 우선순위를 확인합니다. (특히 중요합니다. 면접이라는 환경 상, 시간 제약이 있으니 현실의 프로젝트와는 달리 스펙을 핵심 기능으로 제한하고, 시간이 남으면 확장해 나가야할 수 있습니다.)
- 규모: 예상되는 트래픽 (QPS), 데이터 저장량, 읽기/쓰기 비율 등
- 제약사항: 성능 목표 (응답 시간, 지연 시간), 가용성 목표 (SLA), 보안 요구사항, 비용 제약, 개발 기간 등
기능적/비기능적 요구사항 식별:
- 기능적 요구사항 (Functional Requirements): 시스템이 무엇을 '할' 것인가 (예: 사용자 인증, 게시물 작성, 검색 기능 등).
- 비기능적 요구사항 (Non-functional Requirements): 시스템이 어떻게 '잘' 작동할 것인가 (예: 초당 10,000건의 요청 처리, 99.99% 가용성 보장 등).
범위 좁히기: 주어진 시간 내에 현실적으로 설계할 수 있는 범위를 면접관과 합의해야 합니다. 모든 기능을 다 다루려고 하면 시간이 부족해질 수 있습니다. 꼭 소통하세요. 그냥 혼자 속사포 랩으로 설명 쏟아내고 설계 들어가면 안됩니다. 스펙에 문제가 있으면 면접관이 원하는 방향으로 푸시를 해줄 겁니다.
더보기
안물어보면 일부러 중간에 제지 하지 않고 그래, 너 혼자 어떻게 하나 보자 하고 가만히 있는 면접관들도 많습니다.
심하면 설계 다 끝나고 나서 야, 근데 스펙에 이게 빠졌는데 어쩔거야? 하고 막판에 벙찌게 만들어주는 면접관도 간혹 있습니다만..
사실 그런 경우는 애초에 떨어진 면접이니 기분 나빠하기 보단 피드백해서 다음에 잘 소통 하시기 바랍니다.

왜 이 단계가 중요한가?:

문제에 대한 오해를 방지하고, 면접관과 동일한 그림을 그릴 수 있도록 돕습니다.
앞으로의 설계 방향을 설정하는 나침반 역할을 하며, 불필요한 논의를 줄여 효율성을 높입니다. (중간에 갑자기 스펙이 바뀌어서 설계가 어그러지면 곤란하죠.)
적극적인 소통 능력과 문제 정의 능력을 보여줄 수 있는 기회입니다.
중요는 하지만, 전체 시간 안배를 위해 5-8분 이상 시간을 쓰면 곤란합니다.

2 단계: 개략적인 설계 (High-Level Design)

요구사항이 명확해졌다면, 이제 시스템의 큰 그림을 그릴 차례입니다. 이 단계에서는 주요 컴포넌트들을 식별하고, 이들 간의 데이터 흐름을 대략적으로 정의하는 데 집중합니다.

무엇을 해야 하는가?:

핵심 컴포넌트 식별: 클라이언트, 웹/앱 서버, 로드 밸런서, 캐시, 데이터베이스(DB), 메시지 큐 등 시스템을 구성할 핵심 요소들을 화이트보드나 문서에 그려보십시오. (기업에 따라 제대로된 그림을 그릴 환경이 아닐 수 도 있는데, 따로 사전에 안내가 없다면, 텍스트로 메모장에 그리는것도 상정 하세요.)
데이터 흐름 정의: 사용자의 요청이 시스템에 들어와서 어떤 컴포넌트들을 거쳐 처리되고 응답되는지 큰 흐름을 설명해야 합니다.
API 설계 (초안): 주요 서비스 간에 어떤 API가 필요할지 간단하게 정의해볼 수 있습니다 (예: POST /users, GET /posts/{id}).
초기 스케일링 고려: 트래픽 요구사항을 고려하여, 각 컴포넌트가 어떻게 스케일링될 수 있을지 (예: 웹 서버는 여러 대로, DB는 복제본 사용) 간단하게 언급하는 것도 좋습니다.

왜 이 단계가 중요한가?:

복잡한 시스템을 한눈에 파악할 수 있는 전체적인 아키텍처 뷰를 제공합니다.
면접관이 여러분의 시스템 구성 능력과 전반적인 이해도를 평가할 수 있게 합니다.
이후 심화 설계 단계로 나아가기 위한 튼튼한 토대가 됩니다.

3 단계: 깊이 있는 설계 (Deep Dive)

개략적인 설계가 면접관과 공유되었다면, 이제 특정 핵심 컴포넌트에 대해 심층적으로 파고들 차례입니다. 면접관이 특정 부분을 지정하거나, 여러분이 중요하다고 생각하는 부분(혹은, 깊이있는 질문에 대응 가능한 숙련도 있는 부분)을 선택해서 더 자세히 설명할 수 있습니다. 사실 이 단계에서는 대충 넘어갈 수 있는 부분은 없을것이긴 한데요, 너무 한 컴포넌트에서 시간을 많이 쓰지 않도록 시간 안배 하는 연습이 많이 필요할 수 있습니다. 평소에 잘 알고 있는 내용이여도 면접중에는 긴장하기 마련이라 연습이 없다면 시간 안배가 생각보다 잘 안될 수 있습니다. (중요한 컴포넌트를 짚고 넘어가지 못하고 "I think we should stop right here." 소리 듣는거 정말 싫죠?)

무엇을 해야 하는가?:

핵심 컴포넌트 상세화:
- 데이터베이스 스키마 설계: 필요한 테이블과 컬럼, 인덱스, 관계 등을 구체적으로 정의합니다.
- API 상세 설계: 요청/응답 형식, 에러 코드, 인증 방식 등을 더 자세히 설명합니다.
- 특정 알고리즘/자료구조 적용: Rate Limiter라면 토큰 버킷/리키 버킷 알고리즘의 동작 방식, Consistent Hashing이라면 해시 링과 가상 노드 개념 등을 자세히 설명합니다.
트레이드오프 설명:
- 각 설계 결정(예: SQL vs NoSQL, 강한 일관성 vs 결과적 일관성)에는 장단점이 있습니다. 여러분의 선택에 대한 명확한 근거와 다른 대안들의 단점을 설명하고, 왜 그 선택을 했는지 납득시켜야 합니다.
- 가장 중요한 부분 중 하나입니다! 면접관은 여러분이 다양한 기술을 단순히 나열하는 것보다, 상황에 맞춰 합리적인 판단을 내릴 수 있는지 보고 싶어 합니다. 컴포넌트마다 최소한 두개 이상의 대안을 알고 있어야, 트레이드오프 설명이 가능하겠죠?
성능 최적화 및 확장성 고려: 캐싱 전략, 비동기 처리, 메시지 큐 활용, 샤딩(Sharding) 등 시스템의 성능과 확장성을 높이기 위한 구체적인 방안들을 제시합니다. (시간이 없거나 잘 모르면 일단 단계마다 캐싱만 언급해도.. 중고 신입 수준 경력이라면 이해할 수 있는 부분이지만, AI 시대가 되고나서 캐시 떡칠로 면피 되는것도 곧 끝나겠네요..)

왜 이 단계가 중요한가?:

여러분의 실질적인 기술 깊이와 문제 해결 능력이 가장 잘 드러나는 단계입니다.
트레이드오프 분석 능력과 비판적 사고를 효과적으로 보여줄 수 있습니다.
추상적인 개념을 넘어 구체적인 구현 아이디어까지 제시할 수 있는지를 평가받을 수 있습니다.
시간 안배상으로도 이 단계에서 최소한 20분 이상을 쓰게 됩니다. (앞뒤로 10분씩 정도 더 쓰면 딱 40분 정도 될거고, 5-10분 정도 여유를 가져야 중간에 질문이 들어오거나 처음 생각대로 안흘러갔을때 시간이 맞춰집니다.)

4 단계: 마무리 및 개선 (Wrap Up & Improvements)

설계 설명을 마쳤다면, 인터뷰를 깔끔하게 마무리하고 깊이 있는 통찰력을 보여줄 시간입니다.

무엇을 해야 하는가?:

성능 병목 지점 식별 및 개선 방안 제시: 설계한 시스템에서 잠재적인 병목 지점이 어디일지 예측하고, 이를 개선하기 위한 추가적인 방안을 제시합니다. (예: DB 핫스팟, 특정 API의 부하 등)
미래 확장성 및 개선 사항 언급:
- "현재는 이렇지만, 미래에 트래픽이 10배 늘어난다면 어떤 부분을 개선해야 할까요?"와 같은 질문에 답할 준비가 되어 있어야 합니다.
- 모니터링, 로깅, 알람 시스템 등 운영상의 고려사항을 언급하는 것도 좋은 인상을 줄 수 있습니다.
질의응답: 면접관의 추가 질문에 대해 논리적이고 자신감 있게 답변합니다. 모르는 부분은 솔직하게 인정하고, "지금 당장은 명확히 모르지만, 이런 방식으로 접근해서 찾아볼 것 같습니다"와 같이 어느정도 방향을 잡는 능력과 배우려는 태도를 보여주는 것이 중요합니다.

왜 이 단계가 중요한가?:

단순히 주어진 문제만 해결하는 것이 아니라, 전체적인 시야와 주도적인 문제 해결 능력을 보여줄 수 있습니다.
지속적인 개선과 성장을 중요하게 생각하는 개발자임을 어필할 수 있는 기회입니다.
시간 관계상 너무 깊게 설명 하진 않아도 되고, 면접관도 마무리하면서 질문을 좀 던지면서 혹시 빠뜨렸더라도, 알고는 있나 정도만 확인 하는 단계가 되기도 합니다.

마치며: 체계적인 접근이 성공의 열쇠!

시스템 디자인 인터뷰는 여러분의 개발 역량을 총체적으로 보여주는 무대입니다. 위에서 설명한 4단계 접근 방식을 숙지하고, 각 단계에서 무엇을 해야 할지 미리 고민한다면, 훨씬 자신감 있게 인터뷰에 임할 수 있을 것입니다.

평소에 열심히 일하고 배우고 경험했다면, 이미 크게 준비하지 않아도 평소에 프로젝트 미팅 들어가서 나누는 대화랑 크게 다르지 않을겁니다. 차이가 있다면, 내가 리드 개발자로써 설계와 대화를 주도하는 입장이여야 한다는 정도니까요.

저작자표시 비영리 변경금지 (새창열림)