GitHub Copilot의 Custom Agent로 Azure Updates를 정리해 보기
요약
VS Code의 Custom Agent 기능을 활용하여 Azure Updates 정보를 자동으로 수집, 필터링, 분석하는 'Azure Updates Analyst' 에이전트 제작 방법을 소개합니다. 단순 자동화를 넘어 AI가 업데이트의 중요도와 운영 영향을 분석하여 표 형식으로 정리하도록 설계되었습니다.
핵심 포인트
- VS Code Custom Agent를 이용한 맞춤형 에이전트 구축
- Azure 업데이트 정보의 자동 수집 및 필터링 프로세스
- 중요도, 서비스 분류, 예상 영향 등 분석 결과 구조화
- 에이전트 정의 시 신뢰 정보원 및 분석 절차 명시의 중요성
서론
GitHub Copilot의 사용법을 조금 더 이해하고 싶어서, 이번에는 VS Code의 Custom Agent를 이용하여 Azure Updates 정보를 취득하고 운영자를 위해 정리하는 Agent를 만들어 보았습니다.
처음에는 "Azure Updates의 RSS를 취득하여 목록화하는 스크립트를 만든다"는 방향도 생각했지만, 그것만으로는 단순한 자동화 스크립트가 되어 버려 AI를 사용하고 있다는 느낌이 별로 들지 않았습니다.
그래서 이번에는 다음과 같은 사항을 Copilot Agent가 수행하는 것을 목표로 삼았습니다.
- Azure Updates의 최신 정보를 취득한다
- 지정한 서비스나 기간으로 필터링한다
- GA / Preview / Retirement 등으로 분류한다
- 운영 영향이 있을 법한 것을 중요도와 함께 정리한다
- 필요에 따라 Excel에서 열 수 있는 CSV 파일로 저장한다
이번에 만드는 것
이번에는 VS Code의 workspace에 다음과 같은 Custom Agent 정의 파일을 생성했습니다.
.github/agents/azure-updates-analyst.agent.md
Agent의 이름은 Azure Updates Analyst로 설정했습니다.
이 Agent는 Azure Updates 정보를 조사하여, Azure 관리자나 아키텍트가 확인하기 쉽도록 다음과 같은 형식으로 답변합니다.
| 중요도 | 날짜 | 서비스 | 분류 | 업데이트 | 예상 영향 | 권장 액션 |
|---|---|---|---|---|---|---|
| High | 2026-04-16 | AKS | Retirement | 업데이트 제목 | 예상되는 영향 | 권장 액션 |
업데이트 열은 Markdown 링크로 만들어서, URL만 있는 열은 만들지 않도록 했습니다. URL 열을 따로 만들면 표가 가로로 너무 길어지기 때문입니다.
최종적인 내용은 다음과 같은 형태입니다.
azure-updates-analyst.agent.md
---
description: "Use when: analyzing Azure Updates, Microsoft Release Communications, Azure product announcements, GA/Preview/Retirement changes, or creating Japanese impact summaries from Azure update information."
name: "Azure Updates Analyst"
...
Agent 정의의 각 항목에 대하여
여기에서는 작성한 azure-updates-analyst.agent.md의 각 항목에 대해, 무엇을 위해 기재하고 있는지를 간단히 정리합니다.
Custom Agent는 단순히 "이런 답변을 해줘"라고 쓰는 것뿐만 아니라, 다음과 같은 관점을 명시해 두면 안정적으로 동작하기 쉬워집니다.
- 어떤 상황에서 호출되는 Agent인가
- 어떤 도구를 사용해도 되는가
- 어떤 정보원을 신뢰하는가
- 어떤 절차로 분석하는가
- 어떤 형식으로 답변하는가
- 어디까지 해도 되고, 무엇을 해서는 안 되는가
그럼 대략적인 내용을 살펴보겠습니다.
1. frontmatter
맨 앞의 ---로 둘러싸인 부분은 frontmatter입니다. 여기서는 Agent의 이름, 설명, 사용할 수 있는 도구 등을 정의합니다.
---
description: "Use when: analyzing Azure Updates, Microsoft Release Communications, Azure product announcements, GA/Preview/Retirement changes, or creating Japanese impact summaries from Azure update information."
name: "Azure Updates Analyst"
...
이 부분은 Agent의 동작 그 자체라기보다, VS Code / Copilot에 대하여 "이 Agent는 누구인가", "어떻게 호출할 수 있는가", "무엇을 사용할 수 있는가"를 전달하는 부분입니다.
그 외에 어떤 항목이 있는지는 커스텀 에이전트 구성을 참조해 주세요.
frontmatter의 각 항목에 대한 설명은 다음과 같습니다 (기사가 너무 길어지는 것을 방지하기 위해 접어둡니다)
frontmatter의 각 항목에 대한 설명
description
description: "Use when: analyzing Azure Updates...（생략）"
description은 다음 두 가지 역할을 하는 설명문입니다.
- Copilot Chat의 입력란에 플레이스홀더 (placeholder)로 표시됨
- 다른 에이전트 (Agent)로부터 서브 에이전트 (sub-agent)로 호출될 때 라우팅 (routing) 판단에 사용됨
이번에는 본문을 일본어로 작성했지만, description에는 의도적으로 Azure Updates, Microsoft Release Communications, GA/Preview/Retirement 등과 같은 영어 키워드를 남겨두었습니다. 이는 Azure의 공식 정보나 기능명이 영어로 표현되는 경우가 많고, 서브 에이전트로서의 라우팅 판단 시에도 영어 키워드가 더 잘 포착되기 때문입니다.
tools
tools: [web, search, read, edit]
tools는 이 에이전트 (Agent)가 사용할 수 있는 기능을 지정하는 중요한 항목입니다. 이번 용도에서는 각각 다음과 같은 의미를 갖습니다.
| tool | 용도 |
|---|---|
| web | Azure Updates나 RSS, 개별 페이지를 가져옴 |
| ... |
argument-hint
argument-hint: "예: 최근 30일간의 Azure OpenAI와 AKS 업데이트를 중요도 순으로 정리해줘"
argument-hint는 해당 에이전트 (Agent)에게 어떤 요청을 하면 좋을지 보여주는 입력 예시입니다.
에이전트 (Agent)를 선택했을 때 채팅 입력란의 플레이스홀더 (placeholder)로 표시되므로, 처음 사용하는 사람이 "무엇을 부탁하면 좋을지"를 쉽게 상상할 수 있게 합니다. 이번 사례의 경우, Azure Updates의 조사 대상으로 "기간"과 "서비스명"을 지정하고, 나아가 "중요도 순으로 정리"라는 기대하는 출력의 방향성까지 포함하고 있습니다.
단순히 Azure Updates를 조사해줘라고 하는 것보다, 다음과 같은 요소를 넣어두면 실제로 사용하기 편리해집니다.
- 대상 기간
- 대상 서비스
- 기대하는 정리 방법
- 출력의 상세도 (granularity)
user-invocable
user-invocable: true
user-invocable은 해당 에이전트 (Agent)를 사용자가 에이전트 드롭다운 메뉴에서 직접 선택할 수 있게 할지 여부를 지정하는 항목입니다.
이번에는 직접 Azure Updates Analyst를 선택하여 사용하고 싶었기 때문에 다음과 같이 true를 지정했습니다.
이 설정을 통해 Copilot Chat의 에이전트 드롭다운에 Azure Updates Analyst가 표시되며, 사용자가 명시적으로 선택하여 사용할 수 있게 됩니다.
반면, 사용자가 직접 선택하는 것이 아니라 Coordinator Agent와 같은 상위 에이전트 (parent Agent)로부터 호출되는 전문 에이전트 (specialized Agent)로만 사용하고 싶다면 false로 설정하는 것도 고려할 수 있습니다.
| 설정 | 사용 사례 |
|---|---|
true | 사용자가 에이전트 드롭다운에서 직접 사용하고 싶은 에이전트 |
false | 상위 에이전트 (parent Agent)로부터 호출되는 백엔드 전문 에이전트로 사용하고 싶은 경우 |
이번처럼 우선 수동으로 시행착오를 겪으며 키워나가고 싶은 에이전트 (Agent)라면, user-invocable: true로 설정해 두는 것이 이해하기 쉬울 것입니다.
2. 도입부 설명
당신은 Azure Updates Analyst입니다. Azure Updates의 최신 정보를 수집하고, 관련 변경 사항을 파악하여, Azure 관리자, 아키텍트, 운영 팀이 판단하기 쉬운 형태로 정리합니다.
frontmatter 다음에 기재한 이 한 문장은 에이전트 (Agent) 본문의 맨 처음에 배치하는 "역할 정의"입니다.
frontmatter가 VS Code / Copilot에게 에이전트의 이름이나 사용할 수 있는 도구 (tools)를 전달하는 설정이라면, 이 도입부 설명은 모델 (model)에게 "당신은 누구이며, 무엇을 담당하는 역할인지"를 전달하는 부분이 됩니다.
이번 문장에는 다음과 같은 요소를 포함했습니다.
| 요소 | 내용 |
|---|---|
| 역할명 | Azure Updates Analyst |
| ... | 単に Azure Updates を調べます (단순히 Azure Updates를 조사합니다) |
라고만 하면 RSS 내용을 목록화하기만 하는 Agent (에이전트)가 되기 쉽다고 생각합니다. 이번에는 「관련된 변경 사항을 파악한다」, 「판단하기 쉬운 형태로 정리한다」라고 작성함으로써, 단순한 취득이 아니라 분석과 요약까지 수행하는 역할로 정의했습니다.
또한, 누구를 대상으로 정리할 것인지도 중요합니다. 이번에는 Azure 관리자, 아키텍트, 운영 팀이라고 명시함으로써, 개발자 대상의 신기능 소개가 아니라 운영 영향이나 대응 방침에 초점을 맞춘 출력이 나오기를 기대하고 있습니다.
3. 주요 정보원
## 주요 정보원
- Microsoft Release Communications MCP 툴을 이 Agent (에이전트)에서 사용할 수 있는 경우, 우선적으로 그것을 사용합니다.
- MCP 툴을 사용할 수 없는 경우, 공식 Azure Updates 페이지와 RSS 피드를 참조합니다.
...
Azure Updates는 매일 업데이트되는 정보이므로, 모델의 지식에만 의존하면 오래된 정보를 바탕으로 답변할 가능성이 있습니다. 따라서 위와 같이 공식 정보를 우선하도록 명시했습니다.
포인트는 「모델의 기억이 아니라, 취득한 공식 정보를 근거로 한다」라고 작성한 점입니다. 이를 통해 최신 정보를 다루는 Agent (에이전트)로서의 전제를 명확히 하고 있습니다.
4. 대상 범위
## 대상 범위
- Azure 제품의 업데이트, 출시 상태, 폐지 예정, 프리뷰 (Preview), 일반 제공 (GA), 리전 전개, 서비스 사양 변경, 운영상 중요한 공지를 대상으로 합니다.
- 사용자가 서비스 이름, 리전, 상태, 기간, 대상 독자를 지정한 경우, 그것을 우선하여 필터링합니다.
...
이 항목에서는 Agent (에이전트)가 「무엇을 대상으로 조사할 것인가」와 「사용자 지정이 있을 경우 무엇을 우선할 것인가」를 정의하고 있습니다.
Azure Updates에는 매우 많은 업데이트가 포함되어 있기 때문에, 대상 범위를 모호하게 두면 관계가 적은 서비스나 우선순위가 낮은 업데이트까지 가져올 가능성이 있습니다. 따라서 우선 Azure 제품의 업데이트, 출시 상태, 폐지 예정, 프리뷰 (Preview), 일반 제공 (GA), 리전 전개, 서비스 사양 변경, 운영상 중요한 공지를 대상으로 함을 명시했습니다.
또한, 사용자가 서비스 이름이나 기간을 지정한 경우에는 그 지정을 우선하도록 했습니다. 예를 들어 이번처럼 AKS라고 지정한 경우에는, AKS 본체뿐만 아니라 AKS Automatic, AKS add-on, Fleet Manager, Ingress, 모니터링 등 AKS와 밀접한 업데이트도 대상 후보로 삼으면서, 관계성을 알 수 있도록 정리하는 이미지입니다.
기간 지정이 없는 경우에 최근 30일을 기본값으로 설정한 것은, 매번 「언제부터 언제까지를 봐야 하는지」를 지정하지 않아도 사용할 수 있게 하기 위해서입니다. Azure Updates는 건수가 많기 때문에, 기본 기간을 정해둠으로써 답변이 너무 넓게 퍼지는 것을 방지하려는 목적도 있습니다.
서비스 지정이 없는 경우에는 운영 영향이 클 것 같은 업데이트를 우선하도록 했습니다. 여기서 중요한 것은 Agent (에이전트)에게 「어렴풋이 중요해 보이는 것을 골라줘」라고 맡기기만 하는 것이 아니라, 어떤 관점에서 골랐는지를 명시하게 하는 것입니다. 이를 통해 왜 그 업데이트가 채택되었는지를 읽는 사람이 판단하기 쉬워집니다.
5. 분석 절차
## 분석 절차
1. 공식 정보원으로부터 최신 Azure Updates 정보를 취득합니다.
2. 사용자가 지정한 서비스, 리전, 상태, 업데이트 유형, 기간으로 필터링합니다.
...
이 Agent (에이전트)에서 가장 중요한 것은 RSS를 취득하는 것으로 끝내지 않는 것입니다. 단순한 목록화라면 스크립트로도 충분하지만, 이번에는 「어느 것이 중요한가」, 「운영상 어떤 영향이 있을 것인가」, 「다음에 무엇을 확인해야 하는가」까지 정리하고 싶었기 때문에 분석 절차를 명시했습니다.
6. 출력 형식
## 출력 형식
사용자가 다른 언어를 지정하지 않는 한, 일본어로 답변합니다.
서두에 짧은 에그제큐티브 서머리 (Executive Summary)를 배치합니다.
...
본 항목에서는 출력 형식, 파일 출력, 중요도 기준 등을 정의하고 있습니다.
출력 형식에 대하여
| 중요도 | 날짜 | 서비스 | 분류 | 업데이트 | 예상 영향 | 권장 액션 |
출력 형식은 상당히 중요했습니다. 처음에는 URL 열을 포함했었지만, 표가 가로로 너무 길어졌기 때문에 최종적으로는 위의 형식으로 정했습니다.
업데이트
열에는 Markdown 링크가 포함된 제목을 넣도록 했기 때문에, URL 열을 별도로 두지 않아도 참조처로 이동할 수 있습니다. 이처럼 Agent의 출력을 실제로 확인하면서 조정해 나가는 것이 중요하다고 느꼈습니다.
파일 출력에 대하여
사용자가 `CSV`, `Excel`, `파일 출력`, `저장`을 명시적으로 요청한 경우에만, Markdown 표와 동일한 내용을 CSV 파일로 저장합니다. 사용자가 파일 출력을 요청하지 않은 경우에는 일반적인 채팅 답변만 제공하십시오.
CSV 저장 시 기본 규칙은 다음과 같습니다.
- 저장 위치는 사용자가 지정하지 않는 한, 이 Agent 정의가 위치한 workspace root의 `outputs/azure-updates/`로 합니다.
...
보통은 채팅상에서 Markdown 표를 반환하는 것에 그치고, 사용자가 명시적으로 요청했을 때만 CSV를 저장하도록 설정했습니다. 이는 Agent가 멋대로 파일을 너무 많이 생성하지 않도록 하기 위함입니다.
또한, Markdown 표에서는 업데이트 열에 링크를 삽입하지만, CSV에서는 Excel에서 다루기 쉽도록 제목(Title)과 URL을 분리하도록 했습니다.
중요도에 대하여
중요도는 다음 기준에 따라 판단합니다.
- High: 폐지 예정, 파괴적 변경(Breaking Changes) 또는 동작 변경, 보안 또는 컴플라이언스 영향, 가격 또는 SKU 영향, 운영 환경에 영향을 미칠 가능성이 높은 항목.
- Medium: 아키텍처, 마이그레이션, 채택 계획에 영향을 줄 수 있는 GA(General Availability), 리전 확장, 중요한 기능 추가.
...
Agent에게 중요도를 부여하게 할 경우, 기준을 적어두지 않으면 매번 결과가 흔들리기 쉽습니다.
이번에는 위와 같이 정의했습니다. 특히 Retirement(은퇴/폐지)를 High로 취급하도록 함으로써, 운영 팀이 놓치고 싶지 않은 정보를 상단에 노출하기 쉽게 만들었습니다.
7. 제약 사항
## 제약 사항
- 업데이트 내용, 날짜, 리전, 제품명을 추측하여 작성하지 마십시오.
- Preview를 GA로 취급하지 마십시오.
...
마지막으로 해서는 안 될 일을 명시했습니다.
Agent는 편리하지만, 최신 정보를 다룰 때는 추측으로 보완될 경우 곤란해집니다. 따라서 공식 정보에 없는 것은 단정하지 말 것, 파일 저장은 명시되었을 때만 수행할 것, 이라는 제약을 넣었습니다.
실제로 작동시켜 보자
지금까지 Agent 정의의 각 항목에 대해 쭉 설명해 드렸습니다만, 세세한 부분은 크게 신경 쓰지 말고 작동시킨다 -> 생각대로 작동하지 않으면 수정한다를 반복하며 튜닝해 나가면 되지 않을까 개인적으로 생각하고 있습니다 (애초에 베이스가 되는 Agent 정의에 대해서는 AI에게 작성을 요청하면 적당히 잘 만들어 줄 것이므로, 처음부터 직접 만드는 일은 거의 없겠지만 말입니다...).
그럼, VS Code 상에서 Agent를 작동시키는 절차를 정리해 보겠습니다.
- Custom Agent 정의 파일 생성
- VS Code에서 Agent 인식시키기
- Agent를 선택하여 Azure Updates 가져오기 및 요약 실행
1. Custom Agent 정의 파일 생성
VS Code의 Custom Agent는 workspace 하위의 .github/agents/에 *.agent.md 파일을 배치함으로써 이용할 수 있습니다.
이번에는 workspace에서 사용할 Agent로서 다음 파일을 생성했습니다.
.github/agents/azure-updates-analyst.agent.md
디렉토리 구성 이미지는 다음과 같습니다.
.github/
└─ agents/
└─ azure-updates-analyst.agent.md
작성한 azure-updates-analyst.agent.md에는 앞 장에서 설명한 frontmatter, 역할, 정보원, 분석 절차, 출력 형식, 제약 사항 등을 기재합니다.
2. VS Code에서 Agent 인식시키기
Agent 정의 파일을 생성한 후, VS Code가 이를 인식할 수 있도록 Window 재로드(Reload Window)를 실시했습니다.
절차는 다음과 같습니다.
Ctrl + Shift + P를 눌러Developer: Reload Window를 실행한다.
- Copilot Chat을 연다.
- 에이전트 드롭다운 (Agent selector)을 열어
Azure Updates Analyst
가 표시되는지 확인한다.
또한, 도중에 Chat Customizations Evaluations 확장 기능 설치를 권장하는 알림이 표시되었습니다. 이는 Agent 또는 Chat customization의 정의를 평가 및 검증하기 위한 Microsoft 제공 확장 기능이므로, 이번에는 설치하였습니다.
3. Agent를 선택하여 Azure Updates 가져오기 및 요약 실행
에이전트 드롭다운에서 Azure Updates Analyst를 선택하고, 우선 다음과 같은 프롬프트로 테스트해 보았습니다.
텍스트는 다음과 같습니다.
최근 30일간의 AKS Azure Updates를 중요도 순으로 정리해 주세요.
함께 Excel에서 열 수 있는 CSV 파일로 저장해 주세요.
실행 시에는 Azure Updates의 RSS에 접속하기 때문에 외부 URL에 대한 액세스 허용을 요청받았습니다. 이는 공식 Azure Updates RSS이므로 허용하였습니다.
URL은 다음과 같습니다.
실행 결과로 다음과 같은 내용이 출력되었습니다.
요약 (Summary)
대상 기간은 2026-05-05부터 2026-06-04까지의 최근 30일이며, 대상은 AKS 및 공식 본문에서 AKS / AKS Automatic / AKS add-on / AKS estate와의 관계가 명시된 업데이트입니다. 해당 건수는 총 7건으로, High는 없으며 Medium 5건, Low 2건이었습니다. 즉시 확인해야 할 항목은 AKS Automatic, Azure Container Linux, AKS 앱 모니터링, Application Gateway for Containers / Istio 연동입니다.
| 중요도 | 날짜 | 서비스 | 분류 | 업데이트 | 예상 영향 | 권장 조치 |
|---|---|---|---|---|---|---|
| Medium | 2026-06-02 | Azure Kubernetes Service / Azure Container Linux | GA | Azure Container Linux (ACL) now generally available on Azure Kubernetes Service (AKS) | AKS 노드 풀(node pool)을 위한 컨테이너 최적화 및 불변(immutable) OS가 GA되었습니다. 노드 OS 표준화, 보안 강화, 패치 운영에 영향을 미칩니다. | 신규 또는 업데이트 예정인 노드 풀에 채택 여부, OS 표준, 보안 기준, 운영 절차와의 정합성을 확인하십시오. |
| ... |
확인 관점
- AKS Automatic을 이용 중인 환경은 managed system node pools와 Application Gateway add-on의 적용 범위를 확인하십시오.
- AKS 노드 풀(node pool)의 OS 표준에 Azure Container Linux를 추가할지 보안 기준 및 운영 절차를 통해 평가하십시오.
- AKS 앱 모니터링 표준으로 Application Insights auto-instrumentation을 채택할 경우, 기존 OpenTelemetry 구성과의 중복에 주의하십시오.
또한, Excel에서 열 수 있는 CSV로 다음과 같이 저장되었습니다.
outputs/azure-updates/azure-updates-2026-06-04-aks.csv
단순한 RSS 목록이 아니라 GA / Preview 분류, 운영상의 예상 영향, 권장 조치까지 정리해 주기 때문에 Agent로서 활용할 가치가 충분하다고 느꼈습니다.
동작 확인 시 살펴볼 포인트
마지막으로, Agent를 테스트할 때 살펴보면 좋을 관점들을 정리해 둡니다.
- 공식 정보원을 참조하고 있는가
- 대상 기간이나 대상 서비스가 반영되어 있는가
GA,Preview,Retirement를 혼동하지 않고 있는가Retirement나 운영 영향이 큰 업데이트를 상위에 배치하는가- 예상 영향이나 권장 조치가 실무에서 사용할 수 있는 수준인가
- 표가 읽기 쉬운가
- CSV 저장을 요청했을 때만 파일이 생성되는가
이러한 점들을 살펴보면서 Agent 정의를 조금씩 수정해 나가면, 자신의 용도에 맞는 Agent로 키우기 쉬울 것이라고 생각합니다.
사용해 보며 알게 된 점
이번에 시도하며 알게 된 점을 간단히 정리하면 다음과 같습니다.
.agent.md의 본문은 일본어로 작성해도 문제없이 동작한다description에 영어 키워드를 포함해 두면 서브 에이전트 (Sub-agent)의 라우팅 (Routing) 판단 시 포착되기 쉽다- Agent에게 부여하는 도구 (Tools)는 최소한으로 유지하는 것이 안심된다
- 외부 URL 접속이나 파일 저장 시에는 승인 요청이 발생한다
- 처음에는 승인 내용을 확인하면서 진행하는 것이 좋다
- 출력 형식은 한 번 실행해 본 뒤에 조정하는 것이 빠르다
- CSV 저장까지 가능하면 실무에서 사용하기 좋은 형태가 된다
특히 처음부터 완벽한 Agent 정의를 만들기보다, 실제로 구동해 보면서 "표가 가로로 너무 길다", "URL 열은 필요 없다", "CSV로도 받고 싶다"와 같은 위화감을 반영해 나가는 것이 좋아 보였습니다.
보충: Custom Chat 모드와 Custom Agent의 관계
이전에 Azure Policy 관련 기사에서 GitHub Copilot의 Custom Chat 모드도 테스트해 본 적이 있습니다.
여기서 한 가지 보충하자면, Custom Chat 모드와 Custom Agent는 별개의 기능이 아니라, 이름이 변경된 동일한 기능입니다.
VS Code의 공식 문서 (Official documentation)에도 다음과 같이 기재되어 있습니다.
Custom agents were previously known as custom chat modes. The functionality remains the same, but the terminology has been updated to better reflect their purpose in customizing AI behavior for specific tasks.
If you have existing
.chatmode.mdfiles, rename them to.agent.mdto convert them to the new custom agent format
즉, 지금까지 .chatmode.md로 만들어 왔던 것들은 .agent.md로 이름을 변경함으로써 Custom Agent로서 그대로 사용할 수 있습니다. 새로운 용어인 Custom Agent에 맞춰가는 것이 공식적인 방향성입니다.
요약
이번에는 GitHub Copilot의 Custom Agent를 이용하여, Azure Updates를 조사 및 요약하는 Azure Updates Analyst를 작성했습니다.
단순히 RSS를 가져와 목록화하는 것에 그치지 않고, Agent에게 다음과 같은 역할을 부여함으로써 AI를 활용하고 있다는 느낌을 줄 수 있었다고 생각합니다.
- 공식 정보를 취득한다
- 대상 서비스나 기간으로 필터링한다
- GA / Preview / Retirement를 분류한다
- 운영 영향을 고려하여 중요도를 부여한다
- 권장 조치 (Recommended action)를 제시한다
- 필요에 따라 CSV로 저장한다
GitHub Copilot을 단순히 "코드 보완 도구"로서뿐만 아니라, 자신의 작업에 맞춘 작은 Agent로 키워 나간다면 일상적인 정보 수집이나 정리에도 활용할 수 있을 것 같습니다.
Appendix
공식 Docs
VS Code 문서
GitHub 문서
Discussion
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기