Power Automate와 PowerShell+작업 스케줄러의 구분 사용 ── 자동화 도구를 섞지 않고 적재적소로 연결하기

“경리 서버에서는 10년 가까이 전부터 PowerShell 야간 배치가 동작하고 있다. 한편 최근 현장 담당자가 Power Automate로 신청 플로우와 알림 플로우를 만들기 시작했다. 같은 ‘자동화’인데 만드는 방법도 두는 위치도 완전히 다른 두 계통이 사내에서 늘어나고 있어, 새 자동화를 어느 쪽으로 만들어야 할지, 애초에 누가 전체를 파악하고 있는지 알 수 없게 되었다.” Microsoft 365를 이미 도입한 중소기업으로부터 최근 이런 상담을 자주 받습니다.

PowerShell+작업 스케줄러와 Power Automate는 둘 다 “정해진 작업을 자동으로 하는” 도구이지만, 잘하는 분야는 거의 겹치지 않습니다. 겹치지 않기 때문에 무리하게 한쪽으로 몰아넣으면 힘들어지고, 경계를 정하지 않고 섞으면 유지보수할 수 없는 땜질 구조가 만들어집니다. 이 글에서는 두 도구의 성격 차이를 정리한 후, 어느 쪽으로 만들지 판단하는 기준과 섞을 때의 연결 패턴을 설명합니다. Power Automate 전체의 설계론은 “Power Automate로 업무 자동화하기 ── 클라우드 플로우・데스크톱 플로우 구분과 오류 처리 설계“에서, PowerShell 자체의 입문은 “PowerShell 명령어의 기초 — 가장 먼저 익힐 조작과 안전한 사용법“에서 다루고 있으므로, 여기서는 “구분해서 만드는 판단”과 “연동”에 초점을 맞춥니다.

1. 먼저 결론

• 판단의 첫 번째 기준은 대상이 어디에 있는가입니다. 로컬 파일・공유 폴더・서버・OS가 대상이라면 PowerShell+작업 스케줄러, SharePoint・Outlook・Teams 등 Microsoft 365상의 데이터와 알림・승인이 대상이라면 Power Automate가 기본선입니다.
• PowerShell의 약점은 사람에게 보내는 알림입니다. 정석이었던 Send-MailMessage는 공식적으로 비권장(obsolete)이며, 직접적인 대체 수단이 PowerShell 안에 없습니다.¹ 알림・승인은 Power Automate에 맡기는 편이 더 저렴하게 해결됩니다.
• Power Automate의 약점은 온프레미스로의 도달과 대량 데이터입니다. 클라우드 플로우가 사내 파일 서버에 닿으려면 온프레미스 데이터 게이트웨이나 데스크톱 플로우 연동이 필요하고, 어느 쪽이든 Microsoft 365 이용권의 범위 밖(프리미엄)입니다.²³⁴
• 두 도구를 연결한다면, PowerShell이 결과 파일을 SharePoint에 두고, Power Automate가 「파일이 생성되었을 때(속성만)」(영어 UI에서는 When a file is created (properties only)) 트리거로 감지해 알림・승인으로 연결하는 느슨한 결합이 첫 번째 후보입니다.⁵
• Power Automate for desktop에는 「PowerShell 스크립트 실행」 액션이 있어, 기존 스크립트를 플로우에서 호출할 수 있습니다. 다만 클라우드 플로우로부터의 호출은 프리미엄 기능이며, 실행 머신의 관리도 필요해집니다.⁶⁴
• 클라우드 플로우의 실행 기록은 기본적으로 28일밖에 보이지 않습니다.⁷ 증적이 필요한 처리는 PowerShell 쪽의 로그 파일이나 SharePoint 목록으로의 기록으로 남깁니다.
• 마지막은 기술이 아니라 유지보수할 수 있는 사람이 있는 쪽으로 만드는 것이 정답인 경우도 많습니다. 만든 사람만 고칠 수 있는 자동화는, 도구가 무엇이든 같은 위험입니다.

2. 두 도구의 성격

먼저 두 도구가 서로 다른 무대의 도구라는 점을 확인해 둡니다.

표의 “변경 관리” 행에 보충해 둡니다. 플로우 내보내기는 Power Automate 포털에 로그인해 왼쪽 내비게이션의 “내 플로우” > “클라우드 플로우”에서 대상 플로우를 선택하고, 메뉴의 “내보내기” 옆 아래 화살표에서 “패키지(.zip)”를 선택하는 조작입니다. 꺼낼 수 있는 것은 zip 패키지이며, 스크립트처럼 행 단위 차분 리뷰에는 적합하지 않습니다. 또한 내보내기를 할 수 있는 것은 플로우의 소유자 또는 공동 소유자뿐이라는 제약도 있습니다. 지속적으로 버전 관리를 하고 싶다면, Microsoft는 패키지 내보내기/가져오기가 아니라 Dataverse 솔루션을 사용하는 ALM을 권장하고 있습니다.⁸

중요한 것은 이 표의 좌우에서 “실행되는 위치”와 “만드는 사람”이 둘 다 다르다는 점입니다. PowerShell+작업 스케줄러는 사내 머신에서 동작하고, 코드를 짤 수 있는 사람이 만들며, 코드로 관리합니다. Power Automate는 클라우드에서 동작하고, 현장의 능숙한 사람도 만들 수 있으며, 실행 기반을 직접 돌볼 필요가 없습니다. 즉 이 둘의 혼재는 단순한 도구의 중복이 아니라 “정보시스템의 자동화”와 “현장의 자동화”라는 두 문화의 공존입니다. 그렇기 때문에 어느 한쪽으로의 통일을 구호만으로 추진하면 대체로 실패합니다.

3. 어느 쪽으로 만들지 판단하는 표

상담을 받을 때는 “대상은 어디에 있는가”, “만들고 유지보수하는 것은 누구인가”, “사람에게 보내는 알림・승인이 필요한가” 이 세 가지로 구분합니다. 구체적인 업무 예시로 보는 편이 빠르므로 판단표로 정리합니다.

열을 세로로 보면, “대상” 열과 거의 1대1로 도구가 정해지는 것을 알 수 있습니다. 예외는 마지막 행처럼 “처리는 로컬, 알림은 클라우드”로 걸쳐 있는 경우이며, 이것이 6장 연동 패턴이 나설 차례입니다.

반대로 다음과 같은 선택은 나중에 힘들어집니다.

• 알림이 필요하다는 이유만으로 파일 처리까지 Power Automate로 몰아넣기. 온프레미스 도달을 위해 게이트웨이나 RPA를 도입하면 라이선스와 관리 대상이 늘어납니다(5장).
• 현장이 사용하는 SharePoint 신청 플로우를, 정보시스템이 PowerShell로 만들기. 만들 수는 있지만, SharePoint 쓰기나 Teams 알림을 코드로 짜는 것은 수고에 비해 얻는 것이 적고, 현장이 손댈 수 없는 유일무이한 물건이 됩니다.
• 어느 쪽으로도 만들 수 있다는 이유로 담당자마다 제각각 선택하기. 7장에서 다루는 유지보수 문제로 직결됩니다. “대상이 여기라면 도구는 이것”이라는 사내 규칙을 한 장으로 정해두는 것만으로도 혼재의 무질서함은 상당히 억제할 수 있습니다.

4. PowerShell 측의 한계

메일・Teams 알림이 힘듦

PowerShell 야간 배치에 “끝나면 메일로 알려줬으면 좋겠다”는 요청이 붙는 순간 갑자기 이야기가 어려워집니다. 오랫동안 쓰여 온 Send-MailMessage 명령은 SMTP 서버로의 안전한 연결을 보장할 수 없다는 이유로 공식적으로 비권장(obsolete)으로 지정되어 있으며, 경고문에는 “PowerShell 안에 직접적인 대체 수단이 없다”고 명시되어 있습니다. 대체 수단으로 안내되는 것은 서드파티의 MailKit 라이브러리나, Exchange Online 이용자를 위한 Microsoft Graph PowerShell SDK(Send-MgUserMail)입니다.¹

Graph를 통한 전송은 동작하지만, Microsoft Entra ID에 대한 앱 등록, 권한(스코프) 부여, 인증서 또는 시크릿 관리 등, 알림 하나를 위해 짊어져야 할 준비가 꽤 많습니다. Teams로의 알림도 마찬가지로, 코드에서 직접 호출하려면 인증 관련 문턱이 높습니다. 여기서는 솔직하게 알림은 Power Automate에 맡기는 판단을 권합니다. 표준 커넥터인 Outlook・Teams 액션이라면 추가 앱 등록 없이 몇 분 만에 구성할 수 있습니다.

담당자 PC에서 동작하는 “야생 작업”

작업 스케줄러 자동화에서 자주 보이는 사고는 서버가 아니라 담당자의 PC에 작업이 심겨 있는 경우입니다. PC를 종료하고 퇴근하면 동작하지 않고, 실행 사용자의 암호 변경이나 퇴사로 조용히 멈춰버립니다. 게다가 작업 스케줄러는 각 머신의 로컬에 있기 때문에, 사내 어디서 무엇이 동작하고 있는지 한눈에 볼 수 있는 장소가 없습니다.

대책은 수수하지만 (1) 정시 실행하는 작업은 정해진 서버(없으면 상시 가동 관리용 PC)에 집약한다, (2) 작업 목록과 목적・담당을 문서화한다, (3) 작업 정의 자체를 Register-ScheduledTask 등의 스크립트로 남겨, 머신이 바뀌어도 재현할 수 있도록 한다, 이 세 가지입니다.⁹ 스크립트 본체만 Git으로 관리하고 있어도, 작업 스케줄러 쪽 설정(기동 시각・실행 사용자・작업 폴더)이 수작업인 채로는 환경을 재현할 수 없습니다.

자격 증명 저장

스크립트가 DB나 외부 서비스에 연결하는 경우, 암호를 어디에 둘지의 문제가 반드시 나옵니다. .ps1에 직접 쓰는 것은 논외로 하고, PowerShell의 표준적인 답은 SecretManagement 모듈+SecretStore 확장입니다. 시크릿을 로컬에 암호화 저장하고, 스크립트에서는 Get-Secret으로 꺼내는 형태로 만들 수 있습니다.¹⁰ 작업 스케줄러의 무인 실행에서 사용할 때의 구성(자동화 계정 컨텍스트에서의 설정)도 공식적으로 안내되어 있습니다.¹¹ 다만 이 모듈군은 현재 “기능 완성” 취급으로 신규 기능 개발은 종료되었지만, 보안 수정 지원은 계속되고 있습니다.¹⁰

한편 Power Automate는 커넥터로의 연결(인증)을 플랫폼 쪽이 보유하기 때문에, 이 문제를 만드는 쪽이 신경 쓰지 않아도 됩니다. 이것은 Power Automate의 숨겨진 강점이지만, 반대로 말하면 연결이 플로우 소유자의 계정에 묶인다는 별도의 관리 문제를 낳습니다. 이 점은 “Power Automate의 속인화 대책 ── 만든 사람이 그만둬도 플로우가 멈추지 않으려면“에서 다루고 있습니다.

5. Power Automate 측의 한계

로컬 파일・온프레미스에 닿지 않음

클라우드 플로우는 Microsoft의 클라우드에서 동작하기 때문에, 사내 네트워크의 공유 폴더나 온프레미스 DB에는 그대로는 닿지 않습니다. 도달 수단은 주로 두 가지입니다.

1. 온프레미스 데이터 게이트웨이. 사내에 상주 앱을 설치해 클라우드와의 다리 역할을 하게 하는 방법입니다. 수신 포트 개방이 필요 없고 송신 방향 연결만으로 동작하기 때문에 안전성이 높은 구조입니다.¹² 파일 시스템이나 SQL Server 등으로의 연결이 게이트웨이를 통해 가능해지지만, 게이트웨이를 사용하려면 대응하는 라이선스가 필요합니다.²
2. 데스크톱 플로우(RPA) 경유. 클라우드 플로우에서 PC에서 동작하는 데스크톱 플로우를 호출해, 로컬 처리를 맡기는 방법입니다. 이 “클라우드 플로우로부터의 트리거・예약 실행” 자체가 프리미엄 기능입니다.⁴

중요한 것은 어느 쪽이든 Microsoft 365에 딸린 Power Automate 이용권 밖이라는 점입니다. Microsoft 365에 딸린 이용권(seeded license)에는 프리미엄 커넥터・온프레미스 게이트웨이・RPA 중 어느 것도 포함되지 않습니다.³ 즉 “공유 폴더의 파일을 Power Automate로 처리하고 싶다”는 겉보기보다 비용이 많이 드는 요청입니다. 라이선스 계층과 표준/프리미엄의 경계는 “Power Automate의 라이선스 ── Microsoft 365에서 어디까지 무료이고, 프리미엄이 필요한 시점은 언제인가“에서 정리하고 있으니 판단 전에 확인해 주십시오.

추가 비용 없이 해결할 수 있는 현실적인 방법은 두 가지입니다. 처리 대상 파일 저장소를 SharePoint/OneDrive 쪽으로 옮기거나, 공유 폴더 쪽 처리는 PowerShell에 맡기고 Power Automate는 클라우드 쪽 업무만 담당하게 하는 것입니다. 후자가 다음 장의 연동 패턴입니다.

대량 데이터・복잡한 로직이 힘듦

수십만 행의 CSV를 한 행씩 플로우의 반복으로 처리하는 작업은 Power Automate의 설계 대상 밖입니다. 라이선스별로 하루당 액션 실행 수 상한도 있어, Microsoft 365 이용권에서는 사용자당 6,000액션/일입니다.³ 대량 건수의 대조・집계・변환은 PowerShell이나 .NET으로 작성하면 몇 분 만에 끝나는 처리이기도 합니다. 구체적인 작성 방법은 “PowerShell 실용 명령어 모음 ── 일상 업무에서 자주 쓰는 작은 기능 늘리기“에서 다룬 Group-Object와 Compare-Object의 조합을 그대로 사용할 수 있습니다.

또한 조건 분기가 깊게 쌓이는 로직은 플로우 화면상에서 읽기 어렵고, 테스트도 작성할 수 없습니다. 1회 실행이 최장 30일이라는 클라우드 플로우의 제한¹³은 승인 대기에는 영향을 주지만, 그 이전에 “분기를 종이에 그리면 A4에 담기지 않는 로직”은 코드의 영역입니다.

실행 기록은 28일이면 사라짐

클라우드 플로우의 실행 기록은 기본적으로 28일밖에 표시되지 않습니다.⁷ “그날의 배치가 동작했는지 3개월 후에 확인하고 싶다”는 요건에는 실행 기록을 쓸 수 없습니다. PowerShell이라면 로그 파일을 직접 작성해 몇 년이든 남길 수 있습니다(이 설계는 로그 정비 글에서 상세히 다뤘습니다). Power Automate에서 증적이 필요한 경우, 처리 결과를 SharePoint 목록에 기록하는 단계를 플로우 자체에 포함시킵니다. 오류 시 알림이나 재시도를 포함한 구현은 “Power Automate의 오류 처리와 재시도 설계“를 참조해 주십시오.

6. 섞을 때의 연결 패턴

두 도구가 잘하는 분야가 겹치지 않는 이상, “처리는 PowerShell, 알림・승인은 Power Automate”로 걸쳐 있는 업무는 반드시 나옵니다. 연결 패턴은 세 가지입니다.

패턴 a: 파일을 통한 느슨한 결합(권장)

작업 스케줄러로 동작하는 PowerShell이 처리 결과(결과 CSV・요약)를 SharePoint 라이브러리에 두고, Power Automate 쪽은 SharePoint 커넥터의 「파일이 생성되었을 때(속성만)」 트리거로 감지해 알림이나 승인으로 연결합니다. 이 트리거는 실제로 존재하는 표준 커넥터 트리거이며, 변경 사항은 수 분 이내를 기준으로 감지됩니다(SharePoint 쪽 변경을 폴링으로 확인하는 방식이므로 즉시는 아닙니다).⁵

테넌트의 표시 언어가 영어면 이 이름으로는 검색할 수 없으므로, 영어 UI에서의 명칭도 함께 표기해 둡니다. 트리거 목록에서 찾을 때는 이쪽으로 검색해 주십시오.⁵

또한 이름이 비슷한 「폴더 내 파일이 생성되었을 때」(When a file is created in a folder)는 비권장으로 지정되어 있고, 하위 폴더에서는 기동하지 않는 등의 제약도 있으므로 신규로 구성할 때는 선택하지 마십시오.⁵

다음 그림은 이 패턴의 흐름을 나타낸 것입니다. 작업 스케줄러가 02:00에 PowerShell 스크립트를 기동 → 스크립트가 집계・파일 처리・로그 출력을 수행하고 결과 CSV와 요약을 출력 → 이를 SharePoint 라이브러리에 배치 → 배치를 「파일이 생성되었을 때」 트리거가 감지해 클라우드 플로우가 기동 → 플로우가 요약 내용을 확인해, 정상 종료라면 Teams로 완료 알림, 오류가 있으면 담당자에게 알림하고 필요하면 승인・대응 플로우로 전달, 이라는 한 방향 흐름입니다.

flowchart TD
    T[작업 스케줄러 02:00 기동] --> PS[PowerShell 스크립트<br/>집계・파일 처리・로그 출력]
    PS --> OUT[결과 CSV와 요약 출력]
    OUT --> UP[SharePoint 라이브러리에 배치]
    UP --> TRG[클라우드 플로우 기동<br/>파일이 생성되었을 때]
    TRG --> CHK{요약 내용}
    CHK -- 정상 종료 --> OK[Teams로 완료 알림]
    CHK -- 오류 있음 --> NG[담당자에게 알림<br/>필요하면 승인・대응 플로우로]

PowerShell에서 SharePoint로 배치하는 방법은 작업이 실행되는 방식에 따라 선택합니다. 출력 대상 폴더를 OneDrive/SharePoint 동기화 대상으로 해두는 방법(스크립트는 로컬 폴더에 쓰기만 하면 됨)이 가장 간단하지만, 동기화 클라이언트는 로그인 중인 사용자 세션에서 동작하는 앱입니다. “사용자가 로그온했는지 여부와 관계없이 실행” 설정의 야간 작업이나, 아무도 로그인하지 않은 서버에서는 동기화가 동작하지 않아, 로컬에 쓴 파일이 업로드되지 않은 채로 플로우도 기동하지 않는 헛수고가 됩니다. 주간에 사람이 있는 PC에서 동작시키는 소규모 운영이라면 동기화로 충분하지만, 야간・무인 실행이 전제라면 PnP.PowerShell이나 Graph API로 스크립트에서 직접 업로드하는 방법을 쓰거나, 동기화용으로 로그인을 유지하는 세션을 준비해 감시 대상에 포함시켜 주십시오. 인증 준비는 늘어나지만 “뒀어야 할 파일이 없다”를 구조적으로 막을 수 있습니다.

PnP.PowerShell은 SharePoint Online이나 Teams 등 Microsoft 365를 조작하기 위한 커뮤니티 제작(Microsoft 공식 제품이 아님) 오픈소스 PowerShell 모듈입니다. 700개가 넘는 명령을 갖추고 있어, 파일 업로드나 목록 조작을 스크립트에서 직접 수행할 수 있습니다. 다만 예전에는 공용 Entra ID 앱으로 손쉽게 연결할 수 있었지만, 2024년 9월에 그 앱이 폐지되어 이용자가 자신의 Entra ID 앱을 등록하는 것이 필수가 되었습니다. “모듈을 넣으면 바로 동작한다”가 아니게 되었으므로, 도입을 판단할 때는 이 앱 등록과 권한 부여 공수까지 감안해 주십시오.¹⁴

이 패턴을 추천하는 이유는 경계가 파일이라는 눈에 보이는 형태로 고정된다는 점입니다. PowerShell 쪽은 Power Automate의 존재를 모르고, Power Automate 쪽은 스크립트의 내용을 모릅니다. 한쪽이 고장 났을 때 SharePoint에 파일이 있는지 없는지만 보면 어느 쪽 문제인지 즉시 분리할 수 있습니다. 담당도 나눌 수 있습니다. 스크립트는 정보시스템, 알림 플로우는 현장의 능숙한 사람, 이라는 분업이 그대로 성립합니다. 게다가 놓인 파일 자체가 실행 기록 28일 문제⁷를 보완하는 증적으로도 기능합니다.

패턴 b: Power Automate for desktop에서 PowerShell을 호출하기

Power Automate for desktop(PAD)에는 「PowerShell 스크립트 실행(Run PowerShell script)」 액션이 있어, 데스크톱 플로우 안에서 임의의 PowerShell 코드를 실행하고 출력을 변수(PowershellOutput)로 받을 수 있습니다.⁶ 기존 스크립트 자산을 플로우의 부품으로 호출할 수 있으므로, “처리의 본체는 스크립트 그대로, 기동과 전후의 화면 조작만 PAD에 맡기는” 구성을 짤 수 있습니다.

이 액션의 설정 항목은 세 가지뿐입니다.⁶

출력은 PowershellOutput(스크립트의 출력)과 ScriptError(실행 중 발생한 오류)라는 두 변수로 받습니다. 값을 플로우로 돌려주려면 PowerShell 쪽에서 Write-Output에 전달하는 것이 공식 작성법입니다.⁶

# PAD의 액션 설정 "PowerShell code to run" 란에 붙여넣는 것을 상정한 최소 예시.
# %InputFolder% 는 PAD 쪽 변수로, PowerShell이 동작하기 전에 문자열로 치환됨
$targetFolder = '%InputFolder%'
$count = (Get-ChildItem -LiteralPath $targetFolder -Filter '*.csv' -File).Count

# Write-Output으로 반환한 내용이 PowershellOutput 변수에 들어감
Write-Output $count

즉 PAD 쪽에서 보면 이 부품의 입구는 “코드 본문에 넣는 변수”, 출구는 “PowershellOutput 문자열”, 이렇게 두 가지뿐입니다. 반환값이 구조화되지 않고 문자열로 반환되기 때문에, 여러 값을 돌려주고 싶다면 CSV 한 행이나 JSON으로 정리해 PowershellOutput을 후속 단계에서 파싱하는 설계가 됩니다. 기본 타임아웃이 10초뿐이라는 점을 포함해, “야간 배치 본체를 이 액션에 통째로 얹는” 용도에는 적합하지 않습니다. 긴 처리는 다음에 드는 주의점도 함께 감안해 판단해 주십시오.

다만 주의점이 세 가지 있습니다. 첫째, 이 액션은 내부에서 powershell.exe, 즉 Windows PowerShell 5.1을 기동합니다.¹⁵ PowerShell 7을 전제로 작성한 스크립트는 그대로는 동작하지 않을 수 있습니다. 둘째, 타임아웃 설정(기본값 10초)이 있어, 장시간 배치를 호출할 경우 명시적으로 늘리거나 무제한으로 설정해야 합니다.⁶ 셋째, 이를 무인으로 정시 실행하고 싶은 경우 클라우드 플로우로부터의 트리거가 프리미엄 기능이며⁴, 무인 실행 라이선스와 실행 머신 관리도 필요해집니다. “작업 스케줄러 대신 PAD로 정시 실행한다”는 것에 추가 비용을 지불할 가치가 있는지는 냉정하게 봐야 합니다. 이미 PAD로 RPA(화면 조작)를 운영하고 있어 실행 기반이 갖춰진 회사라면 선택지가 되지만, 그렇지 않다면 패턴 a로 충분합니다.

패턴 c: HTTP 요청을 받는 자체 API

클라우드 플로우의 「HTTP 요청 수신 시(When an HTTP request is received)」 트리거로 플로우에 URL을 부여해 PowerShell 쪽에서 Invoke-RestMethod로 호출해 기동하는 방법, 또는 반대로 사내에 작은 Web API를 세워 플로우에서 호출하는 방법입니다. 이 트리거는 프리미엄인 HTTP 요청/응답 커넥터에 속합니다.¹⁶ 호출자 제한(테넌트 내 사용자만 등)을 구성할 수 있는 OAuth 인증 구조도 마련되어 있습니다.¹⁷

실시간성이 높고 매개변수도 전달할 수 있는 가장 유연한 패턴이지만, URL 관리・인증・오류 시 재전송 등 생각해야 할 것이 단숨에 개발의 영역으로 들어갑니다. 여기까지 오면 그것은 이미 “Power Automate와 PowerShell의 연동”이 아니라 작은 시스템 개발이므로, 자체적으로 안고 갈지 외부에 설계를 맡길지를 포함해 판단해야 할 상황입니다.

정리하면, 먼저 패턴 a, PAD 기반이 이미 있다면 b, 실시간성 요건이 명확할 때만 c입니다. 느슨한 결합의 설계는 파일 연동 일반에 통하는 이야기로, 배타 제어나 주고받는 방식은 “파일 연계의 배타 제어 기초 지식 - 파일 락과 원자적 claim의 베스트 프랙티스“에서도 다루고 있습니다.

7. “둘 다 할 줄 아는 사람이 없다” 문제

여기까지 기술로 판단 기준을 적어 왔지만, 실제 현장에서 마지막으로 효력을 발휘하는 것은 “누가 유지보수할 수 있는가”입니다. PowerShell을 쓸 수 있는 사람이 정보시스템에 1명, Power Automate를 다룰 수 있는 사람이 현장에 1명, 둘 다 아는 사람은 0명. 중소기업에서는 이것이 흔합니다.

그렇기 때문에 기술적으로는 PowerShell이 적합한 처리라도, 만들 수 있는 사람이 퇴사 예정이라면 Power Automate로 만드는(혹은 그 반대) 판단은 충분히 합리적입니다. 도구의 우열보다 5년 후에도 그것을 고칠 수 있는 사람이 사내에 있는가가 더 중요합니다. 판단표(3장)는 “유지보수할 수 있는 사람이 있다는 전제에서의 최적해”이며, 사람이 없다면 최적해 쪽을 사람에게 맞춰 구부립니다.

그런 다음, 어느 도구든 공통으로 해야 할 일이 두 가지 있습니다.

• 존재의 목록화. 작업 스케줄러의 작업 목록(어느 머신에서・몇 시에・무엇이・누구의 관리 하에 동작하는가)과, Power Automate의 플로우 목록(소유자・연결・목적)을 같은 대장 한 장으로 정리합니다. 두 계통이 혼재하는 회사에서 가장 무서운 것은 한쪽 계통이 다른 쪽에서 보이지 않는 것입니다.
• 인계 가능한 형태로의 보존. 스크립트는 Git으로, 작업 정의는 등록 스크립트로⁹, 플로우는 공동 소유자 설정과 내보내기로. 사양서 없는 자동화는 소스도 사양서도 없는 시스템의 소형판이 대량 생산되는 것과 마찬가지입니다. 플로우 쪽의 구체적인 인계 설계는 속인화 대책 글에 정리했습니다.

8. 정리

PowerShell+작업 스케줄러와 Power Automate는 경쟁하는 도구가 아니라, 담당 범위가 거의 겹치지 않는 별개의 도구입니다. 로컬・서버・파일・대량 데이터는 PowerShell로, Microsoft 365상의 데이터와 알림・승인은 Power Automate로. 이 기본선으로 대부분의 자동화는 둘 위치가 정해집니다.

경계를 넘나드는 업무는 무리하게 어느 한쪽으로 몰아넣지 말고, SharePoint에 둔 파일을 경계로 한 느슨한 결합으로 연결하는 것이 라이선스 면에서도 유지보수 면에서도 견실합니다. PowerShell의 알림이 힘든 점(Send-MailMessage 비권장)과 Power Automate의 온프레미스 도달이 힘든 점(게이트웨이・RPA는 프리미엄)은, 각각 상대방의 특기 분야가 그대로 보완해 줍니다.

그리고 도구 선정과 같은 무게로, “누가 유지보수할 것인가”, “어디에 무엇이 동작하고 있는가”를 처음에 정해두는 것. 두 계통의 자동화가 혼재하는 것 자체는 건전합니다. 무질서하게 섞이는 것만이 문제입니다. 사내 자동화의 전체상을 정리하고 싶다, 어느 쪽으로 만들어야 할지 개별적으로 판단해 달라는 단계부터의 상담도 받고 있습니다.

관련 글

• Power Automate로 업무 자동화하기 ── 클라우드 플로우・데스크톱 플로우 구분과 오류 처리 설계
• 작업 스케줄러 작업이 실행되지 않는다・0x1로 끝난다 ── 원인 분리와 안전한 운영 설계
• PowerShell 스크립트 응용 ── 로그 조사·아카이브·리포트화를 안전하게 자동화하기
• Power Automate의 라이선스 ── Microsoft 365로 어디까지 무료인가, 프리미엄이 필요한 것은 언제인가
• Power Automate의 속인화 대책 ── 만든 사람이 퇴사해도 플로우가 멈추지 않으려면
• Power Automate로 정기 실행 플로우를 설계하기 ── 월말 처리・영업일 판정・독촉의 실무

관련 상담 영역

합동회사 코무라소프트는 PowerShell을 통한 사내 배치 정비부터 Power Automate를 포함한 자동화 기반의 설계 리뷰까지, “어느 도구로 만들어야 하는가”의 판단을 포함해 상담을 받고 있습니다.

• 기술 상담・설계 리뷰
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Power Automate와 PowerShell 중 어느 쪽으로 자동화를 만들어야 하나요?

대상이 어디에 있는지로 나누는 것이 기본입니다. 로컬 파일・공유 폴더・서버・데이터베이스・OS 조작 등 사내 Windows 환경이 대상이라면 PowerShell+작업 스케줄러 쪽이 안정적이고 유지보수하기 쉬운 경우가 많습니다. SharePoint나 Outlook, Teams 등 Microsoft 365상의 데이터와 알림・승인이 대상이라면 Power Automate의 클라우드 플로우가 적합합니다. 처리 본체와 알림을 나누어 생각해, 무거운 처리는 PowerShell, 사람에게 보내는 알림이나 승인은 Power Automate로 분담하는 방식도 현실적입니다.

PowerShell에서 메일이나 Teams로 알림을 보내는 것은 어렵나요?

전통적으로 쓰여 온 Send-MailMessage 명령은 SMTP 서버로의 안전한 연결을 보장하지 않기 때문에 공식적으로 비권장(obsolete)으로 지정되어 있으며, PowerShell 안에 직접적인 대체 수단이 없습니다. Microsoft Graph PowerShell SDK의 Send-MgUserMail로 보내는 방법도 있지만, 앱 등록과 권한 부여 등의 준비가 필요해 알림만을 위해 쓰기에는 문턱이 높은 편입니다. 실무에서는 PowerShell은 결과를 파일에 쓰는 데까지만 담당하고, 감지와 알림은 Power Automate에 맡기는 구성이 다루기 쉽습니다.

Power Automate로 로컬 공유 폴더의 파일을 처리할 수 있나요?

가능하지만, 클라우드 플로우가 사내 네트워크의 파일에 닿으려면 온프레미스 데이터 게이트웨이 도입이 필요하고, 게이트웨이를 사용할 권리는 Microsoft 365에 딸린 Power Automate 이용권에는 포함되지 않아 상위 라이선스가 필요합니다. 데스크톱 플로우(RPA)를 클라우드 플로우에서 호출하는 구성도 프리미엄 기능입니다. 추가 라이선스 없이 해결하고 싶다면, 처리 대상 파일을 SharePoint/OneDrive 쪽으로 옮기거나, 공유 폴더 쪽 처리는 PowerShell+작업 스케줄러에 맡기는 설계를 먼저 검토하는 것이 현실적입니다.

PowerShell의 야간 배치와 Power Automate를 연동시키는 가장 간단한 방법은 무엇인가요?

파일을 통한 느슨한 연결을 권장합니다. 작업 스케줄러로 동작하는 PowerShell이 처리 결과의 CSV나 요약 파일을 SharePoint 라이브러리에 두고, Power Automate 쪽은 「파일이 생성되었을 때(속성만)」 트리거로 감지해 알림이나 승인으로 연결하는 구성입니다. 어느 쪽 구조도 상대방의 내부를 몰라도 되기 때문에, 한쪽이 고장 나도 문제를 쉽게 분리할 수 있고 담당자를 나눌 수도 있습니다. Power Automate for desktop의 「PowerShell 스크립트 실행」 액션으로 직접 호출하는 방법도 있지만, 라이선스와 머신 관리라는 전제가 늘어납니다.

저자 프로필

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

Go Komura

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

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