AI를 병렬로 구동하려면 독립적인 작업 영역을 분리해야 한다

얼마 전, 저는 병렬 처리에 대한 글을 썼습니다. 큰 작업을 나누어 여러 agent에게 동시에 할당하는 방식에 대해서 말이죠. 하지만 한 가지 부족한 부분이 남아 있었습니다. 바로 여러 agent가 동시에 코드를 편집할 때, 무엇이 그들의 충돌을 막아주는가 하는 점입니다. 이번에는 이 부분을 다루고자 합니다.

먼저 저 자신이 부딪혔던 벽부터 말씀드리겠습니다. 하나의 세션 내에서 AI가 스스로 생성하는 subagent는 사실 문제가 없습니다. 스스로 격리 방법을 생각해주기 때문에 크게 신경 쓸 필요가 없었습니다. 정말 고생했던 건 다른 경우였습니다. 제가 수동으로 여러 개의 AI 터미널을 열고, 같은 프로젝트를 동시에 편집하게 했을 때입니다. 여러 손이 같은 작업 디렉터리로 뻗어와서, 제가 조금 쓰고, 저쪽에서 조금 쓰면서 파일들이 서로 덮어쓰여지고 상태가 엉망진창이 되는 것을 목격했습니다. 그 과정에서 누구의 작업도 깨끗하게 남아있지 않다는 것을 깨닫게 되었습니다.

필요한 것, 그리고 하나의 경계

필요한 것은 복잡하지 않습니다. 병렬로 작동하는 여러 손이 각각 자신의 일을 하면서 서로 충돌하지 않고 같은 프로젝트를 편집하는 것입니다.

다만 먼저 경계를 긋고 말씀드립니다. 모든 병렬 작업이 격리를 필요로 하는 것은 아닙니다. 몇 개의 agent를 보낼 때, 하나는 로그를 파고들고, 하나는 원인을 분석하고, 하나는 문서를 뒤지는 경우 등은 모두 읽기 전용(read-only)이기 때문에 같은 작업 영역에 몰아넣어도 아무 문제가 없습니다. 각자 구역을 분리할 필요가 없습니다. 진정으로 격리가 필요한 것은 파일을 수정하는 병렬 작업입니다. 읽기는 공유해도 되지만, 쓰기는 분리해야 합니다. 이것이 아래 모든 논의의 출발점입니다.

우회 경로: 먼저 2개를 clone 해봤다

두 개의 AI가 서로 간섭하지 않으면서 하나의 프로젝트를 편집하게 하기 위해, 처음 시도한 것은 가장 원시적인 방법, 즉 물리적 격리였습니다. 프로젝트를 별개의 두 디렉터리로 clone하여, 마치 우물물이 강물을 더럽히지 않는 것처럼요.

깨끗합니다. 정말 깨끗하죠. 하지만 곧 문제에 부딪혔습니다. 바로 디스크 공간이었습니다. 제가 다루는 많은 프로젝트는 React 프론트엔드 + Python 백엔드의 복합체라 의존성이 엄청납니다. 일부만 clone 해도 몇 GB가 됩니다. 두 개를 clone하면, 디스크 전체가 중복으로 차지되어 사라집니다. 더욱 골치 아픈 것은, 이 '두 개 열기' 방식을 계속 사용하고 싶다면, 그 두 개는 영원히 남아 공간을 점유하며 회수할 수 없다는 것입니다.

그래서 git worktree로 전환했습니다. 그 장점은 바로 이 문제점에 부합합니다. 여러 작업 트리(worktree)가 하나의 .git을 공유하기 때문에, 리포지토리와 히스토리를 통째로 반복해서 복제할 필요가 없습니다. 게다가 일시적입니다. 작업이 끝나고 검증까지 마치면 즉시 회수할 수 있습니다. clone처럼 오랫동안 붙잡아 둘 필요가 없습니다. 두 방식의 격리 효과는 거의 같지만, worktree는 디스크를 낭비하지 않습니다.

두 가지 종류의 병렬 — 누가 worktree를 열 것인가

실제로 사용할 때는 두 가지 상황을 구분해야 합니다. worktree를 여는 방식이 다르기 때문입니다.

하나는 세션 내 subagent 병렬입니다. 이것이 가장 손이 덜 갑니다. AI에게

만약 두 개의 worktree가 정말로 같은 파일을 건드리게 된다면, 주 제어 agent (main agent)가 나타나 merge 합니다. 하지만 솔직히 말해서 그런 일은 드뭅니다. 태스크를 분할할 때 애초에 각 블록을 가능한 한 독립적으로 구성하기 때문입니다. 두 블록이 충돌할 정도로 결합되어 있다면, 애초에 두 개의 태스크로 나누지 말았어야 했습니다.

빠졌던 함정과 방지해야 할 것

가장 흔한 함정은 뒷정리를 잊는 것입니다. worktree를 삭제하는 것을 잊으면, 그것이 그대로 남아 자리를 차지하게 됩니다. 다만 이것은 치명적이지는 않습니다. 기능은 이미 메인 브랜치에 합쳐져 있으므로 잃을 것은 없으며, 이름 충돌이나 git 상태의 혼란도 발생하지 않습니다. 기껏해야 용량만 차지할 뿐입니다.

그렇다고 해서 "자리를 차지하는 것"도 조치가 필요합니다. 저는 글로벌 군규(global rules)에 한 줄을 추가했습니다: worktree의 작업이 검증 및 merge에 문제가 없음을 확인했다면, 정리한다. 보험 조치도 추가했습니다. 해제하기 전에, 해당 worktree의 commits가 모두 메인 브랜치에 합쳐졌는지 한 번 더 확인하는 것입니다. 손이 너무 빨라서 아직 합쳐지지 않은 기능을 통째로 날려버리는 일이 없도록 말입니다. 강력한 AI는 이 식별과 뒷정리를 스스로 할 수 있습니다. 약한 AI는 이를 간과하기 쉬우며, 그럴 때는 제가 감시하거나 다시 주 제어 agent를 호출하여 처리하게 합니다.

현재까지 유용한 worktree를 실수로 삭제한 적은 실제로 없습니다. 정리하기 전 "commits를 확인한다"는 한 수가 대체로 제동 장치 역할을 해주고 있기 때문입니다. 하지만 사람이 수동으로 정리할 때는 그 확인 절차가 사라집니다. 합쳐지지 않은 작업을 잃을 가능성이 있습니다. 그 부분은 스스로 주의할 수밖에 없습니다.

억지로 사용하지 마라, 하지만 한 가지 선은 넘지 마라

worktree를 만능약처럼 취급하는 것도 좋지 않습니다. 단순한 태스크, 몇 개의 파일 변경, 하나의 완결된 기능이라고도 할 수 없는 것들—이런 상황에서 worktree를 여는 것은 순수하게 수지타산이 맞지 않습니다. 하나의 작업 영역에서 수정하고 끝내면 됩니다.

하지만 절대 양보할 수 없는 선이 하나 있습니다: 메인 브랜치에서 직접 작업하지 않는다. 어떤 변경이든 먼저 새로운 브랜치에서 시작하고, 검증 후 문제가 없다면 PR (Pull Request)을 통해 메인 브랜치에 합칩니다. worktree든 단일 브랜치든, 둘 다 이 원칙을 따르고 있습니다. 메인 브랜치를 항상 깨끗하고 신뢰할 수 있는 상태로 유지하기 위해서 말입니다.

마지막으로 worktree 자체로 이야기를 돌려보겠습니다. 누군가는 코웃음을 치며 이렇게 말할지도 모릅니다. "이건 git이 몇 년 전부터 가지고 있던 오래된 기능인데, 무슨 할 말이 있느냐"라고 말이죠. 확실히 오래된 기능입니다. 하지만 AI가 병렬로 일하는 이 새로운 국면에서, "여러 개의 손이 하나의 프로젝트를 동시에 편집한다"라는 실제적인 문제를 해결하며 과거보다 몇 배나 더 많은 일을 해내고 있습니다. 오래된 나무가 새로운 가지를 뻗었다고나 할까요.

다음에는 조금 결이 다른 이야기를 다뤄보고 싶습니다: AI는 이토록 유능하고 이토록 많은 작업을 대신해주는데, 왜 인간은 결국 피곤함을 느끼는가? 그 사이 어디에서 톱니바퀴가 어긋나는가? 관심이 있다면 댓글로 알려주세요.

Discussion