오늘 아침 에이전트 네 개를 띄웠다. 하나는 auth 모듈을 리팩터링했고, 하나는 테스트를 작성했고, 하나는 불안정한 CI 작업을 쫓아다녔고, 하나는 아직도 생각 중이다. 오후가 되면 뭔가 일어나긴 했다는 막연한 느낌, 쌓여만 가는 터미널 탭, 어렴풋이 만들었던 기억만 남은 워크트리 세 개, 그리고 아직 읽지도 않은 풀 리퀘스트 두 개가 남는다. 일은 끝났다. 그런데 그게 뭐였는지는 보이지 않는다.
AI 코딩 에이전트가 완료한 작업을 추적한다는 것은 이렇게 흩어진 조각을 기록으로 바꾸는 문제다. 각 에이전트가 무엇을 바꿨는지, 그게 제대로 된 건지, 어디서 끝났는지. 이건 실제로 골치 아픈 문제다. 에이전트는 당신이 살펴볼 수 있는 속도보다 빠르게 일을 끝내고, 그들이 한 일의 증거는 혼자 일하는 한 사람을 전제로 만들어진 곳에 남아 있기 때문이다. 이 가이드에서는 먼저 수동 설정 방식을 살펴보고, 어디서 무너지는지 짚은 다음, 모든 결과를 그것을 요청한 작업에 붙여 두는 Sharkly의 워크플로를 보여준다.
요점만 말하자면, git과 터미널만으로도 두어 개의 에이전트는 손수 추적할 수 있다. 그 이상이 되면 결과물이 스스로 돌아오는 공유 공간이 필요하다. 병목이 코딩이 아니라 그것을 리뷰하는 능력으로 바뀌기 때문이다.
TL;DR
완료된 에이전트 작업을 추적한다는 것은 모든 실행에 대해 세 가지 질문에 답하는 일이다. 무엇이 바뀌었는가, 올바른가, 어디에 안착했는가. 에이전트가 하나나 둘일 때는 Git 히스토리와 풀 리퀘스트로 첫 번째 질문에 답할 수 있다. 여러 에이전트가 병렬로 움직이기 시작하면 기록은 워크트리, 터미널, PR 큐에 흩어져 조각나고, 작업과 결과를 잇는 연결고리를 잃는다. 태스크 보드는 실행, 블로커, 결과, 사람의 리뷰가 하나의 작업으로 되돌아오게 함으로써 이 문제를 해결한다. 그래서 완료된 작업을 재구성할 필요 없이 바로 검토할 수 있다.
완료된 작업을 추적한다는 것의 의미
추적은 활동 로그가 아니다. 끝난 실행에 대해 역으로 추론하지 않고도 세 가지 질문에 답할 수 있는 능력이다.
- 무엇이 바뀌었는가. diff, 건드린 파일, 그리고 각 변경의 이유.
- 올바른가. 타입 체크, 테스트, 빌드, 그리고 에이전트가 검증한 내용의 요약.
- 어디에 안착했는가. 브랜치, PR, 속한 작업, 그리고 누가 승인하는가.
조용히 끝난 에이전트는 기술적으로는 작업을 완료한 것이지만, 그걸 가지고 뭘 할 수는 없다. 우리가 신경 써야 할 완료 상태란 사람이 검토하고 승인할 수 있는 상태다. 그래서 “테스트가 통과했다”와 “작업이 추적되고 있다”는 같지 않다.
코딩 에이전트를 위한 휴먼 인 더 루프 모델이 그 경계를 긋는다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 방향을 정하고 결과를 승인한다. 추적은 후자의 절반이 실제로 일어나게 해 주는 장치다.
직접 구축 방식 단계별 살펴보기, 그리고 각 단계가 무너지는 지점
에이전트 하나가 브랜치 하나에서 움직인다면 기본 도구만으로 충분하다. 여기 각 단계마다 어떤 방식으로 실패하는지 솔직하게 짚어 본다.
1단계: 무엇이 바뀌었는지 본다. 실행이 끝나면 diff를 읽는다.
git log --oneline -10
git diff main...HEAD --stat
실패하는 경우: 두 에이전트가 브랜치를 공유할 때, 또는 에이전트가 아무것도 커밋하지 않고 잊고 있던 워크트리의 작업 트리에 변경 사항을 남겨 둘 때. 읽은 diff는 실제로 배포된 diff가 아니다.
2단계: 각 에이전트의 작업을 격리한다. 충돌하지 않도록 에이전트마다 별도의 git worktree를 준다.
git worktree add ../auth-refactor -b auth-refactor
git worktree list
실패하는 경우: 목록이 머릿속으로 감당할 수 있는 범위를 넘어설 때. git worktree list는 경로만 알려줄 뿐, 각 워크트리에 어떤 에이전트가 있는지, 어떤 작업을 위한 것인지, 끝났는지는 알려주지 않는다. 자세한 동작 방식은 공식 git-worktree 문서를 참고하라. 다만 거기서 다루는 범위는 기록 관리까지다.
3단계: 결과물이 PR까지 도달했는지 확인한다. GitHub에 기댄다.
gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup
실패하는 경우: PR은 있지만 왜 그런지 아무도 적어 두지 않았을 때, 체크는 통과했는데 변경 내용이 잘못됐을 때, 또는 PR이 시작점이 된 요청으로 되돌아가는 연결고리가 없을 때. gh pr list 레퍼런스는 열린 PR을 보여줄 뿐, 의도는 보여주지 않는다.
4단계: 무엇을 요청했는지 기억한다. 이 단계에는 명령어가 없다. 원래 요구사항은 Slack 메시지, 메모, 또는 기억 속에 존재한다. 사흘 뒤에 PR을 리뷰할 때쯤이면 수용 기준을 추측하고 있는 자신을 발견한다.
각 단계는 잘 작동한다. 문제는 단계 사이의 이음새다. diff, 격리, PR, 의도는 서로를 전혀 모르는 네 개의 시스템에 흩어져 있고, 그것들을 연결하는 유일한 존재가 바로 당신이다.
수동 설정이 확장을 멈추는 지점
무너지는 건 어느 한순간이 아니다. 완만한 경사이고, 지금 어디쯤 서 있는지 짚어 볼 수 있다.
| 병렬 에이전트 수 | 추적 비용 | 가장 먼저 무너지는 것 |
|---|---|---|
| 1 | diff 하나, PR 하나만 확인 | 없음 |
| 2~3 | 워크트리 사이를 오가며 컨텍스트 전환 | 어느 에이전트가 무엇을 했는지 놓침 |
| 4~6 | PR마다 의도 재구성 | 결과물이 리뷰 역량을 앞지름 |
| 7개 이상 | 전담 조정 필요 | 완료된 작업이 며칠째 리뷰되지 않고 방치됨 |
실제 비용은 에이전트 속도가 아니라 리뷰 역량으로 측정된다. 에이전트는 한 사람이 살펴볼 수 있는 것보다 빠르게 완료된 작업을 쏟아내기 때문에, 실행이 몇 개를 넘어서면 처리량은 에이전트가 코딩하는 속도가 아니라 세 가지 질문에 얼마나 빨리 답할 수 있는지에 의해 결정된다. 에이전트를 더 추가하면 전달 문제가 나아지는 게 아니라 추적 문제가 더 심해진다.
태스크 보드가 더해 주는 것
해법은 완료된 실행을 diff로 취급하는 것을 멈추고, 작업으로 되돌아오는 무언가로 취급하는 것이다.
Sharkly에서는 작업(task)이 공유 기록이다. 에이전트나 Crew에 작업을 할당하면 격리된 워크트리에서 실행되므로, 병렬로 움직이는 에이전트들이 같은 파일을 건드리는 일이 없다. 실행이 끝나면 실행 과정, 블로커, 결과, 후속 조치가 작업 타임라인으로 돌아온다. 변경 요약, 검증 결과, 알려진 한계는 계속 열어 둬야 하는 터미널이 아니라 작업 자체에 붙는다.
이것이 로그와 기록의 차이다. 로그는 무언가 일어났다고 알려준다. 기록은 무엇이 바뀌었고, 올바른지, 어디에 안착했는지를 한곳에서 알려주며, 그것을 시작한 요청에 연결되어 있다. 작업에서 완료된 결과를 리뷰하고, 승인하거나 되돌려 보내며, 그 결정에는 당신의 이름이 붙는다.
여기서 직접 구축 방식의 이음새가 메워진다. 의도, diff, 검사, 승인이 하나의 객체 위에 모인다. 에이전트가 이미 쓰는 도구는 그대로 유지된다. Claude Code와 Codex가 여전히 실행을 담당하고, Sharkly가 그 주위에 작업, 컨텍스트, 리뷰 계층을 더한다. 그러면 AI 에이전트에 작업 할당하기가 팀 동료에게 일을 맡기는 것처럼 읽히고, 결과는 찾을 수 있는 곳으로 돌아온다.
Sharkly를 내려받아 Computer 하나를 연결하고, 규모를 키우기 전에 실제 작업 하나로 이 방식을 시험해 볼 수 있다.
이 모든 게 필요 없는 경우
기준선에 대해 솔직해지자. 코딩 에이전트 하나를 저장소 하나에서 돌리고, 병합 전에 모든 diff를 읽는다면 git과 터미널만으로 이미 완료된 작업을 추적하고 있는 셈이다. 태스크 보드는 굳이 필요 없는 의식만 더할 뿐이다. Claude Code에 내장된 프로젝트 뷰는 단일 에이전트 워크플로에서 놀랄 만큼 많은 부분을 커버한다.
다음 세 가지가 겹치면 계산이 달라진다. 한 번에 두어 개를 넘는 에이전트, 끝난 당일에 리뷰할 수 없는 작업, 그리고 당신 외의 누군가에게까지 전달되어야 하는 결과. 그때부터 공유 작업 기록은 부담이 아니라, 요청부터 릴리스까지 완료된 작업이 보이게 하는 유일한 방법이 된다.
오늘 바로 실행해 볼 수 있는 체크리스트
에이전트를 하나 더 추가하기 전에, 이미 돌고 있는 에이전트들에 대해 다음 항목에 모두 '예'라고 답할 수 있는지 확인하자:
- [ ] 끝난 실행이라면 터미널을 열지 않고 1분 안에 diff를 찾을 수 있는가?
- [ ] 완료된 각 실행에 초록불 체크만이 아니라 에이전트가 검증한 내용의 요약이 함께 있는가?
- [ ] PR을 그것을 시작하게 한 요구사항까지 거슬러 추적할 수 있는가?
- [ ] 어떤 에이전트가 무엇을 맡고 있는지, 무엇이 끝났는지, 무엇을 리뷰해야 하는지 보여주는 한 곳이 있는가?
- [ ] 완료된 작업을 승인할 때 사람의 이름이 붙는가?
- [ ] 에이전트가 끝났을 때 결과가 당신에게 오는가, 아니면 직접 찾아 나서야 하는가?
어느 하나라도 '아니오'라면, 에이전트를 추가할수록 벌어질 이음새다. 나중에 추적되지 않은 일주일치 실행을 재구성하는 것보다 지금 고치는 편이 훨씬 싸다.
FAQ
AI 코딩 에이전트가 무엇을 바꿨는지는 어떻게 추적하나? 에이전트의 요약이 아니라 diff를 읽어라. 에이전트가 하나면 git diff와 PR로 충분하다. 여러 개라면 각 실행을 별도 워크트리에 두고 diff와 검증 요약을 공유 작업으로 돌려보내, 스크롤백에서 재구성하지 않도록 하라.
GitHub만으로 AI 에이전트 작업을 추적할 수 있나? 에이전트 하나나 둘이면 가능하다. GitHub는 열린 PR과 체크 상태를 보여준다. 하지만 어떤 에이전트가 그 PR을 만들었는지, 어떤 작업을 위한 것인지, 변경이 원래 의도와 맞는지는 알려주지 않는다. 그래서 여러 에이전트가 병렬로 돌기 시작하면 금세 힘을 잃는다.
태스크 보드가 필요해지기 전까지 몇 개의 에이전트를 돌릴 수 있나? 대부분 병렬 에이전트가 3~4개쯤 될 때 이음새를 체감한다. PR마다 의도를 재구성하는 데 리뷰 자체보다 더 많은 시간이 들기 시작하는 지점이다. 기준은 고정된 숫자가 아니라 리뷰 역량이다. 병렬 코딩 에이전트 관리에 관한 글을 참고하라.
태스크 보드가 빠르게 움직이는 에이전트의 속도를 떨어뜨리나? 아니다. 에이전트는 여전히 격리된 워크트리에서 최고 속도로 실행된다. 보드는 완료된 작업이 리뷰할 수 있는 곳에 안착하도록 되돌아오는 경로를 더할 뿐이며, 이는 수동 재구성 단계를 추가하는 게 아니라 없애 준다.
