sql

사업자 데이터 리터러시 높이기: BC Monthly Report 발행기 (새 탭에서 열림)

토스는 각 사업부별로 흩어져 있던 사업자(Business Customer, BC) 데이터를 통합하여 '단일 진실의 근원(SSOT)'인 데이터 마트를 구축하고, 이를 기반으로 전사적인 월간 리포트를 발행하여 비즈니스 의사결정 구조를 혁신했습니다. 이 과정에서 파편화된 지표 정의를 하나로 모으고 현업의 니즈를 반영한 결과, 전사 구성원들이 동일한 기준으로 사업 현황을 파악하고 데이터에 기반해 실질적인 액션 아이템을 도출할 수 있는 환경이 마련되었습니다. 이러한 여정은 단순한 데이터 정리를 넘어 토스 전반의 데이터 리터러시를 높이고 비즈니스 성장을 가속화하는 기폭제가 되었습니다. **단일 진실의 근원(SSOT)을 위한 데이터 마트 구축** * 쇼핑, 광고, 페이 등 각 사업부별로 분산되어 관리되던 사업자 데이터를 통합하여 전사적으로 공통된 언어를 사용하는 'BC 데이터 마트'를 설계했습니다. * 사업부별로 상이했던 매출과 비용 발생 기준을 표준화하기 위해 도메인 담당자들과의 소통을 거쳐 '토스에서 활동하는 사업자'에 대한 명확한 정의를 수립했습니다. * 이를 통해 "이번 달 매출을 발생시킨 사업자가 몇 명인가?"라는 기초적인 질문에 대해 전사가 동일한 숫자로 답변할 수 있는 기술적 기반을 마련했습니다. **통찰을 제공하는 Monthly BC Report 설계 및 자동화** * 데이터의 전파력을 높이기 위해 신규(New), 이탈(Churn), 유지(Retained) 트렌드와 매출 규모별 티어(Tier) 분석을 포함한 월간 리포트를 기획했습니다. * 단순 지표 나열이 아닌, 코호트 리텐션(Cohort Retention) 분석을 통해 플랫폼 만족도를 확인하고, 이탈 가맹점 리스트 등 실무자가 즉시 활용 가능한 로우 데이터(Raw Data)를 함께 제공했습니다. * 데이터 파이프라인은 Airflow를 통해 마트를 구축하고 Jenkins로 배치 작업을 수행하며, 최종적으로 태블로(Tableau)와 SQL을 연동해 매달 자동으로 업데이트되는 환경을 구현했습니다. **현업 피드백을 통한 리포트의 고도화와 데이터 리터러시 확산** * PO, 세일즈 팀장 등 실제 사용자의 니즈를 파악하기 위해 심층 인터뷰를 진행하고, 이를 바탕으로 '회원 가입' 단계 분석이나 도메인 간 활성화 순서 등 구체적인 지표를 리포트에 추가했습니다. * 리포트 발행 이후 사업자 데이터에 대한 전사적 관심이 급증하며, 이탈 가맹점 상세 분석이나 데일리 트래킹 등 후속 심화 분석 프로젝트로 이어지는 성과를 거두었습니다. * 고정된 포맷에 안주하지 않고 매달 현업의 피드백을 반영하여 지표를 개선함으로써, 조직 전체의 데이터 이해도와 활용 능력을 점진적으로 상향 평준화했습니다. 데이터 마트 구축과 리포트 발행은 끝이 아닌 시작이며, 현업과의 지속적인 피드백 루프를 통해 리포트를 ' 살아있는 문서'로 관리하는 것이 중요합니다. 조직 내 데이터 리터러시를 높이고 싶다면 표준화된 지표 정의부터 시작해 구성원들이 실제 업무에 바로 적용할 수 있는 액션 중심의 데이터를 제공하는 단계적 접근이 필요합니다.

dbt 오버클러킹 (새 탭에서 열림)

디스코드는 2,500개 이상의 데이터 모델과 100명 이상의 개발자가 협업하는 페타바이트급 데이터 환경을 관리하기 위해, dbt의 기본 기능을 넘어선 커스텀 확장 시스템을 구축했습니다. 초기 도입 시에는 20분이 넘는 컴파일 시간과 개발자 간의 작업 충돌 등 확장성 한계에 부딪혔으나, 이를 자동화된 백필(Backfill)과 생산성 도구로 해결하며 견고한 데이터 분석 기반을 마련했습니다. 이 사례는 대규모 데이터 웨어하우스 환경에서 dbt를 효율적으로 확장하려는 기업들을 위한 기술적 청사진을 제시합니다. ### dbt 선정 배경과 주요 장점 * **엔지니어링 철학과의 일치:** 오픈 소스를 지향하고 엔지니어링의 유연성과 투명성을 중시하는 디스코드의 철학에 따라 dbt를 채택했습니다. * **도구 간 통합 및 모듈화:** 오케스트레이터인 Dagster와의 원활한 통합은 물론, SQL 기반의 모듈식 설계를 통해 코드 재사용성과 유지보수성을 확보했습니다. * **품질 관리:** 데이터 품질을 보장할 수 있는 포괄적인 테스트 프레임워크를 활용하여 신뢰할 수 있는 데이터 변환 프로세스를 구축했습니다. ### 대규모 데이터 환경에서의 한계점 * **긴 컴파일 대기 시간:** 프로젝트 규모가 커짐에 따라 전체 프로젝트를 재컴파일하는 데 20분 이상이 소요되어 개발 생산성이 급격히 저하되었습니다. * **증분 전략의 비효율성:** dbt가 기본적으로 제공하는 증분(Incremental) 구체화 전략은 디스코드의 페타바이트급 데이터 볼륨을 처리하기에 최적화되어 있지 않았습니다. * **동시성 충돌 문제:** 여러 개발자가 동시에 작업하는 과정에서 서로의 테스트 테이블을 덮어쓰는 등 협업상의 혼선과 자원 낭비가 발생했습니다. ### 확장성을 위한 커스텀 최적화 전략 * **성능 중심의 코어 확장:** dbt의 표준 기능을 확장하여 대규모 조직에 적합한 커스텀 시스템을 구축함으로써 개발 사이클을 획기적으로 단축했습니다. * **자동화된 백필 시스템:** 수동 개입이 많이 필요한 복잡한 데이터 백필 과정을 자동화하여 운영 리소스를 절감하고 데이터의 정합성을 높였습니다. * **플랫폼 독립적 설계:** Google BigQuery를 사용하면서도 특정 클라우드 제공업체에 종속되지 않는(Provider-agnostic) 구조를 취해 범용적인 적용이 가능하도록 설계했습니다. 디스코드의 이러한 시도는 단순한 도구 도입을 넘어, 대규모 데이터 스택을 운용할 때 발생하는 병목 현상을 엔지니어링 기반의 커스텀 솔루션으로 해결할 수 있음을 보여줍니다. 데이터 규모가 급격히 성장하는 조직이라면 dbt의 기본 기능에만 의존하기보다, 자사의 인프라에 맞춘 자동화와 확장 도구를 결합하는 전략이 필수적입니다.