Tech
화해의 AI 에이전트 ‘다해’: 데이터 기반 의사결정을 함께하는 AI 동료 만들기
2026. 03. 18
화해글로벌 ㅣ 화해를 운영하는 기업, 화해팀
안녕하세요, 데이터전략팀의 Data Analytics Engineer 김진석입니다.
슬랙에서 @다해 어제 DAU가 갑자기 늘게 된 원인이 뭐야? 라고 물어보면,
DataHub에서 테이블과 스키마를 파악한 뒤 BigQuery 쿼리를 생성·실행하여 답변하는 AI 데이터 분석봇.
데이터전략팀의 든든한 지원군 ‘다해’는 어떻게 탄생했을까요?”
/
1. 다해는 왜 만들어졌을까
1-1. 데이터팀의 오래된 숙제, Ad-hoc 요청
화해에서 이런 질문은 꽤 자주 들려옵니다. 질문 자체는 단순해 보이지만, 실제로 답변하기까지의 과정은 결코 간단하지 않아요. 질문의 맥락을 파악하고, 적절한 테이블과 스키마를 확인한 뒤, 쿼리를 작성하고 결과를 검증한 후, 동료가 이해하기 쉬운 형태로 정리해서 전달해야 하니까요. 시맨틱 일관성을 위해 데이터 엔지니어나 데이터 애널리틱스 엔지니어와 추가 소통이 필요한 경우도 적지 않습니다.
이 과정에서 두 가지 문제가 반복적으로 발생했습니다.
첫째, 업무 병목입니다. 단순 데이터 조회가 데이터 분석가의 업무 시간을 잠식하면서, 비즈니스 성장을 위한 핵심 분석에 집중할 여유가 줄어들었어요. 답변을 기다리는 동료 입장에서는 의사결정이 지연되기도 하고, 데이터 기반 의사결정에 대한 기대치도 자연스럽게 낮아질 수밖에 없었습니다.
둘째, 접근성입니다. SQL에 익숙하지 않은 동료들은 미리 만들어둔 대시보드에만 의존해야 했습니다. 대시보드가 아무리 잘 설계되어 있어도, 사전에 정의되지 않은 질문에 대한 답은 결국 Ad-hoc 데이터 요청을 통해서만 얻을 수 있었습니다. 요청 맥락을 전달하고 답변을 받기까지 며칠이 소요되는 일이 반복되면서, 데이터 기반 의사결정의 민첩성은 점점 떨어지고 있었습니다.
1-2. 이미 준비되어 있던 AI-ready 데이터 환경
이러한 문제를 인식하고 있던 중, Claude Desktop에 DataHub MCP와 BigQuery MCP를 연동하여 테스트해볼 기회가 있었습니다. 단순한 자연어 질문만으로도 놀라울 정도로 정확한 쿼리를 생성하고 실행하는 모습을 확인할 수 있었는데요. 주니어 데이터 분석가가 처리하는 Ad-hoc 요청 수준은 충분히 수행할 수 있을 정도의 답변 품질이었습니다.
그런데 이 결과가 단순히 Claude AI 모델의 성능 덕분만은 아니었습니다. 화해의 데이터 환경은 이미 수년간 DataHub을 운영하며 모든 테이블과 칼럼의 정의를 체계적으로 카탈로그해왔고, 데이터 웨어하우스 내의 네이밍 컨벤션 역시 명확한 규칙으로 설계되어 있었습니다. 분석에 자주 쓰이는 지표들은 Aggregate이 완료된 Metrics Store 형태로 정리되어 있었고요.
만약 네이밍 컨벤션도 부실하고 카탈로그도 없었다면, 아무리 뛰어난 AI 모델을 활용하더라도 적절한 테이블과 칼럼을 찾기 어려워 좋은 답변 품질을 기대하기 어려웠을 것입니다. 그동안 데이터 카탈로그와 애널리틱스 엔지니어링에 공들인 시간이 AI Agent를 빠르게 도입할 수 있는 AI-ready Data 기반이 된 셈입니다.
/
2. 우리가 해결하려 했던 문제
Claude Desktop에서 가능성을 확인한 후, 자연스럽게 다음 질문으로 이어졌습니다.
별도의 앱 설치나 새로운 인터페이스 학습 없이, 슬랙에서 <span data-token-index="3" spellcheck="false" class="notion-enable-hover">@다해</span>로 멘션하면 AI가 알아서 테이블을 찾고, 쿼리를 만들어 실행한 뒤, 결과를 정리해서 답변해주는 환경. 이것이 현실화 된다면 데이터전략팀은 더 가치 있는 업무에 집중할 수 있고, 동료들의 데이터 접근성도 극적으로 높아질 수 있겠다고 생각했어요.
해결하고자 한 핵심 문제는 명확했습니다.
- 데이터 분석가의 반복적인 Ad-hoc 처리 업무를 줄이고, 고차원적인 분석에 집중할 수 있도록 하는 것
- SQL을 모르는 동료도 자연어만으로 데이터에 접근할 수 있게 하는 것
- 데이터 기반 의사결정의 속도를 “며칠”에서 “몇 분”으로 앞당기는 것
그렇게 “다해” 프로젝트가 시작되었습니다.
“다해”는 데이터(DAta) + 화해(HwaHAE)의 합성어로, 데이터 분석을 “다 해”준다는 의미를 담았습니다. 화해의 데이터전략팀이 함께 일하는 든든한 AI 동료를 만들겠다는 목표로 출발한 프로젝트였습니다.
/
3. 해결을 위한 접근 방식
3-1. 왜 Slack AI Agent 형태였을까
다해의 형태를 결정할 때, 가장 중요하게 고려한 것은 진입장벽이었습니다. 아무리 좋은 도구를 만들어도 동료들이 실제로 사용하지 않으면 의미가 없으니까요. 별도의 웹 앱이나 대시보드를 만드는 대신, 이미 모든 구성원이 매일 사용하고 있는 슬랙을 선택한 이유였습니다. 새로운 인터페이스를 배울 필요 없이, 동료에게 말을 거는 것처럼 <span data-token-index="3" spellcheck="false" class="notion-enable-hover">@다해</span>를 멘션하면 되는 경험을 만들고 싶었어요.
3-2. 핵심 설계 원칙: DataHub First
기술적 방향을 잡을 때 세운 가장 중요한 원칙은 DataHub First였습니다. AI가 BigQuery 쿼리를 바로 작성·실행하는 것이 아니라, 반드시 DataHub에서 메타데이터를 먼저 확인한 뒤에 쿼리를 작성하도록 설계한 것입니다.
실제로 초기 프로토타입에서 BigQuery Tools만 제공했을 때 심각한 문제가 있었습니다. 예를 들어 사용자가 매출 관련 질문을 하면, AI가 sales라는 이름의 테이블을 찾으려고 시도하는 할루시네이션이 빈번했거든요. 실제로는 revenue라는 이름의 테이블이 적절했는데도 말이죠. DataHub을 통해 SSOT(Single Source of Truth)를 먼저 확인하도록 강제하자, 이 문제가 극적으로 개선되었습니다.
3-3. 기술 스택 선택
다해의 핵심 엔진은 Claude의 Tool Use 기능입니다. 사용자의 질문을 Claude가 분석하여 필요한 도구를 스스로 선택·조합하며, 이 과정을 반복하면서 최종 답변을 생성합니다.
/
4. 개발 과정
/
4-1. Tool Use 기반의 Agentic Workflow 구현
다해에는 총 10개의 도구(Tools)가 탑재되어 있어요. DataHub 탐색을 위한 6개의 도구와, 실제 데이터를 조회하기 위한 BigQuery 4개 도구로 구성됩니다.
Claude API의 Tool Use는 “한 번 호출하면 끝”이 아닙니다. Claude가 도구를 호출하면 그 결과를 다시 Claude에게 전달하고, Claude가 다음 행동을 결정하는 루프가 반복됩니다. 실제로 복잡한 질문의 경우 최소 10번 이상의 Tool Use를 거치기도 했어요.
예를 들어, 매출 상위 카테고리별 추이 보여줘라는 질문에 대해 다해는 다음과 같은 과정을 자동으로 수행합니다.
/
4-2. 시행착오 ① — 할루시네이션과의 싸움
개발 초기에 마주한 가장 큰 벽은 할루시네이션이었습니다.
처음에는 BigQuery 도구만 제공하면 AI가 “알아서 잘 하겠지”라고 기대했지만, 현실은 달랐습니다. 존재하지 않는 테이블명을 생성하거나, 실제 스키마와 다른 칼럼명을 사용하는 문제가 지속적으로 발생했거든요. 앞서 언급한 sales vs. revenue 사례가 대표적이었는데, 이는 AI가 일반적인 언어 지식에 기반해 테이블명을 “추측”했기 때문입니다.
이 문제를 극복하기 위해 시스템 프롬프트에 DataHub First 원칙을 강제하는 워크플로우를 명시했습니다. “BigQuery 쿼리를 실행하기 전에 반드시 DataHub에서 테이블 정보를 먼저 확인하세요”라는 지시를 프롬프트 최상단에 배치한 것이죠. 이후 할루시네이션 문제가 극적으로 줄어들었고, AI가 실제로 존재하는 테이블과 칼럼만을 사용하여 쿼리를 작성하게 되었습니다.
/
4-3. 시행착오 ② — Flag 칼럼의 함정
할루시네이션을 해결한 뒤에도 또 다른 문제가 나타났습니다. 쿼리 결과가 비정상적으로 적게 나오는 경우가 있었던 것인데요. 원인을 추적해보니, YN이나 <span style="color: #ff0000; background-color: #f2f2f2;">Flag</span> 관련 칼럼의 필터 조건을 잘못 작성하는 패턴이 반복되고 있었습니다. 예를 들어, 실제 데이터에서는 flag_column = false가 올바른 조건인데, Claude가 flag_column is null로 작성하여 대부분의 데이터가 제외되는 상황이었습니다.
이를 해결하기 위해 시스템 프롬프트에 “이상 징후 탐지” 지침을 추가했습니다. 쿼리 결과가 예상보다 현저히 적거나, Flag 칼럼 필터링 후 결과가 극소수인 경우, Claude가 먼저 해당 칼럼의 값 분포를 확인하는 검증 쿼리를 추가 실행하도록 한 것입니다.
이 지침을 추가한 후, Claude가 스스로 “결과가 너무 적네요. 값 분포를 먼저 확인해보겠습니다”라며 검증 쿼리를 추가 실행하는 모습을 관찰할 수 있었습니다. 이처럼 Markdown 형태의 프롬프트가 곧 아키텍처라는 사실을 체감했는데요. 워크플로우를 코드로 직접 작성하는 대신 프롬프트로 지시하니, Claude가 상황에 따라 유연하게 판단하면서도 핵심 원칙은 지키는 균형을 찾을 수 있었던 것입니다.
/
4-4. 시행착오 ③ — Slack의 3초 타임아웃
기능적으로 안정화된 후, 배포 과정에서 또 하나의 벽을 만났습니다. Slack API는 요청을 보낸 후 3초 안에 응답을 받지 못하면 Timeout Error를 발생시키는데요. 그런데 다해는 Claude API 호출 + DataHub 탐색 + BigQuery 쿼리 실행 워크플로우의 반복이라는 측면에서 최소 30초 이상이 소요될 수밖에 없었던 것이죠.
이 문제를 해결하기 위해, Slack Bolt의 이벤트 핸들러에서 ack()를 즉시 호출하여 먼저 200 응답을 보내고, 실제 처리는 백그라운드에서 수행하는 비동기 패턴을 적용했습니다.
여기에 더해, 사용자가 답변을 기다리는 수십 초 동안 답답함을 느끼지 않도록 실시간 진행 상황 표시 기능도 구현했습니다. Claude가 도구를 호출할 때마다 슬랙 메시지를 업데이트하여, “🔍 DataHub에서 ‘매출’ 관련 테이블 검색 중…”, “📊 BigQuery 쿼리 실행 중…”과 같이 다해가 지금 무엇을 하고 있는지 실시간으로 보여주도록 한 것입니다.
/
4-5. 보안: 다층 방어 체계
NL2SQL 시스템은 본질적으로 SQL 인젝션 위험을 안고 있습니다. 가령, 사용자가 악의적으로 “모든 테이블을 DROP 해줘”라고 요청하는 프롬프트 인젝션 시나리오에 대비해야 했습니다.
이를 위해 다층 방어 체계를 구축했어요. 쿼리 실행 전 SQL을 파싱하여 오로지 SELECT 문만 허용하도록 필터링하고, DDL·DML·DCL 등 데이터를 변경하는 모든 구문을 차단했습니다. 또한 모든 요청은 슬랙을 통해서만 수신하되, Slack의 signing_secret 서명 기반 검증을 통해 인증 레이어를 구현하여, 외부에서의 직접 API 호출을 원천적으로 차단했습니다.
/
4-6. 비용 관리: BigQuery 과금 폭탄 방지
BigQuery는 스캔한 데이터량에 비례하여 과금되기 때문에, AI가 자유롭게 쿼리를 실행하도록 방치하면 비용이 기하급수적으로 늘어날 위험이 있었습니다.
이를 관리하기 위해 BigQuery의 dry run 기능을 활용하여 쿼리를 실행하기 전 예상 스캔량을 먼저 확인하는 도구를 추가했습니다. 단일 쿼리당 스캔량 제한과 사용자당 일일 쿼리 횟수 제한을 함께 적용하여, 비용이 통제 가능한 범위 내에서 운영될 수 있도록 설계했습니다. Claude API 토큰 사용량 역시 별도로 제한을 두었습니다.
/
4-7. 배포와 운영 인프라
화해의 데이터 파이프라인은 GCP 환경에서 운영하고 있었기 때문에, 다해 역시 GCP 환경 위에서 Cloud Build를 통해 CI/CD 파이프라인을 구성하고, Cloud Run으로 서빙하도록 개발했습니다.
이 과정에서 몇 가지 운영상의 포인트가 있었는데요. Cloud Run은 기본적으로 HTTP 응답 후 CPU를 제한하지만, Slack ack() 이후에도 백그라운드에서 Claude API를 반복적으로 호출해야 하므로 --no-cpu-throttling 옵션을 적용했습니다. 또한 DataHub이 사내 네트워크에 위치해 있어 Cloud Run에서 Private IP로 접근하기 위한 VPC Connector 설정이 필요했고, Slack API 토큰, Claude API 키, DataHub PAT 등 민감 정보는 Secret Manager를 통해 안전하게 관리하도록 했습니다.
/
5. 실제 조직에서의 활용 및 다해가 만든 변화
5-1. 다해는 현재 어떻게 쓰이고 있을까
다해는 현재 화해의 전사 구성원이 슬랙에서 자유롭게 사용하고 있습니다. 데이터전략팀 뿐만 아니라 임원진 분들을 비롯하여 각 스쿼드, 마케팅팀, 커머스팀, 사업팀, 운영혁신팀 등 다양한 동료들이 일상적인 데이터 질문에 다해를 활용하고 있어요.
대표적인 활용 사례를 살펴보면 다음과 같습니다.
- 일상적인 KPI 확인: “어제 DAU 얼마였어?”, “이번 주 신규 가입자 수 알려줘”와 같은 일상적인 지표 확인을 다해에게 물어보는 것이 자연스러운 문화가 되었습니다. 기존에는 대시보드를 열어 확인하거나 데이터전략팀에 요청해야 했던 작업을 슬랙 한 줄로 해결할 수 있게 된 것입니다.
- 원인 분석 요청: “어제 DAU가 갑자기 늘게 된 원인이 뭐야?” 처럼, 단순 수치 확인을 넘어 원인까지 파악하는 분석을 요청하는 사례도 빈번했어요. 이는 다해가 잘 해내는 영역이기도 한데요. 다해가 관련 데이터를 다각도로 반복 조회하여 가능한 원인을 좁혀주면, 이를 출발점으로 더 깊은 분석이 이어지는 형태입니다.
- 비정기적 데이터 조회: “지난 달 특정 프로모션에 참여한 사용자 수”, “최근 3개월 카테고리별 매출 추이” 처럼 대시보드에 미처 설정되지 않은 다양한 질문들도 다해를 통해 바로 확인할 수 있게 되었습니다.
/
5-2. 다해가 만든 변화
- 업무 시간 절감: 기존에 데이터 요청 → 맥락 파악 → 쿼리 작성 → 결과 전달 까지 수 시간에서 며칠이 걸리던 과정이, 슬랙에서 몇 분 이내로 단축되었습니다. 데이터전략팀의 데이터 분석가는 단순 Ad-hoc 처리에 쏟던 시간을 줄이고, 더 가치 있는 분석 업무에 집중할 수 있게 된 것이 가장 큰 변화예요.
- 데이터 접근성 개선: SQL을 모르는 동료들도 자연어만으로 데이터에 접근할 수 있게 되면서, 데이터 활용의 범위가 넓어졌습니다. 더 이상 데이터 요청을 위해 별도의 티켓을 생성하거나 미팅을 잡을 필요 없이, 궁금한 것이 생기면 슬랙에서 바로 물어볼 수 있는 환경이 만들어졌습니다.
- 의사결정 속도 향상: 데이터 기반 의사결정의 속도가 빨라졌습니다. 회의 중 “이 수치 한 번 확인해볼까요?”라는 말이 나오면, 그 자리에서 다해에게 물어보고 바로 답을 얻을 수 있게 된 것이에요. 데이터를 확인하기 위해 회의를 중단하거나 다음 회의로 미루는 일이 줄어들었습니다.
- 피드백 기반 지속 개선: 모든 답변에 1~5점 척도의 피드백 버튼을 붙여, 어떤 유형의 질문에서 만족도가 낮은지, 그리고 어떤 테이블을 사용할 때 품질이 떨어지는지를 지속적으로 추적하고 있습니다. 이 피드백은 다해의 시스템 프롬프트를 개선하는 것뿐만 아니라, 카탈로그와 데이터 마트의 품질 관리 우선순위를 정하는 데에도 큰 도움이 되고 있습니다. 임팩트에 집중한 데이터 애널리틱스 엔지니어링 업무가 이루어질 수 있는 셈이죠.
/
5-3. 앞으로의 여정
다해를 만들었다고 해서 임무가 끝난 것은 아니에요. 화해에서 더 좋은 AI 동료로 성장시키기 위한 다음 단계를 준비하고 있습니다.
- 시각화 기능: 텍스트 기반 답변을 넘어, 차트나 리포트 등을 이미지나 HTML 포맷으로 생성하여 슬랙에 첨부하는 기능
- 이벤트 정의서 연동: Firebase 이벤트 데이터에 대한 분석 품질을 높이기 위해, 구글 시트 기반의 이벤트 정의서를 BigQuery External Table로 연동하여 시스템 프롬프트에서 조건부 참조하도록 확장
- 파일 추출 기능: 대량 데이터가 필요한 리포팅 요청 시, 쿼리 결과를 CSV 파일로 추출하여 슬랙에 첨부해주는 기능
- 다양한 워크플로우 기능: NL2SQL 영역의 워크플로우를 넘어, 각 동료들이 실제 업무에 필요한 다양한 액션들까지 자동으로 수행할 수 있도록 확장
/
6. 마치며
다해 프로젝트를 진행하여 기술적으로 가장 크게 배운 점은 “NL2SQL AI Agent의 품질은 AI 모델의 성능이 아니라, 기반 데이터 인프라의 품질에 의존한다”는 사실입니다. 화해의 경우, 잘 정돈된 데이터 카탈로그, 명확한 네이밍 컨벤션, 체계적인 데이터 마트가 있었기 때문에 DataHub First 전략이 효과를 발휘할 수 있었거든요. AI-ready Data란 결국 “잘 만든 카탈로그”를 포함하는 개념이며, 그것이 NL2SQL Agent 품질의 핵심 자산이라는 것을 체감했습니다.
–
다해 프로젝트의 Repository는 전체 코드가 2,000줄도 되지 않지만, DataHub 메타 데이터 활용부터 SQL 인젝션 방지, 비용 관리, 실시간 UX, 피드백 수집까지 실제 프로덕션에 필요한 기본적인 요소를 모두 갖추고 있습니다. 개발 과정에서 할루시네이션, Flag 칼럼 필터링 오류, Slack Timeout 등 크고 작은 문제들을 마주했지만, 하나하나 원인을 분석하고 해결책을 찾아나가면서 성장할 수 있었습니다.
–
다해를 기반으로, 화해의 모든 동료들이 데이터에 더 쉽고 빠르게 접근하여 더 중요한 임팩트에 집중할 수 있으면 좋겠어요. 데이터 기반 의사결정의 속도와 질을 한 단계 높여, 뷰티 시장에서 새로운 혁신을 만들어가는 여정을 함께 하기 위해서요.
–
이 글이 마음에 드셨다면 다른 콘텐츠도 확인해 보세요!
