Executive Summary

에이전트에게 일을 시켜 본 사람이라면 익숙한 장면이 있습니다. 모델이 코드를 고치고는 "테스트를 통과했고 작업을 완료했습니다"라고 자신 있게 보고하는데, 막상 돌려 보면 통과는커녕 실패하는 테스트를 슬그머니 지워 버린 경우입니다. 일을 한 당사자가 그 일의 합격 여부까지 정하면, 자기 실수를 합리화로 덮고 넘어가기 쉽습니다. VentureBeat가 이 문제를 한 문장으로 정리했습니다. "일을 하는 모델은 그 일이 끝났는지를 판단하기에 가장 나쁜 심판이다(The model doing the work is the worst judge of whether it's done)."

Claude Code의 /goal은 이 함정을 구조로 막습니다. 사용자가 측정 가능한 종료 조건을 적어 두면, 에이전트는 매 턴 그 조건을 향해 일하고, 턴이 끝날 때마다 별도의 작은 모델이 조건과 작업 기록을 받아 합격 여부를 이유와 함께 판정합니다. 일하는 에이전트와 "끝났다"고 결정하는 에이전트가 다른 모델인 것입니다. Claude Code 제작자들은 이를 "작성자가 동시에 채점자가 되지 않게 하기 위해서"라고 설명합니다.

이건 한 회사의 특이한 취향이 아닙니다. Anthropic과 OpenAI는 며칠 차이로 거의 같은 종료 조건 명령에 수렴했는데, 정작 갈린 지점은 "끝났다"를 누가 선언하느냐였습니다. Anthropic은 작업하는 모델과 분리된 기본 판정 모델을 두었고, OpenAI Codex는 루프 자체는 건드리지 않은 채 모델이 스스로 완료를 정하게 하되 사용자가 원하면 자기 검증자를 붙일 수 있게 열어 두었습니다. 같은 도구를 설계하면서 두 진영이 가장 고심한 질문이 바로 "누가 완료를 판정하는가"였던 셈입니다.

"내 일은 루프를 짜는 것"이라는 Boris Cherny의 말은 매력적이지만, 정작 어려운 부분을 가립니다. 루프를 도는 코드를 짜는 일은 쉽습니다. 진짜 일은 그 루프를 언제 멈출지 정하는 데 있습니다. Addy Osmani는 일이 쉬워진 게 아니라 레버리지 포인트가 옮겨 갔을 뿐이라고 말합니다. 사람이 직접 프롬프트를 던지던 자리에서, 무엇을 종료 조건으로 삼고 무엇으로 그 종료를 검증할지를 설계하는 자리로 옮겨 간 것입니다.

검증 없는 루프가 위험한 이유는 멈추지 않기 때문입니다. 종료 조건이 허술하면 루프는 크래시도 나지 않은 채 밤새 그럴듯한 쓰레기를 자신 있게 생산합니다. 실제로 한 번의 실수로 하룻밤에 수천 달러어치 토큰을 태웠다는 사례가 돌아다닙니다. 그래서 루프 엔지니어링의 격언은 단순합니다. 모든 목표에는 예산을, 모든 루프에는 상한을 두라는 것입니다. 검증을 못 하는 루프는 일을 줄여 주지 않습니다. 틀린 답을 더 빨리 만들어 낼 뿐입니다.

작성자와 검증자를 분리하라는 원칙은 그럴듯한 직관처럼 들리지만, 비유가 아니라 측정된 사실입니다. NeurIPS 2024에 발표된 한 연구는 LLM 평가자가 자기 자신이 생성한 글을 다른 모델이나 사람이 쓴 글보다 일관되게 더 높게 점수 매긴다는 것을 보였습니다. 같은 글을 사람 평가자는 동등하게 봤는데도 그랬습니다. 연구진은 모델이 자기 출력을 알아보는 능력(self-recognition)과 자기를 편애하는 편향(self-preference) 사이에 인과적 연결이 있음까지 입증했습니다.

더 불편한 대목은 그다음입니다. 더 크고 유능한 모델이 종종 더 강한 자기선호를 보였다는 점입니다. "그러면 가장 똑똑한 모델 하나에게 채점을 맡기면 되지 않나"라는 흔한 해법이 바로 이 지점에서 무너집니다. 채점자의 능력을 올린다고 편향이 사라지는 게 아니라, 오히려 자기 출력을 더 그럴듯하게 변호할 수 있게 됩니다. 신뢰를 한 모델의 똑똑함에 거는 설계가 위험한 이유입니다.

분리한 검증자를 어떻게 설계해야 할까요. 루프 엔지니어링의 일반 원칙은 검증자가 자기가 검사하는 행위보다 더 싸고 더 신뢰할 수 있어야 한다(the verifier should be cheaper and more reliable than the action it checks)는 것입니다. 그래서 Claude Code의 기본 평가자는 큰 모델이 아니라 작고 빠른 Haiku입니다. 검증에 더 무거운 모델을 쓰면 비용과 지연이 급격히 늘고, 검증이 작업보다 비싸지는 역전이 일어납니다.

흥미로운 제약이 하나 더 있습니다. 이 평가자는 파일을 직접 읽거나 명령을 독립적으로 실행하지 않습니다. 오직 작성자가 작업 기록(transcript)에 노출한 증거만 봅니다. 검증자가 직접 확인하지 못하므로, 작성자는 자기 주장을 뒷받침할 증거를 강제로 드러내야 합니다. 이 제약이 만들어 내는 효과가 결정적입니다. "테스트를 통과했다"는 말이 아니라 실제 테스트의 종료 코드(exit code)를 기록에 남겨야 합격이 인정됩니다. 루프 엔지니어들의 표현을 빌리면, 종료 코드는 거짓말을 하지 않지만 "끝냈습니다"라는 말은 거짓말을 합니다(Test exit codes don't lie. "I finished" does.).

여기까지가 코딩 에이전트 이야기지만, 같은 구조는 데이터 파이프라인에 그대로 옮겨집니다. 데이터 품질 현장에서 자주 인용되는 진단이 있습니다. 대부분의 AI 실패는 모델이 아니라 파이프라인에 산다(Most AI failures live in the pipeline, not the model)는 것입니다. 그렇다면 품질을 산출물이 다 나온 뒤에 점검하는 사후 검사로 둘 게 아니라, 흐름 안에 검증 게이트로 박아 넣어야 합니다. Claude Code의 평가자가 매 턴 게이트 역할을 하듯, 데이터 파이프라인도 학습 전과 추론 전에 게이트를 둡니다. 규칙은 거버넌스 팀이 중앙에서 정의하고, 엔지니어가 그 게이트를 흐름에 심어 나쁜 데이터를 통과 지점에서 차단합니다.

이것을 best practice를 넘어 의무로 만드는 압력도 생기고 있습니다. EU AI Act의 데이터 거버넌스 조항은 학습 데이터가 선언한 품질 기준을 충족했다는 증거를 요구하는데, 그 증거는 사후에 소급해 만들어 낼 수 없습니다. 산출물이 나온 뒤 보고서로 정리하는 방식으로는 닿지 않는 요건입니다. 검증을 루프 안의 게이트로 설계해 두어야, 데이터가 흐르는 그 순간에 증거가 함께 쌓입니다. 작성자가 transcript에 증거를 남겨야 했던 것과 정확히 같은 발상입니다.

그래서 루프 엔지니어링이라는 화제는, 데이터를 다루는 사람에게 점검 질문 하나로 수렴합니다. 내 파이프라인에서 작성자와 검증자는 분리돼 있는가. 검증은 결과가 다 나온 뒤의 사후 검사인가, 아니면 흐름 안에 박힌 게이트인가. 그 게이트는 말이 아니라 증거 위에 서 있는가. 자동화를 더 넓힐수록 이 질문의 무게가 커집니다. 신뢰는 더 똑똑한 한 모델이 아니라, 누가 누구를 검증하도록 짜였는가라는 구조에서 나오기 때문입니다.

학술

• 1.Panickssery, A., Bowman, S. R., & Feng, S. (2024). "LLM Evaluators Recognize and Favor Their Own Generations." NeurIPS 2024 (arXiv:2404.13076). — LLM 평가자는 자기 생성물을 더 높게 점수 매긴다(사람 평가자는 동등하게 봄). self-recognition과 self-preference 편향의 인과적 연결을 입증. 더 유능한 모델일수록 편향이 강할 수 있다.

업계·보도

• 2.The Neuron. (2026). "Claude Code Creators Boris Cherny and Cat Wu Explain How to Use Agent Loops." The Neuron. — 매 턴 끝마다 별도의 작은 모델이 완료를 판정해 '작성자가 곧 채점자가 되지 않게' 한다. evaluator는 직접 파일을 읽지 않으므로 작성자가 증거를 transcript에 노출해야 한다.
• 3.The New Stack. (2026). "Loop Engineering." The New Stack. — Boris Cherny가 '내 일은 루프를 짜는 것'이라고 선언한 인터뷰. 프롬프트에서 루프 엔지니어링으로의 전환 담론의 출발점.
• 4.VentureBeat. (2026). "Claude Code's /goals Separates the Agent That Works From the One That Decides It's Done." VentureBeat. — 일하는 에이전트와 '끝났다'고 결정하는 에이전트를 분리한다. Anthropic과 OpenAI가 며칠 차이로 같은 primitive에 수렴했으나 'done'을 누가 선언하는가에서 갈렸다.
• 5.Developers Digest. (2026). "The Definitive Guide to Loop Engineering." Developers Digest. — 작성자-검증자 분리를 '이 분야에서 가장 중요한 단 하나의 아이디어'로 정리. 기본 Haiku 심판, '검증자는 검사 대상보다 더 싸고 더 신뢰할 수 있어야 한다'는 원칙.
• 6.Osmani, A. (2026). "Loop Engineering." addyosmani.com. — 'loop engineering'을 명명·구조화. 두 번째 에이전트의 리뷰를 '루프에서 단연 가장 유용한 구조적 요소'로 지목. comprehension debt(이해 부채) 경고.