필사 모드: 시스템 설계 면접 준비법 — 정답이 아니라 좁혀 가는 과정을 채점받는 45분

들어가며 — 화이트보드 앞에서 45분이 증발하는 이유

흔한 장면이 있습니다. 면접관이 "URL 단축 서비스를 설계해 주세요"라고 말하자마자 후보는 펜을 듭니다. 클라이언트, 로드 밸런서, 웹 서버, 데이터베이스. 박스 다섯 개와 화살표 여섯 개가 3분 만에 완성됩니다. 그리고 25분쯤 지났을 때 면접관이 묻습니다. "하루에 몇 건을 처리해야 하나요?" 후보는 그제야 자신이 아무것도 정하지 않은 채 그림만 그렸다는 것을 깨닫습니다.

이 실패는 지식의 문제가 아닙니다. 같은 후보가 카프카도 알고 샤딩도 압니다. 무너진 것은 진행 방식입니다. 시스템 설계 면접은 정답이 존재하지 않도록 일부러 열어 둔 문제이고, 그래서 채점표도 결과물이 아니라 과정을 향해 있습니다.

솔직히 말하면, 이 형식이 실제 업무 능력을 얼마나 잘 예측하는지에 대해서는 업계 안에서도 회의론이 있습니다. 45분 동안 화이트보드에서 하는 일은 실무의 설계 작업과 꽤 다르니까요. 다만 그 논쟁과 별개로, 당장 통과해야 하는 사람에게 필요한 것은 형식의 규칙을 아는 일입니다. 이 글은 그 규칙에 관한 것입니다.

면접관이 실제로 채점하는 것

알렉스 쉬의 『System Design Interview』(2020)는 이 면접을 네 단계로 정리합니다. 문제를 이해하고 범위를 정하기, 개략 설계를 제안하고 동의를 얻기, 깊게 파기, 마무리하기. 이 구조가 널리 퍼진 이유는 실제 채점 양식이 대체로 비슷한 축을 갖기 때문입니다.

대부분의 회사에서 면접관이 채우는 피드백 항목은 네다섯 개입니다. 요구사항을 스스로 좁혔는가, 개략 구조가 요구사항과 연결되는가, 한 지점을 깊게 팔 수 있는가, 선택마다 대가를 말했는가, 생각을 알아들을 수 있게 말했는가. 여기 "최적의 아키텍처를 제시했는가"라는 항목은 보통 없습니다.

면접관이 찾는 것은 정답이 아니라, 제약이 주어졌을 때 후보가 무엇을 포기할 줄 아는가입니다. 무한한 예산과 무한한 시간이 있다면 설계는 필요 없습니다. 설계란 어떤 것을 못 하기로 정하는 일이고, 못 하기로 정한 이유를 설명하는 것이 이 면접의 본체입니다.

연차가 올라갈수록 비중이 이동합니다. 주니어 채용에서는 "무엇을 아는가"가 크고, 시니어 채용에서는 "무엇을 모르는지 아는가"가 커집니다. 자신이 운영해 본 적 없는 영역을 운영해 본 것처럼 말하는 후보는, 아는 것이 많아도 시니어 판정을 받기 어렵습니다.

45분을 쓰는 법 — 시간 예산을 먼저 말하고 시작합니다

시간 배분을 미리 정해 두지 않으면 45분은 반드시 앞쪽에서 새어 나갑니다. 다음이 무난한 기본값입니다.

• 요구사항 정리 5분. 기능 요구 두세 개로 범위를 잘라 내고, 비기능 요구를 숫자로 확정합니다.
• 개략 설계 10분. 박스와 화살표는 여기서 처음 등장합니다. API 한두 개와 데이터 모델의 뼈대까지.
• 심화 15분. 면접관이 관심을 보인 한 지점으로 들어갑니다. 이 구간이 사실상 배점의 절반입니다.
• 병목과 확장 10분. 트래픽이 열 배가 되면 어디가 먼저 깨지는지, 그때 무엇을 바꾸는지.
• 마무리 5분. 남은 위험, 다음에 측정할 것, 시간이 더 있다면 볼 것.

여기서 실전 팁 하나. 이 예산을 혼자 지키지 말고 소리 내어 선언하세요. "5분 정도 요구사항을 정리하고 10분쯤 개략 구조를 그린 다음, 관심 있으신 부분을 깊게 파는 순서로 진행하겠습니다. 괜찮을까요?" 이 한 문장이 두 가지를 동시에 합니다. 진행의 통제권을 가져오고, 상대와 합을 맞추는 사람이라는 신호를 줍니다.

그리고 시계를 봅니다. 자가 진단 기준 하나만 기억하면 됩니다. 15분이 지났는데 첫 박스를 아직 못 그렸다면 요구사항에 너무 오래 머문 것이고, 5분 만에 전체 그림이 끝났다면 아무것도 정하지 않은 것입니다.

외워 둘 가치가 있는 숫자들

설계에서 오가는 대부분의 판단은 자릿수 감각 위에 서 있습니다. 캐시를 왜 두는지, 왜 리전을 나누는지, 왜 동기 호출을 줄이는지가 전부 아래 표의 간격에서 나옵니다.

이 표의 원본은 제프 딘이 정리하고 피터 노빅이 널리 퍼뜨린 "모든 프로그래머가 알아야 할 지연 시간 수치"입니다. 2012년판을 기준으로 인용되는 경우가 많은데, 절대값 일부는 이미 낡았습니다. 특히 저장장치 쪽은 그 사이 한 자릿수 이상 빨라졌습니다. 그래도 층과 층 사이의 간격은 여전히 유효하고, 면접에서 필요한 것도 정확한 값이 아니라 그 간격입니다.

마지막 줄만은 하드웨어가 바뀌어도 줄지 않습니다. 광섬유 안에서 빛은 초속 20만 킬로미터 정도로 갑니다. 서울과 미국 서부는 편도 9천 킬로미터쯤이니 물리적 하한만으로 왕복 90밀리초입니다. 실제 경로의 우회까지 더하면 실측은 대개 130밀리초 안팎이 됩니다. 이 숫자를 알고 있으면 "CDN과 엣지 캐시를 두겠습니다"가 유행어 나열이 아니라 계산의 결론이 됩니다.

가용성 숫자도 하나만 외워 두면 좋습니다. 99.9퍼센트는 연간 약 8.8시간의 중단, 99.99퍼센트는 약 53분입니다. 면접관이 "가용성 목표는요?"라고 물었을 때 이 환산을 즉시 하면, 그다음 대화는 자연스럽게 다중 가용영역과 장애 조치 비용으로 넘어갑니다.

추정 연습 — DAU 하나에서 QPS와 스토리지까지

개략 추정은 재능이 아니라 반복입니다. 시작은 반올림 두 개입니다. 하루는 86,400초인데 10만 초로 반올림하고, 1년은 3천만 초로 반올림합니다. 그러면 계산이 암산 범위에 들어옵니다. 하루 100만 요청은 평균 10 QPS 언저리(정확히는 11.6), 하루 1억 요청은 1,000 QPS 언저리입니다.

실제로 굴려 보겠습니다. 일간 활성 사용자 1,000만 명, 한 사람이 하루 20번 요청한다고 가정하면 하루 2억 건입니다. 10만으로 나누면 평균 2,000 QPS. 트래픽은 고르게 오지 않으니 피크를 평균의 2~3배로 잡아 5,000에서 6,000 QPS를 설계 기준으로 삼습니다. 여기서 읽기와 쓰기 비율을 100 대 1로 가정한다고 말하는 순간, 캐시와 읽기 복제본 이야기가 억지 없이 따라 나옵니다.

스토리지도 같은 방식입니다. 텍스트 게시글 하나가 1킬로바이트이고 하루 100만 건이면 하루 1기가바이트, 1년이면 365기가바이트입니다. 5년 보관에 3중 복제를 하면 5.5테라바이트쯤. 여기에 이미지가 붙으면 자릿수가 바뀝니다. 평균 200킬로바이트 이미지가 하루 100만 장이면 하루 200기가바이트, 1년에 73테라바이트입니다. 이 계산을 해 본 사람만이 "이미지는 객체 스토리지로 분리하고 메타데이터만 데이터베이스에 둡니다"라는 문장을 근거와 함께 말할 수 있습니다.

추정에서 채점되는 것은 정확도가 아니라 가정을 밖으로 꺼내 놓았는가입니다. 1,000만이라는 숫자가 틀려도 괜찮습니다. 다만 "사용자 1,000만, 1인당 20회, 피크 3배"라고 말해 두면 면접관이 그 자리에서 숫자를 고쳐 줄 수 있고, 그때부터는 둘이 같은 문제를 풀게 됩니다.

자주 무너지는 네 지점

• 요구사항을 묻지 않고 그림부터 그리기. 가장 흔하고 가장 치명적입니다. 하루 1만 건 시스템과 하루 10억 건 시스템은 완전히 다른 물건인데, 묻지 않고 시작하면 둘 중 어느 쪽도 아닌 것을 그리게 됩니다. 첫 5분에 최소한 이 네 가지는 확정하세요. 규모, 읽기와 쓰기 비율, 지연 목표, 일관성 요구 수준.
• 유행 기술 나열. 카프카, 레디스, 엘라스틱서치, 쿠버네티스를 한 화면에 올려놓고 "이렇게 구성하겠습니다"로 끝내는 경우입니다. 면접관이 "이 큐가 없으면 어떻게 되나요"라고 물었을 때 답이 안 나오면, 그 박스는 가점이 아니라 감점이 됩니다. 컴포넌트를 하나 그릴 때마다 그것이 제거하는 문제를 한 문장으로 붙이세요.
• 대가 없이 단정하기. "NoSQL을 쓰겠습니다", "MSA로 가겠습니다" 같은 문장이 그 자체로 답이 되는 경우는 없습니다. 여기서 CAP 정리를 정확히 다루면 인상이 크게 달라집니다. 2000년 에릭 브루어가 추측으로 제시하고 2002년 길버트와 린치가 증명한 이 명제는 흔히 "셋 중 둘"로 요약되지만, 브루어 본인이 2012년 글에서 그 요약이 오해를 낳는다고 정정했습니다. 정확한 진술은 네트워크 분단이 실제로 일어났을 때만 일관성과 가용성 사이에서 골라야 한다는 것이고, 평시에는 둘 다 상당 수준으로 가질 수 있습니다.
• 심화 구간에서 얕게 머물기. 면접관이 "그 부분 조금 더 볼까요"라고 말하는 순간이 배점의 중심입니다. 그때 다른 컴포넌트로 화제를 옮기면 회피로 읽힙니다. 준비할 만한 단골 심화 주제는 정해져 있습니다. 샤딩 키 선택과 핫스팟, 캐시 무효화와 스탬피드, 멱등성과 재시도, 중복 없는 식별자 발급, 그리고 꼬리 지연.

"모릅니다"를 잘 말하는 법

모르는 것이 나오는 것은 사고가 아니라 설계입니다. 45분짜리 열린 문제에서 모르는 구간이 안 나오면, 문제가 너무 쉬웠던 것입니다. 그러니 준비할 것은 "모르는 상황을 피하는 법"이 아니라 "모르는 상황을 다루는 문장"입니다.

세 부분으로 말하면 거의 언제나 안전합니다. 경계를 인정하고, 아는 원리로 추론하고, 확인할 방법을 제시하는 것입니다.

"카프카의 정확히 한 번 전달은 제가 직접 운영해 본 적이 없습니다. 원리로 추론하면 프로듀서 멱등성과 트랜잭션 커밋이 함께 있어야 할 텐데, 소비자 쪽 처리까지 포함하면 결국 애플리케이션 수준의 멱등성이 필요할 것 같습니다. 실제로는 문서와 벤치마크를 확인한 뒤 결정하겠습니다."

이 답변이 얻는 점수는 지식 점수가 아니라 보정 점수입니다. 아는 것과 모르는 것의 경계를 정확히 그을 줄 아는 사람은, 운영 중에 위험한 결정을 덜 내립니다. 면접관은 그것을 봅니다. 반대로 최악의 대응은 두 가지입니다. 아는 척하다가 두 번째 질문에서 무너지는 것, 그리고 "모르겠습니다" 한마디로 대화를 끊는 것.

압박이 심한 순간일수록 이 문장이 안 나옵니다. 면접에서 무너지는 지점은 모른다는 사실 자체가 아니라, 모른다는 사실을 감추려고 애쓰는 몇 분입니다. 그 몇 분 동안 사고는 멈추고 말은 빨라집니다. 이 반응을 다루는 훈련은 압박 상황에서 무너지지 않는 법에서 다룬 압박 접종과 같은 원리입니다. 실전과 비슷한 조건에서 미리 흔들려 보는 것 말고 지름길은 없습니다.

그리고 이 면접의 절반은 결국 대화입니다. 혼자 중얼거리며 그림을 완성하는 사람보다, 상대의 반응을 보고 속도를 조절하는 사람이 더 좋은 점수를 받습니다. 대화를 잘한다는 것에서 다룬 원칙이 화이트보드 앞에서도 그대로 작동합니다.

마치며 — 채점되는 것은 결론이 아니라 좁혀 가는 과정입니다

시스템 설계 면접을 잘 본 날의 기록을 떠올려 보면, 대개 화려한 아키텍처가 나온 날이 아닙니다. 요구사항을 다섯 개에서 두 개로 잘라 내고, 숫자를 세 번 계산하고, 한 지점을 끝까지 판 날입니다. 그림은 오히려 단순합니다.

준비도 같은 방향이면 됩니다. 문제 열 개를 훑는 것보다 세 개를 시간 재고 소리 내어 45분씩 풀어 보는 편이 낫습니다. 그리고 매번 마지막 5분은 스스로에게 이 질문을 던지세요. 오늘 나는 무엇을 포기했고, 왜 그것을 포기해도 된다고 판단했는가. 그 답이 정리되는 만큼 실력이 올라갑니다.