Claude Code 원격 세션 활용 — 파이프라인이 아니라 내가 부르는 클라우드, '저장소에 커밋된 것만 존재하는' Anthropic 관리 VM, 준비의 두 층(환경의 Setup script ↔ 저장소의 SessionStart Hook)과 환경 캐싱, `CLAUDE_CODE_REMOTE` 게이트와 환경 변수 세 층, `--cloud`로 보내고 `--teleport`로 끌어오는 왕복, push가 현재 브랜치로 잠기는 GitHub 프록시

들어가며

41차시는 이렇게 끝났다 — “파이프라인이 주도하는 자동화에서, 내가 주도하되 실행만 원격인 세션으로.” 파이프라인의 Claude는 이벤트(push, PR, cron)가 불렀고 나는 결과만 받았다. 이번 차시의 Claude는 내가 부른다. 대화의 주도권은 그대로 내게 있는데, 실행 환경만 내 머신이 아니라 Anthropic 관리 클라우드 VM이다.

이 무대의 이름이 Claude Code on the web — claude.ai/code다. 41차시의 claude ultrareview가 돌던 바로 그 클라우드 샌드박스 인프라에서, 이번엔 리뷰 전용 작업이 아니라 내 세션 전체를 굴린다. 브라우저를 닫아도 세션은 계속 돌고, Claude 모바일 앱에서 지켜볼 수 있다. 현재 research preview 상태로 Pro·Max·Team 사용자, 그리고 프리미엄 시트(또는 Chat + Claude Code 시트)의 Enterprise 사용자에게 열려 있다.

다룰 것은 커리큘럼의 세 목표 그대로다 — 원격 환경에서 실행(클라우드 VM의 성질과 --cloud/--teleport 왕복), 원격 세션 전용 Hook(CLAUDE_CODE_REMOTE 게이트), 환경 변수 관리(세 층으로 갈라 다룬다). 이 차시로 섹션 9(CI/CD 통합)가 닫힌다.

같은 Claude, 무대만 다르다

공식 문서가 실행 방식 네 가지를 표 하나로 비교한다. 판단 기준은 두 개뿐이다 — 코드가 어디서 도는가, 그리고 내 로컬 설정이 보이는가.

	On the web	Remote Control	터미널 CLI	Desktop 앱
코드 실행 위치	Anthropic 클라우드 VM	내 머신	내 머신	내 머신 또는 클라우드 VM
대화하는 곳	claude.ai·모바일 앱	claude.ai·모바일 앱	터미널	Desktop UI
로컬 설정 사용	아니오 — repo만	예	예	로컬=예, 클라우드=아니오
GitHub 필요	예(또는 `--cloud` 번들)	아니오	아니오	클라우드 세션만
접속 끊어도 계속 실행	예	터미널이 열려 있는 동안	아니오	세션 타입에 따라
권한 모드	Accept edits·Plan·Auto	Manual·Accept edits·Plan	전부	세션 타입에 따라

혼동하기 쉬운 이웃부터 정리하자. Remote Control은 반대 방향이다 — 세션은 내 머신에서 돌고, claude.ai나 폰은 그 로컬 세션을 들여다보는 창일 뿐이다(“nothing moves to the cloud”). 이번 차시의 주인공은 왼쪽 열, 코드 자체가 클라우드 VM에서 도는 쪽이다.

공식 문서가 꼽는 어울리는 일은 넷이다 — 병렬 태스크(워크트리 관리 없이 세션·브랜치가 각각 분리), 로컬에 체크아웃이 없는 저장소(매 세션 새로 클론하므로), 자주 조종할 필요 없는 잘 정의된 태스크(맡기고 다른 일 하다가 결과 리뷰), 코드 질문·탐색. 그리고 선을 긋는 문장 —

For work that needs your local config, tools, or environment, running Claude Code locally or using Remote Control is a better fit.

로컬 설정·도구·환경이 필요한 일은 로컬이나 Remote Control이 맞다. 이 구분이 왜 나오는지는 다음 절의 ‘무대의 법칙’에서 분명해진다.

권한 모드도 좁다 — 웹 세션은 Accept edits(기본)·Plan·Auto 셋뿐이고 Manual과 Bypass가 없다. 승인 다이얼로그 앞에 사람이 상주하지 않는 무대라는 뜻이다. 41차시의 CI가 ‘물어볼 사람이 없어서’ 사전 선언으로 갔다면, 클라우드 세션은 ‘물어보면 내가 웹에서 답할 수는 있지만’ 기본 설계는 자율 실행 쪽에 있다.

세션의 한 사이클, 그리고 입장권

태스크를 제출하면 네 단계가 돈다.

클론과 준비 — 저장소가 Anthropic 관리 VM에 클론되고, 설정해 뒀다면 setup script가 돈다
네트워크 구성 — 환경(environment)의 접근 레벨대로 인터넷 접근이 설정된다
작업 — 분석·수정·테스트. 지켜보며 조종해도 되고 떠나 있어도 된다
브랜치 푸시 — 멈춤 지점에서 브랜치를 GitHub에 푸시한다

중요한 디테일 하나 — 푸시해도 세션은 닫히지 않는다. diff 리뷰, PR 생성, 추가 수정이 전부 같은 대화 안에서 이어진다. 39차시에서 배운 ‘PR은 대화의 끝이 아니라 중간’이라는 감각이 여기선 UI로 굳어 있다.

입장권은 GitHub 연결이다. 두 가지 방법이 있다.

방법	동작	어울리는 경우
GitHub App	웹 온보딩에서 Claude GitHub App 승인	브라우저로 시작, Auto-fix를 원하는 팀
`/web-setup`	로컬 `gh` CLI 토큰을 Claude 계정에 동기화	이미 `gh`를 쓰는 개인

/web-setup은 셸이 아니라 Claude Code CLI 안에서 실행하는 명령이고(v2.1.80+, claude.ai 구독 인증 필요), 클라우드 환경이 없으면 Trusted 네트워크의 기본 환경까지 만들어 준다. 그리고 접근 범위에 대한 공식 문서의 주의 하나를 정확히 읽어 두자 —

a cloud session can access any repository the connecting GitHub account can see, not just the repositories the Claude GitHub App is installed on. App installation … is not a session-level access control.

어느 방법이든 클라우드 세션은 연결된 GitHub 계정이 볼 수 있는 모든 저장소에 접근할 수 있다. App을 특정 저장소에만 설치했다고 접근이 거기로 제한되는 게 아니다 — App 설치는 Auto-fix용 PR 웹훅을 켜는 일이지 접근 제어가 아니며, 제한하려면 GitHub 쪽에서 계정의 권한 자체를 줄여야 한다. 참고로 Zero Data Retention을 켠 조직은 클라우드 세션 기능 전체를 쓸 수 없고, 조직에 IP allowlist가 걸려 있으면 세션이 Anthropic 인프라에서 API를 부르므로 전부 인증 오류로 실패한다(Code Review·Routines도 동일).

무대의 법칙 — 저장소에 커밋된 것만 존재한다

각 세션은 새 VM + 저장소 fresh clone에서 시작한다. 공식 문서의 두 문장이 이 무대의 법칙이다.

Anything committed to the repo is available. Anything you’ve installed or configured only on your own machine isn’t available in the session.

커밋된 것만 존재한다. 표로 보면 명확하다.

	클라우드 세션에서	이유
repo의 `CLAUDE.md`(21차시)	있음	클론의 일부
repo의 `.claude/settings.json` 훅(28~31차시)	있음	클론의 일부
repo의 `.mcp.json`(35차시)	있음	클론의 일부
repo의 `.claude/rules/`·skills·agents·commands(23~27차시)	있음	클론의 일부
repo 설정에 선언한 플러그인	있음	세션 시작 시 마켓플레이스에서 설치
조직의 server-managed settings	있음	Anthropic 서버에서 별도 수신
`~/.claude/CLAUDE.md`·skills·agents·commands	없음	내 머신에 산다 — repo의 `.claude/`에 커밋할 것
`claude mcp add`로 넣은 MCP 서버	없음	로컬 사용자 설정에 기록 — `.mcp.json`에 선언할 것
정적 API 토큰·자격증명	없음	전용 시크릿 스토어가 아직 없다(아래 참고)
AWS SSO 같은 인터랙티브 인증	없음	브라우저 로그인이 클라우드 세션에서 불가

41차시의 --bare와 나란히 놓으면 재미있는 대칭이 보인다. --bare는 로컬에 컨텍스트가 있는데 안 읽는 선택이었고, 클라우드 세션은 저장소 밖 컨텍스트가 아예 없는 무대다. 결론은 같은 방향을 가리킨다 — 팀과 공유할 설정은 저장소의 .claude/에 커밋하라. 23차시에서 협업 원칙으로 배운 그 문장이, 클라우드 세션에선 동작 조건이 된다.

한 가지 더, 보안 감각이 필요한 대목 —

A dedicated secrets store is not yet available. Both environment variables and setup scripts are stored in the environment configuration, visible to anyone who can edit that environment.

전용 시크릿 스토어가 아직 없다. 환경에 넣은 환경 변수와 setup script는 그 환경을 편집할 수 있는 사람에게 보인다. 41차시의 “키는 시크릿으로” 규율이 여기선 ‘넣더라도 그 가시성을 알고 넣는다’로 바뀐다.

무대 자체의 사양도 알아 두자. 리소스는 대략 4 vCPU / 16GB RAM / 30GB 디스크(초과 워크로드는 Remote Control로 자기 하드웨어에서). 언어 런타임은 넉넉히 깔려 있다 — Python 3.x(pytest·ruff 포함), Node 20/21/22(nvm), Ruby, PHP, Java(OpenJDK 21), Go, Rust, C/C++, 그리고 Docker와 PostgreSQL 16·Redis 7.0까지. 정확한 버전이 궁금하면 클라우드 세션에서 check-tools를 실행해 달라고 하면 된다 — 이 명령은 클라우드 세션에만 존재한다. DB 둘은 설치만 되어 있고 꺼져 있으므로 세션에서 service postgresql start처럼 켠다.

의외의 부재 하나 — gh CLI가 없다. 대신 내장 GitHub 도구(이슈 읽기, PR 목록, diff, 코멘트)가 있는데, 이 도구들은 GitHub 프록시로 인증해서 내 토큰이 컨테이너 안에 들어가지 않는다. gh release처럼 내장 도구 밖의 명령이 필요할 때만 setup script로 apt install -y gh 하고 환경 변수 GH_TOKEN을 준다(gh가 자동 인식하므로 gh auth login 불필요).

준비의 두 층 — Setup script와 SessionStart Hook

클라우드 **환경(environment)**은 세 가지를 담는 단위다 — 네트워크 접근 레벨, 환경 변수, 그리고 setup script. 관리는 웹 UI에서 하고, 터미널의 /remote-env는 CLI발 클라우드 세션이 쓸 기본 환경을 고르는 것만 한다(추가·편집·보관은 웹에서).

Setup script는 새 클라우드 세션이 시작될 때, Claude Code가 뜨기 전에 도는 Bash 스크립트다. Ubuntu 24.04에서 root로 실행되므로 apt install이 그냥 된다. 성질 세 개가 실무를 좌우한다.

non-zero exit면 세션이 아예 안 뜬다. 비핵심 명령엔 || true를 붙이고, 디버깅은 첫 줄에 set -x.
총 실행 ~5분 예산. 이 안에 끝나야 환경 캐시가 빌드된다. 독립 설치는 &와 wait로 병렬화하고, 안 들어가는 큰 다운로드는 SessionStart hook에서 백그라운드로 넘긴다.
결과는 캐싱된다. 첫 실행 후 Anthropic이 파일시스템을 스냅샷 떠서, 이후 세션은 setup script를 건너뛰고 그 스냅샷에서 시작한다. 재빌드는 스크립트나 허용 네트워크 호스트를 바꿨을 때, 그리고 캐시 만료(~7일) 때다. 세션 resume은 절대 재실행하지 않는다. 캐시는 파일만 담는다 — 서비스·컨테이너 같은 프로세스는 매 세션 다시 시작해야 한다.

그럼 npm install은 어디에 두나? 공식 문서가 두 층의 구분 기준을 한 문장으로 준다.

Use a setup script to install things the cloud needs but your laptop already has, like a language runtime or CLI tool. Use a SessionStart hook for project setup that should run everywhere, cloud and local, like npm install.

클라우드엔 없는데 내 노트북엔 있는 것 — 언어 런타임, CLI 도구 — 은 setup script. 어디서나 필요한 프로젝트 셋업 — 의존성 설치 — 은 SessionStart hook. 나머지 차이도 표로 정리돼 있다.

	Setup script	SessionStart hook
붙는 곳	클라우드 환경	저장소
설정 위치	클라우드 환경 UI	repo `.claude/settings.json`
실행 시점	Claude Code 실행 전, 캐시 없을 때만	Claude Code 실행 후, 매 세션(재개 포함)
적용 범위	클라우드 환경 전용	로컬+클라우드 양쪽

로컬 ~/.claude/settings.json의 SessionStart hook은 무대의 법칙대로 클라우드에 오지 않는다 — 클라우드에서 hook의 출처는 repo와 server-managed settings뿐이다.

원격 전용 Hook — `CLAUDE_CODE_REMOTE` 게이트

31차시 패턴 2에서 이미 만난 스크립트가 여기서 공식 예제로 재등장한다. 그땐 hook의 관점에서 봤다면, 이번엔 그 hook이 도는 무대의 관점이다. repo의 .claude/settings.json에 SessionStart hook을 건다.

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

scripts/install_pkgs.sh를 만들고 chmod +x 한다.

#!/bin/bash

if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

npm install
pip install -r requirements.txt
exit 0

게이트의 근거는 hooks 문서의 정의다 —

The $CLAUDE_CODE_REMOTE environment variable is set to "true" in remote web environments and not set in the local CLI.

클라우드 세션에서만 "true", 로컬 CLI에선 세팅 자체가 안 된다. 31차시의 뉘앙스도 그대로 유효하다 — SSH로 들어간 원격 서버는 이 변수 기준으론 그냥 로컬이다. 이 변수는 ‘지리적 원격’이 아니라 정확히 Claude Code on the web의 클라우드 세션 신호다.

왜 게이트가 필요한가? 공식 문서가 클라우드에서의 SessionStart hook 제약 네 개를 명시한다.

클라우드 전용 스코핑이 없다 — hook은 로컬·클라우드 양쪽에서 돈다. 로컬을 건너뛰는 방법이 바로 위의 CLAUDE_CODE_REMOTE 체크다.
네트워크가 필요하다 — 환경이 None 레벨이면 설치가 실패한다. 기본 Trusted의 allowlist가 npm·PyPI·RubyGems·crates.io를 커버한다.
프록시 호환성 — 모든 outbound가 보안 프록시를 통과하는데, 일부 패키지 매니저가 이 프록시와 안 맞는다. Bun이 알려진 예다.
시작 지연 — setup script와 달리 캐싱 혜택이 없어 매 시작·재개마다 돈다. 이미 설치돼 있는지 체크해서 빠르게 유지하라는 게 공식 조언이다.

환경 변수 — 세 층으로 갈라 관리한다

커리큘럼의 세 번째 목표. 원격 세션의 환경 변수는 출처가 셋이라 층을 갈라 봐야 헷갈리지 않는다.

층 ① — 환경 설정의 변수. 세션 밖에서, 웹 UI의 환경 설정에 넣는 값이다. .env 형식으로 한 줄에 KEY=value 하나씩 쓰고, 값을 따옴표로 감싸지 않는다 — 따옴표가 값의 일부로 저장된다. 그 환경으로 시작하는 모든 세션에 공통 적용되고, 앞서 본 대로 환경 편집 권한자에게 보인다.

NODE_ENV=development
LOG_LEVEL=debug
DATABASE_URL=postgres://localhost:5432/myapp

층 ② — hook이 세션 안에서 심는 변수. 31차시에서 배운 CLAUDE_ENV_FILE 메커니즘 그대로다. SessionStart hook이 이 파일에 export 문을 append하면, 이후 Claude Code가 실행하는 모든 Bash 명령에 그 변수가 적용된다. nvm 버전 선택처럼 ‘명령을 돌려야 결정되는’ 환경이 이 층의 몫이다.

if [ -n "$CLAUDE_ENV_FILE" ]; then
  echo 'export PATH="$PATH:./node_modules/.bin"' >> "$CLAUDE_ENV_FILE"
fi

층 ③ — 시스템이 주는 신호. 내가 넣는 게 아니라 무대가 넣어 주는 변수들이다.

변수	의미
`CLAUDE_CODE_REMOTE`	클라우드 세션이면 `"true"`, 로컬 CLI면 미설정 — 원격 분기 게이트
`CLAUDE_CODE_REMOTE_SESSION_ID`	세션이 자기 ID를 읽는 변수 — 결과물에 추적 링크를 심는 용도
`CLAUDE_PROJECT_DIR`	프로젝트 루트 절대 경로 — hook 스크립트 경로의 기준점

가운데 것이 재미있다. 클라우드 세션의 커밋에는 v2.1.179부터 Claude-Session: <url> git trailer가 붙고 PR 본문에도 세션 URL이 들어간다 — 리뷰어가 ‘이 코드를 만든 실행’을 열어볼 수 있다(38차시 Co-Authored-By가 누가였다면 이건 어느 세션이다. 끄려면 v2.1.182+의 attribution.sessionUrl: false). 커밋·PR 밖의 산출물에 링크를 넣고 싶으면 변수의 cse_ 접두사를 URL의 session_으로 바꾼다.

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID/#cse_/session_}"

네트워크 — 기본은 잠겨 있다

환경마다 접근 레벨 하나를 고른다. 기본은 Trusted다.

레벨	허용되는 outbound
None	없음
Trusted	allowlist 도메인만 — 패키지 레지스트리, GitHub, 클라우드 SDK
Full	모든 도메인
Custom	내가 정한 allowlist(± 기본 목록 포함 체크박스)

Trusted의 기본 allowlist는 npm·PyPI·RubyGems·crates.io·Go proxy·Maven 같은 패키지 레지스트리부터 Docker Hub·ghcr.io 같은 컨테이너 레지스트리, 주요 클라우드 도메인까지 꽤 넓다. 사내 API처럼 목록 밖 도메인이 필요하면 Custom에서 한 줄에 하나씩 추가한다 — *.internal.example.com처럼 *. 와일드카드 서브도메인도 된다.

이 설정과 별개로 도는 배관이 둘 있다.

GitHub 프록시. 모든 git 작업은 네트워크 레벨과 무관하게 전용 프록시를 탄다. 샌드박스 안의 git 클라이언트는 스코프된 임시 자격증명만 갖고, 프록시가 그걸 검증해 실제 GitHub 토큰으로 바꾼다 — 진짜 토큰은 컨테이너에 들어오지 않는다. 그리고 안전장치 하나가 프로토콜 레벨에 박혀 있다. git push가 현재 작업 브랜치로 제한된다. 37차시의 “파괴적 git 명령 금지” 원칙이 여기선 규율이 아니라 인프라다 — main에 직접 푸시하는 사고가 구조적으로 막혀 있다.

보안 프록시. 그 외 모든 outbound HTTP/HTTPS가 통과하는 프록시로, 요청 필터링·rate limiting·호스트명 DNS 감사 추적을 제공한다(SessionStart hook 제약에서 본 Bun 비호환이 이 프록시 때문이다). 참고로 MCP 커넥터 트래픽은 Anthropic 서버를 경유하므로 커넥터의 호스트를 allowlist에 넣지 않아도 동작한다.

격리의 한계도 문서가 정직하게 적어 둔다 —

When running with network access disabled, Claude Code can still communicate with the Anthropic API, which may allow data to exit the VM.

네트워크를 None으로 잠가도 Anthropic API와의 통신은 살아 있다 — 데이터가 VM을 나갈 경로가 완전히 0은 아니라는 뜻이다. 격리 모델을 평가할 때 기억해 둘 문장이다.

왕복 — `--cloud`로 보내고 `--teleport`로 끌어온다

웹 UI에서 시작해도 되지만, 이 시리즈의 독자라면 터미널에서 오갈 것이다.

터미널 → 웹: `claude --cloud`

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

새 클라우드 세션이 만들어지고, 현재 디렉토리의 GitHub remote를 현재 브랜치에서 클론해 작업을 시작한다. 여기에 이 절 최대의 함정이 있다 — VM은 GitHub에서 클론하지, 내 머신에서 가져가지 않는다. 로컬에만 있는 커밋은 먼저 push해야 클라우드에 존재한다. 예전 표기 --remote는 deprecated alias로 아직 동작하고, --remote-control은 전혀 다른 기능(로컬 세션을 웹에서 보는 Remote Control)이니 헷갈리지 말 것.

--cloud를 여러 번 부르면 각각 독립 세션으로 병렬 실행되고, 진행은 /tasks로 본다. 공식 문서가 권하는 협업 패턴이 인상적이다 — plan locally, execute remotely:

claude --permission-mode plan     # 로컬에서 계획을 함께 다듬고
# 계획을 repo에 저장, 커밋, push
claude --cloud "Execute the migration plan in docs/migration-plan.md"

전략은 내 손에서, 실행은 클라우드에서. 계획 자체를 클라우드에서 만들고 브라우저로 리뷰하는 변형이 ultraplan이다.

GitHub에 연결 안 된 저장소도 보낼 수 있다 — 이 경우 로컬 저장소를 번들로 묶어 업로드한다(전 브랜치 히스토리 + 추적 파일의 미커밋 변경 포함). GitHub이 연결돼 있어도 강제하려면 CCR_FORCE_BUNDLE=1. 제한이 있다: 커밋이 하나 이상 있는 git 저장소여야 하고, 100MB 초과면 현재 브랜치만 → squash 스냅샷 순으로 폴백하며, untracked 파일은 안 들어가고(git add 필요), GitHub 인증이 없으면 결과를 원격에 push하지 못한다.

웹 → 터미널: teleport

반대 방향은 넷 중 아무거나 —

claude --teleport — 인터랙티브 세션 피커(특정 세션은 claude --teleport <session-id>)
세션 안에서 /teleport 또는 /tp
/tasks 목록에서 t
웹 UI의 Open in CLI — 붙여넣을 명령을 복사해 준다

teleport는 세 가지를 한다 — 올바른 저장소인지 확인하고, 클라우드 세션의 브랜치를 fetch+checkout하고, 대화 이력 전체를 터미널에 로드한다. --resume과는 다르다 — resume은 이 머신의 로컬 이력만 뒤지고 클라우드 세션을 보여 주지 않는다. teleport가 클라우드 세션과 그 브랜치를 끌어오는 쪽이다.

요구사항 네 개를 채워야 한다.

요구사항	내용
깨끗한 git 상태	미커밋 변경이 있으면 stash 프롬프트가 뜬다
같은 저장소	같은 repo의 체크아웃에서 실행(포크 불가)
브랜치 존재	클라우드 세션의 브랜치가 원격에 푸시돼 있어야 한다
같은 계정	클라우드 세션과 같은 claude.ai 계정으로 인증

그리고 41차시 ultrareview에서 본 것과 같은 인증 제약 — teleport는 claude.ai 구독 인증이 필요하다. API 키·Bedrock·Google Cloud Agent Platform·Microsoft Foundry 인증으로는 안 되고 /login으로 claude.ai 계정에 로그인해야 한다. 같은 인프라를 타는 기능들이 같은 제약을 공유하는 셈이다.

웹에서의 세션 운영, 그리고 Auto-fix PR

웹 세션 안의 사용감에서 알아 둘 것들.

명령의 가부. /compact(포커스 지시 가능)와 /context는 되고, /clear는 없다 — 새 세션을 사이드바에서 만든다. /plugin·/resume 같은 터미널 전용 명령도 없다. v2.1.205부터 /model sonnet처럼 인자를 붙이는 형태로 /model·/effort·/rename 등이 동작한다(터미널의 피커·슬라이더 대신). 컨텍스트가 차면 자동 compact가 돌고, 더 일찍 돌리고 싶으면 환경 변수 CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70처럼 트리거 시점을 당길 수 있다. 서브에이전트는 로컬과 똑같이 동작하고 repo의 .claude/agents/도 자동 인식된다.

리뷰 루프. 세션의 diff 인디케이터(+42 -18)를 열면 diff 뷰가 뜨고, 라인을 골라 인라인 코멘트를 남길 수 있다 — 코멘트는 큐에 쌓였다가 다음 메시지와 함께 번들로 전달된다(“at src/auth.ts:47, don’t catch the error here” 식으로). 다 됐으면 Create PR(정식/드래프트/GitHub compose 페이지). 참고로 https://claude.ai/code?prompt=...&repositories=owner/repo 식 URL 파라미터로 프롬프트·저장소를 프리필할 수 있어서 이슈 트래커에 ‘이 이슈를 Claude에게’ 버튼을 다는 것도 가능하다.

공유의 가시성. Team·Enterprise 계정은 Private/Team이고 저장소 접근 검증이 기본 켜져 있다. Max·Pro 계정은 Private/Public인데 — 접근 검증이 기본 꺼져 있다. 세션엔 비공개 저장소의 코드·자격증명이 담겨 있을 수 있으니 공유 전에 내용을 확인하라는 게 공식 경고다.

세션의 수명. 탭을 닫아도 세션은 계속 돈다 — 설계다. 오래 비활성이면 환경이 회수되고(“environment has expired”), claude.ai/code에서 다시 열면 대화 이력이 복원된 새 환경이 뜬다. 비용 쪽은 41차시 CI와 대비된다 — 러너 분(minute) 개념이 없다. 클라우드 VM에 별도 컴퓨트 과금이 없고, 계정의 rate limit을 다른 Claude 사용과 공유하며 병렬 세션은 비례해서 소모한다.

Auto-fix PR. 41차시와의 다리가 하나 더 있다. 클라우드 세션이 만든(또는 아무) PR에 Auto-fix를 켜면, Claude가 그 PR의 GitHub 이벤트를 구독해서 CI가 실패하거나 리뷰 코멘트가 달리면 조사하고, 수정이 명확하면 고쳐서 푸시한다. 켜는 방법은 넷 — 웹 세션 CI 상태 바의 토글, PR 브랜치 위에서 /autofix-pr(gh로 PR을 감지해 웹 세션 생성+토글까지 한 번에), 모바일 앱에서 지시, 세션에 PR URL을 붙여넣고 지시. PR 단위 토글이고 GitHub App 설치가 필수다. 동작은 세 갈래 — 명확한 수정은 푸시하고 설명, 모호하거나 아키텍처적인 요청은 물어보고, 중복·무조치 이벤트는 기록만. 머지 충돌은 GitHub이 웹훅을 안 쏘기 때문에 자동 대응하지 못한다 — 세션을 열고 rebase를 시키면 된다. 주의 둘: 리뷰 스레드 답글이 내 GitHub 계정으로 달린다(Claude Code 라벨은 붙는다). 그리고 issue_comment로 도는 자동화(Atlantis, Terraform Cloud류)가 있는 저장소라면 Claude의 답글이 그 자동화를 트리거할 수 있으니 Auto-fix를 켜기 전에 저장소의 자동화를 점검하라는 공식 경고가 있다.

흔한 함정

로컬 커밋을 push하지 않고 --cloud를 부른다. VM은 GitHub에서 클론한다 — 내 머신의 미푸시 커밋은 클라우드에 없다.
~/.claude의 스킬·훅·CLAUDE.md가 클라우드에 있길 기대한다. 무대의 법칙 — 커밋된 것만 존재한다. repo의 .claude/로 옮겨 커밋한다.
claude mcp add로 넣은 MCP 서버가 클라우드에 없다. 그건 로컬 사용자 설정이다. 프로젝트 스코프 .mcp.json(35차시)에 선언한다.
환경 변수에 시크릿을 넣고 비밀이라고 생각한다. 전용 시크릿 스토어가 없다 — 환경 편집 권한자에게 보인다는 걸 알고 넣는다.
환경 변수 값을 따옴표로 감싼다. 따옴표째 값으로 저장된다. .env 형식은 맨몸으로.
층을 뒤집는다 — setup script에 npm install을, hook에 대형 툴체인 설치를 넣는다. 반대다: 클라우드에만 필요한 도구는 setup script(캐싱된다), 어디서나 필요한 프로젝트 셋업은 hook.
설치 hook에 CLAUDE_CODE_REMOTE 게이트가 없다. 로컬 매 세션마다 npm install이 돈다. 클라우드 전용 스코핑은 없으니 게이트는 스크립트 안에서 직접.
setup script가 5분을 넘기거나 non-zero로 끝난다. 세션이 아예 안 뜬다. set -x로 디버깅, || true로 비핵심 명령 보호, &+wait로 병렬화, 큰 다운로드는 hook의 백그라운드로.
클라우드 세션에서 gh 명령을 기대한다. 미설치다. 내장 GitHub 도구로 충분한지 먼저 보고, 필요하면 setup script+GH_TOKEN.
teleport가 안 된다고 버그로 안다. 체크리스트 — claude.ai 구독 인증인가(API 키·Bedrock 불가), 작업 트리가 깨끗한가, 같은 저장소인가, 브랜치가 푸시돼 있는가, 같은 계정인가.
App을 설치한 저장소만 접근된다고 믿는다. 연결된 GitHub 계정이 보는 모든 저장소에 세션이 접근할 수 있다. 제한은 GitHub 계정 권한으로.
comment-trigger 자동화가 있는 저장소에 Auto-fix를 켠다. Claude의 답글이 내 계정으로 달리며 Atlantis류 자동화를 트리거할 수 있다 — PR 코멘트가 인프라를 배포하는 저장소라면 끄는 걸 고려한다.

정리

핵심 요점

Claude Code on the web = 주도권은 나, 실행은 Anthropic 클라우드 VM. claude.ai/code에서 세션이 돌고, 브라우저를 닫아도 지속되며, 모바일로 모니터링한다. research preview(Pro·Max·Team·Enterprise 프리미엄 시트), VM 컴퓨트 별도 과금 없음 — 계정 rate limit 공유. Remote Control은 반대 방향(세션은 내 머신, 웹은 창)이다.
무대의 법칙 — 저장소에 커밋된 것만 존재한다. repo의 CLAUDE.md·훅·.mcp.json·rules·skills는 오고, ~/.claude와 claude mcp add는 안 온다. 시크릿 스토어는 아직 없다 — 환경 변수는 환경 편집자에게 보인다. 리소스는 ~4 vCPU/16GB/30GB, gh는 미설치(내장 GitHub 도구가 프록시 인증 — 토큰은 컨테이너 밖).
준비는 두 층. 클라우드에만 필요한 도구는 환경의 setup script(root·Ubuntu 24.04, non-zero면 세션 불발, ~5분 예산, 파일시스템 스냅샷 캐싱 ~7일). 어디서나 필요한 프로젝트 셋업은 저장소의 SessionStart hook(매 세션, 캐싱 없음).
원격 전용 hook의 스위치는 CLAUDE_CODE_REMOTE. 클라우드 세션에서만 "true", 로컬 CLI에선 미설정(SSH 서버도 미설정). 게이트는 스크립트 안에서 직접 건다 — 클라우드 전용 스코핑이 없기 때문. 제약: 네트워크 필요(None이면 실패), 프록시 비호환(Bun), 시작 지연.
환경 변수는 세 층 — 환경 설정의 .env(따옴표 금지), hook이 심는 CLAUDE_ENV_FILE, 시스템 신호(CLAUDE_CODE_REMOTE·CLAUDE_CODE_REMOTE_SESSION_ID·CLAUDE_PROJECT_DIR). 커밋의 Claude-Session: 트레일러로 결과물이 세션으로 역추적된다.
네트워크는 기본 Trusted allowlist. None/Trusted/Full/Custom, *. 와일드카드. GitHub은 독립 프록시 — push가 현재 작업 브랜치로 제한된다(37차시 원칙의 인프라화). 단 None이어도 Anthropic API 통신은 살아 있다.
왕복 — claude --cloud(GitHub에서 클론하니 먼저 push, 없으면 100MB 번들 폴백), plan locally/execute remotely 패턴, /tasks로 병렬 모니터링, --teleport//tp로 회수(깨끗한 트리·같은 저장소·푸시된 브랜치·같은 계정+claude.ai 구독 인증). PR엔 Auto-fix를 켜서 CI 실패·리뷰 코멘트에 자동 대응시킬 수 있다 — 단 답글은 내 계정으로 달린다.

다음 단계

이번 차시 내내 한 문장이 반복됐다 — “~/.claude의 것들은 클라우드에 따라오지 않는다.” 그런데 그 ~/.claude 안에는 정확히 뭐가 있고, 어떻게 생겼나? **43차시(전역 설정 관리)**부터 섹션 10이 열린다 — 무대를 다시 내 머신으로 옮겨 ~/.claude/settings.json의 구조를 해부하고, 권한 설정을 최적화하고, 프록시·네트워크 설정을 다룬다. 원격 세션이 ‘저장소의 설정’만 보는 세계였다면, 이제 ‘내 머신의 설정’이 쌓이는 뿌리를 판다.