어제 LLM에 전달할 매출 지표 용어집을 JSON으로 만들었는데, 순매출 (net_sales) 계산에 필요한 취소액 (cancellation_amount)이 어디에도 정의되어 있지 않다는 사실을 깨달았다. 프롬프트라면 "부족한 용어는 질문해줘"라고 쓸 수 있다. 하지만 실행할 때마다 지키게 하는 것보다, 머지(Merge) 전에 차단하는 것이 더 빠르다.

업무 용어집은 설명 자료가 아니라, 에이전트(Agent)가 참조하는 데이터 계약(Data Contract)으로 취급하는 것이 좋다. 필수 항목의 결락, 존재하지 않는 의존성, 지표 간의 순환 참조를 CI에서 차단하는 작은 linter를 작성했다. Python 3.10 이상, 외부 패키지 없이 동작한다.

8월 3일에 공개된 AWS Japan의 Context Ontology Accelerator 기사도 데이터만으로는 업무적 의미가 부족하다는 점을 다루고 있다. 나는 우선 훌륭한 그래프 기반(Graph Infrastructure)을 만들기 전에, "그 용어를 누가 정의하고 무엇을 바탕으로 계산하는가"를 기계적으로 검사할 수 있는 상태를 만들고 싶다.

예시로 수주 명세서에서 만드는 매출 계열 지표를 둔다. id는 프로그램용, label과 definition은 사람과 LLM이 읽기 위한 정보다. source와 owner가 없는 용어는 숫자가 맞지 않게 되었을 때 돌아갈 곳이 없어 곤란해진다.

owner는 처음에는 부서명만으로도 충분했다. 정의를 변경하는 PR에 이름 없는 지표가 섞이면, 리뷰에서 정답을 결정할 사람도 없어진다. 이것은 기술적인 문제처럼 보이지만, 실제로는 변경 사항을 받아줄 창구를 마련하는 작업이기도 하다.

[
{
"id": "gross_sales",
...

계산식 자체를 문자열로 해석하는 것은 SQL 방언(Dialect)이나 별칭(Alias) 때문에 갑자기 어려워진다. 여기서는 의존 대상을 depends_on으로 분리했다. 집계 쿼리나 세만틱 레이어(Semantic Layer)는 별도로 리뷰하고, 이 JSON은 "어떤 단어가 어떤 단어에 의존하는가"를 기록하는 대장으로 한정한다. 역할을 욕심내지 않는 것이 CI에서 깨지지 않는 비결이다.

여기서 용어집을 머지 전에 검사한다.

다음 스크립트는 필수 필드, ID의 중복과 형식, 정의되지 않은 의존성, 순환 참조를 조사한다. 순환 참조 탐지는 깊이 우선 탐색(DFS)을 사용하며, 탐색 중인 노드를 다시 밟으면 경로를 출력한다.

#!/usr/bin/env python3
"""JSON 업무 용어집을 CI용으로 검사한다. Python 3.10+."""
from __future__ import annotations
...

내 로컬 환경에서는 위의 3개 JSON에 대해 다음과 같은 출력을 확인했다.

$ python glossary_lint.py glossary.json
OK: 3 terms, 0 errors

adjustment를 정의하지 않고, gross_sales와 net_sales를 상호 참조하게 만든 fixture에서는 종료 코드 1이 되었다.

net_sales: unknown dependency 'adjustment'
cycle: gross_sales -> net_sales -> gross_sales

CI에서는 예를 들어 GitHub Actions의 테스트 절차에 이것을 한 줄 추가하면 된다.

- run: python glossary_lint.py data/business_terms.json

이 linter는 "순매출의 SQL이 정말로 올바른가"까지는 증명하지 않는다. 취소일의 기준, 소비세를 포함할지, 반품을 언제 차감할지는 definition을 리뷰하고, 실제 데이터에 대한 테스트도 별도로 가질 필요가 있다.

그럼에도 불구하고, 참조 대상이 사라진 채 용어만 남는 사고나, 지표 A가 B를 참조하고 B가 A를 참조하는 사고는 모델의 답변을 살펴보고 있는 중에는 찾아내기 어렵다. 용어집의 구조라면 차이(Diff)가 발생하는 시점에 결정된다. 이곳을 조용히 걸러낼 수 있는 것만으로도, 답변이 그럴싸해 보이는 와중에 숫자의 유래를 놓치는 횟수는 상당히 줄어든다.

업무 용어를 LLM에 전달하려면, 설명문을 늘리기 전에 깨지지 않는 참조 관계를 만들어 두고 싶다. definition, source, owner, depends_on 이 4가지가 갖춰지면 답변의 근거를 추적하는 입구가 된다.

나라면 처음에는 매출이나 재고처럼 논란이 되기 쉬운 지표만 10개 정도 JSON화하여 이 검사를 CI에 넣을 것이다. 용어집이 늘어난 뒤에는 빠진 단어 하나가 어떤 프롬프트에 영향을 주었는지 추적하기 어렵다. 미리 차단할 장소를 만들어 두면 에이전트 측의 평가도 수월해진다.