MCP로 연결된 AI 에이전트로 배부 추적하기

Model Context Protocol(MCP)로 AI 에이전트를 워크스페이스에 연결하고 나면, 일상적인 말로 배부 단계를 거치는 비용을 추적해 달라고 요청할 수 있습니다. 보고서를 실행하거나 SQL을 작성할 필요 없이 질문만 하면, 에이전트가 PlaidCloud의 배부 추적 도구를 호출하여 모델을 찾고, 변화를 설명하고, 흐름을 따라가고, 가정 질문에 답합니다.

채팅 에이전트(Claude Desktop, ChatGPT)든 코딩 에이전트(Claude Code, Cursor)든 모두 MCP 서버를 통해 같은 도구에 접근하므로, MCP로 연결된 모든 클라이언트에서 사용할 수 있습니다.

사전 요구 사항

배부 단계(allocation_split, allocation_rules, allocation_dim)가 있는 프로젝트
MCP로 워크스페이스에 연결된 AI 에이전트 — AI 코딩 에이전트 시작하기를 참조하십시오.

질문할 수 있는 내용

에이전트에게 …	수행하는 작업	사용되는 도구
“이 프로젝트에는 어떤 배부 모델이 있나요?”	각 모델과 그 단계, 생성하는 결과 테이블을 나열합니다	`allocation_model_find`
“`cost_line_rev`는 어떻게 계산되나요?”	분할되는 비용 풀, 분할에 쓰이는 배부 동인, 대상 테이블을 보여 줍니다	`allocation_describe`
“`cost_line_rev`가 2025년에서 2026년으로 왜 바뀌었나요?”	두 기간을 비교하여 변화를 풀 규모와 배부 동인 구성으로 나누어 설명하고, 가장 크게 기여한 계정을 보여 줍니다	`allocation_root_cause`
“`cost_line_rev`에는 무엇이 입력되나요?”	배부 동인, 소스 풀, 가져오기 등 상위 흐름을 따라갑니다	`allocation_lineage`
“`revenue_by_line`은 어디에서 배부 동인으로 쓰이나요?”	해당 테이블로 분할하는 모든 배부를 나열합니다	`allocation_driver_usage`
“미국 매출이 100만 달러 늘면 어떻게 되나요?”	영향을 받는 각 결과에 풀에서 차지하는 현재 비중에 따라 변화를 나누어 줍니다. 테이블별 최악의 경우가 아니라 팬아웃 전체에 걸쳐 합산됩니다	`allocation_forward_impact`
“조립 비용 센터의 인원 배부 동인이 10 늘면 어떻게 되나요?”	새 배부 동인 가중치로 고정된 풀을 다시 나누어, 어떤 대상이 늘고 어떤 대상이 줄어드는지 보여 줍니다. 결과 테이블을 둘 이상의 단계가 기록하는 경우에는 배부 자체의 풀이 아닌 풀을 다시 나누지 않도록 답변을 거부하며, 배부 동인이 모델의 마지막 실행에서 이루어진 분할과 더 이상 일치하지 않는 경우에도 거부합니다	`allocation_driver_scenario`

활용 예시

재무 분석가가 매출 기반 비용 항목이 전년 대비 줄어든 것을 발견하고 질문 하나를 합니다. 에이전트는 내부적으로 여러 배부 도구를 호출하여 처음부터 끝까지 답변합니다.

질문: 매출 기반 비용 배부(cost_line_rev)가 2025년에 비해 2026년에 줄어든 것 같습니다. 무슨 일이 있었고, 무엇으로 구성되어 있으며, 미국 매출이 100만 달러 변동하면 어떻게 되나요?

에이전트의 답변:

개요. cost_line_rev는 활동 기준 원가 계산(ABC) 모델에서 매출 기반 단계입니다. 비용 풀(group_amount, 일부 손익계산서 계정으로 제한)을 가져와 revenue_by_line의 매출을 기준으로 엔터티, 연도, 월 단위로 가중하여 분할합니다.

감소 이유(미국, 2025 → 2026). 미국에 배부된 비용은 712만 달러에서 299만 달러로 413만 달러 감소(−58.0%) 했습니다. 이는 구성 변화가 아닙니다. 미국이 풀에서 차지하는 비중은 두 해 모두 약 23%로 일정했습니다. 원인은 전체 비용 풀의 축소이며, 몇몇 계정에 집중되어 있습니다.

계정 2025 2026 변화

700000 $2.58M $1.09M −$1.49M

701000 $1.85M $0.77M −$1.08M

610000 $1.71M $0.72M −$0.99M

670000 $0.68M $0.29M −$0.39M

702000 $0.30M $0.13M −$0.18M

이 다섯 개 계정이 변화의 거의 전부를 설명합니다.

입력. cost_line_rev는 revenue_by_line(분할 배부 동인)과 gl_pool_entity(비용 풀)로 구성됩니다.

참고 — 이 배부 동인은 공유됩니다. revenue_by_line은 cost_line_cs와 cost_line_admin에도 쓰이므로, 매출을 수정하면 세 곳 모두에 영향이 갑니다.

미국 +100만 달러 시나리오. 100만 달러는 이 배부 동인을 공유하는 결과들에 각 결과가 풀에서 차지하는 현재 비중에 따라 나뉩니다. 따라서 테이블별 추정치는 각각 100만 달러 전체를 반복하는 것이 아니라 변화량에 합산되며, cost_line_rev, cost_line_cs, cost_line_admin에 대한 수치를 얻어 합계를 낼 수 있습니다. 질문을 단일 대상으로 좁히면 추정치는 해당 부분에만 적용됩니다.

계정	2025	2026	변화
700000	$2.58M	$1.09M	−$1.49M
701000	$1.85M	$0.77M	−$1.08M
610000	$1.71M	$0.72M	−$0.99M
670000	$0.68M	$0.29M	−$0.39M
702000	$0.30M	$0.13M	−$0.18M

분석가는 테이블을 하나도 열지 않고도 변화의 크기, 그 뒤의 계정, 계보, 가정 변경의 파급 범위까지 완전한 답변을 얻습니다.

답변을 어느 정도 신뢰할 수 있는가

유려한 답변이 반드시 정확한 것은 아닙니다. 이제 “왜 바뀌었나” 답변마다 얼마나 신뢰할 수 있는지를 쉬운 말로 설명하는 내용이 함께 제공되므로, 그럴듯하지만 불안정한 수치를 설명 속에 묻어 두지 않고 조치하기 전에 알려 줍니다. 에이전트는 설명과 함께 다음을 알려 줍니다.

신뢰 수준 — 높음, 보통, 낮음 중 하나이며, 변화가 얼마나 깔끔하게 분해되는지를 반영합니다. 하나의 뚜렷한 원인으로 설명되는 변화는 높음으로, 여러 원인이 겹치거나 수치가 완전히 일치하지 않는 변화는 더 낮게 표시됩니다. 결과가 여러 배부 브랜치로 구성된 경우, 신뢰 수준은 각 브랜치가 변화에서 차지하는 비중에 따라 가중됩니다. 그래서 작고 불안정한 브랜치 하나가 그 외에는 깔끔한 답변의 수준을 끌어내리지는 않습니다. 하지만 수치 자체가 의심스러운 브랜치(조정되지 않은 분할, 오래된 데이터, 귀속시킬 수 없는 항목)는 전체 답변의 신뢰 수준을 계속 낮춥니다.
쉬운 말로 된 주의 사항 — 예를 들어 원인이 단일 요인이 아니라 겹치는 여러 요인의 혼합이라는 점, 답변이 현재 계층이나 배부 동인 가중치에 근거한다는 점, 변화의 일부가 실제 움직임이 아니라 데이터 완전성의 영향(아직 로드가 끝나지 않은 기간)일 수 있다는 점, 배부에 입력되는 풀이나 배부 동인이 최근에 다시 로드되지 않아 수치가 오래된 데이터에 근거할 수 있다는 점, 가정 수치를 대상 간에 합산할 수 없다는 점 등이 있습니다.
수행할 수 없었던 비교를 분명하게 알림. 대부분의 답변은 보고하는 움직임의 크기를 1년 전의 같은 움직임과, 그리고 최근 기간과 비교하여 가늠하므로 평범한 해와 추세의 단절을 구분할 수 있습니다. 여러 값 열을 한 번에 배부하는 단계가 기록하는 테이블에는 이 두 가지가 모두 제공되지 않는데, 각각이 단일 열 답변을 기준으로 만들어지기 때문입니다. 예전에는 이를 알리지 않아서, 실제로는 설계상 중간에 멈췄는데도 데이터가 허용하는 데까지 도달한 답변처럼 읽혔습니다. 이제 이 내용이 한계 항목에 명시되며, 대신 물어볼 수 있는 더 좁은 질문이 없는 이유와 답변의 어떤 수치도 이로 인해 철회되지 않는다는 사실이 함께 설명됩니다. 금액은 정확하고, 빠져 있는 것은 맥락입니다.

에이전트가 정확한 원인을 보증할 수 없을 때는 그렇다고 말하고, 확신에 찬 이야기를 지어내는 대신 깔끔하게 답할 수 있는 범위나 필터를 알려 줍니다. 신뢰 수준과 주의 사항은 답변의 일부이므로 답변과 함께 전달됩니다. 다른 에이전트에게 후속 질문으로 요약을 요청해도 신뢰 신호가 조용히 빠지지 않습니다.

기반 데이터가 정해진 기간 안에 다시 로드되지 않았을 때 신뢰 수준을 낮추는 최신성 주의 사항은 기본적으로 꺼져 있으며, 관리자가 워크스페이스별로 켭니다. 어느 정도까지를 최신으로 볼지도 관리자가 정합니다(분기별이나 연간으로만 새로 고치는 데이터는 더 길게 설정합니다). 팀이 의도적으로 오래된 데이터를 사용한다면, 누군가 켜기 전까지는 영향을 주지 않습니다.

켜면 웨어하우스를 읽는 모든 답변에 적용됩니다. “왜 바뀌었나” 설명과 두 종류의 가정 답변이 해당하며, 가정 답변에서 특히 중요합니다. 가정 분석은 모델이 마지막 실행에서 실현한 비중을 사용해 변화를 전파하거나 가중치를 다시 매기므로, 오래된 데이터에서 추정치의 신뢰도가 가장 떨어지기 때문입니다.

이 기능이 알려 줄 수 있는 범위에는 두 가지 한계가 있으며, 가정 분석뿐 아니라 모든 답변에 적용됩니다. 첫째, PlaidCloud에 직접 로드된 테이블의 경과 시간만 확인합니다. 워크플로 단계가 만든 테이블은 그 단계가 마지막으로 실행된 시점만 알 수 있는데, 이는 데이터가 도착한 시점과는 다른 문제이므로 잘못된 수치로 답하지 않고 일부러 확인하지 않습니다. 둘째, 각 종류별로 가장 오래된 테이블(풀 하나, 배부 동인 하나)만 알려 주므로, 가정 분석이 여러 단계로 팬아웃되고 둘 이상의 배부 동인이 오래된 경우에는 그중 하나만 알려 줍니다. 어느 경우에도 오래된 테이블을 최신으로 보고하는 일은 없습니다.

알아 두면 좋은 내용

결과 테이블을 둘 이상의 배부 단계가 생성하는 경우, 에이전트는 어느 단계가 변화를 일으켰는지 추측하지 않고 후보 단계를 나열한 뒤 원하는 단계를 지정해 달라고 요청합니다. 질문이 그중 한 단계만 생성한 행으로 좁혀지는 경우(예: 그 단계만 배부하는 지역)에는 에이전트가 이를 알아보고 해당 단계를 자동으로 추적하며, 그렇게 했다고 알려 줍니다.

단계를 지정하면 에이전트가 설명할 단계가 정해질 뿐, 측정할 행이 정해지는 것은 아닙니다. 보고되는 변화는 테이블 전체의 변화이며 정확합니다. 하나의 단계에 귀속시킬 수 없는 것은 요인 간 분할이므로, 기록하는 단계가 여럿인 테이블에서는 에이전트가 이 분할을 보류하고, 수치가 해당 테이블에 기록하는 모든 단계를 포함한다고 알리며, 나머지 단계를 차례로 거쳐 테이블을 추적해 보겠다고 제안합니다. 이렇게 다시 실행하는 각각은 별도의 측정입니다. 보고 있는 변화에서 해당 단계가 차지하는 몫도 아니고, 해당 단계 단독의 측정도 아닙니다. 이 단계들은 같은 열에 기록하며, 이것이 분할이 보류된 이유이므로 돌아오는 변화는 여전히 이들 전체를 포함합니다.

이는 다른 기록 단계가 무엇이든 적용됩니다. 배부가 아닌 단계(예: 결과 테이블에 행을 추가하는 단계)는 추적 후보가 되지 않으므로 선택을 요청하는 일이 없지만, 그 행도 합계에는 똑같이 포함됩니다. 이제 에이전트는 그 단계의 움직임을 분할에 섞어 넣지 않고 이 사실을 알려 줍니다.

“이 풀이 … 늘어나면 어떻게 되나요?” 같은 답변은 팬아웃 전체에 걸쳐 각 대상의 풀에서 차지하는 현재 비중에 따라 변화를 나누므로, 테이블별 수치는 각각이 최악의 경우의 상한이 되지 않고 합산됩니다. 이는 오늘 기준 모델의 비중을 반영하며, 변화가 어디에 반영되는지에 대한 범위가 잘 정해진 추정치이지 정밀한 예측은 아닙니다. 입력 풀이 아니라 배부 동인이나 기준 테이블을 지정하면, 배부 동인을 바꾸는 것은 가치를 더하는 것이 아니라 고정된 분할을 재편하는 것이므로 배부 동인 가정 분석(아래)으로 처리됩니다.

이 경우에는 기간을 명시적으로 지정하십시오. “왜 바뀌었나” 질문이나 배부 동인 가정 분석과 달리, 순방향 가정 분석은 기간 열을 대신 찾아 주지 않습니다. 지정하지 않으면 추정치는 염두에 둔 기간이 아니라 모든 기간을 포함합니다.

순방향 가정 분석은 각 대상을 기록하는 단계를 쿼리하여 그 대상의 비중을 계산합니다. 그 쿼리가 실패하는 경우(단계의 테이블에 기간 열이 없거나 웨어하우스가 쿼리를 거부하는 경우), 해당 대상은 이제 사유와 함께 추정치를 전혀 보고하지 않습니다. 예전에는 해당 대상에 도달하는 변화 전체를, 즉 측정된 답변과 똑같이 보이는 최댓값을 보고했고, 그 단계 아래의 모든 것이 이 값을 바탕으로 추정되어 브랜치 전체가 평범한 수치처럼 보였습니다.

따라서 세 가지 사항이 적용되며, 답변에 각각 명시됩니다. 합계는 측정된 대상만 포함합니다. 측정되지 않은 단계의 하위는 그 단계에서 추정하지 않으므로, 해당 대상은 추측으로 채워지지 않고 답변에서 빠집니다. 대상을 기록하는 항목 중 일부만으로 측정된 대상은 그 사실과 읽지 못한 단계의 이름을 알려 줍니다. 그 부분 수치는 읽을 수 있었던 부분에 대한 실제 측정이므로 유효하지만, 대상 전체는 아니며 빠진 부분이 더 클 수도, 더 작을 수도, 부호가 반대일 수도 있습니다. 이를 하한으로 읽지 마십시오.

배부 동인을 바꾸면 어떻게 되는지 물어보면(“조립 비용 센터의 인원 배부 동인이 10 늘면 어떻게 되나요?”) 에이전트는 모델을 다시 실행하지 않고 새 가중치로 고정된 풀을 정확하게 다시 나눕니다. 어떤 대상이 늘고 어떤 대상이 줄어드는지 보여 주며, 늘어난 양과 줄어든 양의 합이 0이 되는지 내장 검사로 확인합니다. 정확하게 계산할 수 있는 것, 즉 단순한 배부 동인을 쓰는 단일하고 간단한 분할로 한정합니다. 계층 기반 배부나 필터/조건부 배부, 완전히 새로운 배부 동인 멤버 추가, 그룹을 비우는 변경처럼 더 복잡한 것은 추정하지 않고 사유와 함께 거부됩니다.

배부 동인 테이블에 표기된 대로 열 이름을 지정하십시오. 단계가 배부 동인 열을 다른 이름으로 넘기는 경우, 질문에는 배부 동인 테이블 자체의 이름을 써야 하며, 잘못 지정하면 답변이 되돌려 알려 주는 이름도 이것입니다. 결과는 반대로 표시됩니다. 이동한 비용 센터와 그룹은 결과 테이블에 표기된 이름으로 표시되며, 결과를 필터링하고 읽을 때 쓰는 이름이 그것이기 때문입니다. 대부분의 단계에서는 두 이름이 같습니다.

필드로 변화를 분류하면 같은 값을 공유하는 행이 한데 모이는데, 값이 없는 행도 한데 모입니다. 그래서 비교 대상 기간의 모든 행에서 비어 있는 필드는 변화 전체를 담은 단일 그룹을 만들었고, 이는 가능한 가장 집중된 결과, 즉 멤버 하나가 움직임 전체를 차지하고 신뢰도가 최대인 것처럼 읽혔습니다.

이제 에이전트는 해당 행에서 그 필드가 채워져 있지 않다고 알려 주며, 집중도 수치를 100%로 보고하는 대신 보류합니다. 값이 채워진 필드나 분류를 아예 없애는 방법을 제안하며, 분류를 없애면 에이전트가 변화를 가장 잘 설명하는 필드를 직접 찾습니다. 값이 채워진 두 번째 그룹화 필드가 있는 경우에는 분류가 정당하므로 평소처럼 보고하고, 비어 있는 필드는 따로 표시합니다. 빈 값은 (값 없음) 또는 *(빈 값)*으로 표시되며 둘은 구분됩니다. 한 번도 채워지지 않은 필드와 명시적으로 아무것도 없음으로 설정된 필드는 서로 다릅니다.

영향을 받은 것은 분류뿐이었습니다. 전체 변화, 합계, 귀속 방식은 처음부터 정확했습니다.

필드를 지정하지 않으면 에이전트는 변화를 가장 잘 설명하는 필드를 고르는데, 때로는 그 답이 해당 필드에 값이 전혀 없는 행인 경우가 있습니다. 이는 오류가 아니라 실제 발견이므로 숨기지 않고 보고합니다. 조용히 태그 지정이 중단된 비용은 알아 둘 가치가 있습니다.

하지만 “할당되지 않은 행이 늘었다”는 것은 거의 항상 채워지는 필드와 거의 항상 비어 있는 필드에서 전혀 다른 의미입니다. 이제 답변은 같은 문장에서 어느 쪽인지 알려 줍니다. “가장 적합한 분류는 cost_centre의 할당되지 않은 행입니다. 비교한 기간의 행 중 12%에서만 cost_centre에 값이 있습니다.” 행의 12%에서만 채워진 필드는 거의 쓰이지 않는 것이고, 95%에서 채워진 필드의 공백은 추적할 가치가 있는 실제 공백입니다. 매우 드물거나 매우 완전한 필드는 0%나 100%가 아니라 1% 미만과 99% 초과로 표시되는데, 이 경우 둘 다 사실일 수 없기 때문입니다.

검색에 앞서 에이전트는 데이터에 간단한 질문을 하나 하여, 전체에 걸쳐 값이 하나뿐인 필드나 너무 잘게 나뉘어 그룹으로 쓸 수 없는 필드를 제외합니다. 웨어하우스가 측정할 수 없는 열 유형이나 끊어진 연결처럼 이 질문에 답할 수 없는 경우, 예전에는 대신 모든 필드를 검색해서, 이미 무언가 잘못된 바로 그 순간에 두 가지 제한을 모두 풀어 버렸습니다.

이제는 검색이 실행되지 않았다고 직접 알려 주며, 이는 데이터에 대한 발견이 아니라 검색의 한계라는 점을 분명히 합니다. 비교한 기간이 너무 커서 검색할 수 없을 때 받는 안내와는 문구가 다른데, 대처 방법도 다르기 때문입니다. 그 경우에는 기간을 좁히고, 이 경우에는 검토할 필드를 직접 지정하면 되며 이는 원인과 관계없이 통합니다. 다시 시도하는 것은 일시적인 실패였을 때만 도움이 됩니다.

테이블에 없는 필드로 분류해 달라고 요청하면 이제 그 사실과 함께 테이블에 있는 필드를 알려 주므로, 질문을 한 번에 바로잡을 수 있습니다. 예전에는 분류만 빠진 채 답변이 완전하고 확신에 찬 모습으로 돌아왔고, 분류를 시도했다는 안내도 없었으며, “더 알아보기” 제안은 전혀 다른 곳을 가리켰습니다. 실제 모델에서 연속된 질문 네 개가 이런 식으로 돌아왔습니다.

상위 흐름에서는 규칙이 의도적으로 다릅니다. 배부로 추가된 필드는 그 하위 테이블에만 존재하므로, 질문한 테이블에 있는 필드가 두 단계 앞에서는 실제로 없는 경우가 흔합니다. 이 경우 추적은 해당 단계의 분류를 잃는 대신 그 단계에 있는 필드로 그룹화하며, 어느 필드를 뺐는지 알려 줍니다.

이 안내는 앞선 단계에 대한 것이며 그렇게 명시합니다. *“요청한 분류를 이 단계에서는 사용할 수 없었습니다”*라고 표시됩니다. 답변에 표시되는 멤버 테이블에 대한 안내가 아닙니다. 그 테이블은 질문한 테이블이며 요청한 전체 그룹화로 표시됩니다. 앞선 단계의 더 거친 그룹화는 그 단계 자체의 집중도 수치를 측정하는 기준이며, 그 멤버는 나열되지 않습니다. 함께 나오는 제안도 그 단계를 지목합니다. 그 멤버도 보려면 추적한 모든 단계에 있는 필드로 그룹화하십시오. 2026년 8월까지는 이 안내가 “이 답변에 없습니다”라고 쓰였고 *“표시되는 멤버는 나머지 항목으로만 그룹화됩니다”*라고 설명했으며, 제안은 필드가 “추적한 테이블”에 없다고 했습니다. 이는 표시된 테이블을 가리키면서 실제와 다르게 설명했고, 정상적으로 작동하는 필드를 빼라고 권했습니다.

웨어하우스의 일시적인 오류처럼 다른 이유로 분류가 빠진 경우에도, 답변은 같은 방식으로 이를 알리며 분류를 만들지 못한 단계의 이름을 알려 줍니다. 합계는 측정되었고 영향이 없으며, 다시 시도하도록 제안합니다. 세부 정보가 없는 것이지 틀린 것이 아닙니다.

합계가 두 기간 사이에 양수에서 음수로 바뀐 경우(예: 순비용이던 비용 센터가 순수익으로 바뀐 경우) 그 움직임을 원인들에 나누는 의미 있는 방법이 없고, 의미 있는 백분율도 없습니다. 작은 양수에서 큰 음수로 바뀌면 −10,013% 같은 수치가 나오는데, 이는 아무것도 측정하지 못합니다.

에이전트는 예전부터 그랬듯이 이런 변화의 배분을 거부합니다. 달라진 점은 이제 그것을 이유로 밝힌다는 것입니다. 이전에는 측정 방식에 대한 일반적인 안내로 시작해서 그것이 설명인 것처럼 읽혔고, 바로 아래에 인쇄된 줄과도 어긋났습니다. 0을 넘은 변화에 대해서는 백분율이 더 이상 표시되지 않으며, 양쪽 금액과 변화 자체는 정확하고 영향을 받지 않습니다.

두 기간을 별개의 수치로 읽으십시오. 이제 답변은 거부하는 줄에 두 수치를 모두 인쇄하며, 요청한 슬라이스인지 전체 열인지도 밝힙니다. 무엇이 움직였는지 보려면 분류 차원을 추가하십시오. 0을 넘은 합계는 원인으로 나눌 수 없지만, 그 뒤에 있는 멤버별 움직임은 정상적으로 읽히며, 답은 대개 거기에 있습니다.

모든 답변은 실행할 수 있는 다음 단계로 끝납니다. 예전에는 두 가지 상황에서 아무것도 제안하지 않았는데, 바로 가장 막막한 두 상황, 즉 0을 넘은 합계와 에이전트가 전혀 집계하지 못한 단계였습니다. 이제 둘 다 제안이 표시되며, 두 번째는 확인할 테이블과 가장 유력한 원인(해당 단계의 테이블에 기간 열이 없음)을 알려 주므로, 웨어하우스의 일시적인 오류라고 가정하기 전에 이를 먼저 배제할 수 있습니다.

마찬가지로, 질문을 이미 멤버 하나로 한정했다면 답변이 더 이상 멤버로 한정하라고 제안하지 않습니다. 이 조언은 질문 자체가 아니라 상위 흐름에서 기록된 제한에서 나온 것이었는데, 마치 여기에 해당하는 것처럼 명시된 한계 항목에서 반복되었습니다.

여전히 다음 단계를 제안하지 않는 경우가 하나 있습니다. 배부 동인 테이블을 독립적으로 읽은 결과가 실현된 분할과 일치하지 않을 때, 답변은 그렇다고 알려 주지만 문제를 해결하는 재실행을 제안할 수는 없습니다. 이때 유용한 조치는 배부 동인 테이블을 직접 살펴보는 것이며, 이는 이 요청을 조정하는 것이 아니라 별개의 요청입니다.

팁

테이블은 이름(cost_line_rev)이나 ID로 지정하십시오. 둘 다 작동합니다.
변화에 대한 질문에서는 비교할 기간(예: 2025년과 2026년)을 지정하고, 필요하면 계정이나 엔터티 같은 분류 차원도 지정하십시오.
“이 프로젝트에는 어떤 배부 모델이 있나요?“처럼 넓게 시작해서 점점 깊이 들어가십시오. 에이전트는 대화의 맥락을 유지하므로 후속 질문은 같은 모델을 기반으로 이어집니다.
가정 분석은 두 종류입니다. 값 변경(“이 풀이 100만 달러 늘어남”)은 현재 비중으로 추정되며 대상 전체에 걸쳐 합산됩니다. 배부 동인 변경(“이 배부 동인의 가중치 조정”)은 정확하게 다시 나뉘며 합이 0이 됩니다. 의도한 쪽에 맞게 질문을 표현하십시오.