Power Automate로 정기 실행 플로우를 설계하기 ── 월말 처리·영업일 판정·리마인드의 실무

「매월 말이 가까워지면 경리 담당자가 각 부서에 『경비 정산 마감은 ○일입니다』라고 메일을 보낸다」「매일 아침 업무가 시작되면 수주 리스트를 열어 미처리 건이 남았는지 눈으로 확인한다」「제출 기한을 넘긴 서류를 대장과 맞춰 한 건씩 독촉한다」. Microsoft 365를 이미 쓰는 회사에서도, 이런 「달력과 대장을 보고 사람이 움직이는」 일은 생각보다 많이 남아 있습니다. 잊으면 사고로 이어지는데, 잊지 않게 붙잡아 주는 장치는 담당자의 기억과 Outlook 일정밖에 없는 상태입니다.

Power Automate의 예약 실행(Recurrence 트리거)을 쓰면 이런 정기 작업은 자동화할 수 있습니다. 다만 일본 업무에 맞춰 실제로 짜려고 하면 바로 세 가지 벽에 부딪힙니다. 시각 기본값이 UTC(협정 세계시)라는 점, 「영업일」 개념이 제품에 없다는 점, 「월말」「20일 마감」 판정을 식으로 써야 한다는 점입니다. 이 글에서는 Recurrence 트리거의 사양과 함정, 날짜 계산에 쓰는 도구, 공휴일 마스터로 하는 영업일 판정, 독촉을 과하게 보내지 않는 리마인드 설계, 정기 실행 플로우만의 운영 리스크까지 정리합니다.

일본력·공휴일·마감일이라는 일본의 날짜 요건을 시스템 전반에서 어떻게 다룰지는 별도 글 「업무 앱의 일본력·공휴일·마감일 처리 ── 연호 변경에 강한 설계와 JapaneseCalendar·영업일 계산의 실무」에서 자세히 썼습니다. 이 글은 그 생각을 Power Automate 플로우에 적용하는 실전편입니다.

1. 먼저 결론

• Recurrence 트리거의 시각은 표준 시간대를 지정하지 않으면 UTC로 취급됩니다. 「매일 아침 9시」로 넣었는데 일본 시간 18시에 도는 사고는, 표준 시간대 칸에서 「(UTC+09:00) 오사카, 삿포로, 도쿄」를 고르고 시작 시각을 명시하면 막을 수 있습니다.¹²
• 「평일만 실행」은 빈도 「주」에 요일 지정(월~금)으로 만들 수 있습니다. 다만 공휴일은 반영되지 않습니다. 「매월 20일」처럼 고정된 날짜는 시작 일시와 빈도 「월」로 만들 수 있지만, 「매월 말」「마감일이 휴일이면 직전 영업일」처럼 날짜가 바뀌는 경우는 지정할 수 없으므로, 「매일 실행하고 식으로 판정」하는 것이 실무적인 해법입니다.²
• 식 안의 utcNow()도 항상 UTC입니다. 일본 시간의 「오늘」은 convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time')으로 변환한 뒤 씁니다. 아침 8시대 플로우에서 변환을 빼먹으면 「오늘」이 전날이 됩니다.³⁴
• 일본 공휴일을 판정하는 기능은 내장되어 있지 않습니다. 식 함수 목록에도 공휴일 함수는 없고⁵, 공휴일 마스터(SharePoint 리스트 등)를 직접 두고 플로우 맨 앞에서 「오늘이 영업일인지」를 판정해 아니면 종료하는 구성이 정석입니다. 마스터의 1차 소스로는 내각부의 공휴일 CSV를 쓸 수 있습니다.⁶
• 리마인드는 「1건 1통」이 아니라 담당자별로 묶어 1통으로 보냅니다. Filter array나 Create HTML table 같은 데이터 작업 액션을 쓰면 Apply to each 중첩을 피하면서도 읽기 쉽게 짤 수 있습니다.⁷
• 정기 실행 플로우는 「돌고 있지 않다」는 사실을 알아채기 어렵습니다. 연속 실패 14일이면 해제, 90일 동안 트리거가 없으면 해제, 실행 기록은 기본 28일이라는 사양을 전제로, 실패 알림과 실행 기록을 처음부터 설계합니다.⁸⁹

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

2. 「사람이 달력을 보고 움직이는 업무」를 가려내기

가장 먼저 할 일은 플로우를 만드는 것이 아닙니다. 「달력을 보고 움직이는 업무」를 찾아내고, 정기 실행에 맞는지 나누는 일입니다.

가르는 기준은 세 가지입니다. 판정 조건을 데이터로 나타낼 수 있는지(「왠지 수상한 건」은 자동화할 수 없습니다), 실행일 규칙을 말로 적을 수 있는지, 실패해도 다음 날 복구할 수 있는지(불가능한 것은 8장의 개발 영역)입니다.

이 가운데 두 번째가 일본 업무에서는 가장 어렵습니다. 「매월 말에 마감 리마인드」라고 말해도, 사람이 실제로 하는 일은 「월말이 토·일·공휴일이면 직전 영업일로 앞당기고, 골든위크가 있는 해에는 연휴 전에 보낸다」 같은 조정입니다. 이 암묵지를 사양으로 적는 일이 플로우 작업의 본론입니다. 여기가 흐린 채로 플로우만 만들면, 「공휴일에 독촉 메일이 나갔다」「연휴 전 리마인드가 연휴 중에 나갔다」는 식으로 신뢰를 잃습니다.

3. Recurrence 트리거의 기본과 함정

예약 실행 클라우드 플로우는 「예약된 클라우드 플로우」로 만들고, Recurrence(반복) 트리거에서 빈도와 간격을 설정합니다.¹ 빈도는 초·분·시간·일·주·월에서 고르며, 간격 최솟값은 60초, 최댓값은 500일입니다.⁸ 사양 자체는 단순하지만, 함정이 많은 트리거이기도 합니다.

먼저 전체를 한눈에 보겠습니다. 국내 업무 플로우에서 밟기 쉬운 순입니다(6은 해외 거점이 있을 때만 해당합니다).

함정 1: 기본값은 UTC ── 「9시여야 하는데 18시」

가장 흔한 사고입니다. Recurrence 트리거의 시작 시각은 표준 시간대를 고르지 않으면, 끝에 Z가 붙은 UTC 형식(YYYY-MM-DDThh:mm:ssZ)으로 해석됩니다. 표준 시간대 칸에서 일본을 고르면, 시작 시각은 그 표준 시간대의 로컬 시각(YYYY-MM-DDThh:mm:ss, Z 없음)으로 취급됩니다.¹² 「매일 아침 9시에 알리는 플로우」라면, 표준 시간대를 「(UTC+09:00) 오사카, 삿포로, 도쿄」로 두고 시작 시각을 9:00으로 하는 것이 맞습니다.

함정 2: 시작 시각을 안 넣으면, 저장한 순간에 한 번 돈다

시작 일시를 지정하지 않으면, 플로우를 저장하는 시점에 첫 실행이 바로 돌아갑니다.² 테스트 중이라면 괜찮지만, 독촉 메일이 들어 있는 플로우를 저녁에 저장해 그 자리에서 전원에게 독촉이 나가는 사고가 납니다. 시작 일시는 반드시 지정하십시오.

게다가 고급 옵션의 「설정 시각(이 시간/이 분)」을 지정하지 않으면, 두 번째 이후 실행 시각은 직전 실행으로부터의 상대값으로 계산되므로, 지연이 쌓여 실행 시각이 조금씩 밀립니다(드리프트).² 매일 같은 시각에 돌리고 싶은 플로우에서는 시작 일시에 더해 실행 시각도 밝혀 두는 편이 안전합니다.

함정 3: 「평일만」은 되지만, 월별 상세 지정은 제한적이다

빈도를 「주」로 하면 요일(월~금)을 고를 수 있고, 「일」 또는 「주」이면 실행 시각(시·분)도 지정할 수 있습니다. 즉 「평일 아침 9시만」은 트리거 설정만으로 됩니다. 반면 이런 상세 옵션을 쓸 수 있는 것은 빈도가 「일」「주」일 때뿐이고, 빈도 「월」에는 「매월 20일」「매월 말」 같은 날짜 칸이 없습니다.²

다만 날짜가 고정된 월별 처리라면 매일 돌릴 필요는 없습니다. 시작 일시를 대상일(예: 다음 달 20일 9:00)로 두고 빈도를 「월」로 하면, 실행은 시작 일시를 기점으로 한 달마다이므로 「매월 20일 9시」는 트리거만으로 만들 수 있습니다.² 한 달에 12번이면 되는 플로우를 매일 365번 띄워 판정으로 버리는 일은, 실행 기록이 읽기 어려워지고 요청 수도 낭비하므로 피합니다.

「매일 실행 + 플로우 맨 앞 식으로 오늘이 대상일인지 판정」이 필요한 것은 날짜가 바뀌는 월별 처리입니다. 「매월 말」(달에 따라 28~31일), 「20일이 토·일·공휴일이면 직전 영업일」, 「매월 제N영업일」 같은 날짜는 트리거로 나타낼 수 없습니다. 이 판정식은 다음 장에서 다룹니다. 29~31일을 시작일로 한 고정일 지정은, 그 날이 없는 달의 동작을 구현으로 확인해야 하므로, 월말 근처 처리는 처음부터 「매일 실행 + 판정」 쪽으로 두는 편이 안전합니다.

함정 4: 트리거에 쓴 식은 저장 시점에 고정된다

트리거 입력에 utcNow() 같은 식을 넣으면, 그 값은 플로우를 저장한 시점에 계산되어 고정됩니다. 실행할 때마다 다시 계산되지 않습니다.¹⁰ 「시작 시각을 오늘로 하고 싶어서」 트리거에 식을 넣는 발상은 통하지 않는다고 기억해 두십시오. 날짜 계산은 트리거가 아니라 플로우 안의 액션에서 합니다(4장).

함정 5: 꺼 둔 동안의 분은 나중에 실행되지 않는다

Recurrence 트리거는 플로우가 꺼져 있던 기간에 지나간 일정을 재개 후에 몰아서 처리하지 않고, 다음 주기부터 다시 시작합니다.¹¹ 「월말 처리 플로우를 수정하려고 며칠 꺼 두었더니, 마침 월말 실행일을 건너뛰어 이번 달 분이 돌지 않았다」는 사고가 납니다. 정기 실행 플로우를 멈출 때는 다음 실행 예정일을 확인한 뒤에 멈추십시오.

함정 6: 서머타임 ── 해외 거점만 주의

표준 시간대를 고르지 않고 UTC 시각으로 쓴 경우, 서머타임(DST)이 있는 지역에서는 전환 때마다 실행 시각이 1시간 밀립니다. 표준 시간대를 골라 두면 계절 전환을 따라가며 일정이 유지됩니다.¹¹ 일본에는 서머타임이 없어 국내만이면 실해가 없지만, 해외 거점 알림을 같은 플로우에서 다루면 거점 표준 시간대를 명시적으로 골라야 합니다.

4. 날짜 계산 도구 ── 월말·월초·마감일을 식으로 판정하기

플로우 안 날짜 계산은 Logic Apps와 공통인 식(함수)으로 씁니다.⁵ 전제로, utcNow()가 돌려주는 값은 항상 UTC 현재 시각입니다.¹² 그래서 플로우 맨 앞에서 「일본 시간의 오늘」을 만들어 변수(또는 Compose)에 넣고, 이후에는 그것을 재사용하면 식이 읽기 쉬워집니다.

convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')

convertTimeZone(타임스탬프, 변환 원본, 변환 대상, 서식)은 표준 시간대 변환 함수이고¹³, 표준 시간대 이름은 Windows 표준 시간대 목록의 이름을 씁니다. 일본은 「Tokyo Standard Time」입니다.⁴ 식을 쓰고 싶지 않으면, 같은 일을 하는 「표준 시간대 변환」 액션도 있습니다.¹³

변환이 필요한 이유는 UTC와 일본 시간에 9시간 차가 있기 때문입니다. 일본 시간 아침 9시까지는 UTC로는 아직 전날입니다. 아침 8시에 도는 플로우에서 formatDateTime(utcNow(), 'yyyy-MM-dd')라고 쓰면, 돌아오는 「오늘」은 전날 날짜입니다. 날짜 어긋남은 실행 시각에 따라 나타나기도 하고 아니기도 해서 테스트에서 놓치기 쉽고, 운영에서 「월초여야 할 처리가 월말 마지막 날에도 돌았다」는 형태로 드러납니다.

이 식을 어디에 쓰는지 ── 변수와 Compose, 식 탭

Power Automate를 막 다루기 시작하면 여기서 헷갈리므로, 먼저 정해 둡니다.

• 변수 초기화(Initialize variable): 「작업 추가」의 「변수」에 있는 액션입니다. 이름·형식(문자열 등)·값을 정해 만들고, 이후에는 variables('today')처럼 참조합니다. 루프 안에서 값이 바뀌거나, 나중에 「변수 설정」으로 덮어쓸 것은 이쪽입니다.
• 작성(Compose): 「작업 추가」에서 compose를 검색하면 「데이터 작업」 아래에 나오는 액션으로, 「입력」에 쓴 식 결과를 그대로 보관합니다. 같은 내용을 반복해 쓰지 않기 위한 액션이므로⁷, 「일본 시간의 오늘」처럼 한 번 계산하면 바뀌지 않는 값에는 이쪽이 맞습니다. 참조는 outputs('Today')처럼 액션 이름으로 합니다.
• 식 자체를 쓰는 위치: 어느 액션이든 값 입력란을 고르면 동적 콘텐츠와 식을 고르는 패널이 열리므로, 「식」 탭(fx 아이콘이 표시)에 위의 convertTimeZone(...)을 붙여 넣고 확정합니다. 디자이너 버전에 따라 화면은 달라져도, 「입력란을 클릭한 다음 식 탭」 순서는 같습니다.
• 액션 이름과 변수 이름은 식에서 참조하므로 영숫자로 붙이는 편이 안전합니다(이름 안의 공백은 밑줄로 바뀝니다).

이후 이 글에서는 이 식으로 만든 「일본 시간의 오늘」을 오늘로 표기합니다. 실제 플로우에서는 variables('today')나 outputs('Today')로 바꿔 읽으십시오. 만든 뒤의 판정 패턴을 정리합니다.

addDays, addToTime, startOfMonth, formatDateTime, dayOfWeek는 모두 Logic Apps/Power Automate 공통 식 레퍼런스에 정의된 함수입니다.⁵ 표의 조합 식 자체는 필자의 구현 패턴이므로, 도입할 때는 월말·월초·윤년(2월 29일)을 걸치는 날짜로 시험한 뒤 운영에 올리십시오. 특정 날에만 터지는 날짜 버그의 위험과, 미리 시험해야 할 날짜를 고르는 방법은 일본력·공휴일·마감일 글 4장에 적은 그대로입니다.

5. 영업일 판정 ── 공휴일은 마스터로 둔다

내장 공휴일 판정은 없다

반복하지만, Power Automate에 일본 공휴일을 판정하는 내장 기능은 없습니다. Recurrence 트리거의 요일 지정은 말 그대로 요일만 보고, 식 함수 목록에 있는 것도 날짜 가감·서식·표준 시간대 변환까지입니다. 「이 날이 공휴일인가」를 돌려주는 함수는 없습니다.⁵ 공휴일을 계산식으로 구하는 일 자체가 원리적으로 불가능하다는 사정(춘분·추분은 전년에 확정되고, 법 개정이나 특별조치법으로 공휴일 자체가 움직인다)은 일본력·공휴일·마감일 글 3장에서 자세히 썼습니다. 결론은 같고, 공휴일은 데이터(마스터)와 갱신 운영으로 둔다가 맞습니다.

Power Automate에서 두는 방법은 SharePoint 리스트에 「공휴일 마스터」(날짜 열 + 이름 열)를 만드는 것이 손쉽습니다. 1차 소스로는 내각부가 공개하는 쇼와 30년부터 다음 해분까지의 공휴일 월일·이름 CSV를 쓸 수 있습니다(대체 휴일도 행으로 들어 있습니다).⁶ 공개되는 것은 확정분뿐이므로, 1년에 한 번 다음 해분을 마스터에 넣는 작업을 업무 달력에 올리는 것까지가 설계입니다. 갱신을 빼먹으면 다음 해 공휴일에 독촉이 나가는 형태로 그대로 오동작합니다. 또한 하기 휴가나 창립기념일 같은 회사 휴무일은 공휴일 마스터에 섞지 말고 별도 리스트로 두십시오. 「은행 이체 기한 판정은 공휴일만 본다」「사내 독촉은 회사 휴무일도 본다」처럼, 용도마다 봐야 할 휴일 집합이 다르기 때문입니다.

플로우 맨 앞의 「영업일 가드」

영업일에만 돌리고 싶은 플로우는 Recurrence의 요일 지정(월~금)에 더해, 플로우 맨 앞에 다음 판정을 둡니다.

1. 「일본 시간의 오늘」을 만든다(4장)
2. 공휴일 마스터에 대해 SharePoint의 「여러 항목 가져오기(Get items)」를 실행하고, 필터 쿼리로 HolidayDate eq '오늘'처럼 오늘 날짜를 찾는다¹⁴
3. 회사 휴무일 리스트에도 같은 검색을 한다
4. 한 건이라도 맞으면 「종료(Terminate)」 액션으로 실행을 멈춘다

Terminate는 플로우 실행을 그 자리에서 멈추고 지정한 상태(성공/실패/취소)로 끝내는 액션입니다(Apply to each나 Do until 루프 안에는 둘 수 없습니다).¹⁵ 여기서 상태를 「취소됨」으로 두면, 실행 기록에서 「영업일이 아니라 건너뛴 날」과 「실제로 처리가 돈 날」을 한눈에 가릴 수 있습니다. 모두 「성공」으로 맞추는 것보다 나중에 조사가 수월합니다.

「직전 영업일로 앞당기기」와 「N영업일 전」

월말 마감 리마인드에서 실제로 필요한 것은 「매월 말」이 아니라 「월말이 휴일이면 직전 영업일」입니다. 이는 영업일마다 도는 플로우에서 「오늘은 영업일이고, 내일부터 월말까지 영업일이 하루도 없다」고 판정하면 나타낼 수 있습니다. 바꿔 말하면 「오늘이 이번 달 마지막 영업일인가」를 매일 아침 판정하기만 해도, 앞당기기는 저절로 이루어집니다.

이 글에서 가장 옮기기 어려운 부분이므로 식과 액션 구성까지 적습니다. 전제는 영업일 가드(앞 절)를 통과했다는 것, 즉 오늘은 영업일로 확정된 상태입니다.

flowchart TD
    Start[영업일 가드 통과<br/>오늘은 영업일로 확정] --> Hol[이번 달 휴일 목록 작성<br/>공휴일 마스터와 회사 휴무일을 Get items]
    Hol --> Days[남은 일수 계산<br/>월말 일에서 오늘 일을 뺌]
    Days --> Zero{남은 일수가 0인가}
    Zero -- 예 --> Run[오늘이 마지막 영업일<br/>월말 처리·리마인드 실행]
    Zero -- 아니요 --> Range[내일부터 월말까지 날짜 배열 작성<br/>range 와 addDays]
    Range --> Filter[Filter array로 토·일과 휴일 제외]
    Filter --> Len{남은 건수가 0인가}
    Len -- 0건 --> Run
    Len -- 1건 이상 --> Skip[Terminate 취소됨<br/>오늘은 앞당긴 날이 아님]

구체적인 내용은 다음과 같습니다.

1. 이번 달 휴일 목록을 만든다. 공휴일 마스터와 회사 휴무일 리스트를 Get items로 이번 달분만 가져와 「선택」(Select)으로 yyyy-MM-dd 형식 문자열만의 배열로 만든 뒤, union()으로 하나로 합칩니다.¹⁴⁵ 이 액션 이름을 Holidays로 둡니다.

2. 월말 날짜와 남은 일수를 낸다. 4장의 식을 그대로 씁니다.

   월말:     addDays(startOfMonth(addToTime(오늘, 1, 'Month')), -1, 'yyyy-MM-dd')
   남은 일수: sub(int(formatDateTime(월말, 'dd')), int(formatDateTime(오늘, 'dd')))
   

3. 남은 일수가 0이면 오늘은 월말이다. 영업일 가드를 통과했으므로 오늘이 마지막 영업일입니다. 그대로 처리로 갑니다.
4. 남은 일수가 1 이상이면, 내일부터 월말까지 날짜 배열을 만든다. 「선택」(Select) 액션의 시작에 range(1, 남은 일수), 맵에 addDays(오늘, item(), 'yyyy-MM-dd')를 지정합니다. range()의 두 번째 인수는 양의 정수여야 하므로⁵, 3단계 분기를 반드시 앞에 두십시오(여기를 빼면 월말 당일에만 플로우가 오류로 죽습니다).

5. 토·일과 휴일을 뺀다. 「배열 필터」(Filter array)에 4단계 출력을 넣고, 조건을 고급 모드로 전환한 뒤 다음 식을 씁니다.⁷ createArray(0, 6)은 일요일과 토요일의 요일 번호¹², body('Holidays')는 1단계에서 만든 휴일 목록입니다.

   @and(not(contains(createArray(0, 6), dayOfWeek(item()))),
        not(contains(body('Holidays'), item())))
   

6. 남은 건수로 판정한다. 5단계 액션 이름을 Filter array로 두면, 그 출력은 body('Filter_array')로 참조할 수 있습니다(이름 공백이 밑줄로 바뀝니다). length(body('Filter_array'))가 0이면 「오늘 이후에 영업일이 없다」= 오늘이 이번 달 마지막 영업일이므로 처리를 실행하고, 1 이상이면 오늘은 앞당긴 날이 아니므로 Terminate(취소됨)로 끝냅니다.⁵¹⁵

「매월 20일, 휴일이면 직전 영업일」처럼 마감일을 앞당기는 경우도 같은 형태입니다. 월말 날짜 대신 마감일(20일)을 쓰고, 「오늘이 마감일 이전이며, 내일부터 마감일까지 영업일이 없다」로 바꿔 읽으면 판정 구조는 바뀌지 않습니다. 도입할 때는 마감일이 월요일·토요일·일요일·공휴일에 걸리는 달을 각각 골라 시험하십시오.

「지급 기한 3영업일 전에 독촉」처럼 N영업일 전도 같은 바꿔 읽기입니다. 「기한의 N영업일 전이 되면」을 「영업일마다 실행하고, 오늘부터 기한까지 영업일 수를 세어 N과 같으면」으로 바꿉니다. 영업일 세는 법은 「토·일이 아니고, 공휴일 마스터에 없고, 회사 휴무일에도 없는」 날을 세기만 하면 됩니다. 다만 플로우 루프에서 날짜를 하루씩 세는 처리는, 대상 건이 수백 건을 넘으면 건수×일수 루프가 되어 실행 시간과 API 호출이 커집니다. 그 규모가 되면 영업일 계산을 플로우 밖(데이터베이스의 영업일 테이블이나 작은 API)으로 빼거나, 8장의 개발 영역으로 다루는 편이 건전합니다.

6. 리마인드·독촉 설계 ── 담당자별로 묶어 1통

전제: 대장이 데이터여야 한다

기한 초과 독촉을 자동화할 수 있는 것은 「무엇이·누구 담당이고·언제가 기한인지」를 데이터로 가져올 수 있을 때뿐입니다. 대장이 공유 폴더 Excel이고 메일 첨부으로 돌고 있다면, 먼저 SharePoint 리스트로 옮기는 것을 검토하십시오(「Excel 대장을 SharePoint 리스트로 바꾸기」에서 다룹니다). 아래는 SharePoint 리스트에 「기한」「상태」「담당자」 열이 있다는 전제입니다.

추출은 가져올 때 좁힌다

기한 초과 추출은 리스트 전체를 가져온 뒤 플로우에서 조건 분기하지 말고, Get items의 필터 쿼리(OData 필터)로 서버에서 좁힙니다.¹⁴

DueDate lt '2026-07-18' and Status ne '完了'

날짜 부분에는 4장에서 만든 「일본 시간의 오늘」 식을 넣습니다. 필터 쿼리의 열 이름은 화면 표시 이름이 아니라 SharePoint 내부 이름으로 써야 하고, 기본으로는 100건만 돌아오므로 건수가 많은 리스트에서는 상한(Top Count) 지정이나 페이지네이션 설정이 필요합니다.¹⁴

Apply to each 지옥을 피하기 ── 묶어서 1통 만드는 법

추출 결과를 그대로 Apply to each로 돌려 한 건씩 메일을 보내면, 담당자 A에게 미처리가 10건 있으면 매일 아침 10통이 갑니다. 몇 주 이어지면 알림은 분명 읽히지 않고, 리마인드 장치 자체가 죽습니다. 알림은 담당자별로 1통으로 묶는 것이 원칙입니다. 데이터 작업 액션을 쓰면 다음 흐름으로 짤 수 있습니다.⁷

1. Select로 추출 결과에서 담당자 메일 주소 배열을 만들고, union()으로 중복을 뺀 「오늘 알려야 할 담당자 목록」을 만든다⁵
2. 담당자 목록을 Apply to each로 돌리며, 그 안에서 Filter array로 「이 담당자의 건만」 추출한다
3. Create HTML table로 제목·기한·상태 표로 만든 뒤, 메일(또는 Teams 메시지) 본문에 넣어 1통만 보낸다(메일이면 HTML 표시를 켭니다⁷)

전체 그림은 다음과 같습니다.

flowchart TD
    Rec[Recurrence 트리거<br/>평일 아침 9:00 표준 시간대: 오사카, 삿포로, 도쿄] --> Today[일본 시간의 오늘 작성<br/>convertTimeZone]
    Today --> Hol{공휴일 마스터·회사 휴무일에<br/>오늘이 있는가}
    Hol -- 있음 --> Term[Terminate 취소됨<br/>영업일이 아니므로 종료]
    Hol -- 없음 --> Get[Get items<br/>기한 초과이면서 미완료를 추출]
    Get --> Any{대상이 있는가?}
    Any -- 없음 --> End([종료 알림 없음])
    Any -- 있음 --> Sel[Select로 담당자 목록 작성<br/>union으로 중복 제거]
    Sel --> Each[담당자마다 루프]
    Each --> Filter[Filter array<br/>이 담당자의 건만 추출]
    Filter --> Table[Create HTML table로 표 작성]
    Table --> Send[담당자에게 1통만 알림<br/>Teams 또는 Outlook]
    Send --> Log[실행 결과를 로그용 리스트에 기록]

Teams와 Outlook을 나누기

알림 출구는 성격에 따라 나눕니다.

일별 요약은 Teams, 마감 전 정식 리마인드와 기한 초과 독촉은 메일,처럼 나누는 것이 정석입니다. 양쪽에 같은 내용을 흘리는 일은 알림 총량만 늘리므로 권하지 않습니다.

독촉을 과하게 보내지 않는 설계

리마인드 자동화에서 가장 두려운 일은 너무 많이 보내 전부 무시당하는 것입니다. 사람이 하는 독촉에는 「말하기 어려워서 빈도가 줄어드는」 자연스러운 브레이크가 있지만, 플로우에는 없습니다. 설계로 넣습니다.

• 총량을 설계합니다. 매일 아침·전원·전건이 최악입니다. 매일 보내는 것은 당일 기한과 초과분만, 사전 리마인드는 3영업일 전과 전날 두 번만,처럼 보내는 조건을 좁힙니다.
• 단계를 둡니다. 먼저 본인만 알리고, 초과가 N영업일 이어지면 상사를 수신처에 더하는 식으로 에스컬레이션을 나눕니다. 처음부터 전부 상사에게 보내면 알림은 소음이 됩니다.
• 멈추는 장치를 만듭니다. 담당자가 리스트 상태 열을 「완료」로 바꾸면 다음 날부터 알림이 멈추는 출구를 반드시 둡니다. 완료 보고가 메일 회신인 채로면, 플로우는 독촉을 계속하고 담당자는 플로우를 미워하게 됩니다.
• 「알림이 없다 = 문제 없다」를 믿을 수 있는 상태로 유지합니다. 이는 다음 장의 감시와 세트가 되어야 성립합니다.

7. 운영 시 주의 ── 정기 실행 플로우는 「멈춘 것을 알아채지 못한다」

이벤트 기동 플로우는 업무 쪽이 「신청했는데 안 돈다」고 알아채 줍니다. 정기 실행 플로우에는 그 감지기가 없습니다. 월말 리마인드가 멈춰 있어도 아무도 말하지 않은 채 마감만 늦어집니다. 운영 설계에서는 다음 사양을 전제로 하십시오.

• 플로우가 자동으로 꺼지는 조건이 있다. 트리거나 액션이 계속 실패하는 플로우는 14일 만에, 스로틀링이 이어지는 플로우도 14일 만에 꺼집니다. 90일 동안 한 번도 트리거되지 않은 플로우는 꺼질 수 있습니다(소유자가 프리미엄 라이선스 또는 용량 라이선스(Process 등)를 가진 플로우는 대상이 아닙니다. 꺼지기 30일 전에 소유자·공동 소유자에게 알림이 가고, 다시 켜면 이어갈 수 있습니다).⁸ 「분기에 한 번만 도는 플로우」를 만들 때는 이 90일 규칙에 주의해야 합니다.
• 실행 기록은 기본으로 28일만 보인다.⁹ 월별 플로우라면 최근 1회분만 확인할 수 있는 셈입니다. 플로우 마지막에 「실행 일시·처리 건수·결과」를 로그용 SharePoint 리스트에 한 행 추가하는 단계를 넣어 두면, 「지난달에 제대로 돌았는지」를 기록 만료와 무관하게 확인할 수 있습니다. 6장 그림 끝에 로그 기록을 둔 것은 이 때문입니다.
• 실패를 알아채는 장치를 플로우 스스로 갖게 한다. 실패 시 관리자에게 알리는 분기(실행 조건 구성에서 「실패한 경우」에 도는 액션)를 넣지 않으면, 꺼질 때까지 14일 동안 아무도 실패를 모릅니다. 오류 처리와 재시도 넣는 법은 「Power Automate의 오류 처리와 재시도 설계」에서 자세히 다룹니다.
• 소유자의 퇴직·이동으로 일정째 멈춘다. Recurrence 트리거 플로우는 플로우 만든 사람의 연결로 실행됩니다.¹⁰ 소유자 계정이 비활성화되면 연결이 끊겨 플로우가 실패하기 시작하고, 이윽고 꺼집니다. 공동 소유자 설정과 연결 점검은 가동 첫날에 마치십시오.¹⁶ 인수인계 실무는 「Power Automate의 속인화 대책 ── 만든 사람이 그만둬도 플로우가 멈추지 않으려면」에 정리했습니다.
• 꺼 둔 기간의 분은 돌지 않는다(3장 함정 5). 수정이나 장애 대응으로 플로우를 끌 때는 다음 실행 예정일을 확인하고, 걸쳐 버린 경우에는 수동 실행으로 보완하는 운영을 정해 둡니다.¹¹

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

정기 실행은 자동화의 입구로는 뛰어나지만, 「정기적으로 도는 것」을 무엇이든 플로우로 만드는 일은 위험합니다. 선을 긋는 기준을 듭니다.

감각으로는 「알아채게 하는」 것까지는 Power Automate, 「확정하는」(기간계 데이터를 바꾸는) 것은 개발 근처에 선이 있습니다. 마감 처리 자체를 플로우로 짜려다 분기투성이가 된 건을 몇 번 봤는데, 대개는 「마감 실행은 기존 시스템이나 수탁 개발, 마감을 잊지 않게 하는 알림만 플로우」로 다시 나누면 안정됐습니다. 또한 클라우드를 거치지 않고 서버 안에서 끝나는 정기 처리라면, PowerShell과 작업 스케줄러가 더 단순하고 유지하기 쉬운 경우도 있습니다. 나누는 법은 「Power Automate와 PowerShell/작업 스케줄러 나누기」에서 정리했습니다.

9. 정리

정기 실행 플로우 설계는 Recurrence 트리거 설정보다, 그 앞과 뒤에 본론이 있습니다. 앞에 있는 것은 「달력을 보고 움직인다」는 암묵지를 사양으로 적는 일입니다. 월말이 휴일이면 어떻게 할지, 공휴일은 누가 언제 마스터에 넣을지. 여기를 정하지 않고 만든 플로우는 일본 달력 앞에서 반드시 오동작합니다. 뒤에 있는 것은 멈춘 것을 알아채기 위한 운영입니다. 실행 기록 28일, 자동 해제의 각 조건, 소유자 퇴직으로 멈추는 일정. 정기 실행 플로우는 조용히 멈춘다는 전제로, 실패 알림과 실행 로그를 처음부터 넣으십시오.

기술 면의 요점은 세 가지로 모입니다. 시각은 표준 시간대를 명시한다(기본값은 UTC), 날짜는 일본 시간으로 변환한 뒤 판정한다, 공휴일은 마스터로 두고 플로우 맨 앞 영업일 가드로 걸러낸다. 이 세 가지를 잡은 다음, 알림은 담당자별로 묶고 독촉에는 단계와 출구를 붙입니다. 여기까지 하면 「사람이 달력을 보고 움직이는」 업무의 상당 부분을, 맡겨도 되는 정기 실행 플로우로 바꿀 수 있습니다. 그리고 마감 처리나 기간계 배치처럼 「확정하는」 처리에 발을 들이고 싶어질 때가, 개발 영역으로 바꿀지를 검토할 시점입니다.

관련 글

• Power Automate로 업무를 자동화하기 ── 클라우드 플로우·데스크톱 플로우 나누기와 오류 처리 설계
• 업무 앱의 일본력·공휴일·마감일 처리 ── 연호 변경에 강한 설계와 JapaneseCalendar·영업일 계산의 실무
• Power Automate의 오류 처리와 재시도 설계
• Power Automate의 속인화 대책 ── 만든 사람이 그만둬도 플로우가 멈추지 않으려면
• Power Automate와 PowerShell/작업 스케줄러 나누기

관련 상담 영역

합동회사 코무라소프트는 Power Automate로 하는 정기 처리·리마인드 설계 검토부터, 플로우로 담지 못하는 마감 처리·영업일 계산·기간계 연동 배치 개발까지 다룹니다.

• 기술 상담·설계 검토
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Power Automate의 스케줄 플로우를 일본 시간 매일 아침 9시에 돌리려면?

Recurrence 트리거의 표준 시간대 칸에서 「(UTC+09:00) 오사카, 삿포로, 도쿄」를 고르고 시작 시각을 지정합니다. 표준 시간대를 지정하지 않으면 시작 시각은 끝에 Z가 붙은 UTC(협정 세계시)로 해석되므로, 「9:00」으로 넣으면 일본 시간 18시에 실행됩니다. 식 안의 utcNow()도 항상 UTC를 반환하므로, 플로우에서 「오늘 날짜」를 쓸 때는 convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')처럼 일본 시간으로 바꾼 뒤 사용합니다.

Power Automate에 일본 공휴일을 판정하는 기능이 있습니까?

내장 기능은 없습니다. Recurrence 트리거의 요일 지정으로 「평일만」 실행할 수는 있지만 공휴일은 반영되지 않고, 식 함수에도 공휴일을 돌려주는 것은 없습니다. 실무에서는 공휴일 날짜를 담은 마스터(SharePoint 리스트 등)를 직접 두고, 플로우 맨 앞에서 「오늘이 마스터에 있는지」를 조회한 뒤 영업일이 아니면 종료합니다. 마스터를 갱신할 1차 소스로는 내각부가 공개하는 공휴일 CSV를 쓸 수 있습니다.

매월 말 영업일에만 실행하는 플로우를 만들 수 있습니까?

「매월 20일」처럼 날짜가 고정이면, 시작 일시를 그 날짜로 두고 빈도를 「월」로 하면 시작 일시를 기준으로 매월 같은 날·같은 시각에 실행됩니다. 반면 Recurrence 트리거에 「매월 말」을 직접 넣는 옵션은 없고, 요일이나 시각을 자세히 지정할 수 있는 것도 빈도가 「일」「주」일 때뿐입니다. 월말처럼 날짜가 바뀌는 처리는 매일(또는 평일 매일) 실행하는 플로우로 두고, 맨 앞 식에서 「오늘이 월말인지」「오늘이 영업일인지」를 판정해 조건에 맞지 않으면 종료합니다. 월말 판정은 「오늘 달과 내일 달이 다르면 오늘은 월말」이라는 식으로 쓸 수 있습니다. 「월말이 토·일·공휴일이면 직전 영업일에 실행」도 같은 구성에 공휴일 마스터 판정을 더하면 됩니다.

정기 실행 플로우가 모르는 사이에 꺼져 있었습니다. 왜입니까?

Power Automate에는 플로우가 자동으로 꺼지는 조건이 있습니다. 트리거나 액션이 계속 실패한 플로우는 14일 만에, 스로틀링(제한 초과)이 이어진 플로우도 14일 만에 꺼집니다. 90일 동안 한 번도 트리거되지 않은 플로우는 꺼질 수 있습니다(소유자가 프리미엄 라이선스나 용량 라이선스를 가진 경우는 대상이 아니고, 꺼지기 30일 전에 소유자·공동 소유자에게 알림이 갑니다). 정기 실행 플로우는 멈춰도 알아채기 어려우므로, 실패 알림과 실행 기록을 처음부터 넣는 것이 중요합니다.

저자 프로필

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

Go Komura

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

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