에이전트 셋을 동시에 굴리는 책상: GitHub Copilot 앱과 워크트리

에이전트가 하나일 때의 병목

코딩 에이전트에게 일을 맡겨 본 사람은 비슷한 경험을 합니다. 에이전트가 일하는 동안 기다리게 됩니다.

에이전트가 저장소를 고치고 있으니 같은 작업 폴더에서 다른 일을 하기가 애매합니다. 브랜치를 바꾸면 에이전트의 작업이 꼬입니다. 그래서 결국 에이전트가 끝날 때까지 지켜보게 됩니다.

GitHub Copilot 앱은 이 병목을 에이전트를 여러 개 동시에 돌리는 쪽으로 풀었습니다.

세션마다 워크트리

Mario Rodriguez의 글에 따르면 Copilot 앱은 세션마다 별도의 git 워크트리를 만듭니다. 글은 이를 "브랜치의 실제 격리된 복사본"이라고 부릅니다.

git 워크트리는 하나의 저장소에서 여러 브랜치를 각각 다른 폴더에 동시에 꺼내 두는 기능입니다. 원래 있던 기능이지만, 직접 쓰려면 만들고 정리하는 일이 번거로웠습니다. Copilot 앱은 이걸 자동으로 만들고 지웁니다.

글에 나온 예시가 이 앱의 쓰임새를 잘 보여 줍니다.

에이전트 1: 운영 중인 버그 조사
에이전트 2: 백로그 이슈 구현
에이전트 3: PR의 리뷰 의견 반영

셋이 각자의 워크트리에서 일하니 서로의 파일을 건드리지 않습니다.

그림 1. 세션마다 격리된 워크트리. GitHub 블로그의 예시를 바탕으로 직접 그렸습니다.

일의 출발점은 이슈와 PR

세션은 프롬프트로 시작할 수도 있고, 받은 편지함의 이슈에서 시작할 수도 있습니다. 어느 쪽이든 Copilot은 기존 이슈, PR, 연결된 저장소에서 맥락을 가져옵니다.

"My Work" 화면은 연결된 저장소 전체의 진행 중인 에이전트 세션, 이슈, PR, 백그라운드 자동화를 한 화면에 보여 줍니다. 여러 에이전트를 돌릴 때 필요한 건 결국 이런 관제 화면입니다.

머지까지 따라가는 에이전트

Agent Merge는 PR이 리뷰와 머지를 거치는 동안 따라갑니다. CI를 지켜보고, 필요한 리뷰어를 추적하고, 실패한 검사를 고칩니다.

어디까지 맡길지는 사람이 정합니다. 글의 표현을 빌리면 "CI를 다시 초록색으로 만들기, 리뷰 의견 반영하기, 조건이 맞으면 머지하기" 중에서 고릅니다.

머지까지 맡기는 건 조심스럽습니다. 하지만 "CI가 깨지면 고쳐 놓기"까지만 맡겨도 꽤 많은 시간이 돌아옵니다. 린트 오류나 깨진 테스트 하나 때문에 PR이 하루씩 멈추는 일이 흔하니까요.

리뷰를 위한 장치들

에이전트가 많아지면 사람의 일은 리뷰가 됩니다. 앱에는 리뷰를 돕는 장치가 몇 가지 있습니다.

Canvases: 에이전트가 계획, PR, 터미널, 대시보드를 갱신하는 공유 작업면. 사람이 고치거나 승인하거나 방향을 틀 수 있음
중간 리뷰 등급: PR을 더 높은 추론 모델로 보내는 코드 리뷰 단계
/security-review: 보안 관점 리뷰 스킬
/rubberduck: 여러 모델 계열로 구현을 비평하게 하는 스킬

/rubberduck이 재미있습니다. 한 모델이 쓴 코드를 다른 계열의 모델이 비평하게 하는 방식입니다. 같은 모델은 자기가 만든 실수를 잘 못 찾는 경향이 있으니, 리뷰어를 바꾸는 건 사람 사이의 리뷰와 같은 논리입니다.

병렬의 비용

에이전트 셋을 동시에 돌리면 사람이 리뷰할 PR도 셋입니다.

병렬화로 늘어나는 건 에이전트의 처리량이지, 사람의 리뷰 능력이 아닙니다. 리뷰가 밀리면 결국 대충 승인하게 되고, 그게 가장 위험합니다. 처음에는 서로 다른 성격의 일, 예를 들어 버그 조사처럼 결과를 읽기만 하면 되는 일과 구현 하나를 짝지어 돌리는 편이 현실적일 것 같습니다.