#Codex
18개의 포스트
에이전트 여럿, 저장소 하나 부록 — 도구 지도 2026: 언제 무엇을 쓰나
git worktree 위에는 CLI·에이전트 앱 내장 기능·관제 앱이 층층이 올라가 있고, 옆에는 GitButler·Jujutsu처럼 방식이 다른 도구와 Forgejo 같은 자체 호스팅이 있습니다. 2026년 9월 기준으로 공식 저장소와 문서에서 확인한 사실만으로 각 도구가 무엇이고 worktree와 어떤 관계인지, 언제 쓰고 언제 피할지를 정리하고, 결정 흐름도와 비교표로 '우리 팀은 무엇부터 깔까'에 답합니다.
에이전트 여럿, 저장소 하나 5편 — 두 에이전트에게 같은 일 시키고 좋은 것만 합치기
같은 기능을 Claude Code와 Codex에게 각자의 worktree·브랜치에서 동시에 맡기고, git log·diff A...B·range-diff·같은 테스트로 두 결과를 비교한 뒤 좋은 부분만 골라 합치는 법을 실제 출력으로 따라갑니다. 통째로 채택(squash), 커밋만 가져오기(cherry-pick -x), 파일 하나 가져오기(restore --source), 세 번째 에이전트에게 합치기를 맡기는 법과 뒷정리, 그리고 이 방법이 오히려 손해인 경우까지 다룹니다.
에이전트 여럿, 저장소 하나 6편 — 에이전트가 길을 잃지 않는 저장소
에이전트는 매번 기억 없이 새로 시작하고, Mac은 저마다 설치된 버전이 다릅니다. 규칙은 AGENTS.md와 CLAUDE.md(@AGENTS.md)에, 도구 버전과 명령은 mise.toml에, 비밀은 .env.example 견본에, 큰 파일은 LFS·S3에, 안전장치는 pre-commit 훅·CI·main 보호에 담아 저장소 자체가 규칙과 환경을 들고 다니게 만드는 법을 실제 실행 결과와 함께 정리합니다. 마지막엔 새 Mac에서 다섯 줄로 똑같은 환경을 되살립니다.
에이전트 여럿, 저장소 하나 3편 — 에이전트에 worktree 맡기기: Claude Code·Codex·Worktrunk
2편에서 손으로 만들던 worktree를 이제 도구에게 맡깁니다. Claude Code의 --worktree·.worktreeinclude·worktree.baseRef·격리 강제·정리 규칙·서브에이전트 isolation, Codex 앱과 CLI가 worktree를 다루는 방식의 차이, 그리고 Worktrunk(wt)로 만들기부터 병합·정리까지 한 바퀴를 실제 출력으로 따라갑니다.
에이전트 여럿, 저장소 하나 4편 — Mac을 바꿔 가며 이어서 작업하기
맥북에서 하던 일을 맥 스튜디오에서 이어 가는 방법을 Git만으로 정리합니다. 퇴근 전 WIP 커밋과 push, 출근 후 fetch와 switch, stash가 다른 Mac으로 건너가지 못하는 이유, 두 Mac이 같은 브랜치를 만졌을 때의 pull --rebase와 --force-with-lease, 다른 Mac에 두고 온 커밋 찾기, 그리고 Mac마다 한 번씩 해 둘 인증·includeIf 설정까지 git 2.55 실제 출력으로 따라갑니다.
에이전트 여럿, 저장소 하나 1편 — 폴더를 동기화하지 말고 Git으로 주고받기
Claude Code와 Codex를 동시에 여러 개 돌리고, 맥북과 사무실 Mac을 오가며 같은 프로젝트를 만지기 시작하면 가장 먼저 떠오르는 방법이 '저장소 폴더를 동기화하자'입니다. 이 글은 그 방법이 왜 조용히 작업을 잃게 만드는지 직접 재현한 실험으로 보여 주고, 원격 하나 → Mac마다 clone → 작업마다 worktree로 이어지는 전체 설계도와 세 원칙, 그리고 소스·비밀·대용량 파일·빌드 산출물을 각각 어디에 둘지 정리합니다.
에이전트 여럿, 저장소 하나 2편 — git worktree 완전 정복
저장소 하나에서 작업 폴더를 여러 개 꺼내 쓰는 git worktree를 처음부터 끝까지 다룹니다. add·list·remove·prune·lock·move를 git 2.55 실제 출력으로 따라가고, 커밋·브랜치·stash·설정은 공유되지만 파일·스테이징·HEAD는 폴더마다 따로라는 사실을 명령으로 하나씩 증명합니다. 같은 브랜치를 두 곳에서 꺼낼 수 없는 이유, worktree마다 node_modules·포트·.env를 따로 챙겨야 하는 함정, switch·stash·clone과의 비교까지 정리합니다.
![[특집] 플랜 모드는 죽었다 — AI 코딩에서 '계획서'는 사라지고 '이해'의 문제만 남았다](/_next/image?url=https%3A%2F%2Ffiles.core.today%2Fstorage%2Fcoredot%2Fpublic%2Fblog%2Fpm-cover.webp&w=3840&q=75)
[특집] 플랜 모드는 죽었다 — AI 코딩에서 '계획서'는 사라지고 '이해'의 문제만 남았다
2026년 9월 24일, 전 GitHub 엔지니어 아이먼 나딤이 「플랜 모드는 죽었다」라는 글을 올렸습니다. '계획'을 제품의 중심에 둔 코딩 앱을 직접 만들었다가 실패한 사람의 고백입니다. 이틀 만에 해커뉴스 553점, 댓글 477개가 달렸고, 맨 위 댓글은 Claude Code를 만든 보리스 체르니의 "대체로 동의합니다"였습니다. 이 특집은 그 글을 뼈대로, 1970년 로이스의 '폭포수' 논문이 사실은 폭포수를 경고했다는 이야기부터 브룩스의 '하나는 버려라', 켄트 벡의 변경 비용 곡선, 나우르의 '프로그래밍은 이론 쌓기', 쇤의 '재료와의 대화'를 거쳐 2025년 플랜 모드와 스펙 주도 개발 붐까지 따라갑니다. 나딤이 꼽은 네 가지 오판(계획하기와 계획서를 혼동했다, 모델이 너무 좋아졌다, 아무도 AI가 쓴 글을 읽고 싶어 하지 않는다, 계획과 구현을 떼어 놓았다)을 사례로 풀고, 에이전트가 수백 개로 늘어나는 2026년에 사람의 '이해'를 어떻게 지킬지까지 인터랙티브 6개와 웹툰 12장으로 함께 읽어 보세요.
같은 모델인데 성적이 10배 차이 — 코딩 에이전트 하니스 해부 (Zoom·UMass 176개 실험 완전 정리)
Nemotron-3 550B가 32k 창에서 SWE-Bench Verified 6.4%를 받았다. 모델을 한 글자도 바꾸지 않고 하니스의 맥락 관리만 켜자 58.4%가 됐다. 같은 bash 단독 인터페이스가 550B에게는 +3.6pp에 비용 절반, Mistral에게는 −24pp였다. 2026년 9월 17일 공개된 Zoom·UMass·Emory 연구진의 논문은 코딩 하니스를 계획·행동 공간·맥락 관리 세 부품으로 분해해 4개 모델 × 2개 벤치마크 × 176개 설정에서 부품 하나씩의 효과를 쟀다. 결론은 ‘좋은 하니스’가 아니라 ‘모델·예산·과제에 따라 갈리는 하니스’다. ReAct에서 하니스 엔지니어링까지의 역사, 논문의 네 가지 발견, 그것이 Claude Code·Codex의 오늘과 어떻게 맞물리는지를 인터랙티브 위젯 6종과 삽화로 풀었다.
루프 엔지니어링 — 더 이상 에이전트에게 프롬프트하지 마라
Addy Osmani의 글 한 편이 개발자 타임라인을 뒤흔들었습니다. '에이전트에게 프롬프트하지 마라. 에이전트를 프롬프트하는 시스템을 설계하라.' 프롬프트→컨텍스트→하니스→루프로 이어진 추상화의 사다리, ReAct·Reflexion부터 2026년 /goal까지의 역사, 루프를 이루는 5가지 빌딩블록과 비용·위험을 논문과 사례로 쉽고 자세하게 풀어드립니다.
Computer Use와 자동화 — 코드 자동완성에서 디지털 동료로 (Codex Use Cases 특집 6·완결)
Codex가 책상에 앉았다. Cua Driver가 만든 멀티 커서 백그라운드, 받은 편지함 정리, /goal로 지속되는 장기 목표, Verified Operations, Skills로 절차 영구화까지 — Codex Use Cases 특집 시리즈를 닫는 마지막 편. 코드 자동완성이 어떻게 디지털 동료가 됐는지의 완결.
iOS·macOS 네이티브 개발을 위한 Codex — 시뮬레이터에서 직접 만져보는 AI (Codex Use Cases 특집 4)
네이티브 앱은 빌드해서 시뮬레이터에 띄워 직접 만져봐야 한다. Codex가 XcodeBuildMCP 검증 루프로 '픽셀보다 텍스트 먼저' 원칙 아래 iOS 앱 제작·시뮬레이터 디버깅·Liquid Glass 마이그레이션·App Intents·Mac 셸·Logger 텔레메트리를 어떻게 해내는지 실제 사례로 풀어봅니다. Codex Use Cases 특집 4편.