대사 AI 자동화: PG엔 있는데 우리 장부에 없는 결제를 잡아내게 했다

개요

PG 정산 파일에는 있는데 우리 장부에는 없는 결제를 모델이 찾아내게 했습니다. 규칙이 원인 후보를 하나도 못 낸 건만 모델에게 넘기고 이 원인 하나만 판정하도록 범위를 좁혔더니, 60건 중 60건을 맞혔습니다.

대사는 내 결제 기록과 PG(결제대행사)가 보내주는 정산 파일을 하루치씩 대조해 안 맞는 건을 찾는 작업입니다. 불일치가 나면 사람이 원인을 골라 확정합니다. 그 화면을 만들면서 셋을 먼저 붙였습니다. 주문 하나에 무슨 일이 있었는지를 11곳에서 모아 한 번에 보여주는 것, 차액이 수수료율과 맞는지 같은 산수로 원인 후보를 내는 것, 그리고 고객에게 보낼 안내 초안을 쓰는 것입니다. 앞의 둘에는 AI를 안 썼습니다. 산수가 답하는 걸 모델에게 추측시킬 이유가 없습니다.

그러고도 남는 게 있습니다. 규칙이 아무 후보도 못 내는 건입니다. 이 글은 거기에만 모델을 붙인 이야기입니다.

여기에 모델을 붙이는 건 미뤄뒀던 일입니다. 근거를 재려면 사람의 확정이 쌓여야 하는데, 개인 프로젝트에는 쌓일 실데이터가 없고 기다린다고 생기지도 않습니다. 만들어서 재는 쪽이 배우는 게 많다고 판단했습니다.

만들고 나서 배운 게 넷입니다.

개인 프로젝트로 만든 결제 시스템 pay의 개발 기록입니다. 실무 운영 경험이 아닙니다.

상황 1. 남의 사례에서 가드를 가져왔다

만들기 전에 이 일이 자동화된 업계 수준부터 봤습니다. 규칙 엔진이 성숙하면 예외 큐에 남는 것이 전체의 5~15% 이고, 모델이 맡을 자리는 그 안쪽입니다. 구조가 가장 가까운 Ramp의 사례에서 가드 일곱 개를 가져왔습니다.

이 일이 자동화되는 업계 수준부터 봤다

대사 자동화의 지표는 자동 매칭률(auto-match rate) 입니다. 일반적인 운영이 초기 75~85%, 규칙 엔진이 성숙한 곳이 95% 이상까지 갑니다. 성숙한 구현에서 예외 큐에 남는 것이 전체의 5~15% 입니다.

숫자를 보고 나니 이 기능의 자리가 분명해졌습니다. AI가 맡을 자리는 그 5~15%의 안쪽이고, 그중에서도 규칙이 이미 답한 것을 뺀 나머지입니다. 매칭률을 올리는 일이 아닙니다.

가장 가까운 사례는 Ramp였다

카드 거래가 엉뚱한 가맹점으로 분류됐을 때 고치는 에이전트입니다. 이 기능과 구조가 거의 같습니다. 분류 후보가 정해져 있고, 사람이 하던 예외 처리를 대신하며, 틀리면 돈에 영향이 갑니다.

거절률 25%가 눈에 띄었습니다. 커버리지를 100% 가까이 올리면서도 네 건 중 하나는 안 하겠다고 답합니다.

가져온 장치가 셋입니다.

• 후처리 가드레일: 모델이 고를 수 있는 값을 미리 정한 목록으로 제한합니다. Ramp의 표현으로는 “존재하지 않는 가맹점을 발명하는 것”을 막는 장치입니다
• 재시도: 형식에 안 맞는 응답이 오면 무엇이 틀렸는지 알려주고 다시 시킵니다
• 섀도 모드: 에이전트가 “무엇을 할 것인지”만 정하고 실행하지 않습니다. 사람의 행동과 대조해 정확도를 누적하다가 임계를 넘은 뒤에 실제 개입을 켭니다

세 번째는 이 프로젝트에 이미 있었습니다. 고객 안내 초안 쪽에 같은 장치가 이미 있습니다. 확정 직전에 초안을 만들어 기록만 하고 화면에는 안 띄웁니다. 잔여 후보에도 같은 방식을 쓰면 “만들었다”와 “켰다”를 분리할 수 있습니다.

기권은 고위험 분류의 표준 장치였다

selective prediction, 우리말로 선택적 예측입니다. 신뢰도가 임계 아래면 답을 내지 않습니다. 커버리지를 정확도와 맞바꾸는 것이고, 최근 연구는 기권을 “정답 / 오답 / 모름” 세 갈래로 두고 오답률에 상한을 거는 형태까지 갑니다.

여기에 그대로 필요했습니다. 규칙이 못 가른 건은 애초에 어려운 건이라, 모델이 아무거나 고르면 확인하는 사람의 일이 오히려 늡니다.

국내 쪽에서 얻은 것

토스가 Flowise와 LLM으로 에러 분석을 자동화한 사례에서 든 교훈이 “더 많은 정보를 제공할수록 더 많은 분석을 이끌어낼 수 있었다”입니다. 모델에게 주문 하나의 이력을 통째로 넘기는 근거가 됐습니다. 앞서 11곳에서 모아둔 그 이력입니다. 사실이 부족한 상태로 물으면 모델은 추측으로 메웁니다.

카드사 이상거래탐지(FDS) 쪽 서술은 방향이 반대라서 더 유용했습니다. “기본 분류·대조·반복 입력은 AI가 처리하고, 담당자는 판단이 필요한 업무에 집중한다.” 그런데 이 프로젝트는 기본 분류·대조를 이미 규칙이 합니다. AI에게 남는 건 규칙이 못 가른 어려운 건이고, 그건 판단이 필요한 쪽입니다. 그래서 제안까지만 하기로 했습니다.

LINE이 공개한 평가 자동화 사례에서도 같은 순서를 봤습니다. 모델을 고르기 전에 평가 하네스를 먼저 둡니다. 이 프로젝트가 11편에서 잣대를 먼저 만든 것과 같은 판단입니다.

가드 일곱 개

가드 5가 이 프로젝트만의 것입니다. Ramp는 가맹점 목록으로 출력을 제한했는데, 여기서는 원인 코드뿐 아니라 근거 문장에 나오는 금액과 날짜까지 코드가 낸 값인지 대조합니다. 고객 안내 초안을 만들 때 쓰려고 붙여둔 검증기를 그대로 씁니다. 초안에 나온 금액과 날짜를 전부 뽑아 코드가 만든 사실 목록과 대조하고, 하나라도 목록에 없으면 그 초안을 버리는 장치입니다.

상황 2. 원인 코드에 뜻을 안 줬다

대사 케이스 12건을 손으로 만들었습니다. 아홉은 정답이 있는 건이고, 셋은 기권해야 맞는 건입니다. 원인 일곱 종을 모두 덮습니다.

모델은 셋을 씁니다. 같은 계열의 크기 차이(qwen3 8B와 14B)와 다른 계열(llama3.1 8B)을 같이 봐야 계열 편향과 크기 효과를 가를 수 있습니다.

1차: 원인 코드를 이름만 줬을 때

셋 다 절반 이하입니다. 그리고 틀린 자리가 모델을 넘어 겹쳤습니다.

1
기대=TIMEZONE_BOUNDARY   qwen3:8b=DUPLICATE_RECORD   qwen3:14b=PG_FILE_DELAY
2
기대=PG_FILE_DELAY       qwen3:8b=PARTIAL_CANCEL...  qwen3:14b=PG_FILE_DELAY

TIMEZONE_BOUNDARY와 PG_FILE_DELAY는 둘 다 “다른 날짜 파일에 있다”입니다. 방향을 알려주지 않으면 가를 수가 없습니다. 전날 파일이면 거래일 경계고, 다음날 파일이면 파일 지연입니다.

제가 이름만 보고 가를 수 있다고 여긴 게 잘못이었습니다. PG_FILE_DELAY라는 문자열에는 “다음날”이 안 들어 있습니다.

2차: 뜻을 함께 줬을 때

정의 아홉 줄을 프롬프트에 붙였습니다.

1
- TIMEZONE_BOUNDARY: 거래일 경계. KST 새벽 건이 PG 기준으로 <전날> 파일에 잡힘
2
- PG_FILE_DELAY: PG 파일이 늦게 도착. <다음> 거래일 파일에 포함됨
3
  TIMEZONE_BOUNDARY 와 PG_FILE_DELAY 는 방향으로 가릅니다.
4
  전날 파일이면 경계, 다음날 파일이면 지연입니다.

세 모델 모두 올랐습니다. 계열이 다른 llama에서도 같은 방향이 나왔으니, 적어도 이 12건에서는 qwen에만 있는 성질로 보이지 않았습니다. 같은 12건, 같은 모델, 바뀐 것은 정의 아홉 줄뿐입니다.

모델을 키운 것보다 정의를 붙인 게 컸습니다. 8B에서 14B로 키운 효과가 1차에서 +1이었는데, 정의를 붙인 효과는 같은 8B에서 +3이었습니다.

이건 알려진 현상이었다

찾아보니 분류 과제에서 라벨 이름만 주는 것과 한 줄 설명을 붙이는 것의 차이는 이미 측정돼 있었습니다. 카테고리 설명을 뺐을 때 Micro F1이 0.79에서 0.73으로 떨어졌다는 절제 실험이 있고, 라벨링 규칙을 요약해 프롬프트에 넣자 F1이 0.57에서 0.95로 올랐다는 보고도 있습니다.

12편에서 용어 사전을 만든 것과 같은 축입니다. 그때는 고객이 읽을 문장에 시스템 용어가 새는 문제였고, 이번엔 모델에게 던지는 문장에 코드 안에서만 통하는 이름을 그대로 쓴 것입니다. 방향만 반대입니다.

이 결과를 코드에 박았습니다. ResidualPromptBuilder가 원인마다 뜻을 들고 있고, 새 원인을 추가하면서 뜻을 안 적으면 테스트가 걸립니다.

1
assertThat(ResidualPromptBuilder.causeMenu()).doesNotContain("(정의 없음");

화면에 연결하려니 경계에 막혔다

만들고 껐다로 끝내면 만들었다고 하기 어렵습니다. 사람이 보는 화면까지 연결하려고 했는데 확정 화면 쪽에서 부를 수가 없었습니다.

1
reconciliation   allowedDependencies = { shared, payment, audit }
2
assist           allowedDependencies = { shared, timeline, reconciliation }

ReconciliationAdminService가 assist를 부르면 순환입니다. 10편에서 “경계를 지키느라 못 막은 구멍”이라고 적은 자리와 정확히 같습니다. 그때는 못 고치고 남겼는데 이번엔 다른 답이 있었습니다.

창구를 assist 쪽에 두고 화면이 두 번 부르게 했습니다. 상담 초안이 이미 그 구조입니다. 왕복이 하나 늘지만 경계가 유지되고, 규칙 제안만으로 충분한 건에서는 이 호출이 아예 안 나갑니다.

응답에는 source를 항상 싣습니다. 규칙이 낸 후보와 모델이 낸 후보가 화면에서 같아 보이면 사람이 둘을 같은 무게로 읽습니다. 그러면 가드를 일곱 개 걸어둔 의미가 화면에서 사라집니다.

그런데 같은 12건으로 고치고 다시 쟀다

여기까지가 이 글의 원래 결론이었습니다. 그런데 외부 리뷰가 이걸 짚었습니다.

1차 결과를 보고 프롬프트를 고친 뒤, 같은 12건으로 다시 쟀습니다. 그러면 나아진 건 맞지만 그 12건에 맞춘 결과일 수 있습니다. 12/12가 새 케이스에서도 유지되는지는 아무도 모릅니다.

맞는 지적이라 안 본 케이스 15건을 새로 만들어 한 번만 쟀습니다. 프롬프트는 손대지 않았습니다. 금액·날짜·서술을 전부 새로 썼고, 답이 있는 11건과 기권해야 하는 4건으로 나눴습니다.

14B는 유지됐습니다. 개발셋에 맞춘 결과가 아니었다는 뜻입니다. 8B와 llama는 비율이 비슷하게 나왔습니다.

합쳐 보면 안 보이는 게 있다

전체 정확도 하나로 합치면 중요한 게 가려집니다. 이 기능에서 제일 위험한 실패는 오분류가 아니라, 기권해야 할 때 단정하는 것입니다. 틀린 원인을 확신 있게 제시하면 확인하는 사람의 일이 늘어납니다.

분류는 셋 다 쓸 만한데 기권은 아닙니다. llama는 기권해야 하는 네 건 중 셋을 단정했습니다. 14B도 하나 남습니다.

1
H-15  사실:  승인 120,000원 / 파일 119,000원 / 취소 이력 조회 실패
2
      14b :  FEE_CALCULATION_DIFF, confidence 80

차액 1,000원이 수수료율과 맞는다는 근거가 없고, 취소 이력을 못 봤다는 사실이 목록에 적혀 있는데도 단정했습니다.

고친 건 모델도 프롬프트도 아니었다

단정한 건들을 보니 공통점이 있었습니다. 사실 목록이 불완전한 건이었습니다.

1
H-15  사실:  승인 120,000원 / 파일 119,000원 / 취소 이력 조회 실패
2
      프롬프트: "주의: 일부 출처 조회가 실패해 이 목록은 불완전합니다."
3
      14b :  FEE_CALCULATION_DIFF, confidence 80

적어 줬는데 무시했습니다. 세 모델 다 그랬습니다.

그래서 모델에게 기권을 부탁하는 대신 코드가 막게 했습니다. 조회가 한 곳이라도 실패하면 그 사실 묶음으로는 원인을 가릴 수 없으니, 모델을 아예 부르지 않습니다.

1
if (!facts.complete()) {          // 가드 6
2
    count("incomplete_facts");
3
    return Optional.empty();      // 모델을 부르지 않는다
4
}

같은 홀드아웃 15건을 다시 돌렸습니다.

모델도 프롬프트도 안 바꿨습니다. 코드가 막았습니다.

이것도 이 분야의 표준이었다

찾아보니 그렇게 하는 이유가 정리돼 있었습니다.

프롬프트 엔지니어링은 행동에 영향을 줄 수는 있어도 강제 가능한 통제 경계를 만들지 못한다. 실패가 사업에 영향을 주는 순간부터는, 모델이 잘 답해주기를 바라는 것보다 결정적 검증이 더 믿을 만하다.

모델 가중치는 드리프트하거나 파인튜닝으로 덮일 수 있지만, 코드의 조건문은 그렇지 않다.

그래서 LLM 호출 전에 도는 결정적 검사(pre-LLM 가드레일)를 둡니다. 기권도 마찬가지라서, 프롬프트로 시키는 기권은 맥락이 부족할 때 실패한다는 것이 따로 보고돼 있습니다. 강한 모델도 맥락이 모자라면 기권하지 않고 지어냅니다.

제가 프롬프트에 세 번째 규칙으로 적어둔 “근거가 약하면 ABSTAIN 을 내십시오”가 정확히 그 실패였습니다.

남은 실패는 코드가 못 막는다

가드를 넣고도 남은 단정이 있습니다.

1
H-12  사실:  승인 62,000원 / 금액 불일치, 차액 15,500원   ← 목록은 완전하다
2
      8b·llama:  FEE_CALCULATION_DIFF, confidence 80

사실이 완전한데도 틀립니다. 차액이 수수료율과 맞는다는 근거가 없는데 단정합니다. 이건 “정보가 모자라다”가 아니라 “있는 정보로 틀린 추론을 한다” 라서 조건문으로 못 막습니다.

그런데 그 27건도 내가 쓴 것이었다

홀드아웃까지 하고 나서도 남는 게 있었습니다. 개발 12건도 홀드아웃 15건도 제가 문장을 썼습니다. 케이스 작성자와 프롬프트 작성자와 평가자가 같은 사람입니다. 문장 틀도 거의 같습니다.

표본 크기 기준을 찾아보니 이렇습니다.

정확도는 250~500개에서 안정화되기 시작한다. 다만 1,000개가 의미상 비슷하면 실제로는 수백 개만큼의 검정력밖에 없다.

개수만 늘려도 소용없다는 뜻입니다. 그래서 조건 축만 정하고 사실 문장은 대사 엔진이 만들게 했습니다. 금액 8종 × 조건 8종 × 변형 5개로 320건을 심고 실제 대사를 돌렸습니다.

발견 1. 규칙이 거의 다 답한다

320건 중 규칙 분류기가 아무 후보도 못 낸 건은 40건이었습니다.

이 기능이 실제로 도는 문은 마지막 한 줄뿐입니다. 손으로 케이스를 쓸 때는 그 문을 몰라서 일곱 원인을 골고루 만들었습니다. 27건은 실제로는 이 기능에 오지 않을 건들이었습니다.

발견 2. 그 40건에서 세 모델이 0/40이다

남은 40건은 내부에만 기록이 있고 어느 거래일 파일에서도 못 찾은 건입니다. 일곱 원인 중 맞는 게 없습니다. PG_FILE_DELAY는 “다음 파일에 포함됨”이고 INTERNAL_RECORD_LOST는 방향이 반대입니다. 정답은 기권입니다.

세 모델이 같은 방향 오류를 100% 확신으로 냈습니다. 그 원인의 뜻을 “PG에는 있는데 내부에 기록이 없음”이라고 프롬프트에 적어 뒀는데, 사실은 정반대였습니다.

앞에서 TIMEZONE_BOUNDARY와 PG_FILE_DELAY를 방향으로 못 가른 것과 같은 실패입니다. 그때는 정의를 붙여 고쳤는데, 이번엔 정의가 이미 있는데도 틀렸습니다.

그래서 14/15는 무엇이었나

이 기능에 실제로 오지 않는 분포에서 잰 값이었습니다. 틀린 수치는 아니지만 “쓸 만하다”의 근거로는 못 씁니다.

차이를 만든 것은 모델이 아니라 표본입니다.

상황 3. 신뢰도로는 맞고 틀림을 못 가른다

가드 4의 전제는 “신뢰도가 낮으면 틀릴 가능성이 높다”입니다. 그 전제를 홀드아웃 15건에서 재봤습니다.

평균만 보면 잘 안 보입니다. 임계를 올렸을 때 무엇이 사라지는지를 봐야 합니다. 원인을 실제로 고른 건만 모아, 임계별로 몇 건이 통과하고 그중 몇이 정답인지 세었습니다.

qwen3:14b

85에서 오답만 빠지고 정답 11이 다 남습니다. 이 모델 이 표본에서는 임계가 듣습니다. 다만 90으로 올리면 정답 넷이 같이 사라집니다.

qwen3:8b

llama3.1:8b

llama는 85를 걸면 14건 중 1건만 통과합니다. 오답이 사라지는 게 아니라 기능이 사라집니다.

같은 임계가 모델마다 전혀 다르게 듭니다. 14B에서 85는 오답만 걷어내는 좋은 값인데, llama에서 85는 기능을 끄는 값입니다. 8B는 85에서 정답 셋을 잃고도 오답이 하나 남습니다.

그러니 “임계 70”처럼 코드에 박아둔 숫자에는 근거가 없었습니다. 모델을 바꾸면 같이 바꿔야 하는데, 무엇을 보고 바꿀지는 재보기 전에는 모릅니다.

이것도 알려진 현상이었다

모델이 말로 표현하는 신뢰도(verbalized confidence)는 경험적으로 보정이 안 돼 있다는 것이 반복 확인된 결과입니다. 정확도가 낮은 사례에 높은 신뢰도를 보고하고, 정확도가 떨어져도 신뢰도는 높은 수준에 머뭅니다.

원인으로 지목되는 것 중 하나가 사람 피드백으로 모델을 다듬는 훈련 방식(RLHF)입니다. 보상 모델이 단정적으로 들리는 답을 선호하기 때문에, 학습된 모델이 마땅히 해야 할 만큼 유보하지 않습니다. 최근에는 중간에서 후반 층의 특정 블록이 신뢰도 부풀리기 신호를 쓴다는 기계적 분석까지 나와 있습니다.

즉 모델에게 자기 확신을 물어서 거르는 설계는 처음부터 약했습니다. 그걸 모르고 가드 4를 넣었습니다.

그리고 오답 하나가 가드를 전부 통과한다

2차에서 qwen3:8b가 못 맞힌 셋 중 하나가 기권해야 하는 건이었습니다.

1
사실:  결제 승인 25,000원
2
       금액 불일치. 차액 7,000원
3

4
8b :   FEE_CALCULATION_DIFF, confidence 80
5
       "차액 7,000원은 수수료·부가세 계산 방식 차이로 추정됩니다"
6

7
14b:   ABSTAIN, confidence 0
8
       "원인을 판단할 수 있는 충분한 정보가 없습니다"

7,000원이 수수료율과 맞는다는 근거가 어디에도 없습니다.

출처가 맞는 숫자로 틀린 주장을 할 수 있습니다.

숫자 검증기가 잡는 것은 출처가 없는 숫자입니다. 이건 출처가 있습니다. 진짜 있는 숫자를 틀린 인과에 붙인 것이라 검증기의 관할 밖입니다.

그럼 누가 잡느냐면 채점 기준입니다. 초안이나 후보가 “쓸 만한가”를 항목별로 매기는 표입니다. 그런데 그 채점 기준이 네 번 나를 속인 적이 있습니다. 발송할 수 없는 초안에 96점을 주고, 요구를 넣자 이번엔 모델이 점수를 채우려고 모르는 것까지 단언했습니다. 출처를 재는 일과 주장이 맞는지 재는 일은 다른 층이고, 어려운 쪽은 두 번째입니다.

상황 4. 범위를 좁혀서 켰다

0/40을 보고 접을 수도 있었는데, 그 전에 하나를 더 봤습니다. 전체 정확도로만 보고 있었습니다.

유형별로 가르니 그림이 달랐다

코퍼스를 고쳤습니다. 처음엔 결제 이력을 전부 비워 뒀는데, 대사의 내부 기록은 결제 이벤트에서 만들어집니다. 결제 기록 없는 대사 기록이라는 없는 세계를 만들고 있었습니다.

그리고 가드 1도 넓혔습니다. 금액 불일치는 수수료도 취소도 아닐 때 배제법으로 SUSPECTED_TAMPERING을 약한 확신으로 내는데, 그 근거 문구가 “수수료로도 취소로도 설명되지 않는다”입니다. 위변조 판정이 아니라 “모르겠다”이고, 사람이 다시 봐야 하는 자리가 거기입니다. 그래서 기준을 “후보가 하나라도 있으면 안 부른다”에서 “결정적 후보가 있으면 안 부른다”로 바꿨습니다.

잔여가 40건에서 272건이 됐습니다. 유형별로 최대 20건씩 뽑아 다시 쟀습니다.

전체는 25~40%인데 한 유형은 60건 중 60건입니다.

맨 위가 잘 되는 이유가 있습니다. 사실이 “파일에 있고 내부에 없다”로 단순하고 다른 원인과 겹치지 않습니다. 맨 아래는 셋 다 수수료 차이로 답합니다. 차액이 있으면 무조건 수수료라고 봅니다.

목록만 줄였더니 오히려 나빠졌다

그래서 고를 수 있는 값을 그 하나로 줄였습니다. 그랬더니 45건 중 38건에 그 하나를 찍었습니다. 정확도가 15%로 떨어졌습니다.

목록만 줄이고 “그 밖은 전부 기권”을 안 적었기 때문입니다.

모델은 “고를 게 하나뿐”을 “그러니 그걸 골라라”로 읽습니다.

판정 기준을 명시하고 나서야 됐습니다.

1
  - 사실에 "내부에 이 주문의 기록이 없음"이 있어야 합니다
2
  - 내부 기록 금액이 아예 없어야 합니다
3
  - 내부 기록 금액이 <있으면> 이 원인이 아닙니다. 반드시 ABSTAIN 입니다
4

5
그 밖의 모든 경우는 ABSTAIN 입니다.

그래서 켰다

기본값을 ollama로 바꿨습니다. 켠 유형은 하나이고 전체 잔여의 14%를 덮습니다. 나머지 86%는 기권으로 사람에게 갑니다.

작아 보이는데, 제일 위험한 유형입니다. 금액이 조금 안 맞는 것보다 “PG는 처리했다는데 우리 장부에 아예 없다”가 훨씬 무섭습니다. 원인 목록에도 그 유형만 “위험한 원인, 별도 조치 필요”로 따로 적혀 있습니다.

업계도 범위를 좁게 잡는다

Monzo와 Revolut는 잔액 조회와 단순 분쟁만 봇에 맡기고 복잡한 건은 사람에게 넘깁니다.

반대 사례가 Klarna입니다. AI 상담으로 한 달에 230만 건, 전체 대화의 3분의 2를 자동화하고 해결 시간을 11분에서 2분 미만으로 줄였습니다. 그런데 2025년에 되돌렸습니다. 사람 상담원을 다시 뽑았고 CEO가 “비용 주도 자동화는 품질이 낮다”고 인정했습니다.

되돌린 이유가 이 프로젝트가 본 것과 같습니다. 단순한 건은 사람만큼 했는데 복잡한 분쟁·사기·연체에서 품질이 떨어졌고, 모델이 정책과 수수료에 대해 확신에 찬 틀린 답을 냈습니다.

네 상황을 관통하는 것

두 번 다 제가 재는 방법을 잘못 잡았습니다. 모델이 아니었습니다.

손으로 만든 27건에서 14B가 14/15를 냈을 때 “분류는 됐다”고 적었습니다. 그런데 그 27건은 규칙이 이미 답하는 것까지 골고루 만들어 넣은, 이 기능에 실제로 오지 않는 건들이었습니다. 엔진을 돌려 진짜 잔여 분포를 만드니 0/40이었습니다.

그 0/40을 보고 “안 된다”고 적었습니다. 그것도 틀렸습니다. 전체 정확도로만 보고 있었고, 유형별로 가르니 하나는 60건 중 60건이었습니다.

두 번 다 숫자가 아니라 숫자를 만든 방법이 문제였습니다. 그래서 이 글의 원래 결론이 틀렸습니다. 표본을 바꾸기 전까지는 알 수 없었고, 표본을 손으로 쓰는 한 계속 몰랐을 것입니다.

그다음이 모델 이야기입니다. 모델이 못 하는 것과, 모델에게 못 알려준 것은 다릅니다. 그리고 알려줘도 안 지키는 것이 또 따로 있습니다.

이번에 셋을 다 만났습니다. 원인 코드에 뜻을 안 준 것은 못 알려준 것이라 정의 아홉 줄로 고쳐졌습니다. 사실이 불완전한데 단정한 것은 알려줘도 안 지킨 것이라 프롬프트로는 안 되고 코드가 막아야 했습니다. 사실이 완전한데 틀린 추론을 하는 것은 모델이 못 하는 것이라 아직 답이 없습니다.

1차 결과만 보고 “8B로는 안 된다”고 적었으면 틀린 결론이었습니다. 정의 아홉 줄로 6에서 9가 됐고, 계열이 다른 llama도 3에서 8이 됐으니까요. 반대로 2차 결과만 보고 “된다”고 적어도 틀립니다. 남은 실패가 기권이고, 이번 수정만으로는 그게 안 풀렸습니다.

그리고 가드를 일곱 개 걸어도 마지막 한 겹이 남습니다. 형식·목록·유형·임계·출처를 다 검사해도, 있는 숫자를 틀린 곳에 붙이는 건 못 잡습니다. 그걸 잡으려면 “이 주장이 맞는가”를 재야 하는데, 그건 채점 기준의 일이고 12편에서 그 기준이 저를 네 번 속였습니다.

게다가 가드 하나는 전제부터 틀렸습니다. 신뢰도로 거르겠다고 만들어놓고 재보니 맞은 답과 틀린 답이 3점 안에서 겹쳤습니다. 문헌이 이미 말하고 있던 것을 안 찾아보고 넣었습니다.

그래서 지금 상태를 뭐라고 불러야 하나

“AI로 대사를 자동화했다”는 아닙니다. 정확히는 이렇습니다.

규칙이 못 가른 예외 중 한 유형을 AI에게 맡겼습니다. 일곱 유형을 다 맡기면 못 쓰는데, PG엔 있고 우리 장부엔 없는 건 하나만 켜니 세 모델이 91~100%였습니다.

그리고 그 91~100%를 홀드아웃에서 다시 재고 나서, 이 기능을 껐습니다. 왜 껐는지가 이 글의 마지막 절입니다.

무엇이 됐고 무엇이 안 됐는지 갈라 적으면 이렇습니다.

현업 기준으로는 무엇이 더 있어야 하나

찾아보니 켜는 조건을 미리 선언하는 게 표준이었습니다.

• 섀도 모드 졸업 기준. 에이전트를 실제로 행동시키기 전에 사람의 행동과 대조하고, 정렬 점수가 임계(예: 95%)에 닿으면 자율 운영으로 졸업시킵니다. 오프라인 평가와 섀도 통과 없는 모델 교체는 미래의 장애로 봅니다
• 채택률. Shopify는 상품 분류를 하루 3천만 건 예측하면서 판매자 채택률 85% 를 지표로 둡니다. 분류 정확도가 “모델이 맞았나”라면 채택률은 “사람이 쓸 만하다고 봤나” 입니다. 다른 질문이고, 업무 개선을 말하려면 뒤가 필요합니다
• 승인 워크플로. 출력을 채널로 보내 승인·거절·타임아웃 세 결과로 처리합니다

이 중 채택률을 배선했습니다. 다만 그것 하나만 재지는 않았습니다.

채택률만 재면 같은 실수를 반복한다

사람이 제안을 보고 확정하므로 앵커링이 섞입니다. 제안에 끌려간 확정이 채택으로 집계되면, 숫자는 예뻐지는데 답하는 게 없습니다. 이 프로젝트에서 이미 한 번 걸렸던 문제입니다. 규칙 분류기를 잴 때 그 숫자를 정확도라고 부르지 않고 일치율이라고 부른 이유가 그거였고, 채택률은 그 일치율의 다른 이름입니다.

업계도 같은 한계를 말합니다.

채택률은 작업이 깨끗하게 끝났는지, 뒤에 비용이 생겼는지를 답하지 못한다. 채택률이 높은데 재작업률과 검토 시간도 높다면, 낮은 품질을 받아들이고 있다는 뜻이다.

앵커링은 문헌으로도 확인됩니다. LLM 심판이 첫 제안에 끌려가는 계수가 GPT-4에서 0.255로 사람 위원회의 0.193보다 높게 관측됐고, 이를 푸는 표준이 blind 평가입니다.

그래서 셋을 짝으로 남겼습니다.

blind가 요점입니다. 후보를 만들되 일부(기본 20%)는 화면에 주지 않고 기록만 합니다.

1
boolean shown = ThreadLocalRandom.current().nextInt(100) >= blindPercent;
2
suggestions.record(reconResultId, cause, shown);
3

4
if (s.isEmpty() || !shown) {
5
    return new ResidualView(false, null, null, 0);   // 만들었지만 안 준다
6
}

보여준 건만 모으면 「제안 덕분에 빨라졌다」와 「원래 그 정도였다」를 가를 수 없습니다. 전부 감추면 기능이 죽고, 전부 보여주면 비교군이 없습니다.

저장소는 두지 않았습니다. 표본이 쌓이기 전에 스키마를 정하면 무엇을 재야 하는지 모르는 채 모양부터 굳습니다. 상담 초안 섀도 기록도 같은 이유로 로그와 지표만 남깁니다.

국내 사례는 못 찾았다

찾아본 범위에서는 대사 예외 분류에 LLM을 쓴 국내 공개 사례가 없었습니다. FDS에 머신러닝을 쓰는 사례는 나오는데(카카오뱅크 등), 대사 쪽은 금융위 가이드라인과 망분리 논의에 머물러 있습니다. 해외는 Modern Treasury가 감사 가능한 에이전트로 대사·원장 워크플로를 자동화한 사례가 있고, LLM이 자유 서술을 읽어 분류하는 것이 매칭에 빠져 있던 연결고리라는 서술이 반복됩니다.

그래서 지금 상태를 정확히 적으면 이렇습니다. 장치는 다 만들었고, 화면 창구도 있고, 안 본 케이스로 재봤습니다. 기본값은 template이라 아무 일도 하지 않고, ollama로 바꾸면 즉시 삽니다. 켜도 하는 일은 후보 하나를 더 얹는 것이고 확정은 사람이 합니다.

표본을 셋 만들었습니다. 손으로 쓴 개발 12건, 손으로 쓴 홀드아웃 15건, 엔진이 만든 40건입니다. 앞의 둘은 제가 문장을 썼고, 마지막이 실제 분포입니다. 그리고 세 표본의 결론이 서로 다릅니다.

위 수치는 전부 이 글 안에 적었습니다. 12건의 케이스 정의와 프롬프트 전문, 모델별 응답 원문은 저장소에 조사 문서로 남겨 뒀습니다.

돈을 움직이는 선은 넘지 않았다

승인 절차를 만들지 않았습니다. 슬랙으로 승인 요청을 보내는 것도 안 했습니다. 이 기능이 하는 일은 화면에 후보 하나를 얹는 것이고, 되돌릴 게 없기 때문입니다.

찾아보니 기준이 그렇게 서 있었습니다.

되돌릴 수 있는 단계(초안 작성, 요약)는 끝까지 자동화해도 되고, 되돌릴 수 없는 단계(발행, 고객에게 이메일, 돈 옮기기)는 명시적 승인으로 막아야 한다.

결제에서 “되돌릴 수 있나”는 곧 “돈이 움직였나”입니다. 이 프로젝트가 원인을 등급으로 나눌 때 쓴 기준도 그거였습니다.

만들지 않은 더 큰 이유

조사에서 제일 아팠던 문장입니다.

사람이 모든 행동을 승인해야 한다면 아무것도 자동화하지 않은 것이고, 검토자는 곧 읽지 않고 승인을 누르는 법을 배운다. 거수기는 게이트가 없는 것보다 나쁘다. 감독의 실체 없이 겉모습만 만들기 때문이다.

이 프로젝트에 그 위험이 이미 있습니다. 백오피스 확정 화면을 만들 때 적어둔 그대로입니다. 화면은 경고를 띄우지만 확정 버튼은 그대로 눌립니다. 여기에 승인 절차를 더 얹으면 누르는 횟수만 늘고 읽는 양은 안 늡니다.

넘으려면 무엇이 있어야 하는지는 정해뒀다

문서에 조건 셋을 적어뒀습니다.

1
증거가 결정적일 것
2
  + 금액이 중요성 임계 미만일 것
3
  + 그 유형의 실측 오류율이 선언한 한도 안일 것

마지막 조건 때문에 자동 확정은 사람이 그 유형을 충분히 확정해 통계를 만든 뒤에야 켤 수 있습니다. 지금은 그 통계가 없습니다.

그리고 그 선을 넘는 순간 승인 게이트가 같이 필요해지는데, 배치가 밤에 도는 건이라면 화면이 아니라 채널로 나가야 합니다. 사람이 화면 앞에 없을 때는 띄워봐야 아무도 안 봅니다. 그래서 경보는 미리 채널을 붙여 뒀습니다. 알림 규칙만 있고 받는 데가 없으면 그래프에 빨간 줄만 그어집니다.

홀드아웃에서 다시 쟀더니

91~100%는 기준을 고친 그 표본에서 다시 잰 값이었습니다. 기준을 그 표본을 보고 고쳤으니, 그 표본에서 잘 나오는 건 당연합니다. 개발과 홀드아웃을 안 나눈 수치였습니다.

프롬프트는 한 글자도 안 바꾸고 새 표본 45건을 만들었습니다. 사실 문장은 지어내지 않고 대사 결과를 타임라인에 옮길 때 쓰는 형식("대사 %s (거래일 %s) — 내부 %s / 외부 %s")을 그대로 쓰고 값만 새로 뽑았습니다.

켠 유형은 살아남았습니다. 무너진 건 기권해야 할 쪽입니다. 특히 방향이 정반대인 “내부에만 있음”에서 세 모델이 모두 0/15입니다. 프롬프트에는 이렇게 적혀 있었습니다.

1
  - 내부 기록 금액이 <있으면> 이 원인이 아닙니다. 반드시 ABSTAIN 입니다

이 오답은 가드가 못 막습니다

프롬프트가 켠 유형만 보여주므로 모델이 낼 수 있는 값은 그 하나 아니면 기권 둘뿐입니다. 그래서 모든 오답이 켠 유형과 같은 값이 됩니다. 유형 가드는 그걸 통과시키고, 신뢰도도 95~100이라 임계에 안 걸립니다. 기본 모델이 8B였으니 45건 중 30건에서 틀린 후보가 운영자에게 갔습니다.

그래서 판정 기준을 코드로도 강제했습니다. 프롬프트에 이미 적어 둔 조건인데 모델이 안 지키니까요. 이 프로젝트가 이미 배운 걸 한 번 더 적용한 셈입니다 — 지시하고, 코드로도 막는다.

신호는 문장에서 되뽑지 않았습니다. 사실 묶음이 “대사 결과가 외부에만 있음인가”를 구조화된 값으로 함께 냅니다. 문장 "내부 없음"을 정규식으로 뽑으면 문구를 고칠 때 가드가 조용히 깨집니다. 허용 금액 목록에서 이미 한 번 겪은 실패입니다.

가드를 넣으니 세 모델 모두 100%가 됐습니다. 그런데 그 100%는 모델이 좋아진 게 아닙니다. 가드가 기계적으로 바꾼 값입니다.

그리고 껐습니다

가드를 채우고 나서 계산이 이렇게 됩니다.

• 모델이 낼 수 있는 값 = 그 하나 또는 기권
• 그 값이 통과하는 조건 = 대사 결과가 “외부에만 있음”
• 그 조건에서 규칙 분류기가 이미 같은 답을 냅니다

1
case EXTERNAL_ONLY -> out.add(CauseSuggestion.likely(ResolveCause.INTERNAL_RECORD_LOST,
2
        "외부에만 존재. 내부에 이 주문의 기록이 없다"));

모델이 할 수 있는 최선이 규칙에 동의하는 것입니다. 그 왕복은 값을 만들지 않고 지연과 비용만 만듭니다.

후보 모델을 프로덕션에 올릴 때 기준은 절대 정확도가 아니라 기존 방식 대비 개선입니다. 섀도 모드로 후보와 현행을 같은 입력에 태워 비교하고 그 차이로 승격을 정하는 게 표준 절차인데, 여기서 현행은 규칙 분류기이고 차이는 0이었습니다.

대사에서 규칙과 모델을 섞는 건 업계 표준이 맞습니다. 다만 나누는 기준이 있습니다 — 결정적으로 갈리는 건은 규칙, 모호하고 편차가 큰 건은 모델. 제가 켠 유형은 대사 결과 유형 하나로 결정되는 건이라 애초에 모델의 자리가 아니었습니다.

유형별로 갈라 잰 것까지는 맞았습니다. 놓친 건 그 유형을 규칙이 이미 답하고 있다는 사실이었습니다. 정확도를 유형별로는 봤는데 규칙 대비로는 안 봤습니다.

남긴 것

기능은 껐지만 만든 건 남깁니다.

• 재현 가능한 평가 하네스 — 전에는 애드혹이라 다시 못 돌렸습니다. 이제 ./gradlew evalTest입니다
• 판정 기준을 강제하는 가드 — 유형을 다시 열 때 필요합니다
• 규칙이 이미 답한 건에 모델을 안 부르는 가드
• 홀드아웃 절차 — 다음에 유형을 열 때 이 방식으로 먼저 잽니다

규칙이 못 가르는 유형을 열 수 있게 되면 그때 다시 켭니다. 지금은 나머지 유형이 세 모델 모두 0~50%라 열 수 없습니다.

뒷이야기 — 출처 검증이 세 번째로 같은 벽에 부딪혔습니다

이 글에서 이렇게 적었습니다.

근거 없이 “차액 7,000원은 수수료 차이”라고 단정한 오답이 출력 검증 다섯을 전부 통과했다. 인용한 7,000원은 실제로 있는 값이었다. 출처가 맞는 숫자로 틀린 주장을 할 수 있다

그 뒤에 같은 일이 두 번 더 일어났습니다.

두 번째 — 잔여 원인. 홀드아웃에서 방향이 정반대인 건(“내부에만 있음”)에 세 모델 모두 같은 원인을 냈고, 신뢰도가 95~100 이라 임계에도 안 걸렸습니다.

세 번째 — 장애 로그. 로그를 읽고 원인을 고르는 걸 붙여 봤는데, 큐 적체 로그에 RACE_CONDITION 을 찍었습니다. 상담 초안에서 쓴 방법을 그대로 가져와 모델이 인용한 줄이 실제 로그에 있는지 대조하는 가드를 만들었습니다.

못 잡았습니다.

1
CAUSE: RACE_CONDITION
2
EVIDENCE: 웹훅이 결제보다 먼저 도착 — 보류 paymentKey=tviva… retry=6

인용은 진짜입니다. 로그에 그대로 있는 줄입니다. 틀린 건 그 줄에서 끌어낸 결론입니다. “재시도가 반복된다”를 읽고 “동시성 문제”라고 답한 거죠.

세 번이면 우연이 아닙니다

출처 검증은 “없는 걸 지어냈는가”를 잡지, “있는 걸로 틀린 말을 하는가”를 못 잡습니다.

이건 가드를 더 촘촘히 만들어 해결되는 문제가 아닙니다. 출처 검증이 보는 것은 인용의 실재이고, 틀린 것은 인용에서 결론으로 가는 단계입니다. 그 단계를 검사하려면 “이 주장이 맞느냐”를 재야 하는데, 그게 12편에서 저를 네 번 속인 그 채점 기준입니다.

그래서 세 번째 기능도 안 켰습니다. 이번에는 “규칙 대비 얻는 게 없어서”가 아니라 틀린 답을 막을 방법을 못 찾아서입니다.

참고

• Ramp 거래 재분류 에이전트: ZenML LLMOps Database
• Modern Treasury 대사에 AI 붙이기: Modern Treasury Journal
• 토스 Flowise + LLM 에러 분석 자동화: 토스 테크
• LINE 평가 하네스 자동화: LY Corporation 기술블로그
• 말로 표현한 신뢰도의 보정 문제: Overconfidence is Key (arXiv 2405.02917), On Verbalized Confidence Scores (arXiv 2412.14737)
• 라벨 설명이 분류 정확도에 미치는 영향: PoliPrompt (arXiv 2409.01466)
• 기권과 선택적 예측: Uncertainty-Aware Abstention (arXiv 2607.04430)
• 채택률의 한계: The rise and looming fall of acceptance rate (LeadDev)
• 심판의 앵커링: Understanding the Anchoring Effect of LLM (arXiv 2505.15392)
• 대사에 AI 붙이기: AI reconciliation 사례 정리 (Ledge)
• 프롬프트로 시키는 기권이 실패하는 이유: Prompt-Based Abstention Fails Under Misleading Context (arXiv 2608.22228)
• 승인 게이트를 어디에 둘 것인가: Building a Human-in-the-Loop Approval Gate for Autonomous Agents
• 대역 외 승인(Slack·이메일): Human approval for async AI agent actions (WorkOS)
• Klarna 가 되돌린 기록: Klarna Reverses Course on AI Customer Support
• 결정적 가드레일: Designing Deterministic Guardrails for LLM Systems, Pre-LLM & Post-LLM Best Practices (Arthur)