대규모 시스템 설계 스터디 03. 설계 질문을 풀어가는 순서

이 글의 핵심은 시스템 설계 질문을 요구사항 확인, 개략 설계, 상세 설계, 운영 점검 순서로 풀어가는 방법입니다.

시스템 설계 질문에는 하나의 정답만 있는 경우가 드뭅니다. 같은 뉴스 피드라도 사용자 규모, 정렬 기준, 이미지 포함 여부, 지연 시간 목표에 따라 설계가 달라집니다.

3장은 정답을 외우는 방법보다 설계 대화를 어떤 순서로 진행할지 다룹니다. 요구사항을 확인하고, 큰 구조를 제시하고, 병목이 되는 부분을 깊게 파고든 뒤, 운영 관점으로 마무리하는 흐름입니다.

이 순서를 익히면 막연한 설계 문제가 조금 더 다루기 쉬워집니다. “무엇부터 물어봐야 하는지”, “어디까지 그려야 하는지”, “어떤 선택의 장단점을 설명해야 하는지”가 분명해지기 때문입니다.

설계 대화는 여덟 가지 용어에서 시작합니다

용어	뜻
요구사항	시스템이 제공해야 하는 기능과 조건입니다. 예를 들어 게시글 작성, 피드 조회, 이미지 업로드가 요구사항이 될 수 있습니다.
비기능 요구사항	성능, 확장성, 가용성, 보안처럼 기능 자체는 아니지만 시스템 품질을 좌우하는 조건입니다.
설계 범위	이번에 어디까지 설계할지 정한 경계입니다. 모든 기능을 한 번에 다루지 않기 위해 필요합니다.
API	클라이언트와 서버가 약속한 요청 형식입니다. GET /feed처럼 표현할 수 있습니다.
컴포넌트	시스템을 이루는 구성 요소입니다. API 서버, 캐시, 데이터베이스, 메시지 큐가 각각 컴포넌트입니다.
병목	전체 성능을 제한하는 지점입니다. 요청이 몰리는 데이터베이스나 느린 외부 API가 병목이 될 수 있습니다.
트레이드오프	한 가지 장점을 얻는 대신 다른 비용을 감수하는 선택입니다. 빠른 응답을 얻는 대신 데이터 최신성이 낮아질 수 있습니다.
엣지 케이스	일반적이지 않지만 반드시 고려해야 하는 특수 상황입니다. 팔로워가 매우 많은 계정이나 갑작스러운 트래픽 폭증이 예시입니다.

바로 그리기 전에 문제의 경계를 먼저 정해야 합니다

시스템 설계 문제를 받으면 바로 박스와 화살표를 그리고 싶어질 수 있습니다. 하지만 설계 범위가 정해지지 않은 상태에서 그린 구조는 쉽게 빗나갑니다.

예를 들어 “뉴스 피드를 설계하세요”라는 요청만으로는 부족합니다. 다음 질문에 따라 구조가 크게 달라집니다.

확인할 질문	설계에 미치는 영향
피드에 텍스트만 있나요, 이미지와 동영상도 있나요?	저장소, CDN, 업로드 처리 방식이 달라집니다.
피드는 시간순인가요, 추천순인가요?	정렬 로직과 데이터 모델이 달라집니다.
사용자는 몇 명인가요?	캐시, 데이터베이스, 메시지 큐 규모가 달라집니다.
읽기와 쓰기 중 무엇이 더 많나요?	캐시 전략과 데이터 복제 전략이 달라집니다.
지연 시간 목표가 있나요?	비동기 처리와 사전 계산 여부가 달라집니다.

이 단계의 목표는 모든 답을 얻는 것이 아닙니다. 설계를 진행할 만큼의 가정을 명확히 만드는 것입니다.

좋은 표현은 다음과 같습니다.

이번 설계에서는 모바일 피드 조회와 게시글 작성을 범위로 두겠습니다.
이미지 업로드는 포함하되, 추천 알고리즘 자체는 제외하겠습니다.
DAU는 1,000만 명으로 가정하겠습니다.

이렇게 범위를 정하면 이후 설계가 흔들릴 때 다시 기준점으로 돌아올 수 있습니다.

큰 그림은 방향을 확인하는 단계입니다

요구사항을 확인한 뒤에는 개략 설계를 그립니다. 개략 설계는 모든 세부 사항을 담은 최종 설계가 아닙니다. 주요 컴포넌트와 데이터 흐름을 보여주는 지도에 가깝습니다.

뉴스 피드를 예로 들면 기본 구조는 다음처럼 시작할 수 있습니다.

클라이언트
  -> API 서버
  -> 피드 서비스
  -> 캐시
  -> 데이터베이스
  -> 메시지 큐
  -> 알림 서비스
  -> CDN

각 컴포넌트의 역할도 짧게 붙입니다.

컴포넌트	역할
API 서버	클라이언트 요청을 받고 인증과 기본 검증을 처리합니다.
피드 서비스	피드 생성과 조회 흐름을 담당합니다.
캐시	자주 조회되는 피드 목록을 빠르게 반환합니다.
데이터베이스	게시글, 사용자, 팔로우 관계를 저장합니다.
메시지 큐	피드 배포나 알림처럼 오래 걸리는 작업을 비동기로 넘깁니다.
CDN	이미지와 동영상 같은 정적 파일을 사용자 가까이에서 전달합니다.

이 단계에서는 API도 간단히 적을 수 있습니다.

POST /v1/posts      게시글 작성
GET  /v1/feed       피드 조회

API를 적는 이유는 설계가 실제 요청 흐름과 연결되기 때문입니다. 박스만 그리면 구조는 있어 보이지만, 사용자의 요청이 어디로 들어와 어떤 데이터를 읽고 쓰는지 흐려질 수 있습니다.

상세 설계는 병목이 큰 부분부터 들어갑니다

개략 설계가 끝났다고 모든 컴포넌트를 같은 깊이로 설명할 필요는 없습니다. 시간이 제한되어 있다면 병목이 크거나 트레이드오프가 중요한 지점부터 깊게 봐야 합니다.

뉴스 피드에서는 보통 피드 배포 방식이 핵심입니다. 사용자가 글을 썼을 때 팔로워들의 피드에 언제 반영할지 결정해야 하기 때문입니다.

대표 선택지는 Push 방식과 Pull 방식입니다.

방식	설명	장점	단점
Push	글을 쓰는 순간 팔로워들의 피드 캐시에 미리 넣습니다.	읽기가 빠릅니다.	팔로워가 많은 사용자는 쓰기 비용이 폭발합니다.
Pull	사용자가 피드를 읽을 때 필요한 글을 모아옵니다.	쓰기가 가볍습니다.	읽기 시점 계산이 무거워질 수 있습니다.

실제 시스템에서는 두 방식을 섞을 수 있습니다. 일반 사용자는 Push 방식으로 빠르게 피드를 준비하고, 팔로워가 매우 많은 계정은 Pull 방식으로 읽기 시점에 가져오는 식입니다.

이 선택을 설명할 때는 “이 방식이 더 좋습니다”에서 끝내지 않는 편이 좋습니다. 다음처럼 조건을 붙이면 판단이 더 명확해집니다.

일반 사용자는 팔로워 수가 제한적이므로 Push 방식이 읽기 지연 시간을 줄입니다.
다만 대형 계정은 쓰기 한 번이 수백만 건의 피드 갱신으로 이어질 수 있으므로 Pull 또는 혼합 방식을 사용하겠습니다.

이것이 트레이드오프 설명입니다. 빠른 읽기를 얻기 위해 쓰기 비용을 감수할지, 가벼운 쓰기를 얻기 위해 읽기 비용을 감수할지 선택하는 과정입니다.

마무리는 운영 관점으로 설계를 점검합니다

상세 설계까지 설명했다면 마지막에는 운영 관점의 질문으로 설계를 점검합니다.

점검 항목	확인할 내용
모니터링	QPS, 에러율, 지연 시간, 캐시 hit rate를 어떻게 볼 것인가
장애 대응	캐시 장애, 데이터베이스 장애, 메시지 큐 지연이 생기면 어떻게 우회할 것인가
확장 시나리오	DAU가 10배 늘면 어떤 컴포넌트를 먼저 늘릴 것인가
데이터 일관성	피드가 몇 초 늦게 반영되어도 되는가
보안과 권한	비공개 게시글이나 차단 관계를 어떻게 반영할 것인가

이 마무리는 단순한 덧붙임이 아닙니다. 설계가 실제 서비스로 운영될 수 있는지 확인하는 단계입니다.

예를 들어 캐시를 많이 쓰는 설계라면 캐시 장애 시 데이터베이스로 요청이 한꺼번에 몰릴 수 있습니다. 메시지 큐를 쓰는 설계라면 큐가 밀릴 때 사용자에게 어떤 상태를 보여줄지 정해야 합니다.

운영 관점을 마지막에 넣으면 설계가 “그림”에서 “운영 가능한 시스템”으로 조금 더 가까워집니다.

설계 대화의 기본 순서는 네 단계입니다

3장의 흐름은 다음 네 단계로 정리할 수 있습니다.

단계	목표
요구사항 확인	설계 범위와 가정을 명확히 합니다.
개략 설계	주요 컴포넌트와 요청 흐름을 그립니다.
상세 설계	병목과 트레이드오프가 큰 부분을 깊게 다룹니다.
마무리 점검	운영, 장애, 확장, 엣지 케이스를 확인합니다.

이 순서를 따르면 모호한 문제를 조금 더 안정적으로 다룰 수 있습니다. 먼저 범위를 정하고, 큰 그림을 맞추고, 중요한 부분만 깊게 들어간 뒤, 운영 관점으로 빠진 부분을 확인하기 때문입니다.

다음 글에서는 독립된 컴포넌트 설계 문제로 넘어갑니다. API 요청이 너무 많이 들어올 때 어떻게 제한할지, 처리율 제한 장치를 다룹니다.