# 시스템 설계 면접이 묻는 것: 정답이 아닌 사유의 체계

# 시스템 설계 면접이 묻는 것: 정답이 아닌 사유의 체계  시스템 설계 면접은 정답을 요구하지 않는다. 제약 속에서 트레이드오프를 사유하고, 불확실성을 구조화하며, 의사결정의 근거를 논리적으로 전개하는 능력을 검증한다. 기술적 선택 이면의 사유 체계를 드러낼 때, 비로소 설계자로서의 자격이 증명된다. ---  ## 면접의 본질: 정답 없는 문제의 구조 시스템 설계 면접은 특이한 형식이다. 명확한 정답이 존재하지 않으며, 같은 문제에 대해 열 명의 시니어 엔지니어가 열 가지 다른 답을 내놓을 수 있다. 이는 설계라는 행위의 본질적 속성이다. 면접관이 "일일 활성 사용자 1억 명 규모의 소셜 미디어 피드를 설계하라"고 요구할 때, 그들은 완벽한 아키텍처 다이어그램을 기대하지 않는다. 오히려 제약 조건을 명확히 하고, 가정을 설정하며, 트레이드오프를 의식적으로 선택하는 과정을 관찰한다. 설계는 수학 문제가 아니라 사유의 전개다. 이 형식이 요구하는 것은 기술적 지식의 암기가 아니다. 불완전한 정보 속에서 합리적 판단을 내리고, 그 근거를 논리적으로 설명하며, 새로운 제약이 주어졌을 때 유연하게 설계를 조정하는 능력이다.  ## 면접의 구조: 네 단계의 사유 전개 시스템 설계 면접은 암묵적으로 네 단계의 구조를 따른다. 각 단계는 순환적으로 상호작용한다. ### 요구사항의 명확화 첫 단계는 모호함과의 투쟁이다. "트위터 같은 시스템을 설계하라"는 지시는 의도적으로 불완전하다. 면접자는 이 모호함을 구조화해야 한다.  핵심은 올바른 질문을 던지는 능력이다. "읽기와 쓰기 비율은 어떻게 되는가?", "일관성과 가용성 중 무엇을 우선시하는가?", "지연시간 요구사항은 얼마인가?" 같은 질문은 단순한 정보 수집이 아니다. 설계자가 어떤 차원에서 문제를 바라보는지, 어떤 변수를 중요하게 인식하는지를 드러낸다. 많은 면접자가 이 단계에서 실패하는 이유는 명확하다. 질문을 던지지 않고 곧바로 솔루션을 제시한다. 실무에서 요구사항을 제대로 파악하지 못한 설계가 얼마나 큰 비용을 초래하는지 생각하면, 이 단계의 중요성은 자명하다. ### 개략적 설계의 제시 두 번째 단계는 전체 그림을 그리는 작업이다. 시스템의 주요 컴포넌트와 그 상호작용을 고수준에서 정의해야 한다.  클라이언트, 로드 밸런서, 애플리케이션 서버, 데이터베이스, 캐시 계층을 배치하되, 각각의 역할과 필요성을 명확히 해야 한다. "여기에 캐시를 둔다"는 것만으로는 부족하다. "읽기 요청이 쓰기보다 100배 많으므로, 데이터베이스 부하를 줄이기 위해 읽기 경로에 캐시 계층을 배치한다"처럼 의사결정의 근거를 명시해야 한다. 이 단계에서 중요한 것은 완벽함이 아니라 합리성이다. 모든 엣지 케이스를 다루려 하지 말고, 핵심 흐름을 먼저 정립하라. 사용자가 글을 작성하고, 저장하고, 다른 사용자가 조회하는 기본 경로를 명확히 한 후 점진적으로 복잡성을 추가하는 것이 효과적이다. ### 상세 설계의 심화  세 번째 단계는 특정 컴포넌트를 깊이 파고드는 과정이다. 면접관은 보통 이 단계에서 특정 영역에 집중하도록 유도한다. "데이터베이스 스키마를 어떻게 설계하겠는가?", "피드 생성 알고리즘은 어떻게 작동하는가?" 같은 질문이 여기에 해당한다. 이 단계에서 드러나는 것은 기술적 깊이와 트레이드오프에 대한 이해다. 예컨대 데이터베이스 선택을 논할 때, 단순히 "PostgreSQL을 쓰겠다"가 아니라 관계형 데이터베이스의 ACID 속성이 주는 이점과 수평 확장의 어려움이라는 한계를 동시에 언급해야 한다. NoSQL을 고려한다면 왜 그런 선택을 하는지, 어떤 일관성 모델을 수용할 것인지 명확히 해야 한다. 캐시 전략을 논한다면 write-through와 write-back의 차이, cache invalidation의 어려움, cache stampede 문제 같은 구체적 이슈를 다룰 수 있어야 한다. 각 선택이 시스템의 다른 부분에 어떤 영향을 미치는지, 어떤 상황에서 어떤 전략이 적합한지에 대한 사유를 요구한다. ### 확장성과 병목지점 분석 마지막 단계는 설계의 한계를 직시하는 작업이다. 완벽한 시스템은 존재하지 않으며, 모든 설계는 특정 규모와 부하 패턴을 가정한다. 이 가정이 깨질 때 무엇이 먼저 실패하는지, 어떻게 대응할 것인지가 핵심이다. 병목지점을 식별하고 완화 전략을 제시하는 능력이 여기서 평가된다. 데이터베이스가 병목이라면 읽기 복제본을 추가할 것인가, 샤딩을 도입할 것인가? 네트워크 대역폭이 문제라면 CDN을 활용할 것인가, 데이터 압축을 강화할 것인가? 각 해결책의 복잡성과 비용을 인식하는 것이 중요하다. 샤딩은 수평 확장을 가능하게 하지만, 조인 연산을 어렵게 만들고 운영 복잡도를 높인다. 이런 트레이드오프를 명시적으로 다루는 것이 시니어 엔지니어의 자격을 증명한다. ## 핵심 패턴: 반복되는 설계의 원리 시스템 설계 면접에서 다루는 문제는 다양하지만, 그 이면에는 공통된 패턴이 존재한다. 이 패턴을 내재화하면 새로운 문제에 대해서도 구조화된 접근이 가능하다. ### 데이터의 흐름과 저장 모든 시스템 설계는 결국 데이터를 어떻게 다루는가로 귀결된다. 데이터가 어디서 생성되고, 어떻게 전달되며, 어디에 저장되고, 누가 조회하는가를 명확히 하는 것이 출발점이다. 관계형 데이터베이스는 강한 일관성과 복잡한 쿼리를 지원하지만 수평 확장이 어렵다. NoSQL은 확장성을 제공하지만 일관성을 희생하거나 쿼리 능력이 제한적이다. 이는 기술적 사실이기도 하지만, 더 근본적으로는 CAP 정리가 강제하는 본질적 트레이드오프다. 실무에서 많은 시스템은 하이브리드 접근을 택한다. 트랜잭션이 중요한 핵심 데이터는 관계형 데이터베이스에, 높은 처리량이 필요한 로그나 세션 정보는 NoSQL에 저장한다. 이런 설계 결정을 내릴 때 각 데이터의 특성과 접근 패턴을 먼저 분석해야 한다. ### 캐싱과 성능 최적화 캐시는 거의 모든 대규모 시스템에 등장하는 패턴이다. 자주 접근되는 데이터를 빠른 저장소에 두어 응답 시간을 줄이고 백엔드 부하를 낮춘다. 하지만 캐시의 실제 구현은 복잡하다. 무엇을 캐시할 것인가? 캐시 크기를 어떻게 제한할 것인가? 데이터가 변경되었을 때 어떻게 동기화할 것인가? 이 질문들에 대한 답은 시스템의 특성에 따라 달라진다. 읽기가 압도적으로 많고 데이터 변경이 드물다면 긴 TTL을 가진 캐시가 효과적이다. 반대로 데이터가 자주 변경된다면 cache invalidation 전략이 핵심이 된다. "캐시 무효화는 컴퓨터 과학에서 가장 어려운 두 가지 문제 중 하나"라는 농담은 이 복잡성을 정확히 지적한다. ### 비동기 처리와 메시지 큐 모든 작업을 동기적으로 처리하는 시스템은 확장하기 어렵다. 사용자 요청에 즉시 응답해야 하는 작업과 백그라운드에서 처리해도 되는 작업을 분리하는 것이 핵심이다. 메시지 큐는 이 분리를 가능하게 한다. 사용자가 동영상을 업로드하면 파일을 저장하고 큐에 메시지를 넣은 후 즉시 응답한다. 실제 인코딩과 썸네일 생성은 워커가 비동기적으로 처리한다. 이는 응답 시간을 개선할 뿐 아니라 각 컴포넌트를 독립적으로 확장할 수 있게 한다. 메시지 큐를 도입할 때는 메시지 순서 보장, 중복 처리, 실패 시 재시도 같은 이슈를 고려해야 한다. at-least-once와 exactly-once 전달 보장의 차이를 이해하고, 시스템의 요구사항에 맞는 선택을 해야 한다. ### 부하 분산과 고가용성 단일 서버는 단일 장애점이다. 고가용성을 위해서는 중복성을 도입해야 하며, 이는 부하 분산 메커니즘을 필요로 한다. 로드 밸런서는 여러 전략을 지원한다. 라운드 로빈은 간단하지만 서버 간 부하 차이를 고려하지 못한다. least connections는 더 정교하지만 오버헤드가 있다. 세션 어피니티가 필요한지, 무상태 설계가 가능한지에 따라 적합한 전략이 달라진다. 데이터베이스 고가용성을 위해서는 복제를 활용한다. 주-복제본 구조에서 복제본은 읽기 부하를 분산하고 주 서버 장애 시 페일오버 대상이 된다. 하지만 복제 지연은 일관성 문제를 야기한다. 비즈니스 로직에서 어느 정도의 stale read를 수용할 수 있는지 판단해야 한다. ## 공략의 방법론: 사유를 드러내는 기술 시스템 설계 면접을 준비하는 것은 단순히 기술을 익히는 것과 다르다. 사유의 체계를 구축하고, 그것을 명료하게 전달하는 능력을 기르는 과정이다. ### 소통의 구조화 면접은 대화다. 침묵 속에서 완벽한 답을 구성하려 하지 말고, 사고 과정을 지속적으로 공유하라. "지금 데이터베이스 선택을 고민하고 있는데, 읽기 패턴이 쓰기보다 훨씬 많으니 읽기 최적화가 중요할 것 같습니다"처럼 생각의 흐름을 말로 표현하라. 면접관의 피드백에 귀 기울이고 설계에 반영하라. 그들이 특정 영역을 더 깊이 파고들라고 하면, 그것은 그 부분이 평가의 핵심임을 의미한다. 방향을 전환하는 것을 두려워하지 마라. 새로운 제약이 주어졌을 때 설계를 조정하는 것은 약점이 아니라 유연성의 증거다. ### 추상화 수준의 조절 처음부터 모든 세부사항을 다루려 하지 마라. 고수준 설계를 먼저 확립한 후 점진적으로 깊이를 더하라. 이는 시간 관리의 문제이기도 하지만, 더 근본적으로는 복잡성을 다루는 방법론이다. "데이터베이스를 사용한다"에서 시작해 "PostgreSQL을 사용한다"로 구체화하고, "읽기 복제본 3개를 두어 읽기 부하를 분산한다"로 세부화하라. 각 단계에서 면접관의 반응을 확인하고, 더 깊이 들어갈지 다른 영역으로 이동할지 판단하라. ### 트레이드오프의 명시화 모든 기술적 결정은 트레이드오프를 수반한다. 이를 명시적으로 언급하는 것이 시니어 엔지니어의 표식이다. "일관성을 위해 동기 복제를 선택하면 쓰기 지연이 증가합니다. 비동기 복제는 성능을 개선하지만 페일오버 시 데이터 손실 가능성이 있습니다. 이 시스템에서는 사용자 경험을 우선시하므로 비동기 복제를 선택하겠습니다." 이런 설명은 단순히 선택을 정당화하는 것을 넘어, 당신이 선택의 함의를 이해하고 있음을 보여준다. ### 실무 경험의 활용 이론적 지식도 중요하지만, 실제로 시스템을 구축하고 운영한 경험은 더 큰 가치를 지닌다. 면접에서 "이전 프로젝트에서 비슷한 문제를 겪었는데, 그때는 이렇게 해결했습니다"처럼 구체적 사례를 언급하라. 이는 당신이 이론을 실무에 적용할 수 있음을 증명한다. 설계가 완벽하게 작동하지 않았을 때 어떻게 대응했는지, 무엇을 배웠는지를 공유하는 것이 진정한 성숙함을 드러낸다. ## 준비의 체계: 지식을 사유로 전환하기 시스템 설계 면접 준비는 단기간에 끝나는 작업이 아니다. 기술적 지식을 축적하고, 실무 경험을 반추하며, 사유의 체계를 정립하는 장기적 과정이다. ### 기초 개념의 공고화 네트워크 프로토콜, 데이터베이스 이론, 운영체제 기초 같은 컴퓨터 과학의 근간을 탄탄히 하라. HTTP와 TCP의 차이, ACID와 BASE의 대비, 프로세스와 스레드의 트레이드오프 같은 개념은 모든 설계의 토대다. 이 지식은 암기가 아니라 이해를 통해 내재화되어야 한다. "CAP 정리는 일관성, 가용성, 분할 내성 중 두 가지만 선택할 수 있다"는 문장을 외우는 것이 아니라, 왜 세 가지를 동시에 만족할 수 없는지, 실제 시스템에서 어떤 선택을 하는지를 이해해야 한다. ### 실제 시스템의 분석 Twitter, Netflix, Uber 같은 대규모 시스템의 아키텍처를 공부하라. 이들 기업의 엔지니어링 블로그는 실제 문제와 해결책을 상세히 기록한다. 단순히 읽는 것을 넘어 "왜 이런 선택을 했을까?", "다른 방법은 없었을까?"를 스스로 질문하라. 이는 패턴 인식 능력을 기른다. 많은 문제가 본질적으로 유사하다는 것을, 표면적 차이 너머의 공통 구조를 볼 수 있게 된다. ### 모의 면접의 반복 혼자 설계하는 것과 다른 사람에게 설명하는 것은 다르다. 동료나 친구와 모의 면접을 반복하라. 시간 제약 속에서 사고를 정리하고, 질문에 대응하며, 피드백을 받는 경험이 중요하다. 자신의 설명을 녹음해서 들어보라. 불필요한 말이 많은지, 논리적 비약이 있는지, 핵심을 명확히 전달하는지 확인하라. 이는 단순한 면접 기술이 아니라 엔지니어로서의 소통 능력을 기르는 과정이다. ## 결론: 설계는 사유의 외형이다 시스템 설계 면접이 평가하는 것은 최종 아키텍처의 완벽함이 아니다. 불확실성 속에서 합리적 판단을 내리고, 제약 조건을 다루며, 트레이드오프를 의식적으로 선택하는 능력이다. 이 능력은 단순히 면접을 통과하기 위한 기술이 아니다. 시니어 엔지니어가 실무에서 매일 수행하는 작업의 본질이다. 새로운 기능을 설계할 때, 성능 문제를 해결할 때, 기술 스택을 선택할 때, 우리는 동일한 사유 과정을 거친다. 시스템 설계 면접은 당신의 사유 체계를 검증하는 장이다. 기술적 지식은 도구일 뿐이고, 진정으로 평가받는 것은 그 도구를 어떻게 사용하는가, 어떤 원칙에 따라 결정을 내리는가, 복잡성을 어떻게 다루는가다. 면접실을 나설 때 면접관이 기억하는 것은 당신이 그린 다이어그램이 아니다. 당신이 문제를 바라보는 방식, 질문을 던지는 태도, 트레이드오프를 다루는 성숙함이다. 설계는 결국 사유의 외형이며, 당신의 사유가 당신을 정의한다.