영업(sales)에 종사하는 사람이라면 누구나 이 파일을 가지고 있습니다. 이벤트 목록, 오래된 내보내기 파일 또는 CRM에서 가져온 프로필 URL 열과 그 옆에 이메일 주소가 들어가야 할 빈 열이 있는 식입니다.
어떤 이메일 찾기 도구든 그 열을 채워줄 것입니다. 하지만 그들이 알려주지 않는 것은 그 사람이 여전히 해당 사서함(mailbox)을 읽는지 여부입니다. 기록은 경력이 고용주들을 모으는 방식처럼 주소도 모으며, 찾기 도구는 가장 위에 있는 것만 건네줍니다. 반송 메일은 일주일 후에 당신의 도메인 평판에 영향을 미칩니다.
그래서 2026-10-29일에 저는 Apify Actor를 사용하여 200개의 프로필 URL을 실행했습니다. 이 액터는 단순히 주소를 반환하는 대신 주소에 라벨을 붙여줍니다. 현재 직장, 이전 직장, 기록 없음, 프로필 삭제됨과 같은 라벨입니다. 그리고 여기에 두 개의 액터를 더 연결하여 Claude Code가 동일한 20개의 URL을 MCP에서 실행하도록 했습니다. 아래의 모든 숫자는 이 실행들로부터 나온 것입니다.
요약하자면: 대량 이메일 찾기 도구는 줄마다 프로필 URL을 가져와 각 사람 기록에 있는 주소와 그 라벨을 반환합니다. 현재 직장 도메인의 주소, 이전 회사 주소, 또는 아무것도 없을 수 있습니다. 누락된 경우(misses)는 이유가 명시된 빈 행입니다.
이전 및 빈 행의 경우에는 두 번째 액터가 이름과 회사 도메인을 사용하여 찾은 내용을 검증하려고 시도합니다. 이는 비용을 지불하기 전에 세그먼트 크기를 측정하는 무료 검색 단계 역할을 합니다.
200개의 URL 출처와 무료 검사가 알려주는 것들
저는 블로그 게시물을 위해 고객 목록을 실행하고 싶지 않았기 때문에, 찾기 도구가 읽는 동일한 사람 데이터베이스에서 무작위로 두 개의 샘플(인하우스 마케팅 리더 및 창업자)을 추출했습니다. 서로 다른 사서함, 다른 습관을 가지고 있습니다. 먼저 market 모드에서 People Search를 사용하여 비용이 들지 않으면서 데이터를 끌어내기 전에 사서함의 모습을 파악했습니다.
| 세그먼트 | 인원 수 (People) | 기록된 개인 이메일 주소 |
|---|
| 소프트웨어 회사에 근무하는 미국 마케팅 리더 (VP, Head, CMO, Marketing Director), 직원 51~500명 규모 | 2,386 | 약 3분의 2 정도 |
| 소프트웨어 회사에 근무하는 미국 창업자 및 CEO, 직원 2~50명 규모 | 59,835 | 절반을 약간 넘는 수준 |
마케팅 목록을 살펴보니, 최고 마케팅 책임자(chief marketing officers)와 기타 C-레벨 직책이 거의 절반에 달했고, 이사급은 약 3분의 1, VP는 10분의 1 미만이었습니다. 이는 백 명의 샘플만으로 결론 내리기 전에 알아두면 유용한 정보입니다.
다음으로 데이터를 추출했습니다. people 모드, 간결한 행(compact rows), 그리고 제가 임의로 선택할 수 없도록 무작위 시드(random seed)를 사용했으며, 세그먼트당 20개씩 총 다섯 번 실행했습니다:
{
"mode": "people",
"titleKeywords": ["vp marketing", "head of marketing", "chief marketing officer", "marketing director"]
...
}
백 명의 마케팅 대상자 중 두 명이 같은 사람이었기 때문에, 목록은 98개입니다. 각 간결한 행에는 프로필 URL, 고용주 도메인(employer's domain), 회사 규모, 그리고 두 개의 플래그(hasWorkEmail 및 hasPersonalEmail)가 포함되어 있습니다. 98명의 마케팅 리더 중 82명이 업무 이메일이 있다고 답했습니다. 100명의 창업자 중 76명이 그렇다고 답했습니다.
이 숫자를 기억해 두세요.
실행 과정: 한 필드, 4초
검색기는 하나의 필드를 가져옵니다. 링크, 일반 핸들(bare handles), 모바일 URL 모두 작동하며, 동일한 프로필의 철자는 단 한 번 조회됩니다. 실행당 최대 1,000개까지 가능합니다. 무료 플랜은 실행당 최대 100개의 결과를 반환하므로, 다음 배치 전에 각 배치를 읽을 수 있도록 20개씩 데이터를 입력했습니다.
{
"profileUrls": [
"<프로필 URL 하나를 줄마다>",
...
}
20개 단위의 배치당 4초가 소요되었습니다. 200개의 URL이 어떻게 처리되었는지 보여드리겠습니다:
| 결과 | _status / emailType | 마케팅 리더 (98명) | 창업자 (100명) |
|---|
| 현재 고용주 주소 | work_current | 38 | 26 |
| ... | | | |
첫 두 행만 청구됩니다. 비어 있거나 사라진 행은 상태(status)와 함께 반환되며, 이름과 직책이 있는 경우에도 그렇게 되어 다른 곳으로 라우팅할 대상을 알 수 있습니다.
다시 플래그로 돌아가 보겠습니다. 82명의 마케팅 리더는 데이터베이스 행에 "업무 이메일 보유(has a work email)" 여부를 가지고 있었습니다. 그중 38명은 현재 근무하는 회사에서 업무 이메일을 보유하고 있습니다. 데이터베이스에서 '예'라는 것은 기록 어딘가에 주소가 존재한다는 의미입니다. 어디에 있다는지는 알려주지 않습니다.
이것이 전체 게시물 내용입니다. 작업의 절반 정도는 B2B 기록에 있는 주소가 이미 떠난 직장의 것이며, 이러한 정보를 라벨링하지 않는 검색기(finder)를 사용하면 반송된 이메일만 얻게 됩니다.
오래된 주소의 형태
경력은 사서함의 흔적을 남깁니다. 확보한 마케팅 기록에는 중간 그룹에서 각각 4개의 주소가 포함되어 있었고, 그중 3/4는 3개 이상의 주소를 가졌으며, 한 사람은 무려 13개의 주소를 가지고 있었습니다. 창업가(Founders)의 기록은 조금 짧아 평균적으로 3개가었습니다.
검색기는 현재 직장의 주소가 있는 경우 먼저 이를 분류합니다. 만약 없다면 오늘날의 고용주에 연결할 수 있으며, 해당 행은 work_other로 라벨링되고 목록의 첫 번째 주소는 단순히 가장 처음 발견된 것이며 최신성(recency)에 대한 주장은 없습니다.
저는 이 레이블을 소스 행(CRM이 보유했을 법한 원본 데이터)의 고용주 도메인과 비교했습니다:
work_current 행, 마케팅 리더 | 38 |
|---|
| 소스 행과 동일한 도메인 | 27 |
| ... | |
11개는 메일 도메인이 웹사이트와 다른 브랜드의 경우입니다. 사이트에는 제품명이 있고, 봉투에는 법적 실체가 적혀 있는 식입니다. 창업가들의 기록에서는 절반으로 나뉘었는데, 이는 한 사람이 동시에 두 개의 회사를 운영할 때 발생하는 현상입니다.
기록의 신선도(freshness)는 아무것도 결정하지 않으면서 확률을 바꿉니다:
| 소스 기록 최종 업데이트일 | 현재 주소 | 오래된 주소만 |
|---|
| 지난 1년 이내 | 21 | 18 |
| 1년 이상 전 | 17 | 25 |
신선한 기록은 유효한 주소 쪽으로 기울어집니다. 하지만 필터링할 만큼 충분하지는 않습니다. 레이블이 필터링을 수행하며, 신선도는 단지 얼마나 신뢰해야 하는지를 알려줄 뿐입니다.
개인 메일함, 요청 시
기본적으로 검색기는 회사 주소만 반환합니다. 매칭된 프로필에 기업 정보는 없지만 개인 메일함이 기록되어 있는 경우, 빈 행은 _note에 그렇게 명시됩니다. 24개의 빈 창업가 행 중 5개가 해당 메모를 포함하고 있었습니다. 12개의 빈 마케팅 행 중에는 아무것도 없었고, 그들의 소스 행도 동일했습니다. 둘 다 어떤 종류의 정보도 없었습니다.
저는 이 다섯 건을 includePersonalEmails 옵션을 켜고 다시 실행했습니다. 약속대로 개인 주소 5개가 나왔습니다.
처음부터 개인 메일함을 켠 상태로 전체 창업자 배치(20개)를 다시 실행하여, 해당 스위치가 이미 정보가 있는 행에 어떤 영향을 미치는지 확인했습니다:
| 첫 번째 실행에서의 행 | 행 수 | 개인 메일함 활성화 시 |
|---|
| 현재 직장 주소 | 3 | 여전히 현재 주소 |
| ... | | |
스위치를 켜면, 개인 메일함이 오래된 회사 주소보다 우선순위를 갖게 됩니다. 이는 보통 읽히는 받은 편지함이기 때문입니다. 내부 CMO의 경우 잘못된 정보가 될 수 있으며, 이것이 기본적으로 스위치가 꺼져 있는 이유입니다.
두 번째 방법: 이름과 도메인으로 검증하기
오래되었거나 비어있는 행들이 죽은 사람을 의미하는 것은 아닙니다. 그들은 기록이 뒤처진 사람들을 의미합니다. 이런 경우를 위해 다른 액터(Actor)가 있습니다. Work Email Finder는 이름과 회사 도메인을 받아, 해당 도메인이 주소를 작성하는 방식대로 후보군을 구축하고, verifyTopCandidate 기능을 사용하여 최적의 후보를 메일 서버 및 자체 기록과 비교 검증합니다.
저는 찾은 마케팅 행 81개, 파인더(finder) 행에서 가져온 이름, 그리고 소스(source) 행에서 가져온 도메인을 모두 이 도구를 통해 실행했습니다:
{
"lookups": [
{ "domain": "<CRM의 회사 도메인>", "full_name": "<파인더 행의 이름>" },
...
}
| 이메일 파인더가 보고한 유형 | 행 수 | 오늘날 도메인에서 검증된 주소 | 기록 내 이미 존재하는 비율 | 패턴으로 새로 구축된 주소 |
|---|
work_current | 38 | 30 | 26 | 4 |
work_other | 43 | 33 | 21 | 12 |
'오래된' 행 43개 중 33개가 오늘날 직장의 검증된 주소로 돌아왔습니다. 이 중 21개는 기록의 최상단에 있는 주소 아래, workEmails 목록에 이미 존재하던 것이었습니다. 파인더는 주소를 회사의 정규 도메인(canonical domain)에 연결하므로, 리스트 하단에 있는 브랜드 도메인은 '오래됨'으로 레이블이 지정된 상태를 유지합니다.
파이프라인을 위한 두 가지 교훈입니다. 행을 폐기하기 전에 전체 목록을 자체 도메인 목록과 일치시키십시오. 그리고 나머지 항목들은 검증 기능을 켠 상태로 이름+도메인 경로를 통해 전송했는데, 이것이 여기서 나머지 대부분을 구제했습니다.
솔직한 나머지 절반: 기록된 현재 주소가 있는 8명의 사람은 패턴 경로를 통해 검증된 후보자를 얻지 못했습니다. '기록(Record)'과 '패턴(Pattern)'은 두 가지 출처입니다. 이들이 일치하는, 여기의 26개 행을 제가 가장 먼저 보낼 곳이라고 생각합니다.
Claude Code가 그 스무 개 항목으로 한 일
저는 Claude Code에게 Email Finder와 People Search를 MCP 위에서만 제공했고, 다른 것은 아무것도 주지 않았습니다. 셸(Shell) 및 파일 도구는 비활성화했습니다.
프롬프트는 평이한 말로 표현된 RevOps 담당자였습니다. 프로필 URL은 있지만 이메일이 없는 2,000개의 CRM 연락처 중 여기 스무 개가 있습니다. 저희 정책은 현재 고용주의 직장 주소만 허용하며, 이유를 제시할 수 없다면 개인 사서함은 절대 안 됩니다. 각 사람을 한 번 조회해 주세요.
그것은 두 가지 도구 정의를 로드하고, 개인 사서함을 끈 상태로 스무 개 항목 전체에 대해 한 번의 조회를 실행했으며, get-dataset-items을 사용하여 스무 개의 행을 읽고 답변을 작성했습니다. 네 번의 도구 호출 중 하나는 유료였으며, 4분 이내였습니다. 그것은 무료 검색을 실행하지 않았고, 그 이유를 말했습니다: 작업에서 그것이 필요하지 않았기 때문입니다.
스무 개 항목에 대한 그 기록은 다음과 같습니다: 현재 7개, 이전(older) 8개, 아무것도 없는 것 2개, 프로필이 사라진 것 3개. 그러고 나서 그것은 제가 금요일에는 건너뛰었을 법한 읽기를 했습니다.
"이전(older)" 행 중 하나는 목록의 더 아래쪽에 있는 현재 고용주의 도메인에 속한 주소를 가지고 있었습니다. 그것은 어떤 것을 폐기하기 전에 전체 목록을 CRM의 도메인과 일치시키는 방법을 제안했는데, 이는 제가 81개 행과 두 번째 Actor를 사용했을 때 도착했던 것과 같은 수정 사항이었습니다.
한 행의 유일한 주소는 그 사람 자신의 이름으로 만들어진 도메인에 있었습니다. 그것은 실제로는 1인 컨설팅 사서함이라고 말하며, 레이블이 무엇을 말하든 정책에 따라 제외했습니다.
그것은 profile_removed가 도구 설명에 포함되어 있지 않다는 것을 알아차렸지만, 어쨌든 상태를 올바르게 읽었고, 자신이 가진 도구로는 그 의미를 확인할 수 없다고 말했습니다. 목록의 이 공백을 메우는 것은 저의 몫입니다.
또한 _freshness 필드는 발견된 15개 행에 걸쳐 변동하지 않았다는 점도 언급했습니다. 따라서 해당 샘플에서는 필터링되는 항목이 없었습니다. 사실이며, 이 규칙을 만들기 전에 알아두면 좋습니다.
나머지 2천 건의 데이터에 앞서 다섯 가지를 요청했습니다: 핸들(handle)의 URL을 정규화하고 중복 제거하며, work_current 고용주 정보를 CRM과 비교하고, 수백 개의 정보에 의존하기 전에 전달 가능성(deliverability)을 검증하며, 사라진 프로필 비율을 관찰하고, 인라인으로 기다리기보다 실행(run)을 폴링(poll)하는 것입니다. 저는 이 다섯 가지 모두에 동의합니다.
전송 전 확인 사항 (Before you send)
첫 번째 액터(Actor)에서 가져온 주소는 실시간으로 검증된 것이 아닙니다. 두 번째 액터의 검사는 메일함이 메일을 받을 수 있다는 것만을 의미할 뿐, 그 사람이 실제로 읽는다는 것을 보장하지 않습니다.
라벨은 지연될 수 있습니다. 몇 달 전 직장 변경 사항이라도 여전히 현재(current)로 표시될 수 있습니다. 해당 행의 고용주 정보와 사용자가 보유한 정보를 비교하십시오.
두 번째 메일 도메인을 가진 브랜드는 '오래됨(older)'으로 나타납니다. 라벨만으로 매칭하지 말고, 자체 도메인 목록과 매칭해야 합니다.
198개의 URL 중 7개는 더 이상 존재하지 않는 프로필을 가리키고 있었습니다. 3년 전의 URL로 가득 찬 CRM이라면 이보다 더 많을 것입니다. 해당 비율을 계속 염두에 두십시오. 측정하는 것은 무료입니다.
동의(Consent)와 법률은 사용자의 책임입니다: CAN-SPAM, GDPR, PECR 등 사람이 위치한 곳에서 적용되는 모든 규정을 준수해야 합니다. 검증된 주소가 곧 허가(permission)를 의미하지는 않습니다.
FAQ
Hunter나 Apollo 이메일 파인더의 대체재인가요? 프로필 URL을 대량으로 주소로 변환하는 용도로는 그렇습니다: 좌석 수 제한이 없고, 브라우저 확장 프로그램도 필요 없으며, 발견된 행당 비용을 지불하고 누락분은 무료입니다. 하지만 사용자가 웹을 탐색할 때 주소를 채워주는 Chrome 플러그인으로는 그렇지 않습니다.
주소를 추측하나요? 첫 번째 액터는 추측하지 않습니다. 사람의 기록에 실제로 존재하는 주소만을 반환하며, 존재하지 않을 경우 그렇게 알려줍니다. 두 번째 액터는 이름과 도메인을 기반으로 후보군을 만들고 가장 적합한 것을 검증할 수 있습니다. 이것이 바로 '추측(guessing)' 기능이며, 그로 명시되어 있습니다.
work_other는 무엇을 의미하나요? 찾기 도구가 현재 고용주와 연결할 수 없는 회사 주소입니다. 보통 이전 직장이며, 때로는 브랜드 도메인 하의 동일한 회사일 수도 있습니다. 결정하기 전에 workEmails 목록을 자체 도메인과 비교해 보세요.
제가 요청하지 않았는데 일부 주소가 개인적인 이유는 무엇인가요? 그렇지 않습니다. 단지 includePersonalEmails가 활성화된 경우에만 해당됩니다. 이 기능이 켜지면, 해당 행에서 개인 메일함이 이전 회사 주소보다 우선순위를 갖습니다.
한 번 실행(run)은 얼마나 클 수 있나요? 이 Actor에서는 실행당 최대 1,000개의 URL을 처리할 수 있습니다. 무료 Apify 플랜은 실행당 최대 100개의 결과와 월 500개의 행을 반환하며, 유료 플랜은 이러한 제한을 제거합니다.
AI 에이전트를 위한 안내
세 개의 Actor는 URL에 고정된 도구들과 함께 호스팅되는 Apify MCP 서버에서 실행되므로, 에이전트는 다음 정의들만 로드합니다:
claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/linkedin-email-finder,b2bsearch/work-email-finder,b2bsearch/people-database-search" --header "Authorization: Bearer <APIFY_TOKEN>"
{
"mcpServers": {
"apify": {
...