Opus 4.6과 Codex 5.2에 같은 것을 만들도록 요청했더니 결과가 놀라웠다

Source: Dev.to

대부분의 세계가 이제 Opus 4.6과 Codex 5.2를 사용하고 있습니다

그들의 출시 후 24시간이 조금 넘은 시점에야 비로소 직접 테스트해볼 수 있었습니다. 워크플로우를 바꿔야 할 상황이 올까요?

얼마 전, 제 Discord 서버용으로 RAG 시스템에 사용할 콘텐츠를 수집하고 자동 역할 부여를 통해 모더레이션을 돕는 애플리케이션을 만들었습니다. 재미있는 사이드 프로젝트였죠.

새 모델들을 가지고 다시 뛰어들어 만지작거리기 전에, 먼저 테스트해보고 어떤 모델을 사용할지 결정하고 싶었습니다. 데이터 시각화 테스트를 선택했으며, 이는 프론트엔드‑중심에 약간의 로직 구현이 포함된 형태라고 볼 수 있습니다. 곧 백엔드 카테고리의 다른 프로젝트에 대해서도 별도 테스트를 진행할 예정입니다.

이번 테스트에서는 두 가지 주요 항목을 측정합니다: 속도와 정확도. 시작해봅시다.

테스트 설정

1. 연결 – 두 모델 모두 내 Xano.com 워크스페이스에 연결되어 데이터를 읽을 수 있도록 했습니다. (MCP에 대한 별도의 논의가 필요하지만, 모델이 플랫폼과 통신하는 방식은 이와 같습니다.)

2. 환경 –

   • Cursor 를 사용해 Codex를 테스트했습니다.
   • Claude (Claude 3 Opus 4.6) 를 사용해 Opus를 테스트했습니다.

   (핵심적으로, 이것들은 서로 다른 환경이며, 백그라운드 처리 방식이 달라 결과에 영향을 줄 수 있습니다. 향후 이를 위한 별도 테스트를 진행할 예정입니다.)

3. 프롬프트 – 두 모델 모두 동일한 프롬프트를 받았습니다:

   Please take the data from workspace 11 inside Xano (MCP); I want you to create a visual representation of all of my data as it relates to one another. By this, I want you to show me an isometric view of all the relationships between tables, data, and functions; this includes middlewares, authentication systems, tasks, and anything else. Please go through the entire application and assess all functions, tables, endpoints, tasks, and more to create a map.

   1. Scan through the necessary .XS files. Use MCP to assist with both application flow and data‑storage.
   2. Create an HTML page with CSS and JS that shows, in isometric view, the landscape of the application, with a way to visualize how everything is interconnected. This should be mildly video‑game‑like, but with emphasis on readability and accessibility.
   3. To assist with readability: query all data, persist as files within local.

   Your prompts may look different, which will 100 % impact the outcome of this experiment. However, I want to test the models on their ability to extrapolate from what I provide.

And we’re off to the races!

두 프로그램 모두에서 Enter 키를 누르니, Codex는 작업을 순식간에 처리하는 반면 Claude는 몇 분씩 멈칫거리는 모습을 보였습니다. 결정 과정에 큰 차이는 없지만, 실행 속도는 눈에 띄게 다릅니다.

• Codex는 5 분 55 초에 완료했습니다.
• **Claude (Opus 4.6)**는 8 분 정도가 지나서 마무리했습니다.

개발 속도 우승: Codex

Source:

기대했던 결과

Opus 4.6

먼저 Opus 4.6 결과부터 시작했습니다. 큰 놀라움은 없었지만, 페이지를 열었을 때 작동했고, 접근성도 확보되었으며, 머릿속에 그려두었던 시각적 모델과도 일치했습니다.

• 자동 줌, 드래그, 노드 클릭, 노드 클릭 해제 → 사이드바가 열리면서 연결 정보가 표시됩니다.
• 감탄은 아니었지만, Opus 4.6이 훌륭한 작업을 할 것이라고 전적으로 기대했습니다. 기준은 유지되었습니다.

Codex 5.2

빈 빌드

이는 예상하지 못한 결과였습니다. Codex에 대해 좋은 얘기만 들어서, 아무것도 로드되지 않은 점이 실망스러웠습니다.

Codex 자체를 탓하기는 어렵지만, 주어진 작업의 제약 안에서 서버 측에서 콘텐츠를 제공해야 한다고 가정했을 때 과잉 수행한 것으로 보입니다. 로컬에서 진행하고 싶었기 때문에 오류 코드를 복사해 Cursor에 넣어 적절히 코딩한 뒤 새로 고침을 했습니다.

수정된 빌드

시각화가 다소 투박했고, 무엇을 보고 있는지 파악하기 어려웠습니다. 전체 UX가 사용 가능하도록 만들기 위해 추가적인 프롬프트가 필요했습니다.

개발 정확도 우승자: Opus

Summary

궁극적으로 결과에 크게 실망하지는 않았습니다: Claude는 언제나 약간… 라는 느낌을 주었거든요.

원본 텍스트는 여기서 끊겼으며, 나머지 요약은 추후에 추가될 수 있습니다.

Better for me on the frontend

환경 차이를 고려하면, Codex는 여전히 적절한 백엔드 개발과 함께 CLI에서 현장 테스트를 갈망하고 있습니다.

하지만 놀랐나요? 예. 두 모델이 비슷한 결과를 낼 것이라고 정말 기대했었습니다.

당분간 워크플로우를 크게 바꿔야 할 것 같지는 않는데, Claude는 문맥을 읽고 사용자의 의도를 추론해 전달하는 데 뛰어난 친화력을 보여줍니다.

하지만 이는 모델의 성격과 어느 것이 당신의 개발 스타일에 더 맞는가에 대한 논의를 불러일으킵니다: 해석형 vs. 실행형.

이를 바탕으로, 그리고 나의 개발 스타일을 고려했을 때, 이번 테스트에서는 Opus 4.6이 승자라고 평가합니다. Codex는 속도가 빠르지만 정확도와 결과가 최종적인 판단 요소입니다.

특정하게 테스트해 보길 원하는 것이 있으면 댓글로 알려 주세요. 더 많은 테스트가 이어질 예정입니다!