Power Automate로 정기 실행 플로우를 설계하기 ── 월말 처리・영업일 판정・독촉의 실무

「매월 말이 다가오면 경리 담당자가 각 부서에 ‘경비 정산 마감은 ○일입니다’라고 메일을 보낸다」「매일 아침 업무 시작 후, 수주 리스트를 열어 미처리 건이 남아 있지 않은지 눈으로 확인한다」「제출 기한을 넘긴 서류를 대장과 대조해 한 건씩 독촉한다」. Microsoft 365를 도입한 회사라도 이런 「달력과 대장을 보고 사람이 움직이는」 업무는 의외로 많이 남아 있습니다. 잊으면 사고로 이어지는데, 잊지 않기 위한 장치가 담당자의 기억과 Outlook 일정표뿐인 상태입니다.

Power Automate의 스케줄 실행(Recurrence 트리거)을 사용하면 이런 종류의 정기 작업은 자동화할 수 있습니다. 다만 일본(한국을 포함한 UTC+9 지역)의 업무에서 실제로 만들려고 하면 곧바로 세 가지 벽에 부딪힙니다. 시각의 기본값이 UTC(협정 세계시)라는 점, 「영업일」이라는 개념이 내장되어 있지 않다는 점, 그리고 「월말」 「20일 마감」의 판정을 식으로 작성해야 한다는 점입니다. 이 글에서는 Recurrence 트리거의 사양과 함정, 날짜 계산 도구 상자, 공휴일 마스터에 의한 영업일 판정, 지나치게 독촉하지 않는 리마인드 설계, 그리고 정기 실행 플로우 특유의 운영 리스크까지 정리합니다.

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

1. 먼저 결론

• Recurrence 트리거의 시각은 표준 시간대를 지정하지 않으면 UTC로 취급됩니다. 「매일 아침 9시」로 알았던 것이 실제로는 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일이라는 사양을 전제로, 실패 알림과 실행 기록을 처음부터 설계해 넣습니다.⁸⁹

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의 표준 시간대 목록의 이름을 사용합니다. 일본(및 한국을 포함한 UTC+9)은 「Tokyo Standard Time」입니다.⁴ 식을 작성하고 싶지 않은 경우, 같은 동작을 하는 「표준 시간대 변환」 액션도 있습니다.¹³

왜 변환이 필수인가 하면, UTC와 UTC+9 지역 시간 사이에는 9시간의 차이가 있기 때문입니다. 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영업일 전과 전날의 2회만, 처럼 보내는 조건을 좁힙니다.
• 단계를 둔다. 먼저 본인에게만 알리고, 초과가 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/작업 스케줄러의 구분 사용」에서 정리하고 있습니다.

정리

정기 실행 플로우의 설계는 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」이라고 생각하고 설정하면 실제로는 UTC+9 지역 시간으로 18시에 동작합니다. 또한 식 안의 utcNow()도 항상 UTC를 반환하므로, 플로우 안에서 「오늘 날짜」를 사용할 때는 convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')처럼 현지 시간으로 변환한 후 사용합니다.

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

내장 기능으로는 제공되지 않습니다. Recurrence 트리거의 요일 지정으로 「평일만」 실행할 수는 있지만 공휴일은 고려되지 않으며, 식의 함수 목록에도 공휴일을 반환하는 함수는 없습니다. 실무에서는 공휴일 날짜를 가진 마스터(SharePoint 리스트 등)를 직접 준비하고, 플로우 맨 앞에서 「오늘이 마스터에 있는가」를 검색해 영업일이 아니면 종료하는 구성으로 만듭니다. 마스터의 갱신 원본으로는 일본 내각부가 공표하는 공휴일 CSV를 1차 소스로 사용할 수 있습니다.

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

「매월 20일」과 같은 고정일이라면 시작 일시를 대상 날짜로 설정하고 빈도를 「월」로 하면, 시작 일시를 기준으로 매월 같은 날・같은 시각에 실행하도록 만들 수 있습니다. 한편 Recurrence 트리거에 「매월 말」을 직접 지정하는 옵션은 없으며, 요일이나 시각의 상세 지정이 가능한 것도 빈도가 「일」 「주」인 경우뿐입니다. 월말처럼 날짜가 변동하는 처리는 매일(또는 평일 매일) 실행하는 플로우로 만들고, 맨 앞의 식에서 「오늘이 월말인가」 「오늘이 영업일인가」를 판정해 조건에 맞지 않는 날은 종료하는 형태로 만듭니다. 월말 판정은 「오늘의 월과 내일의 월이 다르면 오늘은 월말」이라는 식으로 작성할 수 있습니다. 「월말이 토・일・공휴일이면 전 영업일에 실행」도 같은 구성에 공휴일 마스터 판정을 더해 표현합니다.

정기 실행 플로우가 나도 모르는 사이에 꺼져 있었습니다. 왜 그런가요?

Power Automate에는 플로우가 자동으로 꺼지는 조건이 몇 가지 있습니다. 트리거나 작업이 계속 실패한 플로우는 14일 만에, 스로틀링(제한 초과)이 계속되는 플로우도 14일 만에 꺼집니다. 또한 90일 동안 한 번도 트리거되지 않은 플로우는 꺼질 수 있습니다(소유자가 프리미엄 라이선스나 용량 라이선스를 가진 경우는 대상에서 제외되며, 꺼지기 30일 전에 소유자・공동 소유자에게 알림이 전송됩니다). 정기 실행 플로우는 멈춰도 아무도 알아차리기 어렵기 때문에, 실패 시 알림과 실행 기록을 처음부터 넣어 두는 것이 중요합니다.

저자 프로필

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

Go Komura

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

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