먼저 답할 질문: 지금 바로 프로덕션에 써도 될까?
아직은 ‘누구나 같은 조건으로 쓸 수 있는 완성형 기능’으로 가정하면 안 된다. Microsoft는 Copilot Cowork의 /app 스킬을 Frontier 프로그램에서 제공하고, Copilot Studio의 앱 빌더는 공개 프리뷰로 순차 배포한다고 안내했다. 테넌트, 라이선스, 관리자 설정에 따라 실제 노출 범위가 달라질 수 있다.
따라서 첫 검토 문서는 기능 목록이 아니라 사용 가능 계정, 허용된 사용자 그룹, 사용할 데이터, 쓰기 작업, 승인자를 한 장에 적는 것이 좋다. 화면에 기능이 보인다는 사실만으로 운영 승인을 대신하지 않는다.
1. ‘앱 하나’가 해결할 결과를 한 문장으로 고정한다
Microsoft가 제시한 흐름은 원하는 결과, 사용자, 데이터, 행동을 자연어로 설명하는 데서 시작한다. 이때 ‘영업 앱 만들기’처럼 넓게 쓰면 성공 여부를 판정하기 어렵다. 예를 들어 ‘상담원이 승인된 계정의 갱신 예정일을 조회하고, 변경 요청 초안을 담당자에게 보내는 내부 앱’처럼 결과와 경계를 함께 적어야 한다.
- 사용자: 어떤 그룹만 접근하는가
- 읽기: 어떤 시스템의 어느 필드를 보는가
- 쓰기: 어디에 어떤 변경을 만드는가
- 완료 기준: 사람이 확인할 수 있는 결과는 무엇인가
첫 파일럿은 한 역할, 한 데이터 원천, 한 승인 흐름으로 제한하면 실패 원인을 분리하기 쉽다.
2. 커넥터는 ‘연결됨’이 아니라 읽기·쓰기 권한으로 나눈다
새 빌더는 커넥터와 Work IQ를 통해 조직 데이터를 읽고 결과를 다시 기록할 수 있다. 편리함이 커질수록 연결 계정이 실제로 할 수 있는 행동을 먼저 확인해야 한다. 고객 이름을 읽는 권한과 고객 상태를 바꾸는 권한은 같은 위험이 아니다.
테스트 표에는 커넥터별 계정, 읽는 데이터, 쓰는 데이터, 승인 단계, 보존 기간을 기록하자. 쓰기 권한은 기본적으로 끄고, 승인된 시나리오에서만 열어 두는 편이 안전하다. 서비스 계정을 쓴다면 최소 권한과 소유자, 만료일도 함께 정한다.
3. 생성된 화면보다 코드와 데이터 흐름을 검토한다
Microsoft 발표는 생성된 앱의 미리보기뿐 아니라 기반 코드도 살펴볼 수 있다고 설명한다. 보기 좋은 화면은 입력 검증, 오류 처리, 권한 누락을 증명하지 않는다. 프리뷰에서 정상 경로만 클릭하는 대신 잘못된 값, 빈 값, 권한 없는 계정, 연결 장애를 각각 시험해야 한다.
검토자는 입력이 어느 데이터 원천으로 이동하는지, 생성된 앱이 예상하지 못한 필드를 노출하지 않는지, 오류 때 일부 쓰기만 남지 않는지를 확인해야 한다. 민감정보가 포함되면 로그와 분석 데이터에 무엇이 남는지도 별도 항목으로 둔다.
4. 개발·시험·운영을 분리하고 되돌릴 버전을 정한다
Copilot Studio의 Git 기반 소스 관리, 배포 단계, 버전 분리는 변경을 추적하는 데 유용하다. 하지만 기능이 있다고 자동으로 안전해지는 것은 아니다. 개발 환경의 변경을 곧바로 운영에 반영하지 말고, 승인된 커밋과 배포 버전을 연결해야 한다.
- 개발 환경에서 초안을 만든다.
- 시험 계정과 비식별 데이터로 검증한다.
- 승인자가 변경 내역과 권한을 확인한다.
- 운영 버전을 지정하고 이전 안정 버전을 보존한다.
- 오류·비용·권한 이상이 발생하면 즉시 이전 버전으로 되돌린다.
롤백은 문서가 아니라 실제로 한 번 실행해 본 절차여야 한다.
5. 비용 측정은 운영 공개가 아니라 제작·시험부터 시작한다
Microsoft Learn은 에이전트를 만들고, 미리 보고, 시험하고, 평가하는 과정도 Copilot Credits를 사용할 수 있다고 안내한다. 사용량은 언어 모델 토큰뿐 아니라 도구, 지식 원천, MCP와 실행 구조에 따라 달라질 수 있다. 따라서 ‘사용자 1명당 월 비용’만으로 예산을 잡으면 실제 비용을 놓칠 수 있다.
| 측정 항목 | 파일럿 기록값 |
|---|
| 완료된 업무 1건당 크레딧 | 제작·시험·운영을 분리 |
| 재시도율 | 실패 원인과 함께 기록 |
| 외부 도구 호출 수 | 커넥터별 구분 |
| 사람 검토 시간 | 자동화 전 기준값과 비교 |
절감액은 관측 전에는 쓰지 않는다. 먼저 Power Platform 관리 센터에서 할당과 사용량을 확인하고, 7일 파일럿의 실제 완료 건수로 비용을 나눈다.
6. 관리자 통제는 DLP 하나로 끝내지 않는다
Microsoft는 Power Platform 데이터 정책을 통한 DLP, 게시 제한, 지역 간 데이터 이동 제어, Microsoft 365 관리 센터의 에이전트 관리 기능을 제공한다. Agent Registry에서는 작성자, 생성일, 호스트, 가용성 같은 정보를 확인하고 필요하면 차단할 수 있다.
실무 점검은 세 층으로 나누는 편이 낫다. 첫째, 누가 앱을 만들고 게시할 수 있는지 정한다. 둘째, 어떤 커넥터 조합과 데이터 이동을 허용할지 정한다. 셋째, 어떤 관리자가 인벤토리·청구·보안 이벤트를 주기적으로 검토할지 지정한다. Microsoft의 보안 문서는 Lockbox가 모든 아웃바운드 텔레메트리 흐름을 포괄하지 않는다는 제한도 밝히므로, 보안 기능의 이름만 보고 데이터 흐름 검토를 생략해서는 안 된다.
7. 통과 기준과 중단 기준을 같은 표에 둔다
파일럿은 ‘잘 작동했다’가 아니라 수치와 사건으로 평가해야 한다. 권장 최소 지표는 시나리오 완료율, 잘못된 쓰기 건수, 사람의 수정률, 승인까지 걸린 시간, 완료 업무 1건당 비용이다. 표본이 작으면 비율 옆에 분자와 분모를 함께 적는다.
중단 기준도 시작 전에 합의하자. 권한 없는 데이터 노출, 승인 없는 쓰기, 되돌릴 수 없는 변경, 예산 상한 초과, 책임자 부재 중 하나라도 발생하면 운영 확대를 멈춘다. 반대로 7일 동안 정한 시나리오가 안정적으로 끝나고 사람 검토 시간과 비용이 기준값보다 개선됐을 때만 다음 팀으로 넓힌다.
60분 도입 점검0–10분: 테넌트·라이선스·Frontier 접근 확인. 10–20분: 사용자·데이터·행동 한정. 20–35분: 커넥터 권한과 DLP 확인. 35–45분: 비용·로그 계측 설정. 45–55분: 실패와 롤백 시험. 55–60분: 통과·중단 기준과 책임자 서명.
최종 판단: 속도는 초안에서, 신뢰는 운영 경계에서 나온다
Copilot Cowork와 Copilot Studio의 앱 빌더는 자연어에서 업무 앱의 초안을 만드는 시간을 줄일 가능성이 크다. 그러나 조직 데이터에 연결하고 쓰기 작업을 허용하는 순간부터 핵심은 생성 속도가 아니라 권한, 비용, 버전, 승인, 롤백이다.
지금 할 일은 전사 도입 발표가 아니다. 읽기 전용의 작은 내부 시나리오를 고르고, 기준값을 측정하고, 실패를 재현하고, 실제 비용을 확인하는 것이다. 이 네 가지 증거가 모인 뒤에만 확대 결정을 내리자.
함께 읽기: AI 실행과 검증을 분리한 Cloud Runner 실험, 업무에 맞는 AI 도구 선택 기준.
