시스템 디자인 기초 (System Design Basics)

시스템 디자인 인터뷰란
요구사항 정리부터 시작하는 이유
규모 추정과 병목 예측
핵심 컴포넌트 나누기
데이터 흐름과 저장 전략 정하기
장애 지점과 운영 포인트 점검
트레이드오프를 설명하는 방법
면접에서 답변을 구성하는 순서
면접 포인트
참고 자료

시스템 디자인 인터뷰란

시스템 디자인 인터뷰(System Design Interview) 는 정답 하나를 맞히는 문제가 아니라, 요구사항을 해석하고 구조를 나누고 트레이드오프를 설명하는 과정을 평가하는 면접입니다.

면접관이 보려는 핵심은 보통 다음과 같습니다.

문제 정의 능력: 무엇을 만들고 무엇은 이번 범위에서 제외할지 정리하는가
구조화 능력: 큰 문제를 API, 애플리케이션, 데이터 저장소, 비동기 처리, 운영 요소로 나눌 수 있는가
우선순위 판단: 성능, 일관성, 비용, 개발 속도 중 무엇을 우선할지 설명하는가
실무 감각: 장애, 배포, 모니터링, 보안 같은 운영 포인트까지 같이 보는가

즉, 좋은 답변은 “정교한 아키텍처 그림”보다 왜 이런 선택을 했는지 설명 가능한 답변입니다.

요구사항 정리부터 시작하는 이유

시스템 디자인에서 가장 흔한 실수는 곧바로 기술 스택을 말하는 것입니다.
면접에서는 먼저 요구사항을 정리해야 이후 선택이 자연스러워집니다.

요구사항은 보통 두 축으로 나눕니다.

기능적 요구사항 (Functional Requirements): 사용자가 무엇을 할 수 있어야 하는가
비기능적 요구사항 (Non-Functional Requirements): 얼마나 빠르고, 얼마나 안정적이고, 얼마나 확장 가능해야 하는가

예를 들어 URL 단축기 설계 문제라면 다음처럼 정리할 수 있습니다.

기능적 요구사항
- 긴 URL을 짧은 URL로 변환
- 짧은 URL로 접속 시 원본 URL로 리다이렉트
- 만료 정책 또는 커스텀 별칭 지원 여부
비기능적 요구사항
- 읽기 요청이 쓰기 요청보다 훨씬 많음
- 짧은 지연 시간 필요
- 충돌 없는 키 생성 필요
- 장애 시에도 리다이렉트는 최대한 유지해야 함

면접에서 이 단계를 먼저 보여주면, 이후 설계가 “내가 떠올린 기술”이 아니라 요구사항에서 자연스럽게 도출된 구조처럼 보입니다.

규모 추정과 병목 예측

시스템 디자인은 숫자를 완벽히 맞히는 시험이 아니라, 대략의 규모를 근거 있게 추정하는 능력을 보는 경우가 많습니다.

보통 다음 항목을 빠르게 추정합니다.

DAU / MAU: 하루 또는 한 달 활성 사용자 수
QPS / TPS: 초당 요청 수
읽기/쓰기 비율: 캐시, 복제, 큐 필요성을 판단하는 기준
데이터 크기: 스토리지와 파티셔닝 필요성 판단
트래픽 피크: 평균이 아니라 피크 구간을 감당할 수 있는지 확인

항목	왜 필요한가	예시 질문
QPS	서버 수와 오토스케일 기준 판단	초당 몇 건을 처리해야 하는가
읽기/쓰기 비율	캐시, 복제본 전략 판단	조회가 90%인가, 쓰기가 많은가
저장 용량	스토리지와 보관 정책 판단	1년 뒤 데이터가 얼마나 쌓이는가
피크 배수	순간 부하 대응 판단	평시 대비 몇 배까지 치솟는가

중요한 점은 숫자 자체보다 그 숫자가 어떤 설계 결정을 밀어내는지 설명하는 것입니다.

읽기가 압도적으로 많으면 캐시와 읽기 복제본을 먼저 검토
쓰기가 많고 충돌이 심하면 파티셔닝 키와 큐 기반 비동기화를 검토
데이터 증가 속도가 빠르면 아카이빙과 파티셔닝을 함께 검토

핵심 컴포넌트 나누기

시스템을 설명할 때는 한 번에 모든 것을 말하기보다, 핵심 컴포넌트로 나눠서 설명하는 편이 좋습니다.

대표적으로 다음 단위로 나눌 수 있습니다.

클라이언트: 웹, 모바일, 내부 서비스
진입 계층: DNS, CDN, 로드 밸런서, API Gateway
애플리케이션 계층: 인증, 비즈니스 로직, 조합 서비스
데이터 계층: RDBMS, NoSQL, 캐시, 검색 엔진, 오브젝트 스토리지
비동기 계층: 메시지 큐, 이벤트 스트림, 배치 처리
운영 계층: 모니터링, 로깅, 알림, 배포, 보안

이 구조를 빠르게 잡아두면 면접관이 후속 질문을 던져도 어느 층 이야기인지 정리하기 쉽습니다.

또한 컴포넌트를 나눌 때는 같은 기능끼리만 묶지 말고,
어느 실패 도메인에 배치할지까지 같이 생각하는 편이 좋습니다.¹²

예를 들어 “트래픽이 급증하면?”이라는 질문은 보통 진입 계층과 애플리케이션 계층 이야기이고,
“데이터가 커지면?”은 데이터 계층 이야기로 분리해 답할 수 있습니다.

데이터 흐름과 저장 전략 정하기

면접 답변이 강해지려면 컴포넌트 이름만 나열하지 말고, 요청이 어떻게 흘러가고 어디에 저장되는지까지 보여줘야 합니다.

확인할 포인트는 다음과 같습니다.

동기 호출인가, 비동기 처리인가
강한 일관성이 필요한가, 최종적 일관성으로 충분한가
데이터를 어디까지 정규화할 것인가
읽기 최적화와 쓰기 최적화 중 무엇이 중요한가

예를 들어 주문 시스템이라면:

사용자가 주문 요청을 보낸다
주문 서비스가 주문을 기록한다
결제와 알림은 메시지 큐나 이벤트로 비동기 처리한다
조회 API는 캐시나 읽기 모델을 따로 둔다

이런 흐름이 있으면 자연스럽게 다음 주제를 연결할 수 있습니다.

데이터베이스 선택 기준
캐시 배치 위치
메시징 시스템 필요성
재시도와 중복 처리 전략

관련 주제는 캐싱, 데이터베이스 스케일링, 메시징 시스템 문서와도 이어집니다.

장애 지점과 운영 포인트 점검

초기 구조를 말한 뒤에는 반드시 어디가 깨질 수 있는지 짚어야 합니다.
이 단계가 없으면 설계가 교과서식 답변으로 보이기 쉽습니다.

대표 점검 항목은 다음과 같습니다.

단일 장애점 (SPOF): 단일 DB, 단일 캐시 노드, 단일 로드 밸런서
백프레셔: 다운스트림이 느려질 때 요청이 쌓이는 문제
재시도 폭주: 타임아웃 후 무작정 재시도해 전체 장애가 커지는 문제
장애 전파: 한 서비스의 지연이 다른 서비스 전체에 번지는 문제
관측성 부족: 장애가 나도 어디서 병목인지 찾기 어려운 상태

이때 자주 같이 언급하는 운영 포인트는 다음입니다.

헬스 체크와 오토스케일링
로그, 메트릭, 트레이스
알림 임계치와 런북
배포 전략과 롤백

실무형 답변은 “정상 상태에서 잘 동작한다”가 아니라
느려질 때, 일부가 실패할 때, 특정 의존성이 죽을 때 어떻게 버틸지까지 포함합니다.

트레이드오프를 설명하는 방법

시스템 디자인 면접에서 높은 평가를 받는 답변은 보통 선택지를 비교합니다.
한쪽만 일방적으로 좋다고 말하면 설계가 단순해 보입니다.

의사결정	빠른 선택	대가
강한 일관성 우선	단일 DB 트랜잭션, 동기 처리	지연 증가, 확장성 제약
가용성 우선	비동기 처리, 큐, 재시도	일시적 불일치, 복잡도 증가
단순한 운영 우선	관리형 서비스, 모놀리식 출발	세밀한 제어 한계
최대 성능 우선	캐시, 샤딩, 비정규화	데이터 일관성, 운영 난이도 증가

좋은 설명 방식은 다음 순서입니다.

무엇을 우선할지 말한다
왜 그렇게 선택했는지 요구사항과 연결한다
무엇을 포기하는지 인정한다
나중에 언제 구조를 바꿀지 말한다

예를 들어:

초기에 모놀리식으로 시작하는 이유
트래픽이 커지면 캐시와 큐를 먼저 붙이는 이유
그 이후에 샤딩이나 서비스 분리를 검토하는 이유

이 흐름이 있으면 설계가 훨씬 설득력 있어집니다.

면접에서 답변을 구성하는 순서

실전에서는 다음 순서로 답변하면 안정적입니다.

문제와 범위를 다시 정리한다
기능적/비기능적 요구사항을 확인한다
대략의 트래픽과 데이터 규모를 추정한다
고수준 아키텍처를 제시한다
핵심 컴포넌트와 데이터 흐름을 설명한다
병목과 장애 대응을 짚는다
트레이드오프와 확장 방향을 말한다

이 순서를 지키면 면접관이 중간에 끼어들어도 답변이 흐트러지지 않습니다.

면접 포인트

시스템 디자인은 기술 나열보다 요구사항 해석과 우선순위 판단을 보는 면접입니다.
처음부터 샤딩이나 마이크로서비스를 말하기보다, 왜 그 단계가 필요한지 설명하는 편이 좋습니다.
숫자는 완벽하지 않아도 되지만, 규모 추정이 설계 결정으로 연결돼야 합니다.
좋은 설계 답변은 정상 경로뿐 아니라 장애와 운영 포인트를 포함합니다.
트레이드오프를 명확히 말하면 답변이 훨씬 실무적으로 보입니다.