Copilot Studio 에이전트 제대로 만들기: 그라운딩, 페르소나, 디버깅, 게시까지 초보자 실수 피하기

첫 번째 Copilot Studio 에이전트를 공개했는데 "정책에 따르면 아마도 그게 자연스러운 부분인 것 같아요" 같은 엉뚱한 답이 나온다면 난감합니다. 하지만 몇 가지 수정과 실제 정책 문서에 기반한 명확한 지침을 더하면, 이런 답변을 정확한 조항을 인용하는 답변으로 바꿀 수 있습니다.

이 글에서는 테스트 창에서 잘못된 응답을 재현하는 방법, 에이전트가 실제 문서를 인용하도록 그라운딩하는 방법, 페르소나 설정, 디버깅 루프, 게시 전 체크리스트를 순서대로 정리합니다. 초보자가 자주 하는 실수를 피하는 데 초점을 맞췄습니다.

테스트 창에서는 완벽한데 실제 환경에서 무너지는 이유

Copilot Studio의 테스트 창은 정돈되고 예의 바른 환경입니다. 질문은 짧고 명확하며, 대개 준비해 둔 예제와 비슷합니다. 그래서 모든 테스트가 성공처럼 느껴집니다. 실제 사용자는 평소 말하듯 입력합니다. 같은 의미라도 "호텔에 머물 때 얼마까지 청구할 수 있나요?", 오타가 섞인 "호텔 경비 한도", "출장비 좀 다시 알려줘"처럼 표현이 제각각입니다. "경비 한도가 얼마인가요?"만 테스트했다면 에이전트가 이 연결고리를 항상 찾아내지는 못합니다.

3가지 변형 질문으로 격차 확인하기

테스트 창에서 같은 질문을 세 가지 버전으로 입력해 보세요.

1. 깔끔하게 정리된 버전
2. 평소 쓰는 말투의 버전
3. 오타가 있는 버전

세 가지를 모두 맞히기도 하지만, 깔끔한 질문에만 제대로 답하는 경우도 있습니다. 후자라면 보기 좋은 테스트 결과가 실제 환경에서의 안정성을 보장하지 않는다는 첫 번째 신호입니다.

원인은 트리거 구문과 토픽 정의

에이전트는 트리거 구문과 토픽 정의에 의존해 어떤 응답을 보낼지 판단합니다. 예제가 모두 비슷하면 유연성이 떨어지고, 유의어 하나에도 혼란에 빠질 수 있습니다. 해결책은 단순합니다. 정책 문서의 공식 문구만 쓰지 말고, 사람들이 실제로 쓰는 일상적이고 축약된 표현까지 트리거 구문에 넣으세요. 수십 개가 필요하지는 않습니다. 눈에 띄는 변형만 커버하고 다시 테스트하면 됩니다.

채널마다 달라지는 동작: Teams, SharePoint, 데모 웹사이트

스튜디오의 테스트 창은 어디까지나 시뮬레이션입니다. Teams, SharePoint, 데모 웹사이트에 게시하면 플랫폼에 따라 입력 텍스트 처리와 응답 렌더링이 달라질 수 있습니다. Teams는 줄 바꿈을 다르게 처리할 수 있고, 웹페이지는 서식을 제거할 수 있습니다. 핵심 구문이 다른 줄로 밀리는 작은 변화도 모델이 가중치를 두는 방식에 영향을 줄 수 있습니다. 그래서 Microsoft도 채널 전반에 걸친 반복 테스트를 강조합니다.

예를 들어 스튜디오에서 "비용 한도가 얼마인가요?"라고 물으면 "숙박비는 하루 200달러입니다"라고 바로 답한다고 해봅시다. 배포 후 "호텔 비용으로 얼마까지 받을 수 있나요?"라고 물었더니 정책을 인용하지 않고 인사팀에 문의하라는 모호한 답이 돌아올 수 있습니다. 의도는 같아도 결과는 다릅니다.

사용자는 인텐트나 트리거를 생각하지 않고, 동료에게 말하듯 질문을 바꿔 말할 뿐입니다. 데모 중에 이런 실수가 한 번만 나와도 신뢰는 흔들립니다. 스튜디오는 연습용 스파링 파트너로 생각하세요. 학습에는 유용하지만 준비가 끝났다는 증거는 아닙니다.

그라운딩: 에이전트를 수정 구슬이 아닌 규칙서 위에 세우기

초보자의 첫 번째 실수는 에이전트를 실제 지식 없이 시작하는 것입니다. 준비 없이 신입 인턴을 이사회에 내보내는 것과 같습니다. 말은 빠르고 자신감 있게 들리지만, 누군가 확인하는 순간 절반은 무너집니다. 근거가 없으면 시스템은 사실이 아니라 패턴을 끌어다 씁니다.

환각의 위험

가장 나쁜 결과는 부실한 답이 아니라 환각입니다. 환각은 봇이 사실처럼 보이지만 근거 없는 내용을 지어내는 현상입니다. 출장비 환급을 물으면 정중히 거절하는 대신 그럴듯한 숫자를 만들어냅니다. 직원이 그 답을 믿고 호텔을 예약하면 비용 분쟁과 항의 메일을 수습해야 합니다.

공식 실습 과정의 사례가 이를 잘 보여줍니다. 업로드하는 Expenses Policy.docx에는 숙박비 한도가 1박당 200달러로 명시되어 있습니다. 그라운딩을 건너뛰고 "호텔 규정이 뭐야?"라고 물으면 1박당 100달러라고 자신 있게 답할 수도 있습니다. 파일을 연결하면 "회사 출장 규정에 따르면 숙박비는 1박당 200달러로 제한됩니다"처럼 문서를 인용합니다. 날조와 인용의 차이가 바로 그라운딩입니다.

지식 소스 추가 방법

1. Copilot Studio에서 해당 에이전트로 이동합니다.
2. 개요 화면에서 지식(Knowledge)을 클릭합니다.
3. 지식 추가를 선택한 뒤 파일 업로드를 고르고 신뢰할 수 있는 문서를 지정합니다.

공개 웹사이트나 SharePoint 위치를 연결할 수도 있지만, 파일이 훨씬 깔끔합니다. 업로드 후에는 인덱싱을 기다려야 하며 몇 분, 길게는 10분 안팎이 걸릴 수 있습니다. 바로 결과가 나오지 않아도 당황하지 말고, 인덱싱이 끝난 뒤 질문을 다시 실행하세요. 제대로 설정되었다면 업로드한 문서에서 가져왔다는 작은 인용 표시와 함께 200달러라는 정확한 답이 나옵니다. 이 인용 표시가 올바르게 설정되었다는 증거입니다.

대화형 부스팅에 대한 오해

대화형 부스팅(conversational boosting)이 부족한 부분을 마법처럼 채워 줄 것이라는 믿음은 오해입니다. 부스팅은 정책에 대한 이해를 새로 만들지 않고 텍스트 패턴을 강화할 뿐입니다. 지식 베이스에서 일치하는 내용을 찾지 못하면 모델에 내장된 일반 지식으로 대체되어 모호하거나 부정확한 답이 나올 수 있습니다. 규정 준수, 재무, 인사처럼 정확성이 중요한 주제는 추가한 소스에서만 검색하도록 구성하세요.

직원 5명이 모두 잘못된 요율로 비용을 청구했다면 재무팀에 어떻게 설명하겠습니까? 나중에 수습하는 비용은 처음부터 문서를 업로드하는 비용보다 훨씬 큽니다.

페르소나 설정: 이름, 설명, 지침으로 신뢰 만들기

정확하더라도 개성이 없으면 사용자는 떠납니다. Copilot Studio에서는 개성이 저절로 생기지 않으므로 직접 작성해야 합니다. 개요 페이지의 이름, 설명, 지침 필드를 비워 두면 기본 스타일의 무미건조한 안내자만 남습니다. 인사나 재무 같은 환경에서는 이런 평범한 어조가 "아직 프로토타입을 테스트하는 중"이라는 인상을 줍니다. 첫 만남에서 사용자를 잃으면 다시 돌아오는 일은 드뭅니다.

전체 설정을 캐릭터 시트처럼 생각해 보세요. 이름은 직업, 설명은 배경 이야기, 지침 입력란은 능력치, 어조는 성향입니다.

필드별 가이드

• 이름: 최대 30자이므로 짧고 명확하게 씁니다. 경비정책 전문가, 여행 가이드, 혜택 도우미 같은 이름이 예입니다.
• 설명: 약 1,000자까지 가능합니다. 예를 들어 "직원들에게 공식 여행 정책에 따른 최신 답변을 제공하고, 관련 구절을 인용하며 추측성 답변은 피합니다"처럼 몇 문장이면 충분합니다.
• 지침: 최대 8,000자까지 쓸 수 있는 핵심 공간입니다. "친절하게 대화하라"에서 그치지 말고 "가능할 때는 항상 정책 내용을 인용한다", "추측성 답변은 피한다", "임원을 위해 한 문장으로 요약한 뒤 근거를 제시한다"처럼 구체적인 규칙을 적습니다.

체크리스트로 정리하면 다음과 같습니다. 역할을 지정하고, 전문 분야를 짧게 설명하고, 어조(격식 있는, 캐주얼한, 비전문가도 이해하기 쉬운)를 정하고, 지침에 포함할 것·피할 것·형식 지정 방식을 채웁니다. 어조는 "격식 있고 전문적인", "기술적 배경이 없는 직원을 위한 캐주얼하고 이해하기 쉬운" 같은 문구로 명시적으로 유도할 수 있고, 지침에 예시를 직접 넣어도 됩니다.

5분 안에 끝나는 두 가지 개선

첫째, 대화 시작 주제(소개 메시지)를 수정하세요. 기본 환영 인사를 "여행 정책을 이해하도록 돕고, 가능한 경우 공식 문서를 인용하겠습니다"처럼 역할에 맞는 문구로 바꾸고, 대화를 새로 고침해 확인합니다. 둘째, 에이전트 아이콘을 교체하세요. 30KB 미만, 최대 192x192 픽셀의 PNG 파일을 지원합니다. 이런 작업을 선택적 보완이 아니라 기본적인 방어구로 생각하면 좋습니다. 역할을 밝힌 소개 문구는 사용자가 적절한 질문을 하도록 이끌고, 어조 규칙은 장황한 답변을 줄여 줍니다.

실시간 디버깅: 재현, 수정, 재실행 루프

실시간 디버깅은 실수를 티켓이 아닌 교훈으로 바꾸는 과정입니다. 순서는 확인, 격리, 수정, 재테스트입니다.

1. 재현: 실패한 사용자 질문을 테스트 창에 사용자가 입력할 문장 그대로 넣습니다.
2. 초기화: 새로 고침 아이콘이나 새 채팅으로 대화를 초기화하고 깨끗한 상태에서 다시 시작합니다.
3. 토픽 확인: 토픽 창을 열어 어떤 토픽이 작동했는지 봅니다. 직접 만든 토픽이 아니라 시스템의 대화 강화(부스팅) 토픽이었다면 지식이 아닌 모델에 의존했다는 신호입니다.
4. 인덱싱 점검: 관련 파일이나 사이트가 업로드되고 인덱싱되었는지 확인합니다. 인덱스가 없으면 그라운딩도 없습니다.
5. 수정 후 재실행: 지침이나 토픽 콘텐츠를 고쳐 저장하고 똑같은 질의를 다시 실행합니다.

구조가 부족할 때: 새 토픽 만들기

때로는 어조가 아니라 구조가 문제입니다. 토픽 페이지에서 Copilot으로 설명만 입력해 토픽을 추가할 수 있습니다. "사용자가 비용 한도를 물으면 바로 답한다"처럼 필요한 내용을 적고 추가를 누르면, 시스템이 그 설명을 바탕으로 토픽 노드 트리를 만들어 줍니다. 봇이 같은 질문을 계속 회피할 때 유용합니다.

어조 A/B 테스트와 그라운딩 체크

10분 정도 어조 A/B 테스트도 해볼 수 있습니다. 지침에 격식 있는 어조의 A버전을 쓰고 저장한 뒤 "출장 경비 한도가 얼마인가요?"라고 물어 답을 기록합니다. 이어서 "규정을 인용하며 간단하고 친근하게 설명하는 인사 담당자" 페르소나의 B버전으로 바꿔 같은 질문을 실행하고 비교합니다. 추측이 아닌 증거로 어조를 정할 수 있습니다.

테스터가 "호텔 비용은 얼마까지 청구할 수 있나요?"라고 물었는데 "인사팀에 확인하세요"라는 모호한 답이 나왔다면, 이는 완전한 실패가 아니라 피드백입니다. Expenses Policy 파일이 아직 인덱싱되지 않았거나, 트리거 구문에 "호텔"이 빠져 있을 수 있습니다. 지식 탭에서 파일 상태를 확인하고 여행 토픽의 트리거 구문에 "호텔 비용"을 추가한 뒤 다시 실행하세요. "정책에 따르면 숙박비는 1박당 200달러로 제한됩니다"라는 답이 나오면 해결된 것입니다.

개요 페이지에는 추천 질문(대화 시작 문구)도 3~5개 미리 채워 두세요. "호텔 비용 한도는 얼마인가요?", "출장비 청구는 어떻게 하나요?", "어떤 식비가 환급되나요?" 같은 질문입니다. 사용자는 빈 입력창 앞에서 망설이지 않고, 여러분은 실제 경로를 더 빨리 테스트할 수 있습니다.

게시 전 체크리스트와 채널별 재테스트

게시는 단순히 버튼 한 번으로 끝나지 않습니다. 누가 에이전트에 접근하는지, 어떻게 접속하는지, 응답이 실제 환경에서 어떻게 보이는지를 정하는 과정입니다. 스튜디오에서 "숙박비는 하루 200달러입니다"라고 깔끔하게 나오던 답이 Teams에서는 이해하지 못했다는 반응으로 바뀔 수 있습니다. Teams가 텍스트를 감싸고 메타데이터를 전달하는 방식 때문입니다. SharePoint는 줄간격 처리가 독자적이고, 데모 웹사이트는 가장 단순하지만 스튜디오와 다르게 서식을 렌더링할 수 있습니다. 채널마다 따로 테스트해야 합니다.

게시 체크리스트

1. 지식 파일이 완전히 인덱싱되었는지 확인합니다. 방금 업로드했다면 아직 실시간 답변 준비가 안 됐을 수 있습니다.
2. 인증을 설정합니다. 폭넓은 데모라면 "인증 없음"을 선택해 링크가 있는 누구나 사용해 볼 수 있게 합니다.
3. 게시를 누른 뒤 채널 페이지에서 녹색 확인 배너나 상태 업데이트를 확인합니다.
4. 데모 웹사이트 채널 설정에서 환영 메시지와 대화 시작 문구를 업데이트합니다.
5. 클로즈드 파일럿을 실행합니다. 전체 테넌트에 바로 공개하지 말고 명확한 지침을 가진 소규모 그룹과 먼저 진행합니다.

파일럿 그룹에는 자신이 테스트 팀임을 알리고, 일상적인 언어와 오타를 섞어 쓰고, 적절한 경우 파일도 업로드해 보도록 요청하세요. 그들의 실수가 취약점을 드러내는 단서가 됩니다. 스튜디오에서 테스트한 공식 표현, 일상적 표현, 오타, 출처 기반 인용을 각 채널에서 그대로 다시 실행해야 합니다. Teams에서 렌더링이 달라지는지, SharePoint에서 간격이 깨지는지, 웹 데모에서도 출처 인용이 표시되는지 확인하세요.

게시 이후: 모니터링과 지속적인 개선

게시는 끝이 아니라 시작입니다. Teams나 데모 웹사이트에 배포되면 사용량 데이터가 쌓이기 시작합니다. Power Platform 관리 센터와 내장 분석 도구로 사용량, 오류 횟수, 어떤 대화가 토픽을 트리거하지 못했는지까지 확인할 수 있습니다. 이는 부가 작업이 아니라 모니터링 시스템입니다. 게시하고 잊어버리지 말고, 에이전트가 올바르게 쓰이는지, 새로운 지원 요청을 유발하지 않는지 로그를 지켜보세요.

이 단계를 서두르면 위험합니다. 무작정 전 부서에 배포했다가 Teams에서 핵심 응답이 누락되어 지원 요청이 쏟아질 수 있고, 한번 떠난 사용자의 마음을 돌리는 데는 문제를 고치는 것보다 더 많은 시간이 듭니다. 반대로 게시 단계를 또 하나의 테스트 단계로 다루면, 색인 완료, 인증 설정, 게시 확인, 데모 사이트 조정, 파일럿 실행을 거쳐 본격 확장 때는 이미 스트레스 테스트를 통과한 상태가 됩니다. Copilot Studio 에이전트는 한 번 만들고 끝나는 결과물이 아니라 계속 조정해 가는 시스템입니다.

초보자가 자주 하는 실수 요약

• 테스트 창의 깔끔한 결과만 믿고 변형 질문(일상 표현, 오타)을 테스트하지 않는 것
• 트리거 구문을 공식 문구로만 채워 유의어에 취약한 토픽을 만드는 것
• 지식 소스 없이 에이전트를 시작해 환각을 방치하는 것
• 대화형 부스팅이 부족한 지식을 채워 줄 것이라고 믿는 것
• 이름, 설명, 지침, 소개 메시지, 아이콘을 기본값으로 두는 것
• 실패한 응답을 재현하고 수정하는 루프 없이 다음번에는 잘되기를 바라는 것
• 한 채널에서만 테스트하고 전체 테넌트에 바로 공개하는 것

실무 적용 핵심 정리

• 그라운딩: 실제 정책 문서를 업로드하거나 신뢰할 수 있는 소스를 연결하고, 인덱싱 완료 후 인용 표시를 확인합니다.
• 중요 주제(규정 준수, 재무, 인사)는 추가한 소스에서만 답하도록 구성합니다.
• 페르소나: 목적이 드러나는 이름(30자), 짧은 설명, 어조, 구체적인 행동 규칙을 담은 지침(최대 8,000자)을 작성합니다.
• 대화 시작 인사말과 추천 질문 3~5개, 간단한 아이콘으로 첫인상을 정리합니다.
• 디버깅: 재현, 초기화, 토픽 확인, 인덱싱 점검, 수정 후 재실행을 반복합니다.
• 트리거 구문에 일상적인 표현을 추가하고 세 가지 변형 질문으로 다시 테스트합니다.
• 게시: 인덱싱, 인증, 게시 확인, 데모 사이트 설정을 점검한 뒤 클로즈드 파일럿부터 시작합니다.
• Teams, SharePoint, 데모 웹사이트 각 채널에서 핵심 질문을 다시 실행하고, 게시 후에는 분석 데이터로 모니터링합니다.

결론

불안정한 빌드를 신뢰할 수 있는 에이전트로 바꾸는 요소는 세 가지입니다. 실제 문서로 기반을 다지는 그라운딩, 이름·설명·어조·지침으로 정체성을 부여하는 페르소나, 그리고 테스트 창의 리허설 결과에 안주하지 않고 파일럿과 모니터링으로 검증하는 습관입니다. 이 과정을 반복하면 에이전트는 추측에 의존하는 도박 같은 존재에서 믿을 수 있는 팀원으로 한 걸음씩 다가갑니다. 문의 티켓이 아니라 신뢰를 쌓는 에이전트를 만들고 싶다면, 먼저 근거가 될 정책 문서 하나를 정해 업로드하는 것부터 시작하세요.