버그 리포트는 보통 며칠씩 이슈 트래커에 누워 있다가, 그 버그가 숨어 있는 파일을 누군가 열어야 비로소 움직인다. 그리고 실제로 코드를 고치는 시간은 수리 과정 전체에서 가장 짧은 장인 경우가 많다. 달력을 잡아먹는 것은 그 주변부다. 브랜치를 따고, 왜 이 변경이 필요한지 설명하는 커밋 메시지를 쓰고, 밀어 올리고, 풀 리퀘스트를 열고, 리뷰하는 사람이 의도를 역추적하지 않아도 되도록 차이를 설명하고, 답을 기다리고, 지적에 맞춰 한 바퀴 더 고친다. 어느 하나 어려운 일은 없다. 그런데 겹쳐지면 하루를 생각하기 어려운 조각으로 잘라 놓는다.

GitHub Copilot의 코딩 에이전트가 겨냥하는 지점이 바로 이 잘린 중간 구간이다. 공식 설명은 문자 그대로 받아들이는 편이 좋다. 기대를 어디에 둘지가 거기서 정해지기 때문이다. 이것은 에디터 안에서 다음 질문을 기다리는 대화창이 아니라, 작업을 넘겨받아 백그라운드에서 끝까지 스스로 끌고 가는 역할이다. 그동안 이쪽은 다른 일을 처리할 수 있다.

이슈를 넘기면 풀 리퀘스트가 돌아온다

방식은 소박하다. 어떤 이슈를 Copilot에게 배정하거나, 어느 화면에서든 에이전트 패널에서 작업을 띄우면 된다. 그러면 이슈 제목과 본문, 이미 달린 댓글을 들고 시작해, 자기 전용 임시 개발 환경에서 저장소를 훑고, 계획을 세우고, 코드를 고치고, 마지막에 풀 리퀘스트를 연다. 끝나면 이쪽을 리뷰어로 등록하고 알림을 보낸다. 인수인계가 실제로 눈에 들어오는 자리에 떨어지는 셈이다.

그 환경은 지속적 통합 기능 위에서 돌아간다. 결과를 보기도 전에 프로젝트의 테스트와 정적 검사를 돌릴 수 있고, 저장소에 이미 적혀 있는 준비 절차대로 작업 공간을 먼저 세팅할 수도 있다. 데이터베이스와 배후 서비스 몇 개가 살아 있어야 테스트가 통과하는 프로젝트라도, 그 준비를 짐작으로 넘기지 않아도 된다.

요구가 바뀔 때 걸려 넘어지기 쉬운 지점이 하나 있다. 배정한 뒤에 이슈에 덧붙인 댓글은 에이전트가 보지 못한다. 추가 요청은 에이전트가 연 풀 리퀘스트 쪽에 남겨야 한다. 거기에 한 줄 적으면 새 세션을 열어 처리하고, 같은 풀 리퀘스트에서 앞선 세션의 맥락이 유지되기 때문에 두 번째 요청이 첫 번째보다 빠르고 오해도 적게 도착한다. 지속적 통합 워크플로가 실패했을 때도 경로는 같다. 실패를 넘기면 조사하고 수리를 밀어 올린다.

세상에 나오기 전에 스스로 읽는다

기계가 쓴 변경을 리뷰하는 일이 지치는 이유는 명백히 망가져 있어서가 아니다. 돌아갈 것처럼 보이는데 팀의 누구도 그렇게 쓰지 않았을 형태로 오기 때문이다. 공식 구성은 풀 리퀘스트를 열기 전에 코딩 에이전트가 코드 리뷰 기능으로 자기 패치를 먼저 읽고, 돌아온 지적으로 반복 개선하도록 되어 있다. 이쪽이 리뷰어로 등록될 시점에는 이미 한 차례가 끝나 있는 상태다.

같은 흐름에서 코드 스캔, 시크릿 스캔, 의존 패키지 취약점 검사도 함께 돈다. 알려진 문제가 있는 의존성이나, 실수로 커밋한 자격 증명처럼 보이는 문자열은 리뷰하는 사람이 발견하기 전이 아니라 풀 리퀘스트가 보이기 전에 표시된다.

팀의 방식을 설정 파일에 적어 넣기

짧은 프롬프트는 그 자리에서 판단할 여지를 크게 남긴다. 그리고 그 자리의 판단이 팀의 실제 방식과 늘 맞지는 않는다. 그 부분을 고정하는 것이 커스텀 에이전트다. 저장소에 설정 파일 하나를 두면 어떤 종류의 작업을 어떤 순서로 진행할지 지정할 수 있다. 예를 들어 성능 개선 에이전트라면 먼저 측정하고, 다음에 코드를 바꾸고, 바꾼 뒤 다시 측정해 효과를 숫자로 보여 주고, 그다음에야 풀 리퀘스트를 연다. 이 설정은 조직이나 기업 단위로 공유할 수 있어서, 팀마다 사설 절차를 여러 벌 키우는 대신 하나의 흐름으로 모인다.

데스크톱에서는 세션이 나란히 놓인다

동시에 도는 작업이 늘어나면 어려움은 '어떻게 분리해 둘 것인가'로 옮겨 간다. 데스크톱 앱은 이슈, 풀 리퀘스트, 한 문장, 지난 세션 어디에서든 작업을 띄울 수 있고, 여러 에이전트 세션을 병렬로 돌릴 수 있다. 세션마다 작업 트리와 브랜치가 따로 주어지므로 파일도 대화도 작업 상태도 섞이지 않는다. Windows, macOS, Linux용 빌드가 있고, 변경은 통합 터미널과 브라우저에서 확인할 수 있으며, 열리는 풀 리퀘스트는 팀이 이미 쓰는 리뷰와 검사, 병합 규칙을 그대로 통과한다.

코딩 에이전트는 백그라운드에서 작업을 넘겨받아 브랜치 생성, 커밋, 풀 리퀘스트 개설까지 옆에서 떠밀지 않아도 혼자 걸어간다.

넘기기 전 자기 점검은 먼저 코드 리뷰로 반복 개선하고, 이어서 코드와 시크릿, 의존성 스캔을 돌린다.

병렬 세션은 데스크톱의 각 세션에 작업 트리와 브랜치를 따로 주어 같은 파일을 동시에 건드리지 않게 한다.

비용은 어떻게 계산되나

개인 요금제는 2026년 6월부터 사용량 기반 과금으로 바뀌었고, 무료 Free 단계에서 Pro, Pro+, Max까지 이어진다. Free에는 완성 기능의 한도와 채팅 및 에이전트 사용량 한도가 붙지만, 명령줄 도구와 에이전트 모드도 함께 들어 있어서 일단 시험하는 데 돈이 들지는 않는다. 유료 단계에서는 기본 한도가 구독 가격과 일대일로 대응하고, 그 위에 비용에 따라 움직이는 탄력 한도가 더해진다. 완성과 다음 편집 제안은 유료에서 무제한이며 한도도 쓰지 않는다. 세부 단계와 숫자는 공식 가격 페이지가 유일하게 믿을 만한 출처다.

코드를 쓰는 일은 절반이다. 나머지 절반은 그 변경을 리뷰와 검사, 병합 너머로 통과시키는 일이고, 이 구성은 그 나머지까지 맡는다. 그래서 사람은 정말로 판단이 필요한 자리에만 나타나면 된다.