동일한 모션 브리프로 Claude Code와 Codex를 공정하게 비교하는 방법
보기 좋은 영상 두 편만으로 코딩 에이전트 두 개를 공정하게 비교할 수는 없습니다. 한쪽에 더 좋은 자료, 더 자세한 프롬프트, 한 차례 더 많은 수정 기회, 다른 쪽에는 없는 도구 접근 권한이 주어졌을 수 있습니다. 화면을 나란히 놓은 스크린샷에는 이런 차이가 드러나지 않습니다.
모션 작업에서는 특히 이런 착각에 빠지기 쉽습니다. 어떤 모델은 인상적인 첫 프레임을 만들면서도 시간 조건을 놓칠 수 있습니다. 다른 모델은 수수하지만 일부를 수정해도 정상적으로 작동하는 편집 가능한 프로젝트를 만들 수 있습니다. 어느 쪽이 더 나은지는 원래 무엇을 맡기려 했느냐에 달려 있습니다.
모션 그래픽 작업에서 Claude Code와 Codex를 비교하려면 같은 검수 과제와 자료를 제공한 뒤 정확한 문구, 타이밍, 조작부, 실제로 쓸 수 있는 결과에 도달하기까지의 복구 노력을 살펴보세요. 이 글의 실험 사례에서는 Codex 결과물의 재생, 탐색 조작 실패, 복구를 차례로 확인합니다. Claude Code는 짝을 이루는 실행에서 인증을 완료하지 못했으므로 모델 간 비교는 아직 미완입니다.
필요한 역량이 드러나는 과제 선택하기
“멋진 제품 영상을 만들어 줘”에는 해석의 여지가 너무 많습니다. 더 나은 시험에는 실제 전달 요건과 범위가 정해진 기술적 결과물이 들어갑니다. 예를 들어 정확한 가격 문구, 어느 시점으로 이동해도 일관된 상태를 보여 주는 탐색 기능, 두 문구를 함께 읽을 수 있는 구간을 갖춘 6초짜리 편집 가능한 요금 안내 장면을 만들도록 합니다.
화면은 단순해도 중요한 동작을 시험할 수 있습니다. 정확한 문구는 사실 보존을 검증합니다. 안정적인 정지 구간은 시간적 추론을 검증합니다. 탐색 조작부는 처음부터 순서대로 재생할 때만 작동하는 시퀀스인지, 시간에 따라 상태가 결정되는 애니메이션인지를 검증합니다. 일부 수정은 소스를 계속 통제할 수 있는지 확인합니다.
첫 시험에 가능한 모든 기능을 넣지는 마세요. 내레이션, 음악, 자막, 차트 데이터, 여러 화면 비율, 복잡한 인터페이스를 한꺼번에 포함하면 실패 원인을 특정하기 어렵습니다. 먼저 작은 대표 과제를 사용하고, 여기서 드러나지 않는 역량은 두 번째 과제로 시험하세요.
코드 생성 자체를 비교하는지, 에이전트의 전체 작업 과정을 비교하는지도 결정하세요. 코드만 비교하는 시험에서는 도구를 비활성화하고 독립 실행형 문서를 요구해 도구 조건을 맞출 수 있습니다. 작업 과정 시험에서는 비슷한 권한 아래 각 에이전트가 자료를 살펴보고 프로젝트를 실행하며 오류를 고칠 수 있게 해야 합니다. 서로 다른 실험이므로 하나의 순위로 합쳐서는 안 됩니다.
도구 도입을 검토하는 팀에는 전체 작업 과정 시험이 더 적절한 경우가 많습니다. 필요한 결과는 단순한 소스 코드가 아니라 실용적인 과정을 통해 얻은 정확하고 편집 가능한 산출물이기 때문입니다. 다만 작은 코드 전용 시험으로 요건과 환경 문제를 먼저 드러내면 더 큰 비교에 시간을 쓰기 전에 도움을 얻을 수 있습니다.
브리프와 자료 고정하기
두 실행에 같은 브리프를 한 글자도 바꾸지 않고 사용하세요. 어느 에이전트든 호출하기 전에 저장합니다. 첫 결과를 보고 모호한 점을 발견했다면 양쪽 브리프를 모두 수정하고 새로운 한 쌍을 별도 시험으로 취급하세요. 한쪽에만 추가 설명을 주지 마세요.
이 글에 첨부된 로컬 시험의 브리프는 1280×720 크기의 독립 실행형 HTML 문서를 요구했습니다. 가상 장면의 제목은 Still Studio이며 “US$29 per month”와 “US$348 billed annually”를 정확히 표시해야 했습니다. 두 줄은 0초부터 0.8초까지 등장하고, 4.8초까지 안정적으로 유지되며, 6초까지 퇴장하도록 했습니다.
브리프에는 화면에 보이는 Play/Pause 및 탐색 조작부, 2.4초에서 일시 정지된 초기 상태, 시스템 산세리프 글꼴, 외부 자료 사용 금지, 가상 실험임을 알리는 표기도 포함했습니다. 결과를 직접 확인할 수 있게 하고 외부 이미지나 글꼴 때문에 생기는 차이를 피하려고 정한 제약입니다.
문구와 청구 금액의 관계는 중요합니다. 연간 금액을 바꾼 모델은 타이포그래피가 더 매력적이어도 사실 요건을 어긴 것입니다. 조건을 끝에만 보여 주는 모델은 소스에 정확한 단어가 있더라도 시간 요건을 어긴 것입니다.
실제 제품 자료를 쓴다면 동일한 사본을 제공하고 각 자료의 정체성을 유지하세요. 한 에이전트만 더 최신 스크린샷이나 다른 로고를 사용하게 해서는 안 됩니다. 재배포할 수 없는 자료라면 접근 요건을 설명하고 허용된 환경 안에서 비교하세요.
실제 실행 환경 기록하기
도구 이름만으로 전체 시스템을 식별할 수는 없습니다. CLI 버전, 실행에서 보고한 모델, 관련 설정, 사용 가능한 도구, 권한, 새 세션인지 이어서 진행한 세션인지 기록하세요. 기본 모델은 시간이 지나면 바뀔 수 있으므로 제품 이름에서 추측한 모델보다 실행에서 실제로 보고한 모델이 중요합니다.
계정 접근과 모델 성능을 구분하세요. 로그인 실패, 요청 한도, 네트워크 중단은 실제 작업 흐름에 영향을 줄 수 있지만 모델이 만들지 못한 영상의 품질을 보여 주지는 않습니다. 이런 실패도 기록하되 창작 점수로 환산하지 마세요.
Codex 실행은 OpenAI 제공자를 통한 ChatGPT 인증을 사용했습니다. 로그에 기록된 CLI 버전은 0.163.0, 모델은 gpt-6.1-sol이며 결과물은 독립 실행형 HTML 문서입니다.
인증과 설정에 따라 접근 경로가 달라질 수 있으므로 명시적으로 살펴봐야 합니다. 도구 자체 문서를 확인하고 실제로 사용한 경로를 보존하세요. 벤치마크 묶음에 토큰이나 비공개 계정 파일을 노출하지 마세요. Claude Code 인증 문서
복구 전에 원본 결과 보존하기
첫 응답을 받은 그대로 브리프, 실행 상태와 함께 저장하세요. HTML 문서를 열기 위해 마크다운 코드 블록 표시를 제거해야 한다면 그 변환도 기록합니다. 문법을 조용히 고쳐 놓고 원래 첫 초안이라고 부르지 마세요.
실패한 요청은 완성된 산출물과 별도로 보관해 시험 기록에서 설정 실패와 결과물 결함을 구분할 수 있게 하세요.
코드 전용 비교에서는 반환된 문서를 수정하지 않고 여세요. 필요한 단어가 나타나는지, 외부 의존성 없이 장면이 열리는지, 조작부가 있는지 확인합니다. 그런 다음 전체 시퀀스를 재생하고 등장, 유지, 퇴장 구간으로 직접 이동하세요.
소스에는 범위 입력 요소와 시간에 따라 상태를 그리는 렌더 함수도 있습니다. 후속 동작 시험에서 조작부가 존재하지만 모두 정상 작동하지는 않는다는 사실을 확인했습니다. 실제 재생은 초기 상태에서 3.1초를 지나 6초까지 진행한 뒤 멈췄습니다. 탐색에서는 별도 결함이 드러났습니다. 표시 시간이 요청한 값으로 이동하지 않고 이전 값에 머물렀습니다.
스타일보다 의미부터 평가하기
먼저 양보할 수 없는 요건을 확인하세요. 정확한 사실이 포함되어 있나요? 사실 사이의 관계도 올바른가요? 정해진 구간 동안 시청자가 완전한 문장을 읽을 수 있나요? 제공한 자료를 사용하면서 존재하지 않는 인터페이스 동작을 만들어 내지는 않았나요?
다음으로 시간에 따른 동작을 살펴보세요. 중간, 시작, 등장 경계, 퇴장 경계, 끝으로 직접 이동합니다. 결정론적 애니메이션은 해당 시간에 어떤 경로로 도달했는지와 무관하게 예상 상태를 보여야 합니다. 앞선 프레임을 재생했는지에 따라 상태가 달라진다면 안정적인 프레임 렌더링에 적합하지 않을 수 있습니다.
그 뒤에 시각적 품질을 비교하세요. 위계, 간격, 타이포그래피, 모션의 일관성, 구도가 메시지를 얼마나 잘 뒷받침하는지 살펴봅니다. 판단 기준은 브리프에 두세요. 의도적으로 절제한 요금 안내 장면이 다른 버전보다 화려함이 덜하다는 이유만으로 낮은 평가를 받아서는 안 됩니다.
알 수 없는 하나의 총점 대신 몇 가지 항목으로 나눈 간단한 평가표를 사용하고 각 결과를 따로 보고하세요. 사실 정확성, 타이밍, 편집 가능성, 시각적 전달력, 납품 신뢰도는 서로 다른 평가를 받을 수 있습니다. 하나의 점수는 팀이 실제로 이해해야 할 절충 관계를 가립니다.
후속 시험에서 실제로 발견한 것
재생이 6초에 도달한 뒤 탐색 실패를 재현할 수 있었습니다. 키보드 Home 키를 눌러도 0초로 이동하지 않았습니다. 0.8초, 4.8초, 5.4초에 대한 입력 이벤트를 보내도 결과물은 6초에 머물렀습니다. 편집자는 전체 시퀀스를 다시 재생하지 않고 특정 상태를 확인해야 하므로 중요한 문제입니다. 화면에 타임라인이 보이는 것만으로는 충분하지 않습니다.
원인은 이벤트 순서였습니다. 입력 처리기가 슬라이더에서 요청 값을 읽기 전에 pause()를 호출했습니다. 이 구현에서는 일시 정지가 이전 상태를 조작부에 다시 렌더링하기도 했습니다. 따라서 뒤이어 값을 읽으면 이전 값이 나왔습니다. 애니메이션 계산은 올바르더라도 이를 확인하는 조작부가 고장 날 수 있습니다.
작성자는 요청 값을 먼저 읽고 일시 정지한 다음 적용하도록 별도 사본을 수정했습니다. 모델의 원본 결과는 그대로 보존했습니다.
// Preserve the requested value before pause() renders the old state.
const requestedTime = Number(seek.value);
pause();
state.time = Math.max(0, Math.min(motion.duration, requestedTime));
render();
수정본은 키보드 Home과 End에 각각 0초와 6초로 응답했습니다. 0.8초와 4.8초에는 두 가격 문구가 완전히 불투명하고 위치 이동이 없었습니다. 5.4초에는 둘 다 불투명도 0.5, 위쪽 이동 18픽셀이었습니다.
contenteditable 문구를 US$39 per month와 US$468 billed annually로 직접 편집해도 2.4초에서 두 줄이 모두 보였습니다. 인수 시험의 다음 단계에서는 변경 사항을 저장하고 다시 불러온 뒤 렌더링해야 합니다.
표시 시간을 읽는 것은 재생 결함과 탐색 결함을 구분하는 가장 빠른 방법입니다. 이 사례에서 원본은 재생할 때 정상적으로 진행하지만 이후 특정 상태로 이동하라는 요청을 거부합니다. 복구는 이벤트 처리기의 순서를 바꾸고 등장·퇴장 곡선은 그대로 유지합니다. 한 쌍의 에이전트를 시험할 때는 이를 정확한 복구 과제로 사용할 수 있습니다. 탐색을 고치되 6초 길이와 두 가격 문구를 유지하고 Home, End, 중간 시점 하나를 확인하도록 하는 것입니다.
동일한 부분 수정 요청하기
첫 초안은 과제의 절반입니다. 성공한 두 실행에 같은 수정 요청을 주세요. 예를 들어 월 환산액과 연간 청구액을 바꾸되 레이아웃과 타이밍을 유지하고 두 문장을 함께 보여 달라고 합니다. 한정된 부분을 수정하면서 나머지를 불필요하게 다시 작성하지 않는지 시험하는 방법입니다.
원본 소스를 보존하고 수정본과 비교하세요. 문구, 도형, 타이밍, 조작부, 자료 참조에서 무엇이 바뀌었는지 확인합니다. 화면이 비슷해도 고장 난 탐색 조작부나 달라진 종료 시점이 숨어 있을 수 있습니다. 소스 차이가 커도 최종 동작이 올바르다면 허용할 수 있지만 직접 살펴봐야 합니다.
허용할 복구 기회를 미리 정하세요. 한 에이전트는 갈수록 구체적인 프롬프트를 세 번 받고 다른 에이전트는 한 번만 받았다면, 최종 두 결과를 동등한 첫 시도처럼 보여 주지 말고 그 차이를 보고하세요. 도움을 주는 일도 쓸 수 있는 결과에 도달하는 비용의 일부입니다.
전체 작업 과정 시험에서는 비슷한 권한 아래 에이전트가 자신의 산출물을 실행하고 확인하게 하세요. 실제로 사용한 도구와 필요한 사람의 개입을 기록합니다. 로딩 오류를 발견하고 고치는 에이전트는 스크린샷만 비교하면 놓치는 유용한 일을 수행한 것입니다.
거짓 정밀도 없이 비용 측정하기
경과 시간은 쉽게 기록할 수 있지만 쉽게 잘못 해석하기도 합니다. 여기서 Codex 요청에는 약 179초가 걸렸으며 로그에 기록된 시작 과정과 모델 탐색 시간 초과도 포함되어 있습니다. 순수한 생성 속도를 측정한 값이 아닙니다. 이를 “Codex는 애니메이션에 3분이 걸린다”라고 보고하면 측정 범위를 과장하게 됩니다.
더 유용하게 비교하려면 도구가 허용하는 범위에서 설정, 요청, 복구, 렌더링, 사람의 검토 시간을 구분하세요. 응답 지연보다 사용 가능한 산출물까지 걸리는 전체 시간이 더 중요할 수 있습니다. 빠른 첫 초안도 여러 번 신중하게 고쳐야 한다면 느리지만 정확한 결과보다 더 많은 노력이 들 수 있습니다.
실제 청구 맥락 없이 경과 시간이나 토큰 수로 금액을 추정하지 마세요. 구독 사용량, API 청구, 캐시된 입력, 모델 설정이 다를 수 있습니다. 신뢰할 만한 비용 수치를 구할 수 없다면 관찰 가능한 사용량 정보만 보고하고 비용은 미측정으로 두세요.
운영상의 설명에 실패도 포함하되 분류하세요. 인증 설정은 모델이 잘못된 코드를 만든 것과 다릅니다. 렌더링 의존성 실패는 읽기 어려운 디자인과 다릅니다. 이 구분이 있어야 도구와 이를 뒷받침할 작업 과정을 함께 선택하는 데 비교가 유용해집니다.
넓은 결론을 내리기 전에 대표 과제를 반복하세요. 작은 장면 하나로 실패 유형을 드러낼 수는 있습니다. 그것만으로 어떤 에이전트가 제품 출시, 기술 설명, 차트, 현지화, 앞으로의 모든 모션 작업에서 전반적으로 더 낫다고 입증할 수는 없습니다.
사람의 도움도 드러내기
공정한 비교에서는 요청 사이에 운영자가 한 일도 기록해야 합니다. 빠진 패키지 설치, 자료 찾기, 파일명 수정, 오류 설명은 최종 결과를 실질적으로 개선할 수 있습니다. 이런 도움이 보이지 않으면 사람의 기여를 에이전트의 성과로 돌리게 됩니다.
어떤 도움을 시험에 포함할지 결정하세요. 현실적인 작업 과정에서는 운영자가 제품 질문에 답하거나 파일 접근을 승인하는 것이 합리적일 수 있습니다. 통제된 코드 생성 시험에서는 수동으로 소스를 고치면 평가하는 산출물이 달라집니다. 어느 방식이 본질적으로 틀린 것은 아닙니다. 하나를 다른 방식인 것처럼 제시하는 것이 문제입니다.
짧은 개입 기록을 남기세요. 두 시스템에 같은 스크린샷을 제공했다거나, 청구 문구를 양쪽에 설명했다거나, 어느 결과를 열기 전 로컬 서버를 복구했다고 적을 수 있습니다. 한 시스템에만 복구가 필요했다면 그것도 기록하세요. 최종 화면이 비슷하게 좋아 보여도 추가 작업은 팀의 결정에 관련될 수 있습니다.
반복 실행에서는 운영자의 학습과 에이전트 성능을 구분하세요. 첫 시스템을 시험한 뒤 운영자가 과제를 더 잘 이해해 두 번째 시스템에 더 유용한 지침을 줄 수 있습니다. 실행 순서를 번갈아 바꾸거나 시작 전에 모든 입력을 고정하면 이런 이점을 줄일 수 있습니다. 소규모 로컬 연구에서 모든 변동 요인을 없앨 수는 없지만 드러낼 수는 있습니다.
이 투명성은 모션 작업에서 특히 중요합니다. 시각적 완성도가 빠른 판단을 유도하기 때문입니다. 세심한 수동 타이밍 조정이 필요했던 결과를 손대지 않은 단번 생성물로 설명해서는 안 됩니다. 제작 과정을 이해하면서도 결과를 높이 평가할 수 있습니다.
다른 사람이 확인할 수 있는 결과 공개하기
신뢰할 수 있는 비교에는 브리프, 자료 묶음 또는 확보 방법, 환경 기록, 원본 결과, 수정 프롬프트, 렌더 설정, 관찰한 검사가 포함됩니다. 독자가 매력적인 비교 이미지를 믿는 데 그치지 않고 결론의 근거를 이해할 수 있어야 합니다.
결과는 요건 수준에서 설명하세요. 초기 상태에서 정확한 문구를 통과했고, 재생은 끝에 도달했으며, 복구 전에는 탐색이 실패했습니다. 이후 짝을 맞춘 실행에서 같은 브리프와 검사를 사용하면 각 에이전트가 산출물을 어떻게 진단하고 수정하는지 비교할 수 있습니다.