개요
이 글은 2025년 7월 기준으로, 저자가 어떻게 여러 AI 에이전트(특히 claude code, o3, sonnet 4 등)를 조합해 개인용 AI 팩토리를 구축하고, 이를 통해 코드 생산과 검증, 자기 개선까지 자동화하는 과정을 시간순으로 상세히 설명합니다. 저자는 여러 개의 claude code 창을 각각의 git-worktree에 띄워두고, 다양한 AI 모델을 조합해 계획 수립, 실행, 검증, 피드백의 루프를 돌립니다. 이 과정에서 팩토리 자체가 스스로 발전하도록 설계한 점이 핵심입니다.
"팩토리는 스스로를 개선합니다."
핵심 원칙 – 출력이 아니라 입력을 고쳐라
저자는 코드 생성에 문제가 생겼을 때, 결과물을 직접 수정하거나 AI와 논쟁하지 않습니다. 대신 계획, 프롬프트, 에이전트 조합 등 '입력'을 수정해서 다음 실행에서 처음부터 제대로 동작하도록 만듭니다.
"무언가 잘못되면, 생성된 코드를 손으로 고치지 않습니다. claude와 논쟁하지도 않아요. 대신 계획, 프롬프트, 에이전트 구성을 조정해서 다음 실행이 처음부터 제대로 되도록 합니다."
이 원칙은 게임 Factorio에서 영감을 받았습니다. Factorio처럼, AI 에이전트들이 스스로 코드를 만들고, 검증하고, 점점 더 나아지도록 AI 팩토리를 구축하는 것이 목표입니다.
일상적인 워크플로우 – 팩토리 만들기
저자의 주요 인터페이스는 claude code입니다. 여기에 Goose와 o3가 돌아가는 로컬 mcp도 사용합니다. Goose는 Azure OpenAI 구독에 연결되어 있어 편리하게 사용 중입니다.
1. 계획 수립
- 고수준의 작업을 claude code에 지시하면, claude code가 o3를 호출해 계획을 생성합니다.
- o3는 일을 명확히 하기 위해 여러 질문을 던지고, <task>-plan.md 파일에 원래 요청과 구현 계획을 정리합니다.
"o3는 좋은 플래너라서, 해야 할 일을 명확히 하기 위해 여러 질문을 던집니다."
2. 실행
- sonnet 4가 계획을 읽고 검증한 뒤, 작업 리스트로 변환합니다.
- claude code가 sonnet 3.7 또는 sonnet 4와 함께 계획을 실행합니다. (Clojure 작업이 많아 sonnet 4를 주로 사용)
- 중요한 점은, 각 작업 단계마다 claude가 커밋을 남기도록 지시한다는 것!
이렇게 하면 문제가 생겼을 때 언제든 이전 상태로 쉽게 되돌릴 수 있습니다.
"claude에게 각 작업 단계마다 커밋을 남기게 합니다. 이렇게 하면 문제가 생겼을 때 언제든 이전 상태로 돌아갈 수 있죠."
3. 검증 → 입력에 피드백
- 코드가 생성되면, sonnet 4가 계획과 대조해 검증합니다.
- 이어서 o3가 계획과 원래 요청 모두에 대해 코드 검증을 합니다.
- o3는 매우 엄격해서, 불필요한 코드나 'lint 무시 플래그' 같은 것도 지적합니다.
- 두 모델이 함께 검증하면, 문제를 더 잘 잡아내고, claude와의 불필요한 소모전을 줄일 수 있습니다.
"o3는 타협하지 않습니다. claude는 기쁘게 하려고 불필요한 하위 호환성 코드를 남기는데, o3는 그걸 지적하고 제거하라고 하죠."
- 발견된 모든 문제는 '계획 템플릿'에 반영되고, 코드 자체를 직접 고치지 않습니다.
"sonnet 4나 o3가 발견한 모든 문제는 계획 템플릿에 반영되고, 코드에서 직접 고치지 않습니다."
- 여러 git worktree를 활용해, 여러 claude code 인스턴스를 동시에 띄워 여러 기능을 병렬로 개발할 수 있습니다.
왜 입력이 출력보다 중요한가?
- 출력(코드)은 언제든 버릴 수 있지만, 계획과 프롬프트는 계속 쌓여서 발전합니다.
- 근본 원인에서 문제를 고치면, 앞으로의 모든 작업에 적용됩니다.
- 에이전트들이 단순한 코드 생성기가 아니라, 스스로 발전하는 동료가 됩니다.
"출력은 버릴 수 있지만, 계획과 프롬프트는 누적됩니다. 근본에서 고치면 앞으로 모든 작업에 적용되죠."
예를 들어, 한 에이전트가 CSV 전체를 메모리에 올리는 코드를 썼을 때, 저자는 스트리밍 방식으로 바꾸고, 'CSV는 항상 스트리밍으로 처리'라는 규칙을 계획에 추가했습니다. 이제는 계획 검사기가 이 규칙을 자동으로 체크해줍니다.
"이제 내 계획 검사기는 CSV를 스트리밍으로 처리하지 않는 코드를 자동으로 지적합니다. 매번 PR 리뷰에서 기억할 필요가 없죠. 팩토리가 스스로 발전합니다."
팩토리 확장하기
저자는 점점 더 복잡한 워크플로우를 만들고 있습니다.
- 특정 작업을 위한 전용 에이전트(MCP 뒤에 배치)를 두고, 예를 들어 Clojure 코드 전체를 훑어 스타일 규칙을 적용하는 에이전트도 있습니다.
- 내부 라이브러리 코드도 자동으로 개선합니다. 예를 들어, 직접 구현한 재시도 코드나
Thread/sleep을 사내 표준 라이브러리로 자동 교체합니다. - 작고 특화된 에이전트들을 모아 복잡한 워크플로우를 조합합니다.
예를 들어, API 문서와 내부 비즈니스 케이스를 입력하면, 여러 에이전트가 협업해 API 통합, 테스트, 문서화까지 자동으로 처리합니다.
"작은 에이전트들을 조합해서 더 복잡한 워크플로우를 만들 수 있습니다. 모든 작업을 직접 할 필요가 없죠."
이렇게 하려면 한 번에 완성하려고 하지 말고, 입력을 반복적으로 개선하는 것이 비결입니다.
- 여러 번 시도해도 비용이 거의 들지 않으니, 동시에 여러 에이전트를 실행합니다.
- 실패하거나 맥락이 부족한 시도에서 배운 점을 다음 입력에 반영합니다.
- 출력을 고치고 싶은 유혹을 참으며, 입력을 고칩니다.
"그 반복이 바로 팩토리입니다. 코드 자체는 버릴 수 있지만, 지침과 에이전트가 진짜 자산이죠."
다음 단계
저자는 팩토리를 더 발전시키기 위해 다음을 준비 중입니다.
- 에이전트 간의 더 나은 자동화 및 조정
- 현재는 수동으로 시작하지만, 앞으로는 워크플로우와 의존성을 자동으로 관리하고 싶어합니다.
- 비즈니스 문서와 에이전트의 정렬
- 더 높은 수준의 추상화로 정보를 정리해, 에이전트가 더 효과적으로 활용할 수 있도록 개선할 계획입니다.
- 더 복잡한 워크플로우
- 더 많은 에이전트, 더 복잡한 상호작용을 통해 한층 진화된 자동화에 도전합니다.
- 토큰 사용 극대화
- sonnet 4의 토큰 제한 등 여러 AI 제공자 간의 제약을 극복하고, 중단 없이 전환할 수 있는 방안을 모색합니다.
마무리
현재 저자의 AI 팩토리는 커피 한 잔을 채우는 동안 코드를 배포할 수 있을 정도로 충분히 쓸만하지만, 아직 완전히 자동화되진 않았습니다.
하지만 핵심 원칙은 변하지 않습니다.
"제약은 바뀌겠지만, 핵심 원칙은 남습니다: 출력이 아니라 입력을 고쳐라."
주요 키워드:
- AI 팩토리
- 입력(계획, 프롬프트) 중심 개선
- 에이전트 조합 및 자동화
- 자기 개선 루프
- 병렬 개발
- 지속적 피드백
- 출력(코드)은 소모품, 입력은 자산
이렇게 저자는 AI 에이전트들을 조합해 자기 개선이 가능한 개인용 팩토리를 만들고, '출력이 아니라 입력을 고치는' 원칙을 통해 점점 더 효율적이고 강력한 개발 환경을 만들어가고 있습니다. 🚀