루프의 병목은 판정으로 옮겨갔다

한 달 전에 루프에 관한 글을 하나 썼다. "루프는 모두에게 필요하지 않다"는 제목이었고, 결론은 이랬다. 루프의 최소 단위는 cron에 결정자를 한 명 앉힌 것이고, 부품을 뜯어보면 전부 조직을 운영해 본 사람에게 익숙한 어휘이며, 값을 하는 조건은 네 가지뿐이다. 그 글을 다시 읽었다. 결론 자체가 틀렸다고는 생각하지 않는다. 다만 그 글은 "이걸 언제 써야 하는가"에는 답했지만 "왜 이 얘기가 몇 달 간격으로 계속 돌아오는가"에는 답하지 않고 있었다.

이후 몇 주간 루프를 더 파고들면서 원전을 다시 찾아 읽었다. Geoffrey Huntley가 처음 ralph를 설명한 글, Anthropic이 나중에 만든 ralph-wiggum 플러그인의 README, 얼마 전 나온 Claude Code의 dynamic workflows 발표까지. 그 과정에서 지난 글에 실제로 구멍이 있었다는 걸 알았다. 조건이 갖춰지면 쓰고 아니면 안 쓴다는 판단 기준은 정지 사진 한 장이었다. 그 사진 속에서 뭐가 움직이고 있었는지를 놓쳤다.

이 글은 그 움직임을 다시 본다. 병목이 어디로 옮겨갔는지, ralph의 정지 조건을 내가 왜 거꾸로 읽었는지, 그 정정이 실제로 뭘 바꾸는지를 순서대로 짚는다. 결론부터 말하면 이렇다. 메커니즘은 그대로였다. 옮겨간 건 조건이 아니라 병목이었고, 병목은 생성에서 판정으로 옮겨갔다. 같은 논쟁이 모델이 좋아질 때마다 다시 불붙는 이유도 거기 있다.

병목은 사라지지 않고 옮겨간다

제약이론은 한 줄로 줄어든다. 파이프라인의 속도는 가장 느린 공정이 정한다. 그 공정을 아무리 빠르게 만들어도 병목은 사라지지 않고 다음 공정으로 옮겨갈 뿐이다. 컨베이어벨트 한 구간을 두 배 빠르게 돌리면 그 앞뒤 구간이 새 병목이 되는 것과 같다. 루프를 둘러싼 소음을 이 틀로 다시 보면 왜 지금 이 얘기가 반복되는지가 잡힌다.

예전 파이프라인은 목표를 세우고, 사람이 그걸 코드로 느리게 번역하고, 확인하고, 배포하는 순서였다. 이때 검증은 별도 공정이 아니었다. 사람이 코드를 쓰면서 동시에 맞는지 틀린지를 계속 판단하고 있었으니, 검증은 느린 글쓰기 공정에 무임승차한 채로 따라왔다. 코드가 거의 공짜에 가깝게 즉시 나오기 시작하자 이 무임승차가 끝났다. Anthropic도 2024년 말 에이전트 설계 원칙을 정리한 글에서, 에이전트가 만드는 오류는 누적되므로 샌드박스 테스트와 사람의 체크포인트를 반드시 별도로 박아 둬야 한다고 짚는다. 검증이 글쓰기에 묻어오지 않게 된 순간, 그건 스스로 서야 하는 공정이 됐다.

이 격차가 코드와 기획에서 다르게 벌어지는 이유도 같은 틀로 설명된다. 코드는 컴파일러와 테스트가 판정도 순식간에 내린다. 기획이나 글쓰기는 판정이 여전히 느린 사람에게 묶여 있어서, 생성이 아무리 빨라져도 그 격차가 좁혀지지 않는다. 모델이 한 번 더 좋아질 때마다 생성 쪽 속도만 또 벌어지고 판정 쪽은 그대로 멈춰 있으니, 담론이 해소되지 않고 계속 재점화된다.

내가 거꾸로 읽었던 것, ralph의 정지 조건

여기서 나는 지난 글을 쓸 때 구체적으로 하나 틀렸다. ralph가 처음엔 반복 횟수로 멈추다가 점점 품질을 판단해서 멈추는 쪽으로 진화했다고 어렴풋이 읽고 있었다. 순서가 맞아 보였다. 거친 기준에서 정교한 기준으로 나아가는 건 익숙한 성숙의 서사이기 때문이다. 그런데 원전을 직접 열어 보니 그 서사 자체가 틀렸다.

Huntley가 ghuntley.com에 올린 원래 글에는 반복 횟수를 세는 장치가 아예 없다. 그가 쓴 정지 조건은 할 일 목록이 빌 때까지였고, 그 판단은 터미널을 보고 있던 사람이 직접 내렸다. 그는 이 판단을 두고 취향의 문제라고 표현한 적이 있다. 뭔가 이상하다 싶으면 사람이 Ctrl-C를 눌러 개입했다. 숫자 상한은 없었고, 판정은 처음부터 끝까지 사람 몫이었다.

내가 ralph의 것이라 여겼던 --max-iterations 안전장치는 사실 Anthropic이 나중에 만든 ralph-wiggum 플러그인에서 나왔다. 그 README는 완료 문자열을 정확히 매칭하는 자동 판정 장치를 만들어 두고도, 그 장치를 전적으로 믿지 말고 반복 횟수 상한을 1차 안전장치로 쓰라고 스스로 적어 뒀다. 즉 내가 생각한 진화의 방향은 처음부터 반대였다. 사람의 판단에서 시작해 자동 판정을 얹었는데, 그 자동 판정을 만든 쪽조차 그것보다 숫자 상한을 더 믿고 있었던 것이다. 판정을 자동화하는 일은 한 사람의 터미널에서 여러 사람이 쓰는 도구로 넘어가면서 더 쉬워진 게 아니라 더 어려워졌다.

왜 처음엔 이걸 놓쳤나

처음 루프를 봤을 때 내 시선은 "핵심 코드가 while문이네"에서 멈췄다. 2022년 ReAct 논문까지 거슬러 올라가는 계보를 확인하고는 안심하고 넘어갔다. 메커니즘이 낡았다는 확인은 맞았지만, 그 확인이 끝나는 지점에서 진짜 질문이 시작되고 있었다. 병목이 어디로 옮겨갔는지는 메커니즘을 보는 눈으로는 안 보인다.

이건 반사 신경의 차이이기도 하다. 엔지니어에게는 테스트와 타입체크로 성공 신호를 직접 만들어 두는 습관이 몸에 배어 있다. 다리에 금이 가면 눈에 보이지만, 코드는 틀려도 겉보기엔 멀쩡하게 돈다. 물리적 신호가 없는 재료를 오래 다루다 보면 신호를 스스로 만드는 쪽으로 방어 습관이 굳는다. 나는 프롬프트 품질 쪽 렌즈만 갖고 있었고, 그건 첫 턴의 출발점만 좋게 만들 뿐 두 번째 반복부터 "지금이 맞나"를 묻는 물음에는 아무 말도 하지 못한다.

그 무렵 타임라인에서 루프 얘기가 계속 스쳐 지나가는 것도 불안하게 느껴졌다. 뭔가를 놓치고 있다는 조바심이었다. 그런데 그 반복 노출은 하이프였다기보다, 병목이 구조적으로 옮겨간 자리를 사람들이 각자 다른 각도에서 계속 다시 짚고 있었던 것에 가까웠다. 이유를 모른 채 반복만 보고 있으니 그게 유행처럼 느껴졌을 뿐이다.

그래서 바뀌는 것, 판정을 실행 가능하게 쓰는 일

정정이 실제로 바꾸는 건 하나다. "다 됐다"를 기계가 판단할 수 있는 신호로 옮겨 적는 일이, 루프를 쓸지 말지 조건을 따지는 일보다 앞에 있다는 것이다. 최근 AIX에서 다루는 콘텐츠 생성 파이프라인에서 보완 요청을 처리하는 로직을 고치면서 이걸 실감했다. "요청한 대로 자연스럽게 고쳐줘"라는 지시로는 매번 전체가 다시 쓰였다. 요청하지 않은 부분까지 건드려지는데 그걸 판정할 방법이 없으니, 매번 처음부터 다시 생성하는 게 가장 안전해 보였기 때문이다.

고친 건 프롬프트 문구가 아니라 판정 기준이었다. 요청한 부분만 바뀌었는가, 나머지는 바이트 단위로 그대로인가, 앞뒤 맥락과 여전히 맞물리는가. 세 가지를 판정 가능한 체크로 쪼개고 나서야 재생성 범위가 줄었다. 문구를 다듬은 게 아니라 완료가 무엇인지를 판정 가능하게 다시 적은 것, 그게 이번에 바뀐 실제 작업이었다.

Claude Code의 /goal 같은 도구를 쓰는 것과 이걸 설계하는 것도 다른 일이다. 만들어진 루프 하네스를 돌리는 건 그 방법론이 낸 결과물을 소비하는 쪽에 가깝다. 내가 실제로 뭔가를 설계하는 유일한 순간은 목표 문장에 "무엇이 완료인가"를 적어 넣을 때다. 스키마나 타입 체크처럼 값싸고 확실한 판정부터 걸고, 그다음에야 사람 검수를 최후 수단으로 남겨 두는 순서도 그 문장 하나에서 갈린다.

메커니즘은 한 달 전이나 지금이나 똑같다. cron에 결정자 하나를 앉힌 것, 그 이상도 이하도 아니다. 달라진 건 그 결정자가 무엇을 근거로 멈출지를 판정하는 능력이었고, 그 판정이 미더워지는 만큼만 루프는 값을 한다. 병목은 생성에서 판정으로 옮겨갔고, 모델이 좋아질 때마다 그 격차는 좁혀지는 대신 더 벌어진다.

한 가지는 인정해야 한다. 지난 글의 네 가지 조건, 그러니까 반복량과 무인성과 판정 가능한 정지 조건과 토큰 예산은 여전히 유효하다고 본다. 다만 그중 세 번째 조건, 정지 조건을 코드로 쓸 수 있는가를 체크리스트의 항목 하나로만 다뤘던 게 이번에 드러난 구멍이었다. 그건 항목이 아니라 나머지 세 조건을 다 갖춰도 이게 없으면 전부 무너지는 축이었다. 이 정정도 몇 달 뒤에 다시 열어 보면 또 다른 구멍이 보일 것이다.

지난 글에서 루프의 최소 단위를 cron에 결정자를 앉힌 것이라 적었다. 그 결정자에게 뭘 믿고 맡길 수 있는지, 그 신뢰를 판정 가능한 신호로 바꿔 낼 수 있는지가 처음부터 전부였다. 루프든 사람에게 맡기는 다른 일이든 이 질문은 똑같이 따라온다. 무엇을 완료로 볼지 판정할 수 있게 적어 두지 않으면, 아무리 정교한 장치를 앉혀도 누군가 계속 옆에서 지켜보고 있어야 한다.