# 2026년 2월 기준, 코딩 에이전트 활용 현황과 워크플로우 비교 > Clean Markdown view of GeekNews topic #26920. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26920](https://news.hada.io/topic?id=26920) - GeekNews Markdown: [https://news.hada.io/topic/26920.md](https://news.hada.io/topic/26920.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-23T14:21:02+09:00 - Updated: 2026-02-23T14:21:02+09:00 - Original source: [calv.info](https://calv.info/agents-feb-2026) - Points: 37 - Comments: 4 ## Summary 코딩 에이전트의 경쟁 구도가 **모델 성능 중심**에서 **자율 실행 시간과 컨텍스트 관리 능력** 중심으로 이동하고 있습니다. Anthropic의 **Claude Code(Opus)** 는 여러 컨텍스트 윈도우를 넘나들며 계획 수립과 도구 활용에 강점을 보이는 반면, OpenAI의 **Codex** 는 코드 정확성에서 우위를 점하지만 속도와 위임 구조가 한계로 지적됩니다. 개발자들은 반복 작업을 점진적으로 **skill 자동화**하며 계획→구현→리뷰 루프를 구축하고 있으며, 이는 장기적으로 24/7 자율 코딩 환경으로 이어질 기반이 되고 있습니다. ## Topic Body - 코딩 에이전트 선택의 핵심 기준이 **모델 성능 자체**가 아닌 **사용자의 가용 시간과 자율 실행 시간**으로 전환되고 있으며, Claude Code와 Codex를 **상황에 따라 병행** 사용 - Opus는 **컨텍스트 윈도우 관리와 도구 사용**에 강점을 보이며, 서브 에이전트를 동시에 여러 개 실행해 빠른 탐색과 계획 수립에 유리 - Codex는 **코드 정확성**에서 Opus를 능가하지만, 컨텍스트 윈도우 간 작업 위임이 부족해 처리 속도가 느린 단점 존재 - skill 자동화를 통해 계획 → 구현 → 리뷰 → 버그 수정 루프를 단계적으로 구축했으며, 처음부터 설계하기보다 **반복되는 수작업을 점진적으로 자동화**하는 접근이 효과적 - 궁극적으로 에이전트가 24/7 자율적으로 작업하는 미래를 향하고 있으나, **컨텍스트 윈도우 한계**와 **프롬프트 인젝션 저항성**이 주요 장벽 --- ### 백그라운드 - [Codex 웹 버전 관련 작업을 했었고](https://calv.info/openai-reflections), 2025년 7월에 OpenAI를 퇴사 - [YC Lightcone Podcast](https://www.youtube.com/watch?v=qwmmWzPnhog) 이후 코딩 에이전트 활용 세부 전략 정리 목적으로 이 글을 정리 - 에이전트 선택 기준이 모델 성능보다 **자율 실행 시간과 업무 중요도** 중심으로 이동하고 있음 - Claude Max, ChatGPT Pro, Cursor Pro+를 모두 구독 중이며 생산성 대비 비용 효율 높음 ### 핵심 원칙: 컨텍스트 이해 - 코딩 에이전트를 잘 쓰려면 **컨텍스트(context)** 를 반드시 이해해야 함 - 에이전트가 아무리 뛰어나도 결국 **next token prediction**을 수행하며, 모든 토큰은 컨텍스트 윈도우 안에 들어가야 함 - 이로부터 도출되는 주요 원칙: - 문제를 컨텍스트 윈도우에 맞게 **적절한 크기로 분할**해야 하며, 너무 큰 문제는 오래 걸리고 결과도 나쁨 - **Compaction은 손실이 있는 기법**으로, 어떤 정보를 포함하고 생략할지 에이전트가 판단하며, compaction이 많아질수록 성능 저하 경향 - 계획 문서 등으로 **컨텍스트를 파일시스템에 외부화**하면, 에이전트가 전체 대화 컨텍스트를 채우지 않고 선택적으로 읽고 기억 가능 - **컨텍스트 윈도우의 '스마트한 절반'에 머무는 것**이 중요하며, 짧은 컨텍스트 데이터에서 훈련이 더 잘 되므로 윈도우가 덜 찬 상태에서 더 나은 결과 도출 — Dex Horthy는 이를 **'[dumb zone](https://www.youtube.com/watch?v=rmvDxxNubIg&t=355s)'** 밖에 머무르라고 표현 - 에이전트가 관련 파일이나 패키지를 놓치면 예상치 못한 방향으로 진행될 수 있으며, 코드베이스 구조와 아키텍처의 **'점진적 공개(progressive disclosure)'** 가 도움됨 — [OpenAI가 여러 마크다운 파일을 구조화하는 방법](https://openai.com/index/harness-engineering/)에 대한 블로그 포스트를 게시한 바 있음 - 모델 성능과 속도는 모델 자체의 순수 성능뿐 아니라, **여러 컨텍스트 윈도우 관리 및 서브 에이전트/팀 위임 능력**에도 좌우됨 ### Opus: 컨텍스트 관리, 도구 사용, 인간적 느낌 - Claude Code를 **계획 수립, 터미널 조율, git/GitHub 작업 관리**의 주력 도구로 사용 - Opus는 **여러 컨텍스트 윈도우를 넘나들며 매우 효율적**으로 작동하도록 훈련되어 있어, Claude Code 사용 시 Codex보다 체감 속도가 빠름 - Opus가 `Explore`나 `Task` 호출 등 **여러 서브 에이전트를 동시에 실행**하는 모습이 자주 관찰됨 - Explore 도구는 **Haiku**를 사용하므로 대량의 토큰을 빠르게 처리하고 관련 컨텍스트를 Opus에 전달 - `gh`, `git`, 다양한 **MCP 서버** 등 로컬 도구 사용에 대한 훈련도 잘 되어 있음 - `/chrome` 확장 기능으로 버그 검증도 가능하나, 느리고 불안정할 수 있음 - Claude Code의 **권한 모델**이 Codex보다 이해하기 쉬움 — Codex 모델은 bash에서 명령을 스크립팅하는 경향이 있어 개별 CLI 도구 화이트리스팅이 어려움 - Claude Code의 세세한 UX 장점: **터미널 제목을 작업 관련 내용으로 업데이트**, 상태표시줄에 현재 PR 표시, 작은 상태 메시지 등 - Opus가 Codex보다 **인간이 이해하기 쉬운 PR 설명과 상세한 아키텍처 다이어그램** 생성에 뛰어남 - 코드 구조 설명을 요청할 때는 주로 Claude Code 사용 - Opus는 **계획 수립 시 더 '창의적'** 으로, 사용자가 언급하지 않은 부분을 제안하거나 모호한 영역을 짚어주는 특성이 있음 ### Codex: 압도적인 코드 정확성 - Codex가 빛나는 영역은 **코드의 정확성(correctness)** 이며, 모델을 많이 사용하는 다른 개발자들도 이에 동의 - **GPT-5.3-Codex-xhigh 또는 high**로 실행 시, Codex 코드가 버그가 확연히 적음 - Opus의 빈번한 실수 사례: - React 컴포넌트가 유닛 테스트를 통과하지만 **최상위 `<App>`에 추가하는 것을 잊음** - 명백한 **off-by-one 에러** 미감지 - 미묘한 **댕글링 참조(dangling references)** 나 **레이스 컨디션** - 오랫동안 두 모델 간 차이가 무시할 수준이라 생각했으나, Codex와 Cursor **Bugbot의 자동 리뷰**를 통해 충분한 PR을 본 후 OpenAI 모델의 코드 품질이 우수하다고 판단 - 직접 A/B 테스트하려면 브랜치를 체크아웃한 뒤 Claude Code의 `/code-review`와 Codex의 `/review`를 비교하면 됨 - 그러나 Codex는 **느림** — 주된 이유는 컨텍스트 윈도우 간 작업 위임이 부족하기 때문이며, 토큰 간 지연시간도 더 높은 것으로 체감 - 실험적 **서브 에이전트 지원**(`/experimental` 토글)을 사용하면 작동하지만, Claude만큼 매끄럽지는 않고 병렬성도 아직 부족 - 결과적으로 **Claude Code로 시작**하여 창에 열어두고, 실제 코딩 단계에서 **Codex로 전환**하는 패턴 ### 유용한 도구와 설정 - 현재 **그린필드 코드베이스** 작업 중이며, 프로덕션 코드베이스보다 훨씬 작고 토큰 효율적 - **레포 구조**: 모든 레포에 `plans/` 폴더를 두고 번호가 매겨진 계획서를 관리, `apps/` 폴더로 서비스 분리, **turborepo**로 TypeScript 모노레포 관리, **bun**으로 빠른 설치 - **Ghostty**: Mitchellh의 터미널로, 빠르고 네이티브이며 지속 개선 중 — 한때 tmux로 여러 Claude/Codex 인스턴스를 실행했으나 현재는 같은 터미널 탭 내 여러 pane 사용 - **Next.js on Vercel, API는 Cloudflare Durable Objects**: 데이터베이스를 사전 파티셔닝하고 온디맨드로 깨우며 동시 쓰기 걱정이 적은 구조 — 에이전트가 작은 데이터 조각을 다루는 시대에 인프라 관점에서 적합 - Cloudflare가 **cloudflare/actors** 라이브러리로 컴퓨트와 소규모 코로케이티드 스토리지를 묶는 방향으로 확장 중 - **Worktrees**: 코드가 가볍기 때문에 병렬 worktree를 활용, 각각에서 `bun install` → `bun run dev`로 로컬 검증 — 관련 계획·환경변수·업데이트를 복사하고 새 브랜치를 시작하는 `worktree` skill 사용 - 코딩 에이전트 이전에는 주로 브랜치만 사용했으나, worktree와 Claude Code의 조합이 매우 유용 - **Plan, Implement, Review**: 거의 항상 모델에 **계획부터 시작**하게 함 — 1) 단일 컨텍스트 윈도우 너머로 컨텍스트를 외부화 2) 무엇을 했는지 리뷰하거나 질문 가능 — 에이전트가 중단되면 새 컨텍스트 윈도우에서 계획 재개 가능 - **Preview deploys**: 모든 브랜치가 새로운 Web + API 배포를 받아, 병렬 실행과 빠른 테스트에 유리 — 이 기능 없이 작업하기 어려움 - **Cursor Bugbot과 Codex Code Review**: 아키텍처 수준에서 코드를 이해하고 스팟 체크하되, 점점 **모든 PR의 모든 라인을 읽지는 않음** — 에이전트가 미묘한 버그를 찾는 데 더 뛰어남 - 한때 Claude Code, Cursor Bugbot, Codex 세 가지를 모두 사용했으나 Claude Code는 실질적인 이슈를 잡지 못해, **Cursor를 기본 옵션**으로, Codex도 결과가 좋다고 평가 ### Skills: 자동화의 핵심 - 여러 **skill**과 공유 AGENTS.md/CLAUDE.md를 claudefiles라는 레포에 정의 - skill 추가 규칙: 섣불리 추가하지 않고, **몇 번 반복한 뒤 워크플로우가 안정된 후**에만 추가 - AGENTS/CLAUDE.md는 모델의 전반적 방향 유도에 유용하고, skill은 두 가지 목적: 1. **워크플로우 체이닝과 자동화** — 계획 → 단계별 구현 → 리뷰를 각각 skill로 만들고, 이를 순서대로 실행하는 메타 skill 구성 2. **컨텍스트 윈도우 분할** — Claude Code에서 skill 호출 시 `context: fork`를 설정하면 새 컨텍스트 윈도우에서 실행 가능, '마스터 오케스트레이터'와 서브 에이전트를 분리 - skill은 **매우 컨텍스트 효율적**으로, MCP 호출(수천 토큰)과 달리 보통 **~50-100 토큰** ### Skill 자동화의 진화 과정 - 초기에는 **skill 마켓플레이스** 아이디어(프론트엔드 디자인, 보안 점검, 아키텍처 리뷰 등을 설치)에 관심을 가졌으나, 작업을 거치며 **다른 사람이 작성한 skill은 대부분 포기** - 대신 수동 작업을 먼저 하고, 어떻게 자동화할지 고민하는 방식으로 전환 - skill 진화 과정: - **`/commit`**: 모델에 커밋·푸시를 다양한 방식으로 지시하는 대신 하나의 skill로 통합 — Claude Code에서 직접 차용 - **`/worktree`**: 에이전트가 별도 worktree에서 작업하도록, 계획 번호 기반(예: 00034-add-user-auth)으로 새 worktree 생성 - **`/implement`**: 계획 단계를 실행한 뒤 `/commit`을 수행하는 반복 작업을 하나의 skill로 통합 - **`/implement-all`**: 현재 worktree 경로를 계획 번호에 연결하여 모든 단계를 자동 구현 — 야간 실행 시 `/ralph-loop`으로 모든 단계 완료까지 계속 실행, 로컬 `/codex-review`로 `codex --review` 프로세스 생성 - **`/address-bugs`**: GitHub API에서 마지막 커밋 이후 Cursor + Codex 코멘트를 검색하여 버그 검증 및 수정 시도 - **`/pr-pass`**: `/implement-all` 종료 시 실행되며, 1) 리모트 푸시 2) 모든 CI 통과 대기 3) `/address-bugs` 실행 후 선택적으로 1단계 반복 - **`/focus`**: `plans` 디렉터리, 미완료 PR, worktree를 조회하여 기억을 새로고침하고 작업 추적 지원 - 이 프로세스를 **처음부터 만들려 했다면 성공하지 못했을 것**이며, 시간이 지나면서 자동화할 수 있는 작은 영역을 발견하며 점진적으로 구축한 것이 핵심 ### 기타 도구들 - **Codex App**을 최근 사용해 봤으며 세부 디테일과 작은 터치에 긍정적 인상 — 다만 CLI 도구의 유연성을 선호하여 완전 전환하지는 않음 - **Cowork**도 시도했으나 제대로 작동시키기 어려웠으며, 두 경우 모두 **샌드박싱 모델**이 큰 차이를 만듦 - 비동기 작업에 웹 인터페이스를 가끔 사용하지만, 점점 더 CLI에 의존 — 6개월 전에는 주로 **Cursor**와 내장 에이전트/확장 기능을 사용했던 것과 대비 - **pencil.dev**를 프론트엔드 UI 작업에 사용 중 — 로컬 Claude Code로 셸아웃하여 기존 구독을 재활용하는 배포 모델이 흥미로움 - 더 정형화된 **이슈 트래커** 필요성을 느끼고 있으며, David Cramer의 **Dex**와 Steve Yegge의 **beads**가 유망하지만 아직 필요 이상으로 복잡하게 느껴짐 - **Playwright** 등 자동화된 e2e MCP는 현재 사용하지 않음 ### 연구소들에 대한 조언 - ## Anthropic에 대한 피드백 - **모델**: Opus는 인간적 느낌, 엔지니어링 도구 활용, 컨텍스트 분할, "사용자가 잊었을 수 있는 것" 제안에 뛰어나지만 코드 정확성이 부족 — **'Opus Strict' 모드**로 기본 모델에 RL을 강화하여 성능 개선을 희망 - Opus로 시작하지만 코드는 Codex가 작성하며, 예산 제약이 있다면 Codex를 선택할 것 - **제품 하네스**: 거의 지적할 것이 없으며, Boris와 Cat의 아이디어가 뛰어남 - **agent skills** 표준 채택 요청 — 여러 CLI 간 디렉터리 심링크 작업이 불편 - `--stream-json`의 **출력 포맷 공개** 요청 — 사용자를 대신해 Claude Code를 샌드박스에서 실행하는 데 관심이 있으나, 포맷 변경 우려와 경로 설정이 다른 CLI 도구(Codex, Cursor, Gemini)보다 번거로움 - ## OpenAI에 대한 피드백 - **모델**: 최우선 개선 과제는 **컨텍스트 윈도우 간 분할과 서브 에이전트 위임** — Opus가 계획 수립에서 달성하는 "요청 이상의 것" 개념도 유용할 것 - **제품 하네스** 세부 피드백: - 샌드박싱 모델이 Claude Code와 비교해 **이해하기 어려움** — 모델이 스크립팅을 시도하므로 승인 요청이 많아지고, `--yolo` 모드 실행 시 우려 - Claude Code처럼 **CLI에 내장된 사용자 가이드** 추가 요청 — skill 위치, 지원 필드, 샌드박싱 모델 설정 등을 질문 가능하게 - `/review`를 패키지된 명령이 아닌 **일반 skill로 변환** 요청 — 모델이 동적으로 호출할 수 있도록 - 실행 시 **터미널 탭 제목을 작업 관련 내용으로 변경** 요청 — 수십 개의 `codex` 탭에서 혼란 발생 - **PR 설명과 커밋 설명에 특화된 훈련** 필요 — Codex의 간결한 성격은 좋지만 설명 확장 필요 - skill 정의에서 **`context: fork` 지원** 요청 - pane에서 링크가 줄을 넘기면 **클릭 가능하도록** 수정 - 상태바 하단에 현재 **worktree/PR/브랜치명 표시** 요청 ### 향후 전망 - Steve Yegge의 **[Gas Town](https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04)** 포스트를 인용 — 항상 토큰을 최대로 사용하고, 작업자 풀이 24/7 돌아가며, 많은 계획을 세우고 버릴 것을 기대해야 한다는 주장 - 추상화의 정확성 여부와 별개로, **방향적으로는 절대적으로 맞다**고 평가 - 이상적 미래: 노트북이나 클라우드 샌드박스가 **백그라운드에서 지속적으로 아이디어를 처리**하고, 사용자는 방향을 조정하거나 리서치를 하거나 결과를 리뷰하는 역할 - 코딩 에이전트 작업이 **엔지니어링 매니저 역할**과 유사하게 느껴지지만, 에이전트의 동기부여나 성격을 신경 쓸 필요 없음 - 현재 이 미래에 상당히 가까워진 상태 — 트위터에서는 과대광고되지만, 실제로 취침 전 **Codex에서 3-4개 작업을 시작**해 아침에 리뷰하는 루틴 수행 - 그러나 아직 **에이전트를 24/7 실행**할 수준은 아님 - 더 큰 진전을 가로막는 **두 가지 장벽**: 1. **컨텍스트 윈도우 크기/조율** — 에이전트가 같은 컨텍스트 윈도우에서 끝없이 압축/재활용할 수 없으며, 더 스마트한 하네스나 위임 메커니즘 필요 2. **프롬프트 인젝션 저항성** — 에이전트가 몇 분 만에 승인 요청을 하며, `--yolo` 모드를 신뢰할 수 없지만 허용 가능한 권한/도메인의 하위 집합이 존재 - 첫 번째 문제에 대해 Cursor가 **다수 컨텍스트 윈도우에 걸친 에이전트 스웜**의 한계를 밀어붙이고 있으며, 두 번째는 활발한 연구 영역 - 샌드박스 실행이 현재 최선의 우회책이나 설정이 여전히 번거롭고, 에이전트가 **오픈 인터넷 접근과 특권 데이터를 동시에 가지면** Simon Willison이 말한 **'Lethal Trifecta'** 에 취약 - 솔로 엔지니어로서 이미 **올바른 아이디어**가 병목이 되고 있으며, 점점 더 **아이디어, 아키텍처, 프로젝트 시퀀싱**이 훌륭한 제품을 만드는 데 있어 제약 요인이 될 것 ## Comments ### Comment 51665 - Author: yangeok - Created: 2026-02-23T15:58:22+09:00 - Points: 2 아키텍처도요..? ### Comment 51742 - Author: wegaia - Created: 2026-02-24T07:37:14+09:00 - Points: 1 코덱스에 서브 에이전트 기능만 있어도 옮겨갈거 같네요. 근데 뭐 관심이 없는건지.. ### Comment 51793 - Author: tested - Created: 2026-02-24T15:22:25+09:00 - Points: 1 - Parent comment: 51742 - Depth: 1 https://developers.openai.com/codex/multi-agent 실험적인 단계지만 진행하고는 있는 것 같네요. ### Comment 51779 - Author: kgcrom - Created: 2026-02-24T13:59:54+09:00 - Points: 1 - Parent comment: 51742 - Depth: 1 codex cli 에서 /experimental 명령어 입력하면 실험 기능으로 Multi-agents를 제공하고 있어요. › [x] Multi-agents Ask Codex to spawn multiple agents to parallelize the work and win in efficiency. 얘기하신 서브 에이전트와 결이 같은지는 모르지만 한번 알아보셔요.