클라우드에서 쓰는 Claude Code: 클라우드 세션 활용 가이드

대부분 노트북 터미널에서 Claude Code를 실행하실 겁니다. 이 방식은 세 가지 면에서 노트북에 의존합니다.

• 작업 트리를 함께 쓰기 때문에, 같은 저장소에서 세션 두 개를 돌리면 같은 파일을 동시에 수정하거나 같은 포트를 두고 충돌할 수 있습니다.
• 내 자격 증명으로 실행됩니다.
• 컴퓨터가 절전 모드에 들어가거나 Wi-Fi가 끊기면 세션도 멈춥니다.

클라우드 세션은 Claude Code를 별도의 머신에서 실행합니다. 작업마다 새 가상 머신(VM)이 만들어지고, 여기에 저장소가 새 브랜치로 클론되며 환경 설정도 미리 끝나 있습니다.

claude.ai/code, Claude 모바일 앱, 데스크톱 앱, 터미널, Slack에서 세션을 시작할 수 있고, 진행 상황은 브라우저, 모바일 앱, 데스크톱 앱에서 확인할 수 있습니다. 작업이 끝나면 결과가 브랜치에 남으며, 이를 풀 리퀘스트로 만들면 됩니다.

클라우드 세션은 Pro, Max, Team, Enterprise 요금제에 추가 비용 없이 포함됩니다. 클라우드 머신에 별도 요금은 없고, 사용량은 Claude Code의 다른 기능과 같은 한도에서 차감됩니다. 요금제에 따라서는 조직 소유자가 먼저 클라우드 세션을 활성화해야 할 수도 있습니다.

클라우드 세션 보너스 크레딧 기존 개인 Pro·Max 구독자는 요금제 한도와 별개로 클라우드 세션용 보너스 크레딧을 한 번 받을 수 있습니다. Pro는 $100, Max는 $250입니다. 10월 7일까지 claude.ai/code/claim-credit에서 신청하거나 Claude Code에서 /claim-credit을 실행해 받으세요. 크레딧은 11월 4일에 만료되며, 모두 쓰거나 만료된 뒤에는 요금제의 일반 사용량이 적용됩니다. Projects와 Routines에는 사용할 수 없습니다. 자세한 내용은 프로모션 크레딧 제공 약관을 참고하세요.

이 가이드를 쓰려고 작은 샘플 저장소를 대상으로 실제 클라우드 세션을 네 번 실행했습니다. 글 곳곳에 나오는 트랜스크립트, diff, 소요 시간은 모두 그 세션에서 가져왔습니다. 스크린샷 속 저장소와 사용자는 가상이지만, 작업 내용과 결과물, 수치는 실제 세션에서 나온 것입니다.

클라우드 세션의 가장 큰 장점은 여러 작업을 서로 간섭 없이 동시에 돌릴 수 있다는 점입니다. 아래는 16초 간격 안에 시작한 세 작업으로, 각각 별도의 머신에서 실행됐습니다. 노트북이었다면 하나씩 순서대로 돌리거나, 서로 부딪히지 않게 신경 쓰느라 시간을 썼을 겁니다.

작업 세 개, 저장소 하나, 머신 세 대

샘플 저장소는 가상의 항구 세 곳의 조수를 예측하는 작은 Node API인 tidepool입니다. 여기에는 흔히 볼 법한 문제가 세 가지 있었습니다. 테스트 하나가 네 번에 한 번꼴로 실패하고, API 문서에는 코드가 더 이상 읽지 않는 파라미터가 적혀 있으며, 로거가 문자열을 이어 붙여 로그 줄을 만들고 있었습니다.

문제마다 하나씩, 클라우드 세션 세 개를 16초 이내에 연달아 시작했습니다. 프로그래밍 방식으로 시작했고 tidepool은 GitHub에 올라와 있지 않아서, 각 세션이 먼저 프롬프트에 담긴 파일로 저장소를 다시 만들었습니다. 실제 저장소라면 이 단계는 필요 없고, 터미널에서는 세션마다 claude --cloud 명령어 한 줄이면 됩니다. 프롬프트를 줄여 보면 다음과 같습니다.

claude --cloud "npm test fails maybe one run in four. Find the flaky test, fix the root cause in the code (not the test), and prove it by running the suite at least 30 times in a row."
claude --cloud "docs/API.md is out of date with src/server.js. Rewrite it so every endpoint, parameter, default and response shape matches the code. Start the server and run each curl example to check it."
claude --cloud "Make src/logger.js emit one JSON object per line, keep LOG_LEVEL, and log method, path, status and duration_ms as fields. Add a test for the logger."

세션은 각각 61초, 65초, 72초 동안 실행됐고, 첫 세션이 시작된 지 87초 만에 세 개가 모두 끝났습니다. 저장소를 다시 만드는 데 각 실행 시간의 약 3분의 1에서 절반을 조금 넘는 시간이 걸렸습니다. 결과는 다음과 같습니다.

• 불안정한 테스트. Claude는 TtlCache.get에서 경합 상태(race)를 찾아냈습니다. 캐시가 로더 실행이 끝난 뒤에야 값을 저장하는 구조여서, 로드 도중 같은 키로 get이 한 번 더 호출되면 로더가 다시 실행됐습니다. Claude는 캐시가 진행 중인 promise를 저장하도록 바꾸고, 로드가 실패하면 해당 항목을 지우게 했습니다. 그런 다음 npm test을 40번 연속 실행해 실패가 한 번도 없음을 확인했습니다.
• 문서. Claude는 서버를 띄우고 모든 엔드포인트에 curl을 실행해, 기존 문서가 틀린 부분을 다섯 가지 찾았습니다. API가 반환하지 않는 필드가 적혀 있었고, 코드가 무시하는 days 파라미터가 문서화돼 있었으며, 높이가 미터인데 피트로 표기돼 있었습니다. 또 /next-high 엔드포인트가 빠져 있었고 오류 응답도 누락돼 있었습니다. 잘못된 형식의 from= 값을 보내면 200 응답과 함께 빈 목록이 돌아온다는 점도 발견했는데, 요청받지 않은 서버 코드는 건드리지 않고 이를 주의 사항으로 문서에 적었습니다.
• 로거. Claude는 JSON 로거를 작성하고 요청 로그를 구조화된 필드로 옮긴 뒤 테스트 다섯 개를 추가했습니다. 커밋 시점에 테스트 하나가 실패하자 캐시 테스트를 여덟 번 다시 돌렸고, 그중 다섯 번 실패하는 것을 확인한 뒤 첫 번째 세션이 고치고 있던 것과 같은 경합 상태가 원인임을 밝혀냈습니다. 같은 해결책을 제안하긴 했지만 자기 작업 범위를 벗어난 캐시는 건드리지 않았고, 요약에 테스트 스위트가 깨끗하지 않다고 남겼습니다.

로거 세션의 결과를 보면 클라우드 세션이 병렬 작업에 왜 잘 맞는지 알 수 있습니다. 세션마다 저장소 사본, 프로세스, 브랜치가 따로 있었습니다. 문서 세션과 로거 세션은 테스트용으로 각자 API 서버를 띄웠지만 서로 영향을 주지 않았습니다. 노트북 한 대에서 에이전트 두 개가 같은 체크아웃으로 작업하면 같은 파일을 수정하게 되고, 각자 포트를 따로 정하지 않으면 포트도 충돌합니다.

이렇게 격리되어 있다 보니, 로거 세션은 첫 번째 세션이 만들던 캐시 수정을 쓸 수 없었습니다. 병렬 작업은 파일 경계를 기준으로 나누고, 브랜치는 적절한 순서로 병합하세요. 그리고 다른 세션이 이미 고치고 있는 문제를 어떤 세션이 보고하는 일도 있다는 점을 염두에 두세요.

Claude Code 클라우드 세션의 내부 구조

클라우드 세션은 Anthropic이 관리하는 인프라, 또는 셀프 호스팅 환경을 쓸 경우 조직이 보유한 머신에서 실행되는 Claude Code 세션입니다. 아래 그림은 구성 요소를 보여 줍니다. 그림 뒤의 네 가지는 작업 방식을 바꾸는 핵심 포인트입니다.

• 작업마다 전용 머신이 생깁니다. 저장소가 새 브랜치로 클론된 새 VM이 만들어지므로 세션끼리 서로의 파일이나 포트를 건드릴 수 없습니다. 설치된 항목을 참고하세요.
• GitHub 토큰은 VM 안으로 들어가지 않습니다. 토큰은 프록시가 보관하고, 세션에는 자기 작업 브랜치에만 푸시할 수 있는 단기 자격 증명이 발급됩니다. GitHub 프록시를 참고하세요.
• 저장소의 Claude 설정은 따라오지만, 개인 설정은 따라오지 않습니다. CLAUDE.md, 규칙, 스킬, 에이전트, 커맨드는 저장소와 함께 전달되고, ~/.claude은 노트북에만 남습니다. 클라우드 세션의 설정을 참고하세요.
• 유휴 상태의 VM은 회수됩니다. 세션을 다시 열면 대화 내용이 복원된 새 VM이 만들어지므로, 중요한 작업은 커밋해 두세요. 환경 만료를 참고하세요.

사양, 권한 모드, 네트워크 수준에 대해서는 클라우드 환경 문서를 참고하세요.

로컬과 클라우드, 무엇을 쓸까?

클라우드 세션이 로컬 세션을 대체하는 것은 아니며, 대부분 둘을 함께 씁니다. 표에서 차이점을 확인하고, 이어지는 설명에서 각각 어떤 경우에 맞는지 살펴보세요.

내 머신에만 있는 무언가가 필요한 작업이라면 로컬에서 하세요. 실제 로컬 데이터가 든 데이터베이스, VPN으로 접속하는 서비스, GPU, 휴대폰 시뮬레이터, 책상 위의 하드웨어가 여기에 해당합니다. 변경 사항을 몇 초 안에 내 브라우저에서 바로 확인하고 싶은 빠른 시각적 반복 작업도 로컬이 낫습니다. 조직이 클라우드 세션이 꺼지는 Zero Data Retention으로 운영되는 경우에도 로컬을 써야 합니다.

두 방식의 중간에 있는 기능도 두 가지 있습니다. 원격 제어는 세션을 내 머신에 둔 채 휴대폰이나 브라우저에서 조작할 수 있게 해 줍니다. Team과 Enterprise에서 베타로 제공되는 셀프 호스팅 환경은 클라우드 세션을 조직의 자체 인프라에서 실행하므로 사설 네트워크에도 접근할 수 있습니다.

이 중 어디에도 해당하지 않는다면 클라우드에 맡기기 좋은 작업입니다. 다음 섹션에서는 클라우드가 특히 효과적인 워크플로를 다룹니다.

클라우드 세션에 잘 맞는 워크플로 일곱 가지

이 워크플로들은 표에서 본 차이를 활용합니다. 작업마다 별도 머신을 쓰고, 자리를 비워도 세션이 계속 돌아가며, 끝나면 검토할 브랜치가 남습니다.

1. 밀린 작업을 병렬로 처리하기

서로 관련 없는 작은 수정이 다섯 개 있다고 해 봅시다. 로컬에서는 하나씩 차례로 하거나, 워크트리 다섯 개를 만들고 포트와 설치를 따로 관리해야 합니다. 클라우드에서는 세션 다섯 개를 시작하고 브랜치 다섯 개를 검토하면 됩니다.

claude --cloud "Fix the flaky test in auth.spec.ts"
claude --cloud "Update the API documentation"
claude --cloud "Refactor the logger to use structured output"

claude --cloud는 현재 브랜치 기준으로 GitHub 원격 저장소를 클론하므로, 로컬 커밋을 먼저 푸시하세요. VM이 시작되는 동안 CLI에는 설정 단계의 체크리스트가 실시간으로 표시되고, 그사이 입력한 내용은 대기열에 쌓입니다.

각 작업은 무엇이 문제인지, 완료 기준이 무엇인지, 어떻게 증명할지를 담은 독립적인 티켓처럼 작성하세요. 불안정한 테스트를 다룬 프롬프트에는 증명 방법이 명시돼 있었습니다. 스위트를 연속으로 30번 이상 실행하라는 것이었고, 세션은 40번을 실행했습니다.

작업들이 더 큰 하나의 과제에 속한다면, 프로젝트(Pro와 Max에서 공개 베타)가 조율용 대화를 실행해 클라우드 세션을 대신 시작하고 추적해 줍니다. 세션은 진행 중, 사용자 응답 대기 중, 검토 준비 완료의 상태별로 묶여 표시됩니다.

2. 수정이 맞다는 증거까지 맡기기

불안정한 테스트는 반복 검증이 필요한 작업의 대표적인 예입니다. 스위트를 계속 되풀이해 돌려야 하는데, 그 반복이 지금 쓰는 머신을 붙잡고 있는 것은 곤란하죠. 클라우드에서는 Claude가 캐시를 고친 뒤 명령어 한 번으로 전체 스위트를 40번 실행했습니다.

VM에는 컴퓨팅 비용이 없고 CPU도 내 것이 아니니, 철저한 검증을 요청하세요. 스위트를 200번 실행하거나, 커밋 50개에 걸쳐 회귀(regression)를 bisect하거나, 느린 통합 테스트 단계를 돌리거나, 문서 세션이 한 것처럼 앱을 띄우고 curl로 호출해 보게 할 수 있습니다.

Claude의 턴은 하나하나가 여전히 요금제 사용량에 포함되지만, 명령어 하나 안에서 긴 테스트를 돌리는 비용은 크지 않습니다. 포그라운드 명령어는 기본적으로 2분(최대 10분) 후 시간 초과되고, 이후 최대 30분 더 백그라운드에서 계속 실행됩니다. 환경 변수에 BASH_DEFAULT_TIMEOUT_MS와 BASH_MAX_TIMEOUT_MS을 설정하면 이 기본값을 늘릴 수 있습니다.

3. 책상에서 계획하고, 클라우드에서 만들고, 터미널에서 마무리하기

규모가 큰 변경이라면 의견을 주고받는 비용이 적게 드는 곳에서 먼저 접근 방식을 합의하세요. 계획 모드에서 Claude를 시작해 함께 계획을 세운 뒤, 그 계획을 커밋하고 푸시합니다.

claude --permission-mode plan
# ...agree on the plan, save it to docs/migration-plan.md, commit and push...
claude --cloud "Execute the migration plan in docs/migration-plan.md"

클라우드 세션이 작업하는 동안 터미널은 다른 일에 쓸 수 있습니다. 작업이 끝나면 세션을 내려받아 직접 마무리하세요.

claude --teleport            # pick a cloud session
claude --teleport <session-id>

텔레포트는 같은 저장소인지 확인하고, 세션의 브랜치를 가져와 체크아웃한 뒤, 전체 대화를 터미널로 불러옵니다. 작업 트리가 깨끗해야 하고(스태시를 제안해 줍니다), 브랜치는 푸시되어 있어야 합니다. Claude Code 안에서는 /teleport(또는 /tp)로 같은 선택 화면을 열 수 있고, /tasks 다음 t도 같은 역할을 합니다. 데스크톱 앱은 반대 방향도 지원해서, Open in 메뉴로 로컬 세션을 클라우드로 보낼 수 있습니다.

4. 휴대폰으로 확인하기

Claude 앱의 Code 탭은 같은 세션에 연결됩니다. 휴대폰에서 작업을 시작하고, 진행 상황을 지켜보고, 방향을 조정하고, Claude의 질문에 답하거나, 풀 리퀘스트를 지켜보라고 시킬 수 있습니다.

휴대폰은 키보드 앞에 앉을 때쯤이면 잊어버릴 만한 질문을 던지기에 좋습니다. 네 번째 세션에는 휴대폰에서 입력할 법한 질문을 던졌습니다. tidepool은 조수를 어떻게 예측하는지, 시간 구간의 경계에서는 어떤 문제가 생길 수 있는지였습니다. Claude는 코드를 실행해 답을 검증했고 실제 버그를 찾았습니다. 루프가 첫 번째와 마지막 샘플을 검사하지 않아서, 구간이 시작되는 정확한 시점의 만조를 API가 놓친다는 것이었습니다.

5. CI 실패와 리뷰 코멘트를 Claude에게 넘기기

저장소에 Claude GitHub 앱이 설치되어 있으면 클라우드 세션이 풀 리퀘스트를 지켜보다가 일어나는 일에 대응할 수 있습니다. claude.ai/code의 세션에서 CI 바를 열고 Auto-fix를 켜세요. 터미널에서 PR 브랜치에 /autofix-pr를 실행하거나, 모바일 앱에 PR을 지켜보라고 요청하거나, 세션에 PR URL을 붙여 넣는 방법도 있습니다.

Claude는 실패한 체크와 리뷰 코멘트 중 해결 방법이 분명한 것은 수정을 푸시하고 무엇을 바꿨는지 설명합니다. 모호하거나 아키텍처에 관련된 사안은 사용자에게 물어봅니다. 리뷰 스레드의 답글은 내 GitHub 사용자 이름으로 게시되며 Claude Code라는 라벨이 붙습니다. 베이스 브랜치와의 병합 충돌은 Claude에 알림이 가지 않으므로 리베이스를 요청하세요. 또한 Claude의 코멘트가 Atlantis 같은 코멘트 기반 자동화를 작동시킬 수도 있습니다.

6. 직접 시작하지 않고 작업 시작하기

루틴(리서치 프리뷰)은 프롬프트, 저장소, 커넥터, 환경처럼 하나의 작업을 수행하도록 저장해 둔 여러 리소스의 묶음입니다. 실행할 때마다 트리거가 클라우드 세션을 시작합니다. 트리거는 스케줄(최소 간격은 1시간), 루틴 전용 엔드포인트로 보내는 HTTP 호출, 풀 리퀘스트 오픈이나 릴리스 같은 GitHub 이벤트가 될 수 있습니다. claude.ai/code/routines나 데스크톱 앱에서, 또는 CLI에서 /schedule로 만들 수 있습니다. 루틴은 승인 프롬프트 없이 실행되며, 기본적으로 claude/ 접두사가 붙은 브랜치에 푸시합니다.

여기에 도움이 되는 작은 도구가 두 가지 있습니다. 로그인한 어떤 머신에서든(CI 작업 포함) 실행 중인 세션에 후속 요청을 대기열로 넣을 수 있습니다.

claude -p "The integration tier is green now; rebase on main and push" --cloud <session-id>

미리 채워 둔 세션을 북마크해 둘 수도 있습니다. claude.ai/code?prompt=Triage+the+newest+issues&repositories=acme-labs/tidepool 같은 URL을 열면 프롬프트와 저장소가 이미 입력된 상태로 claude.ai/code가 열립니다.

7. 완전히 믿기 어려운 코드 실행하기

외부 기여자의 풀 리퀘스트, 새 의존성의 설치 스크립트, 5분 전에 클론한 저장소는 모두 읽어 보지 않은 코드를 실행할 수 있습니다. 노트북에서는 그런 코드가 SSH 키, 클라우드 CLI 세션, 브라우저 프로필 바로 옆에서 실행됩니다. 클라우드 세션에서는 이런 것이 하나도 없는 일회용 VM에서, 세션 범위의 GitHub 자격 증명과 좁힐 수 있는 네트워크만 가진 채 실행됩니다.

가장 엄격하게 실행하려면 환경의 네트워크 접근을 None으로 설정하세요. 패키지 레지스트리, GitHub, 주요 클라우드 SDK 호스트를 허용하는 Trusted를 유지해도 됩니다. None으로 설정해도 Claude Code는 Anthropic API로 요청을 보내므로 그 경로로 데이터가 VM 밖으로 나갈 수 있고, 세션은 자기 브랜치에 푸시할 수도 있습니다. 모든 아웃바운드 트래픽은 호스트 이름을 기록하는 프록시를 거칩니다.

막힘없이 GitHub 연동하기

첫 클라우드 세션이 잘 안 풀린다면 가장 흔한 원인은 GitHub입니다. 문제 대부분은 클라우드 세션에 서로 다른 GitHub 권한 두 가지가 필요하다는 데서 비롯됩니다.

• GitHub로 로그인하면 Claude가 내가 누구인지 알 수 있습니다.
• 계정이나 조직에 Claude GitHub 앱을 설치하면 Claude가 그곳의 어떤 비공개 저장소를 볼 수 있는지가 정해집니다.

공개 저장소는 첫 번째만으로 충분합니다. 비공개 저장소는 해당 저장소를 소유한 계정이나 조직에 두 번째 권한도 있어야 합니다. GitHub를 연결했는데 비공개 저장소가 보이지 않는다면, 대개 그 저장소를 소유한 계정이나 조직에 앱이 설치되어 있지 않은 것입니다.

방법 A: 브라우저에서 연결하기(권장)

claude.ai/connect-github에서 GitHub 계정을 연결한 다음, 저장소를 소유한 계정이나 조직에 Claude GitHub 앱을 설치하세요. 조직이라면 보통 소유자가 설치를 승인해야 합니다. 각 단계는 퀵스타트에 자세히 나와 있습니다.

GitHub가 claude.ai/code로 돌려보내지 않는다면, claude.ai/connect-github의 연결 페이지에서 흔한 원인을 짚어 주는 간단한 체크리스트를 볼 수 있습니다. 그중 하나가 싱글 사인온 단계로, 이를 건너뛰면 조직의 저장소가 보이지 않습니다.

Auto-fix, GitHub 트리거 루틴, 프로젝트도 앱에 의존하므로, 다른 방법으로 연결하더라도 앱은 설치하세요.

방법 B: 터미널에서 /web-setup으로 연결하기

이미 gh CLI를 쓰고 있다면 Claude Code 안에서 /web-setup을 실행해 gh 토큰을 Claude 계정으로 전송하세요. 그러면 앱 설치 여부와 관계없이 세션이 그 토큰으로 접근할 수 있는 모든 저장소에 접근할 수 있습니다. 자세한 과정은 터미널에서 연결하기를 참고하세요. Team과 Enterprise 요금제에서는 소유자가 먼저 빠른 설정(Quick setup)을 켜야 합니다.

방법 C: 일회성 작업이면 GitHub 건너뛰기

GitHub 원격 저장소가 없거나 앱이 설치되지 않은 저장소에서 claude --cloud을 실행하면, Claude Code가 저장소를 클론하는 대신 번들로 묶어 업로드합니다. 세션이 결과를 푸시할 수 있는 것은 내 GitHub 연결에 해당 저장소의 푸시 권한이 있을 때뿐입니다. 번들에 포함되는 항목과 제외되는 항목은 문서의 번들 구성에서 확인할 수 있습니다.

Team이나 Enterprise를 사용한다면

소유자가 확인할 체크리스트는 짧습니다. claude.ai/admin-settings/connectors에서 GitHub 커넥터를 켜고, Claude Code 관리자 설정에서 클라우드 세션을 허용하고, 조직의 저장소에 Claude GitHub 앱을 설치하거나(또는 구성원의 요청을 승인하고), 빠른 설정을 켤지 결정하면 됩니다. IP 허용 목록을 쓰는 조직이나 GitHub Enterprise Server를 쓰는 조직은 단계가 하나 더 있습니다. IP 허용 목록과 GitHub Enterprise Server 문서를 참고하세요.

그래도 해결되지 않을 때

그 밖의 문제는 문서의 문제 해결을 참고하세요. GitHub를 연결했는데 저장소가 나타나지 않는 경우도 다룹니다. GitHub 연결을 완전히 해제하려면 claude.ai/customize/connectors를 이용하세요.

세션이 스스로 결과를 확인할 수 있게 갖춰 주기

테스트를 직접 실행할 수 있는 세션은 결과를 넘기기 전에 스스로 검증합니다. 그렇지 않으면 아무도 실행해 보지 않은 변경을 검토해야 합니다. 이 가이드의 데모에서 얻은 가치 대부분은 Claude가 직접 실행해 본 데서 나왔습니다. 스위트 40회 실행, 서버 기동과 curl 호출, 시간 구간 경계에서의 조수 계산이 그 예입니다. 환경 설정에 10분만 들이면 Claude가 이런 검증을 할 수 있습니다.

• 먼저 Default 환경으로 시작하세요. Trusted 네트워크 접근을 쓰고 변수와 설정 스크립트는 없는 구성으로, 대부분의 JavaScript, Python, Go, Rust 저장소에는 이것으로 충분합니다.
• 머신 설정에는 설정 스크립트를 쓰세요. Claude Code가 시작되기 전에 root 권한으로 실행되므로 apt install이 동작합니다. 종료 코드가 0이어야 하며, 그렇지 않으면 세션이 시작되지 않습니다. 환경이 캐시되도록 약 5분 안에 끝나는 것이 좋습니다. 그 후 새 세션은 도구가 디스크에 설치된 스냅샷에서 시작합니다. 캐시는 스크립트나 허용 호스트를 바꿀 때, 그리고 약 7일마다 다시 만들어집니다.
• 프로젝트 설정에는 SessionStart 훅을 쓰세요. npm install 같은 단계는 저장소의 .claude/settings.json에 있는 훅에 넣으면 로컬과 클라우드에서 똑같이 실행됩니다. 클라우드에서만 실행해야 하는 단계라면 CLAUDE_CODE_REMOTE를 확인하세요. 저장소 훅은 단일 저장소 세션에서 로드됩니다.
• 서비스는 세션마다 시작하세요. 캐시에는 파일이 저장될 뿐, 실행 중이던 프로세스는 유지되지 않습니다. Claude에게 service postgresql start를 실행하라고 요청하거나 SessionStart 훅에서 처리하세요.
• 동작하는 범위에서 가장 좁은 네트워크 수준을 고르세요. Trusted는 흔히 쓰는 레지스트리를 포함합니다. 비공개 레지스트리를 추가하려면 Custom을, 작업에 열린 인터넷이 필요할 때만 Full을 쓰세요. 변경 사항은 약 1분 안에 실행 중인 세션에 반영됩니다.
• 공유 변수에 비밀 값을 넣지 마세요. 환경 변수는 그 환경을 쓰는 모든 사람에게 보입니다. Pro와 Max에서는 환경의 API 자격 증명이 지정한 호스트로 가는 요청에 VM 밖에서 키를 붙여 주므로, 키가 변수에 남지 않습니다.
• 명령어는 CLAUDE.md에 적어 두세요. 개인 ~/.claude은 클라우드 VM에 전달되지 않습니다. 통합 테스트를 어떻게 실행하는지 Claude가 알아야 한다면 저장소에 그 내용이 있어야 합니다.

효과를 보는 습관

• 작업 하나에 세션 하나. 작고 독립적인 세션이 검토하기 쉽고 버리기도 부담이 적습니다.
• 증거를 요구하세요. 작업이 끝났음을 증명하는 명령어를 지정하고, diff보다 Claude의 요약을 먼저 읽으세요.
• claude --cloud 전에 푸시하세요. VM은 GitHub에서 클론하므로 푸시하지 않은 커밋은 전달되지 않습니다.
• 긴 작업은 진행하면서 커밋하세요. 유휴 VM은 회수될 수 있습니다.
• diff 뷰에서 검토하세요. 인라인 코멘트는 모아서 다음 메시지로 전달되고, Create PR로 정식 PR, 초안 PR, GitHub의 작성 페이지 중 하나를 열 수 있습니다.
• Claude가 작업하는 동안에도 방향을 잡아 주세요. 작업 중에 보낸 메시지는 대기열에 쌓이고, 대기 중인 메시지는 다시 회수할 수 있습니다.
• 세션을 공유하세요. Team과 Enterprise에서는 세션의 공개 범위를 Team으로 설정하면 리뷰어가 변경이 어떻게 만들어졌는지 읽어 볼 수 있습니다. 클라우드 세션의 커밋에는 트랜스크립트로 연결되는 Claude-Session 트레일러가 붙습니다.
• 사용 한도를 확인하세요. 병렬 세션은 요금제 한도를 동시에 소모하므로, 세션 다섯 개는 하나일 때보다 약 다섯 배 빠르게 한도를 씁니다. 루틴에는 시간당 한도가 따로 있고, 프로젝트는 하루에 최대 200개의 새 스레드를 시작할 수 있습니다.

자주 묻는 질문

누가 클라우드 세션을 쓸 수 있나요? claude.ai 계정으로 로그인한 Pro, Max, Team 요금제 사용자와, 프리미엄 시트 또는 Chat + Claude Code 시트가 있는 Enterprise 사용자입니다. Console API 키나 서드파티 제공업체로는 사용할 수 없습니다. 클라우드 세션 문서를 참고하세요.

내 데이터는 어디로 가나요? Anthropic이 세션 트랜스크립트를 저장하며, 보관 기간은 요금제와 모델 개선 설정에 따라 달라집니다. VM은 일정 시간 활동이 없으면 회수되고, 세션을 삭제하면 해당 데이터도 삭제됩니다. 데이터 사용과 보안을 참고하세요.

Claude가 내 클라우드 세션 데이터로 학습하나요? 클라우드 세션도 Claude Code의 나머지 기능과 같은 정책을 따릅니다. Team, Enterprise, API에서는 조직이 동의하지 않는 한 Anthropic이 코드나 프롬프트로 모델을 학습하지 않습니다. Free, Pro, Max에서는 모델 개선 설정에 따라 달라집니다. 데이터 사용을 참고하세요.

규모가 큰 저장소도 감당할 수 있나요? VM은 약 4 vCPU, 16GB RAM, 30GB 디스크를 갖추고 있습니다. 무거운 설치는 설정 스크립트에 넣어 한 번만 실행되게 하고, 그 결과가 캐시된 스냅샷에 담기게 하세요.

GitLab이나 Bitbucket은요? claude --cloud는 어떤 git 저장소에서든 번들을 업로드할 수 있지만, 세션이 그 호스트로 푸시할 수는 없습니다. GitHub Enterprise Server는 Team과 Enterprise에서 지원됩니다. 플랫폼 제한 사항을 참고하세요.

병렬 브랜치끼리 충돌하면 어떻게 하나요? 세션들은 서로의 존재를 모릅니다. 브랜치 하나를 먼저 병합한 뒤, 다음 세션에 claude -p "rebase on main and fix any conflicts" --cloud <session-id> 같은 후속 요청을 보내세요.

로컬 도구를 잃게 되나요? 사용자 수준 설정은 전달되지 않으므로, 팀에 필요한 것은 저장소로 옮기세요. 스킬과 커맨드는 .claude/ 아래에 커밋하고, 프로젝트 범위의 MCP 서버는 .mcp.json에 추가하고, 테스트 명령어는 CLAUDE.md에 문서화하면 됩니다. 각 세션이 읽는 항목은 클라우드 세션의 설정에 정리되어 있습니다.

5분 만에 시작하기

설정에는 5분 정도 걸립니다. 그 후에는 작업을 맡기고 노트북을 닫은 뒤, 검토할 준비가 된 브랜치를 확인하러 돌아오면 됩니다.

1. claude.ai/code를 열거나, claude.ai 계정으로 로그인한 Claude Code에서 /login를 실행하세요.
2. GitHub를 연결하고, 저장소가 있는 곳에 Claude GitHub 앱을 설치하세요.
3. 저장소와 Default 환경을 선택하세요.
4. 밀린 작업 중 하나를, 완료를 증명할 명령어와 함께 Claude에게 맡기세요.
5. 탭을 닫으세요. 나중에 휴대폰으로 확인한 다음, claude.ai/code에서 diff를 검토하고 풀 리퀘스트를 만들면 됩니다.