goal 명세에 따라 달라지겠지만, 경험상 Claude Code는 조금 더 러프하고 open-ended 목표에 잘 맞았고, Codex는 검증 기준과 산출물 규격이 정해졌을 때 더 버티컬하게 파고들어 퀄리티 향상에 도움이 되었다. 왜 이런 차이가 날까? 그래서 공식 문서를 좀 뜯어봤다.
먼저 둘은 "완전히 다른 원리"라기보다 같은 추상 루프를 다르게 구현했다. 둘 다 멘탈 모델 자체는 [목표 설정 → 작업 → 확인 → 계속/종료]로 해석할 수 있다. 차이는 이 루프를 어떻게 관리하느냐다. 미리 결론 부터 이야기하면 공식 문서와 공개 코드 기준으로 보면 Claude Code는 작업자 + 별도 평가자 구조로 단순한 hook인 반면, Codex는 루프를 위한 정보 관리 구조가 더 뚜렷하다.
Claude Code의 /goal은 턴이 끝난 뒤 별도 평가자가 판단하는 구조로 문서에는 언급되어 있다. 더 정확하게는 "session-scoped prompt-based Stop hook의 wrapper라고 명시되어 있다. (언젠가 "다시" 오픈소스화가 된다면 실제로도 그런지 확인해보자) 목표에 맞게 기존 작업을 하고 나면, "작은 빠른 모델"이 goal 조건과 지금까지의 대화를 읽고 yes/no와 짧은 이유를 반환한다. 이 모델은 기본적으로 Haiku다. 여기서 Haiku 평가자가 도구를 직접 실행하거나 파일을 따로 읽지 않는다. 즉, 결과가 대화에 드러나야 Haiku가 판단할 수 있다. 다만 Haiku를 써본 사람이라면 알 것이다. 이걸 LLM Judge로 사용한다면, 똑똑하긴 해도 여전히 부족한 도구다. 그래서 성공 조건을 명확하게 하여야 평가 모델이 더 발산하거나, 잘못된 종료를 줄일 수 있다. 아니면 모델을 바꿀 수도 있는데, 또는 슬롯 머신처럼 발산을 원한다면 그것도 뭐 빌더의 역할이 아닐까 싶기도.
Codex도 비슷하게 근거를 보고 종료 조건을 판단한다. (Claude가 어떻게 구현했는지는 몰라도) Codex는 깃헙에 공개된 오픈소스를 뜯어보면 코드에서 보이는 구성은 다르다. Codex의 goal은 단순히 프롬프트에 붙는 문장이 아니라 "현재 작업 흐름에 저장되는 목표 상태"로 다뤄진다. 실제 app-server 문서에는 thread/goal/set, thread/goal/get, thread/goal/clear가 있고, goal 객체에는 objective, status, tokenBudget, tokensUsed, timeUsedSeconds 같은 필드가 있다. 또 코드에는 모델이 goal을 다루기 위한 get_goal, create_goal, update_goal 도구가 정의되어 있고, 실행 루프에는 턴 시작, 도구 완료, 턴 종료, 유휴 시 continuation, 사용량 제한 같은 이벤트가 있다. 즉 Codex는 /goal을 이어가고 판단하기 위해 goal 상태, 사용량, 도구 호출, 턴 종료, 중단 조건 같은 실행 맥락을 더 구조적으로 관리한다.
더 뜯어보면 Codex repo 안에 goal continuation prompt도 직접 들어 있다. 이 프롬프트는 "active thread goal을 계속하라", "목표를 더 작고 쉬운 것으로 재정의하지 마라", "현재 worktree와 외부 상태를 근거로 삼아라". 그리고 완료 전에는 파일, 명령 결과, 테스트, 로그, 실행 상태 같은 근거로 요구사항별 감사를 하라고 한다. 증거가 약하거나 일부만 맞으면 complete로 표시하지 말고 계속 작업하라는 것. 즉 Codex의 /goal은 단순 확인의 반복보다는 목표 상태, 도구 호출, 예산, 막힘 판단, 완료 감사가 묶인 근거 기반 실행 루프에 가깝다. 그래서인지 /goal에서 "막혔을 때 다음 전략 및 행동"을 명시해주면 훨씬 더 좋은 결과로 이어진다. 그리고 아무리 많은 정보를 수합하더라도 이것도 마찬가지로 LLM Judge이기에 여전히 goal은 명확하고 AI가 판단할 수 있는 범위가 무엇인지 아는 것이 중요하다.
loop engineering의 핵심은 결국 LLM Judge를 얼마나 잘 설계하고, 얼마나 judgeable한 goal을 주느냐에 달려 있다.