AI 모델은 거의 언제나 다음 답을 하나 더 만들어낼 수 있다. 문단을 다시 고쳐 쓰고, 다른 구현을 시도하고, 조명과 구도를 바꾼 이미지를 또 생성한다. 지치지도 않고, 최근 세 번의 수정이 결과를 다르게 만들었을 뿐 반드시 더 낫게 만든 것은 아니라는 사실도 스스로 알아차리지 못한다. 우리가 알아차릴 방법을 주지 않는 한 그렇다. a16z가 정리한 '루프 엔지니어링' 논의는 바로 이 지점에서 출발한다. 사람이 매번 프롬프트를 넣고 결과를 살피고 다시 지시하는 대신, 시스템이 그 주기 전체를 스스로 돌게 만들자는 발상이다. 문제는 '끝났다'는 판단이 작업물 자체의 속성이 아니라 작업을 둘러싼 시스템이 내리는 판단이라는 데 있다. 프로그래머는 테스트가 초록불이 되거나 리뷰가 승인될 때 멈추고, 작가는 마감이 왔거나 편집자가 수락했을 때 원고를 낸다. 완료 신호는 늘 작업의 바깥에서 온다.
검증기가 곧 방향이다
루프의 품질은 각 단계의 검증기(verifier) 만큼만 좋다. 사람을 루프에서 빼내는 순간, 매 단계에서 무엇을 검증할지 설계하는 일이 루프를 전진시키는 핵심이 된다. 흔한 코딩 에이전트 루프, 즉 '테스트가 통과할 때까지 계속하라'는 거의 완벽하게 검증 가능해 보인다. 그러나 테스트는 과제의 대리 지표일 뿐이다. 원문이 인용한 SpecBench에서 프런티어 에이전트들은 보이는 테스트는 통과하면서 같은 기능을 함께 시험하는 감춰진 테스트에서는 실패했고, 한 에이전트는 테스트 입력을 그대로 외워버린 2,900줄짜리 '컴파일러'를 만들어냈다. 루프는 수렴했지만 사용자의 의도가 아니라 검증기에 수렴한 것이다. 검증기는 정지 조건일 뿐 아니라 루프가 무엇을 '진전'으로 취급할지를 정의한다. 신호가 불완전하면 루프는 과제를 더 잘하지 못한 채 검사만 더 잘 통과하게 된다.
루프가 잘 작동한 첫 사례가 코딩이었던 것은 우연이 아니다. 코드는 편집 가능하면서 동시에 실행 가능하다. 함수 하나를 바꾸고 프로그램을 돌려 실패 원인을 읽고 다시 시도할 수 있다. 저자는 SVG나 Blender 장면 같은 시각 작업에서도 비슷한 패턴을 관찰한다. 이들은 경로, 도형, 지오메트리, 재질처럼 국소적으로 검사하고 수정할 수 있는 구조를 가진다. 반면 개방형 이미지 생성에서 '한 번 더'는 대개 샘플을 새로 뽑아 그중 나은 것을 고르는 일이며, '더 나빠 보인다'를 특정 편집 한 곳으로 연결하기 어렵다.
수렴에 필요한 네 가지
원문은 루프가 수렴하려면 네 가지가 필요하다고 정리한다. 첫째, '완료'가 무엇인지에 대한 표상이 있어야 한다. 테스트 스위트, 명세, 성능 제약, 참조 이미지 따위다. '더 좋게 만들어'는 목표 상태가 아니라 또 하나의 프롬프트일 뿐이다. 둘째, 지금 존재하는 것을 들여다볼 수 있어야 한다. 렌더링된 출력만으로는 부족하고 파일, 디프, 트레이스, DOM, 장면 그래프 같은 내부 구조가 있어야 오류의 출처를 짚는다. 셋째, 나머지를 다시 만들지 않고 오류에 책임 있는 부분만 국소적으로 고칠 수 있어야 한다. 넷째, 생성기 바깥에서 오는 정지 조건이 있어야 하며, 이 조건은 비용까지 고려해야 한다.
실무자에게 가장 뼈아픈 대목은 이것이다. 저자가 만난 거의 모든 연구자가 '적절한 도구 호출과 중간 프롬프트를 찾았을 때 비로소 루프가 돌기 시작했다'고 말했지만, 그 도구들을 사전에 아는 사람은 아무도 없다. 대부분 시행착오다. 그래서 루프는 자신의 스택에 맞춰 튜닝된다. 한 코드베이스에서 수렴시킨 도구 호출은 그 코드베이스에 대한 가정을 품고 있고, 그 가정은 다른 곳에서 더는 성립하지 않는다. 남이 공개한 루프가 그대로 마법처럼 통했다는 사람도, 전혀 작동하지 않았다는 사람도 동시에 나오는 이유다. 남의 루프는 보장이 아니라 출발점이다.
멈추는 법을 모르는 루프의 경제학
루프를 찾는 것은 초기 비용일 뿐이고, 진짜 비용은 매 개발 주기마다 그것을 돌리는 데 든다. '조건이 충족될 때까지 계속하라'는 가장 단순한 형태에서 문제는 '언제까지'다. 20회를 돌릴지 500회를 돌릴지 루프도 모르고, 시작 버튼을 누르는 개발자도 그 시점엔 모른다. 알려진 것은 곡선의 모양뿐이다. 테스트타임 컴퓨트 연구 대부분에서 수익은 로그 곡선을 그린다. 원문이 든 한 웹 에이전트 벤치마크에서 샘플을 1개에서 10개로 늘리자 성공률이 38.8%에서 43.2%로 올랐지만, 다시 20개로 두 배 늘렸을 때는 두 배의 토큰을 쓰고 0.2점을 더 얻었을 뿐이다. 정체 구간을 지나면 한계 반복은 오히려 해가 되어, 더 큰 예산을 받은 추론 모델이 이미 맞힌 답을 버리기 시작한다.
저자가 Anthropic의 루프 엔지니어링 글에 실린 예제를 직접 돌린 실험은 이 점을 선명하게 보여준다. 일부러 망가뜨린 페이지(Lighthouse 35점)에서 Claude Code는 첫 시도에 0.35달러로 98점을 냈고 루프는 아예 개입하지 않았다. 그래서 목표를 도달 불가능하게 바꿔, 같은 페이지에 2.2초의 인위적 지연을 걸어 점수 상한을 89점 근처로 묶은 뒤 100점을 요구했다. 처음 1.40달러가 점수를 26에서 89로 끌어올렸고, 전체 청구액의 67%에 해당하는 나머지 2.84달러는 정확히 0점을 샀다. 에이전트는 다섯 번째 시도쯤 지연 한계 때문에 목표가 불가능하다고 정확히 진단했지만, 평가 모델이 그 판단을 14번이나 되돌려 보냈다. 루프가 작동하지 않는다는 이야기가 아니다. 루프에는 멈출 줄 아는 감각이 없다는 이야기다.
한국 실무자를 위한 함의
국내 팀들도 코딩 에이전트를 자동화 루프로 감싸는 실험을 늘리고 있는 만큼, 이 글의 교훈은 구체적이다. 잘 멈추는 능력은 프롬프트로 불어넣을 수 없고 인프라를 요구한다. 지출을 계량하는 층, 진전을 그 지출에 견주어 측정하는 층, 그리고 루프를 끊어낼 만큼의 정보를 쥔 층이 각각 필요하다. 검증기 설계에 투자하지 않은 채 '조건 충족까지 반복'만 걸어두면, 가치는 대개 초반 3분의 1의 지출에서 다 나오고 나머지는 성장하는 트랜스크립트만큼 매 턴 더 비싸지는 헛돌기가 되기 쉽다. 또한 과제를 다시 표상하는 것 자체가 루프 엔지니어링의 본질임을 기억할 필요가 있다. 편집 가능성과 검증 가능성이라는 두 축에서, 개방형 이미지를 SVG 경로나 장면 그래프로 바꾸면 편집 가능 쪽으로, 참조 이미지나 제약을 주면 검증 가능 쪽으로 과제가 이동해 루프가 수렴하는 사분면에 놓인다. 다만 이 모든 것이 아직 시행착오의 영역이라는 점, 즉 보편적으로 통하는 루프를 찾는 일은 사람의 지식을 루프에 새겨 넣으려는 시도에 가깝다는 저자의 신중한 진단도 함께 새겨둘 만하다.