저는 항상 AI 프로그래밍을 즐깁니다.

저의 일반적인 워크플로우는 계획을 세우고, 이를 검토(Audit)받은 다음, 구현(Implementation)을 진행하는 것입니다.

하지만 검토 과정이 제대로 작동하지 않는다고 느꼈습니다. 특히 Opus 4.7 이후부터 더욱 그렇습니다. 아마도 Opus가 더 넓은 관점을 갖게 되었기 때문일까요? Opus는 종종 제 계획과 무관한 점들을 지적하며, 검토와 수정을 자동 루프(Automated loop)로 수행하게 하면 피드백이 제대로 수렴(Converge)하지 못하는 경우가 많습니다.

두더지 잡기 (Whac-A-Mole)

그러던 어느 날, 저는 깨달았습니다.

약간 복잡한 로직을 가진 프로그램을 작성할 때, AI는 매번 "이것은 틀렸다" 또는 "저것은 틀렸다"라고 말합니다. 이는 간접적인 루프, 혹은 더 정확하게는 끊임없는 두더지 잡기(Whac-A-Mole)처럼 느껴집니다.

AI는 "A의 관점에서 B가 취약하다"라고 말하고, 그러면 저는 B를 수정합니다. 다음 검토에서는 "B는 과도하고, A는 빈약하다"라고 말합니다. 제가 A를 추가하면, 이번에는 "C가 일관성이 없다"라고 말합니다. C를 수정하면, "C에 대한 설명이 중복된다"라고 말합니다. 그것을 수정하고 나면, 다시 "C에 대한 설명이 불충분하다"라고 말합니다.

이는 시소와 같습니다. 탈출구가 보이지 않습니다.

제가 시도한 것

이를 깨닫고 저는 다음과 같은 접근 방식을 시도했습니다.

상당히 완성된 계획(1~2회의 검토를 거친 상태)에 대해 AI에게 다음과 같이 요청했습니다. "오직 논리적 모순(Logical contradictions)에 대해서만 계획을 검토해 주세요."

이 방법은 완벽하게 작동했습니다. AI는 모순을 성실하게 해결했고, 몇 차례의 검토를 거친 후 적절하게 수렴했습니다.

모순의 수는 유한하기 때문에, 실제로 수렴하게 됩니다.

그리고 모순이 없는 계획으로 구현을 시작하게 하면, 멈추지 않고 끝까지 곧장 달려갑니다 (lol).

물론 가끔 재시도가 필요한 구현 오류(Implementation errors)가 발생하기도 하지만, 그것은 예상 가능한 범위 내에 있습니다.

세상에 이런 방법이 이미 존재할까?

이 단계에 도달하자 문득 궁금해졌습니다. 분명 제가 이 방법을 처음 생각해낸 사람은 아닐 것입니다. 분명 다른 누군가도 똑같은 생각을 했을 것입니다.

검색을 해보았습니다.

유사한 개념들은 있었지만, 느낌이 달랐습니다. 간단히 말하자면, 그것들은 너무 복잡했습니다.

• Criteria Drift (Hamel Husain의 설명, Shankar et al.): 리뷰를 위해 LLM (Large Language Model)을 사용할 때 평가 기준이 점진적으로 변하는 현상입니다. 이에 대한 대응책은 "평가 축을 정교화하면서 과거의 점수를 재산정(rescoring)하는 것"입니다. ...너무 무겁네요.
• Oscillatory Convergence (Fractal Thought Engine): LLM의 반복적인 피드백으로 인해 접근 방식이 진동(oscillate)하는 특정 횟수의 세션이 존재한다는 관찰 결과입니다. 현상은 관찰되었지만, 대응책에 관한 것은 아닙니다.
• Moving the Goalposts (Microsoft Blog): 평가 중에 루브릭 (rubric, 평가 기준)을 변경하지 않고, 평가를 시작하기 전에 루브릭을 확정해야 한다는 아이디어입니다.

관련된 주제들은 있습니다. 하지만 제가 한 일은 "루브릭을 확정하는 것"이 아니라, "평가 축을 단 하나의 지점, 즉 모순(contradictions)으로 좁히는 것"이었습니다. 범위가 넓은 한 비판 지점은 무한히 생겨날 것이기에, 범위를 유한한 집합으로 제한하려고 노력한 것입니다. 이를 명확하게 명시한 기존 연구는 찾을 수 없었습니다.

어딘가에 적혀 있을 것 같다는 의심이 듭니다. 분명히 있을 텐데, 아마 학술적인 용어로 쓰여 있을 것이고, 제가 깨달았을 때는 이미 두 달이 지나 있었습니다.

알려주고 나면 단순한 것

글로 써놓으니 단순해 보입니다. "범위를 좁히면 수렴할 것이다." 그게 전부입니다.

하지만 제가 이를 알아차리는 데는 두 달이 걸렸습니다.

저는 "Claude를 더 지능적으로 사용하면 더 나아질 거야"라고 생각하며 프롬프트 (prompt) 작성 방식을 계속 바꾸려고 시도했습니다. "너무 많은 지적을 하지 마세요"라거나 "이전 피드백과 일관성을 유지하세요"라고 써보기도 했지만 효과가 없었습니다. 왜냐하면 문제는 제가 프롬프트를 어떻게 작성하느냐가 아니었기 때문입니다.

범위를 "오직 유한한 항목들(only finite items)"로 좁혀야 한다는 생각이 떠오르기까지 시간이 걸렸습니다. 일반적인 감사 (audit)를 수행할 때는 범위가 너무 넓기 때문에, 무엇을 수정하더라도 다른 각도에서 새로운 허점이 발견됩니다. 그것이 문제의 핵심이었습니다.

결론

• 계획에 대한 감사 (audit)가 수렴하지 않는다면, 범위를 "오직 모순점(only contradictions)"으로 좁히세요.
• 모순점은 유한하기 때문에 프로세스가 수렴할 것입니다.
• 넓은 범위로 감사 (audit)를 수행하면 비판이 무한히 솟아나와, 마치 두더지 잡기 (Whac-A-Mole) 게임과 같은 상황이 됩니다.
• 모순이 없는 계획을 AI가 실행하도록 하면, AI는 멈추지 않고 완료될 때까지 실행할 것입니다.

만약 저와 똑같은 두더지 잡기 (Whac-A-Mole) 함정에 빠진 분이 있다면, 이 글을 쓰는 보람이 있을 것입니다.

무언가 좋은 일을 한 날에는 기분이 좋습니다.