추론 속도로 배포하기
Shipping at Inference-Speed
게시일: 2025년 12월 28일 작성자: Peter Steinberger
5월 이후 달라진 점
올해 "바이브 코딩(vibe coding)"이 얼마나 발전했는지 생각해보면 놀라울 따름입니다. 지난 5월 즈음만 해도 프롬프트 몇 번으로 바로 작동하는 코드가 나온다는 사실에 놀라워했었는데, 이제는 그게 당연한 기대치가 되었습니다. 지금 저는 비현실적으로 느껴질 만큼 빠른 속도로 코드를 배포하고 있습니다. 그동안 토큰도 정말 많이 태웠죠. 이제 업데이트를 할 시간입니다.
이 에이전트들이 작동하는 방식은 참 재미있습니다. 몇 주 전, 나쁜 아키텍처를 느끼기 위해서는 직접 코드를 짜봐야 하며, 에이전트를 사용하는 것은 단절을 초래한다는 주장이 있었는데, 저는 이 의견에 결코 동의할 수 없습니다. 에이전트와 충분한 시간을 보내다 보면, 어떤 작업이 얼마나 걸려야 하는지 정확히 알게 됩니다. 만약 codex(코덱스)가 결과를 가져왔는데 한 번에(one-shot) 해결하지 못했다면, 저는 이미 의심을 품게 되죠.
이제 제가 만들 수 있는 소프트웨어의 양은 주로 추론 시간(inference time)과 깊은 사고(hard thinking)에 의해 제한됩니다. 솔직히 말해서, 대부분의 소프트웨어는 깊은 사고를 필요로 하지 않습니다. 대부분의 앱은 데이터를 한 폼에서 다른 폼으로 옮기고, 어딘가에 저장한 뒤, 사용자에게 어떤 방식으로든 보여주는 것이 전부입니다. 가장 단순한 형태는 텍스트이므로, 저는 무엇을 만들든 기본적으로 CLI(명령줄 인터페이스)로 시작합니다. 에이전트가 이를 직접 호출하고 출력을 검증할 수 있어 개발 루프(loop)를 닫을 수 있기 때문입니다.
모델의 전환 (The Model Shift)
공장처럼 찍어내는 식의 개발을 가능하게 한 진정한 "잠금 해제"는 GPT-5였습니다. 출시 후 몇 주가 지나서야 깨달았고, codex가 claude code(클로드 코드)의 기능을 따라잡는 데 시간이 좀 걸렸으며, 차이점을 배우고 이해하는 데도 시간이 필요했지만, 그 후로는 모델을 점점 더 신뢰하기 시작했습니다. 요즘 저는 코드를 많이 읽지 않습니다. 생성되는 스트림을 지켜보다가 가끔 핵심 부분만 봅니다. 솔직히 말해서 대부분의 코드는 읽지 않습니다. 어떤 컴포넌트가 어디에 있는지, 구조가 어떻게 되어 있는지, 전체 시스템이 어떻게 설계되었는지만 알면 되는데, 보통은 그걸로 충분하니까요.
요즘 중요한 결정은 언어/생태계와 의존성(dependency) 선택입니다. 제가 즐겨 쓰는 언어는 웹 관련은 TypeScript, CLI는 Go, macOS 기능이나 UI가 필요하면 Swift입니다. Go는 몇 달 전만 해도 거들떠보지도 않던 언어였는데, 가지고 놀다 보니 에이전트가 Go 코드를 정말 잘 짠다는 것을 발견했습니다. 그리고 단순한 타입 시스템 덕분에 린팅(linting) 속도도 빠르고요.
Mac이나 iOS 앱을 만드는 분들: 더 이상 Xcode가 별로 필요 없습니다. 저는 xcodeproj 파일도 안 씁니다. 요즘 Swift의 빌드 인프라는 웬만한 건 다 커버합니다. codex는 iOS 앱을 실행하는 법도 알고 시뮬레이터를 다루는 법도 압니다. 특별한 도구나 MCP 같은 건 필요 없습니다.
codex 대 Opus
지금 이 글을 쓰고 있는 동안에도, codex는 거대하고 몇 시간이 걸리는 리팩터링 작업을 수행하며 Opus 4.0이 저질러 놓은 과거의 엉망인 코드들(slops)을 치우고 있습니다. 트위터 사람들은 종종 벤치마크 점수가 비슷한데 Opus와 codex의 큰 차이가 뭐냐고, 왜 굳이 따지냐고 묻습니다. 제 생각에 벤치마크를 신뢰하기는 점점 더 어려워지고 있습니다. 진짜 차이를 알려면 둘 다 써봐야 합니다. OpenAI가 사후 학습(post-training) 과정에서 무슨 짓을 했는지 몰라도, codex는 코드를 작성하기 전에 엄청난 양의 코드를 읽도록 훈련받았습니다.
가끔은 코드를 한 줄도 안 쓰고 10분, 15분 동안 조용히 파일만 읽을 때도 있습니다. 한편으로는 짜증 나지만, 다른 한편으로는 놀랍습니다. 제대로 된 부분을 고칠 확률이 훨씬 높아지니까요. 반면 Opus는 훨씬 더 성격이 급합니다(eager). 작은 수정에는 좋지만, 큰 기능 추가나 리팩터링에는 별로입니다. 파일 전체를 안 읽거나 일부를 놓쳐서 비효율적인 결과물을 내놓거나 뭔가를 빼먹곤 합니다. codex가 비슷한 작업에 Opus보다 4배나 더 걸릴 때도 있지만, 고친 걸 다시 고칠 필요가 없어서 결과적으로는 제가 더 빠를 때가 많습니다. Claude Code를 쓸 때는 이런 일이 꽤 흔했거든요.
또한 codex 덕분에 Claude Code 시절에 필요했던 온갖 "눈치 게임(charades)"을 안 해도 됩니다. "플랜 모드(plan mode)" 대신, 그냥 모델과 대화를 시작해서 질문하고, 검색하게 하고, 코드를 탐색하고, 같이 계획을 짭니다. 그리고 결과가 마음에 들면 "빌드해(build)" 또는 "계획을 docs/*.md에 쓰고 빌드해"라고 씁니다. 플랜 모드는 프롬프트를 잘 따르지 못하는 구세대 모델들을 위해 편집 도구를 뺏어야 했던 시절의 임시방편(hack)처럼 느껴집니다. 아직도 돌아다니는 제 오해받은 트윗이 하나 있는데, 그걸 보면 대부분의 사람들이 플랜 모드가 마법이 아니라는 걸 이해하지 못하는 것 같습니다.
오라클 (Oracle)
GPT 5/5.1에서 5.2로의 도약은 엄청났습니다. 저는 약 한 달 전에 oracle 🧿을 만들었습니다. 에이전트가 GPT 5 Pro를 실행하고 파일과 프롬프트를 업로드하며 세션을 관리해서 나중에 답변을 다시 가져올 수 있게 해주는 CLI입니다. 에이전트가 막혔을 때 모든 내용을 마크다운 파일에 쓰라고 한 뒤 제가 직접 쿼리를 날리는 게 반복적인 시간 낭비처럼 느껴졌거든요. 루프를 닫을 기회이기도 했고요. 사용법은 제 전역 AGENTS.MD 파일에 있고, 모델은 막히면 알아서 오라클을 호출하기도 했습니다. 하루에도 몇 번씩 사용했죠. 엄청난 발전이었습니다. Pro 모델은 50여 개의 웹사이트를 순식간에 훑어보고(speedrun) 정말 깊게 생각해서 거의 모든 경우에 완벽한 답변을 내놓습니다. 10분 만에 끝날 때도 있지만, 1시간 넘게 걸린 적도 있습니다.
이제 GPT 5.2가 나왔으니 오라클이 필요한 상황이 훨씬 줄었습니다. 연구 목적으로 제가 직접 Pro를 쓰긴 하지만, 모델에게 "오라클한테 물어봐"라고 시키는 경우는 하루에 여러 번에서 일주일에 몇 번으로 줄었습니다. 아쉽지는 않습니다. 오라클을 만드는 건 정말 재밌었고, 브라우저 자동화나 Windows에 대해 많이 배웠으며, 오랫동안 무시했던 '스킬(skills)' 개념을 제대로 들여다볼 시간을 가졌으니까요. 이건 5.2 버전이 실전 코딩 작업에서 얼마나 더 좋아졌는지를 보여줍니다. 제가 던지는 거의 모든 걸 원샷(one-shot)으로 해결합니다.
또 다른 엄청난 이점은 지식 단절(knowledge cutoff) 시점입니다. GPT 5.2는 8월 말까지인 반면, Opus는 3월 중순에 머물러 있습니다. 약 5개월 차이죠. 최신 도구를 사용하고 싶을 때 이 차이는 큽니다.
구체적인 예시: VibeTunnel
모델이 얼마나 발전했는지 보여주는 또 다른 예시가 있습니다. 제 초기 집중 프로젝트 중 하나인 VibeTunnel입니다. 이동 중에도 코딩할 수 있게 해주는 터미널 멀티플렉서죠. 올해 초에 거의 모든 시간을 여기에 쏟아부었고, 2개월 후에는 친구들과 외출 중에도 폰으로 코딩하는 제 자신을 발견할 정도로 좋아졌습니다... 정신 건강을 위해 그만둬야겠다고 결심했죠. 당시 저는 멀티플렉서의 핵심 부분을 TypeScript에서 다른 언어로 재작성하려고 했는데, 구형 모델들은 계속 실패했습니다. Rust, Go... 심지어 Zig도 시도해봤죠. 물론 제가 직접 완성할 수도 있었겠지만, 수작업이 많이 필요할 것 같아서 묻어두고 완료하지 못했습니다. 지난주에 먼지를 털어내고 codex에게 전체 포워딩 시스템을 Zig로 변환하라는 두 문장짜리 프롬프트를 줬는데, 5시간 넘게 돌아가며 여러 번의 압축(compaction) 과정을 거치더니 작동하는 변환 코드를 한 번에 내놓았습니다.
왜 다시 꺼냈냐고요? 제 현재 관심사는 제 모든 컴퓨터, 메시지, 이메일, 홈 오토메이션, 카메라, 조명, 음악, 심지어 침대 온도까지 제어할 수 있는 AI 비서 Clawdis입니다. 물론 자기 목소리도 있고, 트윗을 날리는 CLI와 전용 clawd.bot도 있습니다.
Clawd는 제 화면을 보고 제어할 수 있으며 가끔 비꼬는 말도 합니다. 저는 이 녀석에게 제 에이전트들을 감시하는 능력도 주고 싶었습니다. 이미지보다 문자 스트림을 얻는 게 훨씬 효율적이니까요... 잘 될지는 두고 봐야겠죠!
나의 워크플로우 (My Workflow)
압니다... 더 빨리 개발하는 법을 배우러 오셨는데 제가 OpenAI 마케팅만 하고 있다는 거요. Anthropic이 Opus 5를 준비해서 다시 전세가 역전되기를 바랍니다. 경쟁은 좋은 거니까요! 동시에 저는 범용 모델로서 Opus를 사랑합니다. 제 AI 에이전트는 GPT 5에서 돌렸다면 절반도 재미없었을 겁니다. Opus는 함께 일하기 즐겁게 만드는 특별한 무언가가 있습니다. 저는 대부분의 컴퓨터 자동화 작업에 Opus를 쓰고 있고, 물론 Clawd🦞도 Opus 기반입니다.
제 워크플로우는 지난 10월에 썼던 글과 크게 다르지 않습니다.
저는 보통 동시에 여러 프로젝트를 진행합니다. 복잡도에 따라 3개에서 8개 사이입니다. 컨텍스트 전환(context switching)이 피곤할 수 있어서, 집에서 조용히 집중할 수 있을 때만 이렇게 합니다. 머릿속에서 굴려야 할 멘탈 모델이 많으니까요. 다행히 대부분의 소프트웨어는 지루합니다. 음식 배달을 확인하는 CLI를 만드는 건 별로 생각을 요하지 않죠. 보통 제 집중력은 하나의 큰 프로젝트에 쏠려 있고, 위성 프로젝트들은 그냥 굴러갑니다(chug along). 에이전트 엔지니어링을 충분히 하다 보면 뭐가 쉬울지, 어디서 모델이 헤맬지 감이 옵니다. 그래서 보통 프롬프트 하나 던져두면 codex가 30분 동안 알아서 하고, 저는 필요한 걸 얻습니다. 가끔 조작이나 창의성이 필요할 때도 있지만, 보통은 직관적입니다.
저는 codex의 대기열(queueing) 기능을 광범위하게 사용합니다. 새로운 아이디어가 떠오르면 파이프라인에 추가합니다. 많은 분들이 다중 에이전트 오케스트레이션, 이메일 또는 자동 작업 관리 시스템 등을 실험하는 걸 보는데, 아직까지는 그런 것들의 필요성을 못 느낍니다. 보통 병목은 저니까요. 제 소프트웨어 개발 방식은 매우 반복적(iterative)입니다. 무언가 만들고, 가지고 놀아보고, "느낌"이 어떤지 본 다음, 다듬을 새로운 아이디어를 얻습니다. 머릿속에 완성된 그림을 가지고 있는 경우는 드뭅니다. 물론 대략적인 아이디어는 있지만, 문제 영역을 탐색하면서 급격하게 바뀌곤 합니다. 그래서 완성된 아이디어를 입력으로 받아 결과를 내놓는 시스템은 저랑 잘 맞지 않습니다. 저는 직접 가지고 놀고, 만지고, 느끼고, 봐야 합니다. 그게 제가 발전시키는 방식입니다.
저는 체크포인트(checkpointing)를 쓰거나 되돌리는(revert) 일이 거의 없습니다. 마음에 안 들면 모델에게 바꾸라고 합니다. codex가 가끔 파일을 리셋하기도 하지만, 보통은 편집 내용을 되돌리거나 수정합니다. 완전히 뒤로 돌아가야 하는 경우는 드물고, 대신 그냥 다른 방향으로 나아갑니다. 소프트웨어를 만드는 건 산을 오르는 것과 같습니다. 직선으로 올라가는 게 아니라, 빙글빙글 돌고, 방향을 틀고, 가끔 경로를 이탈해서 조금 돌아가기도 하지만, 불완전해도 결국엔 필요한 곳에 도달합니다.
저는 그냥 main 브랜치에 커밋합니다. 가끔 codex가 너무 지저분하다고 판단해서 자동으로 워크트리(worktree)를 만들고 변경 사항을 병합(merge)하기도 하지만, 드문 일이고 제가 특별한 경우에만 그렇게 시킵니다. 프로젝트의 여러 상태를 생각해야 하는 인지적 부하가 불필요하다고 느끼며, 선형적으로 발전시키는 걸 선호합니다. 더 큰 작업은 제가 딴짓할 때를 위해 남겨둡니다. 예를 들어 이 글을 쓰는 동안 4개 프로젝트의 리팩터링을 돌려놨는데, 각각 1~2시간 정도 걸릴 겁니다. 물론 워크트리에서 할 수도 있지만, 그러면 병합 충돌만 많아지고 리팩터링 결과도 별로일 겁니다. 주의: 저는 주로 혼자 일합니다. 큰 팀에서 일한다면 이 워크플로우는 당연히 안 먹힐 겁니다.
기능을 계획하는 방식은 이미 언급했습니다. 저는 프로젝트 간 상호 참조를 자주 합니다. 특히 다른 곳에서 이미 해결한 문제라면, codex에게 ../project-folder를 보라고 하면 문맥상 어디를 봐야 할지 추론하기에 충분합니다. 프롬프트를 아끼는 데 매우 유용합니다. 그냥 "../vibetunnel 보고 Sparkle 변경 로그에도 똑같이 해"라고 쓰면 됩니다. 거기서 이미 해결된 문제니까 99%의 확률로 올바르게 복사해서 새 프로젝트에 맞춰 적용합니다. 새 프로젝트의 스캐폴딩(scaffolding)도 이런 식으로 합니다.
과거 세션을 참조하고 싶어 하는 시스템들을 많이 봤습니다. 제가 절대 필요 없거나 안 쓰는 기능 중 하나입니다. 저는 각 프로젝트의 docs 폴더에 하위 시스템과 기능에 대한 문서를 유지 관리하고, 스크립트와 글로벌 AGENTS 파일의 지침을 통해 모델이 특정 주제에 대한 문서를 강제로 읽게 합니다. 프로젝트가 클수록 효과가 좋아서 모든 곳에 쓰지는 않지만, 문서를 최신 상태로 유지하고 작업의 컨텍스트를 더 잘 설계하는 데 큰 도움이 됩니다.
컨텍스트 얘기가 나와서 말인데, 예전에는 새 작업을 할 때마다 세션을 재시작하려고 엄청 신경 썼습니다. GPT 5.2에서는 더 이상 그럴 필요가 없습니다. 컨텍스트가 꽉 차 있어도 성능이 매우 좋고, 이미 많은 파일을 로드한 상태라 오히려 속도에 도움이 되기도 합니다. 물론 작업들을 직렬화(serialize)하거나 두 세션이 서로 많이 겹치지 않도록 변경 사항들의 거리를 둬야 잘 작동합니다. codex는 claude code와 달리 "이 파일이 변경됨" 같은 시스템 이벤트가 없어서 좀 더 조심해야 하지만, 반대로 codex는 컨텍스트 관리를 훨씬 더 잘합니다. codex 세션 하나에서 claude보다 5배는 더 많은 일을 하는 느낌입니다. 객관적으로 더 큰 컨텍스트 크기 때문만은 아니고, 다른 요인이 있습니다. 제 추측으로는 codex는 토큰을 아끼기 위해 내부적으로 정말 압축해서 생각하는 반면, Opus는 말이 많습니다(wordy). 가끔 모델이 실수를 해서 내부 생각 스트림이 사용자에게 유출될 때가 있는데, 꽤 여러 번 봤습니다. 정말이지 codex의 화법은 묘하게 재미있습니다.
프롬프트. 예전에는 음성 받아쓰기로 길고 정교한 프롬프트를 작성했습니다. codex를 쓰면서 프롬프트가 훨씬 짧아졌고, 다시 타이핑을 자주 하며, 특히 UI를 반복 수정하거나(CLI 텍스트 문구 포함) 할 때 이미지를 많이 첨부합니다. 모델에게 뭐가 잘못됐는지 보여주면, 몇 단어만으로도 원하는 걸 얻을 수 있습니다. 네, 저는 UI 컴포넌트를 캡처해서 "패딩 고쳐"나 "다시 디자인해"라고 던지는 그런 사람입니다. 그게 문제를 해결해주거나 상당히 진척시켜 주거든요. 예전에는 마크다운 파일을 참조했지만, docs:list 스크립트 덕분에 더 이상 그럴 필요가 없습니다.
마크다운. 저는 자주 "docs/*.md에 문서 작성해"라고 쓰고 파일 이름은 모델이 알아서 정하게 둡니다. 모델이 훈련된 구조와 명확하게 일치하도록 설계할수록 작업이 쉬워집니다. 결국 저는 코드베이스를 제가 탐색하기 쉽게 설계하는 게 아니라, 에이전트가 효율적으로 작업할 수 있도록 엔지니어링합니다. 모델과 싸우는 건 시간과 토큰 낭비일 때가 많습니다.
도구 및 인프라 (Tooling & Infrastructure)
여전히 어려운 점은 무엇일까요? 적절한 의존성과 프레임워크를 선택하는 건 제가 꽤 시간을 투자하는 부분입니다. 유지보수는 잘 되는지? 피어 의존성(peer dependencies)은 어떤지? 인기가 있어서 에이전트가 쉽게 다룰 만큼 세상의 지식(world knowledge)이 충분한지? 시스템 설계도 마찬가지입니다. 웹 소켓으로 통신할까? HTML? 서버에는 뭘 넣고 클라이언트에는 뭘 넣지? 데이터 흐름은 어떻게 되지? 이런 것들은 모델에게 설명하기 좀 더 어렵고, 연구와 사고가 빛을 발하는 영역입니다.
저는 많은 프로젝트를 관리하기 때문에, 종종 에이전트를 프로젝트 폴더에서 실행하고 제가 새로운 패턴을 알아내면 "내 최근 go 프로젝트 다 찾아서 이 변경 사항 구현하고 + 변경 로그 업데이트해"라고 요청합니다. 각 프로젝트 파일의 패치 버전이 올라가 있고, 제가 나중에 다시 방문하면 테스트할 개선 사항들이 이미 기다리고 있죠.
물론 저는 모든 것을 자동화합니다. 도메인을 등록하고 DNS를 변경하는 스킬도 있습니다. 좋은 프론트엔드를 작성하는 스킬도 있고요. 제 AGENTS 파일에는 제 Tailscale 네트워크에 대한 노트가 있어서 "내 Mac Studio로 가서 xxx 업데이트해"라고 말만 하면 됩니다.
Mac 여러 대 얘기가 나왔으니 말인데, 저는 보통 두 대의 Mac으로 일합니다. 큰 화면에는 MacBook Pro, 다른 화면에는 Mac Studio에 연결된 Jump Desktop 세션을 띄워둡니다. 어떤 프로젝트는 저기서, 어떤 건 여기서 굴러갑니다. 가끔 같은 프로젝트의 다른 부분을 각 머신에서 편집하고 git으로 동기화합니다. 워크트리보다 간단한 게 main의 변경 사항을 조정하기 쉽거든요. UI나 브라우저 자동화가 필요한 작업은 Studio로 옮겨서 팝업으로 방해받지 않을 수 있다는 장점도 있습니다. (네, Playwright에 헤드리스 모드가 있지만 안 먹히는 상황이 꽤 있거든요.)
또 다른 장점은 작업이 거기서 계속 실행된다는 겁니다. 여행을 가면 원격 접속이 제 메인 작업대가 되고, Mac을 덮어도 작업은 계속 돌아갑니다. 과거에 codex나 Cursor web 같은 진짜 비동기 에이전트를 실험해봤지만, 조향성(steerability)이 아쉬웠고 결국 작업이 풀 리퀘스트(PR)로 끝나서 제 설정에 복잡함만 더했습니다. 저는 터미널의 단순함을 훨씬 선호합니다.
슬래시 커맨드(/)도 써봤지만 별로 유용하지 않았습니다. 스킬(skills)이 그중 일부를 대체했고, 나머지는 그냥 "commit/push"라고 씁니다. /commit이랑 시간 차이도 안 나고 항상 잘 작동하니까요.
예전에는 날 잡고 프로젝트 리팩터링이나 정리를 했지만, 지금은 훨씬 즉흥적으로(ad-hoc) 합니다. 프롬프트가 너무 오래 걸리거나 코드 스트림에서 못생긴 게 지나가는 게 보이면 바로 처리합니다.
Linear나 다른 이슈 트래커도 써봤지만 정착한 건 없습니다. 중요한 아이디어는 바로 시도하고, 나머지는 기억하거나 중요하지 않은 겁니다. 물론 오픈 소스 사용자를 위한 공개 버그 트래커는 있지만, 버그를 찾으면 바로 프롬프트에 넣습니다. 적어놨다가 나중에 다시 컨텍스트를 전환하는 것보다 훨씬 빠르니까요.
무엇을 만들든, 모델과 CLI로 먼저 시작하세요. 오랫동안 유튜브 영상을 요약하는 크롬 확장 프로그램 아이디어를 가지고 있었습니다. 지난주에 무엇이든 마크다운으로 변환해서 모델에게 요약시키는 CLI인 summarize 작업을 시작했습니다. 먼저 핵심을 제대로 만든 뒤, 그게 잘 작동하자 하루 만에 전체 확장 프로그램을 만들었습니다. 꽤 마음에 듭니다. 로컬, 무료, 유료 모델 다 돌아갑니다. 비디오나 오디오를 로컬에서 전사(transcribe)합니다. 로컬 데몬과 통신해서 엄청 빠릅니다. 한번 써보세요!
제가 주로 쓰는 모델은 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 컨텍스트 윈도우 근처에서 네이티브 압축(compaction)을 위한 공간 확보.
# 공식: 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"
이렇게 하면 모델이 한 번에 더 많이 읽을 수 있습니다. 기본값은 좀 작아서 모델이 보는 걸 제한할 수 있거든요. 조용히 실패하는데, 이건 정말 골치 아프고 언젠가 고쳐지겠죠. 그리고 웹 검색이 아직도 기본으로 안 켜져 있다고요? unified_exec은 tmux와 제 옛날 러너 스크립트를 대체했고, 나머지도 깔끔합니다. 그리고 압축(compaction)을 절대 겁내지 마세요. OpenAI가 새로운 /compact 엔드포인트로 전환한 이후로, 작업이 여러 번의 압축을 거쳐도 완료될 만큼 잘 작동합니다. 속도는 좀 느려지지만, 종종 검토(review) 같은 역할을 해서 모델이 코드를 다시 볼 때 버그를 찾아내기도 합니다.
일단은 여기까지입니다. 다시 글을 좀 더 쓸 계획이고 머릿속에 아이디어 백로그가 꽤 쌓여 있는데, 그냥 뭐 만드는 게 너무 재밌어서 탈이네요. 이 새로운 세상에서 어떻게 개발할지에 대한 횡설수설과 아이디어를 더 듣고 싶다면 트위터에서 저를 팔로우하세요.