메시지 전체, 본문, PDF 첨부 파일을 읽고 필드를 스프레드시트 열로 정리하는 AI 이메일 파서
각 이메일을 직접 열고 첨부 파일을 다운로드한 뒤 필드를 스프레드시트에 입력하는 작업은 문서당 약 3분이 걸립니다. 이 도구는 본문과 첨부 파일을 5~10초 안에 파싱합니다.
페이지당 5~10초 · 인쇄 텍스트 최대 99% 정확도 · 전용 받은편지함 주소 · 발신자별 규칙 불필요
이메일 파서가 모든 메시지와 첨부 파일에서 추출하는 정보
이메일 파서는 비정형 메시지를 스프레드시트 행으로 변환합니다. ImageToTable.ai는 메시지의 두 부분을 모두 처리합니다: 모든 도구가 볼 수 있는 헤더 필드와 일반적으로 첨부 파일 안에 있는 데이터로, 비전 모델이 업로드된 문서를 읽는 것과 동일한 방식으로 PDF, 스캔본, 사진을 읽습니다. 열 이름을 입력하면 전달된 모든 이메일이 해당 헤더를 가진 행으로 저장됩니다.
다음은 예시 열 이름입니다. 본문 필드는 메시지 자체에서 가져오며, 라인 항목 및 합계와 같은 필드는 PDF 또는 이미지 첨부 파일에서 읽어옵니다. 한 번 정의하면 전달된 모든 이메일에서 동일한 구조의 행이 생성됩니다.
데이터는 보통 이메일 본문이 아니라 첨부 파일에 있습니다.
이 검색어에서 상위에 노출되는 대부분의 도구는 메시지 본문만 읽고 멈추는 이메일 파서입니다. 이메일 자체가 문서였던 시절에는 합리적인 설계였지만, 청구서, 주문 확인서, 은행 통지의 경우 메시지는 PDF를 감싼 봉투에 불과합니다. 이러한 설계에서 세 가지 구조적 문제가 발생하며, 많은 파싱 설정이 조용히 무너지는 이유를 설명합니다.
본문 텍스트 파싱의 한계
본문 전용 파서는 데이터가 시작되는 지점에서 멈춥니다. 주문 확인 이메일은 4페이지 분량의 PDF 청구서를 감싼 두 문장의 산문에 불과합니다. 본문 파서는 산문, 제목 줄, 그리고 텍스트에 언급된 총액 정도를 포착하지만, 청구서 번호, 품목, 세금 내역은 열지 않는 첨부 파일 안에 있습니다. 이 범주의 Gmail 및 Sheets 애드온은 "템플릿 이메일"을 파싱할 뿐, 첨부된 문서는 파싱하지 않습니다.
파싱 규칙은 한 발신자의 레이아웃에 묶여 있으며, 공급업체 문서도 이를 인정합니다. cloudHQ의 설정 가이드는 모든 메시지가 "유사한 형식"을 가져야 하므로 단일 발신자와 제목으로 필터링하라고 안내합니다. Mailparser의 자체 도움말 센터는 각 규칙을 "텍스트의 고정된 위치"를 기준으로 구축할 것을 권장합니다. 공급업체가 "Total"을 "Amount Due"로 바꾸거나 템플릿을 재구성하면 규칙은 오류를 내지 않습니다. 잘못된 범위를 포착하거나 아무것도 포착하지 못합니다.
이메일 노이즈는 위치 기반 규칙을 무력화합니다. 서명 블록, 법적 고지, 인용된 회신 체인으로 인해 "Total: 다음의 텍스트"가 한 메시지에 세 번 나타날 수 있으며, 가장 오래된 사본은 보통 인용된 스레드에 있습니다. r/ConnectWise의 파싱 규칙 스레드는 이를 명확히 설명합니다: "파싱 규칙의 문제는 항상 사용할 수 없고 이메일 제목 줄에 따라 달라진다는 것입니다."
열 이름 추출이 처리하는 방식
첨부 파일은 건너뛰지 않고 문서로 읽힙니다. 비전 모델은 직접 업로드한 파일과 동일한 방식으로 PDF, 스캔본, 사진을 읽으며, 인쇄된 텍스트에 대해 최대 99% 정확도를 제공합니다. 비밀번호로 보호된 첨부 파일도 처리됩니다. 설정에 자주 사용하는 비밀번호를 저장해 두면, 암호화된 PDF도 처리 전에 자동으로 시도됩니다. 본문 필드와 첨부 파일 필드는 한 행에 함께 저장됩니다.
열을 한 번 정의하면 모든 발신자에 적용됩니다. 이것이 맞춤 열 추출입니다. 원하는 열 이름을 입력하면 AI가 위치가 아닌 의미를 파악하여 각 값을 찾습니다. 새 발신자나 이메일을 재설계한 기존 발신자도 재구성이 전혀 필요 없습니다. 또한 모든 계정에 전용 받은편지함 주소가 하나씩 제공되므로, 규칙 기반 도구처럼 레이아웃별로 사서함을 유지할 필요 없이 모든 이메일을 한 곳으로 전달하면 됩니다.
의미 기반 읽기는 메일 장식 요소의 영향을 받지 않습니다. 서명, 면책 조항, 인용된 스레드 텍스트는 필드 값과 혼동되지 않습니다. 추출이 위치가 아닌 의미를 기준으로 실행되기 때문입니다. "합계"라는 단어가 포함된 면책 조항은 합계가 아닙니다. 전달된 체인에 동일한 수치의 이전 버전이 포함된 경우, bbox 강조 표시가 있는 검토 모드에서 각 추출 값이 어떤 항목에서 왔는지 정확히 보여주므로 재검토 대신 한눈에 확인할 수 있습니다.
세 가지 문제의 공통 패턴은 동일합니다. 규칙 기반 이메일 파싱은 발신자와 레이아웃 변경마다 새로운 작업을 요구합니다. 의미 기반 추출은 스키마를 한 번만 정의하고 발신자를 흡수합니다.
메일 클라이언트를 열지 않고 공급업체 이메일을 스프레드시트 행으로
이메일로 도착하는 공급업체 청구서를 처리한다면, 메시지 도착부터 내보내기까지의 전체 과정은 다음과 같습니다.
전용 받은편지함 주소로 전달하세요
모든 계정에는 받은편지함 주소가 하나씩 제공됩니다. 이 주소를 공급업체와 공유하거나, 자신의 메일함에 전달 규칙을 설정하여 청구서가 자동으로 라우팅되도록 하세요. 발신자 화이트리스트를 활성화하면 관련 없는 메일이 큐에 섞이지 않으며, 자동 처리를 켜면 메시지가 도착하는 즉시 다음 단계에서 정의한 열 템플릿을 사용하여 추출이 시작됩니다. 첨부 파일은 자체적으로 처리 큐에 들어오므로, 누구도 다운로드하거나 재업로드할 필요가 없습니다.
주소 하나면 어떤 메일함이든 업로드 단계가 필요 없습니다.
열 이름을 한 번만 지정하세요
원하는 필드를 입력하세요: 발신자, 청구서 번호, 청구서 날짜, 마감일, 합계, 그리고 품목과 같은 첨부 파일 관련 필드도 포함됩니다. 이 이름들은 출력 스프레드시트의 정확한 헤더가 됩니다. 열 세트를 템플릿으로 저장하면 자동 처리가 모든 수신 메일에 이를 재사용합니다. AI가 각 메시지와 첨부 파일을 읽고 가능한 모든 열을 채우며, 특정 이메일에 없는 필드는 추측하지 않고 비워 둡니다.
열 이름이 곧 출력입니다. 발신자별 규칙이 필요 없습니다.
배치 내보내기
각 이메일은 한 행이 되며, 본문 필드와 첨부 파일 필드가 나란히 배치됩니다. 배치를 XLSX, CSV 또는 JSON으로 내보내거나, 애드온을 통해 결과를 Google Sheets에 직접 저장할 수 있습니다. 날짜와 금액은 추출 과정에서 표준화되므로, 별도의 정리 작업 없이 AP 또는 보고 워크플로우에 바로 사용할 수 있는 파일이 생성됩니다.
| 발신자 | 청구서 번호 | 납기일 | 합계 |
|---|---|---|---|
| [email protected] | INV-88213 | 2026-09-30 | $4,218.60 |
| [email protected] | VP-10427 | 2026-10-07 | $1,102.00 |
예시 값입니다. 발신자는 메시지 헤더에서 가져오며, 나머지는 첨부된 청구서 PDF에서 가져옵니다.
이 이메일 파서가 잘하는 것과 의도적으로 하지 않는 것
이메일 내용과 첨부 파일을 열로 파싱하는 것은 범위가 정해진 작업이며, 그 위에 워크플로를 구축하기 전에 경계가 어디에 있는지 정확히 아는 것이 중요합니다.
가장 적합한 경우
실제 콘텐츠가 PDF 또는 이미지 첨부 파일인 이메일. 청구서, 구매 주문서, 은행 거래 내역서, 배송 명세서는 일반적으로 첨부 파일로 도착합니다. 첨부 파일은 전체 문서로 파싱되므로 품목 및 합계가 유지되며, 단순한 커버 노트만 처리되지 않습니다.
화이트리스트에 등록할 수 있는 반복 발신자. 자동 처리와 바인딩된 템플릿이 활성화되면 클릭 없이 도착 즉시 추출이 시작됩니다. 주소를 공급업체나 고객과 공유하는 경우 화이트리스트를 통해 큐를 깨끗하게 유지할 수 있습니다.
혼합 발신자와 변화하는 형식. 하나의 받은 편지함 주소와 하나의 열 세트로 모든 발신자를 처리할 수 있으므로, 공급업체가 이메일을 재설계하거나 새 공급업체가 추가되어도 유지 관리 작업이 발생하지 않습니다.
주의가 필요한 경우
열을 생성할 뿐, 백오피스 운영을 대신하지 않습니다. 이 도구는 이메일 내용과 첨부 파일을 구조화된 데이터로 파싱합니다. 답장을 보내거나, 사서함 규칙을 관리하거나, 누락된 필드를 공급업체에 추적하거나, CRM이나 회계 시스템을 대체하지 않습니다. 이후 스프레드시트로 무엇을 할지는 사용자의 워크플로우에 달려 있습니다.
첨부 파일 품질은 여전히 중요합니다. 디지털 PDF는 화면을 촬영한 사진보다 훨씬 안정적으로 추출됩니다. 사람이 첨부 파일의 필드를 읽기 위해 눈을 찡그려야 한다면, 모델도 그 필드를 읽는 데 어려움을 겪을 가능성이 높습니다. 손으로 쓴 문서나 심하게 손상된 스캔본은 검토 과정을 거치는 것이 좋습니다.
긴 전달 체인은 확인이 필요합니다. 추출은 의미를 기준으로 읽지만, 동일한 수치의 이전 버전을 여러 개 인용하는 체인은 값이 어느 항목에서 왔는지 확인하는 데 30초가 걸릴 수 있는 유일한 시나리오입니다. bbox 하이라이트가 있는 검토 모드가 바로 이러한 경우를 위해 존재합니다.
자주 묻는 질문
어떤 사서함에서 자동 전달할 수 있나요? Gmail, Outlook, Zoho 이메일 파서 설정이 있나요?
전달을 지원하는 모든 사서함에서 작동합니다. 파서는 사서함에 로그인하지 않기 때문입니다. 모든 ImageToTable.ai 계정에는 전용 수신 주소가 하나 제공되므로, gmail 이메일 파서, outlook 이메일 파서, zoho 이메일 파서 같은 검색어는 모두 동일한 설정으로 이어집니다. 즉, Gmail, Outlook, Zoho Mail 또는 기타 클라이언트에서 해당 주소로 메시지를 보내는 전달 규칙을 만드는 것입니다. 파서는 전달된 내용만 확인하며, 발신자 화이트리스트를 통해 관련 없는 발신자는 대기열에서 제외됩니다. 이메일을 파싱하며 문자 메시지는 처리하지 않습니다. SMS 전달은 이 도구의 범위를 벗어납니다.
첨부 파일도 읽나요, 아니면 이메일 본문만 읽나요?
둘 다 읽으며, 보통 첨부 파일이 더 중요한 부분입니다. 본문 텍스트 파서는 본문과 제목 줄까지만 처리하지만, 청구서 이메일의 경우 청구서 번호, 품목, 합계는 PDF 첨부 파일 안에 있습니다. ImageToTable.ai는 업로드된 PDF나 스캔 문서를 읽는 것과 동일하게 비전 모델로 첨부 파일을 문서로 읽고, 본문 필드와 첨부 파일 필드를 동일한 스프레드시트 행에 기록합니다.
공급업체가 이메일 형식을 변경하면 어떻게 되나요?
아무 문제가 발생하지 않습니다. 발신자별 규칙이 없기 때문입니다. 템플릿 기반 파서는 모든 필드를 특정 발신자 레이아웃의 고정 위치나 라벨에 연결하므로, 라벨 이름이 바뀌거나 템플릿이 재구성되면 잘못된 값이 반환되거나 아무것도 반환되지 않습니다. 여기서는 출력 열을 한 번 정의하면 AI가 의미를 기준으로 각 값을 찾으므로, 새 발신자나 재설계된 이메일에도 재구성이 전혀 필요 없습니다. 설정을 변경해야 하는 경우는 이전에 추출하지 않던 필드를 새로 캡처하려 할 때뿐이며, 이때도 규칙을 수리하는 것이 아니라 열을 추가하는 것입니다.
PDF 첨부 파일에서 청구서 번호와 합계를 자동으로 추출해 Excel로 가져올 수 있나요?
네. 원하는 열을 정의하고 템플릿에 연결한 다음 수신함에 자동 처리를 켜면 됩니다. 이후 청구서 PDF가 포함된 이메일이 전달될 때마다 누군가 메시지를 열지 않아도 스프레드시트 행이 생성됩니다. 비밀번호로 보호된 첨부 파일도 처리할 수 있습니다. 설정에 사용하는 비밀번호를 미리 저장해 두면 암호화된 PDF도 처리 전에 자동으로 시도됩니다. 결과는 XLSX, CSV, JSON으로 내보내거나 애드온을 통해 Google Sheets에 직접 저장할 수 있습니다.
무료 이메일 파서 Excel 체험판이 있나요?
네. 가입은 무료이며 직접 이메일로 테스트할 수 있는 크레딧이 포함되어 있습니다. 첨부 파일이 있는 샘플 메시지를 전달하고 열이 채워지는 것을 확인한 후 비용을 지불하기 전에 결과를 평가할 수 있습니다. 이 페이지의 라이브 데모는 계정 없이도 작동합니다. 유료 요금제는 무료 크레딧을 모두 사용한 후 월 $9부터 시작합니다.
이메일 기반 추출 워크플로에 대해 더 알아보세요:
- Google Sheets 청구서 파이프라인: 공급업체 이메일에서 구조화된 AP까지, 공급업체 이메일을 AP 준비 완료 행으로 전환한 가장 가까운 공개 사례입니다.
- 청구서 데이터를 Excel로 일괄 추출, 받은편지함이 비워지는 속도보다 청구서가 더 빨리 쌓일 때의 첨부 파일 처리 워크플로입니다.
- API vs 노코드 문서 추출, 더 큰 파이프라인용 파서를 평가할 때 참고할 아키텍처 프레임워크입니다.