Copilot Studio 에이전트를 위한 ALM: 기초

원문: ALM for Copilot Studio Agents: The Foundation 게시일: 2026-05-20 · 저자: James Papadimitriou

왜 중요한가

Copilot Studio를 사용하면 아이디어에서 동작하는 에이전트까지 놀랍도록 빠르게 갈 수 있어요. 그 속도는 이 플랫폼의 가장 큰 강점 중 하나이지만, 동시에 누군가 안전하게 변경하는 방법을 고민하기도 전에 에이전트가 실제 사용자 앞에 놓일 수 있다는 뜻이기도 해요. 사람들이 이미 사용 중인 버전 1을 깨뜨리지 않으면서 버전 2 작업을 하고 싶어지는 순간, 프로덕션이 아닌 곳에서 변경할 수 있는 장소와, 그 변경을 앞으로 옮길 신뢰할 수 있는 방법이 필요해져요.

바로 그것을 애플리케이션 수명 주기 관리(Application Lifecycle Management, ALM)가 제공해요. 이 글은 기초를 다뤄요. 에이전트가 본인 이외의 누군가에게 중요해지기 전에 모든 메이커가 갖추어야 할 안전한 기준선 말이죠. 의도적으로 모든 것을 다루지는 않아요. Power Platform 배경이 없는 사람들을 위해 설명한, 문제를 피하게 해 주는 결정들의 집합이에요.

참고: 이 글은 짧은 시리즈의 첫 번째 글이에요. 목표는 모든 고급 패턴이 아니라 안전한 기준선이에요. 이후 글들에서 곧 발표될 어젠다와 함께 더 깊이 들어가요.

환경부터 시작하기

모든 ALM 전략의 기초는 환경 격리예요. Power Platform에서 가장 검증된 패턴은 세 개의 환경이에요: Development(개발), Test(테스트), Production(프로덕션). Dev는 메이커가 작성하는 곳이에요. Test는 검증하는 곳이에요. Production은 사용자가 라이브 에이전트와 상호작용하는 곳이에요. 변경은 한 방향으로만 흘러요 — Dev에서 Test로, Test에서 Prod로. 이것이 프로덕션을 안정적이고 예측 가능하게 유지하는 방법이에요.

플랫폼이 처음이라면 환경이 실제로 무엇인지 이해하기 위해 Power Platform 환경 개요부터 시작하세요. 환경은 Power Platform 관리 센터에서 만들며, 그 부분은 간단해요.

이 3개 환경 모델은 플랫폼이 강제하는 필수 요구 사항이 아니에요. 일회성 개념 증명(PoC)이라면 환경 하나로 충분해요. 하지만 현재 버전이 사용자를 계속 서비스하는 동안 다음 버전의 에이전트를 만들고 싶어지는 순간, 분리가 그 값어치를 해요. 분리가 없으면 여러분이 하는 모든 편집이 프로덕션에 대한 편집이에요.

팁: 시리즈 후반에 다룰 내용: Dev/Test/Prod가 자리 잡으면, 성숙한 에이전트들은 플랫폼 회귀(regression)를 프로덕션에 도달하기 전에 잡아내기 위해 조기 릴리스 링의 프리뷰 환경과, 진행 중인 작업을 방해하지 않는 긴급 핫픽스를 위한 프로덕션 정렬 환경을 추가하는 경우가 많아요. 이는 기초가 아니라 회복력 패턴이므로 별도의 글에서 다뤄요.

환경	무엇이 있는가	이유
Dev	관리되지 않는 솔루션 (진행 중인 작업)	일상적인 작성
Test	관리형 솔루션	검증, UAT¹
Production	관리형 솔루션	라이브 사용자

여기서 시작하세요. 실제 문제가 요구할 때만 환경을 추가하세요.

솔루션: 배포의 단위

환경이 에이전트가 사는 곳이라면, **솔루션(solution)**은 에이전트가 환경 사이를 이동하는 방법이에요. 솔루션은 에이전트가 의존하는 모든 컴포넌트를 담아 전체 집합을 하나의 단위로 이동 가능하게 만드는 컨테이너예요.

소프트웨어 개발에서 왔다면, 솔루션은 개념적으로 프로젝트나 패키지와 비슷해요. 관련 자산을 그룹화하여 하나의 일관된 아티팩트로 버전 관리하고, 내보내고, 가져올 수 있게 해요. 전체 모델은 Power Platform ALM의 솔루션 개념을 읽어 보세요.

먼저 게시자를 만드세요

솔루션을 만들기 전에 커스텀 접두사를 가진 **커스텀 게시자(publisher)**를 만드세요. 형식적인 절차가 아니라 진짜 모범 사례예요. 게시자의 접두사(예: contoso_)는 여러분이 만드는 모든 것의 스키마 이름에 찍히므로 컴포넌트를 명확하게 식별할 수 있고 일반적인 기본 게시자를 피할 수 있어요. 접두사는 한 번 설정하면 컴포넌트를 평생 따라다니므로 신중하게 할 가치가 있어요. 솔루션 게시자 만들기를 참고하세요.

솔루션 안에 무엇이 들어가나

에이전트가 의존하는 모든 것은 하나의 솔루션 안에 있어야 해요. 실질적으로 이는 Copilot Studio 메이커 경험에서 보이는 에이전트와 그 컴포넌트를 의미해요.

토픽 - 대화 로직
도구 - 에이전트가 호출할 수 있는 작업
지식 소스 - 에이전트가 답변의 근거로 삼는 콘텐츠

이와 함께 몇 가지 Power Platform 컴포넌트가 일반적으로 에이전트와 함께 이동해요.

커스텀 커넥터 - 에이전트나 흐름이 호출하는 자체 API 정의
연결 참조(connection references) - 연결을 가리키는 솔루션 인식 포인터. 실제 자격 증명은 하드코딩되지 않고 환경별로 바인딩돼요
환경 변수 - 환경마다 다른 구성 값 (아래에서 자세히)
워크플로 - 에이전트를 대신해 로직을 실행하는 Power Automate 흐름

솔루션 밖에서 만들어진 것은 배포 파이프라인에 보이지 않으며 깔끔하게 승격할 수 없어요. 이것이 팀이 초기에 저지르는 가장 흔한 실수예요. 기본 솔루션에서 컴포넌트를 만들고 나서야 옮길 수 없다는 것을 발견하는 것이죠. 솔루션을 먼저 만들고 모든 것을 그 안에서 작성하여 이 실수를 피하세요. 솔루션에서 에이전트를 작성하는 방법을 참고하세요.

관리형 vs 비관리형

솔루션은 두 가지 형태로 존재해요.

유형	어디에 있나	무엇을 하나
비관리형(Unmanaged)	Development	작성하는 동안 컴포넌트를 자유롭게 추가, 편집, 제거
관리형(Managed)	Test, Production	배포 가능한 아티팩트 - 가져오는 것이지 작성하는 것이 아님

Dev에서는 에이전트, 워크플로, 변수 같은 컴포넌트가 비관리형 솔루션 안에 있고 메이커가 자유롭게 편집해요. 솔루션은 버전이 매겨진 관리형 패키지로 내보내져 Test, 그다음 Production에 배포되며, 관리형 솔루션으로 도착해요. 변경은 한 방향으로만 흘러요: Dev에서 패키지를 거쳐 다운스트림 환경으로.

에이전트를 앞으로 옮기는 모범 사례는 Dev에서 관리형 패키지로 내보내고 그것을 Test, 나중에 Production으로 가져오는 것이에요. 관리형 솔루션은 읽기 전용 배포 아티팩트로 의도되었어요. 변경이 필요하면 Dev에서 수정하고, 다시 내보내고, 다시 배포해요.

주의: 관리형 솔루션이 진짜로 봉인된 것은 아니에요. 대상 환경에서 여전히 관리형 컴포넌트 위에 비관리형 계층을 만들어 그 자리에서 재정의할 수 있어요. 가능하기는 하지만, 최악의 ALM 혼란의 근원이에요. 그 로컬 편집은 다음 배포에서 조용히 덮어써지기 때문이에요. 두 가지가 여러분을 안전하게 지켜줘요.

Test와 Production에서 비관리형 사용자 지정 차단 환경 설정을 켜기

애초에 아무도 거기서 편집하지 않도록 해당 환경에서 메이커/관리자 접근 권한 제거하기

(차단 설정이 흐름 켜기/끄기 같은 몇몇 작업은 여전히 허용하므로 접근 위생도 중요해요.)

기본 솔루션으로 설정하기

에이전트 자산을 만들기 전에 Dev에서 솔루션을 만들고, 기본 설정 솔루션(preferred solution)으로 설정하세요. 그러면 새 컴포넌트가 잊혀지기 쉬운 기본 솔루션에 떠다니는 대신 자동으로 여러분의 솔루션에 들어가요.

파이프라인: 솔루션을 안전하게 옮기기

환경이 갖춰지고 솔루션이 에이전트의 모든 자산을 담고 있다면, 다음 질문은 이것이에요. 솔루션이 실제로 어떻게 Dev에서 Test로, Prod로 이동하나요?

수동으로 할 수도 있어요 — Dev에서 .zip을 내보내고, Test로 가져오고, Prod에 반복하는 거죠. 동작은 하지만 오류가 나기 쉽고, 무엇이 언제 누구에 의해 배포되었는지 기록이 남지 않아요.

Power Platform 파이프라인이 이를 해결해요. 파이프라인은 환경을 순서대로 연결하는 사전 구성된 승격 경로예요. 승격이 단일 작업이 돼요. 솔루션 선택, 다음 단계 선택, 배포. 중요한 점은 Test에 배포된 것과 동일한 솔루션 버전이 Production으로 승격된다는 것이에요 — 파이프라인은 Dev에서 다시 내보내는 대신 정확히 그 아티팩트를 앞으로 날라요.

Dev의 솔루션이 관리형 패키지로 내보내져 파이프라인에 공급되고, 파이프라인은 이를 Test, 그다음 Prod에 배포해요. 파이프라인은 배포 중에 환경별 구성을 해결하고 각 배포를 히스토리에 기록해요.

배포는 또한 구성이 대상 환경에 바인딩되는 지점이에요. 파이프라인 배포 중에 환경마다 다른 값을 제공할 수 있어요.

도구, 커스텀 커넥터, MCP 서버, 워크플로를 위한 연결(Connections) - 연결 참조를 통해 매핑되어 각 환경이 자체 자격 증명 사용
대상 환경을 위한 환경 변수 값

파이프라인이 주는 것:

반복 가능성 - 매번 동일한 프로세스, 잊어버릴 수동 단계 없음
감사 추적 - 누가, 무엇을, 언제, 어느 환경에 배포했는지
버전 가시성 - 배포 히스토리가 각 환경에 정확히 어떤 버전이 있는지 보여줌
가드레일 - 배포가 다음 단계로 진행되기 전에 승인 요구 가능

주의: 배포 히스토리는 버전에 대한 가시성을 주지만, 원클릭 롤백이 아니에요. 관리형 솔루션을 제거하면 에이전트를 포함한 그 컴포넌트가 제거돼요. “롤백”은 보통 이전 관리형 버전을 배포하거나 환경 백업을 복원하는 것을 의미하므로, 단순히 되돌릴 수 있다고 가정하지 말고 미리 계획하세요.

설정 세부 사항은 Power Platform에서 파이프라인 설정을 참고하세요.

구성: 환경 변수

원칙은 간단해요. 환경 특정적인 것은 아무것도 하드코딩하지 않아요. API 엔드포인트, SharePoint URL, 임곗값, 기능 플래그 — 모두 환경 변수에 넣어요.

환경 변수는 두 부분으로 되어 있어요.

정의(Definition) - 스키마 (이름, 데이터 유형, 설명). 항상 솔루션과 함께 이동해요.
값(Value) - 특정 환경의 실제 내용.

기본적으로는 값을 솔루션 밖에 두어 각 환경이 자체 값을 제공하도록 하는데, 진짜로 환경 특정적인 것(Test 엔드포인트가 Prod로 나가면 안 되죠)에는 그것이 올바른 선택이에요. 하지만 강제는 아니에요. 값을 솔루션에 포함시켜 함께 이동하게 선택할 수도 있어요. 어떻게 할지는 사용 사례에 따라 달라요 — 어디서나 동일한 기본값이라면 포함하기 좋은 후보예요.

값은 솔루션이 도착하기 전이 아니라 배포 시점에 제공돼요. 이 순서가 중요해요. 정의가 아직 존재하지 않는 변수에 값을 설정할 수 없고, 정의는 솔루션을 가져올 때 나타나요. 그래서 파이프라인은 배포 중에 값을 물어요(또는 무인 시나리오에서는 배포 설정 파일에서 읽어요). 첫 배포에서는 정의가 솔루션과 함께 도착하고, 이후 업그레이드에서는 정의가 이미 있으므로 값을 대상에 미리 구성해 둘 수 있어요.

팁: 비밀(Secrets) — API 키, 토큰, 자격 증명 — 은 비밀 환경 변수를 통해 참조되는 Azure Key Vault에 속해요. 에이전트는 비밀을 이름으로 참조하고 플랫폼이 런타임에 해결하므로, 키를 교체하려면 Key Vault를 업데이트하면 되고 재배포는 필요 없어요. 파이프라인은 환경별로 참조를 매핑할 뿐, 비밀 값 자체를 저장하지 않아요.

참고: 시리즈 후반에 다룰 내용: 완전 무인 CI/CD²(Azure DevOps 또는 GitHub Actions)에서는 값이 pac solution으로 생성한 배포 설정 파일에서 와요. 그 메커니즘과 더 넓은 연결 참조 이야기는 구성에 초점을 맞춘 별도 글에서 다뤄요.

동작하는지 알기: 평가

올바르게 배포되었다고 올바르게 동작한다는 보장은 없어요. 평가(evaluation)는 에이전트가 올바른 도구를 선택하고 수용 가능한 응답을 생성하는지 측정하는, 정의된 테스트 입력과 기대 출력의 집합이에요. 이것을 품질 게이트로 취급하세요. 내보내기 전에 Dev에서 평가를 실행하고, 가져온 후 대상에서 다시 실행하여 배포가 깨끗하게 완료되었는지 확인해요.

수작업으로 할 필요는 없어요. 에이전틱 개선 루프는 품질을 반복 개선하는 방법을 보여주고, Azure DevOps의 자동화된 평가는 품질이 떨어질 때 변경을 차단하는 강제 게이트로 평가를 바꾸는 방법을 보여줘요. 평가를 승격 흐름에 연결하는 것은 이 시리즈의 자동화 편에서 다뤄요.

승격 전 체크리스트

커스텀 게시자와 접두사가 준비됨
모든 에이전트 자산이 하나의 솔루션 안에 있음
해당 솔루션이 Dev에서 기본 설정 솔루션으로 지정됨
환경 특정 값이 하드코딩되지 않음 - 환경 변수에 있음
비밀은 Key Vault에 있고 비밀 환경 변수로 참조됨
Test와 Production이 비관리형 사용자 지정을 차단하고 메이커/관리자 접근이 제거됨
올바른 단계 순서로 파이프라인이 구성됨
솔루션이 Test와 Prod용으로 관리형으로 내보내짐
내보내기 전 Dev에서, 가져온 후 대상에서 평가 통과

보상

기초가 갖춰지면 에이전트를 앞으로 옮기는 것은 파이프라인 작업 한 번이에요. 아무도 직접 편집하지 않기 때문에 프로덕션은 안정적으로 유지돼요. 구성은 올바른 환경에 자동으로 바인딩돼요. 비밀은 재배포 없이 교체돼요. 그리고 어디에 정확히 어떤 버전이 실행 중인지 항상 알 수 있어요.

그것이 기준선이에요. 이것을 탄탄히 하면, 이 시리즈의 나머지에서 다룰 고급 패턴들 — 조기 릴리스 검증, 핫픽스 환경, 소스 제어, 자동화된 품질 게이트 — 이 의지할 수 있는 든든한 토대가 생겨요.

여러분의 ALM 설정은 지금 어떤 모습인가요? 그리고 기초의 어느 부분에서 처음 문제를 겪으셨나요? 댓글로 알려주세요.

어휘 주석

UAT(User Acceptance Testing): 실제 업무 담당자나 사용자가 배포 전 마지막 단계에서 직접 써보며 요구사항대로 동작하는지 확인하는 검수 테스트.
CI/CD(Continuous Integration/Continuous Deployment): 코드나 구성 변경을 사람 손을 거치지 않고 자동으로 검증·빌드하고, 정해진 환경까지 자동으로 배포하는 방식.