그냥 대화하세요 - 에이전틱 엔지니어링의 노BS 방식

게시일: 2025년 10월 23일 | 원문 작성일: 2025년 10월 14일 | 원저자: Peter Steinberger | 원문 보기

현재 워크플로우와 기술 스택

혼자 작업 중이에요. 프로젝트는 약 30만 줄 규모의 TypeScript React 앱, Chrome 확장 프로그램, CLI, Tauri 클라이언트 앱, 그리고 Expo 모바일 앱이죠. Vercel에 호스팅하고 있어서 PR 하나면 2분 만에 새 버전을 테스트할 수 있어요.

codex cli를 메인으로

요즘은 완전히 codex cli로 넘어왔어요. 3x3 터미널 그리드에서 동시에 3-8개를 돌리는데, 대부분 같은 폴더에서 작업해요. worktrees나 PR 실험도 해봤지만, 항상 이 설정으로 돌아오게 되더라고요. 가장 빠르게 일을 끝낼 수 있거든요.

에이전트들이 스스로 git atomic commit을 해요. 깔끔한 커밋 히스토리를 유지하려고 에이전트 파일을 많이 다듬었죠. 덕분에 git 작업이 더 날카로워져서 각 에이전트가 정확히 자기가 수정한 파일만 커밋해요.

모델 선택: GPT-5-codex

거의 모든 걸 gpt-5-codex의 mid 세팅으로 만들어요. 똑똑함과 속도의 좋은 균형이고, thinking을 자동으로 올리고 내리죠. 설정 고민하는 게 별 의미 없더라고요. ultrathink에 대해 생각 안 해도 되니까 좋아요.

Blast Radius 개념 💥

작업할 때마다 “blast radius”를 생각해요. 이 용어는 제가 만든 건 아니지만, 진짜 좋아해요. 변경 사항을 생각하면 얼마나 걸릴지, 몇 개 파일을 건드릴지 대충 감이 와요. 코드베이스에 작은 폭탄 여러 개를 던질 수도 있고, “Fat Man” 하나랑 작은 거 몇 개를 던질 수도 있죠. 큰 폭탄 여러 개를 던지면 isolated commit이 불가능해지고, 뭔가 잘못됐을 때 리셋하기도 훨씬 어려워져요.

에이전트를 지켜볼 때도 좋은 지표예요. 예상보다 오래 걸리면 그냥 escape 누르고 “what’s the status”라고 물어봐서 상태 업데이트를 받아요. 그 다음에는 모델이 올바른 방향을 찾도록 돕거나, abort하거나, 계속하거나. 모델을 중간에 멈추는 거 겁낼 필요 없어요. 파일 변경은 atomic이고, 멈춘 지점부터 다시 시작하는 걸 정말 잘하거든요.

영향이 확실하지 않으면 “give me a few options before making changes”라고 해서 가늠해봐요.

왜 codex인가? Claude Code와의 비교

예전엔 Claude Code를 사랑했는데, 요즘엔 못 참겠어요. 그 언어랑, “absolutely right”라는 말들, 테스트가 실패하는데 “100% production ready”라는 메시지들 - 더 이상은 무리예요. codex는 내향적인 엔지니어 같아요. 묵묵히 일을 해내죠. 작업 시작 전에 훨씬 더 많은 파일을 읽어서, 짧은 프롬프트로도 보통 정확히 제가 원하는 걸 해요.

codex의 다른 장점들

속도 얘기를 더 해볼까요. OpenAI가 codex를 Rust로 다시 썼는데, 그게 느껴져요. 엄청 빠르거든요. Claude Code 쓸 땐 자주 멀티세컨드 프리징이 있었고 프로세스가 기가바이트 단위로 메모리를 먹었어요. 거기다 터미널 깜빡임까지, 특히 Ghostty 쓸 때요. codex는 그런 거 전혀 없어요. 엄청 가볍고 빠르게 느껴져요.

그리고 언어요. 이게 제 정신 건강에 진짜 큰 차이를 만들어요. claude한테 소리 지른 적이 몇 번인지 몰라요. codex한테는 거의 안 화나요. codex가 더 나쁜 모델이라도 그것만으로도 쓸 거예요. 둘 다 몇 주 써보면 이해하게 될 거예요.

왜 다른 하네스(harness)는 안 쓰나요?

제 생각엔 엔드유저와 모델 회사 사이에는 그다지 공간이 없어요. 구독으로 훨씬 좋은 딜을 받거든요. 현재 OpenAI 구독 4개랑 Anthropic 구독 1개가 있어서, 전체 비용이 월 1천 달러 정도로 기본적으로 무제한 토큰이죠. API 콜을 쓰면 10배는 더 들 거예요.

amp나 Factory는요?

amp는 GPT-5를 드라이버에서 치웠고 이제 “oracle”이라고 부르네요. 한편 저는 codex를 쓰면서 기본적으로 계속 더 똑똑한 모델, 즉 oracle과 작업해요. 벤치마크가 있긴 하지만, 편향된 사용 수치를 보면 신뢰가 안 가요. codex가 amp보다 훨씬 좋은 결과를 줘요.

Factory는 확신이 안 서요. 마케팅 비디오가 너무 cringe하고, DM으로 무료 토큰 줘서 관심 끌려는 회사는 제 존경심을 떨어뜨려요. 그렇게 좋으면 무료 걸로 설득할 필요가 없잖아요.

오픈 모델은요?

중국의 오픈 모델들을 계속 주시하고 있어요. GLM 4.6이랑 Kimi K2.1이 강력한 경쟁자로 천천히 Sonnet 3.7 퀄리티에 도달하고 있지만, 일일 드라이버로는 추천 안 해요.

벤치마크는 절반만 말해줘요. 제 생각엔 에이전틱 엔지니어링이 5월쯤 Sonnet 4.0 릴리스와 함께 “이거 쓰레기”에서 “이거 괜찮네”로 넘어갔고, gpt-5-codex로 “이거 대박”으로 훨씬 더 큰 도약을 했어요.

Plan 모드와 접근법

벤치마크가 놓치는 건 모델+하네스가 프롬프트를 받았을 때 추구하는 전략이에요. codex는 훨씬훨씬 더 조심스럽고 결정하기 전에 레포에서 훨씬 더 많은 파일을 읽어요. 어리석은 요청을 하면 더 강하게 밀어내죠. Claude나 다른 에이전트들은 훨씬 더 적극적이고 그냥 뭔가를 시도해요.

요즘은 codex랑 큰 plan 파일을 거의 안 써요. codex는 전용 plan 모드도 없어요 - 하지만 프롬프트를 따르는 게 훨씬 나아서 그냥 “let’s discuss”나 “give me options”라고 쓰면 제가 승인할 때까지 부지런히 기다려요. 하네스 연극 같은 거 필요 없어요. 그냥 대화하면 돼요.

Claude Code의 플러그인은요?

저 멀리서 들리는 소리 들려요? 제가 한숨 쉬는 소리예요. 엄청난 BS 더미네요. 이건 정말 Anthropic의 초점에 실망했어요. 모델의 비효율성을 패치하려고 하는 거죠. 특정 작업을 위한 좋은 문서를 유지하는 건 좋은 아이디어예요. 저도 docs 폴더에 유용한 문서 큰 목록을 마크다운으로 보관하거든요.

그리고 Subagents!!!

subagents랑 이 모든 댄스에 대해 말해야겠네요. 5월에는 이게 subtasks라고 불렸고, 주로 모델이 전체 텍스트가 필요 없을 때 작업을 별도 컨텍스트로 분리하는 방법이었어요 - 주로 병렬화하거나 시끄러운 빌드 스크립트 같은 걸 위해 컨텍스트 낭비를 줄이는 거였죠.

사용 케이스는 똑같아요. 다른 사람들이 subagents로 하는 걸, 저는 보통 별도 윈도우로 해요. 뭔가 리서치하고 싶으면 별도 터미널 패널에서 하고 다른 데 붙여넣어요. 이게 제가 엔지니어링하는 컨텍스트에 대한 완전한 제어와 가시성을 줘요. subagents는 뭐가 전송되는지 보고 조종하거나 제어하기 더 어렵게 만들죠.

프롬프트 작성 방법

claude 쓸 때는 아주 광범위한 프롬프트를 작성(물론 아니고, 말로 해요)했어요. 제가 더 많은 컨텍스트를 주면 이 모델이 “저를 이해”하거든요. 어떤 모델이든 사실이긴 하지만, codex로 넘어오면서 프롬프트가 훨씬 짧아진 걸 알았어요. 종종 그냥 1-2 문장 + 이미지예요. 모델이 코드베이스를 읽는 걸 엄청 잘해서 그냥 저를 이해해요. 가끔은 타이핑으로 돌아가기도 해요. codex가 이해하는 데 훨씬 적은 컨텍스트가 필요하거든요.

이미지 추가는 더 많은 컨텍스트를 제공하는 놀라운 트릭이에요. 모델이 제가 보여주는 걸 정확히 찾는 걸 정말 잘해요. 문자열을 찾고 매치해서 제가 언급한 위치에 바로 도착하죠. 제 프롬프트의 최소 50%는 스크린샷을 포함해요. 주석은 거의 안 달아요. 그게 더 잘 되긴 하지만 느려요. 스크린샷은 터미널에 드래그하는 데 2초면 돼요.

웹 기반 에이전트들

최근에 웹 에이전트들을 다시 실험했어요: Devin, Cursor, Codex. Google의 Jules는 괜찮아 보이지만 설정이 정말 짜증났고 Gemini 2.5는 그냥 좋은 모델이 아니에요. codex web만 남았네요. 설정이 귀찮고 깨져있긴 한데, 터미널이 현재 제대로 로드가 안 돼요. 하지만 제 환경의 오래된 버전이 있어서 작동하게 만들었어요. 대신 시작 시간이 느려졌지만요.

codex web을 단기 이슈 트래커로 써요. 이동 중에 아이디어가 생기면 iOS 앱으로 한 줄 쓰고 나중에 Mac에서 리뷰해요. 폰으로 훨씬 더 많이 할 수 있고 리뷰/머지도 할 수 있지만, 안 해요. 제 일은 이미 충분히 중독성 있어서, 밖에 있거나 친구들 만날 땐 더 빨려들고 싶지 않거든요.

에이전틱 여정의 도구들

도구들 얘기해볼게요. Conductor, Terragon, Sculptor 그리고 다른 1000개 정도. 취미 프로젝트도 있고 VC 돈에 빠져있는 것도 있죠. 엄청 많이 써봤어요. 하나도 안 남아요. 제 생각엔 현재의 비효율성을 우회하고 최적이 아닌 워크플로우를 홍보하는 거예요. 게다가 대부분 터미널을 숨기고 모델이 보여주는 모든 걸 안 보여줘요.

대부분은 Anthropic의 SDK + work tree 관리를 얇게 감싼 거예요. 해자가 없어요. 그리고 폰에서 코딩 에이전트에 더 쉽게 접근하고 싶은지 의문이에요. 제가 했던 작은 사용 케이스는 codex web이 완전히 커버해요.

MCP는요?

다른 사람들이 MCP에 대해 많이 썼어요. 제 생각엔 대부분 마케팅 부서가 체크박스 만들고 자랑하려는 거예요. 거의 모든 MCP는 진짜 CLI여야 해요. 제가 MCP 5개를 직접 만든 사람으로서 하는 말이에요.

CLI는 이름으로 참조할 수 있어요. 에이전트 파일에 설명이 필요 없죠. 에이전트가 첫 호출에 $randomcrap을 시도하면, CLI가 도움말 메뉴를 보여주고, 컨텍스트에 이게 어떻게 작동하는지 전체 정보가 생기고 이제부터는 문제없어요. MCP처럼 지속적인 비용도 없고, 컨텍스트의 쓰레기도 안 돼요. GitHub의 MCP 쓰면 23k 토큰이 날아가요. 처음 출시했을 땐 거의 5만이었는데 더 나아진 거죠. 아니면 기본적으로 같은 기능 세트를 가진 gh CLI를 쓰면, 모델이 이미 사용법을 알고, 컨텍스트 세금은 제로예요.

요즘은 chrome-devtools-mcp를 써요. 루프를 닫기 위해서요. Playwright를 대체해서 웹 디버깅용 제 go-to MCP가 됐어요. 많이 필요하진 않지만, 필요할 때는 루프를 닫는 데 꽤 유용해요.

코드가 slop이잖아요!

시간의 약 20%를 리팩토링에 써요. 물론 전부 에이전트가 하죠. 수동으로 그런 거 할 시간 낭비 안 해요. 리팩토링 날은 집중이 덜 필요하거나 피곤할 때 좋아요. 너무 많은 집중이나 명확한 사고 없이도 좋은 진전을 만들 수 있거든요.

전형적인 리팩토링 작업은 코드 중복을 위한 jscpd, 데드 코드를 위한 knip, eslint의 react-compiler랑 deprecation 플러그인 돌리기, API 라우트 통합 체크하기, 문서 유지하기, 너무 커진 파일 쪼개기, 까다로운 부분에 테스트랑 코드 주석 추가하기, 의존성 업데이트, 도구 업그레이드, 파일 재구조화, 느린 테스트 찾아서 다시 쓰기, 현대 React 패턴 언급하고 코드 다시 쓰기 등이 있죠. 할 일은 항상 있어요.

매 커밋마다 이걸 할 수도 있다고 주장할 수 있지만, 빠르게 반복하는 단계와 코드베이스를 유지하고 개선하는 단계 - 기본적으로 기술 부채를 조금 갚는 단계를 갖는 게 훨씬 생산적이고 전반적으로 훨씬 재미있더라고요.

spec 기반 개발을 하나요?

6월에는 했어요. 큰 spec 디자인하고, 모델이 만들게 하고, 이상적으로는 몇 시간 동안. 제 생각엔 그게 소프트웨어 구축에 대한 옛날 사고방식이에요.

현재 접근법은 보통 codex랑 토론을 시작하는 거예요. 웹사이트 몇 개, 아이디어 좀 붙여넣고, 코드 읽으라고 하고, 함께 새 기능을 구체화해요. 까다로운 거면 spec에 전부 쓰라고 하고, 그걸 GPT-5-Pro한테 줘서 리뷰받고(chatgpt.com을 통해) 더 나은 아이디어가 있는지 봐요(놀랍게도 자주 제 플랜을 크게 개선해요!). 그 다음 유용하다고 생각하는 걸 메인 컨텍스트에 다시 붙여넣어서 파일을 업데이트해요.

이제 어떤 작업이 얼마나 컨텍스트를 쓸지 감이 잡히고, codex의 컨텍스트 공간이 꽤 좋아서 종종 그냥 빌드를 시작해요.

UI 기반 작업의 더 재미있는 접근법

훨씬 더 재미있는 접근법은 UI 기반 작업할 때예요. 종종 간단한 걸로 시작하고 요청을 완전히 부족하게 spec하고, 모델이 빌드하는 걸 지켜보고 브라우저가 실시간으로 업데이트되는 걸 봐요. 그 다음 추가 변경사항을 큐에 넣고 기능을 반복해요. 종종 뭔가가 어떻게 보여야 할지 완전히 모르는데, 이 방식으로 아이디어를 가지고 놀고 반복하면서 천천히 살아나는 걸 볼 수 있어요. codex가 제가 생각도 못 한 흥미로운 걸 만드는 걸 자주 봤어요. 리셋 안 해요. 그냥 반복하고 카오스를 올바른 형태로 변형시켜요.

슬래시 커맨드 보여주세요!

몇 개 없고, 드물게 써요:

• /commit - 여러 에이전트가 같은 폴더에서 작업한다고 설명하는 커스텀 텍스트, 당신의 변경사항만 커밋하라고 해서 깔끔한 코멘트를 받고 gpt가 다른 변경사항에 대해 놀라서 linter 실패하면 되돌리려고 하지 않게
• /automerge - 한 번에 PR 하나씩 처리, 봇 코멘트에 반응, 답장, CI 그린으로 만들고 그린이면 squash
• /massageprs - automerge와 같지만 squashing 없어서 PR 많으면 병렬화 가능
• /review - 내장, 가끔만 (GH에 리뷰 봇이 있어서), 하지만 유용할 수 있음

이것들로도 보통 그냥 “commit”이라고 타이핑해요. 너무 많은 더러운 파일이 있어서 가이던스 없으면 에이전트가 망칠 수 있다는 걸 알지 않는 한요. 확신이 있으면 연극/컨텍스트 낭비가 필요 없어요. 이런 거에 대한 직관이 생겨요.

다른 트릭 있어요?

장기 실행 작업에서 계속하도록 에이전트를 동기부여할 완벽한 프롬프트를 만들려고 하는 대신, 게으른 우회 방법이 있어요. 큰 리팩터를 하면 codex가 종종 중간 작업 답변으로 멈춰요. 떠나서 완료된 걸 보고 싶으면 continue 메시지들을 큐에 넣으면 돼요. codex가 끝나고 더 많은 메시지를 받으면, 기꺼이 무시해요.

각 기능/수정이 끝나면 모델한테 테스트 쓰라고 하세요. 같은 컨텍스트를 쓰세요. 이게 훨씬 좋은 테스트로 이어질 거고, 구현의 버그를 발견할 가능성이 높아요. 순전히 UI 조정이면 테스트가 의미 없을 수도 있지만, 다른 건 다 해요. AI가 일반적으로 좋은 테스트를 쓰는 데 안 좋지만, 그래도 도움이 돼요. 솔직히 - 여러분은 만드는 모든 수정에 테스트를 쓰나요?

모델한테 의도를 보존하고 “add code comments on tricky parts”라고 하면 여러분과 미래의 모델 실행 둘 다 도와줘요.

일이 어려워지면, “take your time”, “comprehensive”, “read all code that could be related”, “create possible hypothesis” 같은 트리거 단어를 프롬프팅에 추가하면 codex가 가장 까다로운 문제도 해결해요.

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

Agents.md 파일이 있고 claude.md로 심볼릭 링크가 있어요. Anthropic이 표준화 안 하기로 했거든요. GPT-5가 Claude와 꽤 다른 프롬프팅을 선호해서 이게 어렵고 최적이 아니라는 걸 인정해요.

Claude는 100마리 새끼 고양이가 죽을 거라고 위협하는 🚨 전부 대문자로 소리치는 🚨 명령어에 잘 반응하지만, 그게 GPT-5를 놀라게 해요. (당연하죠). 그러니까 그런 거 다 빼고 그냥 인간처럼 단어를 쓰세요. 이건 이 파일들을 최적으로 공유할 수 없다는 의미예요. 저한테는 문제가 안 돼요. 주로 codex를 쓰고, claude가 가끔 플레이할 때 명령어가 너무 약할 수 있다는 걸 받아들이거든요.

제 Agent 파일은 현재 약 800줄이고 조직적 흉터 조직의 컬렉션 같아요. 제가 쓴 게 아니라 codex가 썼고, 뭔가 생길 때마다 거기에 간결한 메모 하나 만들라고 해요. 언젠가 정리해야겠지만, 크기에도 불구하고 엄청 잘 작동하고, gpt가 거기 있는 항목들을 정말 대부분 따라요. 적어도 Claude가 했던 것보다 훨씬훨씬 더 자주요.

GPT-5-Codex는 완벽한가요?

절대 아니에요. 가끔 30분 동안 리팩토링하다가 패닉해서 모든 걸 되돌리고, 다시 실행해서 아이 달래듯이 시간이 충분하다고 말해줘야 해요. 가끔 bash 커맨드를 할 수 있다는 걸 잊어버려서 격려가 좀 필요해요. 가끔 러시아어나 한국어로 답장하기도 해요. 가끔 괴물이 실수해서 생각을 bash로 직접 보내기도 하죠. 하지만 전반적으로 이런 건 꽤 드물고, 다른 거의 모든 면에서 엄청나게 좋아서 이런 결점은 눈감아줄 수 있어요. 인간도 완벽하지 않잖아요.

codex에 대한 제 최대 짜증은 라인을 “잃어버려서” 빠르게 스크롤하면 텍스트의 일부가 사라지는 거예요. 이게 OpenAI 버그 명단의 맨 위에 있기를 정말 바라요. 가끔 느려져야 해서 메시지가 사라지지 않게 하는 주된 이유거든요.

결론

RAG, subagents, Agents 2.0이나 대부분 그냥 연극인 다른 것들에 시간 낭비하지 마세요. 그냥 대화하세요. 가지고 놀아보세요. 직관을 개발하세요. 에이전트와 더 많이 작업할수록 결과가 더 좋아질 거예요.

Simon Willison의 글이 훌륭한 포인트를 만들어요 - 에이전트를 관리하는 데 필요한 많은 스킬들은 엔지니어를 관리할 때 필요한 것과 비슷해요. 이런 것들 거의 전부가 시니어 소프트웨어 엔지니어의 특성이죠.

그리고 좋은 소프트웨어를 만드는 건 여전히 어려워요. 제가 더 이상 코드를 안 쓴다고 해서 아키텍처, 시스템 디자인, 의존성, 기능, 사용자를 즐겁게 하는 방법에 대해 열심히 생각 안 하는 건 아니에요. AI를 쓴다는 건 단순히 배송해야 하는 것에 대한 기대치가 올라갔다는 의미일 뿐이에요.