Meta 시스템 디자인 면접 질문

분산 시스템 지식을 암기하며 준비했을 수도 있지만, 이 면접에서는 그런 지식을 평가하지 않습니다. 이 섹션에서는 실제 출제되는 문제 유형을 다루는데, 이는 인프라보다는 제품 엔지니어링에 훨씬 가깝습니다. 반복되는 패턴은 당신이 이미 사용하고 있는 소비자 규모의 기능을, 열린 문제로 던져주는 것입니다.

• 뉴스 피드를 설계하라. 랭킹, 쓰기 시 팬아웃과 읽기 시 팬아웃의 차이, 그리고 팔로워가 수백만 명인 계정에서 발생하는 문제.
• 메시징 또는 채팅 시스템을 설계하라. 전달 보장, 순서, 프레즌스, 기기 간 오프라인 동기화.
• 알림 시스템을 설계하라. 중복 제거, 배치 처리, 사용자별 속도 제한, 그리고 푸시·이메일·인앱 전반의 전달.
• 주변 친구 또는 위치 기반 기능을 설계하라. 지리공간 인덱싱, 업데이트 빈도, 프라이버시 모델.
• 검색 또는 트렌딩 컴포넌트를 설계하라. 인덱스 신선도와 쿼리 지연 시간의 트레이드오프.

일부 면접 프로세스는 이를 사용자 대면 동작에 더 가까운 제품 아키텍처 변형으로 나눕니다. 준비 방식이 달라지므로, 자신이 어떤 유형을 보게 되는지 리크루터에게 물어보세요.

실패하는 흔한 패턴은 시작 2분 만에 박스를 그리기 시작하는 것입니다. 실용적인 배분은 요구사항과 범위를 명확히 하고, API와 데이터 모델을 스케치하고, 상위 수준 아키텍처를 그린 다음, 면접관이 지목하는 부분을 깊이 파고드는 순서입니다.

• 요구사항이 먼저입니다. 어떤 사용자를 위한 것인지, 어떤 플랫폼인지, 읽기 위주인지 쓰기 위주인지, 그리고 명시적으로 만들지 않을 것은 무엇인지.
• 다음은 숫자입니다. 대략적인 일일 활성 사용자 수, 요청 비율, 페이로드 크기 등, 이후 트레이드오프를 뒷받침할 근거가 됩니다.
• 다이어그램보다 데이터 모델이 먼저입니다. 엔티티의 형태와 쿼리 방식이 대개 아키텍처를 결정합니다.
• 깊이 파고들기는 한 번입니다. 하나의 컴포넌트로 유도되어 그것이 어떻게 실패하는지 질문받을 것이라 예상하세요.

가정을 소리 내어 말하세요. 면접관이 어떤 가정에 동의하지 않으면 바로잡아 줄 텐데, 이는 공짜 정보입니다. 반대로 말하지 않은 가정은 그저 빈틈처럼 보일 뿐입니다.

평범한 답변은 올바른 아키텍처를 설명하는 데 그칩니다. 뛰어난 답변은 자신이 받아들인 트레이드오프와 감수할 실패를 구체적으로 짚어냅니다. “여기서는 읽기가 지배적이라 쓰기 시 팬아웃을 선택하고, 유명 계정의 쓰기 지연은 감수하되 별도의 풀 경로로 처리하겠다”라고 말하는 것이, 완벽한 다이어그램보다 더 큰 설득력을 갖습니다.

시니어 직급 면접을 보는 백엔드 엔지니어를 생각해 봅시다. 그녀는 알림 시스템 설계를 요청받고, 처음 6분을 오직 요구사항에만 씁니다. 한 이벤트에 대해 사용자가 두 개의 알림을 받을 수 있는지, 순서가 중요한지, 보존 기간은 얼마인지. 면접관은 나중에 중복 제거에 대한 논의가 이 면접의 결정적인 부분이었다고 말했고, 그녀는 한 페이지짜리 다이어그램 이상으로 나아가지 못했습니다.

이런 설명 방식을 책상 앞에서 혼자 연습하는 것이 가장 어려운 부분입니다. /mock-interview 페이지에서 AI 면접관을 상대로 디자인 문제를 연습하며, 생각하면서 말하는 데 익숙해질 수 있습니다.

음성 화상 면접에서 SubcueAI는 면접관의 질문을 받아 적고, macOS와 Windows에서는 데스크톱 오버레이로, Chromium 브라우저 확장 프로그램에서는 사이드 패널로 당신 쪽에 제안된 구조를 보여줍니다. 통화에 참여하는 미팅 봇은 없으며, 미팅 페이지에 아무것도 주입되지 않습니다. 디자인 면접에서 현실적인 가치는 소리 내어 읽는 답이 아니라, 용량 추정치나 실패 모드처럼 압박 속에서 자꾸 잊어버리는 체크리스트 역할을 하는 것입니다.

다만 한계는 분명합니다. 디자인 면접은 보통 화면을 공유한 공용 화이트보드 툴에서 진행되며, 화면에 있는 모든 것이 면접관에게 보입니다. 생성된 답을 읽는 것도 곧바로 무너지는데, 면접관의 다음 질문이 “다른 접근 방식은 왜 안 되나요?”이기 때문입니다. 다른 회사들의 관련 면접 정보는 기업별 면접 토픽에 있습니다.