Claude Code로 여러 AI 에이전트를 연동하는 방법: 자율 대화 대신 Git과 파일로 연결하는 업무 루프 설계 (1인 법인

「여러 AI 에이전트를 만들고, 에이전트끼리 대화하게 하면서 자율적으로 업무를 진행시키고 싶다」.

「AutoGPT나 멀티에이전트 프레임워크를 시도해봤지만, 에이전트들끼리 끝없이 채팅을 반복해서 비용만 소진되고 기대했던 결과물이 나오지 않는다」.

1인 법인이나 개인 개발, 혹은 본업의 틈틈이 AI 에이전트를 실무에 통합하려 할 때, 누구나 한 번쯤 직면하는 벽이 바로 **'에이전트 간 연계(멀티에이전트)의 파탄'**입니다.

연재 '1인 법인 1000마력화 계획'에서는 지금까지 4명의 AI 직원(전문 기능)을 세웠습니다.

• 비서 역할 (태스크 관리): 기한이나 미병합 PR을 한 장에 모으기 (제1회: Claude Code의 태스크 관리) -
• 제작 담당 (게시물 생성): 틀과 설정을 분리하여 SNS 게시물을 대량 생산하기 (제2회: Claude Code로 SNS 게시물을 자동화하는 방법) -
• 분석 담당 (반향 분석): 평가식을 고정하여 객관적인 성공 유형을 추출하기 (제3회: Claude Code로 SNS의 반향을 분석하는 방법) -
• 품질 관리 담당 (검사 채점): 75점 기준으로 형식 검사와 인간의 판단을 분리하기 (제4회: AI에게 블로그 기사를 채점시키는 방법)

단독으로 작동하는 에이전트(점)가 갖춰진 다음 단계는, 그것들을 하나의 선, 그리고 지속적으로 돌아가는 '업무 루프(면)'로 연결하는 것입니다.

하지만 여기서 '에이전트들끼리 직접 API나 채팅으로 대화하게 하여 연계시키려고' 하면, 거의 확실하게 현장에서 파탄을 맞습니다.

먼저 결론부터 말씀드리자면, 제 회사(Nogawa L.prince 합동회사)에서는 에이전트들 간의 직접적인 대화를 완전히 버렸습니다. 대신, 모든 상태와 인계(引き継ぎ)를 'Git 리포지토리 상의 파일(Markdown이나 JSON)'을 인터페이스로 삼아 비동기적으로 연결하고, 인간이 잡아야 할 두 가지 의사결정 게이트(공개 GO 및 시책 선정)만을 고정하는 설계를 채택했습니다.

장기 연재의 제5회로서, 여러 AI 에이전트를 파탄 없이 연계시키는 '자율 가동 루프(Software Factory)'의 설계 사상과 운영의 실화를 기록합니다.

• 에이전트들끼리 말을 시키지 않는다. 'Git과 파일'을 유일한 정본으로 삼는다: 채팅 대화로 상태를 가지지 않고, Git 관리된 Markdown/JSON 파일의 입출력으로 느슨하게 연결(疎結合)합니다. 컨텍스트 오염과 무한 루프를 구조적으로 방지합니다.

• 제작·검사·분석을 잇는 '비동기 파이프라인'을 구축한다: 「제작(생성) → 검사(정적 분석・품질 판정) → 인간의 승인(공개 GO) → 측정(자동 수집) → 분석(성공 유형 추출) → 지시서 업데이트」라는 일방향의 폐쇄 루프를 확립합니다.

• 인간은 '작업'을 놓아주고 '두 가지 게이트(의사결정)'만 잡는다: 인간이 병목이 되는 편집·집계 작업은 놓아주고, 「실제 공개・병합의 GO 사인」과 「추출된 유형으로부터 다음 주 시책을 고르는 판단」에만 집중합니다.

• この記事가 도움이 될 사람:

• 개별 AI 프롬프트나 스크립트는 작동하게 되었지만, 전체 업무 플로우로 자동화·반자동화하고 싶은 사람

• 멀티 에이전트의 대화 형식을 시도하여 무한 루프나 품질 저하에 좌절했던 엔지니어

• 1인 법인이나 스몰 비즈니스에서, 자신의 작업 시간을 늘리지 않고 사업의 아웃풋을 최대화하고 싶은 사람

• 제한 사항:

• 특정 멀티 에이전트 라이브러리(LangGraph나 CrewAI 등)의 API 튜토리얼이 아니라, Claude Code나 CLI 도구를 실무에 통합하여 파탄 나지 않게 하기 위한 '아키텍처와 운영 설계 기록'입니다.

여러 AI에게 일을 분담시키려고 할 때, 처음에 떠오르는 것은 '제작 에이전트가 초안을 만들고, 리뷰 에이전트에게 채팅으로 보내 수정점을 대화하며 다듬는' 협조적 대화의 구도입니다.

하지만 실제로 이 대화형 멀티 에이전트를 업무 플로우에 통합하면, 다음과 같은 3가지 벽에 부딪힙니다.

에이전트 A가 만든 문서에 대해 에이전트 B가 지적을 하고, A가 재수정하는...와 같은 왕복을 반복하면, 왕복할 때마다 최초의 제약이나 전제(페르소나, 글자 수, 절대 지켜야 할 규약)가 컨텍스트에서 옅어집니다.

3번 정도 왕복하면, 문서는 매끄러워지지만 처음에 노렸던 독창적인 날카로움이나 구체적인 숫자가 깎여나가 '무난하고 지루한 일반론'으로 변질되는 현상이 빈번하게 발생했습니다.

'합격 기준을 만족할 때까지 대화를 계속한다'는 루프를 만들면, 에이전트들끼리 서로의 사소한 표현 선호도를 두고 지적하며 끝없이 대화가 멈추지 않게 됩니다.

문득 깨닫고 나면 엄청난 양의 토큰을 소비하여 API 비용이 급증하고, 도중에 타임아웃이나 레이트 리밋에 도달하여 오류로 종료되는 사고가 발생합니다.

에이전트들 간의 채팅 기록 속에 수정 이유나 채택 판단이 묻혀버리면, 나중에 사람이 '왜 이 표현이 되었는지', '왜 중요한 주의사항이 삭제되었는지'를 검증할 수 없습니다.

또한, 제작 에이전트와 리뷰 에이전트가 같은 세션에서 작동하고 있으면, 리뷰 역할이 '자신이 생성하는 것을 지원한 맥락'에 끌려 객관적인 채점이 느슨해지는 '자기 검토의 함정(self-review trap)'도 발생합니다.

이러한 실패들로부터 얻은 결론은, **'사람 간의 Slack 같은 실시간 대화 모델을 그대로 AI 에이전트 간의 연동에 적용해서는 안 된다'**는 것이었습니다.

이런 파탄을 막기 위해 자체적으로 도입한 것이 바로, **GitOps 사상을 접목한 '파일 기반의 느슨하게 결합된 아키텍처(loosely coupled architecture)'**입니다.

에이전트들끼리는 서로의 채팅 세션이나 메모리를 직접 참조하지 않습니다. 모든 주고받음은 Git 리포지토리 상의 Markdown 파일 또는 JSON 파일을 거쳐 이루어집니다.

【제작 담당 에이전트】
↓(신규 파일 생성 및 PR 생성)
[ drafts/xxx.md ] ← Git이 단일 진실 공급원(Single Source of Truth)입니다.
...

• 컨텍스트가 완전히 격리됩니다:
  제작 에이전트가 아무리 많은 시도와 오류를 거치며 토큰을 사용하려 해도, 후속 품질 관리 에이전트에게 전달되는 것은 '완성된 Markdown 파일 1장'뿐입니다. 도중에 발생한 고민이나 불필요한 컨텍스트가 전혀 인계되지 않기 때문에, 품질 관리 측에서는 항상 깨끗한 상태에서 엄격한 검사가 가능합니다.
• 모든 변경 이력과 이유가 Git 로그에 남습니다:
  어떤 에이전트가 어떤 지침서에 근거하여 몇 번째 줄을 어떻게 수정했는지 커밋 로그와 PR의 차이점(diff)으로 100% 기록됩니다. 문제가 발생했을 때도 git diff나 git blame으로 즉시 원인 파악과 롤백이 가능합니다.
• 병렬 작업(Worktree 운영)이 가능해집니다:
  Git worktree를 사용함으로써, 제작 에이전트가 기사 A를 작성하는 동안 다른 에이전트가 기사 B의 검사를 수행하고, 또 다른 에이전트가 지난주 게시물 분석을 실행하는 등의 병렬 처리가 서로의 작업 환경을 오염시키지 않고 안전하게 실행될 수 있습니다.

단일 진실 공급원(Git)을 거치면서, 제1회부터 제4회까지 개별적으로 구축했던 에이전트들이 하나의 매끄러운 '업무 루프'로 연결되었습니다.

자사의 오너 미디어 및 SNS 운영에서 실제로 가동 중인 루프의 전체 구조는 다음과 같습니다.

이 루프의 핵심은, **'에이전트가 에이전트를 직접 호출하는 것이 아니라, 이벤트와 파일 상태 변화에 의해 다음 공정이 트리거된다'**는 점에 있습니다.

• 제작(Generation):
  최신 '성공 사례 대장'과 '금지/기각 패턴'을 읽고, Claude Code의 제작 에이전트가 신규 초안 파일을 생성합니다. -
  검증(Verification):
  초안이 생성되면, 규칙 기반 스크립트와 품질 관리 에이전트가 작동하여 글자 수, 링크 수, SEO 태그, 쿼리 형식 등을 자동 검사합니다. 75점 미만이거나 제외 항목이 있으면 제작 측으로 되돌리고, 합격한 것만 PR로 제출합니다. -
  공개 게이트(Human-in-the-Loop ①):
  사람은 올라온 PR의 차이점과 사실 확인/독창성 체크 항목(지난번 '실제 사례 증명' 추출 결과)만을 확인하고, 문제가 없으면 머지 및 공개합니다. -
  측정(Measurement):
  공개된 기사나 게시물의 성과 데이터는 GitHub Actions의 cron job에 의해 자동으로 취득 및 기록됩니다. -
  분석(Analysis):
  분석 에이전트가 고정된 평가식에 따라 상위/하위 게시물을 분류하고, 왜 성장했는지/왜 부진했는지의 유형을 객관적으로 추출합니다. -
  시책 선정 게이트(Human-in-the-Loop ②):
  사람은 추출된 개선 후보 중에서 '다음 주 어떤 시책에 리소스를 투입할지'를 선택하고, 지침서나 성공 사례 대장을 업데이트합니다. 업데이트된 대장이 다음 제작 공정의 입력값이 됩니다.

1인 법인이나 소규모 조직에서 '1000마력'을 실현하는 본질은, **'사람을 프로세스의 어디에 배치할 것인가'**입니다.

완전히 모든 것을 자동화(No Man in the Loop)하려고 하면, 잘못된 정보 공개나 컴플라이언스 위반, 논란 등 치명적인 사고로 직결됩니다.

반대로, 글의 교정이나 집계 작업에 사람이 매번 개입하게 되면, 사장님의 시간이 아무리 많아도 부족합니다.

그래서 저희 회사에서는 인간의 역할을 **'두 가지 결정 게이트(Decision Gate)'**로만 좁혔습니다.

이 게이트 설계를 도입한 결과, 사장님(인간)의 손에서 다음 작업들이 완전히 사라졌습니다.

• '백지 상태에서 구성안을 생각하고 초안을 제로부터 작성하는 시간'
• '글자 수나 내부 링크가 기준을 충족하는지 자를 대고 세는 시간'
• '지난주 게시물 목록을 스프레드시트에 복사 붙여넣기 하고 계산기를 두드리는 시간'
• '과거에 어떤 시책을 해서 실패했는지 기억에서 파헤치는 시간'

인간이 하는 것은 **'검사된 결과물을 보고 YES/NO를 내는 것'**과, **'분석된 데이터를 보고 방침을 결정하는 것'**뿐입니다.

작업(Do)은 극단적으로 AI와 자동화에 맡기고, 의사결정(Decide)에만 인간이 특화합니다. 이것이야말로 1인 법인이 규모를 확장하기 위한 유일한 길입니다.

이 자율 구동 루프를 실제로 회사에서 돌리기 시작하면서 몇 가지 중요한 지견을 얻었습니다.

에이전트를 단순히 '편리한 스크립트'로 취급할 때는, 임시방편적인 프롬프트를 던지고 결과를 복사 붙여넣기 하는 운영 방식이 되기 쉬웠습니다.

하지만, '제작의 관문', '검사의 관문', '분석의 숫자', '사실 확인의 실습'처럼 역할과 책임 경계를 정의하고, 각각의 입출력 파일을 계약(인터페이스)으로 고정함으로써 시스템 전체의 유지보수성이 비약적으로 향상되었습니다.

이전에는 기사 1편을 공개하는 데 글쓰기에 2시간, 퇴고와 링크 확인에 30분, 총 2시간 반 정도가 걸렸습니다.

현재는 제작 에이전트가 초안을 만들고, 품질 관리 에이전트가 기계 검사를 마친 상태로 PR(Pull Request)이 도착합니다. 인간이 확인하는 것은 '실제 경험의 일관성'과 '전체적인 방침'뿐이라, 1개 기사당 단 3~5분 만에 리뷰부터 공개 판단까지 완료합니다.

에이전트들끼리 직접 대화하게 하지 않고, Markdown이나 설정 파일로 절차를 코드화(Infrastructure as Code라기보다는 'Workflow as Code')하고 있기 때문에, 운영 개선이 모두 리포지토리에 커밋으로 축적됩니다.

'지난주에는 이 검사 규칙을 추가했다', '이번 주에는 이 성공 유형을 지시서에 반영했다'라는 누적이 그대로 1인 법인의 견고한 사업 기반(1000마력 엔진)이 되어갑니다.

장기 연재 '1인 법인 1000마력화 계획'의 제5회로서, 여러 AI 에이전트를 파탄시키지 않고 연계시키는 루프 설계를 설명했습니다.

• 에이전트들끼리 직접 대화하지 않게 하기: 채팅이 아니라 'Git과 파일'을 유일한 정본으로 삼고, 컨텍스트를 격리합니다. - 비동기 파이프라인 구축하기: 제작 → 검사 → 승인 → 측정 → 분석 → 지시서 업데이트라는 일방향 루프를 만듭니다. - 인간의 역할을 의사결정 게이트에 좁히기: 공개 GO와 시책 선정만 인간이 담당하고, 그 외 작업은 모두 포기합니다.

AI 에이전트를 업무에 도입하는 목적은 '재미있는 대화를 하는 것'이 아닙니다. '내가 손을 움직이지 않아도 사업이 전진하는 시스템을 만드는 것'입니다.

점(點)으로 만든 에이전트들을 Git으로 연결하여 견고한 업무 루프로 승화시키는 것. 이 설계야말로 본업이나 육아로 인해 자투리 시간밖에 확보할 수 없는 엔지니어가 1인 상태로 큰 사업을 움직일 수 있는 최대의 무기가 됩니다.

다음 회차(제6회)에서는, **'채용한 AI 직원은 다음 주에도 사용할 수 있었는가? 실무에서 직면한 구식화와 지시서 재교육/유지보수 운영'**에 대해 자세히 기록하겠습니다.

AI에게 블로그 글을 채점하게 하는 방법, 점수와 공개 판단을 분리한 품질 관리 에이전트 설계 (1인 법인 1000마력화 계획 제4회)
Claude Code로 SNS 반응을 분석하는 방법, 평가식과 성공 패턴을 추출하는 에이전트 설계 및 사람에게 남는 의사결정 (1인 법인 1000마력화 계획 제3회)
Claude Code로 SNS 게시물을 양산하기: 틀(型)과 설정을 분리한 에이전트 지시서 작성법 (1인 법인 1000마력화 계획 제2회)
Claude Code의 태스크 관리: 마감일과 PR 보고를 한 장으로 만드는 방법 (1인 법인 1000마력화 계획 제1회)
LLM 평가 방법을 어떻게 설계할 것인가, '데모에서는 작동하지만 실무에서 사용할 수 없는' 것을 막는 데이터셋 3가지 분류와 2축 평가
LLM 평가 프롬프트는 어떻게 작성할까, LLM-as-a-judge의 판정이 흔들리는 원인과 3가지 대처법