노트북에서 파이프라인까지: GitHub Copilot 커스텀 에이전트 확장

URL: https://www.youtube.com/watch?v=b9UhZkKjX_A 날짜: 2026-10-11 채널: aiDotEngineer 발표자: Jose Palafox, GitHub 필드 조직 원문 제목: From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot

📌 핵심 질문 / 이 논의가 다루는 핵심 논점

==개인 노트북에서 반복 작업을 수행하는 로컬 에이전트를 조직의 공유 자산과 CI 파이프라인에서 자율적으로 실행되는 에이전트로 발전시키려면, 하네스·마켓플레이스·교차 저장소 오케스트레이션·관측성을 한 단계씩 붙여야 한다.==

• IDE, GitHub CLI, SDK라는 여러 진입점은 하나의 Copilot API 서비스 하네스로 모이며, 하네스가 컨텍스트 분할, 모델 호출, 인증, 필터링, 지표·감사 로깅을 맡는다.
• 로컬 에이전트는 특정 모델과 지시를 가진 재사용 가능한 작업 단위이며, 에이전트 빌더는 설명만으로 프런트매터·성공 기준·방법론까지 스캐폴딩한다.
• 마켓플레이스와 조직의 .github-private 저장소는 개인 에이전트를 버전 관리·보안 공지·팀 배포가 가능한 표준 자산으로 바꾼다.
• orchestrate는 GitHub 이슈를 목표로 삼아 실제 작업 대상 저장소에 하위 에이전트를 배치하므로, API를 바꾸는 저장소와 그 영향을 받는 하위 서비스의 변경을 동시에 처리한다.
• headless CLI를 GitHub Actions나 CI에서 실행하는 agentic workflows는 저장소 예산과 정체성으로 유지보수 작업을 수행하고 사람 승인 지점을 남긴 채 확장된다.
• CI에 에이전트를 모으면 토큰 사용량, P90 비용, 도구 호출 실패, 모델·프런트매터별 결과를 관찰하고 A/B 테스트할 수 있어 비용과 품질을 함께 최적화할 수 있다.

개인 작업을 자동화하는 것만으로는 조직 규모의 효과를 얻기 어렵다. 반복 가능한 에이전트를 같은 방식으로 배포하고, 올바른 저장소 권한으로 실행하며, 파이프라인의 결과와 비용을 계측해야 한다. 로컬 에이전트는 공유 자산이 되고, 공유 자산은 저장소 단위의 자율 워크플로가 되며, 관측 가능한 워크플로는 더 저렴하고 신뢰할 수 있는 에이전트 설계의 근거가 된다.

1. 발표의 출발점: 두 종류의 에이전트와 확장 경로

Jose Palafox는 GitHub에서 고객의 기술 도입과 조직 내 확장을 돕는 현장 역할을 맡고 있으며, 로컬 작업과 파이프라인 실행을 하나의 연속된 설계 문제로 연결한다.

1.1. 발표자와 다루는 범위

1. GitHub 보안에서 AI로 이동한 경력

   1. GitHub 합류 시점: Microsoft의 GitHub 인수 직후 GitHub에 합류했고, 이후 GitHub가 Semmle이라는 보안 도구 회사를 인수한 시기와도 함께 일했다.
   2. 보안 사업 경험: 지난 5~6년 동안 GitHub의 보안 사업을 성장시키는 일을 담당했다.
   3. 최근의 AI 초점: 최근 1년은 AI에 집중하면서 고객이 GitHub 기술을 도입하고 조직 안에서 확장하는 방법을 현장에서 지원했다.

2. 고수준 투어라는 발표의 성격

   1. 핵심 주제: 플랫폼 위에서 에이전트를 만들고, 에이전트를 어떻게 사고하며, 조직 규모로 확장하고, 어떤 워크플로에 적용하는지 소개한다.
   2. 두 가지 실행 모드: 파이프라인에서 자율적으로 돌아가는 autonomous agent와 개인이 여러 작업에 사용하는 local agent를 구분한다.
   3. 후속 대화: 상세한 사용 사례나 추가 질문은 발표 뒤 방 뒤편에서 계속 논의할 수 있고, Jose의 LinkedIn이나 GitHub AE를 통해 연락할 수 있다고 안내한다.

1.2. 노트북에서 파이프라인으로 가는 단계

1. 로컬 작업의 시작

   1. 개발자는 IDE나 CLI에서 직접 에이전트를 호출하고 자신의 세션 안에서 결과를 확인한다.
   2. 반복되는 탐색·검토·요약 작업을 하나의 이름 있는 에이전트로 만들면 같은 지시를 매번 다시 작성하지 않아도 된다.

2. 공유와 자동 실행으로의 전환

   1. 마켓플레이스나 조직 저장소는 개인 에이전트를 팀원이 가져다 쓸 수 있는 버전 관리 자산으로 만든다.
   2. headless CLI와 CI 실행은 개인 세션을 저장소 이벤트와 일정에 연결하고 개발자의 노트북이 꺼져 있어도 작업을 계속한다.
   3. 관측성은 단순 자동화를 비용·품질·실패 원인까지 관리하는 운영 체계로 바꾼다.

2. Copilot 플랫폼의 공통 하네스

Copilot의 표면은 여러 개지만 입력을 모델에 전달하고 결과를 되돌려주는 기반 서비스는 하나의 하네스로 수렴한다.

2.1. 에이전트에 들어가는 세 가지 문

1. IDE

   1. IDE 안의 에이전트 인터페이스에서 로컬 작업을 수행하고 CLI와 유사한 에이전트 생성 흐름을 이용할 수 있다.
   2. IDE는 프로젝트 맥락 안에서 작업하는 개발자에게 가장 가까운 진입점이다.

2. GitHub CLI

   1. 데스크톱에 놓이는 가벼운 인터페이스이며 CLI 세션을 시작해 작업을 이어갈 수 있다.
   2. slash remote 명령으로 세션을 스트리밍하면 노트북을 닫거나 자리를 비운 뒤에도 모바일 기기로 로그인해 에이전트를 조종할 수 있다.
   3. GitHub.com으로 에이전트를 위임하면 작업을 백그라운드에서 실행할 수 있다.

3. SDK

   1. SDK로 Slack이나 Teams 안에 에이전트를 넣어 특정 기능만 노출하는 애플리케이션을 만들 수 있다.
   2. GitHub 라이선스가 없는 팀원에게도 필요한 기능을 제공할 수 있어 에이전트 기능을 조직의 다른 업무 채널로 가져가는 통로가 된다.

2.2. Copilot API 서비스가 맡는 하네스 역할

1. 모델 앞단의 공통 계층

   1. IDE, CLI, SDK 중 어느 문으로 들어가든 Copilot API 서비스라는 계층에 도달한다.
   2. 이 계층은 에이전트 애플리케이션과 모델 제공자 사이의 harness로 작동한다.

2. 인프라 작업의 위임

   1. 사용자 입력을 청크로 나누어 모델에 전달한다.
   2. 오픈소스 제공자의 콘텐츠를 반복해서 재현하지 않도록 결과를 필터링한다.
   3. 인증, 지표 로깅, 감사 로깅을 처리해 각 애플리케이션이 같은 기반 기능을 다시 구현하지 않게 한다.
   4. 모델 제공자로부터 결과를 받은 뒤 다시 필터링하고 최종 결과를 사용자에게 표시한다.

3. 플랫폼 설계의 의미

   1. 어떤 표면에서 에이전트를 호출할지 선택할 수 있지만 모델 호출과 운영 통제의 기본 흐름은 공유된다.
   2. 여러 표면을 지원하면서 인증·감사·측정 방식을 통일할 수 있어 조직 차원의 관리가 가능해진다.

3. 로컬 에이전트 만들기: 내장 에이전트에서 커스텀 에이전트까지

CLI의 내장 에이전트는 작은 모델을 특정 역할에 배치하는 방법과 모델·지시·범위를 직접 설계하는 방법을 함께 보여준다.

3.1. 내장 에이전트로 역할과 모델을 분리하기

1. Explorer 연구 에이전트

   1. slash agents 명령은 CLI 하네스에 포함된 기본 에이전트 목록을 보여준다.
   2. 코드베이스를 살펴보는 단순한 조사에 가장 큰 모델을 쓸 필요는 없으므로 Explorer라는 특화 연구 에이전트를 제공한다.
   3. 키워드나 CLI slash 명령으로 Explorer를 호출하면 Haiku 같은 소형 모델이 코드베이스를 조사한다.

2. Rubber Duck 계획 검증 에이전트

   1. 한 모델로 작성한 계획을 다른 모델 제공자가 검토하게 하면 서로 다른 학습 데이터와 모델 가중치에서 나온 관점을 얻을 수 있다.
   2. Rubber Duck은 Opus가 작성한 계획을 GPT 계열 모델이 검증하는 식의 교차 검토에 사용할 수 있는 내장 에이전트다.
   3. 계획 작성과 검증에 동일한 모델을 반복해서 쓰는 대신 역할과 모델 제공자를 분리해 오류를 발견할 기회를 만든다.

3. 커스텀 에이전트의 두 핵심 설정

   1. 사용할 모델을 명시해 비용·속도·추론 능력에 맞는 모델을 고른다.
   2. 수행할 지시를 명시해 탐색, 검토, 컴플라이언스 검사처럼 조직에 특화된 역할을 부여한다.

3.2. 에이전트 빌더의 스캐폴딩

1. 커스텀 요구의 출발점

   1. 내장 에이전트가 특정 검토나 규제·컴플라이언스 요구를 충족하지 못하면 직접 에이전트를 만들 수 있다.
   2. 조직 전용 도구를 실행하거나 여러 검사를 순서대로 수행해야 하는 경우도 커스텀 에이전트의 대상이다.

2. 프로젝트·사용자·조직 범위 선택

   1. agent 명령의 빌더는 작업 중인 Git 프로젝트에만 존재하는 project-level 에이전트와 여러 프로젝트에서 쓸 수 있는 user-level 에이전트 중 하나를 고르게 한다.
   2. 조직 차원의 배포를 염두에 두면 org-level 위치에 두고 개인의 모든 프로젝트에서 쓸 도구라면 user-level 위치를 선택한다.

3. 한 줄 설명에서 구조화된 파일로

   1. GitHub change log를 읽고 최신 기능을 요약하는 에이전트를 만들고 싶다고 한 줄로 설명하면 Copilot이 기본 구조를 생성한다.
   2. 에이전트 설명과 프런트매터를 작성하고 성공 기준을 구조화하며 수행 방법론까지 초안으로 채운다.
   3. 에이전트 파일 형식을 처음부터 외우지 않아도 일반적인 작업 설명만으로 실행 가능한 스캐폴딩을 얻는다.

4. 자동 생성 뒤의 사람 편집

   1. 빌더가 작성한 소스 순서와 방법론은 확정된 규칙이 아니라 사람이 수정할 수 있는 초안이다.
   2. 생성된 에이전트가 GitHub roadmap부터 읽도록 되어 있어도 로드맵 항목을 제외하고 change log부터 읽도록 순서를 바꿀 수 있다.
   3. 스캐폴딩은 반복적인 형식 작업을 줄이지만 어떤 소스를 어떤 순서로 신뢰할지는 사용자가 결정한다.

5. 반복 작업의 재사용

   1. 하네스 안에서 동작하는 에이전트를 한 번 만들면 change log 요약처럼 반복되는 작업을 같은 호출로 실행할 수 있다.
   2. 개인의 첫 번째 목표는 반복 작업을 이름 있는 에이전트로 바꾸는 것이며 다음 목표는 그 에이전트를 다른 사람과 공유하는 것이다.

4. 조직 안에서 에이전트를 공유하고 표준화하기

개인 에이전트의 가치가 팀 전체의 생산성으로 이어지려면 패키지 관리·배포·버전·보안 공지를 갖춘 공유 위치가 필요하다.

4.1. 마켓플레이스 저장소

1. 마켓플레이스의 구성

   1. 마켓플레이스는 특정 디렉터리에 “이 저장소가 marketplace다”라고 표시하는 추가 JSON을 둔 저장소다.
   2. 복잡한 별도 서비스라기보다 저장소 위에 얹은 가벼운 패키지 관리 계층이다.

2. 구독과 버전 관리

   1. 팀원이 마켓플레이스를 구독하면 여러 에이전트를 동시에 업데이트할 수 있다.
   2. 에이전트 버전을 관리하고 downstream 사용자가 어떤 버전을 쓰는지 통제할 수 있다.
   3. 보안 취약점이 발견되면 하위 사용자에게 알릴 수 있고 마켓플레이스 운영자와 사용자가 운영 정보를 공유할 수 있다.

3. 중앙 저장소가 필요한 이유

   1. 조직에는 여러 팀이 에이전트나 스킬을 기여할 중앙 저장소가 없는 경우가 많다.
   2. 중앙 위치가 없으면 팀마다 비슷한 에이전트를 새로 만들고 수정 사항과 보안 공지를 흩어진 방식으로 관리하게 된다.
   3. 마켓플레이스를 만들고 로컬 클라이언트와 동기화하면 에이전트를 안팎으로 밀어 넣고 회수하는 조직 경로가 생긴다.

4.2. .github-private와 클라우드 에이전트

1. 조직 수준 공유

   1. GitHub 조직이나 특정 저장소 안에 .github-private라는 이름의 저장소를 만들면 에이전트 파일을 노출할 수 있다.
   2. 해당 저장소에는 세 개의 에이전트를 두고 Cloud agent 화면에서 플랫폼의 에이전트로 호출하는 구성이 가능하다.

2. 파일과 클라우드 메뉴의 동일성

   1. Cloud 드롭다운에 보이는 compliance bot은 저장소 안에 있는 동일한 compliance bot이다.
   2. 저장소에 정의된 에이전트를 클라우드 상호작용에서 호출하므로 화면에서 별도의 복사본을 관리할 필요가 없다.

3. 팀 환경으로의 배포

   1. change log를 검사하는 편리한 에이전트를 작성해 게시하면 모든 팀원에게 공유할 수 있다.
   2. 게시된 에이전트는 각자의 IDE나 CLI 환경으로 밀려가고 팀원은 같은 이름의 에이전트를 호출한다.
   3. 마켓플레이스와 조직 자산과 .github-private 저장소는 모두 반복 구현을 줄이고 표준화를 만든다.

4. 조직 밖으로의 확장

   1. 조직 내부 전용 마켓플레이스뿐 아니라 여러 조직에서 쓰거나 외부에 공개하는 마켓플레이스도 만들 수 있다.
   2. GitHub의 Awesome Copilot 저장소는 다양한 예제 에이전트를 모아 둔 사례이며 마켓플레이스로 등록해 가져다 쓸 수 있다.

4.3. 재사용과 캐시 적중률이 비용에 미치는 영향

1. 비용 모델의 기본 직관

   1. AI 제품을 싸게 쓰려면 공통 데이터에 대한 턴 간 정확한 일치, 즉 cache hit를 높이는 것이 중요하다.
   2. 같은 구성 요소를 재사용하면 모델이 이미 처리한 공통 데이터와 구조를 반복 활용할 가능성이 커진다.

2. 표준화의 경제성

   1. 모든 사람이 같은 문제를 매번 새 방식으로 해결하면 비슷한 프롬프트와 도구 호출이 반복되어 전체 청구액이 커진다.
   2. 재사용 가능한 에이전트와 공통 해결 방식을 도입하면 cache rate를 높이고 전체 비용을 낮출 수 있다.
   3. 마켓플레이스는 배포 편의성뿐 아니라 조직이 AI 비용을 관리하는 표준화 장치이기도 하다.

4.4. 저장소를 가로지르는 orchestrate

1. 권한 경계의 문제

   1. compliance agent가 정의된 저장소에서 시작하면 다른 저장소에 대한 권한을 자동으로 갖지 못할 수 있다.
   2. 에이전트가 실제로 변경할 저장소에서 시작해야 그 저장소의 권한으로 작업할 수 있다.

2. 수평 확장 명령

   1. Copilot 앱의 orchestrate 명령은 교차 저장소를 위한 수평 확장 방식이다.
   2. 여러 GitHub 이슈를 에이전트의 목표로 지정하고 목표별 하위 에이전트를 생성해 작업을 분배한다.

3. 마이크로서비스 변경 사례

   1. 한 마이크로서비스의 API를 수정하면 downstream 서비스에도 연쇄적인 변경이 필요할 수 있다.
   2. orchestrate는 각 작업을 실제 대상 저장소에서 수행하는 에이전트를 만들고 여러 저장소의 변경을 동시에 진행한다.
   3. 다른 마켓플레이스에서 가져온 사전 제작 에이전트나 조직 관리자가 배포한 에이전트도 각 저장소에 소환할 수 있다.
   4. orchestrate는 로컬 에이전트를 저장소 단위로 배치해 작업 범위와 권한을 맞추는 세 번째 확장 층이다.

5. 저장소 예산으로 실행하는 agentic workflows

개인 세션을 공유하는 단계에서 더 나아가면 프로젝트 유지보수 에이전트를 저장소의 예산과 정체성으로 실행할 수 있다.

5.1. 개인 정체성과 저장소 정체성의 분리

1. 프로젝트가 책임지는 유지보수

   1. 특정 에이전트가 저장소의 유지보수 작업을 담당한다면 개발자 개인의 예산이 아니라 저장소 예산으로 실행하는 편이 자연스럽다.
   2. 에이전트가 개인의 정체성으로 행동하는 대신 프로젝트의 정체성으로 이슈를 만들고 변경을 제안할 수 있다.

2. 모든 자동화가 사람의 행동일 필요는 없다

   1. 반복적인 유지보수는 특정 개발자가 직접 명령을 내리는 작업이 아니라 프로젝트를 위해 수행되는 작업이다.
   2. 실행 주체와 비용 주체를 저장소에 맞추면 개인이 자리를 비워도 프로젝트 수준의 자동화가 지속된다.

5.2. headless CLI와 CI 파이프라인

1. 일회성 프롬프트

   1. Copilot CLI는 headless mode에서 실행할 수 있다.
   2. -p 옵션으로 단일 프롬프트를 전달하면 사람이 대화형 세션을 유지하지 않아도 한 번의 작업을 수행한다.

2. 저장소 이벤트에 연결

   1. headless CLI를 GitHub Actions runner나 다른 CI 시스템에서 호출하면 파이프라인 안에서 동작하는 에이전트가 된다.
   2. release가 발생할 때 문서를 업데이트하거나 매주 context 파일을 갱신하거나 정기적인 유지보수 작업을 실행하는 식으로 트리거를 붙인다.
   3. 노트북 세션이 아니라 저장소 이벤트와 일정이 실행 조건이 되므로 개발자와 작업 시간이 분리된다.

5.3. 에이전틱 개발이 만드는 중복 코드와 사람 승인 흐름

1. 자동 생성 코드의 유지보수 문제

   1. 에이전트가 많이 개발하는 저장소에는 spaghetti code와 중복 코드가 빠르게 늘어날 수 있다.
   2. 에이전트가 이미 있는 함수를 재사용하기보다 새 함수를 만들고 네임스페이스를 꼼꼼히 정리하지 않아 같은 상수와 기능이 코드베이스에 반복될 수 있다.

2. 중복 탐지 에이전트

   1. 정기 실행 에이전트가 저장소를 살펴보고 코드 중복을 줄일 기회를 찾는다.
   2. 에이전트는 바로 코드를 고치는 대신 개선 후보를 이슈 목록으로 만든다.
   3. 예시 흐름에서는 cron으로 실행된 첫 에이전트가 개선 기회 세 가지를 찾아낸다.

3. 사람이 지출 시점을 통제하는 게이트

   1. 개발자는 생성된 이슈를 읽고 실제로 고칠 가치가 있는지 판단한다.
   2. 이슈 댓글의 slash 명령으로 “이 이슈를 다음 단계로 진행하라”고 표현하면 사람 승인 뒤에만 다음 에이전트가 실행된다.
   3. 사람이 승인하지 않은 후보에는 후속 모델 호출과 비용이 발생하지 않도록 human-in-the-loop 트리거를 둔다.

4. 계획·구현·수용의 단계

   1. 승인된 이슈는 planning 단계로 이동하고 PRD를 생성하는 product manager 에이전트가 기능 범위를 정한다.
   2. PM 에이전트가 계획을 생성하면 플랫폼의 Copilot 에이전트가 구현을 맡는다.
   3. 개발자는 acceptance 단계에서 코드가 프로젝트에 들어갈 만한지 다시 검토한다.
   4. 탐지 → 승인 → 계획 → 구현 → 수용이라는 단계별 구조가 무분별한 자동 커밋보다 안전한 배포 흐름을 만든다.

6. 파이프라인 에이전트의 규모와 재사용 가능한 아키텍처

파이프라인 실행은 개인 기기의 장애를 격리하고 다수의 전문 에이전트를 같은 이벤트 흐름에 연결한다.

6.1. 로컬 세션보다 강한 실행 지속성

1. 기기 의존성 제거

   1. 로컬 작업은 하나의 세션과 하나의 기기에 묶여 있어 기기가 꺼지거나 네트워크가 끊기면 워크플로가 중단된다.
   2. 플랫폼에서 실행되는 pipeline agent는 개발자와 독립적으로 동작하므로 노트북 상태와 무관하게 작업을 이어간다.

2. GitHub AW의 극단적인 사례

   1. 모든 에이전트를 만드는 프레임워크 자체가 에이전트로 전부 개발되는 GitHub AW 프로젝트가 소개된다.
   2. 해당 팀은 slash 명령으로 애플리케이션과 상호작용하며 모바일 기기만으로 개발하는 것을 내부 목표로 삼고 있다.
   3. 이 사례는 사람이 IDE에서 직접 코드를 편집하는 모델을 넘어 이슈·명령·파이프라인으로 프로젝트를 운영하는 방식을 보여준다.

6.2. 수백 개 에이전트에 반복 적용되는 패턴

1. AW 프레임워크의 규모

   1. 프레임워크에는 약 200개의 에이전트가 서로 다른 파이프라인 작업을 수행한다.
   2. 개별 에이전트는 탐지·계획·구현·검토 같은 단계 중 하나를 맡지만 전체적으로는 동일한 워크플로 패턴을 따른다.
   3. 한 프로젝트에서 검증한 아키텍처를 다른 저장소와 다른 유지보수 문제에 재사용할 수 있다.

2. 메타 에이전트의 일일 실행

   1. 무작위로 고른 한 에이전트는 다른 에이전트의 일일 보고서를 검사하는 meta-agent다.
   2. 정해진 일일 일정에 따라 agent.md 파일을 실행하고 매번 Markdown 보고서나 다음 에이전트가 사용할 작업·입력을 생성한다.
   3. 생성된 보고서와 입력이 다시 다른 에이전트를 트리거하면서 작은 자동화가 연속된 파이프라인을 이룬다.
   4. 이 프로젝트에는 이런 에이전트가 수백 개 있고 각 에이전트가 다음 작업에 필요한 구조화된 산출물을 만든다.

6.3. Agentix의 사전 제작 파이프라인 에이전트

1. 선반에서 꺼내 쓰는 구성 요소

   1. GitHub Next 조직의 Agentix 프로젝트에는 약 30개의 파이프라인 에이전트가 묶여 있다.
   2. 필요한 에이전트를 복사해 자신의 프로젝트 파이프라인에 넣으면 처음부터 모든 역할을 설계하지 않아도 된다.

2. 제공되는 역할의 폭

   1. 코드 중복을 찾는 에이전트가 있다.
   2. 여러 종류의 코드 리뷰어가 있고 QA 리뷰어도 선택할 수 있다.
   3. 진지한 리뷰뿐 아니라 농담을 던지는 재미있는 리뷰어처럼 목적에 맞는 샘플 에이전트도 있다.
   4. 샘플을 출발점으로 삼아 조직의 코드 규칙과 승인 단계에 맞게 수정할 수 있다.

7. CI 관측성과 비용 최적화

에이전트를 노트북에서 CI로 옮기는 핵심 이점은 백그라운드 실행뿐 아니라 조직 전체의 에이전트 행동을 측정하고 개선할 수 있다는 데 있다.

7.1. 노트북 실행만으로는 보이지 않는 것

1. 사용 현황의 불투명성

   1. 조직 전체에 AI 사용을 권장해도 각 개발자가 실제로 어떤 방식으로 에이전트를 쓰는지 보이지 않으면 최적화할 수 없다.
   2. 에이전트가 지나치게 장황한지 요청한 작업을 실제로 달성했는지 판단하기 어렵다.

2. 도구 호출과 추론의 불투명성

   1. 어떤 도구 호출이 발생했는지 호출이 성공했는지 실패했는지 확인하기 어렵다.
   2. 에이전트가 모든 작업에 긴 추론을 사용하는지 간단한 검색에는 작은 bash 스크립트를 올바르게 작성하는지 구분하기 어렵다.
   3. 세부 정보가 보이지 않으면 모델 교체, 프롬프트 수정, 도구 설계 변경 중 어떤 조치가 효과적인지 알 수 없다.

7.2. CI와 로깅 플랫폼이 제공하는 계측

1. 공통 관측 계층

   1. CI에서 실행되는 모든 에이전트에 OpenTelemetry 계측을 붙이면 실행 흐름을 중앙에서 관찰할 수 있다.
   2. SIEM이나 다른 로깅 플랫폼에서 코드 중복 제거 에이전트가 저장소마다 어떻게 동작하는지 비교할 수 있다.

2. 비용·품질 지표

   1. 저장소별 실행 비용과 평균 토큰 사용량을 확인한다.
   2. 같은 에이전트가 어느 저장소에서는 성공하고 어느 저장소에서는 실패하는지 비교한다.
   3. 도구 호출이 반복적으로 실패하는 지점과 모델이 실제 목표를 달성하지 못하는 패턴을 찾는다.

3. 임계값 기반 자기 조사

   1. 예상 실행 비용의 P90을 기준으로 임계값을 설정한다.
   2. 에이전트가 P90을 넘을 때마다 원인을 조사하고 추가 평가에 사용할 디버깅 정보를 보고하게 만들 수 있다.
   3. 비용 이상을 사후 청구서에서 발견하는 대신 실행 순간에 원인을 추적하는 운영 루프를 만든다.

7.3. 프런트매터·모델 A/B 테스트

1. 반복 실패의 원인 분리

   1. 특정 도구 호출이 계속 실패하면 프런트매터나 실행 지시의 다른 버전을 A/B 테스트한다.
   2. 같은 작업을 서로 다른 모델에 맡겨 어떤 모델이 요구한 출력과 성공 기준을 더 잘 만족하는지 비교한다.

2. 더 싼 모델로의 전환

   1. 품질이 유지되는 더 저렴한 모델을 찾으면 비용을 낮출 수 있다.
   2. 모델 선택은 감으로 고정하는 것이 아니라 저장소·작업·실패율·토큰 사용량을 관찰한 결과로 바꿔야 한다.
   3. 파이프라인에 들어온 에이전트는 실행 데이터와 비교 실험을 남기므로 지속적인 운영 최적화가 가능하다.

주요 발언 모음

“에이전트에는 파이프라인에서 자율적으로 실행하는 모드와 다양한 작업에 사용하는 로컬 모드가 있다.”

“마켓플레이스는 저장소 안에 작은 JSON을 추가한 저장소이며 에이전트를 위한 패키지 관리 기능을 제공한다.”

“모든 에이전트가 내가 행동하는 것일 필요는 없다. 프로젝트를 대신해 수행되는 유지보수 작업일 수 있다.”

“노트북에서 파이프라인으로 작업을 옮기면 무슨 일이 일어나는지 볼 수 있고 비용과 실행을 최적화할 수 있다.”

“에이전트가 예상 비용의 P90을 넘을 때 원인을 조사하고 더 평가하거나 개선할 수 있는 디버깅 정보를 알려주게 만들 수 있다.”

핵심 데이터 & 수치

• 6년 6개월: Jose Palafox가 GitHub에서 일한 기간이다.
• 5~6년: GitHub 보안 사업을 성장시키는 역할을 수행한 기간이다.
• 2가지 모드: 개인이 사용하는 local agent와 파이프라인에서 자율 실행하는 autonomous agent다.
• 3가지 주요 진입점: IDE, GitHub CLI, SDK가 Copilot API 서비스 하네스로 들어간다.
• 3개 개선 후보: cron으로 실행된 중복 탐지 에이전트가 예시 흐름에서 세 가지 개선 기회를 찾는다.
• 약 200개 에이전트: GitHub AW 프레임워크 안에서 각기 다른 파이프라인 작업을 수행하는 규모다.
• 약 30개 에이전트: GitHub Next의 Agentix 프로젝트에서 제공하는 사전 제작 pipeline agent 규모다.
• 일일 일정: 다른 에이전트의 보고서를 검사하는 meta-agent의 실행 주기다.
• 주간 일정: context 파일을 갱신하는 agentic workflow의 예시 실행 주기다.
• P90: 예상 비용을 초과한 에이전트를 조사하기 위한 비용 임계값 예시다.