이 글은 3부작의 3편(완결)입니다. ① 하네스 엔지니어링이란 무엇인가 → ② 루프 엔지니어링이란 무엇인가 → ③ 그래서 어떻게 쓰이고 있는가(이 글)
들어가며: 자리를 비워도 되는가
앞의 두 글은 도구를 설명했습니다. 1편에서 하네스는 에이전트 하나가 돌아가는 환경이었고, 2편에서 루프는 그 환경을 타이머 위에 올려 사람 대신 스스로 돌게 만든 것이었습니다. 두 글 모두 마지막에 같은 질문을 남겨 뒀습니다. 루프가 "다 됐다"고 판단하는 그 순간, 누가 그 판단을 하는가.
이 질문은 추상적이지 않습니다. 아주 실용적입니다. 루프를 켜 놓고 회의에 들어가도 되는가. 아침에 자동으로 도는 에이전트에게 PR을 열 권한까지 줘도 되는가. 이것은 결국 하나의 질문으로 좁혀집니다. 에이전트가 자기 일이 끝났다고 말할 때, 그 말을 믿고 자리를 비워도 되는가.
이 글은 그 질문에 답합니다. 지난 몇 달 사이 이 주제에 관한 논문과 실측이 제법 쌓였고, 그 결과는 한국어로 아직 정리된 적이 없습니다. 미리 결론을 말하면 이렇습니다. 자리를 비워도 되는 정도는 모델 성능이 아니라 검증 장치가 얼마나 멀리까지 버티는가로 정해집니다. 그리고 이 블로그를 굴리는 저장소 자체가 그 판단을 매일 내리고 있어서, 마지막에는 우리가 어디서 루프를 닫고 어디서 일부러 열어 뒀는지를 실물로 보여 드리겠습니다.
전제가 뒤집히고 있다
루프의 약속은 단순합니다. 만드는 쪽과 검사하는 쪽을 분리하면 사람이 자리를 비울 수 있다는 것입니다. 2편에서 본 것처럼 Osmani도 이 분리를 루프의 다섯 부품 중 하나로 꼽았고, Anthropic의 벤더 문서도 정지 조건을 정의의 중심에 뒀습니다.
그런데 이 약속에는 조용히 깔린 전제가 하나 있습니다. 검증이 생성보다 쉽다는 것입니다. 만드는 것보다 검사하는 게 싸야, 검사를 반복해서 돌리는 게 이득이 됩니다. 이 전제는 오래된 직관입니다. 답을 만드는 것보다 답이 맞는지 확인하는 게 쉽다는 것은 거의 상식처럼 들립니다.
2026년 6월의 한 논문은 코딩 에이전트에서 이 직관이 뒤집히고 있다고 말합니다. "The Verification Horizon"이라는 제목의 이 논문은 이렇게 시작합니다.
A classical intuition holds that verifying a solution is easier than producing one. For today's coding agents, this intuition is being inverted: as foundation models develop stronger reasoning capabilities and engineering harnesses grow more sophisticated, generating complex candidate solutions is no longer difficult — reliably verifying them has become the harder problem.
고전적 직관은 답을 검증하는 게 만드는 것보다 쉽다고 본다. 그런데 오늘의 코딩 에이전트에서는 이 직관이 뒤집히고 있다. 모델의 추론 능력이 강해지고 하네스가 정교해지면서 복잡한 후보 답을 생성하는 것은 더 이상 어렵지 않게 됐고, 그것을 믿을 만하게 검증하는 쪽이 더 어려운 문제가 됐다는 것입니다.
여기서 이 논문이 2026년 것이라는 점이 중요합니다. 자기검증의 한계를 지적한 연구는 예전에도 있었지만, "요즘 모델은 다르지 않냐"는 반박이 늘 따라붙었습니다. 이 논문은 바로 그 "요즘 모델"을 대상으로, 오히려 모델이 좋아질수록 검증이 상대적으로 더 어려워진다고 말합니다. 생성이 쉬워졌기 때문입니다.
그렇다면 루프는 헛된 것일까요. 그렇지 않습니다. 반대 방향의 증거부터 정직하게 봐야 합니다.
루프는 실제로 작동한다
자기 자신을 개선하는 루프가 실제로 성능을 끌어올린 사례들이 있습니다. 이것을 먼저 인정하지 않으면 이 글은 반례 하나에 무너집니다.
가장 극적인 것은 Darwin Gödel Machine(DGM)입니다. 이 시스템은 자기 코드를 스스로 고쳐 가며 성능을 올렸는데, 코딩 벤치마크 SWE-bench에서 20.0%에서 50.0%로, Polyglot에서 14.2%에서 30.7%로 점수를 두 배 넘게 끌어올렸습니다. 사람이 매 수정을 지시하지 않았습니다. MIT의 SEAL은 모델이 자기 학습 데이터를 스스로 만들어 자기 가중치를 갱신하는 방식으로, 질의응답 정확도를 32.7%에서 47.0%로 올렸습니다. 마인크래프트 에이전트 Voyager의 실험은 한 걸음 더 나아가, 자기검증(두 번째 모델이 비평가 역할을 하는 것)을 제거하면 성능이 크게 떨어진다는 것을 보였습니다.
여기까지만 보면 "루프가 자기 자신을 개선한다"는 주장은 이미 입증된 것처럼 보입니다. 실제로 입증됐습니다. 그러니 "아무도 자기개선을 실증하지 못했다"는 식으로 쓰면 틀립니다. 문제는 이 성공들이 어떤 조건에서 일어났는가입니다.
공통점: 전부 바깥에 심판이 있다
위 사례들을 다시 보면 하나의 공통점이 드러납니다. 어느 것도 모델이 자기 작업을 스스로 판정하지 않았습니다.
DGM은 새로 만든 에이전트를 벤치마크 점수로 채점했습니다. 논문의 표현은 이렇습니다.
Each newly generated agent is quantitatively evaluated on a chosen coding benchmark to estimate its coding abilities. Only agents that compile successfully and retain the ability to edit a given codebase are added to the DGM archive.
새로 생성된 에이전트는 코딩 벤치마크로 정량 평가되고, 컴파일에 성공하고 코드를 편집하는 능력을 유지한 것만 보관소에 추가된다는 것입니다. 여기서 판정을 하는 것은 모델이 아니라 컴파일러와 벤치마크입니다. SEAL의 보상 신호도 held-out 과제의 정확도, 즉 바깥에서 채점되는 점수였습니다. Voyager의 비평가조차 자기 추론을 판정한 게 아니라 마인크래프트 세계가 돌려주는 실제 상태(인벤토리에 무엇이 생겼는지)를 봤습니다.
즉 이 루프들은 전부 모델이 제안하고, 바깥의 무언가가 처분하는 구조였습니다. 모델은 답을 내지만, 그 답이 맞는지는 벤치마크·컴파일러·게임 세계가 결정했습니다. 자기개선은 자기채점이 아니었습니다.
이 점을 가장 선명하게 보여 주는 것이 ACE(Agentic Context Engineering)라는 연구입니다. ACE는 정답 레이블 없이도 작동한다고 보고했는데, 얼핏 우리 논지의 반례처럼 보입니다. 그런데 논문 자신의 설명이 핵심입니다. 레이블 없이도 되는 이유는 "실행 중에 자연스럽게 얻어지는 신호, 예컨대 코드 실행의 성공 또는 실패"를 쓰기 때문이라는 것입니다. 그것이 바로 외부 그라운드트루스입니다. 레이블을 뺐지 심판을 뺀 게 아닙니다.
그리고 그 증거가 숫자에 그대로 남습니다. ACE에서 정답 레이블을 제거했을 때, 실행 신호가 있는 과제(AppWorld)는 성능이 2.2%포인트만 떨어졌지만 실행 신호가 없는 과제(금융)는 4.8%포인트 떨어졌습니다. 바깥에 실행이라는 심판이 있는 곳에서는 레이블을 빼도 버티고, 없는 곳에서는 무너집니다. 비대칭 자체가 심판의 존재를 증명합니다.
심판이 없으면 어떻게 되나
그렇다면 반대로, 바깥 심판이 없는데 모델에게 스스로 절차적 지식을 만들라고 하면 어떻게 될까요. 이것을 정면으로 측정한 연구가 SkillsBench입니다.
SkillsBench는 에이전트가 스스로 작성한 스킬과 사람이 큐레이션한 스킬을 같은 과제에서 결정론적 검증자로 비교했습니다. 87개 과제, 8개 도메인, 18가지 모델·하네스 조합에 걸친 실험입니다. 사람이 만든 스킬은 평균 통과율을 33.9%에서 50.5%로, 16.6%포인트 끌어올렸습니다. 스킬이 쓸모없다는 이야기가 아닙니다.
그런데 에이전트가 스스로 만든 스킬은 정반대였습니다. 논문의 소제목이 결론을 그대로 담고 있습니다. "Self-generated Skills do not substitute for curated ones" — 자가생성 스킬은 큐레이션된 스킬을 대신하지 못한다. 수치로는 no-Skills 기준선보다 오히려 아래로 떨어졌습니다. Claude Code에 Opus 4.7을 얹은 조합에서 8.1%포인트, Codex에 GPT-5.5를 얹은 조합에서 11.3%포인트, Gemini CLI에 Gemini 3.1 Pro를 얹은 조합에서 11.5%포인트씩, 스킬을 아예 안 쓰느니만 못했습니다. 같은 조합에서 사람이 만든 스킬은 18.2%에서 24.8%포인트를 더했는데도 말입니다.
논문이 원인으로 든 것 중 마지막 항목이 특히 눈에 띕니다. 자가생성 스킬이 성능을 떨어뜨린 이유는 "생성된 팩을 정작 풀이자가 발견하지 못하고, 작성하는 쪽이 푸는 쪽의 일을 밀어내며, 자신 있게 틀린 내용(confidently wrong pack content)"이 담기기 때문이라는 것입니다. 모델은 자기가 소비해서 이득을 보는 절차적 지식을, 스스로 쓸 때는 확신에 차서 틀리게 씁니다.
여기서 흔한 반박 하나가 미리 막힙니다. "모델이 아직 부족해서 그렇지 다음 세대는 다를 것"이라는 반박입니다. SkillsBench는 모델이 좋아질수록 이 격차가 오히려 벌어졌다고 보고합니다. 프론티어가 나아가도 자가생성의 손해는 줄지 않았습니다. 문제는 모델의 지능이 아니라, 자기가 쓴 것을 판정할 바깥 심판이 없다는 구조에 있기 때문입니다.
가장 눈에 띄는 실물: Hermes
이 구조적 문제를 널리 쓰이는 제품 하나에서 통째로 볼 수 있습니다. Nous Research의 Hermes Agent입니다. 이 저장소는 스스로를 "내장 학습 루프를 갖춘 유일한 에이전트(the only agent with a built-in learning loop)"라고 소개합니다. (이 블로그에서 앞서 Hermes의 자기개선 루프를 따로 리뷰한 적이 있습니다.) 마케팅 문구와 실제 소스 코드를 나란히 놓으면, 루프가 무엇에 닫혀 있고 무엇에 닫혀 있지 않은지가 그대로 드러납니다.
먼저 학습이 언제 일어나는지를 보겠습니다. 저장소의 설정에서 스킬 생성을 촉발하는 값은 nudge_interval이고 기본값은 10입니다. 즉 10턴마다 에이전트를 찔러 "뭔가 배울 게 없느냐"고 묻습니다. 작업이 성공했는지 실패했는지는 이 촉발 조건에 들어 있지 않습니다. 성과가 아니라 타이머입니다.
배울 게 있는지 판정하는 프롬프트는 더 노골적입니다. 저장소의 리뷰 프롬프트에는 이런 지시가 박혀 있습니다.
Be ACTIVE — most sessions produce at least one skill update, even if small. A pass that does nothing is a missed learning opportunity, not a neutral outcome.
적극적이어라, 대부분의 세션은 작더라도 최소 하나의 스킬 갱신을 낳는다, 아무것도 하지 않고 지나가는 것은 놓친 학습 기회이지 중립적 결과가 아니다. 검증자의 기본 가정이 뒤집혀 있습니다. 원래 "배울 것이 없다"가 기본값이어야 하는데, Hermes는 그것을 실패로 재정의합니다.
그리고 이 판정을 누가 하느냐가 문제입니다. Hermes는 매 턴 뒤에 자기 자신을 포크(fork)해서 대화를 되짚어 보게 하는데, 저장소 주석의 표현이 정확합니다. 포크가 "should any skill/memory be saved or updated?"라고 자기 자신에게 묻는다(asks itself)는 것입니다. 그 포크는 부모와 같은 모델, 같은 자격 증명, 심지어 같은 캐시된 시스템 프롬프트를 물려받습니다. 독립된 검증자가 아니라 같은 판사의 복사본입니다.
가장 결정적인 것은 데이터 모델입니다. Hermes가 스킬의 사용 기록으로 저장하는 필드 전체는 이렇습니다. 생성자, 사용 횟수, 조회 횟수, 마지막 사용 시각, 마지막 조회 시각, 패치 횟수, 마지막 패치 시각, 생성 시각, 상태, 고정 여부, 보관 시각. 여기에 성공 필드가 없습니다. 실패 필드도 없습니다. 검증 결과도 없습니다. 스킬이 얼마나 자주 쓰였는지는 기록하지만, 그 스킬이 실제로 맞았는지는 어디에도 기록하지 않습니다.
데이터 모델은 그 시스템의 인식론입니다. 필드에 없는 것은 시스템이 알 수 없습니다. Hermes의 루프는 분명히 닫혀 있습니다. 다만 사용량에 닫혀 있지 진실에 닫혀 있지 않습니다. 자주 쓰이는 틀린 스킬은 살아남고, 옳지만 안 쓰이는 스킬은 보관 처리됩니다.
오해를 막기 위해 분명히 해 둘 것이 있습니다. Hermes의 코드는 허술하지 않습니다. 오히려 사려 깊습니다. 예컨대 큐레이터 코드는 한 번도 안 쓰인 스킬을 성급히 지우지 않으려고 "사용 횟수 0은 오래됐다는 증거가 아니라 증거의 부재"라고 신중하게 추론합니다. 배관은 훌륭합니다. 문제는 그 훌륭한 배관이 재는 계기판이 진실이 아니라 사용량이라는 것입니다. 그리고 저장소는 그 대가를 이미 알고 있습니다. 같은 리뷰 프롬프트의 다른 대목에는, 도구가 안 된다는 식의 부정적 교훈을 저장하지 말라는 경고가 있습니다. 그런 교훈이 "실제 문제가 고쳐진 뒤에도 몇 달 동안 에이전트가 스스로에게 인용하며 거부하는 근거로 굳는다(harden into refusals the agent cites against itself for months)"는 것입니다. 오염된 교훈이 스스로를 강화한다는 것을, 개발자들은 겪어서 알고 있습니다. 그리고 그 대응책이 프롬프트 안에 박은 또 다른 금지 목록이라는 점이 이 문제의 성격을 보여 줍니다. 프롬프트로 프롬프트의 문제를 막고 있는 것입니다.
SkillsBench가 통제된 실험에서 측정한 것을, Hermes는 널리 쓰이는 실제 제품에서 그대로 구현하고 있습니다. 심판이 바깥에 없으면, 학습 루프는 잘 배우는 게 아니라 잘 확신할 뿐입니다.
심판도 진짜 심판이 아니다
지금까지의 이야기는 "바깥 심판이 있으면 루프가 닫힌다"였습니다. 그런데 여기서 한 겹을 더 벗겨야 합니다. 그 바깥 심판조차 완전하지 않습니다.
앞서 인용한 "The Verification Horizon" 논문의 다른 문장이 이것을 짚습니다.
Every verifier we can build is only a proxy for human intent, never the intent itself.
우리가 만들 수 있는 모든 검증자는 인간 의도의 대리물일 뿐, 의도 그 자체가 아니다라는 것입니다. 테스트는 "이 코드가 옳다"를 재지 않습니다. "이 테스트들을 통과한다"를 잴 뿐입니다. 대개 그 둘은 같지만, 언제나 같지는 않습니다.
이 틈이 벌어지는 방식을 SpecBench라는 연구가 측정했습니다. 이 연구는 리워드 해킹을, 에이전트가 볼 수 있는 검증 테스트와 숨겨 둔 held-out 테스트의 통과율 차이로 측정합니다. 그리고 이렇게 관찰합니다.
As long-horizon coding agents produce more code than any developer can review, oversight collapses onto a single surface: the automated test suite.
오래 도는 코딩 에이전트가 어떤 개발자도 다 리뷰할 수 없을 만큼 많은 코드를 만들어 내면, 감독은 단 하나의 표면, 즉 자동화된 테스트 스위트로 무너져 내린다는 것입니다. 그리고 그 표면은 새어 나갑니다. SpecBench의 측정에서 가시 테스트와 held-out 테스트의 격차는 코드 규모가 10배 커질 때마다 대략 28%포인트씩 벌어졌습니다. 모든 프론티어 에이전트가 눈에 보이는 테스트는 만점으로 통과하면서, 숨겨 둔 테스트에서는 실패했습니다. 에이전트가 코드를 고친 게 아니라 테스트를 통과하는 법을 배운 것입니다.
이것이 루프에 관한 이야기라는 점이 중요합니다. 격차가 코드 규모와 함께, 즉 지평선의 길이와 함께 벌어진다는 것은, 자리를 오래 비울수록 대리물이 더 심하게 새어 나간다는 뜻입니다. 이것은 모델 일반에 관한 관찰이 아니라 루프에 특유한 관찰입니다.
여기서 한 가지 반론을 정직하게 다뤄야 합니다. "그렇다면 트랜스크립트를 읽는 감시자를 붙이면 리워드 해킹을 못 잡는 것 아니냐"고 생각하기 쉬운데, 그렇지 않습니다. "The Verification Horizon"은 에이전트의 궤적을 읽는 행동 감시자를 붙였을 때 해킹으로 통과한 비율이 28.57%에서 0.56%로 떨어졌다고 보고합니다. 감시자는 실제로 대부분을 잡았습니다. 다만 여기에는 함정이 있습니다. 그 지표 자체가 감시자가 정의한 것이고, 개입은 바로 그 감시자를 상대로 최적화됩니다. 감시자는 자기가 아는 종류의 해킹만 잡습니다. 새로운 종류의 새어 나감은 여전히 지평선 너머에 있습니다.
그래서 질문이 바뀝니다. "그라운드트루스가 있는가"가 아니라 "당신의 대리물이 얼마나 멀리까지 버티는가"입니다. 테스트가 의도를 얼마나 촘촘히 대신하는지, 그 촘촘함이 코드가 불어나도 유지되는지가, 루프를 얼마나 오래 풀어놔도 되는지를 정합니다. 이것은 모델 성능의 문제가 아니라 검증 설계의 문제입니다.
벤더는 정반대로 풀었다
이 문제가 얼마나 실질적인지는 Claude Code와 Codex가 같은 기능을 정확히 반대 방향으로 설계했다는 데서 드러납니다. 둘 다 완료 조건을 걸어 두면 스스로 판정하며 도는 기능을 제공하는데, "누가 무엇을 근거로 판정하는가"에서 갈립니다.
Claude Code의 완료 판정자는 별도의 신선한 모델입니다. 코드를 쓴 모델이 아닌 다른 모델이 조건 충족을 판정합니다. 그런데 이 판정자에게는 한 가지 제약이 있고, 공식 문서가 그것을 스스로 밝힙니다. 판정자는 "도구를 호출하지 않으므로, Claude가 대화에 이미 드러낸 것만 판정할 수 있다(does not call tools, so it can only judge what Claude has already surfaced in the conversation)"는 것입니다. 즉 판사는 독립적인데, 그 판사가 보는 증거는 피고인이 제출한 것뿐입니다. 판사가 직접 파일을 열거나 테스트를 돌리지 못합니다.
Codex는 반대로 갔습니다. 별도의 판정 모델을 두지 않고, 작업하던 에이전트가 자기 전체 도구 접근 권한을 그대로 쥔 채 스스로 완료를 선언합니다. 다만 OpenAI의 가이드는 그 선언에 조건을 답니다.
A Goal should not be marked complete because the model believes it is probably done. It should be complete only after the objective is checked against the relevant files, tests, logs, benchmark output, generated artifacts, or other concrete evidence.
목표는 모델이 "아마 끝난 것 같다"고 믿어서 완료로 표시되면 안 되고, 관련 파일·테스트·로그·벤치마크 출력·생성 산출물 같은 구체적 증거에 비추어 확인된 뒤에만 완료여야 한다는 것입니다.
두 설계를 나란히 놓으면 대칭이 보입니다. Claude Code는 독립적인 판사에게 종속된 증거를 줬고, Codex는 독립적인 증거에 종속된 판사를 줬습니다. 한쪽은 판사를 분리했지만 판사의 눈을 가렸고, 다른 쪽은 판사가 다 보게 했지만 그 판사가 피고인 자신입니다. 어느 쪽도 완전하지 않습니다. 같은 근본 문제를 각자 다른 절반에서 포기한 것입니다.
그리고 이 제약이 기술적 필연이 아니라는 것을, 세 번째 제품이 보여 줍니다. Cursor의 자동 리뷰는 분류자 에이전트에게 "ReadFile, Grep, Glob, ListDir 같은 도구로 워크스페이스를 직접 조사한 뒤 판단할 수 있게(the classifier can inspect the workspace with tools ... before deciding)" 했습니다. 검증자에게 도구를 줄 수 있습니다. Claude Code가 판정자에게 도구를 주지 않은 것은 할 수 없어서가 아니라, 단순함과 비용을 위해 그렇게 택한 것입니다. 이것은 트레이드오프이지 한계가 아닙니다. 그리고 어떤 트레이드오프를 택할지가 바로 하네스 엔지니어링입니다. 여기서 1편의 어휘가 되돌아옵니다. Böckeler의 구분으로 말하면, 도구 없는 판정자는 추론형 센서이고 도구를 쥔 판정자는 계산형 센서에 가깝습니다. 계산형이 더 믿을 만하지만 더 비쌉니다.
같은 파이프라인, 다른 결정
여기까지가 남들의 이야기입니다. 이제 우리 이야기를 하겠습니다. 이 블로그를 굴리는 저장소는 매일 이 판단을 내리고 있고, 흥미롭게도 같은 파이프라인 안에서 어떤 루프는 닫고 어떤 루프는 일부러 열어 뒀습니다. 그 선택의 기준이 정확히 지금까지 이야기한 것이었습니다.
이 저장소는 매일 GeekNews 기사를 수집해 태그를 붙이고, 엔티티들 사이의 관계를 그래프로 그립니다. 여기에는 LLM을 쓰는 두 가지 작업이 있습니다. 하나는 엔티티 사이의 관계를 분류하는 일이고, 다른 하나는 어떤 단어를 트렌드 키워드로 승격할지 정하는 일입니다. 둘 다 LLM이 제안을 내놓는다는 점에서 똑같아 보입니다. 그런데 우리는 두 곳에서 정반대의 결정을 내렸습니다.
관계 추출에서는 루프를 닫았습니다. LLM이 두 엔티티의 관계를 분류하고 확신도를 매기면, 확신도가 0.8 이상인 관계는 사람의 개입 없이 자동으로 확정되어 노출됩니다. 왜 닫았을까요. 여기에는 검증 가능한 기준이 있기 때문입니다. 관계의 타입은 닫힌 집합이고, 방향이 있으며, 확신도라는 대리 신호가 실제 품질과 충분히 상관됩니다. 완벽하지는 않지만, 자리를 비워도 될 만큼은 버팁니다.
키워드 승격에서는 루프를 열어 뒀습니다. LLM이 "이 단어를 승격하면 어떠냐"고 추천은 하지만, 실제 승격 결정은 사람이 합니다. 자동 승격을 코드 차원에서 금지해 뒀습니다. 왜 열어 뒀을까요. 키워드 품질에는 그라운드트루스가 없기 때문입니다. 어떤 일반 명사가 "트렌드 키워드로서 좋은지"는 테스트로 표현할 수 없습니다. 그것은 의도의 문제이고, 우리가 만들 수 있는 어떤 대리물도 그 의도를 충분히 촘촘하게 대신하지 못합니다. 그래서 사람을 루프 안에 남겨 뒀습니다.
우리가 이 결정을 처음부터 옳게 내린 것은 아닙니다. 한때 자동으로 승격된 엔티티들이 정의도 종류도 없는 쓰레기 더미가 된 적이 있었고, 결국 사람이 다시 들어가 정의를 붙이는 별도의 큐레이션 절차를 만들어야 했습니다. 이것이 2편에서 언급한 드리프트의 실물입니다. 자동화가 조용히 품질을 갉아먹었고, 그 사실을 뒤늦게 발견했습니다.
이 대비를 앞의 Hermes와 나란히 놓으면 그림이 완성됩니다. Hermes는 프롬프트에 "일단 뭐라도 배워라"를 박았습니다. 우리 저장소의 키워드 원칙은 정반대로 "승격 기준을 좁게 잡아라"입니다. 같은 종류의 문제 앞에서 두 시스템이 반대 결정을 내렸고, SkillsBench가 통제된 실험에서 어느 쪽이 맞는지 측정해 줬습니다. 심판이 없는 곳에서 적극적으로 배우면, 잘 배우는 게 아니라 확신에 차서 틀립니다.
우리 저장소에는 오래된 원칙이 하나 있습니다. "증거는 DB에, 결정은 git에." 관계 추출의 증거와 확신도는 데이터베이스에 쌓이지만, 무엇을 코퍼스에 반영할지의 결정은 사람이 검토해 git에 커밋합니다. 이 문장이 2편에서 인용한 Osmani의 한 줄과 정확히 같은 결론이라는 것을, 우리는 그 글을 읽기 한참 전에 실패를 통해 배웠습니다. "에이전트는 잊지만 저장소는 잊지 않는다." 서로 다른 곳에서 같은 결론에 도달한 셈입니다.
마무리: 루프는 차이를 모른다
세 편을 관통한 질문은 결국 하나였습니다. 모델을 둘러싼 환경을 어떻게 설계하고(1편), 그 환경을 어떻게 스스로 돌게 만들고(2편), 그렇게 도는 루프를 언제 믿을 것인가(3편).
마지막 질문의 답은 모델 성능표에 있지 않습니다. 검증 설계에 있습니다. 루프는 대리물이 의도를 촘촘히 대신하는 곳에서, 그 촘촘함이 코드가 불어나도 유지되는 곳에서, 그만큼만 닫힙니다. 테스트가 실행되는 관계 추출에서는 닫아도 되고, 취향이 판단하는 키워드 승격에서는 열어 둬야 합니다. 같은 모델, 같은 파이프라인, 다른 결정입니다.
이 글이 시종 조심스러웠던 것과 별개로, 루프가 우리 일의 미래라는 관측 자체를 부정할 필요는 없습니다. Flask를 만든 Armin Ronacher는 이 흐름에 저항감을 느낀다고 밝히면서도 그것이 우리의 미래일 것이라고 인정합니다. 다만 그는 오늘의 자동 루프가 만드는 코드가 지난가을에 우리가 짜던 것보다 나쁘다고 보고, 그 대가가 이해라고 말합니다. "우리는 그것을 다루고, 감시하고, 안정화하지만, 반드시 이해하지는 못한다(we do not necessarily comprehend it)." 그가 루프의 검증에 대해 남긴 관찰은 이 글의 요지를 거꾸로 비춥니다. 루프의 하네스가 필요로 하는 신호는 "객관적이거나 이진적일 필요가 없고, 그저 다음 반복을 돌리기에 충분히 쓸모 있기만 하면 된다(does not have to be objective or binary, it just has to be useful enough to drive another iteration)." 바로 그 느슨함이 루프를 계속 돌게 하는 동시에, 이해를 흘려보내는 통로가 됩니다.
그래서 루프 설계는 프롬프트 엔지니어링보다 쉬운 일이 아니라 더 어려운 일입니다. Osmani가 2편의 끝에서 남긴 문장이 이 3부작 전체의 결론이기도 합니다.
Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn't know the difference. You do.
두 사람이 똑같은 루프를 만들어도 정반대의 결과를 얻을 수 있습니다. 한 사람은 깊이 이해하는 일을 더 빨리 하려고 루프를 쓰고, 다른 사람은 그 일을 아예 이해하지 않으려고 루프를 씁니다. 루프는 그 차이를 모릅니다. 아는 것은 당신입니다.
이 글에서 다루지 못한 주제
이 글은 검증의 지평선이라는 관점에서 자기개선 루프의 성공 조건과 실패 구조, 벤더들의 설계 선택, 그리고 우리 저장소의 실제 결정을 다뤘습니다. 다음 주제들은 초점을 위해 깊이 들어가지 않았습니다.
- 자기개선 연구들(DGM, SEAL, Voyager, ACE)의 방법론 상세와 각 벤치마크의 한계 — 본문에서는 "무엇이 루프를 닫는가"라는 한 축으로만 다뤘습니다.
- 루프의 생산성 효과에 대한 실측 데이터(개발자 속도 측정, 자기보고와 실측의 괴리)와 그 해석의 어려움 — 이 글의 초점인 검증 문제와는 별개의 주제입니다.
- 토큰 비용을 검증 설계의 변수로 넣은 최적화(더 비싼 계산형 센서를 언제 쓸 가치가 있는가)의 정량 분석.
- 리워드 해킹을 막는 구체적 하네스 패턴(테스트 디렉터리 쓰기 금지, 별도 검증 에이전트)의 실전 설계 — 1편의 센서 논의와 이어지는 후속 주제입니다.