Claude Code 병렬 다중 세션 Projects 기능 공개

Anthropic이 Claude Code의 Projects를 재구성했다. 사용자가 목표를 설정하면 Claude가 작업을 분해하고, 여러 스레드를 병렬로 스케줄링하며, 출력을 검토하고 결과를 종합한다. 스레드는 본질적으로 각자 독립된 브랜치의 Claude Code 클라우드 세션이다.

지난주 한 팀이 Claude Code로 레거시 스케줄링 모듈을 리팩터링했는데, 개발자는 같은 세션 안에서 코드를 고치고, 테스트를 돌리고, 에러를 추적해야 했다. 컨텍스트를 오가며 전환하는 데 40분이 걸렸다. Boris는 이를 보고, 터미널 세 개를 동시에 띄워서 하면 된다고 말했다.

전통적인 단일 세션 모드의 병목은 어디에 있는가

단일 세션 모드에서는 모든 작업이 같은 대화 기록과 컨텍스트 윈도우를 공유한다. 문제는 컨텍스트 윈도우가 유한하다는 점이다. Claude는 Sonnet 4.6에서 약 200개의 지시를 처리한 뒤 준수 능력이 떨어지기 시작한다[[3]]. 더 중요한 것은, 단일 스레드 작업은 곧 대기를 의미한다는 점이다.

개발자는 AI가 코드를 생성하기를, 테스트가 돌아가기를, 에러 분석이 나오기를 기다린다. 이 대기 시간 동안 개발자는 다른 가치 있는 일을 하는 것이 아니라 진행 표시줄을 바라보고 있다. 한 팀의 2026년 회고에 따르면, 전통적인 AI 보조 프로그래밍에서 개발자는 약 50%의 시간을 응답이나 코드 실행 결과를 기다리는 데 쓴다[[6]].

또 다른 숨은 비용은 컨텍스트 오염이다. 같은 세션에서 리팩터링, 테스트, 버그 수정을 끝내면 대화 기록이 점점 길어지고, 모델은 새로운 결정을 내릴 때 오래된 컨텍스트의 간섭을 받는다. 이는 정밀도 문제가 아니라 주의 배분 문제다.

다중 세션 병렬이란 무엇이고, 무엇을 해결하는가

다중 세션 병렬의 핵심 착상은 간단하다. 성질이 다른 작업을 서로 다른 독립 세션에 배분하는 것이다. 한 세션은 테스트 작성을, 한 세션은 버그 수정을, 한 세션은 리팩터링을 맡는다. 각 세션은 독립된 컨텍스트 윈도우, 독립된 대화 기록, 독립된 Claude Code 인스턴스를 가진다.

이 모드는 대기 시간을 직접 제거한다. 테스트 세션이 케이스를 돌리는 동안 리팩터링 세션은 코드 구조를 동시에 수정할 수 있고, 버그 수정 세션은 에러의 근원을 추적할 수 있다. 세 스레드가 병렬로 진행되면 총 소요 시간은 셋의 합이 아니라 가장 긴 하나에 가까워진다.

더 정확히 말하면, 이것이 해결하는 것은 연산력 문제가 아니라 동시성 문제다. Claude Code의 스레드는 본질적으로 클라우드 세션이며, 각자 독립적인 API 토큰과 컨텍스트 할당량을 소비한다[[5]]. 이는 사용자가 오프라인 상태에서도 AI가 계속 작업하게 할 수 있다는 뜻이다[[2]].

당신은 당신이 AI를 쓰고 있다고 생각하지만, 실은 AI가 당신을 대신해 일하고 있다

방안 A: 전통적 AI 프로그래밍 — 단일 스레드 대화 모드

당신이 묻고, 그것이 답하고, 당신이 고치고, 다시 묻는 순환

전통적인 AI 보조 프로그래밍의 작업 방식은 하나의 고정된 순환으로 단순화할 수 있다. 개발자가 질문하면 모델이 코드를 주고, 개발자가 버그나 요구 변경을 발견하면 다시 묻는다.

순환 자체가 문제는 아니다. 문제는 이 순환의 모든 단계가 개발자의 주의를 소모한다는 점이다.

구체적인 예를 하나 들어 보자. 어떤 611줄짜리 스케줄링 메서드를 리팩터링해야 한다고 가정하자. 전통적 모드에서는 우선 Claude에게 "이 메서드의 문제를 분석해 줘"라고 물어 한 무더기의 제안을 받을 것이다. 그다음 "먼저 보조 함수를 추출해 줘"라고 말하면 그것이 고치고, 이어서 "파이프라인 아키텍처를 설계해 줘"라고 하면 또 한 차례 고친다. 마지막으로 테스트를 돌려 보니 어떤 의존성이 제대로 처리되지 않았다는 걸 발견하고 돌아와 "여기서 왜 에러가 나는 거야"라고 다시 묻는다.

전체 과정에서 당신의 컨텍스트는 두 곳을 오간다. 머릿속의 작업 상태와 대화 속의 역사다. 매번 전환에는 비용이 따른다.

더 중요한 것은, Claude의 컨텍스트 윈도우가 크긴 하지만 무한하지는 않다는 점이다. 한 팀의 2026년 대형 프로젝트 회고에 따르면, LLM은 총 지시 수가 150~200개에 도달하면 준수 능력이 떨어지기 시작한다.

이는 모델이 멍청해진 것이 아니라 주의 메커니즘의 물리적 한계다. 컨텍스트가 길수록 각 토큰이 받는 주의는 희석된다.

컨텍스트 오버플로와 전환 비용

컨텍스트 오버플로는 단일 스레드 대화에서 가장 흔한 구조적 문제다.

그 발현은 보통 세 가지다.

첫째는 역사 오염이다. 같은 세션에서 서로 무관한 다섯 개 작업을 했는데, 여섯 번째 작업에 앞 세 작업의 지식이 필요하다. 하지만 Claude는 뒤의 두 작업 정보까지 함께 끌어들인다. 당신의 질문은 잡음에 둘러싸이고 답변 품질이 떨어진다.

둘째는 롤백의 어려움이다. Claude가 한 세션에서 많은 파일을 고쳤는데 갑자기 방안이 틀렸다는 걸 발견하고 20단계 이전 상태로 돌아가고 싶다. /rewind 명령으로 해결할 수 있긴 하지만, 대화 기록의 특정 지점으로만 롤백할 수 있을 뿐 두 개의 병렬 탐색 경로를 동시에 유지하게 해 주지는 못한다.

셋째는 작업 전환 비용이다. 개발자는 흔히 /clear로 대화를 비우고 작업을 바꾸지만, 이는 모든 컨텍스트를 버리는 것과 같다. 또는 /compact로 역사를 압축하는데, 이는 세부 사항을 잃는다. 두 방식 모두 '컨텍스트 보존'과 '메모리 보존' 사이에서 타협하는 것이며, 좋은 답이 없다.

솔직히 말하면, 당신이 여전히 하나의 대화창에서 여러 작업을 직렬로 진행하고 있다면, 당신은 플래그십 모델을 샀지만 실제로는 보급형 요금제를 쓰고 있는 것이다.

더 심한 것은, 이 모드에서 개발자는 50%의 시간을 응답을 기다리거나 컨텍스트를 수동으로 정리하는 데 쓰며, 진짜 엔지니어링 결정을 내리는 데 쓰지 않는다는 점이다.

단일 스레드 대화 컨텍스트 압박 메커니즘

단일 스레드 대화의 핵심 모순은 이렇다. 당신은 같은 대화 기록이 여러 독립 작업의 컨텍스트를 담게 하려 하지만, 대화 기록은 선형 구조여서 병렬에 본질적으로 맞지 않는다.

이 문제는 Claude Code만의 것이 아니다. 대화 기반의 모든 AI 프로그래밍 도구가 이 구조적 제약을 가진다. Claude Code의 Projects 재구성은 본질적으로 이 제약을 인정한 바탕 위에서 엔지니어링적 해법을 찾는 것이다.

다중 세션 병렬: 각 세션의 독립 컨텍스트와 작업 디렉터리

Claude Code의 다중 세션 병렬은 개념이 아니라 구체적으로 조작 가능한 메커니즘이다. Desktop 버전의 Code 탭에서 각 대화는 독립 세션이며, 자신만의 채팅 기록, 프로젝트 폴더, 코드 변경을 가지고 다른 세션과 완전히 격리된다.

사이드바에는 모든 세션이 나열되며, 여러 개를 동시에 시작할 수 있다. 예를 들어 한 세션은 단위 테스트를 돌리고, 한 세션은 리팩터링을 처리하며, 세 번째 세션은 버그 수정에 전념한다. 각 세션은 독립된 컨텍스트 윈도우를 소비하며 서로 영향을 주지 않는다.

/add-dir 크로스 디렉터리 작업과 공유 작업 보드

Claude Code는 단일 세션 안에서 /add-dir 명령으로 추가 작업 디렉터리를 더하는 것을 지원한다. 이는 모델이 세션을 전환하지 않고도 여러 프로젝트나 폴더에 걸쳐 코드를 조작하고 분석할 수 있게 한다.

더 중요한 것은 공유 작업 보드 기능이다. Claude가 팀 모드로 실행될 때, 그것은 Task List를 유지하며, 책임자가 큰 작업을 분해해 특정 하위 세션에 할당하고, 모두가 실시간으로 진행 상황을 갱신한다. 각 Claude Code 인스턴스는 터미널에서 자발적으로 SendMessage를 호출해 서로 메시지를 주고받으며, 백그라운드에서 인터페이스 정의, 검증 판단, 코드 변경 동기화를 논의한다.

Claude Code Projects 다중 스레드 아키텍처

독립 컨텍스트와 역사 격리 메커니즘

각 하위 세션은 독립된 컨텍스트 윈도우를 가지며, 프로젝트 로컬 컨텍스트(예: CLAUDE.md, MCP 서비스 등)를 로드한다. 하지만 책임자(메인 세션)의 대화 기록은 하위 세션에 전달되지 않으며, 하위 세션은 책임자가 전달한 시작 프롬프트와 직접 메시지만 인지할 수 있다.

이 격리 설계에는 명확한 트레이드오프가 있다. 장점은 컨텍스트가 교차 오염되지 않고 각 하위 세션이 단일 작업에 집중할 수 있다는 것이다. 단점은 하위 세션들 사이에 중간 추론 과정을 자동으로 공유할 수 없고, 공유 파일이나 명시적 메시지를 통해 정보를 전달해야 한다는 것이다.

Plan 모드와 권한 제어의 협업

Plan 모드는 권한 제어의 핵심 협업 메커니즘이다. Shift+Tab으로 Claude의 실행 모드를 순환 전환할 수 있다. Manual(기본), acceptEdits(파일 편집과 일반적인 파일 시스템 명령 허용), Plan(어떤 파일이든 건드리기 전에 먼저 제안).

리팩터링이나 다중 파일 변경 시나리오에서는 Plan 모드로 시작하는 것이 최선의 실천이다. Claude는 단일 파일 이동 전에 완전한 제안을 제시하고, 당신이 확인한 뒤 실행한다. 이는 '먼저 고치고 나중에 묻기'로 인한 연쇄 재작업을 피한다.

Plan 모드 권한 흐름

이 메커니즘의 가치는 '신뢰'를 설정 가능한 파라미터로 바꾼다는 데 있다. 저위험 소규모 변경에는 acceptEdits 모드로 상호작용 마찰을 줄일 수 있고, 영향 범위가 큰 리팩터링에는 Plan 모드를 강제해 매 단계를 통제 가능하게 만든다.

방안 C: Git Worktree + 다중 인스턴스 Claude 병렬

Boris 팀의 '독사 키우기식' 개발 전략

Gen AI 연구자 Boris 팀의 방법은 단순하고 과감하다. 바로 3~5개의 Git Worktree를 만들고, 각 Worktree에서 독립적으로 하나의 Claude Code 인스턴스를 실행하는 것이다.

하나는 테스트를 돌리고, 하나는 버그를 추적하고, 하나는 리팩터링을 하고, 또 하나는 먼저 구현을 작성하고 검토를 기다린다. 네 스레드가 동시에 진행되며, 당신은 그들 사이에서 수동으로 컨텍스트를 전환할 필요가 없다.

솔직히 말하면, 50%의 시간을 AI 응답이나 코드 실행 결과를 기다리는 데 쓰는 것은 단일 스레드 프로그래밍에서 가장 어리석은 부분이다.

Boris의 해법은 딱 두 글자다. 병렬.

각 Worktree는 독립된 Git 브랜치 스냅샷이며, Claude Code가 그 안에서 실행될 때 각자의 CLAUDE.md와 프로젝트 컨텍스트를 로드한다. 서로 다른 인스턴스는 간섭하지 않으며, 당신은 그것들이 각자 진행하게 두고 정기적으로 결과를 병합하거나 비교할 수 있다.

이 '독사 키우기식' 개발의 핵심 이념은 여러 agent가 같은 코드베이스의 서로 다른 브랜치에서 독립적으로 작업하고, 최종적으로는 사람의 검토가 어느 산출물을 남길지 결정한다는 것이다.

Git Worktree + 다중 Claude 병렬 아키텍처

비용은 API 토큰 소모에 있다. 세 인스턴스가 동시에 실행되면 각자 독립적으로 컨텍스트 윈도우를 소모하며, 도구를 고빈도로 상호 호출할 때 비용은 단일 인스턴스의 약 3배다.

하지만 효율 면에서 보면, 원래 3시간이 걸려 직렬로 완료해야 했던 작업을 1시간 이내에 병렬로 완료하도록 압축할 수 있다. 단, 최종 병합을 할 충분한 인내심이 있다는 전제하에.

Claude Code Projects와의 아키텍처 비교

Claude Code Projects의 재구성(2026년 9월 출시)은 기존의 '단일 폴더 기반 대화'를 '다중 스레드를 호스팅할 수 있는 협업 아키텍처'로 업그레이드했다.

핵심 차이는 컨텍스트 관리 방식이다.

Git Worktree 방안은 개발자가 여러 작업 디렉터리를 수동으로 유지해야 하며, 각 디렉터리는 독립 브랜치에 대응하고 Claude 인스턴스들 사이에는 내장 통신 메커니즘이 없다. 충돌을 스스로 처리하고, 진행을 조율하고, 언제 병합할지 결정해야 한다.

Projects 방안은 다르다. 사용자가 단일 프로젝트 안에서 목표를 설정하면, Claude가 자동으로 작업을 분해하고, 여러 스레드를 병렬로 스케줄링하며, 출력을 검토하고 결과를 종합한다. 스레드는 본질적으로 각자 독립 브랜치의 Claude Code 클라우드 세션이지만, 같은 프로젝트 지식 베이스와 작업 보드를 공유한다.

Projects는 크로스 스레드 통신 메커니즘을 도입했다. 스레드끼리 공유 작업 보드를 통해 진행 상황을 동기화할 수 있고, 책임자는 각 스레드의 상태를 보고 개입할 수 있다. 하지만 이것이 완전 자동화를 뜻하지는 않는다. 최종 병합은 여전히 사람의 판단이 필요하다.

두 방안의 경계 조건은 다르다.

- Git Worktree + 다중 인스턴스: Git 워크플로에 익숙하고 각 인스턴스의 동작을 완전히 통제해야 하는 시나리오에 적합하다. 비용이 투명하고 유연성이 높지만 조율 부담이 크다.

- Claude Code Projects: 수동 조율을 줄이고 일정 정도의 블랙박스 스케줄링을 받아들이고자 하는 시나리오에 적합하다. 진입 비용이 낮지만 동시성과 사용자 정의 정도가 플랫폼에 제약된다.

더 심한 것은, 전자가 당신이 무엇을 하고 있는지 이해하게 만들고, 후자가 당신이 무엇을 하고 있는지 잊게 만든다는 점이다. 둘 다 일은 하지만, 문제가 생겼을 때 debugging 난이도는 하늘과 땅 차이다.

설명 가능성과 통제 가능성을 추구한다면 Worktree를, 전달 속도와 낮은 마찰을 추구한다면 Projects를 선택하라.

이번 변경은 오래된 문제 하나를 해결했다. 과거에 당신이 Claude에게 세 가지 일을 동시에 하게 시켰을 때, 그것은 한 번에 하나씩만 할 수 있었고, 매번 전환할 때마다 컨텍스트를 다시 로드해야 해서 비용과 시간 모두 이득이 없었다.

선정 결정: 언제 어떤 방안을 쓰는가

의사결정 매트릭스: 프로젝트 규모, 위험 허용도, 협업 요구

세 방안은 각기 적용 시나리오가 있으니, 일괄적으로 말하지 말아야 한다.

단일 세션 Claude Code는 개인 개발자가 소규모 작업을 할 때 적합하다. 컨텍스트 전환 비용이 낮고 상호작용이 간단하며, 아이디어를 빠르게 검증하거나 소형 스크립트를 작성하기에 알맞다. 하지만 코드베이스가 2만 줄을 넘거나 서로 무관한 여러 작업을 동시에 해야 할 때는 단일 세션의 컨텍스트 오버플로 문제가 빠르게 드러난다.

Git Worktree + 다중 인스턴스 방안은 고위험, 고복잡도 대형 리팩터링에 적합하다. Boris 팀의 방법은 같은 저장소를 세 개의 독립 Worktree로 클론해 각각 테스트, 버그 추적, 리팩터링을 수행하고 서로 간섭하지 않게 하는 것이다. 이렇게 하면 디스크 점유가 세 배가 되고 수정 사항을 수동으로 동기화해야 하는 대가를 치른다. 하지만 당신이 얻는 것은 완전히 독립된 컨텍스트와 언제든 롤백할 수 있는 능력이다.

Claude Code Projects 다중 스레드 방안은 대부분의 일상 개발 시나리오에 적합하다. 다중 인스턴스와 유사한 격리 능력을 제공하지만 여러 폴더를 관리할 필요가 없다. 스레드끼리 공유 작업 보드를 통해 조율할 수 있어 팀 협업이나 일인 다중 작업 전환에 알맞다.

선택의 핵심 차원은 세 가지다. 프로젝트 규모는 컨텍스트 관리의 복잡도를 결정하며, 코드량이 클수록 병렬 방안의 우위가 뚜렷해진다. 위험 허용도는 잠재적 컨텍스트 오염이나 동기화 충돌을 받아들일 의향이 있는지를 결정하며, 고위험 작업은 격리 방안을 더 선호한다. 협업 요구는 여러 사람이 같은 작업 보드를 공유해야 하는지를 결정하며, Projects 방안은 이 측면에서 뚜렷한 우위를 가진다.

아키텍처演进 경로 제안

Claude Code를 막 접한 경우 단일 세션부터 시작해, /clear로 컨텍스트를 비우고 /compact로 역사를 압축하는 것을 권한다. 익숙해지면 /add-dir로 다중 디렉터리를 추가해 보며 다중 컨텍스트 관리의 실제 고충을 관찰하라. 고충이 나타나면 그때 Projects 다중 스레드나 Git Worktree 방안으로 업그레이드하는 것을 고려하라.

이러한 점진적 경로는 처음부터 과도하게 엔지니어링하는 것을 피하게 해주고, 각 방안의 경계에 대해 직접 체감하게 해준다.

Mermaid 아키텍처 비교도

Claude Code 다중 세션 방안 아키텍처 비교

방안 B의 핵심 가치는 멀티스레드 스케줄링을 수동 조작에서 시스템 동작으로 바꿔준다는 점이며, 당신은 목표만 설명하면 구체적으로 어떻게 분할하고 실행할지는 Claude가 완성한다.

세 가지 방안의 취사선택 결론은 매우 직접적이다. 단일 세션은 소규모 작업에, Projects 멀티스레드는 일상적인 멀티태스킹 개발에, Git Worktree는 고위험 리팩터링에 사용한다. 병렬을 위해 병렬하지 말고, 적합함이 관건이다.

참고 문헌

[1] Projects redesigned: from folder to conversation | Claude by Anthropic. claude.com/blog/projec… [2] Claude Code推出Projects：一個對話拆出並行線程 - 富途资讯. news.futunn.com/hk/post/794… [3] Claude Code 支持在单会话中添加多个工作目录. www.oschina.net/news/[REDAC… ] [4] Claude Code代码生成调试重构一键搞定-腾讯云开发者社区-腾讯云. cloud.tencent.com/developer/a… [5] tutorials. www.huaxiaozhuan.com/claude_code… [6] Claude Code之父首曝：「养蛊式」开发，质量碾压老架构师 - 智源社区. hub.baai.ac.cn/view/52820 [7] Desktop application - Claude Code Docs. code.claude.com/docs/zh-CN/… [8] Claude Code 的常用技巧. labuladong.online/zh/ai-codin…

확장 입구

- 원문 아카이브: tobemagic.github.io/ai-magician…

- 위챗 공식 계정: 计算机魔术师

AI 풀스택 엔지니어

331

글

69k

읽음

55

팬