AI 에이전트로 만드는 자동화 코딩 팩토리
최근 한 개발자가 공유한 흥미로운 개발 워크플로우를 보게 되었다. 여러 개의 Claude 코드 창을 열어두고, 각각을 다른 git-worktree에서 작업하면서 o3와 Sonnet 4가 계획을 세우고, Sonnet 3.7이나 4가 실행하고, o3가 결과를 검증하는 시스템이다. 문제가 발견되면 계획 템플릿에 피드백을 넣어 코드를 재생성한다. 말 그대로 팩토리가 스스로 개선되는 구조다.
이 접근법에서 가장 인상적인 부분은 "결과가 아닌 입력을 고치라"는 핵심 원칙이다. 뭔가 잘못되었을 때 생성된 코드를 직접 수정하거나 Claude와 논쟁하지 않는다. 대신 계획, 프롬프트, 또는 에이전트 조합을 조정해서 다음 실행에서 구조적으로 올바른 결과가 나오도록 한다.
팩토리오에서 배운 자동화 철학
이 개발자는 팩토리오 게임을 예로 들면서 자신만을 생산할 수 있는 팩토리를 만드는 것이 핵심이라고 설명한다. 컨베이어 벨트와 기계들이 끝없이 부품을 제작하는 것처럼, AI 에이전트들로 코드를 생성하고 검증하며 시간이 지날수록 스스로 개선되는 팩토리를 만들어야 한다는 것이다.
이런 접근법이 흥미로운 이유는 단순히 AI를 도구로 사용하는 것을 넘어서, AI들이 서로 협력하고 검증하며 학습하는 생태계를 만들었다는 점이다. 각 AI 모델의 강점을 활용해 역할을 분담하고, 실패로부터 학습해 시스템 전체를 개선하는 구조는 매우 체계적이다.
일상적인 워크플로우: 3단계 프로세스
1단계: 계획 수립
Claude Code에 고수준 작업을 주면, o3를 호출해서 계획을 생성한다. o3는 좋은 계획자이고 작업을 명확히 하기 위해 적절한 질문들을 던진다. 그 다음 원래 요청과 구현 계획이 담긴 `-plan.md` 파일을 작성한다.
2단계: 실행
Sonnet 4가 계획을 읽고 검증한 후 작업 목록으로 변환한다. 그 다음 Claude Code가 작업 복잡도에 따라 Sonnet 3.7이나 4를 사용해 계획을 실행한다. 이 개발자는 주로 Clojure를 사용하기 때문에 괄호를 제대로 맞추려면 Sonnet 4를 선호한다고 한다.
중요한 지침 중 하나는 Claude가 각 작업 단계마다 커밋을 작성하도록 하는 것이다. 이렇게 하면 뭔가 잘못되었을 때 Claude나 개발자가 이전 상태로 되돌릴 수 있다.
3단계: 검증과 피드백
코드가 생성되면 Sonnet 4가 원래 계획과 대조해 코드를 검증한다. 그 다음 o3가 원래 계획과 요청 모두와 대조해 코드를 검증한다. o3는 타협하지 않는다. Claude는 사용자를 기쁘게 하려고 불필요한 하위 호환성 코드를 그대로 두지만, o3는 이를 지적하고 제거를 요구한다. Claude는 또한 코드에 "lint ignore 플래그"를 추가하는 경향이 있는데, o3는 이것도 지적한다.
두 모델이 모두 코드를 검증하면 문제를 잡아내고 Claude와의 왕복을 줄일 수 있다. Sonnet 4나 o3가 발견한 모든 문제는 인라인으로 수정하지 않고 계획 템플릿에 반영된다.
입력이 출력보다 중요한 이유
이 접근법의 핵심 통찰은 "출력은 일회용이지만 계획과 프롬프트는 복합적"이라는 것이다. 소스에서 디버깅하면 모든 미래 작업에 확장되고, 에이전트를 단순한 코드 프린터에서 자기 개선하는 동료로 변화시킨다.
구체적인 예를 들어보자. 한 에이전트가 전체 CSV를 메모리에 로드하는 코드를 작성했다. 개발자는 스트리밍으로 전환하게 하고, 에이전트가 CSV에 대해서는 항상 스트리밍을 사용하라는 지침을 계획에 작성하게 했다. 이제 계획 검사기가 CSV에 스트리밍을 사용하지 않는 코드를 플래그로 표시하고, 개발자는 모든 PR 리뷰에서 이를 기억할 필요가 없다. 팩토리가 스스로 개선되는 것이다.
팩토리 확장하기
이 개발자는 더 복잡한 워크플로우를 인코딩하기 시작했다. 특정 작업을 위한 전용 에이전트들을 MCP 뒤에 두고 있다.
하나의 MCP는 생성된 모든 Clojure 코드를 스윕하고 로컬 스타일 규칙을 적용한다. 이런 규칙들은 원래 계획과 에이전트의 지침에 포함되어 있지만, 생성된 코드에는 종종 스타일 문제가 있다. 특히 Claude가 lint/test/debug 사이클에 들어가면 더욱 그렇다. 이런 집중된 에이전트는 더 엄격한 동작을 보장하고 스타일 규칙을 일관되게 적용할 수 있다.
내부 라이브러리에도 이런 방식을 적용하기 시작했다. 생성된 코드를 보고 재시도나 Thread/sleep 같은 것들을 자체 재시도 라이브러리로 교체하는 데 능숙하다.
이런 작은 에이전트들의 컬렉션을 구축하고 있다. 각각은 작고 구체적인 작업을 수행할 수 있고, 이들을 조합해서 더 복잡한 워크플로우를 만들 수 있다. 예를 들어, API 문서와 내부적으로 정의된 비즈니스 케이스 세트를 가지고 에이전트들의 조합이 API용 통합, 테스트, 문서를 구축하게 할 수 있다.
반복적 개선의 비밀
한 번에 큰 단계로 도달하지는 않는다. 비밀 소스는 입력을 반복하는 것이다. 작업에 대해 수십 번의 시도를 하는 것은 본질적으로 무료이므로 그렇게 한다. 모든 에이전트가 병렬로 실행된다. 하나가 실패하거나 정체되거나 컨텍스트가 부족하면, 그 교훈을 다음 반복에 피드한다. 출력을 고치고 싶은 충동을 억제하고 대신 입력을 고친다.
그 루프가 바로 팩토리다. 코드 자체는 일회용이고, 지침과 에이전트가 진짜 자산이다.
미래 개선 계획
이 개발자는 팩토리를 개선하기 위해 몇 가지 작업을 하고 있다:
더 나은 전체 에이전트 조정: 현재는 수동으로 시작하는 경향이 있지만, 워크플로우와 에이전트 간 의존성을 관리하는 더 자동화된 방법을 원한다.
비즈니스 문서와 에이전트 정렬: 에이전트가 더 효과적으로 사용할 수 있도록 더 높은 추상화 수준에서 정보를 캡처하도록 변경한다. 이는 저수준 구현 세부사항에서 벗어나 사용 사례에 집중하는 것을 의미한다.
더 복잡한 워크플로우: 현재 설정으로 꽤 복잡한 워크플로우를 구축할 수 있지만 더 밀어붙이고 싶다. 더 많은 에이전트, 더 많은 조정, 더 복잡한 상호작용을 의미한다.
제공업체 간 토큰 사용량 최대화: 특히 Sonnet 4의 경우 Bedrock의 토큰 제한에 상당히 제약을 받고 있다. 중단 없이 Claude 최대 계획과 Bedrock 간을 전환할 수 있어야 한다.
결론: 미래의 개발 방식
이 사례는 AI 도구를 단순히 사용하는 것을 넘어서, AI들이 협력하고 학습하는 생태계를 구축하는 방향으로 개발 패러다임이 변화하고 있음을 보여준다. 현재 이 팩토리는 개발자가 커피를 다시 채우는 동안 코드를 배포할 수 있을 정도로 좋지만, 아직 개발자를 완전히 대체할 정도는 아니다.
하지만 핵심 원칙은 변하지 않을 것이다: 출력이 아닌 입력을 고쳐라. 이는 단순히 기술적인 접근법을 넘어서, AI와 협업하는 새로운 사고방식을 제시한다. 코드는 일회용이지만, 그 코드를 생성하는 지침과 프로세스는 계속 축적되고 개선되는 자산이다.
이런 접근법이 널리 퍼진다면, 개발자의 역할은 코드를 직접 작성하는 것에서 AI 에이전트들을 조율하고 개선하는 것으로 변화할 것이다. 마치 오케스트라 지휘자처럼, 각 악기(AI 에이전트)의 특성을 이해하고 조화롭게 협력하도록 만드는 것이 핵심 역량이 될 것이다.