2026년 2월 기준, 코딩 에이전트 활용 현황과 워크플로우 비교

(calv.info)

15P by neo 18시간전 | ★ favorite | 댓글 2개

코딩 에이전트 선택의 핵심 기준이 모델 성능 자체가 아닌 사용자의 가용 시간과 자율 실행 시간으로 전환되고 있으며, Claude Code와 Codex를 상황에 따라 병행 사용
Opus는 컨텍스트 윈도우 관리와 도구 사용에 강점을 보이며, 서브 에이전트를 동시에 여러 개 실행해 빠른 탐색과 계획 수립에 유리
Codex는 코드 정확성에서 Opus를 능가하지만, 컨텍스트 윈도우 간 작업 위임이 부족해 처리 속도가 느린 단점 존재
skill 자동화를 통해 계획 → 구현 → 리뷰 → 버그 수정 루프를 단계적으로 구축했으며, 처음부터 설계하기보다 반복되는 수작업을 점진적으로 자동화하는 접근이 효과적
궁극적으로 에이전트가 24/7 자율적으로 작업하는 미래를 향하고 있으나, 컨텍스트 윈도우 한계와 프롬프트 인젝션 저항성이 주요 장벽

백그라운드

Codex 웹 버전 관련 작업을 했었고, 2025년 7월에 OpenAI를 퇴사
YC Lightcone Podcast 이후 코딩 에이전트 활용 세부 전략 정리 목적으로 이 글을 정리
에이전트 선택 기준이 모델 성능보다 자율 실행 시간과 업무 중요도 중심으로 이동하고 있음
Claude Max, ChatGPT Pro, Cursor Pro+를 모두 구독 중이며 생산성 대비 비용 효율 높음

핵심 원칙: 컨텍스트 이해

코딩 에이전트를 잘 쓰려면 컨텍스트(context) 를 반드시 이해해야 함
에이전트가 아무리 뛰어나도 결국 next token prediction을 수행하며, 모든 토큰은 컨텍스트 윈도우 안에 들어가야 함
이로부터 도출되는 주요 원칙:
- 문제를 컨텍스트 윈도우에 맞게 적절한 크기로 분할해야 하며, 너무 큰 문제는 오래 걸리고 결과도 나쁨
- Compaction은 손실이 있는 기법으로, 어떤 정보를 포함하고 생략할지 에이전트가 판단하며, compaction이 많아질수록 성능 저하 경향
- 계획 문서 등으로 컨텍스트를 파일시스템에 외부화하면, 에이전트가 전체 대화 컨텍스트를 채우지 않고 선택적으로 읽고 기억 가능
- 컨텍스트 윈도우의 '스마트한 절반'에 머무는 것이 중요하며, 짧은 컨텍스트 데이터에서 훈련이 더 잘 되므로 윈도우가 덜 찬 상태에서 더 나은 결과 도출 — Dex Horthy는 이를 'dumb zone' 밖에 머무르라고 표현
- 에이전트가 관련 파일이나 패키지를 놓치면 예상치 못한 방향으로 진행될 수 있으며, 코드베이스 구조와 아키텍처의 '점진적 공개(progressive disclosure)' 가 도움됨 — OpenAI가 여러 마크다운 파일을 구조화하는 방법에 대한 블로그 포스트를 게시한 바 있음
모델 성능과 속도는 모델 자체의 순수 성능뿐 아니라, 여러 컨텍스트 윈도우 관리 및 서브 에이전트/팀 위임 능력에도 좌우됨

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 포스트를 인용 — 항상 토큰을 최대로 사용하고, 작업자 풀이 24/7 돌아가며, 많은 계획을 세우고 버릴 것을 기대해야 한다는 주장
- 추상화의 정확성 여부와 별개로, 방향적으로는 절대적으로 맞다고 평가
이상적 미래: 노트북이나 클라우드 샌드박스가 백그라운드에서 지속적으로 아이디어를 처리하고, 사용자는 방향을 조정하거나 리서치를 하거나 결과를 리뷰하는 역할
- 코딩 에이전트 작업이 엔지니어링 매니저 역할과 유사하게 느껴지지만, 에이전트의 동기부여나 성격을 신경 쓸 필요 없음
현재 이 미래에 상당히 가까워진 상태 — 트위터에서는 과대광고되지만, 실제로 취침 전 Codex에서 3-4개 작업을 시작해 아침에 리뷰하는 루틴 수행
- 그러나 아직 에이전트를 24/7 실행할 수준은 아님
더 큰 진전을 가로막는 두 가지 장벽:
1. 컨텍스트 윈도우 크기/조율 — 에이전트가 같은 컨텍스트 윈도우에서 끝없이 압축/재활용할 수 없으며, 더 스마트한 하네스나 위임 메커니즘 필요
2. 프롬프트 인젝션 저항성 — 에이전트가 몇 분 만에 승인 요청을 하며, --yolo 모드를 신뢰할 수 없지만 허용 가능한 권한/도메인의 하위 집합이 존재
첫 번째 문제에 대해 Cursor가 다수 컨텍스트 윈도우에 걸친 에이전트 스웜의 한계를 밀어붙이고 있으며, 두 번째는 활발한 연구 영역
- 샌드박스 실행이 현재 최선의 우회책이나 설정이 여전히 번거롭고, 에이전트가 오픈 인터넷 접근과 특권 데이터를 동시에 가지면 Simon Willison이 말한 'Lethal Trifecta' 에 취약
솔로 엔지니어로서 이미 올바른 아이디어가 병목이 되고 있으며, 점점 더 아이디어, 아키텍처, 프로젝트 시퀀싱이 훌륭한 제품을 만드는 데 있어 제약 요인이 될 것