마지막 편집일: 2026년 10월 26일
dbt 서밋 2026의 분과 세션에서, 베리스크 애널리틱스의 인수심사 데이터 팀 소속 데이터 엔지니어인 케이시 슈웨겔, 비자이 싱, 그리고 마테우스 게카는, 레거시 데이터 스택을 계승한 경험이 있는 이들이라면 익숙하게 느낄 만한 4단계 현대화 과정에 대해 설명했습니다. 이 과정은 결국 확장되지 못할 때까지는 작동하던 시스템이, 그 문제를 해결하기 위한 개선 조치를 취했지만 또 다른 새로운 문제를 낳게 되는 구조로 진행됩니다.
Verisk는 수백 개의 개별 보험사로부터 수집한 보험 관련 경험 데이터를 집계하며, 각 보험사는 자체 시스템을 천 페이지에 달하는 PDF 매뉴얼에 명시된 요구되는 고정폭 형식으로 변환합니다. 팀은 이 과정이 드물게나마 오류가 발생하지 않는다고 건조하게 인정했습니다. 이러한 출력 데이터는 액추어리들에게 제공되며, 이들은 역사적 데이터를 바탕으로 주 규제 당국에 제출되는 가격 결정을 도출하는 것이 전적인 업무인 까다로운 데이터 소비자로 여겨집니다. 다시 말해, 이 프로세스 라인에는 잘못된 수치가 들어갈 여지가 전혀 없습니다.
데이터 자체는 각각 수십억 개의 행과 수백 개의 열을 갖는 테이블에 저장되어 있습니다. 수십 년 동안 이 데이터는 메인프레임에서 처리되어 왔습니다. “메인프레임이 고장난 것은 아니었습니다.”라고 케이시는 말했습니다.
“그것은 수십 년에 걸친 인수 규정을 보유하고 있었으며, 그 역할을 매우 훌륭하게 수행했습니다.” 그러나 숫자가 실제로 어디서 유래했는지, 문서화되지 않은 수십 년간의 로직 속 어딘가에 묻혀 있는 요율 산정 규정이 어디에서 비롯되었는지를 추적하는 일은 마치 블랙박스를 들여다보는 것과 같았고, 팀의 자체 규칙은 다음과 같았습니다: 작업이 실패하면 절대 손대지 않는다.
팀이 클라우드로 처음 전환했을 때, Snowflake와 Jupyter 노트북을 결합한 방식은 과거 메인프레임 작업 스트림 속에 묻혀 있던 비즈니스 로직에 버전 관리와 가시성을 제공했습니다. 이는 분기별 배치 처리에는 잘 작동했지만, 노트북은 일상적인 프로덕션 자동화를 위해 설계된 것이 아니었습니다. 그 다음 단계에서는 스트림, 태스크, 동적 테이블 등 Snowflake의 기본 객체를 직접 기반으로 구축함으로써 매일 갱신이 가능해졌으나, 기존 문제는 새로운 문제로 대체되었습니다: 수백 개의 서로 독립된 태스크와 테이블을 수동으로 조율해야 했고, 환경 간에 코드를 깔끔하게 승격할 방법도 없었습니다.
테이블과 뷰는 데이터와 로직을 저장하고, 마テ리얼라이즈드 뷰는 가장 무거운 데이터 세트의 처리 속도를 향상시켰으며, 스트림과 작업은 크론 스케줄에 따라 변경 데이터를 포착했고, 동적 테이블은 대상 지연에 맞춰 자동으로 새로 고쳐졌습니다. 이 시스템은 작동했지만, 이를 유지하는 데에는 수백 개의 개별 객체를 일일이 수동으로 관리해야 했습니다. 상위 계층의 스키마 변경이나 작업 실패가 발생하면, 쿼리 기록을 하나씩 일일이 검토해야 했습니다.
dbt는 마침내 이 모든 것을 하나로 통합했습니다: 피어 리뷰가 적용된 버전 관리형 모델, 오래된 위키 대신 자체 문서화된 계열성, 그리고 보고서를 조용히 손상시키기보다는 잘못된 데이터가 보험계리사에게 전달되기 전에 파이프라인을 중단하는 테스트 기능입니다. Snowflake에서는 서로 다른 스키마 간에 동일한 테이블 이름을 사용할 수 있지만, dbt는 모든 모델 이름을 고유하게 요구하므로 팀은 비즈니스 라인별로 프로젝트를 구성하고, 각 라인 안에 스테이징, 중간, 마트 계층을 중첩시켰으며, 계층·도메인·객체명을 결합한 명명 규칙을 도입해 충돌을 방지했습니다. 또한 맞춤형 매크로가 각 모델의 파일 경로에 있는 표식을 읽어 해당 모델이 배치될 위치를 결정하며, 개발 환경에서는 개발자의 개인 스키마에, 생산 환경에서는 공유 스키마에 자동으로 배치되도록 하여 별도의 별칭 설정이 필요하지 않습니다.
dbt 이전에는 팀이 서로 완전히 일치하지 않는 세 가지 서로 다른 진실의 원천과 씨름하고 있었습니다: Snowflake에 직접 패치되는 프로덕션 로직, 코드가 뒤처지는 Git 저장소에 있는 소스 코드, 그리고 몇 달 전에 이미 현실을 반영하지 않게 된 Confluence에 저장된 문서. dbt의 doc blocks은 이러한 문제를 하나의 마크다운 파일에 한 번 작성한 설명으로 통합하여, 필요한 모든 곳에서 자동으로 참조되도록 했습니다. 따라서 한 곳에서 업데이트하면 모든 곳에서 자동으로 반영되며, 코드와 별도로 벗어나지 않고 버전 관리되고 코드와 함께 검토됩니다.
마테우시가 구현 과정을 설명하며 말했듯이, “이 발표는 사실 dbt 자체에 관한 내용은 아닙니다. 오히려 dbt를 도입한 뒤에 발생하는 변화들에 대한 이야기입니다.”
그 기반을 뒷받침하던 체계가 이제 팀이 AI를 차곡차곡 더해나갈 수 있게 해줍니다: 맞춤형 dbt Wizard 스킬을 활용해 DAG 전반에 문서를 자동으로 배포하고, 프로젝트 컨텍스트를 이용해 더욱 우수한 AI 생성 SQL을 도출하며, 푸ルリ퀘스트에서 표준을 자동으로 강제 적용하고, 작업 로그와 쿼리 히스토리를 상호 참조하여 디버깅을 가속화합니다. 가장 먼저 손을 댄 분야는 문서 관리였습니다. 전용 dbt Wizard 스킬과 doc blocks 패턴을 결합하면, 개발자가 초기 소스 설명을 작성한 후에는 이를 수동으로 복사·붙여넣기 하는 대신, DAG 전체에 걸쳐 열 설명이 자동으로 아래로 전파됩니다.
바로 그 풍부한 맥락 층 덕분에 AI 지원 모델 개발이 더욱 신뢰할 수 있게 되며, 요청을 단순한 원시 SQL 구문이 아니라 비즈니스 용어로 표현할 수 있고, 별도의 스킬이 팀 고유의 표준, 명명 규칙, 필수 YAML 필드 등을 정의하므로 개발자는 다른 사람이 이를 검토하기 전에 자신의 풀 리퀘스트에 대해 이를 실행해 볼 수 있습니다.
팀은 이 모든 과정이 여전히 인간의 개입 하에 이루어진다는 점을 분명히 밝혔습니다. 케이시는 “AI는 패턴과 맥락을 기반으로 성장할 것이며, 우리의 문서화, 명명 규칙, 계보 관리 및 표준이 더욱 정교해질수록 AI가 활용할 수 있는 맥락도 더 많아질 것”이라고 말했습니다.
이 전환 과정에서 인간 측면에 대한 청중의 질문은 다음과 같았다: Git나 SQL에 대한 배경 지식이 없는 직원들을 어떻게 온보딩할 것인가, 그리고 팀의 솔직한 답변은 방향성이 점점 더 기술 중심으로 바뀌고 있기 때문에 일부 사람들은 변화를 주도하고 다른 모든 이들을 함께 이끌어 가야 한다는 것이었다. 데이터 측면에서는 아직 해결되지 않은 과제로 규모 문제가 남아 있다: 보험계리사들은 10년 이상의 완전히 최신화된 과거 데이터를 원하며, 점진적인 모델들은 여전히 이러한 요구에 따라잡기 위해 노력하고 있다.
dbt 서밋 2026의 모든 키노트와 분과 세션을 주문형으로 시청하세요. dbt 서밋 2026 주문형 시청 →
dbt 시작하기
실제로 확장 가능한 데이터 인프라를 구축하는 분석 엔지니어들과 함께하세요.
dbt Wizard CLI 설치
분석 엔지니어링에 특화된 에이전트로 시작해 보세요. 이 에이전트는 어떤 도구를 호출해야 하는지, 어떤 컨텍스트를 가져와야 하는지 알고 있으며, 사용자에게 결과를 표시하기 전에 스스로 작업을 검증합니다.
최신 게시물
프롬프트에서 PR까지: Careem의 AI가 사람이 직접 확인하기도 전에 dbt 모델을 어떻게 작성하고 검증하는지
2026년 10월 26일에
DocuSign이 Claude Code와 dbt v2, dbt MCP, 그리고 에이전트 스킬을 결합함으로써 분석 엔지니어링 시간을 절반으로 줄인 방법
2026년 10월 26일에
버진 미디어 O2가 dbt에 메모리를 제공함으로써 컴퓨팅 비용을 30% 절감한 방법
2026년 10월 26일에
데이터를 형성하는 가장 큰 커뮤니티에 참여하세요
dbt 커뮤니티는 전 세계 수천 명의 데이터 리더 및 AI 실무자들과 함께 최고의 실무 사례, 혁신을 경험하고 직접 협업할 수 있는 문입니다. 질문을 던지고, 통찰을 공유하며, 전문가들과 함께 더 나은 결과를 만들어 보세요.