How LangChain Built an Agent-First Data Stack
Quick Summary
랭체인은 명확한 데이터 모델, 일관된 지표 정의, 업무 맥락, 신뢰 신호와 피드백 체계를 결합한 에이전트 우선 데이터 스택으로 전환해 데이터 셀프서비스 규모를 크게 확대했다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
랭체인은 명확한 데이터 모델, 일관된 지표 정의, 업무 맥락, 신뢰 신호와 피드백 체계를 결합한 에이전트 우선 데이터 스택으로 전환해 데이터 셀프서비스 규모를 크게 확대했다.
📌 핵심 요약
- 랭체인은 기존 비아이 도구 중심 구조를 대시보드, 노트북, 대화형 분석을 하나의 작업 공간에서 지원하는 에이전트 우선 데이터 스택으로 전환했다.
- 새 데이터 에이전트는 현재 3명인 데이터 팀이 직접 처리할 수 있는 요청량의 약 40배를 담당하며, 최근 30일 동안 약 2,200건의 대화가 이루어졌다.
- 회사는 6주 만에 기존 비아이 도구에서 완전히 이전했으며, 현재 전 직원이 어떤 형태로든 헥스 기반 데이터 스택을 사용한다.
- 에이전트에 필요한 맥락은 디비티 모델 설명, 시맨틱 모델의 지표와 관계, 업무 가이드, 승인된 자산, 깃허브의 구현 논리에서 제공된다.
- 데이터 팀의 역할은 반복적인 개별 질문에 답하는 업무에서 모델, 맥락, 가드레일과 피드백 순환 구조를 개선하는 업무로 이동했다.
🧩 주요 포인트
- 기존에는 거의 모든 데이터 요청이 소수의 데이터 팀을 거쳤지만, 통합된 대화형 셀프서비스 환경을 도입하면서 일반적인 분석의 첫 단계를 사용자가 직접 수행할 수 있게 됐다.
- 테이블 접근만으로는 신뢰할 수 있는 답을 만들기 어려웠기 때문에 모델 정의, 공통 지표, 업무 규칙과 승인 신호를 계층적으로 제공해 잘못된 해석과 출처 선택의 위험을 낮췄다.
- 사용 기록과 반복되는 오류·맥락 부족을 관찰함으로써 데이터 팀은 개별 답변 생산보다 재사용 가능한 모델과 문서, 대시보드, 통제 체계를 개선하는 데 더 집중하게 됐다.
🧠 상세 정리
1. 에이전트 우선 구조로 전환한 이유
랭체인은 대시보드, 보고서와 에스큐엘 작업 흐름을 중심으로 설계된 기존 데이터 스택이 에이전트 활용에는 충분하지 않다고 판단했다. 에이전트는 테이블에 접근해 기술적으로 유효한 쿼리를 만들 수 있지만, 회사 고유의 지표 정의와 업무 맥락을 모르면 잘못된 테이블을 선택하거나 질문의 실제 의도와 맞지 않는 답을 낼 수 있다. 따라서 데이터 접근성을 넓히는 것과 동시에, 에이전트가 어떤 정의와 출처를 사용했는지 설명할 수 있도록 만드는 것이 전환의 핵심 목표였다. 이를 위해 기존 비아이 도구 중심 구조에서 셀프서비스 분석, 공유된 맥락, 에이전트 사용을 함께 지원하는 구조로 크게 변경했다. 기존 대시보드와 에스큐엘의 용도를 없앤 것이 아니라, 에이전트가 정확하고 유용한 분석을 수행하는 데 필요한 추가 계층을 데이터 스택에 포함한 것이다.
2. 기존 데이터 요청 방식의 병목
이전에는 거의 모든 데이터 요청이 당시 한 명뿐이던 데이터 팀 담당자를 거쳐야 했다. 기존 비아이 도구는 미리 정의된 보고서에는 적합했지만, 탐색적 분석을 공동으로 진행하거나 공유하기 어려웠고 데이터가 비아이 계층에 미리 모델링되지 않으면 다른 직원이 직접 살펴보기도 어려웠다. 질문 하나에 답하려면 데이터 팀이 업무 질문을 데이터 문제로 번역하고, 적절한 모델을 찾고, 쿼리를 작성하거나 수정한 뒤 결과를 검증해 전달해야 했다. 그 결과 데이터 팀은 심층 분석, 모델링과 부서 간 프로젝트보다 일회성 요청 처리에 많은 시간을 사용했다. 새 구조에는 대시보드가 필요한 사용자, 노트북과 에스큐엘이 필요한 기술 사용자, 데이터 위치를 몰라도 안내받으며 질문하고 싶은 비기술 사용자를 동시에 수용하면서도 사용 맥락과 신뢰가 여러 시스템으로 분산되지 않도록 하나의 중심 작업 공간이 필요했다.
3. 도구 선정 기준과 헥스의 활용 방식
랭체인은 단순한 대시보드 대체재가 아니라 인공지능 기능과 에이전트 경험을 제품의 핵심 작업 흐름으로 다루는 도구를 찾았다. 기술 사용자와 엔지니어에게는 데이터 팀의 매번 도움을 기다리지 않고 반복적으로 분석을 개발할 수 있는 노트북 환경이 필요했고, 비기술 사용자에게는 업무 질문을 입력해 합리적인 첫 답을 받고 사용된 출처를 확인할 수 있는 공간이 필요했다. 대시보드, 노트북과 대화형 분석을 한곳에서 제공한다는 점을 바탕으로 헥스를 선택해 중앙 데이터 작업 공간으로 삼았다. 사용자는 헥스의 스레드와 노트북뿐 아니라 슬랙, 명령줄, 엠시피, 그리고 엠시피·명령줄 연동을 통한 랭스미스 플릿에서도 에이전트에 접근한다. 마케팅은 주간 파이프라인 분석, 제품 팀은 사용자 행동과 사용 추세, 영업과 배포 엔지니어링은 고객 상태와 사용량, 고객 엔지니어링은 이탈·확장·계정 추세 분석에 이를 활용하고 있다.
4. 이전 결과와 데이터 팀 역할의 변화
랭체인은 6주 만에 기존 비아이 도구에서 완전히 이전했으며, 현재 전 직원이 어떤 형태로든 헥스 기반 에이전트 우선 데이터 스택을 사용한다. 사용자 가운데 약 70%는 읽기 전용 권한을, 약 30%는 에이전트 권한을 보유하고 있으며 필요한 사람은 정보기술 부서를 통해 셀프서비스 방식으로 권한을 요청할 수 있다. 최근 30일에는 회사의 약 3분의 1에 해당하는 에이전트 권한 사용자 중 거의 전부가 에이전트를 사용했고, 약 2,200건의 대화와 사용자당 월평균 23건의 대화가 기록됐다. 에이전트가 담당하는 요청량은 현재 3명인 데이터 팀이 직접 처리할 수 있는 규모의 약 40배에 이른다. 데이터 팀이 업무에서 사라진 것은 아니며, 단순 질문의 첫 분석은 도구가 처리하고 데이터 팀은 더 깊은 업무 맥락, 강한 데이터 모델링, 엄밀한 검증과 부서 간 조율이 필요한 고부가가치 질문에 집중하게 됐다.
5. 디비티 모델과 명확한 데이터 정의
랭체인은 에이전트가 원시 테이블 접근을 실제 업무 분석으로 바꾸려면 데이터가 무엇을 나타내고 어떻게 사용되어야 하는지 설명하는 맥락이 필요하다고 본다. 디비티는 에스큐엘 논리와 문서화된 정의를 함께 관리하는 주요 장소이며, 각 테이블과 열에는 데이터의 의미, 적절한 사용법과 주의할 예외가 포함되어야 한다. 예를 들어 계정 상태를 단순히 계정의 상태라고 설명하는 것은 기술적으로 맞지만, 활성·이탈·잠재 고객의 실제 의미나 고객 보고 시 적용할 기본 필터를 알려주지 못한다. 더 강한 정의는 각 상태가 계약 생애주기에서 무엇을 뜻하는지 설명하고, 특별한 분석 목적이 없다면 활성 계정으로 필터링하라는 해석 지침까지 제공한다. 테이블 수준에서도 데이터의 관측 단위, 답변하도록 설계된 질문의 종류와 사용 시 주의점을 명시함으로써, 에이전트가 기술적으로 맞지만 업무적으로 틀린 결과를 만드는 가능성을 줄인다.
6. 시맨틱 모델과 기초 모델링의 중요성
시맨틱 모델은 에이전트에 지표의 정의와 데이터 모델 사이의 관계를 제공하는 계층이다. 랭체인은 연간 반복 매출, 파이프라인, 활성 사용량, 고객 상태처럼 여러 사용자가 반복해서 묻는 개념을 이 계층에서 정의해, 에이전트가 질문을 받을 때마다 지표 계산 논리를 처음부터 추론하지 않도록 했다. 공통 정의를 재사용하면 동일한 개념을 서로 다른 방식으로 계산하는 문제를 줄이고, 분석 결과의 일관성을 높일 수 있다. 다만 시맨틱 계층은 불명확하거나 중복되고 문서화가 부족한 기초 모델을 대신할 수 없다고 강조한다. 명확한 관측 단위, 정리된 모델과 충실한 정의가 먼저 갖춰져야 시맨틱 모델을 비롯한 모든 후속 계층에서도 더 높은 품질의 답변을 얻을 수 있다는 것이 랭체인의 경험이다.
7. 업무 가이드와 승인 신호를 통한 신뢰 관리
모든 업무 맥락을 테이블이나 지표 정의에 넣을 수 없기 때문에 랭체인은 헥스 작업 공간 가이드를 데이터 에이전트를 위한 별도의 지침 계층으로 사용한다. 이 가이드에는 주간 시장진출 보고에서 파이프라인을 정의하는 방식, 특정 지표의 기준 대시보드, 배포 유형별 제품 사용량 해석법, 고객 상태 분석에 필요한 필터와 데이터 팀 검증으로 넘겨야 하는 조건 등이 평문으로 기록된다. 가이드는 깃허브 저장소에서 관리해 변경 이력을 남기고 검토할 수 있으며, 헥스로 직접 동기화된다. 이와 별도로 승인은 여러 테이블과 대시보드 중 어떤 자산을 신뢰해야 하는지 에이전트에 알려주는 신호로 사용된다. 승인 권한은 데이터 팀에만 있고 승인된 대시보드의 변경도 데이터 팀 검토를 거치며, 모든 자산을 무분별하게 승인하면 신호의 의미가 사라지므로 제한적인 통제를 유지한다.
8. 구현 맥락과 관찰 기반의 지속적 개선
에이전트는 디비티 깃허브 저장소를 살펴보며 특정 데이터가 처음부터 끝까지 어떻게 만들어지는지 더 깊게 확인할 수 있다. 표면적인 열 설명만으로 부족한 질문에서는 실제 에스큐엘과 모델 논리를 통해 조인, 변환과 필드 생성 과정을 추적할 수 있으며, 이는 기술 사용자의 디버깅과 검증, 심층 분석에 특히 중요하다. 이 구조는 업무 수준의 설명과 구현 수준의 근거를 하나의 분석 흐름에서 오갈 수 있게 한다. 랭체인은 맥락도 피드백 순환 구조가 필요하다고 보고 헥스의 컨텍스트 스튜디오를 사용해 대화 주제의 추세, 반복되는 경고와 문제, 부족한 맥락을 관찰하며 자체 구축한 데이터 에이전트에는 랭스미스도 사용할 수 있다고 설명한다. 사람들이 비슷한 질문을 계속하면 더 나은 대시보드가 필요한지 검토하는 식으로 사용 기록을 스택 개선의 근거로 삼고 있으며, 원문은 특정 지표에서 반복적으로 어려움을 겪는 경우를 언급하기 시작한 지점에서 끝난다.
🧾 핵심 주장 / 시사점
- 셀프서비스 확대의 핵심은 에이전트에 테이블과 쿼리 권한만 주는 것이 아니라, 회사 고유의 정의와 기본 해석 규칙, 신뢰할 출처를 함께 제공하는 데 있다.
- 하나의 중앙 작업 공간을 유지하면서 헥스, 슬랙, 명령줄과 엠시피 등 여러 접근 경로를 제공한 방식은 사용 맥락과 신뢰를 분산시키지 않으면서 각 직군의 기존 작업 환경을 지원한다.
- 권한 요청은 셀프서비스로 열어 두되 승인 자산의 지정과 변경은 데이터 팀이 검토하게 함으로써 접근 규모 확대와 데이터 신뢰 관리를 함께 수행한다.
✅ 액션 아이템
- 랭체인의 에이전트 우선 데이터 스택처럼 대시보드·노트북·대화형 분석을 한 작업 공간에 묶는 범위를 정의한다.
- 디비티 모델 설명과 시맨틱 모델의 공통 지표·관계를 계층적으로 정리해 승인된 자산 기준을 점검한다.
- 데이터 팀이 반복적인 개별 질문 대응 대신 가드레일과 피드백 순환 구조를 개선하는 우선순위를 정한다.
❓ 열린 질문
- 데이터 에이전트가 3명 데이터 팀 대비 약 40배 요청량을 감당할 때 셀프서비스 품질 기준은 무엇인가?
- 6주 만의 비아이 도구 이전과 전 직원의 헥스 기반 데이터 스택 사용을 성공으로 볼 임계치는 어떻게 판단할 것인가?
- 최근 30일 약 2,200건 대화에서 반복되는 오류·맥락 부족을 보고 어떤 재사용 가능 모델·문서를 먼저 고칠 것인가?