메일로 도착하는 주문서・청구서 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)으로 도착하는 첨부 파일은 플로우로 풀려고 하지 말고, 받는 방식 자체를 바꾸는 것이 본질적인 대책입니다.

2. 대상 업무의 정리 ── “메일 첨부로 도착하는 서식”을 어디까지 자동화할 것인가

먼저 이 글이 대상으로 하는 업무의 형태를 확인해 두겠습니다.

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

수발주를 받는 방식에는 FAX, 메일 첨부, 웹 폼, EDI와 같은 단계가 있습니다. 메일 첨부는 FAX보다는 데이터화하기 쉬운 한편, 구조화된 데이터 연계인 EDI나 디지털 인보이스에는 미치지 못하는 중간적인 위치에 있습니다. 이 전체상은 별도 글 “EDI란 무엇인가? 기업 간 수발주를 어떻게 편하게 만드는가 ── 팩스・메일・수작업 입력에서 데이터 연계로“에서 정리하고 있습니다.

그 위에서 메일 첨부 운용을 유지한 채 자동화로 노릴 수 있는 범위를 나누면 다음 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']
)

3개 부품의 의미는 다음과 같습니다.

• 수신 일시: 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까지라는 제한이 있습니다.¹⁴

한편 주문서처럼 회사마다 레이아웃이 다른 서식이나, 청구서라도 표준 필드 이외의 항목(자사 관리 번호 등)을 가져오고 싶은 경우에는 문서 처리 커스텀 모델을 만듭니다. “고정 템플릿 문서” “일반 문서” “청구서(사전 구축된 모델의 확장)”의 3가지 유형 중에서 선택하고, 같은 레이아웃의 서식을 컬렉션으로 묶어 1컬렉션당 최소 5건의 샘플 문서를 업로드하여 추출하고 싶은 필드나 표를 태그 지정해 학습시킵니다.¹⁵

플로우로의 편입은 둘 다 간단하며, 청구서 처리 모델이라면 “청구서에서 정보 추출” 액션에, 커스텀 모델이라면 “문서 처리” 액션에 SharePoint에 저장한 PDF의 파일 콘텐츠를 전달하기만 하면 됩니다.¹⁶⁸

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

읽기 자동화에서 가장 중요한 것은 “추출은 틀릴 수 있다”를 전제로 설계하는 것입니다. AI Builder의 추출 결과에는 필드마다 0〜1의 신뢰도 점수가 붙어 나옵니다. 실무에서는 이 점수로 플로우를 분기시킵니다.¹⁶

• 점수가 높음(예: 0.9 이상) → 그대로 대장에 기록하고 알림은 “자동 처리 완료”
• 점수가 낮음 → 대장에는 “확인 필요”로 기록하고 담당자에게 “이 항목을 확인해 주세요”라고 알림

위의 0.9는 어디까지나 작성 방법의 예시로, 어떤 서식에도 해당하는 값은 아닙니다. 임계값은 자사의 서식으로 정하는 것이므로 다음 절차로 산출합니다.

1. 임계값 없이 한 번 흘려본다. 실제 운영과 같은 거래처・같은 레이아웃의 서식을 20〜50건 준비하여 분기를 넣지 않고 전건을 읽힙니다. 추출값과 신뢰도 점수를 그대로 SharePoint 목록이나 Excel에 기록해 둡니다.
2. 정답과 대조한다. 1건씩 육안으로 정오를 표시하고, 필드마다 “잘못 추출된 것의 점수 최댓값”을 봅니다. 임계값의 하한은 이보다 약간 위입니다.
3. 필드마다 다르게 한다. 합계 금액・청구서 번호처럼 틀리면 하류에 영향이 미치는 항목은 높게, 비고처럼 나중에 고칠 수 있는 항목은 낮게 설정합니다. 하나의 임계값으로 모든 필드를 재단하려고 하면 어딘가가 반드시 불편해집니다.
4. 운용 후 재검토한다. “확인 필요로 돌린 건수”와 “실제로 수정이 필요했던 건수”를 기록해 두고 분기마다 한 번씩 재검토합니다. 확인 필요만 있다면 학습용 샘플을 추가하고, 반대로 확인 필요가 거의 나오지 않는데 오류가 빠져나가고 있다면 임계값을 올린다는 조정이 됩니다.

Microsoft의 문서 자체가 사전 구축된 모델과 커스텀 모델을 조합하여 신뢰도 점수가 낮은 경우 다른 한쪽 모델로 폴백시키는 구성 예를 소개하고 있습니다.¹⁴ “전부 자동으로 읽을 수 있으면 이득이고, 읽지 못한 부분만 사람이 본다”는 설계로 하면 정확도 100%를 좇지 않아도 되어 도입 문턱이 크게 낮아집니다.

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

AI Builder의 액션은 실행할 때마다 소비형 용량을 사용합니다. 종래 이 용량은 AI Builder 크레딧이라 불렸으며, AI Builder 용량 애드온(애드온 1개당 월 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 초과, 암호화 메일, 동시 대량 수신)가 있음을 전제로 놓침을 알아챌 수 있는 운용을 남긴다. 여기까지가 1단계입니다.

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

관련 글

• Power Automate로 업무 자동화하기 ── 클라우드 플로우・데스크톱 플로우 구분과 오류 처리 설계
• 왜 이메일 보안에서 PPAP는 안 되는가. 올바른 방법은?
• EDI란 무엇인가? 기업 간 수발주를 어떻게 편하게 만드는가 ── 팩스·메일·수작업 입력에서 데이터 연계로
• 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.