Power Automate의 오류 처리와 재시도 설계 ── 「돌아가던 플로우가 멈춰 있었다」를 막기

「매일 아침 돌아가던 집계 플로우가 사실은 지난주부터 멈춰 있었다」「주문 등록 플로우가 같은 데이터를 두 번 처리해 대장에 중복이 생겼다」. Power Automate로 플로우를 만들어 운영을 시작한 회사에서 이런 상담을 자주 받습니다. 만들기는 쉬웠는데, 멈춘 사실을 아무도 몰랐다는 패턴입니다.

Power Automate 플로우는 정상 경로만 보면 몇 시간 만에 돌아갑니다. 다만 연결 대상 서비스는 잠시 내려가고, 인증은 끊기며, 예상 밖의 데이터는 반드시 들어옵니다. 「실패했을 때 무엇이 일어나는가」를 설계하지 않은 플로우는 실패를 조용히 쌓고, 최악의 경우 14일 만에 자동으로 꺼집니다¹. 이 글에서는 플로우 실패의 분류부터 표준 재시도의 정확한 사양, 스코프를 이용한 Try-Catch-Finally 패턴, 실패를 알아채는 장치, 재실행과 멱등성까지, 운영 환경에서 버틸 수 있는 오류 처리 설계 패턴을 정리합니다. Power Automate 전반의 역할 나누기와 UI 자동화(데스크톱 플로우) 쪽 오류 처리는 「Power Automate로 업무를 자동화하기 ── 클라우드 플로우·데스크톱 플로우의 역할 나누기와 오류 처리 설계」에서 다루므로, 이 글은 클라우드 플로우를 깊게 보는 데 한정합니다.

1. 먼저 결론

• 실패는 「일시적 장애」「데이터에서 비롯된 실패」「권한·인증 만료」「사양 변경」의 네 가지로 나눕니다. 표준 재시도로 해결되는 것은 첫 번째뿐이고, 나머지 셋은 감지와 수정을 위한 장치가 필요합니다².
• 표준 재시도 정책은 요청이 타임아웃되거나 408·429·5xx 응답으로 실패했을 때만 동작합니다. 기본값은 지수 백오프이며, 횟수는 라이선스 계층(성능 프로필)에 따라 최대 2회 또는 12회입니다³¹.
• 오류 처리의 기본형은 스코프 + 「실행 조건 구성」으로 만든 Try-Catch-Finally입니다. 실행 조건 구성에서는 「성공한 경우·실패한 경우·건너뛴 경우·타임아웃된 경우」의 네 상태 가운데 고릅니다³⁴. 이 기능의 일본어 UI 표시 이름은 「実行条件の構成」이고, 영어 UI와 문서에서는 「run after」입니다. 이하에서는 UI 표시 이름인 실행 조건 구성으로 통일합니다.
• Catch에서 실패를 처리했다면 마지막에 Terminate 액션으로 실행을 「실패」로 기록합니다. 이 단계를 빼면 실행 기록상 성공으로 보여 실패가 묻힙니다⁴³.
• 기본 실패 알림 메일은 「알려진 수정 방법이 있는 실패」로 한정되고 28일 쿨다운이 붙어 있어, 이것만 믿기에는 빈틈이 많습니다. Catch 블록에서 직접 보내는 알림을 필수로 봅니다⁵.
• 실행 기록은 기본으로 28일만 보입니다. 계속 실패하는 플로우는 14일 만에 자동으로 꺼집니다. 「멈춰 있던 것을 한 달 뒤에야 알았다」는 사양상 일어날 수 있습니다⁶¹.
• 재실행(재제출)과 이중 시작에 대비해, 두 번 실행해도 안전한 멱등 설계(처리 완료 플래그, 생성이 아니라 upsert, 트리거 조건)를 처음부터 넣습니다⁷⁸.

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

2. 플로우는 어떻게 실패하는가 ── 실패의 네 분류

오류 처리 설계는 「어떻게 실패하는가」를 나누는 일에서 시작하면 정리하기 쉽습니다. Microsoft 가이드도 자동화는 반드시 실패할 수 있다고 보고, 연결 대상 유지 관리·API 변경·비밀번호 변경·순간적인 네트워크 장애를 가정하라고 요구합니다². 실무에서는 다음 네 분류로 보면 대응 방향이 바로 정해집니다.

이 가운데 실무에서 가장 까다로운 것이 권한·인증 만료입니다. 플로우의 액션뿐 아니라 트리거 자체가 실패하기 시작합니다. 트리거가 4xx 계열 오류로 실패하는 전형 예로, 연결에 쓰던 비밀번호 변경(만료)이 공식 문제 해결 문서에도 나옵니다. 트리거가 실패하면 플로우가 아예 시작되지 않아 실행 기록에 「실패」 행조차 남지 않고, 알아채는 시점이 더 늦어집니다⁹. 연결은 만든 사용자 개인에 묶이므로, 담당자 퇴사·이동으로 한꺼번에 끊기는 사고도 납니다. 이런 조직 차원의 대책은 「Power Automate의 개인 의존 대책 ── 만든 사람이 그만둬도 플로우가 멈추지 않게」에서 자세히 다룹니다.

또 하나 알아 둘 점은, 실패를 방치하면 플로우 자체가 멈춘다는 것입니다. 트리거나 액션이 계속 실패하는 플로우는 14일 만에 자동으로 꺼지고, 스로틀링이 이어지는 플로우도 14일 만에 꺼집니다. 90일 동안 트리거되지 않은 플로우도(프리미엄·용량 라이선스 소유자가 아니면) 꺼질 수 있습니다¹. 또한 DLP(Data Loss Prevention: 데이터 손실 방지. 관리자가 커넥터 사용 여부와 조합을 제한해, 조직 데이터가 의도치 않게 밖으로 나가지 못하게 하는 가드레일입니다. 현재 공식 명칭은 「데이터 정책」)¹⁰ 정책 위반이나 반복 실패로 플로우가 「중단(suspended)」 상태인 경우도 있습니다¹¹. DLP 정책 변경은 즉시 적용되고 예고 없이 플로우를 멈추므로, 여러 플로우가 동시에 깨졌을 때는 먼저 정책 변경을 의심하는 것이 정석입니다¹¹. 「돌아가던 플로우가 멈춰 있었다」의 상당수는 장애가 아니라 이 사양 때문입니다.

3. 표준 재시도를 이해하기

Power Automate(기반은 Azure Logic Apps)의 액션에는 처음부터 재시도 정책이 들어 있습니다. 이 사양을 정확히 알면 「재시도 설정을 더해야 하는가」「재시도로는 안 되는가」를 판단할 수 있습니다.

무엇이·언제 재시도되는가

재시도 정책이 동작하는 때는 액션(또는 트리거) 요청이 타임아웃되었거나, 408(요청 타임아웃)·429(요청 과다=스로틀링)·5xx(서버 오류) 응답으로 실패했을 때입니다³. 기본 정책은 지수 백오프(간격을 지수적으로 늘리며 다시 시도)이고, Power Automate에서 기본 횟수와 간격은 플로우의 성능 프로필(실질적으로는 라이선스 계층)에 따라 다릅니다¹.

같은 플로우 정의라도 소유자 라이선스에 따라 「일시 장애에 버티는 힘」이 달라집니다. 프로필은 재시도 횟수뿐 아니라 하루 요청 수 상한에도 영향을 주므로, 라이선스 계층의 생각은 「Power Automate의 라이선스와 표준/프리미엄 커넥터의 경계」도 참고하시기 바랍니다.

재시도 정책은 액션 설정에서 바꿀 수 있습니다. 종류는 기본·없음·고정 간격·지수 간격의 네 가지이고, 횟수와 간격을 명시적으로 지정할 수 있습니다. 설정 상한은 횟수 90회·최소 간격 5초·최대 지연 1일입니다³¹. Microsoft 코딩 가이드라인은 일시 장애 회복에는 고정 간격보다 지수 간격을 권합니다. 짧은 간격으로 계속 두드려 상대의 회복을 막지 않기 위해서입니다⁴.

재시도로 해결되는 것과 안 되는 것

주의할 점은 재시도도 요청 수(Power Platform 요청)를 소비한다는 것입니다. 성공·실패와 관계없이 액션 실행은 요청 수에 잡히고, 재시도와 페이지네이션 요청도 마찬가지입니다¹. 429에 대해 횟수만 늘리면 스로틀링이 더 나빠질 수 있으므로, 재시도를 두껍게 하기 전에 「호출 횟수 자체를 줄일 수 없는가」를 먼저 봅니다.

4. Try-Catch-Finally 패턴 ── 스코프와 실행 조건 구성

재시도로 해결되지 않는 실패는 플로우 안에서 잡아 처리합니다. Power Automate에는 try-catch 구문이 없지만, 스코프(Scope)와 실행 조건 구성(영어 UI에서는 run after)을 조합하면 같은 구조를 만들 수 있습니다. Microsoft 코딩 가이드라인에서도 권하는 정석입니다⁴.

구조의 토대는 실행 조건 구성입니다. 각 액션은 끝날 때 성공(Succeeded)·실패(Failed)·건너뜀(Skipped)·타임아웃(TimedOut) 가운데 하나의 상태를 가지며, 다음 액션은 기본으로 「앞 액션이 성공한 경우」에만 실행됩니다. 이 조건은 액션마다 바꿀 수 있어, 「실패한 경우」「타임아웃된 경우」에 타는 분기를 만들 수 있습니다³.

설정 위치는 처음에는 잘 안 보입니다. 디자이너에서 대상 액션(또는 스코프)의 「…」(점 세 개 메뉴)를 열고 「실행 조건 구성」을 고르면, 직전 액션마다 네 상태 체크박스가 늘어선 패널이 나옵니다¹¹. 여기서 필요한 상태에 체크합니다. 한 가지 주의점은, 반드시 하나는 선택되어 있어야 하므로 기본의 「성공한 경우」를 끄는 것은 다른 상태에 체크한 뒤라는 순서입니다³. 실행 조건 구성은 「바로 앞 액션」에만 묶이지 않고, 여러 선행 액션을 지정해 각각에 상태를 할당할 수도 있습니다³.

이를 스코프에 적용하면 Try-Catch-Finally가 됩니다. 스코프는 안에 든 액션 전체의 결과를 모아 하나의 상태로 가지므로, 「Try 스코프 안 어딘가에서 실패하면 Catch 스코프를 실행한다」는 구성이, 액션마다 조건을 돌며 거는 것보다 유지보수가 훨씬 쉽습니다³⁴.

flowchart TD
    Trigger[트리거] --> Try[[Try 스코프<br/>본처리를 여기에 모은다]]
    Try -- 성공 --> Fin
    Try -- 실패 / 타임아웃 --> Catch[[Catch 스코프<br/>실행 조건 구성: 실패·타임아웃된 경우]]
    Catch --> Extract[result 함수+배열 필터링으로<br/>실패한 액션과 이유를 추출]
    Extract --> Notify[Teams / 메일로 담당자에게 알림<br/>플로우 이름·실패 단계·오류 상세·실행 URL]
    Notify --> Fin[[Finally 스코프<br/>실행 조건 구성: 성공·실패·건너뜀·타임아웃 모두]]
    Fin --> Cleanup[뒷정리·대장 상태 열을 업데이트]
    Cleanup --> Judge{Catch를 거쳤는가}
    Judge -- 예 --> Term[Terminate<br/>상태: Failed 로 실행 종료]
    Judge -- 아니오 --> Done([정상 종료])

짜는 요점은 네 가지입니다.

• Catch 스코프의 실행 조건 구성은 「실패한 경우」와 「타임아웃된 경우」를 둘 다 고른다. 기본의 「성공한 경우」는 끕니다. 실패만 고르면 승인 대기나 지연 액션의 타임아웃이 빠져나갑니다³.
• Catch 안에서 실패의 내용을 꺼낸다. result('Try스코프이름') 함수는 스코프 바로 아래 액션의 결과(상태·입출력·오류 본문)를 배열로 돌려주므로, 「배열 필터링」(Filter array)으로 상태가 Failed 또는 TimedOut인 것만 남기면, 실패한 액션 이름과 오류 메시지를 알림에 실을 수 있습니다³⁴. Failed만으로 걸러 내면 타임아웃을 타고 Catch에 들어왔을 때 추출 결과가 비어, 알림에서 정작 실패 단계가 빠집니다. 함께 workflow() 함수에서 실행 ID를 꺼내 실행 기록으로 바로 가는 URL을 만들어 두면 조사가 한결 수월합니다(식은 다음 절)⁴.
• Finally 스코프의 실행 조건 구성은 네 상태를 모두 고른다. 성공이든 실패든 반드시 지나야 하는 뒷정리(임시 파일 삭제, 대장 상태 열 업데이트 등)를 여기에 둡니다.
• 실패한 실행은 마지막에 Terminate 액션으로 「실패」로 끝낸다. 여기가 가장 빠지기 쉬운 점입니다. Catch가 정상 완료되면 플로우 실행 전체는 마지막 액션이 성공으로 끝난 것이 되어, 실행 기록에 「성공」으로 남습니다. 알림만 보내고 끝내면 실행 기록에서 실패가 사라져, 모니터링과 이후 집계에서 빠집니다. Terminate로 상태 Failed와 오류 메시지를 설정하고 종료하면 실행 기록에도 실패로 남습니다⁴³. 다만 Terminate를 Catch 스코프 맨 끝에 바로 두면 안 됩니다. Terminate는 그 시점에 실행 전체를 즉시 끝내므로, 뒤의 Finally 스코프가 돌지 않고 오류 때야말로 필요한 뒷정리가 건너뜁니다. 그림처럼 Catch에서는 실패 플래그(변수)만 세우고 알림까지 하고, Finally 뒷정리를 지난 뒤 플래그를 판별해 실패일 때만 Terminate로 끝내는 순서로 만듭니다.

실행 조건 구성은 승인 플로우의 타임아웃 분기(독촉·에스컬레이션)에서도 핵심 부품입니다. 구체적인 짜는 법은 「Power Automate로 승인 플로우 만들기 ── 종이와 메일의 품의·신청을 전자화하기」에서 다룹니다.

Catch의 내용 ── 실패한 액션과 실행 URL을 식으로 꺼내기

여기가 구현의 급소이므로 식까지 적어 둡니다. Try 스코프 이름을 Try로 둔 경우, 「배열 필터링」(Filter array) 설정은 다음과 같습니다. 조건은 「고급 모드로 편집」으로 바꿔 식을 직접 씁니다³⁴.

시작(From):  @result('Try')
조건(고급 모드): @or(equals(item()['status'], 'Failed'), equals(item()['status'], 'TimedOut'))

result()가 돌려주는 항목 하나하나에서 다음 값을 꺼낼 수 있습니다. 알림 본문에 이 네 가지를 나란히 두면, 실행 기록을 열기 전에 윤곽이 잡힙니다³.

실행 기록으로의 바로 가기 링크는 workflow() 함수로 조립합니다. 이 함수는 플로우 ID(name), 환경 이름(tags.environmentName), 플로우 논리 이름(tags.logicAppName), 실행 ID(run.name) 등을 담은 객체를 돌려주므로, URL은 다음 형태가 됩니다⁴.

concat('https://make.powerautomate.com/environments/', workflow()?['tags']?['environmentName'],
       '/flows/', workflow()?['tags']?['logicAppName'],
       '/runs/', workflow()?['run']?['name'])

공식 문서는 workflow() 출력을 「JSON 구문 분석」(Parse JSON)으로 분석한 뒤 「작성」(Compose) 액션으로 URL을 조립하는 절차로 설명합니다⁴. 어느 쪽이든 결과는 같지만, 포털 URL은 바뀔 수 있으므로 조립 직후 생성된 링크를 한 번 눌러, 목적한 실행 기록이 열리는지 확인하시기 바랍니다. 같은 문서는 자체 로그를 너무 늘리면 액션 수와 실행 시간이 불어나 역효과가 난다고도 경고합니다⁴. 실무에서는 「플로우 이름·실패 액션·오류·실행 URL」 네 가지로 줄이는 편이 낫습니다.

5. 실패를 알아채는 장치 ── 알림과 가시화

오류 처리를 짜도 실패를 아무도 모르면 의미가 없습니다. 「알아채는 장치」는 기본 알림에만 기대지 말고 여러 겹으로 설계합니다.

기본 실패 알림 메일을 정확히 이해하기

Power Automate는 실패 때 메일 알림을 보내는 장치가 있지만, 사양을 모르고 믿으면 빈틈투성이입니다. 알림은 두 종류입니다⁵.

• 실행 단위 실패 알림: 실행이 실패한 직후에 보내지지만, 연결 끊김·스로틀링·알려진 커넥터 오류처럼 「알려진 수정 방법이 있는 실패」로 판정된 경우만 대상입니다. 일반적인 액션 실패에서는 오지 않습니다. 수신자는 소유자와 공동 소유자(실행 전용 사용자는 포함되지 않음)이고, 관리자에게는 가지 않습니다. 한 번 보내지면 같은 플로우에는 28일 쿨다운이 있어, 그 사이의 실패에는 추가 알림이 오지 않습니다. 실행 단위 알림이 모든 플로우에서 기본으로 켜져 있는 것도 아니므로, 플로우 설정에서 확인해야 합니다⁵.
• 주간 실패 다이제스트: 환경을 가로지른 실패 요약이 주 1회 옵니다. 실행 단위 알림이 가지 않는 일반 실패도 여기에는 포함됩니다⁵.

이 외에, 특정 오류에는 복구 절차가 붙은 「복구 힌트」 메일이 소유자에게 갑니다(플로우마다 끌 수도 있습니다)⁷. 정리하면 기본 알림은 「처음 연결 끊김은 알아챌 수 있지만, 업무 데이터에서 비롯된 실패나 두 번째 이후 실패는 빠져나가기 쉬운」 구조입니다. 중요한 플로우에서는 4장의 Catch 블록에서 직접 보내는 알림을 필수로 보시기 바랍니다.

Catch에서 보내는 알림 설계 ── 알림 플로우 자체가 실패하는 경우

직접 보내는 알림에도 설계 포인트가 있습니다.

• 수신자를 개인으로 두지 않는다. 담당자 개인 앞으로 보내면 부재·퇴사 때 누구에게도 닿지 않습니다. 공유 사서함이나 Teams 채널로 보내는 것이 공식 문서에서도 권장됩니다¹¹.
• 알림 경로를 본처리와 나눈다. 흔한 사고가 「Outlook 연결이 끊겨 플로우가 실패했는데, 실패 알림도 같은 Outlook 연결이라 보내지 못한다」는 동반 실패입니다. 인증 만료가 원인인 실패에서는 같은 연결을 쓰는 알림 액션도 함께 실패합니다. 알림은 Teams 게시처럼 본처리와 다른 커넥터·다른 연결로 두거나, 알림 전용 작은 플로우로 나눠 호출하면 동반 실패 위험을 낮출 수 있습니다. 그래도 「알림의 알림」을 무한히 만들 수는 없으므로, 마지막 보루로 다음의 정기 확인을 둡니다.
• 알림에는 조사에 필요한 정보를 모두 담는다. 플로우 이름, 실패한 액션 이름, 오류 메시지, 실행 기록으로의 바로 가기 링크. 이것이 없으면 알림이 와도 「무언가 실패했다」 이상은 알 수 없어 방치되기 쉽습니다⁴.

가시화와 정기 확인

• 플로우 검사기: 저장 전에 플로우 정의의 오류와 경고를 찾아 줍니다. 다 만든 뒤 한 번 확인하는 습관을 들입니다¹².
• 실행 기록의 정기 확인: 플로우 실행 기록은 기본으로 28일만 표시됩니다⁶. 솔루션에 넣은 플로우는 Dataverse에 실행 기록 메타데이터를 남길 수 있지만, 이쪽도 기본 보존은 28일이고 연장은 관리자 쪽 설정입니다¹³. 운영 플로우에 대해서는 실패뿐 아니라 「취소 상태의 실행」(동시 실행 제어가 원인인 경우가 있음)이나 「실행 수 급감」(트리거가 돌지 않는 징후)까지 포함해 주 1회 정도 확인하는 운영이 권장됩니다¹¹.
• 관리자의 일원 감시: 실행 단위 알림 메일이 가지 않는 실패까지 전건을 보려면 Power Platform 관리 센터의 Monitor(모니터링)가 가장 포괄적입니다. 플로우 단위·환경 단위로 실패 건수와 오류 상세를 확인할 수 있습니다⁵.

정기 실행 플로우라면 「애초에 시작되었는가」의 감시가 필요합니다. 영업일 판정이나 월말 처리를 포함한 정기 실행 설계는 「Power Automate의 정기 실행 플로우와 영업일 설계」에서 다룹니다.

6. 재실행과 멱등성 ── 「두 번 돌아도 깨지지 않게」 만들기

실패 대응은 감지로 끝나지 않습니다. 「실패한 부분을 다시 돌리는」 조작과 「다시 돌려도 깨지지 않는」 설계가 한 세트입니다.

재제출(resubmit)의 사양

실패한 실행은 실행 기록에서 재제출(Resubmit)로 다시 돌릴 수 있습니다. 같은 트리거 데이터로 다시 실행하는 조작이며, 일시 장애(500/502 등)라면 그대로 재제출하고, 플로우 정의가 원인이면 고쳐 저장한 뒤 재제출하면 수정 후 정의로 다시 돌아갑니다⁷. 실행 기록 목록에서는 한 번에 최대 20건까지 묶어 재제출할 수 있어, 대량 실패 때 복구에 씁니다. 수동 시작(인스턴트 트리거) 플로우는 자신의 실행은 언제든 재제출할 수 있지만, 다른 사용자가 시작한 실행의 재제출은 테넌트 설정에서 관리자가 허용해야 합니다¹⁴.

여기서 중요한 점은 재제출이 플로우를 처음부터 다시 돈다는 것입니다. 10단계 중 8단계에서 실패한 실행을 재제출하면, 성공했던 1~7단계도 다시 실행됩니다. 「메일은 이미 갔는데 한 번 더 보내졌다」「대장에 같은 행이 두 줄 생겼다」는 사고는 여기서 납니다.

멱등성 ── 두 번 실행해도 안전한 설계

그래서 같은 입력으로 몇 번을 돌려도 결과가 같아지는(멱등한) 설계를 처음부터 넣습니다. 재제출뿐 아니라 트리거 중복 시작과 병렬 실행에도 먹히는, 오류 설계의 핵심입니다.

• 처리 완료 플래그를 둔다. SharePoint 목록 같은 대장에 「상태」 열(미처리/처리 중/처리 완료)을 두고, 플로우 맨 앞에서 상태를 확인해 처리 완료면 거기서 끝내고, 처리를 마치면 상태를 업데이트합니다. 이렇게 하면 재제출해도 이중 처리가 되지 않습니다. 다만 플래그는 업데이트 순서까지 정해야 비로소 동작합니다. 메일 발송이나 기간계 등록처럼 밖으로 나가는 부작용은, 직전에 「처리 중」으로 바꾼 뒤 실행하고, 끝난 뒤에 「처리 완료」로 바꿉니다. 부작용 이후·플래그 업데이트 이전에 실패한 실행은 「처리 중」으로 남아, 부작용이 끝났는지 알 수 없는 상태입니다. 이 행을 기계적으로 재제출하면 이중 발송이 될 수 있으므로, 「처리 중」 행은 자동 재실행 대상에서 빼고, 실제 발송·등록 결과와 맞춰 본 뒤 사람이 「처리 완료」 또는 「미처리」로 되돌리는 운영으로 합니다. 안심하고 다시 돌려도 되는 것은 「미처리」로 멈춰 있는 행뿐입니다.
• 「만들기」가 아니라 「있으면 업데이트, 없으면 만들기」(upsert)로 한다. 고유 키(주문 번호, 신청 ID 등)로 기존 행을 찾아, 맞으면 업데이트, 없으면 만드는 분기로 둡니다. 무조건 「항목 만들기」는 재실행할 때마다 중복 행을 쌓습니다. 바꿔 말하면 고유 키가 없는 데이터는 멱등하게 만들 수 없으므로, 대장 설계 단계에서 키 열을 정해 두는 것이 전제입니다.
• 트리거 조건으로 불필요한 시작을 막는다. 「항목이 만들어지거나 변경되었을 때」 트리거 플로우가 자기 자신의 다시 쓰기로 재시작되는 식의 다중 시작은, 뒤단 조건 분기가 아니라 트리거 조건(trigger conditions)으로 막습니다. 트리거 조건을 만족하지 않는 이벤트에서는 실행 자체가 생기지 않아, 실행 횟수도 요청 수도 쓰지 않습니다⁸.

한 가지 주의가 있습니다. 처리 완료 플래그나 upsert처럼 「확인하고 나서 쓰는」 방식은, 재제출처럼 순차적인 다시 돌리기에는 먹히지만, 그것만으로는 원자적 보호가 아닙니다. 중복 트리거 이벤트가 거의 동시에 둘 뜨면, 양쪽 실행이 「미처리」를 읽은 뒤 둘 다 처리를 진행하는 경합이 날 수 있습니다. 병렬 시작이 가능한 플로우에서 중복을 확실히 막으려면, 다음 절의 동시 실행 제어로 병렬도를 1로 직렬화하거나, 저장처에서 고유 키 제약을 강제하는 장치(데이터베이스 고유 제약 등)를 써서 중복 만들기를 쓰기 시점에 실패시키는 설계를 함께 쓰시기 바랍니다.

동시 실행 제어(concurrency control)와 순서의 트레이드오프

이중 실행과 나란히 문제가 되는 것이 「동시 실행」과 「순서」입니다. 기본값에서는 트리거 조건을 만족하는 이벤트가 동시에 많이 오면, 플로우는 몇 개든 병렬로 돌아갑니다¹. 대장의 같은 행을 여러 실행이 동시에 읽고 쓰면, 오래된 값을 읽어 덮어쓰는(더티 리드) 불일치가 날 수 있습니다¹⁵.

트리거 설정의 동시 실행 제어(Concurrency Control)를 켜면 병렬 실행 수(병렬도)를 1~100으로 지정할 수 있습니다. 병렬도를 1로 하면 실행은 한 번에 하나가 되어, 순서대로의 처리에 가까워집니다¹¹⁵. 다만 이 스위치에는 무거운 주의점이 있습니다.

• 한 번 켜면 되돌릴 수 없다. 끄려면 트리거를 지우고 다시 만드는 수밖에 없습니다¹. 동시 실행 제어는 되돌릴 수 없으므로, 적용한다면 액션 수가 적은 플로우(필요하면 자식 플로우로 잘라)로 한정하는 것이 권장됩니다¹⁵.
• 누락 위험이 생긴다. 동시 실행 제어가 켜져 있을 때 대기할 수 있는 실행 수는 「10+병렬도」까지이고, 이 상한에 닿아 있는 동안 도착한 트리거는 커넥터 쪽에서 재시도되지만, 상한 초과가 오래 이어지면 실행에 이르지 못할 수 있습니다. 모든 트리거를 반드시 실행으로 이어야 하는 플로우에서는 동시 실행 제어를 끈 채로 두라고 공식 문서가 명시합니다¹. 실행 기록이 취소 상태투성이라면 이 설정이 원인인 경우가 있습니다¹¹.

즉 「순서를 지킨다」와 「빠뜨리지 않는다」는 트레이드오프입니다. 병렬도 1의 직렬화는 유량이 적고 순서가 중요한 처리(대장의 연번 채번 등)에는 유효하지만, 피크에 대량 이벤트가 오는 처리에 가볍게 쓰면 안 됩니다. 순서와 누락 없음이 둘 다 엄격히 필요하면, 8장에서 말하듯 Power Automate 밖에서 설계해야 할 영역으로 들어갑니다.

7. 운영에 올리기 전 설계 체크리스트

새 플로우를 운영에 올리기 전에 최소한 여기까지는 확인합니다. 전부를 첫날에 맞추는 것이 이상적이지만, 도입 문턱을 낮추려고 「최소한」(이것이 빠지면 사고가 보이지 않음)과 「여유가 있으면」(운영에 올린 뒤 한 달 안에 채움)의 두 단으로 나눴습니다.

12개나 되냐고 느낄 수 있지만, 운영 첫날에 필요한 것은 「최소한」 6항목뿐이고, 절반 이상은 처음 한 번만 생각하면 끝나는 항목입니다. 「여유가 있으면」 6항목도 내버려 두라는 뜻이 아니라, 돌리기 시작한 뒤에 차분히 채울 수 있다는 구분입니다. 반대로 이것을 건너뛰고 운영에 올린 플로우의 「나중에 붙이기」는, 돌아가는 것을 만지는 두려움과 겹쳐 대개 실행되지 못한 채 사고를 맞습니다.

8. 어디까지 Power Automate로 할 것인가

오류 처리를 파고들면 Power Automate의 수비 범위를 넘는 요건이 보입니다. 선을 긋는 기준을 듭니다.

판단의 감각은 「실패했을 때 복구 절차를 말로 설명할 수 있는 동안은 Power Automate, 그림을 그려야 설명할 수 없게 되면 개발 영역」 정도로 봅니다. 특히 보상 트랜잭션(A사 시스템에는 등록됨, B사 시스템은 실패, 그렇다면 A를 취소할 것인가?)이 필요한 업무는 플로우 겉모습 이상으로 복잡하고, Terminate와 알림으로는 수습되지 않습니다. 작업 스케줄러나 PowerShell과의 역할 나누기까지 포함한 판단은 「Power Automate와 PowerShell·작업 스케줄러의 역할 나누기」에서 정리합니다.

9. 정리

「돌아가던 플로우가 멈춰 있었다」는 불운이 아니라 거의 설계 문제입니다. 플로우는 반드시 실패합니다. 실패의 네 분류 가운데 재시도가 맡아 주는 것은 일시적 장애뿐이고, 데이터에서 비롯된 실패·인증 만료·사양 변경은 Try-Catch로 잡기, Terminate로 기록하기, 직접 보내는 알림, 그리고 주간 실행 기록 확인이라는 여러 겹의 장치로 건질 수밖에 없습니다. 기본 실패 알림 메일은 조건부·28일 쿨다운이 붙은 한정적인 장치이며, 이것에 기댄 운영은 반드시 빠져나감을 만듭니다.

그리고 실패 대비의 핵심은 알림보다 멱등성입니다. 처리 완료 플래그와 upsert로 「두 번 돌아도 깨지지 않는」 형태로 두면, 재제출도 트리거 중복도 두렵지 않고, 복구는 「실패한 부분을 골라 재제출」로 끝납니다. 반대로 보상 트랜잭션이나 엄격한 순서 보장이 필요한 업무는 Power Automate로 억지로 욱여넣지 말고, 개발 영역으로 잘라 내는 판단이 장기적으로는 싸게 먹힙니다. 돌기 시작한 날이야말로 이 체크리스트를 한 바퀴 돌아보시기 바랍니다.

관련 글

• Power Automate로 업무를 자동화하기 ── 클라우드 플로우·데스크톱 플로우의 역할 나누기와 오류 처리 설계
• Power Automate의 정기 실행 플로우와 영업일 설계
• Power Automate로 승인 플로우 만들기 ── 종이와 메일의 품의·신청을 전자화하기
• Power Automate의 개인 의존 대책 ── 만든 사람이 그만둬도 플로우가 멈추지 않게
• Power Automate와 PowerShell·작업 스케줄러의 역할 나누기

관련 상담 영역

합동회사 코무라소프트는 Power Automate 플로우의 오류 처리·운영 설계 리뷰부터, 플로우로는 담기지 않는 순서 보장·트랜잭션 요건의 시스템화까지 다룹니다.

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Power Automate 플로우가 실패하면 알림 메일이 자동으로 오나요?

제한적으로만 옵니다. 실행 단위 실패 알림 메일은 연결 끊김이나 스로틀링처럼 「알려진 수정 방법이 있는 실패」로 판정된 경우에만 소유자·공동 소유자에게 보내지는 구조이며, 일반적인 액션 실패에서는 오지 않습니다. 한 번 보내지면 같은 플로우에는 28일 쿨다운이 있어, 그 사이에는 추가 알림이 오지 않습니다. 실행 단위 실패 알림이 모든 플로우에서 기본으로 켜져 있는 것도 아닙니다. 실패를 놓치지 않으려면 Catch 블록에서 Teams나 메일로 직접 알리도록 설계하는 편이 좋습니다.

Power Automate의 표준 재시도는 몇 번, 어떤 간격으로 이루어지나요?

액션 요청이 타임아웃되거나 408·429·5xx 계열 응답으로 실패하면, 기본값으로는 간격을 지수적으로 늘리며 자동 재시도합니다. 횟수는 플로우의 성능 프로필(실질적으로는 라이선스 계층)에 따라 다르며, Microsoft 365 라이선스 등 Low 프로필에서는 최대 2회, Power Automate Premium이나 Process 라이선스 등 Medium·High 프로필에서는 최대 12회입니다. 액션 설정에서 재시도 정책을 「없음·고정 간격·지수 간격」으로 바꿀 수 있고, 횟수는 최대 90회까지 지정할 수 있습니다. 400이나 404처럼 데이터·설정에서 비롯된 오류는 재시도 대상이 아닙니다.

실패한 플로우 실행을 다시 하려면(재제출하려면) 어떻게 하나요?

실행 기록에서 실패한 실행을 연 뒤 「재제출」을 고르면 같은 트리거 데이터로 다시 실행합니다. 플로우 정의가 원인인 경우에는 플로우를 고쳐 저장한 다음 재제출하면 수정 후 내용으로 다시 돌아갑니다. 실행 기록 목록에서는 한 번에 최대 20건까지 묶어 재제출할 수 있습니다. 주의할 점은 재제출이 플로우를 처음부터 다시 돌린다는 것입니다. 중간에 이미 성공한 단계가 있었다면 그 처리도 한 번 더 실행됩니다. 두 번 돌아도 결과가 깨지지 않는 멱등 설계(처리 완료 플래그, 생성보다 업데이트를 우선하는 쓰기)가 필요합니다.

플로우가 모르는 사이에 꺼지는 일이 있나요?

있습니다. 트리거나 액션이 계속 실패하는 플로우는 14일 만에 자동으로 꺼집니다. 스로틀링(제한 초과)이 이어지는 플로우도 마찬가지로 14일 만에 꺼집니다. 90일 동안 한 번도 트리거되지 않은 플로우도, 프리미엄 라이선스나 용량 라이선스 소유가 아니면 꺼질 수 있습니다. 실패를 방치하면 플로우 중지로 직결되므로, 실패를 알아채는 장치와 실행 기록(기본 28일)의 정기 확인을 운영에 넣어 두는 것이 중요합니다.

저자 프로필

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

Go Komura

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

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