사내 데이터 분석에 에이전트를 붙이기 전에 정리할 요청 채널과 지표 정의: Grab 사례

김덕중 게시물 해석입니다. 김덕중 님은 2026년 10월 12일 LinkedIn에 Grab Engineering 블로그 글 "How AI is transforming analytics at Grab"을 소개하고 데이터 분석이 어떻게 달라지는지에 대한 의견을 올렸습니다. 원문은 2026년 10월 12일 게시입니다. 김덕중 님이 소개한 Grab 글은 2026년 8월 1일 게시된 글이라 이 글을 쓰는 10월 13일 기준으로 2개월 넘게 지났습니다. 이 글은 새 소식을 전하지 않고, Grab이 공개한 구조를 기준으로 사내 데이터 분석에 에이전트를 붙일 때 무엇부터 정리할지 살펴봅니다. 글에 나오는 Grab의 수치는 모두 Grab이 자체 발표한 값이고, 이 글을 쓰면서 Grab의 도구나 비슷한 에이전트를 직접 써 보지는 않았습니다.

1. 김덕중 님이 주목한 내용

김덕중 님은 AI가 데이터 분석을 자동화한다는 말을 처리 시간이 줄어든다는 뜻으로만 읽으면 부족하다고 봤습니다. 글 첫머리에서 "데이터 분석의 주체와 범위, 그리고 분석가의 역할 자체가 달라지고 있다는 점에 주목할 필요가 있다"고 썼습니다.

김덕중 님은 Grab 글의 수치를 옮긴 뒤 변화를 이렇게 정리했습니다. 분석을 요청하고 활용하는 사람이 분석 부서 밖으로 넓어지고, 분석 대상이 과거를 설명하는 데서 시나리오를 따져 의사결정을 돕는 쪽으로 넓어지며, 사람은 무엇을 분석할지 정하고 결과의 의미를 판단하는 일을 더 많이 맡게 된다는 해석입니다. Grab이 데이터와 업무 맥락을 관리하는 ContextIQ에 투자하는 이유도 AI가 비즈니스 맥락을 모르면 정교한 분석을 하고도 잘못된 결론에 이를 수 있기 때문일 것이라고 봤습니다. 이 해석과 전망은 김덕중 님의 의견입니다.

2. Grab이 발표한 수치를 읽을 때 확인할 것

수치를 인용하려면 Grab 글에서 각 수치의 기간과 대상을 함께 확인해야 합니다. 아래 표는 Grab 글 본문과 도표에서 확인한 내용입니다.

김덕중 님 글의 표현	Grab 글에서 확인한 내용	기간과 대상
평균 처리 시간 약 33% 단축	본문은 "cycle times reduced by ~33%"라고 쓰고, 도표는 티켓 해결까지 걸린 영업일의 중앙값을 3일에서 2일로 표시합니다. 75번째 백분위는 7일에서 6일, 90번째 백분위는 17일에서 14일입니다.	1분기와 2분기 비교. 처음 진행 중 상태로 바뀐 때부터 해결까지
반복적 업무 비중 44%에서 30%	분석가가 닫은 티켓 가운데 데이터 준비·알림·보고 같은 기계적 업무의 비중입니다.	본문은 2월과 6월 비교. 도표는 분석가 5명 팀의 1분기 49%, 2분기 39%
사람 개입 없는 데이터 추출 63%에서 90%, SQL 50%에서 81%	셀프서비스 에이전트를 연결한 Slack 채널에서 사람이 개입하지 않고 답한 비율입니다. 같은 기준으로 지표 질문은 53%에서 67%로 올랐습니다.	3월과 5월 비교
요청의 약 75%가 분석 부서 외부	같은 채널 스레드 가운데 4개 중 3개에 조금 못 미치는 수가 분석팀 밖의 사람이 시작했습니다. 85%는 1분 안에 첫 응답을 받았습니다.	같은 채널

위쪽 막대 그래프는 Grab 글 본문의 Slack 채널 수치이고, 아래쪽 카드는 처리 시간과 기계적 업무 비중의 측정 기간과 도표 값입니다. 모든 수치는 Grab 자체 발표입니다.

표를 보면 김덕중 님 글과 Grab 원문이 다른 부분이 있습니다. 김덕중 님은 "평균 처리 시간"이라고 썼지만, Grab 도표에 표시된 값은 평균이 아닌 중앙값과 백분위입니다. 중앙값 3일에서 2일로의 변화를 계산하면 약 33% 감소입니다. 기계적 업무 비중은 본문(2월 44%, 6월 30%)과 도표(1분기 49%, 2분기 39%)의 값이 다르고, 기간도 다릅니다. 도표에는 분석가 5명으로 이뤄진 팀 1곳의 결과라고 적혀 있습니다. 두 값의 관계는 Grab 글에 설명이 없어 이 글에서도 판단하지 않습니다.

Grab 글은 Monte라는 내부 앱도 소개합니다. 불확실한 입력값에 하나의 값 대신 범위를 주면 1만 개의 시나리오를 실행해 목표를 달성할 확률을 알려 주는 도구입니다. 김덕중 님은 이 도구를 분석 범위가 미래 의사결정으로 넓어지는 사례로 들었습니다.

3. Grab이 공개한 구조: 요청 채널, 라우터, 맥락 문서

사내 도입을 준비할 때는 수치보다 Grab이 공개한 구조를 참고하면 됩니다. Grab은 Spartan이라는 분석 에이전트 흐름을 Slack 같은 업무 도구에 붙였고, 사용량의 대부분이 분석가가 아닌 사람에게서 나온다고 밝혔습니다. 광고 영업 담당자가 특정 가맹점의 광고비를 나눠 보거나, 캠페인 담당자가 대상 고객 규모를 추정하거나, 국가 팀이 지난주 대비 숫자가 왜 움직였는지 묻는 요청이 모두 업무 언어로 들어옵니다.

위에서 아래로 요청 채널, 라우터, 두 처리 경로, 맥락 문서, 티켓 기록과 실패 반영 순서로 놓았습니다. 오른쪽 점선 화살표는 실패를 맥락 문서에 다시 반영하는 흐름입니다. 번호와 배치는 작성자가 Grab 글을 정리하며 구성했습니다.

Grab은 7월에 들어온 요청 2건으로 이 흐름을 설명했습니다. 필리핀 중간 시장 세그먼트의 매출이 6월 마지막 2주 동안 왜 줄었는지 묻는 질문은 라우터가 원인 분석 질문으로 읽고 진단 경로로 보냈습니다. 광고 도메인의 분석 프레임워크를 고른 뒤 인증된 지표를 기준으로 세그먼트, 시장, 캠페인 유형별로 나눠 무엇이 바뀌었는지 찾습니다. 광고 노출 빈도 제한 실험을 요약해 달라는 질문은 실험 경로로 갔습니다. 실험 플랫폼에 미리 계산된 스코어카드와 실험 메타데이터를 읽어 요약하고, 데이터 레이크는 조회하지 않았습니다. Grab은 이 라우팅 뒤에 스킬 50개 이상과 분석 프레임워크 120개 이상이 있다고 밝혔습니다.

맥락 문서에 대해서는 "Context sets an agent’s ceiling."이라고 썼습니다. 지표의 집계 단위, 제외 조건, 주의 사항을 모르는 에이전트는 추측으로 틀린 결과를 빠르고 대량으로 만든다는 설명입니다. 지표 정의에 대해서도 "Ambiguous definitions cause most analytics slop."이라고 적었습니다. Grab은 ContextIQ와 Context Lifecycle Manager를 만들어 맥락 문서를 한 번 쓰고 끝나는 문서가 아닌 계속 관리하는 대상으로 다룬다고 밝혔습니다. 운영 중에 에이전트 실패를 분류하면 그 실패의 원인이 된 맥락 문서를 고칩니다. 분석가 2명이 포장 수수료가 설정값으로 어떻게 저장되는지 에이전트로 찾은 사례에서는, 에이전트가 인증된 맥락 테이블 참조와 골든 데이터셋 테스트 사례를 함께 커밋하는 병합 요청을 열었고, 분석가가 오탐을 찾아내자 에이전트가 고쳐 다시 올렸다고 소개했습니다.

Grab은 에이전트가 맡는 범위를 단계로 나눠 설명하면서도 어느 단계에서든 사람이 판단한다고 밝혔습니다. 문제 정의, 공식 지표 정의, 숫자 변화의 인과 설명, 사업 계획의 가정, 진행 여부 결정, 이해관계자와의 관계는 사람이 맡습니다. 사람이 중간 검토 지점에서만 확인하는 단계에서는 이상치, 처음 다루는 범위, 민감한 데이터 구분이 나오면 사람에게 넘기도록 정해 둡니다.

4. 작성자 해석: 사내 데이터 분석에 에이전트를 붙이기 전에 정리할 순서

여기부터는 작성자의 해석입니다. Grab 사례에서는 수치를 측정할 수 있었던 조건을 눈여겨볼 만합니다. Grab 글에 따르면 셀프서비스 에이전트를 연결한 Slack 채널에서는 거의 모든 스레드가 팀 보드에 티켓으로 기록됩니다. 작성자는 이런 기록이 있어야 사람 개입 비율 같은 값을 기간별로 비교할 수 있다고 봅니다. 요청이 메신저 개인 대화, 메일, 회의 중 구두 요청으로 흩어져 있으면 에이전트를 붙인 뒤에도 무엇이 나아졌는지 비교할 수 없습니다.

그래서 사내에서 시작할 때는 아래 순서로 정리해 볼 수 있습니다.

1. 요청이 들어오는 채널을 하나로 정하고 모두 기록합니다. 사내 메신저의 분석 요청 채널 하나로 모으고, 요청마다 요청자 부서, 질문 유형, 처리 시간, 사람이 개입했는지를 남깁니다. 도입 전 몇 주 동안 먼저 기록해 두면 도입 후와 비교할 수 있습니다.
2. 자주 묻는 지표부터 정의 문서를 씁니다. 지표마다 집계 단위, 제외 조건, 주의 사항을 적습니다. 예를 들어 "월 매출"이 주문일 기준인지 결제일 기준인지, 취소·환불을 빼는지, 어느 날짜부터 계산 방식이 바뀌었는지를 적어 둡니다.
3. 질문 유형별 처리 경로를 나눕니다. 원인을 묻는 질문, 실험이나 캠페인 결과를 묻는 질문, 단순 추출 요청은 필요한 자료와 확인 방법이 다릅니다. 이미 계산된 보고서가 있는 질문은 원본 데이터를 다시 조회하지 않고 보고서를 읽게 하면 됩니다.
4. 사람에게 넘길 조건을 미리 적습니다. 개인정보가 들어가는 조회, 처음 다루는 데이터, 평소 범위를 크게 벗어난 숫자, 경영 보고에 들어갈 수치는 담당자가 확인한 뒤 전달하도록 정해 둡니다.
5. 틀린 답이 나오면 정의 문서와 테스트 질문에 반영합니다. 같은 질문에 같은 실수가 반복되지 않도록, 틀린 원인을 정의 문서에 고치고 그 질문과 정답을 테스트 목록에 추가합니다.

수치를 인용하거나 사내 성과를 보고할 때는 Grab이 공개한 방식처럼 비교 기간, 대상 팀, 평균인지 중앙값인지를 함께 적어야 합니다. Grab 수치를 사내 목표치로 그대로 가져오지 않는 편이 좋습니다. 기계적 업무 비중 도표는 분석가 5명 팀의 결과이고 사람 개입 비율은 Slack 채널 1곳의 결과이며, 회사마다 데이터 정리 상태와 요청 유형이 다르기 때문입니다.

5. 이 글에서 확인하지 못한 것

Grab 수치의 원자료와 표본 크기는 공개되지 않아 확인하지 못했습니다. 본문의 기계적 업무 비중(2월 44%, 6월 30%)과 도표 값(1분기 49%, 2분기 39%)이 같은 팀을 기준으로 한 것인지, 처리 시간 단축이 에이전트 도입 때문인지 다른 요인이 함께 작용했는지도 Grab 글에 설명이 없습니다. ContextIQ, Spartan, BriX, Monte는 Grab 내부 도구로 소개됐고 외부 제공 여부는 확인하지 못했습니다. 다른 회사에서 같은 구조로 비슷한 결과가 나오는지도 이 글에서 확인하지 않았습니다. 김덕중 님이 본 Grab 글의 수치 해석은 김덕중 님의 요약이며, 이 글에서는 Grab 원문과 다른 부분만 따로 적었습니다.

6. 이번 주에 해 볼 일

• 지난 2주 동안 받은 데이터 요청을 모아 요청자 부서와 질문 유형별로 나눠 봅니다.
• 가장 자주 나온 지표 1개를 골라 집계 단위, 제외 조건, 주의 사항을 한 쪽으로 적습니다.
• 에이전트에게 맡기기 전에 담당자가 반드시 확인해야 하는 조회 조건을 목록으로 적어 둡니다.