클로드 코드 클라우드 세션: 노트북을 덮어도 계속 일하는 에이전트

클로드 코드에 버그 수정을 맡겨 놓고 퇴근하려는데 노트북을 덮으면 작업이 멈춥니다. 🤔 작업 세 개를 동시에 돌리고 싶어도 로컬에서는 git worktree를 여러 개 만들어 가며 브랜치가 섞이지 않게 챙겨야 하고요. 에이전트가 일하는 동안 내 컴퓨터가 계속 켜져 있어야 한다는 게 은근히 발목을 잡습니다.

Anthropic이 2025년 10월 20일에 리서치 프리뷰로 내놓은 Claude Code on the web은 에이전트를 아예 클라우드로 옮겨서 이 문제를 풉니다. 클로드 코드가 내 컴퓨터가 아니라 Anthropic이 관리하는 가상 머신(VM)에서 돌기 때문에 노트북을 덮어도, 폰으로 들여다봐도 작업이 이어지는데요. 이 글에서는 이렇게 클라우드에서 도는 클라우드 세션(cloud session)을 시작하는 법부터 터미널과 세션을 주고받는 법, 실행 환경을 설정하는 법, PR 자동 수정(auto-fix)까지 차례로 살펴보겠습니다.

클라우드 세션이란?

클라우드 세션은 말 그대로 클라우드 인프라에서 실행되는 클로드 코드 세션입니다. 작업을 맡기면 GitHub 저장소를 격리된 VM에 클론하고, 거기서 코드를 고치고 테스트를 돌린 뒤 브랜치를 푸시합니다. 세션은 계정에 묶여 있어서 노트북에서 시작한 작업을 나중에 폰에서 이어 확인할 수 있어요.

처음에는 브라우저의 claude.ai/code에서만 쓰는 기능이라 “Claude Code on the web”이라고 불렀는데요. 지금은 시작할 수 있는 곳이 꽤 늘었습니다. 브라우저 외에도 Claude 모바일 앱의 Code 탭, 데스크톱 앱에서 Local 대신 Cloud를 고른 세션, 터미널의 claude --cloud 명령이 모두 클라우드 세션을 만들어요. 뒤에서 살펴볼 루틴(routine)도 실행될 때마다 클라우드 세션을 하나씩 띄웁니다.

헷갈리기 쉬운 게 클로드 코드 원격 제어인데요. 둘 다 claude.ai/code 화면에서 조작하지만 코드가 실행되는 위치가 완전히 다릅니다.

그래서 쓰임새도 갈립니다. 서로 독립적인 작업 여러 개를 병렬로 돌릴 때, 로컬에 클론해 두지 않은 저장소를 다룰 때, 중간에 자주 개입하지 않아도 되는 잘 정의된 작업을 맡길 때 클라우드 세션이 잘 맞아요. 반대로 내 컴퓨터에만 있는 설정이나 도구, 사내망 같은 환경이 필요하다면 로컬 세션이나 원격 제어가 낫습니다.

사용할 수 있는 플랜은 Pro, Max, Team이고 Enterprise는 프리미엄 좌석이나 Chat + Claude Code 좌석을 가진 사용자만 쓸 수 있습니다.

GitHub 연결하기

클라우드 세션은 GitHub 저장소를 클론해서 일하기 때문에 GitHub 연결이 먼저 필요합니다. 연결하는 방법은 두 가지예요.

첫 번째는 브라우저에서 claude.ai/code에 로그인한 뒤 안내에 따라 GitHub 인증을 승인하는 방법입니다. 이렇게 연결하면 공개 저장소는 어디든 클론할 수 있지만, 비공개 저장소는 Claude GitHub App이 설치된 곳만 다룰 수 있어요. 비공개 저장소를 쓰려면 해당 계정이나 조직에 앱을 설치해 두세요.

두 번째는 이미 GitHub CLI(gh)를 쓰고 있다면 터미널에서 연결하는 방법입니다. 먼저 셸에서 gh에 로그인되어 있는지 확인하고요.

gh auth login

클로드 코드를 claude.ai 계정으로 로그인한 상태에서 /web-setup을 실행합니다. API 키로 인증한 상태라면 이 명령이 아예 보이지 않으니 /login으로 다시 로그인하세요.

/web-setup

그러면 클로드 코드가 gh auth token이 출력하는 토큰을 읽어 확인을 구한 뒤 claude.ai 계정에 암호화해 저장합니다. 이후 내가 시작하는 클라우드 세션은 GitHub App 설치 여부와 상관없이 이 토큰으로 접근할 수 있는 모든 저장소를 다룰 수 있어요. Team과 Enterprise 플랜에서는 Owner가 관리자 설정에서 Quick web setup을 켜야 /web-setup이 나타납니다.

어느 쪽으로 연결하든 GitHub 인증 정보는 Anthropic 서버에 암호화되어 보관되고 세션 VM 안으로는 들어오지 않습니다. VM에서 나가는 GitHub 요청은 프록시를 거치고, 프록시가 서버 쪽에서 인증 정보를 붙여 주는 구조예요. 다만 뒤에서 다룰 PR 자동 수정과 Claude Projects의 스레드는 GitHub App이 설치된 저장소에서만 동작하니, 결국 GitHub App은 설치해 두는 게 낫습니다.

GitHub를 연결하고 나면 Default라는 이름의 클라우드 환경(cloud environment)이 만들어집니다. Pro와 Max 플랜은 자동으로 만들어지고, Team과 Enterprise 플랜은 폼이 뜨는데 기본값 그대로 Create & finish를 누르면 됩니다. 환경이 뭔지는 뒤에서 자세히 보겠습니다.

첫 작업 맡기기

준비가 끝났으면 입력창 아래 저장소 선택기에서 작업할 저장소와 브랜치를 고릅니다. 저장소를 여러 개 골라 한 세션에서 함께 다룰 수도 있어요.

입력창 옆 드롭다운에서는 세션의 권한 모드를 고릅니다. 클라우드 세션에는 세 가지 모드만 있습니다. Accept edits는 승인을 기다리지 않고 코드를 고쳐 브랜치를 푸시하고, Plan은 계획 모드처럼 접근 방식을 먼저 제안한 뒤 승인을 받아야 파일을 고칩니다. Auto는 분류기가 Claude의 행동을 대신 검토하는 모드로, 조직이 허용하고 선택한 모델이 지원할 때만 보여요. 매번 확인을 받는 기본 모드나 모든 권한을 우회하는 모드는 없습니다.

작업 설명은 구체적일수록 좋습니다. “테스트 고쳐줘”보다는 “tests/test_auth.py에서 실패하는 인증 테스트를 고쳐줘”처럼 파일이나 함수 이름을 짚어 주고, 에러 출력이 있으면 그대로 붙여 넣고, 증상보다 기대하는 동작을 적으세요. 클라우드 세션은 중간에 들여다보지 않는 경우가 많아서 로컬보다 첫 지시의 완성도가 결과를 크게 좌우합니다.

작업을 보내면 세션마다 자기만의 VM과 브랜치가 생깁니다. 하나가 끝나기를 기다릴 필요 없이 다음 작업을 바로 던져도 서로 섞이지 않아요.

Claude가 일을 마치면 +42 -18 같은 변경 표시가 나타납니다. 이걸 누르면 diff 화면이 열리는데, 특정 줄을 골라 인라인 코멘트를 남길 수 있어요. 코멘트는 다음 메시지를 보낼 때 함께 묶여 가서 “src/auth.ts:47에서는 에러를 잡지 마” 같은 식으로 위치와 함께 Claude에게 전달됩니다. diff가 마음에 들면 상단의 Create PR로 PR을 만들면 되고요. PR을 만든 뒤에도 세션은 살아 있어서 같은 대화에서 계속 수정을 요청할 수 있습니다.

터미널에서 클라우드로 보내기

클라우드 세션을 꼭 브라우저에서 시작할 필요는 없습니다. 터미널에서 --cloud 플래그를 붙여 작업을 넘기면 새 클라우드 세션이 만들어져요.

claude --cloud "Fix the authentication bug in src/auth/login.ts"

이때 클라우드 VM이 클론하는 건 내 로컬 체크아웃이 아니라 현재 디렉토리의 GitHub 원격 저장소, 그중에서도 현재 브랜치입니다. 그래서 로컬에만 있는 커밋이 있다면 먼저 푸시해야 해요. 예전에는 --remote라는 이름이었는데 지금도 폐기 예정(deprecated) 별칭으로 동작합니다.

--cloud를 여러 번 실행하면 각각 독립된 세션이 동시에 돌아갑니다.

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"

worktree를 관리할 필요도 없고 내 터미널은 그대로 비어 있으니, 자잘한 작업을 한꺼번에 흩뿌려 두기 좋습니다.

복잡한 작업이라면 로컬에서 계획을 세우고 실행만 클라우드에 맡기는 방식도 추천합니다. claude --permission-mode plan으로 계획 모드에서 접근 방식을 다듬은 뒤, 계획을 파일로 저장해 커밋하고 푸시해 두는 거예요. 그다음 이 파일을 실행하라고 클라우드에 넘깁니다.

claude --cloud "Execute the migration plan in docs/migration-plan.md"

GitHub 원격 저장소가 없거나 GitHub App이 설치되지 않은 저장소에서 --cloud를 실행하면 클로드 코드가 로컬 저장소를 번들로 묶어 직접 업로드합니다. 전체 커밋 기록과 추적 중인 파일의 커밋하지 않은 변경까지 올라가는데, .env나 id_rsa, *.pem처럼 인증 정보로 보이는 파일의 변경은 빼고 올려요. 번들은 100MB를 넘으면 안 되고, 추적하지 않는(untracked) 파일은 포함되지 않으니 필요한 파일은 git add해 두세요. GitLab이나 Bitbucket 저장소도 CCR_FORCE_BUNDLE=1을 설정하면 이렇게 번들로 보낼 수 있지만, 결과를 그 원격 저장소로 다시 푸시하지는 못합니다.

CCR_FORCE_BUNDLE=1 claude --cloud "Run the test suite and fix any failures"

이미 돌고 있는 세션에 후속 지시를 보낼 때도 터미널을 쓸 수 있어요. -p와 함께 세션 ID나 claude.ai/code URL을 넘기면 메시지를 큐에 넣고 바로 종료합니다. 성공하면 공식 문서의 예시처럼 세션 ID와 링크가 출력돼요.

claude -p "테스트가 통과하면 CHANGELOG도 업데이트해줘" --cloud session_01DiUkqY2kzbUbDmW1w96rfi

Sent to cloud session.
Session ID: session_01DiUkqY2kzbUbDmW1w96rfi
View: https://claude.ai/code/session_01DiUkqY2kzbUbDmW1w96rfi?from=cli&m=0

응답을 기다리지 않으니 CI 스크립트에서 세션을 조종할 때도 쓸 만합니다.

클라우드에서 터미널로 가져오기

반대로 클라우드에서 하던 작업을 내 터미널로 가져와 이어서 할 수도 있습니다. 이걸 텔레포트(teleport)라고 부르는데요. 세션 목록에서 고르려면 인자 없이, 특정 세션을 바로 가져오려면 세션 ID를 붙여 실행합니다.

claude --teleport
claude --teleport session_01DiUkqY2kzbUbDmW1w96rfi

이미 클로드 코드를 실행 중이라면 /teleport(줄여서 /tp)로 같은 선택 화면을 열 수 있고, /tasks에서 세션을 고른 뒤 t를 눌러도 됩니다. claude.ai/code의 세션 메뉴에서 Open in > Terminal을 고르면 붙여 넣을 명령어를 복사해 주고요.

텔레포트하면 클로드 코드가 같은 저장소인지 확인하고, 클라우드 세션의 브랜치를 가져와 체크아웃한 뒤, 대화 기록 전체를 터미널에 불러옵니다. 작업 디렉토리가 깨끗해야 하는데 커밋하지 않은 변경이 있으면 git stash로 치워 두라고 안내해 줘요. 같은 저장소의 체크아웃이어야 하고 포크에서는 안 되며, 클라우드 세션과 같은 claude.ai 계정으로 로그인되어 있어야 합니다.

주의할 점이 하나 있습니다. 터미널로 가져온 세션은 복사본이라서 이후 로컬에서 한 작업은 claude.ai의 클라우드 세션에 반영되지 않아요. 가져온 뒤에도 폰으로 조종하고 싶다면 로컬 세션에서 /remote-control을 켜면 됩니다. 그리고 CLI에서는 이 이동이 한 방향뿐이라 이미 진행 중인 터미널 세션을 클라우드로 밀어 올릴 수는 없습니다. 그런 흐름이 필요하면 데스크톱 앱의 Continue in 메뉴를 쓰세요.

--resume과 헷갈리기 쉬운데, --resume은 이 컴퓨터의 로컬 기록에서 대화를 다시 여는 것이라 클라우드 세션은 목록에 나오지 않습니다.

클라우드 환경 설정하기

모든 클라우드 세션은 클라우드 환경 안에서 실행됩니다. 환경은 네트워크 접근, 환경 변수, 셋업 스크립트(setup script)를 묶어 저장해 둔 설정인데요. claude.ai/code의 환경 선택기에서 만들고 고칠 수 있고, 브라우저, 터미널, 모바일 앱, 루틴 어디서 세션을 시작하든 같은 환경이 적용됩니다. 터미널의 --cloud가 쓸 기본 환경은 /remote-env로 고를 수 있어요.

입력창 왼쪽 아래의 환경 버튼을 누르고 Cloud로 들어가면 지금까지 만든 환경 목록이 나옵니다. 여기서 환경을 골라 설정 창을 열거나 Add cloud environment로 새 환경을 만들 수 있어요.

가장 먼저 챙길 건 네트워크 접근 수준(access level)입니다. 설정 창의 Network access 드롭다운에서 네 가지 중 하나를 고릅니다.

Default 환경은 Trusted로 만들어집니다. npm, PyPI, RubyGems, crates.io 같은 레지스트리와 Docker Hub는 열려 있어서 대부분의 프로젝트는 그대로 돌아가요. 사내 API처럼 목록에 없는 도메인이 필요하다면 Custom을 고르고 Allowed domains에 한 줄에 하나씩 적습니다. *.internal.example.com처럼 앞에 *.을 붙이면 하위 도메인 전체가 허용되고, Also include default list of common package managers를 체크하면 기본 목록도 함께 유지돼요. 허용되지 않은 호스트로 나가는 요청은 403과 x-deny-reason: host_not_allowed 헤더로 거절되니, 세션에서 이런 에러가 보이면 네트워크 설정부터 의심하면 됩니다. 참고로 None이어도 클로드 코드가 Anthropic API와 통신하는 것까지 막지는 않습니다.

환경 변수는 .env 형식으로 한 줄에 KEY=value 하나씩 적습니다. 여기서 조심할 게 있는데, 환경 변수와 셋업 스크립트는 그 환경을 쓰는 누구나 읽을 수 있어요. 그래서 API 키 같은 비밀 값은 환경 변수에 넣지 않는 게 좋습니다. Pro와 Max 플랜에서는 대신 API 인증 정보(API credentials)로 등록하면 키가 VM 밖에 머물고, 프록시가 지정한 호스트로 가는 요청에만 키를 붙여 줘요.

명령 타임아웃도 환경 변수로 조정합니다. 클로드 코드는 명령 하나를 기본 2분, 최대 10분까지 기다리는데 빌드가 오래 걸리는 프로젝트라면 이렇게 늘릴 수 있어요.

BASH_DEFAULT_TIMEOUT_MS=600000
BASH_MAX_TIMEOUT_MS=1200000

셋업 스크립트와 SessionStart 훅

클라우드 VM은 Ubuntu 24.04(x86_64)이고 자주 쓰는 도구가 미리 깔려 있습니다. Python, Node.js 20, 21, 22, Ruby, PHP, Java, Go, Rust, C/C++ 툴체인에 Docker, PostgreSQL 16, Redis 7.0, gh, jq, ripgrep까지 들어 있어요. 지금 이 글을 쓰는 세션이 마침 클라우드 세션이라, VM 안에 들어 있는 check-tools 명령으로 버전을 확인해 봤습니다.

check-tools

=================== Python ===================
✅ python3: Python 3.11.15
✅ pip: pip 24.0 from /usr/lib/python3/dist-packages/pip (python 3.11)
✅ poetry: Poetry (version 2.3.3)
✅ uv: uv 0.8.17
✅ pytest: pytest 9.0.2
✅ ruff: ruff 0.15.8

=================== NodeJS ===================
✅ node: v22.22.2
✅ npm: 10.9.7
✅ yarn: 1.22.22
✅ eslint: v10.1.0
✅ prettier: 3.8.1

CPU는 4코어, 메모리는 16GB 정도였고요. 공식 문서에 적힌 대략적인 한도도 4 vCPU, 16GB RAM, 30GB 디스크입니다.

목록에 없는 도구가 필요하면 셋업 스크립트를 씁니다. 셋업 스크립트는 새 세션이 시작될 때 클로드 코드가 뜨기 전에 root 권한으로 실행되는 Bash 스크립트예요. 환경 설정 창의 Setup script 칸에 적으면 됩니다.

#!/bin/bash
apt update && apt install -y shellcheck

셋업 스크립트는 매번 도는 게 아닙니다. 처음 세션을 시작할 때 한 번 실행되고, 5분 안에 끝나면 파일 시스템 스냅샷을 떠서 이후 세션의 출발점으로 재사용해요. 이 환경 캐시(environment caching) 덕분에 무거운 툴체인을 설치해도 다음 세션부터는 바로 시작됩니다. 스크립트나 허용 도메인을 바꾸면, 그리고 캐시가 만들어진 지 대략 7일이 지나면 다시 실행되고요.

여기서 흔히 하는 실수가 두 가지 있습니다. 하나는 5분을 넘기는 스크립트예요. 5분을 넘기면 캐시가 만들어지지 않아서 세션이 셋업 단계에서 멈추거나 실패할 수 있습니다. 서로 독립적인 설치는 &와 wait로 병렬로 돌리고, 큰 다운로드는 뒤에서 볼 SessionStart 훅으로 빼세요. 다른 하나는 스크립트에서 띄운 프로세스가 남아 있을 거라고 기대하는 겁니다. 캐시는 파일 시스템 스냅샷이라 설치한 패키지나 받아 둔 Docker 이미지는 남지만, 실행 중이던 데이터베이스나 docker compose up으로 띄운 서비스는 남지 않아요. 그리고 스크립트가 0이 아닌 코드로 끝나면 세션이 시작되지 않으니, 실패해도 괜찮은 명령에는 || true를 붙여 두는 게 안전합니다.

셋업 스크립트와 역할이 겹쳐 보이는 게 바로 이 SessionStart 훅입니다. 구분하는 기준은 단순해요. VM 자체를 준비하는 일, 그러니까 미리 깔려 있지 않은 툴체인이나 CLI 도구 설치는 셋업 스크립트에 둡니다. npm install처럼 클라우드든 로컬이든 프로젝트를 쓸 때마다 필요한 준비는 저장소의 .claude/settings.json에 SessionStart 훅으로 둡니다. 셋업 스크립트는 claude.ai의 환경 설정에 저장되고 캐시가 있으면 건너뛰는 반면, 훅은 저장소에 커밋되고 재개한 세션을 포함해 매번 실행된다는 차이도 있어요.

클라우드에서만 의존성을 설치하고 싶다면 CLAUDE_CODE_REMOTE 환경 변수를 확인하면 됩니다. 먼저 훅을 등록하고요.

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR\"/scripts/install_pkgs.sh"
          }
        ]
      }
    ]
  }
}

스크립트에서는 클라우드가 아니면 바로 빠져나가게 합니다.

#!/bin/bash

# 클라우드 VM에서만 true로 설정되므로 로컬에서는 아무것도 하지 않는다
if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

npm install
pip install -r requirements.txt
exit 0

실제로 이 세션에서 값을 찍어 보면 이렇게 나옵니다.

echo "CLAUDE_CODE_REMOTE=$CLAUDE_CODE_REMOTE"

CLAUDE_CODE_REMOTE=true

한 가지 알아둘 점은 저장소를 여러 개 고른 세션에서는 어느 저장소의 .claude/settings.json 훅도 로드되지 않는다는 겁니다. 그런 세션의 의존성 설치는 셋업 스크립트로 처리해야 해요. 그리고 VM에 Bun이 설치되어 있긴 하지만 프록시와의 호환성 문제로 패키지를 받아 올 때 말썽을 부릴 수 있다고 공식 문서에 적혀 있으니, Bun 프로젝트라면 설치 단계를 한 번 확인해 보세요.

로컬 설정 중 따라오는 것과 안 따라오는 것

클라우드 세션은 저장소를 새로 클론해서 시작하기 때문에 저장소에 커밋된 것만 따라옵니다. 저장소의 CLAUDE.md, .claude/rules/, .claude/skills/, .claude/agents/, .claude/commands/는 그대로 쓸 수 있어요. .claude/settings.json의 훅과 권한 규칙, .mcp.json의 MCP 서버도 저장소 하나짜리 세션이라면 적용됩니다.

반면 내 컴퓨터에만 있는 것은 따라오지 않습니다. ~/.claude/CLAUDE.md, 사용자 수준의 스킬과 에이전트, claude mcp add로 기본 범위에 추가한 MCP 서버, 사용자 설정에서만 켠 플러그인이 모두 해당돼요. 의외인 건 저장소의 .claude/settings.json에서 enabledPlugins로 켠 플러그인도 설치되지 않는다는 점입니다. AWS SSO처럼 브라우저 로그인이 필요한 인증도 쓸 수 없고요.

로컬에서는 잘되던 게 클라우드에서 안 된다면 대부분 이 차이 때문입니다. 클라우드에서도 쓰고 싶은 설정은 저장소에 커밋하는 게 원칙이에요. MCP 서버라면 claude mcp add --scope project로 추가해 .mcp.json에 들어가게 하면 됩니다.

PR 자동 수정

PR을 올리고 나서 CI가 깨지거나 리뷰 코멘트가 달리면 또 한 번 손이 갑니다. 클라우드 세션의 자동 수정은 이 뒷일까지 맡아 주는 기능이에요. 켜 두면 Claude가 PR의 GitHub 활동을 구독하다가 체크가 실패하거나 리뷰어가 코멘트를 남기면 원인을 조사하고, 고칠 방법이 분명하면 수정을 푸시합니다.

켜는 방법은 PR이 어디서 왔는지에 따라 다릅니다. 클라우드 세션에서 만든 PR이라면 세션의 CI 상태 표시줄을 열고 Auto-fix를 선택하면 돼요. 터미널에서는 PR 브랜치에서 /autofix-pr을 실행하면 클로드 코드가 gh로 열린 PR을 찾아 클라우드 세션을 띄우고 자동 수정까지 한 번에 켭니다.

/autofix-pr

이미 있는 PR이라면 아무 세션에나 PR URL을 붙여 넣고 지켜보면서 고쳐 달라고 말해도 됩니다.

Claude가 모든 이벤트에 무조건 코드를 고치는 건 아닙니다. 수정이 명확하고 앞선 지시와 충돌하지 않으면 바로 고쳐 푸시하고, 리뷰 코멘트가 여러 가지로 해석되거나 설계에 영향을 주는 내용이면 먼저 물어봐요. 중복 이벤트나 할 일이 없는 이벤트는 세션에 기록만 남기고 넘어갑니다.

주의할 점도 있습니다. Claude가 리뷰 스레드에 다는 답글은 내 GitHub 계정으로 올라가요. 답글마다 클로드 코드가 쓴 것이라는 표시는 붙지만, 저장소에 PR 코멘트로 동작하는 자동화(issue_comment 이벤트로 도는 GitHub Actions나 Atlantis 같은)가 있다면 Claude의 답글이 그 워크플로우를 건드릴 수 있습니다. 코멘트 하나로 인프라가 배포되는 저장소라면 자동 수정을 켜기 전에 한 번 따져 보세요. 또 GitHub는 기본 브랜치가 앞서 나가 충돌이 생겨도 웹훅을 보내지 않기 때문에, 병합 충돌은 자동으로 처리되지 않고 세션에 들어가 직접 리베이스를 요청해야 합니다.

자동 수정 역시 GitHub App이 설치된 저장소에서만 동작합니다. 저장소 이벤트에 반응하는 자동화가 목적이라면 클로드 코드 GitHub Actions도 비교해 볼 만해요.

클라우드 세션 위에 올라간 기능들

클라우드 세션이 나온 뒤로 Anthropic은 이 위에 기능을 계속 쌓아 왔습니다. 사람이 세션을 직접 띄우지 않아도 무언가가 알아서 띄워 주는 방식이에요.

2026년 4월에 나온 루틴은 프롬프트, 저장소, 커넥터를 한 번 묶어 두고 자동으로 실행하는 기능입니다. 정해진 일정, HTTP API 호출, PR 생성이나 릴리스 같은 GitHub 이벤트를 트리거로 걸 수 있고, 실행될 때마다 클라우드 세션이 하나씩 생겨요. 터미널에서는 /schedule로 대화하듯 만들 수 있고요. 자세한 사용법은 클로드 코드 예약 작업에서 다룹니다.

같은 달에 나온 ultrareview는 코드 리뷰를 클라우드로 보냅니다. /code-review ultra를 실행하면 리뷰어 에이전트 여러 개가 클라우드 샌드박스에서 브랜치나 PR을 살펴보고, 찾아낸 버그를 각각 재현해 검증한 것만 알려줘요. 보통 5분에서 10분 정도 걸리고 백그라운드에서 돌기 때문에 그동안 터미널은 비어 있습니다. Pro와 Max 플랜은 무료 실행 3회가 한 번 주어지고, 그 뒤로는 변경 크기에 따라 1회에 대략 5달러에서 25달러가 사용량 크레딧으로 청구돼요.

그리고 2026년 9월에 재설계된 Claude Projects는 클라우드 세션 여러 개를 띄우고 추적하는 일까지 Claude에게 넘깁니다. 대화 하나에 일감을 던지면 Claude가 스레드를 띄워 병렬로 처리하는데, 이 스레드 하나하나가 곧 클라우드 세션이에요.

알아두면 좋은 제약

마지막으로 클라우드 세션에 작업을 맡기기 전에 알아둘 제약을 정리하겠습니다.

비용부터 보면, 클라우드 VM에 따로 붙는 컴퓨팅 요금은 없습니다. 대신 클라우드 세션은 Claude와 클로드 코드의 다른 사용량과 같은 한도를 나눠 씁니다. 작업을 병렬로 많이 돌리면 그만큼 한도도 빨리 줄어든다는 뜻이에요.

세션은 한동안 아무 일도 없으면 멈추고 VM이 회수됩니다. claude.ai/code에서 세션을 다시 열면 새 VM에 대화 기록을 복원해 이어갈 수 있지만, 그때 돌고 있던 서브 에이전트나 셸 명령은 복원되지 않아요. MCP 커넥터의 도구 호출 승인을 기다리는 시간도 비활성으로 치기 때문에 너무 오래 방치하면 그사이에 만료될 수 있습니다. 반대로 브라우저 탭을 닫는다고 세션이 멈추지는 않아요. Claude가 현재 작업을 끝낼 때까지 백그라운드에서 계속 돕니다.

클라우드 세션에서는 텍스트를 출력하는 내장 명령만 쓸 수 있습니다. /compact와 /context는 되지만 /clear는 안 되니 새 세션을 시작해야 하고, /plugin이나 /resume처럼 터미널 UI 전용 명령도 쓸 수 없어요. /model처럼 선택 화면을 여는 명령은 /model sonnet처럼 값을 인자로 넘기면 됩니다.

저장소 클론과 PR 생성은 GitHub에서만 됩니다. 그리고 --cloud와 --teleport는 claude.ai 계정 로그인이 필요해서 API 키 인증이나 Amazon Bedrock, Google Vertex AI 같은 서드파티 제공자를 통해서는 쓸 수 없어요. 조직에 IP 허용 목록이 걸려 있으면 Anthropic 클라우드에서 나가는 요청이 막혀 세션이 인증 에러로 실패하니, 이 경우에는 Anthropic 지원팀에 예외를 요청해야 합니다.

마치며

클라우드 세션은 클로드 코드를 내 컴퓨터에서 떼어 내 Anthropic의 VM 위에 올려 둔 것입니다. GitHub만 연결하면 브라우저나 폰, 터미널 어디서든 작업을 던져 놓고 노트북을 덮을 수 있어요. --cloud로 보내고 --teleport로 가져오며 터미널과 오갈 수 있고, 환경의 네트워크 수준과 셋업 스크립트로 VM을 프로젝트에 맞출 수 있습니다. PR을 올린 뒤의 CI 실패와 리뷰 코멘트는 자동 수정에 맡기면 되고요.

처음에는 작고 명확한 작업 몇 개를 --cloud로 동시에 보내 보는 걸 추천합니다. 로컬에서 한 번에 하나씩 처리하던 일이 병렬로 끝나는 걸 보면 작업을 나누는 방식 자체가 달라질 거예요. 😊

더 자세한 내용은 Claude Code 공식 문서의 클라우드 세션 가이드를 참고하세요.