들어가기 앞서서

Peter Steinberger의 블로그 글 “Just Talk To It - the no-bs Way of Agentic Engineering” 한국어 번역입니다. 원문 링크
그는 OpenClaw를 제작하면서 현재 '개발 국룰'로 여겨지는 Claude Code를 사용하지 않고, codex를 사용해 만들었어요. codex뿐만 아니라 AI Agent를 바라보는 시각에 대해서 생각해볼 수 있는 좋은 글이라서 가져왔습니다.

번역 본문

요즘 블로그에 글이 뜸했죠. 최근 프로젝트에 푹 파묻혀 있었거든요. 에이전틱 엔지니어링이 이제 너무 좋아져서, 제 코드를 사실상 거의 100% 다 써줍니다.

그런데도 아직도 너무 많은 사람들이 문제를 해결하려고 하면서, 일을 해치우는 대신 온갖 복잡한 쇼를 벌이더라고요. 이 글은 어젯밤 런던에서 있었던 “Claude Code Anonymous”에서 나눈 대화들에서 일부 영감을 받았고, 마지막 워크플로우 업데이트 이후로 “AI로 꽉 찬 1년”이 지났기도 해서... 한번 점검할 타이밍이라 생각했습니다.

기본 아이디어들은 여전히 똑같아서, 컨텍스트 관리 같은 기초는 다시 얘기하지 않겠습니다. 입문이 필요하면 제 “Optimal AI Workflow” 글을 먼저 보세요.

컨텍스트 & 기술 스택

저는 혼자 일하고 있고, 지금 프로젝트는 대략 30만 LOC 규모의 TypeScript React 앱, 크롬 익스텐션, CLI, Tauri 기반 클라이언트 앱, 그리고 Expo 모바일 앱으로 구성돼 있어요. 배포는 Vercel을 쓰고, PR 하나면 제 웹사이트는 약 2분 내로 새 버전이 떠서 테스트할 수 있습니다. 그 외(앱 등)는 자동화가 아직 안 돼 있어요.

하네스(harness) & 전반적인 접근

저는 완전히 codex CLI로 갈아탔고, 지금은 이게 데일리 드라이버입니다. 3x3 터미널 그리드에서 보통 3~8개를 병렬로 돌려요. 대부분은 같은 폴더에서 굴리고, 실험은 별도 폴더로 뺍니다. worktree나 PR 기반으로도 실험해봤지만, 결국 “가장 빨리 끝내는” 세팅은 늘 이 쪽이라 돌아오게 되더군요.

제 에이전트들은 git의 원자적(atomic) 커밋도 스스로 합니다. 커밋 히스토리를 최대한 깔끔하게 유지하려고 에이전트 파일을 꽤 많이 다듬었고, 그 덕에 git 작업이 더 날카로워져서, 각 에이전트가 자기가 수정한 파일만 정확히 커밋하도록 만들었습니다.

맞아요. Claude라면 Hook 같은 걸로 뭔가 할 수도 있겠지만, codex는 아직 그걸 지원하지 않습니다. 그런데 모델들은 엄청 영리해서, 마음 먹으면 어떤 훅도 못 막습니다.

예전엔 제가 “slop-generator(대충 뽑아내는 사람)” 같은 소리도 들었는데, 병렬 에이전트 돌리는 게 요즘은 슬슬 메인스트림이 되어가는 것 같아 다행이네요.

모델 선택

저는 거의 모든 걸 gpt-5-codex를 “중간(mid) 설정”으로 만들어요. 똑똑함과 속도 사이에서 균형이 좋고, 알아서 생각 강도를 올렸다 내렸다 해줍니다. 설정을 너무 고민해봐야 크게 달라지는 게 없다는 걸 느꼈고, “ultrathink” 같은 걸 신경 안 써도 된다는 점이 좋아요.

블라스트 반경(Blast Radius)

작업할 때 저는 항상 “블라스트 반경”을 생각합니다. 제가 만든 용어는 아니지만, 이 표현이 너무 좋더라고요. 어떤 변경을 떠올리면 “대충 얼마나 걸릴지”, “파일 몇 개를 건드릴지” 감이 옵니다. 코드베이스에 작은 폭탄을 여러 개 던질 수도 있고, ‘팻 맨(Fat Man)’ 같은 큰 거 하나에 작은 거 몇 개를 섞을 수도 있죠.

큰 폭탄을 여러 개 던져버리면 커밋을 분리하기도 어렵고, 뭔가 꼬였을 때 되돌리기도 훨씬 힘들어집니다.

이건 에이전트를 지켜볼 때도 좋은 지표예요. 예상보다 오래 걸린다 싶으면 그냥 ESC 누르고 “지금 상태가 어때?”라고 물어서 상태 업데이트를 받은 다음, 방향을 잡아주거나, 중단하거나, 계속 진행합니다. 중간에 모델을 멈추는 걸 무서워하지 마세요. 파일 변경은 원자적이고, 모델은 멈춘 지점에서 다시 이어서 하는 것도 꽤 잘합니다.

영향 범위가 불확실하면 저는 “변경하기 전에 옵션 몇 개만 먼저 줘”라고 해서 감을 잡습니다.

왜 worktree를 안 쓰냐고?

저는 dev 서버를 하나만 띄워놓고, 프로젝트를 발전시키면서 이것저것 클릭해보며 여러 변경 사항을 한 번에 테스트합니다. 변경마다 트리/브랜치를 따로 두면 이게 훨씬 느려져요. dev 서버를 여러 개 띄우는 것도 금방 짜증납니다. 게다가 Twitter OAuth 콜백 도메인 등록에 제한이 있어서, 등록 가능한 도메인 수가 많지 않기도 하고요.

Claude Code는 어때?

예전엔 Claude Code를 정말 좋아했는데, 요즘은 못 견디겠어요. (codex는 Claude Code를 좋아한다는 말도 있긴 하더라만...) 그 특유의 말투, “Absolutely right” 같은 표현들, 테스트는 깨지는데 “100% 프로덕션 레디”라고 우기는 메시지들... 이제는 진짜 더는 못 하겠습니다.

반면 codex는 약간 “말수 적은 내향형 엔지니어” 같아요. 묵묵히 해치우는 타입. 일을 시작하기 전에 리포 안의 파일을 훨씬 더 많이 읽어줘서, 작은 프롬프트만 던져도 제가 원하는 걸 정확히 하는 경우가 많습니다. 제 타임라인에서도 “codex가 답이다” 쪽으로 분위기가 꽤 형성돼 있어요 — 1, 2.

codex의 다른 장점들

사용 가능한 컨텍스트가 ~230k 정도로 Claude(156k)보다 큽니다. Sonnet 1M도 있긴 하지만, 현실적으로는 그 길이까지 가기 전에 Claude가 이미 좀 “바보같아지는” 경우가 많아서, 실사용에선 크게 의미가 없다고 느껴요.
토큰 사용이 더 효율적입니다. OpenAI가 뭘 다르게 하는지 모르겠지만, 동일한 워크플로우에서 컨텍스트가 훨씬 천천히 차요. Claude를 쓸 때는 “Compacting...”을 진짜 자주 봤는데, codex에선 컨텍스트 초과를 거의 못 봅니다.
메시지 큐잉이 좋아요. codex는 메시지를 큐에 쌓아두는 것을 지원합니다. Claude도 비슷한 기능이 있었는데, 몇 달 전에 바뀌면서 큐에 쌓는 메시지가 모델을 “조향(steer)”해버리더라고요. codex는 조향하고 싶으면 ESC 누르고 새 메시지를 보내면 됩니다. 두 방식 다 선택 가능한 게 훨씬 낫습니다.
속도: OpenAI가 codex를 Rust로 다시 썼다는데, 체감이 확 옵니다. 엄청 빠릅니다. Claude Code는 몇 초씩 멈추거나 프로세스 메모리가 기가 단위로 불어나고, 터미널 깜빡임(특히 Ghostty)도 있는데, codex는 그런 게 거의 없어요. 가볍고 빠릅니다.
말투/언어: 이게 제 정신 건강에 진짜 큰 차이를 만듭니다. Claude한테 소리 지른 적이 너무 많아요. codex에는 화날 일이 거의 없습니다. 심지어 codex가 모델 품질이 조금 더 나빠도 이 이유만으로 쓸 것 같아요. 둘 다 몇 주만 같이 써보면 무슨 말인지 알 겁니다.
랜덤한 마크다운 파일이 여기저기 생기지 않음. (아는 사람은 압니다.)

왜 하네스 도구들을 안 쓰냐고?

제 생각엔 모델 회사와 최종 사용자 사이에 “중간 레이어”가 낄 공간이 별로 없습니다. 구독이 압도적으로 가성비가 좋아요. 저는 OpenAI 구독 4개, Anthropic 구독 1개를 쓰고 있고, 전체 비용이 월 1k 달러 정도인데 사실상 토큰이 거의 무제한입니다. API로 똑같이 하면 비용이 10배는 나올 거예요. (정확한 계산은 아니고 ccusage 같은 툴로 대략적으로 잰 겁니다. 5배만 나와도 여전히 말도 안 되는 딜이죠.)

amp나 Factory 같은 툴이 있는 건 좋지만, 장기적으로 살아남기 어렵다고 봐요. codex와 Claude Code 자체가 매 릴리즈마다 좋아지고, 결국 다 비슷한 아이디어/기능 세트로 수렴할 겁니다. todo 리스트가 조금 더 낫다거나, 조향이 좀 더 편하다거나, DX가 살짝 좋다거나 정도의 “일시적 우위”는 있을 수 있지만, 빅 모델 회사들을 크게 이길 수 있을 것 같진 않아요.

amp는 GPT-5를 드라이버로 쓰던 걸 바꿔서 “oracle”이라고 부르고, 저는 codex에서 사실상 계속 더 똑똑한 모델(oracle)을 쓰는 느낌이고요.
벤치마크는 있긴 한데, 사용량 편향이 너무 심해서 저는 잘 안 믿습니다. 제 경험상 codex가 amp보다 결과가 훨씬 좋았습니다. 다만 세션 공유 같은 건 멋진 아이디어라 굿잡.
Factory는... 아직은 확신이 없어요. 영상이 좀 오글거리긴 한데, 좋다는 이야기도 듣긴 합니다. 다만 이미지 지원도 아직이고 signature flicker도 있고요.
Cursor는(아직 사람이 코드를 직접 쓴다면) 탭 자동완성 모델이 업계 최고 수준이라고 봅니다. 저는 주로 VS Code를 쓰고, Cursor가 브라우저 자동화나 plan mode 같은 걸 밀어붙이는 건 좋아요. GPT-5-Pro도 실험해봤는데, Cursor는 예전부터 절 짜증나게 했던 버그들이 아직도 있더군요. 그래도 개선 중이라 해서 도크에 남겨뒀습니다.
Auggie 같은 애들은 한때 타임라인에 잠깐 떴다가 사라졌어요. 결국 다 GPT-5나 Sonnet을 감싸는 래퍼라 대체 가능하죠. Sonnet에는 RAG가 도움이 됐을 수도 있지만, GPT-5는 코드 검색을 워낙 잘해서 코드베이스에 벡터 인덱스를 따로 둘 필요를 거의 못 느낍니다.

가장 유망한 건 opencode나 crush 같은 것들(오픈 모델과 조합할 때 특히)인데, OpenAI/Anthropic 구독을 꼼수로 붙여 쓰는 방식도 가능하긴 하더라구요. 다만 이게 허용되는지는 애매하고, 애초에 codex/Claude Code에 최적화된 모델을 두고 덜 좋은 하네스를 쓰는 의미가 있나 싶어요.

오픈 모델은?

중국 오픈 모델들을 계속 보고 있는데, 따라오는 속도가 인상적입니다. GLM 4.6, Kimi K2.1 같은 것들이 Sonnet 3.7급 퀄리티에 슬슬 닿고 있어요. 다만 데일리 드라이버로는 비추합니다.

벤치마크는 이야기를 반만 해줘요. 제 느낌엔 에이전틱 엔지니어링이 “이거 쓰레기네”에서 “오, 괜찮은데?”로 넘어간 게 Sonnet 4.0 나온 5월쯤이고, 그 다음 “좋다”에서 “미쳤다”로 점프한 건 gpt-5-codex였어요.

Plan Mode & 접근 방식

벤치마크가 놓치는 건 “프롬프트를 받았을 때 모델+하네스가 어떤 전략으로 움직이느냐”입니다. codex는 훨씬 더 신중하고, 일을 시작하기 전에 리포에서 훨씬 더 많은 파일을 읽습니다. 그리고 내가 멍청한 요청을 하면 더 강하게 푸시백도 해요.

Claude나 다른 에이전트들은 더 성급하게 “일단 뭔가 해보자”로 달려드는 편입니다. plan mode와 엄격한 문서 구조로 어느 정도 완화할 수는 있지만, 제겐 그게 고장난 시스템을 우회하는 느낌이에요.

요즘 저는 codex에선 큰 plan 파일을 거의 안 씁니다. codex는 전용 plan mode도 없는데, 프롬프트를 잘 지키는 능력이 좋아서 그냥 “우리 일단 얘기부터 하자”거나 “옵션 몇 개만 줘”라고 쓰면, 제가 승인하기 전까지 성실히 기다립니다. 하네스 쇼가 필요 없어요. 그냥 말하면 됩니다.

“근데 Claude Code에 Plugins 생겼잖아”

저 멀리서 한숨소리 들리죠? 저입니다.
솔직히 말하면... 큰 의미 없는 땜질 같아요. (원문: Claude Code Plugins) Anthropic이 모델의 비효율을 “플러그인”으로 덮으려는 느낌이었습니다. 물론 특정 작업을 위한 좋은 문서를 유지하는 건 좋은 습관이고, 저도 docs 폴더에 마크다운으로 유용한 문서를 쌓아둡니다.

“근데 근데 Subagents!!!1!”

서브에이전트 춤판에 대해서도 말이 좀 필요해요. 5월에는 이게 “subtasks”라고 불렸고, 모델이 전체 컨텍스트가 필요 없을 때 별도 컨텍스트로 작업을 빼서 병렬화하거나(혹은 시끄러운 빌드 스크립트 같은 걸로 컨텍스트 낭비를 줄이려는) 용도였죠. 나중에 리브랜딩해서 “subagents”가 됐고, 지시사항을 예쁘게 패키징해서 작업을 분리해주는 형태로 발전했습니다.

하지만 본질적 유스케이스는 같아요. 남들이 subagents로 하는 걸 저는 보통 별도 터미널 창/패널로 합니다. 뭔가 리서치가 필요하면 다른 pane에서 하고, 결과를 복사해 다른 pane에 붙여넣죠. 그러면 제가 설계한 컨텍스트를 완전히 통제하고 가시성도 확보할 수 있습니다. subagents는 뭐가 보내지고 돌아오는지 보기/조향/통제하기가 더 어려워요.

그리고 Anthropic이 블로그에서 추천한 “AI Engineer” 서브에이전트 문서도... 솔직히 말해 “슬롭”입니다. 그냥 이거 보세요: “AI Engineer” agent. GPT-4o랑 o1을 통합에 언급하고, 전체적으로 자동생성된 단어 수프 같은 느낌이에요. 그걸 읽고 “이게 내 에이전트를 더 나은 AI 엔지니어로 만들어주겠다”는 확신이 들 만한 내용이 없습니다.

“AI 엔지니어가 대체 뭐냐?”도 그렇고요. 모델에게 “너는 프로덕션급 LLM 앱 전문 AI 엔지니어야” 같은 문장을 붙인다고 출력이 좋아지진 않습니다. 문서, 예시, do/don't 같은 구체물이 훨씬 중요하죠. 차라리 “AI 에이전트 빌드 베스트 프랙티스 구글링해줘”라고 해서 웹사이트 몇 개 읽게 만드는 게 더 낫지 않을까요. 이 정도면 “컨텍스트 독(context poison)”이라고 불러도 될 겁니다.

제가 프롬프트를 쓰는 방식

Claude를 쓸 때는 프롬프트를 (물론... 전 보통 말로 하지만 — I speak) 엄청 길게 쓰곤 했습니다. 컨텍스트를 많이 줄수록 “날 더 잘 이해”한다고 느꼈거든요. 그런데 codex로 오면서 프롬프트가 눈에 띄게 짧아졌습니다. 보통 1~2문장 + 이미지 한 장이면 끝나는 경우도 많아요. 코드베이스를 읽고 “그냥 알아서” 파악하는 능력이 좋습니다. 오히려 제가 다시 타이핑을 더 하게 되기도 해요. 그만큼 적은 컨텍스트로도 충분히 이해하거든요.

이미지(스크린샷)를 넣는 건 컨텍스트를 더하는 엄청난 트릭입니다. 모델이 내가 보여준 걸 정확히 찾아가요. 문자열을 매칭해서 내가 말한 위치로 바로 들어갑니다. 제 프롬프트의 최소 50%는 스크린샷이 들어갑니다. 주석으로 표시하면 더 좋긴 한데 느려서 잘 안 하고, 그냥 드래그해서 터미널에 넣는 건 2초면 됩니다.

Wispr Flow(semantic correction 포함)는 여전히 최고고요.

웹 기반 에이전트들

최근에 웹 에이전트들을 다시 실험했습니다: Devin, Cursor, Codex. 구글의 Jules는 좋아 보이긴 하는데 세팅이 너무 귀찮았고, Gemini 2.5는 이제 좋은 모델이 아니라고 느꼈습니다. Gemini 3 Pro가 나오면 바뀔 수도 있겠죠.

결국 남은 건 codex web 하나였습니다. 이것도 세팅이 귀찮고 망가져 있는 부분이 있어요(터미널 로딩 문제). 그래도 예전 환경 버전을 갖고 있어서 어떻게든 맞춰서 굴렸고, 대신 워밍업 시간이 좀 느려졌습니다.

저는 codex web을 “단기 이슈 트래커”로 씁니다. 밖에 있을 때 아이디어가 떠오르면 iOS 앱으로 한 줄 던져두고, 나중에 맥에서 검토해요. 사실 폰으로 더 많은 걸 할 수도 있고, 리뷰/머지까지도 가능하겠지만 일부러 안 합니다. 일이 이미 충분히 중독적이라, 친구 만나거나 밖에 나가 있을 때까지 더 끌려 들어가고 싶지 않거든요. (제가 폰에서 코딩하기 쉽게 만들려고 두 달 가까이 도구를 만든 사람이라는 걸 생각하면 웃기죠.)

codex web이 예전엔 사용량 제한에 포함되지 않았는데, 요즘은 그 시절도 끝이 보이더군요.

에이전틱 여정

도구 이야기를 해봅시다. Conductor, Terragon, Sculptor... 그리고 수천 개의 다른 것들. 취미 프로젝트도 있고 VC 돈에 잠긴 것도 있고요. 저는 진짜 많이 써봤는데, 남는 게 없었습니다. 제 관점에서 그 도구들은 “현재의 비효율”을 우회하는 워크플로우를 강요하고, 그 워크플로우가 최적이라고도 생각하지 않아요. 게다가 대부분 터미널을 숨기고, 모델이 보여주는 모든 걸 그대로 보여주지 않습니다.

대부분은 Anthropic SDK + worktree 관리 래퍼에 가까워요. 해자가 없습니다. 그리고 폰에서 코딩 에이전트를 더 쉽게 접근하게 하는 게 정말 필요한지 자체도 의문입니다. 제가 필요했던 “아주 작은” 모바일 유스케이스는 codex web이 다 커버해요.

대신 이런 패턴은 보입니다. 거의 모든 엔지니어가 한 번쯤은 “내 도구 만들기” 페이즈를 지나가요. 재미있고, 지금은 너무 쉽게 만들 수 있으니까요. 그리고 또 뭘 만들겠어요? (우리가 생각하기엔) 더 많은 도구를 만들기 쉽게 해주는 도구를 만들겠죠.

“근데 Claude Code는 백그라운드 태스크가 되잖아!”

맞습니다. codex는 Claude가 가진 몇 가지 “종소리/휘슬(편의 기능)”이 아직 없어요. 그중 가장 뼈아픈 건 백그라운드 태스크 관리입니다. 타임아웃이 있어야 할 것 같은데, dev 서버 띄우기처럼 끝나지 않는 CLI 작업이나 테스트 데드락 같은 데서 꽤 자주 걸리는 걸 봤습니다.

이게 예전에 제가 Claude로 돌아갔던 이유 중 하나였는데, Claude가 다른 면에서 너무 “바보 같은” 부분이 있어서... 지금은 그냥 tmux를 씁니다. tmux는 오래된 도구지만 백그라운드로 CLI를 지속 세션에서 돌리기 좋고, 모델에게 “tmux로 실행해”라고 말하면 이미 지식이 충분해서 잘 알아듣습니다. 별도의 에이전트 문서 쇼가 필요 없어요.

MCP는 어때?

MCP는 다른 사람들이 이미 많이 썼죠. 제 생각엔 대부분 “마케팅 체크박스”용입니다. 거의 모든 MCP는 사실 그냥 CLI여야 해요. (저도 MCP 5개나 만든 사람으로서 하는 말입니다.)

저는 그냥 CLI 이름만 언급하면 됩니다. 에이전트 파일에 설명을 덕지덕지 붙일 필요가 없어요. 에이전트가 처음엔 이상한 커맨드를 치더라도 CLI가 help 메뉴를 보여주면, 그 순간 컨텍스트에 “이 CLI가 어떻게 쓰이는지” 정보가 들어오고, 그 다음부터는 잘 굴러갑니다.

반면 MCP는 도구 자체가 컨텍스트에 상시 비용(컨텍스트 세금)을 올립니다. GitHub MCP를 쓰면 2.3만 토큰이 그냥 날아가요. (처음 나왔을 때는 거의 5만 토큰이었는데 그나마 나아진 거죠.)

차라리 gh CLI를 쓰세요. 기능은 비슷하고, 모델은 이미 사용법을 알고 있고, 컨텍스트 세금이 0입니다.

저는 bslog, inngest 같은 CLI 툴도 오픈소스로 공개했고요. 요즘은 web 디버깅에서 Playwright 대신 chrome-devtools-mcp를 “클로즈 더 루프(닫힌 고리 만들기)” 용도로 씁니다. 자주 필요하진 않지만, 필요할 땐 유용해요. 그리고 제 웹사이트는 모델이 curl로 어떤 엔드포인트든 조회할 수 있는 API 키를 만들 수 있게 설계해뒀습니다. 대부분의 경우 이게 더 빠르고 토큰 효율도 좋아서, 그 MCP조차 매일 쓰는 건 아닙니다.

“근데 코드가 슬롭 아니냐?”

저는 시간의 20% 정도를 리팩토링에 씁니다. 물론 그것도 전부 에이전트가 합니다. 제가 손으로 리팩토링 하느라 시간을 버리진 않아요.

리팩토링 데이는 집중이 덜 필요하거나 피곤할 때 특히 좋습니다. 머리가 맑지 않아도 큰 진전을 만들 수 있거든요.

제가 리팩토링 때 주로 하는 일은 이런 겁니다:

jscpd로 중복 코드 찾기
knip으로 죽은 코드(dead code) 정리
eslint의 react-compiler 및 deprecation 플러그인 돌리기
API 라우트가 쓸데없이 늘어나서 합칠 수 있는지 점검
문서 유지보수
커져버린 파일 쪼개기
까다로운 부분에 테스트/주석 추가
의존성 업데이트
툴 업그레이드
파일 구조 재정리
느린 테스트 찾아서 개선
최신 React 패턴 반영해서 코드 리라이트(예: “you might not need useEffect”)

할 일은 항상 있습니다. 커밋마다 이걸 다 하자고 주장할 수도 있겠지만, 저는 “빠르게 기능을 만들고 → 유지보수/개선으로 기술부채를 갚는” 페이즈를 번갈아 가는 게 훨씬 생산적이고, 솔직히 더 재밌더라고요.

스펙 기반 개발(spec-driven development) 하냐고?

6월엔 저도 했어요 — 그때 글. 큰 스펙을 설계해두고, 모델에게 몇 시간씩 쭉 빌드하게 두는 방식. 저는 그건 “옛날 사고방식”이라고 봅니다.

요즘 제 방식은 보통 이렇습니다. codex랑 먼저 대화를 시작하고, 웹사이트/아이디어를 좀 붙이고, 코드 읽어보라고 하고, 같이 새 기능을 다듬어요. 까다로운 건 스펙 문서로 정리하게 한 다음, 그걸 GPT-5-Pro(chatgpt.com)에 리뷰로 던져서 더 좋은 아이디어가 있는지 봅니다. (놀랍게도 이게 계획을 확 좋아지게 하는 경우가 꽤 자주 있어요.) 그리고 쓸만한 걸 골라서 다시 메인 컨텍스트에 가져와 문서를 업데이트하죠.

이젠 “어떤 작업이 컨텍스트를 얼마나 먹는지” 감이 있고, codex의 컨텍스트도 넉넉해서 많은 경우 그냥 바로 빌드 들어갑니다. 어떤 사람들은 계획을 짜면 반드시 새 컨텍스트로 시작하는데, Sonnet에는 그게 유효했을지 몰라도 GPT-5는 큰 컨텍스트를 훨씬 잘 다루고, 새 컨텍스트로 시작하면 필요한 파일을 다시 천천히 긁어오느라 모든 게 10분씩 느려지기 쉽습니다.

UI 작업은 더 재밌어요. 저는 일부러 아주 간단하게 시작해서 요구사항을 심하게 덜-spec 해두고, 모델이 만들면서 브라우저가 실시간으로 바뀌는 걸 봅니다. 그 다음 추가 변경을 큐에 넣고 계속 형태를 다듬어요. 종종 “어떤 모습이어야 하는지” 저도 확신이 없는데, 이런 식으로 아이디어를 가지고 놀면서 서서히 생명력을 불어넣는 게 좋습니다. codex가 제가 생각 못 했던 재미있는 걸 만들어낸 적도 많고요.

저는 리셋하지 않습니다. 그냥 계속 반복해서 혼돈을 원하는 형태로 “변형(morph)”시켜요. 관련 인터랙션 아이디어가 떠오르면 다른 에이전트에서 또 다른 부분을 동시에 다듬기도 합니다. 보통은 큰 메인 기능 하나 + 작은 주변 작업 몇 개 조합으로 갑니다.

지금 이 글을 쓰는 동안엔 크롬 익스텐션에서 트위터 데이터 임포터를 새로 만들고 있는데, 그 과정에서 GraphQL 임포터도 갈아엎고 있어요. 접근이 맞는지 조금 애매해서, 그건 별도 폴더에 두고 PR로 보면서 판단하려고 합니다. 메인 리포는 리팩토링이 돌아가고 있고요. 저는 그 사이 글을 쓰는 거죠.

슬래시 커맨드 보여달라면

몇 개만 있고, 자주 쓰진 않습니다.

/commit: 같은 폴더에서 여러 에이전트가 돌고 있다는 설명 + “네가 건드린 것만 커밋해”를 강제해서 커밋을 깨끗하게 만들기(다른 변경 때문에 GPT가 패닉/되돌리기 같은 걸 안 하도록)
/automerge: PR을 하나씩 처리(봇 코멘트 반영, 답변, CI 통과시키고, green이면 squash)
/massageprs: automerge와 비슷하지만 squash 없이(PR이 많을 때 병렬화용)
/review: 내장 커맨드(가끔. GH에 리뷰 봇이 있긴 하지만 유용할 때가 있음)

그리고 사실 이런 커맨드가 있어도 보통은 그냥 “commit”이라고 타이핑합니다. 너무 많은 더티 파일이 있어서 에이전트가 실수할까 걱정될 때만 더 안내를 줘요. 확신이 있으면 쇼/컨텍스트 낭비할 필요 없습니다. 이런 감은 하다 보면 생깁니다. 솔직히 이 외에 “진짜로 쓸모 있는” 커맨드는 아직 못 봤어요.

그 밖의 팁

길게 돌아가는 작업에서 모델이 끝까지 달리게 하려고 “완벽한 프롬프트”를 짜는 대신, 대충(하지만 효과적인) 우회로가 있습니다.

큰 리팩토링을 하면 codex가 중간에 답을 뱉고 멈추는 경우가 있어요. 그럴 땐 continue 메시지를 큐에 쌓아두기가 꽤 먹힙니다. codex가 이미 끝난 상태에서 메시지가 더 오면 그냥 기분 좋게 무시하기도 하고요.

그리고 기능/버그 픽스가 끝날 때마다 테스트를 작성하라고 시키세요. 같은 컨텍스트에서요. 그러면 테스트 품질이 훨씬 좋아지고, 구현에 숨어 있던 버그가 드러나는 경우도 많습니다. UI 자잘한 tweak이라면 테스트가 애매할 수 있지만, 그 외엔 하세요. AI는 좋은 테스트를 잘 못 적는 편이긴 해도, 그래도 도움이 됩니다. 솔직히 우리... 모든 수정마다 테스트 적나요?

또 모델에게 “의도를 보존해줘”, “까다로운 부분엔 코드 주석 달아줘”라고 하면, 나중의 나와 미래의 모델 런 둘 다에게 도움이 됩니다.

막히는 문제가 나오면 “take your time”, “comprehensive”, “관련 있을 수 있는 코드를 전부 읽어”, “가능한 가설들을 만들어” 같은 트리거 문구를 섞어보세요. codex가 진짜 어려운 문제도 풀어내는 경우가 많습니다.

Agents/Claude 파일은 어떻게 생겼냐고?

저는 Agents.md를 두고, Anthropic이 표준화를 안 해서 claude.md로 심볼릭 링크를 걸어놨습니다. 이게 어렵고 비최적이라는 건 인정해요. GPT-5는 Claude와 꽤 다른 프롬프팅을 선호하거든요. 아직 GPT-5 prompting guide를 안 봤다면, 여기서 멈추고 읽어보세요.

Claude는 대문자로 소리 지르는 명령(‘이거 안 하면 세상이 멸망하고 100마리 고양이가 죽는다’ 급의 협박 포함)에 잘 반응하는 편인데, GPT-5는 그런 걸 보면 오히려 놀랍니다. (당연히 그래야죠.) 그러니까 그런 거 다 버리고, 사람처럼 말하세요. 그럼 이 파일들은 모델 간에 최적으로 공유되기도 어려워집니다.

하지만 저는 대부분 codex를 쓰니까 상관없습니다. 아주 가끔 Claude가 “놀러오는” 경우엔 지시가 약할 수도 있는 걸 감수하죠.

제 Agent 파일은 지금 약 800줄 정도고, 조직적 흉터(scar tissue) 같은 느낌입니다. 이건 제가 쓴 게 아니라 codex가 썼고, 뭔가 사건이 생길 때마다 “간단히 메모로 추가해줘”라고 시킵니다. 언젠가 정리해야겠지만, 커도 꽤 잘 돌아가고, GPT는 이걸 Claude보다 훨씬 더 잘 지켜요. (Sonnet 4.5는 이 부분이 좀 나아졌다고 하긴 합니다.)

git 지침 외에도, 제품 설명, 선호 네이밍/API 패턴, React Compiler 메모 등이 들어 있습니다. 제 스택이 워낙 최신이라 “세상 지식”에 없는 내용이 자주 생기거든요. 모델이 업데이트되면 그만큼 이 파일도 다시 줄일 수 있을 거라고 봅니다.

예를 들어 Sonnet 4.0은 Tailwind 4를 이해시키려면 가이드가 필요했는데, Sonnet 4.5나 GPT-5는 이미 그걸 아니까 그 “군더더기”를 삭제할 수 있었어요. 큰 덩어리는 선호 React 패턴, DB 마이그레이션 관리, 테스팅, ast-grep 룰 사용/작성 같은 것들입니다.

(만약 ast-grep을 모르거나 코드베이스 린터로 안 쓰고 있다면, 여기서 멈추고 모델에게 “git hook으로 설정해서 커밋을 막아줘”라고 시켜보세요.)

그리고 “텍스트 기반 디자인 시스템”(화면이 어떻게 보여야 하는지에 대한 텍스트 규칙 모음)도 실험 중인데, 이건 아직 결론이 안 났습니다.

그럼 GPT-5-Codex가 완벽하냐?

절대 아니죠.

가끔 30분씩 리팩토링하다가 갑자기 패닉해서 전부 되돌려버리기도 하고, 그럴 땐 다시 돌리면서 “시간 충분하니까 괜찮아”라고 애를 달래듯 진정시켜야 합니다. 가끔은 bash 명령을 쓸 수 있다는 걸 잊어버려서 “명령 써도 돼”라고 부추겨야 하고요. 가끔 러시아어/한국어로 답하기도 합니다. 가끔은 ‘괴물’이 튀어나와 raw thinking을 bash에 보내기도 하고요.

그래도 이런 건 드물고, 다른 거의 모든 면에서 미친 듯이 좋아서 저는 이 결함들을 감수합니다. 인간도 완벽하지 않잖아요.

제가 codex에서 제일 짜증나는 건 스크롤을 빨리 올리면 텍스트 일부가 “사라지는” 현상입니다. 이게 OpenAI 버그 리스트 최상단에 있길 바라고, 이 때문에 제가 메시지가 안 날아가게 속도를 늦춰야 하는 경우가 생겨요.

결론

RAG, subagents, Agents 2.0 같은 “대부분 쇼에 가까운 것들”에 시간 낭비하지 마세요. 그냥 말하세요. 가지고 놀아보세요. 감을 키우세요. 에이전트와 많이 일할수록 결과는 좋아집니다.

Simon Willison의 글이 아주 좋은 포인트를 짚는데, 에이전트를 관리하는 데 필요한 많은 스킬은 결국 엔지니어를 관리할 때 필요한 스킬과 비슷합니다. 그리고 그건 대부분 시니어 엔지니어의 특성이죠.

그리고 네, 좋은 소프트웨어 만드는 건 여전히 어렵습니다. 제가 이제 코드를 직접 안 쓴다고 해서, 아키텍처/시스템 디자인/의존성/기능/사용자에게 기쁨을 주는 방법을 덜 고민한다는 뜻은 아닙니다. AI를 쓰면 그냥 “출시해야 하는 기대치”가 올라갈 뿐이에요.

PS: 이 글은 100% 자연산(organic)이고 손으로 직접 썼습니다. AI를 사랑하지만, 어떤 건 여전히 구식 방식이 더 낫다는 것도 압니다. 오타도, 제 말투도 그대로 두세요. ✌️
PPS: 헤더 그래픽 크레딧은 Thorsten Ball에게 있습니다.

역자의 말

해당 글은 2026년 3월 3일 시점으로 약 4개월 전에 작성된 글이라, 기술적 변화가 있었는지 추가로 확인해봤습니다.

"Claude Code는 백그라운드 태스크가 되는데 codex는 없다" -> 이건 Codex app에서 Automations(스케줄 기반 백그라운드 작업) 기능을 발표하면서 일부 해소되고 있어요.
컨텍스트 길이는 GPT-5.3-Codex 기준 윈도우 크기는 400k, Opus 4.6은 1M로 명시합니다. 따라서 크기는 Claude가 우세하지만, 저자의 말처럼 1M 컨텍스트가 실질적인 생산성으로 이어지는지에는 여전히 의문이 남아 있습니다.