에어비앤비의 멀티 프로덕트 데이터 아키텍처 분리 vs 통합, 실전 프레임워크에서 배우는 7가지 교훈

들어가며: 멀티 프로덕트 시대의 데이터 고민

2025년 5월, 에어비앤비는 Summer Release를 통해 앱을 전면 개편하고 Experiences를 재런칭했으며, 새로운 Services 제품군을 선보였습니다. 전통적으로 '홈(Homes)'에 집중하던 비즈니스가 순식간에 3개의 제품 축으로 확장된 것이죠.

이 변화는 데이터 조직에 근본적인 질문을 던졌습니다. "어떻게 하면 새로운 제품 라인을 지원하면서도 기존 분석 서비스에 혼란을 주지 않고 오프라인 데이터 아키텍처를 진화시킬 수 있을까?"

단편적인 접근은 데이터 사일로, 일관성 없는 분석, 미래 혁신을 저해하는 기술 부채로 이어질 위험이 컸습니다. 이 글에서는 에어비앤비 데이터 엔지니어링 팀이 선택한 프레임워크, 핵심 결정, 그리고 실전 교훈을 상세히 풀어봅니다.

참고: 이 글은 앱을 직접 서빙하는 온라인 데이터 시스템이 아닌, 오프라인 데이터 웨어하우스(분석 지향 데이터 인프라) 에 초점을 맞춥니다. 두 도메인은 요구사항과 설계 철학이 근본적으로 다르기 때문에 별도로 다루어야 합니다.

핵심 딜레마: 분리형 vs 통합형 데이터 모델

가장 첫 번째이자 가장 중요한 결정은 새롭게 확장된 3개 제품(Homes, Experiences, Services)의 오프라인 데이터를 어떻게 구조화할지였습니다.

두 가지 접근법 비교

에어비앤비 팀은 "어느 한 접근법이 절대적으로 우월하지 않다" 는 결론에 도달했습니다. 최적의 선택은 비즈니스 도메인의 성격에 크게 의존했습니다. 예를 들어 게스트 데이터에 완벽한 모델이 결제 데이터에는 부적합할 수 있었죠.

세 가지 기초 원칙

팀은 일관성과 유연성 사이의 균형을 잡기 위해 중앙 집중식 원칙 + 분산형 모델링 가이드라인 프레임워크를 수립했습니다.

원칙 1: 하이브리드 모델 금지 한 도메인의 데이터 모델은 완전히 분리형이거나 완전히 통합형이어야 합니다. 혼합 모델은 미래 확장성을 해치고, 일부 제품만 통합 테이블을 사용하는 일관성 없는 상황을 방지합니다.

원칙 2: 식별자 명명 규칙 통일 모델링 선택에 따라 기본 식별자 구조를 엄격히 구분했습니다.

• 분리형 모델: 제품별 ID 사용 (예: id_experience, id_service)
• 통합형 모델: 일반 제품 설명자 ID (예: id_product_listing) + 제품 타입 컬럼 (dim_product_type)

원칙 3: 네임스페이스 명확화

• 제품별 핵심 테이블 → 전용 제품 네임스페이스
• 통합 크로스커팅 테이블 → 글로벌 네임스페이스
• 팀별 중간 테이블 → 팀 전용 네임스페이스

# 예시: 분리형 모델의 네임스페이스 구조 (주석: 한국어)
# 데이터 카탈로그 예시
namespace: "product_homes"
  - table: "listings"          # Homes 전용 리스팅
  - table: "availability"      # 날짜 기반 가용성

namespace: "product_services"
  - table: "offerings"         # Services 전용 오퍼링 (다대일 관계)
  - table: "availability"      # 영업시간 기반 가용성

namespace: "global"
  - table: "messaging_threads" # 모든 제품 아우르는 메시징
  - table: "payments"          # 제품 무관 결제

이 세 가지 원칙은 모든 팀이 따라야 할 명확한 경계를 설정하여 회사 전체의 일관된 기반을 보장했습니다.

모델링 가이드라인: 7가지 의사결정 기준

원칙만으로는 충분하지 않습니다. 각 팀이 자신의 도메인에 맞는 모델을 선택할 수 있도록 7가지 공통 고려사항을 가이드라인으로 제공했습니다.

1. 공통 vs 고유 속성: 제품 라인 간 공유 속성이 많은가? 아니면 각 제품에 고유한 속성이 많은가?
2. 미래 확장성: 4번째, 5번째 제품 라인이 추가되어도 이 모델이 확장 가능한가?
3. 업스트림 정합성: 온라인 프로덕션 데이터베이스가 데이터를 어떻게 구조화하는가?
4. 다운스트림 소비자: 분석가와 데이터 과학자가 이 오프라인 데이터를 어떻게 조회할 것인가?
5. 코드 유지보수성: 어떤 경로가 더 깔끔하고 모듈화된 코드를 만드는가?
6. 데이터 볼륨 & 성능: 새로 추가되는 데이터의 규모를 효율적으로 처리할 수 있는가?
7. 비즈니스 연속성: 기존 핵심 지표의 정확한 리포팅을 유지하면서 새로운 데이터를 통합할 수 있는가?

실전 적용 패턴

분리형 모델이 선택된 도메인 (제품별 고유 로직)

• Listings: Services 제품군의 '오퍼링(Offering)' 개념은 기존 Homes/Experiences와 전혀 다른 다대일 관계를 가짐
• Availability: Services의 '영업시간(business hours)' 개념은 기존 날짜/시간 기반 가용성과 완전히 다른 모델 필요
• Location: Services의 '서비스 지역(radius 기반)'은 고정 위치 기반인 Homes/Experiences와 상이
• Guests: 제품별 사용자 여정이 완전히 달라 별도 모델링 필요

통합형 모델이 선택된 도메인 (크로스커팅 개념)

• Messaging: 하나의 메시지 스레드가 여러 제품에 걸쳐 있을 수 있어 분리 불가
• Payments: 거래, 환불, 지급은 제품과 무관하게 처리되므로 통합 모델 유지
• Customer Support: 고객 문의가 여러 제품에 걸쳐 있으므로 통합 뷰 필수

인사이트: 가장 결정적인 질문은 "제품 라인이 대부분 공통 속성을 공유하는가, 아니면 상당한 고유 속성을 가지는가?" 였습니다. 이 질문 하나로 대부분의 결정이 갈렸습니다.

표준화의 현실적 도전과 교훈

도전 1: 실행 가능한 인사이트 기반 만들기

오프라인 데이터 웨어하우스는 진공 상태에 존재하지 않습니다. 업스트림 온라인 데이터 모델은 트랜잭션 속도와 안정성에 최적화되어 있어, 분석에 이상적인 구조와 거리가 먼 경우가 많습니다.

해결책: 오프라인 데이터 웨어하우스가 중요한 변환 계층(translation layer) 역할을 수행하도록 설계했습니다. 데이터 엔지니어와 분석 엔지니어는 원시 프로덕션 데이터를 가져와 표준화된 신뢰할 수 있는 진실 공급원(Single Source of Truth)으로 변환합니다.

-- 예시: 변환 계층에서의 ID 표준화 (주석: 한국어)
-- 원시 데이터: 다양한 ID 포맷
-- 변환 후: 통일된 식별자 체계

CREATE VIEW analytics.unified_listings AS
SELECT 
    CASE 
        WHEN product_type = 'Homes' THEN 'HM_' || id
        WHEN product_type = 'Experiences' THEN 'EX_' || id
        WHEN product_type = 'Services' THEN 'SV_' || id
    END AS id_product_listing,
    product_type,
    name,
    location_json  -- 통합 JSON 필드로 각 제품의 위치 정보 수용
FROM raw_production.listings;

도전 2: 데이터 부채 관리

새로운 표준은 기존 레거시 테이블과 대시보드가 기준을 충족하지 못한다는 사실을 드러냈습니다. 특히 이전 버전의 Experiences 테이블은 수백 개의 다운스트림 소비자를 가지고 있어 마이그레이션이 매우 까다로운 작업이었습니다.

접근법:

• 광범위한 커뮤니케이션
• 이중 파이프라인 운영을 통한 검증
• 비즈니스 중단을 피하기 위한 신중한 폐기 사이클

한국 개발 생태계에서의 적용 맥락

국내 SI/스타트업 환경에서도 유사한 고민이 발생합니다. 특히 여러 서비스를 하나의 플랫폼에서 운영하는 경우(예: 커머스 + 배달 + O2O) 데이터 모델 선택은 아키텍처의 향방을 결정합니다.

• 초기 스타트업: 통합형 모델로 시작하는 것이 일반적 (빠른 프로토타이핑)
• 성장 단계: 제품별 고유성이 커지면 분리형 모델로 전환 검토
• 주의사항: 하이브리드 모델은 단기적으로 편리해 보이지만, 장기적으로 데이터 사일로와 유지보수 지옥을 초래할 수 있습니다.

이 기술의 한계 또는 주의사항

에어비앤비의 프레임워크는 대규모 조직에 최적화되어 있습니다. 소규모 팀(5~10명)에서는 오히려 오버엔지니어링이 될 수 있습니다. 또한 이 프레임워크는 오프라인 데이터 웨어하우스에 국한되며, 실시간 데이터 파이프라인이나 이벤트 스트리밍에는 추가적인 고려가 필요합니다.

다음 단계 학습 방향

1. 데이터 메싱(Data Mesh) 아키텍처: 분산형 데이터 소유권과 중앙 집중식 거버넌스의 균형
2. dbt(Data Build Tool) 를 활용한 데이터 모델링 자동화
3. 데이터 카탈로그 도입으로 네임스페이스 관리 자동화

결론

에어비앤비의 사례는 "하나의 크기가 모든 것을 만족시키지 않는다" 는 데이터 모델링의 핵심 교훈을 보여줍니다. 중앙의 일관성과 도메인별 유연성 사이의 균형을 잡는 시스템을 만들고, 과거를 신중하게 해결하면서 미래를 준비하는 것이 중요합니다.

이 프레임워크는 확장성, 명확성, 그리고 신속하고 정확한 인사이트 전달 능력에서 이미 가시적인 성과를 내고 있습니다.

함께 보면 좋은 글

• React 동적 폼, 컴포넌트 vs 스키마 실무에서 고민해야 할 선택지
• AWS Verified Permissions로 구현하는 실전 세분화 인가 Convera 사례에서 배우는 것

근거자료: Airbnb Engineering Blog - Scaling beyond one: How Airbnb evolved its data architecture for a multi-product world