---
title: 릴리스 전 검토: Copilot Studio 에이전트를 위한 Agent Review Tool 활용하기
description: Preview 통과만으로는 부족해요. Agent Review Tool로 구성을 점검하고, 발견 사항과 근거를 확인해 릴리스 전 위험을 줄이는 방법을 정리했어요.
date: 2026-09-04
  tags: [Agent Review Tool, Copilot Studio, Skill evaluator, Power Platform, AI 에이전트]
cards:
  - /cards/agent-review-tool/card-01.png
  - /cards/agent-review-tool/card-02.png
  - /cards/agent-review-tool/card-03.png
  - /cards/agent-review-tool/card-04.png
  - /cards/agent-review-tool/card-05.png
  - /cards/agent-review-tool/card-06.png
  - /cards/agent-review-tool/card-07.png
  - /cards/agent-review-tool/card-08.png
author: Lissa
source: https://interlinear.work/notes/agent-review-tool/
---

> **원문:** [Review Before Release: Using Agent Review Tool for Copilot Studio Agents](https://microsoft.github.io/mcscatblog/posts/agent-review-tool/)
> **게시일:** 2026-08-18 · **저자:** Ramakrishnan Raman

여러분의 에이전트가 **미리 보기(Preview)** 탭에서 기대한 대로 동작해요. 예상했던 질문에 답하고, 올바른 도구를 호출하고, 다음 환경으로 넘어갈 준비가 된 것처럼 보이죠.

하지만 릴리스하기 전에, 에이전트의 지침, 스킬, 도구, 지식 소스, 평가 커버리지, 연결된 에이전트 아키텍처를 어떻게 체계적으로 검토할 수 있을까요?

에이전트에 지침 하나와 스킬 하나만 있을 때는 모든 걸 검사하기 쉬워요. 하지만 에이전트가 그렇게 작은 채로 머물러 주는 경우는 드물죠.

에이전트가 커지면 구성이 여러 표면에 흩어져요. 어떤 스킬은 그 자체로는 완벽히 합리적인데 다른 스킬과 겹칠 수 있고, 어떤 도구는 올바르게 구성돼 있는데 모호하게 참조될 수 있어요. 어떤 지식 소스는 존재하긴 하는데, 스킬이 에이전트에게 그걸 어떻게 쓰라는 건지 충분한 방향을 주지 못할 수도 있고요. 미리 보기는 딱 맞는 입력 조합이 나타나기 전까지는 이런 문제를 드러내지 않을 수 있어요.

Copilot Agent Kit의 일부인 [Agent Review Tool](https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/kit-overview)은 이런 위험을 반복 가능하게 검사하는 방법을 제공해요. 이 글에서는 GitHub Copilot 하니스로 구동되는 Copilot Studio 에이전트인 **ZAVA Visual Merchandiser**라는 가상의 리테일 비주얼 머천다이징 에이전트를 예로 들게요. 이를 통해 세 가지 기능에 초점을 맞춘 실용적인 릴리스 전 워크플로를 보여드릴게요.

1. **Review findings** — 근거 기반(grounded)<sup>1</sup> 점검을 심각도와 규칙 계열별로 정리해요.
2. **Skill evaluator** — 개별 스킬의 품질과 스킬 간 오케스트레이션<sup>2</sup>을 평가해요.
3. **Agent map** — 검토된 스킬이 도구, 지식 소스, 기타 구성된 컴포넌트와 어떻게 연결되는지 검사할 수 있게 도와줘요.

이 글은 Agent Review Tool의 모든 버튼을 둘러보는 투어가 아니에요. 목표는 딱 하나의 질문에 잘 답하는 거예요. **에이전트가 동작하게 된 뒤, 릴리스하기 전에 메이커는 무엇을 검사하고 개선해야 하는가?**

> **참고:** 2026년 8월 18일 기준으로 Agent Review Tool은 미리 보기(preview) 경험으로 제공돼요. 평가기와 화면 구성은 바뀔 수 있어요.

## 미리 보기 탭이 검토의 전부가 아닌 이유

대화 테스트는 꼭 필요하지만, 대화 하나는 그 입력에 대해 선택된 경로 하나만 실행해요. 다음 같은 것들은 저절로 알려주지 않아요.

- 두 스킬의 책임이 겹치는지
- 스킬 설명이 에이전트가 언제 그 스킬을 쓸지 결정하는 데 도움이 되는지
- 지침이 경계와 에스컬레이션 동작을 정의하는지
- 구성된 기능에 대해 대표성 있는 평가 커버리지가 있는지
- 스킬이 도구나 지식 소스를 유지 보수 가능할 만큼 명확하게 참조하는지
- 아키텍처상의 관계가 실제로 구성된 것인지, 작성된 텍스트에서 추론된 것인지, 런타임에 실제로 관측된 것인지

Agent Review Tool은 저장된 구성을 검사하고, 메이커가 살펴볼 수 있는 발견 사항(findings)을 만들어내서 런타임 테스트를 보완해줘요.

이 구분이 중요해요.

| 검토 방법 | 답하는 데 도움이 되는 질문 |
| --- | --- |
| 미리 보기와 평가 | 이 대화들에 대해 에이전트가 기대한 대로 동작했는가? |
| Agent Review | 저장된 구성에 품질, 명확성, 커버리지, 유지 보수성 위험이 있는가? |

어느 쪽도 에이전트가 프로덕션에 쓸 준비가 됐다고 인증해주진 않아요. 다만 둘을 함께 쓰면, 하나만 쓸 때보다 훨씬 쓸모 있는 그림이 나와요.

더 넓은 툴킷이 처음이라면, 위에 링크한 개요 문서가 메이커와 관리자 경험이 어떻게 맞물리는지 설명해줘요.

## 베이스라인 검토 수립하기

ZAVA Visual Merchandiser는 이 워크스루를 위한 가상의 에이전트이고, 다운로드할 수 있는 샘플은 아니에요. 스크린샷에는 가상의 이름을 썼고 테넌트별 세부 정보는 뺐어요. 2026년 8월 18일의 검토를 고른 이유는, 그 발견 사항들이 이해하고 수정하고 다시 검토하기에 충분히 구체적이었기 때문이에요.

**Agent Review Tool**에서 에이전트를 찾아 검토를 시작하세요. 검토는 사용 가능한 구성에 대해 [결정론적 점검과 AI 지원 분석을 결합](https://github.com/microsoft/Power-CAT-Copilot-Studio-Kit/blob/2e1a9883f73669d410d33c38a3a4527744df90a4/AGENTREVIEWTOOL_REFERENCE_GUIDE.md#capability-summary)해요. 발견 사항은 항상 그 검토에서 수집된 근거에 뿌리를 둔 채로 유지되고요.

검토가 끝나면 세 개의 주요 섹션으로 된 작업 공간이 열려요.

- **Review** — 발견 사항, Skill evaluator, 평가 커버리지, 전체 점검 목록을 담고 있어요.
- **Agent map** — 검토된 아키텍처의 그래프 뷰와 목록 뷰를 담고 있어요.
- **Cost & efficiency** — 범위가 한정된 관측 활동 신호, 개선 가이드, 검증 가이드, 계획 범위를 담고 있어요.

이 글은 앞의 두 섹션만 다룰게요. 비용과 효율성은 계획 범위와 관측 활동이 구성 검토와는 다른 근거 경계를 가지고 있어서 따로 다뤄야 하거든요.

_이 워크스루 스냅숏에서 베이스라인 검토는 63%를 기록했고, 54개 점검 중 39개를 통과했어요._

## 발견 사항에서 시작하되, 점수에서 멈추지 말기

검토 요약은 점수와 함께 오류, 경고, 정보성 발견 사항의 분류를 보여줘요. 점수는 유용한 요약이 되어주지만, 무엇을 조사하고 개선할지 알려주는 건 개별 발견 사항과 그 근거예요.

GitHub Copilot 하니스로 구동되는 에이전트라면, [근거 기반 점수(grounded score)](https://github.com/microsoft/Power-CAT-Copilot-Studio-Kit/blob/2e1a9883f73669d410d33c38a3a4527744df90a4/AGENTREVIEWTOOL_REFERENCE_GUIDE.md#github-copilot-agent-score)는 평가 준비 상태와 지침에 대해 결정론적이고 규칙 기반인 축(pillar)을 써요. 여기에 에이전트가 스킬, 도구, 지식 소스, 연결된 에이전트를 갖고 있으면 축이 추가되고요. AI 지원 발견 사항은 검토를 뒷받침하는 근거로 표시되긴 하지만, 결정론적 축의 점수 자체를 바꾸지는 않아요.

> **주의:** 높은 점수가 런타임 품질을 증명하지는 않고, 낮은 점수가 에이전트의 실패를 증명하지도 않아요. 발견 사항을 보고 무엇을 조사할지, 다음에 어떤 평가를 실행할지 결정하세요.

무언가를 바꾸기 전에 베이스라인을 기록해두세요.

- 전체 점수
- 오류와 경고
- 평가된 스킬 수
- 가장 약한 스킬 차원
- 스킬 간 오케스트레이션 발견 사항
- 구성된 기능에 대한 평가 커버리지

이렇게 해두면 검토를 다시 돌렸을 때 "좀 나아진 것 같은데" 수준보다 훨씬 쓸모 있는 비교 기준이 생겨요.

### 트리아지<sup>3</sup>에는 Review findings 뷰 사용하기

먼저 **Review findings**를 여세요. 기능 인벤토리가 무엇이 수집됐는지 요약해주고, 심각도 필터로 결과 범위를 좁힐 수 있어요. 발견 사항은 규칙 계열별로 묶여 있고, 하나를 선택하면 그 근거, 판단 이유, 권장 사항, 가능한 수정 단계, 참고 자료가 열려요.

여기가 처음 던지는 세 가지 질문에 가장 빠르게 답할 수 있는 곳이에요.

1. 이번 릴리스 전에 주의가 필요한 발견 사항은 무엇인가요?
2. 어떤 기능 또는 구성 영역이 그걸 만들어냈나요?
3. 그 근거가 에이전트에서 검증할 수 있을 만큼 구체적인가요?

_Review findings는 심각도, 근거, 권장 사항, 참고 자료를 하나의 작업 공간에 담아 초기 트리아지 뷰를 제공해요._

Review findings 뷰는 **뭘 조사할 가치가 있는지** 알려줘요. Skill evaluator 뷰는 그 문제가 고립된 건지 스킬 세트 전반에 반복되는 건지 판단하는 데 도움을 주고, Agent map은 주변 구성 컨텍스트를 보여줘요.

## 패턴별로 스킬 품질 검사하기

**Skill evaluator**를 여세요. 기본값인 **Group by pattern** 뷰는 평가된 모든 스킬에 걸쳐 결과를 정리해서, 평균 품질, 안전 플래그, 가장 약한 루브릭<sup>4</sup> 차원, 스킬 간 오케스트레이션 발견 사항을 요약해줘요.

지침 품질은 네 가지 루브릭 차원에 걸쳐 평가돼요.

| 차원 | 살펴볼 것 |
| --- | --- |
| 명확성(Clarity) | 설명이 구체적이고 모호하지 않은 언어로 스킬이 언제 선택되어야 하는지 서술하는가? |
| 실행 가능성(Actionability) | 단계가 실행 가능하고, 순서가 있으며, 필요한 입력, 출력, 엣지 케이스, 검증에 대해 명확한가? |
| 범위 규율(Scope discipline) | 스킬이 명확한 경계를 가지고 무관한 책임 없이 하나의 일관된 일을 수행하는가? |
| 조합 가능성(Composability) | 스킬이 부모 지침 및 형제 스킬과 겹침, 모순, 숨은 의존성 없이 함께 작동할 수 있는가? |

같은 스킬 뷰는 Bundle integrity, Resource safety, Operational readiness도 함께 보여줘요. 이 결과들은 앞의 네 가지 지침 품질 차원과는 별개예요.

이 차원들은 GitHub Copilot 하니스로 구동되는 에이전트에 특히 유용해요. 스킬 품질은 하나의 `SKILL.md` 안에 담긴 내용만의 문제가 아니거든요. 에이전트는 그 스킬을 자기가 쓸 수 있는 다른 모든 대안과도 구별할 수 있어야 해요.

GitHub Copilot 하니스로 구동되는 에이전트의 스킬에 대한 더 깊은 소개는 [Agents Have Skills Now](https://microsoft.github.io/mcscatblog/posts/modern-mcs-agent-skills/)를 참고하세요.

_스킬 결과를 패턴별로 그룹화하면 에이전트 전반에 반복되는 약점이 눈에 보여요._

### 실제로 고칠 곳을 찾으려면 "By skill" 사용하기

그룹 뷰는 약점이 반복되는지 알려줘요. **By skill**은 어디를 고쳐야 하는지 알려주고요.

ZAVA의 경우 `display-audit`을 가리켰어요. 다섯 단계 중 두 단계가 **Merchandising Scorecard**와 **Regional Escalation Agent**를 언급했지만, 정작 어느 기능도 에이전트에 구성되어 있지 않았어요. Agent Review는 이걸 **Skill References a Capability the Agent Does Not Have** 항목의 오류로 표시했고요. 이 스킬은 **Actionability 4/10**, **지침 품질 61%**도 기록했어요.

덕분에 풀어야 할 구체적인 문제가 눈에 보였어요. 에이전트는 작성된 대로라면 컴플라이언스 채점이나 에스컬레이션 단계를 완료할 수 없었던 거예요.

_선택된 발견 사항이 스킬 품질 판단을 범위가 한정된 구성 근거와 연결해요._

유용한 발견 사항은 문제를 일으킨 지침이나 스킬 텍스트를 콕 짚어줘서, 메이커가 검증하고 고치기 쉽게 만들어줘요. AI 지원 평가를 쓸 수 없을 때는, Agent Review가 그 점검을 그냥 통과로 처리하는 대신 그 상태를 그대로 표시해요.

## Agent map으로 주변 아키텍처 확인하기

스킬 발견 사항은 아키텍처 맥락 안에서 봐야 더 잘 이해돼요. **Agent map**을 열어서 저장된 검토에 담긴 컴포넌트들을 살펴보세요.

맵에는 검토에서 수집된 지원 컴포넌트가 다 들어 있어요. 검색과 필터로 그래프를 좁힐 수 있고, **Map**과 **List**는 같은 필터링 정보를 시각적 뷰와 의미적 뷰로 각각 보여줘요.

ZAVA 발견 사항의 경우, 맵을 해당 스킬과 관련 도구·지식 소스로 필터링한 다음 이렇게 물어보세요.

1. 참조된 기능이 실제로 에이전트에 구성되어 있나요?
2. 스킬이 그 기능의 구성된 이름을 명확하고 일관되게 쓰고 있나요?
3. 다른 메이커가 그 스킬이 언제, 왜 그 기능을 쓰는지 이해할 수 있을까요?

_Agent map은 런타임 실행을 주장하지 않으면서 네 개의 스킬과 그 작성된 참조에 대한 구성 컨텍스트를 제공해요._

> **참고:** Agent map은 검토된 구성과, 범위가 한정된 텍스트상의 참조 관계를 보여줄 뿐이에요. 에이전트의 런타임 계획을 재구성하거나, 도구·지식 소스·스킬·연결된 에이전트가 실제로 호출됐다는 걸 증명해주지는 않아요.

## 집중된 개선 하나만 수행하기

근거가 짚어준 지침이나 구성만 바꾸세요. ZAVA를 수정하기 전에 의도한 수정 내용을 문서로 남기고, 그게 관련 없는 동작까지 바꾸지는 않는지 확인하세요.

`display-audit`은 새 기능을 추가하는 대신 스킬을 다시 쓰기로 했어요.

정확한 단계 텍스트는 남아 있지 않아서, 아래 표는 전후 문구를 그대로 옮긴 게 아니라 검증된 변경 내용을 개념적으로 요약한 거예요. 수정 패턴을 보여줄 뿐, 그대로 복사해 쓸 수 있는 스킬 가이드는 아니에요.

| 베이스라인 문제 | 구현된 수정 |
| --- | --- |
| 스킬이 **Merchandising Scorecard**와 **Regional Escalation Agent**를 참조했지만, 어느 것도 ZAVA에 구성되어 있지 않았어요. | 해당 단계들이 구성된 기능인 **Planogram Archive**, **Display Photo Library**, **ZAVA visual-merchandising standards** 지식 소스, **ZAVA Store Ops Assistant**를 사용하도록 변경했어요. |

이 변경은 참조된 모든 기능이 이제 에이전트에 실제로 존재하니 근거를 직접 해결해줘요. 동시에 스킬의 원래 목적, 즉 디스플레이를 점검하고, 쓸 수 있는 머천다이징 표준으로 평가하고, 후속 조치를 구성된 어시스턴트로 라우팅한다는 목적도 그대로 지켜줘요.

업데이트한 다음에는:

1. 변경된 스킬을 실행할 가능성이 가장 높은 대화와 평가를 돌려봐요.
2. 라우팅과 출력이 여전히 의도대로 동작하는지 확인한 다음, Agent Review를 다시 실행해요.
3. 스킬 차원, 오케스트레이션 발견 사항, 뒷받침 근거를 베이스라인과 비교해요.
4. Agent map을 다시 열어 구성 뷰가 여전히 의도한 아키텍처를 반영하는지 확인해요.

| 지표 | 베이스라인 검토 | 두 번째 검토 |
| --- | ---: | ---: |
| 근거 기반 구성 점수 | 63% | 67% |
| 통과한 점검 | 54개 중 39개 | 54개 중 51개 |
| 오류 | 8 | 0 |
| 경고 | 7 | 2 |
| 평균 스킬 품질 | 64% | 90% |
| 평가 커버리지 | 7개 중 0개 | 7개 중 0개 |

대상이었던 미구성 기능(unavailable-capability) 발견 사항은 더 이상 나타나지 않았어요. 다만 평가(Evaluation)가 축 가중 근거 기반 점수에서 고정 **30%** 비중을 차지하기 때문에, 54개 중 51개 점검을 통과했는데도 빠진 테스트 커버리지가 계속 결과를 끌어내렸어요.

최종 `display-audit`의 지침 품질 결과는 보존된 근거에 담겨 있지 않아서, 이 비교가 스킬별로 정밀한 변화를 주장하지는 않아요. 이 워크스루에서는 런타임 평가 결과도 남아 있지 않았고요. 근거가 보여주는 건 구성 발견 사항이 해결됐다는 것이지, 런타임 동작이 좋아졌다는 게 아니에요.

_두 번째 검토는 67%에 도달했으며, 54개 점검 중 51개 통과, 오류 0개, 경고 2개, 평가 커버리지는 여전히 7개 중 0개였어요._

_두 번째 Skill evaluator 결과는 평균 품질 90%, 안전 플래그 없음, 스킬 간 오케스트레이션 발견 사항 1건을 보여줘요._

미구성 기능 오류를 해결하자, 발견 사항 목록이 텅 비는 대신 다음 검토 우선순위가 드러났어요. 남은 경고 두 개는 누락된 평가 테스트 세트와 지침 문자 위생(instruction-character hygiene)에 관한 것이었고요. Skill evaluator는 네 개 스킬 전반에서 **Capability Coverage Gap**도 하나 찾아냈어요. 이 항목들은 이번 워크스루의 집중된 변경 범위 밖에 있었어요.

발견 사항은 사라졌는데 런타임 평가가 오히려 나빠진다면, 그건 에이전트를 개선한 게 아니라 검토 결과만 개선한 거예요. 목표는 점수를 따는 게 아니라, 에이전트를 더 명확하고, 더 신뢰할 수 있고, 다음 메이커가 이해하기 쉽게 만드는 거예요.

이게 바로 모델이 내놓은 평점 하나만으로는 충분하지 않은 이유이기도 해요. [더 나은 LLM 점수화 패턴](https://microsoft.github.io/mcscatblog/posts/better-llm-scoring/)은 모델에게 정체불명의 숫자 하나를 요구하는 것보다, 근거가 뒷받침된 작은 점검들과 결정론적 결합 규칙이 왜 더 방어 가능한지 설명해줘요.

## Agent Review Tool이 주장하지 않는 것

Agent Review Tool은 조사를 안내해줄 뿐이에요. 에이전트를 프로덕션에 쓸 준비가 됐다고 인증하지도, 원본 에이전트를 직접 고쳐주지도, 대표성 있는 테스트 케이스와 사람의 검토를 대신하지도, 구성된 기능이 실제로 실행됐다는 걸 증명해주지도 않아요. 비용 계획과 관측 활동 뷰도 마찬가지로 실제 청구 금액을 알려주거나 절감을 보장하지는 않고요.

## 결론

미리 보기 탭에서 기대대로 동작하는 에이전트는 더 깊은 검토를 할 준비가 된 것이지, 반드시 릴리스할 준비가 된 건 아니에요. Agent Review Tool은 발견 사항, 뒷받침 근거, 스킬 품질, 평가 공백, 구성 관계를 하나의 워크플로에 모아서, 메이커가 "괜찮아 보이는데"에서 벗어나 집중적이고 추적 가능한 개선으로 나아갈 수 있게 해줘요.

Agent Review Tool은 [Microsoft Marketplace](https://marketplace.microsoft.com/en-us/product/dynamics-365/microsoftpowercatarch.copilotstudiokit2)의 Copilot Agent Kit을 통해 쓸 수 있어요. 설치와 접근 요구 사항은 [Agent Review Tool 레퍼런스 가이드](https://github.com/microsoft/Power-CAT-Copilot-Studio-Kit/blob/2e1a9883f73669d410d33c38a3a4527744df90a4/AGENTREVIEWTOOL_REFERENCE_GUIDE.md)에 정리돼 있으니, 이 워크플로는 툴킷 설정이 아니라 에이전트 검토 자체에 집중하면 돼요.

대표성 있는 평가와 함께 쓰세요. 베이스라인을 수립하고, 근거를 검사하고, 집중된 변경을 하나 수행하고, 다시 검토하세요. 점수보다 결과가 중요해요. 구성은 더 명확해져야 하고, 런타임 동작은 별도로 검증해야 하고요.

오늘 여러분의 에이전트에서 릴리스 전 검토 중 가장 어려운 부분은 뭔가요? 스킬 경계, 평가 커버리지, 아니면 구성된 아키텍처를 이해하는 일인가요?

---

## 어휘 주석

1. **근거 기반(grounded):** 추측이 아니라 실제로 수집된 구성 데이터와 증거에 뿌리를 두고 있다는 뜻.
2. **오케스트레이션(orchestration):** 여러 스킬이나 구성 요소가 서로 조율되어 함께 동작하도록 조정하는 것.
3. **트리아지(triage):** 여러 문제 중 무엇을 먼저 처리할지 우선순위를 매겨 선별하는 작업.
4. **루브릭(rubric):** 품질을 평가할 때 기준이 되는 세부 항목들의 체계.