dbt

토스플레이스 데이터봇 ‘판다(PANDA)’를 소개합니다 : 모든 팀원이 데이터 전문가처럼 일하는 방법 (새 탭에서 열림)

토스플레이스는 데이터 분석가에게 집중된 단순 추출 요청을 해결하고 전사적인 데이터 민주주의를 실현하기 위해 AI 데이터 분석 어시스턴트 ‘판다(PANDA)’를 개발했습니다. 판다는 단순한 챗봇을 넘어 표준 데이터 마트 정비와 에이전트 기반의 자율 루프 시스템을 통해 데이터 조회부터 실무 인사이트 제공까지 수행하며, 출시 후 전사 구성원의 70%가 활용하는 필수적인 도구로 자리 잡았습니다. 기술적 복잡함보다 비즈니스 맥락과 데이터 거버넌스에 집중함으로써, 누구나 데이터 분석가의 도움 없이도 정확한 의사결정을 내릴 수 있는 환경을 구축했다는 데 큰 의의가 있습니다. ### 데이터 신뢰성을 위한 표준 데이터 마트(SSOT) 구축 * AI가 일관된 답을 낼 수 있도록 Data Analysis와 Platform 팀이 협업하여 핵심 데이터를 단일화된 테이블로 정비했습니다. * **표준 네이밍 컨벤션:** 테이블명은 `{역할}_{도메인}_{주제}`(예: fact_device_error_log)로, 컬럼명은 `{접두어}_{대상}_{속성}_{접미어}`(예: is_merchant_active)로 규칙화하여 AI가 이름만으로도 데이터의 목적을 이해하게 했습니다. * 모든 테이블과 컬럼에 상세 설명을 추가하여 AI가 데이터를 정확하게 탐색할 수 있는 기반 정보를 제공했습니다. ### 데이터 선택의 정확도를 높이는 Scoring & Ranking 시스템 * 질문에 대해 매번 다른 테이블을 선택하는 문제를 방지하기 위해 유사도와 신뢰도를 결합한 점수 체계를 도입했습니다. * **최종 점수 산출:** `(질문-테이블 유사도) × (데이터 계층 가중치)` 공식을 적용합니다. * **계층별 가중치:** 전사 주요 지표(SSOT)는 4배, 검증된 표준 마트는 3배, 도메인 마트는 2배, 원시 로그 데이터는 1배의 가중치를 부여하여 가장 신뢰할 수 있는 소스를 우선 선택하게 합니다. * dbt tags를 활용해 관리되는 테이블만 Manifest 파일로 가져와 탐색 범위를 최적화했습니다. ### 비즈니스 맥락 연결과 에이전틱 루프(Agentic Loop) * ‘설치 매장’이나 ‘업종 분류’와 같은 비즈니스 용어 정의를 데이터 구조와 연결하여 AI가 단순 수치 이상의 맥락을 파악하도록 설계했습니다. * AI가 스스로 상황에 맞는 도구를 선택하고, 결과가 부정확할 경우 스키마를 다시 확인하여 쿼리를 수정 및 재실행하는 자율적 재시도 과정을 거칩니다. * '테이블 탐색 → 쿼리 실행 → 결과 검증 → 수정 → 최종 결과 도출'의 과정을 반복하며 정답률을 높이는 구조를 갖췄습니다. ### 실무 활용성을 고려한 답변 구조 및 성과 * 단순 숫자 나열이 아니라 **결과, 조회 기준, 실무 인사이트**라는 3단계 구조로 답변을 제공하여 사용자의 해석 시간을 단축했습니다. * 출시 직후 전체 팀원의 절반 이상이 사용했으며, 현재는 70%의 사용률을 기록하며 데이터 요청에 대한 심리적 문턱을 낮추고 실질적인 업무 방식의 변화를 이끌어냈습니다. * 개발자, 기획자 등 비데이터 직군에서도 활발히 사용하며 데이터 분석가의 리소스를 고부가가치 분석 업무에 집중할 수 있도록 지원합니다. 성질 급한 AI 모델의 성능에만 의존하기보다, **데이터의 표준화와 비즈니스 로직의 명확한 정의(Governance)**가 선행될 때 비로소 실효성 있는 AI 서비스가 완성된다는 점을 시사합니다. 사내 데이터 민주화를 고민한다면, 기술적 기교 이전에 AI가 읽기 좋은 데이터 환경을 만드는 것부터 시작할 것을 추천합니다.

Background Coding Agents: Supercharging Downstream Consumer Dataset Migrations (Honk, Part 4) | Spotify Engineering (새 탭에서 열림)

Spotify는 배경 코딩 에이전트 'Honk'와 내부 플랫폼인 Backstage를 결합하여 약 1,800개의 데이터셋 소비자를 새로운 버전으로 마이그레이션하는 복잡한 과정을 자동화했습니다. 이 프로젝트를 통해 수동 작업 시 약 10주가 소요될 것으로 예상되었던 엔지니어링 공수를 획기적으로 절감하며 대규모 소프트웨어 유지보수의 새로운 가능성을 확인했습니다. 결과적으로 에이전트 기반의 자동화가 성공하려면 데이터 환경의 표준화와 명확한 컨텍스트 제공이 핵심적이라는 교훈을 얻었습니다. **데이터셋 마이그레이션의 도전 과제** * Spotify는 새로운 기능을 지원하기 위해 널리 사용되던 기존 데이터셋 2개를 폐기하고 새 버전으로 교체해야 하는 상황에 직면했습니다. * 마이그레이션 대상은 약 1,800개의 직접적인 파이프라인이었으며, SQL 기반(BigQuery Runner, dbt)과 Scala 기반(Scio)이라는 서로 다른 세 가지 프레임워크가 혼재되어 있었습니다. * 6개월이라는 짧은 기간 내에 수천 개의 저장소를 수정해야 했기에, 단순 수동 작업으로는 감당하기 어려운 규모였습니다. **Backstage와 Fleet Management를 통한 대상 식별** * 마이그레이션 전, Backstage의 'Endpoint Lineage'와 'Codesearch' 플러그인을 활용하여 폐기될 데이터셋을 사용하는 모든 저장소와 팀을 정확히 파악했습니다. * 식별된 대상 저장소들은 Spotify의 대규모 변경 관리 도구인 'Fleetshift'를 통해 관리 범주로 지정되었습니다. * 이를 통해 수천 개의 저장소에 걸친 변경 사항을 한곳에서 모니터링하고 조율할 수 있는 기반을 마련했습니다. **에이전트를 위한 컨텍스트 엔지니어링과 제약 사항** * Honk 에이전트가 정확한 수정을 수행할 수 있도록 인간용 마이그레이션 가이드를 재구성하여 상세한 컨텍스트 파일을 제공했습니다. * 초기에 에이전트가 잘못된 필드 매핑을 추측하는 문제를 해결하기 위해, 모든 필드 변경 사항을 명확한 테이블 형태로 프롬프트에 포함했습니다. * 프레임워크의 유연성이 너무 높아 표준화가 어려운 Scio 파이프라인은 자동화 대상에서 제외하고, 비교적 구조가 일관된 SQL 기반 프레임워크(dbt, BigQuery Runner)에 집중했습니다. * 에이전트가 스스로 판단하기 어려운 모호한 케이스의 경우, 코드를 직접 수정하는 대신 해당 위치에 인간 엔지니어가 참고할 수 있는 가이드 링크와 주석을 남기도록 설정했습니다. **자동화된 마이그레이션의 성과와 기술적 교훈** * Fleetshift를 통해 총 240개의 자동 마이그레이션 Pull Request(PR)를 성공적으로 배포했습니다. * 하지만 많은 SQL 저장소에 유닛 테스트가 부족하여, 에이전트가 수정한 내용을 스스로 검증하고 보완하는 '자가 수정 루프'를 완전히 활용하지 못한 점은 한계로 남았습니다. * 이번 프로젝트를 통해 데이터 환경의 전략적 표준화와 테스트 코드의 의무화가 배경 코딩 에이전트의 효율을 극대화하는 필수 조건임을 확인했습니다. 성공적인 에이전트 도입을 위해서는 코드의 표준화와 테스트 자동화가 선행되어야 합니다. 향후 Spotify는 Honk가 스스로 Jira 티켓이나 문서를 읽고 컨텍스트를 수집하는 기능을 추가하여, 인간이 사전 컨텍스트를 작성하는 수고를 더욱 줄이고 복잡한 작업의 성공률을 높일 계획입니다.

당근은 왜 User Activation을 전사 공통 데이터 레이어로 만들었을까? (새 탭에서 열림)

당근은 단순한 액티브 유저(Active User) 수치만으로는 파악하기 어려운 사용자 행동의 원인과 흐름을 분석하기 위해 전사 공통 데이터 레이어인 'Activation 레이어'를 구축했습니다. 이를 통해 사용자의 활성 상태와 상태 전이를 일관된 기준으로 정의함으로써 데이터 신뢰성을 확보하고, 팀 간 중복 계산으로 인한 비용과 운영 리소스를 대폭 절감했습니다. 결과적으로 데이터 분석 환경을 쿼리 중심에서 시스템 중심으로 격상시켜 전사적인 의사결정 속도와 정확도를 높였습니다. **단순 지표를 넘어선 User Activation의 중요성** * 단순한 액티브 유저 수는 '무슨 일이 일어났는지'는 보여주지만, '왜' 일어났는지에 대한 해답을 주지 못하므로 유저를 상태별로 쪼개어 보는 관점이 필요합니다. * **활성 상태**: 특정 시점에 유저가 신규(New), 유지(Retained), 복귀(Reactivated), 이탈(Inactive) 중 어떤 상태인지 분류합니다. * **상태 전이**: 기간의 흐름에 따라 유저가 어떤 경로로 이동하는지(예: 유지 → 이탈) 파악하여 활동성 수준에 따른 구체적인 액션을 가능하게 합니다. * 이전에는 팀마다 이 기준을 각자 계산하여 신뢰도가 낮고 운영 안정성이 떨어졌으나, 이를 공통 레이어로 통합하여 해결했습니다. **신뢰성 확보를 위한 기준 행동의 고정** * 단순한 UI 로그(클릭 등)가 아닌, 비즈니스적 의미를 담은 **Fact 모델**을 기준으로 Activation을 계산하도록 설계했습니다. * 로그 내 파라미터에 따라 의미가 달라지는 혼선을 방지하기 위해, 사전에 정제된 Fact 레이어를 입력값으로 사용합니다. * `<fact_name>_activation_<time_grain>`과 같은 엄격한 네이밍 컨벤션을 적용하여 모델 이름만으로도 어떤 행동과 주기(일/주/월)를 기준으로 하는지 누구나 쉽게 알 수 있게 했습니다. **증분 모델(Incremental Model)을 통한 비용 최적화** * 수천만 명의 사용자 데이터를 매일 전체 재처리하는 방식은 비용 소모가 크기 때문에, dbt의 증분 모델 방식을 도입했습니다. * **FirstLast 모델**: 각 유저별 최초/직전/최근 활동일을 별도로 관리하여 전체 이력을 매번 스캔하지 않도록 했습니다. * **Activation 모델**: 당일 활동 유저 정보와 FirstLast 모델을 결합하여 상태와 복귀 간격 등을 계산하고, 결과를 다시 FirstLast 모델에 업데이트하는 순환 구조로 데이터 스캔량을 최소화했습니다. * **Activation Status 모델**: 활동이 없는 유저를 포함한 전체 유저의 현재 상태(특히 이탈 기간)를 관리하여 분석 편의성을 높였습니다. **dbt 매크로를 활용한 생산성 극대화** * 다양한 행동(앱 방문, 게시글 작성 등)과 시간 단위(Daily, Weekly, Monthly)별로 수많은 모델을 직접 구현해야 하는 번거로움을 매크로로 해결했습니다. * 복잡한 상태 계산 로직을 dbt 매크로로 표준화하여, 새로운 Activation 모델이 필요할 때 설정값만 입력하면 자동으로 수십 개의 모델이 생성되도록 자동화했습니다. * 이를 통해 데이터 엔지니어의 반복 작업을 줄이고, 분석가들이 필요할 때 즉시 공통 레이어를 확장할 수 있는 환경을 만들었습니다. 데이터를 단순히 쿼리 결과물로 보는 단계를 넘어, 시스템화된 '인프라'로 구축할 때 비로소 전사적인 데이터 활용도가 극대화됩니다. 당근의 사례처럼 상태 전이와 같은 복잡한 로직을 공통 레이어로 추상화하고 자동화한다면, 분석 효율성을 높이는 동시에 데이터 기반의 의사결정 문화를 더욱 공고히 할 수 있습니다.

네이버 TV (새 탭에서 열림)

네이버웹툰은 기존 데이터 파이프라인에서 발생하던 복잡한 데이터 적재(Backfill) 작업과 높은 운영 비용 문제를 해결하기 위해 DBT와 Airflow를 결합한 'Flow.er' 시스템을 구축했습니다. Flow.er는 데이터 간의 의존성을 명확히 정의하는 데이터 계보(Lineage)를 중심으로 설계되어, 엔지니어가 데이터의 흐름을 온디맨드로 파악하고 관리할 수 있게 돕습니다. 이를 통해 데이터 품질을 높이는 동시에 여러 데이터 조직으로 확장 가능한 고도화된 데이터 플랫폼으로 발전하고 있습니다. **과거 파이프라인의 한계와 Flow.er의 탄생** * 과거에는 파이프라인 복구와 수동 백필 작업에 과도한 운영 리소스가 소모되어 업무 효율이 저하되는 문제가 있었습니다. * 데이터 간의 복잡한 연결 고리를 한눈에 파악하기 어려워 데이터 정합성을 유지하고 장애에 대응하는 데 한계가 존재했습니다. * 이러한 문제를 극복하기 위해 데이터 계보를 가시화하고 자동화된 운영이 가능한 'Flow.er' 서비스에 대한 PoC를 거쳐 실무에 도입했습니다. **DBT와 Airflow를 활용한 계보 중심 아키텍처** * **DBT의 역할**: SQL 기반의 데이터 모델링을 통해 데이터 변환 로직을 관리하며, 모델 간 의존성을 바탕으로 데이터 계보와 관련 문서(Documentation)를 자동 생성합니다. * **Airflow의 역할**: DBT로 정의된 모델들이 선후 관계에 맞춰 정확히 실행되도록 워크플로우를 오케스트레이션하고 스케줄링을 담당합니다. * **개발 생산성 향상**: 개인 인스턴스를 제공하여 개발자가 격리된 환경에서 모델을 테스트할 수 있게 하고, CI/CD 파이프라인을 통해 코드 변경 사항을 안전하게 배포합니다. **시스템 안정성 및 확장을 위한 컴포넌트** * **Playground & Tower**: 자유로운 데이터 실험을 위한 샌드박스 환경인 Playground와 파이프라인 상태를 실시간으로 감시하는 Tower를 통해 운영 가시성을 확보했습니다. * **Partition Checker**: 상위 데이터 소스의 파티션 생성 여부를 사전에 체크하여 데이터 누락을 방지하고 적재 정합성을 획기적으로 개선했습니다. * **Manager DAG System**: 수많은 데이터 모델과 DAG를 효율적으로 관리하기 위해 관리 전용 시스템을 개선하여 운영 편의성을 극대화했습니다. **Flow.er의 미래와 기술적 지향점** * **MCP(Model Context Protocol) 서버**: 데이터 모델의 컨텍스트를 외부 도구나 AI 에이전트가 이해할 수 있는 규격으로 제공하여 데이터 활용도를 높일 예정입니다. * **AI Agent 연동**: 단순한 파이프라인 운영을 넘어 AI가 데이터 계보를 분석하고 문제를 해결하거나 코드를 최적화하는 단계로의 발전을 준비하고 있습니다. 데이터 파이프라인의 복잡성으로 인해 백필과 운영에 고통받고 있다면, DBT를 활용해 계보를 명확히 정의하고 이를 Airflow와 유기적으로 연결하는 접근 방식이 필수적입니다. 데이터 계보 중심의 아키텍처는 단순한 자동화를 넘어 데이터 프로덕트의 신뢰성을 담보하는 가장 강력한 수단이 될 것입니다.

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

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

셀프 서비스 분석 확장: 5,000명의 직원에게 힘을 실어주는 도구들 (새 탭에서 열림)

Datadog은 200명에서 5,000명 규모로 급격히 성장하는 과정에서 발생하는 데이터 병목 현상을 해결하기 위해, 모든 직원이 중앙 데이터 팀의 도움 없이 스스로 데이터를 활용할 수 있는 '셀프 서비스 분석' 체계를 구축했습니다. 오픈 소스 기술을 기반으로 데이터 수집부터 변환, 발견, 리포팅까지 이어지는 통합 툴킷을 제공함으로써 데이터 팀은 단순 운영 업무에서 벗어나 고부가가치 과제에 집중할 수 있게 되었으며, 전사적으로 데이터 기반의 의사결정 문화를 정착시키는 성과를 거두었습니다. ### 셀프 서비스 분석의 세 가지 기둥과 사용자 분류 * 셀프 서비스 분석은 모든 임직원이 중앙 팀의 개입 없이 스스로 데이터를 활용해 의사결정을 내리는 상태를 지향하며, 이는 '데이터(Data)', '도구(Tools)', '지식(Knowledge)'이라는 세 가지 핵심 요소로 뒷받침됩니다. * 사용자의 데이터 숙련도와 니즈에 따라 사용자를 세 가지 페르소나로 분류하여 맞춤형 환경을 제공합니다. * **탐험가(Explorers):** 잘 정돈된 데이터와 미리 구축된 리포트를 활용하는 일반 사용자. * **빌더(Builders):** 직접 쿼리를 작성하고 팀을 위한 대시보드를 생성하는 숙련된 사용자. * **전문가(Experts):** 새로운 데이터를 노출하고 비즈니스 로직을 유지하며 데이터 품질을 제어하는 고숙련 사용자. ### 데이터 제품화와 단일 진실 공급원(SSOT) 구축 * 엔지니어링, 마케팅, 영업, 인사 등 모든 부서가 동일한 데이터를 바라볼 수 있도록 중앙 집중화된 '단일 진실 공급원(Single Source of Truth)'을 확립했습니다. * 'Bring Your Own Data(BYOD)' 툴을 개발하여, 데이터를 생성하는 어떤 팀이든 이를 분석 환경에 직접 노출하고 공유할 수 있는 자율성을 부여했습니다. * 데이터의 신뢰성을 높이기 위해 강력한 명명 규칙(Conventions)을 적용하고, 상세한 문서화와 데이터 품질 모니터링 시스템을 통해 사용자가 데이터를 믿고 사용할 수 있는 환경을 조성했습니다. ### 기술적 셀프 서비스 툴 스택: 수집에서 발견까지 * **데이터 수집(Intake):** 내부 데이터 스토어 및 서드파티 도구와 연결되는 커넥터, 데이터 요청을 위한 유저 인터페이스, 파이프라인 가시성 및 알림 기능을 제공합니다. * **데이터 변환(Transformation):** 전사 데이터 분석가들이 dbt와 SQL을 사용해 각 부서의 비즈니스 로직을 직접 제어할 수 있는 개발 환경을 구축했습니다. 이를 통해 데이터 모델링 레이어의 일관성을 유지하면서도 부서별 자율성을 보장합니다. * **데이터 발견(Discovery):** 모든 데이터셋과 필드에 대한 검색 기능을 제공하며, 데이터 리니지(Lineage), 소유권, 민감도, 신뢰도 등 풍부한 메타데이터를 제공하여 사용자가 필요한 데이터를 쉽게 찾고 이해할 수 있게 합니다. ### 실용적인 결론 조직이 커질수록 데이터 팀의 인원을 늘리는 것만으로는 데이터 수요를 감당할 수 없습니다. Datadog의 사례처럼 데이터 자체를 하나의 '제품'으로 취급하고, 현업 담당자들이 직접 데이터를 가공하고 소비할 수 있는 인프라와 가이드라인을 제공하는 것이 확장성 있는 데이터 문화를 만드는 핵심입니다. 이를 위해서는 도구의 도입뿐만 아니라 데이터 품질에 대한 엄격한 기준 확립과 사용자 교육이 반드시 병행되어야 합니다.