메일로 도착하는 주문서·청구서 PDF를 Power Automate로 자동 처리하기 ── 저장·분류·알림·읽기 설계

「수주 메일에 첨부된 PDF 주문서를 매일 아침 공유 폴더에 저장하고, Excel 수주 대장에 옮겨 적는다」. 이 일을 담당자가 매일 30분씩 손으로 하고 있다——그런 회사는 드물지 않습니다. 실제로 Power Automate 상담에서도 「메일로 들어오는 문서를 자동화하고 싶다」는 이야기는 꽤 많은 편입니다.

언뜻 단순한 자동화로 보이지만, 만들어 보면 사소한 함정이 많은 영역이기도 합니다. 서명 이미지까지 저장되어 폴더가 잡파일로 가득 찹니다. 대상이 아닌 메일에서 플로우가 돌아 잘못 저장됩니다. 첨부가 큰 메일만 이상하게 처리되지 않습니다. 이 글에서는 수신 트리거부터 저장·분류·알림까지의 기본 플로우, 실무에서 자주 걸리는 함정, AI Builder로 읽기(기입 자동화)까지 갈지 말지의 판단, 그리고 메일 첨부라는 수신 방식 자체의 한계까지 순서대로 정리합니다.

1. 먼저 결론

• Office 365 Outlook 커넥터의 「새 메일이 도착했을 때 (V3)」 트리거에는 폴더·보낸 사람·제목 필터·「첨부 파일이 있는 것만」 같은 좁히기 조건이 있습니다. 조건은 뒤쪽 조건 분기 액션이 아니라, 되도록 트리거 쪽에서 지정합니다.¹²
• 수신 창구는 담당자 개인 받은 편지함이 아니라 공유 사서함(예: order@자사 도메인)으로 둡니다. 전용 트리거 「공유 사서함에 새 메일이 도착했을 때 (V2)」가 있으며, 연결 계정에 공유 사서함 액세스 권한이 있으면 쓸 수 있습니다.³
• 「첨부 파일 있음」 판정만으로는 서명이나 로고 같은 인라인 이미지도 첨부로 집어갑니다. 첨부 메타데이터의 Is Inline 속성과 확장자로 걸러 내는 것이 기본 대책입니다.⁴
• 저장 위치는 SharePoint 문서 라이브러리로 두고 「파일 만들기」 액션으로 쓰며, Teams 또는 메일로 저장 완료를 알리는 구성이 다루기 쉽습니다.⁵
• 읽기(기입 자동화)까지 가면 AI Builder의 문서 처리를 쓰지만, 사용량 기반 크레딧(용량)이 따로 필요하고, 추출 결과에는 사람이 확인하는 설계가 필수입니다. 라이선스 체계가 2025년 이후 바뀌고 있으므로 도입 전에 최신 정보를 확인해야 합니다.⁶⁷
• 비밀번호가 걸린 ZIP(PPAP)으로 오는 첨부는 플로우로 풀려고 하지 말고, 받는 방식 자체를 바꾸는 것이 본질적인 대책입니다.

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

2. 대상 업무 정리 ── 「메일 첨부로 오는 문서」를 어디까지 자동화할 것인가

먼저 이 글이 다루는 업무의 모양을 확인해 두겠습니다.

• 거래처에서 주문서·청구서·납품서 같은 PDF가 메일 첨부로 온다
• 담당자가 열어 공유 폴더의 정해진 위치에 저장한다
• 내용(거래처명, 금액, 품목 등)을 Excel이나 업무 시스템에 옮겨 적는다
• 담당자나 관계자에게 「주문이 왔다」고 알린다

수발주를 받는 방식에는 FAX, 메일 첨부, 웹 폼, EDI 같은 단계가 있습니다. 메일 첨부는 FAX보다 데이터화하기는 쉽지만, 구조화된 데이터 연동인 EDI나 디지털 인보이스에는 미치지 못하는 중간 위치에 있습니다. 이 전체 그림은 별도 글 「EDI란? 기업 간 수발주를 어떻게 편하게 만드는가 ── FAX·메일·손입력에서 데이터 연동으로」에서 정리했습니다.

그다음, 메일 첨부 운용을 유지한 채 자동화로 노릴 수 있는 범위를 나누면 다음 3단계가 됩니다.

이 글의 초점은 (1)과 (2)입니다. 우선 (1)만으로도 매일의 효과는 충분하고, (2)는 비용 대비 효과를 보고 판단하는 진행을 권합니다. (3)은 7장에서 다룹니다.

3. 기본 플로우 ── 수신 트리거부터 저장·알림까지

기본 형태는 「수신 트리거 → 좁히기 → 첨부마다 루프 → SharePoint에 저장 → 알림」입니다.

flowchart TD
    Start([공유 사서함에 새 메일이<br/>도착했을 때 V2<br/>order@자사 도메인]) --> Filter[트리거 조건으로 좁히기<br/>보낸 사람·제목 필터·첨부 파일이 있는 것만]
    Filter --> Each[Apply to each<br/>첨부 파일마다 루프]
    Each --> Check{Is Inline = false<br/>그리고 확장자 .pdf ?}
    Check -- 아니오 --> Skip[처리하지 않음<br/>서명 이미지 등을 제외]
    Check -- 예 --> Save[SharePoint: 파일 만들기<br/>거래처/연월 폴더로<br/>수신 일시를 넣은 파일 이름으로 저장]
    Save --> Notify[Teams 채널에 게시 또는 메일 알림<br/>저장 위치 링크·보낸 사람·제목을 적음]
    Notify --> End([완료])
    Save -. 실패 시 .-> Err[오류 알림<br/>관리자에게 실패를 알림]

주요 액션과 설계 포인트는 다음과 같습니다.

3.1 트리거에 넣는 구체적인 설정값

트리거의 좁히기 조건은 기본값으로는 보이지 않습니다. 트리거 카드에서 「고급 옵션 표시 (Show advanced options)」를 열면 아래 항목이 나타납니다. 실제로 넣는 값과 함께 적어 둡니다.¹²

「첨부 파일이 있는 것만」과 「첨부 파일 포함」은 이름이 비슷하지만 역할이 다르며, 둘 다 켜지 않으면 기본 플로우는 동작하지 않습니다. 전자만 켜면 첨부 내용을 가져오지 못하고, 후자만 켜면 첨부가 없는 메일에서도 플로우가 뜹니다.

저장 폴더를 「거래처/연월」처럼 동적으로 정할 때는 저장 폴더가 있는지를 플로우 쪽에서 보장하는 일도 빼먹지 마십시오. 새 거래처의 첫 메일이나 월초 첫 메일에서는 저장 폴더가 아직 없습니다. SharePoint 커넥터에는 「새 폴더 만들기 (Create new folder)」 액션이 있어 폴더 경로를 한꺼번에 만들 수 있으므로⁵, 「파일 만들기」 앞에 폴더를 준비하는 단계를 넣어 두면 여기서 저장이 막히는 일을 막을 수 있습니다.

저장 위치를 예전 파일 서버가 아니라 SharePoint로 두는 이유는, 클라우드 플로우에서 바로 쓸 수 있고, 링크로 알릴 수 있으며, 나중에 AI Builder나 검색과 맞추기 쉽기 때문입니다. 온프레미스 파일 서버에만 둘 수밖에 없다면 온프레미스 데이터 게이트웨이를 경유하는 방법도 있지만, 구성이 무거워지므로 가능하면 저장 위치까지 SharePoint로 모으는 쪽을 권합니다.

플로우 전체의 오류 처리(실패 시 알림, 실행 기록 확인) 사고방식은 별도 글 「Power Automate로 업무를 자동화하기 ── 클라우드 플로우·데스크톱 플로우 구분과 오류 처리 설계」에서 자세히 썼습니다.

4. 함정과 대책

처음 돌아가는 플로우는 반나절이면 만들 수 있습니다. 문제는 그다음이고, 실제 운영을 견딜지는 아래 함정을 없앴는지로 갈립니다.

4.1 서명·로고 이미지가 「첨부 파일」로 저장된다

가장 흔한 상담입니다. 본문에 심어 둔 서명 이미지나 회사 로고는 데이터상 인라인 첨부로 다루어지므로, 「첨부 파일 있음」 조건만으로 저장하면 정작 필요한 PDF와 함께 image001.png 같은 파일이 대량으로 쌓입니다.

Office 365 Outlook 커넥터에서는 트리거나 액션이 돌려주는 첨부 메타데이터에 Id·Name·Content Type·Size·Is Inline이 들어가며, 이들은 「첨부 파일 포함」 설정과 관계없이 항상 가져올 수 있습니다. Is Inline이 true인 것이 인라인 첨부입니다.⁴

대책은 두 겹으로 둡니다.

1. Apply to each 안에서 조건 액션으로 Is Inline이 false인 것만 통과시킨다
2. 이어서 파일 이름 끝이 .pdf인지 확인한다(거래처가 본문에 이미지로 문서를 붙여 넣는 경우를 빼면, 이것으로 거의 확실하게 좁혀진다)

조건 액션은 「모두 충족 (And)」으로 2행을 만듭니다.

items('Apply_to_each')는 Apply to each의 현재 항목을 가리키는 식입니다. 루프 이름을 바꿨다면 그 이름의 공백을 밑줄로 바꾼 형태로 둡니다. 확장자는 대문자로 오기도 하므로, toLower를 거친 뒤 판정하는 편이 안전합니다.

크기가 큰 첨부나 첨부가 많은 메일을 일상적으로 받는다면, 트리거의 「첨부 파일 포함」을 끄고 메타데이터로 대상을 고른 뒤, 필요한 첨부만 「첨부 파일 가져오기 (V2)」 액션으로 따로 가져오는 구성도 고를 수 있습니다.¹ 첨부 메타데이터(Is Inline이나 이름)는 「첨부 파일 포함」 설정과 관계없이 가져올 수 있으므로, 선별 로직은 어느 구성이든 같습니다.⁴ 트리거가 넘기는 데이터를 작게 유지할 수 있어, 플로우가 커져 첨부 처리가 무거워지면 이 형태로 바꾸는 것을 검토하십시오.

4.2 대상 메일 좁히기 ── 전용 주소 + 공유 사서함

개인 받은 편지함에는 주문서 말고도 메일이 많이 들어옵니다. 보낸 사람이나 제목으로 아무리 좁혀도, 거래처가 메일 쓰는 법을 바꾸면 빠집니다. 근본 대책은 주문 접수 전용 주소를 마련하고, 거래처에는 그곳으로 보내 달라고 하는 것입니다.

이때 수신 창구는 공유 사서함으로 둡니다. 이유는 두 가지입니다.

• 수신 입구를 담당자 개인 사서함에서 떼어 낼 수 있다. 담당자가 이동·퇴사하면 수신 창구까지 사라지거나, 후임이 지난 메일을 못 보는 일을 막을 수 있다
• 공유 사서함 자체에는 개별 라이선스가 필요 없고, 접근하는 사용자 쪽에 라이선스가 있으면 된다⁹

트리거는 「공유 사서함에 새 메일이 도착했을 때 (V2)」를 씁니다. 전제 조건으로, 플로우 연결에 쓰는 계정이 그 공유 사서함 액세스 권한을 갖고 있어야 합니다. 권한을 준 뒤 플랫폼에 반영되기까지 2시간 정도 걸릴 수 있고, Microsoft 365 그룹 주소는 공유 사서함으로 지정할 수 없다는 점도 주의하십시오.³

다만 공유 사서함으로 바꾼다고 플로우의 특정인 의존이 없어지는 것은 아닙니다. 플로우 연결(Outlook 인증)은 연결을 만든 사용자 계정에 그대로 묶여 있고, 공유된 연결은 그 플로우 안에서만 쓸 수 있으며, 다른 소유자가 다른 소유자의 연결 자격 증명을 바꿀 수도 없습니다.¹⁰ 즉 연결에 쓴 계정이 퇴사로 막히면, 수신 창구가 공유 사서함이어도 플로우는 멈춥니다. 연결은 되도록 퇴사 일정과 떼어 낼 수 있는 운용 계정으로 만들고, 함께 공동 소유자를 두어, 필요할 때 다른 소유자가 자기 연결로 갈아 끼워 플로우를 유지할 수 있게 해 둡니다.

4.3 같은 이름 파일의 덮어쓰기와 중복

「주문서.pdf」라는 첨부 이름은 여러 거래처에서 여러 번 옵니다. 받은 이름 그대로 저장하면 같은 이름끼리 반드시 부딪칩니다. 저장할 때 파일 이름은 수신 메일 정보로 기계적으로 조립해 고유하게 만듭니다. 실무에서는 「수신 일시(초까지)+보낸 사람 도메인+원래 파일 이름」처럼 이름 붙이면 충돌을 거의 피하고, 나중에 메일과 대조하기도 쉽습니다.

SharePoint 「파일 만들기」의 파일 이름 칸에는 다음 식을 넣습니다.

concat(
  convertFromUtc(triggerOutputs()?['body/receivedDateTime'], 'Tokyo Standard Time', 'yyyyMMdd-HHmmss'),
  '_',
  last(split(triggerOutputs()?['body/from'], '@')),
  '_',
  items('Apply_to_each')?['name']
)

세 조각의 의미는 다음과 같습니다.

• 수신 일시: receivedDateTime은 UTC로 오므로, formatDateTime만으로 꾸미면 일본 시간과 9시간 어긋나, 날짜가 바뀌는 저녁 이후 메일이 전날 파일 이름이 됩니다. convertFromUtc의 두 번째 인수에 Windows 시간대 ID Tokyo Standard Time을 넣고, 세 번째 인수로 형식을 지정하는 편이 확실합니다. 수신 일시 자체는 동적 콘텐츠에서도 고를 수 있습니다.
• 보낸 사람 도메인: split으로 @ 앞뒤를 나누고, last로 뒤쪽(도메인)을 가져옵니다. 표시 이름이 아니라 도메인을 쓰는 이유는, 표시 이름에 공백이나 기호가 들어가 다루기 어렵기 때문입니다.
• 원래 파일 이름: Apply to each의 현재 첨부 파일 이름입니다. 확장자까지 들어 있으므로 .pdf를 더 붙일 필요는 없습니다.

SharePoint 파일 이름에는 \ / : * ? " < > |를 쓸 수 없습니다. 제목이나 보낸 사람 표시 이름을 파일 이름에 섞으면, 이런 문자가 들어오는 순간 저장이 실패합니다. 위처럼 형식이 기계적으로 정해지는 값만으로 조립하는 편이 안전합니다.

또한 플로우를 고친 뒤 테스트로 수동 재실행하는 경우처럼, 같은 메일을 두 번 처리하는 상황도 있습니다. 수신 일시 기반 이름이면 이때 쓰는 곳은 같은 메일에서 온 같은 이름 파일뿐이므로, 다른 거래처 파일까지 지워 버리는 일은 없습니다. 다만 같은 이름에 두 번째 쓰기는 그 자체로 충돌하므로(덮어쓰든 실패하든 내용은 같습니다), 이중 처리 자체를 잡고 싶다면 트리거 출력의 메시지 ID를 저장 목록 열이나 파일 이름에 넣어 두면, 이미 처리했는지 기계적으로 대조할 수 있습니다.¹

4.4 누락 감지 ── 「트리거가 돌지 않은 메일」을 알아챌 수 있는가

놓치기 쉽지만, 수신 트리거는 만능이 아닙니다. 문서에 명시된 제한으로 다음 경우가 있습니다.

• 합계 크기가 Exchange 관리자가 정한 상한 또는 50 MB 중 더 작은 쪽을 넘는 메일은 트리거가 건너뜁니다. 보호된 메일(암호화 메일)이나 본문·첨부가 잘못된 메일도 건너뛰는 경우가 있습니다¹
• 동시에 메일이 대량으로 오면, 시스템 쪽 제한 때문에 드물게 트리거가 메일을 놓칠 수 있습니다¹¹

즉 「플로우가 오류가 난 것」이 아니라 「애초에 실행되지 않은」 메일이 생길 수 있습니다. 오류 알림만 보고 있어서는 이 누락을 알아채지 못합니다. 대책으로는 플로우 성공·실패 알림에 더해, 받은 편지함을 사람이 주기적으로 확인하는 운용을 남기는 것(처리한 메일은 플로우로 폴더를 옮기고, 받은 편지함에 남은 것은 미처리로 보이게 하는 것)이 현실적입니다.

이 폴더 이동에는 Office 365 Outlook 커넥터의 「메일 이동 (Move email (V2))」 액션을 씁니다.¹² 알림 바로 뒤에 두고, 공유 사서함의 「처리됨」 폴더로 옮기는 형태입니다. 「메일을 읽음 또는 읽지 않음으로 표시 (Mark as read or unread (V3))」로도 처리 여부는 표시할 수 있지만, 읽은 메일은 받은 편지함에 계속 남습니다. 「받은 편지함에 남아 있다 = 미처리」라는 한눈에 보이는 상태를 만들려면 이동이 더 확실합니다. 이동 대상은 트리거가 감시하는 폴더(보통은 받은 편지함)가 아닌 다른 폴더로 하십시오. 감시 대상 폴더로 옮기면, 이동 자체가 새 메일로 다루어져 다시 실행될 여지가 남습니다. 메일 자체의 크기 상한은 Exchange Online 쪽 설정으로 정해지고, 기본값은 수신 36 MB, 관리자 설정으로 1~150 MB 범위에서 바꿀 수 있습니다. 대용량 첨부를 주고받는 거래처에는 뒤에서 말하는 파일 공유 링크 등 다른 전달 방법을 검토합니다.¹³

5. 읽기(기입 자동화)까지 갈 것인가 ── AI Builder의 문서 처리

저장과 알림이 돌기 시작하면 다음에 하고 싶어지는 것이 「PDF 내용을 읽어 대장에 쓰기까지 자동화하고 싶다」입니다. 여기서 쓰는 것이 AI Builder의 문서 처리입니다.

5.1 사전 구축 모델과 커스텀 모델

AI Builder에는 청구서용 사전 구축 청구서 처리 모델이 있습니다. 청구서 번호·청구일·지급 기한·거래처명·합계 금액·명세 행 같은 공통 필드를 모델 학습 없이 그대로 추출할 수 있고, 지원 언어에 일본어도 들어 있습니다. 입력은 JPEG/PNG/PDF이며, 파일 크기는 20 MB까지라는 제한이 있습니다.¹⁴

한편 주문서처럼 회사마다 레이아웃이 다른 문서나, 청구서라도 표준 필드 밖 항목(자사 관리 번호 등)을 가져오고 싶을 때는 문서 처리 커스텀 모델을 만듭니다. 「고정 템플릿 문서」「일반 문서」「청구서(사전 구축 모델 확장)」 세 유형에서 고르고, 같은 레이아웃 문서를 컬렉션으로 묶어, 컬렉션당 최소 5건의 샘플 문서를 올린 뒤, 추출할 필드나 표를 태그해 학습시킵니다.¹⁵

플로우에 넣는 일은 둘 다 간단합니다. 청구서 처리 모델이면 「청구서에서 정보 추출」 액션, 커스텀 모델이면 「문서 처리」 액션에 SharePoint에 저장한 PDF의 파일 콘텐츠를 넘기기만 하면 됩니다.¹⁶⁸

5.2 정확도와 예외 처리 ── 신뢰도 점수로 사람 확인에 돌린다

읽기 자동화에서 가장 중요한 것은 「추출은 틀릴 수 있다」를 전제로 설계하는 일입니다. AI Builder 추출 결과에는 필드마다 0~1의 신뢰도 점수가 붙습니다. 실무에서는 이 점수로 플로우를 나눕니다.¹⁶

• 점수가 높다(예: 0.9 이상) → 그대로 대장에 쓰고, 알림은 「자동 처리됨」
• 점수가 낮다 → 대장에는 「확인 필요」로 쓰고, 담당자에게 「이 항목을 확인해 주십시오」라고 알린다

위의 0.9는 어디까지나 적는 방식의 예이며, 모든 문서에 맞는 값이 아닙니다. 임계값은 자사 문서로 정하는 것이므로, 다음 순서로 냅니다.

1. 임계값 없이 한 번 흘린다. 운영과 같은 거래처·같은 레이아웃 문서를 20~50건 마련하고, 분기 없이 전건을 읽게 합니다. 추출 값과 신뢰도 점수를 그대로 SharePoint 목록이나 Excel에 꺼내 둡니다.
2. 정답과 대조한다. 한 건씩 눈으로 맞고 틀림을 매기고, 필드마다 「틀린 추출의 점수 최댓값」을 봅니다. 임계값 하한은 그보다 조금 위입니다.
3. 필드마다 다르게 둔다. 합계 금액·청구서 번호처럼 틀리면 뒤에 파급되는 항목은 높게, 비고처럼 나중에 고칠 수 있는 항목은 낮게 둡니다. 한 임계값으로 모든 필드를 자르려 하면 어딘가는 반드시 불편해집니다.
4. 운영 뒤에 다시 본다. 「확인 필요로 보낸 건수」와 「실제로 수정이 필요했던 건수」를 남겨 두고, 분기에 한 번 다시 봅니다. 확인 필요만 많으면 학습 샘플을 더하고, 반대로 확인 필요가 거의 없는데 오류가 새면 임계값을 올리는 식의 조정입니다.

Microsoft 문서 자체가 사전 구축 모델과 커스텀 모델을 조합해, 신뢰도 점수가 낮을 때 다른 쪽으로 폴백하는 구성 예를 소개합니다.¹⁴ 「전부 자동으로 읽히면 이득이고, 못 읽은 분만 사람이 본다」는 설계로 두면, 정확도 100%를 쫓지 않아도 되어 도입 문턱이 크게 낮아집니다.

5.3 라이선스와 크레딧 ── 여기는 사전 확인이 필수

AI Builder 액션은 실행할 때마다 사용량 기반 용량을 씁니다. 그동안 이 용량은 AI Builder 크레딧이라 불렸고, AI Builder 용량 애드온(애드온 하나당 월 100만 크레딧) 외에 Power Automate Premium 같은 Premium 라이선스에도 소량(Power Automate Premium에서 5,000 크레딧)이 붙어 왔습니다. 크레딧은 테넌트 단위로 모였다가, 환경에 할당해 씁니다. 환경에 용량이 없으면 플로우는 NoCapacity 같은 오류로 멈춥니다.⁶

다만 이 체계는 이 글을 쓰는 시점(2026년 7월) 기준으로 이행기입니다. 2025년 10월에 AI Builder 크레딧의 단계적 종료가 발표되었고, Premium 라이선스에 붙던 시드 크레딧은 2026년 11월 1일에 끝나며, 신규 고객은 AI Builder 용량 애드온을 사지 못하고 Copilot 크레딧을 사는 형태로 바뀌었습니다. AI Builder 기능 자체는 Copilot 크레딧으로 계속 쓸 수 있지만, 클라우드 플로우에서는 AI Builder 크레딧을 먼저 쓰고, 떨어지면 Copilot 크레딧을 쓰는 우선순위입니다.⁷¹⁷

정리하면 「읽기까지 하려면 추가 비용이 든다. 그 체계는 2026년 7월 시점에서 바로 바뀌는 중」입니다. 시드 크레딧 종료일(2026년 11월 1일)을 지나 읽고 있다면 전제가 바뀌었을 가능성이 높으니, 반드시 1차 정보로 현재 체계를 확인하십시오. 도입 판단의 가늠을 표로 둡니다.

6. 비밀번호가 걸린 ZIP(PPAP)이 오는 경우 ── 플로우로 푸는 이야기가 아니다

「첨부가 비밀번호가 걸린 ZIP으로 오는데, 플로우로 압축을 풀 수 있나요」라는 질문도 단골입니다. 결론부터 말하면, 플로우 안에서 풀려고 하지 마십시오.

비밀번호가 걸린 ZIP 운용은, 비밀번호가 다른 메일로 오고 사람이 그것을 읽어 손으로 입력해 연다는 전제로 성립합니다. 비밀번호 안내 시점이나 형식도 상대에게 맡겨져 있어, 기계 처리를 상정한 장치가 아닙니다. 여기를 억지로 자동화하려 하면, 비밀번호 메일 분석이나 비밀번호 보관처럼 원래 할 필요 없는 위험한 장치를 떠안게 됩니다.

애초에 PPAP는 같은 경로로 열쇠와 짐을 보내는 시점에서 보안 대책으로서의 의미도 빈약하고, 수신 측 바이러스 검사를 그냥 통과시키는 해가 더 큰 운용입니다. 이 문제점과 대안(파일 공유 링크 등)은 별도 글 「왜 메일 보안에서 PPAP는 안 되는가. 올바른 방법은?」에서 자세히 썼습니다. 자동화 맥락에서 말하면, PPAP로 오는 문서는 「받는 방식을 바꾸도록 설득해야 할 대상 목록」의 맨 앞입니다. 거래처에도 「자동 처리 때문에 비밀번호가 걸린 ZIP이 아니라 암호 없는 PDF 첨부 또는 파일 공유 링크로 부탁한다」는 요청은, PPAP 폐지 흐름도 있어 예전보다 통하기 쉬워졌습니다.

7. 그다음 ── 메일 첨부 운용의 한계와 단계적 이전

저장도 알림도 읽기도 갖춘 뒤에 남는 것은, 「애초에 메일 첨부로 문서를 주고받는다」는 것 자체의 한계입니다.

• 문서 레이아웃은 거래처 수만큼 있고, 읽기 모델 유지는 거래처가 늘수록 무거워진다
• 읽기 정확도는 100%가 되지 않으므로, 사람 확인 공정은 영원히 남는다
• 메일은 도착하지 않는 경우가 있고(크기 초과, 스팸 판정), 누락 감시도 계속 남는다

이것은 Power Automate 설계를 아무리 다듬어도 사라지지 않습니다. 공정의 출발점이 「비구조화 데이터(PDF)를 사람 앞으로 보내는 것」인 한, 읽기와 확인은 필요 비용으로 남습니다. 그래서 중기적으로는 처음부터 구조화 데이터로 받는 방향, 즉 웹 수주 폼, EDI, 청구서라면 디지털 인보이스(Peppol / JP PINT)로의 단계적 이전을 시야에 둘 가치가 있습니다.

이전은 한번에 갈아탈 필요가 없습니다. 응해 주는 거래처부터 새 수신 방식으로 옮기고, 나머지는 메일 첨부+자동 처리로 받는 이중 운용이 현실적입니다. 이 단계적 이전의 설계는 「FAX 수주를 웹으로 옮기려면 ── 이중 운용 기간 설계와 단계 이전 실무」에서, 디지털 인보이스 구조는 「디지털 인보이스란? ── 「청구서 PDF를 메일로 보내는 것」과 무엇이 다른가」에서 정리했습니다. 이 글의 플로우는 그 이전 기간 중 「메일 첨부로 계속 받는 몫」을 받치는 장치로 두는 편이 좋다고 봅니다.

8. 정리

메일로 오는 주문서·청구서 PDF 처리는 Power Automate 자동화 주제로 보면 입문 쪽에 가깝지만, 실제 운영을 견디게 하려면 짚어야 할 점이 분명합니다.

먼저 수신 창구를 공유 사서함의 전용 주소로 두고, 좁히기 조건은 트리거 쪽으로 모읍니다. 첨부 선별은 Is Inline과 확장자 두 겹으로 서명 이미지를 뺍니다. 파일 이름은 수신 일시 기반으로 고유하게 만들고, 트리거가 건너뛰는 경우(50 MB 초과, 암호화 메일, 동시 대량 수신)가 있음을 전제로, 누락을 알아챌 수 있는 운용을 남깁니다. 여기까지가 첫 단계입니다.

읽기까지 간다면 AI Builder의 사전 구축 모델 또는 커스텀 모델을 신뢰도 점수 분기와 세트로 쓰고, 사용량 기반 크레딧 비용과 이행 중인 라이선스 체계를 미리 확인합니다. 그리고 비밀번호가 걸린 ZIP은 플로우로 풀지 말고, 받는 방식을 바꾸는 설득 대상으로 둡니다. 메일 첨부라는 형식 자체의 한계가 보이기 시작하면 웹 폼·EDI·디지털 인보이스로의 단계적 이전을 검토합니다——이 순서로 가면 큰 재작업 없이 키워 갈 수 있는 영역입니다.

관련 글

• Power Automate로 업무를 자동화하기 ── 클라우드 플로우·데스크톱 플로우 구분과 오류 처리 설계
• 왜 메일 보안에서 PPAP는 안 되는가. 올바른 방법은?
• EDI란? 기업 간 수발주를 어떻게 편하게 만드는가 ── FAX·메일·손입력에서 데이터 연동으로
• FAX 수주를 웹으로 옮기려면 ── 이중 운용 기간 설계와 단계 이전 실무
• 디지털 인보이스란? ── 「청구서 PDF를 메일로 보내는 것」과 무엇이 다른가

관련 상담 영역

합동회사 코무라소프트에서는 Power Automate를 이용한 메일·문서 처리 자동화 설계와, 수발주 업무 디지털화를 위한 단계적 이전 상담을 다루고 있습니다.

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

공유 사서함에 도착한 메일로도 Power Automate 플로우를 실행할 수 있나요?

가능합니다. Office 365 Outlook 커넥터에는 ‘공유 사서함에 새 메일이 도착했을 때(V2)’라는 전용 트리거가 있어, 주문 접수용 공유 주소로 들어온 메일을 기점으로 플로우를 돌릴 수 있습니다. 전제는 연결에 쓰는 계정이 그 공유 사서함에 대한 액세스 권한을 갖고 있어야 한다는 점입니다. 권한을 막 부여한 뒤에는 적용까지 2시간 정도 걸릴 수 있고, Microsoft 365 그룹 주소는 공유 사서함으로 지정할 수 없다는 점도 알아 두십시오. 담당자 개인 받은 편지함보다 공유 사서함으로 받는 편이 수신 창구를 넘기기 쉽습니다. 다만 플로우 연결 자체는 만든 사용자 계정에 묶이므로, 연결에 쓰는 계정을 어떻게 둘지와 공동 소유자 설정도 함께 정해 두어야 합니다.

메일 서명 이미지가 첨부 파일로 저장되는 이유는 무엇인가요?

본문에 심어 둔 서명 이미지나 로고는 데이터상으로는 첨부 파일의 한 종류(인라인 첨부)로 다루어지기 때문입니다. ‘첨부 파일 있음’ 조건만으로 처리하면 정작 필요한 PDF와 함께 서명의 PNG나 GIF까지 저장됩니다. 대책으로는 Office 365 Outlook 커넥터가 첨부마다 돌려주는 Is Inline 메타데이터를 조건 분기에 써서, Is Inline이 false인 것만 처리합니다. 파일 이름 확장자가 .pdf인지도 함께 보면 대상을 더 확실하게 좁힐 수 있습니다.

AI Builder로 PDF 읽기까지 자동화하려면 무엇이 필요한가요?

AI Builder에는 청구서에서 청구서 번호·날짜·합계 금액 등을 뽑아내는 사전 구축 청구서 처리 모델이 있으며, 일본어 청구서에도 대응합니다. 주문서처럼 레이아웃이 제각각인 문서는 샘플 문서(레이아웃당 최소 5건)로 학습시키는 문서 처리 커스텀 모델로 맞춥니다. 실행에는 AI Builder 크레딧 같은 사용량 기반 용량이 필요하고, 환경에 용량이 할당되어 있지 않으면 플로우가 오류로 멈춥니다. 또한 2025년 10월에 AI Builder 크레딧의 단계적 종료가 발표되어 앞으로는 Copilot 크레딧으로 옮겨 가므로, 새로 도입할 때는 최신 라이선스 체계를 확인하십시오.

비밀번호가 걸린 ZIP(PPAP)으로 오는 첨부 파일도 플로우로 처리할 수 있나요?

비밀번호가 걸린 ZIP은 자동 처리와 근본적으로 맞지 않아, 플로우 안에서 풀 것을 전제로 설계해서는 안 됩니다. 비밀번호가 다른 메일로 오고 사람이 읽은 뒤에야 연다는 운용 자체가 기계 처리를 염두에 두지 않았기 때문입니다. ZIP 그대로 저장해 사람이 여는 곳에 두는 것은 가능하지만, 그것으로는 기입이나 읽기 자동화로 이어지지 않습니다. 현실적인 대책은 거래처에 PPAP를 그만두도록 설득하는 것, 즉 파일을 받는 방식 자체를 바꾸는 일입니다. 보안 면에서도 PPAP는 문제가 많으므로, 설득 자료로 PPAP의 문제점을 정리한 글도 참고하십시오.

저자 프로필

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

Go Komura

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

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