Introduction & Requirements

이 글에서 사용하는 Store Capacity Service, Order Promise Service, Smart Queue Orchestrator, Store Edge Gateway, Production Task Service 같은 이름도 공개된 Starbucks 내부 서비스 이름이 아닙니다. 모바일 주문, 매장 주문, 드라이브스루, 배달 주문을 함께 처리하는 대규모 커피 매장 플랫폼을 설명하기 위해 이 글에서 정의한 컴포넌트입니다.

Starbucks 앱에서는 사용자가 주변 매장을 찾고, 메뉴를 확인하고, 음료를 원하는 방식으로 변경한 뒤 주문할 수 있습니다. 참여 매장에서는 즉시 픽업뿐 아니라 최대 한 시간 뒤의 픽업 시간을 선택하는 예약 주문도 제공할 수 있습니다.

주문 기능만 보면 일반적인 전자상거래 시스템처럼 보일 수 있습니다.

메뉴 조회
  -> 장바구니
      -> 결제
          -> 주문 완료

하지만 커피 매장 주문은 창고에서 완성된 상품을 꺼내 배송하는 과정과 다릅니다.

음료는 주문이 들어온 뒤 매장에서 제조하게 됩니다. 같은 라테라도 크기, 우유 종류, espresso shot, syrup, cold foam, 온도와 얼음 양에 따라 제조 시간이 달라질 수 있습니다.

매장에는 동시에 여러 주문 채널이 들어옵니다.

카운터 주문
모바일 즉시 픽업
모바일 예약 픽업
드라이브스루
배달

각 채널의 주문을 단순히 도착 순서대로 처리하면 문제가 생길 수 있습니다.

드라이브스루 차량이 계속 들어오면 모바일 주문이 오랫동안 밀릴 수 있습니다. 반대로 모바일 주문을 모두 먼저 처리하면 매장 안에서 기다리는 고객과 드라이브스루 고객의 대기 시간이 증가하게 됩니다.

예약 주문을 너무 많이 받으면 해당 시간에 현장 주문을 처리할 여유가 사라질 수 있습니다. 주문을 적게 받으면 매장의 생산 능력을 충분히 사용하지 못하게 됩니다.

그래서 이 시스템은 결제 요청을 받기 전에 다음 상태를 확인해야 합니다.

매장이 현재 주문을 받을 수 있는가?
요청한 상품이 해당 매장에서 판매 중인가?
필요한 재료가 남아 있는가?
요청한 픽업 시간에 생산 여유가 있는가?
해당 채널이 현재 운영 중인가?
결제 금액과 리워드 사용 결과가 유효한가?

“우리가 설계하는 것은 음료 주문 API인가요, 아니면 여러 주문 채널과 매장 생산 능력을 함께 제어하는 매장 운영 시스템인가요?”

주문 API만 설계한다면 주문 row를 저장하고 결제를 처리하면 됩니다.

하지만 매장 운영까지 포함하면 메뉴 availability, 제조 작업, 픽업 시간, 재고, 매장별 설비, 채널별 대기열, POS 상태, 배달 기사 도착 시간까지 함께 관리해야 합니다.

주문 승인과 제조 시작은 같은 상태가 아닙니다

앱에서 결제가 승인되었다고 해서 바리스타가 이미 음료를 만들고 있다는 뜻은 아닙니다. 주문은 다음과 같은 상태를 거칠 수 있습니다.

cart_created
quote_ready
payment_pending
confirmed
queued_at_store
in_preparation
ready_for_pickup
picked_up
completed
cancelled
refund_pending
refunded

confirmed는 결제와 매장 수용 가능 여부가 확인되어 주문이 확정된 상태입니다.

queued_at_store는 주문이 매장 시스템에 전달되어 제조 순서를 기다리는 상태입니다.

in_preparation은 하나 이상의 상품이 실제 제조 작업에 들어간 상태입니다.

앱에서는 이 상태를 구분해서 보여줘야 합니다.

주문을 확인하고 있습니다
매장에서 주문을 받았습니다
음료를 만들고 있습니다
픽업할 수 있습니다

결제 승인 직후 앱에 “제조 중”이라고 표시하면 실제 매장 시스템 전달이 지연된 상황을 정확히 표현하지 못하게 됩니다.

현재 재고와 앱 메뉴는 완전히 동시에 바뀌지 않을 수 있습니다

매장에 oat milk가 한 개 남았다고 가정하겠습니다. 두 사용자가 거의 같은 시각에 oat milk 음료를 주문할 수 있습니다.

User A
  -> oat milk 주문

User B
  -> oat milk 주문

메뉴 화면의 availability만 보고 두 주문을 모두 허용하면 매장은 한 주문을 만들 수 없게 됩니다. 반대로 모든 메뉴 조회에서 POS 재고를 실시간으로 읽으면 앱 메뉴 조회가 매장 네트워크와 POS 상태에 의존하게 됩니다. 그래서 조회용 availability와 주문 확정 시점의 재검증을 나눠야 합니다. 메뉴 화면에서는 최근 재고 상태를 기반으로 상품을 표시합니다. 결제 직전에는 매장 재고와 수용 가능 시간을 다시 확인합니다.

조회용 데이터가 실제 원본보다 잠시 늦게 갱신될 수 있는 구조를 최종적 일관성(eventual consistency)이라고 부릅니다. 이 구조에서는 사용자가 메뉴를 보는 동안 상품이 품절될 수 있습니다. 따라서 결제 단계에서 다음과 같은 응답을 제공할 수 있어야 합니다.

Oat milk is no longer available.
Choose another milk option to continue.

즉시 주문과 예약 주문은 생산 능력을 다르게 사용합니다

즉시 주문은 현재 대기열 뒤에 제조 작업을 추가합니다.

예약 주문은 미래의 특정 시간 구간에 제조 작업을 배정하게 됩니다.

예를 들어 사용자가 9시 20분에서 9시 25분 사이의 픽업을 선택했다고 가정하겠습니다.

시스템은 9시 20분에 제조를 시작하면 안 됩니다. 음료 제조 시간, 상품 수, 매장까지 전달되는 지연 시간을 고려해 더 이른 시점에 작업을 시작해야 합니다.

선택한 픽업 시간
09:20–09:25

예상 제조 시간
4분

준비 여유 시간
1분

예상 제조 시작
09:15

이 글에서는 매장이 일정한 시간 구간에 처리할 수 있는 작업량을 생산 가능량(capacity)이라고 부르겠습니다. 예약 주문을 받을 때는 5분 단위와 같은 시간 구간별로 남은 생산 가능량을 확인할 수 있습니다.

09:10–09:15
남은 생산 점수: 18

09:15–09:20
남은 생산 점수: 4

09:20–09:25
남은 생산 점수: 11

모든 주문을 단순 주문 건수로 계산하면 정확도가 낮아질 수 있습니다.

드립 커피 한 잔과 여러 customization이 포함된 Frappuccino 네 잔의 제조 시간이 같지 않기 때문입니다. 그래서 상품과 customization에 예상 작업량을 부여할 수 있습니다.

Brewed Coffee
work_units = 1

Latte
work_units = 3

Customized Frappuccino
work_units = 6

Heated Food
work_units = 2

이 수치는 절대적인 제조 시간이 아니라 매장별 처리 가능량을 계산하기 위한 상대적인 값입니다.

주문 순서는 접수 시간만으로 결정하기 어렵습니다

다음 주문이 같은 매장에 들어왔다고 가정하겠습니다.

08:00:00 모바일 픽업, 음료 2개
08:00:05 드라이브스루, 음료 1개
08:00:10 카운터 주문, 음료 3개
08:00:15 배달 주문, 음료 5개

모바일 주문을 무조건 먼저 처리하면 드라이브스루 대기 시간이 늘어날 수 있습니다. 드라이브스루만 우선하면 모바일 앱에서 약속한 픽업 시간이 지켜지지 않을 수 있습니다.그래서 제조 순서에는 다음 정보가 들어갈 수 있습니다.

주문 접수 시간
약속한 준비 시간
주문 채널
상품별 제조 시간
현재 station의 작업량
배달 기사 예상 도착 시간
주문 지연 시간
고객이 이미 매장에 도착했는지 여부

여러 주문 채널의 작업을 하나의 제조 순서로 정리하는 컴포넌트를 이 글에서는 Smart Queue Orchestrator라고 부르겠습니다.

Smart Queue Orchestrator는 모든 상품을 하나의 줄에 넣지 않습니다. 음료와 음식은 서로 다른 설비에서 동시에 준비될 수 있습니다.

Espresso Station
Cold Bar
Brewed Coffee Station
Oven Station
Packaging Station

주문 하나는 여러 제조 작업으로 나뉠 수 있습니다.

Order #991
  -> Latte: Espresso Station
  -> Cold Foam: Cold Bar
  -> Sandwich: Oven Station
  -> Final Assembly: Packaging Station

각 작업이 완료된 뒤 주문 전체가 준비 상태로 전환됩니다.

매장 시스템은 인터넷 연결이 불안정해도 주문을 처리해야 합니다

매장 인터넷이 잠시 끊길 수 있습니다.

이미 매장에 전달된 주문까지 사라지면 안 됩니다. 바리스타가 제조를 완료했는데 중앙 서버에 상태를 전송하지 못할 수도 있습니다.

그래서 매장에는 중앙 서버와 주문을 동기화하는 로컬 컴포넌트가 필요합니다.

이 글에서는 이를 Store Edge Gateway라고 부르겠습니다.

Store Edge Gateway는 다음 데이터를 짧은 기간 보관할 수 있습니다.

현재 주문 대기열
상품별 제조 작업
최근 완료 주문
매장 메뉴 availability
중앙 서버에 전송하지 못한 상태 변경
마지막 동기화 이벤트

연결이 복구되면 중앙 서버와 상태를 다시 맞추게 됩니다.

다만 매장이 오프라인일 때 새로운 모바일 주문을 계속 받아서는 안 됩니다. 주문은 결제되었지만 매장에 전달되지 않는 상황이 생길 수 있기 때문입니다.

연결 상태가 일정 시간 이상 확인되지 않으면 해당 매장을 앱 주문 불가 상태로 전환할 수 있습니다.

Functional Requirements

1. 사용자는 현재 위치나 검색어를 기준으로 주변 매장을 찾을 수 있어야 합니다.

2. 사용자는 매장의 영업시간, 지원 주문 채널, 예상 준비 시간과 메뉴를 확인할 수 있어야 합니다.

3. 사용자는 음료 크기, 우유, syrup, shot, 온도, 얼음과 같은 옵션을 선택할 수 있어야 합니다.

4. 시스템은 매장별 가격, 판매 상품, 품절 상태와 customization 가능 여부를 제공할 수 있어야 합니다.

5. 사용자는 즉시 픽업 또는 제공되는 시간 구간 중 하나를 선택해 예약 주문을 만들 수 있어야 합니다.

6. 시스템은 주문 확정 전에 매장 생산 가능량, 상품 availability, 가격, 리워드 사용 가능 여부를 다시 확인할 수 있어야 합니다.

7. 사용자는 저장된 결제 수단, Starbucks Card 또는 지원되는 외부 결제 수단으로 결제할 수 있어야 합니다.

8. 동일한 결제 요청이 재전송되어도 주문과 결제가 중복 생성되지 않아야 합니다.

9. 매장 시스템은 모바일, 카운터, 드라이브스루, 배달 주문을 하나의 제조 계획으로 변환할 수 있어야 합니다.

10. 음료와 음식 작업을 제조 station에 배정하고 진행 상태를 추적할 수 있어야 합니다.

11. 사용자는 주문 접수, 제조, 준비 완료 상태를 앱에서 확인할 수 있어야 합니다.

12. 매장은 상품이나 재료를 품절로 전환하고 특정 주문 채널을 일시 중단할 수 있어야 합니다.

13. 주문 완료 후 리워드 적립과 전자 영수증 생성을 처리할 수 있어야 합니다.

14. 주문 취소, 전체 환불과 부분 환불을 처리할 수 있어야 합니다.

15. 배달 주문은 외부 배달 제공자와 연결하고 기사 배정 및 도착 상태를 반영할 수 있어야 합니다.

16. 매장 네트워크가 복구되면 중앙 서버와 주문 진행 상태를 중복 없이 동기화할 수 있어야 합니다.

Non-Functional Requirements

Latency

• 주변 매장 조회는 p95 300ms 이내를 목표로 둘 수 있습니다.

• 매장 메뉴 조회는 p95 300ms 이내를 목표로 둡니다.

• 주문 가격과 예상 픽업 시간을 계산하는 요청은 p95 500ms 이내를 목표로 둘 수 있습니다.

• 결제와 주문 확정은 외부 결제 제공자의 응답 시간을 제외하고 p95 1초 이내를 목표로 설정할 수 있습니다.

• 주문 확정 후 매장 시스템 전달은 p95 2초 이내를 목표로 둘 수 있습니다.

위 수치는 실제 Starbucks SLA가 아니라 시스템 디자인을 위한 가정입니다.

Availability

• 메뉴 이미지나 추천 기능이 실패해도 주문 생성 경로는 계속 동작해야 합니다.

• 리워드 적립이 지연되어도 결제와 매장 주문 전달이 함께 실패하면 안 됩니다.

• 특정 매장 시스템이 오프라인이면 해당 매장만 모바일 주문을 제한하고 다른 매장의 주문은 계속 받아야 합니다.

Scalability

• 매장 검색, 메뉴 조회, 주문 생성, 주문 상태 stream, 매장 dispatch, 리워드 처리를 독립적으로 확장할 수 있어야 합니다.

• 아침 피크 시간에 특정 도시와 매장으로 요청이 집중되어도 다른 지역의 주문 처리 시간이 증가하지 않아야 합니다.

Consistency

• 결제 승인과 주문 확정 상태를 추적할 수 있어야 합니다.

• 같은 주문이 매장에 두 번 전달되거나 같은 결제가 두 번 승인되지 않아야 합니다.

• 재고와 메뉴 availability는 잠시 차이가 날 수 있지만 주문 확정 시점에는 다시 확인해야 합니다.

Durability

• 결제 상태, 주문 상태, 환불 상태, 제조 완료 상태는 서버와 worker가 재시작되어도 복구할 수 있어야 합니다.

• 여기서 영속 상태(durable state)는 실행 중인 서버의 메모리가 사라진 뒤에도 데이터베이스에서 다시 읽을 수 있는 상태를 의미합니다.

Security

• 카드 번호를 애플리케이션 데이터베이스에 직접 저장하지 않아야 합니다.

• 결제 제공자가 발급한 token을 사용하고 민감한 데이터 접근을 제한해야 합니다.

• 매장 직원과 관리자의 권한을 매장 단위로 확인해야 합니다.

Auditability

• 가격 변경, 상품 품절, 주문 취소, 환불, 리워드 조정, 채널 중단과 관리자 개입을 추적할 수 있어야 합니다.

Store Isolation

• 한 매장의 주문량 증가와 장애가 다른 매장의 제조 순서와 주문 조회에 영향을 주지 않아야 합니다.

Scope

이 글에서는 다음 기능을 다룹니다.

매장 검색
영업시간과 주문 채널
매장별 메뉴
상품 customization
즉시 픽업
예약 픽업
주문 견적
매장 생산 가능량
결제
리워드 적립과 사용
주문 상태
전자 영수증
모바일 주문
카운터 주문
드라이브스루 주문
배달 주문
매장 제조 순서
상품 제조 작업
매장 품절 처리
주문 취소와 환불
매장 Edge 시스템
약한 네트워크 복구
운영자 모니터링

다음 기능은 범위에서 제외합니다.

커피 원두 공급망 전체
직원 근무 일정 전체
결제 네트워크 내부 구현
배달 제공자의 기사 배차 내부 구현
개인화 추천 모델 학습
Starbucks Card 발행 회계 전체
세금 신고 시스템 전체
실제 음료 제조 장비 제어

Traffic & Load Assumptions

아래 수치는 실제 Starbucks 트래픽이 아닙니다.

시스템 디자인을 위해 전 세계 참여 매장을 40,000개로 가정하겠습니다.

매장 하나가 하루 평균 1,000건의 전체 주문을 처리한다고 가정하면 하루 주문은 4,000만 건이 됩니다.

40,000 stores × 1,000 orders
= 40,000,000 orders/day

평균 주문 생성 QPS는 약 463입니다.

40,000,000 / 86,400
≈ 463 orders/second

평균 QPS는 낮아 보일 수 있지만 주문은 지역별 아침 시간에 집중됩니다.

전 세계 피크 계수 30배를 적용하면 약 13,900 QPS가 됩니다.

463 × 30
≈ 13,890 orders/second

매장 하나의 피크를 별도로 봐야 합니다. 말이 안될수도 있지만, 도심의 대형 매장이 30분 동안 600건의 주문을 처리한다고 가정하겠습니다.

600 / 1,800
≈ 0.33 orders/second

주문 QPS 자체는 높지 않습니다. 하지만 주문 하나가 여러 상품과 제조 작업으로 나뉩니다. 주문 한 건에 평균 2.3개의 상품이 있고, 상품 하나가 평균 1.4개의 제조 작업을 만든다고 가정하겠습니다.

40,000,000 × 2.3 × 1.4
= 128,800,000 production tasks/day

평균 약 1,491개의 제조 작업 이벤트가 초당 생성됩니다.

주문 상태 이벤트는 더 많아질 수 있습니다.

주문 한 건이 평균적으로 다음 이벤트를 만든다고 가정하겠습니다.

order_created
payment_approved
order_confirmed
store_received
preparation_started
item_completed
order_ready
order_picked_up
order_completed
reward_posted

주문당 평균 12개의 이벤트가 발생하면 하루 4억 8천만 개의 이벤트가 생성됩니다.

40,000,000 × 12
= 480,000,000 events/day

평균 약 5,556 event QPS입니다.

Read more

Introduction & Requirements

아래 설계는 OpenAI Codex의 공개 문서와 제품 기능을 바탕으로 한 시스템 디자인 가정입니다. OpenAI 내부 구현을 그대로 설명하는 글은 아닙니다.

Codex는 사용자의 저장소를 읽고, 파일을 수정하고, 명령을 실행하고, 테스트 결과를 확인할 수 있습니다. 사용자는 터미널이나 IDE에서 현재 작업 폴더를 대상으로 Codex를 실행할 수 있고, 클라우드 환경에 작업을 넘겨 다른 작업과 병렬로 실행할 수도 있습니다.

여기서 작업(task)이라는 용어를 먼저 설명하겠습니다.

사용자가 다음과 같이 요청했다고 가정하겠습니다.

결제 API의 중복 요청 문제를 수정하고 관련 통합 테스트를 추가해 주세요.

시스템은 이 요청과 함께 아래 정보를 계속 기억해야 합니다.

어느 저장소를 수정하는가?
어느 branch 또는 commit을 기준으로 시작했는가?
어떤 환경에서 실행하는가?
어떤 파일을 읽고 수정했는가?
어떤 명령을 실행했는가?
사용자 승인이 필요한 작업이 있었는가?
테스트 결과는 무엇인가?
최종 diff는 무엇인가?
Pull Request를 만들었는가?

이렇게 사용자 요청, 실행 상태, 결과, 로그를 함께 관리하는 작업 단위를 이 글에서는 task라고 부르겠습니다.

처음 이 문제를 보면 코드 생성 API로 설계할 수 있습니다.

“사용자의 요청과 저장소 파일을 모델에 보내고 수정된 코드를 반환하면 되지 않을까요?”

파일 몇 개만 포함된 저장소에서 함수 하나를 수정하는 경우에는 이 방식으로 결과를 만들 수 있습니다. 사용자가 현재 파일과 오류 메시지를 보내면 모델이 코드 조각을 반환하게 됩니다.

하지만 실제 소프트웨어 작업에는 코드 생성 이후의 처리가 계속 이어집니다.

저장소 구조 파악
관련 파일 검색
프로젝트 지침 확인
의존성 설치
코드 수정
formatter 실행
linter 실행
unit test 실행
integration test 실행
실패 원인 분석
추가 수정
diff 검토
commit 또는 Pull Request 작성

모델이 코드 문자열을 생성했다고 작업이 완료되는 것은 아닙니다. 생성된 코드가 실제 저장소에서 빌드되고, 기존 테스트를 통과하고, 사용자의 프로젝트 규칙을 따르는지 확인해야 합니다.

면접관은 이렇게 물을 수 있습니다.

“우리가 설계하는 것은 코드를 반환하는 API인가요, 아니면 저장소를 격리된 실행 환경에서 수정하고 검증하는 작업 플랫폼인가요?”

코드 반환만 지원한다면 prompt, model request, response 정도로 구성할 수 있습니다.

하지만 Codex와 같은 시스템에서는 저장소 버전, 실행 환경, 파일 변경, 터미널 명령, 승인 요청, 테스트 결과, diff, Git 작업을 함께 관리해야 합니다.

특히 명령 실행은 일반적인 텍스트 생성과 다른 보안 조건을 가집니다.

에이전트가 다음 명령을 실행하려고 할 수 있습니다.

npm test

이 명령은 현재 작업 폴더 안에서 테스트를 실행하므로 비교적 제한된 작업입니다.

반면 다음 명령은 더 넓은 권한을 요구할 수 있습니다.

curl https://example.com/install.sh | sh

rm -rf ~/Documents

git push origin main

파일 시스템, 네트워크, 외부 저장소에 영향을 주는 작업은 별도의 실행 경계를 가져야 합니다.

에이전트가 접근할 수 있는 파일과 네트워크 범위를 제한하는 실행 환경을 sandbox라고 부르겠습니다.

sandbox는 에이전트가 자율적으로 명령을 실행하더라도 사용자의 다른 파일이나 허용되지 않은 네트워크에 접근하지 못하도록 제한합니다.

예를 들어 workspace-write 모드에서는 다음 작업을 허용할 수 있습니다.

현재 저장소 파일 읽기
현재 저장소 파일 수정
저장소 안에서 테스트 실행
임시 빌드 파일 생성

반면 다음 작업은 차단하거나 사용자 승인을 받을 수 있습니다.

작업 폴더 밖의 파일 수정
외부 인터넷 접속
운영 환경에 배포
원격 저장소에 push
사용자의 자격 증명 접근

sandbox와 함께 승인(approval) 처리도 구성해야 합니다.

승인은 에이전트가 현재 허용 범위를 넘어서는 작업을 실행하기 전에 사람이나 별도 검토 시스템의 허가를 받는 과정입니다.

Agent
  -> 외부 네트워크 접근 요청
  -> Approval Service
      -> 사용자 또는 검토 에이전트 판단
          -> 허용
          -> 거부

모든 명령을 승인받게 만들면 사용자가 계속 작업을 확인해야 하므로 자동화 수준이 낮아집니다. 반대로 모든 명령을 자동으로 허용하면 파일 삭제, 외부 전송, 비밀 정보 노출 가능성이 증가합니다.

그래서 실행 위치, 명령 종류, 파일 경로, 네트워크 domain, 저장소 권한을 기준으로 승인 정책을 나누게 됩니다.

클라우드 작업은 로컬 작업과 다른 실행 조건을 가집니다.

Read more

Introduction & Requirements

아래 설계는 Substack의 공개 문서와 제품 기능을 바탕으로 한 시스템 디자인 가정입니다. Substack 내부 구현을 그대로 설명하는 글은 아닙니다.

Substack에서는 창작자가 텍스트, 오디오, 영상 게시물을 발행하고 구독자를 관리할 수 있습니다. 독자는 무료 또는 유료로 publication을 구독하고 웹, 앱, 이메일, 팟캐스트 앱에서 콘텐츠를 볼 수 있습니다. Notes를 통해 짧은 글, 링크, 이미지, 인용문을 공유할 수도 있으며, 라이브 영상은 전체 사용자, 전체 구독자, 유료 구독자처럼 접근 범위를 다르게 설정할 수 있습니다.

처음 이 문제를 보면 이메일 뉴스레터 서비스로 설계하기 쉽습니다.

“창작자가 글을 작성하면 DB에 저장하고, 구독자 이메일 목록을 읽어 메일을 보내면 되지 않을까요?”

구독자 수가 수백 명이고 텍스트 게시물만 지원한다면 이 방식으로 시작할 수 있습니다. 게시물 row를 저장하고 구독자 목록을 조회한 뒤 이메일 발송 API를 반복 호출하면 됩니다.

하지만 실제 창작자 플랫폼에서는 하나의 게시물이 여러 위치에 나타나게 됩니다.

Publication Website
Substack App
Email Inbox
Home Feed
Reader Library
Podcast RSS
Push Notification
Creator Analytics
Search Index

게시물이 텍스트인지, 오디오인지, 영상인지에 따라 처리 과정도 달라집니다. 유료 구독자에게만 공개할 수도 있고, 무료 미리보기만 제공할 수도 있으며, 이메일에는 전체 글을 넣고 웹에서는 paywall을 적용하는 정책도 가능합니다.

여기서 paywall은 사용자가 콘텐츠를 열 때 현재 구독 상태를 확인하고, 접근할 수 없는 콘텐츠에는 구독 화면을 표시하는 기능입니다.

사용자가 유료 콘텐츠를 열 수 있는 상태를 이 글에서는 접근 권한(entitlement)이라고 부르겠습니다.

접근 권한에는 다음 정보가 들어갈 수 있습니다.

어떤 publication에 대한 권한인가?
무료 콘텐츠만 볼 수 있는가?
유료 콘텐츠도 볼 수 있는가?
권한이 언제까지 유지되는가?
무료 체험이나 선물 구독으로 받은 권한인가?
환불이나 결제 실패로 제한된 상태인가?

결제 성공과 접근 권한 갱신도 항상 같은 순간에 끝나지 않을 수 있습니다. 결제 제공자가 성공 응답을 보냈지만 webhook이 늦게 도착할 수 있고, 사용자가 구독을 취소해도 이미 결제한 기간이 끝날 때까지 유료 콘텐츠를 계속 볼 수 있습니다.

그래서 결제 상태와 콘텐츠 접근 상태를 하나의 boolean 값으로 처리하면 운영 중에 문제가 생길 수 있습니다.

예를 들어 다음과 같은 상태가 필요합니다.

subscription_state = cancelled
access_until = 2026-08-31T23:59:59Z

사용자는 갱신을 취소했지만 이미 결제한 기간까지는 유료 콘텐츠를 볼 수 있습니다.

면접관은 이렇게 물을 수 있습니다.

“우리가 설계하는 것은 이메일 발송 서비스인가요, 아니면 콘텐츠 발행, 구독 결제, 접근 권한, 다중 채널 배포가 결합된 publishing platform인가요?”

이 질문에 따라 저장소와 처리 경로가 달라지게 됩니다.

이메일 발송만 필요하다면 수신자 목록과 이메일 template만 있어도 됩니다. 하지만 Substack과 같은 플랫폼에서는 게시물 원본, 수정 이력, 웹 페이지, 이메일 버전, 오디오 파일, 영상 파일, 구독 plan, 접근 권한, 댓글, Notes, 피드, 발송 결과를 함께 관리해야 합니다.

게시 버튼을 누른 뒤 모든 작업을 같은 HTTP 요청 안에서 끝내는 방식도 적합하지 않습니다.

게시물을 저장한 뒤 다음 작업이 이어질 수 있습니다.

웹 페이지 생성
CDN cache 갱신
구독자 대상 계산
이메일 발송 작업 생성
앱 피드 반영
push notification 생성
팟캐스트 RSS 갱신
미디어 변환
검색 인덱스 반영
분석 이벤트 생성

구독자가 수백만 명인 publication에서는 게시물 하나가 수백만 개의 이메일 발송 작업으로 확장될 수 있습니다.

하나의 이벤트가 내부의 여러 작업으로 확장되는 현상을 fan-out이라고 부르겠습니다.

1 PostPublished event
  -> 1 web page update
  -> 1 feed projection
  -> 1 podcast RSS update
  -> 5,000,000 email delivery tasks
  -> 2,000,000 push candidates
  -> analytics events

게시물 저장과 수백만 건의 발송을 같은 요청에 넣으면 게시 API 연결이 오랫동안 유지되고, 일부 이메일 제공자가 느려질 때 게시 자체가 실패할 수 있습니다.

그래서 게시물 저장과 채널별 배포를 분리해야 합니다.

게시물은 먼저 영속 저장소에 확정하고, 이후 웹, 이메일, 앱, push, 팟캐스트 배포를 이벤트 기반으로 진행하게 됩니다.

여기서 이벤트 기반 처리는 게시 API가 각 후속 작업을 직접 호출하지 않고, 게시 완료 이벤트를 발행한 뒤 각 작업자가 필요한 처리를 독립적으로 수행하는 구조입니다.

또 다른 문제가 있습니다.

“게시물이 발행된 뒤 창작자가 오타를 수정하면 이미 전송된 이메일도 바뀌어야 하나요?”

Read more

Introduction & Requirements

이 글에서 등장하는 Search Orchestrator, Source Snapshot Service, Citation Mapper, Answer Snapshot Store 같은 컴포넌트는 공개 문서에서 확인된 Google 내부 서비스 이름이 아닙니다. 공개된 제품 동작과 Search Central 정책을 바탕으로, 면접 상황에서 대규모 생성형 검색 시스템을 어떻게 설계할 수 있는지 설명하기 위해 정의한 컴포넌트입니다.

Google은 AI Overviews가 검색 결과에서 AI가 생성한 정보 요약과 더 깊게 탐색할 수 있는 링크를 제공한다고 설명합니다. 또한 Google Search Central은 AI Overviews와 AI Mode가 관련 웹 링크를 보여주며, 여러 하위 주제와 데이터 소스에 걸쳐 관련 검색을 동시에 수행하는 query fan-out을 사용할 수 있다고 설명합니다.

여기서 query fan-out이라는 용어를 먼저 풀어보겠습니다.

사용자가 다음과 같이 검색했다고 가정하겠습니다.

전기차를 처음 사는데 겨울 주행거리와 충전비를 고려하면 어떤 차가 좋은가?

이 질문을 검색 한 번으로만 처리하지 않고 내부적으로 다음과 같은 관련 검색으로 확장할 수 있습니다.

전기차 겨울 주행거리 감소율
전기차 모델별 실제 겨울 주행거리
지역별 급속 충전 비용
가정용 충전 비용
전기차 배터리 열관리
초보 운전자 전기차 비교

하나의 사용자 질문에서 여러 관련 검색을 만드는 방식을 query fan-out이라고 부릅니다.

이 구조가 들어가면 일반적인 검색 결과 조회보다 처리량이 빠르게 증가할 수 있습니다. 사용자 요청은 한 건이지만 내부에서는 여러 검색 요청, 문서 후보, 중복 URL, source policy 확인, ranking, context 구성 작업이 생기게 됩니다.

처음 이 문제를 보면 이렇게 설계할 수 있습니다.

“검색 결과 상위 몇 개를 가져오고, 본문 일부를 LLM에 넣어서 답변을 만들면 되지 않을까요?”

작은 테스트 환경에서는 이 방식으로 결과를 만들 수 있습니다. 검색 결과 URL 몇 개를 가져오고, 텍스트를 추출한 뒤, 모델에 전달하면 요약 답변이 나옵니다.

하지만 실제 검색 환경에서는 질문 하나가 여러 하위 주제로 확장될 수 있습니다. 각 하위 검색에서는 서로 다른 문서 후보가 나오고, 같은 URL이 반복될 수 있으며, 페이지마다 최신성도 다르게 됩니다. 일부 페이지에는 snippet 사용 제한이 있을 수 있고, 일부 문서는 검색 결과에 표시될 수 있는 조건을 충족하지 않을 수 있습니다.

Google Search Central은 AI 기능의 supporting link로 표시되려면 페이지가 Google Search에 색인되어 있고 snippet 표시 자격을 가져야 한다고 설명합니다. 또한 nosnippet, data-nosnippet, max-snippet 같은 제어가 Search의 AI 기능에서 콘텐츠 사용 범위에 영향을 줄 수 있다고 설명합니다.

그래서 이 글에서는 검색 결과 URL을 바로 LLM에 넣지 않습니다.

검색 후보를 수집한 뒤 다음 조건을 확인하게 됩니다.

Read more

Introduction & Requirements

아래 설계는 Spotify의 공개 문서와 제품 특성을 바탕으로 한 시스템 디자인 가정입니다. Spotify 내부 구현을 그대로 설명하는 글은 아닙니다.

이 글은 음악 추천 모델 전체나 오디오 스트리밍 플레이어 내부 구현을 설계하는 글이 아닙니다. 사용자의 청취 이벤트를 수집하고, 개인화 규칙을 적용하고, 연말에 빠르게 열리는 Wrapped 카드와 공유 이미지를 제공하는 시스템을 설계하는 글입니다.

“사용자가 들은 노래를 DB에 저장하고, 연말에 가장 많이 들은 곡과 아티스트를 집계해서 보여주면 되지 않을까요?”

작은 기능이라면 이 접근으로 화면 하나는 만들 수 있습니다. 사용자별로 track_id와 play_count를 저장하고, 연말에 count가 높은 순서대로 정렬하면 상위 곡 목록은 나옵니다. 하지만 Spotify Wrapped는 사용자가 단순히 “많이 들은 곡 목록”을 보려고 여는 기능이 아닙니다.

사용자는 자신의 1년을 음악 취향으로 다시 보고 싶어 합니다. 친구에게 공유하고 싶고, 특정 아티스트와 장르가 왜 나왔는지 납득하고 싶어 합니다. 그래서 Wrapped는 단순 청취 횟수 집계가 아니라, 1년 치 스트리밍 이벤트를 사용자별 스토리 카드로 바꾸는 대규모 개인화 시스템이 됩니다.

Spotify는 2025 Wrapped 설명에서 총 청취 시간이 실제 재생 시간 기준으로 계산된다고 설명합니다. 예를 들어 팟캐스트를 2배속으로 들으면 콘텐츠 길이가 아니라 실제로 들은 시간이 반영됩니다. 또한 Private Mode와 Exclude from Taste Profile로 제외한 콘텐츠는 총 청취 시간에는 포함될 수 있지만, 취향 기반 스토리에는 영향을 주지 않는다고 설명합니다.

이 설명만 봐도 Wrapped는 단순 카운터가 아닙니다. 같은 청취 이벤트라도 어떤 숫자에는 포함하고, 어떤 카드에는 제외하거나 낮은 가중치로 반영해야 합니다. 즉, 총 청취 시간 계산과 취향 기반 카드 계산은 서로 다른 규칙을 가져야 합니다.

Spotify는 사용자가 특정 트랙이나 플레이리스트를 Taste Profile에서 제외할 수 있는 기능도 제공합니다. Taste Profile은 사용자의 장기적인 음악 취향을 나타내기 위해 쓰이는 개인화 기준입니다. 사용자가 수면용 음악, 아이가 듣는 노래, 임시로 반복 재생한 트랙을 제외하고 싶을 수 있기 때문에 이런 기능이 필요합니다.

이 기능이 있으면 추천과 Wrapped가 같은 청취 이벤트를 보더라도 모든 이벤트를 같은 방식으로 반영하면 안 됩니다. 예를 들어 수면용 플레이리스트를 매일 밤 8시간씩 틀었다고 해서 그 음악이 사용자의 올해 대표 취향으로 나오는 것은 어색할 수 있습니다. 반면 총 청취 시간에서는 실제로 재생된 시간이므로 포함될 수 있습니다.

“우리가 설계하는 것은 단순 청취 횟수 집계인가요, 아니면 사용자별 제외 규칙과 공유 가능한 스토리 카드가 붙은 개인화 이벤트 시스템인가요?”

이 질문에 따라 저장 위치와 처리 흐름이 달라지게 됩니다. 단순 청취 횟수 집계라면 user_id, track_id, count만 있어도 됩니다. 하지만 Wrapped는 총 청취 시간, 상위 곡, 상위 아티스트, 장르, 팟캐스트, 오디오북, 취향 변화, 공유 카드, 글로벌 랭킹을 서로 다른 규칙으로 계산해야 합니다.

특히 Taste Profile 제외나 Private Mode처럼 어떤 화면에는 반영하고 어떤 카드에는 덜 반영해야 하는 조건이 생기면, 하나의 count 필드만으로는 설명하기 어렵습니다. 청취 이벤트 처리 단계에서부터 계산 목적에 맞는 policy_version, rule_version, content_type, session_mod_를 함께 기록해야 합니다.

여기서 또 하나의 질문이 나옵니다.

“사용자가 노래를 재생한 순간마다 바로 Wrapped 집계를 업데이트할 건가요, 아니면 이벤트를 모아 나중에 계산할 건가요?”

실시간 업데이트는 좋아 보일 수 있습니다. 오늘 들은 노래가 바로 올해 상위 곡 후보에 반영되면 화면이 최신처럼 보입니다. 하지만 수억 명의 사용자가 매일 음악을 듣는 환경에서 매 재생마다 모든 Wrapped 집계를 즉시 업데이트하면 이벤트 수집, 중간 집계, 카드 생성 경로가 동시에 느려질 수 있습니다.

Spotify는 2026년 데이터 트렌드 글에서 2025년 12월 24일이 음악 스트리밍 역사상 가장 큰 날이었고, 하루 110억 회 이상의 음악 스트림이 있었다고 공개했습니다. 이 정도 규모에서는 원본 청취 이벤트를 먼저 안전하게 수집하고, 사용자별 중간 집계를 시간 단위나 일 단위로 정리한 뒤, Wrapped 공개 전에 사용자별 결과를 미리 만들어 두는 방식이 더 안정적입니다.

Wrapped 카드가 사용자의 현재 취향을 보여줘야 하는지, 1년 전체를 보여줘야 하는지도 결정해야 합니다. 최근 한 달의 반복 청취가 전체 1년 취향을 지나치게 밀어내면 사용자는 “내 Wrapped가 이상하다”고 느낄 수 있습니다. 반대로 연초 청취가 너무 오래 유지되면 최근 취향 변화가 보이지 않습니다.

그래서 사용자 화면마다 freshness, 즉 최신 상태를 얼마나 강하게 요구할지 다르게 잡아야 합니다. 연말 Wrapped의 확정 카드는 일정 기간의 snapshot으로 만들고, 추천 홈 화면은 더 짧은 시간 창을 볼 수 있습니다. 여기서 snapshot은 특정 시점의 계산 결과를 고정해 둔 데이터입니다. 같은 청취 이벤트라도 Wrapped와 추천 홈은 읽는 기준이 달라질 수 있습니다.

“Wrapped를 모든 사용자에게 동시에 열어도 되나요?”

연말 공개 직후에는 많은 사용자가 동시에 앱을 열고, 스토리 카드를 넘기고, 공유 이미지를 생성합니다. 이때 모든 카드를 요청 시점에 계산하면 카드 생성 작업자와 이미지 렌더링 경로가 동시에 느려질 수 있습니다.

그래서 Wrapped는 사전에 사용자별 결과를 계산하고, 런칭 시점에는 빠른 조회용 데이터와 카드 파일을 내려주는 구조가 필요합니다. 실시간성 일부를 줄이더라도, 전 세계 사용자가 동시에 들어오는 시간에 첫 카드가 빠르게 열리는 쪽이 더 중요합니다.

Functional Requirements

1. 사용자의 음악, 팟캐스트, 오디오북 청취 이벤트를 수집하고, 실제 재생 시간과 콘텐츠 종류를 구분할 수 있어야 합니다.

2. Taste Profile 제외, Private Mode, 지역, 계정 상태, 콘텐츠 타입별 규칙을 반영해 총 청취 시간 계산과 취향 기반 카드 계산을 분리할 수 있어야 합니다.

3. 사용자별 상위 곡, 상위 아티스트, 장르, 청취 시간, 공유용 카드, 스토리 순서를 계산할 수 있어야 합니다.

4. Wrapped 공개 시점에 많은 사용자가 동시에 열어도 카드와 요약 결과를 낮은 지연 시간으로 제공할 수 있어야 합니다.

5. 약한 네트워크에서도 사용자가 이미 받은 Wrapped 카드와 공유 이미지를 다시 볼 수 있도록 이벤트 동기화와 로컬 캐시를 제공할 수 있어야 합니다.

Non-Functional Requirements

1. Wrapped 홈 진입 후 첫 카드 표시까지 p95 500ms에서 1초 이내를 목표로 둡니다.

2. 사전 계산 파이프라인이 느려져도 음악 재생 이벤트 수집과 일반 추천 경로가 같이 느려지지 않게 분리해야 합니다.

3. 사용자의 제외 설정, 청취 기록 삭제, 계정 상태 변경이 뒤늦게 반영될 때 잘못된 알림이나 오래된 카드가 보이지 않도록 검증해야 합니다.

4. 공개 첫날 카드 조회, 공유 이미지 조회, 이벤트 동기화가 동시에 증가해도 read path가 안정적으로 동작해야 합니다.

5. 청취 이벤트 재처리가 필요할 때 원본 이벤트를 다시 읽을 수 있어야 하지만, 카드 조회 경로에서 원본 이벤트를 직접 스캔하면 안 됩니다.

Scope

이 글은 청취 이벤트 수집에서 시작합니다. 사용자가 음악, 팟캐스트, 오디오북을 재생하면 재생 서버는 content_id, content_type, played_ms, playback_speed, session_mode 같은 정보를 포함한 이벤트를 발행합니다. 여기서 played_ms는 실제로 들은 시간을 나타냅니다.

그리고 사용자별 중간 집계를 다룹니다. 연말에 원본 이벤트를 처음부터 다시 모두 읽으면 비용과 시간이 커집니다. 그래서 일별 또는 주별로 사용자별 재생 시간, 트랙 count, 아티스트 count, 제외 규칙 적용 결과를 미리 계산해야 합니다.

Taste Profile 제외 규칙도 범위에 들어갑니다. 사용자가 제외한 트랙이나 플레이리스트는 추천과 취향 기반 Wrapped 카드에 덜 반영되어야 합니다. 다만 총 청취 시간처럼 실제 재생 시간 자체를 보여주는 숫자에는 포함될 수 있습니다.

Wrapped 카드 생성도 다룹니다. 사용자가 보는 것은 원본 이벤트가 아니라 상위 곡, 상위 아티스트, 장르, 청취 시간, 공유 이미지, 카드 순서가 포함된 최종 카드 묶음입니다.

공유 이미지 생성도 포함합니다. 공유 이미지는 요청 시점에 매번 새로 만들면 공개일에 렌더링 경로가 느려질 수 있습니다. 그래서 사전 생성하거나, 템플릿과 사용자별 결과를 조합해 캐시 가능한 형태로 만들어야 합니다.

글로벌 런칭 캐시도 필요합니다. Wrapped 공개 직후에는 많은 사용자가 동시에 앱을 열게 됩니다. 이때 사용자별 story pack 상태, 첫 카드, 공유 이미지 pointer를 빠르게 읽을 수 있어야 합니다.

앱 이벤트 스트림, Event Sync, 로컬 카드 캐시, 약한 네트워크 복구도 다룹니다. 사용자가 지하철이나 약한 네트워크에서 Wrapped를 열어도 이미 받은 카드는 다시 볼 수 있어야 합니다. 다만 cached card가 언제 확인된 것인지 표시해야 합니다.

Read more

Introduction & Requirements

아래 설계는 Tesla Robotaxi의 공개 문서, Tesla Fleet API 문서, 공개 특허 문헌, 그리고 공개 보도에서 확인 가능한 제품 특성을 바탕으로 최대한 실제 시스템 디자인 특징을 반영한 시스템 디자인 가정입니다.

Tesla는 Robotaxi 네트워크를 자율 차량 fleet으로 설명해 왔습니다. Tesla Fleet API 문서는 차량 상태를 주기적으로 조회하는 대신 차량이 직접 서버로 데이터를 stream하는 Fleet Telemetry 방식을 제공합니다.

이 방식은 불필요한 vehicle wake와 배터리 소모를 줄이기 위한 구조입니다. 또한 Fleet Telemetry 문서는 차량 데이터가 500ms 단위로 전송될 수 있고, 특정 signal은 측정할 수 없는 상태에서 invalid로 표시될 수 있다고 설명합니다.

이 두 가지는 Robotaxi Fleet Manager 설계에서 바로 운영 제약이 됩니다. 차량을 계속 깨워서 상태를 긁어오면 배차 정확도는 좋아 보일 수 있습니다. 하지만 배터리와 연결 비용이 계속 압박받게 됩니다. 그래서 fleet 운영 시스템은 “항상 최신 상태를 polling한다”가 아니라 “차량이 보내는 telemetry stream을 받아 최신 snapshot을 유지한다”는 방향으로 설계해야 합니다.

처음 이 문제를 보면 단순한 ride matching처럼 보일 수 있습니다.

“승객이 출발지와 목적지를 보내면, 가까운 차량 하나를 찾아서 배정하면 되지 않을까요?”

차량 100대가 있고, 도심 하나에서만 운행하고, 모든 차량이 항상 온라인이고, 배터리도 충분하고, 충전소도 비어 있고, 차량 실내 상태도 항상 좋다면 가까운 차량 배정으로 시작할 수 있습니다. 하지만 운전자가 없는 fleet에서는 가까운 차량이 항상 좋은 차량은 아닙니다.

가까운 차량이 배터리 12퍼센트일 수 있습니다. 다음 충전 슬롯이 없을 수 있습니다. 이전 승객 하차 후 실내 검사가 끝나지 않았을 수 있습니다. 현재 위치 신뢰도가 낮을 수 있습니다. 해당 지역에서 규제상 운행이 제한될 수도 있습니다. 그래서 Robotaxi 배차는 “가장 가까운 차량 찾기”가 아니라 “이 ride를 끝까지 안정적으로 완료할 수 있는 차량 찾기”가 됩니다.

“우리가 설계하는 것은 단순 ride matching인가요, 아니면 차량 위치, 배터리, 충전소, 원격 명령, cabin readiness, 규제 구역을 동시에 보는 autonomous fleet operating system인가요?”

이 질문 하나로 저장소와 파이프라인이 바뀌게 됩니다. 단순 ride matching이라면 rides table에서 nearest vehicle을 찾으면 됩니다. 하지만 Robotaxi에서는 차량이 승객에게 가기 전에 이미 자율주행 가능 상태인지, 실내가 다음 승객에게 제공 가능한 상태인지, 충전 계획이 다음 몇 건의 ride 이후에도 가능한지, 차량 명령이 실제로 전달 가능한지 확인해야 합니다.

Tesla Fleet API 문서는 vehicle command가 virtual key와 signed command 처리를 전제로 한다고 설명합니다. 그리고 차량이 online이라고 해서 command 성공이 곧바로 보장되는 것도 아닙니다. 그래서 원격 명령 경로는 일반 상태 조회 경로와 분리되어야 합니다. 승객 앱에는 “차량 배정됨”과 “차량이 명령을 실제로 ack함”을 같은 상태로 보여주면 안 됩니다.

차량 위치도 GPS 좌표 하나로 믿으면 안 됩니다. Robotaxi 배차에서 위치는 곧 비용입니다. 차량이 승객에게 2분 거리라고 계산했는데 실제로는 도로 반대편, 지하 주차장 입구, 접근 불가 차선에 있으면 픽업 실패가 생길 수 있습니다.

Tesla의 “Technologies for vehicle positioning” 공개 특허는 차량들이 map pose와 raw positioning measurement를 공유하고, 서버가 이를 통해 map-relative localization을 보정하는 아이디어를 설명합니다.

이 아이디어를 시스템 디자인에 반영하면, Fleet Manager는 단순 위치 저장소가 아니라 fleet positioning correction service를 가져야 합니다. 차량 위치에는 좌표뿐 아니라 confidence, correction version, stale 여부가 함께 붙어야 합니다.

승객의 현재 위치를 그대로 픽업 지점으로 쓰는 것도 충분하지 않습니다. 승객이 서 있는 위치와 차량이 안전하게 정차할 수 있는 지점은 다를 수 있습니다.

Tesla의 “Autonomous and user controlled vehicle summon to a target” 공개 특허는 사용자가 지도에서 목표 지점을 선택하고, 목적지가 충전소인 경우 차량이 충전 포트와 충전기를 맞추도록 orientation을 잡을 수 있다고 설명하고 있습니다.

이 아이디어는 Robotaxi Fleet Manager에서 두 가지 흐름으로 바뀌게 됩니다. 승객 위치와 실제 승차 지점을 분리하는 pickup rendezvous planner가 필요합니다. 또한 충전소 접근 시 차량 자세와 충전기 정렬을 고려하는 charging alignment planner도 필요합니다.

배터리가 낮은 차량을 그냥 가장 가까운 충전소로 보내는 것도 좋은 설계가 아닙니다. 가까운 충전소가 답처럼 보일 수 있지만, fleet 단위에서는 충전소가 공급 제약이 됩니다. 충전소가 이미 예약되어 있거나, 해당 충전소까지 이동하면 다음 피크 시간대 수요 지역에서 차량이 빠져나가거나, 충전 후 청소와 정비 슬롯이 필요할 수 있습니다.

자동 충전 관련 공개 특허 문헌은 이미지 기반으로 차량 정보를 식별하고, 데이터베이스에서 충전 포트 위치를 찾아 robotic arm이 충전 커넥터를 연결하는 방식을 설명합니다. 또 다른 특허 문헌은 목적지가 충전소일 때 차량이 충전 포트와 charger가 맞도록 orientation을 조정할 수 있다고 설명합니다. 이 내용을 시스템 디자인에 반영하면 충전은 “차량을 충전소로 보내기”가 아니라 charging slot reservation, vehicle alignment, charging command, charging state stream, failure recovery가 묶인 workflow가 됩니다.

승객이 내린 차량을 바로 다음 승객에게 보내도 되는지도 확인해야 합니다. 무인 ride-hailing에서는 차량 실내 상태가 fleet 처리량을 직접 압박하게 됩니다. 공개 특허 문헌 “Controlling environmental conditions in enclosed spaces”는 여러 사람이 공유하는 차량 cabin 같은 enclosed space를 대상으로 sensor data를 바탕으로 sanitation routine을 생성하는 흐름을 설명합니다.

이 내용을 시스템 디자인에 반영하면 Fleet Manager는 ride completion 직후 차량을 바로 배차하지 않습니다. cabin sensor 상태, cleaning requirement, service bay availability, passenger report를 보고 cabin readiness state를 갱신해야 합니다. 실내 상태가 불확실하면 배차 후보에서 보수적으로 제외하는 편이 안전하다고 할 수 있습니다.

Functional Requirements

1. 승객은 출발지, 목적지, 탑승 인원, 접근성 요구, 픽업 시간 조건을 기반으로 Robotaxi ride request를 생성할 수 있어야 합니다.

2. Fleet Manager는 차량 위치, 배터리, cabin readiness, 충전 계획, 규제 구역, 차량 명령 가능 상태를 바탕으로 차량을 배정할 수 있어야 합니다.

3. 시스템은 차량 telemetry stream을 받아 위치, 충전 상태, 차량 readiness, connectivity, invalid signal을 빠르게 반영할 수 있어야 합니다.

4. 시스템은 차량을 픽업 지점, 하차 지점, 충전소, 정비 지점, 청소 지점으로 보내는 원격 명령 workflow를 관리할 수 있어야 합니다.

5. 시스템은 약한 네트워크와 차량 offline 상태에서도 마지막 명령 상태와 ride 상태를 복구하고, 중복 배차와 중복 명령을 막을 수 있어야 합니다.

Non-Functional Requirements

1. ride request 접수 ACK는 p95 100ms 이내를 목표로 둡니다. 첫 배차 후보는 p95 500ms 이내, 차량 배정 확정은 p95 2초 이내를 목표로 둘 수 있습니다.

2. 차량 telemetry 지연이나 충전소 예약 지연이 승객 요청 접수와 ride 상태 조회 경로를 같이 밀지 않게 해야 합니다.

3. 차량 원격 명령, ride assignment, charging assignment, cabin readiness override, regulatory hold는 변경 이력과 idempotency_key를 남길 수 있어야 합니다.

Read more

Introduction & Requirements

아래 설계는 GitHub Copilot의 공개 문서와 제품 특성을 바탕으로 한 시스템 디자인 가정이며, GitHub Copilot 내부 구현을 그대로 설명하는 글은 아닙니다. 이 글은 foundation model 학습이나 GitHub 전체 호스팅 시스템을 설계하는 글이 아닙니다. 개발자가 IDE에서 코드를 작성할 때, 어떤 코드 조각과 설정과 정책을 모델 입력으로 넣을지 결정하는 context engine을 시스템 디자인 관점에서 다루는 글입니다.

GitHub Copilot을 시스템 디자인 문제로 받으면 처음에는 현재 파일 기반 자동완성 문제처럼 보일 수 있습니다.

“개발자가 코드를…

Read more

Introduction & Requirements

아래 설계는 Amazon Robotics Proteus의 공개 문서와 제품 특성을 바탕으로 한 시스템 디자인 가정이며, Amazon Robotics 내부 구현을 그대로 설명하는 글은 아닙니다. 이 글은 로봇의 모터 제어, 센서 융합 알고리즘, 실제 안전 인증 절차를 설명하는 글이 아니라, 사람과 로봇이 같은 운영 공간에서 움직일 때 로봇 위치, 작업 배정, 경로 조율, 지도 버전, 안전 이벤트를 어떻게 소프트웨어 인프라로 다룰지 설계하는 글입니다.

Amazon은 2012년 Kiva Systems 인수 이후 운영 네트워크 전반에 로봇을 대규모로 배치해 왔고, 2025년 공식 발표 기준…

Read more

Introduction & Requirements

아래 설계는 Neuralink의 공개 문서와 제품 특성을 바탕으로 한 시스템 디자인 가정이며, Neuralink 내부 구현을 그대로 설명하는 글은 아닙니다. 이 글은 의료 기기 안전성, 수술 로봇, 임상 규제 절차를 설명하는 글이 아니라, 이식 장치에서 발생하는 신경 신호를 낮은 전력과 낮은 지연 시간으로 외부 해석 장치까지 전달하는 데이터 경로를 설계하는 글입니다.

Read more

Introduction & Requirements

아래 설계는 X의 공개 도움말, 수익화 약관, 제품 특성을 바탕으로 한 시스템 디자인 가정이며, X 내부 구현을 그대로 설명하는 글은 아닙니다. 이 글은 광고 입찰 시스템이나 추천 알고리즘을 설계하는 글이 아니라, 이미 발생한 노출과 참여 이벤트를 크리에이터 수익 배분, 정산 원장, 지급 실행까지 연결하는 데이터 경로를 설계하는 글입니다.

X의 Creator Revenue Sharing은 공개 문서 기준으로, 자격을 갖춘 크리에이터가 X에서 만든 콘텐츠의 참여로부터 발생한 수익 일부를 받을 수 있는 프로그램입니다. 공개 약관은 수익 공유 프로그램을 통해 크리에이터가 콘텐츠 참여로부터…

Read more

Introduction & Requirements

발사 후 약 3분, booster와 2단이 분리되는 구간에서 지상국 handover가 일어났다고 해보겠습니다. 이전 지상국 경로에서 늦게 출발한 frame과 새 지상국 경로에서 먼저 도착한 frame이 몇 초 차이로 섞여 들어옵니다. 수신 서버가 도착 순서를 그대로 믿고 콘솔에 밀어 넣으면, propulsion 담당자는 압력 값이 잠깐 과거로 되돌아가는 화면을 보게 됩니다. 값 자체는 전부 정상인데 시간 순서가 어긋난 것입니다. 이 장면 하나가 원격 측정 플랫폼 설계에서 가장 먼저 다뤄야 할 문제를 보여줍니다. 센서 값을 받아 그래프에 띄우는 일이 아니라, 어떤 값이 지금 판단 가능한 값인지 구분하는 일이 이번 시스템 설계의 역할 입니다.

미리 분명히 해두겠습니다. 아래 설계는 공개된 발사체 사용자 가이드와 NASA의 공개 지상 시스템 자료를 참고해서 만든 면접용 설계 가정입니다. SpaceX 내부의 telemetry platform, command path, mission control 구현을 그대로 설명하는 글이 아니고, 본문에 나오는 컴포넌트 이름은 모두 이 글에서 정의한 것입니다.

공개 자료 기준으로 확인되는 사실은 이 정도입니다. Falcon의 avionics는 flight computer, GPS 수신기, 관성 측정 장치, S-band 송신기 등을 포함하고, S-band 송신기가 1단과 2단에서 지상으로 원격 측정과 영상을 전송합니다. 그리고 지상국은 telemetry, command, tracking을 서로 다른 서비스로 제공하며, 비행체에서 지상으로 내려오는 데이터 흐름은 downlink telemetry, 지상에서 비행체로 올라가는 흐름은 uplink command로 구분됩니다. 저궤도 비행체는 특정 지상국의 시야 안에 머무는 시간이 궤도의 일부에 그치고, relay 자산이 그 공백을 메웁니다.

이 서비스의 본질은 데이터 수집기가 아니라 판단 지원 시스템입니다. 발사, stage separation, 궤도 진입, docking, 재진입 같은 구간마다 flight controller가 화면의 값을 근거로 결정을 내립니다. 그래서 사용자가 보는 동선은 단순합니다. 콘솔을 열면 담당 subsystem의 최신 값, 경보, 추세, link 상태가 보이고, 필요하면 명령 요청을 올려 승인 절차를 거칩니다. 화면에서는 숫자 하나가 갱신되는 것처럼 보이지만, 그 뒤에서는 수신, 순서 보정, 중복 제거, 복호화, 우선순위 배포가 같이 돌아갑니다.

Read more

Introduction & Requirements

Read more

Introduction

ChatGPT의 비즈니스 본질은 단순한 모델 API 래퍼가 아닙니다. 사용자는 텍스트, 이미지, 파일, 음성으로 메시지를 보낼 수 있고, 프로젝트 안에서 대화와 파일을 묶어 문맥을 이어갈 수 있으며, 메모리 설정과 임시 대화 설정을 조정할 수 있습니다. 앱 연결이나 프로젝트 파일을 컨텍스트로 사용할 때는 사용자가 현재 접근 가능한 자료만 모델 입력에 들어가야 합니다. 캐시에 이전 검색 결과가 남아 있어도, 모델 입력에 넣기 직전에는 권한 기준 장부나 정책 서비스를 통해 현재 접근 가능 여부를 다시 확인해야 합니다.

메시지 실행을 단일 HTTP 요청 안에서 끝내려고 하면 파일 검색이나 코드 실행이 붙는 순간 처리 시간이 길어집니다. 클라이언트가 타임아웃 후 재시도하면 같은 메시지가 두 번 실행될 수 있습니다. 그래서 메시지를 전송하는 경로와 답변 이벤트를 구독하는 경로를 나눠야 합니다.

짧은 일반 대화와 파일 분석 요청을 같은 실행 경로에 넣는 선택도 문제가 됩니다. 파일 검색 대기 시간이 길어질 때 일반 메시지의 첫 이벤트 지연도 증가할 수 있기 때문입니다. 그래서 API 입구에서 요청의 무게를 나누고, 일반 응답과 무거운 도구 작업을 별도 worker pool로 분리해야 합니다.

토큰 단위 이벤트를 RDBMS에 모두 저장하는 것도 피해야 합니다. 최종 메시지는 나중에 다시 열어야 하는 장부성 데이터이고, 토큰 이벤트는 스트리밍 복구를 위해 짧은 시간 필요한 전송 상태입니다. 이 둘을 같은 RDBMS write path에 넣으면 긴 답변이 많은 시간대에 row insert 수가 급격히 늘고, 대화 목록 조회나 감사 이벤트 저장의 지연도 증가할 수 있습니다.

Read more

Introduction & Requirements

“사용자가 화면을 녹화하면 mp4 파일을 서버에 업로드하고, 업로드가 끝나면 링크를 만들면 되지 않을까요?”

작은 데모라면 됩니다. 그런데 Loom의 제품 가치는 단순히 화면 녹화 파일을 저장하는 데 있지 않습니다. 사용자는 녹화가 끝난 뒤 긴 업로드와 처리 시간을 기다리고 싶어 하지 않습니다. 녹화가 끝나자마자 링크를 복사하고, 상대방은 그 링크를 열자마자 영상을 재생하기를 기대합니다.

이 서비스의 비즈니스적 본질은 “영상을 저장한다”가 아니라 “비동기 커뮤니케이션의 지연 시간을 줄인다”입니다. 회의 대신 Loom을 보냅니다. 긴 이메일 대신 Loom을 보냅니다. 제품 설명, 코드 리뷰, 디자인 피드백, 고객 지원 답변을 영상으로 전달합니다. 그러면 시스템은 녹화 파일을 안전하게 저장하는 것만으로는 부족합니다. 녹화와 동시에 업로드를 시작하고, 업로드된 조각을 빠르게 재생 가능한 형태로 바꾸고, 공유 링크는 먼저 발급하고, 고화질 버전은 뒤에서 따라오게 만들어야 합니다.

Clarifying Questions - 인터뷰 전, 또는 시스템 디자인 전에 명확한 설계를 위해 해야 하는 질문들 입니다. 이 단계에서 설계 범위 그리고 최적화에 대한 부분들, 중점적으로 설계를 해야하는 부분들을 명확하게 가져갈 수 있습니다.

“녹화가 끝나기 전부터 업로드를 시작해야 하나요, 아니면 녹화가 끝난 뒤 전체 파일을 한 번에 업로드 해야 되나요?”

이 질문 하나가 전체 시스템에 영향을 줄 수 있습니다. 전체 파일을 한 번에 올리는 구조는 단순합니다. 하지만 30분짜리 화면 녹화를 생각해보세요. 사용자는 녹화가 끝난 뒤 업로드가 끝날 때까지 기다립니다. 업로드 도중 네트워크가 끊기면 처음부터 다시 올려야 할 수도 있습니다. 녹화 파일이 커질수록 사용자 경험은 점점 나빠집니다. 그래서 Loom 시스템 디자인에서는 녹화 중에도 작은 영상 분할 데이터 chunk 를 계속 업로드하고, 서버는 먼저 도착한 분할 데이터 chunk 부터 처리합니다.

여기서 말하는 점진적 처리는 라이브 방송처럼 녹화 중 상대방이 동시에 본다는 뜻이 아닙니다. 녹화 중 조각을 미리 올려두고, 녹화 종료 직후 준비된 앞부분부터 빠르게 재생 가능하게 만드는 방향으로 잡겠습니다.

Read more

Introduction & Requirements

Salesforce를 처음 보면 고객 정보를 저장하고 조회하는 업무 앱처럼 보입니다. 그런데 시스템 디자인 문제로 들어가면 바로 복잡해집니다.

같은 플랫폼 위에 수많은 기업 고객이 올라가고, 각 회사는 서로 다른 데이터 구조, 화면 구성, 업무 자동화, 사용자 권한, 조직 역할 구조, 데이터 공유 규칙을 가집니다.

기술적으로는 이 회사 단위 공간을 tenant라고 부르고, 고객이나 영업 기회 같은 데이터 단위를 object와 record라고 부릅니다.

어떤 회사는 고객, 연락처, 영업 기회만 씁니다. 어떤 회사는 수백 개의 맞춤형 데이터 구조와 수천 개의 맞춤형 필드를 씁니다. 어떤 회사는 리포트와 대시보드를 짧은 주기로 반복 조회하고, 어떤 회사는 대량 데이터 이전이나 외부 시스템 동기화로 매우 큰 규모의 데이터를 한 번에 밀어 넣습니다.

그래서 이번 설계에서는 화면보다 먼저 "회사별 데이터가 섞이지 않게 하는 문제"를 봐야 합니다. 그다음에는 회사마다 다른 데이터 구조를 어떻게 해석할지, 사용자가 볼 수 있는 데이터만 어떻게 빠르게 걸러낼지, 대량 저장과 리포트 조회가 일반 화면 요청을 압박하지 않게 어떻게 분리할지를 봐야 합니다.

Functional Requirements

1. 사용자는 회사 공간 안에서 고객사, 연락처, 영업 기회, 지원 요청, 맞춤형 데이터 한 건을 생성하고 조회하고 수정하고 삭제할 수 있어야 합니다.

2. 시스템은 데이터를 조회할 때 회사 공간 분리, 객체 접근 권한, 필드 표시 권한, 데이터 한 건 단위의 공유 규칙을 적용해야 합니다.

3. 회사마다 다른 데이터 구조, 필드 정의, 입력 검증 규칙, 업무 자동화 규칙을 실행 시점에 반영할 수 있어야 합니다.

4. 대량 데이터 입력과 대량 수정은 일반 사용자의 화면 저장 경로와 분리해서 처리해야 합니다.

5. 데이터가 바뀐 뒤에는 변경 이벤트 발행, 업무 자동화 실행, 대시보드 캐시 무효화, 외부 시스템 동기화를 비동기로 처리해야 합니다.

Read more

Introduction & Requirements

아래 설계는 Perplexity의 공개 API 문서와 검색형 AI 제품 특성을 바탕으로 한 시스템 디자인 가정이며, Perplexity 내부 구현을 그대로 설명하는 글은 아닙니다.

Perplexity AI를 시스템 디자인 문제로 받으면, 주니어 엔지니어가 가장 먼저 하는 실수가 있습니다. 문제를 너무 작게 잡습니다.

“사용자가 질문을 입력하면 LLM이 답변을 만들고, 그 답변을 저장하면 되지 않을까요?”

이렇게 말하면 면접관은 바로 다음 질문을 던질 겁니다.

“그 답변은 어디서 나온 건가요?”

Perplexity AI는 단순 생성형 답변 UI가 아닙니다. Perplexity의 공식 API 문서도 Search API를 실시간 웹 검색 결과, 랭킹 결과, 도메인 필터, 다중 쿼리 검색, 콘텐츠 추출을 제공하는 경로로 설명합니다. 그리고 Sonar는 웹 기반 응답, citation, conversation context, streaming을 제공하는 경로로 설명합니다. 즉 이 시스템의 설계 대상은 “답변 생성”이 아니라 “검색, 출처 선별, 생성, 인용, 스트리밍을 하나의 응답으로 묶는 실시간 답변 엔진”입니다.

면접에서 먼저 잡아야 할 질문은 이겁니다.

“우리가 설계하는 것은 단순 질의 응답인가요, 아니면 citation이 붙은 source-grounded answer engine인가요?”

이 질문이 먼저 나와야 합니다. 왜냐하면 citation이 붙는 순간 시스템의 중심 축이 달라집니다. answer text만 저장하면 되는 게 아닙니다. 어떤 검색 후보가 들어왔는지, 어떤 source가 최종 context에 들어갔는지, 답변의 어느 문장이 어느 source에 기대고 있는지, source가 나중에 접근 불가능해졌을 때 citation을 어떻게 표시할지까지 설계해야 합니다.

두 번째 질문은 이겁니다.

“모든 질문이 실시간 검색을 타야 하나요, 아니면 캐시된 검색 결과를 허용하나요?”

이 질문은 비용과 latency를 가릅니다. 모든 질문을 실시간 검색, 문서 추출, reranking, LLM 생성, citation mapping으로 태우면 답변 품질은 좋아 보일 수 있습니다. 하지만 피크 시간대에는 Search Orchestrator, Document Extractor, Ranking Service, Model Gateway, Stream Gateway가 동시에 압박받습니다. 반대로 캐시를 적극적으로 쓰면 latency와 비용은 줄어듭니다. 하지만 source freshness가 떨어질 수 있습니다.

아키텍트는 이 시점에서 냉정한 결단을 내려야 합니다. 모든 질문에 같은 신선도와 같은 검색 깊이를 주는 설계는 보기에는 공평합니다. 하지만 운영에서는 정상 작동하기 어렵습니다. 사용자의 질문 의도에 따라 fast path와 deep research path를 나눠야 합니다.

세 번째 질문은 이겁니다.

“사용자는 완성된 답변만 받아야 하나요, 아니면 처리 상태와 partial answer를 streaming으로 받아야 하나요?”

Perplexity AI 같은 서비스에서 streaming은 단순 UI 장식이 아닙니다. 인간의 인지적 한계를 이용하는 UX 계약에 가깝습니다. 긴 분산 작업을 사용자가 이해 가능한 작은 상태 변화로 쪼개 보여주는 방식입니다. 사용자는 전체 답변 완료 시간이 8초여도, 1.5초 안에 첫 문장을 보면 시스템이 빠르다고 느낍니다. 그런데 이 UX 계약은 인프라 비용을 가져옵니다. streaming connection은 오래 열려 있습니다. client network가 약하면 서버 buffer가 쌓입니다. 재연결이 늘어나면 Event Sync API도 같이 바빠집니다.

네 번째 질문은 이겁니다.

“답변 생성 이후에도 source freshness를 다시 확인해야 하나요?”

이 질문이 중요합니다. source는 답변 생성 시점에는 접근 가능했지만, 사용자가 나중에 다시 열었을 때는 접근 불가능할 수 있습니다. 그래서 answer와 source status를 분리해야 합니다. answer는 과거 생성 결과로 보존할 수 있습니다. 하지만 citation은 현재 validation status를 반영해야 합니다. 특히 notification이나 shared preview처럼 시스템이 사용자에게 먼저 밀어내는 경로에서는 Send-time Validation이 필요합니다.

Functional Requirements

Read more

Twitch(트위치)는 단순한 웹 동영상 재생 서비스가 아니라, 초저지연 라이브 미디어 전송 인프라와 대규모 실시간 Pub/Sub 메시징 시스템이 결합된 분산 플랫폼에 가깝습니다.

e스포츠 결승전이나 글로벌 탑 스트리머의 방송에 단일 채널 기준 수십만 명에서 100만 명 수준의 동시 시청자가 몰릴 수 있습니다. 이때 시스템은 1080p 60FPS 고해상도 미디어 스트림을 전 세계 엣지 인프라로 짧은 지연 시간 안에 배포해야 합니다.

동시에 채팅, 이모티콘, 구독, 후원, 시청자 수 같은 실시간 이벤트도 처리해야 합니다. 특히 단일 채널에서 초당 수만 건의 채팅 메시지가 발생하면, 이를 일반적인 데이터베이스 쓰기 경로로 처리해서는 안 됩니다. 미디어 전송 경로, 채팅 경로, 결제 및 이벤트 경로를 서로 분리해야 안정적인 처리가 가능합니다.

이 글에서는 Twitch 같은 라이브 스트리밍 서비스를 다음 질문을 중심으로 설계합니다.

“100만 명 수준의 시청자에게 고화질 라이브 비디오를 전송할 때, 원본 서버와 API 서버에 미디어 트래픽이 직접 집중되지 않도록 트랜스코딩과 CDN 인프라를 어떻게 나눌 것인가?”

“단일 채널에서 초당 수만 개의 채팅이 발생할 때, 데이터베이스 쓰기 병목과 브라우저 DOM 렌더링 부담을 어떻게 줄일 것인가?”

“상태가 무겁고 비용이 큰 비디오 처리 파이프라인과, 가볍고 휘발성이 강한 실시간 채팅 파이프라인을 어떻게 분리할 것인가?”

“시청자의 네트워크 상태가 계속 바뀔 때, 비디오 플레이어는 어떤 기준으로 1080p, 720p, 480p 화질을 전환해야 하는가?”

“실시간 시청자 수, 구독, 후원 같은 이벤트를 전 세계 시청자에게 지연을 줄이면서 전달하려면 어떤 fan-out 구조가 필요한가?”

Twitch 같은 라이브 스트리밍 서비스 설계는 대규모 미디어 전송(Video Delivery)과 휘발성 실시간 트래픽 제어(Graceful Degradation)를 함께 다루기 좋은 시스템 디자인 문제입니다.

Functional Requirements - 기능적 요구사항

• 스트리머는 OBS 같은 방송 소프트웨어를 통해 RTMP ingest endpoint로 비디오/오디오 스트림을 송출할 수 있어야 합니다.

• 시청자는 본인의 네트워크 상태에 따라 1080p, 720p, 480p 등 서로 다른 해상도와 비트레이트의 미디어를 자동으로 수신할 수 있어야 합니다.

• 사용자는 채널별 WebSocket 세션에 연결되어 실시간 채팅 메시지를 송수신할 수 있어야 하며, 커스텀 이모티콘은 메시지 본문이 아니라 이모티콘 ID와 CDN URL 메타데이터 기반으로 처리되어야 합니다.

• 전 세계 분산 노드에서 시청 중인 단일 채널의 동시 시청자 수와 라이브 상태는 수 초 단위의 지연을 허용하되, 사용자 화면에는 일관된 방향으로 갱신되어야 합니다.

• 후원(Bits), 구독(Subscription) 같은 트랜잭션이 성공하면, 해당 채널을 시청 중인 사용자들에게 오버레이 이벤트가 실시간으로 전파되어야 합니다.

Non-Functional Requirements - 비기능적 요구사항

Ultra-Low Latency - 초저지연 미디어 파이프라인

스트리머의 캡처 장비에서 인코딩된 영상이 시청자 화면에 렌더링되기까지의 Glass-to-Glass Latency를 수 초 단위로 낮추는 것을 목표로 합니다.

일반 HLS보다 낮은 지연을 위해 LL-HLS 또는 유사한 저지연 스트리밍 방식을 사용할 수 있지만, 실제 지연 시간은 네트워크 상태, CDN 설정, 플레이어 버퍼 전략에 따라 달라집니다.

Graceful Degradation - 우아한 성능 저하

대형 이벤트로 인해 단일 채널에 초당 수만~수십만 건의 채팅 버스트가 발생할 수 있습니다.

이 경우 시스템은 모든 메시지를 동일한 품질로 저장하고 전달하려고 하기보다, 채팅 전송 경로를 메인 스토리지에서 분리하고, 필요하면 batching, throttling, sampling, dropping을 적용해야 합니다.

목표는 모든 메시지를 동일한 경로에서 보존하는 것이 아니라, 비디오 재생과 기본 채팅 경험을 안정적으로 유지하는 것입니다.

High Availability & Flash Crowd 확장성

대형 e스포츠 경기, 유명 스트리머의 방송 시작처럼 특정 채널로 트래픽이 짧은 시간 안에 집중될 수 있습니다.

이때 미디어 전송은 CDN과 엣지 캐시 계층에서 흡수하고, 채팅과 이벤트는 channel sharding, WebSocket gateway fan-out, partitioned pub/sub 구조로 분산 처리해야 합니다.

Scope 정리

In Scope

RTMP ingest layer부터 transcoder farm, media origin, CDN 배포로 이어지는 라이브 미디어 write/read path 설계

HLS/LL-HLS 기반 미디어 segment와 manifest 갱신 구조

클라이언트 비디오 플레이어의 ABR(Adaptive Bitrate) 전략

단일 채널 초대형 CCU 상황을 처리하기 위한 WebSocket gateway, channel sharding, partitioned pub/sub 기반 실시간 메시징 구조

초고빈도 채팅 수신과 클라이언트 DOM 렌더링 부담을 줄이기 위한 batching, throttling, dropping 전략

Out of Scope

방송 종료 후 VOD 영구 저장소로 이관되는 스토리지 아키텍처와 VOD 전용 트랜스코딩 파이프라인

스트리머 정산 대시보드와 광고 수익 분배를 위한 데이터 웨어하우스 내부 설계

실시간 저작권 음원 필터링과 유해 영상 실시간 ML 추론 파이프라인

가정하는 규모 - Scale Estimation

DAU: 3,500만 명

Peak Global CCU: 500만 명

Maximum CCU in a Single Channel: 최대 100만 명 수준의 extreme case

Peak Outbound Network Bandwidth: 단일 대형 채널 기준 수 Tbps, 글로벌 피크 기준 수십 Tbps 이상

Peak Chat Ingestion QPS: 글로벌 기준 수십만 QPS 이상

Peak Chat Fan-out Events: 수천만 fan-out event/sec 수준까지 확장 가능하도록 설계

Target Latency: 미디어 지연은 수 초 단위, 채팅 및 이벤트 라우팅은 수십~수백 ms 단위를 목표로 설계

Core Entities

트위치 시스템의 데이터 모델링에서 중요한 점은 모든 데이터를 하나의 관계형 데이터베이스에 넣지 않는 것입니다.

유저, 채널, 구독 관계처럼 오래 유지되어야 하는 데이터는 영구 저장소에 둡니다.

반면 라이브 채팅, 실시간 시청자 수, 영상 청크 전송 상태처럼 초당 매우 자주 변하는 데이터는 메인 RDBMS의 동기 쓰기 경로에서 분리합니다.

즉, Twitch의 데이터 모델은 크게 세 가지 경로로 나뉩니다.

영구 저장 데이터
→ accounts, channels, subscriptions

미디어 인프라 메타데이터
→ live_streams, ingest node, manifest path, available renditions

휘발성 실시간 데이터
→ chat messages, viewer count, presence state

이 구분을 하지 않으면 채팅이나 시청자 수처럼 초고빈도로 변하는 데이터가 계정, 채널, 결제 같은 중요한 영구 데이터 경로에 영향을 줄 수 있습니다.

1. accounts, 사용자 및 스트리머 계정

서비스를 이용하는 일반 시청자와 방송을 송출하는 스트리머의 계정 정보입니다.

이 테이블은 실시간 채팅 메시지나 시청 기록을 저장하는 곳이 아닙니다. 웹소켓 세션 인증, 채널 소유권 확인, 스트리머 권한 검증에 필요한 최소 계정 정보를 저장합니다.

id: UUID
username: VARCHAR(50), UNIQUE
email: VARCHAR(255)
role: VIEWER | STREAMER | ADMIN
created_at: TIMESTAMP
updated_at: TIMESTAMP

username은 로그인과 채팅 디스플레이에 사용되므로 unique index가 필요합니다. role은 스트리머 권한, 관리자 권한, 일반 시청자 권한을 구분하는 데 사용합니다.

2. channels, 스트리머 채널 메타데이터

스트리머의 방송 채널을 나타내는 엔티티입니다. 채널 페이지, 검색, 추천, 팔로우 목록에서 자주 조회되므로 read-heavy한 데이터입니다. 다만, 실시간 시청자 수나 초고빈도 채팅 상태를 이 테이블에 직접 업데이트하면 안 됩니다.

id: UUID
streamer_id: UUID, UNIQUE
title: VARCHAR(255)
game_category_id: INT
stream_key_hash: VARCHAR(255)
is_live: BOOLEAN
current_live_stream_id: UUID, NULLABLE
version: INT
created_at: TIMESTAMP
updated_at: TIMESTAMP

stream_key는 평문으로 저장하지 않는 것이 좋습니다. 대신, stream_key_hash 또는 별도 secret store에 저장하고, ingest 인증 시 검증합니다. is_live는 현재 라이브 상태를 나타내지만, 초 단위로 계속 업데이트되는 viewer count와는 분리해야 합니다.

version은 스트리머가 방송 제목이나 카테고리를 수정할 때 낙관적 락을 적용하기 위한 필드입니다.

3. live_streams, 실시간 라이브 세션 로그

스트리머가 방송을 시작할 때 생성되는 라이브 세션 정보입니다. 하나의 채널은 여러 번 방송할 수 있으므로, channels와 live_streams는 1:N 관계입니다. 이 테이블은 영상 파일 자체를 저장하지 않습니다. 인제스트 노드, 트랜스코딩 상태, 매니페스트 경로 같은 미디어 인프라 메타데이터를 추적합니다.

id: UUID
channel_id: UUID, INDEX
ingest_region: VARCHAR(50)
ingest_node_id: VARCHAR(100)
origin_manifest_url: VARCHAR(512)
available_renditions: JSONB
status: STARTING | LIVE | ENDING | ENDED
last_viewer_count_snapshot: INT
started_at: TIMESTAMP
ended_at: TIMESTAMP, NULLABLE

available_renditions 예시는 다음과 같습니다.

{
  "renditions": [
    {"resolution": "1080p60", "bitrate_bps": 8000000, "manifest_name": "1080p60/index.m3u8"},
    {"resolution": "720p60", "bitrate_bps": 5000000, "manifest_name": "720p60/index.m3u8"},
    {"resolution": "480p30", "bitrate_bps": 2000000, "manifest_name": "480p30/index.m3u8"}
  ]
}

last_viewer_count_snapshot은 실시간 카운터의 최종 값이 아니라, 장애 대응이나 UI fallback에 사용할 수 있는 주기적 스냅샷입니다. 실시간 시청자 수 자체는 Redis, Flink, Kafka Streams, HyperLogLog 같은 별도 경로에서 집계하는 편이 적합합니다.

4. stream_emotes, 채널 전용 커스텀 이모티콘

Twitch 채팅에서는 커스텀 이모티콘이 매우 자주 사용됩니다. 하지만 채팅 메시지 안에 이미지 바이너리를 직접 넣으면 안 됩니다. 채팅 payload에는 이모티콘 코드나 ID만 포함하고, 클라이언트는 미리 받은 메타데이터를 바탕으로 CDN에서 이미지를 렌더링합니다.

id: UUID
channel_id: UUID, NULLABLE
emote_code: VARCHAR(50)
cdn_url: VARCHAR(512)
asset_version: INT
is_global: BOOLEAN
created_at: TIMESTAMP

channel_id가 NULL이면 글로벌 공용 이모티콘으로 볼 수 있습니다.

asset_version은 이모티콘 이미지가 갱신되었을 때 클라이언트 캐시를 무효화하는 데 사용할 수 있습니다. 채팅 메시지는 이렇게 가볍게 유지합니다.

{
  "sender": "viewer_ko",
  "message": "ㅋㅋㅋ",
  "emotes": ["pog_1", "kappa_2"]
}

5. channel_subscriptions, 사용자 구독 및 후원 관계 관계 테이블

사용자가 특정 스트리머를 유료 구독하는 관계를 나타냅니다. 구독은 결제와 연결되므로 일반 채팅처럼 휘발성 이벤트로 처리하면 안 됩니다. ACID 트랜잭션이 필요한 영구 데이터입니다.

id: UUID
subscriber_id: UUID
channel_id: UUID
tier: TIER_1 | TIER_2 | TIER_3
is_active: BOOLEAN
started_at: TIMESTAMP
expires_at: TIMESTAMP
created_at: TIMESTAMP
updated_at: TIMESTAMP

subscriber_id + channel_id에는 index가 필요합니다.

사용자가 해당 채널에서 구독자 전용 이모티콘을 사용할 수 있는지, 구독자 전용 채팅에 참여할 수 있는지 판단할 때 자주 조회되기 때문입니다.

6. donation_events 또는 bits_transactions

후원 및 Bits 트랜잭션

기존 초안에서는 후원과 구독을 channel_subscriptions 안에서 함께 설명했는데, 실제 모델링에서는 분리하는 편이 좋습니다. 구독은 지속적인 관계이고, 후원/Bits는 개별 금융 이벤트입니다.

id: UUID
viewer_id: UUID
channel_id: UUID
amount: INT
currency_or_bits_type: VARCHAR(20)
payment_status: PENDING | CONFIRMED | FAILED
event_id: UUID
created_at: TIMESTAMP

결제 성공 후에는 DONATION_CONFIRMED 또는 BITS_USED 이벤트를 발행하고, 이 이벤트를 WebSocket overlay fan-out 경로로 전달합니다. 이때 결제 기록은 영구 저장소에 남기고, 오버레이 전파는 비동기로 분리합니다.

RDBMS 동기 쓰기 경로에서 분리해야 하는 데이터

1. 실시간 채팅 메시지

초대형 채널에서는 초당 수만 건의 채팅 메시지가 발생할 수 있습니다. 이를 매번 RDBMS에 동기 INSERT하면 디스크 쓰기, index update, lock 경합, replication lag 비용이 커집니다. 따라서, 라이브 화면에 전달되는 채팅 경로는 RDBMS 동기 쓰기에서 분리합니다. 대신 다음과 같은 구조를 사용합니다.

WebSocket Gateway
→ Partitioned Pub/Sub
→ Gateway Fan-out
→ Client Rendering Buffer

다만 모든 채팅을 “영구 저장하지 않는다”고 단정하면 안 됩니다. 모더레이션, 신고, 스팸 탐지, VOD chat replay, 분석 목적의 일부 메시지는 별도 비동기 로그 파이프라인에 저장할 수 있습니다.

즉, 정리하면 이렇습니다.

라이브 채팅 전달 경로
→ RDBMS 동기 쓰기 제외

모더레이션/분석/VOD replay 경로
→ 비동기 로그 저장 가능

2. 실시간 동시 시청자 수

동시 시청자 수를 다음처럼 업데이트하면 안 됩니다.

UPDATE live_streams
SET viewer_count = viewer_count + 1
WHERE id = 'stream_123';

전 세계 수백만 명의 시청자가 들어오고 나갈 때마다 같은 row를 업데이트하면 row lock 경합과 replication 지연이 커집니다. 대신, presence event를 별도 스트림으로 처리합니다.

viewer_joined
viewer_left
heartbeat

이 이벤트를 Redis, Kafka Streams, Flink, HyperLogLog, Count-Min Sketch 같은 구조로 집계합니다. 정확한 1명 단위 숫자보다 수 초 단위의 근사치가 더 적합합니다. 전달 방식도 여러 선택지가 있습니다.

별도 lightweight metadata endpoint
WebSocket metadata channel
manifest sidecar metadata
m3u8 metadata tag

다만 .m3u8에 직접 viewer count를 넣는 방식은 CDN 캐시 정책과 최신성 제어를 같이 설계해야 하므로 단정하지 않는 편이 좋습니다.

최종 정리

Twitch의 Core Entity 설계에서 중요한 원칙은 이것입니다.

영구성이 필요한 데이터는 RDBMS에 둡니다.

accounts
channels
live_streams metadata
subscriptions
donation transactions
emote metadata

초고빈도 실시간 데이터는 RDBMS 동기 쓰기 경로에서 분리합니다.

chat messages
viewer presence
viewer count
live overlay fan-out

채팅은 WebSocket Gateway와 partitioned Pub/Sub 경로로 처리합니다. 시청자 수는 row update가 아니라 분산 카운터와 주기적 스냅샷으로 처리합니다. 후원과 구독은 금융 데이터이므로 영구 저장하고, 화면 오버레이 전파는 이벤트 기반으로 분리합니다.

API Signatures

Twitch 같은 실시간 라이브 스트리밍 플랫폼은 사용자가 채널을 클릭하면 영상이 나오고, 타이핑을 하면 채팅이 뜨고, 후원이나 구독이 발생하면 화면 위에 오버레이 알림이 표시되는 서비스입니다.

하지만 시스템 내부에서는 세 가지 성격이 완전히 다른 데이터 경로가 동시에 동작합니다.

첫 번째는 라이브 비디오 전송 경로입니다.

스트리머가 OBS 같은 인코더에서 RTMP로 원본 영상을 송출하면, 시스템은 이를 ingest server에서 받아 transcoder farm으로 전달합니다. 이후 1080p60, 720p60, 480p30 같은 여러 화질로 변환하고, HLS/LL-HLS segment와 manifest를 생성한 뒤 CDN edge로 배포합니다.

두 번째는 실시간 채팅 경로입니다.

채팅은 영상과 다르게 크기는 작지만 빈도가 매우 높습니다. 단일 대형 채널에서 초당 수만 개의 메시지가 발생할 수 있으므로, 이를 일반적인 RDBMS 동기 쓰기 경로에 태우면 디스크 쓰기, 인덱스 갱신, replication 비용이 급격히 증가합니다. 따라서 채팅 전송 경로는 WebSocket Gateway와 partitioned Pub/Sub 구조로 분리합니다.

세 번째는 실시간 이벤트 경로입니다.

구독, Bits, 후원, 라이브 상태 변경, 시청자 수 갱신 같은 이벤트는 채널을 보고 있는 사용자 화면에 빠르게 전파되어야 합니다. 다만 결제 자체는 ACID 트랜잭션으로 안전하게 저장하고, 화면 오버레이 전파는 비동기 이벤트 파이프라인으로 분리합니다.

이 섹션에서는 Twitch의 주요 API를 아래 네 가지 경로로 나누어 설명합니다.

1. Live Video Stream Ingestion & Playlist Read API

2. High-Frequency Chat Ingestion & Connection Management API

3. Live Metadata & Event Overlay Streaming API

4. Weak Network Support & Local Mutation Sync API

1. Live Video Stream Ingestion & Playlist Read API, 라이브 미디어 스트림 인제스트 및 재생 경로

스트리머가 방송 시작 버튼을 누르는 순간부터 시청자의 비디오 플레이어가 영상을 재생하기까지의 경로입니다.

스트리머의 인코더는 RTMP ingest endpoint로 원본 스트림을 송출합니다. 시청자의 플레이어는 직접 API 서버에서 비디오 바이너리를 받지 않고, CDN edge에 있는 manifest와 media segment를 요청합니다.

POST /v1/streams/ingest/authorize
{
  "channel_id": "chan_faker123",
  "stream_key": "live_sk_882319fka90123",
  "ingest_region": "ap-northeast-2",
  "encoder_spec": {
    "codec": "H.264",
    "bitrate": 8000000,
    "fps": 60,
    "resolution": "1920x1080"
  }
}

이 API는 스트리머가 실제 미디어를 보내기 전에 stream key가 유효한지 확인하는 경량 인증 경로입니다.

Twitch 기준으로 방송 소프트웨어는 RTMP URL과 stream key를 사용해 ingest subsystem으로 스트림을 송출합니다. stream key는 방송 권한을 식별하는 민감한 값이므로 평문 저장을 피하고, hash 또는 secret store 기반 검증을 사용하는 편이 안전합니다.

Playback Manifest API

GET /v1/streams/chan_faker123/playback
Headers:
Authorization: Bearer <JWT_TOKEN>
X-Client-Network-Bandwidth: 15400000

응답 예시는 다음과 같습니다.

{
  "channel_id": "chan_faker123",
  "live_stream_id": "stream_20260521_001",
  "master_manifest_url": "https://edge-cdn.example.com/live/chan_faker123/master.m3u8",
  "supported_renditions": [
    "1080p60",
    "720p60",
    "480p30",
    "audio_only"
  ],
  "low_latency_enabled": true
}

API 서버는 비디오 청크 바이너리를 직접 반환하지 않습니다.

대신 CDN edge에 있는 master.m3u8 URL만 반환합니다. 이후 플레이어는 CDN edge에서 manifest와 media segment를 직접 가져옵니다.

비디오 전송의 단계별 데이터 흐름, Data Flow

1.미디어 수신 및 인증

스트리머의 OBS 인코더가 지정된 RTMP 수신 서버(Ingest Server)로 영상을 쏩니다. 수신 서버는 매번 DB를 조회하는 대신, 캐시된 크리덴셜 정보를 활용해 대기시간(Latency) 없이 빠르게 Stream Key를 검증합니다.

2.실시간 트랜스코딩

수신된 원본 영상 스트림은 트랜스코더 서버군(Transcoder Farm)으로 넘겨집니다. 여기서 원본 고화질 영상을 시청자의 다양한 네트워크 환경에 맞춰 여러 화질(1080p, 720p, 480p, Audio-only)로 실시간 인코딩합니다.

3.청크(Chunk) 및 매니페스트 생성

Read more

Zillow 는 “거대한 글로벌 시공간(Geospatial) 인덱싱 엔진이자, 실시간 데이터 정합성 보장 플랫폼”에 가깝습니다. 사용자가 지도상에서 화면을 이리저리 이동할 때마다, 시스템은 수천만 개의 부동산 데이터 중 해당 화면 좌표 내에 존재하는 매물을 수십 밀리초(ms) 이내에 찾아내 렌더링해야 합니다.

“위도/경도 기반의 대규모 공간 데이터를 RDB가 아닌 어떤 인덱싱 알고리즘(Quadtree, Uber H3)으로 관리해야 검색 병목이 없을지”

“동일한 매물에 대해 수만 명의 사용자가 보고 있는 상황에서, 집값 변동이나 계약 완료 상태를 어떻게 데이터 유실 없이 실시간으로 전파할 것인가?”

“질로우의 가치 예측 모델(Zestimate)이 백엔드 파이프라인과 어떻게 결합하여 실시간 가격 변동 이력을 관리할 것인가?”

Zillow 같은 대규모 부동산 서비스 설계는 “공간 데이터 처리(Geospatial Query)”와 “대규모 읽기 최적화(Read-Heavy System)” 역량을 훈련하기 좋은 문제이기에 이 컨텐츠를 제작했습니다.

• 질로우의 ‘시공간(Geospatial) 매물 검색 아키텍처’를 데이터베이스로 어떻게 모델링할까?

• 사용자가 지도를 드래그하고 확대, 축소할 때 발생하는 수만 QPS의 지도 기반 쿼리 병목을 어떻게 해결할까?

• 매물 가격 변동이나 상태 변화(판매 중 → 계약 완료) 정보를 수백만 명의 관심 사용자에게 어떻게 실시간 알림으로 유실 없이 전파할까?

• 집 한 채당 수십 장씩 존재하는 고화질 부동산 이미지와 메타데이터를 글로벌 사용자에게 최저 지연 시간(Low Latency)으로 서빙하는 구조는 무엇일까?

• Zillow 의 자체 자산 가치 평가 엔진(Zestimate)의 대량 배치/스트리밍 연산 결과를 실시간 서비스 레이어에 어떻게 안정적으로 반영할까?

Functional Requirements - 기능적 요구사항

• 사용자는 화면 지도 상의 경계 상자(Bounding Box, 위도와 경도 범위) 내에 있는 매물을 검색하고, 가격, 방 개수, 매물 종류 등으로 필터링할 수 있어야 합니다.

• 매물의 고화질 사진 리스트, 가치 변동 이력(Zestimate History), 주변 학군 및 편의시설 등의 상세 데이터를 제공해야 합니다.

• 중개인이나 집주인이 새로운 매물을 등록하거나, 가격 변경, 매각 완료 등 매물의 상태를 실시간으로 업데이트할 수 있어야 합니다.

• 사용자가 특정 지역이나 필터 조건을 저장하면, 해당 조건에 맞는 새로운 매물이 등록되거나 가격이 변동되었을 때 실시간 푸시 알림 및 이메일을 발송해야 합니다.

Non-Functional Requirements - 비기능적 요구사항

• Low Latency (Read-Heavy)

  • 사용자가 지도를 이동하거나 확대/축소할 때 매물 마커가 화면에 렌더링되는 시간은 수백 밀리초(ms) 이내여야 합니다. (Read와 Write의 비율이 100:1 이상인 Read-Heavy 시스템)

• High Availability 및 확장성 (Scalability)

  • 특정 핫플레이스 지역이나 출퇴근 시간대에 트래픽이 폭발하더라도 시스템이 중단 없이 매끄럽게 동작해야 합니다.

• Consistency

  • 집값 변동이나 매물 상태(판매 중 또는 계약 완료)가 너무 오랫동안 구버전으로 캐시에 남아있어 허위 매물로 노출되는 상황을 최소화해야 합니다. (Eventual Consistency 최종 일관성 보장 및 적절한 Cache Invalidation 전략 필요)

Scope 정리

In Scope

• 시공간 데이터 모델링 및 지오 인덱싱(Geospatial Indexing) 구조 설계

• 지도 경계면(Bounding Box) 내 대규모 매물 검색 최적화 및 필터링 파이프라인

• Read-Heavy 트래픽 처리를 위한 다층 캐시(Multi-level Cache) 및 CDN 아키텍처

• 실시간 매물 상태 변동 전파 및 대규모 알림 팬아웃(Fan-out) 시스템

Out of Scope

• 3D 가상 투어(Virtual Tour) 영상 스트리밍 처리 기술의 상세 구현

• 부동산 중개인과의 실시간 채팅/통화 연결 시스템 내부 상세

• 매물 계약 진행 시 필요한 금융 및 전자결제/대출(Mortgage) 심사 시스템

가정하는 규모

• DAU (Daily Active Users)

  • 3,000만 명

• Concurrent Users (Peak)

  • 500만 명

• Total Registered Properties (총 매물 수): 1억 5,000만 건 (미국 전체 주택 기준 가정)

• Peak QPS

  • Page & Map Read (조회/검색)

    • 수만 ~ 수십만 QPS (사용자의 지도 이동 및 필터 조작이 매우 잦음)

  • Property Write/Update (등록/수정)

    • 수천 QPS (상대적으로 Read에 비해 빈도가 낮음)

• Latency

  • 지도를 조작할 때 지도 내 매물 마커 응답 속도 < 200ms

  • 상세 페이지 조회 < 100ms.

Core Entities

accounts (사용자 및 중개인)

서비스를 이용하는 일반 구매자(Buyer) 및 매물을 등록, 관리하는 부동산 중개인(Agent)의 계정 정보입니다. 실시간 채팅이나 금융 대출 심사 등 Out of Scope 영역의 복잡한 데이터는 철저히 제외하고, 시스템 인증 및 매물 수정 권한 검증에 필요한 최소한의 프로필만 유지합니다.

• id: UUID (글로벌 식별자)

• role: BUYER, AGENT 등의 권한 구분

• agent_license_number: 중개인인 경우 공인 자격증 번호 (일반 유저는 Null)

properties

미국 전역의 모든 주택 정보를 담고 있으며, 지리적 조회 성능을 위해 공간 데이터 인덱싱이 적용되는 테이블입니다. 중개인이 매물을 등록하고 상태를 실시간 업데이트할 수 있도록 담당자 ID 권한 필드가 포함됩니다.

• id: BIGSERIAL / UUID (분산 환경 식별자)

• region_shard_id: 지리적 거리를 기준으로 분산 샤딩(Sharding)을 하기 위한 파티션 키 (예: 주(State) 단위)

• agent_id: 이 매물을 등록하고 관리하는 중개인의 고유 ID (accounts.id 참조). 매물 상태 및 가격 업데이트 시 권한 검증의 기준이 됩니다.

• status: 현재 매물 상태 (FOR_SALE, FOR_RENT, PENDING, SOLD)

• price: 현재 리스팅 가격 (또는 최종 거래 가격)

• specifications: JSONB 형태의 페이로드 (침실 수, 욕실 수, 평방피트 면적, 건축 연도 등 유연한 스펙 확장 및 다중 필터링용)

• coordinate: GEOMETRY(Point, 4326) 위도와 경도를 하나로 묶은 시공간 데이터 (GIST 인덱스 적용)

• address_search_vector: 주소 텍스트 고속 검색을 위한 Full-text Search 벡터 데이터

• version: 데이터 정합성 유지를 위한 낙관적 락(Optimistic Locking) 버전 번호

property_media - 매물 미디어 데이터

요구사항인 “고화질 사진 리스트”를 충족하기 위한 테이블입니다. Out of Scope인 3D 가상 투어 실시간 스트리밍 인프라는 철저히 배제하고, 오직 이미지와 일반 소개 영상의 정적 스토리지 경로만 관리합니다. properties와 1:N 관계를 가집니다.

• id: BIGSERIAL

• property_id: 해당 매물의 외래키(FK)

• media_type: IMAGE, VIDEO (3D 가상 투어 스트리밍 데이터 유형은 원천 제외)

• url: S3 및 CDN(CloudFront)을 가리키는 원본 및 해상도별 썸네일 경로

• sort_order: 사용자가 상세 페이지를 열었을 때 보여줄 사진 우선순위 번호

valuation_histories - Zestimate & 가격 시계열 테이블

질로우의 비즈니스 가치인 ‘Zestimate(AI 예측 가치)’와 ‘과거 리스팅 가격 변동 추이’를 기록하는 시계열(Time-series) 데이터입니다. 수정(Update)이 발생하지 않고 시간 순서대로 삽입(Append-only)만 일어납니다.

• id: BIGSERIAL

• property_id: 해당 매물의 외래키(FK)

• event_type: LISTED (최초 등록), PRICE_DROPPED (가격 인하), ZESTIMATE_UPDATED (AI 가치 예측치 갱신), SOLD (매매 완료)

• amount: 해당 이벤트 시점의 금액/가치

• timestamp: 기록된 날짜 및 시간

saved_searches / alerts - 사용자 관심 지역 및 알림 조건

사용자가 지도상에서 특정 영역을 지정하고 필터를 걸어 “이 조건의 매물이 새로 나오면 알림을 줘”라고 저장한 데이터입니다. 대규모 푸시 및 이메일 알림 시스템의 트리거 기준이 됩니다.

• id: UUID

• user_id: 알림을 받을 사용자의 ID (accounts.id 참조)

• bounding_box: GEOMETRY(Polygon, 4326) 사용자가 지정한 지도상의 사각형/다각형 영역 정보

• filter_conditions: JSONB 형태 (예: “방 3개 이상, 50만 달러 이하”)

• last_notified_at: 마지막으로 푸시/이메일 알림이 발송된 시점

참고: 요구사항에 포함된 “주변 학군 및 편의시설 데이터”는 코어 DB의 비대화를 막기 위해 공공 데이터 외부 API(3rd Party)를 통해 지도 화면에서 실시간으로 매시업(Mash-up)하여 서빙하므로, 본 엔티티 설계에서는 영속성 테이블을 별도로 두지 않고 배제합니다.

API Signatures

Zillow 같은 부동산 플랫폼은 단순히 “집 목록을 보여주는 웹사이트”가 아닙니다. 겉으로는 사용자가 지도를 움직이면 매물이 뜨고, 가격이 바뀌면 알림이 오고, 관심 매물을 저장하는 서비스처럼 보입니다. 하지만 시스템 내부로 들어가면 완전히 다른 문제가 나옵니다. Zillow의 본질은 대규모 시공간 데이터 플랫폼입니다.

여기서 시공간 데이터란 단순히 위도와 경도만 의미하지 않습니다. 매물은 공간 위에 존재합니다. 동시에 시간에 따라 가격이 바뀌고, 판매 상태가 바뀌고, 사용자의 관심 조건도 계속 변합니다. 즉, Zillow는 아래 세 가지를 동시에 해결해야 합니다.

Read more

이번에는 글로벌 1위 디자인 협업 툴인 Figma(피그마) 같은 대규모 실시간 그래픽 편집 플랫폼을 설계하는 문제를 다룹니다.

피그마는 디자이너, 기획자, 개발자가 하나의 무한한 캔버스에 모여 UI/UX를 그리고, 수십 개의 마우스 커서가 동시에 움직이며, 픽셀 단위의 벡터데이터를 실시간으로 동기화하는 서비스입니다.

앞서 다루었던 슬랙(텍스트 스트리밍)이나 노션(블록 트리)과는 차원이 다른 엔지니어링 한계에 부딪히게 됩니다. 사용자가 마우스를 드래그하여 사각형의 크기를 조절하는 순간, 브라우저는 1초에 60번(60FPS) 화면을 다시 그려야 하며, 동시에 이 X, Y 좌표의 변화를 수백 명의 다른 접속자들에게 지연 없이 동기화해야 합니다.

AI가 단순한 백엔드 코드를 짜주는 시대에, 시니어 엔지니어의 시스템 디자인 역량은 다음과 같은 질문에서 빛을 발합니다.

“수만 개의 레이어(Layer)와 벡터 이미지를 가진 무거운 디자인 파일을 브라우저 메모리 한계 내에서 어떻게 끊김 없이 렌더링할까?”

“노션처럼 단순한 CRDT만으로는 해결할 수 없는, 도형의 Z-Index(앞뒤 순서)와 그룹화 충돌을 중앙 서버에서 어떻게 조율할까?”

“수십 명의 마우스 커서가 1초에 60번씩 움직이는 압도적인 트래픽(Cursor Movement)을 서버 DB를 터뜨리지 않고 어떻게 중계할까?”

Figma 같은 디자인 툴은 프론트엔드의 극한(WASM/WebGL)과 백엔드의 극한(Stateful Multiplayer Server)이 만나는 시스템 설계의 끝판왕입니다. 이 글을 끝까지 읽으면 다음 질문에 답할 수 있게 됩니다.

1. 웹 브라우저의 한계를 넘기 위해 DOM 대신 WebGL과 WebAssembly(WASM)를 어떻게 설계에 녹여낼 수 있을까?

2. 디자인 파일의 본질인 ‘씬 그래프(Scene Graph)’를 데이터베이스에 어떻게 모델링하고 저장할까?

3. 50명이 동시에 요소를 드래그할 때, 피그마의 중앙 집중형 멀티플레이어 서버는 충돌을 어떻게 해결할까?

4. 초당 수백 번 쏟아지는 ‘실시간 마우스 커서’ 데이터를 메인 DB 트래픽과 완벽히 격리하는 방법은?

5. 기가바이트(GB) 단위로 커진 디자인 파일을 1초 만에 열기 위한 스냅샷(Snapshot) 청크 전략은?

Functional Requirements - 기능적 요구사항

• 무한 캔버스와 벡터 렌더링

  • 사용자는 브라우저에서 벡터 도형, 이미지, 텍스트를 그리고 줌/팬(Zoom & Pan)을 할 수 있어야 합니다.

• 씬 그래프 (Scene Graph) 계층

  • 프레임(Frame), 그룹(Group), 레이어(Layer) 등으로 요소들이 부모-자식 트리 관계를 가져야 합니다.

• 실시간 멀티플레이어 (Real-time Multiplayer)

  • 여러 사용자가 동시에 동일한 파일을 편집할 수 있으며, 다른 사람의 마우스 커서 움직임이 실시간으로 보여야 합니다.

• 히스토리 및 버전 관리

  • 과거의 특정 시점으로 파일을 되돌리거나(Undo/Redo), 버전 스냅샷을 저장할 수 있어야 합니다.

Non-Functional Requirements - 비기능적 요구사항

• Zero-Latency Rendering (60FPS)

  • 마우스를 드래그하는 즉시 로컬 화면에 지연 없이(16ms 이내) 렌더링되어야 합니다. 네이티브 앱 수준의 퍼포먼스가 필수입니다.

• Low Latency Sync (< 50ms)

  • 내 마우스 움직임과 편집 내용이 다른 사용자에게 50밀리초 이내에 도달하여 ‘같은 공간에 있는 듯한’ 경험을 주어야 합니다.

• High Consistency (강력한 일관성)

  • 디자인 툴의 특성상 1픽셀이라도 어긋나면 안 됩니다. 모든 사용자의 브라우저는 정확히 100% 동일한 좌표와 레이어 순서를 렌더링해야 합니다.

• High Durability

  • 디자인 파일은 회사의 핵심 자산이므로 절대 유실되어서는 안 됩니다.

Scope 정리

• In Scope

  • 프론트엔드 렌더링 아키텍처(WASM/WebGL)

  • 씬 그래프 데이터 모델링

  • 실시간 동기화(Multiplayer Server)

  • 마우스 커서 브로드캐스팅

  • 파일 저장 및 로딩 최적화

• Out of Scope

  • 피그마 커뮤니티 플랫폼

  • 플러그인 생태계 실행 샌드박스

  • 결제 시스템.

가정하는 규모

• DAU: 1,000만 명

• Concurrent Users (Peak): 200만 명

• Active Multiplayer Sessions: 동시 편집 중인 파일 수십만 개

• Peak QPS (WebSocket):

  • 문서 편집 이벤트: 수십만 QPS

  • 마우스 커서 이벤트: 수백만 ~ 수천만 QPS (가장 무거운 트래픽)

Core Entities

피그마의 데이터 모델은 일반적인 블로그나 슬랙처럼 텍스트 덩어리를 데이터베이스에 통째로 저장하는 방식이 아닙니다. 피그마 파일의 본질은 화면에 그려지는 수만 개의 그래픽 요소들이 부모-자식 관계로 복잡하게 얽혀 있는 거대한 트리 구조, 즉 씬 그래프(Scene Graph) 라고 할 수 있습니다.

files (파일 메타데이터)

• 디자인 파일의 껍데기 역할을 합니다. 파일 이름, 워크스페이스 ID, 썸네일 URL 등의 기본 정보를 담고 있습니다.

• 대규모 분산 환경에서 특정 서버로 트래픽을 몰아주거나 데이터베이스를 쪼갤 때(Sharding), 이 file_id가 가장 중요한 파티션 키(Partition Key)로 활용됩니다.

nodes

• 피그마 캔버스 위에 존재하는 모든 것은 ‘노드(Node)’입니다. 도화지 역할을 하는 프레임(Frame)도 노드이고, 그 안의 사각형(Rectangle), 텍스트(Text), 다각형(Polygon)도 모두 하나의 노드 레코드로 저장됩니다.

• id: 각 요소의 분산 고유 식별자(UUID).

• file_id: 이 노드가 속한 파일의 ID. 파일을 열 때 해당 파일의 모든 노드를 한 번에 긁어오기 위한 핵심 인덱스입니다.

• parent_id: 이 요소를 감싸고 있는 부모 노드(예: 특정 프레임이나 그룹)의 ID입니다. 이 필드를 통해 씬 그래프라는 깊은 트리(Tree) 구조가 조립됩니다.

• type: FRAME, GROUP, RECTANGLE, TEXT 등 요소의 형태.

• properties: X, Y 좌표, 너비(Width), 높이(Height), 채우기 색상(Fill), 선 굵기(Stroke) 등 픽셀 렌더링에 필요한 무거운 메타데이터가 담긴 페이로드(주로 JSONB 형식).

• z_index: 같은 부모 내에서 어떤 요소가 더 화면 앞쪽에 렌더링되어야 하는지를 결정하는 깊이 순서입니다. 동시 편집 상황에서 가장 충돌이 잦고 서버가 깐깐하게 조율해야 하는 핵심 속성입니다.

snapshots (스냅샷 저장소)

• 기가바이트(GB) 단위로 무거워진 디자인 파일을 열 때, 과거에 마우스로 움직였던 수백만 번의 변경 기록(Delta Log)을 데이터베이스에서 처음부터 끝까지 다시 조립(Replay)한다면 로딩에만 수 분이 걸릴 것입니다.

• 이를 방지하기 위해, 시스템은 주기적으로 특정 시점의 전체 씬 그래프 상태를 하나로 압축합니다. 그리고 이를 AWS S3와 같은 오브젝트 스토리지(Blob Storage)에 통째로 박제(Check-pointing)해 둡니다. 클라이언트는 이 무거운 스냅샷 파일의 URL만 받아와 초고속으로 초기 화면을 렌더링합니다.

API Signatures

피그마의 진가는 단순한 데이터의 저장이 아니라, 프론트엔드의 렌더링 최적화와 서버의 멀티플레이어 아키텍처에 있습니다. 프론트엔드 시스템 디자인 강의는 현재 제작중에 있습니다.

텍스트 기반의 협업 툴(슬랙, 노션)이 대부분 REST API에 의존하는 반면, 피그마는 초기 로딩을 제외한 모든 편집 과정이 WebSocket을 통한 ‘실시간 스트리밍(Streaming)’과 ‘상태 동기화(State Sync)’로 이루어집니다.

단순한 JSON 페이로드를 넘어서, 이 데이터를 어떻게 처리해야 60FPS의 렌더링과 충돌 없는 동기화를 달성할 수 있는지 API 파이프라인으로 나누어 알아보겠습니다.

1. File Load APIs (파일 초기 로딩 - 스냅샷 기반 Read Path)

수만 개의 레이어와 기가바이트(GB) 단위의 고해상도 이미지가 포함된 디자인 파일을 열 때, 일반적인 웹 서비스처럼 DB에서 데이터를 긁어와 화면을 그리려 한다면 사용자는 5분 넘게 하얀 화면(White Screen of Death)만 쳐다봐야 할 것입니다.

피그마의 초기 로딩은 API 서버가 무거운 데이터를 직접 다루지 않고, 오브젝트 스토리지(S3)로 부하를 완벽히 오프로딩(Offloading)하는 전략을 취합니다.

Read more

이번에는 실시간 협업 기반의 글로벌 생산성 툴인 Notion(노션) 같은 대규모 문서 및 지식 관리 플랫폼을 설계하는 문제를 다룹니다.

노션은 사용자가 페이지를 만들고, 텍스트, 이미지, 표, 데이터베이스 등 다양한 요소를 자유롭게 배치하며, 동료들과 실시간으로 동시에 문서를 편집할 수 있는 서비스입니다.

겉으로 보면 “웹에서 글을 쓰는 에디터” 같지만, 시스템 디자인 관점에서 노션은 단순한 텍스트 에디터가 아닙니다. 거대한 분산 트리(Tree) 데이터베이스이자, 상태 동기화(State Synchronization) 엔진이라고 할 수 있습니다.

사용자가 노션에서 타이핑을 하는 순간, 시스템은 단순한 긴 텍스트를 저장하는 것이 아닙니다.

“이 문장은 block_id: 123이고, 부모는 page_id: 456이며, 현재 버전은 v10인데, 마침 미국에 있는 동료가 같은 텍스트 블록을 동시에 수정했네? 둘의 충돌을 어떻게 병합(Merge)하지?”

AI가 코드를 짜주는 시대에, 시니어 엔지니어의 가치는 단순히 REST API를 만드는 데 있지 않습니다.

“왜 문서 전체를 통째로 저장하지 않고 수십 개의 블록(Block) 단위로 쪼개어 저장해야 하는지”

“다수의 사용자가 동일한 문장을 동시에 수정할 때, 어떻게 데이터 유실 없이 화면을 실시간으로 동기화(CRDT/OT)할 수 있는지”

“부모 페이지의 권한이 바뀌었을 때 수만 개의 하위 블록들의 읽기 권한을 어떻게 1초 만에 제어할지”

Notion 같은 협업 문서 시스템은 이러한 “상태 충돌(Conflict) 해결”과 “계층형 데이터(Tree) 처리” 역량을 훈련하기 가장 완벽한 문제이기 때문에 이 컨텐츠를 제작했습니다. 이 글을 끝까지 읽으면 다음 질문에 답할 수 있게 됩니다.

1. 노션의 핵심인 ‘블록(Block) 아키텍처’를 데이터베이스로 어떻게 모델링할까?

2. 5명이 동시에 같은 단락을 수정할 때 발생하는 충돌을 CRDT를 통해 어떻게 우아하게 해결할까?

3. 수백만 개의 블록을 트리 구조로 렌더링할 때 발생하는 DB 쿼리 병목(N+1 문제)을 어떻게 피할까?

4. 오프라인 상태에서 비행기 안에서 작성한 문서가, 온라인이 되었을 때 어떻게 완벽히 동기화될까?

5. 노션의 무한히 깊어지는 페이지 트리에서 ‘검색 권한 필터링’을 어떻게 고속으로 처리할까?

Functional Requirements - 기능적 요구사항 (Notion)

• 문서는 통짜 텍스트가 아닌 텍스트, 이미지, 체크리스트 등의 ‘블록(Block)’ 단위로 생성, 수정, 삭제(CRUD) 되어야 합니다.

• 페이지 안에 페이지를 무한히 중첩하여 생성할 수 있어야 합니다.

• 여러 사용자가 동일한 페이지, 심지어 동일한 블록을 동시에 수정해도 지연 없이 실시간으로 반영되어야 합니다.

• 인터넷이 끊긴 상태에서도 문서를 읽고 편집할 수 있으며, 네트워크가 연결되면 자동으로 서버와 동기화되어야 합니다.

• 사용자는 권한이 있는 워크스페이스 내의 모든 페이지와 블록 내용을 빠르게 검색할 수 있어야 합니다.

Non-Functional Requirements - 비기능적 요구사항

• High Availability & Durability

  • 지식 베이스(Wiki)이므로 데이터 유실은 절대 허용되지 않습니다.

• Eventual Consistency (실시간 동기화 영역)

  • 여러 사용자가 동시 편집 시, 찰나의 순간에는 화면이 다를 수 있으나 궁극적으로는 모든 사용자가 완벽히 동일한 문서 상태를 보게 되어야 합니다(Strong Eventual Consistency).

• Low Latency (Read/Write)

  • 사용자가 타이핑하는 순간 로컬 반응은 0ms에 가까워야 하며, 동료에게 전파되는 시간은 수백 밀리초(ms) 이내여야 합니다.

Scope 정리

• In Scope

  • 블록 데이터 모델링, 실시간 동기화(CRDT), 트리 구조 렌더링 및 페이지 조회, 오프라인 로컬 캐싱, 검색 시스템.

• Out of Scope

  • 노션 데이터베이스(표, 칸반보드)의 롤업/포뮬라 연산 엔진 상세, 타사 툴 연동(Integration), 결제 시스템.

가정하는 규모

• DAU: 3,000만 명

• Concurrent Users (Peak): 500만 명

• Blocks Written per day: 50억 건 (사용자 타이핑과 블록 생성이 잦음)

• Peak QPS: * Block Write/Sync: 수십만 QPS (WebSocket을 통한 상태 동기화)

  • Page Read: 수만 QPS

• Latency: 로컬 렌더링 즉시, 네트워크 동기화 < 500ms

Core Entities

Notion의 데이터 모델은 일반적인 블로그나 게시판과는 완전히 다릅니다. HTML 문서 통째로 DB에 넣는 방식(Anti-pattern)이 아니라, 모든 것을 잘게 쪼갠 그래프/트리(Graph/Tree) 데이터베이스에 가깝다고 할 수 있습니다.

workspaces

• 워크스페이스(회사/조직) 기본 정보. 노션 시스템 샤딩(Sharding)의 가장 핵심적인 기준(Partition Key)이 됩니다.

users

• 사용자 정보.

blocks (가장 핵심적이고 거대한 테이블)

• 노션의 심장입니다. 페이지도 블록이고, 텍스트 단락도 블록이며, 이미지도 블록입니다.

• id: UUID (분산 환경에서 클라이언트가 직접 생성)

• workspace_id: 샤딩을 위한 파티션 키

• parent_id: 이 블록을 감싸고 있는 부모 블록(또는 페이지)의 ID. 이를 통해 트리 구조를 만듭니다.

• block_type: page, text, h1, image, toggle 등

• properties: JSONB 형태의 페이로드 (텍스트 내용, 폰트 색상, 이미지 URL 등)

• version: 낙관적 락(Optimistic Locking) 및 동기화를 위한 버전 번호

• created_at, updated_at, created_by, last_edited_by

permissions (권한 테이블)

• 특정 블록(주로 페이지 레벨)에 대한 사용자/그룹의 읽기/쓰기 권한을 정의합니다.

API Signatures & Deep Dives

단순한 REST API가 아니라, 실시간 상태 동기화(State Sync)와 트리 탐색이 결합된 형태입니다.

1. Page Load API, 페이지 읽기 - 계층형 데이터 로드

사용자가 특정 페이지를 클릭했을 때, 서버는 해당 페이지와 그 안의 내용물(자식 블록들)을 어떻게 가져올까요?

POST /v1/sync/load_page
{
  "page_id": "block_12345",
  "limit": 50
}

안티 패턴의 함정, WITH RECURSIVE가 DB를 죽이는 이유

주니어 엔지니어들이 노션 클론 코딩을 할 때 가장 많이 하는 실수는, RDBMS의 트리 탐색 기능인 WITH RECURSIVE (재귀 CTE)를 맹신하는 것입니다.

상황 가정

어느 회사에 “2026년 프로젝트 총람”이라는 최상위 페이지가 있습니다. 그 안에는 부서별 하위 페이지가 20개 있고, 각 하위 페이지 안에는 수백 개의 토글(Toggle)과 표(Table), 텍스트 블록들이 중첩되어 있습니다. 총 블록 수는 50,000개입니다.

재귀 쿼리를 쓴다면?

Read more