앞 편 알아서 공개되는 구조를 만든다에서 올리면 공개되는 구조가 생겼습니다. 이제 Issue 1건씩 넘기던 바퀴를 여러 개 동시에 돌릴 차례입니다. 다만 AI가 여러 건을 동시에 할 수 있다는 것과 내가 여러 건을 동시에 판정할 수 있다는 것은 다른 이야기입니다. 이 편은 어디까지 늘려도 되는지의 기준을 정합니다. 다음 편 계측을 먼저 심어 둔다에서는 공개 전에 숫자를 줍는 장치를 심습니다.
핵심 요약
- AI가 놀고 있는 시간이 아까운 것은 사실이지만, 병목은 AI가 아니라 사람의 판정 속도입니다.
- 프로젝트는 주인공 하나만 둡니다. 동시 진행은 같은 프로젝트 안의 Issue 2~3건까지입니다.
- Claude Code는
--worktree로 세션마다 격리된 작업 폴더를 만들어 편집 충돌을 막습니다. - 맥락 전환 비용은 사람 쪽에 쌓입니다. 세션 이름과 문서로 그 비용을 줄입니다.
AI를 놀려 두는 게 아깝다, 그 전에
Issue 하나를 넘기고 기다리는 10분이 아깝게 느껴지는 순간이 옵니다. 그래서 두 번째, 세 번째 Issue를 동시에 넘기고 싶어집니다. 그 전에 앞 편의 판정 세 가지, 통과·반려·폐기를 떠올려 보세요. 돌아온 결과를 증거로 확인하고 판정하는 것은 사람의 일이고, 이 일은 병렬이 되지 않습니다. 세 건이 동시에 돌아오면 세 건을 순서대로 판정해야 하고, 그동안 AI는 다시 놉니다.
그러니 질문을 바꿔야 합니다. "AI를 얼마나 바쁘게 할까"가 아니라 "내가 판정을 밀리지 않고 처리할 수 있는 동시 건수는 몇 개인가"입니다. 우리 8주 교재 5주차부터 작업 시간을 기록하게 하는 이유가 여기 있습니다. 내 판정 속도를 숫자로 알고 있어야 동시 건수를 정할 수 있습니다.
여러 기획을 동시에 돌린다
같은 프로젝트 안에서 서로 다른 파일을 건드리는 Issue라면 동시에 돌려도 됩니다. 문제는 한 폴더에서 두 세션이 같은 파일을 편집할 때입니다. Claude Code는 이를 위해 worktree를 제공합니다. claude --worktree feature-auth처럼 시작하면 저장소 루트의 .claude/worktrees/feature-auth/ 아래에 별도 작업 폴더가 생기고 worktree-feature-auth라는 새 브랜치에서 작업합니다. 다른 터미널에서 다른 이름으로 한 번 더 실행하면 두 세션이 서로의 파일을 건드리지 않습니다.
# 터미널 1
claude --worktree issue-12-mail
# 터미널 2
claude --worktree issue-14-log
worktree는 새 체크아웃이라 .env 같은 추적되지 않는 파일이 없습니다. 프로젝트 루트에 .worktreeinclude 파일을 만들어 .env를 적어 두면 새 worktree에 자동 복사됩니다. .claude/worktrees/는 .gitignore에 넣어 두는 것이 공식 문서의 권장입니다. Windows에서도 같은 명령이 동작합니다.
단, 전부가 어중간해지는 함정
세션이 셋으로 늘어나면 각각이 조금씩 진행된 상태로 하루가 끝나는 날이 생깁니다. 셋 다 통과 판정을 못 받고, 셋 다 공개되지 않고, 추적할 숫자는 셋 다 움직이지 않습니다. 이것이 병렬의 함정입니다. 바이브 코딩의 성과는 얼마나 많이 굴리는가가 아니라 얼마나 자주 공개 지점을 넘는가로 결정되는데, 병렬은 공개 지점을 오히려 늦출 수 있습니다.
강사 원구연은 매일 돌아가는 자동화를 10종 넘게 운영하지만, 개발 중인 주인공 프로젝트는 항상 하나입니다. 나머지는 운영만 하고 손대지 않습니다. 세션도 한 세션에 한 작업만 두고, 끝나면 닫습니다. 서너 개 이상의 창을 동시에 띄우지 않는 것은 판정이 섞이는 것을 막기 위해서입니다.
동시에 돌려도 되는 개수의 기준
기준은 세 가지입니다.
- 프로젝트는 하나. 두 프로젝트를 동시에 개발하지 않습니다. 하나가 공개 지점을 넘은 뒤에 다음으로 갑니다.
- Issue는 2~3건. 서로 다른 파일을 건드리고, 하나가 실패해도 다른 하나의 판정에 영향이 없는 조합만 고릅니다.
- 판정 대기 0건. 돌아온 결과가 판정되지 않은 채 쌓여 있으면 새 Issue를 넘기지 않습니다.
권한 모드도 개수에 영향을 줍니다. default 모드에서 세 세션을 돌리면 승인 요청이 세 곳에서 번갈아 뜨고 나는 세 화면을 오가게 됩니다. 방향이 정해진 Issue는 acceptEdits나 auto 모드로 넘기고, 판정만 마지막에 하는 것이 병렬의 전제입니다.
전환 비용은 사람 쪽에 있다
AI는 세션마다 자기 맥락을 갖고 있어 전환 비용이 없습니다. 비용은 사람에게 쌓입니다. 세션 A의 결과를 판정하다가 세션 B로 넘어가면 "이 세션은 무슨 Issue였지"부터 다시 떠올려야 합니다.
줄이는 방법은 도구가 아니라 기록입니다. 세션마다 Issue 번호를 이름으로 두고(worktree 이름을 Issue 번호로 짓는 이유), 판정 결과를 Issue 댓글에 바로 적고, 다음 날 이어갈 때는 claude --continue로 가장 최근 대화를, claude --resume으로 목록에서 골라 재개합니다. 그리고 우리 6주차 교재의 원칙, 오래된 대화는 요약본으로 이어가기. 긴 세션을 붙들고 있는 것보다 요약을 남기고 새 세션을 여는 편이 사람에게도 AI에게도 싸게 먹힙니다.
해 보기
- 열려 있는 Claude Code 창을 세어 봅니다. 셋을 넘으면 판정 대기 중인 것부터 처리하고 닫습니다.
- 같은 프로젝트에서 서로 다른 파일을 건드리는 Issue 2건을 고릅니다.
claude --worktree <Issue번호>로 두 세션을 열고 각각 한 문장으로 넘깁니다.- 두 결과를 순서대로 판정하고, 판정 사이에 걸린 시간을 기록합니다.
- 그 시간이 Issue 1건 실행 시간보다 길면 동시 건수를 줄입니다.
정리
- 병목은 AI가 아니라 사람의 판정입니다.
- 주인공 프로젝트는 하나, 동시 Issue는 2~3건, 판정 대기는 0건.
- worktree로 세션을 격리하고
.worktreeinclude로.env를 넘깁니다. - 전환 비용은 세션 이름과 Issue 댓글, 요약으로 줄입니다.
자주 묻는 질문
AI가 대기 중일 때 다른 Issue를 같이 넘겨도 되나요?
같은 프로젝트에서 서로 다른 파일을 건드리는 Issue라면 됩니다. 단 worktree로 세션을 격리하고, 판정 대기가 없을 때만 넘기세요. 판정이 밀린 채 새 건을 넘기면 결과가 쌓이기만 하고 공개는 늦어집니다.
프로젝트를 여러 개 동시에 돌리면 왜 안 되나요?
프로젝트가 둘이면 그림, 규칙, 완료 정의가 둘이 되고 사람의 머리가 둘 사이를 오가며 전환 비용을 냅니다. 결과적으로 둘 다 공개 지점을 못 넘긴 채 어중간해집니다. 하나를 공개까지 밀고 난 뒤 다음으로 가는 편이 총 시간이 짧습니다.
주인공 프로젝트는 언제 바꾸나요?
현재 주인공이 첫 공개 정의를 통과하고, 추적할 숫자가 실제로 들어오기 시작했을 때입니다. 그 전에는 바꾸지 않습니다. 접기로 판정한 경우도 바꾸는 시점이 되는데, 그 기준은 뒤의 접는 기술 편에서 다룹니다.
주인공을 고르는 기준은 무엇인가요?
가장 작게 공개할 수 있는 것, 그리고 추적할 숫자를 가장 빨리 볼 수 있는 것입니다. 우리 8주 과정에서 개인 프로젝트를 "내 컨설팅 업무 중 하나"로 좁히게 하는 이유와 같습니다. 크고 멋진 것보다 내일 아침 결과를 확인할 수 있는 것이 주인공입니다.
맥락 전환 비용을 줄이려면 어떻게 하나요?
세션 이름을 Issue 번호로 짓고, 판정을 Issue 댓글에 즉시 적고, 하루가 끝나면 다음 할 일을 한 줄 남깁니다. 다시 시작할 때는 claude --continue나 --resume으로 이어가되, 대화가 길어졌으면 요약을 남기고 새 세션을 여세요.