에이전트를 사용하여 CRM으로 이메일 서명을 가져오는 방법

이메일 서명은 귀하의 CRM이 버리고 있는 가장 가치 있는 데이터셋입니다. 비즈니스 이메일의 약 82%는 최소한 이름과 직책을 포함하는 서명을 가지고 있으며, 보통 전화번호, LinkedIn URL, 회사 이름, 때로는 전체 조직도 단서를 담고 있습니다. 이것은 산문처럼 위장된 구조화된 데이터이며, 모든 메시지와 함께 무료로 제공되지만 대부분의 플랫폼은 이를 무시합니다.

이 데이터를 수집하기 위해 데이터 벤더나 심지어 LLM(대규모 언어 모델)이 필요하지 않습니다. 몇 백 줄의 정규 표현식(regex), 교차 참조 트릭, 그리고 작업을 수행하는 에이전트를 위한 전용 받은 편지함만 있으면 생산에 사용할 수 있는 정확도를 얻을 수 있습니다. 여기에 구축 방법을 소개합니다.

여기서 regex가 LLM보다 우수한 이유 (진짜로)

진정으로 비정형적인 산문의 경우 모델이 승리합니다. 서명은 비정형적이지 않고, 예측 가능하게 구조화되어 있습니다: 3~6줄이며, 종종 본문과 RFC 3676 -- 구분 기호로 분리되고, 소수의 필드 유형에서 가져옵니다. 정규 표현식 패스는 잘 구성된 서명의 95% 이상을 포착하며, 마이크로초 내에 실행되고 메시지당 비용이 들지 않습니다. LLM은 특이한 나머지 5%를 위한 폴백(fallback)으로 유지하고, 버전 1에서는 완전히 건너뛰는 것이 좋습니다.

먼저 경계를 찾으세요:

import re

SIG_DELIMITERS = [
...

그런 다음 키워드 어휘집과 함께 필드를 추출하세요. 전화번호, LinkedIn (/in/만 사용; /pub/ URL 형태는 몇 년 전에 폐지됨), 웹사이트, 그리고 직책 및 회사 정보가 포함됩니다. 판매와 관련하여 중요한 세부 사항은 다음과 같습니다: 직책을 등급으로 분류합니다 (C-suite, VP, Director, Manager, IC).

가장 큰 차이는 헤드라인 수치로 나타납니다. 단일 메시지 추출로는 약 67%의 필드 완성도를 얻는 반면, 세 개의 메시지를 교차 참조하면 약 91%에 달합니다. 이는 아무도 신뢰하지 않는 열과 영업팀이 실제로 필터링하는 열 사이의 차이를 만듭니다.

DNS 쿼리 비용으로 얻을 수 있는 추가 인텔리전스: 발신자의 도메인은 MX 레코드를 통해 메일 호스트를, SPF 포함(SendGrid, Salesforce 등)을 통해 사용 중인 툴링을, DMARC를 통해 보안 성숙도를 파악할 수 있습니다. 이 모든 것은 이메일 본문 없이도 무료로 얻는 풍부한 정보입니다.

에이전트에게 전용 받은 편지함을 제공하기

메일은 어디에서 오는 것일까요? 두 가지 패턴이 있으며, 동일한 인프라를 사용합니다. 바로 message.created 웹훅을 갖춘 전용 에이전트 계정 (Nylas에서 호스팅하는 메일함으로 현재 베타 버전입니다)을 사용하는 것입니다.

패턴 1: 수동적 풍부화(passive enrichment). 에이전트 자체의 받은 편지함(support@, outreach@ 등)은 이미 비즈니스 메일을 받고 있습니다. 모든 수신 메시지는 파싱 기회이며, 웹훅 핸들러가 내용을 추출하고, 교차 참조하며, CRM에 기록합니다.

패턴 2: 사용자 주도 가져오기(user-initiated import). signatureimport@agents.yourcompany.com을 설정하고 사용자들에게 '원하는 서명이 포함된 이메일을 전달해 달라'고 안내합니다. 사용자의 핸들러가 포워더를 식별하고, 서명 HTML을 추출하여 해당 사용자에게 저장합니다:

app.post("/webhooks/signature-import", async (req, res) => {
  res.status(200).end();

...

매핑 조회(mapping lookup)가 핵심적인 부분입니다. 앱은 사용자 이메일 주소에서 grant_id로 연결되는 테이블을 필요로 하며, 알 수 없는 포워더는 추측해서는 안 되고 무시해야 합니다. 실제 저장 과정 자체는 Signatures API를 통해 이루어집니다:

const signature = await nylas.signatures.create({
  identifier: targetGrantId,
  requestBody: {
...

하나의 가져오기 받은 편지함(import inbox)이 모든 사용자에게 서비스를 제공합니다. 전달된 이메일의 from 주소를 기준으로 경로를 지정합니다. 저장된 서명은 signature_id 매개변수와 함께 발신 메일에 첨부되며, 이는 에이전트 사서함(agent mailboxes)에서도 작동합니다. 즉, 아웃리치 에이전트는 이 방식으로 가져온 실제 사람처럼 보이는 서명을 사용하여 메시지를 보낼 수 있습니다.

알아두면 좋은 예외 상황 (Edge cases that will find you)

• 하나의 이메일 내 여러 개의 서명. 전달된 스레드에는 여러 사람의 블록이 포함될 수 있습니다. 가장 최근 발신자의 서명을 원한다면, 첫 번째 Forwarded message 경계선 위에 있는 내용을 추출하십시오.
• 크기가 큰 추출물. 상식적인 검사(sanity check)는 유용합니다. 20 KB가 넘는 블록은 단순히 서명일 가능성이 낮습니다. 로그를 기록하고 건너뛰십시오.
• 권한별 제한(Per-grant ceiling). 각 권한(grant)은 최대 10개의 서명을 저장할 수 있습니다. 개수를 확인하고, 열한 번째에서 실패하는 대신 기존의 서명 중 하나를 업데이트하십시오.
• HTML 전용. Signatures API는 HTML을 저장합니다. 순수 텍스트만 포함된 전달 메일에는 추출할 내용이 없습니다.
• 이미지 위주의 서명. 기업 서명은 종종 회사에서 호스팅하는 로고 및 증명사진을 가리키는 <img> 태그를 임베드합니다. 해당 URL은 회사의 서버가 작동하는 한 계속 작동합니다. 만약 자체적으로 완결된(self-contained) 서명을 원한다면, 이미지를 다운로드하여 자체 CDN에 호스팅하고 저장하기 전에 URL을 재작성해야 합니다.
• 정제는 처리되지만, 상식적 검사는 아닙니다. Signatures API는 입력 시 HTML을 정제(sanitizes)하여 안전하지 않은 태그와 속성을 제거하므로 별도의 정제기가 필요 없습니다. 하지만 실수로 이메일의 절반을 추출했다는 사실은 알려주지 못합니다. 이것이 바로 위의 크기 검사가 필요한 이유입니다.
• 개인정보 보호 맥락. 데이터가 귀하에게 전송되었지만, 추론된 속성(직급, 구매 신호)을 CRM에 기록하는 것은 다른 처리 맥락입니다. 이를 개인정보 보호 고지(privacy notice)에 포함시키십시오。

이번 주에 구축해 보세요 (Build it this week)

두 부분은 별도로 문서화되어 있습니다. 서명 가져오기 받은 편지함 레시피는 포워드-투-임포트(forward-to-import) 흐름을 처음부터 끝까지 다루며, 서명 풍부화 레시피는 정규표현식 어휘와 교차 참조 수학을 다룹니다.

다음 단계: 본인의 받은 편지함에서 최근 50개의 메시지를 가져와서 위에 설명된 경계 분할기(boundary-splitter)를 실행하고, 적중률(hit rate)을 계산해 보세요. 만약 그 수치가 약 82%에 가깝다면, 이미 받고 있는 메일 속에 CRM 풍부화 파이프라인이 숨어 있다는 뜻입니다.