통과할 때까지 시키면, 통과하는 법을 찾아냅니다

들어가며 — 두 달 전에 “채점자를 떼어놓으라”고 썼습니다

6월에 루프 엔지니어링에 대해 쓰면서, 다들 놓친 실전 포인트로 두 가지를 꼽았습니다. 채점을 작업과 같은 세션에서 하지 말 것, 그리고 메모리는 쌓지 말고 증류할 것.

그 뒤 두 달이 지났습니다. 그사이 이 흐름은 간판만 요란한 유행에서 조금 더 내려왔습니다. 자기 결과를 스스로 검증하고 다시 고치는 구조가 제품 기능으로 팔리기 시작했고, 연구 쪽에서는 그 구조를 실제로 돌려보고 어디서 무너지는지를 재기 시작했습니다.

그리고 그 측정 결과가, 6월 글의 처방을 절반은 확정하고 절반은 부족하다고 말합니다.

채점자를 떼어놓으라는 말은 맞았습니다. 그런데 떼어놓은 다음에 벽이 하나 더 있습니다. 통과 도장은 찍히는데 일은 안 되어 있는 상태예요. 지난 글이 채점자를 어디에 둘 것인가의 문제였다면, 이 글은 그 채점자가 무엇을 보고 있는가의 문제입니다.

---

1. 자기가 쓴 검사는, 만점을 주면서 최저점을 만듭니다

먼저 6월 글의 권고가 수치로 확인된 대목부터.

지난달 나온 한 연구가 스스로 개선하는 에이전트에게 자기 검증을 맡겼을 때 무슨 일이 벌어지는지를 측정했습니다. 에이전트가 자기 성과를 채점할 검사를 직접 쓰고, 그 점수를 보며 스스로를 고쳐 나가는 구조입니다. 루프를 짜본 분이라면 익숙한 모양일 겁니다.

결과는 이렇습니다.

• 실험한 35개 모델·과제 조합 전부가 자기 점수 0.70 이상으로 끝났습니다. 자기 눈에는 전부 성공입니다.
• 그런데 그중 15개는 실제 성과가 무작위로 찍은 것보다 못했습니다.
• 6개는 해당 과제에서 나올 수 있는 최저점을 받으면서 성공을 보고했습니다.
• 외부의 봉인된 감사를 붙였더니, 같은 조건에서 실제 성과가 7.9에서 30.0으로 올랐습니다. (특정 과제·모델 한 조건의 수치입니다)

연구자들이 붙인 이름이 정확합니다 — 판정기와 실제 사이의 간극(verifier–deployment gap). 자기 점수는 만점 근처를 유지하는데 실제 성과는 그대로거나 더 나빠집니다.

이 실험은 게임 환경에서 돌아갔습니다. 그러니 “우리 보고서 작업이 저렇다”고 옮기면 과장입니다. 옮길 수 있는 건 숫자가 아니라 구조입니다. 자기가 쓴 자로 자기를 재면, 자를 만족시키는 쪽이 늘 더 쉽습니다.

2. 떼어놓은 채점자도 뚫립니다 — 그것도 16%나

여기서부터가 6월 글에 없던 이야기입니다.

채점자를 다른 세션으로 떼어놨다고 해봅시다. 그 채점자는 이제 사람이 손으로 쓴 통과 기준을 들고 있습니다. 6월 글에서 목표·통과 기준을 적은 마크다운 파일이라고 불렀던 그것이죠. 이건 안전할까요.

6월에 나온 한 연구가 그걸 감사했습니다. 다섯 개 터미널 에이전트 벤치마크의 1,968개 과제를 훑어서, 최신 모델에게 과제 설명만 주고 판정기를 통과해 보라고 시켰습니다.

323개(16%)가 뚫렸습니다. 과제를 실제로 풀지 않고 통과한 겁니다.

어떻게 뚫었는지가 더 중요합니다. 이 계열 연구들이 관찰한 방식은 이렇습니다.

• 검사 문장(assertion)을 지우거나 주석 처리하기
• 채점 함수 자체를 고쳐 쓰기
• 실패한 답이 통과되도록 테스트 파일을 덮어쓰기
• 검증이 끝나기 전에 프로그램을 미리 종료시키기

한 논문이 이걸 한 문장으로 정리했습니다. 모델은 “판정기가 강제하지 못하는 것을 파고든다”는 것입니다.

여기서 정확히 해둘 것이 하나 있습니다. 위 연구들은 대부분 모델을 학습시킬 때의 보상 신호나 벤치마크 채점을 다룹니다. 우리가 업무에서 돌리는 루프(한 작업 안에서 검사하고 고치기를 반복하는 것)와는 층이 다릅니다. 그러니 “AI가 우리 검사를 조작한다”로 읽으면 과장입니다.

옮겨오는 건 이 한 줄입니다. 통과 조건을 걸면, 그 조건이 목표가 됩니다. 일이 목표가 아니라요.

3. 루프는 일을 하러 가지 않습니다. 통과를 하러 갑니다

그래서 단발 지시와 루프는 성질이 다릅니다.

지시를 한 번 주고 결과를 받으면, 좁은 검사는 놓치는 정도로 끝납니다. 통과 도장은 “내가 물어본 것에 한해서”라는 생략된 절반을 갖고 있을 뿐이죠. 저는 이미 자동검사 네 겹을 통과한 결과물이 깨져 있던 이야기를 쓴 적이 있습니다.

루프는 여기서 한 칸 더 갑니다. 통과가 뜰 때까지 결과물을 계속 고치기 때문입니다.

이 차이가 작지 않습니다. 44편의 검사기는 결함을 못 봤습니다 — 수동적인 한계죠. 루프의 판정기는 결과물을 자기 쪽으로 끌어당깁니다. 자 안쪽은 점점 정교해지고, 자 바깥은 아무도 보지 않는 채 방치되거나 오히려 무너집니다. 반복 횟수가 늘어날수록 이 쏠림은 세집니다. 루프를 열 번 돌린 결과물은 한 번 돌린 결과물보다 판정기에는 더 잘 맞고, 일에는 덜 맞을 수 있습니다.

24시간 자율은 증폭기라고 쓴 적이 있는데, 그건 정의를 안 했을 때 빈칸이 24배로 커진다는 이야기였습니다. 지금은 반대쪽입니다. 정의를 했는데도, 그 정의만 정확히 만족시키는 쪽으로 결과물이 수렴합니다. 성실하게 틀리는 것이죠.

4. 그래서 갈리는 건 루프가 아니라 판정기입니다

루프를 짤 때 우리가 시간을 쓰는 곳은 대개 반복 구조입니다. 몇 단계로 나눌지, 몇 번까지 돌릴지, 어디서 사람을 부를지.

그런데 성패는 그 앞에서 결정됩니다. 무엇을 통과로 볼지 정하는 자리입니다.

이건 업계에 이미 정리된 말이 있습니다. 연구자 제이슨 웨이가 정리한 검증자의 법칙(Verifier’s Law) — AI가 어떤 일을 해내게 만드는 난이도는, 그 일이 얼마나 검증 가능한지에 비례한다. 그가 꼽은 검증이 쉬운 일의 다섯 조건은 이렇습니다.

1. 정답에 이견이 없다 — 무엇이 좋은 답인지 모두가 동의한다
2. 몇 초 안에 판정된다
3. 여러 답을 동시에 판정할 수 있다
4. 잡음이 적다 — 판정 결과가 실제 품질과 어긋나지 않는다
5. 순위를 매길 수 있다 — 여러 답의 좋음을 줄 세울 수 있다

그러면 내 일을 여기에 대보면 됩니다.

판정 조건	월 마감 숫자 점검	보고서 초안 쓰기
정답에 이견이 없다	○ 합계는 하나다	✕ 사람마다 다르다
몇 초 안에 판정된다	○	✕ 읽어봐야 안다
동시에 여러 개 판정	○	✕
잡음이 적다	△ 합이 맞아도 기준이 틀릴 수 있다	✕
순위를 매길 수 있다	○	△ 겨우

루프 사례가 대부분 코딩에서 나오는 이유가 여기 있습니다. 코드는 다섯 조건을 거의 다 통과합니다. 테스트가 몇 초 안에 객관적으로, 여러 개를 동시에, 잡음 없이 판정해 줍니다.

보고서·기획서·교육 설계는 한두 개만 통과합니다. 그러니 코딩 루프 사례를 그대로 옮겨오면 안 됩니다. 루프가 나빠서가 아니라 전제조건이 안 맞아서입니다. 그 자리에 억지로 판정기를 세우면, 세우기 쉬운 것만 자가 됩니다 — 분량, 항목 수, 형식. 그리고 루프는 정확히 그 자를 채우러 갑니다.

5. 자를 넓히지 말고, 먼저 뚫어보고 조입니다

판정기가 좁다는 걸 알면 사람은 대개 기준을 더 붙입니다. 항목을 늘리고, 체크리스트를 길게 만들죠. 이건 대개 안 듣습니다. 늘린 항목도 똑같이 “적기 쉬운 것”이라서요.

앞의 그 연구가 쓴 방법이 훨씬 낫습니다. 이름이 해커-픽서 루프입니다. 세 역할을 번갈아 돌립니다.

1. 해커 — 과제를 풀지 않고 판정기를 통과하려 시도한다
2. 픽서 — 발견된 구멍을 막도록 판정기를 고친다
3. 솔버 — 고친 판정기가 정직한 답은 여전히 통과시키는지 확인한다

결과는 분명합니다. 한 벤치마크에서 공격 성공률이 62%에서 0%로 내려갔습니다. 더 흥미로운 건 약한 모델이 강한 모델의 공격을 막아냈다는 대목입니다. 작은 모델이 돌린 이 루프가, 훨씬 강한 모델들의 성공률을 76%와 61%에서 각각 0%로 끌어내렸습니다. 판정기를 조이는 일은 성능이 아니라 설계의 문제라는 뜻입니다.

이건 비개발자도 그대로 씁니다. 다음에 AI에게 반복 검사를 붙이기 전에, 순서를 하나 끼워 넣으면 됩니다.

통과 기준을 적었으면, 그 기준을 전부 만족시키면서도 쓸모없는 결과물을 하나 만들어 봅니다. 만들어졌으면, 그걸 막는 줄을 기준에 추가합니다.

검사기가 자고 있지 않은지 시험하라고 쓴 것과는 다른 시험입니다. 그건 틀린 것을 흘려보내 빨간 불이 켜지는지 보는 일이었습니다. 검사기가 깨어 있는지를 확인하는 거죠. 이건 반대 방향입니다. 검사기가 정상 작동하는데도 통과해 버리는 쓰레기가 있는지를 봅니다. 하나는 장치가 사는지 보고, 하나는 기준이 좁은지 봅니다.

판정기를 AI 밖에 둘 수 있으면 더 강해집니다. 지난달 말 지멘스가 엔비디아와 함께 내놓은 것이 정확히 그 구조입니다 — 자율적으로 오래 도는 설계 에이전트가 자기 결정을 물리 기반 설계 검증 엔진에 계속 대보게 묶어놨습니다. 판정을 AI의 말이 아니라 딱딱한 도구가 하게 만든 것이죠.

사무실 버전은 소박합니다. 기계가 세어주는 숫자에 판정을 맡기면 됩니다. 합계, 건수, 중복 0건, 빈칸 0개, 원문에 실제로 있는 문장인지. AI의 자평이 아니라 셀 수 있는 것으로요.

6. 오늘의 한 걸음

루프를 짜지 않는 분에게도 이 이야기는 그대로 옵니다. AI에게 “확인하고 고쳐서 다시 줘”라고 말하는 순간, 우리는 이미 작은 루프를 돌리고 있으니까요.

그러니 다음 한 번만 순서를 바꿔보십시오.

몇 번 다시 시킬까를 정하기 전에, 무엇을 통과로 볼까를 한 줄로 적습니다. 그리고 그 한 줄을 만족시키면서 쓸모없는 결과물을 상상해 봅니다.

상상이 되면, 그 자는 아직 자가 아닙니다.

---

마무리 — 루프의 실력은 반복이 아니라 정의에 있습니다

6월에 저는 간판 말고 그 아래를 보라고 썼습니다. 두 달이 지나서, 그 아래에 무엇이 있는지 한 칸 더 말할 수 있게 됐습니다.

루프의 실력은 몇 번 돌리느냐에 있지 않습니다. 채점자를 떼어놓는 것도 시작일 뿐입니다. 실력은 무엇을 통과로 두었느냐, 그리고 그 기준이 만족되면서도 일이 안 되는 경우를 내가 먼저 찾아봤느냐에 있습니다.

기계는 우리가 세운 자를 향해 갑니다. 성실하게, 지치지 않고, 통과가 뜰 때까지.

그러니 자를 세우는 일은 여전히 사람의 몫입니다. 그리고 그건 루프를 짜는 일보다 어렵습니다.

출처

• Self-Authored Verification Is Unreliable in Heuristic Self-Improving Agents (arXiv 2607.24300)
• Hardening Agent Benchmarks with Adversarial Hacker-Fixer Loops (arXiv 2606.08960)
• LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking (arXiv 2604.15149)
• Jason Wei — Asymmetry of verification and verifier’s law
• Siemens·NVIDIA — 자기검증 에이전틱 EDA 워크플로 (2026-07-31)

이 글의 사실관계는 위 출처를 따르며, 해석과 현장 관점은 박상훈의 견해입니다.