PR을 열 수 있는 코딩 에이전트는 유용합니다. 아무도 지켜보지 않는 사이에 PR을 병합할 수 있는 코딩 에이전트는 커밋 권한을 가진 위험 요소입니다. 이 두 문장 사이의 간극이 바로 문제의 전부입니다. 에이전트가 브랜치에 푸시하고, 테스트를 실행하고, 병합 버튼을 누를 수 있게 되는 순간, 질문은 “일을 할 수 있는가”에서 “그 권한은 어디까지인가”로 바뀝니다.
대부분의 팀은 이 질문에 어쩌다 보니 답하게 됩니다. 에이전트는 런타임에 부여된 권한을 그대로 가지며, 리뷰는 실행이 시작된 터미널에서 이루어지고, 누가 무엇을 승인했는지에 대한 기록은 한 사람의 스크롤백에 남습니다. 이 방식은 두 저장소에 걸쳐 세 에이전트를 돌리고 금요일 배포가 아무도 읽지 않은 무언가를 내보내기 전까지는 버팁니다. 승인 게이트가 해결책이지만, 모두가 지키길 바라는 습관이 아니라 공유 시스템 안의 실제 체크포인트일 때만 그렇습니다.
그 공유 시스템이 바로 Sharkly가 제공하는 것입니다. 이미 코딩 에이전트는 가지고 계실 겁니다. Sharkly는 그 실행을 상태, Assignee, 그리고 사람이 의도적으로 수행해야 하는 리뷰 단계가 있는 Task로 바꿔 줍니다. 이 글에서는 그 뒤에 있는 운영 모델을 살펴봅니다: 누가 작업을 할당하고, 누가 실행하고, 누가 리뷰하고, 누가 수락하며, 에이전트가 자신의 변경을 리뷰 없이 병합하지 못하도록 정지 지점이 정확히 어디에 있어야 하는지까지.
승인 게이트란 실제로 무엇인가
승인 게이트는 작업 수명주기에서 자동 실행이 멈추고 사람이 다음 단계를 결정할 때까지 기다리는 지점입니다. 경고도, 그냥 지나쳐 스크롤할 수 있는 로그 한 줄도 아닙니다. 사람이 움직이기 전까지 작업이 머무는 상태입니다.
가장 중요한 구분은 에이전트가 변경을 제안하는 것과 변경을 반영하는 것 사이입니다. 풀 리퀘스트를 여는 것은 제안입니다. 병합하는 것은 프로덕션에 대한 결정입니다. 이 둘은 서로 다른 권한 행사이며, 두 번째에 팀의 판단이 있어야 합니다. Sharkly는 이 경계를 명시적으로 만듭니다: GitHub가 연결되어 있어도 풀 리퀘스트를 병합한다고 해서 Task 상태가 바뀌지 않습니다. 병합은 에이전트가 완료하면서 일으키는 부작용이 아니라, 기록에 남는 사람의 행동으로 유지됩니다.
이 경계를 기억해 두세요. 대부분의 “에이전트가 프로덕션을 망가뜨렸다”는 이야기는 사실 제안과 반영 사이에 빠진 게이트에 관한 이야기입니다.
운영 모델: 할당, 실행, 리뷰, 수락
Sharkly는 작업을 네 가지 역할로 나누고, 각 역할에 하나의 임무를 부여합니다. 계약은 명확합니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 수락합니다.
- 할당. 사람이 필요를 설명하고 Assignee를 설정합니다. Task는 두 가지 별도 할당을 가집니다: Task에 포함된 People과, 작업을 실행하는 단일 실행 Assignee인 Agent 또는 Crew입니다. 하나를 바꾸어도 다른 하나는 바뀌지 않습니다.
- 실행. 실행 Assignee가 격리된 git 워크트리에서 작업하므로 병렬 실행이 서로의 파일을 건드리지 않습니다. 진행 상황, 차단 요소, 결과는 Task로 돌아옵니다.
- 리뷰. Agent가 끝나면 Task를 닫는 대신 사람의 리뷰를 기다리는 상태로 남깁니다. diff, 테스트 출력, 변경 요약은 터미널이 아니라 Task에 첨부됩니다.
- 수락. 사람이 증거를 읽고 결정합니다: 변경을 요청하거나, 수락하고 병합합니다. 수락은 최종 행동이며, 오직 사람만이 수행합니다.
여기서 가치 있는 것은 Sharkly가 에이전트를 실행한다는 점이 아닙니다. 네 역할이 열려 있던 터미널로 흩어지지 않고 한곳에서 계속 보인다는 점입니다. 리뷰 절반에 대한 더 깊은 내용은 휴먼 인 더 루프 코딩 에이전트를 참고하세요.
게이트를 습관이 아닌 상태로 만들기
기억해야 하는 게이트는 언젠가 건너뛰게 되는 게이트입니다. 그러니 작업 수명주기에 새겨 넣으세요.
Sharkly의 상태는 카테고리를 통해 시스템적 의미를 지닙니다. Backlog는 대기 상태입니다. Agent가 할당되어 있어도 그곳의 Task는 실행되지 않습니다. 작업 준비 완료 범주로 옮겨야 실행이 시작됩니다. Completed는 최종 상태이며, 거기에 도달하는 것은 사람의 움직임이지 Agent가 스스로 부여하는 것이 아닙니다.
Task 상태는 Agent의 작업 상태와 의도적으로 분리되어 있습니다. 수명주기 상태가 In Progress로 표시되는 동안, 그 아래의 Agent는 작업 중이거나, 사람의 답변을 기다리거나, 사람의 리뷰를 기다리거나, 오류를 보고하는 중일 수 있습니다. 이 분리가 바로 게이트입니다. Agent는 실행을 끝내고 “사람 리뷰 대기 중”을 표시할 수 있지만, Task가 출시되었음을 암시하는 상태로 넘어가지는 않습니다. 작업은 Task로 돌아와 멈추고, 누군가 수락할 때까지 그대로 있습니다.
이 점 덕분에 여러 에이전트를 동시에 안전하게 실행할 수 있습니다. 다섯 개의 격리된 워크트리의 병렬 에이전트가 모두 같은 리뷰 칼럼에 도착하면, 다섯 개의 터미널을 돌보는 대신 한곳에서 분류할 수 있습니다.
구체적인 예시: 티켓에서 병합된 PR까지
Sharkly의 SH-312 식별자 형식을 사용해 Task 하나를 따라가 보겠습니다.
- 등록. 사람이 버그 작업
SH-312를 만듭니다: “필터 변경 후 검색이 오래된 결과를 반환함.” 설명에는 목표, 재현 방법, 수락 기준이 담깁니다. Assignee: 검색 저장소에 바인딩된 Claude Code Agent. - 구체화. Agent가 코드베이스와 관련 이력을 조사하고, 범위를 확인한 뒤, 계획을 Task에 다시 게시합니다. 사람이 계획을 읽고
SH-312를 Backlog에서 준비 상태로 옮기면, 이것이 시작 신호입니다. - 실행. Agent가 Task를 가져가 새 워크트리에서 작업합니다. 수정 사항을 작성하고, 타입체크와 테스트 스위트를 실행하고, 제목에
SH-312가 포함된 풀 리퀘스트를 열어 Sharkly가 PR을 Task에 다시 연결하도록 합니다. - 게이트에서 정지. Agent는 병합하지 않습니다. 변경 요약, 통과한 테스트 출력, 알려진 제약을 첨부한 뒤
SH-312를 사람 리뷰 대기 상태로 남깁니다. 작업이 Task로 돌아온 것입니다. - 리뷰. 사람이
SH-312를 열고, 한 화면에서 diff와 증거를 읽고, 수정이 공유 쿼리 헬퍼를 건드렸다는 점을 알아챕니다. 더 좁은 변경을 요청하는 댓글을 남깁니다. 준비된 Agent Assignee가 있는 Task에서는 이 댓글이 실행을 다시 큐에 넣으므로, 변경 요청 루프가 비공개 채팅에서 다시 시작되지 않고 기록에 남습니다. - 수락 및 병합. 두 번째 실행이 리뷰를 통과합니다. 사람이 풀 리퀘스트를 승인하고 병합한 뒤
SH-312를 Completed로 옮깁니다. 병합이 Task를 자동으로 닫지 않기 때문에, 수락과 병합은 하나의 자동 연쇄가 아니라 기록된 두 번의 사람 결정입니다.
그 체인의 모든 단계는 나중에 검사할 수 있습니다. 이것이 추적 가능한 요구사항-투-코드 워크플로의 핵심입니다: 누군가의 스크롤백을 고고학처럼 뒤지지 않고도 “누가 이것을, 어떤 증거를 근거로 승인했는가”에 답할 수 있습니다.
게이트를 두지 말아야 할 곳
게이트가 많다고 자동으로 더 안전해지는 것은 아닙니다. 게이트는 마찰을 더하고, 사람들이 그냥 클릭해 넘기도록 훈련시킵니다. 잘못된 병합의 비용이 실제로 큰 곳에 게이트를 두세요. 작고 명확하며 위험이 낮은 변경이 단일 Agent에 할당된 경우에는 병합 전 리뷰 중단으로 충분하며, Crew나 추가 승인 단계를 겹쳐 둘 필요가 없습니다. 영향 범위가 클 때는 더 무거운 리뷰를 추가하세요: 공유 코드, 마이그레이션, 인증이나 결제를 건드리는 모든 것.
절대 제거하지 말아야 할 게이트는 병합 게이트입니다. Agent는 하루 종일 조사하고, 작성하고, 테스트하고, 제안할 수 있습니다. 그 변경이 메인 브랜치에 도달할지는 사람의 결정이며, Agent가 대부분의 경우 옳더라도 그렇게 남아야 합니다. Sharkly의 작업 수준 리뷰를 기존 브랜치 보호와 함께 사용해 플랫폼이 워크플로의 의도를 강제하도록 하고, 팀이 이미 사용하는 도구는 그대로 유지하세요: GitHub를 연결하고 프로세스를 다시 만들지 않고도 AI 에이전트에 티켓 할당할 수 있습니다.
이미 여러 코딩 에이전트를 실행 중이고 어떤 것이 끝났고, 어떤 것이 실패했고, 어떤 것이 여러분을 기다리는지 놓치고 있다면, 그 리뷰 칼럼이 Sharkly를 시도할 이유입니다. 기존 에이전트를 Sharkly를 통해 실행하고, 병합 결정은 있어야 할 곳에 두세요.
자주 묻는 질문
Sharkly가 에이전트가 스스로 병합하는 것을 막을 수 있나요? 네. Sharkly에서 풀 리퀘스트를 병합해도 Task 상태는 바뀌지 않으므로, 실행은 변경을 반영하는 대신 “사람 리뷰 대기 중”에서 끝납니다. 여기에 GitHub 브랜치 보호를 함께 사용하면 저장소 수준에서 필수 리뷰를 강제할 수 있습니다.
Task 상태와 에이전트 상태의 차이는 무엇인가요? Task 상태는 수명주기 범주입니다(Backlog, Started, Completed 등). 에이전트 상태는 실행이 지금 무엇을 하고 있는지입니다: 작업 중, 사람 답변 대기, 리뷰 대기, 오류. Task는 Agent가 여러분을 기다리는 동안 In Progress에 머물 수 있습니다.
리뷰가 필요한 모든 Task에 Crew가 필요한가요? 아닙니다. 작고 범위가 잘 정해진 작업에는 Task를 하나의 Agent에 할당하고 병합 전 리뷰 게이트를 사용하세요. Crew는 리더 Agent가 여러 멤버를 조정해야 하는 목표를 위해 남겨 두세요.
