Power Automate로 업무 자동화하기 ── 클라우드 플로우・데스크톱 플로우 구분과 오류 처리 설계

“공유 폴더에 쌓이는 CSV를 매일 아침 Excel로 정리해서 상급자에게 메일로 보낸다”, “여러 업무 시스템에서 값을 수작업으로 복사해 붙여넣어 집계한다”. 이런 작업을 Power Automate로 자동화하고 싶다는 상담을 최근 자주 받습니다.

처음 만드는 작은 플로우는 대체로 수십 분 만에 동작하게 됩니다. 문제는 그 이후입니다. 운영 환경에서 실제로 돌리기 시작하고 얼마 지나면, 간혹 오류로 멈추게 됩니다. 대상 시스템의 화면 레이아웃이 조금만 바뀌어도 플로우가 깨집니다. 비밀번호를 둘 곳을 정하지 못한 채, 일단 입력 변수에 직접 써넣은 상태로 남아 있습니다. “동작하는 플로우”는 있지만, 정작 필요할 때 누구도 고칠 수 없는 — 이런 상태에 빠진 사례를 여러 번 봐 왔습니다.

Power Automate는 학습 비용이 낮고, 노코드・로우코드로 시작할 수 있습니다. 그 손쉬움 때문에 설계를 뒤로 미룬 채로 운영 환경에 올라가기 쉬운 도구이기도 합니다. 이 글에서는 클라우드 플로우와 데스크톱 플로우의 차이, PowerShell・VBA와의 역할 분담, 오류 처리, UI 자동화를 안정시키는 사고방식, 자격 증명 처리, 거버넌스와 운영, 그리고 Power Automate의 범위를 벗어나는 시점을 판단하는 방법까지, 실무에서 걸림돌이 되기 쉬운 순서로 정리합니다.

1. 먼저 결론

• Power Automate에는 크게 클라우드 플로우(커넥터를 통해 클라우드 서비스를 연결)와 데스크톱 플로우(Windows의 화면 조작이나 데스크톱 앱을 자동화하는 RPA)라는 두 계통이 있습니다. 먼저 어느 쪽이 필요한지 구분하는 것이 첫 번째 설계 판단입니다.
• “PC 상의 정형 작업”만 자동화하고 싶다면, Power Automate Desktop보다 먼저 PowerShell이 후보가 되는 경우도 많습니다. 화면 클릭이나 입력이 필수가 아니라면, PowerShell 쪽이 유지보수하기 쉽고 버전 관리에도 올리기 쉬운 경우가 있습니다.
• Power Automate를 선택하는 가치가 큰 경우는, API 연동이 적은 기존 시스템의 화면을 조작해야 하는 경우, 혹은 Microsoft 365의 커넥터(Outlook, SharePoint, Teams 등)로 알림・승인 플로우를 빠르게 만들고 싶은 경우입니다.
• 운영 환경에 올릴 것이라면, 오류 처리(On Block Error), UI 셀렉터 안정화, 자격 증명의 안전한 관리, DLP 정책에 의한 거버넌스라는 4가지는 처음부터 설계에 포함시킵니다. 나중에 추가하는 것은 사고의 원인이 됩니다.¹²
• 무인 실행(unattended)에는 유인 실행(attended)과는 별도의 라이선스・전제 조건이 필요합니다. 라이선스 설계를 뒤로 미루면, 검증 환경에서는 동작했는데 운영 환경에서는 실행할 수 없는 상황이 됩니다.³⁴

2. Power Automate의 전체 구조

Power Automate는 단일 제품이라기보다, 여러 자동화 수단을 모아 놓은 플랫폼입니다.

flowchart TB
    PA[Power Automate]
    PA --> Cloud[클라우드 플로우]
    PA --> Desktop[데스크톱 플로우 / RPA]
    PA --> Process[프로세스 마이닝]
    PA --> Builder[AI Builder]

    Cloud --> Auto[자동화 플로우<br/>이벤트 트리거]
    Cloud --> Sched[예약 플로우<br/>정기 실행]
    Cloud --> Instant[즉시 플로우<br/>수동・버튼 실행]
    Cloud --> Connectors[커넥터<br/>SharePoint / Outlook / Teams / SQL 등]

    Desktop --> Attended[유인 실행<br/>사용자 앞에서 실행]
    Desktop --> Unattended[무인 실행<br/>서버/전용 PC에서 실행]
    Desktop --> UIAuto[UI 자동화<br/>화면 조작・기존 앱 연동]

• 클라우드 플로우는 커넥터를 통해 클라우드 서비스끼리 연결하는 방식입니다. 트리거 종류에 따라 자동화 플로우(이벤트 발생 시), 예약 플로우(정기 실행), 즉시 플로우(수동 실행)로 나뉩니다.
• 데스크톱 플로우는 Windows 상의 애플리케이션이나 화면을 직접 조작하는 RPA(Robotic Process Automation)입니다. 클라우드 플로우에서 호출할 수도 있고, 단독으로 실행할 수도 있습니다.⁵
• 데스크톱 플로우는 다시, 사람이 화면 앞에 있는 상태에서 실행하는 유인 실행(attended)과, 전용 PC나 서버에서 사람의 개입 없이 실행하는 무인 실행(unattended)으로 나뉩니다.⁴

무인 실행의 “전용 머신”이란 잠겨 있지 않으면 된다는 뜻이 아닙니다. Windows 10/11에서는 접속에 사용하는 사용자인지 여부와 관계없이, 누군가의 세션이 잠금 상태로라도 남아 있으면 무인 실행이 실패합니다. Windows Server에서는 범위가 조금 더 좁아서, 접속에 사용하는 동일한 사용자의 잠긴 세션이 남아 있으면 실행할 수 없습니다. 유지보수 작업이나 다른 관리자의 RDP 접속 후에 “잠금”이나 “연결 끊기”로 끝내버리기 쉽지만, 반드시 모든 사용자를 “로그아웃”해 두어야 합니다.⁶

상담을 받을 때는 먼저 “이것이 클라우드 서비스끼리 연결하는 이야기인지, 아니면 화면을 조작하는 이야기인지”를 구분하는 것부터 시작합니다. 그것만으로도 전망이 훨씬 좋아집니다.

3. 클라우드 플로우・데스크톱 플로우・PowerShell・VBA의 구분 사용

같은 “자동화”라도, 잘하는 영역은 상당히 다릅니다.

실무에서 흔한 오해는 “자동화하고 싶다 = 일단 Power Automate”라고 생각하는 것입니다. 이미 API가 마련되어 있는 시스템을 Power Automate Desktop으로 UI 조작하는 것은, 원래라면 PowerShell이나 .NET에서 API를 직접 호출하는 쪽이 더 안정적인 경우입니다. 반대로 API가 없는 오래된 업무 시스템이나 Win32 앱의 화면을 조작해야 한다면, 데스크톱 플로우의 UI 자동화가 현실적인 선택지가 됩니다.

참고: Excel과 VBA의 제약, 대체 방안에 대해서는 다른 글 「VBA란 무엇인가 - 제약, 장래성, 교체해야 할 장면과 현실적인 이행 패턴」에서도 정리하고 있습니다. Microsoft 365 상의 업무 플로우를 Office Scripts와 Power Automate로 조합하는 패턴에 대해서도 다루고 있습니다.⁷

4. 라이선스 이해하기

Power Automate의 라이선스는 크게 사용자 단위 라이선스와, 플로우 단위(프로세스) 라이선스로 나뉩니다.³

여기서 헷갈리기 쉬운 점은, 라이선스 개념이 “누가 만들었는가”가 아니라 “어떻게 실행되는가”로 결정된다는 것입니다. 자동화 플로우나 예약 플로우는 플로우 소유자의 라이선스 컨텍스트로 동작하고, 버튼으로 실행하는 즉시 플로우는 호출한 사용자의 라이선스 컨텍스트로 동작합니다. 무인 실행을 전제로 설계한다면, 검증 단계에서 라이선스 요건을 확인해 두지 않으면 운영 전환 직전에 막히게 됩니다. 참고로 이전에 있던 “무인 실행 애드온(Unattended RPA add-on)”은 현재 레거시로 취급되어 Power Automate Process 라이선스로 대체되었습니다. 기존의 무인 실행 애드온은 Process 라이선스와 동등한 취급으로 격상되었지만, 신규로 할당할 경우에는 Process 라이선스를 사용합니다.³⁸⁴

주의해야 할 점은, Process / Hosted Process 라이선스만으로는 사용자 라이선스를 대체할 수 없다는 것입니다. 머신에 Process 라이선스를 할당(무인 실행에 필요)하려면, 그 머신이 Power Automate Premium 라이선스를 가진 사용자에 의해 등록되어 있어야 한다는 전제가 있습니다. 또한 클라우드 플로우에서 유인 실행・무인 실행의 데스크톱 플로우를 호출하는 경우에도, 실행에 사용하는 연결의 사용자가 Premium 라이선스(또는 데스크톱 플로우 권한을 포함한 다른 라이선스)를 가지고 있어야 합니다. Process 용량만 확보하고 운영에 필요한 사용자 라이선스를 놓치면, 기능 테스트 단계에서 막히게 됩니다.³

5. 실전 설계 ── 공유 폴더의 CSV를 집계해 Excel 보고서를 만들고 메일로 보내기

구체적인 예로, 흔히 있는 “일일 보고서 작성”을 주제로 삼습니다.

하고 싶은 일

1. 공유 폴더에 있는 당일자 CSV를 모은다
2. 내용을 집계해 Excel 보고서 템플릿에 기록한다
3. 보고서를 지정된 폴더에 저장한다
4. 관계자에게 메일로 알린다
5. 실패하면 담당자에게 알리고, 원인을 로그에 남긴다

flowchart TD
    Start([예약 실행 06:30]) --> Block[[On Block Error: 집계 처리]]
    Block --> List[List files in folder<br/>당일자 CSV 가져오기]
    List --> Check{대상 파일 있음?}
    Check -- 없음 --> NoticeEmpty[대상 없음을 기록하고 종료]
    Check -- 있음 --> Read[Read from CSV file<br/>파일별로 반복]
    Read --> Agg[값을 집계・변수에 더하기]
    Agg --> Excel[Launch Excel<br/>템플릿 열기]
    Excel --> Write[Write to Excel worksheet<br/>집계 결과 기록]
    Write --> Save[Excel 저장 후 닫기]
    Save --> Mail[Send an email<br/>담당자에게 보고서 전송]
    Mail --> Log[실행 결과를 로그 파일에 추가]
    Log --> End([정상 종료])
    Block -. 오류 발생 .-> Handler[오류 핸들러]
    Handler --> CloseExcel[Excel이 열려 있으면 닫기]
    CloseExcel --> LogErr[오류 내용을 로그에 기록]
    LogErr --> Notify[관리자에게 실패 알림 메일]
    Notify --> End2([비정상 종료로 기록])

주요 액션과 역할은 다음과 같습니다.

플로우 전체를 하나의 거대한 액션 목록으로 만들지 말고, “파일 가져오기” “집계” “Excel 기록” “통지” “로그 기록”처럼 하위 플로우로 분할해 두면, 이후의 수정이나 단독 재실행이 쉬워집니다. 클라우드 플로우 쪽에서 예약으로 실행하고, 실제 처리는 호출 대상 데스크톱 플로우에 맡기는 구성도 운영 면에서 다루기 쉬운 형태입니다.⁵

6. 오류 처리 설계하기

Power Automate Desktop에는 블록 단위로 오류 처리를 한꺼번에 설정할 수 있는 On Block Error 액션이 있습니다. 개별 액션마다 “오류 시 동작”을 설정하는 대신, 블록에 포함된 모든 액션에 공통 오류 처리를 적용할 수 있습니다.¹

[On Block Error] 집계 처리 블록
  ├─ List files in folder
  ├─ Read from CSV file(반복)
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[오류 핸들러]
  ├─ Get last error 액션으로 오류 내용(이름・발생 위치・해당 액션・상세 메시지)을 변수로 가져옴
  ├─ Excel 인스턴스가 열려 있으면 닫기(실패 시일수록 뒷정리를 생략하지 않음)
  ├─ Write text to file(Append)로 로그에 기록
  ├─ Send an email(V2)로 관리자에게 통지
  └─ "블록의 마지막부터 재개" 또는 "플로우 실행 중지"를 선택

여기서 짚어 두고 싶은 점이 몇 가지 있습니다.

• 개별 액션의 오류 처리는 블록 단위 오류 처리보다 우선되므로, 특정 액션만 동작을 바꾸고 싶은 경우에는 개별 설정을, 그 외에는 On Block Error로 묶는 방식으로 역할을 나눕니다.¹
• “Retry action if an error occurs”를 사용하면, 일시적인 오류(네트워크 지연이나 파일 잠금 등)에 대해 지정한 횟수・간격으로 자동 재시도할 수 있습니다. 모든 오류를 재시도 대상으로 하면 시간이 낭비되므로, 재시도해야 할 오류와 재시도하지 않아야 할 오류(데이터 불일치 등)를 구분해서 생각합니다.¹
• 오류 핸들러 안에서 직전 오류 내용을 참조하고 싶다면, Get last error 액션을 명시적으로 배치합니다. 이것은 발생한 오류의 이름・위치・해당 액션・소속 하위 플로우・상세・메시지라는 6개 속성을 가진 변수를 반환하는 액션으로, 암묵적 변수로 자동으로 준비되어 있는 것은 아닙니다. 같은 오류 값을 나중에 잘못 재사용하지 않도록, 가져온 후에는 “Clear error” 옵션으로 초기화해 두면 안전합니다.¹
• 로그는 “성공/실패”만이 아니라, 처리 건수, 대상 파일명, 오류 메시지까지 남기도록 합니다. 나중에 “왜 멈췄는가”를 조사할 실마리는 로그에만 있습니다.
• 블록의 후처리로, “블록의 마지막부터 재개할지” “플로우 실행을 중지할지”를 명시적으로 선택합니다. Excel 인스턴스를 열어 둔 채로 중지하면 다음 실행 시 프로세스가 남아 있는 사고로 이어지므로, 오류가 발생했을 때일수록 뒷정리(인스턴스 종료)를 의식합니다.¹¹

PowerShell의 try/catch/finally에 익숙하다면, On Block Error의 “블록”은 try, 오류 핸들러는 catch, 뒷정리 처리 열은 finally에 가까운 이미지로 받아들이면 설계하기 쉬워집니다.

7. UI 자동화 안정시키기

데스크톱 플로우가 불안정해지는 가장 큰 원인은, 대부분 “UI 요소를 특정하는 방법(셀렉터)”에 있습니다.

• 기본적으로 UI 요소 선택기(picker)가 화면 요소를 셀렉터(속성의 조합)로 기록합니다. 앱 버전 업그레이드나 표시 내용 변화에 약한 속성(연속 번호 인덱스나 동적 ID 등)이 포함되어 있으면, 겉보기가 같아도 플로우가 깨집니다.¹²
• 값이 변하는 속성은 Equals가 아니라 Contains나 정규식으로 변경하고, 이전 액션의 결과에 의존하는 값은 변수화함으로써, 더 동적이고 깨지기 어려운 셀렉터가 됩니다.¹²
• 여러 셀렉터를 설정해 두면, 첫 번째 셀렉터가 실패했을 때 다음 셀렉터로 자동으로 폴백합니다. 중요한 조작에는 예비 셀렉터를 준비해 두면 안정성이 높아집니다.¹²
• 셀렉터가 깨졌을 때는, Repair selector 기능으로 자동으로 복구 후보를 생성할 수 있습니다. 수동으로 처음부터 다시 만들기 전에 먼저 시도해 볼 가치가 있습니다.¹²
• 화면 전환이나 앱 실행에는 시간차가 있습니다. 고정된 Wait에만 의존하지 않고, “창을 대기한다” “UI 요소를 찾을 때까지 대기한다”와 같은 조건 대기 액션을 함께 사용하고, UI 요소를 찾지 못했을 때의 자동 재시도도 함께 설정합니다.¹³
• 아무리 해도 안정되지 않는 자동화 대상(가상화된 화면, 레이아웃이 자주 바뀌는 화면 등)에 대해서는, UI 조작에 집착하지 말고 API・파일 연동・데이터베이스 액세스 등 더 안정적인 연동 방법이 없는지를 먼저 확인합니다.

UI 자동화를 처음 동작시키는 것 자체는 어렵지 않습니다. 반년 후에도 깨지지 않고 동작하는지는 거의 셀렉터를 만드는 방식만으로 결정됩니다.

8. 자격 증명을 안전하게 다루기

업무 자동화에서 가장 사고가 나기 쉬운 것이, 자격 증명(비밀번호, API 키, 연결 문자열 등)의 처리입니다.

• 비밀번호나 연결 정보를 플로우의 입력 변수에 그대로 값으로 적어 두는 것은 피합니다. Get credential 액션을 사용하면, Azure Key Vault나 CyberArk를 뒤에서 시크릿 저장소로 하는 “Power Automate의 자격 증명”에서 인증 정보를 안전하게 가져올 수 있으며, 가져온 값은 기밀 정보로 표시되어 플로우 실행 로그에도 남지 않습니다.¹⁴¹⁵
• Azure Key Vault를 시크릿 보관 장소로 사용하는 경우, Power Automate 쪽에서 Key Vault로의 연결 정보를 한 곳에 모아 관리할 수 있으므로, 인증 정보를 플로우마다 분산시키지 않아도 됩니다.¹⁵
• 무인 실행용 계정은 이용 범위를 필요 최소한으로 좁힌 전용 계정을 마련하고, 사람이 일상적으로 사용하는 계정과 겸용하지 않도록 합니다. 계정이 가진 권한이 넓을수록, 플로우의 결함이나 설정 오류가 미치는 영향 범위도 넓어집니다.
• “일단 동작시키기 위해 임시로”라며 평문으로 비밀번호를 입력 변수에 적어 둔 채 검증을 진행하면, 그대로 운영 환경에 남기 쉽습니다. 검증 단계부터 Get credential 액션을 사용하는 습관을 들여 두는 것이 안전합니다.

9. 거버넌스와 운영

개인이나 팀 단위로 만든 플로우가 늘어나면, 다음은 조직으로서의 통제가 필요해집니다.

• 데이터 손실 방지(DLP) 정책은 플로우나 앱에서 사용할 수 있는 커넥터를 “업무 데이터 전용”, “업무 데이터 사용 불가”, “차단” 등으로 분류하여, 업무 데이터용 커넥터와 업무 데이터 사용 불가 커넥터를 같은 플로우 안에서 함께 사용할 수 없게 하는 체계입니다. 조직의 데이터가 의도치 않게 외부 서비스로 유출되는 것을 막는, 가장 먼저 정비해야 할 거버넌스입니다.¹⁶
• 데스크톱 플로우의 액션도 같은 DLP 정책의 틀 안에서 분류・차단할 수 있지만, 이것은 기본값으로는 활성화되어 있지 않습니다. Power Platform 관리 센터의 테넌트 설정에서 “Show desktop flow actions in DLP policies”를 한 번 켜야 하며, 이 설정은 나중에 되돌릴 수 없습니다. 활성화한 이후에도, 정책에서 명시적으로 분류한 모듈・액션만 제어 대상이 되므로, “DLP 정책을 만들었다 = 데스크톱 플로우 전체가 통제 아래 있다”는 뜻은 아니라는 점에 주의합니다.²
• 무인 실행용 머신은 머신 그룹으로 묶어서 관리하고, 어느 플로우가 어느 머신에서 실행되는지를 명확히 해 둡니다.
• 실행 기록은 Power Automate의 관리 화면・실행 기록에서 확인할 수 있습니다. 실패 시 알림(Teams 알림이나 메일 알림)을 플로우 자체의 처리로 넣어 두면, 누군가가 수동으로 확인하러 가지 않아도 이상을 알아챌 수 있습니다.
• 사내 네트워크의 데이터베이스나 파일 공유처럼, 클라우드에서 직접 액세스할 수 없는 온프레미스 리소스를 클라우드 플로우에서 다루고 싶은 경우에는 온프레미스 데이터 게이트웨이를 사용합니다. 게이트웨이는 클라우드 쪽에서의 수신 포트 개방을 필요로 하지 않으며, 송신 방향 연결만으로 안전하게 데이터를 중개합니다.¹⁷
• 검증용과 운영용으로 환경을 나누고, 데스크톱 플로우나 연결 정보를 환경별로 구분해 두면, 검증 중의 변경이 운영 플로우에 영향을 주는 것을 막을 수 있습니다.

10. Power Automate의 한계와 전환 기준

Power Automate는 강력하지만 만능은 아닙니다. 다음과 같은 상황에서는 PowerShell이나 .NET 앱으로 전환하는 것을 검토합니다.

“Power Automate로 만든 것이 커져서 지나치게 복잡해졌다”고 느껴질 때는, 무리하게 플로우를 계속 확장하기보다, 핵심 처리를 .NET이나 PowerShell로 분리하고, Power Automate는 트리거와 통지에 전념하게 하는 구성으로 옮기는 쪽이 결과적으로 유지보수하기 쉬워지는 경우가 많습니다. PowerShell을 이용한 로그 조사・아카이브 자동화의 실제 예는 다른 글 「PowerShell 스크립트 응용 ── 로그 조사·아카이브·리포트화를 안전하게 자동화하기」에서도 소개하고 있습니다.

11. 정리

Power Automate는 첫걸음까지는 놀랄 만큼 쉽습니다. 다만 그 손쉬움은 뒤집어 보면 “설계를 대충 해도 일단은 동작해 버린다”는 뜻이기도 합니다. 운영에 내놓은 플로우를 오래 유지보수할 수 있는지는, 처음에 얼마나 수수한 판단을 미리 끝내 두었는지로 거의 결정됩니다.

클라우드 플로우와 데스크톱 플로우 중 어느 쪽을 쓸지, PowerShell이나 .NET에 맡기는 편이 좋은 처리는 어느 것인지. 이 구분을 처음에 해 두면, 이후의 재작업이 상당히 줄어듭니다. 오류 처리, UI 셀렉터, 자격 증명, 라이선스, DLP 정책은 모두 “동작한 뒤에 고치는” 것보다 “처음부터 포함시키는” 쪽이 압도적으로 비용이 적게 듭니다. 그리고 플로우가 커져서 복잡해졌을 때, 무리하게 확장하지 않고 .NET이나 PowerShell로 처리를 옮기는 판단을 할 수 있는지도, 오래 계속 사용할 수 있는지를 좌우합니다.

“일단 동작하는 플로우”와 “안심하고 맡길 수 있는 플로우” 사이에는 이만큼의 설계 차이가 있습니다. 기존 업무 시스템이나 Excel / VBA 자산이 관련된 자동화일수록, 처음의 설계 판단이 이후의 유지보수 비용을 크게 좌우합니다.

관련 글

• VBA란 무엇인가 - 제약, 장래성, 교체해야 할 장면과 현실적인 이행 패턴
• PowerShell 스크립트 응용 ── 로그 조사·아카이브·리포트화를 안전하게 자동화하기
• Excel 장표 출력을 어떻게 만들까 - COM 자동화 / Open XML / 템플릿 방식의 판단표

관련 상담 영역

합동회사 코무라소프트는 기존의 Excel / VBA / Windows 업무 자산을 남기면서 단계적으로 자동화・현대화하는 상담이나, Power Automate를 포함한 자동화 기반의 설계 리뷰를 다루고 있습니다.

• 기존 자산 활용・이행 지원
• 기술 상담・설계 리뷰
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

클라우드 플로우와 데스크톱 플로우는 어떻게 구분해서 사용하나요?

클라우드 플로우는 커넥터를 통해 클라우드 서비스끼리 연결하는 방식으로, 승인 플로우, 알림, SaaS 연동, Microsoft 365 관련 업무 플로우에 적합합니다. 데스크톱 플로우는 Windows 상의 앱이나 화면을 직접 조작하는 RPA로, API가 없는 오래된 업무 시스템이나 Win32 앱의 화면 조작이 필요한 경우의 현실적인 선택지입니다. 상담을 받을 때는 먼저 '클라우드 서비스끼리 연결하는 이야기인지, 화면을 조작하는 이야기인지'를 구분하는 것부터 시작하면 전망이 좋아집니다.

Power Automate와 PowerShell 중 어느 것을 사용해야 하나요?

PC 상의 정형 작업만 자동화하고 싶다면, 화면 클릭이나 입력이 필수가 아닌 경우 PowerShell이 유지보수하기 쉽고 Git으로 버전 관리하기도 쉬운 경우가 많습니다. API가 마련되어 있는 시스템을 UI로 조작하는 것은 원래 PowerShell이나 .NET에서 API를 직접 호출하는 쪽이 더 안정적입니다. 수십만 행 규모의 데이터 처리, 자동 테스트가 필요한 복잡한 로직, 고빈도 상시 처리도 PowerShell이나 .NET에 적합합니다. 플로우가 지나치게 복잡해지면 핵심 처리를 분리하고 Power Automate는 트리거와 알림에 전념하게 하는 구성이 유지보수하기 쉬워집니다.

Power Automate의 무인 실행에 필요한 라이선스는 무엇인가요?

무인 실행에는 유인 실행과는 별도의 라이선스가 필요하며, 플로우나 머신에 라이선스를 연결하는 Power Automate Process 라이선스를 사용합니다. 이전의 무인 실행 애드온은 현재 레거시로 취급되어 Process 라이선스로 대체되었습니다. 또한 Process 라이선스만으로는 사용자 라이선스를 대체할 수 없으며, 머신 등록에는 Power Automate Premium 라이선스를 가진 사용자가 필요합니다. 게다가 Windows 10/11에서는 누군가의 세션이 잠금 상태로 남아 있으면 무인 실행이 실패하므로, 모든 사용자의 로그아웃이 필요합니다.

데스크톱 플로우의 UI 자동화가 불안정해지는 원인은 무엇인가요?

가장 큰 원인은 대부분 UI 요소를 특정하는 방법(셀렉터)에 있습니다. 연속 번호 인덱스나 동적 ID처럼 변화에 약한 속성이 포함되어 있으면, 겉보기가 같아도 플로우가 깨집니다. 대책으로는 값이 변하는 속성을 Equals가 아니라 Contains나 정규식으로 바꾸고, 여러 셀렉터를 설정해 폴백시키며, 깨졌을 때는 Repair selector 기능으로 복구 후보를 생성합니다. 고정된 Wait에만 의존하지 않고 조건 대기 액션을 함께 사용하는 것도 중요합니다. 반년 뒤에도 깨지지 않고 동작하는지는 거의 셀렉터를 만드는 방식으로 결정됩니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.