【시도해 보기】Copilot Studio + Power Automate Desktop

자연어로 Copilot 에이전트에게 지시를 내려서, Outlook으로부터 테스트 메일을 전송할 수 있었습니다・・・

이렇게 혼잣말을 내뱉을 정도로 놀라움을 감출 수 없었습니다! 에... 뭐가 말이냐고요?

RPA처럼 UI 조작을 정의하는 것이 아니라, "문장을 쓰는 것만으로" 데스크톱 앱을 조작할 수 있었다는 것입니다.

Copilot Studio에서 Power Automate Desktop (PAD) 등의 로컬 리소스를 호출하여 업무 자동화를 수행하는 구성은 엔터프라이즈 AI 영역에서 정석이 되어가고 있습니다.

이번에 검증한 Copilot Studio의 「컴퓨터 유즈 (Computer Use)」 기능은 기존 RPA의 상식을 뒤엎을 정도의 임팩트를 가지고 있습니다. 기존처럼 "UI 요소 (버튼이나 텍스트 박스)를 하나씩 지정하여 플로우를 구성하는" 것이 아니라, "시작 메뉴에서 열고, 수신인을 입력하고..."와 같은 자연어 절차를 기술하는 것만으로, AI가 화면을 해석하여 데스크톱 앱 (새로운 Outlook)을 조작해 메일을 전송할 수 있었습니다.

주의사항

본 기사의 내용은 어디까지나 최신 기능을 활용한 실험적인 "시도해 보기" 계열의 기술 검증이며, 실제 업무나 엔터프라이즈 환경으로의 즉시 도입을 상정한 실천적인 접근 방식이 아닙니다. AI에 의한 데스크톱 화면 자동 조작은 예기치 않은 동작 (의도하지 않은 앱 조작이나 오발송 등)을 일으킬 리스크가 있으므로, 실제로 시도하실 경우에는 반드시 영향이 없는 테스트 환경에서 모든 자기 책임 하에 실시해 주시기를 부탁드립니다.

위의 전제를 바탕으로, 본 기사에서는 이 차세대 자동화 접근 방식의 구현 절차와 안전하게 검증하기 위한 보안 설정의 요점, 그리고 시스템 아키텍처로서의 고찰을 해설합니다.

기존의 RPA (PAD 등)를 이용한 UI 조작과 이번 컴퓨터 유즈 기능을 이용한 접근 방식에는 근본적인 차이가 있습니다.

• 기존의 접근 방식 (UI 셀렉터 의존): PAD의 레코더 기능 등을 사용하여, 조작 대상인 윈도우나 버튼의 "UI 셀렉터 (내부 ID나 계층 구조)"를 정확하게 캡처하여 스텝을 구축합니다. 화면 레이아웃이나 내부 ID가 조금이라도 변경되면 플로우가 에러로 멈춰버리는 유지보수의 과제가 있었습니다.
• 이번의 접근 방식 (AI에 의한 동적 화면 인식): 사용자의 입력과 Copilot Studio에서 정의한 "절차 (텍스트)"를 Claude Opus 4.6 등의 AI 모델이 해석합니다. AI가 현재의 데스크톱 화면을 인식·추론하며 조작을 대행하기 때문에 레이아웃의 미세한 변경에 강하며, 무엇보다 "플로우 작성 공수"가 극적으로削減됩니다.

그럼, 실제로 Copilot Studio에서 에이전트를 설정해 나가는 절차를 살펴보겠습니다.

AI가 로컬의 데스크톱 앱을 조작하기 위해서는, 실행 대상 PC가 Power Automate의 클라우드 환경과 보안 연결되어 있어야 합니다.

이 준비를 마쳐둠으로써, 후술할 Copilot Studio의 툴 설정 내 (머신 관리)에서 동작시킬 물리 PC를 지정할 수 있게 됩니다.

Copilot Studio의 에이전트 설정 화면에서 액션으로서 「컴퓨터 유즈」 툴을 추가합니다.

모델에는 화면 인식과 조작에 능숙한 프리뷰 모델 (예: Claude Opus 4.6)을 지정합니다.

툴이 실행될 때 AI에게 전달할 파라미터 (변수)를 정의합니다. 이번에는 다음과 같은 변수를 설정했습니다.

• testMailAddress (수신인 1)
• testMailAddress2 (수신인 2 / CC용)
• suggestedAccount (초기 설정 시의 계정명)
• olkpassword (비밀번호)

이 부분이 본 기능의 최대 특징입니다. PAD처럼 액션을 퍼즐처럼 나열하는 것이 아니라, 다음과 같이 자연어 (일본어)로 절차를 기술합니다.

※ Microsoft 365 Developer Program 환경 (영어)에서 테스트했으므로 지시하는 Outlook의 버튼 이름은 영어로 되어 있습니다.

Windows 시작 메뉴에서 Outlook을 검색하여 실행합니다.
초기 설정 화면인 'Welcom to the new Outlook' 화면이 표시되는 경우,
'Suggested account'에 입력한 suggestedAccount를 입력하고 'Continue' 버튼을 누르세요.
...

주목해야 할 점은, "초기 설정 화면이 표시되는 경우...", "비밀번호를 요구받으면..."과 같은 조건 분기(Conditional Branching)나 예외 처리(Exception Handling)조차도 자연어로 기술하는 것만으로 AI가 화면 상태를 판단하여 작동한다는 점입니다.

#프롬프트 문장을 오타 내도 이해해 준다는 점이 더욱 놀랍습니다...

#2행: Welcom to the new Outlook → Welcome to the new Outlook

AI에게 컴퓨터 조작을 맡기는 이 기능은 매우 강력하지만, 의도하지 않은 앱의 실행이나 웹사이트 접속을 방지하기 위한 거버넌스(Governance) 설정이 필수적입니다.

도구의 설정 화면 하단에 있는 "허용된 웹 사이트 및 데스크톱 앱" 섹션에서 AI의 행동 범위를 엄격하게 제한합니다.

특정 앱으로만 제한:

이번에는 새로운 Outlook을 조작하기 위해 다음 컴포넌트(Component)를 허용 목록에 추가했습니다.

• OUTLOOK
• msedgewebview2
• OneDrive / OneDrive (및 Outlook)

Tips:

WebView2 허용이 필수: 새로운 Outlook은 웹 기술(WebView2)을 기반으로 동작합니다. 따라서 본체인 OUTLOOK 프로세스뿐만 아니라, msedgewebview2를 허용 목록에 넣어두는 것이 조작을 정상적으로 완료하기 위한 숨겨진 중요 포인트입니다.

통신의 안전성 담보:

"HTTPS 적용"을 ON으로 설정하여, 조작 대상을 보안 엔드포인트(Secure Endpoint)로 한정합니다.

채팅을 통해 에이전트 테스트 실행 지시를 내리면, Copilot Studio의 "활동(Activity)" 탭에서 AI가 어떻게 화면을 조작하고 있는지 실시간으로 확인할 수 있습니다.

매우 흥미로운 점은, 약 10초 간격으로 현재 데스크톱의 스크린샷이 캡처되며, 그 사이에 AI가 무엇을 인식하고 어떤 조작을 수행했는지가 텍스트로 통지된다는 점입니다.

예를 들어 "메일 본문 영역에 커서가 배치되었습니다... 지시대로 무시하고 작업을 계속합니다"와 같이, Claude 모델이 화면의 시각 정보를 바탕으로 "추론(Reasoning)"하며 작업을 진행하는 프로세스를 명확하게 알 수 있습니다. 이를 통해 에러 발생 시 디버깅(Debugging)도 매우 용이해집니다.

단순히 "작동했다"는 것을 넘어, 엔터프라이즈 아키텍처(Enterprise Architecture) 관점에서 이 접근 방식을 평가해 보겠습니다.

기존의 데스크톱 자동화(Attended RPA)에서 가장 큰 과제는 "실행 중에 PC 화면(마우스나 키보드)을 점유해 버린다"는 점이었습니다. 하지만 이번 검증을 통해, 대상 PC에서 사용자가 로그인하여 다른 작업을 하고 있더라도 Copilot 에이전트는 별도의 계정을 사용한 백그라운드 처리(독립된 세션)로서 동작할 수 있음을 확인했습니다. 이를 통해 사용자의 일상 업무를 방해하지 않으면서, 백그라운드에서 AI에게 데스크톱 앱 조작을 완전히 위임하는 진정한 비어텐디드(Unattended) 아키텍처를 실현할 수 있습니다.

백그라운드에서 빠르고 확실한 메일 전송 처리가 요구되는 시스템 연계라면 당연히 Microsoft Graph API를 사용하는 것이 베스트 프랙티스(Best Practice)입니다. 하지만 본 기능은 "API가 제공되지 않는 레거시 앱(Legacy App)의 조작"이나 "인간의 UI 조작 프로세스를 완전히 모방·테스트하고 싶은 경우"에 진가를 발휘합니다.

"UI 셀렉터(Selector)를 하나씩 가져와서 플로우(Flow)를 구성한다"는 기존 RPA 개발의 상식은 생성형 AI의 "컴퓨터 유즈(Computer Use)" 기능에 의해 크게 변화하려 하고 있습니다. 일본어 자연어 지시만으로 조건 분기를 포함하여 유연하게 새로운 Outlook을 조작할 수 있었다는 점은 놀라웠습니다. 사전 머신 런타임(Machine Runtime) 설정과 적절한 액세스 제어(msedgewebview2 허용 등)를 거친다면, 실무 검증에도 충분히 견딜 수 있는 잠재력을 지니고 있습니다.

한편, 현시점에서의 명확한 과제로 「실행 속도의 지연」을 꼽을 수 있습니다. 이번 검증에서는 단순히 이메일을 1통 송신하는 작업만 완료하는 데 약 5~10분이라는 시간이 소요되었습니다. 이는 AI가 약 10초마다 화면의 스크린샷 (Screenshot)을 캡처하고, 시각 정보로부터 상황을 추론하여 다음 액션 (Action)을 결정하는 프로세스를 반복하고 있기 때문입니다. 기존의 RPA나 API 연동과 같은 즉시성은 없으며, 실시간성 (Real-time)이 요구되는 업무에 적용하는 것은 현 단계에서는 어렵다고 할 수 있습니다.

당분간은 즉시성이 불필요한 야간 배치 (Batch) 방식의 비동기 처리나 테스트 자동화와 같은 영역부터 적용 방안을 모색하면서, 향후 AI 모델의 추론 속도 향상에 따른 패러다임 시프트 (Paradigm Shift)를 기대하고자 합니다.