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

「Power Automate에 밝은 직원이 있어서 사내 여기저기 업무를 자동화해 주었다. 그런데 그 사람이 다음 달 퇴사하게 되었고, 어느 플로우가 무엇을 하는지 아무도 모른다」── 이런 문의가 최근 눈에 띄게 늘고 있습니다. 이미 퇴사한 뒤에 「지난달부터 주문 알림 메일이 오지 않는데, 고칠 사람이 없다」는 단계에서 들어오는 경우도 있습니다.

이전에 「소스 코드도 사양서도 없는 시스템을 인수인계받았을 때 ── 멈추지 않고 운영·유지보수하는 실무 절차」에서, 만든 사람이 없어진 시스템의 인수인계를 다루었습니다. Power Automate 플로우는 노코드로 만들 수 있는 만큼 같은 상황이 더 잘 생기고, 실행 파일처럼 「그 자리에 계속 있다」는 보장도 없습니다. 플로우는 작성자 계정과 연결(connection)에 강하게 묶여 있어, 계정이 비활성화·삭제되는 순간 깨지는 방식이 달라지기 때문입니다. 이 글에서는 소유자가 없어졌을 때 플로우가 어떻게 되는지를 Microsoft 공식 문서로 확인한 뒤, 퇴사 전에 할 일·퇴사 후에 할 수 있는 일·애초에 속인화하지 않기 위한 인벤토리와 실행 계정 설계를 중소기업 실무 순서로 정리합니다.

1. 먼저 결론

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

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

2. 플로우 속인화는 어떻게 생기는가

Power Automate의 속인화는 악의나 태만에서가 아니라, 좋은 의도가 쌓이면서 생깁니다. 전형적인 경과는 이렇습니다.

1. 현장을 잘 아는 사람이 자기 일을 편하게 하려고 플로우를 만듭니다. 「Forms 응답을 Excel에 옮겨 적는다」 정도의 작은 것입니다.
2. 편하다 보니 주변이 따라옵니다. 「그 알림, 우리 과에도 보내 줘」「주문서 저장도 안 될까?」 같은 요청이 모여 플로우가 늘고 커집니다.
3. 어느새 업무의 핵심에 들어갑니다. 수주 1차 연락, 청구서 보관, 결재 회람처럼 「멈추면 업무가 막히는」 처리가 그 사람 개인 계정 플로우로 돌아가게 됩니다.
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로, 플로우 하나당 한 행, 다음 열만 둡니다.

핵심은 「연결이 누구 명의인지」 열입니다. 소유자는 관리 화면에서 보이지만, 연결 명의는 플로우를 열지 않으면 모르므로, 대장에 적어 둘 가치가 가장 큰 정보입니다.

명명 규칙과 「설명」 칸

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. 판단표 ── 그 플로우는 누구의 자산인가

마지막으로, 개별 플로우를 어느 수준으로 관리할지 선을 긋습니다. 모든 플로우를 엄격히 관리하는 일은 비현실적이므로, 「멈추면 누가 곤란한가」로 세 단계로 나눕니다.

맨 아래 상태가 되어 버린 플로우를 대하는 방법은, 서두에서 든 소스도 사양서도 없는 시스템의 인수인계와 같습니다. 바로 다시 만들지 말고, 트리거·연결·출력처를 관찰해 「무엇을 하는지」를 대장에 풀어 쓰는 일부터 시작합니다. 다행히 플로우는 소스 코드 없는 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의 라이선스와 표준/프리미엄 커넥터의 경계

관련 상담 영역

합동회사 코무라소프트에서는 담당자의 퇴사·인사 이동으로 아무도 손대지 못하게 된 자동화·업무 시스템의 인수인계 조사부터, Power Automate 운영 설계 리뷰, 플로우로는 담지 못하게 된 처리의 시스템화까지 다룹니다.

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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

플로우 자체는 퇴사자 계정을 삭제해도 자동으로 사라지지 않으며, 공동 소유자가 남아 있으면 계속 실행됩니다. 다만 플로우 안의 연결(SharePoint나 Outlook 인증)은 만든 본인 계정에 묶여 있으므로, 퇴사자 연결을 쓰는 작업은 계정 비활성화·삭제와 함께 실패합니다. 또한 유효한 소유자가 한 명도 없는 플로우는 「고아 플로우」가 되고, 프리미엄 기능을 쓰는 플로우는 소유자 라이선스가 사라지면 성능이 떨어지며 조치하지 않으면 14일 뒤에 사용 중지됩니다. 퇴사 전에 공동 소유자를 넣고 연결을 바꿔 두는 일이 중요합니다.

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

가능합니다. Power Platform 관리 센터에서 환경을 고른 뒤 「리소스」→「플로우」를 열면 소유자가 없는 고아 플로우를 확인할 수 있고, 「공유」에서 새 소유자를 추가할 수 있습니다. 플로우가 많으면 관리용 PowerShell 모듈의 Get-AdminFlow로 목록을 가져와 Set-AdminFlowOwnerRole로 공동 소유자를 한꺼번에 넣는 방법도 있습니다. 다만 소유자를 이어받아도 퇴사자 명의 연결은 그대로는 동작하지 않으므로, 플로우 안 각 작업의 연결을 새 계정 연결로 바꾸는 작업이 따로 필요합니다.

공동 소유자만 넣어 두면 퇴사 대책으로 충분한가요?

충분하지 않습니다. 공동 소유자는 플로우 편집·중지·소유자 추가까지 할 수 있지만, 다른 사람이 만든 연결의 자격 증명은 바꿀 수 없고, 공유된 연결은 그 플로우 안에서만 쓸 수 있습니다. 퇴사자 연결을 쓰는 작업은 공동 소유자가 자기 연결로 바꿔야 비로소 계속 돌아갑니다. 알림 메일이 퇴사자 명의로 계속 나가는 문제도 남으므로, 발신은 공유 사서함에서 하게 하고, 핵심 업무 플로우는 실행용 계정이나 서비스 주체 소유로 옮기는 설계와 함께 봐야 합니다.

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

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

저자 프로필

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

Go Komura

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

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