iMessage 스크린샷에서 고객의 배송 주소와
주문 번호 추출하기

iMessage가 WhatsApp과 다른 추출 시나리오인 이유

채팅 스크린샷에서 주소를 추출하는 WhatsApp Business 가이드를 읽어보셨다면 기본적인 문제를 아실 것입니다. 채팅 메시지는 양식이 아니며, 필요한 데이터가 대화 텍스트에 포함되어 있다는 점입니다. iMessage도 동일한 핵심 과제를 공유합니다. 주소와 주문 번호가 구조화된 필드가 아닌 메시지 안에 있다는 점은 같지만, WhatsApp에는 없는 세 가지 복잡성이 추가됩니다.

첫째, iMessage는 iOS 전용이므로 스크린샷이 단일 운영체제에서 제공됩니다. 채팅 버블 스타일은 일관적이지만(파란색은 iMessage, 초록색은 SMS), WhatsApp에는 없는 플랫폼 특유의 시각적 요소가 있습니다. 읽음 확인은 메시지 아래에 '읽음' 레이블로 표시됩니다. 입력 중 표시는 애니메이션 말줄임표로 나타납니다. 반응(Tapbacks)은 메시지 위에 인라인으로 아이콘 배지 형태로 표시됩니다. 이러한 요소 중 어느 것도 필요한 데이터를 포함하지 않지만, 기존 OCR 엔진이 구분해야 할 시각적 공간을 차지합니다.

둘째, iMessage는 Apple Pay Cash를 지원합니다. Apple의 자체 피어투피어 결제 시스템입니다. 누군가 Apple Pay Cash로 결제하면 확인 내용이 채팅에 스타일이 적용된 어두운 카드 형태로 표시되며, 일반 텍스트 버블이 아닙니다. 금액, 수취인 이름, 거래 상태는 큰 흰색 텍스트와 색상이 있는 상태 배지가 있는 컴팩트한 검은색 카드 안에 렌더링됩니다. 시각적으로 이 카드는 주변 채팅 버블과 전혀 공통점이 없습니다. 일반 파란색 버블에 있는 주소와 동일한 화면에 결제 카드가 함께 캡처된 스크린샷에는 한 이미지에 완전히 다른 두 가지 시각적 형식이 포함됩니다.

셋째, iMessage는 풍부한 링크 미리보기를 생성합니다. 누군가 URL을 붙여넣으면 채팅에 페이지 제목, 설명, 썸네일이 포함된 카드가 만들어집니다. 고객이 주문 페이지 링크를 붙여넣으면 해당 미리보기가 주소 데이터를 포함할 것처럼 보이지만 일반적으로는 그렇지 않은 또 다른 시각적 요소가 됩니다.

결과적으로 필요한 데이터가 서로 다른 스타일의 UI 요소들 사이에 섞여 있는 이미지가 생성되며, 이 모든 요소가 유용한 정보를 포함하고 있는 것처럼 보입니다. 추출 방법은 주소가 포함된 버블, 결제 금액을 표시하는 카드, 링크만 포함된 미리보기를 구분할 수 있어야 합니다.

iMessage 주문의 세 가지 일반적인 시나리오

모든 iMessage 주문 스크린샷이 동일하게 보이는 것은 아닙니다. 고객이 정보를 제출한 방식과 결제가 포함되었는지 여부에 따라 시각적 레이아웃이 달라집니다.

시나리오 1: 텍스트 버블의 주소 및 주문 번호

고객이 대화에서 주소와 주문 세부 정보를 일반 메시지로 입력합니다. 주소는 표준 파란색 iMessage 버블에 표시됩니다:

"3421 Maple Street, Apt 4B, Portland, OR 97202로 배송해 주실 수 있나요? 주문 #A45-8921"

주소와 주문 번호는 같은 메시지에 있거나 두 개의 연속된 메시지에 나뉘어 있을 수 있습니다. 버블 텍스트는 일반 텍스트입니다 — 서식도 라벨도 없습니다. 주소는 추출 엔진이 구조로 인식할 수 있는 표준 패턴(도로명, 도시, 주, 우편번호)을 따르며, 주문 번호는 영숫자 형식과 주문 맥락과의 근접성으로 식별할 수 있습니다. 이 시나리오가 가장 간단합니다: 보낸 사람 이름과 타임스탬프만 주변 요소로 있는 채팅 버블뿐입니다.

시나리오 2: 채팅의 Apple Pay Cash 결제 카드

고객이 같은 대화에서 Apple Pay Cash로도 결제하는 경우, 채팅 스레드에는 주변의 모든 버블과 시각적으로 구분되는 어두운 카드가 포함됩니다. 카드는 검은색 배경에 큰 중앙 흰색 텍스트로 달러 금액, 수신자 또는 보낸 사람 이름, 상태 배지("Sent," "Delivered," "Pending"), 하단의 선택적 메모를 표시합니다.

이해해야 할 중요한 점은 Apple Pay Cash 카드에 포함되지 않는 내용입니다. 결제 금액과 관련 인물은 표시되지만 배송 주소나 주문 번호는 포함되지 않습니다. 이러한 정보는 카드 위나 아래의 텍스트 버블에 남아 있습니다. 둘 다 포함된 스크린샷에서 데이터를 추출하는 경우 주소(텍스트 버블에서), 주문 번호(역시 텍스트 버블에서), 결제 금액(카드에서)에 대한 별도의 열이 필요합니다.

이는 결제 정보가 일반적으로 일반 텍스트로 공유되는 WhatsApp Business와의 주목할 만한 차이점입니다 — "I sent $85 to your number" — 렌더링된 카드가 아닌 형태입니다. 카드 형식은 결제 확인을 시각적으로 더 눈에 띄게 만들지만, 추출 엔진이 카드를 별개의 시각적 구성 요소로 인식할 수 있다면 다른 정보와 분리되어 더 쉽게 추출할 수 있는 방식이기도 합니다.

시나리오 3: 미리보기 카드가 있는 주문 링크

일부 고객은 판매자 웹사이트의 URL을 붙여넣어 주문을 공유합니다. iMessage는 채팅에 카드 형태로 표시되는 풍부한 링크 미리보기를 생성합니다. 즉, 둥근 컨테이너 안에 썸네일, 페이지 제목, 설명이 표시됩니다. 실제 주소와 주문 번호는 링크와 함께 제공되는 텍스트 버블에 나타나거나 링크를 통해서만 접근할 수 있습니다. 미리보기 카드 자체에는 일반적으로 전체 배송 주소나 전체 주문 번호가 표시되지 않습니다. 고객이 주소를 별도로 입력하지 않고 링크만 보낸 경우, 해당 데이터는 스크린샷에 표시되지 않습니다. 이는 모든 추출 방법에 적용되는 한계입니다. 정보가 화면에 표시되지 않으면 추출할 수 없습니다.

iMessage의 시각적 노이즈 읽기

iMessage 스크린샷에는 읽음 확인, 입력 중 표시, Tapbacks(이모지 반응), 메시지 효과, 타임스탬프, 연락처 아바타가 포함될 수 있습니다. 이러한 요소는 주소와 주문 번호를 추출하려는 경우 시각적 노이즈입니다. 이미지를 왼쪽에서 오른쪽으로 처리하는 기존 OCR 엔진은 "읽음"을 텍스트로, 입력 중 표시를 마침표로, 이모지 반응을 유니코드 문자로 읽어 주소와 동일한 출력 스트림에 모두 섞어 버립니다. 그 결과 "3421 Maple Street"와 "읽음", "..."이 순서대로 나타나는 텍스트 블록이 생성되어 수동 정리가 필요합니다.

시각적 언어 모델은 스크린샷을 다르게 처리합니다. 이미지를 완전한 시각적 장면으로 해석하고 각 요소의 의미적 역할을 인식합니다. 즉, "이것은 읽음 확인 레이블이다" 대 "이것은 주소가 포함된 채팅 버블이다"를 구분한 다음 각 영역 내부의 텍스트를 읽습니다. 읽음 확인 텍스트는 주소 추출을 오염시키지 않으며, 입력 중 표시는 출력에 깨진 문자로 나타나지 않습니다. 각 UI 구성 요소는 포함된 텍스트뿐만 아니라 시각적 기능에 따라 분류됩니다.

동일한 원칙, 즉 스크린샷은 표가 아니지만 이미지의 각 부분이 무엇을 나타내는지 이해하면 데이터를 추출할 수 있다는 원칙은 결제 스크린샷과 마찬가지로 iMessage 인터페이스에도 적용됩니다. 여기서 구체적인 차이점은 iMessage의 시각적 노이즈가 문서 콘텐츠가 아닌 대화형 UI 요소로 구성되며, 추출 방법이 이 둘을 구분해야 한다는 것입니다.

추출할 수 있는 항목과 추출할 수 없는 항목

올바른 열 이름을 정의하는 것만으로 스크린샷에서 무엇을 추출할지 지정할 수 있습니다. iMessage 주문 스크린샷의 경우 관련 열은 배송 주소, 주문 번호, 결제 금액(Apple Pay Cash 카드에서), 고객 이름(대화 헤더에서)입니다. 추출 엔진은 각 열 정의를 읽고, 각 시각적 요소의 의미적 역할을 이해하여 해당 값을 찾은 다음, 스크린샷당 한 행을 출력합니다. 서로 다른 고객의 iMessage 스크린샷 15장 — 각각 다른 메시지 형식과 Apple Pay Cash 카드를 가진 — 을 배치로 처리하면 15개의 행을 가진 단일 테이블이 생성됩니다.

알아야 할 한계가 있습니다. Apple Pay Cash 카드 데이터에는 거래 금액만 포함됩니다 — 배송 주소나 주문 번호는 포함되지 않습니다. 그것들은 텍스트 버블에 있으며 별도로 추출해야 합니다. 스크린샷에 입력된 주소 대신 링크 미리보기가 캡처된 경우, 주소는 단순히 이미지에 보이지 않습니다. 주소가 여러 버블에 걸쳐 분산된 다중 메시지 스레드는 스크린샷이 모든 부분을 포함할 만큼 충분한 대화를 캡처해야 합니다. 그리고 읽음 확인과 입력 중 표시 — 의미적 추출을 방해하지는 않지만 — 고객이 입력을 마치기 전에 스크린샷을 찍은 경우 관심 영역을 시각적으로 정의하기 어렵게 만듭니다.

배치 처리의 경우 워크플로는 다른 스크린샷 카테고리와 동일합니다. 이미지를 업로드하고, 열을 한 번 정의하고, 함께 처리합니다. iMessage 스크린샷과 SMS 주문 확인 — 데이터가 순수 텍스트인 — 이 섞인 배치는 동일한 열 구조를 따르며, 추출 방법은 각 입력 이미지의 시각적 형식에 개별적으로 적응합니다.

자주 묻는 질문