결론: 「판정」의 설계는, 검사 공정이 수십 년 전부터 풀어온 문제

지난 기사에서 그래프의 다음 단계는 「판정 그 자체」의 공학이 아닐까라고 썼다. 판정 기준을 어떻게 만들 것인가, 판정을 잘못했을 때 어떻게 기록할 것인가, 판정자 자신의 정밀도를 어떻게 검증할 것인가. 아직 이름이 없기에 「Judgment Engineering(판정 엔지니어링)」이라고 임시로 불러 보았다.

그 기사를 쓴 후, 자신의 본업을 되돌아보며 깨달은 것이 있다. 이 이야기는 제조업의 검사 공정이 아주 오래전부터 해오던 일이다.

합격·불합격의 판정 기준을 만든다. 판정에 편차가 발생하고 있지 않은지 측정한다. 판정한 내용이 맞았는지를 나중에 검증한다. 검사 공정에서는 이를 「품질 보증」이라는 틀 안에서, 통계적인 수법까지 사용하여 수십 년 동안 해왔다. AI 에이전트의 검증역(Verifier)에 부족한 발상의 상당수는, 사실 이쪽에 이미 답이 있다.

「한도 견본」도 「게이지 R&R」도 모른 채, AI의 판정 정밀도를 이야기하고 있었다

솔직히 말하면, 지난 기사를 쓰고 있던 시점에는 이 두 가지 단어가 머릿속에 없었다.

**한도 견본(Limit Sample)**이란, 육안 검사에서 "여기까지는 합격, 여기서부터는 불합격"이라는 경계선을 나타내는 실물 샘플을 말한다. 문장으로 기준을 써도 사람에 따라 해석이 어긋나기 때문에, 실제로 아슬아슬한 합격·아슬아슬한 불합격 샘플을 준비하여 검사원 전원에게 보여준다. 판정 기준을 말이 아닌 물건으로 맞춘다는 발상이다.

게이지 R&R(Gauge Repeatability and Reproducibility, 측정 시스템 분석의 일종)은, 동일한 제품을 동일한 검사원이 반복해서 측정했을 때의 편차(Repeatability)와, 서로 다른 검사원이 측정했을 때의 편차(Reproducibility)를 통계적으로 측정하는 수법이다. "그 판정 기준, 정말 신뢰할 수 있습니까?"를 수치로 대답하기 위한 메커니즘이라고 해도 좋다.

AI의 Judgment Engineering 이야기로 돌아가면, Verifier나 리뷰용 서브 에이전트의 판정 기준은 대개 자연어 프롬프트(Prompt)로 작성되어 있다. 이는 「한도 견본 없이 검사원에게 판정을 시키고 있는」 상태에 가깝다. 그리고 그 Verifier의 판정이 정말로 안정적인지를 검증하는 발상(게이지 R&R에 상당)은, 내가 살펴본 범위 내의 Judgment Engineering 주변 논의에는 아직 등장하지 않았다.

검사 공정의 용어로 Judgment Engineering을 다시 번역하기

같은 발상을 다시 나열하면, 다음과 같은 대응 관계가 된다.

이렇게 나열해 보니, AI 측에 아직 없는 발상이 명확히 보인다. 「판정 기준 샘플의 정비」와 「판정자 자체의 정기 교정」 이 두 가지다.

이 빈틈은 이미 실제 OSS에서 표면화되고 있다

여기까지는 탁상공론이었지만, 조사하면서 발견한 것이 있다. Nous Research가 공개한 자기 개선형 AI 에이전트 「Hermes Agent」다.

Hermes Agent는 복잡한 태스크를 수행한 후, 혹은 에러로부터 회복한 후에 그 절차를 ~/.hermes/skills/에 Markdown 스킬 파일로서 자동 생성한다. 다음에 비슷한 상황을 만나면 그 스킬을 읽어 들여 같은 실수를 반복하지 않도록 하는 설계다.

솔직히 이 이야기를 들었을 때 "바로 지금 생각하고 있는 이야기 그 자체 아닌가"라고 생각했다. 조사해 보니, Hermes Agent 자신의 공식 GitHub issue에 의도했던 대로의 빈틈이 보고되어 있었다. 자기 생성한 스킬은 작성자·실행자·품질 검사를 전부 에이전트 스스로가 겸하고 있어서, 외부에서 검증하는 메커니즘이 없다는 지적이다. 실제 부적합 사례로서, 일시적인 장애(우연히 한 번 실패했을 뿐)를 영구적인 규칙으로 학습해 버려, 그 이후 해당 도구를 계속 피하게 되는 케이스까지 보고되고 있다.

이는 검사 공정의 용어로 말하자면, 「우연히 나온 불량품 하나를 보고, 이후 해당 공정 전체를 계속 멈추고 있는」 상태에 가깝다. 한도 견본도 게이지 R&R도 없이, 검사원(이 경우에는 에이전트 자신)이 자신의 판정을 스스로 채택해 버리기 때문에 발생하는 문제다.

Issue: Self-created skills lack mechanism-level guarantees for correctness and execution consistency를 읽어보면, 커뮤니티 측의 대책안도 나오고 있다. 결정적인 출력을 하는 스킬은 정기적으로 같은 태스크를 2회 실행하여 결과를 비교한다거나, 새로운 스킬을 즉시 활성화하지 않고 한 단계 가벼운 리뷰를 거친다는 등의 안이다. 이는 이전 섹션에서 기술한 「판정 기준 샘플집」이나 「정기적인 재테스트」와 방향성 면에서 상당히 유사하다.

즉, 이 이야기는 추상적인 사고 실험이 아니라, 널리 사용되는 OSS가 지금 바로 맞닥뜨리고 있는 벽이기도 하다.

AI verifier에게 부족한 것은 「판정자 자신의 교정」이라는 발상

지난 기사에서는 review-mistakes.md에 오판정을 기록하고, 다음 리뷰 요청 프롬프트에 읽히는 부분까지를 생각했다. 이는 검사 공정에서 말하는 「불량 유출 기록」에 가깝다.

하지만 검사 공정은 거기서 멈추지 않는다. 기록이 어느 정도 쌓이면, 검사원(또는 검사 장치) 자체를 대상으로 한 확인을 정기적으로 수행한다. 「이 검사원은 정말로 항상 같은 기준으로 판정하고 있는가」를 물건을 사용하여 테스트한다. 이것이 게이지 R&R (Gauge R&R)에 해당한다.

AI verifier로 치환하면 다음과 같은 질문이 된다. 「이 verifier 서브 에이전트에게 기지의 합격 사례와 기지의 불합격 사례를 섞어서 정기적으로 흘려보냈을 때, 항상 같은 판정을 내리는가」 프롬프트를 작성한 본인이 「아마 괜찮겠지」라며 넘겨버리는 부분을, 검사 공정은 수치로 확인하는 문화를 가지고 있다.

구체적으로 무엇을 도입할 수 있는가: 「판정 기준 샘플집」이라는 발상

한도 견본의 사고방식을 그대로 코드 리뷰에 도입한다면, 다음과 같은 형태가 될 것이다.

review-samples/
clear-pass/ ← 명백히 문제가 없는 코드 예시 (수 건)
clear-fail/ ← 명백히 문제가 있는 코드 예시 (수 건, 실제 버그가 포함된 커밋)
...

review-mistakes.md에 쌓인 오판정 중, 「나중에 보니 미묘했던 케이스」를 boundary/로 옮겨간다. 그리고 때때로 이 샘플집을 검증 프롬프트에 섞어서 흘려보내며, verifier의 판정이 흔들리고 있지 않은지 확인한다. 이것이 코드 리뷰 버전의 게이지 R&R이 된다.

솔직히 아직은 아이디어 단계에 머물러 있다. 실제로 해보지 않으면 판정의 흔들림을 검출할 수 있을 만큼의 샘플 수를 준비할 수 있을지, 애초에 자동 테스트와 비교했을 때 수고를 들일 가치가 있는지는 알 수 없다.

내가 직접 해보려고 생각하는 것

설비 점검 관리 시스템 개인 학습 프로젝트에서, 지난번에 쓴 requesting-code-review + 오판정 기록 메커니즘을 시도해 보려 했다. 이번 고찰을 바탕으로 여기에 boundary/ 샘플집 운용도 추가해 볼 생각이다.

구체적으로는, review-mistakes.md가 어느 정도 쌓인 단계에서 경계 사례(boundary cases)만을 추출하여 verifier를 위한 확인 프롬프트에 정기적으로 섞는다. 판정이 갈린다면, 그것을 검사 기준(프롬프트) 측을 재검토하라는 신호로 취급한다.

제조업의 검사 공정을 지켜봐 온 내 입장에서 보면, AI 에이전트의 판정 정밀도 이야기는 새로운 문제라기보다 「품질 보증을 지금부터 다시 한번 발명하고 있는」 것처럼 보이는 부분이 있다. 수치가 나오면 다시 기사로 쓰겠다.

만약 자신의 프로젝트에도 verifier 서브 에이전트를 두고 있다면, 한 번 「경계 사례만 모으면 몇 건이 되는가」를 세어보면 판정의 느슨함이 보일지도 모른다.

자주 묻는 질문

Q. 게이지 R&R을 개인의 코드 리뷰에 사용하는 것은 과하지 않나요?

A. 양산 라인의 엄격한 통계 계산까지는 필요 없다고 생각한다. 여기서 도입하고 싶은 것은 「판정자(verifier)가 정말로 안정적으로 판정하고 있는지를 가끔 테스트한다」는 발상 부분이지, 통계적인 계산식 그 자체는 아니다.

Q. 한도 견본과 게이지 R&R은 애초에 같은 검사 공정 이야기인가요?

A. 목적은 비슷하지만 역할이 다르다. 한도 견본은 「판정 기준을 사람(모델)에게 맞추기 위한 실물 샘플」이고, 게이지 R&R은 「맞췄을 터인 판정이 정말로 흔들리지 않는지를 측정하는 수법」이다. 따라서 한도 견본을 준비한 뒤에 게이지 R&R로 검증한다는 순서가 된다.

Q. 이 사고방식은 업계에서 사용되고 있습니까?

A. 품질 보증 (QA) 분야에서는 확립된 사고방식이지만, 이를 AI 에이전트의 검증기 (verifier) 설계에 적용하여 이야기하는 사례는 내가 조사한 범위 내에서는 아직 찾아볼 수 없다. 지난 기사에서 임시로 명명했던 "Judgment Engineering"과 마찬가지로, 이 기사에서의 대응 방식 또한 나의 가설에 머물러 있다.

Discussion