대규모 서비스 기술 스택 해부

왜 남의 스택을 보나

큰 회사의 기술 스택은 그대로 따라 할 목록이 아니다. 여러 회사의 스택을 겹쳐 보면 같은 문제에 비슷한 설계 원칙이 반복되는데, 그 원칙이 쓸모 있다. 구체 제품은 자주 바뀌므로 제품명보다 「어느 층에 어떤 성질의 도구를 두었나」를 본다.

계층별로 겹쳐 보기

폴리글랏 저장: 데이터마다 맞는 DB

모든 데이터를 한 DB에 넣지 않는다. 데이터의 일관성 요구, 접근 패턴, 크기에 따라 DB를 고른다.

관계형 DB 앞에 캐시를 두고, 새 기능에는 가용성이 높은 와이드 컬럼 DB를 쓰는 조합(Reddit)이 전형적이다.

캐시의 네 가지 쓰임

분산 키-값 캐시는 조회 가속 외에도 쓰인다. 영상 스트리밍 사례(Netflix의 EVCache)는 하나의 캐시 플랫폼을 네 용도로 쓴다.

미리 계산해 캐시에 넣어 두기(precompute) 는 요청 시점의 계산을 없애 지연을 줄인다. 캐시 전략 일반은 캐싱 전략에서 다룬다.

비싼 작업은 미루고, 캐시는 변경 로그로 맞춘다

소셜 커뮤니티 사례(Reddit)에서 볼 수 있는 패턴이다.

flowchart LR
  w["투표·글 제출 같은 비싼 쓰기"] --> q["작업 큐(RabbitMQ)"] --> wk["워커가 비동기 처리"]
  s["콘텐츠 안전 검사"] --> k["Kafka로 실시간 전달"] --> re["규칙 엔진이 검사"]
  d["DB 변경"] --> cdc["CDC(Debezium)로 변경 로그 추출"] --> rep["복제본·캐시 갱신"]

• 사용자 응답 경로에서 비싼 작업을 빼면 요청이 빨라지고 부하 폭증을 큐가 흡수한다.
• 애플리케이션이 캐시와 DB에 이중 쓰기를 하면 둘이 어긋나기 쉽다. DB의 변경 로그를 원천으로 삼아 캐시·복제본을 갱신하면 일관성을 맞추기 쉽다.

이벤트 플랫폼 표준화

이벤트 기반 아키텍처를 여러 팀이 쓰기 시작하면 이벤트 형식과 오류 처리가 제각각이 된다. 패스트푸드 주문 플랫폼 사례(McDonald's)는 이벤트를 다음 요소로 표준화했다.

확장은 리전별 구성으로 전역 가용성을 확보하고, 리전 안에서는 도메인별로 이벤트를 나눠 도메인마다 관리형 Kafka 클러스터가 처리하며, CPU 같은 지표로 자동 확장한다. Kafka 자체는 메시지 큐와 Kafka에서 다룬다.

CI/CD: 운영 환경에서 검증한다

대규모 서비스의 배포 파이프라인은 비슷한 단계로 이뤄진다.

배포 전략은 배포 전략, 파이프라인 일반은 CI/CD에서 다룬다.

자동 버그 수정

대규모 코드베이스에서는 크래시 수정까지 자동화한다. Meta의 SapFix가 대표 사례다.

flowchart TB
  a["개발자가 변경(diff) 제출"] --> b["자동 생성된 테스트로 변경을 실행 → 크래시 발견"]
  b --> c["수정 후보 생성: 템플릿 적용 / 코드 변이(mutation) /<br/>전체 되돌리기 / 부분 되돌리기"]
  c --> d["후보마다 패치된 빌드로 테스트 → 통과한 후보 선택"]
  d --> e["크래시를 일으킨 변경의 작성자에게 리뷰 요청"]
  e --> f["사람이 수락 또는 폐기"]

이 흐름은 자동화가 고치고, 맥락을 가장 잘 아는 사람이 승인하는 분업이다. 지금은 LLM 기반 코딩 에이전트가 같은 역할을 넓게 맡지만, 「테스트로 검증한 후보만 사람에게 올린다」는 원칙은 같다.

소프트웨어로 안 되면 전용 하드웨어

영상 플랫폼은 업로드된 원본을 기기별 해상도·압축률로 트랜스코딩해야 한다. 업로드 양이 늘면 범용 CPU의 소프트웨어 인코딩은 느리고 비싸다. YouTube는 영상 인코딩·디코딩만 하는 전용 가속기(VCU, Video transCoding Unit)를 만들어 클러스터 단위로 배치했다. GPU가 그래픽을, TPU가 머신 러닝을 맡는 것과 같은 발상이다. 특정 연산이 전체 비용을 지배하면 전용 하드웨어가 답이 된다.

성장기 사례에서 반복되는 교훈

웹 서비스가 폭발적으로 크던 2008~2015년의 사례들은 제품은 낡았어도 판단의 근거가 지금도 통한다.

구글은 이런 원칙을 플랫폼으로 만들었다. 제품팀은 GFS·MapReduce·Bigtable 위에서 새 서비스를 띄우고, 저장 비용을 데이터 성격에 따라 다르게 매긴다(잃으면 안 되는 로그에는 더 쓰고, 다른 데이터에는 덜 쓴다). 그 인프라의 설계는 고전 분산 시스템 설계에 있다.

사례를 더 찾을 곳

설계 사례는 각 회사의 엔지니어링 블로그가 1차 자료다. Netflix TechBlog, Uber Engineering, Cloudflare Blog, Engineering at Meta, LinkedIn Engineering, Discord Blog, AWS Architecture Blog, Slack Engineering, Stripe Blog가 자주 인용된다.

정리

• 남의 스택에서는 제품명이 아니라 계층별로 반복되는 설계 원칙을 가져온다.
• 데이터 성격마다 DB를 따로 고르고(폴리글랏 저장), 캐시는 미리 계산한 결과를 담는 기본 저장소로도 쓴다.
• 비싼 쓰기는 큐로 미루고, 캐시·복제본은 CDC 변경 로그로 맞춘다.
• 이벤트는 레지스트리·공용 SDK·게이트웨이로 표준화하고 도메인별로 나눠 확장한다.
• 배포는 카나리와 지표 판정으로 운영 환경에서 검증하고, 반복되는 수정은 자동화하되 승인은 사람이 한다.

관련 노트: 아키텍처와 API 계층의 진화, 마이크로서비스 아키텍처, 와이드 컬럼 DB, 캐싱 전략, 메시지 큐와 Kafka, CI/CD, 배포 전략