Copilot 자동화: 에이전트를 예약된 인프라로 변모시키다

GitHub는 Copilot 클라우드 에이전트(cloud agent)에 작은 조각들을 계속해서 추가하고 있으며, 그 패턴은 점점 더 무시하기 어려워지고 있습니다.

가장 최근의 변화는 스케줄링(scheduling) 및 이벤트 기반 자동화(event-based automation)입니다. 이제 Copilot 클라우드 에이전트는 사람이 에디터에 프롬프트(prompt)를 입력하거나 이슈(issue)를 할당하기를 기다리는 대신, 자동으로 실행될 수 있습니다.

이것은 단순한 기능 업데이트처럼 들릴 수 있습니다. 하지만 그 이상의 의미를 갖습니다.

에이전트가 스스로 깨어나 저장소(repo)를 검사하고, 변경 사항을 만들며, 풀 리퀘스트(pull request)를 열 수 있게 되면, 그것은 더 이상 채팅 어시스턴트(chat assistant)가 아닙니다. 그것은 예약된 인프라(scheduled infrastructure)가 됩니다.

이는 cron, CI, 릴리스 봇(release bots), 의존성 업데이트 봇(dependency update bots), 그리고 매주 화요일마다 똑같이 지루한 일을 반복하고 싶지 않은 사람들 덕분에 서서히 핵심적인 역할을 하게 된 모든 조용한 자동화 도구들과 같은 범주에 속합니다.

차이점은 이 봇에는 판단력(judgment)이 결합되어 있다는 것입니다.

이는 유용합니다. 또한 문제가 시작되는 지점이기도 합니다.

에이전트는 저장소의 행위자(repo actors)가 되고 있다

저는 최근 GitHub의 에이전트 감사 API(agent audit API)가 지루하지만 중요한 기능에 대해 글을 쓴 적이 있습니다. 이것은 같은 방향이며, 단지 반대편 측면에서 바라보는 것뿐입니다.

먼저, GitHub는 에이전트를 감사할 수 있을 만큼 가시화했습니다. 그다음에는 API를 통해 에이전트를 더 쉽게 시작할 수 있게 만들었습니다. 이제는 에이전트를 자동으로 실행하기 더 쉽게 만들고 있습니다.

이러한 순서는 중요합니다. 이것은 제품이 인프라가 되어가는 형태입니다. 데모 버전은 "당신이 잠든 동안 Copilot이 작은 문제들을 해결합니다"이지만, 프로덕션(production) 버전은 "이제 우리에게는 스케줄, 권한, 비용, 로그, 그리고 드리프트(drift)를 가진 자율적인 저장소 행위자(autonomous repository actors)가 있습니다"입니다.

어떤 작업이 개발자가 수동으로 요청한 후에만 실행될 수 있다면, 그 위험은 인간의 주의력에 의해 제한됩니다. 누군가가 작업을 시작하기로 결정해야 했고, 아마도 누군가가 곧바로 그 결과를 확인했을 것입니다.

하지만 어떤 작업이 매일 밤, 매 릴리스, 매 이슈 라벨(issue label), 또는 매 실패한 워크플로(failed workflow)마다 실행된다면, 그것은 시스템의 일부가 됩니다.

당신은 그것을 영리한 자동 완성(autocomplete)처럼 관리해서는 안 됩니다.

당신은 그것을 노동자(worker)처럼 관리해야 합니다.

그것에는 신원(identity), 범위가 지정된 권한(scoped permissions), 예산, 재시도 동작(retry behavior), 장애 모델(incident model) 내에서의 위치, 그리고 빠르게 일시 중지할 수 있는 방법이 필요합니다.

"AI 에이전트 (AI agent)"라는 문구는 이것을 새로운 것처럼 느끼게 만듭니다. 하지만 엔지니어링 측면의 형태는 익숙합니다. 우리는 저장소 (repository) 내부에 또 다른 행위자 (actor)를 배치하고, 작업(work)을 생성할 수 있는 권한을 부여하고 있는 것입니다.

유용한 작업은 지루하다

"우리 결제 시스템을 하룻밤 사이에 다시 작성하라"는 말로 시작하지 마십시오. 제발 그렇게 하지 마세요.

유용한 첫 번째 작업들은 모두가 수행해야 한다는 데 동의하는 유지보수 작업들입니다:

API 변경 후 예제 (examples) 갱신
설정 파일 (config file) 변경 시 내부 문서 업데이트
병합된 풀 리퀘스트 (pull requests)로부터 릴리스 노트 (release notes) 준비
작은 의존성 마이그레이션 (dependency migration) PR 제안
좁은 규칙에 부합하는 TODO 항목 정리
불안정한 테스트 (flaky tests) 조사 및 가설 초안 작성

예약된 에이전트 (scheduled agents)의 가치는 심도 있는 엔지니어링 작업을 대체하는 데 있는 것이 아닙니다. 짜증 나고, 지위가 낮으며, 미루기 쉽다는 이유로 보통 사장되어 버리는 작은 작업들을 계속해서 시작할 수 있다는 점에 있습니다.

그 지점이 바로 제가 실제 채택 (adoption)이 일어날 것이라고 기대하는 부분입니다. 거대한 자율 프로젝트가 아니라, 저장소 엔트로피 (repository entropy)에 가해지는 꾸준한 배경 압력 말입니다.

모든 저장소에는 엔트로피가 있습니다. 문서는 부식됩니다. 테스트는 소음이 심해집니다. 예제는 어긋납니다. 라벨은 거짓말을 합니다. 릴리스 노트는 마지막 순간에 급하게 조립됩니다.

만약 에이전트가 이러한 것들 중 일부를 초안 풀 리퀘스트 (draft pull requests)로 바꿀 수 있다면, 그것은 유용합니다.

하지만 여기서 "초안 (draft)"이라는 단어가 아주 중요한 역할을 하고 있습니다.

리뷰는 제어 평면 (control plane)이다

풀 리퀘스트 (pull request)는 여전히 올바른 경계입니다.

이 말이 지루하게 들린다는 것을 압니다. 하지만 중요하기도 합니다. PR을 여는 예약된 에이전트는 프로덕션 동작 (production behavior)을 직접 변경하는 예약된 에이전트보다 훨씬 관리하기 쉽습니다.

PR은 차이점 (diff), 리뷰 프로세스 (review process), 상태 체크 (status checks), 브랜치 보호 (branch protection), 댓글, 그리고 감사 추적 (audit trail)을 제공합니다. 팀에게 "이것은 틀렸다" 또는 "이것은 세 개의 더 작은 변경 사항이었어야 했다"라고 말할 수 있는 익숙한 장소를 제공합니다.

그렇다고 해서 에이전트가 기본적으로 안전해지는 것은 아닙니다. 그것은 여러분이 이미 이해하고 있는 제어 장치 (controls)를 적용할 수 있는 장소를 제공할 뿐입니다.

에이전트가 "단순히 유지보수를 하고 있을 뿐"이라는 이유로 PR을 형식적인 절차로 취급하는 것이 바로 실수일 것입니다.

유지보수 작업은 무언가를 망가뜨릴 수 있습니다. 문서 변경은 잘못된 정보를 게시할 수 있습니다. 의존성 업데이트는 런타임 동작(runtime behavior)을 변경할 수 있습니다. 릴리스 노트 자동화는 민감한 정보를 노출할 수 있습니다. 불안정한 테스트(flaky test) 조사는 의심스러워 보인다는 이유로 잘못된 어설션(assertion)을 삭제할 수 있습니다.

올바른 태도는 지루합니다:

브랜치 보호(branch protection)는 여전히 적용됩니다
필수 체크(required checks)는 여전히 적용됩니다
머지(merge)의 소유권은 여전히 인간에게 있습니다
에이전트가 작성한 PR은 명확하게 라벨이 지정되어야 합니다
모호한 작업보다는 좁은 범위의 작업이 더 좋습니다
프롬프트(prompt) 또는 작업 정의는 검사 가능해야 합니다

에이전트는 프로세스의 필요성을 제거하지 않습니다. 오히려 허술한 프로세스를 더 크게 부각할 뿐입니다.

비용은 아키텍처의 일부가 됩니다

여기에는 또 다른 비낭만적인 세부 사항이 있습니다. 예약된 에이전트는 비용이 발생한다는 점입니다.

단가가 작을 수도 있습니다. 모델이 저렴할 수도 있습니다. 작업이 일주일에 한 번만 실행될 수도 있습니다. 좋습니다. 하지만 팀이 유용한 자동화를 발견하면, 더 많은 자동화를 만들게 됩니다. 그러면 모든 리포지토리(repo)가 매일 밤의 정리, 매주 진행되는 릴리스 준비, 불안정한 테스트 분류(flaky test triage), 의존성 마이그레이션, 문서 갱신, 그리고 보안 검토 지원을 원하게 됩니다.

갑자기 AI 지출은 단순한 구독 항목이 아니게 됩니다. 이는 빌드 시간(build minutes), 러너 용량(runner capacity), 또는 로그 볼륨(log volume)에 더 가깝습니다.

이것이 바로 예산과 모델 선택이 중요한 이유입니다. 일상적인 유지보수에는 작은 모델로도 충분할 수 있습니다. 복잡한 마이그레이션에는 더 유능한 모델을 사용할 가치가 있을 수 있습니다. 어떤 작업은 모든 푸시(push)마다 실행되어야 합니다. 어떤 작업은 매주 실행되어야 합니다. 어떤 작업은 아예 자동으로 실행되어서는 안 됩니다.

이것은 재무적인 잡학 지식이 아니라 아키텍처 결정입니다.

만약 에이전트 작업이 컴퓨팅 자원, Actions 시간, 모델 토큰, 또는 리뷰어의 시간을 소비한다면, 그것은 시스템 비용의 일부입니다. 청구서가 누구나 가장 먼저 확인하는 첫 번째 관측성 대시보드(observability dashboard)가 되기 전에 그렇게 취급하십시오.

샌드박스(sandboxes)는 선택 사항이 아닙니다

예약된 에이전트는 샌드박스의 중요성을 더욱 높입니다.

에이전트가 개발자가 지켜보는 동안 한 번 실행된다 하더라도, 취약한 샌드박스는 여전히 나쁩니다. 만약 에이전트가 많은 리포지토리에 걸쳐 정해진 일정에 따라 실행된다면, 취약한 샌드박스는 조직적인 습관이 되어버립니다.

에이전트에는 통제된 환경이 필요합니다: 파일 시스템 경계 (filesystem boundaries), 네트워크 규칙 (network rules), 도구 제한 (tool restrictions), 비밀 정보 접근 규칙 (secret access rules), 그리고 무엇을 설치하거나 실행할 수 있는지에 대한 명확한 기본값 (defaults) 등이 필요합니다.

이는 특히 리포지토리 이벤트 (repository events)의 경우에 더욱 그렇습니다. 스케줄 (schedule)은 예측 가능합니다. 하지만 이벤트 기반 자동화 (event-driven automation)는 이슈 (issues), 라벨 (labels), PR 코멘트 (PR comments), 실패하는 테스트 (failing tests), 의존성 변경 (dependency changes), 심지어 외부 기여자의 콘텐츠와 같이 무질서한 현실 세계의 입력값에 의해 트리거될 수 있습니다.

이것이 "절대 자동화하지 마라"는 뜻은 아닙니다. 자동화 시스템이 적대적이거나 단순히 이상한 입력값을 가정해야 한다는 뜻입니다.

기존의 CI 교훈이 적용됩니다: 흥미로운 질문은 작업이 실행될 수 있느냐가 아니라, 작업이 실행되는 동안 무엇에 접근할 수 있느냐입니다.

내가 가장 먼저 할 일

만약 내가 회사 내부에서 이를 도입한다면, 아주 작고 극도로 구체적인 것부터 시작할 것입니다.

하나의 리포지토리. 하나의 예약된 작업 (scheduled task). 하나의 좁은 작업 범주. 하나의 명확한 소유자.

예를 들어: 매주 금요일마다, 에이전트가 병합된 변경 사항과 기존 라벨을 바탕으로 초안 릴리스 노트 PR (draft release note PR)을 준비하게 합니다. 에이전트는 제품에 대한 주장을 지어내거나 무엇인가를 병합해서는 안 됩니다. 오직 사람이 편집할 수 있는 초안만을 생성해야 합니다.

그런 다음 유용한 지표들을 측정할 것입니다:

PR이 얼마나 자주 유용했는가?
얼마나 자주 수정이 필요했는가?
리뷰 시간이 얼마나 소요되었는가?
비용이 얼마나 들었는가?
의도된 범위를 벗어난 파일에 접근했는가?
팀이 실제로 병합한 변경 사항을 생성했는가?

이것이 데모가 보여주는 것보다 훨씬 더 많은 것을 알려줍니다.

첫 번째 자동화가 유용하다면, 다른 것을 추가하십시오. 만약 소음이 심하다면, 작업을 더 엄격하게 제한하십시오. 만약 리뷰 부담을 초래한다면, 규모를 줄이거나 빈도를 낮추십시오. 만약 아무도 소유하지 않는다면, 삭제하십시오.

나쁜 버전은 아무도 유지보수하고 싶어 하지 않는 리포지토리에 저품질의 풀 리퀘스트 (pull requests)를 생성하며 방치된 예약된 에이전트들의 더미가 되는 것입니다.

우리는 이미 알림 (alerting), 대시보드 (dashboards), CI 작업 (CI jobs), 그리고 의존성 봇 (dependency bots)을 통해 그 교훈을 배웠습니다. 소유권 없는 자동화는 배경 소음이 됩니다. AI도 이를 바꾸지는 못합니다.

핵심 요약

예약된 Copilot 클라우드 에이전트 작업 (Scheduled Copilot cloud agent tasks)은 에이전트를 단순한 기능이 아닌 인프라 (infrastructure)에 가깝게 만든다는 점에서 흥미롭습니다.

그것이 진정한 변화입니다.

이제 리포지토리 (repo)에는 또 다른 작업자 (worker)가 생겼습니다. 이 작업자는 인간의 프롬프트 (prompt) 없이도 깨어나 상태를 점검하고, 결정을 내리며, 비용을 지출하고, 풀 리퀘스트 (pull requests)를 생성하고, 리뷰를 요청할 수 있습니다.

이는 진정으로 유용할 수 있습니다. 저는 지루한 유지보수 작업이 더 저렴해지기를 바랍니다. 릴리스 준비 (release prep) 과정이 덜 번거로워지기를 바랍니다.

하지만 유용한 버전은 마법이 아닙니다. 그것은 규율 있는 자동화 (disciplined automation)입니다.

에이전트에게 좁은 범위의 업무를 부여하십시오. 샌드박스 (sandbox)에 배치하십시오. 출력물을 리뷰할 수 있게 만드십시오. 비용을 추적하십시오. 소유자를 계속 가시화하십시오. 자동화가 제 역할을 다하지 못하면(임대료를 내지 못하면) 삭제하십시오.

이것은 "에이전트가 엔지니어링을 수행할 것이다"라는 말만큼 흥미진진하지는 않습니다.

하지만 이것은 엔지니어링이 실제로 개선되는 방식에 훨씬 더 가깝습니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.