제일 똑똑한 모델 하나로는 부족했다
나는 큰 개발 작업을 Codex에 곧바로 맡기곤 했다. 요구사항을 주면 여러 파일을 빠르게 고쳤고, 실행과 검사까지 마친 뒤 결과를 설명했다. 그런데 가장 곤란한 실패는 코드가 틀린 경우가 아니었다. 기능은 제대로 작동했지만, 내가 원한 제품이 아니었다.
Codex는 내가 준 목표를 빠르고 충실하게 완성했다. 문제는 그 목표가 맞는지 따져보는 단계가 부족했다는 데 있었다.
그래서 Claude로 먼저 계획을 만들고, Codex에 구현을 맡기기 시작했다. 처음에는 역할이 명확해 보였다. Claude는 계획하고, Codex는 구현한다. 최근 Claude의 Fable 5와 Codex의 GPT-5.6 Sol을 함께 쓰면서는 이 차이가 더욱 선명해졌다. 두 모델 모두 이전보다 훨씬 넓은 범위의 작업을 수행할 수 있게 됐지만, 역설적으로 내가 각자에게 맡기고 싶은 역할은 더 뚜렷해졌다.
물론 현실은 그렇게 깔끔하게 나뉘지 않았다. Claude가 세운 계획은 코드 앞에서 자주 깨졌다. Codex가 파일을 읽고 실행하다 새로운 사실을 발견하면 계획부터 다시 써야 했다. 계획과 구현은 앞뒤로 분리된 두 단계가 아니라 서로를 계속 수정하는 과정에 가까웠다.
이 차이를 “Claude는 창의적이고 Codex는 꼼꼼하다”는 성격론으로 설명하기는 쉽다. 하지만 둘 다 계획과 구현, 테스트와 검토를 수행할 수 있다. 사용자가 경험하는 성능은 모델 하나만으로 결정되지 않는다. 시스템 지침, 파일을 찾는 방식, 사용할 수 있는 도구와 권한, 오류가 돌아오는 속도, 작업을 멈추는 조건 같은 환경이 행동을 함께 만든다. 비공개 학습 방식을 추측하기보다 눈에 보이는 작업 환경과 피드백 구조를 살펴보는 편이 더 정확하다.
내가 Claude를 특히 유용하게 느끼는 순간은 목표가 아직 흐릴 때다. 예를 들어 “처음 온 사용자에게 직관적인 가입 화면”에는 정답이 하나가 아니다. 설명을 먼저 보여줄 수도 있고, 바로 체험하게 할 수도 있다. 사용자를 구분하는 질문부터 던질 수도 있다. 이때 필요한 것은 첫 답을 빠르게 확정하는 능력이 아니라 서로 다른 가능성을 펼쳐놓는 능력이다.
다만 Claude가 채운 빈칸은 내 의도가 아니라 모델의 추정이다. 결과가 그럴듯하다고 해서 요구를 제대로 이해했다는 뜻은 아니다. 그래서 Claude의 첫 답은 완성된 계획이 아니라 비교하고 검증하고 버릴 수 있는 가설로 다뤄야 한다.
Codex가 힘을 발휘하는 구간에는 틀렸다고 말해주는 존재가 많다. 파일이 없으면 탐색 결과가 알려준다. 코드가 틀리면 컴파일이나 실행 과정에서 오류가 난다. 기존 기능을 깨뜨리면 자동 검사나 실제 화면에서 드러난다. 모델의 설명이 아무리 그럴듯해도 현실이 아니라고 반박해주는 피드백이 촘촘하다.
그래서 구현은 계획을 받아 적는 일이 아니다. 계획 속 가설을 실제 코드에 대입해보는 실험이다. Codex는 파일을 읽고, 조금 고치고, 실행하고, 실패 원인을 추적한다. 이 반복을 통해 선택지를 줄이고 잘못된 가정을 제거한다. 계획의 오류는 기능을 상당 부분 만든 뒤에야 드러날 수 있지만, 구현 단계의 오류 중 상당수는 더 빨리 돌아온다.
내 작업 방식 안에서 비유하자면 Claude는 0에서 1에, Codex는 1에서 100에 강하다. 최신 모델인 Fable 5와 GPT-5.6 Sol을 사용하면서 이 대비가 더욱 선명해졌다. Claude는 가능한 1을 여러 개 만들고, Codex는 선택된 1을 현실에 부딪혀 100으로 가져간다. 이것은 두 모델의 보편적인 능력에 대한 평가라기보다 내가 둘을 배치하는 방식에 가깝다.
그런데 이 도식에는 중요한 단계가 하나 빠져 있다. 0과 1 사이의 사람이다.
Claude가 세 가지 방향을 제시해도 어느 것이 실제 1인지는 자동으로 결정되지 않는다. 해결하려는 문제, 포기할 수 없는 기능, 허용 가능한 변경 범위와 실패 비용을 사람이 보고 골라야 한다. 이 판단 없이 Claude의 답을 Codex에 넘기면 틀린 가설이 높은 완성도로 구현된다.
그래서 큰 작업을 시작할 때는 Claude에 리서치를 맡기고, 내가 무엇을 원하는지 역으로 인터뷰하게 한다. 확인된 사실과 모델의 추정을 분리하고, 하나의 정답 대신 몇 가지 접근을 비교하게 한다. 내가 방향을 고르면 변경 범위, 유지할 동작, 완료 조건과 중단 조건을 붙여 Codex에 넘긴다.
예상하지 못한 파일이나 의존성을 만나거나 변경 범위가 커지면 멈추도록 지시한다. 중단은 실패가 아니다. 계획이 현실과 충돌했다는 새로운 증거다. 관련 파일과 실패한 명령, 틀린 것으로 드러난 가정을 돌려받고 그 증거로 Claude의 계획을 고친다.
자동 검사를 통과해도 끝은 아니다. 검사 항목에 포함되지 않은 기능은 사라져도 테스트를 통과할 수 있다. 그래서 작업 과정을 보지 않은 다른 모델이나 검토자에게 최초 요구사항과 실제 변경 사항을 다시 비교하게 한다. 가능하다면 실제 화면과 사용자 행동까지 확인한다. 다른 모델도 비슷한 맹점을 공유할 수 있기 때문이다.
모든 수정에 이 절차가 필요한 것은 아니다. 되돌리기 쉽고 범위가 명확한 작은 작업은 Codex에 바로 맡기는 편이 낫다. 탐색과 선택을 앞에 두어야 하는 것은 요구가 모호하거나 여러 기능이 얽혀 있고, 잘못 갔을 때 되돌리는 비용이 큰 작업이다.
이 조합은 두 회사가 합의해서 만든 협업 방식이 아니다. 경쟁하는 두 제품의 장점을 사용자가 손으로 이어 붙인 상태다. 양쪽 모두 조사, 계획, 구현, 검토를 자기 제품 안으로 흡수하려 하고 있다. 따라서 지금의 역할 차이가 계속 유지된다고 보기는 어렵다.
그렇다면 다음 경쟁은 모델 하나의 점수보다 작업 루프의 설계에서 벌어질 가능성이 크다. 최근에는 이런 접근을 ‘루프 엔지니어링’이라고 부르기 시작했다. 아직 하나의 정의가 정착된 것은 아니다. 반복적인 프롬프트를 시스템으로 대체하는 자동화를 강조하기도 하고, 에이전트의 실행과 검증, 개발자와 사용자의 피드백까지 함께 다루기도 한다.
내가 강조하고 싶은 것은 단순히 “사람을 다시 루프에 넣자”는 말이 아니다. 사람의 판단을 예외적인 승인 절차가 아니라 루프의 핵심 구성 요소로 설계해야 한다는 것이다. 목표를 세우고, 가설을 만들고, 실행 결과를 관찰하고, 다음 행동과 중단 여부를 결정하는 전체 반복 안에 사람의 맥락과 판단이 들어가야 한다.
이 관점에서 Claude와 사람, Codex는 하나의 피드백 루프를 이룬다. Claude는 가설의 범위를 넓힌다. 사람은 목적과 위험을 보고 다음에 검증할 가설을 고른다. Codex는 실제 코드와 실행 결과로 그 선택을 검증하거나 반박한다. 그 과정에서 얻은 증거는 다시 Claude의 계획을 바꾼다.
좋은 루프는 많이 반복하는 루프가 아니다. 빠른 실행, 믿을 만한 피드백, 판단 근거의 기록, 명확한 중단 조건이 함께 있어야 한다. 자동 검사가 엉뚱한 목표를 측정하고 있다면 빠른 Codex는 오답을 더 빨리 최적화한다. 틀린 가정이 기록에 남으면 Claude는 같은 계획을 반복한다. 속도가 높아질수록 목표와 평가 기준을 더 자주 의심해야 한다.
기억도 필요하다. 어떤 접근을 버렸는지, 어디에서 현실과 충돌했는지, 왜 계획을 바꿨는지를 다음 작업이 물려받아야 한다. 관측한 사실과 당시의 추정도 분리해야 한다. 오래된 정보와 잘못된 요약은 기억이 아니라 다음 실패의 원인이 된다.
마지막에는 루프 바깥의 평가가 있어야 한다. 계획을 만든 모델과 코드를 고친 모델이 같은 기준만 바라보면 맹점도 반복된다. 작업 과정을 모르는 검토자, 실제 사용자의 반응, 제품 지표와 운영 환경이 필요한 이유다. 내부 루프가 빨라도 외부 현실과 연결되지 않으면 틀린 방향으로 정교해질 뿐이다.
루프 엔지니어링은 AI를 더 오래 돌리는 기술이 아니다. 추측을 검증 가능한 가설로 바꾸고, 실패에서 얻은 증거를 다음 판단까지 돌려보내는 기술이다. 잘 설계된 루프는 틀린 가정을 빠르게 제거한다. 잘못 설계된 루프는 틀린 목표를 더 빠르게 증폭한다.
앞으로 개발 에이전트의 격차는 첫 답의 영리함보다 여기에서 벌어질 것이다. 계획이 틀렸을 때 시스템은 알아차릴 수 있는가. 그 사실이 다음 판단까지 돌아갈 수 있는가.
똑똑한 모델 하나로는 부족했다. Claude와 Codex를 이어 붙여도 마찬가지였다. 부족했던 것은 지능이 아니라 루프였다.
19
13
2July 16, 2026 4.7K 1 52
