클라우드 세션은 당신의 머신 대신 클라우드 인프라에서 실행되는 Claude Code 세션으로, GitHub 저장소의 코드와 함께 작동합니다. claude.ai/code의 웹 Claude Code, Claude Mobile, Claude Desktop 또는 터미널에서 claude --cloud를 사용하여 시작할 수 있습니다. 이 문서에서는 클라우드 세션의 작동 방식, 터미널이나 IDE의 로컬 세션 대신 사용할 시기, 그리고 이를 통해 가능한 워크플로우를 설명합니다.
클라우드 세션이 제공하는 기능
클라우드 세션을 사용하면 당신의 적극적인 감시 없이 실행되는 작업을 Claude에 위임할 수 있습니다. GitHub 저장소를 선택하고 수행할 작업을 설명하면 Claude가 클라우드에서 작업을 진행합니다. Claude Code가 작업을 시작한 후에는 페이지를 완전히 떠날 수 있으며, Claude는 계속 작업을 진행합니다. 작업이 완료되면 Claude가 자동으로 검토할 변경 사항이 포함된 풀 요청을 생성합니다.
이 기능은 로컬 머신에 없을 수 있는 저장소에서도 작동합니다. 로컬로 복제하거나 개발 환경을 설정할 필요 없이 액세스 권한이 있는 모든 GitHub 저장소에서 작업을 시작할 수 있습니다. 이는 가끔 기여하는 프로젝트나 아직 배우고 있는 코드베이스를 탐색할 때 유용합니다.
클라우드 세션은 비동기 개발 워크플로우를 가능하게 합니다. 터미널이나 편집기의 로컬 세션에서는 일반적으로 동기적으로 작업합니다. 요청을 하고, Claude의 응답을 기다리고, 변경 사항을 검토한 후 다시 요청합니다. 이러한 동기적 작업은 세밀한 제어를 제공하지만 전체 프로세스 동안 주의가 필요합니다. 클라우드 세션은 다르게 작동합니다. 더 큰 작업을 할당하고 Claude가 독립적으로 작업하도록 한 후 나중에 완료된 작업을 검토할 수 있습니다.
여러 작업을 병렬로 실행할 수도 있습니다. 각 작업이 자체 격리된 환경에서 실행되므로 Claude가 여러 다른 문제나 저장소에서 동시에 작업할 수 있습니다. 각 작업은 독립적으로 진행되며 완료되면 자체 풀 요청을 생성합니다. 한 개 이상의 작업이 동시에 같은 저장소에서 작업할 수 있습니다.
작동 방식
클라우드 세션을 시작하면 Claude Code가 당신의 작업을 위한 격리된 가상 머신을 생성합니다. GitHub 저장소가 이 환경에 복제되며, 일반적인 개발 도구와 언어 생태계가 미리 구성되어 있습니다.
Claude는 저장소의 구성에서 정의한 설정 명령을 실행하여 환경을 준비합니다. 여기에는 종속성 설치, 데이터베이스 설정 또는 프로젝트에 필요한 기타 초기화 단계가 포함됩니다. 작업에 패키지 설치나 데이터 가져오기를 위해 네트워크 액세스가 필요한 경우 환경이 가질 수 있는 인터넷 액세스 수준을 구성할 수 있습니다.
환경이 준비되면 Claude가 작업을 시작합니다. Claude는 코드를 읽고, 변경을 하고, 테스트를 작성하고, 명령을 실행하여 작업을 검증합니다. 필요한 경우 웹 인터페이스를 통해 진행 상황을 모니터링하고 지침을 제공할 수 있습니다.
Claude가 작업을 완료하면 변경 사항을 GitHub 저장소의 새 브랜치로 푸시합니다. 알림을 받고 변경 사항을 검토한 후 인터페이스에서 직접 풀 요청을 생성할 수 있습니다. 풀 요청에는 Claude의 모든 작업이 포함되어 있으며 검토 및 추가 변경을 위해 준비되어 있습니다.
각 작업은 완전히 격리된 상태에서 실행됩니다. 가상 머신은 해당 특정 작업에만 존재하며 제한된 네트워크 액세스 및 보호된 자격증명 처리와 같은 보안 제어를 포함합니다. GitHub 인증은 보안 프록시를 통해 관리되므로 자격증명이 Claude가 작업하는 환경에 직접 존재하지 않습니다.
클라우드 세션 대 로컬 세션 사용 시기
일부 작업은 클라우드에서 비동기적으로 실행하기에 적합하지만, 다른 작업은 터미널이나 IDE에서 로컬로 실행하는 것이 가장 좋습니다.
클라우드 세션을 사용하는 경우:
명확한 요구사항이 있는 잘 정의된 작업: 정확히 무엇을 해야 하는지 설명할 수 있고 작업 중에 Claude를 조종할 필요가 없을 것으로 예상되는 경우, 클라우드 세션을 사용하면 작업을 시작하고 완료되었을 때 돌아올 수 있습니다.
버그 백로그의 백그라운드 작업: Claude에 백로그의 여러 문제를 할당하고 병렬로 실행하도록 할 수 있습니다. 각 작업은 독립적으로 진행되므로 각각을 개별적으로 모니터링하지 않고도 여러 수정 사항을 한 번에 처리할 수 있습니다.
로컬에 없는 저장소: 복제하지 않았거나 머신에 설정하고 싶지 않은 저장소에 변경을 해야 하는 경우, 클라우드 세션이 환경 설정을 처리합니다.
대기열에 넣고 싶은 작업: 변경할 작업 목록이 있지만 지금 바로 작업하고 싶지 않은 경우, 클라우드에서 시작하고 나중에 결과를 검토할 수 있습니다. 이를 통해 유사한 작업을 일괄 처리하거나 다른 작업에 집중하고 있을 때 작업을 위임할 수 있습니다.
터미널이나 IDE에서 로컬 세션을 사용하는 경우:
빈번한 방향 수정이 필요한 작업: 올바른 접근 방식이 정확히 무엇인지 확실하지 않거나 보이는 것에 따라 Claude를 리다이렉트해야 할 것으로 예상되는 경우, 터미널에서 작업하면 즉각적인 피드백을 얻을 수 있습니다. 완전한 결과를 기다리지 않고 Claude가 작업하는 동안 방향을 조정할 수 있습니다.
요구사항이 불명확한 탐색적 작업: 문제를 해결하는 방법을 파악하거나 다양한 접근 방식을 조사하는 경우, 터미널을 사용하면 배우면서 요청을 개선할 수 있습니다. 왕복 상호작용은 처음에 명확하지 않았던 요구사항을 명확히 하는 데 도움이 됩니다.
커밋되지 않은 변경사항이 있는 로컬 개발: 적극적으로 개발 중이고 로컬 저장소에 커밋되지 않은 작업이 있는 경우, 터미널에서 Claude Code를 사용하면 모든 것을 한 곳에 유지할 수 있습니다. 준비되지 않은 작업을 커밋하거나 푸시할 필요 없이 변경 사항을 빠르게 반복할 수 있습니다.
즉각적인 피드백이 필요한 작업: 빠르게 결과를 보고 싶고 빠르게 반복하고 싶은 경우, 터미널은 더 낮은 지연 시간을 제공합니다. Claude가 실시간으로 작업하는 것을 볼 수 있으며 프로세스 초기에 문제가 발생하면 중지하거나 리다이렉트할 수 있습니다.
사용 사례 예시
테스트 주도 개발을 통한 백엔드 변경
Claude가 예상 동작을 정의하는 테스트를 작성한 후 해당 테스트를 통과하도록 코드를 구현하도록 합니다. 이는 자동화된 테스트를 통해 동작을 검증할 수 있는 백엔드 변경에 특히 잘 작동합니다.
프롬프트 예시:
Add rate limiting to the /api/search endpoint.
The rate limiter should:
- Allow 100 requests per minute per API key
- Return 429 status when limit exceeded
- Reset limits after 60 seconds
- Track different API keys independently
Use a TDD approach: write comprehensive tests first, then implement the rate limiting logic to pass them.
이 접근 방식을 사용할 시기: 테스트가 Claude에 명확한 검증 기준을 제공하므로 클라우드 세션에서 잘 작동합니다. 테스트가 문제를 포착하고 작동하는 솔루션으로의 반복을 안내하므로 Claude의 진행 상황을 모니터링할 필요가 없습니다. Claude가 테스트를 작성한 후 통과하도록 하는 자체 포함된 작업의 특성상 시작 후 입력이 필요하지 않습니다.
이것이 효과적인 이유: Claude는 테스트 실패를 사용하여 문제를 식별하고 수정하면서 감시 없이 구현을 반복할 수 있습니다. 작업은 간단한 코드 변경보다 오래 실행되지만 백그라운드에서 완료되도록 할 수 있습니다. 풀 요청을 검토할 때 테스트와 구현이 모두 준비되어 있으며 테스트가 통과하므로 솔루션이 작동한다는 확신을 가질 수 있습니다.
문서 업데이트
README 파일, API 문서, 코드 주석 또는 사용자 가이드와 같은 기술 문서를 생성하거나 업데이트합니다.
프롬프트 예시:
Update CHANGELOG.md with all changes since the v2.3.0 release:
- Review commits on main branch since that tag.
- Categorize changes into "Added, "Changed, "Fixed", and "Removed" sections.
- Include the commit hash for each entry.
이 접근 방식을 사용할 시기: 변경 로그 업데이트는 Claude가 커밋 기록을 독립적으로 검토하고 지침 없이 항목을 형식화할 수 있으므로 클라우드 세션에 적합합니다. 작업은 수동으로 수행하기에는 지루하지만 Claude가 포함할 커밋이나 분류 방법에 대한 질문 없이 완료할 수 있을 정도로 간단합니다.
이것이 효과적인 이유: 전체 변경 로그 업데이트를 위임하고 완료되었을 때 결과를 검토할 수 있습니다. Claude는 커밋을 읽고, 의미 있는 변경을 추출하고, 기존 변경 로그 형식을 따릅니다.
명확한 범위의 리팩토링
변경에 대한 명확한 경계를 정의할 수 있을 때 코드를 재구성하여 조직이나 가독성을 개선합니다. 여기에는 코드 추출, 큰 파일 분할 또는 모듈 구조 구성이 포함됩니다.
프롬프트 예시:
The UserService class in /src/services/user.go has 800 lines long.
Split it into three focused services:
- UserAuthService (login/logout/sessions)
- UserProfileService (profile CRUD operations)
- UserPreferencesService (settings/preferences)
Ensure all tests still pass.
이 접근 방식을 사용할 시기: 명확한 제약 조건이 있는 리팩토링은 Claude가 따를 명확한 경계를 설정할 수 있으므로 클라우드 세션에서 잘 작동합니다. 테스트 스위트는 검증을 제공하여 Claude가 리팩토링이 기존 기능을 손상시키지 않았는지 확인할 수 있습니다.
이것이 효과적인 이유: 작업에 시간이 걸리지만 구조가 정의되면 활성 입력이 필요하지 않습니다. 리팩토링을 시작하고 Claude가 작업을 진행하는 동안 모니터링하지 않고 나중에 구성된 결과를 검토할 수 있습니다. 명확한 범위는 Claude가 작업 중에 지침이 필요할 가능성이 낮다는 것을 의미합니다.
효과적인 사용을 위한 팁
Claude가 작업을 성공적으로 완료했는지 더 쉽게 확인할 수 있도록 저장소에 테스트 스위트를 추가하는 것을 고려하세요
"개선" 또는 "수정"과 같은 모호한 목표 대신 성공 기준을 지정하세요
프롬프트에서 변경되어야 할 사항과 동일하게 유지되어야 할 사항을 정의하세요
Claude가 작업 중에 지침이 필요하지 않도록 명확한 경계로 작업 범위를 지정하세요
"먼저 이것이 어떻게 진행되는지 봐야 할 것 같다"고 생각하는 경우 대신 터미널 사용을 고려하세요
작업 중에 지침을 제공해야 한다는 것을 깨닫는 경우 "CLI에서 열기"를 사용하세요