하루에 13개 저장소를 건드린 날

2026년 3월 11일 수요일. 나중에 로그를 세어 보니 이날 하루 동안 13개 저장소에서 333개의 프롬프트를 날렸습니다. Claude Code에 177개, Codex에 48개, opencode에 108개. 계획하고 한 게 아닙니다. 아침에 떠오른 서비스 아이디어 하나를 그날 안에 배포하겠다고 달리다 보니, 굴리던 다른 프로젝트들이 전부 그 틈새로 밀려들어온 결과였습니다.

이 숫자를 정확히 알 수 있는 건 Oh My Prompt가 모든 에이전트에 훅으로 붙어서 프롬프트를 SQLite에 쌓고 있기 때문입니다. 이 글의 시각과 인용은 전부 그 DB와 각 저장소의 git log에서 꺼낸 것입니다. 그래서 이 글은 “AI로 생산성이 몇 배가 됐다”는 이야기가 아니라, 그 날 실제로 무슨 일이 있었는지에 대한 기록에 가깝습니다. 부풀려진 숫자가 어디서 나오는지도 포함해서요.

11시 36분, 아이디어

이날의 축은 새 프로젝트였습니다. 카카오톡 대화 내보내기(.zip)를 올리면 대화 상대의 페르소나와 관계를 분석해 주는 서비스. 나중에 tokka라는 이름이 붙습니다.

11:36에 Claude Code에 첫 프롬프트를 던졌습니다. 그 전에 만들어 둔 페르소나 제작 파이프라인을 웹서비스로 바꾸고 싶다는 내용이었습니다. 이후의 흐름을 로그와 커밋에서 그대로 옮기면 이렇습니다.

11:36  첫 프롬프트 — 페르소나 분석을 웹서비스로
13:27  카톡의 "대화 이메일로 내보내기"와 연동하는 방안 논의
13:49  서비스 이름 고민 (SNS 마케팅 관점 리뷰까지 시킴)
14:43  initial commit
15:37  도메인 확정, 배포 (커밋: rename persona.jiun.dev → tokka.jiun.dev)
15:52  라이트 테마 + 모바일 우선으로 UI 재설계
16:05  데모 데이터 교체

16:05의 데모 데이터 교체는 따로 적어둘 만합니다. 개발 중에 쓰던 데모가 실제 지인과의 대화였는데, 랜딩 페이지에 그대로 노출되고 있었습니다. 배포 직전에 발견해서 Claude와 Codex가 대화하는 가상 데이터로 갈아치웠습니다. 커밋 메시지가 replace personal demo data with Claude vs Codex fictional data입니다. 개인 대화를 다루는 서비스를 만들면서 정작 내 데모 데이터로 남의 대화를 흘릴 뻔한 거죠.

아이디어에서 배포까지 약 4시간. 이날 tokka에만 40개의 커밋이 쌓였습니다.

저녁의 디버깅은 Codex가

배포가 끝나자 문제가 터지기 시작했고, 저녁부터는 Codex로 갈아탔습니다. 17:56부터 21:32까지 48개의 프롬프트가 거의 전부 tokka의 배포-장애-수정 사이클입니다.

18:23  "persona, 관계, sns 페이지가 아무것도 보이지않습니다"
18:41  AI 분석 404 — 모델명이 지원 목록에 없다는 에러
18:50  "gemini-3.1-flash-lite-preview를 사용하고 2.5-flash-lite를 fallback으로"
18:57  "No module named 'google.api_core'" — 이미지에 의존성 누락
19:01  "재배포될때 db가 모두 날아가나요?"

19:01의 질문이 뼈아픈 부분입니다. 급하게 만든 서비스라 데이터가 컨테이너 안에 있었고, 재배포마다 날아가고 있었습니다. 그 자리에서 Postgres로 메타데이터를 옮기고 Redis로 큐를 잡는 작업이 이어졌습니다.

이날 가장 사람 냄새 나는 프롬프트는 19:41에 나왔습니다. Codex가 묻지도 않은 Cloudflare Worker를 이메일 수신 경로에 끼워 넣었길래 왜 필요하냐고 물었더니 남 일처럼 설명을 하더군요. 그래서 이렇게 쳤습니다.

“아니 니가 했잖아 왜 추가했냐고”

결국 “worker 부분 모두 삭제하고 원래대로 돌려놓고 제대로 분석해서”라는 프롬프트로 되돌렸습니다. 에이전트가 빠른 만큼, 안 시킨 일을 벌이는 속도도 빠릅니다.

그 틈에 굴러간 나머지 12개

tokka가 빌드되고 배포되는 동안 손이 비니까, 그 사이사이에 다른 프로젝트를 밀었습니다. 15시부터 17시 사이 Claude Code 로그에는 jiun-api의 ArgoCD 자동 싱크가 왜 안 되는지 추적하는 세션, IaC의 monitoring 앱이 언제 추가됐는지 확인하는 세션, agt 스킬 매니저의 페르소나 설치 버그를 고치는 세션, 블로그에 서비스 랜딩 페이지를 만드는 세션이 섞여 있습니다.

nova-pouch에서는 아키텍처 논쟁도 했습니다. 기록 공유 URL을 어디서 서빙할지 이야기하다가 Claude가 jiun-api에 기능을 얹는 쪽으로 가길래, “전제가 잘못되었습니다. record 데이터의 오너십이 nova-pouch로 옮겨와야 합니다. jiun-api는 로그인만 전담하는 게 좋겠습니다”라고 방향을 다시 잡았습니다. 에이전트가 코드를 쓰는 동안 사람이 할 일은 이런 경계 설정이라는 걸 이날 여러 번 느꼈습니다.

피크는 17시대였습니다. 이 한 시간 동안 9개 프로젝트에서 82개의 프롬프트가 기록되어 있습니다. tokka의 AdSense 검수 대응, nova-pouch의 Cloudflare 터널 수정, aily의 PR 머지, 블로그의 프로젝트 링크 연결, IaC와 jiun-api의 GitOps 점검이 전부 이 시간대에 겹쳐 있습니다.

밤에는 인프라 문제가 몰렸습니다. 21:07 clawdia(디스코드 봇)의 헬스체크 실패 점검, 21:09 홈랩 dev-tool 서버의 디스크 용량 부족, 21:26 aily 저장소만 Gitea webhook이 안 걸려 있어서 배포가 누락되던 문제. 그리고 21:13, Codex가 jiun-api의 CORS 허용 목록에 tokka 도메인을 추가하는 커밋을 올렸습니다. 새 서비스 하나를 띄우면 게이트웨이, IaC, ArgoCD까지 연쇄적으로 손대야 하는 구조라서, 이날의 “13개 저장소”는 상당 부분 이 연쇄의 결과입니다.

세 번째 에이전트, 그리고 부풀려지는 숫자

여기까지가 Claude Code와 Codex의 이야기이고, 사실 이날 프롬프트 수가 가장 많이 찍힌 축은 따로 있습니다. opencode로 twee-do, wow-3d, burstpick 같은 게임·사이드 프로젝트 4개를 백그라운드에서 돌리고 있었거든요. 108개의 프롬프트가 기록됐습니다.

그런데 이 108개를 열어 보면 83개가 사람이 친 게 아닙니다. [search-mode] MAXIMIZE SEARCH EFFORT...로 시작하는 오케스트레이션 템플릿, 백그라운드 에이전트에 뿌려지는 1. TASK: ... 지시문, 작업 완료 알림 같은 자동 생성 메시지들입니다. 제가 직접 타이핑한 건 “go starts implementations”, “pull from remote” 수준의 25개뿐이었습니다.

그러니까 “하루 333개 인터랙션”이라는 숫자는 절반쯤 과장입니다. 에이전트 워크플로우의 통계는 자동화 계층이 낀 만큼 부풀려지고, 캡처 시스템을 만들어 둔 저조차 세어 보기 전에는 저 83개를 제 작업량으로 착각하고 있었습니다. AI 생산성 이야기에 붙는 숫자들은 대체로 이런 식으로 커진다고 생각합니다.

역할 분담은 설계가 아니라 결과였다

로그를 보면 세 에이전트의 용도가 꽤 뚜렷하게 갈립니다. Claude Code는 아키텍처 논의, 인프라 추적, 저장소를 넘나드는 작업에 썼고, Codex는 배포하고 터지고 고치는 사이클에 썼고, opencode는 당장 급하지 않은 프로젝트를 백그라운드에서 진행시키는 데 썼습니다.

다만 이건 어느 날 정해 놓은 분담이 아니라 쓰다 보니 굳은 습관에 가깝습니다. Codex 설정에 model_reasoning_effort = "xhigh"와 personality = "pragmatic"을 걸어 둔 것도, 오래 고민하지 말고 실행부터 하는 성격이 배포 사이클에 맞아서였습니다. 이날 “커밋”, “푸시”가 들어간 지시가 21번 기록되어 있는데, 대부분 Codex 쪽입니다. GitHub에 푸시하면 Gitea 미러 → Gitea Actions → IaC 업데이트 → ArgoCD 싱크로 이어지는 파이프라인이 깔려 있어서, “커밋 푸시해서 배포합시다” 한 줄이 실제 배포 명령이 됩니다.

숫자로 보는 하루

이 방식의 비용

솔직히 지속 가능한 하루였는지는 모르겠습니다.

머릿속 컨텍스트는 에이전트처럼 즉시 전환되지 않습니다. tokka의 모델 404를 디버깅하다가 IaC 디스크 용량으로 넘어갔다 돌아오면, “아까 fallback 어디까지 했더라”부터 다시 시작합니다. 에이전트가 일하는 동안 다른 프로젝트를 볼 수 있다는 게 이 워크플로우의 장점인데, 그 장점을 쓸수록 스위칭 비용을 내는 건 사람입니다.

깊이도 문제입니다. 이날 tokka에 인터랙션의 43%가 몰렸지만, 그 내용은 대부분 “고쳐라, 배포해라, 확인해라”였습니다. 재배포하면 DB가 날아가는 구조로 일단 배포부터 한 게 그 증거입니다. 빠르게 띄우는 것과 제대로 만드는 것 사이에서 이날은 명백히 전자를 골랐고, 그 청구서는 며칠에 걸쳐 나눠 냈습니다.

그래도 이날의 로그가 남아 있어서 이 글을 쓸 수 있었습니다. 11:36의 아이디어가 15:37에 도메인을 달고, 19:41에 “아니 니가 했잖아”를 치고, 21:13에 CORS 커밋으로 다른 저장소에 번지는 과정이 전부 타임스탬프와 함께 남아 있습니다. 하루를 이렇게 재구성할 수 있다는 것 자체가, 이 워크플로우에서 제일 마음에 드는 부분입니다.