LLM에게 계산을 시키지 마세요 — Copilot Studio 에이전트 샌드박스가 하는 일

The New Copilot Studio Agent Sandbox

대형 언어 모델에게 직접 시키지 말아야 할 일이 크게 두 가지 있습니다. 계산, 그리고 크고 정확한 산출물 생성(값이 채워진 스프레드시트, 유효한 .docx, 긴 JSON 문서)입니다.

이유는 단순합니다. 모델은 그럴듯한 결과를 예측할 뿐, 계산하지 않습니다. 모델이 돌려준 숫자가 실제 합계라는 보장이 없고, 모델이 뱉어낸 파일이 유효하다는 보장도 없습니다.

반대로 언어 모델이 정말 잘하는 일은 그런 작업을 수행하는 코드를 쓰는 것입니다. 파이썬 몇 줄이면 열의 합계를 정확히 구하고, 파일을 바이트 단위로 매번 똑같이 만들어 냅니다. 다만 코드는 실행할 무언가가 있을 때만 유용합니다. Microsoft Copilot Studio Customer Advisory Team(CAT) 블로그의 이번 글은 그 실행 환경, 즉 에이전트 샌드박스를 다룹니다.


왜 에이전트에게 샌드박스를 주는가

GitHub Copilot CLI 같은 코딩 에이전트를 로컬에서 써 보셨다면 개념은 익숙할 것입니다. 에이전트가 터미널에서 일합니다. 파일을 살펴보고, 코드를 쓰고, 실행하고, 출력을 읽고, 고치고, 다시 시도합니다.

Copilot Studio 샌드박스는 머신을 직접 프로비저닝하고 관리하지 않아도 그런 작업 환경을 제공합니다. 구성은 다음과 같습니다.

  • Python 런타임
  • 로컬 파일
  • 사전 설치된 라이브러리
  • 셸 도구

이 모든 것이 Copilot Studio가 관리하는 컨테이너 안에 있습니다. 이 샌드박스는 GitHub Copilot harness로 구동되는 Copilot Studio 에이전트에서 제공됩니다.

harness 안에서의 위치

샌드박스는 더 넓은 에이전트 harness의 한 부분입니다.

구성요소 역할
Instructions 에이전트의 상시 행동 지침
Knowledge 근거 자료 검색·그라운딩
Skills 시나리오별 지침과 스크립트
Tools 커넥터·MCP 서버 등 외부 액션
Sandbox 위 요소들의 로컬 실행 가능한 부분을 수행

Instructions, Knowledge, Skills, Tools는 모델이 작업을 이해하고 행동하도록 돕고, 샌드박스는 그 스크립트들이 실제로 돌아갈 자리를 제공합니다.

Knowledge에도 샌드박스가 쓰인다

흥미로운 지점입니다. Copilot Studio는 자체 검색 파이프라인에도 샌드박스를 활용합니다. 에이전트가 Knowledge에서 파일을 검색하면 그 파일이 샌드박스에 내려앉고, 에이전트는 파일을 열어 Python으로 분석하고 결과를 차트로 그릴 수 있습니다.

샌드박스가 없다면 에이전트는 검색이 반환한 스니펫에만 갇힙니다. 파일 전체가 그 자리에 있으니 모든 행을 대상으로 작업할 수 있는 것입니다.


직접 해 볼 수 있는 데모

원문은 직접 재현 가능한 데모를 제시합니다.

  1. 매출 원본 데이터(CSV)를 준비합니다. 의도적으로 매출액(revenue) 열이 없어서, 합계를 조회하는 게 아니라 계산해야만 합니다.
  2. 에이전트를 하나 만들고 그 CSV를 Knowledge 파일로 추가합니다.
  3. 다음과 같이 요청합니다.
Generate a chart for the sales data showing revenue growth
per region per quarter

에이전트가 생성한 지역·분기별 매출 차트

결과는 538개 행에서 매출을 계산해 지역·분기별로 합산하고 차트까지 그린 산출물입니다. 주목할 점은 커스텀 Skill 없이, 새로 만든 Copilot Studio 에이전트만으로 이 작업이 완료되었다는 것입니다.


Skill로 반복 작업을 안정화하기

위 데모에서는 에이전트가 코드를 직접 작성했습니다. Skill은 그 코드를 미리 제공하는 방식입니다. 검토를 마친 스크립트와 그것을 사용하는 지침을 함께 담아, 특정 작업이 매번 동일하게 실행되도록 합니다.

CAT 블로그의 문서 레드라이닝 사례가 그 모습을 보여 줍니다. 샌드박스가 제공된 문서에 스크립트를 실행해 최종 Word 파일을 만들어 냅니다.

변경 내용 추적이 적용된 레드라이닝 Word 문서

진짜 Word 변경 내용 추적(tracked changes)이 적용된 .docx 파일이 샌드박스 안에서 만들어집니다. 에이전트는 이 파일을 사용자에게 돌려줄 수 있고, 추가 수정이 필요하면 샌드박스에서 다시 손볼 수 있습니다.


즉석 코드 vs 패키징된 스크립트

코드가 샌드박스에 도달하는 경로는 크게 두 가지입니다.

1. 작업을 위해 생성된 코드

모델이 Python을 작성하고, 실행하고, 결과를 확인하고, 수정합니다.

  • 적합한 경우: 새로운 유형의 작업. 낯선 형식의 내보내기 파일을 이해하거나, 새로 업로드된 파일을 어떻게 차트로 그릴지 탐색할 때
  • 트레이드오프: 코드를 쓰고 반복하는 데 시간이 걸리고, 실행할 때마다 구현이 달라질 수 있음

2. Skill에 패키징된 스크립트

미리 작성된 스크립트가 즉시 실행 준비된 상태로 존재합니다.

  • 적합한 경우: 반복 작업. 보통 더 빠르고 일관적
  • 장점: 팀이 다른 코드 자산처럼 테스트하고 버전 관리할 수 있음

중요: 메이커가 대화마다 이 두 경로 중 하나를 고르는 것이 아닙니다. 모델에게 좋은 선택지를 주면(명확한 설명이 붙은 Skill 포함) 런타임에 모델이 무엇을 쓸지 결정합니다.

실무 규칙

원문이 제시하는 규칙은 명료합니다.

  1. 새로운 작업에는 모델이 코드를 생성할 여지를 준다.
  2. 반복 작업에는 검토된 스크립트를 담은, 설명이 잘 붙은 Skill을 제공해 에이전트가 즉시 일관되게 실행하도록 한다.
  3. evals(평가)로 전체 에이전트가 의도대로 동작하는지 검증한다. CAT 블로그의 quality-gate 패턴이 이 검증을 자동화하는 한 가지 방법을 보여 줍니다.

패키징된 Skill은 에이전트와 함께 이동하며, 조직의 일반적인 애플리케이션 수명 주기 관리(ALM) 프로세스를 따릅니다.


샌드박스가 가능하게 하는 것들

샌드박스에는 문서, 스프레드시트, PDF, 데이터, 차트, 이미지를 다루는 라이브러리가 포함되어 있습니다. 정확한 패키지 이름보다 중요한 것은 이것들이 가능하게 하는 에이전틱 루프입니다.

파일 생성 → 명령 실행 → 결과 확인 → 접근 방식 조정 → 새 명령 실행 → 반복

이 루프 덕분에 에이전트는 다음과 같은 일을 할 수 있습니다.

  • 비례 배분 보너스 계산, 숫자 집합에 대한 what-if 분석, 수식 검증 — 모델의 머릿속이 아니라 코드로 산술 수행
  • 업로드된 스프레드시트를 정제된 통합 문서 + 계산된 요약 + 차트로 변환
  • 문서를 비교해 레드라인 Word 파일 반환
  • PDF에서 콘텐츠를 추출하고 검사 항목을 적용해 발견 사항 리포트 생성
  • 제공된 데이터를 프레젠테이션이나 다른 형식의 산출물로 변환

메이커 입장에서는 계산이나 파일 변환마다 별도 서비스를 구축할 필요가 사라집니다.


경계 1: 아웃바운드 네트워크가 없다

거버넌스 관점에서 가장 중요한 부분입니다.

샌드박스에는 아웃바운드 네트워크 경로가 없습니다. 거기서 실행되는 코드는 무엇을 import하든 API를 호출하거나, 메일을 보내거나, SharePoint에 파일을 쓸 수 없습니다.

예를 들어 Python의 requests 패키지가 설치되어 있지만, 그것으로 만든 어떤 것도 샌드박스를 벗어날 수 없습니다.

외부에 도달하는 방법은 메이커가 명시적으로 구성한 경로뿐입니다.

경로 용도
Knowledge 소스 근거 있는 정보 그라운딩
Tools (커넥터, MCP 서버) 실시간 데이터와 외부 액션

관리자에게는 바로 이 경계가 안심의 근거가 됩니다. 실행은 Copilot Studio가 관리하고, 나가는 길이 그 둘뿐이므로 에이전트가 외부에서 하는 모든 일이 조직의 거버넌스 통제와 데이터 정책(DLP) 안에 머뭅니다.


경계 2: 샌드박스는 임시 공간이다

샌드박스는 작업 공간이지 영구 저장소가 아닙니다.

레드라이닝 에이전트가 contract-redlined.docx를 만들었다면, 그 파일을 사용자에게 돌려주거나 구성된 Tool을 통해 어딘가 영속적인 곳에 저장해야 합니다.

⚠️ 다음 대화에서 샌드박스에 그 파일이 그대로 있을 것을 전제로 설계하지 마세요.

Agent Memory를 활성화하면 대화 간에 사실과 컨텍스트가 유지되지만, 파일은 저장하지 않습니다. 샌드박스 산출물을 남겨 두는 수단이 아닙니다.


샌드박스에 무엇이 들어 있는지 확인하는 법

에이전트를 만들 때 코드를 작성·실행하게 하려면, 또는 Skill에 담을 스크립트를 직접 쓰려면, 샌드박스에 이미 무엇이 설치되어 있는지 알아야 합니다.

가장 간단한 방법은 에이전트에게 직접 물어보는 것입니다. 어떤 런타임, 라이브러리, Tools, Skills에 접근할 수 있는지 질문하면 됩니다.

agent-harness-explorer Skill

반복 가능하고 상세한 인벤토리가 필요하다면 agent-harness-explorer Skill이 이 점검을 자동화하고 독립 실행형 HTML 리포트를 만들어 줍니다.

Agent Harness Capability Report 예시

원문에 따르면, 2026년 7월 21일 기준 아무것도 추가하지 않은 빈 Copilot Studio 에이전트에서 생성한 리포트는 다음과 같았습니다.

항목
런타임 Python 3.12.9 (컨테이너)
Python 라이브러리 99개
내장 도구(built-in tools) 11개
Skills 8개
MCP 서버 0개 (해당 에이전트에 구성 없음)

리포트 생성 절차

  1. cat-agent-skills 라이브러리에서 agent-harness-explorer 번들(zip) 다운로드
  2. Copilot Studio에서 GitHub Copilot harness를 사용하는 에이전트를 만들거나 엽니다
  3. Build 탭 우측 패널에서 “Skills +”를 클릭해 기존 Skill 추가
  4. zip 파일을 업로드하고 Skill이 로드될 때까지 대기
  5. Preview 탭을 엽니다
  6. 에이전트 채팅에 “Please inspect the harness” 입력 (harness/sandbox/environment 중 아무 표현이나 가능)
  7. 활동 추적(activity trace)을 검토해 리포트 생성에 사용된 도구와 스크립트를 확인
  8. “harness-inspection-report” HTML 리포트를 열어 검토

Agent Memory가 활성화되어 있다면 “Capture a snapshot”을 요청해 스냅샷을 저장하고 나중에 비교할 수 있습니다. 이 비교로 시간이 지나며 추가된 기능을 파악할 수 있습니다.


도입 담당자·메이커를 위한 체크포인트

1. “계산은 코드로”를 설계 원칙으로 삼으세요 숫자가 중요한 업무(정산, 비례 배분, 집계)에서는 모델이 답을 말하게 두지 말고 코드를 실행하도록 유도하는 지침을 넣으세요. 에이전트 신뢰도의 상당 부분이 여기서 갈립니다.

2. 반복 작업은 Skill로, 탐색 작업은 즉석 코드로 같은 산출물을 매번 만들어야 하는 업무는 검토된 스크립트를 Skill로 패키징하는 편이 속도와 일관성 면에서 유리합니다. 반대로 자유도가 필요한 분석은 모델이 코드를 쓰게 두는 편이 낫습니다.

3. 네트워크 격리를 보안 검토 자료로 활용하세요 “에이전트가 임의 코드를 실행한다”는 표현은 보안 부서를 긴장시키기 쉽습니다. 그러나 아웃바운드 네트워크가 없고, 외부 접점은 Knowledge와 Tools로만 한정되며, 그 경로는 DLP 정책의 적용을 받는다는 구조를 설명하면 검토가 훨씬 수월해집니다.

4. 산출물 영속화 경로를 반드시 설계하세요 샌드박스는 사라집니다. 만들어진 파일을 어디에 저장할지(사용자 반환 / SharePoint 커넥터 / OneDrive 등)를 에이전트 설계 단계에서 정해 두어야 합니다.

5. harness 인벤토리를 주기적으로 확인하세요 샌드박스 구성은 시간에 따라 바뀝니다. 스킬 스크립트가 특정 라이브러리에 의존한다면, agent-harness-explorer 리포트를 주기적으로 생성해 스냅샷을 비교하는 습관이 안전합니다.


마무리

샌드박스는 Copilot Studio 에이전트가 설명에서 멈추지 않고 검사하고, 계산하고, 만들고, 반복하게 해 주는 요소입니다.

정리하면 이렇습니다.

  • 계산은 모델의 머릿속이 아니라 코드에서 이뤄집니다
  • 파일은 실제 환경에서 만들어지고 검증됩니다
  • 한계도 명확합니다 — 밖으로 나가는 길은 메이커가 구성한 Knowledge와 Tools뿐이고, 대화가 끝나면 아무것도 남지 않습니다

에이전트가 “무엇을 아는가”만큼이나 “무엇을 실행할 수 있는가”가 중요해지는 시점입니다. Copilot Studio 에이전트가 이만큼 유능해진 지금, 다음 에이전트로 어떤 업무 문제를 풀어 볼지 고민해 볼 만합니다.


출처: The New Copilot Studio Agent Sandbox — MCSCAT Blog (The Custom Engine, Microsoft Copilot Studio Customer Advisory Team)

자세한 내용은 원문 참조.