비동기 코딩 에이전트 실전: 던질 일과 붙잡을 일
이슈를 할당하고 자리를 비우는 건 쉽다. 어려운 건 돌아왔을 때다. 던져도 되는 일과 옆에 붙어 있어야 하는 일을 가르는 기준을 정리했다.
퇴근 10분 전, 이슈 세 개를 에이전트에게 할당했다. 다음 날 아침 PR이 세 개 와 있다. 하나는 읽자마자 머지했다. 하나는 코멘트를 두 번 주고받고 나서야 들어갔다. 마지막 하나는 닫았다. 이슈에 쓴 "로그인 오류 수정"이 무슨 오류인지 에이전트도, 하루 지난 나도 정확히 몰랐으니까.
비동기 코딩 에이전트 워크플로는 이 세 가지 결과의 비율을 바꾸는 일이다. GitHub Copilot 코딩 에이전트, Cursor 클라우드 에이전트, OpenAI Codex 클라우드 모두 "맡기고 딴 일 하기"를 내세운다. 그런데 무엇을 맡기느냐에 따라 아침의 PR은 선물이 되기도, 숙제가 되기도 한다.
던지고 나면 실제로 벌어지는 일
Copilot을 예로 들면 흐름은 단순하다. 이슈의 담당자(Assignees)에 Copilot을 지정하면 👀 반응이 붙고, copilot/ 브랜치와 초안(draft) PR이 생긴다. 작업은 GitHub Actions 기반 환경에서 돌고, 끝나면 리뷰 요청 알림이 온다.
여기까진 홍보 문구와 같다. 실전에서 발목을 잡는 건 Microsoft Learn 공식 교육 문서에 조용히 적혀 있는 세부 사항이다.
| 규칙 | 실전에서 의미하는 것 |
|---|---|
| 할당 시점의 제목·본문·기존 댓글만 읽는다 | 할당 뒤 이슈에 단 댓글은 에이전트가 못 본다. 보충할 내용은 PR 쪽에 @copilot으로 남겨야 한다. 즉 할당하는 순간의 이슈가 지시서의 전부다. |
| PR은 항상 초안, 워크플로는 자동 실행 안 됨 | "Approve and run workflows"를 눌러야 CI가 돈다. 아침에 와 보니 테스트가 한 번도 안 돌았을 수 있다. |
| 요청한 사람은 그 PR을 승인할 수 없다 | 혼자 쓰는 저장소가 아니라면 리뷰어가 따로 필요하다. 맡긴 사람이 셀프 승인하는 구조를 막아 둔 것이다. |
| 세션은 1시간이 지나면 타임아웃 | 반나절짜리 작업을 한 이슈에 몰아넣으면 중간에 끊긴다. 쪼개서 던지는 게 기본이다. |
Cursor 쪽도 결이 같다. 에이전트가 클라우드 VM에서 저장소를 복제해 브랜치에서 작업하고 PR을 연다. Cursor는 2026년 2월 발표에서 사내에서 머지되는 PR의 30% 이상을 이런 자율 에이전트가 만든다고 밝혔다. 도구를 만드는 회사가 직접 그 정도 비율로 쓰고 있다는 얘기다.
머지는 되는데, 끝난 건 아니다
숫자만 보면 낙관할 만하다. 2025년 Claude Code로 만든 PR 567건(오픈소스 프로젝트 157곳)을 분석한 와타나베 등의 연구에서 83.8%가 결국 머지됐다. 그런데 머지된 것 중 수정 없이 그대로 들어간 건 54.9%였다. 나머지 45.1%는 사람이 손을 더 댔다.
머지 이후도 있다. 2026년 9월 공개된 프리프린트는 별 500개 이상 저장소에서 머지된 에이전트 PR 6,774건과 같은 시기 사람 PR 5,044건을 비교했다. 에이전트 PR에 후속 수정이 붙을 오즈(odds)는 사람 PR의 1.62배였다. 흥미로운 건 그 수정을 누가 했느냐다. 확인된 수정의 69.6%는 원래 PR을 만든 바로 그 에이전트가 했다.
에이전트를 여러 개 동시에 돌릴 때는 다른 문제가 생긴다. 2026년 7월의 또 다른 프리프린트가 같은 저장소에서 동시에 열린 에이전트 PR 747쌍의 병합을 재현해 봤더니, 같은 에이전트끼리는 19.8%, 서로 다른 에이전트끼리는 41.7%가 텍스트 충돌을 냈다.
관점을 바꾸면
비동기 위임은 일을 없애 주지 않는다. 주의(attention)를 쓰는 시점을 뒤로 옮길 뿐이다. 작성 시간은 에이전트가 가져가지만 판단 시간은 고스란히 아침의 리뷰로 넘어온다. 그래서 질문은 "맡길 수 있나"가 아니라 "돌아왔을 때 10분 안에 판단할 수 있나"가 된다.
물론 반대쪽 주장도 일리가 있다. 사람이 퇴근한 사이 초안이 생긴다는 것 자체가 이득이고, 후속 수정도 대부분 에이전트가 하니 사람 부담은 생각보다 작다는 것이다. 두 주장 다 맞다. 차이는 어떤 작업을 던졌느냐에서 갈린다.
던져도 되는 일을 고르는 기준 4가지
이슈를 할당하기 직전, 아래 네 질문에 답해 본다. 하나라도 "아니오"면 그 작업은 옆에 붙어서 동기로 하는 편이 낫다.
| 질문 | "예"의 신호 | "아니오"의 신호 |
|---|---|---|
| 범위가 문장 하나로 닫히나 | "/api/orders 응답에 createdAt 필드 추가" | "주문 쪽 좀 정리", "로그인 오류 수정" |
| 맞았는지 기계가 판정하나 | 실패하는 테스트·린트·타입 검사가 이미 있다 | "화면이 자연스러워 보이면 OK" |
| 틀려도 PR 닫으면 끝인가 | 새 파일·문서·테스트 추가, 의존성 버전 올리기 | DB 마이그레이션, 결제·권한 로직, 공용 설정 |
| 아침에 10분 안에 리뷰되나 | diff가 몇백 줄 이내로 예상된다 | 여러 모듈을 가로지르는 리팩터링 |
넷 중 건너뛰기 가장 쉬운 건 두 번째 질문이다. 테스트가 없는 작업을 던지면 에이전트는 "돌아가 보이는 코드"를 가져오고, 그게 맞는지는 결국 사람이 처음부터 확인해야 한다. 그럴 바엔 먼저 실패하는 테스트를 하나 써 두고 "이 테스트를 통과시켜라"로 던지는 게 낫다. 테스트 하나를 먼저 쓰는 수고가, 아침에 코드 전체를 처음부터 의심하는 수고보다 작다.
세 번째는 비용의 비대칭이다. 문서 PR이 틀리면 닫으면 된다. 마이그레이션이 틀리면 롤백 계획부터 세워야 한다. 와타나베 연구에서도 에이전트에게 주로 맡겨진 일은 리팩터링·문서·테스트였다. 사람들이 이미 본능적으로 이 선을 지키고 있다는 뜻이다.
지시서 쓰는 법, 그리고 망했을 때
할당하는 순간의 이슈가 지시서의 전부라면, 이슈를 지시서답게 쓰면 된다. 매번 이 틀을 쓴다.
## 목표 (한 문장)
/api/orders 응답에 createdAt(ISO 8601) 필드를 추가한다.
## 완료 조건
- tests/orders.spec.ts 의 "includes createdAt" 테스트 통과
- 기존 테스트 전부 통과, 린트 경고 0
## 건드리지 말 것
- db/migrations/, src/auth/
## 참고
- 비슷한 구현: src/api/invoices.ts 의 toResponse()"건드리지 말 것" 칸이 생각보다 효과가 크다. 에이전트는 친절해서 근처의 이상한 코드까지 고쳐 주는데, 그 친절이 diff를 부풀리고 다른 에이전트의 PR과 충돌을 만든다. 저장소 공통 규칙은 .github/copilot-instructions.md 같은 지침 파일에 한 번 적어 두면 이슈마다 반복하지 않아도 된다.
망한 PR을 다루는 순서
- 코멘트로 고치기는 두 번까지. PR에 @copilot으로 수정 요청을 두 번 했는데도 방향이 틀렸다면, 문제는 코드가 아니라 지시서다.
- PR을 닫고 이슈를 다시 쓴다. 무엇이 오해됐는지 "완료 조건"과 "건드리지 말 것"에 반영한 뒤 다시 할당한다. 고쳐 쓰는 것보다 새로 던지는 게 대개 싸다.
- 동시에 던질 땐 파일이 겹치지 않게. 같은 파일을 만지는 이슈 두 개를 같은 밤에 던지면, 아침에 받는 건 충돌 두 개다.
맡긴 사람이 리뷰까지 끝내야 위임이 끝난다
머지 버튼을 누르는 순간 그 코드는 당신 이름으로 들어간다. 에이전트가 후속 수정을 대부분 해 준다는 데이터는, 첫 리뷰를 건너뛰어도 된다는 뜻이 아니다.
커피를 마시는 동안 할 일
비동기 에이전트를 잘 쓰는 사람의 하루는 의외로 손이 바쁘다. 작업을 쪼개고, 실패하는 테스트를 먼저 쓰고, "건드리지 말 것"을 적고, 아침엔 diff부터 연다. 코드를 덜 치는 대신 지시와 판단에 시간을 쓴다.
오늘 퇴근 전에 던질 이슈 하나를 골라 위의 네 질문을 붙여 보자. 네 번 다 "예"라면 정말로 커피를 마시러 가도 된다. 하나라도 걸린다면, 그 일은 아직 옆에서 같이 하는 게 맞다.
참고: GitHub Docs — Copilot에게 이슈 맡기기 · 프리프린트(arXiv 2609.26847, 2607.04697)는 동료 심사 전 결과이므로 경향으로 읽을 것.