Copilot cloud agent가 자동화 API로 진화하고 있다

GitHub은 이번 달 조용히 중요한 선을 넘었습니다. 이제 Copilot cloud agent 태스크를 REST API를 통해 시작할 수 있습니다.

이것은 단순한 제품 업데이트처럼 들릴 수 있습니다. 또 다른 엔드포인트(endpoint), 또 다른 프리뷰 기능(preview feature) 말이죠.

하지만 저는 이것이 해당 카테고리가 어디로 향하고 있는지를 알려주는, 겉보기에는 지루해 보이는 변화 중 하나라고 생각합니다.

일단 에이전트(agent)를 API로 시작할 수 있게 되면, 그것은 자동화 인프라(automation infrastructure)가 됩니다.

"어시스턴트에게 이 파일을 수정해달라고 요청하기"가 아닙니다.

그보다는 다음과 같은 방식에 가깝습니다: 내부 개발자 포털(internal developer portal)이 레포지토리(repo)를 생성하고, 추적 가능한 에이전트 태스크를 열고, 진행 상황을 모니터링하며, 풀 리퀘스트(pull request)를 수집합니다. 또는 마이그레이션 스크립트(migration script)가 여러 레포지토리에 걸쳐 의존성 업그레이드를 확산시킵니다. 혹은 릴리스 워크플로(release workflow)가 에이전트에게 주간 PR을 준비하도록 요청합니다.

이것은 매우 유용합니다.

동시에 진짜 문제들이 시작되는 지점이기도 합니다.

UI는 보조 바퀴였다

대부분의 팀은 채팅(chat)을 통해 코딩 에이전트(coding agent)를 처음 접합니다.

그것은 괜찮습니다. 채팅은 도구의 형태를 배우기에 좋은 방법입니다. 리팩터링(refactor)을 요청하면, 도구가 차이점(diff)을 제안하고, 테스트를 실행합니다. 사용자는 그 작업이 충분히 괜찮은지 결정합니다.

여전히 스케줄러(scheduler)는 인간입니다.

인간이 태스크를 선택하고, 범위를 설정하며, 언제 멈출지를 결정합니다. 모든 곳에 마찰(friction)이 존재하며, 그 마찰은 누락된 많은 플랫폼 설계(platform design)를 숨기고 있습니다.

API는 그러한 마찰 중 일부를 제거합니다.

이제 에이전트는 다른 시스템에 의해 트리거(triggered)될 수 있습니다. 이는 에이전트가 큐(queue)에 쌓일 수 있고, 재시도(retried)될 수 있으며, 템플릿화(templated)되고, 속도 제한(rate limited)될 수 있으며, 관찰(observed)되고, 기존 엔지니어링 워크플로(engineering workflows) 내에 내장될 수 있음을 의미합니다.

이 순간은 "AI 코딩 어시스턴트(AI coding assistant)"가 "우연히 코드를 작성하는 백그라운드 워커(background worker)"처럼 보이기 시작하는 지점입니다.

그리고 백그라운드 워커에게는 지루한 것들이 필요합니다.

그들에게는 소유권(ownership)이 필요합니다. 권한(permissions)이 필요합니다. 멱등성(idempotency)이 필요합니다. 로그(logs)가 필요합니다. 누군가 새벽 3시에 실행 중인 것을 발견했을 때, 그것이 존재해야 할 이유가 필요합니다.

태스크 경계가 곧 제품이 된다

흥미로운 점은 단순히 API가 태스크 (task)를 시작한다는 것만이 아닙니다. 진짜 흥계로운 점은 무엇이 '좋은 태스크'로 간주되느냐 하는 것입니다.

"우리 서비스들을 현대화해줘"는 태스크가 아닙니다. 그것은 리포지토리 (repo)가 첨부된 하나의 바람일 뿐입니다.

"이 14개의 리포지토리에서 이 의존성 (dependency)을 버전 X에서 Y로 업그레이드하고, 표준 테스트를 실행하며, 공개 동작 (public behavior)을 변경하지 말고, 체크리스트가 포함된 PR을 리포지토리당 하나씩 생성해줘"가 그나마 태스크에 가깝습니다.

이러한 차이는 매우 중요합니다. 왜냐하면 에이전트 (agent)들은 모호한 작업을 마치 바쁜 것처럼 보이게 만드는 데 유난히 능숙하기 때문입니다. 만약 경계가 느슨하다면, 에이전트는 그 빈 공간을 그럴듯한 활동들로 채울 것입니다. 추가적인 정리 작업, 부수적인 리팩토링 (refactor), 생성된 테스트, 패키지 변경, 포맷팅 (formatting) 변경, 어쩌면 아무도 요청하지 않은 아주 작은 아키텍처 (architecture)에 대한 의견까지 말이죠.

때로는 그것이 도움이 될 수도 있습니다. 하지만 대개는 작은 자동화가 리뷰 부채 (review debt)로 변하는 방식이기도 합니다.

API는 태스크 설계 (task design)를 플랫폼의 관심사로 만듭니다. 내부 도구들은 명시적인 범위 (scope)를 가진 태스크 템플릿 (task template)을 필요로 하게 될 것입니다:

어떤 리포지토리들이 대상인지
어떤 파일들을 변경할 수 있는지
어떤 명령어를 실행할 수 있는지
어떤 테스트들이 필수적인지
어떤 라벨 (label)과 리뷰어 (reviewer)가 지정되는지
에이전트가 계속 진행하기 전에 어떤 변경 사항에 인간의 승인이 필요한지
즉흥적으로 행동하는 대신 태스크를 언제 중단해야 하는지

대안과 비교해 보기 전까지는 이 과정이 매우 무겁게 느껴질 수 있습니다. 대안이란, 모든 팀이 일관된 리뷰 모델도 없이 스크립트 내부에서 제각각 에이전트 프롬프트 (agent prompt)를 만들어내는 상황입니다.

프로그래밍 방식의 에이전트에는 큐 규율 (queue discipline)이 필요하다

자동화를 통해 에이전트 태스크를 시작할 수 있게 되면, 얼마나 많은 태스크를 실행할지 결정해야 합니다.

이는 단순히 비용의 문제만이 아닙니다. 인간의 리뷰 역량에 관한 문제이기도 합니다.

만약 마이그레이션 (migration) 스크립트가 어느 오후에 에이전트가 작성한 80개의 PR을 한꺼번에 열어버린다면, 팀의 생산성이 높아진 것일까요, 아니면 병목 현상 (bottleneck)이 리뷰 단계로 옮겨간 것뿐일까요?

그 답은 태스크의 품질과 리뷰어의 수용 능력에 달려 있습니다. 강력한 테스트를 동반한 기계적인 의존성 업데이트는 대량 실행 (fan-out)에 완벽할 수 있습니다. 하지만 핵심 서비스 전반에 걸친 미묘한 프레임워크 마이그레이션이 점심시간 전에 갑작스럽게 생성된 PR 더미로 쏟아져 나와서는 안 될 것입니다.

자동화 API (Automation APIs)는 처리량 (throughput)을 진척도 (progress)와 혼동하기 매우 쉽게 만듭니다.

큐 (queue)는 다운스트림 시스템 (downstream system)을 이해해야 합니다. 이 팀은 오늘 얼마나 많은 에이전트 PR을 검토할 수 있습니까? 어떤 리포지토리 (repos)에 담당자가 있습니까? 어떤 변경 사항이 릴리스 동결 (release freezes)에 의해 차단되어 있습니까?

그렇기 때문에 저는 에이전트 작업 API를 "모든 것을 수정하기"라고 불리는 버튼에 직접 연결하지 않을 것입니다.

저는 명시적인 작업 (task), 리포지토리 (repository), 검토자 (reviewer), 재시도 (retry), 그리고 영향 범위 (blast-radius) 예산이 설정된 큐 (queue) 뒤에 이를 배치할 것입니다. 핵심은 에이전트를 느리게 만드는 것이 아닙니다. 핵심은 에이전트의 작업이 인간이 실제로 수용할 수 있는 형태로 도달하게 만드는 것입니다.

정체성 (identity)은 각주가 아니다

GitHub 프리뷰는 현재 개인 액세스 토큰 (personal access tokens)과 OAuth 토큰을 지원하며, GitHub App 설치 액세스 토큰은 추후 지원될 예정입니다.

그 토큰에 대한 세부 사항은 작아 보일 수 있지만, 플랫폼 팀은 이를 신경 써야 합니다.

만약 내부 포털이 에이전트 작업을 시작한다면, 그것은 누구의 권한을 사용하는 것입니까? 버튼을 클릭한 개발자입니까? 포털 서비스 계정 (service account)입니까? 승인된 리포지토리에 설치된 GitHub App입니까?

그 답변에 따라 감사 (audit) 기록이 달라집니다.

에이전트가 PR을 열고, 파일을 수정하고, 체크를 실행하거나, 실패에 대해 댓글을 달 때, 조직은 어떤 인간의 요청, 어떤 자동화 워크플로 (automation workflow), 그리고 어떤 정책 (policy)이 해당 작업을 허용했는지 알아야 합니다.

"Paulo가 버튼을 클릭했다"는 것만으로는 충분하지 않습니다.

"서비스 템플릿 워크플로가 정책 Z 하에, 요청 ABC로부터, 자동화 정체성 Y를 사용하여, 리포지토리 X에 대한 작업 8f7c를 시작했다"와 같은 지루한 문장이 보안 담당자들을 불안하게 만들지 않도록 유지해 줍니다.

이것이 또한 제가 샌드박싱 (sandboxing), 네트워크 정책 (network policies), 승인 (approvals), 그리고 에이전트 네이티브 텔레메트리 (agent-native telemetry)를 향한 업계 전반의 움직임을 지지하는 이유이기도 합니다. 코딩 에이전트들은 개발 시스템 내부에서 작동하고 있습니다. 제어 평면 (control plane)은 인간이 명령어를 입력하는 것과 에이전트가 그 인간을 대신하여 워크플로를 실행하는 것의 차이를 반드시 알고 있어야 합니다.

풀 리퀘스트 (pull request)가 전체 아티팩트 (artifact)의 전부는 아니다

PR은 훌륭한 결과물입니다. 하지만 전체 기록은 아닙니다.

프로그래밍 방식의 에이전트 작업을 위해서는, 디프 (diff) 이상의 것이 필요합니다:

원본 작업 입력 (original task input)
트리거링 시스템 (triggering system)
사용된 신원 (identity used)
범위 내의 저장소 및 파일 (repositories and files in scope)
실행된 명령 (commands run)
시도된 테스트 (tests attempted)
실패 및 재시도 (failures and retries)
호출된 외부 도구 (external tools contacted)
최종 신뢰도 및 알려진 공백 (final confidence and known gaps)

이 중 일부는 PR (Pull Request) 설명에 포함될 수 있습니다. 일부는 로그 (logs)에 남아야 합니다. 일부는 작업을 시작한 내부 시스템의 무엇인가에 속해야 합니다.

핵심은 미래의 리뷰어들이 단순히 '느낌 (vibes)'만으로 작업을 재구성할 필요가 없어야 한다는 것입니다. 6개월 뒤에 누군가는 왜 47개의 저장소에서 의존성 (dependency)이 업데이트되었는지, 왜 3개의 저장소는 건너뛰었는지, 그리고 에이전트가 승인된 플레이북 (playbook)을 따랐는지 물을 것입니다.

만약 답변이 "예전 채팅 세션을 확인해 보세요"라면, 당신은 자동화 (automation)를 가진 것이 아닙니다. 친절한 인터페이스를 가진 고고학 (archaeology)을 하고 있는 것입니다.

이것이 실제로 유용한 곳

프로그래밍 방식의 에이전트 작업은 반복적이고, 경계가 명확하며, 테스트 가능하고, 번거로운 작업에 가장 적합합니다: 의존성 업그레이드 (dependency upgrades), 코드 수정 (codemods), 저장소 부트스트래핑 (repo bootstrapping), 설정 정리 (configuration cleanup), 릴리스 준비 (release preparation), 그리고 명확한 레시피가 있는 작은 프레임워크 마이그레이션 (framework migrations) 등이 이에 해당합니다.

그것이 실제 업무이며, 리뷰 경로가 정직할 때 에이전트가 도움을 줄 수 있습니다. 함정은 동일한 메커니즘이 모든 종류의 엔지니어링 작업을 처리해야 한다고 가정하는 것입니다. 어떤 변경 사항은 깊은 시스템적 판단을 필요로 합니다. 어떤 것은 제품 컨텍스트 (product context)를 필요로 합니다. 어떤 것은 엔지니어가 "명백한" 수정 사항이 2021년의 이상한 고객 계약을 위반한다는 사실을 알아차려야 할 수도 있습니다.

API는 그것을 제거하지 않습니다. 대신 우리에게 작업을 라우팅 (route)할 더 나은 방법을 제공합니다.

내가 가장 먼저 구축할 것

만약 내가 이것을 내부 개발자 플랫폼 (internal developer platform)에 추가한다면, 조직이 이미 이해하고 있는 하나의 좁은 워크플로 (workflow)부터 시작할 것입니다. 예를 들어 "승인된 템플릿으로부터 새로운 서비스 생성" 또는 "호환성 검사를 통과하는 저장소 전체에서 이 라이브러리 업그레이드"와 같은 것입니다.

그런 다음 플랫폼이 지루한 세부 사항들을 책임지게 만듭니다:

승인된 소수의 작업 템플릿 (task templates)
저장소 적격성 규칙 (repo eligibility rules)
범위가 제한된 자동화 ID (scoped automation identity)
명확한 PR 라벨 (PR labels)
필수 상태 검사 (required status checks)
요청, 로그, PR 및 결과를 연결하는 작업 기록 (task record)
하루를 허비하는 대신 유의미한 실패 후 중단되는 재시도 규칙 (retry rules)

거대한 에이전트 포털을 구축하기 전에 이 작업들을 먼저 수행하십시오. 가치는 버튼 그 자체에 있는 것이 아닙니다. 가치는 요청에서 검토된 변경 사항으로 이어지는 통제된 경로에 있습니다.

핵심 요약 (the punchline)

Copilot cloud agent REST API는 작은 프리뷰 기능이지만 큰 함의를 담고 있습니다. 코딩 에이전트가 호출 가능한 인프라 (callable infrastructure)가 되고 있다는 것입니다. 이것이 올바른 방향입니다. 최고의 에이전트 워크플로 (workflows)는 단순히 채팅창 안에만 머물지 않을 것입니다. 에이전트는 내부 포털, 마이그레이션 도구, 릴리스 시스템 및 플랫폼 워크플로 뒤에 자리 잡게 될 것입니다.

하지만 에이전트가 자동화가 되는 순간, 에이전트는 자동화의 책임을 물려받게 됩니다.

작업을 대기열에 넣으십시오. 작업 범위를 지정하십시오. ID를 제한하십시오. 실행을 추적하십시오. 증거를 보존하십시오. 검토자의 역량을 존중하십시오. 작업이 이상해지면 중단하십시오.

미래는 "모두가 에이전트와 더 열심히 채팅하는 것"이 아닙니다. 미래는 지루한 시스템들이 경계가 지정된 에이전트 작업 (bounded agent tasks)을 시작하고, 그 결과를 프로덕션 엔지니어링 (production engineering) 작업처럼 취급하는 것입니다.

그것이 바로 마땅히 그래야 하는 방식입니다.

데모에서는 마법 같은 기능이 멋져 보일 수 있습니다. 하지만 API는 책임이 나타나는 곳입니다.