영업 메일 본문 추출 검수, 같은 요청이 두 번 등록될 때
영업 메일의 일반 텍스트와 HTML 본문을 모두 읽으면 같은 요청이 중복 등록될 수 있습니다. MIME 대체 본문과 첨부를 구별하고, 선택 실패와 표현 간 내용 차이를 확인하는 인수표를 정리합니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
2026년 11월 기준, 영업 메일의 MIME 대체 본문은 지원하는 표현 하나를 골라 요청을 추출합니다. 일반 텍스트와 HTML을 각각 새 요청으로 등록하면 중복될 수 있습니다.
메일 한 통에 ‘검토 자료를 보내 주세요’가 일반 텍스트와 HTML로 들어 있다고 가정해 보겠습니다. 두 파트를 이어 붙여 AI에 전달하면 같은 문장이 반복됩니다. 업무가 중복됐다면 수신 재시도뿐 아니라 AI가 실제로 읽은 입력도 확인해야 합니다.
일반 텍스트와 HTML은 별개 요청인가요?#
multipart/alternative에 속한 파트는 같은 정보의 대체 표현입니다. 지원하는 표현과 변환 정책에 맞춰 본문을 선택합니다. RFC 2046은 수신 환경이 지원하는 표현 가운데 보통 뒤에 있는 표현을 선택하도록 설명합니다. HTML 변환을 지원하지 않으면 읽을 수 있는 다른 표현으로 돌아가는 조건을 정합니다. RFC 2046의 대체 본문
메일 메시지와 선택한 파트의 위치, 콘텐츠 형식, 파서·변환 정책 버전을 연결하면 어떤 입력에서 요청이 만들어졌는지 대조할 수 있습니다. 실제 본문 보존과 원문 참조는 사내 권한·보존 정책에 맞춥니다. 요청을 등록하는 과정은 추출한 후보와 담당자의 확인을 함께 남깁니다.
이미지와 텍스트 첨부도 본문에 합치나요?#
관련 이미지와 독립 첨부는 MIME 구조에서 맡은 역할부터 확인합니다. multipart/related는 여러 파트가 함께 구성하는 객체이며 start가 가리키는 루트, 또는 start가 없을 때 첫 파트에서 처리를 시작합니다. HTML 본문을 찾는 과정에서 인라인 이미지마다 독립 요청을 만들면 같은 메시지의 처리가 늘어납니다. RFC 2387의 관련 파트와 루트
multipart/mixed에는 독립 파트가 함께 올 수 있습니다. 파일 형식이 text/plain이라는 이유로 텍스트 첨부를 본문 뒤에 무조건 붙이면 첨부의 문장까지 현재 요청으로 읽게 됩니다. 첨부를 분석할 업무라면 별도 입력임을 표시하고 기대 결과를 정합니다.
어떤 표본으로 중복 추출을 검수하나요?#
같은 메일 메시지 안에서 선택한 본문과 요청 후보를 대조합니다. 아래는 ‘검토 자료를 보내 달라’는 요청 하나를 담은 가상 메일의 인수표입니다. 파트 수와 실제 업무 수는 각각 확인합니다.
| 가상 MIME 입력 | 본문 선택에서 확인할 결과 | 요청 추출에서 확인할 결과 |
|---|---|---|
| 같은 요청의 plain·HTML 대체 본문 | 지원하는 표현 하나를 선택 | 같은 요청 후보를 표현별로 두 번 만들지 않음 |
| plain 본문만 있음 | 일반 텍스트 선택 | 요청 문장과 후보 연결 |
| HTML 본문과 related 이미지 | related의 루트 본문 선택 | 이미지 파트 수로 요청 수를 늘리지 않음 |
| 본문과 text/plain 첨부 | 첨부를 독립 입력으로 구분 | 첨부 문장을 현재 본문 요청으로 섞지 않음 |
| 지원하는 본문 후보가 없음 | 선택 불가 사유를 남김 | 요청 없음으로 확정하지 않고 확인 대기 |
| 대체 표현의 기한·내용이 다름 | 선택한 표현과 차이의 근거 확인 | 차이가 발견되면 담당자 확인 뒤 업무 반영 |
Python 3.14의 get_body는 선호 형식에 맞는 본문 후보를 찾고, related 루트와 Content-Disposition을 고려합니다. 이번 합성 실험에서는 HTML·plain 순서로 선택해 대체 본문, plain 단독, 관련 이미지, 텍스트 첨부, 지원 후보 없음의 결과를 확인했습니다. Python의 본문 선택 문서
본문을 하나 골랐으면 업무도 한 건인가요?#
한 본문 안에 독립된 요청이 여러 개 있을 수 있습니다. 본문 선택 결과와 업무 개수는 따로 검수합니다. 산출물과 완료 조건이 다른 요청을 나누는 기준은 영업 메일 후속 업무 큐에서 다룹니다. 첨부 내용을 새 업무 근거로 바꾸는 기준은 영업 메일 첨부파일 검수에서 확인할 수 있습니다.
대체 표현이라도 전달 과정이나 작성 오류로 기한·본문이 다를 수 있습니다. 선택한 한 표현만으로 모든 의미 충돌을 발견할 수는 없습니다. 표본에서 차이가 발견되면 자동 반영을 보류하고 담당자가 원문을 확인하도록 정합니다. 파싱 오류, 빈 본문, 잘못된 문자셋도 ‘요청 없음’과 구분해 남깁니다.
RFC 2046은 1996년 11월, RFC 2387은 1998년 8월에 발행됐습니다. RFC와 Python 문서는 2026년 11월 5일에 확인했습니다. 합성 MIME 파싱 결과는 본문 후보 선택의 검증이며 AI의 요청 해석과 실제 업무 저장은 별도 인수 대상입니다.
알파카랩스의 업무 자동화·API 연동 개발 서비스는 허용된 연동 범위와 중복·실패의 재처리, 운영 인수 조건을 협의합니다. 이 글은 알파카랩스가 작성한 설계 안내이며 하단에 자사 서비스 상담 링크가 있습니다.
영업 메일 본문 추출 FAQ#
모든 text/plain 파트를 이어 붙이면 되나요?
대체 본문인지 독립 첨부인지 먼저 구분합니다. 같은 형식의 파트라도 MIME 구조와 Content-Disposition에 따라 역할이 달라집니다. 선택한 본문과 첨부를 서로 다른 입력으로 기록합니다.
HTML이 있으면 항상 HTML을 선택하나요?
수신 환경이 지원하는 표현과 변환 정책을 정해야 합니다. HTML을 처리할 수 없으면 지원하는 대체 표현을 선택할 수 있습니다. 선택 불가나 해석 오류는 확인 대기로 남깁니다.
관련 이미지가 첫 파트가 아니어도 본문을 찾을 수 있나요?
multipart/related의 start가 루트 파트의 Content-ID를 가리키면 그 루트에서 시작합니다. start가 없으면 첫 파트가 루트입니다. 인수 표본에 실제 중첩 구조와 루트 위치를 포함합니다.
본문이 선택됐으면 AI 요청 추출도 통과한 건가요?
본문 선택은 AI에 전달할 입력을 정한 단계입니다. 현재 요청과 인용된 과거 대화의 구분, 담당자·기한·완료 조건의 해석은 기대 결과와 추가로 대조합니다.
일반 텍스트와 HTML의 내용이 다르면 어떻게 하나요?
두 표현에서 발견한 차이를 원문 근거에 연결하고 담당자가 적용할 내용을 확인합니다. 자동으로 두 요청을 만들거나 임의로 합친 결과를 확정하지 않도록 인수 조건을 정합니다.
메일 본문 선택 인수표 협의#
비식별 MIME 예시와 본문에서 기대하는 요청을 준비하면 본문 선택·실패·검토 대기의 인수표 초안 범위를 협의할 수 있습니다. 소요 시간은 자료 형식과 표본 범위를 확인한 뒤 정합니다.