이메일은 모든 조직이 이미 갖추고 있는 유일한 연동 수단입니다. 공급업체는 이메일로 청구서를 보내고, 양식은 제출 내용을 이메일로 전달하며, 장비는 이메일로 경고를 보냅니다. 이메일 인제스트는 이를 번거로운 업무가 아니라 인터페이스로 활용합니다. 스크립트가 사서함에 연결해 도착한 내용을 읽고 필요한 작업을 수행합니다.
오래된 방식이지만 제대로 평가받지 못하고 있습니다. 모든 거래처에 우리 API를 도입해 달라고 요청하는 대안은 대개 현실적으로 불가능하기 때문입니다. 이 글에서는 이메일 인제스트가 적합한 용도, 장애 없이 오래 운영할 수 있는 구현 방법, webhook이 실제로 더 나은 경우를 설명합니다.
IMAP 이메일 인제스트가 적합한 용도
발신자가 시스템에 직접 연동하려 하지 않거나 연동할 수 없는 모든 상황에서 이메일 인제스트가 제 역할을 합니다.
거래처가 보내는 문서. 청구서, 구매 주문서, 납품서, 거래 명세서가 첨부 파일로 도착하지만 해당 업체가 우리 시스템에 직접 연동 기능을 개발해 줄 가능성은 없습니다. 발신자와 참조 번호에 따라 문서를 분류해 보관하는 스크립트 하나가 연동의 전부인 경우도 많습니다.
장비 경고. 백업 어플라이언스, 모니터링 시스템, 구형 산업 장비처럼 이메일 외에는 아무것도 지원하지 않는 하드웨어가 많습니다. IMAP 이메일 인제스트는 이런 경고를 한곳에 수집할 수 있게 해줍니다.
양식 제출 내용과 답장. 반송 알림이나 자동 부재중 회신처럼 후속 처리가 필요한 메시지를 포함해, 구조화된 내용을 이메일로 보내는 모든 시스템에 사용할 수 있습니다.
답장으로 승인하기. 누군가 메시지에 "예"라고 답하는 것도 업무 흐름의 한 단계입니다. 아무도 로그인하고 싶어 하지 않는 별도 화면을 만드는 것보다 그 답장을 프로그램으로 읽는 편이 더 간단한 경우가 많습니다.
중단 없이 작동하도록 설정하기
이메일 인제스트의 작동 원리는 평범합니다. 몇 가지 설계 결정을 제대로 내려야 오래 안정적으로 운영할 수 있습니다.
전용 사서함을 사용하세요. 개인 사서함 안에 폴더를 만들거나, 사람이 같은 메시지를 읽는 사서함을 함께 사용해서는 안 됩니다. 전용 주소를 두면 누군가 메일을 정리하다가 스크립트의 전제를 깨뜨릴 수 없습니다. 여기서는 사용자별로 사서함 요금을 받지 않으므로 추가 비용도 들지 않습니다.
해당 작업에만 사용할 수 있는 로그인 정보를 발급하세요. 개인의 로그인 정보를 사용해서는 안 됩니다. 스크립트의 로그인 정보가 유출되거나 교체해야 할 때 영향 범위가 스크립트 하나로 끝나야 합니다.
처리한 메시지는 삭제하지 말고 이동하세요. "처리 완료" 폴더를 두면 감사 기록이 남고 버그가 발생한 뒤 다시 처리할 수도 있습니다. 메시지를 삭제하면 실수를 되돌릴 수 없습니다. 그리고 실수는 반드시 생깁니다.
같은 메시지가 두 번 도착하는 상황을 처리하세요. 재시도, 재연결, 재처리는 모두 일어납니다. Message-ID를 키로 사용하고 이미 본 메시지는 건너뛰면 중복 처리가 데이터 문제를 일으키는 대신 아무 변화도 없는 작업으로 끝납니다.
실패를 확실히 알리세요. 사서함 읽기를 중단한 스크립트는 누군가 청구서가 어디로 갔는지 묻기 전까지 발견하기 어렵습니다. 오류가 났을 때뿐 아니라 예정대로 실행되지 않았을 때도 경고해야 합니다.
IMAP이 이 용도에 적합한 이유
이메일 인제스트가 IMAP을 사용하는 이유는 IMAP이 단순한 다운로드 프로토콜이 아니라 이메일을 위한 원격 파일 시스템이기 때문입니다.
서버에서 검색하고, 본문을 가져올지 결정하기 전에 헤더만 불러오고, 폴더 사이에서 메시지를 이동하고, 플래그를 설정할 수 있습니다. 이 모든 작업을 사서함 전체를 다운로드하지 않고 수행할 수 있습니다. 따라서 스크립트가 필요한 항목만 저렴하게 처리할 수 있으며, 수년간 쌓인 기록이 있는 사서함에서는 이 차이가 중요합니다.
모든 환경에서 지원된다는 점이 더 결정적인 이유입니다. 어떤 언어로 개발하든 사용할 라이브러리가 있고, 기존 구현을 깨뜨릴 만큼 프로토콜이 바뀌지 않았으며, 오늘 작성한 스크립트도 10년 뒤 계속 작동할 것입니다. 대부분의 업체별 API보다 더 강한 보장입니다.
알아둘 점이 있습니다. 무료 요금제에도 IMAP이 포함되므로 수신 전용 인제스트 사서함은 비용이 전혀 들지 않습니다. 다만 무료 요금제에서는 발송할 수 없습니다. 프로그램으로 답장을 보내야 한다면 유료 요금제나 별도의 SMTP 프로필이 필요합니다.
운영 비용
비용은 대부분의 예상보다 적어서 오히려 놀라운 부분입니다.
인제스트 사서함은 일반 사서함이며, 개별 사서함에 요금을 부과하지 않고 요금제 등급에 따라 개수 한도를 둡니다. 따라서 인제스트 주소를 열두 번째로 하나 더 추가해도 한계 비용은 없습니다. 이 덕분에 발신처별로 사서함 하나를 두는 구성이 낭비가 아니라 실용적인 선택이 됩니다. 실제로 사용하는 자원은 공용 저장 공간과 문제가 생겼을 때 투입할 관리자의 시간입니다.
사용자별로 요금을 부과하는 플랫폼과 비교하면 설계 판단이 달라집니다. 그런 플랫폼에서는 주소를 추가할 때마다 비용이 들어서 서로 무관한 여러 흐름을 하나의 과부하된 주소에 몰아넣게 되고, 스크립트는 다시 이를 분리해야 합니다. 여기서는 가장 저렴한 선택이 가장 깔끔한 선택이기도 합니다.
Webhook이 더 나은 경우
이 차이를 분명히 알아두면 잘못된 시스템을 만드는 일을 피할 수 있습니다.
거래처가 webhook을 제공한다면 사용하세요. 지연 시간, 안정성, 명확성 면에서 push 방식이 polling보다 낫습니다. 다음 번 조회 시점에야 변화를 발견하고 자연어 문장을 분석하는 대신, 사건이 발생하는 즉시 구조화된 payload를 받습니다. 이메일 인제스트는 이런 방법이 없을 때 사용하는 대안입니다.
Polling에도 적정 하한선이 있습니다. 1분마다 확인하는 것은 괜찮지만 1초마다 확인하는 것은 지나친 요청이며 속도 제한에 걸립니다. 정말 실시간 처리가 필요하다면 읽는 방식과 관계없이 이메일은 적합한 전송 수단이 아닙니다.
사람이 작성한 이메일을 분석하는 것도 성공하기 어려운 일입니다. 기계가 생성한 메시지에서 구매 주문 번호를 추출하는 것은 안정적이지만, 사람이 쓴 문단에서 의도를 알아내는 것은 그렇지 않습니다. 여기에 의존하는 업무 흐름을 만들면 누구도 완전히 고칠 수 없는 오류가 꾸준히 발생합니다.
사서함 하나를 넘어 확장하기
이메일 인제스트는 확장하기 좋은 방식이며, 어떤 구조가 적합한지는 처리할 흐름의 수에 따라 달라집니다.
발신처가 몇 곳뿐이라면 발신처별로 사서함 하나를 두는 것이 가장 명확합니다. 각 스크립트가 자체 주소를 읽으므로 한쪽의 변경이 다른 쪽에 영향을 줄 수 없습니다. 사서함별로 요금을 받지 않고 요금제 등급에 따라 개수를 제한하므로 인제스트 주소 20개의 비용은 하나와 같습니다.
같은 종류의 발신처가 많다면 앞에 catch-all을 둔 사서함 하나가 더 적합합니다. invoice-acme@와 invoice-globex@로 온 메일이 모두 한곳에 도착하고, 주소 자체에 스크립트가 필요한 라우팅 정보가 담깁니다. 공급업체 대신 장비에 적용한다는 점만 다를 뿐 가입 서비스별 별칭과 같은 방식입니다.
처리량이 정말 많다면 저장 공간을 함께 사용한다는 사실을 기억하세요. 첨부 파일이 쌓이는 인제스트 사서함은 공용 공간을 계속 소비합니다. 따라서 용량 제한과 보존 정책을 나중에 문제를 겪고 나서 마련할 것이 아니라 처음부터 설계에 포함해야 합니다. 자세한 내용은 사서함 저장 공간 할당량에서 설명합니다.
