▲

개인용 AI 팩토리 구축기 (2025년 7월 스냅샷)

 (john-rush.com)
15P by GN⁺ 13시간전 | ★ favorite | 댓글 1개
  • 여러 AI 에이전트(claude/o3/sonnet 등) 를 활용해 코드 생성부터 검증까지 자동화하는 개인용 "AI 팩토리" 워크플로를 운영함
  • 문제 발생 시 코드(Output)를 직접 수정하지 않고 플랜, 프롬프트, 에이전트 구성등 입력(Input)을 개선하여 자동화 수준을 높이는 방식이 핵심
  • 이렇게 입력을 반복적으로 개선하면, 에이전트들이 지속적으로 발전하여 반복적인 작업 생산성을 극대화함
  • 각 에이전트 역할 분담: 계획 수립(o3/sonnet4), 실행(sonnet3.7/4), 검증(o3/sonnet4) 등으로 구분하여 병렬 처리와 자동 피드백 루프 구현
  • 코드 오류나 스타일 문제도 계획 템플릿에 반영해 다음 생성부터 개선되도록 설계, 반복적 입력 개선으로 팩토리 자체가 성장함

AI 팩토리 개요 및 핵심 원칙

  • 여러 개의 claude code 창을 서로 다른 git-worktree에 띄워 분리된 작업 환경을 유지함
  • o3와 sonnet 4는 플랜 수립에 활용되고, sonnet 3.7 또는 sonnet 4는 실행을, o3는 결과 평가를 수행함
  • 계획 수립, 실행, 검증을 에이전트별로 병렬 분담하여 효율화함

핵심 원칙 – "결과(Output) 수정 대신 입력(Input) 자체를 개선"**

  • 문제가 생기면 생성된 코드를 직접 패치하지 않고, 플랜, 프롬프트, 에이전트 혼합비를 조정해 자동화된 개선을 추구함
  • Factorio 게임처럼, 자동으로 성장하는 공장식 AI 에이전트 네트워크를 만든다는 컨셉임
  • 이런 구조에서 계획-코딩-검증-개선까지의 루프가 순환되며, AI 에이전트가 스스로 코드를 생산/검증/개선하는 환경을 조성함

일상 워크플로 – 팩토리의 구조

  • 메인 인터페이스는 claude code이며, 로컬에서는 mcp 및 Goose(Azure OpenAI 모델 연결용), o3 등을 활용함

1단계: 계획(Planning)

  • claude code에 고수준 작업(task) 입력 → o3가 추가 질문 후 계획안(<task>-plan.md) 생성
  • 계획안에는 원래 요청사항과 구현 플랜이 포함됨

2단계: 실행(Execution)

  • sonnet 4가 계획을 검토 후 태스크 리스트로 변환
  • claude code가 작업을 실행하며, 과제 복잡도에 따라 sonnet 3.7 또는 4를 사용함
  • claude가 각 작업 단계마다 커밋 기록을 남기므로 문제 발생 시 손쉬운 롤백이 가능함

3단계: 검증 및 피드백(Verification → Feedback)

  • sonnet 4가 생성 코드를 플랜에 맞추어 초기 검증 수행
  • 이어서 o3가 플랜 및 최초 요구사항과 비교해 보다 엄격히 검증함
    • o3는 불필요한 코드(예: lint ignore 플래그)나 구식 구조를 엄격하게 지적
  • 검증에서 드러난 문제는 코드 직접 수정이 아닌 계획 템플릿 개선으로 반영
  • git worktree를 활용해 여러 claude code 인스턴스를 병렬로 운영하며, 동시 다중 작업이 가능함

"입력"이 "출력"보다 중요한 이유

  • 결과물(Output)은 버릴 수 있지만, 계획/프롬프트(입력)는 계속 축적·개선되는 누적 자산임
  • 입력부(플랜, 프롬프트)에서 디버깅하면 앞으로의 모든 작업에 확장 가능
  • 에이전트를 단순 생성기가 아닌 스스로 학습하고 협업하는 존재로 변화시킴
  • 예: 전체 CSV를 메모리에 올리는 코드를 스트림 처리로 변경하게 하고, 이후 모든 CSV에 해당 패턴을 플랜에 반영해 차후 자동 검증 가능해짐

팩토리 확장과 에이전트 협업

  • MCP로 전문화된 에이전트들을 각기 다른 작업에 배정하고 병렬화함
    • 예: Clojure 코드 전체를 모아 로컬 스타일 규칙 적용 전용 에이전트 운용, claude가 lint/test/debug 주기에서 발생하는 스타일 문제 보정
  • 내부 라이브러리 코드에서도, 예전 코드의 retry 및 Thread/sleep 사용을 자체 retry 라이브러리로 치환 등 생산성 및 일관성 강화
  • 작은 단위 에이전트들을 여러 개 구축해, 특정한 소작업별로 조합하여 복잡한 워크플로우도 자동화 가능
    • 예: API 명세와 비즈니스 케이스로부터, 에이전트 조합으로 통합, 테스트, 문서화까지 자동 처리
  • 핵심: 입력을 계속 수정해가며 반복 실행, 실패/정체/문맥 누락 시 다음 시도로 피드백 반영 후 개선
  • 코드 자체는 소모품, 진짜 자산은 지시사항(입력)과 에이전트 구성임
  • 실패·정체·문맥 부족 등 모든 문제 교훈을 다음 입력에 반영해 팩토리 루프 완성

다음 단계 및 미래 방향

  • 에이전트 간 총괄 코디네이션을 강화해 전체 워크플로우 추적 및 자동화 도입 추진
  • 비즈니스 문서와 에이전트 정보를 잘 연결하고, 상위 수준의 추상화 정보 위주로 캡처하여 더 효과적으로 활용할 수 있도록 개선
  • 점점 복잡한 워크플로우를 구현하려고 하며, 에이전트간 협업 및 복잡한 상호작용 확대
  • 여러 공급자의 토큰 할당량 최대한 활용 및 손쉬운 전환(특히 bedrock sonnet 4의 토큰 제한 대응) 방안도 모색 중임

결론

  • 현재 AI 팩토리는 자동 코드 생성·검증이 일상화되어, 커피 한잔 동안에도 코드가 배포 가능
  • 아직 완전 자동화 단계는 아니나, "출력 수정 대신 입력 개선" 이라는 원칙이 팩토리의 본질로 자리 잡음
▲
GN⁺ 13시간전  [-]
Hacker News 의견

  • 이 글은 Claude Code와 'aha' 순간을 겪어보지 않은 사람에게는 거의 이해하기 힘든 내용일 거라고 생각함
    "claude --dangerously-skip-permissions"로 권한 제한을 풀고 복잡한 문제를 맡겨두면, Claude가 다양한 도구를 자유롭게 활용해 문제를 해결하는 광경을 볼 수 있음
    오늘도 Docker로 486 assembly로 된 만델브로트 프랙탈 생성기를 직접 컴파일, 실행, 디버깅까지 하도록 시켜봄
    정말 훌륭하게 처리함
    gist 링크

    • 이런 IDE나 LLM에게는 굉장히 쉬운 예시라고 생각함
      어셈블리는 학습 데이터셋에도 충분히 포함되어 있고, Docker도 마찬가지임
      Cursor가 내 코드베이스에서 마음껏 뛰놀게 해본 적도 있음
      최신 툴들이 언젠가는 정말 제대로 도달할 수 있다고 기대하지만, 아직 그 단계까지는 못 왔다고 느낌

    • Dagger(그리고 Docker의 창립자)가 AI Engineer 컨퍼런스에서 발표한 이 영상을 추가로 추천하고 싶음
      이 영상도 다소 난해할 수 있음

    • 혹시 도움이 될 수도 있을까 싶어서 적어봄
      나는 Claude max에서 pro로 강등했고 월 20달러에 이용 제한도 충분히 넉넉함
      Gemini CLI와 경쟁하는 듯해서 이제는 돈을 덜 내고 있어서 기쁨

    • 이 정도 예제나 맥락은 거의 모든 LLM이 별다른 어려움 없이 해결할 수 있을 거라 생각함
      나는 훨씬 복잡한 Rust 의존성 업그레이드를 30회 이상 반복하면서, custom wasm 코드로 처리한 경험이 있음
      Claude는 context7이나 mcp-lsp 등 여러 툴을 연결하며 세부정보를 모음
      하지만 계속 사용하다 보면 한계에 부딪히게 되니, 더 정교하고 어렵게 밀어붙이면 약점이 드러남

    • "claude --dangerously-skip-permissions"로 복잡한 문제를 맡기면 여러 도구를 활용해 문제를 해결한다는, 그 문구에 대해
      나는 Claude가 한 시간을 넘게 틀린 방식으로 코드를 고치려 애쓰는 걸 지켜본 적 있음
      결국 직접 개입해서 "먼저 단위 테스트를 쓰고, 테스트 통과시 코드를 작성해서 다시 알려달라"고 지시함
      Claude Code는 정말 멋진 도구이지만, 기본적인 아키텍처 지도를 계속 반복하며 제공해야 하는 현실임

  • 코드 결과물이 실제로 어떻게 사용되는지 모르고서는 이런 셋업들을 평가하기 어렵다는 생각
    개인적으로 활용하는 vibe coding 앱이라면 정말 믿기 쉬운 얘기지만,
    복잡한 프로덕션 환경에서 고품질 코드를 쓴다는 이야기는 쉽게 납득되지 않음

    • 완전 동의함
      나는 Claude Code로 코딩 속도를 크게 높이지만, 모든 코드 변경마다 항상 직접 체크해서 최적의 시스템이 만들어지는지 확인함
      그냥 돌려만 둔 몇 번의 시도에서는 사용자에게 버그를 안겨줌

    • 사실 이 글에서 설명하는 워크플로우나 개념을 잘 이해 못하겠음
      조금 두루뭉술한 설명이라 그런 듯
      나는 일상적으로 여러 에이전트가 서로 대화하는 구조, 비동기적 에이전트, git work tree 같은 걸 활용해서 복잡한 프로덕션 시스템을 다룸
      출력 결과를 절대 바꾸지 않는 건 아니지만, 원하는 결과가 안 나오면 그걸 내 워크플로우 개선 신호로 받아들이는 편임

  • 나도 비슷한 워크플로우를 시도해보고 있어서 내 경험을 공유하고 싶음
    내가 다루는 Go 코드베이스는 수십만 라인 규모이며, 실제로 수만~수십만 명의 B2C 유저가 사용 중임
    퍼포먼스는 넉넉하지만 정확성과 신뢰성이 매우 중요한 파이낸스 분야임
    나는 오픈AI 키만 사용하는 환경이라 codex-cli와 간단한 스크립트로 저장소 복제, 에이전트 구성, 프롬프트 실행 등의 기본 셋업만 사용
    codex 인스턴스가 시스템 알림으로 내 차례를 알려주고, fzf를 활용해 필요할 때 tmux 세션에 붙음
    아직 MCP는 안 써봤지만 관심 리스트에 올라 있음
    이런 방식이 작은 산발적 태스크를 처리할 땐 엄청 도움되고, 이제는 자잘한 PR들을 훨씬 많이 만들어 내고 있음
    "cattle not pets" 메타포가 여전히 적용됨, 그냥 작은 작업은 빠르게 프롬프트 던져서 산만함을 줄이고 있음
    더 규모가 큰 일에는 아직 잘 안 맞는 듯하고, 아마 나 역시 충분한 컨텍스트 플라이휠을 못 만든 것일지도
    대부분은 결과 코드를 항상 직접 읽고 손봐서 코드 리뷰에 올림
    변경 관리도 수동으로 거의 다 하며, 브랜치/커밋/푸시도 직접함
    자동화 도구도 몇 개 써봤지만 완전히 넘어가진 못한 상태
    "출력물이 아니라 입력을 고쳐라"는 사고방식에 100% 공감함
    AI 없이도 굉장히 강력한 원칙이고, 업계도 점점 더 받아들이는 추세임
    LLM처럼 비결정적인 프로세스에서는 적용이 쉽지 않고 과학보다는 연습에 가깝게 느껴짐

    • 최근 에이전트 분야에서는 불과 며칠 단위로 컨텍스트 관리에 대한 얘기가 많이 오가지만, 이런 방식 쓸 때 나 스스로의 컨텍스트 관리가 제일 어렵게 느껴짐

  • 좋은 글 감사
    나는 "Vibe Specs"라는 글에서 비슷하지만 약간 더 단순한 워크플로우를 소개함
    관련 블로그 논문
    나는 코드베이스 전체에 이 룰을 사용하고, AI가 두 가지를 다르게 행동하게 만듦
    (1) 무엇보다 먼저 질문부터 하게 함
    (2) 코딩에 앞서 spec.md 문서를 만들게 함
    주제의식은 비슷하지만, 나는 한 LLM에만 한정함

    • 우리 대부분이 이걸 비슷하게 시도하는 것 같음
      개인 개발자라 엔지니어링 중심적 사고로 다양한 생산 자동화를 실험함
      나에게 있어 궁극의 목표는, 에이전트가 (구현과 별개로) 자동 생성한 e2e 테스트로부터 코드에 대한 신뢰를 얻는 방식임
      아직 완전히 성공한 건 아님

    • 이제 Claude Code도 “plan mode”로 이런 플로우를 네이티브하게 지원함
      .md 파일을 수동으로 만드는 일은 사실 느리고 귀찮게 느껴짐

  • 기본 생각은, 시스템이 어떤 동작을 해야 하는지(높은 수준과 세부 기능 모두), 어떻게 동작을 증명할지, 아키텍처 및 코드 스타일 같은 구현 방법까지도, 계속 문서화할 수 있다는 점임
    여러 모델을 쓰는 이유는 편향을 줄이고, 특정 작업에 맞는 미세조정 선택지를 늘리기 위한 수단임
    어떤 날에는 대규모 복잡한 시스템도 요구사항 집합 기반으로 다시 만들어질 수 있고, 이때 비로소 소프트웨어가 요구 명세와 진짜 일치하게 될 것임
    이때 남는 ‘레거시 코드’는 오직 레거시 명세 문서가 될 것임
    생성 코드가 아니라 요구 명세를 고치라는 관점임

  • 도대체 실제로 뭘 만드는 건지 궁금함
    AI 워크플로에 대해 얘기할 때마다 반쯤은 꿈 같은 플로우를 말하는 건지, 아니면 진짜 생산적으로 쓰고 있는지 알기 힘듦

    • 나도 매번 결론이 비슷함
      LLM이 코드를 다 짜주면 그냥 관심이 떨어짐
      50개쯤 되는 프로젝트 중 LLM으로 만든 건 2개뿐이고, 그나마도 나는 직접 손을 봤음
      나머지는 “뭔가 있으면 좋겠다”는 생각만 가지고, 실제론 결과엔 별 관심이 없었음
      결국 여러 모델과 구현 세부사항에 씨름하면서, 원하는 동작이 안 나오면 설계 문서, 프롬프트, 예시 데이터 다 들이대며 컴퓨터와 싸우는 루프에 갇히게 됨
      그냥 코드 조금씩 입력 보완만 해주는 쪽이 훨씬 빠르고 덜 스트레스를 받음
      뒤돌아보면 시간과 비용만 쓰고, 결과물은 근근이 돌아가는 소프트웨어라는 생각임
      분명한 요구사항이나 기존 코드베이스가 있고, 내가 주도적으로 가이드 하면 에이전트가 꽤 도움이 되지만, vibe coding 같은 흐름은 작은 스크립트나 틈새앱이 아닌 이상 전혀 재미도 없고, 원하는 품질이 잘 안 나옴
      지나치게 비싸기도 하고 코드도 여전히 지저분
      결국 컴퓨터와 끝없는 논쟁에 시간을 쓰는 느낌임
      이럴 바엔 그냥 직접 하는 게 훨씬 나음

  • 여러 에이전트가 각자 work tree에서 작업할 때 겪는 문제는, 각 에이전트가 모든 세부에서 서로 완전히 다른 아이디어를 내놓으니 사용자 경험이 전혀 통일되지 않는다는 점임
    예를 들어 Documents 대시보드와 Design 대시보드를 만드는 에이전트들이 완전히 다른 관점에서 설계함
    디자인 일관성도, 구조도, DB 스키마나 API 설계 모두 통일감이 없음
    입력이 같아도 출력이 다름
    결국 일관성을 위해 instruction 파일을 늘리다 보면, 대형 프로젝트는 몇 천 줄이 기본이라 context window도 부족해짐
    결론적으로 특정 룰과 스키마만 학습한 작은 LLM을 쓰는 게 더 맞다고 생각함
    프롬프트로 우주만큼 넓은 아이디어를 다루는 대형 LLM보단 작은 LLM이 정답일 듯함

    • 에이전트마다 완전히 다른 결과, 디자인의 일관성 없음
      결국 시니어가 꼭 필요함
      AI든 사람이든, 원하는 방향으로 움직일 최소한의 구조와 유연성을 직접 제공할 수밖에 없음
      구조가 없다면 그냥 직접 코딩하는 게 훨씬 나음

    • 나는 첫 번째 버전을 직접 만든 후, 이후 일은 Claude Code에게 "이 예시처럼 만들어라"라고 하면 일관성을 유지하기 수월했음

  • ADHD식 코딩, 무작정 프로덕트 생성 시도 후 맞출 때까지 반복하는 방식?
    그냥 미래 확장 가능한 코드를 직접 작성하는 편이 낫지 않을까
    굳이 탄소 발자국만 늘리지 말라는 입장

    • 최종 목표는 개발자를 이 프로세스에서 배제시키는 것임
      비즈니스 오너가 새 CRUD 앱을 요청하면 바로 프로덕션에 띄우는 단계
      물론 결과물은 버그투성이에 느리고, 인증되지 않은 DB에 저장하지만, 그건 내 일이 아니라는 마인드
      마지막엔 뜨거운 차를 벌컥 들이키는 격한 표현으로 마무리

    • 프로그래밍은 영원히 바뀌었고, 그 변화를 빨리 받아들여야 함
      “그냥 코드를 쓰라”는 건 마치 모두가 직접 마차를 손질하자고 주장하는 것과 같음
      차도 고장나니 옛날 방식을 고집하자는 소리와 별반 다를 게 없음

    • 왜 늘 ‘미래 확장 가능한 코드로 그냥 직접 써라’는 얘기가 나오는지 의문임
      요즘 코딩 어시스턴트도 zero-shot으로 확장 가능하고 유지보수 가능한 코드를 쓸 수 있는데, 실제로 그렇게 요청해 보기나 했는지 반문하고 싶음

    • 인간도 결과적으로 trial and error로 계속해서 답을 찾아가는 건 마찬가지임
      경험이 많을수록 머릿속에서 시뮬레이션 정도만 다를 뿐임
      탄소발자국을 문제 삼는다면, AI 데이터센터가 재생에너지로 돌아가면 그건 괜찮은가라는 시각

  • AI를 워크플로에 더 효과적으로 통합하는 법을 찾아야 한다고 생각함
    적극적으로 AI를 도입해본 사람들은 비슷한 고민을 겪었을 텐데, 아직 확실한 해결책이 없음
    이 단계에선 AI에게 최소한의 역할만 정확하게 할당하는 게 핵심이라고 봄
    예를 들어, 주식 리서치에 쓰는 에이전트 워크플로우로 ‘Bullish Guy’와 ‘Bearish Guy’ 두 AI를 만들어 하나의 종목에 대해 장단점 논쟁을 벌이게 함
    이렇게 서로 반대 입장에서 자료조사를 시키면 더 포괄적이면서도 깊이 있는 분석 결과가 도출됨
    이런 아이디어는 실제로 소셜미디어에서 논쟁하는 방식을 보고 착안함

  • vibe-coding에서 결과물이 자기참조적인 얘기 이상의 게 별로 없고, 결국 3D 프린팅의 뒤를 이을 비싼 취미이자 끝없는 장난감 만들기 활동처럼 보임
    요즘 vibe coding에서 “benchy”처럼 쓰이는 예제는 todo 앱 정도 아닌가 하는 의문

    • 3D 프린팅 자체는 실제로 굉장히 유용함
      제품을 직접 설계하거나 엔지니어링을 하는 사람이라면 다들 씀
      일반 소비자들이 활용하지 않는 유일한 이유는, 이미 필요한 거의 모든 플라스틱 아이템을 Amazon에서 바로 주문할 수 있기 때문임
      온라인쇼핑이 없던 시절이라면 평균적인 사람들한테 훨씬 유용했을 것
      앞으로는 커스텀 파일 직접 설계가 가능한 사람들에게만 정말로 필요한 기술일 듯함
답변달기