3장

한 사람이 한 시간 안에 실제 시스템을 설계할 수 없다는 건 모두 압니다. 이 면접의 목적은 완성된 설계가 아니라 협력 시뮬레이션을 보는 것입니다.

면접관은 지원자의 설계 기술, 결정에 대한 방어 능력, 피드백을 건설적으로 다루는 자질을 확인합니다.

설계 면접은 전부 제각각이지만 절차에는 공통점이 있습니다. 4단계로 정리됩니다.

1단계 문제 이해 및 설계 범위 확정, 2단계 개략적 설계안 제시 및 동의 구하기, 3단계 상세 설계, 4단계 마무리입니다.

질문을 던져 요구사항을 정확히 이해하고 모호함을 없애는 것입니다. 엔지니어가 가져야 할 가장 중요한 기술 중 하나는 올바른 질문을 하고 적절한 가정을 세우며 필요한 정보를 모으는 것입니다.

바로 답부터 들이밀지 말고, 가정을 세웠다면 화이트보드나 종이에 적어둡니다.

요구사항을 분명히 하기 위한 오갈 대화의 예입니다. 모바일/웹 지원 범위, 가장 중요한 기능, 정렬 기준, 친구 수 상한, 트래픽 규모, 미디어 첨부 가능 여부 등을 묻고 답합니다.

예를 들어 면접관이 '둘 다 지원, 핵심 기능은 새 포스트 작성과 친구 피드 조회, 시간 역순 정렬, 친구 최대 5000명, DAU 천만, 이미지·비디오 첨부 가능'이라고 답하는 식입니다.

개략적 설계안을 제시하고 면접관의 동의를 얻는 것입니다. 면접관을 팀원처럼 대하며 협력해 진행합니다. 훌륭한 면접관은 지원자와 대화하고 설계 과정에 개입하기를 즐깁니다.

핵심 컴포넌트를 담은 다이어그램을 그리고, 이 설계가 규모 제약을 만족하는지 개략적으로 계산해 소리 내어 설명합니다.

두 가지 처리 플로로 나눠 생각합니다. 피드 발행과 피드 생성입니다.

이 두 플로를 각각 개략적인 다이어그램으로 그려 보입니다.

피드 발행은 사용자가 글을 올린 뒤 그 글이 저장되고, 친구들의 피드에 반영되며, 필요하면 알림까지 이어지는 흐름입니다. 전체 경로는 사용자 단말에서 시작해 DNS, 로드밸런서, 웹 서버를 거친 뒤 포스팅 저장 서비스, 포스팅 전송 서비스, 알림 서비스로 나뉩니다. 웹 서버는 인증, 요청 검증, 기본 라우팅을 처리하고 실제 작업은 성격에 맞는 서비스로 넘깁니다.

하나의 서버가 저장, 전송, 알림을 모두 처리하면 빠르게 끝나는 작업과 오래 걸리는 작업이 서로 발목을 잡습니다. 그래서 마이크로서비스로 나눠 각 작업을 따로 책임지게 합니다. 포스팅 저장은 빠르게 완료되어야 하고, 피드 전송과 알림은 상대적으로 무겁거나 외부 시스템에 영향을 받기 쉽습니다. 서비스를 나누면 독립적으로 scale할 수 있고, fault isolation도 쉬워집니다. 팀별 소유와 독립 배포가 가능하다는 점도 중요한 이유입니다.

포스팅 저장 서비스는 글 본문, 작성자, 생성 시간, 미디어 참조 같은 원본 데이터를 저장합니다. 앞단에는 캐시를 두고, 뒤에는 포스팅 데이터베이스를 둡니다. 포스팅 전송 서비스는 새 글을 친구들의 뉴스 피드 캐시에 반영합니다. 알림 서비스는 모바일 푸시 같은 사용자 알림을 담당하며 APNs, FCM 같은 외부 푸시 시스템과 느슨하게 연결됩니다.

설계 대상 컴포넌트 사이의 우선순위를 정하고, 면접관이 집중하길 원하는 영역을 깊이 있게 설명합니다. URL 단축기라면 해시 함수 설계를, 채팅 시스템이라면 지연시간 축소와 온/오프라인 표시 방법을 듣고 싶어 합니다.

사소한 세부에 시간을 낭비하지 말고 긍정적 신호 전달에 집중합니다.

면접관이 시스템 병목이나 개선 지점을 찾아내라고 주문할 수 있습니다. 이때 '완벽하다, 개선할 게 없다'고 답하지 마세요. 개선할 점은 언제나 있으며, 이런 질문은 비판적 사고를 보이고 좋은 인상을 남길 기회입니다.

설계를 다시 요약해 주는 것도 긴 세션 뒤 면접관의 기억을 환기시키는 데 도움이 됩니다.

질문으로 확인(clarification)하고 요구사항을 이해합니다. 정답·최선의 답은 없음을 명심하고, 면접관이 사고 흐름을 따라올 수 있게 소통합니다. 가능하면 여러 해법을 함께 제시하고, 동의를 얻으면 중요한 컴포넌트부터 세부를 설명합니다. 포기하지 마세요.