LangChain이 데이터 스택을 에이전트 중심으로 재설계한 방법

https://www.langchain.com/blog/agent-data-stack

지난 1년 동안 우리 데이터 팀은 에이전트를 지원하려면 데이터 스택이 어떻게 진화해야 하는지 다시 고민해 왔습니다. 대부분의 회사 데이터 스택은 대시보드, 리포트, SQL 워크플로를 중심으로 만들어져 있습니다. 이런 요소는 여전히 유용하지만, 에이전트가 등장하면서 데이터 레이어가 제공해야 하는 것이 달라졌습니다.

에이전트는 명확한 정의, 신뢰할 수 있는 소스, 비즈니스 맥락, 그리고 데이터 이면의 로직에 접근할 수 있을 때 더 많은 질문에 답할 수 있습니다. 이런 맥락이 없어도 SQL을 생성할 수는 있지만, 그 답은 신뢰하기 어렵습니다. 회사 고유의 정의를 놓치거나, 엉뚱한 테이블을 쓰거나, 기술적으로는 맞지만 비즈니스에는 실제로 도움이 안 되는 방식으로 답할 수 있기 때문입니다.

우리는 회사 전체에서 데이터에 더 쉽게 접근할 수 있게 하는 동시에, 에이전트가 질문에 정확하게 답하고 그 답을 어떻게 도출했는지 설명할 수 있을 만큼 충분한 맥락을 제공하고 싶었습니다.

그래서 전통적인 BI 도구 중심의 데이터 스택에서, 셀프서비스 분석과 공유된 맥락, 에이전트 활용을 위해 설계된 스택으로 큰 아키텍처 전환을 단행했습니다.

주요 성과

• 셀프서비스 데이터 에이전트가 이제 3명으로 구성된 데이터 팀이 직접 처리할 수 있는 요청량의 약 40배를 처리합니다.
• 최근 30일 동안 계정이 발급된 사용자(전사 인원의 3분의 1)의 거의 100%가 데이터 에이전트를 사용했습니다. 이 기간 동안 약 2,200건의 에이전트 대화가 있었고, 사용자 한 명당 월평균 23건에 해당합니다.

출발점

이번 전환 전에는 거의 모든 데이터 요청이 데이터 팀을 거쳤습니다. 당시 그 팀은 단 한 명이었습니다.

기존의 전통적인 BI 도구는 미리 정의된 리포팅에는 문제가 없었지만 경직되어 있었습니다. 탐색적 분석은 협업하기도, 공유하기도 어려웠고, 데이터가 이미 모델링되어 BI 레이어에 노출되어 있지 않으면 데이터 팀 밖의 누구도 스스로 탐색하기 어려웠습니다.

이 모든 것이 병목을 만들었습니다. 회사 곳곳에서 좋은 질문이 나왔지만, 답을 얻으려면 보통 데이터 팀원이 질문을 해석하고, 알맞은 모델을 찾고, 쿼리를 작성하거나 손보고, 결과를 검증한 뒤 답을 보내 주어야 했습니다. 데이터 팀은 더 깊은 분석과 모델링, 부서 간 프로젝트에 집중하는 대신 일회성 요청을 처리하는 데 많은 시간을 썼습니다.

우리에게는 여러 유형의 사용자를 동시에 지원할 수 있는 에이전트 우선(agent-first) 스택이 필요했습니다.

잘 다듬어진 대시보드를 원하는 사람도 있었고, 노트북과 SQL을 원하는 사람도 있었습니다. 데이터가 어디에 있는지 몰라도 질문에 답을 얻게 도와주는 대화형 인터페이스를 원하는 사람도 있었습니다. 엔지니어와 기술 직군에게는 유연성이 필요했고, 많은 비즈니스 사용자에게는 더 안전하고 안내가 잘 갖춰진 탐색 방식이 필요했습니다.

또한 데이터 작업을 한곳에 모으고 싶었습니다. 기존 BI 도구를 유지하면서 새 도구를 추가하는 방안도 검토했지만, 그렇게 하면 사용성과 맥락, 신뢰가 두 시스템으로 갈라졌을 것입니다.

도구를 평가한 방법

우리가 찾던 것은 단순한 대시보드 대체재가 아니었습니다.

여러 벤더를 평가하면서, AI 기능을 제품에 직접 녹여 넣고 에이전트 경험을 핵심 워크플로의 일부로 다루는 곳을 원했습니다. 또 기술에 익숙한 사용자와 엔지니어가 매번 데이터 팀을 기다리지 않고 필요한 것을 직접 만들 수 있는 노트북 형태의 레이아웃도 원했습니다.

비기술 사용자를 위해서는 비즈니스 질문을 던지면 쓸 만한 1차 답변을 받고, 에이전트가 어떤 소스를 사용했는지 파악할 수 있는 공간이 필요했습니다.

최종적으로 Hex를 선택했습니다. 대시보드, 노트북, 대화형 분석을 모두 지원해서 단일 중앙 데이터 워크스페이스로 삼기에 수월했습니다.

이제 사람들은 여러 접점에서 Hex 에이전트와 상호작용합니다.

• Threads와 노트북을 포함한 Hex UI
• Slack
• CLI 워크플로
• MCP
• MCP·CLI 연동을 통한 LangSmith Fleet

접점이 넓다는 것은 도입 확산에 중요합니다. 에이전트는 사람들이 이미 일하고 있는 곳에서 쓸 수 있을 때 가장 유용합니다. 프로덕트 매니저는 Hex에서 사용자 행동을 물어보고 싶을 수 있고, GTM 팀 동료는 Slack에서 파이프라인 관련 질문을 하고 싶을 수 있습니다. 기술 사용자는 CLI나 MCP로 상호작용하고 싶을 수 있습니다.

이미 팀 전반에서 다양한 활용 사례가 나오고 있습니다.

• 마케팅은 주간 파이프라인 분석에 에이전트를 사용합니다
• 프로덕트는 사용자 행동과 사용 추세를 파악하는 데 사용합니다
• 영업과 배포 엔지니어링은 고객 헬스와 사용량 관련 질문에 사용합니다
• 고객 엔지니어링은 이탈(churn), 확장, 계정 추세를 분석하는 데 사용합니다

예전에는 이런 질문들이 데이터 팀 앞에 대기열을 만들었습니다. 이제는 1차 분석이 도구 안에서 바로 이루어지는 경우가 많고, 데이터 팀은 검증이나 더 깊은 분석, 더 엄밀함이 필요한 의사결정을 지원합니다.

전환 후 달라진 것

우리는 6주 만에 기존 BI 도구에서 100% 이전을 마쳤습니다.

오늘날 전사 인원 100%가 어떤 형태로든 Hex를 통해 에이전트 우선 데이터 스택을 사용합니다.

사용자 중 약 70%는 읽기 전용 권한을, 약 30%는 에이전트 권한을 갖고 있습니다. 이 역할은 IT를 통해 셀프서비스로 부여되므로 누구든 필요할 때 에이전트 권한을 신청할 수 있습니다.

이 대화 중 상당수는 예전 같으면 데이터 팀을 거쳤을 질문입니다. 그렇다고 데이터 팀이 워크플로에서 완전히 사라진 것은 아닙니다. 이제 우리에게 도달하는 질문은 더 복잡하고 파급 효과가 큰 것들입니다. 우리는 더 깊은 비즈니스 맥락이나 탄탄한 데이터 모델링, 부서 간 조율이 필요한 일에 더 많은 시간을 씁니다.

이것이 우리의 목표였습니다. 단순한 분석은 셀프서비스가 더 많이 감당하게 하고, 데이터 팀은 비즈니스 임팩트를 내는 일에 집중하기 쉽게 만드는 것이었습니다.

맥락을 바라보는 방식

에이전트 경험은 맥락에 달려 있습니다.

우리 비즈니스와 데이터, 지표, 내부 프로세스를 명확하게 기술할수록 에이전트는 회사에 대한 질문에 더 잘 답할 수 있습니다. 맥락을 제공해야 에이전트가 원시 테이블 접근만으로도 유용한 분석을 만들어 낼 수 있습니다.

우리에게 맥락은 여러 곳에서 나옵니다. 각 레이어는 에이전트에게 서로 다른 종류의 정보를 제공합니다.

LangChain의 데이터 스택 아키텍처

데이터 모델을 정의하는 방법

dbt는 데이터 모델에 관한 맥락을 관리하는 주요 공간 중 하나입니다. 이 맥락은 SQL과 문서화된 정의 양쪽에 존재합니다.

모든 테이블과 컬럼은 그 데이터가 무엇을 나타내는지, 어떻게 사용해야 하는지, 어떤 엣지 케이스가 있는지 사람이 이해하는 데 도움이 되어야 합니다. 이 정의는 에이전트에게도 똑같이 도움이 됩니다.

빈약한 컬럼 정의는 이런 식입니다.

account_status: 계정의 상태.

기술적으로 틀린 말은 아니지만, 읽는 사람에게 알려 주는 것이 별로 없습니다.

더 나은 정의는 이렇습니다.

account_status: Salesforce 기준 계정의 현재 라이프사이클 상태. Active는 고객이 유효한 유료 계약을 보유 중이라는 뜻입니다. Churned는 과거에 유료 계약이 있었지만 종료되었다는 뜻입니다. Prospect는 아직 고객이 되지 않은 계정을 뜻합니다. 고객 리포팅에서는 이탈 고객이나 잠재 고객을 명시적으로 포함하는 분석이 아닌 한 Active로 필터링하세요.

이 정의는 에이전트에게 비즈니스 맥락, 허용 값, 해석 지침, 기본 필터링 규칙을 제공합니다. 또한 잘못된 비즈니스 해석에 기반한, 기술적으로만 맞는 답을 받게 될 가능성도 줄여 줍니다.

테이블 수준에도 같은 접근을 적용합니다. 좋은 테이블 정의는 그 테이블이 어떤 행 단위(grain)를 나타내는지, 어떤 종류의 질문에 답하도록 설계되었는지, 어디를 조심해야 하는지 설명해야 합니다.

시맨틱 모델은 지표와 관계를 정의합니다

시맨틱 모델은 지표, 그리고 모델 간의 관계에 대한 맥락을 에이전트에게 제공합니다.

ARR, 파이프라인, 활성 사용량, 고객 헬스처럼 사람들이 반복해서 묻는 지표 개념을 여기서 정의합니다. 시맨틱 레이어가 이 정의들을 일관되게 유지해 주기 때문에, 에이전트가 질문을 받을 때마다 지표 로직을 처음부터 추론할 필요가 없습니다.

시맨틱 모델은 탄탄한 데이터 모델링 위에 놓일 때 가장 유용합니다. 기반 모델이 불명확하거나 중복되거나 문서화가 부실하면 시맨틱 레이어가 할 수 있는 일에도 한계가 있습니다. 결국 기초가 여전히 중요하다는 것을 확인했습니다. 깔끔한 모델, 명확한 행 단위, 좋은 정의가 하류의 모든 레이어에서 더 높은 품질로 이어집니다.

비즈니스 맥락 담아내기

어떤 맥락은 테이블이나 지표 정의에 깔끔하게 들어맞지 않습니다.

더 넓은 공간이 필요한 회사 프로세스, 팀별 워크플로, 리포팅 관례, 비즈니스 규칙이 있습니다. 데이터 에이전트에게는 일종의 스킬 같은 것입니다. 우리는 이를 위해 Hex 워크스페이스 가이드를 사용합니다. 이 가이드는 비즈니스의 특정 영역, 특정 지표, 자주 쓰는 워크플로, 특정 데이터를 해석하는 방법에 대한 서면 지침을 에이전트에게 제공합니다. 가이드는 Hex로 바로 동기화되는 GitHub 저장소에서 관리합니다. 덕분에 버전을 관리하고 변경 사항을 리뷰하며, 이 맥락을 나머지 데이터 문서와 가까이 둘 수 있습니다.

가이드에는 이런 내용이 담길 수 있습니다.

• 주간 GTM 리포팅에서 파이프라인을 어떻게 정의하는지
• 특정 지표에 대해 어떤 대시보드를 표준으로 보는지
• 배포 유형별로 제품 사용량을 어떻게 해석해야 하는지
• 고객 헬스를 분석할 때 어떤 필터를 적용해야 하는지
• 어떤 질문을 검증을 위해 데이터 팀으로 넘겨야 하는지

이 레이어는 특히 유용했습니다. 모든 세부 사항을 모델이나 컬럼 설명에 욱여넣지 않고도 비즈니스 맥락을 일상 언어로 적을 수 있기 때문입니다.

보증은 무엇을 신뢰할지 에이전트에게 알려 줍니다

보증(endorsement)은 어떤 데이터 소스와 자산이 신뢰할 만한지 에이전트가 파악하도록 돕습니다.

예를 들어 ARR 대시보드가 보증되어 있으면, 에이전트는 ARR 질문에 답할 때 그 대시보드와 그 이면의 로직을 활용할 수 있습니다. 회사에는 같은 개념을 다루는 테이블, 대시보드, 과거 쿼리가 여러 개 있는 경우가 많기 때문에 보증은 중요한 신호입니다. 신뢰 신호가 없으면 에이전트는 관련 있어 보이지만 최선의 소스는 아닌 자산을 고를 수 있습니다.

보증이 의미를 유지하도록 가드레일도 두고 있습니다. 보증 표시는 데이터 팀만 할 수 있습니다. 보증된 대시보드는 변경 사항이 반영되기 전에 데이터 팀 리뷰도 거쳐야 합니다. 이런 리뷰 프로세스가 보증된 자산의 신뢰성을 지켜 줍니다. 모든 것이 보증되어 있다면 그 신호는 더 이상 쓸모가 없어집니다.

GitHub은 더 깊은 구현 맥락을 제공합니다

에이전트는 데이터 포인트가 어디서 어떻게 만들어지는지에 대한 더 깊은 맥락을 얻기 위해 dbt 저장소도 들여다볼 수 있습니다.

dbt 저장소를 통해 에이전트는 컬럼이나 지표를 처음부터 끝까지 정의하는 SQL과 로직에 접근할 수 있습니다. 표면적인 정의만으로는 부족한 질문일 때 유용합니다. 에이전트는 기반 모델 로직을 살펴보고, 조인과 변환을 이해하고, 필드가 어떻게 산출되는지 추적할 수 있습니다.

기술에 익숙한 사용자에게는 이 부분이 전체 구성에서 가장 중요한 요소 중 하나입니다. 에이전트가 비즈니스 수준 맥락과 구현 수준 맥락을 오갈 수 있어서 디버깅, 검증, 심층 분석에 한층 유용해집니다.

시스템을 개선하는 방법

맥락에는 피드백 루프가 필요합니다. 사람들이 에이전트를 어떻게 쓰는지, 에이전트가 어디서 더 도움이 필요한지 볼 방법이 필요했습니다. 관측성(observability) 도구가 여기에 도움이 됩니다. 우리는 Hex의 Context Studio를 활용하지만, 데이터 에이전트를 자체 구축한 팀이라면 LangSmith를 쓸 수 있습니다. 대화 주제의 추세, 자주 나오는 경고, 이슈, 맥락 공백을 살펴볼 수 있습니다. 이 데이터가 스택의 어느 부분을 개선할지 결정하는 데 도움이 됩니다.

사람들이 비슷한 질문을 계속 던진다면 더 나은 대시보드가 필요하다는 뜻일 수 있습니다. 에이전트가 특정 지표에서 반복해서 헤맨다면 시맨틱 모델 정의를 더 명확하게 다듬어야 할 수 있습니다. 내부 비즈니스 맥락이 필요한 질문이 들어온다면 워크스페이스 가이드가 필요할 수 있습니다. 에이전트가 엉뚱한 소스를 쓴다면 보증을 조정하거나 dbt 문서를 개선해야 할 수 있습니다.

이 루프는 데이터 활용 지원(data enablement)에 대한 우리의 관점을 바꿔 놓았습니다. 에이전트 대화가 회사가 무엇을 이해하려고 하는지 보여 주는 훌륭한 신호라는 것도 배웠습니다. 대화에서 패턴이 보이면 리포팅, 문서화, 모델링의 공백을 찾아낼 수 있습니다. 반복되는 일회성 질문보다 대시보드가 사람들에게 더 도움이 되는 지점도 알 수 있습니다.

피드백 루프는 이렇게 돌아갑니다.

1. 사용자가 Hex, Slack, CLI, MCP, LangSmith Fleet을 통해 질문합니다
2. 에이전트가 dbt 정의, 시맨틱 모델, 워크스페이스 가이드, 보증, 대시보드, GitHub 맥락을 활용합니다
3. 관측성 도구가 공백, 경고, 반복되는 주제를 드러냅니다
4. 데이터 팀이 패턴과 제안을 검토합니다
5. 데이터 팀이 모델, 정의, 가이드, 지표, 보증, 대시보드를 업데이트합니다
6. 에이전트의 응답이 시간이 지날수록 좋아집니다

다음 단계

이 워크플로는 아직 초기 단계이고 도구도 빠르게 변하고 있습니다. 앞으로 몇 달 동안은 몇 가지 개선에 집중할 계획입니다.

맥락 변경 평가하기

다음으로는 평가(evals)를 활용해, 맥락을 바꾼 것이 에이전트 응답을 실제로 개선하는지 파악하려고 합니다.

지금은 사용 패턴, 경고, 정성적 피드백을 볼 수 있습니다. 평가가 도입되면 변경을 더 구조적으로 테스트할 수 있습니다. 지표 정의를 수정하거나 가이드를 추가하거나 보증을 바꿨을 때, 그 결과로 에이전트가 더 나은 답을 내는지 알고 싶습니다.

이렇게 되면 맥락 관리가 소프트웨어 개발에 가까워집니다. 변경하고, 테스트하고, 충분히 확신을 쌓은 뒤에 널리 배포할 수 있습니다.

맥락 워크플로 개선하기

맥락 개선 제안을 둘러싼 프로세스도 더 많이 자동화하고 싶습니다.

관측성 덕분에 공백은 이미 찾을 수 있습니다. 다음 단계는 그 공백을 dbt 정의, 워크스페이스 가이드, 시맨틱 모델 업데이트, 보증 전반에 걸쳐 리뷰를 거친 변경으로 더 쉽게 전환하는 것입니다.

맥락 개선을 더 쉽게 추적하고 리뷰하고 배포할 방법을 찾고 있습니다.

계속 배우기

에이전트 워크플로는 빠르게 진화하고 있고, 무엇이 효과적인지, 어디에 가드레일이 필요한지, 제품이 어느 부분에서 개선되어야 하는지 우리도 여전히 배우는 중입니다.

맥락 검색, 신뢰 신호, 평가, 사용자 경험의 작은 개선이 사람들이 에이전트를 믿고 쓰느냐 마느냐에 큰 차이를 만들 수 있습니다.

배운 것들

지금까지의 여정에서 특히 두드러진 교훈 몇 가지가 있습니다.

탄탄한 데이터 모델링 기반이 모든 것을 쉽게 만듭니다

에이전트를 도입한다고 좋은 데이터 모델링이 필요 없어지는 것이 아닙니다. 오히려 좋은 데이터 모델링의 가치가 더 올라갑니다.

명확한 행 단위, 잘 지은 모델 이름, 일관된 정의, 믿을 수 있는 변환이 에이전트를 더 유용하게 만듭니다. 사람에게 헷갈리는 데이터 모델은 에이전트에게도 헷갈립니다.

좋은 맥락은 가장 파급 효과가 큰 투자 중 하나입니다

에이전트는 비즈니스를 이해할 때 더 잘 동작합니다. 명확한 정의를 쓰고, 회사 용어를 설명하고, 지표 로직을 문서화하고, 데이터를 어떻게 해석해야 하는지 지침을 주는 일이 여기에 해당합니다.

가장 좋은 맥락은 구체적입니다. 비즈니스가 어떻게 돌아가는지, 값이 실제로 무엇을 의미하는지, 어떤 필터가 기본인지, 그 데이터를 어디에 써야 하고 어디에 쓰면 안 되는지를 설명합니다.

시맨틱 모델은 튼튼한 기반 위에서 가장 잘 작동합니다

잘 정의된 시맨틱 모델은 특히 자주 쓰는 지표에 중요합니다. 하지만 그 효과는 기반 모델과 문서의 품질에 달려 있습니다.

이 작업을 시작한다면 기초부터 바로잡으세요. 그다음 시맨틱 레이어로 가장 중요한 지표들을 일관되게 만들고 에이전트가 쓰기 쉽게 만드세요.

가장 중요한 질문부터 시작하세요

첫날부터 모든 곳에 완벽한 맥락이 있어야 하는 것은 아닙니다.

사람들이 가장 자주 묻는 질문에서 시작하세요. 가장 자주 조회되는 모델을 파악하세요. 그 영역부터 깊게 파세요.

사람들이 묻는 질문의 약 80%를 커버할 수 있다면 대다수 사용자에게 훨씬 나은 경험을 줄 수 있습니다. 나머지 롱테일은 시간을 두고 처리해 나가면 됩니다.

셀프서비스에도 여전히 데이터 교육이 필요합니다

셀프서비스는 사용자가 시스템의 강점과 한계를 모두 이해할 때 가장 잘 작동합니다.

특히 답변이 중요한 의사결정에 쓰일 때는 에이전트 응답을 판단을 거쳐 받아들여야 한다는 점을 분명히 하고 있습니다. 검증이 필요한 질문에는 항상 데이터 팀원이 참여해야 합니다. 에이전트와 도구를 잘 쓰는 법을 배워 가면서 Slack에 주기적으로 리마인더와 모범 사례도 공유합니다.

모두를 데이터 전문가로 만드는 것이 목표는 아닙니다. 신뢰를 지키면서 사람들이 데이터에 더 잘 접근하게 하는 것이 목표입니다.

마치며

에이전트 우선 데이터 스택을 만드는 일은 결국 맥락을 명시적으로 만드는 일입니다.

에이전트는 데이터가 무엇을 의미하는지, 어떤 소스를 신뢰해야 하는지, 비즈니스가 어떻게 돌아가는지, 어떤 질문에 특별히 주의해야 하는지 알아야 합니다. 스택 전반에 걸쳐 이런 것들을 잘 기술할수록 에이전트도 좋아집니다.

우리에게 그것은 dbt 정의, 시맨틱 모델, 워크스페이스 가이드, 보증, GitHub 기반 맥락, 그리고 동작 관측을 통한 피드백 루프에 투자하는 것을 의미했습니다. 데이터 에이전트의 신뢰성은 데이터 주변에 쌓아 올린 맥락에서 나옵니다.

이 작업은 현재 진행형입니다. 평가, CLI 워크플로, 맥락 관리 도구가 발전하면 이 과정이 더 체계화될 것으로 기대합니다. 다만 한 가지는 이미 분명합니다. 데이터 팀은 모든 질문에 일일이 답하는 데 쓰는 시간을 줄이고, 회사 전체가 질문에 잘 답하도록 돕는 맥락과 모델, 신뢰 시스템을 설계하는 데 더 많은 시간을 쓰게 될 것입니다.