This Open Source Repo Solve Claude''s #1 Problem

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

ClaudeX Loop은 Claude가 자신의 작업을 스스로 높게 평가하는 문제를 Codex의 독립적인 계획·코드 검토 루프로 보완하는 오픈 소스 저장소다.

📌 핵심 요점

1. ClaudeX Loop은 한 모델이 계획·실행·평가를 모두 담당하지 않도록 Claude와 Codex 사이에 상호 검토 구조를 만든다.
2. 워크플로는 조사, 요구사항 심문, 계획 검토, 빌드의 네 단계로 구성되며 중요한 단계마다 두 번째 모델의 판단을 받는다.
3. 계획 검토는 기본 최대 5회로 제한해 무한 반복과 토큰 낭비를 막으며, 데모에서는 합의에 실패한 뒤 2회를 추가해 7회차에 승인됐다.
4. Calendly 재현 데모에서 Codex는 계획 단계의 27개 문제와 빌드 단계의 23개 발견 사항을 제시했고, 빌드 발견 사항 중 19개가 수용·수정됐다.
5. 두 번째 모델은 이중 예약, OAuth 연결, 동시성, 평문 관리 토큰, 시간표 오차처럼 첫 번째 모델이 놓치기 쉬운 경계 조건을 조기에 드러냈다.

🧩 배경과 문제 정의

• 영상은 Claude가 자신이 만든 계획과 결과를 호의적으로 평가하는 자기평가 문제에서 출발한다.
• ClaudeX Loop은 계획·실행 모델과 평가 모델을 분리하고, 두 번째 모델이 승인하거나 수정 이유를 제시한 뒤에만 중요한 작업을 진행하도록 설계됐다.
• 목표는 단순히 모델을 하나 더 사용하는 것이 아니라 조사, 요구사항 구체화, 계획 검토, 구현 검토를 반복 가능하고 제한된 절차로 만드는 것이다.

🕒 시간순 섹션별 상세정리

1. 자기평가 편향과 교차 검토 설계

• Claude가 자신의 계획을 스스로 높게 평가하는 경향 때문에, Codex를 두 번째 시선으로 투입해 승인 여부와 수정 이유를 제시하게 한다. [00:45]
• 워크플로는 조사와 심문을 거쳐 Claude가 작성한 계획을 Codex가 읽기 전용 샌드박스에서 검토하고, 합의 후 구현으로 넘어가는 구조다. [02:34]
• 계획 검토는 기본 5회, 빌드 검토는 2회로 제한하며 필요하면 검토자를 로컬 모델로 바꿀 수 있고, 이전 Grill Me Codex보다 심문과 실행 검토가 강화됐다. [03:19]

2. Calendly 재현을 위한 조사와 요구사항 구체화

• 마스터클래스 안내 후 Calendly의 주요 기능과 Google Calendar·Google Meet 연동을 재현하는 데모를 시작한다. [04:38]
• 심층 조사는 캘린더·Meet·예약 도메인의 함정과 기술 스택을 확인하고, 그 결과를 프로젝트의 가정을 정리한 assumptions ledger로 만든다. [05:56]
• 핵심 기능을 좌우하는 질문과 외형 관련 결정을 차례로 확인하며, 사용자는 모르는 항목을 반복해서 설명받아 무조건 추천안을 수용하지 않도록 권고받는다. [07:16]

3. 계획 검토 교착과 7회차 합의

• Claude가 작성한 plan.md를 Codex가 검토하며 최대 5회 합의를 시도했지만, 첫 회의 27개 문제를 모두 해결하지 못해 승인 없이 상한에 도달한다. [07:55]
• 사용자는 현재 상태 수용, 중단, 2회 연장 중에서 선택할 수 있으며, 데모에서는 연장을 선택해 7회차에 합의한다. [08:18]
• 합의 후 Claude가 빌드하고 Codex가 검토하는 방식과 그 반대 방식 중 전자를 선택해 구현을 시작한다. [08:47]

4. 예약 애플리케이션 완성과 기능 확인

• 완성된 예약 화면에서 Gmail 캘린더와 동기화된 시간을 선택하고 이름과 이메일을 입력해 예약을 확정한다. [09:21]
• 확인 이메일과 참여 링크가 발송되고 일정이 실제 캘린더에도 나타나면서 주요 예약 흐름이 작동함을 보여 준다. [09:27]

5. 계획·빌드 결함 분석과 최종 효과

• 계획 검토에서는 이중 예약 제약, OAuth 연결, 동시 재예약 같은 문제가 발견됐고, 27개 문제는 7회의 왕복 끝에 승인 상태에 도달했다. [10:06]
• 새로운 컨텍스트의 Codex가 코드와 명세를 비교해 23개 발견 사항을 제시했으며, 19개는 수용·수정되고 4개는 거절됐다. 시간표 오차, 평문 관리 토큰, 종일 일정 처리 오류도 포함됐다. [10:44]
• 발표자는 Claude만으로도 반복 끝에 작동했을 수 있지만, Codex가 계획과 구현 단계에서 문제를 먼저 찾아 재작업·토큰·시간·비용을 줄였다고 결론짓는다. [11:29]

🧾 결론

• 핵심 가치는 Claude를 Codex로 대체하는 것이 아니라, 생성자와 평가자를 분리해 자기평가 편향을 줄이는 데 있다.
• 계획 단계의 결함을 구현 전에 찾으면 잘못된 설계를 코드로 만든 뒤 다시 수정하는 비용을 줄일 수 있다.
• 검토 횟수에 상한과 교착 처리 선택지를 두는 것은 품질 향상과 토큰 비용 통제를 함께 달성하기 위한 중요한 운영 장치다.
• 데모는 완성된 예약 기능과 실제 캘린더·이메일 연동을 보여 주지만, 단일 사례이므로 일반적인 성능 우위를 확정하는 비교 실험으로 볼 수는 없다.

📈 투자·시사 포인트

• AI 코딩 도구의 경쟁축은 단일 모델의 생성 능력뿐 아니라 여러 모델을 조율하고 결과를 검증하는 워크플로 품질로 이동할 수 있다.
• 계획 단계에 추가 토큰을 투입하더라도 구현 후 재작업과 운영 결함을 줄인다면 전체 개발 비용은 낮아질 가능성이 있다.
• 읽기 전용 검토, 새 컨텍스트를 사용한 코드 대 명세 비교, 반복 횟수 제한과 같은 검증 인프라가 에이전트 개발 도구의 차별화 요소가 될 수 있다.
• 로컬 모델로 검토자를 교체할 수 있다는 설명은 비용·보안·모델 선택권을 중시하는 사용자에게 확장 가능성을 제시한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Claude 단독 개발과 ClaudeX Loop를 동일 조건에서 비교한 정량 벤치마크는 제시되지 않았으며, 발표자도 Claude만으로도 추가 반복을 거치면 결국 작동했을 가능성을 인정한다.
• 기본 5회 제한으로는 데모의 계획 검토가 승인되지 않아 7회까지 연장됐으므로, 적절한 반복 상한과 비용은 프로젝트 복잡도에 따라 달라질 수 있다.
• Calendly 재현 결과는 하나의 데모이며, 장기 운영 안정성·보안 검증·프로덕션 부하 대응까지 입증한 것은 아니다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 새 기능이나 그린필드 프로젝트를 시작하기 전에 조사·요구사항 확인·계획 검토·빌드 검토 단계를 명시적으로 분리한다.
• 계획 검토와 빌드 검토의 최대 반복 횟수, 승인 조건, 교착 시 중단 또는 연장 기준을 사전에 정한다.
• 두 번째 모델은 읽기 전용 환경과 독립적인 새 컨텍스트에서 계획 또는 코드와 실제 명세를 비교하도록 구성한다.
• 이중 예약, 동시성, OAuth, 비밀정보 노출, 시간 계산처럼 데모에서 발견된 경계 조건을 별도 테스트 항목으로 만든다.

❓ 열린 질문

• Claude와 Codex의 역할을 뒤집거나 로컬 모델을 검토자로 사용할 때도 비슷한 결함 탐지 효과가 유지될까?
• 계획 검토와 빌드 검토에 각각 몇 회를 배정해야 품질 향상보다 토큰 비용이 커지는 지점을 피할 수 있을까?
• 같은 모델을 새 컨텍스트에서 검토자로 사용하는 방식과 서로 다른 모델을 조합하는 방식 사이에는 어느 정도의 품질 차이가 있을까?