오늘의 AI 글: Claude Code를 여러 개 돌릴 때 필요한 격리와 조율

왜 이 글인가

오늘 고른 글은 Claude Code를 한 터미널에서 잘 쓰는 단계를 넘어, 여러 세션을 동시에 굴릴 때 생기는 현실적인 문제를 다룬다. AI 코딩 에이전트는 처음에는 “한 번에 더 많은 코드를 작성해준다”는 점이 눈에 띈다. 하지만 실제로 매일 쓰기 시작하면 병목은 곧 다른 곳으로 옮겨간다. 하나의 세션은 컨텍스트 창, 작업 집중도, 파일 충돌, 사용자의 검토 능력이라는 한계를 가진다. 그래서 자연스럽게 여러 세션을 병렬로 돌리고 싶어진다. 문제는 병렬화가 공짜가 아니라는 점이다. 두 에이전트가 같은 파일을 수정하면 덮어쓰기와 충돌이 생기고, 서로 다른 방향으로 구현을 시작하면 나중에 합치는 비용이 커진다.

원문은 이 문제를 두 가지 축으로 나눈다. 첫째는 파일 격리 문제다. 여러 Claude Code 세션이 같은 작업 디렉터리를 공유하면, 한 세션이 만든 변경을 다른 세션이 의도치 않게 읽거나 덮을 수 있다. 여기서 git worktree가 실용적인 해법이 된다. 같은 저장소의 여러 브랜치를 별도 디렉터리로 체크아웃해두면 각 세션은 자기 작업 공간에서 독립적으로 읽고 쓰고 테스트할 수 있다. 둘째는 조율 문제다. 격리만으로는 충분하지 않다. 여러 세션이 각자 안전하게 작업해도, 누가 무엇을 맡고 어떤 결과를 언제 합칠지 정하지 않으면 중복 작업과 방향 불일치가 생긴다. 원문은 이 지점을 “agent teams”라는 관점으로 설명한다.

이 주제가 지금 특히 중요한 이유는 AI 코딩 도구 사용 방식이 빠르게 “단일 대화”에서 “작업 운영”으로 이동하고 있기 때문이다. 예전에는 에이전트에게 작은 버그 수정이나 함수 작성을 맡겼다면, 이제는 조사, 설계, 구현, 테스트, 문서화, 리뷰 준비까지 나누어 맡기는 흐름이 늘고 있다. 이런 상황에서는 모델 성능보다 작업 환경 설계가 더 중요해진다. 병렬 세션을 제대로 격리하지 않으면 생산성이 오르는 것이 아니라 사고 면적이 넓어진다. 반대로 worktree와 역할 분리를 잘 쓰면, 한 세션은 원인 분석을 하고 다른 세션은 구현 후보를 만들고 또 다른 세션은 테스트 전략을 검토하는 식으로 훨씬 안정적인 병렬성을 얻을 수 있다.

다만 오늘 글은 Medium 회원 전용으로 노출되어 공개 웹 fetch에서는 전문이 아니라 제목, 부제, 요약 문단, 메타데이터만 확인할 수 있었다. 따라서 아래 해설은 공개적으로 확인 가능한 원문 요약과 git worktree, Claude Code 병렬 운영에 대한 일반적인 실무 원칙을 바탕으로 재구성한 것이다. 원문의 문장을 길게 옮기지 않고, 공개 요지인 “worktree는 파일 격리 문제를 풀고, agent team은 조율 문제를 푼다”는 주장에 한국어 해설과 적용 관점을 덧붙였다.

핵심 요약

• 원문의 중심 주장은 “하나의 Claude Code 세션만으로는 일정 지점에서 천장이 온다”는 것이다. 그 천장은 모델의 지능만이 아니라 컨텍스트 창, 사용자의 주의력, 하나의 작업 디렉터리가 감당할 수 있는 변경 범위에서 온다. 더 큰 일을 맡기려면 단순히 한 세션을 오래 돌리는 대신 여러 세션을 안전하게 나누어 운용해야 한다.

• 병렬화의 첫 번째 위험은 파일 충돌이다. 같은 저장소 디렉터리에서 두 에이전트가 동시에 파일을 수정하면, 변경이 섞이고 테스트 결과가 오염되고 어떤 세션이 어떤 의도를 가졌는지 추적하기 어려워진다. AI 에이전트는 빠르게 여러 파일을 읽고 고칠 수 있기 때문에, 사람보다 충돌을 더 빨리 크게 만들 수 있다.

• git worktree는 이 충돌을 줄이는 매우 현실적인 도구다. 하나의 git 저장소에서 여러 작업 트리를 만들면, 각 작업은 별도 디렉터리와 브랜치에서 진행된다. 세션 A는 feature/refactor-api 브랜치의 worktree에서 리팩터링을 하고, 세션 B는 fix/test-flake 브랜치의 worktree에서 테스트 문제를 볼 수 있다. 같은 저장소 이력을 공유하지만 작업 파일은 분리된다.

• worktree는 “격리”를 제공하지만 “협업”을 자동으로 제공하지는 않는다. 각 세션이 어디에서 무엇을 하고 있는지, 어떤 파일을 건드려도 되는지, 결과를 어떻게 합칠지 정해야 한다. 원문이 말하는 agent teams의 핵심은 여러 에이전트를 무작정 띄우는 것이 아니라 역할, 범위, 종료 조건을 명확히 둔 병렬 작업 운영에 가깝다.

• 여러 세션을 돌릴 때 가장 많이 낭비되는 것은 토큰보다 방향성이다. 작업 범위가 겹치거나 목표가 애매하면 각 세션은 나름대로 합리적인 결정을 내리지만, 전체 결과는 중복되거나 서로 충돌할 수 있다. 따라서 병렬 세션에는 “무엇을 하지 말아야 하는가”까지 포함한 짧고 분명한 작업 지시가 필요하다.

• worktree 기반 운영은 특히 조사와 구현을 분리할 때 효과적이다. 한 세션은 현재 구조를 읽고 위험 요인을 정리한다. 다른 세션은 제한된 범위에서 구현을 시도한다. 또 다른 세션은 테스트나 문서 관점에서 검토한다. 이렇게 하면 각 세션의 컨텍스트가 작아지고, 결과를 합치는 사람이 판단하기 쉬워진다.

• 병렬 세션의 핵심은 “최종 통합자를 누구로 둘 것인가”다. 여러 에이전트가 독립적으로 작업해도, 마지막에 변경을 고르고 합치고 버릴 판단 주체가 필요하다. 이것은 사람이 될 수도 있고 메인 에이전트가 될 수도 있지만, 아무도 통합 책임을 갖지 않으면 병렬 결과는 금방 파편화된다.

• git worktree는 브랜치 전략과 함께 써야 한다. 각 세션은 자기 브랜치에서 커밋 가능한 단위로 작업하고, 메인 브랜치에는 검토된 결과만 합쳐야 한다. 그냥 디렉터리를 여러 개 복사하는 것보다 worktree가 나은 이유는 이력이 연결되고, diff와 merge를 git의 정상 흐름 안에서 다룰 수 있기 때문이다.

• 원문의 실무적 메시지는 “더 많은 Claude를 띄우라”가 아니라 “서로 밟지 않도록 구조를 만든 뒤 띄우라”에 가깝다. AI 코딩 에이전트의 생산성은 병렬 개수에 비례하지 않는다. 격리, 역할 분리, 합류 지점, 검증 루틴이 있을 때만 병렬성이 실제 속도로 바뀐다.

원문의 논지를 단계별로 풀어보기

첫 번째 단계는 단일 세션의 한계를 인정하는 것이다. Claude Code 같은 코딩 에이전트는 한 세션 안에서도 꽤 많은 일을 처리할 수 있다. 파일을 읽고, 계획을 세우고, 코드를 고치고, 테스트를 실행하고, 실패 로그를 보고 다시 수정한다. 그러나 이 방식은 작업이 커질수록 점점 무거워진다. 컨텍스트에는 이전 판단, 파일 내용, 테스트 로그, 사용자의 추가 지시가 계속 쌓인다. 어느 순간 세션은 너무 많은 맥락을 들고 움직이고, 사용자는 그 세션이 정확히 어디까지 했는지 따라가기 어려워진다.

두 번째 단계는 “그러면 여러 세션을 동시에 돌리면 되지 않을까?”라는 유혹이다. 이 발상 자체는 맞다. 실제 개발팀도 한 사람이 모든 일을 순서대로 처리하지 않는다. 조사 담당, 구현 담당, 테스트 담당, 리뷰 담당이 나뉜다. AI 에이전트도 비슷하게 나눌 수 있다. 한 세션에게는 실패 로그 분석을 맡기고, 다른 세션에게는 작은 구현 실험을 맡기고, 또 다른 세션에게는 문서나 마이그레이션 영향을 보게 할 수 있다. 잘만 되면 대기 시간이 줄고 탐색 폭이 넓어진다.

세 번째 단계는 병렬화의 부작용을 보는 것이다. 사람이 동시에 같은 파일을 고치면 merge conflict가 생긴다. 에이전트도 마찬가지다. 더 나쁜 점은 에이전트가 매우 빠르게 여러 파일을 건드릴 수 있다는 것이다. 두 세션이 같은 작업 디렉터리에서 실행되면, 한 세션의 중간 변경이 다른 세션의 판단 근거가 될 수 있다. 테스트도 오염된다. 세션 A가 만든 변경 때문에 세션 B의 테스트가 통과하거나 실패할 수 있는데, 세션 B는 그 사실을 모른 채 자기 작업의 결과라고 해석할 수 있다. 이것이 병렬 에이전트 운영에서 가장 먼저 막아야 할 위험이다.

네 번째 단계가 git worktree다. worktree는 하나의 저장소에 여러 작업 디렉터리를 연결하는 git 기능이다. 일반적으로 하나의 저장소 디렉터리는 한 시점에 하나의 브랜치만 체크아웃한다. worktree를 쓰면 같은 저장소 이력을 공유하면서도 브랜치별로 별도 디렉터리를 만들 수 있다. 예를 들어 ../project-refactor, ../project-tests, ../project-docs처럼 작업 공간을 나누고, 각 디렉터리에서 다른 Claude Code 세션을 실행할 수 있다. 각 세션은 자기 디렉터리 안에서 파일을 바꾸므로 다른 세션의 작업 파일을 직접 덮지 않는다.

다섯 번째 단계는 worktree가 해결하는 것과 해결하지 않는 것을 구분하는 것이다. worktree는 파일 격리를 해결한다. 하지만 요구사항 해석, 역할 분담, 중복 작업, 통합 판단은 해결하지 않는다. 세션 A와 세션 B가 서로 다른 디렉터리에서 같은 리팩터링을 하면 파일 충돌은 피할 수 있어도 토큰과 시간이 낭비된다. 두 세션이 서로 다른 설계 방향으로 구현하면 나중에 하나를 버리거나 어렵게 합쳐야 한다. 따라서 worktree는 병렬 에이전트 운영의 기반이지, 운영 방식 자체는 아니다.

여섯 번째 단계는 agent team이라는 관점이다. 여러 에이전트를 팀처럼 다루려면 각각의 역할이 명확해야 한다. “전체를 알아서 개선해줘” 같은 지시는 단일 세션에도 위험하지만, 병렬 세션에는 더 위험하다. 대신 “이 worktree에서는 인증 모듈의 테스트 실패 원인만 조사하고 코드는 수정하지 말 것”, “이 worktree에서는 API 응답 타입 변경에 필요한 최소 수정만 만들 것”, “이 세션은 구현하지 말고 최종 diff를 검토해 리스크를 요약할 것”처럼 범위를 나누는 편이 안전하다. 팀은 사람 수가 아니라 역할 설계로 만들어진다.

일곱 번째 단계는 종료 조건이다. 에이전트에게 병렬 작업을 맡길 때는 언제 멈춰야 하는지도 정해야 한다. 무한히 개선하고, 계속 리팩터링하고, 발견한 문제를 모두 고치기 시작하면 작업 범위가 터진다. 좋은 종료 조건은 측정 가능하다. 예를 들어 “실패하는 테스트 3개 중 원인을 분류하고 수정 후보를 제안하면 멈춤”, “타입 오류가 0개가 되는 최소 diff를 만들면 멈춤”, “성능 개선 아이디어 2개를 비교하고 구현하지 않은 채 보고하면 멈춤”처럼 정할 수 있다. 종료 조건이 있어야 병렬 결과를 통합할 수 있다.

여덟 번째 단계는 통합자 역할이다. 여러 worktree에서 나온 결과는 결국 하나의 제품 코드로 합쳐져야 한다. 이때 통합자는 각 브랜치의 diff, 테스트 결과, 리스크, 중복 여부를 비교한다. 꼭 모든 결과를 합칠 필요는 없다. 오히려 좋은 병렬 운영은 일부 결과를 버릴 수 있어야 한다. A 세션의 구현은 과하지만 테스트 아이디어는 좋고, B 세션의 구현은 작지만 문서 업데이트가 빠졌고, C 세션의 리뷰가 중요한 위험을 잡아냈다면, 통합자는 이 조각들을 선별해야 한다.

아홉 번째 단계는 검증이다. 병렬 세션의 결과를 합친 뒤에는 반드시 깨끗한 기준점에서 테스트해야 한다. 각 worktree에서 테스트가 통과했다는 사실만으로 충분하지 않다. 여러 변경을 합치면 새로운 상호작용이 생길 수 있다. 따라서 메인 통합 브랜치에서 build, test, lint, 타입체크를 다시 돌려야 한다. AI 에이전트가 만든 변경일수록 “각자 통과”보다 “합친 뒤 통과”가 중요하다.

열 번째 단계는 운영 습관화다. worktree와 agent team 방식은 한 번의 멋진 실험으로 끝나면 별 효과가 없다. 저장소별로 worktree 이름 규칙, 브랜치 이름 규칙, 에이전트 지시 템플릿, 통합 체크리스트를 만들어야 반복 가능해진다. 여기까지 가면 AI 코딩은 “도구를 잘 쓰는 개인기”에서 “작업을 안전하게 분산하는 운영 방식”으로 바뀐다. 원문의 가치도 바로 여기에 있다. Claude Code를 더 많이 켜는 법이 아니라, 여러 Claude Code가 서로 망치지 않게 일하게 만드는 법을 묻는다.

일반 독자에게 중요한 포인트

• AI 에이전트의 병렬성은 마법이 아니라 작업 관리 문제다. 여러 에이전트를 동시에 실행한다고 자동으로 생산성이 두 배가 되지는 않는다. 사람이 여러 명인 팀도 역할이 겹치면 혼란스러워지듯, AI 세션도 범위가 겹치면 중복과 충돌이 생긴다.

• 격리된 작업 공간은 안전의 기본이다. 같은 문서를 여러 사람이 동시에 수정하면 버전 충돌이 생기는 것처럼, 같은 코드 디렉터리를 여러 AI가 동시에 수정하면 결과를 믿기 어려워진다. worktree는 각 AI에게 자기 책상을 마련해주는 방식에 가깝다.

• 빠른 자동화일수록 되돌릴 수 있어야 한다. worktree와 브랜치를 쓰면 각 세션의 결과를 독립적으로 검토하고 버릴 수 있다. 마음에 들지 않는 실험은 해당 브랜치나 worktree를 정리하면 된다. 메인 작업 공간을 직접 어지럽히는 것보다 훨씬 안전하다.

• 에이전트에게 일을 맡길 때는 “무엇을 할지”보다 “어디까지 할지”가 더 중요할 때가 많다. 범위가 넓으면 에이전트는 친절하게 더 많은 일을 하려 하고, 그 과정에서 원래 필요하지 않던 변경까지 만들 수 있다. 특히 병렬 세션에서는 작은 범위가 큰 안전장치가 된다.

• 앞으로의 개발 생산성은 AI를 얼마나 많이 쓰느냐보다, AI 작업을 얼마나 잘 나누고 합치느냐에 달릴 가능성이 크다. 단일 프롬프트 실력도 중요하지만, 브랜치 관리, 테스트 루틴, 리뷰 기준, 위험 권한 관리 같은 기본기가 더 중요해진다.

• 이 주제는 개발자에게만 해당하지 않는다. 디자인 문서, 기획안, 데이터 분석, 리서치도 마찬가지다. 여러 AI에게 동시에 일을 맡길 때는 자료 공간, 역할, 산출물 형식, 최종 통합자를 정해야 한다. 코딩 에이전트의 worktree 이야기는 더 넓은 AI 협업 운영의 축소판이다.

적용 아이디어

• 저장소별로 worktree 운영 디렉터리 규칙을 정한다. 예를 들어 메인 저장소 옆에 ../project-agent-refactor, ../project-agent-tests, ../project-agent-research처럼 목적이 드러나는 이름을 쓴다. 이름만 봐도 어떤 세션이 어떤 일을 하는지 알 수 있어야 한다.

• 병렬 세션마다 별도 브랜치를 만든다. agent/2026-05-31-auth-investigation, agent/2026-05-31-api-types, agent/2026-05-31-test-review처럼 날짜와 목적을 포함하면 나중에 정리하기 쉽다. 브랜치 이름은 에이전트 작업 로그의 일부라고 생각하는 편이 좋다.

• 세션 지시문에 “수정 가능 범위”와 “수정 금지 범위”를 함께 적는다. 예를 들어 “src/auth/**와 관련 테스트만 수정하고, DB 마이그레이션과 public API는 건드리지 말 것”처럼 쓴다. 하지 말아야 할 일을 적지 않으면 에이전트는 문제 해결을 위해 범위를 넓히려 할 수 있다.

• 조사 세션과 구현 세션을 분리한다. 한 세션에는 “코드를 수정하지 말고 원인과 옵션만 정리하라”고 맡기고, 다른 세션에는 “선택한 옵션 A만 최소 diff로 구현하라”고 맡긴다. 조사와 구현이 섞이면 컨텍스트가 길어지고, 구현이 조사 결과를 과도하게 끌고 갈 수 있다.

• 각 세션의 산출물 형식을 통일한다. 마지막에 목표, 변경 파일, 테스트 결과, 남은 리스크, 통합 시 주의점을 반드시 보고하게 하면 비교가 쉬워진다. 병렬 작업의 진짜 비용은 실행이 아니라 결과 해석에서 나오므로, 보고 형식을 미리 정하는 것이 중요하다.

• 통합 전에는 각 worktree에서 diff를 독립적으로 검토한다. 어떤 세션이 만든 변경이 다른 세션의 변경보다 낫거나, 둘 다 버려야 할 수도 있다. AI가 만들었다는 이유로 모두 합치지 말고, 작은 PR을 리뷰하듯이 선별해야 한다.

• 통합 브랜치에서 전체 검증을 다시 수행한다. 각 worktree의 테스트 결과를 믿되, 최종 판단은 합쳐진 코드에서 내려야 한다. build, test, lint, typecheck 중 프로젝트에 맞는 최소 게이트를 자동화해두면 병렬 작업의 리스크를 크게 줄일 수 있다.

• 병렬 세션 수에 상한을 둔다. 처음부터 다섯 개, 열 개의 에이전트를 돌리면 사용자가 통합을 감당하지 못할 수 있다. 보통은 2~3개 세션만 잘 나눠도 충분히 효과가 크다. 세션 수를 늘리기 전에 통합 체크리스트와 브랜치 정리 습관부터 갖추는 편이 낫다.

읽기 우선순위

Claude Code나 Codex 같은 코딩 에이전트를 이미 매일 쓰고 있고, 이제 “한 번에 하나씩” 처리하는 방식이 답답해지기 시작했다면 원문을 읽을 가치가 높다. 특히 여러 기능 실험, 테스트 보강, 리팩터링 후보 검토를 동시에 진행하고 싶은 개발자에게 실용적인 힌트를 준다. 다만 공개 접근으로는 전문을 확인하지 못했으므로, 원문을 읽을 수 있다면 worktree 설정 흐름과 agent team 운영 예시를 직접 확인하는 것이 좋다.

오늘의 결론은 단순하다. 하나의 에이전트가 한계를 맞는 순간, 답은 무작정 더 많은 에이전트를 켜는 것이 아니다. 먼저 각 에이전트가 서로의 파일을 밟지 않도록 worktree로 격리하고, 각 세션의 역할과 종료 조건을 정하고, 마지막 통합과 검증을 책임지는 흐름을 만들어야 한다. 병렬성은 생산성의 원천이지만, 구조 없는 병렬성은 사고의 가속기다. Claude Code를 팀처럼 쓰고 싶다면, 먼저 팀이 일할 책상과 역할표부터 마련해야 한다.