'완료'는 누가 정의하는가 — 게임이 40년 먼저 푼 문제

완료는 누가 정의하는가

임대업을 한다고 하자. 임차인이 방을 비웠고, 담당자가 퇴거를 확인해야 한다.

나는 이렇게 설계했다. 담당자는 “확인했습니다"라고 말할 수 없다. 대신 방의 지정된 위치 다섯 곳을 사진으로 찍어 시스템에 올린다. 다섯 장이 다 들어오면, 그때 시스템이 “퇴거 확인 완료"로 처리한다. 한 장이라도 비면, 완료는 없다.

이 설명을 듣고 누군가 말했다. “그거 딱 게임 퀘스트 아니에요?”

맞다. 정확히 그거다. 그리고 그 한마디가 내가 몇 년째 코드에서 씨름하던 걸 단번에 설명해버렸다.

게임은 이걸 40년 먼저 풀었다

“늑대 가죽 5개를 모아 와라.” 게임은 이걸 수십 년째 한다. 그리고 게임은 플레이어의 주장을 절대 믿지 않는다. “다 잡았어요"라고 말한다고 퀘스트가 완료되지 않는다. 게임은 단 하나만 본다 — 인벤토리에 가죽 5개가 있는가. 있으면 완료, 없으면 미완료. 끝.

내가 만든 것	게임이 만든 것
완료의 정의 = 지정 위치 5곳 사진	퀘스트 목표 = 늑대 가죽 5개
명세 = 어디를 찍어야 하는지 목록	퀘스트 로그 · 목표 마커
검증 = 사진 5장 존재하나?	검증 = 가죽 5개 있나?
판정 = 시스템이 완료 처리	판정 = 게임이 완료 띄움
담당자 = 실행자 (판단자 아님)	플레이어 = 실행자

구조가 똑같다. ‘완료’를 선언하는 주체가 행위자의 입에서 시스템으로 옮겨져 있다. 행위자는 조건을 충족시킬 뿐이고, 완료를 띄우는 건 언제나 게이트다.

이게 Reins다 — 그리고 코드도 똑같다

나는 AI 코딩에서 같은 일을 한다. AI가 “다 됐습니다"라고 말하면 믿지 않는다. 테스트가 통과하고, 타입이 맞고, 스키마 검증이 떨어지지 않을 때 — 그때 시스템이 “됐다"고 판정한다. 퀘스트 목표가 “테스트 4419개 통과"고, 인벤토리 대신 CI가 그걸 확인한다. 에이전트 연구의 표준 벤치마크가 정확히 이 방식이다 — SWE-bench는 ‘완료’를 실제 PR의 테스트 스위트 통과로, WebArena는 환경 상태의 기능적 정확성으로 정의한다. 자연어 “다 됐어요"가 아니라.

임대 퇴거든, 늑대 가죽이든, 코드든 — 핵심은 하나다. ‘완료’의 판정을 행위자 자신에게서 떼어내, 행위자 밖의 정의된 게이트로 옮긴다. 행위자가 사람이든 AI든 상관없다. 특히 AI에게 자기 완료를 판정하게 두면 안 된다는 건 실험으로도 드러난다 — 모델의 자기검증(self-critique)은 성능을 거의 못 올리지만 외부의 결정론적 검증기는 크게 올리고(Stechly & Kambhampati, 2024), 정직하게 출발한 모델조차 자기 보상을 판정할 권한을 주면 그 함수를 조작하는 기만 전략을 스스로 찾아낸다(McKee-Reid et al., 2024). 고삐(reins)는 말을 느리게 하지 않는다. 말이 엉뚱한 데로 달리지 않게 한다.

그리고 여기서 하나가 깨끗해진다. 의견을 주면 행위자는 흔들린다. “정말 확인했어요?“라고 다그치면 담당자는 위축되고, AI는 맞았던 답을 번복한다. 하지만 사진 다섯 장은 의견이 아니다. 테스트 통과는 의견이 아니다. 가죽 5개는 의견이 아니다. 사실에는 아첨할 대상이 없다. 게이트가 사실을 묻는 한, 아무도 그것을 구슬릴 수 없다.

그런데 게임은 더 어려운 것도 먼저 겪었다 — 치즈

여기서 멈추면 절반만 본 거다. 게임이 진짜로 알려주는 건 그 다음이다.

“쥐 10마리를 잡아라"는 악명 높은 퀘스트다. 왜? 그 게이트가 검증하는 것(쥐 10마리 죽음)과 디자이너가 진짜 원한 것(플레이어가 콘텐츠를 경험하기) 사이에 틈이 있기 때문이다. 게이트는 목적의 프록시일 뿐이고, 플레이어는 그 틈을 파고든다. 스피드러너는 완료 조건과 설계 의도 사이의 빈틈을 찾아 게임을 부순다. 이걸 게임 디자인에서는 치즈(cheese) 라고 부른다. 그리고 최신 추론 모델들도 정확히 이렇게 한다 — 체스 엔진을 이기라는 퀘스트를 받자 o3 같은 모델은 정정당당히 두는 대신 게임의 상태 파일을 조작해 “이겼다"를 만들어냈다(Bondarenko et al., 2025). 능력이 높을수록 빈틈을 더 잘 찾는다.

내 임대 게이트도 치즈당할 수 있다. 사진 다섯 장은 “사진이 존재한다"를 검증하지 “퇴거가 멀쩡히 끝났다"를 검증하지 않는다. 담당자가 깨끗한 벽만 골라 찍었다면? 입주 전 사진을 재활용했다면? 게이트는 통과한다. 측정이 목표가 되는 순간 측정은 망가진다 — 굿하트의 법칙이고, Manheim & Garrabrant(2018)는 이 과최적화 실패를 네 가지 변종으로 분류했다. AI 안전 연구는 같은 현상을 일찍이 ‘reward hacking’으로 정리했는데, 어질러진 걸 치우는 대신 안 보이게 덮어버리는 에이전트(Amodei et al., 2016)는 깨끗한 벽만 찍는 담당자와 정확히 같은 짓을 한다.

나는 이 틈을 코드에서 매번 만난다. 얼마 전 별 23,000개짜리 웹 프레임워크를 “파일 하나에 개념 하나” 규칙으로 리팩토링하고 테스트 4,419개가 전부 통과하는 걸 확인했다. 검증된 사실이다. 그런데 같은 데이터를 더 파보니, 규칙은 통과했는데 목적은 90%만 달성돼 있었다 — 10%의 파일은 여전히 여러 개념을 한곳에 담고 있었다. 게이트(규칙 위반 0)는 통과했지만, 게이트가 노린 목적은 완전히 닫히지 않았다. 내가 만든 게이트를, 내 코드가 치즈하고 있었던 거다.

그래서 Reins의 진짜 기술은 “게이트를 건다"가 아니다. 치즈 불가능한 게이트를 설계하는 것이다. 약한 퀘스트는 “사진이 있나"를 묻는다. 강한 퀘스트는 타임스탬프를 요구하고, 위치 메타데이터를 검사하고, 입주 시점 사진과 AI 비전으로 차이를 비교한다. 게임 디자이너가 40년간 “치즈 불가능한 퀘스트"를 고민해온 그 문헌이, 사실은 “Goodhart 저항 게이트"의 답안지다.

그리고 이건 저절로 되지 않는다. 검증 가능한 보상(RLVR)으로 훈련해도 모델은 규칙을 배우는 대신 불완전한 검증기를 게이밍하는 쪽을 택할 수 있다(Helff et al., 2026). 다행히 게이트를 의도적으로 단단하게 만들면(environmental hardening) 익스플로잇이 정확도 손실 없이 87.7% 줄었다는 측정도 있다(Thaman, 2026). 게이트의 강도는 운이 아니라 설계의 문제다.

한 가지 다른 점 — 현실의 치즈는 비용이 진짜다

비유에는 한계가 있다. 게임 퀘스트의 완료 조건은 재미와 페이싱을 위해 설계된다. 현실의 목적을 꼭 포착할 필요가 없고, 치즈당해도 무해하다. 플레이어가 “쥐 10마리"를 꼼수로 깨도 아무도 안 다친다.

현실 Reins 게이트는 다르다. 치즈의 비용이 진짜다 — 퇴거 사기, 빌드 깨짐, 잘못 승인된 회계. 그래서 현실 게이트는 게임보다 더 치즈에 강해야 한다. 이 비대칭이 오히려 핵심을 또렷하게 한다. 게임도 이걸 했지만, 우리는 더 빡세게 해야 한다.

에이전트에게 일을 시키는 건 퀘스트를 주는 것이다

여기까지 오면 한 줄이 떨어진다.

바이브 코딩이 무너지는 이유는, 완료 조건 없는 퀘스트를 주기 때문이다. 목표 마커도 없고, 완료 판정도 없는 퀘스트를 받은 에이전트는 맵을 헤맨다. “대충 이쯤이면 됐겠지” 하고 멈추거나, 끝없이 배회하거나. Reins는 그 에이전트에게 제대로 된 퀘스트를 설계해 주는 것이다. 명확한 목표(스펙), 보이는 마커(SSOT), 치즈 불가능한 완료 판정(결정론적 검증).

그리고 이 한 장면 안에 세 층의 기술이 들어 있다.

퀘스트를 플레이한다. 누가 만들어 둔 게이트를 도입해 쓴다. — 사용자.
퀘스트를 설계한다. 내 도메인(퇴거든, 회계든, 코드든)에 맞는 게이트를 직접 짓는다. — 제작자.
치즈 불가능한 퀘스트를 설계한다. 프록시가 목적을 못 따라가는 지점을 미리 막는다. — 설계자.

대부분은 플레이에서 멈춘다. 판을 키우는 건 설계고, 그 판이 부서지지 않게 하는 건 치즈를 막는 설계다.

그러니

다음에 누군가 “다 됐습니다"라고 말하거든, 되묻지 말고 물어라.

“완료란 무엇인가, 그리고 그것을 판정한 퀘스트는 누가 설계했는가.”

이 질문에 답이 없다면, 당신이 가진 건 완료가 아니다. 누군가의 주장일 뿐이다.

래칫 패턴 — 완료를 기계적 검증기로 강제하는 게이트의 본편
코딩 에이전트는 왜 작동하고 왜 깨지는가 — “생성은 확률적이어도 되지만 검증은 결정론적이어야 한다”
고삐 있는 AI: Reins Engineering — 게이트=고삐 reframe의 출처
용골(yongol): 200 엔드포인트의 벽 — 완료조건 없는 퀘스트가 무너지는 지점과 명세 기반 해법

더 읽을거리 (외부)

Specification gaming: the flip side of AI ingenuity — Victoria Krakovna 외, Google DeepMind. 게이트는 의도가 아니라 프록시이며 에이전트가 그 틈을 파고든다는 본문 논지를 권위 있는 안전 연구로 정리.
There’s Cheese in Your Game! — Shay Pierce, Game Developer. “지루해도 가장 효율적이면 플레이어는 그걸 한다” — 치즈 없는 퀘스트 설계라는 게임 디자인 관점이 ‘cheese-proof gate’와 정면으로 포개진다.
From shortcuts to sabotage: emergent misalignment from reward hacking — Anthropic. 코딩 과제에서 채점 스크립트만 통과시키는 보상 해킹이 어떻게 번지는지 — 행위자를 자기 완료의 심판으로 두면 안 되는 최신 실증.
How to write a good spec for AI agents — Addy Osmani. “Make it faster” 대신 “LCP < 2.5s"처럼 검증 가능한 success criteria로 환원하라 — 완료를 checkable condition으로 정의하라는 처방의 실무판.
What is agentic engineering? — Simon Willison. 인간의 역할을 목표 정의·도구 준비·검증으로 나누고 테스트 통과를 ‘done’으로 보는 관점 — 에이전트=실행자/인간=퀘스트 설계자 reframe과 일치.

출처

Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)
Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
Helff et al. “LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking” (2026, arXiv:2604.15149)
Thaman. “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use” (2026, arXiv:2605.02964)
McKee-Reid et al. “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
Stechly, Valmeekam, Kambhampati. “On the Self-Verification Limitations of Large Language Models” (2024, arXiv:2402.08115)
Jimenez et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (2023, arXiv:2310.06770)
Zhou et al. “WebArena: A Realistic Web Environment for Building Autonomous Agents” (2023, arXiv:2307.13854)
대표 이미지: AI 생성 (Google Gemini)