5개 클라이언트 프로젝트를 Claude Code 1명이 동시에 굴린 한 달
도입 배경
컴포넌트팀은 2026년 3월 한 달간 의도적인 실험을 진행했습니다. 풀스택 개발자 1명이 Claude Code Opus 4.6을 활용해 5개 클라이언트 프로젝트를 동시에 운영할 수 있는가라는 질문에 답하기 위해서였습니다.
기존 운영 방식은 1인당 1~2개 프로젝트 담당이 표준이었습니다. 하지만 다음과 같은 변화가 누적되면서 실험이 필요해졌습니다.
- Claude Code의 Agent Teams 기능으로 병렬 작업 위임이 가능해짐
- MCP 서버 표준화로 Linear·Sanity·Sentry·GitHub 같은 외부 도구를 한 세션에서 호출
- git worktree 기반의 작업 디렉터리 분리로 컨텍스트 충돌 방지
- 클라이언트들이 점차 "AI 활용 비용 절감"을 단가 협상 카드로 꺼내기 시작
이를 검증하기 위해 다음 4가지 요구사항을 만족하는 운영 구조가 필요했습니다.
- 5개 프로젝트의 컨텍스트가 서로 오염되지 않는 격리 메커니즘
- 단일 개발자가 하루 안에 5개 프로젝트를 모두 진행할 수 있는 컨텍스트 스위칭 비용 최소화
- 사고 발생 시 어느 프로젝트에서 무엇이 잘못됐는지 추적 가능한 로깅
- 클라이언트별 사용량을 측정해 정확하게 청구할 수 있는 비용 회계
여러 구성을 검토한 결과 git worktree + 프로젝트별 CLAUDE.md + Claude Code Skills + MCP 서버 격리 조합으로 정착했습니다.
운영 아키텍처
작업 디렉터리 구조는 다음과 같이 정리했습니다.
- ~/work/client-a/ — 의료 SaaS 프로젝트 (Next.js + Supabase)
- ~/work/client-b/ — 이커머스 리뉴얼 (Remix + Shopify)
- ~/work/client-c/ — B2B 대시보드 (Next.js + Sanity)
- ~/work/client-d/ — 모바일 앱 백엔드 (NestJS + PostgreSQL)
- ~/work/client-e/ — 마케팅 사이트 (Astro + Sanity)
- ~/work/_shared/skills/ — 공통 Claude Code Skills (lint, deploy, PR 템플릿)
- ~/work/_shared/sync/ — AGENTS.md 동기화 스크립트
각 프로젝트 디렉터리는 다시 git worktree로 작업별 분리했습니다.
- client-a/main/ — 안정 브랜치
- client-a/feature-billing/ — 진행 중 기능
- client-a/hotfix-auth/ — 긴급 수정
핵심 의사결정 4가지는 다음과 같았습니다.
컨텍스트 격리는 디렉터리·MCP 서버·세션 3중으로
git worktree로 파일 시스템 격리, MCP 서버는 프로젝트별 별도 인스턴스, Claude Code 세션은 하루에 한 번만 새로 시작했습니다. 이 3중 격리로 "A 프로젝트 코드가 B 프로젝트에 섞여 들어가는" 사고를 막았습니다.
하루를 "프로젝트 슬롯"으로 쪼개지 않음
처음에는 오전 클라이언트 A, 오후 클라이언트 B 같은 시간 분할을 시도했으나 비효율적이었습니다. 대신 이슈 단위로 큐를 만들고 Claude Code에 자율 실행을 위임한 뒤, 사람은 PR 검토와 의사결정에만 집중하는 방식으로 바꿨습니다.
공통 Skills 라이브러리로 휴먼 워크플로 표준화
PR 작성, 배포 전 체크리스트, 변경사항 노션 동기화 등 모든 프로젝트에 공통되는 작업을 Skills로 추출했습니다. 클라이언트마다 컨벤션은 다르지만 워크플로의 뼈대는 같다는 인사이트가 핵심이었습니다.
Claude Code 사용량을 클라이언트 태그로 분류
세션 시작 시 환경변수에 CLIENT=client-a를 설정하고, 모든 사용량 로그가 이 태그와 함께 기록되도록 했습니다. 월말에 클라이언트별 토큰 사용량과 단가를 정확히 산출할 수 있었습니다.
한 달 운영 결과
3월 한 달간의 실측 데이터입니다.
- 처리한 이슈: 총 87개 (5개 프로젝트 합산)
- PR 머지: 62개 (사람이 직접 머지한 비율 100%, 자동 머지 0%)
- 롤백 발생: 3건 (롤백률 4.8%)
- Claude Code 비용: $340 (1인당)
- Cursor 비용: $60 (Pro+ 플랜)
- 1인 처리량 기준 직전 분기 대비: 약 2.3배
흥미로운 발견은 "5배"가 아니라 2.3배였다는 점입니다. AI가 코드를 5배 빠르게 생성할 수 있다 해도, PR 검토·클라이언트 커뮤니케이션·의사결정 시간은 줄지 않았습니다. 이 부분은 다음 글에서 METR 연구와 함께 더 다룰 예정입니다.
트러블슈팅: 한 달간 만난 4가지 함정
1. 프로젝트 간 코드 누수 사고
클라이언트 A의 결제 모듈 코드가 클라이언트 C의 PR에 포함된 채로 리뷰 요청이 올라왔습니다. 다행히 머지 전에 발견됐지만, 외부에 공개되면 계약 위반이 될 수 있는 사고였습니다.
원인: Claude Code 세션이 같은 터미널 탭에서 프로젝트를 전환하면서, 이전 컨텍스트의 일부가 다음 프로젝트의 코드 생성에 영향을 미쳤습니다. 자세히 추적해보니 "결제 흐름 구현"이라는 비슷한 요구사항을 두 프로젝트에서 동시에 받으면서, 모델이 직전 세션의 패턴을 재사용한 것이 원인이었습니다.
해결: 프로젝트 전환 시 반드시 새 터미널 세션 + 새 Claude Code 세션을 시작하도록 강제했습니다. 자동화 스크립트(switch-client.sh)로 세션 종료·환경변수 갱신·새 세션 시작을 한 번에 처리하게 했고, 같은 터미널 탭에서 다른 프로젝트로 진입하는 것을 셸 함수에서 차단했습니다.
2. MCP 서버 인증 토큰 오남용
클라이언트 D의 Linear API 토큰으로 클라이언트 B의 이슈를 조회하는 호출이 발생했습니다. 결과적으로 권한 에러로 실패했지만, 만약 양쪽이 같은 Linear 워크스페이스를 쓰는 상황이었다면 데이터 유출로 이어질 수 있는 케이스였습니다.
원인: MCP 서버 설정을 글로벌(~/.config/claude/mcp.json)에 두면서 모든 프로젝트가 같은 토큰 풀을 공유했습니다.
해결: MCP 설정을 프로젝트별 로컬 파일(./.mcp.json)로 이동시키고, 환경변수도 프로젝트 디렉터리의 .env.local에서만 읽어오도록 분리했습니다. 글로벌 설정은 프로젝트 무관 도구(예: 시간대 변환, 환율 조회)로만 제한했습니다.
3. Agent Teams의 비용 폭주
클라이언트 C의 대규모 리팩터링을 Agent Teams로 위임한 어느 날, 단일 작업이 $87를 사용하는 사고가 발생했습니다. 평소 작업 평균이 $2~5 수준이었기 때문에 이상치였습니다.
원인: 한 에이전트가 테스트 실패 → 코드 수정 → 다시 테스트 → 다시 실패의 무한 루프에 빠졌습니다. Opus 4.7의 1M 토큰 컨텍스트 윈도와 추가 과금 없는 정책 때문에 모델이 알아서 멈출 유인이 약했습니다.
해결: 작업당 최대 토큰 예산(--max-tokens-per-task)과 최대 실행 시간(--timeout)을 명시적으로 설정했습니다. 또한 동일 테스트가 3회 연속 실패하면 자동으로 사람에게 에스컬레이션하는 훅을 추가했습니다.
4. 클라이언트별 사용량 정산의 누락
월말 정산 시점에 약 12%의 사용량이 어떤 클라이언트 태그도 붙어 있지 않은 채로 기록되어 있었습니다. 청구 정확성에 직접 영향을 주는 문제였습니다.
원인: 새 터미널 탭을 열고 환경변수 설정을 빠뜨린 채로 Claude Code를 실행한 케이스가 누적된 결과였습니다. 사람이 매번 환경변수를 설정하는 방식은 실수가 누적될 수밖에 없는 구조였습니다.
해결: direnv를 도입해 디렉터리에 진입하는 순간 자동으로 CLIENT 환경변수가 설정되도록 했습니다. 환경변수가 비어 있으면 Claude Code 자체가 시작되지 않도록 셸 래퍼를 추가했습니다.
