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 selector 안정화, 인증 정보의 안전한 관리, DLP 정책에 따른 거버넌스 4가지는 처음부터 설계에 넣습니다. 나중에 붙이면 사고로 이어집니다. ¹²
• 무인 실행(unattended)에는 유인 실행(attended)과는 다른 라이선스·전제 조건이 필요합니다. 라이선스 설계를 뒤로 미루면, 검증 환경에서는 됐는데 운영에서는 실행하지 못한다는 사태가 됩니다. ³⁴

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 21건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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. 라이선스 ── 무인 실행에 필요한 것만 잡기

라이선스 체계의 전체 모습(Microsoft 365에 포함된 시드 라이선스의 범위, 표준 커넥터와 프리미엄 커넥터의 경계, Premium과 Process 중 어느 쪽으로 세는 것이 저렴한지, AI Builder의 크레딧)은 다른 글 「Power Automate 라이선스 ── Microsoft 365만으로 어디까지 무료인가, Premium이 필요한 때는 언제인가」에 판단 표와 함께 정리했습니다. 여기에서는 이 글의 주제인 무인 실행을 운영에 올리기 위해 빼놓을 수 없는 3가지만 잡습니다. ³

물리 머신을 직접 준비하고 싶지 않다면, Microsoft가 호스트하는 머신·머신 그룹에서 무인 실행하는 Power Automate Hosted Process라는 선택도 있습니다. ⁸

한 가지만 더, 무인 실행에 한정하지 않는 원칙을 들어 둡니다. 「누구의 라이선스로 실행되는가」는 누가 만들었는지가 아니라, 어떻게 시작되는지로 결정됩니다(자동화 플로우·스케줄 플로우는 소유자, 버튼 시작의 인스턴트 플로우는 실행한 사람, 무인 RPA는 머신). 이 대응 관계는 위의 라이선스 글에 표로 정리되어 있습니다. 어느 쪽이든 라이선스 설계를 뒤로 미루면 「검증 환경에서는 됐는데 운영에서는 실행하지 못한다」는 식으로 멈추므로, PoC 시점에 위의 3가지를 확인하세요.

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

구체 예로, 흔한 「일일 보고서 작성」을 소재로 합니다.

먼저 이 장의 성격을 밝혀 둡니다. 여기서 보이는 것은 화면 절차서가 아니라, 액션 구성·변수·서브플로우 분할·오류 시 뒷정리를 어떻게 정할지라는 개념 설계입니다. Power Automate for desktop의 화면 배치나 조작 절차는 공식 문서와 버전에 따르는 것이 확실하므로, 이 글에서는 「어느 액션을, 어떤 단위로, 어떤 변수 전달로 짜는지」에 한정합니다. 그대로 만들 수 있는 상태에 가깝게 하려고, 5.1에 변수 목록(이름·형·값 예), 5.2에 서브플로우 분할 구조를 실었습니다.

이 글에서는 액션 이름을 영어 UI 이름으로 적습니다. 한국어 UI에서 작업하는 경우에 대비해, 아래 액션 표와 5.1의 변수 표에서는 한국어 이름 / 영어 이름 대응을 함께 적습니다.

하고 싶은 일

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

flowchart TD
    Start([스케줄 시작 06:30]) --> Block[[On Block Error: 집계 처리]]
    Block --> List[Get 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([비정상 종료로 기록])

주요 액션과 역할은 다음과 같습니다. 한국어 UI에서의 이름도 함께 적습니다(공식 문서 한국어판 액션 레퍼런스 표기입니다¹⁰).

한국어 이름은 완전한 일대일 대응이 아니며, 예를 들어 Office 365 Outlook의 Send an email (V2)는 공식 한국어 문서 안에서도 「전자 메일 보내기 (V2)」「메일 보내기 (V2)」처럼 표기가 통일되어 있지 않습니다. ¹² UI에서 찾지 못하면 영어 이름으로 검색하는 것이 확실합니다.

5.1 변수 설계 ── 이름·형·값의 예

변수는 「나중에 읽는 사람이 플로우만 보고 의미를 따라갈 수 있는가」로 결정됩니다. 이 예라면 최소한 이것만은 처음에 정해 둡니다. 값은 환경에 맞게 바꾸면 됩니다.

포인트는 3가지입니다. 경로를 액션 안에 바로 쓰지 않고 변수로 빼낸다(검증 환경과 운영의 교체가 한 곳에서 끝납니다), 날짜는 「날짜/시간 형」과 「표시용 텍스트」를 나눠 가진다(비교는 날짜/시간 형, 파일 이름은 텍스트로 조립한다), 그리고 건수 계열 변수를 반드시 가진다(로그에 남길 재료가 되고, 「0건으로 정상 종료」와 「가져오기에 실패해 0건」을 구분할 수 있습니다).

5.2 서브플로우로 분할

플로우 전체를 하나의 거대한 액션 나열로 두지 않고, 처리 단위로 서브플로우에 나눠 두면 이후 수정도, 실패한 부분만 다시 실행하는 것도 쉬워집니다. 이 예라면 다음 구조입니다.

Main(메인 플로우)
  ├─ 초기화: 5.1의 변수를 설정한다
  ├─ [On Block Error] 블록 시작
  │    ├─ 「CSV를 모은다」를 실행          → 출력: lstFiles
  │    ├─ 대상 0건이면 「대상 없음」을 기록하고 종료
  │    ├─ 「집계한다」를 실행              → 입력: lstFiles / 출력: numTotal, numProcessed
  │    ├─ 「Excel에 쓴다」를 실행        → 입력: numTotal, txtTemplatePath / 출력: txtReportPath
  │    ├─ 「알린다」를 실행              → 입력: txtReportPath, numProcessed
  │    └─ 「로그를 쓴다」를 실행            → 입력: 실행 결과(성공)
  └─ [오류 핸들러]
       ├─ 「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 요소를 식별하는 방법(selector)」에 있습니다.

• 기본값에서는 UI 요소 선택기가 화면 요소를 selector(속성의 조합)로 기록합니다. 앱 업데이트나 표시 내용 변화에 약한 속성(일련번호 인덱스나 동적 ID 등)이 포함되어 있으면, 겉모습이 같아도 플로우가 깨집니다. ¹⁴
• 값이 변하는 속성은 Equals가 아니라 Contains나 정규식으로 바꾸고, 이전 액션 결과에 의존하는 값은 변수화하면 더 동적이고 잘 깨지지 않는 selector가 됩니다. ¹⁴
• 여러 selector를 설정해 두면, 첫 selector가 실패한 경우 다음 selector로 자동 폴백합니다. 중요한 조작에는 예비 selector를 준비해 두면 안정성이 올라갑니다. ¹⁴
• selector가 깨진 경우에는 Repair selector 기능으로 복구 후보를 자동 생성할 수 있습니다. 수동으로 처음부터 다시 만들기 전에 먼저 시도할 가치가 있습니다. ¹⁴
• 화면 전환이나 앱 시작에는 시간 차가 있습니다. 고정 Wait만 의존하지 않고, 「창 대기」「UI 요소가 보일 때까지 대기」 같은 조건 대기 액션을 조합하고, UI 요소를 찾지 못한 경우의 자동 재시도도 함께 설정합니다. ¹⁵
• 아무리 해도 안정되지 않는 자동화 대상(가상화된 화면, 레이아웃이 자주 바뀌는 화면 등)에 대해서는 UI 조작에 집착하지 않고, API·파일 연동·데이터베이스 접근 등 더 안정적인 연동 방법이 없는지를 먼저 확인합니다.

UI 자동화를 처음에 동작시키는 것 자체는 어렵지 않습니다. 6개월 뒤에도 깨지지 않고 동작하는지는 거의 selector를 만드는 방식만으로 결정됩니다.

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에 로그인한 뒤 「내 플로우」→ 대상 플로우 → 상세 페이지의 「실행 이력」에서, 실패한 실행을 고르면 어느 액션에서 실패했는지와 오류 상세를 볼 수 있습니다. 같은 상세 페이지 위쪽 메뉴의 「Analytics」에서는 성공률·실패율과 최근 30일 실행 이력을 볼 수 있습니다. 테넌트 전체·환경 전체의 실패를 빠짐없이 보고 싶을 때는 Power Platform 관리 센터의 Monitor(모니터링)가 가장 포괄적입니다. ¹⁹²⁰ 한편 연쇄 실패(먼저 실패한 액션에 끌려 후속도 실패로 처리되는 것)가 늘어설 수 있으므로, 실행 이력에서는 「처음 실패한 액션」을 보는 것이 원칙입니다. ¹⁹
• 표준 실패 알림의 한계를 안 위에, 자체 알림을 더합니다. Power Automate는 클라우드 플로우 실패에 대해 두 종류의 메일을 보냅니다. 하나는 실행 단위의 실패 알림으로, 연결 끊김이나 제한(throttling)처럼 「해결 방법이 알려진 원인」으로 판정된 때만 플로우 소유자·공동 소유자에게 보내집니다. 게다가 이는 플로우 설정에서 켜져 있어야 하며, 같은 플로우에는 한 번 보내면 28일 쿨다운이 들어갑니다. 다른 하나는 주간 다이제스트로, 알림이 나가지 않은 일반적인 실패까지 모아 도착합니다. ¹⁹ 즉 「매번·바로·담당자에게」를 표준 기능만으로 채울 수는 없습니다. 6장의 오류 핸들러에서 관리자에게 메일이나 Teams로 알리는 처리를 플로우 자신의 일부로 넣어 두세요.
• 사내 네트워크 안의 데이터베이스나 파일 공유처럼, 클라우드에서 직접 접근할 수 없는 온프레미스 리소스를 클라우드 플로우에서 다루고 싶을 때는 온프레미스 데이터 게이트웨이를 사용합니다. 게이트웨이는 클라우드 쪽 수신 포트 개방이 필요 없고, 송신 방향 연결만으로 데이터를 안전하게 중계합니다. ²¹
• 검증용과 운영용으로 환경을 나누고, 데스크톱 플로우나 연결 정보를 환경마다 분리해 두면, 검증 중 변경이 운영 플로우에 영향을 주는 것을 막을 수 있습니다.

10. Power Automate의 한계와 에스컬레이션 기준

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

「Power Automate로 만든 것이 커져 너무 복잡해졌다」고 느낄 때는, 무리하게 플로우를 계속 확장하기보다 핵심 처리를 .NET이나 PowerShell로 분리하고, Power Automate는 트리거와 알림에 전념시키는 구성으로 옮기는 편이 결과적으로 유지보수하기 쉬운 경우가 많습니다. PowerShell로 로그 조사·아카이브 자동화의 실례는 다른 글 「PowerShell 스크립트 응용 ── 로그 조사·아카이브·리포트를 안전하게 자동화하기」에서도 소개합니다.

11. 정리

Power Automate는 첫 한 걸음까지는 놀랄 만큼 쉽습니다. 다만 그 손쉬움은 뒤집으면 「설계를 건너뛰어도 일단 동작한다」는 말이기도 합니다. 운영에 올린 플로우를 오래 유지할 수 있는지는, 처음에 얼마나 눈에 띄지 않는 판단을 끝내 두었는지로 거의 결정됩니다.

클라우드 플로우와 데스크톱 플로우 중 어느 쪽을 쓸지, PowerShell이나 .NET에 맡기는 편이 나은 처리는 무엇인지. 이 구분을 처음에 해 두면 이후 재작업이 꽤 줄어듭니다. 오류 처리, UI selector, 인증 정보, 라이선스, 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 요소를 식별하는 방법(selector)에 있습니다. 일련번호 인덱스나 동적 ID처럼 변화에 약한 속성이 포함되어 있으면, 겉모습이 같아도 플로우가 깨집니다. 대책으로는 값이 변하는 속성은 Equals가 아니라 Contains나 정규식으로 두고, 여러 selector를 설정해 하나가 실패하면 다음으로 넘어가게 하며, 깨진 경우에는 Repair selector 기능으로 복구 후보를 생성합니다. 고정 Wait에만 의존하지 않고 조건 대기 액션을 조합하는 것도 중요합니다. 6개월 뒤에도 깨지지 않고 동작하는지는 거의 selector를 만드는 방식으로 결정됩니다.

저자 프로필

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

Go Komura

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

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