하루에 8개 프로젝트를 AI와 동시에 개발한 이야기

들어가며

3월 11일 화요일, 보통의 하루였습니다. 하지만 나중에 세션 로그를 살펴보니 하루 동안 8개 프로젝트에서 총 149번의 AI 인터랙션을 수행했더군요. Claude Code에서 100번, Codex에서 49번. 이건 계획된 것이 아니었습니다. 여러 서비스를 동시에 운영하다 보니 자연스럽게 이렇게 된 거죠.

이 글은 “나는 이렇게 대단하다”가 아닙니다. AI 코딩 에이전트 시대에 1인 개발자의 워크플로우가 어떻게 바뀌고 있는지, 실제 세션 데이터를 기반으로 공유하려 합니다.

그날의 타임라인

Oh My Prompt가 모든 프롬프트를 자동으로 캡처하고 있었기 때문에, 하루의 작업을 정확하게 재구성할 수 있었습니다.

오전: 기능 개발 러시

08:36 - kakao-persona  : UI 개선, 멀티 포맷 파일 업로드 지원
08:49 - aily           : PR 머지, 웹 페이지 리파인먼트
08:50 - nova-pouch     : Cloudflare 터널 수정
08:51 - jiunbae.github.io : 프로젝트 간 문서 교차 링크
09:05 - oh-my-prompt   : 사용법 문서화
09:10 - jiun-api       : ArgoCD 자동 싱크 설정
09:12 - IaC            : 인프라 관리

7개 프로젝트가 1시간 안에 터치되었습니다. 이건 미친 짓이 아닙니다. 각 프로젝트에서 필요한 작업이 서로 연결되어 있었기 때문이에요.

오후: 디버깅과 배포의 연쇄

Codex 쪽 세션을 보면 더 흥미롭습니다:

09:01 - kakao-persona  : "개인정보 처리에 대해 동의를 받아야할것같습니다"
09:11 - kakao-persona  : 비밀번호 보여주는 경고 페이지 필요
09:23 - kakao-persona  : "persona, 관계, SNS 페이지가 아무것도 보이지않습니다"
09:35 - kakao-persona  : "AI 관계 분석 생성 실패 - gemini-3.1-flash-lite is not found"
11:01 - kakao-persona  : "No module named 'google.api_core'"

하나의 서비스를 배포하고, 문제가 생기고, 고치고, 다시 배포하는 사이클이 계속 반복됩니다. 그 사이에 다른 프로젝트의 이슈도 함께 처리하고요.

저녁: 인프라 전쟁

15:03 - clawdia        : Docker 헬스체크 실패 조사
18:44 - clawdia        : jiun-mini 서버 docker 명령어 못 찾는 문제
21:20 - nova-pouch     : 공유 URL 라우팅 설계
21:30 - jiunbae.github.io : 문서 업데이트
21:36 - IaC            : dev-tool 서버 용량 부족 해결
21:50 - aily           : Gitea webhook 미등록 → ArgoCD 배포 안 됨

두 개의 AI, 두 개의 역할

이날 가장 흥미로운 패턴은 Claude Code와 Codex를 서로 다른 용도로 사용했다는 점입니다.

Claude Code (Opus) — 아키텍처와 탐색

Claude Code는 주로 다음과 같은 작업에 사용했습니다:

• 코드 리뷰와 리팩토링: 기존 코드베이스를 분석하고 개선
• 인프라 디버깅: K8s 팟 상태 확인, ArgoCD 싱크 문제 추적
• 크로스 프로젝트 작업: 여러 레포를 오가며 문서 교차 링크

54개의 커스텀 스킬이 설치되어 있어서, “보안 점검해줘”라고 하면 security-auditor 스킬이 자동 활성화되고, “배포해줘”라고 하면 git-commit-pr 스킬이 동작합니다.

Codex (GPT-5.4) — 빠른 실행과 디버깅

Codex는 다른 성격의 작업에 투입했습니다:

model = "gpt-5.4"
model_reasoning_effort = "xhigh"
personality = "pragmatic"

• 빌드 에러 해결: TypeScript 컴파일 에러, Docker 빌드 실패
• 빠른 기능 구현: OAuth 로그인, 파일 포맷 지원 추가
• 배포 사이클: “커밋 푸시해서 배포합시다” — 이 문구가 하루에 5번 이상 등장

Codex의 pragmatic 퍼스널리티 설정이 이런 작업에 잘 맞았습니다. 오래 고민하지 않고 빠르게 실행하는 성격이에요.

프로젝트 간 연결고리

8개 프로젝트가 제각각 따로 돌아가는 게 아닙니다. 하나의 에코시스템을 이루고 있었어요.

kakao-persona (서비스)
    ↓ 배포
jiun-api (API 게이트웨이)
    ↓ GitOps
IaC (인프라 코드)
    ↓ ArgoCD
K8s 클러스터
    ↑ 모니터링
aily (AI 세션 브릿지)
    ↑ 디스코드 알림
clawdia (디스코드 봇)

kakao-persona를 배포하려면 jiun-api의 CORS 설정이 필요하고, 배포 파이프라인은 IaC 레포를 거치고, 모니터링은 aily와 clawdia가 담당합니다. 하나를 건드리면 연쇄적으로 다른 것들도 손봐야 하는 구조죠.

이 워크플로우를 가능하게 하는 것들

1. Oh My Prompt — 자동 프롬프트 캡처

모든 AI 인터랙션이 자동으로 기록됩니다. 덕분에 “어제 그 프로젝트에서 뭘 했더라?”를 데이터로 답할 수 있어요. Claude Code와 Codex 모두 훅이 설치되어 있어서, 프롬프트를 쓰는 순간 SQLite에 저장되고 서버로 싱크됩니다.

에이전트 사용 → 훅 트리거 → omp ingest → SQLite → 서버 싱크

2. agt — 에이전트 스킬 매니저

agt로 54개의 커스텀 스킬을 관리합니다. agt skill install --profile core 한 번이면 필수 스킬 7개가 설치되고, 7명의 리뷰어 페르소나도 agt persona install -g --all로 한 번에 적용됩니다.

3. GitOps 파이프라인

GitHub → Gitea mirror → Gitea Actions → IaC 업데이트 → ArgoCD 싱크. “커밋 푸시”만 하면 서비스가 자동 배포됩니다. 이게 없었으면 8개 프로젝트를 하루에 관리하는 건 불가능했을 겁니다.

4. 18개 Trusted 프로젝트

Codex의 config.toml에 18개 프로젝트가 trusted로 등록되어 있습니다. 매번 권한 확인 없이 바로 작업에 들어갈 수 있어요.

숫자로 보는 하루

이 방식의 한계

솔직히 말하면, 이건 지속 가능한 방식이 아닐 수도 있습니다.

컨텍스트 스위칭 비용: AI가 코드를 작성하는 동안 다른 프로젝트로 전환할 수 있지만, 머릿속의 컨텍스트는 AI처럼 즉시 전환되지 않습니다. kakao-persona의 Gemini API 에러를 디버깅하다가 갑자기 IaC의 용량 문제로 넘어가면, 돌아왔을 때 “아, 뭐 하고 있었지?” 하는 순간이 생깁니다.

깊이 vs 넓이: 8개 프로젝트를 동시에 진행하면 각각에 투입되는 시간이 줄어들 수밖에 없습니다. kakao-persona에 30%의 인터랙션이 집중되었지만, 그래봐야 30번이에요. 깊은 아키텍처 작업보다는 빠른 수정과 배포 위주가 됩니다.

의존성 지옥: 프로젝트 간 연결이 많을수록 하나의 변경이 연쇄 작업을 유발합니다. 이날도 kakao-persona 배포 때문에 jiun-api, IaC, ArgoCD까지 건드려야 했죠.

마치며

AI 코딩 에이전트는 개발자의 처리량을 늘려줍니다. 하지만 그것은 “더 많은 프로젝트를 동시에”가 아니라, “각 프로젝트에서 더 빠르게”에 가깝습니다. 8개 프로젝트를 하루에 건드린 건 워크플로우의 성과이기도 하지만, 동시에 에코시스템의 복잡성이 만들어낸 필연이기도 합니다.

진짜 중요한 건 AI 인터랙션 숫자가 아닙니다. 그 인터랙션들이 기록되고, 분석되고, 다음 날의 작업을 더 나은 방향으로 이끌어주는 시스템이 있느냐는 거죠. Oh My Prompt로 프롬프트를 캡처하고, agt로 스킬을 관리하고, GitOps로 배포를 자동화하는 — 이 인프라가 없었다면 8개 프로젝트는 그냥 8개의 혼란이었을 겁니다.

내일도 비슷한 하루가 될 겁니다. 하지만 오늘의 로그가 있으니, 내일은 조금 더 나은 프롬프트를 쓸 수 있겠죠.