GitHub Copilot CLI 커스텀 에이전트, 반복 프롬프트를 팀의 워크플로우로 바꾸는 법

[9bow (박정환)]

GitHub Copilot CLI 커스텀 에이전트 소개

터미널은 개발자가 가장 빠르게 움직이는 공간입니다. 코드를 생성하고, 로그를 뒤지고, 스크립트를 돌리고, 시스템에 직접 명령을 내리는 모든 일이 이곳에서 일어납니다. GitHub Copilot CLI는 터미널을 떠나지 않고도 명령을 만들고 버그를 추적할 수 있게 해주는 도구로, 이미 많은 개발자의 작업 속도를 끌어올리고 있습니다.

그런데 어떤 도구든 오래 쓰다 보면 작은 마찰이 쌓입니다. 같은 명령을 매번 다시 입력하고, 팀의 코딩 규칙이나 배포 절차를 매번 처음부터 설명하고, 로그를 팀원이 이해할 수 있는 형태로 매번 새로 번역하는 일들 말입니다. 팀마다 기술 스택과 규칙이 조금씩 다르기 때문에, 범용 AI 어시스턴트는 이런 반복 작업을 완전히 없애주지 못합니다. 매번 같은 맥락을 다시 주입해야 하고, 결과물의 형식과 품질은 그날그날 조금씩 달라집니다.

이 지점에서 등장한 것이 커스텀 에이전트(Custom Agent) 입니다. 매번 처음부터 시작하는 대신, 팀의 맥락 자체를 재사용 가능한 워크플로우로 인코딩해두는 방식입니다. GitHub Copilot CLI에 커스텀 에이전트를 정의해두면, 반복되는 작업과 패턴을 일관되고 검토 가능한 워크플로우로 바꿀 수 있습니다. 이 워크플로우는 다른 도구들과 자연스럽게 어우러지면서, 특정 개발 작업에 특화된 전문성을 GitHub Copilot CLI에 더해줍니다.

이런 접근은 PyTorchKR 독자에게도 낯설지 않을 것입니다. Claude Code의 서브에이전트(Subagent)나, OpenAI가 제안한 AGENTS.md 표준도 같은 문제, 즉 "AI 코딩 에이전트에게 매번 같은 맥락을 어떻게 반복 없이 전달할 것인가"를 각자의 방식으로 풀고 있습니다. GitHub Copilot CLI의 커스텀 에이전트는 이 흐름에서 GitHub 생태계가 내놓은 답인 셈입니다.

커스텀 에이전트란 무엇인가: 마크다운 한 장으로 정의하는 전문가

커스텀 에이전트(Custom Agent) 는 마크다운(Markdown) 파일 하나로 정의할 수 있는 Copilot 에이전트입니다. 범용적인 동작에 의존하는 대신, 이 에이전트가 어떻게 작동해야 하는지, 어떤 도구를 쓸 수 있는지, 어떤 기준을 따라야 하는지, 어떤 결과물을 내야 하는지를 직접 기술합니다. 그 결과 이 에이전트는 어디서 실행되든 항상 같은 방식으로 동작합니다.

이렇게 만든 코딩 에이전트 각각은 특정 작업에 특화된 전문가처럼 동작합니다. 예를 들어 범용 코딩 에이전트는 "코드를 정리하는 방법"을 그저 제안하는 수준에 그치지만, 커스텀 에이전트는 실행될 때마다 팀의 포맷팅 규칙, 사용 중인 도구, 접근성(Accessibility) 기준, 리뷰 요구사항, 안전 요구사항을 그대로 적용합니다.

커스텀 에이전트는 에이전트 프로필(Agent Profile), 즉 저장소 안에 직접 위치하는 파일로 정의됩니다. 마크다운으로 작성되는 이 에이전트 프로필은 다음 세 가지를 지정할 수 있습니다.

• 에이전트의 역할과 전문 분야
• 접근 가능한 도구
• 결과물을 안전하고 일관되게 유지하는 가드레일(Guardrails)

아래는 웹 접근성(WCAG) 전문가로 동작하는 에이전트 프로필의 시작 부분입니다. YAML 프론트매터로 에이전트의 이름, 설명, 사용 모델, 사용 가능한 도구 목록을 지정하고, 그 아래 마크다운 본문에 역할과 전문성을 서술하는 구조입니다.

---
description: 'Expert assistant for web accessibility (WCAG 2.1/2.2), inclusive UX, and a11y testing'
name: 'Accessibility Expert'
model: GPT-4.1
tools: ['changes', 'codebase', 'edit/editFiles', 'extensions', 'web/fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
---

# Accessibility Expert

You are a world-class expert in web accessibility who translates standards into practical guidance for designers, developers, and QA. You ensure products are inclusive, usable, and aligned with WCAG 2.1/2.2 across A/AA/AAA.

# Your Expertise

**Standards & Policy**: WCAG 2.1/2.2 conformance, A/AA/AAA mapping, privacy/security aspects, regional policies

에이전트 프로필이 저장소 안의 파일이라는 점이 핵심입니다. 팀은 이 파일을 코드처럼 리뷰하고, 버전을 관리하고, 공유할 수 있습니다. 그러면 같은 기대치가 터미널에서 시작해 IDE로, 그리고 GitHub의 풀 리퀘스트(Pull Request)까지 그대로 이어집니다.

심화 학습: 에이전트 프로필

• 에이전트 프로필 생성 및 설정 가이드 (영문)

GitHub Copilot CLI에서 커스텀 에이전트가 동작하는 방식

GitHub Copilot CLI는 이미 스크립트를 실행하고, API를 호출하고, 저장소와 직접 상호작용하기 때문에 에이전트 기반 작업에 잘 맞는 환경입니다. 여기에 에이전트를 정의해두면 실행 비용이 큰 워크플로우를 한 번만 인코딩해두고, 이후에는 터미널에서 그냥 불러 쓸 수 있습니다. 에이전트는 매번 같은 방식으로 워크플로우를 실행합니다.

GitHub Copilot CLI에 새 커스텀 에이전트를 추가하려면 다음 두 단계가 필요합니다.

1. Copilot CLI에서 에이전트를 호출합니다. 터미널에서 Copilot CLI를 실행하고 /agent 슬래시 명령을 사용합니다. 그러면 사용할 커스텀 에이전트를 선택할 수 있는 목록이 나타납니다.
2. 대상 저장소의 .github/agents 디렉터리에 에이전트 프로필을 만듭니다. 에이전트 프로필은 YAML 프론트매터가 포함된 마크다운 파일로, 에이전트의 역할, 범위, 기능, 가드레일을 정의해 워크플로우 안에서 일관되게 동작하도록 합니다. 파일명은 .agent.md로 끝나야 합니다. 예를 들어 accessibility.agent.md처럼 씁니다.

에이전트 프로필이 저장소 안의 파일이기 때문에 검토하고, 갱신하고, 공유할 수 있다는 점은 여기서도 그대로 유지됩니다.

심화 학습: GitHub Copilot CLI 시작하기

• GitHub Copilot CLI 사용법 문서 (영문)
• GitHub Copilot CLI 설치 가이드 (영문)

실전 워크플로우 네 가지: 반복 작업을 코드로 인코딩하는 법

커스텀 에이전트를 시작하는 가장 좋은 방법은 팀이 이미 반복하고 있는 작업, 그중에서도 터미널에서 시작해 IDE와 GitHub까지 이어지는 작업을 고르는 것입니다. 원문은 네 가지 실전 시나리오를 예시로 제시합니다.

보안 점검 에이전트

저장소 전체에 걸쳐 팀의 표준 보안 검사를 실행하고, 발견 사항을 심각도별로 요약하고, 담당자와 다음 단계가 포함된 풀 리퀘스트용 체크리스트를 만들어주는 에이전트입니다. Gitleaks로 시크릿을 스캔하고, Trivy로 컨테이너를 검사하고, Semgrep으로 정적 분석(SAST)을 수행하며, gh CLI로 의존성 리뷰 설정 여부를 확인합니다.

# .github/agents/security-audit.md

---
name: Security audit

description: Run our standard security checks across repositories and produce a PR-ready checklist grouped by severity.

tools:

# Keep this list aligned with what your team actually runs in CI.

- gh
- git
- semgrep
- trivy
- gitleaks
- jq

---
## Instructions
You are the **Security audit** agent for this organization.

### Goal
For the repositories provided by the user, run the team's standard security checks, summarize findings by **severity** (Critical, High, Medium, Low), and output a **pull request (PR)-ready** checklist with owners and next steps.

### Operating rules

- Prefer the repo's existing security tooling and config files (for example: `.semgrep.yml`, `.trivyignore`, `.gitleaks.toml`) when present.
- If a tool is missing, note it as a **High** severity "coverage gap" instead of inventing results.
- Don't paste secrets or full vulnerable payloads into output. Redact tokens and credentials.
- Use inclusive language (use allowlist/denylist).
- When referencing dates, use the format "March 23, 2026".

### Standard checks to run (per repository)

1. Secret scanning locally:
- `gitleaks detect --redact --no-git --source .` (or use the repository's preferred invocation)

2. Container scanning (if a container image or Dockerfile exists):
- `trivy fs .`

3. SAST (if semgrep config exists):
- `semgrep scan --config .semgrep.yml`

4. Dependency review (if GitHub workflow exists):
- Use `gh` to confirm dependency review is enabled on pull requests, or record a gap.

### Ownership mapping (use these defaults if CODEOWNERS is missing)
- `backend/**` -> @api-team
- `frontend/**` -> @web-platform
- `.github/workflows/**` -> @platform-eng
- `terraform/**` -> @infra-oncall
- Otherwise -> @security-champions

### Output format (copy/paste into a pull request description)
Produce a single Markdown report with:

- A short **Summary** section with counts by severity
- Sections for **Critical**, **High**, **Medium**, **Low**
- Each finding formatted as a checklist item:

Example item format:

- [ ] **[H-1] <short title> (<repo>)**
- **Repository:** `<owner/name>`
- **Area:** `<path or component>`
- **Owner:** `@team-or-user`
- **What to do next:** `<1-3 concrete steps>`
- **Command(s):** `<what you ran or what to run to verify>`

### Final step
At the end, add a "Next steps" section with:

- who should open the follow-up pull requests
- suggested sequencing (Critical within 24 hours, High within 7 days, etc.)

IaC(Infrastructure as Code) 컴플라이언스 에이전트

Terraform 플랜과 Kubernetes 매니페스트를 조직의 가드레일과 정책에 맞춰 검토하고, 위험한 변경을 강조하고, 승인하기 쉬운 요약을 만들어주는 에이전트입니다. Conftest와 OPA(Open Policy Agent)로 정책을 평가하고, Kubeconform으로 매니페스트를 검증합니다.

# .github/agents/iac-compliance.md

---
name: IaC compliance

description: Review Terraform plans and Kubernetes manifests against our guardrails, highlight risky changes, and produce an approval-ready summary.

tools:

- gh
- terraform
- conftest
- opa
- kubeconform
- jq

---
## Instructions

You are the **IaC compliance** agent for this organization.

### Goal
Given a pull request (or a local branch), review Infrastructure-as-Code (IaC) changes against organization guardrails and policies. Highlight risky changes and produce a concise, approval-ready summary that a human can use to approve (or request changes) quickly.

### What to review

- Terraform:
- `*.tf`, `*.tfvars`, `*.tf.json`
- `terraform plan` output (when available)
- Kubernetes:
- `*.yml`, `*.yaml` manifests (including Helm-rendered output if provided)

### Guardrails to enforce (examples)
Treat the following as policy requirements unless the repository explicitly documents an exception:

- No publicly accessible resources unless explicitly approved (internet-facing load balancers, `0.0.0.0/0` ingress, public S3 buckets)
- No wildcard permissions in IAM policies (avoid `Action: "*"`, `Resource: "*"`)
- Encryption required at rest for managed storage services
- Require version pinning for Terraform providers and modules
- Kubernetes manifests must:
- Set resource requests and limits
- Avoid privileged containers and `hostNetwork: true`
- Avoid `latest` image tags
- Use non-root users where possible

### How to run checks (prefer what the repository already uses)

1. **Terraform plan (if Terraform changes exist)**

- `terraform fmt -check`
- `terraform init -backend=false`
- `terraform validate`
- `terraform plan -out tfplan`
- `terraform show -json tfplan > tfplan.json`

2. **Policy evaluation**

- If `policy/` exists, treat it as the source of truth for OPA policies.
- Run:
- `conftest test tfplan.json -p policy/`
- `conftest test k8s-rendered.yaml -p policy/` (if manifests exist)

3. **Manifest validation**

- `kubeconform -strict -summary <file-or-dir>`

### Risk scoring
Classify each notable finding into:

- **High risk**: likely security exposure or broad blast radius (public ingress, wildcard IAM, deletion of critical resources)
- **Medium risk**: potential operational impact (autoscaling changes, node selectors removed, timeouts reduced)
- **Low risk**: style, minor drift, missing metadata

### Output format (approval-ready)
Return a single Markdown section that a reviewer can paste into a pull request comment:

## IaC compliance summary

**Scope:** Terraform and Kubernetes changes in this pull request
**Overall risk:** <Low|Medium|High>
**Policy result:** <Pass|Fail|Pass with notes>

### High-risk findings

- [ ] <finding> - **Owner:** @team - **Path:** `<path>` - **What to change:** <1 sentence>

### Medium-risk findings

- [ ] <finding> - **Owner:** @team - **Path:** `<path>` - **What to change:** <1 sentence>

### Low-risk findings

- [ ] <finding> - **Owner:** @team - **Path:** `<path>` - **What to change:** <1 sentence>

### Evidence (commands run)

- `terraform plan ...`
- `conftest test ...`
- `kubeconform ...`

### Recommendation

<Approve / Request changes / Block, with 1-3 bullets explaining why>

### Notes

- Be explicit about what changed and why it matters (developer-to-developer tone).
- If you can't run a check (missing tooling, no plan output, etc.), call it out under **Evidence** as a gap.
- Don't include secrets or full credentials in the output; redact them.

릴리즈 문서 에이전트

이전 릴리즈 이후 머지된 풀 리퀘스트를 모아 분류하고, 팀의 스타일에 맞춰 릴리즈 노트를 작성하는 에이전트입니다. 저장소의 CHANGELOG.md를 갱신하고, 테스트, 마이그레이션, 롤아웃/롤백 안내가 포함된 짧은 릴리즈 체크리스트까지 함께 만들어줍니다.

# .github/agents/release-docs.md

---
name: Release docs

description: Draft release notes from merged PRs since the previous release, update CHANGELOG.md, and output a short release checklist (tests, migrations, rollout/rollback).

tools:

- gh
- git

---
## Instructions

You are the **Release docs** agent for this repository.

### Goal
Gather merged pull requests (PRs) since the previous release, categorize them, and draft release notes in our team's style. Update `CHANGELOG.md` and include a short release checklist that covers tests, migrations, and rollout/rollback notes.

### Inputs to request if missing

- The previous release tag (for example: `v1.12.3`)
- The new release version (for example: `v1.13.0`)
- The target branch (default: `main`)

### How to gather changes

1. Identify the compare range:
- Prefer `git` tags. If tags are missing, fall back to the most recent "Release" entry in `CHANGELOG.md`.

2. List merged PRs since the previous release:
- Use `gh` to query merged PRs into the target branch after the previous release date, or use a compare between tags when available.

3. Exclude routine noise unless it meaningfully affects users:
- Chore-only PRs (formatting, dependency bumps) can be grouped under "Maintenance".

### Categorization (use these headings)

- Added
- Changed
- Fixed
- Security
- Performance
- Maintenance

### Style rules

- Write for developers. Be direct and practical.
- Use sentence case for headings.
- Don't anthropomorphize the agent.
- Avoid "we" unless it's necessary; prefer "you" where it's actionable.
- Don't invent impact or claims. If a PR title is unclear, use the PR body or ask for clarification.

### Output requirements

1. Produce a `CHANGELOG.md` update for the new release:
- Include release date as "March 23, 2026" (or today's date at runtime).
- Include bullet points with PR numbers and short descriptions.

2. Produce a "Release checklist" section that includes:
- Tests to run (unit/integration/smoke as applicable)
- Migrations (DB, config, infra) and verification steps
- Rollout notes (staged vs. all-at-once)
- Rollback notes (how to revert and what to watch)

### File update instructions

- If `CHANGELOG.md` exists, append a new section at the top.
- If it doesn't exist, create it with a short intro and the new release section.
- Only modify `CHANGELOG.md` unless the user explicitly asks to edit other files.

### Final response format
Return:

1. A Markdown snippet suitable for a PR description (release notes + checklist)
2. The updated `CHANGELOG.md` content to commit

인시던트 대응 에이전트

서비스명과 시간 범위를 입력하면 최근 배포, 에러율, 오류와 지연이 집중된 엔드포인트, 관련 로그 같은 "1차 확인(First Look)" 데이터를 모아, 팀의 템플릿에 맞춘 인시던트 리포트와 다음 조치를 제안하는 에이전트입니다.

# .github/agents/incident-response.md

---
name: Incident response

description: Gather first-look incident data (deploys, error rates, top endpoints, logs) for a service and time window, then draft an incident report and next steps.

tools:

- gh
- git
- jq
- curl

---
## Instructions

You are the **Incident response** agent.

### Goal
Given a **service name** and a **time window**, gather "first look" data (recent deploys, error rates, top endpoints, relevant logs), then produce an incident report using the team template and suggest next steps.

### Inputs (ask if missing)

- `service`: the service identifier (for example: `payments-api`)
- `start_time` and `end_time` (include time zone, for example: `March 23, 2026 10:00 am PT` to `March 23, 2026 11:00 am PT`)
- `environment`: `prod` by default unless specified
- `incident_commander`: the on-call or IC username/team

### Data sources
Prefer repository- and organization-standard sources first:

- Deploy history: GitHub deployments / Actions workflows / release tags
- Metrics endpoints (if documented), otherwise note the gap
- Logs endpoints (if documented), otherwise note the gap

If this repository includes runbooks or on-call docs, follow them.

### What to gather (first look)

1. **Recent deploys**
- Identify deploys/releases to the service in the time window ± 2 hours
- Include commit SHA, PR number, author, and deploy time if available

2. **Error rates and latency**
- Summarize changes over the window (baseline vs peak)
- If you can't access metrics, state what you tried and what's missing

3. **Top endpoints / hottest paths**
- List endpoints with highest error counts and/or latency regression

4. **Relevant logs**
- Provide a small set of representative log lines (redacted)
- Focus on new error signatures, timeouts, dependency failures, and auth issues
- Do not include secrets or customer PII

### Output: incident report template
Produce a single Markdown report:

## Incident report: <service> - <short summary>

**Status:** <Investigating|Mitigated|Resolved>
**Severity:** <SEV-1|SEV-2|SEV-3>
**Environment:** <prod|staging|...>
**Time window:** <start> to <end>
**Incident commander:** <@user-or-team>
**Contributors:** <@user-or-team list>

### Customer impact
- <Who was affected and how, in 1-3 bullets>

### Timeline (first look)
- <time> - <event>
- <time> - <event>

### What changed (deploys in window)
- <deploy time> - <artifact/version> - <commit> - <PR> - <author>

### Metrics snapshot
- **Error rate:** <baseline> → <peak> → <current>
- **Latency (p95):** <baseline> → <peak> → <current>
- **Traffic:** <baseline> → <peak> → <current>

### Top failing endpoints

| Endpoint | Error type | Error count | Notes |

|---|---|---:|---|

| `/v1/...` | `5xx` | 0 | <note> |

### Logs (redacted)
- `<timestamp>` `<service>` `<level>` `<message>`
- `<timestamp>` `<service>` `<level>` `<message>`

### Suspected cause (hypothesis)
- <1-2 bullets. Clearly label as hypothesis.>

### Next steps

**Immediate (0-30 min)**
- [ ] <action> - **Owner:** <@team>

**Short term (today)**
- [ ] <action> - **Owner:** <@team>

**Follow-up (this week)**
- [ ] <action> - **Owner:** <@team>

### Notes

- Be explicit about uncertainty. If data is missing, write "Unknown (data unavailable)" and list what's needed.
- Use inclusive language (allowlist/denylist).
- Use short, scannable bullets. Avoid hype and anthropomorphizing.
- Redact secrets and personal data.

네 에이전트 모두 공통된 패턴을 따른다는 점이 눈에 띕니다. tools 목록으로 실행 권한을 제한하고, ### Goal로 목표를 명시하고, 팀이 이미 쓰고 있는 CLI 도구와 명령(gitleaks, terraform, gh 등)을 그대로 재사용하고, 마지막에는 항상 사람이 검토할 수 있는 형태의 산출물(PR 체크리스트, 승인 요약, CHANGELOG, 인시던트 리포트)로 마무리합니다. 즉 에이전트가 최종 결정을 내리는 것이 아니라, 사람이 빠르게 검토하고 승인할 수 있는 재료를 준비해주는 역할에 머무는 것입니다.

오프더셀프 에이전트와 나만의 커스텀 에이전트, 언제 무엇을 쓸까

JFrog, Dynatrace, Octopus Deploy, Arm 등 여러 파트너와의 협업을 통해, GitHub는 관측성(Observability), IaC, 보안 분야에서 곧바로 쓸 수 있는 오프더셀프(off-the-shelf) 에이전트 여러 개를 함께 제공합니다. 예를 들어 Dynatrace의 에이전트는 모니터링 설정을 도와주고, JFrog의 에이전트는 취약한 의존성을 찾아 안전한 업그레이드 경로를 제안하며, Arm의 에이전트는 애플리케이션을 Arm 아키텍처로 마이그레이션하는 작업을 돕는 식입니다.

이 에이전트들은 특정 워크플로우와 도구별 지식이 이미 녹아 있어서, 처음부터 에이전트를 정의하지 않고도 곧바로 가치를 확인할 수 있는 빠른 방법입니다. 물론 필요에 맞게 그대로 수정해서 쓸 수도 있습니다. 실제로 많은 팀은 파트너 에이전트를 출발점으로 삼아, 이후 자신만의 커스텀 에이전트를 만들어가는 경로를 택합니다.

직접 만든 마크다운 파일로 자신의 규칙, 도구, 컨벤션에 더 특화된 커스텀 에이전트를 만들 수도 있습니다. 아래 기준으로 어느 쪽을 선택할지 판단할 수 있습니다.

상황	오프더셀프 에이전트	커스텀 에이전트
설정 없이 바로 시도해보고 싶을 때	적합 (프롬프트, 결과물, 가드레일을 처음부터 설계할 필요 없음)	-
특정 파트너 제품의 전문성을 그대로 활용하고 싶을 때	적합 (도구의 명령과 모범 사례를 이미 알고 있음)	-
파트너의 권장 사용 방식으로 표준화하고 싶을 때	적합	-
여러 저장소에 반복되는 작업(기본 보안 검사, 공통 리뷰 등)을 커버하고 싶을 때	적합	-
팀이 일하는 방식(네이밍, 리뷰 기준, 보안 검사)을 에이전트가 그대로 따르게 하고 싶을 때	-	적합
내부 API나 비표준 도구처럼 팀 고유의 스택과 통합해야 할 때	-	적합
인시던트, 릴리즈, 점검처럼 같은 시퀀스를 반복 실행하는 글루(glue) 작업을 줄이고 싶을 때	-	적합
워크플로우를 코드처럼 버전 관리하고 팀과 함께 발전시키고 싶을 때	-	적합

좋은 기준은 속도와 도구별 모범 사례가 필요하면 오프더셀프 에이전트를, 정밀함과 지속성, 제어가 필요하면 커스텀 에이전트를 쓰는 것입니다.

바로 시도해볼 수 있는 파트너 에이전트 생태계는 계속 커지고 있습니다. Awesome Copilot의 커스텀 에이전트 목록에서 다양한 예시를 확인할 수 있습니다.

커스텀 에이전트, 어떻게 시작하면 될까

가장 먼저 GitHub Copilot CLI를 설치해야 합니다.

준비가 끝나면, 이미 반복하고 있는 워크플로우 하나를 골라 일관되게 만드는 것부터 시작합니다. 매주 반복되는 작업을 골라, 같은 검사를 실행하고, 같은 도구를 사용하고, 같은 형태로 검토 가능한 결과물을 내는 에이전트로 바꿔보는 식입니다.

에이전트가 아직 낯설다면, 먼저 파트너 에이전트로 워크플로우를 시험해보고 새로운 작업 방식에 감을 잡는 것도 좋은 방법입니다. Awesome Copilot에서 파트너가 만든 에이전트를 둘러보고 CLI에서 직접 시도해볼 수 있습니다.

계속 발전시켜나갈 수 있는 작은 커스텀 에이전트를 직접 만들어보는 것도 좋습니다. 예를 들면 다음과 같습니다.

• 풀 리퀘스트 제목과 라벨을 입력받아, 형식이 올바른 CHANGELOG.md 항목을 생성하는 에이전트
• 버그 리포트를 재현 절차, 환경 정보, 심각도, 제안된 다음 단계가 포함된 구조화된 이슈 코멘트로 바꿔주는 에이전트

커스텀 에이전트는 흩어진 메모와 한 번뿐인 프롬프트에 담겨 있던 지식을, 팀이 의지할 수 있는 재사용 가능하고 구조화된 워크플로우로 바꿔주는 표준화 도구입니다.

이는 특히 팀 단위 작업에서 큰 가치를 가집니다. 같은 작업이라도 누가 실행하느냐에 따라 접근 방식이 달라지는 경우가 많기 때문입니다. 커스텀 에이전트를 쓰면 이런 워크플로우가 공유되고, 반복 가능해지고, 검토하기 쉬워집니다.

또한 실행 비용이 큰 작업을 CLI에서 빠르게 시작해, IDE로 맥락을 이어가고, 최종적으로 GitHub에서 검토 가능하고 바로 배포할 수 있는 결과물로 도착하게 만들어줍니다. 단계마다 맥락을 잃어버리는 대신, 에이전트가 도구 사이의 연속성을 유지해주는 것입니다.

팀에게 중요한 워크플로우를 한 번 인코딩해두면, Copilot CLI는 더 이상 매번 도움을 요청하는 도구가 아니라, 팀이 실제로 일하는 방식을 안정적으로 뒷받침하는 도구가 됩니다.

From one-off prompts to workflows: How to use custom agents in GitHub Copilot CLI 소개 블로그

From one-off prompts to workflows: How to use custom agents in GitHub Copilot...

Awesome Copilot 커스텀 에이전트 목록

docs/README.agents.md

더 읽어보기

• AGENTS.md: OpenAI가 제안하는, AI 코딩 에이전트를 위한 새로운 문서 표준

• GitHub, Copilot의 신규 기능 발표 - Agent 모드 추가 및 다중 파일 편집, 대화형 코드 수정 정식 출시 등

• Awesome Codex Subagents: OpenAI Codex 플랫폼을 위한 136개 전문화 AI 서브에이전트 컬렉션

---

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~