Claude Code Projects를 오래 실행하는 개발자와 소규모 팀을 위해 세션, 병렬 에이전트, 프로젝트 파일, 빌드 산출물, 복구 여유 공간을 분리해 계산하는 방법을 설명합니다. 단순히 에이전트 수를 늘리는 방식이 아니라 피크 동시성, 저장 공간, 재시도 조건을 기준으로 클라우드 작업 공간을 선택하도록 돕습니다.
공식 안내는 Projects의 자료를 프로젝트 파일, 지침, 기억으로 나누고 클라우드에서 여러 작업 흐름을 실행할 수 있다고 설명합니다. Projects의 구성과 관리 방식을 기준으로 보면, Claude Code Projects 클라우드 세션 복구는 세션 수가 아니라 병렬 스레드, 파일 변경, 생성 산출물, 빌드 대기열, 복구 여유를 따로 계산해야 합니다.
적합합니다: 장시간 작업과 다중 에이전트를 클라우드 작업 공간에서 계속 실행하려는 팀입니다.
적합하지 않습니다: 짧은 단일 작업만 처리하고 로컬 장비의 절전이나 네트워크 단절이 문제가 되지 않는 경우입니다.
이 글은 다음 독자를 위한 내용입니다.
- 로컬 장비가 자주 잠들거나 연결이 끊겨 장시간 Claude Code Projects 작업을 이어가야 하는 개발자
- 같은 저장소에서 여러 에이전트를 병렬 실행하려는 소규모 팀 책임자
- 클라우드 맥 또는 원격 개발 작업 공간의 용량, 권한, 복구 정책을 관리하는 운영자
용량 산정의 핵심 기준
에이전트 수에 일정한 배수를 곱하는 방식은 실제 사용량을 설명하지 못합니다. 짧은 대화형 작업은 세션이 많아도 파일 변화가 적을 수 있습니다. 반대로 하나의 장기 작업은 테스트 로그, 패키지 캐시, 빌드 파일과 생성 문서를 계속 쌓을 수 있습니다.
우리는 다음 식으로 1차 용량을 잡는 방식을 권합니다.
필요 용량 = 현재 작업 공간 + 의존성 및 캐시 + 생성 산출물 + 로그와 기록 + 복구 여유
여기서 복구 여유는 남는 공간이 아닙니다. 실패한 빌드를 다시 실행하고, 이전 상태로 되돌리고, 중단된 세션을 확인하기 위한 운영 공간입니다. 장시간 작업이나 높은 병렬도가 예정되어 있다면 이 항목을 별도로 확보해야 합니다.
공식 문서가 Projects의 자료와 작업 관리를 설명하더라도, 특정 클라우드 작업 공간의 저장 용량이나 대여 비용을 자동으로 보장하지는 않습니다. 따라서 실제 선택에서는 클라우드 맥 대여 조건을 확인하고, 작업 유형별 피크 사용량을 직접 기록해야 합니다.
세션 상태와 피크 동시성
일일 작업 수보다 중요한 값은 같은 시각에 살아 있는 작업의 수입니다. 다음 상태를 분리해 기록합니다.
- 활성 세션: 에이전트가 모델 응답이나 도구 실행을 계속 진행하는 상태입니다.
- 도구 대기 세션: 셸 명령, 빌드, 테스트, 네트워크 요청의 결과를 기다리는 상태입니다.
- 중단 세션: 연결이 끊겼거나 작업 공간이 재시작되어 다시 확인해야 하는 상태입니다.
- 완료 보존 세션: 실행은 끝났지만 감사 기록, 오류 원인, 후속 작업 때문에 남겨야 하는 상태입니다.
활성 세션만 세면 용량이 작게 보입니다. 도구 대기 세션은 CPU를 거의 쓰지 않는 순간에도 프로세스, 파일 잠금, 로그를 남길 수 있습니다. 중단 세션은 더 중요합니다. 복구를 위해 이전 로그와 변경 상태를 보존해야 하므로 단순한 현재 실행량과 다른 공간이 필요합니다.
클라우드 작업 공간의 수명 주기 설명은 원격 작업 공간이 정지, 재시작, 삭제 같은 서로 다른 상태를 가질 수 있음을 설명합니다. Claude Code Projects에서도 비슷하게 세션이 보인다는 이유만으로 모든 작업이 같은 복구 상태라고 판단하면 안 됩니다.
프로젝트 파일과 산출물 분리
프로젝트 용량은 다음 다섯 묶음으로 나눠야 합니다.
- 저장소: 소스 코드, Git 메타데이터, 브랜치와 태그입니다.
- 의존성: 패키지 관리자 캐시, SDK, 빌드 도구와 컨테이너 계층입니다.
- 검증 산출물: 테스트 결과, 빌드 파일, 보안 검사 보고서입니다.
- 모델 생성 파일: 코드 초안, 로그 분석 결과, 화면 캡처, 임시 문서입니다.
- 복구 기록: 세션 로그, 스냅샷, 실패 명령, 수동 인계 메모입니다.
공유된 읽기 전용 의존성을 사용하면 논리적으로는 중복을 줄일 수 있습니다. 그러나 여러 에이전트가 각자 작업 폴더를 복제하면 물리적 저장 공간은 다시 늘어납니다. Git worktree 공식 문서처럼 하나의 저장소에서 작업 트리를 분리하는 방식도 전체 복사와 같은 결과가 되는지 확인해야 합니다.
컨테이너를 사용한다면 볼륨의 수명도 따로 봐야 합니다. Docker 볼륨 문서가 설명하듯 컨테이너를 삭제해도 별도 볼륨의 데이터가 남을 수 있습니다. 작업이 끝났는데도 캐시와 볼륨이 남아 있으면 세션 수가 줄어도 디스크 사용량은 줄지 않습니다.
병렬 실행의 자원 구조
Claude Code 다중 에이전트 병렬 실행은 세 가지 운영 방식으로 나눠 비교하는 것이 좋습니다.
| 운영 방식 | 장점 | 주요 병목 | 적합한 경우 | 복구 평가 |
|---|---|---|---|---|
| 순차 실행 | 자원 예측이 쉽고 충돌이 적습니다 | 전체 완료 시간이 길어집니다 | 의존성이 강한 작업 | 가장 단순합니다 |
| 제한 병렬 | 시간과 안정성의 균형이 좋습니다 | 테스트와 디스크 입출력이 겹칠 수 있습니다 | 작은 기능을 나눠 개발하는 팀 | 실패 범위를 나누기 쉽습니다 |
| 고점 병렬 | 독립적인 탐색 작업을 빠르게 처리합니다 | 메모리, 디스크 입출력, 빌드 대기열이 동시에 증가합니다 | 짧고 독립적인 조사나 초안 생성 | 재시도 비용이 큽니다 |
판단 순서는 에이전트 수가 아니라 작업 의존성입니다. 같은 파일을 수정하는 에이전트가 동시에 실행되면 충돌 해결 시간이 생깁니다. 빌드와 테스트를 동시에 실행하면 CPU보다 디스크 입출력이나 캐시 경쟁이 먼저 병목이 될 수 있습니다. 외부 API를 호출하는 작업은 네트워크 응답을 기다리면서 세션을 오래 점유할 수 있습니다.
우리는 각 작업마다 다음 항목을 기록합니다.
- 동시에 실행되는 에이전트 수
- 실제로 겹치는 빌드와 테스트 수
- 작업 중 생성되는 파일의 종류
- 네트워크 대기와 재시도 여부
- 실패 뒤 처음부터 다시 실행해야 하는 단계
이 기록이 없으면 “에이전트 두 개면 한 개의 두 배”라는 잘못된 계산을 하게 됩니다.
복구 설계와 상태 보존
Claude Code Projects 세션 중단 후 계속하려면 모델 대화만 복원해서는 부족합니다. 다음 상태가 함께 맞아야 합니다.
- 프로젝트 파일이 마지막 성공 지점과 일치하는지
- Git 브랜치와 미커밋 변경이 남아 있는지
- 공유 기억에 기록된 계획이 실제 코드와 일치하는지
- 실행 중이던 빌드와 테스트가 끝났는지
- 키, 토큰, 외부 서비스 요청이 아직 유효한지
- 생성 산출물과 로그가 보존되어 있는지
Git의 임시 변경 보존이 필요할 때는 Git stash 공식 문서의 동작을 확인해야 합니다. 다만 stash는 외부 서비스의 배포 상태나 원격 데이터베이스 변경까지 되돌려 주지 않습니다. 파일 상태, 세션 상태, Git 상태, 외부 서비스 상태를 별개로 확인해야 중복 실행을 막을 수 있습니다.
복구 절차는 다음 순서가 안전합니다.
- 작업 공간을 다시 연결한 뒤 현재 프로세스와 디스크 상태를 확인합니다.
- 마지막 성공 명령, 실패 명령, 실행 중 명령을 로그에서 분리합니다.
- Git 상태와 미커밋 변경을 별도 위치에 보존합니다.
- 빌드 산출물과 테스트 결과가 유효한지 확인합니다.
- 외부 서비스에 이미 반영된 요청이 있는지 확인합니다.
- 완료된 단계는 건너뛰고 실패한 단계부터 선택적으로 재실행합니다.
- 재실행 결과와 수동 판단을 세션 기록에 남깁니다.
빌드 결과를 장기간 보존한다면 저장 공간뿐 아니라 보존 정책도 필요합니다. 작업 흐름 산출물 보존 문서는 산출물을 별도 데이터로 관리하는 방식을 설명하고, 산출물 삭제 문서는 불필요한 기록을 정리하는 방법을 안내합니다.
작업 유형별 선택 기준
다음 비교는 특정 제품의 고정 사양을 제시하는 표가 아닙니다. 실제 작업을 어느 환경에 둘지 결정하기 위한 기준입니다.
| 작업 유형 | 로컬 또는 가벼운 환경 | 지속형 클라우드 작업 공간 | 우선 확인할 값 |
|---|---|---|---|
| 짧은 대화와 작은 수정 | 적합합니다 | 과할 수 있습니다 | 파일 변화와 실행 시간 |
| 장시간 빌드와 테스트 | 절전과 연결 단절에 취약할 수 있습니다 | 적합합니다 | 빌드 대기열, 로그, 산출물 |
| 여러 에이전트의 독립 작업 | 충돌 관리가 쉽다면 가능합니다 | 제한 병렬에 적합합니다 | 작업 폴더 분리, 입출력 |
| 같은 저장소의 동시 수정 | 충돌 해결 비용이 큽니다 | 격리 전략이 필요합니다 | 브랜치, worktree, 수동 병합 |
| 며칠 뒤 이어갈 작업 | 기록 보존을 직접 관리해야 합니다 | 지속성과 복구 정책이 중요합니다 | 스냅샷, 세션 기록, 외부 상태 |
로컬 장비가 절전으로 작업을 멈추는 문제가 반복된다면 맥 장시간 작업 운영 가이드를 함께 검토할 수 있습니다. 반대로 물리 포트, 로컬 장치 접근, 장기간의 일정한 고부하가 핵심이면 원격 대여보다 직접 보유한 장비가 더 적합할 수 있습니다.
용량 계산 순서
실제 계획은 다음처럼 진행합니다.
- 한 주기의 최대 동시 세션을 기록합니다. 평균값이 아니라 피크를 사용합니다.
- 각 세션을 활성, 도구 대기, 중단, 완료 보존 상태로 나눕니다.
- 저장소와 의존성 캐시의 현재 크기를 따로 측정합니다.
- 한 작업이 생성하는 빌드 파일, 로그, 캡처, 모델 생성 파일을 분리합니다.
- 순차, 제한 병렬, 고점 병렬 중 실제 운영 방식을 정합니다.
- 실패한 작업을 한 번 이상 보존하고 재실행할 공간을 추가합니다.
- 로그와 산출물의 보존 기간을 정한 뒤 자동 정리 조건을 만듭니다.
- 작업 공간 재시작 뒤 프로젝트 파일, Git, 세션 기록, 외부 서비스가 모두 이어지는지 시험합니다.
- 피크가 반복되면 에이전트 수를 늘리기 전에 병렬도를 낮추거나 산출물 보존 정책을 조정합니다.
이 방식의 장점은 부족한 자원이 무엇인지 구분할 수 있다는 점입니다. 메모리 부족이면 동시 실행 수를 줄여야 합니다. 디스크가 부족하면 캐시와 산출물 정책을 바꿔야 합니다. 복구가 느리면 세션 기록과 스냅샷 구조를 먼저 고쳐야 합니다.
결론과 선택
현재 로컬 방식은 비용과 접근성이 좋지만 장시간 작업에서 절전, 네트워크 단절, 작업 기록 보존을 직접 관리해야 합니다. 여러 에이전트를 한 장비에서 돌리면 파일 충돌과 빌드 입출력 경쟁도 커집니다. 클라우드 개발 작업 공간을 선택하면 이런 문제를 줄일 수 있지만, 사용하지 않는 세션과 산출물이 계속 남으면 비용과 저장 공간이 함께 늘어납니다.
따라서 먼저 피크 세션 수, 병렬 에이전트 수, 작업 지속 시간, 산출물 보존 기간, 실패 재실행 횟수를 적어야 합니다. 그 값으로도 로컬 장비의 절전과 연결 단절이 반복되거나 장시간 복구가 중요하다면 ZekVPS의 클라우드 맥 대여 환경을 비교 대상으로 넣는 편이 합리적입니다. 반대로 일정한 장기 고부하와 물리 장치 연결이 필요하다면 직접 보유한 맥이 더 나을 수 있습니다.
장기 세션과 병렬 작업을 위한 전용 클라우드 맥을 선택하세요
ZekVPS의 전용 클라우드 맥은 장시간 실행되는 개발 세션과 여러 작업을 안정적으로 운영할 수 있는 환경을 제공합니다.
메모리와 저장 공간을 작업량에 맞춰 선택하고 프로젝트 파일, 빌드 결과물, 의존성 캐시를 여유롭게 관리할 수 있습니다.
MCP나 Agent를 데모에서 일상 운영으로 옮길 때는 스냅샷 가능한 클라우드 Mac 노드를 먼저 고정하는 편이 낫습니다. ZekVPS 클라우드 Mac mini 플랜 보기 — 실험 환경과 생산 데스크톱을 분리하면 배포가 안정됩니다.