코딩 에이전트는 당신이 커피 한 잔 마시는 동안 티켓을 풀 리퀘스트로 바꿔놓는다. 그 속도는 도구가 결코 대신 답해주지 않는, 더 조용한 질문을 남긴다. diff가 생긴 순간, 그 변경의 주인은 누구인가? 코드를 타이핑한 사람이 아니다. 그건 에이전트가 했다. 그 변경이 배포될지, 옳은 변경이었는지, 새벽 2시에 터지면 무슨 일이 벌어질지에 대한 책임은 누구에게 있는가. 실행은 에이전트에게 넘어갔다. 소유권은 넘어가지 않았고, 넘어갈 수도 없다.
에이전트를 두 개 이상 돌리는 순간 이 흐릿함은 더 심해진다. 버그 하나는 Claude Code에, 다른 하나는 Codex에 맡기면 브랜치 두 개, 요약 두 개가 생기지만, 간단한 질문에 대한 공통된 답은 없다. '이게 머지될 때 각각 누구 이름이 붙는가?' 터미널 스크롤백에 남아 있는 소유권은 소유권이 아니다. 다음 git log 한 번이면 사라질 추측일 뿐이다.
Sharkly는 바로 이 문제를 위해 만들어졌다. Sharkly는 코딩 에이전트 위에 위치하는 레이어로서, 누가 작업을 할당했는지, 어느 에이전트가 실행했는지, 누가 결과를 리뷰하고 누가 수락하는지를 기록한다. 이 글에서는 그 운영 모델을 네 가지 역할과 일련의 상태로 정리하고, 티켓 하나가 할당에서 병합된 PR까지 가는 과정을 따라가 본다. 그 아래에 깔린 리뷰 메커니즘은 휴먼 인 더 루프 코딩 에이전트 가이드에서 이런 결정을 강제하는 다섯 개의 게이트를 다룬다.
TL;DR
에이전트 작업에 대한 인간의 소유권이란, 실행은 에이전트에게 넘어가더라도 변경에 대한 책임은 결코 에이전트에게 이전되지 않는다는 뜻이다. 운영 모델은 네 가지 역할로 이루어진다. 사람이 할당하고, 에이전트가 실행하고, 지명된 사람이 리뷰하고, 바로 그 사람이 수락한다. 에이전트는 Task를 '리뷰 준비 완료'까지 옮길 수 있지만, '완료'로 옮기는 것은 사람뿐이다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 수락한다.
에이전트가 만들어낸 작업의 주인은 누구인가
소유권과 실행은 서로 다른 두 가지 일이며, 이 둘을 혼동하는 것이 근본적인 실수다. 실행은 변경을 만들어내는 것이다. 코드베이스를 읽고, 파일을 편집하고, 테스트를 돌리고, PR을 여는 일. 에이전트는 이걸 빠르고 잘 해낸다. 소유권은 결과에 대해 답할 수 있는 것이다. 그 변경이 만들 가치가 있었는지, 인수 기준을 충족하는지, 3개월 뒤에도 누군가에게 물어볼 수 있는지. 그 답할 수 있음은 사람에게 남는다. 에이전트는 사후에 트레이드오프를 정당화하라고 요구받을 수도, 그 결과를 감당할 수도 없기 때문이다.
이 분업을 가장 명확하게 표현하는 방식은 인간-에이전트 계약이다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 수락한다. 자동화는 팀의 판단이 필요한 지점에서 멈춘다. '결과를 수락하는' 단계까지는 모두 에이전트에게 맡길 수 있다. 수락 자체는 맡길 수 없고, 릴리스 결정도 마찬가지다. AI 어시스턴트 vs AI 팀원 글에서는 반대 방향에서 같은 선을 긋는다.
운영 모델: 할당, 실행, 리뷰, 수락
소유권과 실행을 분리하고 나면, 워크플로는 각각 하나의 일을 맡는 네 가지 역할로 나뉜다. 이 역할들에 이름을 붙이는 것이 병렬로 도는 에이전트 다섯 개가 고아 브랜치 다섯 개로 변하는 것을 막아준다.
| 단계 | 행위자 | 소유하는 것 |
|---|---|---|
| 할당 | 사람 | 작업이 할 가치가 있는지 결정하고, 인수 기준을 작성하고, 책임자를 지명하는 것 |
| 실행 | 컴퓨터의 런타임을 통해 동작하는 에이전트 | 변경을 만들어내고, 테스트를 돌리고, 무엇을 했고 무엇이 불확실한지 보고하는 것 |
| 리뷰 | 사람 Assignee | 인수 기준과 증거에 비추어 결과를 판단하는 것 |
| 수락 | 동일한 사람 Assignee | 병합하고 릴리스할지에 대한 결정 |
중요한 부분은 첫 번째와 마지막 행이다. 할당과 수락을 같은 사람이 소유한다. 이것이 루프를 닫는 방식이다. 작업이 가치 있다고 판단한 사람이 그 작업이 끝났음을 확인하는 사람이다. Sharkly는 이를 위해 Task 하나에 사람 Assignee와 Agent assignee라는 두 개의 할당 슬롯을 동시에 유지한다. 덕분에 책임과 실행이 모호한 '담당자' 하나가 아니라 별개의 사실로 기록된다. 작업이 에이전트에게 도달하는 방식은 에이전트 작업을 한곳에서 할당하고 추적하고 리뷰하기 가이드를 참고하라.
상태와 게이트: 에이전트는 '리뷰 준비 완료'까지, 사람이 '완료'로 옮긴다
운영 모델은 Task 상태에 매핑될 때 비로소 실체를 갖는다. 상태 변경은 나중에 가리켜 말할 수 있는 결정이기 때문이다. 여기서 규칙은 엄격하며 분명히 짚을 가치가 있다. 에이전트는 작업을 '리뷰 준비 완료'까지 진행시킬 수 있고, Task를 '완료'로 옮기는 것은 오직 사람뿐이다.
| 상태 범주 | 이동 주체 | 의미 |
|---|---|---|
| 백로그 | 사람 | 시작되지 않음. 이 상태에서 에이전트를 할당해도 아무것도 실행되지 않음 |
| 작업 준비 완료 | 사람 | Task를 이 범주로 옮기는 것이 에이전트 실행을 시작시킴 |
| 진행 중 | 에이전트 | 격리된 워크트리에서 실행이 진행 중 |
| 리뷰 준비 완료 | 에이전트 | 실행이 끝났고 지명된 사람을 기다리는 중 |
| 완료 / 수락됨 | 사람 | 사람이 증거를 읽고 결과를 수락함 |
이를 지키는 두 가지 경계가 있다. 첫째, 에이전트는 자신의 Task Workflow가 허용하지 않는 상태를 선택할 수 없다. 따라서 자기 작업을 수락됨으로 표시할 수 없다. 에이전트는 Task를 사람의 리뷰를 기다리는 상태로 남겨두고, 그 신호는 아무도 보지 않는 채널이 아니라 책임자의 Inbox로 들어간다. 둘째, 연결된 풀 리퀘스트를 병합해도 Task 상태는 바뀌지 않는다. 병합은 Git 이벤트이지 수락 결정이 아니며, Sharkly는 이 둘을 분리해서 'PR이 병합됨'이 '사람이 이게 맞다고 판단함'으로 오해되지 않게 한다. 리뷰 처리 능력이 걱정된다면, 인간 리뷰가 진짜 병목인 이유를 다룬 분석에서 이에 맞춘 설계 방법을 확인할 수 있다.
티켓에서 병합된 PR까지: 실제 사례 하나
Task 하나, SH-312 '공개 검색 엔드포인트에 속도 제한 추가하기'에서 이 모델이 처음부터 끝까지 어떻게 작동하는지 살펴보자.
- 할당. 엔지니어가 Task를 작성한다. 엔드포인트, 목표 제한값, 그리고 인수 기준(초과 시 429 응답, 기존 테스트 통과 유지, 제한에 대한 새 테스트 추가)이다. 자신을 사람 Assignee로 설정하고 Agent assignee를 고른다. Task는 백로그에 머문다. 아직 아무것도 실행되지 않는다.
- 실행. 그녀가
SH-312를 '작업 준비 완료' 상태로 옮긴다. 이 상태 변경이 실행을 시작시킨다. 에이전트가 Task를 가져가고, 이 작업이 다른 작업과 충돌하지 않도록 새 워크트리를 준비하고, 설명과 최근 댓글을 읽고, 엔드포인트를 수정하고, 테스트를 추가하고, 전체 테스트 스위트를 돌린다. - 보고. 에이전트가 풀 리퀘스트를 열고 Task에 댓글을 남긴다. 변경 요약, 실행한 테스트와 그 결과, 그리고 실제 트래픽에서 이 제한을 부하 테스트하지는 않았다는 솔직한 단서 하나. 그리고
SH-312를 '리뷰 준비 완료'로 옮긴다. 거기서 멈춘다. 더 나아갈 수 없다. - 리뷰. 리뷰 대기 신호가 엔지니어의 Inbox에 도착한다. 그녀는 순서대로 읽는다. 인수 기준, 에이전트의 댓글, 실행 로그, 그다음 diff. 로그는 실행이 왜 대기열에 들어갔는지, 어떤 도구 호출을 했는지 보여주므로, 그녀는 변경에 대한 이야기가 아니라 변경 자체를 리뷰하게 된다. 부하 테스트 누락은 실제 문제이므로, 문서화된 한계치에서의 테스트를 요청하는 댓글을 남긴다. 그 댓글은 같은 에이전트에 대한 후속 실행을 대기열에 넣는다. 그녀는 두 번째 Task를 열지 않는다.
- 수락. 에이전트가 테스트를 추가하고, 다시 보고하고, Task를 '리뷰 준비 완료'로 되돌린다. 이번에는 증거가 기준에 부합한다. 그녀는 PR을 병합하고
SH-312를 '완료'로 옮긴다. 처음부터 이 작업을 소유했던 사람이 의도적으로 취한 두 가지 행동이다.
모든 단계가 Task로 돌아온다. 실행, PR 링크, 리뷰 댓글, 수락까지. 터미널에만 존재하는 것은 아무것도 없다. Task 수준의 증거로 AI 생성 코드를 리뷰하는 방법 가이드에서는 수락하기 전에 무엇을 읽어야 하는지 더 깊이 다룬다.
소유권이 조용히 무너지는 지점
모든 Task에 이 모든 절차가 필요한 것은 아니며, 그렇다고 우기면 리뷰가 형식적인 쇼가 된다. 작업이 읽기 전용이거나 되돌리기 쉬울 때는 가벼운 버전을 쓰면 된다. 저장소 감사나 테스트가 통과한 의존성 업데이트는 실행에서 곧바로 빠른 수락으로 넘어가도 된다. 반대로 변경이 데이터를 건드리거나, 공개 인터페이스를 바꾸거나, 명령 하나로 되돌릴 수 없을 때는 양 끝에 사람을 지명한 네 역할 전체 루프를 사용하라.
경계해야 할 실패 유형은 에이전트가 너무 많이 하는 것이 아니다. 소유권이 할당되지 않는 것이다. Agent assignee는 있는데 사람 Assignee가 없는 Task는 책임 없는 실행이다. 진전인 척 위장한 고아 브랜치 문제일 뿐이다. 해결책은 어디에나 적용되는 하나의 규칙이다. 모든 에이전트 Task에는 그것을 소유하는 사람을 지명한다. 여러 에이전트 사이의 핸드오프를 조율할 때는 에이전트 간, 에이전트-사람 핸드오프 패턴 가이드에서 사람 소유자가 그 사슬의 어디에 위치하는지 보여준다.
결론
에이전트 작업에 대한 인간의 소유권은 자동화에 브레이크를 거는 것이 아니다. 자동화를 안전하게 확장할 수 있게 해주는 것이다. 실행은 전부 에이전트에게 맡겨라. 얼마나 빠르든 상관없다. 대신 네 가지 결정은 사람에게 남겨라. 무엇을 할당할지, 실행 권한을 부여할지, 결과가 기준을 충족하는지, 그리고 릴리스할지. 이 결정들을 공유된 Task의 상태 변경으로 기록하라. 그러면 책임은 누군가의 스크롤백 속 추측이 아니라 누구나 읽을 수 있는 사실이 된다.
이미 여러 코딩 에이전트를 돌리고 있다면, Sharkly는 에이전트 작업을 할당하고, 실행되는 모습을 지켜보고, 각 결과를 누가 리뷰하고 수락했는지 기록할 수 있는 한 곳을 제공한다. 워크트리와 스프레드시트로 이 모델을 직접 엮어도 되고, Sharkly를 다운로드해서 Task가 알아서 처리하게 해도 된다. 이 레이어의 전체적인 모습은 Claude Code와 Codex 위의 코딩 에이전트 관리부터 시작하면 된다.
FAQ
인간의 소유권이란 사람이 모든 에이전트 실행을 지켜봐야 한다는 뜻인가요? 아닙니다. 소유권은 감독이 아니라 책임입니다. 사람은 작업을 할당하고 결과를 수락하며, 그 사이의 실행은 에이전트가 무인으로 처리합니다. 어차피 터미널을 지켜보는 방식은 에이전트 하나 이상으로는 확장되지 않습니다.
에이전트가 자기 작업을 완료로 표시할 수 있나요? 아닙니다. 에이전트는 Task를 '리뷰 준비 완료'까지 진행시킬 수 있지만, 자신의 Task Workflow가 수락됨 상태를 허용하지 않습니다. 사람이 증거를 읽고 Task를 '완료'로 옮깁니다.
풀 리퀘스트를 병합하면 Task가 수락되나요? 아닙니다. 연결된 PR을 병합하는 것은 Git 이벤트이며 Sharkly에서 Task 상태를 바꾸지 않습니다. 수락은 리뷰 후 사람 소유자가 수행하는 별도의 상태 변경입니다.
에이전트의 Task는 누가 소유해야 하나요? 그 작업이 할 가치가 있다고 결정한 사람입니다. Sharkly는 Agent assignee 옆에 사람 Assignee 슬롯을 유지하므로, 리뷰 신호가 그 사람에게 전달되고 그 사람이 수락합니다.
사람이 할당되지 않으면 어떻게 되나요? 책임 없는 실행만 남습니다. 모든 에이전트 Task에 사람 소유자를 지명하는 것이 안전한 규칙이며, 그래야 완료된 실행에 대해 항상 답할 수 있는 사람이 존재합니다.
