상담 초안 자동화: 발송 못 할 초안에 96점을 줬다

개요

고객에게 그대로 보낼 수 없는 안내 초안에 채점기가 96점을 줬습니다. 이 글은 초안이 쓸 만한지 재려다 그 잣대가 네 번 나를 속인 기록입니다. 무르면 나쁜 게 통과하고, 빡빡하면 좋은 게 떨어지고, 요구하면 대상이 요구에 맞춰 변형되고, 맞아도 검사 밖은 못 봅니다.

대사는 내 결제 기록과 PG(결제대행사)가 보내주는 정산 파일을 하루치씩 대조해 안 맞는 건을 찾는 작업입니다. 그 불일치를 고객에게 알리는 안내 초안을 모델에게 맡기고, 초안에 지어낸 숫자가 섞이지 않았는지 검사하는 장치까지 붙여둔 상태였습니다. 그다음 질문이 “그래서 그 초안은 보낼 만한가”입니다.

이 글의 수치는 통계적 성능 평가가 아닙니다. 표본은 대사 예외 4건이고, 그 4건으로 루브릭도 가점도 고쳤습니다. 이미 개발 세트라 홀드아웃이 아닙니다. 아래 숫자는 전부 그 4건 위에서 돌린 탐색 실행의 결과로 읽어야 맞습니다.

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

상황 1. 개선을 재려 했더니 잣대가 나를 속였다

숫자는 지켜졌습니다. 그러면 그 초안은 보낼 만한가. 이걸 재려다 잣대가 네 번 나를 속였습니다.

재는 것부터 막혔다

여기까지 잰 것은 두 가지였습니다. 지어낸 숫자가 없다(100%), 내부 용어가 안 샌다(0%).

둘 다 좋은데, 둘 다 “보낼 만하다”는 뜻이 아닙니다.

그걸 재려면 사람이 초안을 얼마나 고치는지를 봐야 합니다. 그런데 초안을 보여주고 “고쳐보세요”라고 하는 가장 쉬운 방법은 쓸 수 없습니다. 사람이 눈앞의 문장에 끌려가서(앵커링) “고칠 게 없었다”와 “고칠 생각이 안 났다”가 구분되지 않습니다.

새로운 문제가 아닙니다. 이 프로젝트의 대사 분류기가 자기 수치를 정확도가 아니라 “일치율” 이라고 부르는 이유가 정확히 그거고, 그 한계가 클래스 주석에 적혀 있습니다.

그래서 순서를 뒤집었다

1
① 사실만 보여준다 → 사람이 직접 답을 쓴다   ← 초안을 보기 <전에>
2
② 그 뒤 모델 초안을 공개합니다
3
③ 사람이 초안을 발송 가능하게 고칩니다

①을 건너뛰면 그 표본은 조용히 무의미해집니다. 겉보기엔 데이터가 쌓이는데 오염돼 있습니다. 그래서 문서나 관례가 아니라 엔티티가 순서를 강제합니다. 블라인드 답 없이 공개를 부르면 예외가 납니다.

서버도 같이 막습니다. 모델 초안은 1단계를 마치기 전까지 응답에 아예 실리지 않습니다. 화면이 감추는 게 아니라 서버가 안 보냅니다. 클라이언트를 믿고 감추면 개발자 도구로 뚫립니다.

처음엔 순서 위반에 IllegalStateException을 던졌는데 500이 나갔습니다. 호출자가 버그인지 의도된 차단인지 구분할 수 없습니다. 이 실험에서 순서 위반은 오류가 아니라 설계된 거절이라 409로 매핑했습니다.

결과: 발송 가능한 수준이 아니었다

4건을 직접 리뷰했습니다. 4건 중 2건을 절반 이상 새로 썼습니다(문자 단위 편집 거리 기준, 중앙값 45.6%). 표본이 4건이라 중앙값은 참고값이고, 읽어야 할 건 “절반을 새로 썼다”는 쪽입니다.

공통 원인이 하나였습니다. 발송본이 전부 초안보다 길어졌습니다. 초안이 “무슨 일이 있었나”는 말하는데 “그래서 고객은 어떻게 되나” 를 말하지 않습니다.

그리고 첫 줄은 내가 만든 버그였습니다. 프롬프트에 “원인이 적혀 있으면 확인 중으로 쓰라”고 했는데, 확신 등급이 DECISIVE면 산수로 이미 확정된 것입니다. 확정된 걸 “확인 중”이라고 쓰면 고객이 불필요하게 불안해합니다.

고치려다 다섯 번 나빠졌다

원인이 명확해 보여서 프롬프트를 고쳤습니다. 전부 실패했습니다.

찾아보니 문서화된 현상이었습니다. 트랜스포머는 프롬프트의 앞과 끝에 높은 주의를 주고 중간을 잃습니다(“lost in the middle”). 우리 사전이 정확히 중간에 있었고, 지시를 더할수록 더 깊이 밀렸습니다.

권고는 재배치입니다. 그래서 ④를 해봤습니다. 사전을 끝으로 보내니 예시가 중간으로 밀렸습니다. 내용 품질을 가르치는 건 예시입니다. 양쪽 끝은 두 자리뿐이라 둘 다 넣을 수 없습니다.

기준선이 이미 최적 배치였습니다. 되돌리고 기준선이 재현되는지까지 확인했습니다.

그리고 검사가 나를 속이기 시작했다

여기부터가 이번 편의 진짜 이야기입니다.

① 검사가 물렀다

표본 4건으로는 아무것도 결정할 수 없어서, 정답 없이 채점하는 루브릭을 만들었습니다(reference-free evaluation: 답이 열려 있고 하나의 정답으로는 유효한 변형을 놓칠 때 쓰는 방식입니다).

첫 결과가 평균 4.97/5, 만점 96%.

그런데 블라인드 리뷰는 편집률 45%라고 했습니다. 둘 중 하나가 틀렸습니다. 무엇으로 통과했는지 뜯어봤습니다.

1
id=14  루브릭 5/5  영향표현=['안내드리']
2
id=13  루브릭 5/5  영향표현=['안내드리']
3
...
4
상투적 마무리만으로 통과: 6/6

6건 전부가 “안내드리겠습니다” 한 마디로 통과했습니다. 어느 초안에나 붙고 고객에게 아무것도 알려주지 않는 문장입니다.

그대로 실었으면 “초안이 거의 완벽하다” 고 적을 뻔했습니다.

② 조였더니 너무 빡빡해졌다

상투어를 빼면서 그대로까지 같이 뺐습니다. 그래서 모델이 “청구 금액은 그대로 유지됩니다”라고 제대로 쓴 것을 못 알아봤습니다.

측정이 개선 0으로 나왔고, 하마터면 “2단계 수정은 소용없다” 고 결론 낼 뻔했습니다.

③ 통과했는데 내용이 틀렸다

고치고 다시 재니 만점이 나왔습니다. 그런데 만점짜리 초안이 이렇게 씁니다.

결제 내역은 외부 기록에만 확인되며, 저희 내부 기록에 해당 주문이 없습니다.
… 고객 영향은 없으며, 청구 금액은 100,000원으로 그대로 유지됩니다.

주문 기록조차 없는 건에 “청구가 멀쩡하다”고 단언합니다. 100,000원은 외부 기록에 있으니 숫자 검증을 통과하고, 영향 표현이 있으니 루브릭도 통과합니다. 둘 다 통과하는데 주장이 틀렸습니다.

다른 계열 모델을 심판으로 세웠다

코드로는 못 잡습니다. 숫자가 아니라 주장의 문제입니다.

초안은 Qwen이 씁니다. 모델은 자기 계열 출력을 후하게 봅니다. 같은 계열을 심판으로 세우면 통과율만 오르고 아무것도 안 걸러집니다. Llama 계열이 이 편향을 안 보인다는 관측이 있어 llama3.1:8b을 골랐고, 설정을 잘못 넣으면 기동 시 경고하게 했습니다.

심판부터 검증했습니다. 처음엔 실패했는데 판정과 이유가 서로 어긋났습니다. “단정하고 있습니다”라면서 위반 아님으로 판정합니다. 좋은 예·나쁜 예·중립 예 셋을 주자 3종 모두 맞혔습니다.

이건 배선 확인이지 심판의 신뢰성 검증이 아닙니다. 다른 계열을 골라 자기 계열 편향을 줄여보려 한 것이지 중립을 보장하지 않습니다. 정밀도·재현율을 재려면 라벨 세트가 필요한데 아직 없습니다.

심판을 만들면 심판이 아는 오류를 실제로 잡는지 먼저 확인해야 합니다. 안 하면 무엇을 하는지 모르는 채 숫자만 늘어납니다.

그리고 심판이 나를 잡았다

대사 예외 10건을 2회씩 돌린 초안 20건 중 16건(80%) 이 근거 없는 단정으로 표시됐습니다. 너무 많아서 오탐을 의심하고 뜯어봤습니다. 오탐이 아니었습니다.

차액 8,888원의 원인을 확인 중입니다. … 고객 영향은 없으며, 청구 금액은 그대로 유지됩니다.

심판: “수수료로도 취소로도 설명되지 않는데 청구 유지라는 근거가 사실에 없다”

원인을 모르는데 결과를 장담합니다. 그리고 이걸 만든 건 내 2단계 수정입니다.

루브릭이 “고객 영향을 말하라”고 요구하니, 모델이 점수를 채우려고 알 수 없는 것까지 단언했습니다.

내가 올린 4.10 → 5.00 중 일부는 점수 따먹기였습니다. 지표를 목표로 삼으면 지표가 목표가 됩니다. 다른 계열 심판이 없었으면 이걸 성과로 인용했을 것입니다.

고친 방법 두 가지

하나, 원인을 모르면 영향을 요구하지 않습니다. 수수료 차감이면 청구가 그대로라고 말할 수 있고 말해야 합니다. 원인 불명이면 결과도 모르고, 그때 요구해야 할 것은 영향이 아니라 모른다는 사실입니다.

둘, 예시를 케이스별로 갈아 끼웁니다. 남은 원인이 고정 예시였습니다. 예시 하나가 “청구된 금액에는 변동이 없습니다”로 끝나서 모델이 기록조차 없는 건에도 그 꼴을 복사했습니다.

늘리지 않고 바꿨습니다. 고정 3개 → 케이스에 맞는 것 1개 + 나쁜 예 1개. 지시를 더할 때마다 나빠졌으니 이래야 합니다.

그리고 원인 불명을 기본값으로 두고 “모른다고 쓰는 예시”를 줍니다. 확언하는 예시만 보여주면 모델은 확언합니다. “‘모른다’고 말할 수 있는 능력이 옳은 답을 내는 능력만큼 중요하다.”

둘을 넣고 다시 재니 16건에서 11건(55%)으로 줄었습니다. 80%에서 55%입니다.

④ 이번엔 심판이 틀렸다

바꾸고 재니 심판이 20건 중 14건(70%) 을 위반이라고 했습니다(11건, 55%에서 악화). 뜯어보니 오탐이었습니다.

초안: 저희 주문 내역에서 찾지 못해 확인 중입니다. 카드사 승인 내역을 보내주시면…
심판: “내부에 이 주문의 기록이 없다는 근거가 사실에 없다”

사실에 내부 없음이 명시돼 있습니다. 초안은 오히려 정확해졌는데 심판이 못 읽었습니다.

LLM을 심판으로 쓸 때 알려진 실패 양상입니다. 심판은 프롬프트를 어떻게 쓰느냐에 민감하고, 명세를 통째로 줘도 그 정보를 다 활용하지는 못합니다. 자기 계열 출력을 후하게 보는 편향(self-enhancement)도 함께 보고돼 있습니다.

그래서 아는 결함은 코드로 셌습니다. 원인이 확정되지 않은 건에 “그대로 유지 / 변동이 없” 류가 있는가 → 0/20.

심판은 모르는 결함을 찾는 데 쓰고, 아는 결함은 코드가 지킵니다.

덤: 금지어를 예시에 적으면 안 된다

용어 누출이 0% → 10%로 재발했습니다. 샌 것은 PAID 세 건이 전부였고, PAID는 나쁜 예시 안에 두 번 있었습니다. *“주문 상태 PAID 확인 중입니다”*와 *“PAID 같은 내부 코드를 쓰지 마십시오”*입니다.

금지하려고 적은 단어를 모델이 그대로 썼습니다.

앞에서 같은 현상을 보고 “priming인 것 같다”고 추측만 했었습니다. 이번엔 토큰만 가려서(주문 상태(영문 코드)) 다시 쟀습니다.

한 단어를 빼서 확인했으므로 이제 추측이 아닙니다.

최종

세 층으로 정리됐습니다.

아래로 갈수록 확실성이 낮아지고 처리도 약해집니다. 확실한 것만 버리고 나머지는 사람에게 넘깁니다.

상황 1이 남긴 것

같은 교훈이 네 번 나왔습니다. 검사가 통과했다는 것과 결과가 좋다는 것은 다릅니다.

• 검사가 무르면 → 나쁜 것이 통과합니다
• 빡빡하면 → 좋은 것이 떨어지고 개선을 없는 것으로 만듭니다
• 맞아도 → 검사 밖의 오류는 그대로 지나갑니다
• 그리고 검사 자체가 틀릴 수도 있습니다

네 번 다 결과를 눈으로 읽어야만 알았습니다. 숫자만 봤으면 네 번 다 넘어갔을 것입니다.

그리고 제일 아픈 건 세 번째입니다. 내가 지표를 만들고, 내가 그 지표를 올리고, 그게 가짜인 걸 다른 모델이 알려줬습니다. 혼자 만들고 혼자 재면 이렇게 됩니다.

상황 2. 잣대가 프런티어 모델과 8B를 구분하지 못했다

여기까지 고치고 나니 검사는 제 몫을 했습니다. 그런데 이번엔 좋은 모델과 작은 모델을 구분하지 못했습니다.

”구독으로 쓰면 안 되나”

상담 초안 이야기를 하다가 이런 요청을 받았습니다.

나 구독하고 있으니까 그걸로 쓰게 해도 괜찮아. 어차피 로컬에서 잠깐 테스트하는 건데.

앱이 구독 자격증명으로 모델을 부르는 건 정책 이전에 기술적으로 안 됩니다. CLI가 쓰는 건 API 키가 아니라 OAuth 토큰이고, 어댑터가 부르는 Messages API는 x-api-key를 받습니다. 로컬이든 아니든 인증이 성립하지 않습니다. 구독은 채팅 앱과 CLI를 커버하지 API 접근을 포함하지 않고 별도 과금입니다.

그런데 목적은 이룰 수 있습니다. 알고 싶은 건 “더 좋은 모델이 어떤 초안을 쓰는가”이고, 그걸 보는 데 앱이 직접 호출할 필요는 없습니다.

1
GET  .../cs-draft/prompt      ← 프롬프트를 그대로 꺼냅니다
2
POST .../cs-draft/imported    ← 받아온 초안을 되돌립니다

되돌리면 같은 검사를 태웁니다. 숫자 검증, 용어 사전, 루브릭, 켜져 있으면 다른 계열 심판까지.

같은 잣대를 태우는 게 요점입니다. 안 그러면 “저 모델이 더 잘 쓰더라”가 인상으로만 남습니다. 이 프로젝트에서 인상이 틀린 적이 여러 번 있었습니다.

저장하지 않습니다. 비교용이지 업무 경로가 아닙니다. 출처를 필수로 받아 manual:<라벨>로 표시합니다. 출처 없는 초안을 만들지 않습니다.

여기에 모순이 있었습니다. 앞에서는 결제 데이터를 밖으로 보내는 설계를 못 쓴다고 해놓고, 뒤에서는 사람이 복사해 외부 모델에 넣을 통로를 기능으로 열었습니다. 꺼낸 프롬프트에 주문번호·금액·거래일이 그대로 들어 있는데 “붙여 넣는 건 꺼낸 사람 책임”이라고 주석에 적어둔 게 전부였습니다.

앱이 직접 보내지 않았다는 건 방어가 안 됩니다. 외부 리뷰에서 이 지점을 지적받았고, 맞는 지적입니다. 제대로 하려면 이렇게 갈라야 합니다.

• 이 경로는 합성 데이터에서만 동작하게 하고
• 주문번호는 비가역 가명값으로, 금액·날짜도 비교에 지장 없는 합성값으로 치환하고
• 실제 업무 데이터에서는 엔드포인트 자체를 끄고
• 그 제약을 주석이 아니라 프로필과 권한으로 강제합니다

지금은 안 돼 있습니다. 규제를 설계 조건으로 걸어놓고 그 조건을 사람 손에 맡긴 셈이라, 이 편에서 제일 약한 자리입니다.

그래서 비교했더니 둘 다 만점이었다

같은 4건에 대해 8B 초안과 프런티어 모델 초안을 나란히 채점했습니다.

잣대가 둘을 구분하지 못합니다.

그런데 읽어보면 같지 않다

루브릭이 못 보는 걸 따로 세어봤습니다.

구체적으로는 이렇습니다.

파일 지연, 8B: ”…확인 중이며, 정산 확정일은 2026-08-30입니다.”
고객에게 의미 없는 내부 일정입니다.

원인 불명, 8B: ”…원인을 확인 중입니다. 결과가 확인되면 안내드리겠습니다.”
추가 청구 여부를 말하지 않습니다. 고객이 가장 궁금해하는 게 그건데.

왜 못 잡나: 내가 그렇게 만들었다

앞에서 이런 일이 있었습니다. 루브릭이 “고객 영향을 말하라”고 요구했더니, 모델이 점수를 채우려고 알 수 없는 것까지 단언했습니다.

차액 8,888원의 원인을 확인 중입니다. … 청구 금액은 그대로 유지됩니다.

원인을 모르는데 결과를 장담합니다. 그래서 “원인이 확정된 건에만” 요구하도록 바꿨습니다.

그 결정은 여전히 맞습니다. 부작용이 이거입니다.

• “모르니까 아무 말도 안 한다” → 통과
• “모르지만 추가 청구는 없다고 약속한다” → 통과

둘 다 통과합니다. 뒤엣것이 분명히 나은데도.

문제의 구조

여기서 문제가 뭔지가 선명해졌습니다.

필수로 걸면 모델이 지어내고, 안 걸면 잣대가 눈이 멉니다.

두 극단만 있었던 거입니다. 필수 아니면 없음.

답은 가점이었다

요구하지 않으면서 재면 됩니다.

• 통과 여부를 안 바꿉니다. 가점이 없어도 6/6입니다
• 프롬프트에도 안 넣습니다. 넣는 순간 그게 압력이 됩니다
• 비교할 때만 필수 + 가점을 씁니다

1
/** 비교용 점수. 같은 만점끼리 <b>가르는</b> 값입니다. */
2
public int comparable() {
3
    return passed + bonus.size();
4
}

가점 두 개를 달았습니다. 둘 다 실제로 차이가 관측된 축입니다.

약속과 주장의 구분

이게 이번 편에서 제일 마음에 드는 부분입니다.

• “이미 청구된 것이 멀쩡하다” → 확인되지 않은 주장. 원인을 모르면 할 수 없습니다
• “앞으로 추가로 청구하지 않겠다” → 우리가 지킬 수 있는 약속. 원인을 몰라도 할 수 있습니다

루브릭은 앞엣것을 막고(필수 항목), 가점은 뒤엣것을 권합니다. 같은 “고객 영향”인데 성격이 다르니 다르게 다뤄야 했습니다.

결과: 구분된다

원인 불명 2건에서 갈렸습니다. 8B는 “결과가 나오는 대로 안내드리겠습니다”에서 멈추고, 프런티어 모델은 “확인이 끝날 때까지 추가로 청구되는 금액은 없으며”를 덧붙입니다.

필수 점수는 여전히 둘 다 만점입니다. 모델에게 점수 압력이 안 생기고, 그럼에도 비교는 가능해졌습니다.

그리고 프롬프트에 안 넣었으니 8B가 못 받은 가점은 진짜 차입니다. 지시를 빼먹어서가 아닙니다.

남는 한계

가점 항목도 결국 내가 골랐습니다.

실험에서 관측된 차이를 축으로 만든 것이니, 그 두 축에서는 프런티어 모델이 이기게 되어 있습니다. 새로운 차원의 차이는 여전히 못 봅니다.

그걸 넓히려면 사람이 초안을 읽고 “이건 왜 나은가”를 말해줘야 합니다. 그게 블라인드 리뷰가 기다리는 자리고, 아직 표본이 없습니다.

덤: 조용히 꺼지는 어댑터

같은 김에 외부 모델 어댑터를 봤더니 두 개가 비어 있었습니다.

테스트가 하나도 없었습니다. 로컬 어댑터는 6건이 있는데 외부 쪽은 0입니다.

그리고 revise()가 없었습니다. 이게 더 나쁩니다.

1
default Optional<String> revise(...) {
2
    return Optional.empty();   // 기본은 "못 한다"
3
}

포트에 기본 구현을 뒀으니 구현하지 않아도 컴파일됩니다. 그래서 프로바이더를 그쪽으로 바꾸면 2단계 수정이 아무 오류 없이 멈춥니다. 루브릭이 5.00에서 4.10으로 돌아가는데 로그에는 아무것도 안 남습니다.

기본 구현을 둔 대가입니다. 편하려고 넣었는데 빠뜨려도 조용한 구조가 됐습니다. 구현하고, 어댑터를 늘릴 때 여기를 같이 봐야 한다고 주석에 박았습니다.

외부 API 응답 모양을 흉내내는 서버로 키 없이 9건을 고정했습니다.

상황 2가 남긴 것

가점은 요구하는 순간 대상이 그 요구에 맞춰 변형된다는 함정을 피하는 방법이었습니다. 재되 요구하지 않기. 관찰자가 관찰 대상을 바꾸지 않게 하는 것에 가깝습니다.

그런데 이것도 완전하지 않습니다. 내가 고른 축만 봅니다. 밖에서 분류표를 가져오거나 다른 계열 모델을 심판으로 세운 것도 같은 문제를 다른 방향에서 친 거였습니다.

두 상황을 관통하는 것

검사를 만들면 그 검사가 나를 속입니다. 무르면 나쁜 게 통과하고(96% 만점인데 발송 불가),
빡빡하면 좋은 게 떨어지고, 맞아도 검사 밖은 못 봅니다.
그리고 하나 더 있었습니다. 요구하는 순간 대상이 그 요구에 맞춰 변형됩니다.

루브릭이 “고객 영향을 말하라”고 요구했더니 모델이 점수를 채우려고 알 수 없는 것까지 단언했습니다.
가점은 그 함정을 피하는 방법이었습니다. 재되, 요구하지 않기.
관찰자가 관찰 대상을 바꾸지 않게 하는 것에 가깝습니다.

그런데 이것도 완전하지 않습니다. 내가 고른 축만 봅니다. 밖에서 분류표를 가져오거나
다른 계열 모델을 심판으로 세운 것도 같은 문제를 다른 방향에서 친 거였습니다.

어디까지 가도 “내가 안 본 것은 내가 못 잰다” 로 돌아옵니다.
혼자 만들면 시야가 만든 만큼입니다. 이 시리즈에서 제일 크게 배운 게 그거입니다.

참고

• 프롬프트 중간의 정보를 놓치는 현상: Lost in the Middle (arXiv 2307.03172)
• LLM 심판의 알려진 편향(위치·장황함·자기 계열 선호): Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv 2306.05685)