Power Automate의 속인화 대책 ── 만든 사람이 퇴사해도 플로우가 멈추지 않으려면

‘Power Automate에 정통한 직원이 있어서 사내 여러 업무를 자동화해 주었다. 그런데 그 직원이 다음 달 퇴사하게 되어, 어떤 플로우가 무엇을 하고 있는지 아무도 모른다’ ── 이런 상담이 최근 눈에 띄게 늘고 있습니다. 이미 퇴사가 끝난 상태로, ‘지난달부터 주문 알림 메일이 오지 않게 되었는데 고칠 수 있는 사람이 없다’는 단계에서 의뢰가 들어오는 경우도 있습니다.

예전에 「소스 코드도 사양서도 없는 시스템을 인계받았다면 ── 멈추지 않고 운용·보수하기 위한 실무 절차」라는 글에서, 만든 사람이 없어진 시스템의 인수인계를 다뤘습니다. Power Automate 플로우는 노코드로 만들 수 있는 만큼 같은 상황이 더 쉽게 일어나며, 게다가 실행 파일처럼 ‘그 자리에 계속 존재한다’는 보장이 없습니다. 플로우는 작성자의 계정과 연결(커넥션)에 강하게 묶여 있어서, 계정이 비활성화·삭제되는 순간 망가지는 방식이 달라지기 때문입니다. 이 글에서는 소유자가 없어졌을 때 플로우가 어떻게 되는지에 대한 사실 관계를 Microsoft 공식 문서로 확인하면서, 퇴사 전에 해야 할 일, 퇴사 후에 할 수 있는 일, 그리고 애초에 속인화시키지 않기 위한 목록화와 실행 계정 설계를, 중소기업의 실무 순서로 정리합니다.

1. 먼저 결론

• 플로우는 작성자가 소유자가 되며, 실행에 사용하는 연결(SharePoint나 Outlook에 대한 인증)은 만든 본인의 계정에 묶입니다. 공유된 연결은 그 플로우 안에서만 사용할 수 있고, 다른 사람이 만든 연결의 자격 증명은 공동 소유자라도 변경할 수 없습니다.¹
• 소유자가 퇴사해도 공동 소유자가 남아 있으면 플로우 자체는 계속 동작합니다. 다만 퇴사자의 연결을 사용하는 작업은 실패하게 되므로, 연결 교체가 필요합니다.¹²
• 유효한 소유자가 한 명도 없는 플로우는 ‘고아 플로우(orphaned flow)’가 됩니다. 관리자는 Power Platform 관리 센터의 환경 페이지(리소스→플로우)에서 이를 발견하고, ‘공유’에서 새 소유자를 추가할 수 있습니다. PowerShell(Get-AdminFlow, Set-AdminFlowOwnerRole)을 이용한 일괄 처리도 가능합니다.²
• 퇴사 전이라면 ‘공동 소유자 추가’와 ‘소유자 변경’의 2단계입니다. 소유자 교체(재직 중의 인수인계)는 솔루션 대응 플로우에서만 가능하며, 비솔루션 플로우는 솔루션에 추가하거나 내보내기/가져오기로 다시 만들어야 합니다.³⁴
• 알림 메일이 본인 명의로 계속 발송되는 문제는, 공유 메일함에서의 발송(‘공유 메일함에서 메일 보내기(V2)’ 작업)으로 옮겨 두면 퇴사의 영향을 받지 않습니다. Microsoft의 가이드도 정형화된 알림은 개인 명의가 아닌 공유된 발신자를 사용할 것을 권장하고 있습니다.⁵⁶
• 사용자 계정을 공용하는 서비스 계정은 모범 사례로서는 권장되지 않으며, 미션 크리티컬한 플로우는 서비스 주체 소유가 공식적으로 권장됩니다. 다만 중소기업에서는 설정·라이선스의 문턱이 있으므로, 이 글의 5장에서 현실적인 구분 사용을 정리합니다.⁴⁷⁸
• 대책의 첫걸음은 기술이 아니라 목록화입니다. 사내에 어떤 플로우가 있는지 관리 센터와 Get-AdminFlow로 목록화하고, 최소한의 플로우 대장(이름·목적·소유자·연결·영향 업무)을 만드는 것부터 시작합니다.⁹

2. 플로우의 속인화는 어떻게 일어나는가

Power Automate의 속인화는 악의나 태만이 아니라, 선의가 쌓여서 일어납니다. 전형적인 경과는 이렇습니다.

1. 현장에 능통한 사람이 자신의 작업을 편하게 하려고 플로우를 만듭니다. ‘Forms 응답을 Excel에 옮겨 적는다’ 정도의 작은 것입니다.
2. 편리하다 보니 주변 사람이 편승합니다. ‘그 알림, 우리 과에도 보내 줘’, ‘주문서 저장도 안 될까?’와 같은 요청이 모여 플로우가 늘고 커집니다.
3. 어느새 업무의 근간에 파고듭니다. 수주의 최초 연락, 청구서 저장, 결재의 회람과 같이 ‘멈추면 업무가 정체되는’ 처리가 그 사람의 개인 계정 플로우로 돌아가게 됩니다.
4. 아무도 내용을 모른 채 안정적으로 가동됩니다. 동작하고 있는 것을 건드릴 이유가 없으므로 인수인계도 문서도 만들어지지 않습니다. ‘동작하고 있으니 건드릴 수 없다’가 그대로 ‘아무도 건드릴 수 없다’로 바뀝니다.

여기까지의 구도는 개발 담당자의 퇴사로 소스도 사양서도 없는 시스템이 남는 이야기와 같습니다. 다만 Power Automate에는 레거시 시스템보다 까다로운 점이 두 가지 있습니다. 첫째, 만들어지는 곳이 개인의 ‘마이 플로우’이며, 본인 외에는 존재 자체가 보이지 않는다는 점입니다. 서버에 실행 파일이 남는 시스템과 달리, 플로우는 목록화하지 않는 한 목록에조차 나타나지 않습니다. 둘째, 플로우의 실행이 작성자의 계정과 연결에 의존하고 있다는 점입니다. 퇴사 처리로 계정을 비활성화·삭제한 순간, 영향이 드러납니다. 다음 장에서 이 동작을 정확히 확인합니다.

먼저 용어 하나 ── ‘솔루션 대응 플로우’란

이후 장에서 반복해서 나오므로 여기서 짚어 두겠습니다. 솔루션이란 플로우와 그 구성 요소(연결 참조, Dataverse 테이블, 앱 등)를 한데 모아 옮기기 위한 그릇입니다. 이용에는 Dataverse가 있는 환경이 필요하며, 솔루션 안에 넣어 만들거나(또는 나중에 추가한) 플로우를 솔루션 대응 플로우(solution-aware flow)라고 부릅니다.¹⁰

인수인계의 맥락에서 중요해지는 것은 다음의 차이입니다.

‘왜 솔루션 대응 플로우라면 소유자를 변경할 수 있는가’라는 의문에는 이 표의 첫 번째 줄이 답이 됩니다. 일반 플로우는 소유자가 플로우 자체의 식별 정보에 포함되어 있어 나중에 바꿔 달 수 없습니다. 솔루션 대응 플로우는 그 연결이 분리되어 있기 때문에 소유자를 교체할 수 있습니다.³ 즉 속인화 대책으로 가장 효과적인 것은 중요한 플로우를 처음부터 솔루션에 넣어 두는 것입니다. 도입 판단은 7장에서 다룹니다.

3. 계정이 사라지면 플로우는 어떻게 되는가

플로우 자체는 사라지지 않지만 ‘고아 플로우’가 된다

먼저 전제로, 퇴사자의 계정을 Microsoft Entra ID에서 삭제해도 그 사람이 만든 플로우는 자동으로 삭제되지 않습니다. 플로우와 연결은 ‘관리자가 수동으로 확인·삭제하는 것’으로 분류되어 있어 임의로 사라지는 일은 없는 반면, 실행 기록은 계정 삭제로 자동으로 삭제됩니다. 과거의 실행 기록을 증적으로 신뢰하고 있는 경우에는 주의가 필요합니다.¹¹

플로우가 남아 있어도 유효한 소유자가 한 명도 없어진 플로우는 고아 플로우(orphaned flow)라 불리는 상태가 됩니다. Microsoft의 지원 문서는 고아 플로우를 ‘유효한 소유자가 없는 플로우’로 정의하고, 퇴사한 사용자의 계정에 묶인 연결을 사용하는 경우 플로우가 실패할 수 있다고 명시하고 있습니다.²

연결이 본인 계정에 묶여 있다

여기가 가장 핵심적인 급소입니다. 플로우의 각 작업이 사용하는 연결(SharePoint, Outlook, Teams 등에 대한 인증)은 작성한 사용자의 자격 증명으로 동작합니다. 공유 플로우의 작성자가 퇴사한 경우에 대한 공식 FAQ는 다음과 같이 정리하고 있습니다.¹

• 공동 소유자 등 유효한 소유자가 남아 있으면 플로우 자체는 계속 동작한다
• 다만 퇴사자 명의의 연결을 사용하는 작업은 실패할 수 있으므로, 연결의 자격 증명을 갱신(실제로는 플로우 편집 화면에서 각 작업의 연결을 다른 계정의 연결로 교체)할 필요가 있다

또한 공유된 연결은 그 플로우 안에서만 사용할 수 있으며, 공동 소유자라 하더라도 다른 소유자가 만든 연결의 자격 증명을 변경할 수는 없습니다.¹ 즉 ‘공동 소유자를 추가해 두었으니 괜찮다’는 절반만 정답이며, 퇴사자의 연결을 플로우에서 몰아내는 작업(각 작업에서 자신의 연결로 교체하여 저장)을 해야 비로소 인수인계가 완료됩니다.

라이선스까지 함께 걸리는 문제 ── 14일 만에 꺼지는 경우

프리미엄 커넥터 등을 사용하는 플로우는 소유자의 라이선스로 동작합니다. 공식 라이선스 FAQ에 따르면, 소유자가 퇴사하는 등의 이유로 라이선스 뒷받침을 잃은 프리미엄 플로우는 성능이 저하된 상태로 격하되고, 모든 소유자에게 통지한 뒤 대응이 없으면 14일 만에 꺼집니다.⁴ ‘왠지 느려졌다’의 2주 뒤에 멈춘다는, 시한이 정해진 동작입니다. 표준 커넥터만 사용하는 플로우라면 이 문제는 잘 일어나지 않지만, 어떤 플로우가 프리미엄 기능을 사용하고 있는지는 목록화를 통해 파악해 두어야 할 정보입니다(표준/프리미엄의 경계는 「Power Automate 라이선스와 표준/프리미엄 커넥터의 경계」에서 정리했습니다).

메일이 본인 명의로 계속 발송되는 문제

간과하기 쉬운 것이 알림의 ‘명의’입니다. ‘메일 보내기(V2)’ 작업은 연결한 사용자의 메일함에서 발송되기 때문에, 플로우가 계속 동작하는 한 알림 메일은 작성자 개인의 명의로 계속 발송됩니다. 재직 중에는 ‘왜 저 사람한테서 매일 아침 메일이 오지?’로 끝나지만, 퇴사 후에는 계정 비활성화와 함께 발송 자체가 실패합니다. 반대로 공동 소유자가 연결만 자신의 것으로 교체하면, 이번에는 그 사람의 명의로 모든 알림이 발송되게 됩니다.

Microsoft의 가이드는 업무상 정형화된 알림을 개인 명의로 보내는 것을 피하고, 공유된 발신자를 사용할 것을 권장하고 있습니다. Outlook이라면 ‘공유 메일함에서 메일 보내기(V2)’ 작업으로 공유 메일함(예: noreply-flow@example.co.jp)에서 발송할 수 있으며, 발송 기록도 공유 메일함의 보낸 편지함에 남습니다(발송에는 메일함에 대한 접근 권한이 필요합니다). Teams 알림이라면 ‘플로우 봇으로 게시’ 계열의 작업이 같은 역할을 합니다. 아울러 ‘이 메일은 Power Automate에서 자동으로 발송되고 있습니다. 문의는 ◯◯로’라는 서명을 넣어 두면, 담당자가 바뀌어도 수신 측이 헷갈리지 않습니다.⁵⁶

4. 퇴사 전에 할 일·퇴사 후에 할 수 있는 일

퇴사 전 ── 2주면 충분하다

퇴사나 이동이 정해지면 다음 6단계로 진행합니다. 전체 그림은 이렇습니다(번호는 아래 각 단계에 대응합니다).

flowchart TD
    Start["퇴사·이동이 결정됨"] --> S1["① 플로우를 목록화·분류"]
    S1 --> S2["② 공동 소유자를 추가"]
    S2 --> Q{"솔루션 대응<br/>플로우인가?"}
    Q -- 예 --> S3a["③ 상세 화면에서 소유자 변경"]
    Q -- 아니요 --> S3b["③ 솔루션에 추가한 후 변경<br/>또는 새로 작성"]
    S3a --> S4["④ 각 작업의 연결을 교체"]
    S3b --> S4
    S4 --> S5["⑤ 알림 발신자를 공유 메일함으로"]
    S5 --> S6["⑥ 퇴사자 계정이 비활성화되어도 동작하는지 테스트"]

1. 플로우를 목록화·분류합니다. 마이 플로우 화면을 본인과 함께 열어 ‘업무에 사용되는 것’, ‘개인의 효율화’, ‘실험의 잔재’로 분류합니다. 이때 6장의 플로우 대장 초안을 만들어 두는 것이 효율적입니다.
2. 공동 소유자를 추가합니다. 후임자와 정보 시스템 담당자(없다면 관리자 권한을 가진 사람)를 플로우의 소유자로 추가합니다. 공동 소유자는 실행 기록 확인, 플로우의 편집·중지·삭제, 소유자 추가까지 할 수 있습니다.¹ 다만 공동 소유자 추가는 최소한의 응급 조치이며, 일상적인 공유는 가능한 한 실행 전용(run-only)으로 하는 것이 공식적으로 권장됩니다.⁷
3. 소유자를 교체합니다. 솔루션 대응 플로우라면 플로우의 상세 화면에서 소유자를 후임자(또는 서비스 계정)로 변경할 수 있습니다. 변경 후에는 기존 소유자와 새 소유자가 공동 소유자가 되며, 예약 실행·자동 실행 플로우는 새 소유자의 라이선스로 동작하게 됩니다(반영에 최대 7일. 플로우를 열어 저장하면 즉시 반영).³ 비솔루션 플로우는 2장에서 본 대로 소유자를 교체할 수 없으므로, Dataverse를 사용할 수 있는 환경이라면 솔루션에 추가한 후 변경하고, 사용할 수 없다면 내보내기/가져오기나 ‘다른 이름으로 저장’으로 새 소유자 아래에 다시 만듭니다.³⁴
4. 연결을 교체합니다. 앞 장에서 본 대로, 이 단계를 건너뛰면 인수인계가 완료되지 않습니다. 플로우 편집 화면에서 각 작업의 연결을 새 계정의 연결로 전환하여 저장합니다. 소유자에서 퇴사자를 제외할 때도, 그 사람의 자격 증명을 사용하던 연결의 갱신이 필요합니다.¹
5. 알림 발신자를 옮깁니다. 개인 명의의 ‘메일 보내기(V2)’를 사용하는 플로우는 3장에서 본 대로 공유 메일함에서의 발송으로 전환합니다. 이 부분을 고쳐 두지 않으면, 인수인계 후 후임자 명의로 모든 알림이 발송되게 됩니다.⁵⁶
6. 테스트합니다. 가능하다면 퇴사자의 계정을 비활성화한 상태(또는 휴가 중 등 본인이 조작하지 않는 기간)에서 한 차례 실행해, 퇴사 후와 같은 조건에서 동작하는지 확인합니다.

퇴사 후 ── 관리자가 할 수 있는 일

이미 퇴사가 끝나 소유자가 없는 경우에도 방법은 있습니다.

• 관리 센터에서 고아 플로우를 찾습니다. 화면 전환은 다음과 같습니다.²

  1. Power Platform 관리 센터에 로그인한다
  2. 왼쪽 메뉴의 ‘환경’(Environments)에서 대상 환경을 선택한다
  3. 환경의 상세 페이지에서 ‘리소스’(Resources)→ ‘플로우’(Flows)를 연다
  4. 목록의 ‘소유자’(Owners) 열을 본다. 이 칸이 비어 있는 플로우가 고아 플로우다

  즉 ‘소유자 열이 비어 있는 행을 찾는 것’이 이 화면에서의 유일한 목적입니다. 플로우가 많은 환경에서는 이 열로 정렬하거나, 뒤에서 설명할 PowerShell로 기계적으로 찾아내는 편이 확실합니다.

• ‘공유’에서 새 소유자를 추가합니다. 목록에서 대상 플로우를 선택하고, ‘공유’(Share)에서 새 소유자의 계정을 추가하여 저장합니다.² 참고로 관리자가 플로우의 내용을 수정하고자 할 때도, 먼저 자신을 소유자·공동 소유자로 추가하는 것이 전제입니다.³
• 수가 많으면 PowerShell로 일괄 처리합니다. 관리용 모듈(Microsoft.PowerApps.Administration.PowerShell)의 Get-AdminFlow -CreatedBy <퇴사자의 개체 ID>로 퇴사자가 만든 플로우를 열거하고, Set-AdminFlowOwnerRole -RoleName CanEdit으로 공동 소유자를 부여할 수 있습니다. 현재 권한은 Get-AdminFlowOwnerRole로 확인합니다.²
• 연결을 다시 만듭니다. 소유자를 인수받은 후, 퇴사자 명의의 연결을 새 계정의 연결로 교체합니다. 퇴사자의 계정이 이미 삭제된 경우 기존 연결은 복구할 수 없으므로, 새 연결을 만들어 각 작업에 다시 할당하게 됩니다.¹

보충하자면, 승인 플로우에 한해서는 ‘승인 대기 요청이 퇴사자에게 할당된 채로 남아 있다’는 또 다른 막힘도 있습니다. 승인자 측의 재할당이나 에스컬레이션 설계는 「Power Automate로 승인 흐름 만들기」의 5~6장에서 다뤘으니 그쪽을 참조해 주십시오.

5. 실행 계정 설계 ── 개인·서비스 계정·서비스 주체

인수인계 소동을 반복하지 않으려면 ‘업무 플로우를 누구 명의로 돌릴 것인가’를 처음부터 정해 두는 것이 근본 대책입니다.

비교표에 나오는 ‘Process 라이선스’만 먼저 설명해 두겠습니다. Power Automate 라이선스에는 크게 두 종류가 있으며, 사용자 라이선스가 ‘사람’에게 할당하는 것인 데 비해, Process 라이선스는 ‘플로우(또는 실행 머신)’ 자체에 할당하는 용량 라이선스입니다.¹² 클라우드 플로우에 할당하면, 그 플로우를 소유·실행하는 사용자가 어떤 라이선스를 가지고 있는지와 관계없이 프리미엄 커넥터와 커스텀 커넥터를 사용할 수 있게 됩니다(할당에는 플로우가 솔루션에 들어 있어야 한다는 조건이 있습니다).¹²

서비스 주체는 사람이 아니므로 사용자 라이선스를 가질 수 없습니다. 그래서 ‘프리미엄 기능을 사용하는 플로우를 서비스 주체 소유로 한다면, 플로우 쪽에 Process 라이선스를 붙인다’는 이야기가 됩니다. 반대로 표준 커넥터만 사용하는 플로우라면 필요 없습니다.⁸ 표준/프리미엄의 경계 자체는 「Power Automate 라이선스와 표준/프리미엄 커넥터의 경계」에서 정리했습니다.

그 위에서 선택지를 비교합니다.

실무적인 구분 사용의 기준은 이렇습니다.

• 개인의 효율화 도구는 개인 계정 그대로 두어도 괜찮습니다. 전부를 엄격하게 관리하려고 하면 현장의 자동화 자체가 위축됩니다.
• 부서가 의존하는 업무 플로우는 적어도 알림 발신자를 공유 메일함으로 옮기고⁵, 공동 소유자를 2명 이상으로 합니다. 실행용 서비스 계정을 세울 경우에는 권한을 필요 최소한으로 하고, 자격 증명에 접근할 수 있는 사람을 몇 명으로 제한합니다. Microsoft 자신도 서비스 계정을 쓸 바에는 서비스 주체를, 이라고 안내하고 있지만⁴, 표준 커넥터 중심의 중소 규모 운영에서는 ‘전용 계정 + 엄격한 비밀번호 관리’가 현실적인 해법이 되는 경우도 많습니다.
• 전사의 근간에 관련된 플로우(수주·청구·지급에 직결되는 것)는 서비스 주체 소유를 검토할 가치가 있습니다. 소유자가 사람이 아니게 되므로 퇴사의 영향을 받지 않고, 소유자의 라이선스 박탈로 플로우가 멈추는 사고도 막을 수 있습니다.⁸ 다만 서비스 주체는 공동 소유자가 될 수 없다(소유자로 삼는 용도만 가능), 프리미엄 기능에는 Process 라이선스가 필요하다는 제약이 있으므로, 여기까지 왔다면 IT 부서나 외부 전문가와 함께 설계해야 할 단계입니다.⁸

참고로 서비스 계정을 세우는 경우에도, 플로우 작성이나 사소한 수정을 전부 그 명의로 하는 것은 피하고, 만드는 사람은 자신의 계정으로 만들고, 소유와 실행만을 서비스 계정으로 옮기는 형태로 하면 ‘누가 언제 변경했는가’의 추적 가능성을 유지할 수 있습니다.

6. 목록화와 문서화 ── 먼저 ‘무엇이 있는지’를 안다

속인화 대책의 출발점은 사내에 어떤 플로우가 있는지를 조직으로서 파악하는 것입니다. 블랙박스화된 시스템의 인수인계에서 가장 먼저 하는 것이 실행 파일과 작업의 목록화였던 것과 마찬가지로, 플로우에도 목록화의 정석이 있습니다.

플로우 목록 가져오기

• 관리 센터에서: Power Platform 관리 센터의 환경 페이지에서 ‘리소스’→’플로우’를 열면 환경 내의 플로우를 소유자와 함께 목록으로 볼 수 있습니다. 고아 플로우 발견도 여기서 합니다.²
• PowerShell에서: 관리용 명령줄 도구 Get-AdminFlow는 환경 관리자라면 관리 대상의 모든 환경을, 전역 관리자라면 테넌트 내의 모든 플로우를 반환합니다. Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv'로 그대로 CSV 대장의 씨앗이 되며, Get-AdminFlowWithHttpAction으로 HTTP 작업을 사용하는 플로우(외부 연계 가능성이 높은 것)만 골라낼 수도 있습니다.⁹ PowerShell에 익숙하지 않다면 「PowerShell 명령어의 기초 — 가장 먼저 익힐 조작과 안전한 사용법」도 참고하시기 바랍니다.

최소한의 플로우 대장

대장은 화려하게 만들지 않는 것이 오래 지속하는 요령입니다. SharePoint 목록이나 Excel로, 플로우 1개당 1행, 다음 열만 갖추게 합니다.

포인트는 ‘연결이 누구의 명의인가’ 열입니다. 소유자는 관리 화면에서 알 수 있지만, 연결의 명의는 플로우를 열어야만 알 수 있으므로 대장에 적어 두는 것이 가장 가치가 높은 정보입니다.

명명 규칙과 ‘설명’ 란

Microsoft의 코딩 가이드라인은 플로우의 구성 요소에 설명적이고 일관된 이름을 붙이고, 명명 규칙을 문서화하여 공유할 것, 코드의 주석에 해당하는 메모를 작업에 붙일 것을 권장하고 있습니다.¹³ 실무에서는 플로우 이름을 ‘[부서] 업무명 - 처리 내용’(예: ‘[영업] FAX 주문 - PDF 저장과 담당자 알림’)처럼 통일하는 것만으로도 목록의 가독성이 크게 달라집니다. 또한 플로우의 상세 화면에는 설명(Description) 란이 있으며, Copilot에 초안을 생성하게 할 수도 있으므로¹⁴, 대장의 ‘목적’과 같은 내용을 플로우 자체에도 넣어 두면 대장이 낡았을 때의 보험이 됩니다.

대장을 만들면, 오류로 멈췄을 때 누가 알아차릴 것인가라는 다음 문제가 보이기 시작합니다. 실패 시의 알림이나 재시도 설계는 「Power Automate의 오류 처리와 재시도 설계」에서 자세히 다루고 있습니다.

7. 환경과 솔루션 ── ‘기본 환경에 전부’에서 한 걸음 벗어나기

Power Platform에는 ‘환경’이라는 구획이 있으며, 아무것도 지정하지 않고 만든 플로우는 모두 기본 환경(default environment)에 들어갑니다. 기본 환경은 테넌트의 모든 사용자가 접근할 수 있으며, Microsoft 365 라이선스를 가진 직원이라면 누구나 앱이나 플로우를 만들 수 있는 곳입니다. 개인의 생산성 향상을 위한 놀이터로서는 그것으로 괜찮지만, Microsoft의 가이드 자체가 기본 환경에는 작성자의 퇴사로 인한 소유자 부재 리소스가 쌓이기 쉽다는 점, 널리 공유되거나 업무상 중요해진 플로우는 전용 환경으로 옮겨야 한다는 점을 지적하고 있습니다.¹⁵

중소기업이 곧바로 본격적인 환경 분리(개발·테스트·프로덕션)까지 갖출 필요는 없습니다. 다만 다음 두 가지는 규모가 작을 때부터 의식할 가치가 있습니다.

• 업무의 근간에 들어간 플로우는 솔루션에 넣습니다. 솔루션은 플로우와 그 구성 요소를 한데 모아 옮기기 위한 그릇으로, 여기에 넣은 플로우(솔루션 대응 플로우)는 소유자 변경을 그 자리에서 할 수 있고, 연결을 ‘연결 참조’라는 교체하기 쉬운 형태로 가질 수 있으며, 버전 기록도 사용할 수 있습니다.³¹⁰ 4장에서 본 대로 퇴사 시 인수인계의 용이함이 크게 달라집니다. 이용에는 Dataverse가 있는 환경이 필요합니다.¹⁰
• DLP 정책을 한 번은 확인합니다. 커넥터를 업무용/비업무용으로 분류하고 조합을 제한하는 데이터 손실 방지(DLP) 정책은, 무단 플로우가 사내 데이터를 외부 서비스로 흘려보내는 사고에 대한 안전망입니다.¹⁶ 거버넌스 전반의 사고방식은 「Power Automate로 업무 자동화하기」의 9장에서 다루고 있습니다.

환경 분리·ALM(개발→테스트→프로덕션 파이프라인)·CoE Starter Kit에 의한 전사 통제와 같은 이야기는 그 앞에 있지만, 플로우가 수십 개 규모가 된 뒤에 검토하면 충분합니다. 먼저 대장과 솔루션화, 그다음이 환경입니다.

8. 판단표 ── 그 플로우는 누구의 자산인가

마지막으로, 개별 플로우를 어느 수준으로 관리할지에 대한 선긋기입니다. 모든 플로우를 엄격하게 관리하는 것은 비현실적이므로, ‘멈추면 누가 곤란한가’로 3단계로 나눕니다.

최하단 상태가 되어 버린 플로우를 대하는 방법은, 서두에서 언급한 소스도 사양서도 없는 시스템의 인수인계와 같습니다. 곧바로 다시 만들 것이 아니라 트리거·연결·출력처를 관찰하여 ‘무엇을 하고 있는지’를 대장에 기록하는 것부터 시작합니다. 다행히 플로우는 소스 코드가 없는 EXE와 달리 내용이 전부 보입니다. 공동 소유자만 될 수 있다면 정의를 읽어 내는 것 자체는 어렵지 않습니다.

또한 ‘애초에 이 처리를 Power Automate로 계속 가지고 있어야 하는가’라는 물음도 있습니다. 속인화의 온상이 되기 쉬운 복잡한 플로우는 PowerShell 스크립트나 작업 스케줄러, 또는 업무 시스템 쪽의 기능으로 옮기는 편이 Git 관리나 코드 리뷰에 올릴 수 있어 인수인계하기 쉬운 경우가 있습니다. 이 구분 사용은 「Power Automate와 PowerShell·작업 스케줄러의 사용 구분」에서 정리했습니다.

9. 정리

• 플로우는 작성자의 계정과 연결에 묶여 있습니다. 퇴사로 계정이 사라져도 플로우 자체는 남지만, 실행 기록은 자동으로 삭제되고, 퇴사자 명의의 연결을 사용하는 작업은 실패하며, 프리미엄 플로우는 14일의 유예 후 꺼집니다.¹¹²⁴
• 퇴사 전이라면 공동 소유자 추가 → (솔루션 대응이라면) 소유자 변경 → 연결 교체 → 공유 메일함으로의 명의 변경 순서로, 2주면 인수인계할 수 있습니다.³¹
• 퇴사 후라도, 관리 센터의 ‘리소스→플로우’나 PowerShell(Get-AdminFlow/Set-AdminFlowOwnerRole)로 고아 플로우를 발견하고 소유자를 다시 할당할 수 있습니다. 다만 연결을 다시 만드는 것은 피할 수 없습니다.²
• 근본 대책은 플로우 대장에 의한 목록화, 명명 규칙과 설명 란, 알림 명의의 공유화, 그리고 중요한 플로우의 실행 주체를 개인에게서 분리하는 설계(서비스 계정은 신중하게, 근간은 서비스 주체)입니다.¹³⁶⁷
• ‘개인의 도구’, ‘팀의 자산’, ‘회사의 인프라’ 중 어느 것인지를 플로우별로 정하고, 관리의 무게를 거기에 맞춘다. 이것이 현장의 자동화를 위축시키지 않으면서 속인화만을 막는 현실적인 선이라고 생각합니다.

만든 본인이 이동·퇴사할 예정이 없더라도, 이 글의 4장까지를 ‘방재 훈련’으로 한 번 해 보시기를 권합니다. 플로우의 목록화나 인수인계 설계, Power Automate에 올려야 할지 말지의 구분에서 망설여지는 부분이 있다면 부담 없이 상담해 주십시오.

관련 글

• Power Automate로 업무 자동화하기 ── 클라우드 플로우・데스크톱 플로우 구분과 오류 처리 설계
• Power Automate로 승인 흐름 만들기 ── 종이와 메일 결재·신청을 전자화하다
• 소스 코드도 사양서도 없는 시스템을 인계받았다면 ── 멈추지 않고 운용·보수하기 위한 실무 절차
• Power Automate의 오류 처리와 재시도 설계 ── “동작하던 플로우가 멈춰 있었다”를 막는 법
• Power Automate의 라이선스 ── Microsoft 365로 어디까지 무료인가, 프리미엄이 필요한 것은 언제인가

관련 상담 영역

합동회사 코무라소프트에서는 담당자의 퇴사·이동으로 아무도 손댈 수 없게 된 자동화·업무 시스템의 인수인계 조사부터, Power Automate의 운용 설계 리뷰, 플로우로는 감당할 수 없게 된 처리의 시스템화까지 다루고 있습니다.

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Power Automate 플로우를 만든 담당자가 퇴사하면 플로우는 어떻게 되나요?

플로우 자체는 퇴사자의 계정을 삭제해도 자동으로 사라지지 않으며, 공동 소유자가 남아 있으면 계속 동작합니다. 다만 플로우 안의 연결(SharePoint나 Outlook에 대한 인증)은 만든 본인의 계정에 묶여 있기 때문에, 퇴사자의 연결을 사용하는 작업은 계정 비활성화·삭제로 실패하게 됩니다. 또한 유효한 소유자가 한 명도 없어진 플로우는 '고아 플로우'가 되며, 프리미엄 기능을 사용하는 플로우는 소유자의 라이선스가 사라지면 성능이 저하되고 대응하지 않으면 14일 만에 비활성화됩니다. 퇴사 전 공동 소유자 추가와 연결 교체가 중요합니다.

퇴사자가 만든 플로우를 관리자가 인수받을 수 있나요?

가능합니다. Power Platform 관리 센터에서 환경을 선택하고 '리소스'→'플로우'를 열면, 소유자가 없는 고아 플로우를 확인할 수 있으며, '공유'에서 새 소유자를 추가할 수 있습니다. 플로우가 많을 경우, 관리용 PowerShell 모듈의 Get-AdminFlow로 목록을 가져오고 Set-AdminFlowOwnerRole로 공동 소유자를 일괄 추가하는 방법도 있습니다. 다만 소유자를 인수받아도 퇴사자 명의의 연결은 그대로는 동작하지 않으므로, 플로우 안의 각 작업의 연결을 새 계정의 연결로 교체하는 작업이 별도로 필요합니다.

공동 소유자를 추가해 두면 퇴사 대책으로 충분한가요?

충분하지 않습니다. 공동 소유자는 플로우의 편집·중지·소유자 추가까지 할 수 있지만, 다른 사람이 만든 연결의 자격 증명을 변경할 수는 없으며, 공유된 연결은 그 플로우 안에서만 사용할 수 있습니다. 퇴사자의 연결을 사용하는 작업은 공동 소유자가 자신의 연결로 교체해야 비로소 계속 동작합니다. 또한 알림 메일이 퇴사자 명의로 계속 발송되는 문제도 남기 때문에, 발송은 공유 메일함에서 하도록 하고, 업무의 근간에 관련된 플로우는 실행용 계정이나 서비스 주체 소유로 옮기는 설계와 함께 고려해야 합니다.

플로우 실행용으로 공용 서비스 계정을 만들어야 하나요?

선택지는 될 수 있지만, Microsoft는 사용자 계정을 공용하는 서비스 계정을 모범 사례로서 권장하지 않습니다. 비밀번호를 여러 사람이 공유하기 때문에 누가 변경했는지 추적하기 어렵고, 비밀번호 관리 자체가 위험 요인이 되기 때문입니다. 사용할 경우에는 권한을 필요 최소한으로 하고, 접근할 수 있는 사람을 제한합니다. 미션 크리티컬한 플로우에 대해서는 사람 계정에 의존하지 않는 서비스 주체 소유가 공식적으로 권장되지만, 설정에는 IT 측의 지식이 필요하고, 프리미엄 기능을 사용할 경우 Process 라이선스가 필요하다는 점에 유의하십시오.

저자 프로필

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

Go Komura

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

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