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 리스트에 다시 써서 남깁니다.
• 마지막에는 기술이 아니라 유지보수할 사람이 있는 쪽으로 만드는 것이 정답이 되는 경우도 많습니다. 만든 사람만 고칠 수 있는 자동화는 도구가 무엇이든 같은 위험입니다.

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

2. 두 도구의 성격

먼저, 둘이 서로 다른 무대 위의 도구임을 확인해 둡니다.

표의 「변경 관리」 행을 보완합니다. 플로 내보내기는 Power Automate 포털에 로그인한 뒤, 왼쪽 탐색의 「내 플로」>「클라우드 플로」에서 대상 플로를 고르고, 메뉴의 「내보내기」 옆 아래쪽 화살표에서 「패키지 (.zip)」를 고르는 조작입니다. 꺼낼 수 있는 것은 zip 패키지이며, 스크립트처럼 행 단위 diff 리뷰에는 맞지 않습니다. 또한 내보낼 수 있는 사람은 플로의 소유자 또는 공동 소유자만이라는 제약도 있습니다. 지속적으로 버전 관리하려면 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 cmdlet은 SMTP 서버에 대한 안전한 연결을 보장할 수 없다는 이유로 공식 사용 중단(obsolete)이며, 경고문에는 「PowerShell 안에 직접적인 대체는 없다」고 명시되어 있습니다. 대안으로 안내되는 것은 서드파티 MailKit 라이브러리이거나, Exchange Online 이용자용 Microsoft Graph PowerShell SDK(Send-MgUserMail)입니다.¹

Graph 경유 송신은 동작하지만, Microsoft Entra ID 앱 등록, 권한(scope) 부여, 인증서 또는 시크릿 관리까지, 알림 한 통을 위해 짊어질 준비가 상당합니다. 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 라이선스와 표준/프리미엄 커넥터의 경계」에서 정리했으니 판단 전에 확인하세요.

추가 비용 없는 현실적인 해는 둘입니다. 처리 대상 파일 장소를 SharePoint/OneDrive로 옮겨 버리거나, 공유 폴더 쪽 처리는 PowerShell에 맡기고 Power Automate는 클라우드 쪽 일만 맡거나. 후자가 다음 장의 연동 패턴입니다.

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

수십만 행 CSV를 한 행씩 플로 루프로 도는 처리는 Power Automate의 설계 대상이 아닙니다. 라이선스마다 하루당 액션 실행 수 상한도 있고, Microsoft 365에 포함된 이용 권한에서는 사용자당 6,000액션/일입니다.³ 대량 건수의 대사·집계·변환은 PowerShell이나 .NET으로 쓰면 몇 분이면 끝나는 처리이기도 합니다. 구체적인 쓰는 법은 「PowerShell 실용 명령 모음 ── 일상 작업에서 자주 쓰는 작은 기능을 늘리기」에서 다룬 Group-Object나 Compare-Object 조합을 그대로 쓸 수 있습니다.

또한 조건 분기가 깊게 쌓이는 로직은 플로 화면에서 읽기 어렵고 테스트도 쓸 수 없습니다. 한 번 실행이 최장 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이 넘는 cmdlet을 갖추고, 파일 업로드나 리스트 조작을 스크립트에서 직접 할 수 있습니다. 다만 예전에는 공용 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을 쓸 수 있는 사람이 정보시스템에 한 명, Power Automate를 만질 수 있는 사람이 현장에 한 명, 둘 다 아는 사람은 제로. 중소기업에서는 이것이 보통입니다.

그래서 기술적으로는 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 라이선스와 표준/프리미엄 커넥터의 경계
• 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 cmdlet은 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.