Transcript
00:00:00오랜 시간 동안 코딩용 AI 모델의 대세는 Claude였습니다.
00:00:03단순히 성능이 좋아서뿐만 아니라, 같은 급의 다른 대안이 없었기 때문이죠.
00:00:07그러다 GPT 모델들이 격차를 좁히며 따라붙었습니다. 특히 GPT 5.5 출시와 함께
00:00:12그 격차는 거의 사라졌습니다.
00:00:14두 모델을 비교하기 위해 각각에 최적화된 환경에 배치할 필요가 있었고,
00:00:18그것은 곧 각자의 CLI를 의미했습니다.
00:00:19그래서 저희는 Opus 4.7과 GPT 5.5의 성능이 서로에 대해 어느 정도인지
00:00:25테스트해 보려 합니다.
00:00:269가지 카테고리에 걸쳐 테스트하여 실제로 어떤 모델이 우위에 있는지 알아보고,
00:00:29마지막에는 여러분의 워크플로우에 어떤 모델이 적합한지 알게 되실 겁니다.
00:00:33사용성 측면에서 Claude Code는 무너지기 시작했습니다.
00:00:36저희는 코딩과 비코딩 작업 대부분에 이 도구를 사용해 왔는데, 사실 2.1.0 업데이트 전까지만 좋았습니다.
00:00:40그 이후로 Claude Code의 상태는 나빠지기 시작했습니다.
00:00:43UI가 가장 답답한 부분인데, 사용자 경험에 가장 큰 영향을 미치기 때문입니다.
00:00:46터미널이 오작동하고 렌더링이 깨지는 등, 예전의 정교했던 느낌이 이제는 엉성하게 느껴집니다.
00:00:50최고의 TUI 중 하나였지만, 소위 "바이브 코딩"이 시작되면서 변했습니다.
00:00:55렌더링 이슈, 캐시 누수 등 여러 버그로 인해 더 엉망이 된 느낌인데,
00:00:56이에 대해 불평하는 것은 저희뿐만이 아니었습니다.
00:00:59더 큰 문제는 위험성 때문에 건너뛰었던 권한 모드를 삭제하고
00:01:03자동 모드를 기본값으로 대체했다는 점입니다.
00:01:05저희는 대부분의 작업에서 권한 우회 모드를 사용했고, Claude가 건드리지 말아야 할
00:01:09파일들은 훅(hook)을 설정해 두었습니다.
00:01:11이제는 그 모드에서조차 권한을 묻습니다. Claude에게 스킬을 만들라고 명령하고,
00:01:15다른 작업을 위해 다른 Claude 세션으로 옮겨갔다가 나중에 돌아와 보니,
00:01:17스킬 생성이 .claude 폴더 쓰기 권한 요청 때문에 내내 멈춰 있었습니다.
00:01:22스킬이 다 만들어졌을 거라 기대하고 돌아왔는데, 그저 대기 중이었던 거죠.
00:01:27Codex는 이 부분을 더 잘 처리합니다. YOLO 모드는 Claude Code의 자동 모드와 달리
00:01:32어떤 권한도 묻지 않기 때문입니다.
00:01:36CLI가 Rust로 제작되어 UI가 React 기반인 Claude Code보다 훨씬 매끄럽고,
00:01:40긴 세션 후에도 깨지는 법이 없습니다.
00:01:42페르소나 설정 또한 Codex가 앞서가는 부분입니다.
00:01:47페르소나를 더 직접적이고 간결한 언어로 설정할 수 있습니다.
00:01:49GPT 5.5가 Opus 4.7보다 훨씬 더 아첨을 잘하고 모든 프롬프트에 동조하는 경향이 있기 때문인데,
00:01:53그래서 Codex에서 페르소나를 변경하는 것이 모델의 기본 동작을 방지하는 데 도움이 됩니다.
00:01:56Opus 4.7을 직설적으로 만들려면 Claude.md의 지침에 의존해야 하지만,
00:02:02Codex는 설정 변경만으로 가능합니다.
00:02:04사전 설치된 스킬 또한 차이점 중 하나입니다.
00:02:08Codex는 에이전트 브라우저 스킬을 포함하여 Claude Code에는 없는 많은 스킬을 기본 제공합니다.
00:02:14이는 앱 개발자에게 중요한데, Codex에서는 브라우저 검증을 위해
00:02:16명시적으로 MCP를 연결할 필요가 없기 때문입니다.
00:02:18기능 구현 후 자동으로 검증을 수행합니다.
00:02:22또한 내장된 스킬 생성기가 있어, 새로운 스킬이 필요할 때 올바른 구조와
00:02:26참조 파일을 갖춘 완전한 스킬을 생성해 줍니다.
00:02:29Claude에서는 적절한 구조의 스킬을 얻으려면 스킬 생성기를 별도로 설치해야 합니다.
00:02:31그렇지 않으면 그저 MD 파일 하나만 작성할 뿐입니다.
00:02:35물론 Claude Code가 여전히 더 잘하는 두 가지가 있습니다.
00:02:38Codex는 저희가 가장 많이 사용하는 기능인 '되감기(rewinding)'를 제공하지 않는데,
00:02:42이는 확실한 단점입니다.
00:02:43또한 Claude Code는 Ctrl+O로 사고 과정을 확장해서 볼 수 있는데,
00:02:45Codex는 이 기능을 제대로 지원하지 않습니다.
00:02:47추론 과정을 보는 것은 유용합니다. 작업 완료를 기다린 뒤 다시 작업하는 대신,
00:02:51작업 중간에 접근 방식을 바로잡을 수 있기 때문입니다.
00:02:52업데이트마다 나빠지는 Claude Code의 사용자 경험을 고려하면,
00:02:57사용성 면에서는 Codex가 승점을 가져갑니다.
00:02:58비용 면에서 Claude Code는 훨씬 더 비싼 도구입니다.
00:03:02실제 가격이 비싸다기보다는, 같은 가격 대비 사용성 측면에서 그렇습니다.
00:03:05Claude Code는 무료 티어에서는 아예 사용할 수 없고, Pro 및 Max 플랜부터 가능합니다.
00:03:10각 플랜의 가격 체계는 거의 동일합니다.
00:03:11Pro 플랜은 어느 정도 규모가 있는 앱에 사용하기엔 거의 불가능한 수준입니다.
00:03:15단 몇 가지 작업만으로 한계에 도달하기 때문입니다.
00:03:19Pro에서는 유의미한 작업에 Opus 4.7을 제대로 활용할 수조차 없습니다.
00:03:23저희가 사용하는 Max 플랜에서도 제한이 매우 빨리 소진됩니다.
00:03:24Codex는 시작부터 더 유리한 위치에 있습니다.
00:03:26무료 플랜에서도 제한적이나마 사용할 수 있기 때문입니다.
00:03:30두 도구 모두 유사한 5시간 창(window) 메커니즘을 사용하므로, 어떤 도구가
00:03:32더 많은 일을 처리하는지 확인하기 위해 같은 규모의 작업을 실행해 보았습니다.
00:03:36Claude Code는 이미 세션에서 사용된 토큰량을 시각화하는 context 명령어가 있지만,
00:03:39Codex에는 내장된 기능이 없어 비교를 위해 해결책을 찾아야 했습니다.
00:03:41두 도구 모두 세션을 JSON 파일로 저장하지만 조직 방식이 다릅니다.
00:03:44그래서 파일을 읽어 각 세션의 사용 토큰을 계산하는 작은 도구를 만들었습니다.
00:03:49동일한 앱과 비슷한 수준의 디버깅 상황에서 Opus 4.7은 173,000 토큰을 사용한 반면,
00:03:51GPT 5.5는 82,000 토큰만 사용했습니다.
00:03:56GPT 5.5가 더 적은 토큰과 훨씬 적은 재시도로 작업을 끝냈기 때문입니다.
00:04:00결과적으로 Codex가 훨씬 더 오래 지속되었고 같은 작업 대비 비용 효율도 훨씬 높았습니다.
00:04:04계속 진행하기 전에, 스폰서인 Stream에 대해 잠시 말씀드리겠습니다.
00:04:08앱을 개발 중인데 사용자들이 대화하고, 스트리밍하고, 연결되어야 한다고 가정해 봅시다.
00:04:15직접 처리하려고 시도하다 보면 3개월 후에도 제품 출시 대신 디버깅만 하고 있을 겁니다.
00:04:18Stream은 그 모든 과정을 생략해 줍니다.
00:04:23Stream은 앱 내 채팅과 영상 통화부터 활동 피드,
00:04:28AI 모데레이션까지 모든 것을 즉시 제공하므로, 인프라 구축 대신 기능을 출시하는 데 집중할 수 있습니다.
00:04:32왓츠앱 스타일의 메시징, 줌 스타일의 영상 통화, 인스타그램 스타일의 피드가 모두 기본 내장되어 있습니다.
00:04:35특히 눈에 띄는 것은 Stream의 신규 출시작인 Vision Agents입니다.
00:04:39라이브 영상과 오디오를 보고 듣고 행동하는 지능형 AI 에이전트를 구축할 수 있으며,
00:04:40파이썬으로 단 몇 줄의 코드만 작성하면 됩니다.
00:04:44모든 서비스는 어디서나 짧은 지연 시간을 유지하도록 글로벌 엣지 네트워크에서 실행됩니다.
00:04:49스타트업부터 성장 중인 앱까지, 소셜, 피트니스, 커뮤니티 분야의 주요 플랫폼들이
00:04:5510억 명 이상의 최종 사용자에게 서비스를 제공하기 위해 Stream을 신뢰하고 있습니다.
00:04:58차세대 대형 앱을 구축하는 개발자라면, Stream은 첫날부터 여러분과 함께 확장할 것입니다.
00:05:02getstream.io에서 무료로 시작해 보세요. 링크는 고정 댓글에 있습니다.
00:05:05두 모델의 진정한 시험대는 제품을 어떻게 구축하느냐에 있습니다.
00:05:08앞서 말했듯이 GPT 5.5는 더 빠르고 토큰 소모가 적어 작동하는 앱을 더 빨리 출시합니다.
00:05:13Opus 4.7은 사고(thinking)에 더 많은 토큰을 사용하며, 더 깊게 계획하고
00:05:16앱의 모든 측면을 동시에 반복해서 개선합니다.
00:05:20저희가 먼저 테스트하고 싶었던 것은 기획(planning)이었습니다.
00:05:24저희는 오랫동안 Claude Code의 기획 모드를 사용해 왔습니다.
00:05:27대부분의 영역을 커버하고 몇몇 결함은 있지만 여전히 꽤 쓸만합니다.
00:05:33OpenAI가 기획 및 실행 능력에서 우수하다고 주장하는 만큼,
00:05:38GPT 5.5의 기획 성능이 어떠한지 확인하고 싶었습니다.
00:05:40FastAPI로 구축된 API 백엔드가 이미 포함된 폴더에서 기획 모드를 활성화하고,
00:05:42해당 백엔드에 맞는 프론트엔드를 구축해 달라고 요청했습니다.
00:05:45프로젝트를 철저히 탐색하고 몇 가지 질문을 던졌지만, 질문 수준은 상당히 단순했습니다.
00:05:48단순했습니다.
00:05:53프론트엔드 작업에서는 디자인이 중요하기 때문에, 우리가 어떤 모습을 원하는지
00:05:55더 깊이 있게 물어볼 수도 있었을 것입니다.
00:06:00제시된 계획은 매우 간단했습니다.
00:06:04잘한 점 하나는 자신의 가정을 명확히 분리했다는 것인데,
00:06:08덕분에 어떤 부분을 당연하게 여기고 있는지 정확히 알 수 있었습니다.
00:06:09진행하라고 지시하자 약 8분 만에 완료했습니다.
00:06:13같은 작업이 Claude Code에서는 24분이 걸렸습니다.
00:06:14하지만 Opus 4.7의 계획은 훨씬 더 심도 있었고, 애플리케이션의 더 많은 측면을 고려했으며,
00:06:16사용자 경험을 개선하기 위해 Shadcn UI까지 가져와 사용했습니다.
00:06:20따라서 기획 측면에서는 Opus 4.7이 더 우수합니다.
00:06:21다음으로, 두 모델을 백지 상태의 신규 앱(Greenfield app)에서 테스트했습니다.
00:06:25Python Flask 백엔드와 Next.js 프론트엔드를 갖춘 모노레포를 생성하고,
00:06:26전체 파이프라인과 앱 작동을 위한 핵심 요구 사항이 포함된 동일한 프롬프트를 주었습니다.
00:06:28Claude Code는 하네스 설계 덕분에 스스로 기획 모드로 전환했습니다.
00:06:31반면 Codex는 기획 모드로 전환하지 않고 즉시 구현을 시작했습니다.
00:06:36Codex는 기획 단계 때문에 약 16분이 걸린 Claude Code보다 훨씬 빨리 끝냈습니다.
00:06:39GPT 5.5가 만든 앱 버전은 UI가 훨씬 단순했고, 주로 앱이 제대로 작동하는지에
00:06:42초점을 맞췄습니다.
00:06:45기획 단계 덕분에 약 16분이 걸린 Claude Code보다 훨씬 빠르게 작업을 마쳤지만,
00:06:50그 이유는 바로 기획 단계가 생략되었기 때문입니다.
00:06:55GPT 5.5 버전의 앱은 UI가 훨씬 단순했으며 주로 앱이 정상적으로 작동하는지에만
00:06:56집중했습니다.
00:06:59처음에는 제대로 작동하지 않아서 반복적으로 디버깅을 거쳐야 했습니다.
00:07:04한 가지 눈에 띄는 점은 인터뷰 프롬프트가 하드코딩되어 있었다는 것인데, 이는 저희가
00:07:08이러한 폴백 메커니즘은 앱 충돌을 방지하므로 실제 운영 환경에서 매우 유용합니다.
00:07:09몇 번의 반복 작업과 API 키 추가 후, UI는 여전히 단순했지만
00:07:14앱의 흐름은 정상적으로 작동했습니다.
00:07:15결국 GPT 5.5는 예외 케이스를 살피고 공백을 메울 메커니즘을 구현해 낸 것입니다.
00:07:17반면 Opus 4.7은 구현을 시작하기 전에 API 키를 달라고 요청했고,
00:07:22그것을 중심으로 앱 전체를 구축했습니다.
00:07:23Opus 4.7은 GPT 5.5와 달리 예외 상황에 대비하지 않았고 모든 것이
00:07:27미리 준비되어 있어야 했습니다.
00:07:30이 때문에 실제로 API가 없었을 때 앱은 폴백 없이 그저 에러만 내뿜었습니다.
00:07:35Claude Code는 사용자 경험과 기능을 동시에 중시하므로 구현 결과물은
00:07:39더 현실적으로 보였습니다.
00:07:40이는 이전 영상에서 Opus 4.7이 UI 처리에 훨씬 뛰어나다고 언급했던
00:07:44강점이 드러난 부분이지만, 구현 과정에서 문제는 있었습니다.
00:07:46디버깅을 요청했을 때, Codex처럼 구현 내용을 직접 조사하지 않았습니다.
00:07:51대신 문제의 원인이 무엇일지 저희에게 질문을 던지며 저희의 테스트에 의존했습니다.
00:07:57UI의 상태 표시기나 콘솔 로그 같은 디버그 포인트를 추가하고는,
00:07:59저희에게 상태를 확인해서 보고해 달라고 요청했습니다.
00:08:05몇 번의 대화 끝에 결국 문제를 해결했고 면접 기능도 작동했습니다.
00:08:06저희는 Codex가 에이전트 브라우저를 사용해 스스로 디버깅하는 방식을 더 선호했습니다.
00:08:10자율적인 작업 능력 면에서는 Codex의 구현이 더 나았고,
00:08:15사용자 경험 면에서는 Claude Code가 훨씬 더 훌륭했습니다.
00:08:16또한 두 도구가 init 명령어를 어떻게 처리하는지도 테스트해 보고 싶었습니다.
00:08:21Claude Code의 init은 프롬프트를 인라인으로 확장하지 않고 실행됩니다.
00:08:26약 90줄 정도의 간단한 Claude.md 파일을 생성하는데, 여기에는 아키텍처, 앱 흐름,
00:08:31프론트엔드 및 백엔드 구조, 앱 실행을 위한 모든 명령어가 포함됩니다.
00:08:35이 중 상당수는 중복된 정보이며 에이전트에게 실질적인 도움이 되지 않기에
00:08:36모든 내용을 유지할 필요는 없습니다.
00:08:41Codex의 설정 방식이 더 정교했습니다.
00:08:42커밋 가이드라인, 풀 리퀘스트 가이드라인, 보안 지침을 제대로 포함하면서도
00:08:46프로젝트 구조 섹션은 상세 정보로 과부하를 주지 않고 간결하게 유지했습니다.
00:08:49둘 다 완벽하진 않았지만, Codex가 agents.md를 더 잘 처리했습니다.
00:08:53코드 리뷰 성능도 테스트해 보았습니다.
00:08:56Codex와 Claude Code에 동일한 신뢰성 리뷰 프롬프트를 주고,
00:08:59같은 코드베이스에서 작업하며 리뷰 내용을 별도 파일로 문서화하라고 요청했습니다.
00:09:02보고서가 생성된 후 새 세션을 열어 Claude에게 두 파일의 차이(diff)를 출력하고
00:09:08분석 결과를 비교해 달라고 했습니다.
00:09:12Claude의 리뷰가 훨씬 더 상세했습니다.
00:09:15모든 분석 내용을 우선순위별로 정리했고, 문제가 되는 구성 요소와
00:09:18정확한 코드 스니펫을 포함했습니다.
00:09:20Codex의 보고서는 줄 번호는 언급했지만 실제 코드 스니펫은 포함하지 않았습니다.
00:09:24두 보고서 모두 철저했으며, 공통된 분석 내용을 공유하면서도
00:09:28상대방이 놓친 부분을 각자 몇 가지씩 잡아냈습니다.
00:09:32Claude Code는 유출된 API 키나 취약점 같은 보안 이슈도 보고했습니다.
00:09:35하지만 본 작업은 신뢰성 리뷰였으므로 해당 이슈들은 범위를 벗어난 것이었습니다.
00:09:40Claude Code는 진행 중 발견한 모든 추가 문제를 보고한 반면, Codex는
00:09:44엄격하게 신뢰성 문제에만 집중했습니다.
00:09:48따라서 Codex의 보고서가 원래 요청에 더 부합했고, Claude Code의 보고서는 범위는 넓었지만
00:09:51특정 작업에 대한 집중도는 낮았습니다.
00:09:53개발 스타일로 비유하자면, GPT 5.5는 애플리케이션의 기능 구현을
00:09:57최우선으로 하는 백엔드 엔지니어 같은 느낌입니다.
00:09:59반면 Opus 4.7은 기능과 사용자 경험의 균형을 맞추려 노력하는
00:10:03풀스택 엔지니어에 더 가깝습니다.
00:10:07컨텍스트 관리 측면에서는 Codex가 Claude Code보다 훨씬 뛰어난 성능을 보였습니다.
00:10:08Claude Code는 세션 내 컨텍스트 편집 기능이 있어, 대화에서 더 이상
00:10:12중요하지 않은 도구 호출이나 추론 단계를 삭제합니다.
00:10:17세션의 비대화를 방지하기 위해 불필요한 정보를 정리하는 것이죠.
00:10:21압축(compaction)이 완벽하진 않지만, 적어도 압축 과정에서
00:10:22컨텍스트 관리 측면에서는 Codex가 Claude Code보다 훨씬 더 뛰어난 성능을 보였습니다.
00:10:27Codex는 컨텍스트를 직접 편집하지 않습니다.
00:10:29대신 전체 대화 내용을 발생한 그대로 압축합니다.
00:10:34잘하는 점 하나는 마지막 20,000 토큰을 메모리에 보존하고
00:10:40그 부분은 전혀 압축하지 않는다는 점입니다.
00:10:45이는 압축 후 Codex의 성능 저하를 방지하여 다음 프롬프트부터
00:10:48대화가 매끄럽게 이어질 수 있도록 돕습니다.
00:10:53성능 테스트 결과, 압축 후의 성능은 Codex가 Claude Code보다 우수했습니다.
00:10:55비록 Claude Code가 더 상세한 다단계 압축 과정을 거치더라도, Codex가
00:10:58최근 내용을 보존하는 방식이 실제 사용 시 에이전트를 더 유용하게 만듭니다.
00:11:02기억(Memory) 방식은 두 모델이 서로 다릅니다.
00:11:03Claude Code의 하네스는 세션 간에 대부분 상태가 유지되지 않으므로, 각 세션은
00:11:05이전 세션의 컨텍스트 없이 시작됩니다.
00:11:08이제는 지속적인 선호도나 지침을 저장할 수 있는 기억 기능이 생겼습니다.
00:11:13특정 방식을 피하라고 말하면, 이를 저장했다가 동일 프로젝트 내의
00:11:14나중 작업에도 다시 적용합니다.
00:11:18이는 하나의 프로젝트에서 반복해서 작업할 때 큰 도움이 됩니다.
00:11:21성능 테스트 결과, 압축 후의 성능은 Claude Code보다 Codex가 더 뛰어났습니다.
00:11:25Claude Code가 더 세밀한 다단계 압축 프로세스를 따르지만, Codex는 뒷부분 데이터를
00:11:30보존함으로써 실제 사용 시 에이전트의 유용성을 더 잘 유지합니다.
00:11:33메모리 작동 방식도 두 모델 간에 차이가 있습니다.
00:11:35Claude Code의 하네스는 세션 간에 대부분 상태를 유지하지 않으므로, 각 세션은
00:11:39이전 세션의 컨텍스트 없이 시작됩니다.
00:11:41현재는 영구적인 기본 설정이나 지침을 저장할 수 있는 메모리 기능이 추가되었습니다.
00:11:46따라서 특정 방식을 피하도록 지시하면, 이를 저장했다가
00:11:50나중에 동일한 프로젝트 내에서 다시 적용합니다.
00:11:52이는 단일 프로젝트에서 반복적으로 작업할 때 도움이 됩니다.
00:11:54하지만 메모리가 프로젝트 단위로 제한되어, 프로젝트를 바꾸면 저장된 동작을 잃게 됩니다.
00:11:58반면 Codex는 반대의 길을 택합니다.
00:12:00시간이 지남에 따라 여러 세션의 정보를 통합하고 상호작용 전반에 걸친 글로벌 메모리를 구축하여,
00:12:05단일 프로젝트를 넘어선 패턴을 유지할 수 있습니다.
00:12:08이는 서로 다른 작업 간의 일관성을 유지하는 데 도움이 됩니다.
00:12:11요약하자면, Claude Code는 메모리를 프로젝트 내에 가두는 반면, Codex는
00:12:15세션과 프로젝트를 넘나드는 방식을 취하여 시간이 지남에 따라 각자 다르게 적응합니다.
00:12:19이러한 차이가 발생합니다.
00:12:20Claude Code는 더 오래전부터 존재해 왔고 개발자 경험 개선을 위해 끊임없이 발전했기에,
00:12:24Codex에 비해 제공하는 기능이 더 많습니다.
00:12:27Claude Code에는 에이전트의 라이프사이클 중 특정 시점(예: 도구 실행 전후 등)에
00:12:32자체 스크립트를 실행할 수 있는 훅(Hook) 시스템이 있습니다.
00:12:36이를 통해 안전하지 않은 명령을 차단하거나 포맷터를 실행하는 등의 작업이 가능합니다.
00:12:39또한 전용 작업 트리에서 서브 에이전트를 실행할 수 있어 서로의 성능에
00:12:43영향을 주지 않습니다.
00:12:44모델의 노력 수준을 제어할 수 있으며, "ultra-think"와 같은 키워드를 사용해
00:12:48특정 작업에 대한 추론 능력을 최대로 끌어올릴 수도 있습니다.
00:12:51현재 Codex에는 이와 동등한 기능이 전혀 없습니다.
00:12:54생태계 측면에서도 Claude Code가 확실히 우세합니다.
00:12:56Claude 데스크톱 앱을 통해 세션을 실행하고 모바일 앱에서 작업을 위임할 수 있습니다.
00:13:01Claude Code, 데스크톱 앱, 웹 앱, 브라우저 확장 프로그램에 이르기까지 그 범위는
00:13:06최근에야 출시되어 테스트 당시 성능이 비교적 약했던 Codex의 웹 및 데스크톱 앱보다
00:13:11훨씬 더 넓습니다.
00:13:14세션 또한 Claude Code 환경 사이를 더 쉽게 이동할 수 있어,
00:13:18다양한 인터페이스에서 작업하기에 더 편리합니다.
00:13:20Codex 역시 흥미로운 기능들을 많이 가지고 있습니다.
00:13:22클라우드 환경에서는 동일한 작업을 n번 실행하는 시도(attempt) 플래그가 있습니다.
00:13:26여러 구현 결과물을 생성한 뒤 그중 최상의 것을 선택합니다.
00:13:29Claude Code도 비슷하게 할 수 있지만, 플래그 형식이 아니라
00:13:33구성 설정과 지침을 통해서만 가능합니다.
00:13:34Codex만의 또 다른 차별점은 OpenAI의 이미지 모델과의
00:13:38통합입니다.
00:13:39CLI에서 직접 이미지 모델을 사용하여 작업 중인 웹사이트용 이미지를 생성할 수 있습니다.
00:13:44Claude는 시각적 요소 생성 시 주로 SVG 방식에 의존하는데, 아직 이미지 모델이 없어서
00:13:49품질 면에서는 경쟁 상대가 되지 않습니다.
00:13:52실제 이미지가 필요한 UI를 구축한다면, 명시적으로 지시하지 않아도
00:13:56이를 수행할 수 있는 것은 두 모델 중 Codex뿐입니다.
00:13:58또한 저희 콘텐츠가 마음에 드신다면 하이프(Hype) 버튼을 눌러주세요.
00:14:03더 많은 콘텐츠를 제작하고 더 많은 분께 다가가는 데 큰 도움이 됩니다.
00:14:06서브 에이전트 개념은 Claude가 먼저 도입했지만, 현재는 둘 다 사용하고 있습니다.
00:14:10Claude Code는 처음부터 에이전트 중심이었고 OpenAI보다 훨씬 더 오래
00:14:15코딩 경험에 집중해 왔기 때문에 통합 수준이 더 성숙합니다.
00:14:19Claude는 원격 세션을 통해 오케스트레이션되는 에이전트를 지원하는 반면, Codex는 주로
00:14:23터미널 환경 내부에서의 멀티 에이전트 워크플로우를 지원합니다.
00:14:27가장 큰 차이점은 서브 에이전트를 호출하는 방식입니다.
00:14:29Claude Code는 명시적인 호출 없이도 에이전트를 생성할 수 있지만, Codex는 프롬프트에서
00:14:35명시적으로 요청해야만 에이전트를 생성합니다.
00:14:37Codex는 에이전트를 생성할 때 이름을 지정하고 적절한 프롬프트도 함께 전달합니다.
00:14:41코딩 성능은 둘 다 비슷하지만, 그 이면의 설계 선택은 서로 다릅니다.
00:14:46Claude Code의 서브 에이전트는 명시적 허용 목록을 사용합니다. 즉, 상위 에이전트가
00:14:51서브 에이전트가 접근할 수 있는 도구를 정확히 정의하는 반면, Codex의 서브 에이전트는
00:14:55기본적으로 상위 에이전트의 도구 접근 권한을 상속받습니다.
00:14:57또한 Claude Code는 모든 서브 에이전트에게 완전히 새로운 컨텍스트 창을 제공합니다.
00:15:01서브 에이전트는 대화 기록에 접근할 수 없으며 상위 에이전트의 프롬프트와
00:15:06시스템 프롬프트, 글로벌 규칙만 볼 수 있습니다. 컨텍스트 격리에 집중하기 때문입니다.
00:15:10Codex CLI는 그 반대입니다.
00:15:12전체 기록을 서브 에이전트 세션으로 복제하고 그 위에 상위 프롬프트를 얹습니다.
00:15:17Codex 에이전트는 이미 논의된 내용에 대해 더 많은 컨텍스트를 유지하며, 이는
00:15:22실제로 성능 향상에 도움이 됩니다.
00:15:23실무에서 Claude Code의 엄격한 격리는 저희의 리서치 서브 에이전트들에게 독이 되었습니다.
00:15:27서브 에이전트들이 직전의 프롬프트만 보고 이전 컨텍스트를 알지 못했기에,
00:15:30결과가 충분히 만족스럽지 못했습니다.
00:15:33전체 기록을 받는 Codex 에이전트는 더 효과적으로 반복 작업을 수행할 수 있으며,
00:15:38연속성이 중요한 작업에서 더 나은 성능을 보여줍니다.
00:15:39이제 이번 영상의 끝에 다다랐습니다.
00:15:41채널을 후원하고 이런 영상을 계속 만드는 데 도움을 주고 싶으시다면,
00:15:45하단의 'Super Thanks' 버튼을 이용해 주시기 바랍니다.
00:15:48언제나 시청해 주셔서 감사드리며, 다음 영상에서 뵙겠습니다.