왜 나는 내 4번째 Claude Code 인스턴스를 죽였는가 — 멀티에이전트 인디 개발에서 얻은 교훈

발행: (2026년 4월 17일 AM 02:09 GMT+9)
7 분 소요
원문: Dev.to

Source: Dev.to

번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.

The Setup

저는 Jibun Inc. 라는 Flutter Web + Supabase 앱을 만들고 있습니다 — 21개의 경쟁사(노션, 에버노트, 머니포워드, 슬랙 등)의 기능을 하나로 흡수하는 AI 생활 관리 허브입니다. AI University 모듈이 오늘 66개의 제공자를 통과했습니다.

제 개발 루프는 네 개의 Claude Code 인스턴스를 병렬로 실행합니다:

  • VSCode 인스턴스lib/ (Flutter UI) 및 supabase/functions/
  • Windows Desktop 인스턴스docs/supabase/migrations/
  • PowerShell 인스턴스.github/workflows/ 및 CI/CD
  • Web 인스턴스 (claude.ai/code) → 블로그 번역 및 GitHub MCP를 통한 PR 리뷰

오늘 저는 Web 인스턴스를 종료했습니다. 그 이유와 멀티‑에이전트 워크플로를 안정적으로 유지하는 데 배운 점을 공유합니다.

무엇이 깨졌는가

  1. GitHub MCP가 연결을 세 번 끊었습니다.
    v2.1.110 수정 사항인 “서버 연결이 끊어질 때 MCP 도구 호출이 멈추는 문제”가 claude.ai/code 런타임에 배포되지 않은 것으로 보입니다. 각 재연결에 몇 분이 걸렸습니다.

  2. Stream idle timeout — partial response received 를 파일 편집과 병행하여 WebFetch를 실행했을 때 발생했습니다. 응답이 중간에 끊겼고 세션이 복구되지 못했습니다.

  3. docs/INSTANCE_CONFIG.md에 대한 잘못된 “파일을 찾을 수 없음” 읽기가 발생했으며, 이로 인해 새 파일 생성 시도가 트리거되었습니다 — 해당 파일은 PowerShell 인스턴스에 속하므로 파일 소유권 경계를 위반하는 것입니다. 근본 원인은 MCP 호출이 끊긴 것이었지만, 에이전트는 이를 알지 못했습니다.

이 중 하나만 발생해도 견딜 수 있지만, 하나의 세션에서 모두 발생하면 워크플로를 배포할 수 없게 됩니다.

해결책: 세 개로 복귀

나는 Web 인스턴스에 대한 모든 참조를 제거하기 위해 5개의 파일을 정리했다:

docs/MULTI_INSTANCE_COORDINATION.md  # title 4→3, drop Web row
docs/INSTANCE_CONFIG.md              # delete Web constraints/prompt/role
docs/README.md                       # 4→3 instances
CLAUDE.md                            # strip Web mentions from Rules 14/21/22
.github/COMPRESSED_PROMPT_V3.md      # header 4→3, scope table

git show 95c385a4 --stat149개의 삭제 / 29개의 추가를 보고했다. Web 인스턴스가 예상보다 더 많은 곳에 스며들어 있었다.

작업 재배포

기존 웹‑인스턴스 담당새 담당자
docs/research/docs/blog-drafts/Windows Desktop (이미 docs/를 소유)
GitHub MCP PR 및 이슈 트리아지PowerShell (gh CLI가 작동)
Opus 4.7 아키텍처 검토Windows Desktop / PowerShell
블로그 영어 번역PowerShell (예, 이 게시물의 EN 버전까지)

누가 무엇을 쓸 수 있는지 명확히 하면 대부분의 병합 충돌이 사라졌습니다.

Source:

주의사항

인스턴스 간 쓰기 권한

docs/INSTANCE_CONFIG.md는 PowerShell이 소유하고 있지만, Web 인스턴스를 폐지하기로 한 결정은 Windows Desktop 세션에서 내려졌습니다. 정확히 이런 경우를 위해 작은 탈출구를 만들었습니다: docs/cross-instance-prs/YYYYMMDD_.md에 메모를 남기고, 소유 인스턴스가 다음 세션에 승인하도록 합니다.

긴급한 경우에는 파일을 직접 수정하고 커밋 메시지에 [cross‑instance: PowerShell approval required] 태그를 붙입니다.

금지된 영역을 계속 금지 상태로 유지하기

Windows Desktop의 쓰기 범위는 docs/(단, DESIGN.md 제외)와 supabase/migrations/입니다. 오늘 변경 사항에는 CLAUDE.md.github/COMPRESSED_PROMPT_V3.md도 포함되었는데, 이 파일들은 명시적으로 공유 영역으로 표시되어 있습니다. 권한 표를 통해 즉시 판단할 수 있었고, 작업이 지연되지 않았습니다.

관련 없는 변경을 실수로 커밋하지 않기

작업 트리에는 병렬 인스턴스에서 수정된 lib/pages/admin/quota_dashboard_page.dart 파일이 아직 커밋되지 않은 상태였습니다. git add -A를 피하고 각 파일을 명시적으로 나열했습니다:

git add \
  docs/MULTI_INSTANCE_COORDINATION.md \
  docs/INSTANCE_CONFIG.md \
  docs/README.md \
  CLAUDE.md \
  .github/COMPRESSED_PROMPT_V3.md

요점

  • Claude Code의 웹 인스턴스는 현재 자동화된 개발 파이프라인에 적합한 프로덕션 등급이 아니다. MCP 안정성이 로컬 런타임과 맞춰지면 다시 고려하겠다.
  • 각 에이전트의 권한 경계를 사전에 문서화하라. 무엇을 grep해야 할지 정확히 알면 배포를 되돌리는 것이 빠르다.
  • 변경하려는 내용만 커밋하라. 파일에 이름을 지정하고, 다중 에이전트 레포에서 git add -A를 신뢰하지 마라.

다음 글: GitHub Actions에서 블로그‑초안 파이프라인을 재구축하여 게시물이 사라지지 않게 만든 방법.

Building in public:

#FlutterWeb #Supabase #buildinpublic #Claude

0 조회
Back to Blog

관련 글

더 보기 »