모델이 생각하는 속도로 제품을 내는 시대

https://steipete.me/posts/2025/shipping-at-inference-speed

5월 이후로 달라진 점

올해 “바이브 코딩(vibe coding)”이 얼마나 멀리 왔는지는 정말 놀랍습니다. 대략 5월만 해도, 어떤 프롬프트들은 바로 동작하는 코드를 내놓는다는 사실만으로도 감탄했는데, 지금은 그게 제 기본 기대치가 되었습니다. 지금은 거의 비현실적인 속도로 코드를 배포할 수 있습니다. 그 사이에 토큰을 정말 많이 태웠고, 이제 업데이트를 할 때가 된 것 같습니다.

에이전트들이 동작하는 방식은 참 재미있습니다. 몇 주 전에, 나쁜 아키텍처를 ‘느끼려면’ 실제로 코드를 써봐야 한다, 그리고 에이전트를 쓰면 그 감각과의 연결이 끊어진다는 주장에 대한 논쟁이 있었는데, 저는 여기에 대해 완전히 동의하지 않습니다. 에이전트와 충분히 시간을 보내다 보면, 어떤 일이 얼마 정도 걸려야 하는지 감이 생기고, 코덱스가 한 번에 해결하지 못하고 결과를 가져오면, 그 순간부터 이미 “뭔가 이상하다”는 의심이 듭니다.

지금 제가 만들 수 있는 소프트웨어의 양은 대부분 추론(inference) 시간과 진짜로 머리를 써야 하는 정도에 의해 제한됩니다. 그리고 솔직히 말해서, 대부분의 소프트웨어는 깊은 사고를 요구하지 않습니다. 대부분의 앱은 한 형태의 데이터를 다른 형태로 옮기고, 어딘가에 저장한 다음, 그걸 어떤 방식으로든 사용자에게 보여줄 뿐입니다. 가장 단순한 형태는 텍스트이고, 그래서 기본적으로, 제가 무엇을 만들든 처음에는 CLI로 시작합니다. 에이전트는 CLI를 직접 호출해서 출력 결과를 검증할 수 있고, 이렇게 해서 루프를 닫을 수 있습니다.

모델의 변화

공장처럼 만들어내는 수준으로 전환하게 한 진짜 열쇠는 GPT 5였습니다. 출시 후 몇 주는 이걸 체감하는 데 걸렸고, 클로드 코드가 가지고 있던 기능들을 코덱스가 따라잡는 데도 시간이 조금 필요했으며, 모델 간의 차이를 배우고 이해하는 데도 시간이 좀 들었습니다. 하지만 그 이후로 저는 이 모델을 점점 더 신뢰하게 되었습니다. 요즘 저는 코드를 거의 읽지 않습니다. 스트리밍 되는 걸 보면서, 가끔 핵심적인 부분만 들여다볼 뿐인데, 솔직히 말하면 대부분의 코드는 읽지 않습니다. 대신 어느 컴포넌트가 어디에 있는지, 구조는 어떻게 되어 있는지, 전체 시스템이 어떻게 설계되어 있는지만 알고 있고, 보통은 그 정도면 충분합니다.

요즘 진짜 중요한 결정은 언어/에코시스템과 의존성을 고르는 일입니다. 웹 관련 작업에는 TypeScript, CLI에는 Go, 그리고 macOS 기능을 써야 하거나 UI가 필요하면 Swift를 기본으로 사용합니다. Go는 몇 달 전까지만 해도 제가 전혀 고려조차 하지 않던 언어였는데, 어느 순간 시험 삼아 써보니 에이전트가 Go 코드를 정말 잘 쓰고, 타입 시스템이 단순해서 린팅도 빠르다는 걸 알게 되었습니다.

Mac이나 iOS용으로 무언가를 만드는 분들께: 이제 Xcode를 많이 쓸 필요가 없습니다. 저는 xcodeproj 파일을 아예 쓰지 않습니다. 요즘은 Swift의 빌드 인프라만으로도 대부분의 작업에 충분합니다. 코덱스는 iOS 앱을 어떻게 실행하는지, 시뮬레이터를 어떻게 다루는지도 알고 있습니다. 별도의 특수한 장치나 MCP 같은 건 필요 없습니다.

codex vs Opus

이 글을 쓰고 있는 지금도, 코덱스는 엄청나게 큰, 몇 시간짜리 리팩터링 작업을 돌리면서 예전 Opus 4.0 시절의 온갖 죄악들을 청소하고 있습니다. 트위터(X)에서 사람들은 자주 “Opus와 코덱스의 큰 차이가 무엇인지, 벤치마크 상으로는 거의 비슷해 보이는데 왜 그게 중요한지”를 묻곤 합니다. 제 생각에는, 벤치마크를 신뢰하기가 점점 더 어려워지고 있습니다. 둘 다 직접 써봐야 진짜 차이를 이해할 수 있습니다. OpenAI가 후처리(post-training)에서 무엇을 했는지는 모르겠지만, 코덱스는 코드를 쓰기 시작하기 전에 정말 많은 코드를 읽도록 훈련된 것 같습니다.

가끔은 코드를 쓰기 시작하기 전에, 그냥 조용히 파일들을 10~15분 동안 읽기만 할 때도 있습니다. 한편으로는 꽤 짜증 나지만, 다른 한편으로는 이게 정말 대단한 게, 그게 바로 “정말 고쳐야 할 부분”을 건드릴 확률을 크게 높여주기 때문입니다. 반면 Opus는 훨씬 더 성급합니다. 작은 수정에는 좋지만, 큰 기능 추가나 대규모 리팩터링에는 별로 좋지 않습니다. 파일 전체를 다 읽지 않거나 일부를 놓치기도 하고, 그러다 보니 비효율적인 결과를 내거나 뭔가를 빠뜨릴 때가 많습니다. 코덱스는 동일한 작업에서 Opus보다 4배 정도 더 오래 걸리는 경우가 종종 있지만, 되돌아가 “수정을 다시 고치는” 일을 하지 않아도 되기 때문에, 전체적으로는 제가 더 빨라진다는 걸 느꼈습니다. 클로드 코드를 쓸 때는 그런 왕복이 꽤 당연하게 느껴졌습니다.

코덱스를 쓰면서, 저는 클로드 코드에서 필요했던 여러 의식 같은 것들을 많이 잊어버릴 수 있게 됐습니다. “플랜 모드(plan mode)”를 쓰는 대신, 저는 그냥 모델과 대화를 시작합니다. 질문을 던지고, 검색을 시키고, 코드를 탐색하게 하고, 함께 계획을 세운 다음, 제가 그 계획에 만족하면 “build”라 쓰거나 “write plan to docs/*.md and build this”라고 적습니다. 플랜 모드는, 예전 세대의 모델들이 프롬프트를 잘 따르지 못해서, 우리가 에디트 툴을 빼앗아야 했던 시절에 어쩔 수 없이 필요했던 해킹에 가까운 기능처럼 느껴집니다. 제 트윗 중에는 많이 오해받는 글이 아직도 돌아다니고 있는데, 그걸 보면서 “사람들이 플랜 모드가 마법이 아니라는 것을 잘 이해하지 못하는구나”라는 걸 깨달았습니다.

Oracle

GPT 5/5.1에서 5.2로의 단계는 엄청났습니다. 저는 약 한 달 전에 oracle 🧿을 만들었습니다. GPT 5 Pro를 실행하고, 파일과 프롬프트를 업로드하고, 세션을 관리해서 나중에 답변을 다시 가져올 수 있게 해주는 CLI입니다. 이걸 만든 이유는, 에이전트가 막힐 때마다 에이전트에게 “모든 내용을 마크다운 파일로 정리하라”고 시키고, 그걸 제가 직접 모델에 넣어서 질의하곤 했는데, 이 반복이 너무 수고스럽고 시간 낭비처럼 느껴졌기 때문입니다. 동시에 이 루프를 닫을 좋은 기회처럼 느껴지기도 했고요. 오라클에 대한 사용 지침은 제 전역 AGENTS.MD 파일에 적혀 있고, 종종 모델이 스스로 막혔다고 판단되면 oracle을 호출하곤 했습니다. 저는 하루에도 여러 번 이걸 사용했습니다. 정말 엄청난 언락이었습니다. Pro는 대략 50개 정도의 웹사이트를 초고속으로 훑은 다음, 정말 깊이 생각해서 거의 모든 경우에 정답에 가까운 응답을 냅니다. 어떤 때는 10분 정도로 빠르게 끝나지만, 한 시간 넘게 걸린 적도 있습니다.

이제 GPT 5.2가 나온 뒤로는, 이런 상황이 훨씬 줄어들었습니다. 저는 여전히 리서치가 필요할 때 Pro를 직접 쓰긴 하지만, 모델에게 “오라클에게 물어봐”라고 요청해야 하는 경우는 하루에 여러 번에서 주당 몇 번 수준으로 줄었습니다. 이게 줄어들었다고 해서 아쉬운 건 아닙니다. 오라클을 만드는 과정 자체가 정말 즐거웠고, 브라우저 자동화, 윈도우즈, 그리고 한동안 무시하던 스킬 개념 같은 것들을 공부할 수 있었으니까요. 하지만 이 변화가 보여주는 건, 5.2가 실제 코딩 작업에서 훨씬 더 좋아졌다는 사실입니다. 던지는 작업마다 거의 거의 모든 걸 한 방에(one-shot) 해결해 줍니다.

또 하나 큰 승리는 지식 컷오프 날짜입니다. GPT 5.2의 지식은 8월 말까지고, Opus는 3월 중순에서 멈춰 있습니다. 거의 5개월 차이가 나는 셈인데, 최신 도구를 사용하고 싶을 때는 이게 꽤 중요합니다.

구체적인 사례: VibeTunnel

모델이 얼마나 발전했는지 또 다른 예를 들어보겠습니다. 제가 초기부터 정말 깊이 파고들었던 프로젝트 중 하나가 VibeTunnel입니다. 이동 중에도 코딩을 할 수 있도록 해주는 터미널 멀티플렉서죠. 올해 초에는 거의 모든 시간을 이 프로젝트에 쏟아부었고, 두 달 정도 지나자, 친구들과 밖에 나와 있을 때조차 폰으로 코딩하고 있는 제 모습을 발견했습니다… 그리고 정신 건강을 위해서라도 이건 멈춰야겠다고 결심했습니다. 그때 저는 멀티플렉서의 핵심 부분을 TypeScript에서 다른 언어로 옮기려고 했고, 예전 모델들은 이 작업에서 계속 실패했습니다. Rust도 써보고, Go도 써보고, 심지어 zig까지 손을 대봤습니다. 물론 제가 직접 나서서 리팩터링을 끝낼 수도 있었겠지만, 그러려면 손으로 해야 할 일이 너무 많았고, 그래서 프로젝트를 멈추기 전에 이 작업을 끝내지 못했습니다. 그러다 지난주에 이 프로젝트의 먼지를 털어내고, 코덱스에게 포워딩 시스템 전체를 zig로 변환하라는 두 문장짜리 프롬프트를 줬습니다. 그리고 코덱스는 5시간 넘게 작업을 돌리면서 여러 번 컴팩션을 거쳐, 한 번에 동작하는 변환 결과를 내놓았습니다.

“그걸 왜 다시 꺼내 들었냐”고 묻는다면, 요즘 제 주된 관심사는 Clawdis이기 때문입니다. Clawdis는 제 모든 컴퓨터, 메시지, 이메일, 홈 오토메이션, 카메라, 조명, 음악, 심지어 침대 온도까지 모든 것에 완전한 접근 권한을 가진 AI 어시스턴트입니다. 물론 고유한 목소리도 있고, 트윗을 올리는 CLI도 있으며, clawd.bot도 갖고 있습니다.

Clawd는 제 화면을 보고 제어할 수 있고, 가끔은 빈정거리는 농담도 던지지만, 저는 여기에 더해 에이전트들을 체크할 수 있는 능력도 주고 싶었습니다. 그런 면에서, 문자(character) 스트림을 받는 것이 이미지를 보는 것보다 훨씬 효율적입니다… 이게 실제로 잘 먹힐지는 두고 봐야겠죠!

나의 워크플로우

알고 있습니다… 여러분은 여기서 더 빨리 만드는 방법을 배우고 싶어서 왔는데, 저는 OpenAI 광고처럼 들리는 글만 쓰고 있죠. Anthropic이 Opus 5를 잘 준비하고 있고, 다시 판이 뒤집히길 바라고 있습니다. 경쟁은 좋은 것이니까요! 동시에, 저는 Opus를 범용 모델로 정말 사랑합니다. 제 AI 에이전트가 GPT 5로만 돌았다면, 지금만큼 재미있지 않았을 겁니다. Opus에는 함께 작업하는 게 정말 즐겁게 느껴지는 뭔가 특별한 것이 있습니다. 저는 대부분의 컴퓨터 자동화 작업에 Opus를 쓰고, 물론 Clawd🦞도 Opus로 구동됩니다.

제 워크플로우는 10월에 썼던 글 이후로 크게 바뀌지 않았습니다.

저는 보통 여러 프로젝트를 동시에 진행합니다. 복잡도에 따라 다르지만, 대략 3~8개 정도입니다. 컨텍스트 스위칭은 꽤 피곤한 일이라, 집에서, 조용한 환경에서 집중해서 일할 때만 이렇게 할 수 있습니다. 머릿속에서 다뤄야 할 멘탈 모델이 정말 많거든요. 다행히 대부분의 소프트웨어는 지루합니다. 음식 배달 상태를 확인하는 CLI를 만든다고 해서, 깊은 사고가 필요한 건 아니니까요. 보통 제 주된 집중은 하나의 큰 프로젝트에 가 있고, 위성을 도는 작은 프로젝트들이 옆에서 꾸준히 돌아갑니다. 에이전트 공학(agentic engineering)을 충분히 하다 보면, 어떤 건 쉬울지, 어디서 모델이 힘들어할지 감이 생기는데, 그래서 자주 그냥 프롬프트만 던져놓고, 코덱스가 30분 동안 작업을 돌리게 한 뒤 결과를 받습니다. 가끔은 약간의 손질이나 창의성이 필요하긴 하지만, 많은 경우 일은 상당히 단순하게 흘러갑니다.
저는 코덱스의 큐(queue) 기능을 아주 적극적으로 사용합니다. 새로운 아이디어가 떠오를 때마다, 그걸 파이프라인에 넣습니다. 많은 사람들이 여러 에이전트 오케스트레이션 시스템, 이메일 기반 워크플로우, 자동 작업 관리 같은 것들을 실험하고 있지만, 지금까지는 그게 꼭 필요하다고 느낀 적이 없습니다. 대부분의 경우 병목은 저 자신이기 때문입니다. 저는 소프트웨어를 아주 반복적으로 만드는 스타일입니다. 먼저 뭔가를 만들고, 직접 써보고, “느낌이 어떤지”를 본 다음, 거기서 아이디어가 새로 나옵니다. 머릿속에 완전히 온전한 그림이 그려져 있는 경우는 거의 없습니다. 물론 대략적인 방향은 있지만, 문제 영역을 탐색하면서 그 방향이 크게 바뀌는 경우가 많습니다. 그래서 “완전한 아이디어”를 입력으로 받아서 결과를 한 번에 내놓는 시스템은 제게 잘 맞지 않습니다. 저는 직접 만지고, 사용해 보고, 느껴보고, 눈으로 확인해 가며 발전시키는 방식을 선호합니다.
저는 기본적으로 리버트(revert)나 체크포인트를 거의 쓰지 않습니다. 마음에 들지 않는 부분이 있으면, 모델에게 그걸 고치라고 요청합니다. 코덱스가 가끔 파일을 통째로 되돌리긴 하지만, 대개는 그 직전의 변경을 되돌리거나 수정하는 방식으로 진행합니다. 완전히 처음으로 돌아가야 하는 경우는 매우 드물고, 대신 그냥 다른 방향으로 계속 이동할 뿐입니다. 소프트웨어를 만드는 건 산을 올라가는 것과 같습니다. 직선으로 꼭대기까지 올라가는 게 아니라, 빙빙 돌면서 올라가고, 때로는 길을 벗어나 조금 되돌아오기도 하면서, 완벽하진 않지만 결국에는 목적지에 도달합니다.
저는 그냥 main 브랜치에 바로 커밋합니다. 가끔 코덱스가 “이건 너무 지저분하다”고 판단하면 자동으로 worktree를 만들고, 나중에 변경 사항을 병합해 주기도 하는데, 그런 경우는 드물고, 저도 특별한 상황에서만 그렇게 하라고 프롬프트를 줍니다. 여러 상태를 동시에 생각해야 하는 추가적인 인지 부담을 싫어하는 편이라, 선형적으로 진화하는 방식을 선호합니다. 좀 더 큰 작업들은 제가 산만한 상태일 때를 위해 남겨두는데, 예를 들어 지금 이 글을 쓰는 동안에도, 다른 네 개 프로젝트에서 1~2시간씩 걸리는 리팩터링을 돌리고 있습니다. 물론 그런 작업을 worktree에서 할 수도 있겠지만, 그러면 머지 충돌이 많아지고 리팩터링도 최적이 아니게 됩니다. 단, 저는 보통 혼자 일하기 때문에 이런 워크플로우가 가능하고, 팀이 크다면 당연히 통하지 않을 겁니다.
기능을 설계하는 방식은 이미 이야기했습니다. 저는 프로젝트들 간에 크로스 레퍼런싱을 아주 많이 합니다. 특히 이미 어딘가에서 해결했던 문제라는 걸 알 때는, 코덱스에게 ../project-folder에서 찾아보라고 시키고, 그 정도면 보통 모델이 어디를 봐야 할지 충분히 추론합니다. 이렇게 하면 프롬프트를 크게 아낄 수 있습니다. 그냥 “look at ../vibetunnel and do the same for Sparkle changelogs” 같은 식으로 적으면 되고, 이미 그 프로젝트에서 해결된 문제라면 거의 99% 확률로 코드를 잘 복사해 오고, 새로운 프로젝트에 맞게 잘 적용해 줍니다. 새 프로젝트를 스캐폴딩 할 때도 이런 식으로 많이 합니다.
세션을 다시 참조하고 싶어 하는 사람들을 위해 만들어진 여러 시스템들을 본 적이 있습니다. 저는 그런 걸 거의 필요로 하지도, 사용하지도 않습니다. 각 프로젝트마다, 서브시스템과 기능에 대한 문서를 docs 폴더에 유지합니다. 그리고 제 전역 AGENTS 파일에 있는 스크립트와 몇 가지 지침을 사용해서, 특정 주제에 대해 모델이 반드시 관련 문서를 먼저 읽도록 강제합니다. 이건 프로젝트가 커질수록 더 값어치가 커져서, 작은 프로젝트에는 굳이 쓰지 않지만, 규모가 있는 프로젝트에서는 문서를 최신 상태로 유지하고, 작업에 더 좋은 컨텍스트를 제공하는 데 꽤 큰 도움이 됩니다.
컨텍스트 이야기가 나왔으니, 예전에는 새로운 작업을 시작할 때마다 세션을 다시 시작하는 데 꽤 신경을 썼습니다. 하지만 GPT 5.2에서는 이제 그럴 필요가 거의 없습니다. 컨텍스트가 꽉 찼을 때도 성능이 굉장히 좋고, 모델이 이미 많은 파일을 로드해 둔 상태에서는 오히려 더 빠르게 작업하는 경우도 많습니다. 물론 이건 작업을 직렬화하거나, 서로 다른 세션의 변경 사항이 서로 겹치지 않도록 충분히 떼어 놓았을 때만 잘 작동합니다. 코덱스는 클로드 코드와 달리 “이 파일이 변경되었다”라는 시스템 이벤트가 없기 때문에, 그 부분은 사용자가 더 조심해야 합니다. 반면 코덱스는 컨텍스트를 훨씬 더 잘 관리합니다. 하나의 코덱스 세션에서 클로드 세션보다 5배는 더 많은 일을 해낸다는 느낌을 받습니다. 이건 단순히 컨텍스트 창이 더 크다는 객관적인 차이만으로 설명되지는 않고, 그 외의 요인이 있는 것 같습니다. 제 추측으로는, 코덱스는 내부적으로 토큰을 절약하기 위해 생각을 아주 압축해서 하는 반면, Opus는 말이 많은 스타일인 것 같습니다. 가끔 모델이 실수해서 내부 사고 스트림이 사용자에게 흘러나올 때가 있는데, 이런 장면을 꽤 자주 봤습니다. 정말로, 코덱스는 단어를 다루는 방식이 묘하게 재미있습니다.
프롬프트 이야기를 해보죠. 예전에는 음성 입력을 써서 길고 정교한 프롬프트를 쓰곤 했습니다. 그런데 코덱스를 쓰면서 프롬프트는 훨씬 짧아졌고, 다시 키보드로 타이핑하는 경우가 많아졌습니다. UI를 반복적으로 다듬을 때(또는 CLI 텍스트 카피를 손볼 때)는, 이미지를 자주 추가하기도 합니다. 뭐가 잘못됐는지 모델에게 보여주기만 하면, 몇 마디만 적어도 원하는 작업을 잘 수행해 줍니다. 저는 UI 컴포넌트의 클립된 이미지를 끌어다 놓고 “fix padding”이나 “redesign” 같은 메모만 남기는 사람이기도 한데, 이 정도만으로 문제를 해결하거나, 적어도 꽤 멀리까지 나아가는 경우가 많습니다. 예전에는 마크다운 파일을 직접 참조하게 하는 편이었지만, 지금은 docs:list 스크립트 덕분에 그럴 필요가 사라졌습니다.
마크다운 이야기로 넘어가면, 저는 자주 “write docs to docs/\*.md”라고 적고, 파일 이름은 모델이 알아서 정하게 둡니다. 모델이 학습할 때 봐왔을 법한 구조를 최대한 그대로 반영해 주는 식으로 디자인하면, 일이 훨씬 쉬워집니다. 결국 저는 코드베이스를 제가 보기 편하도록 설계하는 게 아니라, 에이전트가 효율적으로 일할 수 있도록 엔지니어링합니다. 모델과 싸우는 건 대개 시간과 토큰 낭비입니다.

도구와 인프라

여전히 어려운 것은 무엇일까요? 어떤 의존성과 프레임워크를 채택할지 고르는 데에는 여전히 꽤 많은 시간을 씁니다. 이 라이브러리가 잘 유지 관리되고 있는가? 피어 의존성은 괜찮은가? 충분히 인기가 있어서, 에이전트가 다룰 수 있을 정도로 세계 지식 속에 잘 녹아 있는가? 시스템 설계도 마찬가지입니다. 통신을 웹소켓으로 할까? HTML로 할까? 서버에는 무엇을 두고, 클라이언트에는 무엇을 둘까? 데이터는 어디에서 어디로 어떻게 흐를까? 이런 것들은 모델에게 설명하기가 조금 더 까다로운 경우가 많고, 그렇기 때문에 사람이 직접 리서치하고 고민하는 것이 큰 가치를 발휘하는 영역입니다.
프로젝트를 많이 관리하다 보니, 가끔은 에이전트를 제 프로젝트 폴더에서 그냥 실행해 둔 뒤, 새로운 패턴을 하나 발견하면 그걸 “내 최근 go 프로젝트들을 모두 찾아서, 거기에 이 변경을 동일하게 적용하고 changelog도 업데이트하라”고 시킵니다. 각 프로젝트에는 릴리즈 노트에 패치 버전이 하나씩 올라가는데, 나중에 다시 그 프로젝트를 열어볼 때 이미 놀랍게도 몇 가지 개선이 반겨주는 경우가 많습니다.
물론 저는 모든 것을 자동화합니다. 도메인을 등록하고 DNS를 변경해 주는 스킬이 있고, 괜찮은 프론트엔드를 작성해 주는 스킬도 있습니다. 제 AGENTS 파일에는 tailscale 네트워크에 대한 메모도 있어서, “내 mac studio에 접속해서 xxx를 업데이트해 줘”라고 말하기만 하면 됩니다.
여러 대의 Mac 이야기를 하자면, 저는 보통 두 대의 Mac으로 작업합니다. 큰 화면에는 MacBook Pro를 두고, 다른 화면에는 Jump Desktop으로 Mac Studio에 접속해 놓습니다. 어떤 프로젝트는 여기서, 어떤 프로젝트는 저기서 돌아갑니다. 어떤 때는 같은 프로젝트의 서로 다른 부분을 각 머신에서 편집하고, git으로 동기화하기도 합니다. worktree보다 단순한데, main에서의 드리프트를 조율하는 것도 훨씬 쉽습니다. 또, UI나 브라우저 자동화가 필요한 작업은 Studio 쪽으로 넘겨서, 알림창 같은 걸로 저를 방해하지 않도록 할 수 있다는 장점도 있습니다. (물론 Playwright의 헤드리스 모드도 있지만, 그게 통하지 않는 상황도 꽤 있습니다.)
또 하나의 장점은, 작업이 그쪽에서 계속 돌아간다는 것입니다. 그래서 제가 여행을 갈 때는, 원격 머신이 제 메인 워크스테이션이 되고, 제가 Mac을 닫더라도 작업은 계속 돌아갑니다. 과거에는 코덱스나 Cursor web 같은 진짜 비동기 에이전트를 많이 실험해 봤지만, 그 과정에서 “내가 조정할 수 있는 느낌(steerability)”이 많이 사라지는 게 아쉬웠고, 결국 그 작업물들이 풀 리퀘스트로 들어오게 되면서, 제 설정이 더 복잡해지는 것도 마음에 들지 않았습니다. 저는 터미널 하나로 끝나는 단순함을 훨씬 더 좋아합니다.
슬래시 명령어도 한때 많이 써봤지만, 결국 크게 유용하다고 느끼지 못해서 손을 뗐습니다. 일부는 스킬이 대체했고, 나머지는 그냥 “commit/push”라고 직접 쓰고 있습니다. /commit을 사용하는 것과 시간이 똑같이 들고, 항상 잘 동작하니까요.
예전에는 프로젝트를 리팩터링하고 정리하는 전용 날을 따로 잡는 편이었는데, 지금은 훨씬 더 애드혹하게 처리합니다. 프롬프트 수행 시간이 길어지기 시작하거나, 코드 스트림에 뭔가 보기 싫은 게 흘러가는 게 보이면, 그때 바로 처리해 버립니다.
linear 같은 이슈 트래커들도 여러 번 써봤지만, 결국 정착한 건 하나도 없습니다. 중요한 아이디어라면 저는 바로 실험해보고, 그렇지 않다면 그냥 기억해 두거나, 아니면 애초에 별 중요하지 않았던 겁니다. 물론 제 오픈소스 코드를 사용하는 사람들을 위해 공개 버그 트래커는 운영하지만, 제가 버그를 발견하면 그걸 쓰기 전에 바로 모델에게 프롬프트를 던지는 편입니다. 버그를 기록해 두었다가 나중에 다시 컨텍스트를 바꾸는 것보다 훨씬 빠르니까요.
무엇을 만들든지, 항상 모델과 CLI부터 시작하는 것이 좋습니다. 예를 들어, 저는 오래전부터 “YouTube 영상을 요약해 주는 Chrome 확장” 아이디어를 머릿속에 갖고 있었습니다. 지난주에는 summarize라는 CLI를 만들기 시작했는데, 이 도구는 어떤 것이든 마크다운으로 변환하고, 그걸 모델에 넣어 요약하도록 합니다. 먼저 코어 기능을 제대로 만든 뒤, 그게 잘 작동하는 걸 확인하고 나서, 하루 만에 전체 확장 프로그램을 만들었습니다. 결과물에 굉장히 만족하고 있습니다. 로컬, 무료, 유료 모델 어디든 붙을 수 있고, 영상이나 오디오를 로컬에서 바로 변환합니다. 로컬 데몬과 통신하도록 되어 있어서 정말 빠릅니다. 직접 써보시길 추천합니다!
제가 기본으로 쓰는 모델은 gpt-5.2-codex high입니다. 다시 말하지만, KISS(Keep It Simple, Stupid)입니다. . xhigh를 쓴다고 해서 얻는 이점은 거의 없고, 단지 훨씬 더 느려질 뿐이라서, 모드나 “ultrathink” 같은 걸 고민하는 데 시간을 쓰고 싶지 않습니다. 그래서 거의 모든 작업을 high에서 돌립니다. GPT 5.2와 codex는 충분히 비슷해서, 모델을 바꿔 쓸 이유가 없고, 그래서 그냥 그것만 사용합니다.

My Config

이것이 제 ‎~/.codex/config.toml입니다:

model = "gpt-5.2-codex"
model_reasoning_effort = "high"
tool_output_token_limit = 25000
# 272–273k 컨텍스트 윈도우 근처에서 네이티브 컴팩션을 위한 여유를 남겨둡니다.
# 공식: 273000 - (tool_output_token_limit + 15000) 
# tool_output_token_limit=25000일 때 ⇒ 273000 - (25000 + 15000) = 233000 
model_auto_compact_token_limit = 233000
[features]
ghost_commit = false
unified_exec = true
apply_patch_freeform = true
web_search_request = true
skills = true
shell_snapshot = true

[projects."/Users/steipete/Projects"]
trust_level = "trusted"

이 설정은 모델이 한 번에 더 많은 내용을 읽을 수 있게 해줍니다. 기본값은 조금 작은 편이라, 모델이 볼 수 있는 범위를 제한하기도 합니다. 이 한계에 부딪히면 조용히(에러 없이) 실패하는데, 이게 꽤 성가신 점이고, 언젠가는 고쳐질 부분이기도 합니다. 그리고 web search가 아직도 기본으로 켜져 있지 않다는 게 믿기지 않죠. ‎unified_exec는 tmux와 예전에 쓰던 ‎runner 스크립트를 대체했고, 나머지 옵션들도 꽤 쓸 만합니다. 그리고 컴팩션(compaction)을 너무 두려워할 필요는 없습니다. OpenAI가 새 ‎/compact 엔드포인트로 전환한 뒤로는, 여러 번 컴팩션이 일어나도 작업이 끝까지 잘 진행될 만큼 충분히 잘 작동합니다. 속도는 느려지지만, 종종 일종의 코드 리뷰처럼 작용해서, 모델이 코드를 다시 살펴보는 과정에서 버그를 찾아내기도 합니다.

지금은 여기까지입니다. 다시 글을 더 자주 쓰려고 하고 있고, 머릿속에는 이미 아이디어 백로그가 한가득 쌓여 있습니다. 요즘은 그저 무언가를 만드는 일 자체가 너무 즐겁기 때문입니다. 이 새로운 시대에 어떻게 만들어 나갈지에 대한 제 수다와 아이디어를 더 듣고 싶으시다면, 트위터에서 저를 팔로우해 주세요.