실전 유튜브 시스템 설계로 정복하는 대규모 아키텍처 - Dev.

FAANG(이제는 MAMA - Meta, Apple, Microsoft, Amazon)급의 빅테크 기업 입사를 꿈꾸는 개발자라면 반드시 넘어야 할 산이 있습니다. 바로 '시스템 디자인 인터뷰'입니다. 코딩 테스트가 알고리즘과 자료구조에 대한 탄탄한 기본기를 검증한다면, 시스템 디자인 인터뷰는 대규모 트래픽을 감당할 수 있는 안정적이고 확장 가능한 시스템을 설계할 수 있는 아키텍트로서의 역량을 평가합니다. 수많은 지원자들이 이 단계에서 고배를 마시는 이유는 단순히 기술적 지식을 암기하는 것만으로는 부족하기 때문입니다. 정답이 없는 문제에 대해 합리적인 가정을 세우고, 트레이드오프를 명확히 인지하며, 면접관과 효과적으로 소통하는 능력이 핵심입니다. 이 글에서는 풀스택 개발자의 관점에서 가장 대표적인 시스템 디자인 문제인 '유튜브와 같은 대규모 동영상 스트리밍 서비스 설계하기'를 통해 대규모 시스템 설계의 모든 것을 파헤쳐 보겠습니다. 이 글을 끝까지 읽으신다면, 여러분은 단순한 기술 나열을 넘어, 자신만의 논리로 시스템을 구축하고 FAANG 기술 면접에 자신감 있게 임할 수 있게 될 것입니다.

이 글의 목표: 이 가이드는 단순히 유튜브의 아키텍처를 설명하는 것을 넘어, 왜 그러한 설계 결정이 내려졌는지, 어떤 대안들이 있었고 각 선택의 장단점은 무엇인지(Trade-offs)를 심도 있게 다룹니다. 실제 기술 면접 상황처럼 단계별로 시스템을 구체화해 나가며 대규모 시스템 설계에 대한 감각을 익히는 데 초점을 맞춥니다.

1. 요구사항 분석 및 제약 조건 설정: 모든 설계의 첫 단추

성공적인 시스템 디자인 인터뷰의 시작은 '질문'입니다. 면접관이 "유튜브 같은 시스템을 설계해 보세요"라고 했을 때, 바로 화이트보드에 아키텍처를 그리기 시작하면 십중팔구 실패합니다. 먼저 시스템의 범위를 명확히 하고, 기능적/비기능적 요구사항을 구체화해야 합니다. 이는 우리가 풀어야 할 문제의 경계를 설정하고, 설계의 방향을 결정하는 나침반 역할을 합니다.

기능적 요구사항 (Functional Requirements)

사용자가 시스템을 통해 직접적으로 수행할 수 있는 기능들입니다. 처음부터 모든 기능을 완벽하게 구현하려 하기보다는, 핵심 기능(Core Features)에 집중하고 점진적으로 확장하는 방향으로 논의를 이끌어 가는 것이 좋습니다.

• 동영상 업로드: 사용자는 자신의 동영상을 플랫폼에 업로드할 수 있어야 한다.
• 동영상 스트리밍: 사용자는 업로드된 동영상을 지연 없이 시청할 수 있어야 한다.
• 검색: 사용자는 키워드를 통해 원하는 동영상을 찾을 수 있어야 한다.
• 댓글: 사용자는 동영상에 댓글을 작성하고 다른 사람의 댓글을 볼 수 있어야 한다.
• 사용자 채널 및 구독: 각 사용자는 자신의 채널을 가지며, 다른 사용자의 채널을 구독할 수 있어야 한다.
• 추천 피드: 사용자는 홈 화면에서 개인화된 동영상 추천 피드를 볼 수 있어야 한다.
• 좋아요/싫어요 및 조회수: 사용자는 동영상에 대한 반응을 표시할 수 있으며, 시스템은 조회수를 집계해야 한다.

비기능적 요구사항 (Non-functional Requirements)

시스템의 품질과 성능에 관련된 요구사항들입니다. 대규모 시스템의 성패는 이 비기능적 요구사항을 얼마나 잘 만족시키는지에 달려있다고 해도 과언이 아닙니다. 이것이 바로 FAANG과 같은 기업들이 가장 중요하게 평가하는 부분이기도 합니다.

• 고가용성 (High Availability): 시스템은 연중무휴 24/7 운영되어야 한다. 일부 컴포넌트에 장애가 발생하더라도 전체 서비스 중단으로 이어져서는 안 된다. 목표 가용성 수치를 구체적으로 제시하는 것이 좋습니다 (예: 99.99%).
• 낮은 지연 시간 (Low Latency): 동영상 시청 시 버퍼링이 최소화되어야 하며, 첫 프레임이 나타나기까지의 시간(Time to First Frame)이 매우 짧아야 한다. 웹사이트와 API 응답 속도 또한 빨라야 한다.
• 확장성 (Scalability): 사용자 수와 데이터 양이 급격히 증가하더라도 시스템은 성능 저하 없이 원활하게 서비스를 제공할 수 있어야 한다. 수평적 확장이 용이한 구조여야 한다.
• 내구성 (Durability): 사용자가 업로드한 동영상은 절대 유실되어서는 안 된다. 데이터는 여러 지역에 걸쳐 안전하게 백업 및 복제되어야 한다. 목표 내구성 수치(예: 99.999999999%)를 언급하면 좋습니다.
• 일관성 (Consistency):
  • 강한 일관성 (Strong Consistency): 동영상 업로드 후 즉시 모든 사용자가 볼 수 있어야 하는 등, 데이터의 정합성이 매우 중요한 부분에서는 필요합니다.
  • 최종 일관성 (Eventual Consistency): 조회수, 좋아요 수, 댓글 등은 약간의 지연이 허용됩니다. 모든 사용자에게 최신 데이터가 반영되기까지 시간이 좀 걸려도 괜찮은 경우, 최종 일관성 모델을 채택하여 시스템의 가용성과 성능을 높일 수 있습니다. CAP 이론과 연관 지어 설명하면 좋은 점수를 받을 수 있습니다.

규모 추정 (Back-of-the-envelope calculation)

요구사항을 바탕으로 시스템이 감당해야 할 트래픽과 데이터의 양을 대략적으로 계산해 보는 과정입니다. 이 단계는 앞으로 우리가 설계할 시스템의 컴포넌트 용량과 기술 스택을 결정하는 데 매우 중요한 근거가 됩니다. 정답을 맞히는 것이 아니라, 논리적으로 추론하는 과정을 보여주는 것이 핵심입니다.

면접관과의 소통: 이 모든 과정은 혼자만의 생각이 아닌, 면접관과 끊임없이 대화하며 진행해야 합니다. "월간 활성 사용자(MAU)를 10억 명으로 가정해도 될까요?", "하루 평균 동영상 업로드 수를 5천만 개로 가정하고 계산을 진행하겠습니다." 와 같이 가정을 먼저 제시하고 동의를 구하는 자세가 중요합니다.

항목	가정	계산	결과
활성 사용자 (DAU)	총 사용자 10억 명, 그 중 30%가 매일 접속	1,000,000,000 * 0.3	3억 명
하루 평균 시청 시간	사용자당 하루 평균 10개의 동영상 시청	300,000,000 * 10	하루 30억 회 조회
초당 읽기 요청 (Read QPS)	하루 30억 조회를 초 단위로 변환	3,000,000,000 / (24 * 3600)	약 35,000 QPS (평균)
하루 동영상 업로드 수	사용자 100명 중 1명이 하루에 1개 업로드	300,000,000 / 100	하루 300만 개 업로드
초당 쓰기 요청 (Write QPS)	하루 300만 업로드를 초 단위로 변환	3,000,000 / (24 * 3600)	약 35 QPS (평균)
읽기:쓰기 비율	35,000 QPS : 35 QPS	-	1000 : 1 (읽기 중심 서비스)
스토리지 요구량 (1년)	평균 동영상 길이 5분, 1080p 기준 분당 100MB	3,000,000개/일 * 5분 * 100MB/분 * 365일	연간 약 550 페타바이트 (PB)
네트워크 대역폭 (Egress)	평균 비트레이트 5Mbps, 동시 시청자 1,000만 명 가정	10,000,000 * 5 Mbps	50 Tbps (Terabits per second)

이 계산을 통해 우리는 몇 가지 중요한 사실을 알 수 있습니다. 첫째, 읽기 요청이 쓰기 요청보다 압도적으로 많다는 것(Read-heavy). 둘째, 매년 수백 페타바이트의 데이터가 쌓이는, 즉 스토리지 요구량이 엄청나다는 것. 셋째, 서비스 제공을 위한 네트워크 대역폭이 상상을 초월한다는 것입니다. 이 모든 특성은 우리의 시스템 설계 방향에 직접적인 영향을 미칩니다.

2. 개략적인 시스템 설계 (High-Level Design)

요구사항과 규모 추정이 끝났다면, 이제 전체 시스템의 뼈대를 그려볼 차례입니다. 처음부터 모든 세부사항을 완벽하게 그릴 필요는 없습니다. 주요 컴포넌트들을 블록 다이어그램 형태로 배치하고 데이터가 어떻게 흐르는지를 보여주는 것만으로도 충분합니다. 이 단계에서는 각 컴포넌트의 역할을 명확히 설명하고, 왜 이런 구조를 선택했는지에 대한 근거를 제시하는 것이 중요합니다.

위 다이어그램을 기반으로 각 컴포넌트의 역할을 살펴보겠습니다.

1. 클라이언트 (Client): 사용자가 상호작용하는 인터페이스입니다. 웹 브라우저, 모바일 앱(iOS, Android) 등이 해당됩니다.
2. 로드 밸런서 (Load Balancer): 사용자의 모든 요청을 가장 먼저 받는 관문입니다. L4/L7 로드 밸런서를 사용하여 들어오는 트래픽을 여러 웹 서버로 분산시켜 특정 서버에 과부하가 걸리는 것을 방지하고, 서버 장애 시 해당 서버를 트래픽 분산 대상에서 제외하여 가용성을 높입니다.
3. API 게이트웨이 (API Gateway): 클라이언트의 요청을 받아 적절한 마이크로서비스로 라우팅하는 역할을 합니다. 인증, 권한 부여, 로깅, 캐싱, 요청 속도 제한(Rate Limiting)과 같은 공통 기능을 처리하여 각 마이크로서비스의 부담을 줄여줍니다.
4. 마이크로서비스 (Microservices): 시스템의 전체 기능을 작은 독립적인 서비스 단위로 분리한 것입니다. 예를 들어, 사용자 관리 서비스, 동영상 업로드 서비스, 스트리밍 서비스, 검색 서비스, 추천 서비스 등으로 나눌 수 있습니다. 각 서비스는 독립적으로 개발, 배포, 확장이 가능하여 대규모 시스템의 복잡성을 관리하는 데 매우 효과적입니다.
5. 데이터베이스 (Databases):
   • 메타데이터 DB (Metadata DB): 동영상의 제목, 설명, 업로더 정보, 댓글, 좋아요 수 등 정형화된 데이터를 저장합니다. 관계형 데이터베이스(RDBMS, 예: MySQL, PostgreSQL)가 주로 사용됩니다.
   • NoSQL DB: 사용자 활동 로그, 추천 데이터, 분석 데이터 등 대량의 비정형 데이터를 저장하고 빠르게 처리하는 데 사용됩니다 (예: Cassandra, DynamoDB).
6. 객체 스토리지 (Object Storage): 원본 동영상 파일과 트랜스코딩된 동영상 파일들을 저장하는 곳입니다. 파일 시스템과 달리 확장성이 거의 무한에 가깝고, 내구성이 매우 높아 대용량 미디어 파일을 저장하기에 최적입니다 (예: Amazon S3, Google Cloud Storage).
7. 트랜스코딩 서비스 (Transcoding Service): 사용자가 업로드한 원본 동영상을 다양한 해상도(2160p, 1080p, 720p 등)와 포맷(HLS, DASH)으로 변환하는 역할을 합니다. 이는 사용자의 네트워크 환경에 맞춰 최적의 화질을 제공하는 적응형 비트레이트 스트리밍(Adaptive Bitrate Streaming)을 위해 필수적입니다.
8. 콘텐츠 전송 네트워크 (CDN - Content Delivery Network): 트랜스코딩된 동영상 파일을 전 세계에 분산된 엣지 서버(Edge Server)에 캐싱하여 사용자와 가장 가까운 위치에서 동영상을 전송합니다. 이를 통해 스트리밍 지연 시간을 획기적으로 줄이고, 원본 서버(Origin Server)의 부하를 최소화합니다. 유튜브 시스템 설계의 핵심 중 하나입니다.
9. 메시지 큐 (Message Queue): 서비스 간의 비동기 통신을 위해 사용됩니다 (예: RabbitMQ, Apache Kafka). 예를 들어, 동영상 업로드가 완료되면 '업로드 서비스'가 메시지 큐에 "새 동영상 처리 필요"라는 메시지를 넣고, '트랜스코딩 서비스'의 워커(Worker)들이 이 메시지를 가져가 작업을 수행합니다. 이를 통해 서비스 간의 의존성(결합도)을 낮추고, 특정 서비스에 장애가 발생해도 전체 시스템에 미치는 영향을 최소화할 수 있습니다.
10. 캐시 (Cache): 자주 사용되는 데이터를 메모리에 저장하여 데이터베이스 접근을 줄이고 응답 속도를 향상시킵니다 (예: Redis, Memcached). 인기 동영상 메타데이터, 사용자 세션 정보, 추천 목록 등을 캐싱할 수 있습니다.

이 개략적인 설계는 대규모 시스템의 기본 골격을 보여줍니다. 이제 각 핵심 컴포넌트들이 실제로 어떻게 동작하고 어떤 기술적 과제들을 해결해야 하는지 더 깊이 파고들어 보겠습니다.

3. 핵심 컴포넌트 심층 분석: 동영상 업로드 및 처리 파이프라인

유튜브와 같은 서비스에서 동영상이 사용자에게 보여지기까지의 과정은 단순히 파일을 서버에 복사하는 것 이상으로 복잡합니다. 안정적이고 효율적인 업로드 및 처리 파이프라인을 구축하는 것은 전체 시스템의 성능과 직결됩니다. 이 과정은 크게 '업로드', '비동기 처리', '트랜스코딩'의 세 단계로 나눌 수 있습니다.

Step 1: 동영상 업로드

사용자가 클라이언트(웹/앱)에서 동영상 파일을 선택하고 '업로드' 버튼을 누르는 순간부터 파이프라인이 시작됩니다. 수백 MB에서 수 GB에 달하는 대용량 파일을 안정적으로 전송하는 것이 중요합니다.

1. 클라이언트의 역할:
   • Resumable Uploads (이어 올리기): 네트워크가 불안정하여 업로드가 중단되더라도 처음부터 다시 시작하는 것이 아니라, 중단된 지점부터 이어서 업로드할 수 있어야 합니다. 이를 위해 클라이언트는 파일을 작은 청크(chunk) 단위로 나누어 순차적으로 전송하고, 각 청크의 전송 성공 여부를 확인합니다.
   • 메타데이터 전송: 동영상 파일과 함께 제목, 설명, 태그 등의 메타데이터도 함께 API 서버로 전송합니다.
2. API 서버의 역할:
   • 인증 및 권한 확인: 업로드 요청을 보낸 사용자가 유효한 사용자인지, 업로드할 권한이 있는지 확인합니다.
   • 임시 저장소 위치 제공: 인증이 완료되면, 클라이언트가 동영상 파일을 직접 업로드할 수 있는 임시 객체 스토리지(예: S3 Pre-signed URL)의 주소를 발급해 줍니다. 이렇게 하면 대용량 파일 트래픽이 API 서버를 직접 거치지 않으므로 서버의 부하를 크게 줄일 수 있습니다.
3. 객체 스토리지 (Raw Video Storage): 클라이언트는 API 서버로부터 받은 주소를 이용해 동영상 원본 파일을 객체 스토리지의 특정 버킷(bucket)에 직접 업로드합니다. 객체 스토리지는 내구성과 확장성이 매우 뛰어나 원본 파일을 안전하게 보관하는 데 최적입니다.

Step 2: 비동기 처리 시작 (메시지 큐 활용)

동영상 업로드가 완료되면, 이제 후처리 작업인 '트랜스코딩'을 시작해야 합니다. 트랜스코딩은 CPU 자원을 많이 소모하고 시간이 오래 걸리는 작업이므로, 업로드 요청을 처리하는 API 서버가 직접 수행해서는 안 됩니다. 만약 동기적으로 처리한다면 사용자는 트랜스코딩이 끝날 때까지 하염없이 기다려야 하고, API 서버는 다른 요청을 처리하지 못하게 될 것입니다.

"시스템 설계에서 응답 시간이 긴 작업은 항상 비동기적으로 처리하는 것을 고려해야 합니다. 이는 시스템의 반응성과 가용성을 높이는 핵심 원칙입니다." A Senior Software Engineer

이 문제를 해결하기 위해 메시지 큐를 사용합니다.

1. 업로드가 완료되면, API 서버는 동영상 ID, 원본 파일 위치(객체 스토리지 주소) 등의 정보가 담긴 메시지를 메시지 큐 (예: Kafka, RabbitMQ)의 특정 토픽(Topic)이나 큐(Queue)에 발행(Publish)합니다.
2. 메시지를 발행한 후, API 서버는 즉시 클라이언트에게 "업로드가 성공적으로 시작되었습니다. 처리 중입니다."와 같은 응답을 보냅니다. 사용자는 이제 다른 활동을 할 수 있습니다.
3. 이러한 아키텍처는 업로드 서비스와 트랜스코딩 서비스를 완전히 분리(Decoupling)시킵니다. 트랜스코딩 서버 그룹에 장애가 발생하더라도 업로드 기능 자체는 영향을 받지 않고 계속 동작할 수 있습니다. 메시지 큐가 장애가 발생한 동안 메시지를 안전하게 보관해주기 때문입니다.

Step 3: 트랜스코딩 파이프라인

이제 메시지 큐에 쌓인 작업들을 처리할 차례입니다. 별도의 서버들로 구성된 트랜스코딩 서비스가 이 역할을 담당합니다.

1. 워커(Worker) 프로세스: 트랜스코딩 서버들(워커 팜, Worker Farm)은 메시지 큐를 계속 주시(Subscribe)하고 있다가, 새로운 작업 메시지가 들어오면 하나씩 가져옵니다(Consume).
2. 원본 파일 다운로드: 워커는 메시지에 담긴 정보를 바탕으로 객체 스토리지에서 원본 동영상 파일을 다운로드합니다.
3. 트랜스코딩 실행:
   • 다양한 해상도/품질 생성: FFmpeg과 같은 도구를 사용하여 원본 영상을 2160p, 1080p, 720p, 480p 등 다양한 해상도의 파일들로 인코딩합니다.
   • 적응형 비트레이트 스트리밍 포맷 생성: 인코딩된 파일들을 HLS(HTTP Live Streaming)나 MPEG-DASH(Dynamic Adaptive Streaming over HTTP)와 같은 스트리밍 프로토콜에 맞게 작은 세그먼트(segment, 보통 몇 초 길이의 ts 파일)와 매니페스트(manifest, m3u8 파일 등) 파일로 분할합니다. 매니페스트 파일은 각 세그먼트의 위치와 재생 순서, 사용 가능한 화질 목록 등의 정보를 담고 있습니다.
   • 썸네일 추출: 동영상의 특정 프레임들을 추출하여 다양한 크기의 썸네일 이미지를 생성합니다.
4. 처리된 파일 업로드: 트랜스코딩과 썸네일 생성이 완료된 모든 파일들(세그먼트, 매니페스트, 썸네일 이미지)을 최종 사용자에게 서비스될 영구 객체 스토리지 버킷에 업로드합니다. 이 버킷은 보통 CDN과 연결되어 있습니다.
5. 메타데이터 데이터베이스 업데이트: 마지막으로, 워커는 메타데이터 DB에 해당 동영상의 처리 상태를 '완료'로 변경하고, 생성된 매니페스트 파일의 CDN URL, 썸네일 URL 등을 저장합니다. 이제 이 동영상은 사용자에게 보여질 준비가 된 것입니다.

확장성 확보: 이 파이프라인은 확장성이 매우 뛰어납니다. 동영상 업로드 양이 늘어나면 메시지 큐에 작업이 쌓이게 되고, 우리는 단순히 트랜스코딩 워커 서버의 수만 늘려주면(Scale-out) 병목 현상 없이 처리량을 늘릴 수 있습니다. 클라우드 환경에서는 오토 스케일링(Auto Scaling)을 설정하여 큐의 길이에 따라 자동으로 워커 인스턴스 수를 조절할 수도 있습니다.

4. 동영상 스트리밍 아키텍처: CDN의 마법

앞서 계산했듯이 유튜브는 초당 수십 테라비트(Tbps)에 달하는 엄청난 양의 트래픽을 처리해야 합니다. 만약 이 모든 트래픽을 중앙 데이터 센터에서 직접 감당한다면, 네트워크 비용은 천문학적으로 치솟을 것이고 전 세계 사용자들은 끔찍한 버퍼링을 경험하게 될 것입니다. 이 문제를 해결하는 기술이 바로 CDN(콘텐츠 전송 네트워크)입니다.

CDN의 역할과 동작 원리

CDN은 지리적으로 분산된 여러 개의 캐시 서버(엣지 서버, Edge Server)로 구성된 네트워크입니다. 원본 서버(Origin Server, 여기서는 우리의 동영상 파일이 저장된 객체 스토리지)의 콘텐츠를 복제하여 사용자와 가장 가까운 엣지 서버에 저장해 둡니다. 사용자가 콘텐츠를 요청하면, 원본 서버가 아닌 가장 가까운 엣지 서버에서 콘텐츠를 전송받게 됩니다.

동영상 스트리밍 과정은 다음과 같습니다.

1. 사용자가 동영상 재생을 클릭합니다. 클라이언트(브라우저/앱)는 우리 시스템의 API 서버에 특정 동영상에 대한 재생 정보를 요청합니다.
2. API 서버가 메타데이터를 응답합니다. API 서버는 메타데이터 DB에서 동영상 정보를 조회한 후, 스트리밍에 필요한 정보, 특히 매니페스트 파일의 CDN URL을 클라이언트에게 전달합니다.
3. 클라이언트가 CDN에 매니페스트 파일을 요청합니다. 클라이언트의 비디오 플레이어는 전달받은 URL을 이용해 CDN에 매니페스트 파일(예: `.m3u8`)을 요청합니다. DNS는 요청을 보낸 사용자의 위치를 기반으로 가장 가까운 CDN 엣지 서버의 IP 주소를 알려줍니다.
4. CDN 엣지 서버가 응답합니다.
   • 만약 요청받은 매니페스트 파일이 엣지 서버의 캐시에 존재한다면, 즉시 사용자에게 전송합니다.
   • 만약 캐시에 없다면(Cache Miss), 엣지 서버는 원본 스토리지 서버에 파일을 요청하여 받아온 후, 자신의 캐시에 저장하고 사용자에게 전송합니다. 이후 같은 파일을 요청하는 다른 사용자들은 캐시된 버전을 받게 됩니다.
5. 비디오 플레이어가 세그먼트 파일을 순차적으로 요청합니다. 플레이어는 매니페스트 파일의 내용을 파싱하여 재생할 동영상 세그먼트 파일들의 목록을 확인하고, 첫 번째 세그먼트부터 순서대로 CDN에 요청하여 다운로드하고 재생합니다. 이 과정을 계속 반복하며 동영상을 끊김 없이 보여줍니다.

적응형 비트레이트 스트리밍 (Adaptive Bitrate Streaming)

CDN은 단순히 콘텐츠를 가까운 곳에서 전달하는 것 이상의 역할을 합니다. 최신 스트리밍 기술의 핵심인 '적응형 비트레이트 스트리밍'을 가능하게 합니다.

• 매니페스트 파일에는 1080p, 720p, 480p 등 다양한 화질(비트레이트) 버전의 스트림 정보가 모두 포함되어 있습니다.
• 비디오 플레이어는 동영상을 재생하면서 사용자의 현재 네트워크 대역폭과 CPU 성능을 지속적으로 모니터링합니다.
• 네트워크 상태가 좋으면 고화질(높은 비트레이트) 스트림의 세그먼트를 요청하고, 상태가 나빠지면(예: 지하철에서 LTE 신호가 약해질 때) 버퍼링이 발생하기 전에 저화질(낮은 비트레이트) 스트림으로 자연스럽게 전환하여 끊김 없는 시청 경험을 제공합니다.
• 이 모든 전환 과정은 플레이어 단에서 자동으로 이루어지며, 사용자는 거의 인지하지 못합니다.

결론적으로, 대규모 동영상 스트리밍 서비스에서 CDN은 선택이 아닌 필수입니다. CDN을 통해 네트워크 지연 시간을 최소화하고, 원본 서버의 부하를 90% 이상 줄이며, 전 세계 사용자에게 안정적인 시청 경험을 제공할 수 있습니다. 이는 시스템 디자인 인터뷰에서 반드시 강조해야 할 포인트입니다.

5. 데이터베이스 설계와 확장 전략: 대규모 데이터의 저장과 관리

대규모 시스템의 데이터베이스는 수십억 개의 레코드와 초당 수만 건의 요청을 처리해야 합니다. 단일 데이터베이스 서버로는 이러한 부하를 감당할 수 없으므로, 데이터의 특성에 맞는 데이터베이스를 선택하고 수평적으로 확장할 수 있는 전략을 마련해야 합니다. 이는 FAANG 기술 면접에서 지원자의 데이터베이스에 대한 깊이 있는 이해도를 평가하는 중요한 척도입니다.

데이터 모델링과 데이터베이스 선택

먼저 어떤 데이터를 저장해야 할지 정의하고, 각 데이터의 특성에 맞는 데이터베이스 기술을 선택해야 합니다.

데이터 모델 (예시)

• Users: `user_id` (PK), `name`, `email`, `password_hash`, `created_at`
• Videos: `video_id` (PK), `user_id` (FK), `title`, `description`, `status` (uploading, processing, public), `cdn_url`, `created_at`
• Comments: `comment_id` (PK), `video_id` (FK), `user_id` (FK), `content`, `created_at`
• Subscriptions: `subscriber_id` (FK, user_id), `channel_id` (FK, user_id)
• Likes: `user_id` (FK), `video_id` (FK), `type` (like/dislike)

SQL vs. NoSQL: 무엇을 선택할 것인가?

모든 데이터를 하나의 데이터베이스에 저장하는 것은 좋은 생각이 아닙니다. 각 데이터의 특성(정형/비정형, 읽기/쓰기 패턴, 일관성 요구사항)에 따라 적합한 데이터베이스를 사용하는 폴리글랏 퍼시스턴스(Polyglot Persistence) 접근 방식이 효과적입니다.

데이터 종류	특징	추천 데이터베이스	선택 이유
사용자 정보, 동영상 메타데이터	정형 데이터, 트랜잭션 필요(예: 채널 구독), 데이터 간의 관계(Join) 중요	SQL (RDBMS) (MySQL, PostgreSQL)	데이터의 정합성과 일관성을 보장하는 ACID 트랜잭션을 지원합니다. 스키마가 명확하여 데이터 무결성을 유지하기 용이합니다.
댓글, 사용자 활동 로그	쓰기 작업이 매우 빈번함, 엄청난 양의 데이터, 스키마가 유연할 수 있음	NoSQL (Wide-column) (Cassandra, HBase)	쓰기 성능이 뛰어나고 수평적 확장이 매우 용이하여 대량의 데이터를 분산 저장하는 데 최적화되어 있습니다. 최종 일관성 모델을 사용합니다.
추천 피드, 소셜 그래프(구독 관계)	특정 사용자에 대한 빠른 데이터 조회 필요, 데이터 간의 복잡한 관계 표현	NoSQL (Key-value 또는 Graph) (Redis, Neo4j)	Key-value 스토어는 특정 키에 대한 조회 속도가 매우 빠릅니다. Graph DB는 친구 관계나 구독 관계처럼 노드와 엣지로 구성된 데이터를 효율적으로 처리합니다.

데이터베이스 확장 전략 (Scaling the Database)

데이터베이스를 선택했다면, 이제 트래픽 증가에 따라 어떻게 확장할 것인지에 대한 계획을 세워야 합니다. 크게 수직 확장(Scale-up)과 수평 확장(Scale-out)이 있지만, 대규모 시스템에서는 수평 확장이 필수적입니다.

1. 읽기 부하 분산: 복제 (Replication)

앞서 분석했듯이 우리 시스템은 읽기 요청이 쓰기 요청보다 훨씬 많습니다(Read-heavy). 이 경우, 단일 마스터(Master) 데이터베이스와 여러 개의 슬레이브(Slave) 또는 복제본(Replica) 데이터베이스를 두는 'Master-Slave Replication' 구조가 효과적입니다.

• 쓰기 작업(INSERT, UPDATE, DELETE)은 모두 마스터 데이터베이스에서만 수행됩니다.
• 마스터에서 변경된 내용은 비동기적으로 모든 슬레이브 데이터베이스에 복제됩니다.
• 읽기 작업(SELECT)은 여러 슬레이브 데이터베이스로 분산됩니다.
• 이를 통해 읽기 요청에 대한 처리량을 슬레이브의 수에 비례하여 늘릴 수 있습니다.

복제 지연 (Replication Lag): 비동기 복제 방식에서는 마스터의 변경 사항이 슬레이브에 반영되기까지 약간의 시간 지연이 발생할 수 있습니다. 이로 인해 사용자가 글을 쓴 직후에 자신의 글이 보이지 않는 등의 문제가 발생할 수 있습니다. 이런 경우, 글을 쓴 사용자 본인의 읽기 요청은 마스터로 보내고, 다른 사용자의 요청만 슬레이브로 보내는 등의 전략을 사용할 수 있습니다.

2. 쓰기 부하 분산 및 데이터 파티셔닝: 샤딩 (Sharding)

사용자 수가 수억 명에 달하면, 동영상 메타데이터 테이블 하나만 해도 수십억 개의 행을 갖게 됩니다. 하나의 마스터 데이터베이스로는 더 이상 쓰기 부하와 데이터 용량을 감당할 수 없는 시점이 옵니다. 이 문제를 해결하기 위한 기술이 바로 샤딩입니다.

샤딩은 하나의 거대한 데이터베이스를 '샤드(Shard)'라고 불리는 여러 개의 작은 데이터베이스로 분할하는 기술입니다. 각 샤드는 전체 데이터의 일부만을 저장하며, 독립적인 서버에서 운영됩니다.

• 샤드 키 (Shard Key) 선택: 어떤 기준으로 데이터를 분할할지 결정하는 것이 가장 중요합니다. 좋은 샤드 키는 데이터와 쿼리가 모든 샤드에 고르게 분산되도록 해야 합니다.
  • `user_id` 기준 샤딩: 사용자와 관련된 모든 데이터(사용자 정보, 해당 사용자가 올린 동영상 등)를 같은 샤드에 저장할 수 있습니다. 특정 사용자의 정보를 조회하는 쿼리에 매우 효율적입니다. 하지만 인기 유튜버(핫스팟)가 있는 샤드에 부하가 몰릴 수 있습니다.
  • `video_id` 기준 샤딩: `video_id`를 해싱(hashing)한 값에 따라 샤드를 결정합니다. 데이터가 비교적 고르게 분산되는 장점이 있습니다. 하지만 특정 사용자가 올린 모든 동영상을 조회하려면 모든 샤드를 쿼리해야 하는 비효율이 발생할 수 있습니다.
• 샤딩의 단점:
  • 복잡성 증가: 애플리케이션 로직에서 어떤 샤드로 쿼리를 보내야 할지 결정해야 합니다.
  • 여러 샤드에 걸친 조인(Join) 불가: 서로 다른 샤드에 있는 데이터를 조인하는 것은 매우 어렵고 성능이 저하됩니다. 데이터 모델링 단계에서부터 이를 고려해야 합니다.
  • 리샤딩(Re-sharding)의 어려움: 한번 샤딩 전략을 정하고 나면, 나중에 샤드 수를 늘리거나 샤드 키를 변경하는 작업(리샤딩)이 매우 복잡하고 위험합니다.

CAP 이론과 실제 적용 사례: 면접에서 CAP 이론(Consistency, Availability, Partition Tolerance)을 언급하면 깊이를 더할 수 있습니다. 분산 시스템은 네트워크 장애(Partition Tolerance)를 피할 수 없으므로, 일관성(Consistency)과 가용성(Availability) 사이에서 선택을 해야 한다는 이론입니다. 예를 들어, 동영상 업로드와 같이 중요한 트랜잭션은 강한 일관성을 보장하는 RDBMS(CP 시스템)를 사용하고, 조회수나 좋아요처럼 약간의 부정확성을 감수하더라도 항상 응답이 가능한 것이 중요한 기능은 가용성을 우선하는 NoSQL(AP 시스템, 예: Cassandra)을 선택하는 것이 합리적인 트레이드오프임을 설명할 수 있습니다.

6. 검색, 추천, 그리고 피드 시스템: 개인화 경험의 핵심

사용자가 원하는 콘텐츠를 쉽게 찾고, 새로운 관심사를 발견하게 만드는 것은 플랫폼의 성공에 매우 중요합니다. 이를 위해 검색, 추천, 피드 시스템은 단순한 기능을 넘어 정교한 데이터 파이프라인과 머신러닝 기술을 요구합니다.

검색 시스템 (Search)

수십억 개의 동영상 중에서 사용자가 입력한 키워드와 가장 관련성 높은 결과를 수백 밀리초 안에 반환해야 합니다. RDBMS의 `LIKE` 연산자로는 이러한 요구사항을 절대 만족시킬 수 없습니다.

• 전용 검색 엔진 사용: 이를 위해 Elasticsearch나 Apache Solr와 같은 역인덱스(Inverted Index) 기반의 검색 엔진을 사용해야 합니다.
• 인덱싱 파이프라인:
  1. 새로운 동영상이 업로드되거나 기존 동영상의 메타데이터(제목, 설명, 태그)가 변경될 때마다, 데이터베이스 변경 이벤트를 감지합니다. (CDC - Change Data Capture 기술 활용 가능)
  2. 이 변경 이벤트를 메시지 큐(Kafka 등)로 보냅니다.
  3. 별도의 인덱싱 서비스가 큐에서 메시지를 읽어와 동영상 메타데이터를 검색 엔진에 맞게 가공하여 인덱싱합니다.
• 검색 요청 처리:
  1. 사용자가 검색어를 입력하면, API 서버는 이 요청을 검색 서비스로 전달합니다.
  2. 검색 서비스는 Elasticsearch 클러스터에 쿼리를 실행합니다. Elasticsearch는 관련도 순으로 정렬된 `video_id` 목록을 반환합니다.
  3. API 서버는 이 `video_id` 목록을 이용해 메타데이터 DB나 캐시에서 실제 동영상 정보를 가져와 최종 검색 결과를 사용자에게 보여줍니다.

추천 시스템 (Recommendations)

추천 시스템은 유튜브 사용 시간의 대부분을 차지하게 만드는 핵심 엔진입니다. 이는 매우 복잡한 분야이므로, 시스템 디자인 인터뷰에서는 전체적인 아키텍처와 데이터 흐름을 설명하는 데 집중하는 것이 좋습니다.

• 데이터 수집: 사용자의 모든 행동(시청 기록, 검색 기록, 좋아요, 구독, 댓글)을 로그로 수집합니다. 대규모 로그 수집을 위해 Kafka와 같은 분산 메시징 시스템이 사용됩니다.
• 데이터 처리 및 모델 학습 (오프라인):
  • 수집된 로그 데이터는 데이터 레이크(Data Lake, 예: HDFS)에 저장됩니다.
  • Apache Spark와 같은 분산 처리 프레임워크를 사용하여 대용량 데이터를 가공하고, 머신러닝 모델(예: 협업 필터링, 콘텐츠 기반 필터링, 딥러닝 모델)을 주기적으로 학습시킵니다.
• 추천 목록 생성 및 서빙 (온라인):
  • 학습된 모델을 기반으로 각 사용자를 위한 추천 동영상 목록을 미리 계산해 둡니다(Pre-computation).
  • 이 추천 목록(`user_id` -> [`video_id_1`, `video_id_2`, ...])을 Redis나 Cassandra와 같은 저지연(Low-latency) Key-value 스토어에 저장합니다.
  • 사용자가 앱을 열거나 홈페이지에 접속하면, API 서버는 이 Key-value 스토어에서 해당 사용자의 추천 목록을 매우 빠르게 가져와 보여줍니다.

피드 생성 (Feed Generation)

사용자가 구독한 채널의 새 동영상을 보여주는 구독 피드 역시 중요한 기능입니다. 크게 두 가지 접근 방식이 있습니다.

1. Pull 방식 (읽기 시 생성): 사용자가 피드를 요청할 때마다, 해당 사용자가 구독한 모든 채널을 조회하고, 각 채널의 최신 동영상을 가져와서 시간순으로 정렬하여 보여줍니다. 구현이 간단하지만, 사용자가 피드를 열 때마다 복잡한 쿼리가 실행되어 응답이 느릴 수 있습니다.
2. Push 방식 (쓰기 시 생성): 유튜버가 새 동영상을 업로드하면, 해당 채널을 구독하는 모든 구독자의 피드(타임라인)에 이 동영상 정보를 미리 써넣습니다. 사용자는 자신의 피드를 읽기만 하면 되므로 매우 빠릅니다. 하지만 인기 유튜버(수천만 구독자)가 동영상을 올릴 때마다 엄청난 양의 쓰기 작업(Fan-out)이 발생하여 시스템에 부하를 줄 수 있습니다.

일반적으로는 두 방식을 혼합한 하이브리드 접근법을 사용합니다. 대부분의 사용자는 Push 방식을 사용하고, 구독자가 매우 많은 셀럽 채널에 대해서만 Pull 방식을 적용하여 쓰기 폭발(Write Amplification) 문제를 완화합니다.

7. 고가용성, 장애 극복 및 기타 고려사항

지금까지 설계한 시스템의 각 컴포넌트가 24시간 365일 안정적으로 동작하도록 만드는 것은 매우 중요합니다. 이를 위해 단일 장애점(SPOF, Single Point of Failure)을 제거하고, 장애 발생 시 자동으로 복구할 수 있는 메커니즘을 마련해야 합니다.

• 모든 계층의 이중화 (Redundancy): 웹 서버, API 서버, 데이터베이스, 캐시 등 모든 컴포넌트는 최소 2대 이상으로 구성합니다. 로드 밸런서는 이들 중 일부에 장애가 발생하면 트래픽을 자동으로 다른 정상 인스턴스로 라우팅합니다.
• 다중 데이터센터/리전 배포 (Multi-DC/Region): 특정 데이터센터 전체에 정전이나 네트워크 장애가 발생하더라도 서비스가 중단되지 않도록, 지리적으로 떨어진 여러 데이터센터나 클라우드 리전(Region)에 시스템을 분산 배포합니다. 데이터베이스와 객체 스토리지 역시 여러 리전에 걸쳐 복제(Geo-replication)하여 데이터 유실을 방지합니다.
• 상태 확인 (Health Checks): 로드 밸런서는 주기적으로 백엔드 서버에 헬스 체크 요청을 보내 응답 여부를 확인합니다. 응답이 없는 서버는 비정상으로 간주하고 서비스 풀에서 자동으로 제외합니다.
• 모니터링과 알림 (Monitoring & Alerting): CPU 사용률, 메모리, 지연 시간, 에러율 등 시스템의 모든 주요 지표를 실시간으로 수집하고 대시보드를 통해 시각화합니다 (예: Prometheus, Grafana). 특정 지표가 임계치를 넘으면 즉시 담당자에게 알림(예: Slack, PagerDuty)을 보내 신속하게 대응할 수 있도록 합니다.
• 캐싱 전략 심화:
  • 캐시 데이터: 인기 동영상 메타데이터, 사용자 세션, DB 쿼리 결과 등을 캐싱합니다.
  • 캐시 무효화 (Cache Invalidation): 원본 데이터가 변경되었을 때 캐시의 데이터도 함께 갱신해야 합니다. TTL(Time-To-Live) 기반, 혹은 데이터 변경 시 명시적으로 캐시를 삭제/갱신하는 방식을 사용할 수 있습니다.
  • 캐시 장애 대비: 캐시 서버에 장애가 발생하더라도, 시스템은 캐시를 건너뛰고 원본 데이터베이스에서 데이터를 가져와 서비스를 계속할 수 있어야 합니다 (Cache-aside 패턴).

마무리하며: 트레이드오프에 대한 끊임없는 고찰

지금까지 유튜브와 같은 대규모 시스템을 설계하는 과정을 단계별로 살펴보았습니다. 중요한 것은 이 설계에 유일한 '정답'은 없다는 것입니다. 시스템 디자인의 본질은 주어진 요구사항과 제약 조건 하에서 최적의 해결책을 찾아가는 과정이며, 그 과정은 수많은 트레이드오프(Trade-off)의 연속입니다.

예를 들어, 데이터의 강한 일관성을 선택하면 가용성이나 성능에서 손해를 볼 수 있고, 비용을 절감하기 위해 특정 기술을 선택하면 시스템의 복잡도가 증가할 수 있습니다. 성공적인 시스템 디자인 인터뷰는 단순히 화려한 기술을 나열하는 것이 아니라, 자신이 내린 모든 설계 결정에 대해 "왜?"라고 질문하고, 그 선택으로 인해 얻는 것과 잃는 것을 명확하게 설명할 수 있는 능력에 달려 있습니다. 이 글이 여러분이 FAANG급 기술 면접을 준비하고, 더 나아가 훌륭한 시스템 아키텍트로 성장하는 데 든든한 발판이 되기를 바랍니다.