Claude Code 클라우드 세션, 브라우저 닫아도 작업 이어가기

# Claude Code 클라우드 세션, 브라우저 닫아도 작업 이어가기

자리를 비운 사이에도 AI 코딩 작업을 계속 돌리고 싶은 개발자를 위한 Claude Code on the web 시작 가이드 (2026년 10월 기준)

퇴근 직전에 AI 코딩 도구에 큰 작업을 맡겨 놓고, 노트북을 덮어도 되는지 고민해 본 적 있으신가요? 😅

터미널에서 돌리는 Claude Code는 내 PC 위에서 동작합니다. 그래서 세션을 닫거나 PC가 멈추면 작업 흐름도 함께 끊기기 쉽죠. 이 글에서 다루는 Claude Code 클라우드 세션은 이 부분을 다르게 풀어 줍니다. 공식 명칭은 Claude Code on the web이고, 브라우저에서 시작하면 작업이 내 PC가 아니라 원격 환경에서 돌아갑니다.

공식 웹 도움말(2026년 3월 16일자)의 설명을 그대로 옮기면, 브라우저에서 GitHub 저장소를 고르고 작업을 맡긴 뒤 페이지를 떠나도 Claude가 원격 환경에서 작업을 이어갑니다. 이 글의 기준은 이 문장 하나입니다. 이 글에서는 이 구조를 따라 시작하는 방법부터 결과를 풀 리퀘스트로 받는 과정, 병렬 작업, 설정 스크립트, 그리고 이름이 비슷해서 자주 헷갈리는 Remote Control과의 차이까지 순서대로 짚어 보겠습니다.

먼저 알아둘 구분: 클라우드 세션과 Remote Control은 다른 기능입니다

자리를 떠난 뒤에도 작업이 이어지길 원한다면 로컬 세션을 원격 조종하는 방식이 아니라 클라우드 세션을 시작해야 합니다. 실습에 들어가기 전에 이 구분부터 잡고 가겠습니다.

두 기능을 나란히 놓고 보면 이렇습니다.

클라우드 세션 (Claude Code on the web)
· 브라우저(claude.ai/code)에서 시작합니다.
· 작업이 격리된 원격 가상 머신에서 실행됩니다.
· GitHub 저장소를 복제해 작업하고, 결과를 새 브랜치로 푸시합니다.
· 시작 후 페이지를 떠나도 원격 환경에서 작업이 이어진다고 공식 도움말이 설명합니다.

Remote Control
· 이름은 비슷하지만 별개의 기능입니다.
· 로컬 세션을 휴대전화나 웹에서 제어하는 기능입니다. 작업 자체는 여전히 내 PC에서 돌아갑니다.
· 공식 팁 문서는 `claude remote-control` 명령으로 모바일 앱에서 새 로컬 세션을 시작할 수 있다고 안내합니다.
· 지원 조건으로 CLI v2.1.51 이상 등이 제시되어 있습니다.

정리하면 Remote Control은 "내 PC 위의 세션에 멀리서 손을 대는 리모컨"이고, 클라우드 세션은 "작업 자체를 원격 환경에 맡기는 방식"입니다. PC가 꺼져도 작업이 이어지기를 기대한다면 선택지는 클라우드 세션입니다.

한 가지 짚어 둘 점이 있습니다. "PC를 끈 뒤에도 계속된다"는 문구는 공식 도움말에서 직접 확인되지 않았습니다. 작업이 원격 가상 머신에서 돌기 때문에 로컬 PC 종료와 무관할 것으로 보이지만, PC를 껐을 때의 동작을 공식 문서가 명시하지는 않습니다. 그래서 이 글은 공식 설명인 "페이지를 떠나도 원격 환경에서 계속된다"를 기준으로 안내합니다. 정말 중요한 작업이라면 처음 한두 번은 짧은 작업으로 직접 테스트해서 감을 잡아 보시길 권합니다.

계정, GitHub 저장소, 커밋·푸시 상태 확인하기

준비물은 많지 않지만, 로컬에서 작업하던 내용이 원격 저장소에 올라가 있는지는 반드시 확인해야 합니다.

시작 전에 아래 네 가지를 점검해 보세요.

① 계정에서 웹 기능을 쓸 수 있는지 확인합니다.
계정·조직 설정에 따라 Claude Code on the web을 쓸 수 없는 경우가 있습니다. 공식 도움말에서 확인되는 사례는 HIPAA-ready 설정을 적용한 Enterprise 조직으로, 이 경우 Claude Code on the web을 사용할 수 없습니다. 조직 계정으로 접속하는데 시작이 안 된다면 이런 설정 때문일 수 있으니 소속 조직의 설정을 먼저 확인해 보세요. 그 밖의 요금·사용량·지원 플랜 조건은 이 글에서 단정하지 않습니다. 본인 계정에서 직접 확인하시는 편이 정확합니다.

② 작업 대상 GitHub 저장소를 준비합니다.
클라우드 세션은 GitHub 저장소를 기반으로 시작합니다. 작업을 맡길 저장소가 GitHub에 있어야 합니다.

③ 로컬 변경사항을 커밋하고 푸시합니다. ⚠️
이 단계가 가장 중요합니다. 클라우드 세션은 GitHub 저장소를 복제해서 시작하므로, 로컬에서 아직 커밋·푸시하지 않은 파일 변경사항이 자동으로 포함된다고 가정하기 어렵습니다. "자동으로 포함되지 않는다"는 문장 자체가 공식 문서에 직접 있는 것은 아니지만, 공식 자료는 미커밋 변경이 있는 로컬 작업에는 터미널 사용을 권합니다. 그러니 로컬 작업물을 클라우드 작업에 반영하고 싶다면 원격 저장소에 올라갔는지 먼저 확인하는 것이 안전합니다.

```bash
git status
git add .
git commit -m "작업 내용 요약"
git push
```

④ CLI 버전을 최신으로 맞춥니다.
이 항목은 브라우저로만 시작한다면 필수는 아닙니다. 다만 로컬에서 Claude Code CLI를 함께 쓴다면 업데이트를 권합니다. GitHub 공식 릴리스 페이지 기준으로 2026년 10월 7일 검색에서 확인되는 최신 공개 버전은 2026년 10월 6일 공개된 v2.1.291입니다. 이 릴리스 노트에는 클라우드 세션의 권한 요청 응답 누락과 종료 시 마지막 메시지 손실 문제 수정이 기재되어 있어, 클라우드 세션을 자주 쓰신다면 업데이트 여부를 확인해 볼 만합니다.

Step 1. claude.ai/code에서 로그인하고 GitHub 저장소 선택하기

시작은 브라우저에서 claude.ai/code에 접속해 로그인하는 것으로 충분합니다. 로컬 PC에 저장소를 복제하거나 개발 환경을 직접 구성하지 않아도 작업을 맡길 수 있다는 점이 클라우드 세션의 큰 장점입니다.

진행 순서는 이렇습니다.

1. 브라우저에서 claude.ai/code에 접속합니다.

2. 계정으로 로그인합니다.

3. GitHub 저장소를 연결하고, 작업을 맡길 저장소를 선택합니다.

GitHub 연동은 이 서비스의 출발점입니다. 인증과 관련해서는 안심해도 되는 부분이 있는데, 공식 도움말은 GitHub 인증 정보를 작업용 가상 머신에 직접 두지 않고 보안 프록시로 관리한다고 설명합니다. 이 내용은 뒤에서 다시 다루겠습니다.

한 가지 팁을 드리자면, 처음 써 보는 단계라면 규모가 작고 영향 범위가 좁은 저장소나 브랜치에서 시작해 보세요. 클라우드 세션이 어떤 식으로 브랜치를 만들고 변경을 올리는지 흐름을 익히는 데는 작은 작업이 가장 좋은 교재입니다.

Step 2. 요청을 입력해 세션을 시작하고 브라우저를 떠나기

저장소를 고른 뒤 요청을 입력하면 세션이 시작되고, 그 이후에는 페이지를 떠나도 원격 환경에서 작업이 이어집니다.

요청 문장을 쓸 때는 결과를 확인하기 쉬운 단위로 쪼개 주는 것이 좋습니다. 다음 두 요청을 비교해 보세요.

· 막연한 요청: "코드 좀 개선해 줘."
· 구체적인 요청: "src/utils 폴더의 날짜 처리 함수들을 점검해서, 타임존 처리가 빠진 곳을 찾아 수정하고 관련 테스트를 추가해 줘."

자리를 비울 작업일수록 요청이 구체적이어야 합니다. 중간에 되물을 상대가 없는 상태에서 돌아오면 결과가 엉뚱한 방향일 수 있기 때문입니다. 요청에 다음 네 가지를 담아 보세요.

① 대상 범위: 어느 폴더·파일·기능인지
② 원하는 결과물: 수정, 테스트 추가, 문서 정리 등
③ 건드리지 말아야 할 것: 변경하면 안 되는 영역
④ 완료 기준: 어떤 상태면 끝난 것으로 볼지

세션이 시작되면 격리된 가상 머신에서 저장소를 복제해 작업이 진행됩니다. 이제 브라우저를 닫아도 공식 설명상 원격 환경에서 작업이 이어집니다. 다시 접속했을 때 웹 인터페이스에서 진행 상황을 확인하고, 필요하면 지시를 보탤 수 있습니다.

Step 3. 격리 환경에서 작업이 도는 방식과 보안 구조 이해하기

세션마다 격리된 가상 머신이 따로 만들어지고, 그 안에서 저장소 복제부터 코드 작업까지 이뤄집니다. 이 구조를 알아 두면 "내 PC에서 하던 것처럼"이라는 가정이 어디서 틀어지는지 미리 파악할 수 있습니다.

공식 도움말이 설명하는 내용을 실무 관점에서 풀어 보겠습니다.

첫째, 인증 정보는 가상 머신에 직접 두지 않습니다.
GitHub 인증 정보는 작업용 가상 머신에 직접 보관되지 않고 보안 프록시를 통해 관리된다고 공식 도움말은 설명합니다. 작업 환경이 격리되어 있어도 인증 정보 관리를 따로 분리해 둔 구조라고 이해하시면 됩니다.

둘째, 네트워크 접근에는 제한이 있습니다.
격리 환경의 네트워크 접근에는 제한이 적용되며, 네트워크 접근 범위를 설정할 수도 있습니다. 로컬 PC에서는 사내 서비스나 로컬 DB에 자유롭게 붙던 작업이, 클라우드 세션에서는 막힐 수 있다는 뜻입니다. 로컬 PC와 동일한 접근 권한을 가진다고 가정하면 안 됩니다.

셋째, 클라우드 세션은 내 PC의 파일이나 도구를 쓰지 않습니다.
작업은 GitHub에서 복제한 저장소를 기준으로 원격 가상 머신 안에서 이뤄집니다. 내 PC에만 설치된 도구, 로컬에만 있는 설정 파일, 로컬 DB 같은 것에 의존하는 작업은 클라우드 세션에 그대로 옮기기 어렵습니다. 작업이 저장소 안의 코드와 설정만으로 재현 가능한지 미리 생각해 보세요.

이 세 가지를 염두에 두면, 클라우드 세션에 맡기기 좋은 작업과 아닌 작업이 자연스럽게 구분됩니다.

맡기기 좋은 작업의 특징
· 저장소 안의 코드만으로 완결되는 작업
· 결과를 브랜치와 풀 리퀘스트로 검토하면 되는 작업
· 시간이 걸리지만 중간 판단이 많이 필요하지 않은 작업

맡기기 어려운 작업의 특징
· 내 PC에만 있는 파일·도구·로컬 서비스가 필요한 작업
· 아직 커밋·푸시하지 않은 변경 위에서 이어 가야 하는 작업

Step 4. 새 브랜치로 푸시된 결과를 검토하고 풀 리퀘스트 만들기

작업 결과는 GitHub의 새 브랜치에 푸시되고, 변경 사항을 검토한 뒤 웹 인터페이스에서 풀 리퀘스트를 만들 수 있습니다. 이 흐름 덕분에 AI가 한 일을 내 코드베이스에 그대로 섞어 넣는 것이 아니라, 검토 단계를 거쳐 받아들일 수 있습니다.

돌아와서 결과를 받는 순서는 다음과 같습니다.

1. 웹 인터페이스에서 세션의 진행 상황과 최종 상태를 확인합니다.

2. 작업이 푸시된 새 브랜치를 확인합니다.

3. 변경 사항을 검토합니다.

4. 이상이 없으면 웹 인터페이스에서 풀 리퀘스트를 만듭니다.

검토 단계에서 챙겨 볼 항목을 적어 두겠습니다.

① 요청한 범위를 벗어난 변경이 없는지 확인합니다. 파일 목록부터 훑어보세요.
② 테스트를 직접 돌려 봅니다. 작업 결과가 그럴듯해 보이는 것과 실제로 동작하는 것은 별개입니다.
③ 삭제된 코드가 의도한 것인지 살펴봅니다. 추가된 줄보다 지워진 줄이 더 위험할 때가 많습니다.
④ 풀 리퀘스트 설명을 내 팀이 이해할 수 있는 말로 정리합니다.

브랜치 기반 방식의 장점은 되돌리기가 쉽다는 점입니다. 결과가 마음에 들지 않으면 풀 리퀘스트를 만들지 않고 브랜치를 버리면 그만이고, 메인 브랜치는 건드려지지 않습니다. 자리를 비운 사이에 맡기는 작업이라면 이런 안전장치가 있다는 점이 심리적으로 큰 차이를 만듭니다.

Step 5. 같은 저장소에 여러 작업을 병렬로 맡기기

별개의 격리 환경을 이용해 여러 작업을 동시에 맡길 수 있고, 같은 GitHub 저장소를 대상으로도 여러 웹 작업을 동시에 실행할 수 있습니다. 각 작업은 독립적인 풀 리퀘스트를 만듭니다.

병렬 작업은 이런 상황에서 유용합니다. 예를 들어 퇴근 전에 서로 성격이 다른 세 가지 일을 한꺼번에 맡겨 볼 수 있습니다.

· 작업 A: 특정 모듈의 테스트 보강
· 작업 B: 문서 오탈자·설명 정리
· 작업 C: 반복되는 코드 구조 리팩터링

각 작업이 독립된 환경에서 돌고 독립된 풀 리퀘스트를 만들기 때문에, 하나가 마음에 안 들어도 나머지는 따로 받아들일 수 있습니다.

다만 병렬로 맡길 때는 작업 범위가 서로 겹치지 않도록 설계하는 것이 실무 포인트입니다. 두 작업이 같은 파일의 같은 부분을 건드리면, 각각의 풀 리퀘스트를 합치는 단계에서 충돌을 직접 해결해야 합니다. 이 충돌 처리 방식에 대해 공식 도움말이 별도로 설명하는 내용은 확인하지 못했으므로, 겹칠 가능성이 있는 작업은 순서를 나눠 맡기는 편이 마음 편합니다.

병렬 작업을 설계할 때의 요령을 정리하면 다음과 같습니다.

① 작업마다 건드릴 폴더·파일 범위를 요청에 명시합니다.
② 같은 파일을 수정하게 될 작업은 한꺼번에 맡기지 않고 순차로 진행합니다.
③ 풀 리퀘스트가 여러 개 들어오면 의존성이 적은 것부터 검토하고 합칩니다.

Step 6. 설정 스크립트로 환경 준비하기 (새 세션에서만 실행됩니다)

의존성과 환경 변수를 준비하는 설정 스크립트를 구성할 수 있고, 이 스크립트는 새 클라우드 세션을 시작할 때 실행되며 세션을 재개할 때는 실행되지 않습니다. 프로젝트가 단순하지 않다면 이 설정이 작업 품질을 좌우합니다.

프로젝트를 실행하거나 테스트를 돌리려면 의존성 설치가 먼저 되어 있어야 합니다. 저장소를 복제한 직후의 가상 머신은 말하자면 "빈 작업대"라서, 필요한 패키지가 준비되어 있지 않으면 AI가 코드를 고쳐도 검증을 못 하고 끝납니다.

공식 도움말에 따르면 저장소에 정의한 준비 명령은 클라우드 작업 환경 준비에 쓰일 수 있습니다. 실무에서는 다음 항목을 스크립트에 담는 것을 고려해 볼 수 있습니다.

① 프로젝트 의존성 설치
② 테스트 실행에 필요한 환경 변수 준비
③ 빌드·테스트 도구가 동작하기 위한 기본 준비

설정할 때 꼭 기억할 점은 재개 시에는 스크립트가 다시 실행되지 않는다는 것입니다. 이 점이 만드는 실무적 의미는 다음과 같습니다.

· 새 세션으로 시작한 작업은 스크립트가 환경을 준비해 줍니다.
· 이미 진행한 세션을 나중에 다시 열어 이어갈 때는 스크립트가 다시 돌지 않으므로, 환경이 처음 준비된 상태 그대로라고 가정해야 합니다.
· 재개한 뒤 추가 의존성이 필요한 지시를 한다면, 그 필요를 요청에 직접 포함시켜야 할 수 있습니다.

환경 변수를 다룰 때는 민감한 값의 취급에 신중해야 합니다. 저장소 파일에 비밀 값을 그대로 적어 두는 방식은 피하세요. 클라우드 세션에서 민감 정보를 어떻게 다룰지는 공식 도움말의 설명을 직접 확인하고, 이 글에서는 구체적인 방법을 단정하지 않겠습니다.

네트워크 접근 범위도 함께 점검하세요. 의존성 설치처럼 외부 저장소에서 내려받는 단계가 있다면, 격리 환경의 네트워크 제한 때문에 막힐 수 있습니다. 설정 화면에서 접근 범위를 조정할 수 있다고 공식 도움말은 안내하므로, 설치가 실패한다면 이 부분부터 확인해 보세요.

자주 하는 실수와 바로잡는 법

대부분의 시행착오는 "내 PC와 똑같이 동작할 것"이라는 가정에서 나옵니다.

① 로컬에서만 고친 내용을 푸시하지 않고 시작하는 경우
클라우드 세션은 GitHub 저장소를 복제해 시작하므로, 푸시되지 않은 변경이 자동으로 따라온다고 전제할 수 없습니다. 시작 전에 `git status`로 상태를 보고, 필요한 변경은 커밋·푸시한 뒤 시작하세요.

② Remote Control을 클라우드 세션으로 착각하는 경우
`claude remote-control` 명령은 휴대전화나 웹에서 로컬 세션을 제어하는 쪽입니다. 로컬 PC가 꺼져도 이어지기를 원한다면 claude.ai/code에서 클라우드 세션을 시작해야 합니다.

③ 내 PC에만 있는 도구·파일·서비스에 기대는 경우
클라우드 세션은 로컬 PC의 파일이나 도구에 접근하지 않고, 네트워크 접근에도 제한이 있습니다. 필요한 구성은 저장소 안에서 재현할 수 있게 정리해 두세요.

④ 세션을 재개한 뒤 설정 스크립트가 다시 돌 것으로 기대하는 경우
설정 스크립트는 새 세션에서만 실행됩니다. 재개한 세션에서 환경이 이전과 달라 보인다면 이 점부터 떠올려 보세요.

⑤ 여러 작업을 병렬로 맡기면서 같은 파일 범위를 겹치게 지시하는 경우
작업별로 건드릴 범위를 나눠서 요청하세요. 겹칠 가능성이 있는 작업은 순서를 나눠 맡기는 편이 안전합니다.

⑥ 조직 계정에서 시작이 안 되는데 원인을 모르는 경우
공식 도움말에서 확인되는 제한 사례로 HIPAA-ready 설정을 적용한 Enterprise 조직이 있습니다. 해당된다면 Claude Code on the web을 사용할 수 없습니다. 조직 관리자가 웹 세션을 비활성화할 수 있는지에 대해서는 제가 확인한 공식 문서에서 구체적으로 확인되지 않았으니, 막힌다면 소속 조직의 설정을 직접 확인하시는 것이 정확합니다.

제대로 시작됐는지 확인하는 체크리스트

아래 항목을 차례로 확인하면 클라우드 세션이 의도대로 시작됐는지 알 수 있습니다.

① 시작 전: 로컬에서 작업하던 변경이 커밋·푸시되어 원격 저장소에 올라가 있나요?
② 시작 시점: claude.ai/code에서 올바른 저장소를 선택하고, 범위·결과물·제외 영역·완료 기준을 담은 요청을 입력했나요?
③ 자리를 떠난 뒤: 브라우저를 닫았다가 다시 접속했을 때, 세션의 진행 상황이 웹 인터페이스에서 확인되나요?
④ 결과 확인: GitHub에 작업용 새 브랜치가 푸시되어 있나요?
⑤ 검토와 반영: 변경 사항을 살펴본 뒤 웹 인터페이스에서 풀 리퀘스트를 만들었나요?

처음에는 짧고 위험도 낮은 작업 하나로 이 다섯 단계를 끝까지 통과시켜 보세요. 흐름이 몸에 익은 뒤에 큰 작업과 병렬 작업으로 넓혀 가는 편이 훨씬 안정적입니다.

자주 묻는 질문

Q. 로컬에서 쓰던 CLI 세션을 그대로 클라우드로 옮길 수 있나요?
이 글에서 확인된 범위에서는 그런 전환 방법을 단정할 수 없습니다. 클라우드 세션은 GitHub 저장소를 복제해 새로 시작하는 방식입니다. 로컬 작업을 이어가고 싶다면 변경을 커밋·푸시해 원격 저장소에 올린 뒤, 그 저장소를 선택해 새 세션을 시작하는 방법이 가장 확실합니다.

Q. 공식 문서에 "PC를 꺼도 계속된다"고 적혀 있나요?
그렇게 직접 적힌 문구는 확인되지 않았습니다. 공식 웹 도움말은 시작한 뒤 페이지를 떠나도 Claude가 원격 환경에서 작업을 이어간다고 설명합니다. 작업이 원격 가상 머신에서 돌기 때문에 로컬 PC 종료와 무관할 것으로 보이지만, PC 종료 시 동작을 공식 문서가 명시하지는 않으니 이 글에서도 단정하지 않았습니다.

Q. 클라우드 세션을 쓰려면 CLI를 꼭 최신 버전으로 맞춰야 하나요?
브라우저로 claude.ai/code에서 시작하는 흐름 자체에 특정 CLI 버전이 필요하다는 내용은 이 글의 근거 자료에서 확인되지 않았습니다. 다만 2026년 10월 6일 공개된 v2.1.291 릴리스 노트에 클라우드 세션 관련 수정(권한 요청 응답 누락, 종료 시 마지막 메시지 손실)이 기재되어 있으니, 로컬 CLI를 함께 쓰신다면 업데이트를 확인해 볼 만합니다. 참고로 Remote Control은 CLI v2.1.51 이상 등의 조건이 별도로 안내되어 있습니다.

정리하며

핵심은 하나입니다. 자리를 떠나도 작업이 이어지길 원한다면 로컬 세션을 원격으로 조종하는 Remote Control이 아니라, claude.ai/code에서 시작하는 클라우드 세션을 선택해야 합니다. 이 구분만 잡혀도 시행착오가 크게 줄어듭니다.

흐름을 한 번 더 요약하면 이렇습니다.

· 시작 전에 로컬 변경을 커밋·푸시해 원격 저장소에 올립니다.
· claude.ai/code에서 로그인하고 GitHub 저장소를 선택해 구체적인 요청을 입력합니다.
· 작업은 격리된 가상 머신에서 진행되며, 페이지를 떠나도 원격 환경에서 이어집니다.
· 결과는 새 브랜치로 푸시되고, 검토 후 웹 인터페이스에서 풀 리퀘스트를 만듭니다.
· 같은 저장소에도 여러 작업을 병렬로 맡길 수 있고, 각 작업은 독립된 풀 리퀘스트를 만듭니다.
· 설정 스크립트는 새 세션에서만 실행되고, 인증 정보는 보안 프록시로 관리되며, 네트워크 접근은 제한됩니다.

작은 작업 하나로 시작 → 브라우저 닫기 → 재접속 → 브랜치 확인 → 풀 리퀘스트까지 한 바퀴만 돌려 보면, 이 방식이 내 업무 리듬에 어떻게 맞는지 금방 감이 올 겁니다. 😊