사용자가 회의 사이를 서두르며 가입 양식을 제출합니다. 이메일은 그럴듯해 보이고 버튼은 반응하며, 사서함이 메시지를 수신할 수 있는지 아무도 확인하기 전에 해당 기록이 데이터베이스에 입력됩니다. 환영 이메일이 실패할 때쯤이면 애플리케이션은 이미 잘못된 데이터를 실제 고객 기록으로 처리한 뒤입니다.
바로 그 간극을 메우는 것이 실시간 주소 검증입니다. 이메일 워크플로에서는 사용자와 데이터베이스 사이의 동기식 데이터 품질 게이트 역할을 하며, CRM, ESP, 영업 대기열 또는 제품 로직이 해당 주소를 신뢰하기 전에 주소를 확인합니다. 우편 주소 검증도 권위 있는 데이터세트를 기준으로 형식과 배송 가능성을 확인하는 유사한 원칙을 따르지만, 이 가이드에서는 BillionVerify가 가입, 가져오기 및 캠페인 워크플로에 제공하는 이메일 인증 계층에 초점을 맞춥니다.
잘못된 주소가 유입되는 순간
화요일 오후, 한 잠재 고객이 Gmail 주소 대신 alex@gmal.com을 입력합니다. 필드에 @ 기호와 도메인처럼 보이는 문자열이 포함되어 있기 때문에 브라우저는 이를 허용합니다. 백엔드는 해당 주소를 저장하고, 리드를 생성하며, 온보딩 시퀀스를 시작하고, 환영 메시지를 발송합니다.
메시지는 즉시 하드 바운스됩니다. 이 한 번의 실패는 사소해 보일 수 있지만, 이제 해당 기록은 여러 시스템에 존재합니다. CRM에는 신규 리드로 표시되고, 마케팅 플랫폼은 다음 캠페인에 이 주소를 포함하며, SDR은 시퀀스를 받을 수 없는 사람을 조사하는 데 시간을 씁니다. 이후 고객 성공 팀은 동일한 기록을 인계받고, 연락처 정보가 의도적으로 수집되었다고 생각합니다.
운영상의 실수는 바운스 전에 발생했습니다. 시스템은 저장해도 안전한지 먼저 판단하지 않은 채 주소를 허용했습니다.
철자가 틀린 도메인은 명백한 실패 사례일 뿐입니다. support@ 또는 info@ 같은 역할 기반 별칭은 의사 결정자의 받은편지함이 아니라 공유 대기열로 메시지를 전달할 수 있습니다. 일회용 주소를 사용하면 누군가 지속적인 커뮤니케이션 채널을 만들지 않고도 평가판을 이용하거나 반복해서 가입할 수 있습니다. 캐치올 도메인은 SMTP 대화 중 모든 수신자를 허용한 다음, 알 수 없는 메일을 폐기하거나 다른 곳으로 전달할 수 있습니다.
결과가 항상 즉각적인 하드 바운스로 나타나는 것은 아닙니다. 때로는 주소가 작동하는 것처럼 보이고 데이터베이스에 남아 이후 세분화에 영향을 줍니다. 목록에 별칭, 임시 받은편지함, 수신자가 불확실한 주소가 포함되기 때문에 캠페인 지표를 해석하기가 더 어려워집니다. 목록을 정리하기 전에 기준값이 필요하다면 이 도구를 사용해 캠페인의 이메일 바운스율을 계산하세요.
이 과정은 양식 제출에서 시작됩니다. 검증 게이트를 사용하면 이후 워크플로가 시작되기 전에 오타를 확인하고, 일회용 주소를 표시하거나, 캐치올 결과를 수동 검토로 보낼 수 있습니다.
실시간 주소 검증이 실제로 의미하는 것
실시간 주소 검증은 주소가 입력되는 시점에 수행되는 동기식 확인입니다. 애플리케이션은 제출된 값을 검증 서비스로 보내고, 구조화된 판정을 받은 다음 레코드를 저장할지, 수정을 요청할지, 또는 수동 검토와 같은 정책을 적용할지 결정합니다.
핵심적인 차이는 타이밍입니다. 배치 프로세스는 데이터가 이미 시스템에 들어온 후 기존 목록을 검사합니다. 레거시 레코드는 수정할 수 있지만, 잘못된 가입이 온보딩을 시작하거나, 영업 시퀀스에 들어가거나, 제품 사용 권한을 소모하는 것을 방지할 수는 없습니다. 실시간 검증은 경계에서 해당 레코드를 차단합니다.
실제 흐름은 다음과 같습니다.
- 입력을 수집합니다. 사용자가 가입, 결제 또는 리드 양식에 이메일 주소를 입력합니다.
- 경량 검사를 실행합니다. 제출 전에 인터페이스가 명백한 형식 오류를 발견할 수 있습니다.
- 검증 서비스를 호출합니다. 서버가 도메인, 메일박스 및 위험 검사를 위해 주소를 API로 보냅니다.
- 비즈니스 로직을 적용합니다. 애플리케이션이 레코드를 수락하거나, 추가 확인을 요구하거나, 소프트 차단하거나, 거부합니다.
- 결과를 저장합니다. 판정과 유용한 신호를 저장하여 이후 팀이 결정 이유를 알 수 있도록 합니다.
프로덕션 API는 일반적으로 구문, 도메인 레코드, SMTP 도달 가능성, catch-all 동작, 일회용 주소 여부 및 역할 기반 패턴을 평가합니다. 목표는 완벽한 확실성이 아닙니다. 주소가 운영 데이터가 되기 전에 통제된 방식으로 위험을 줄이는 것입니다.
BillionVerify는 하나의 문제, 즉 잘못된 이메일 데이터가 기업에 비용을 초래하는 문제를 해결하도록 설계된 전문 이메일 검증 서비스입니다. 이메일 검증 API는 이 패턴의 동기식 부분에 적합하며, 배치 정리는 게이트가 존재하기 전에 유입된 오래된 레코드에 여전히 유용합니다.
속도에 따라 사용자는 검증을 보호 기능으로 느낄지, 불편으로 느낄지가 결정됩니다. Loqate 문서에 따르면 Address Find의 서버 내 평균 지연 시간은 2024년 AU/NZ에서 37ms, 국제 트래픽에서 323ms였으며, 이후 2024년 업데이트에서는 AU/NZ에서 22ms, 국제 트래픽에서 86ms로 나타났습니다(API 지연 시간 문서). 이메일 SMTP 검사는 수신 서버가 핸드셰이크를 제어하기 때문에 편차가 더 클 수 있습니다. 따라서 통합에는 타임아웃과 명시적인 알 수 없음 상태가 필요하며, 모든 느린 응답을 유효하지 않은 것으로 처리해서는 안 됩니다.
인증 계층이 내부적으로 작동하는 방식
유용한 실시간 검증기는 하나의 마법 같은 쿼리를 실행하지 않습니다. 여러 계층으로 증거를 조합한 다음, 애플리케이션이 해석할 수 있는 결정을 반환합니다.
구문 및 오타 감지
첫 번째 단계에서는 주소가 허용 가능한 이메일 구조를 따르는지 확인합니다. 구분 기호 누락, 잘못된 문자, 비어 있는 로컬 파트 및 네트워크 호출에 도달해서는 안 되는 기타 오류를 감지합니다. 이 과정은 저렴하고 빠르므로 폼과 서버 측 검증기 양쪽에 적용해야 합니다.
오타 감지는 실용적인 수정 계층을 추가합니다. 사전 기반 도메인 제안 기능은 gmal.com을 gmail.com의 오타일 가능성이 높은 주소로 식별할 수 있습니다. 하지만 제안은 자동 재작성과 같지 않습니다. 특히 해당 도메인이 합법적인 소규모 제공업체일 수 있는 경우에는 제안된 수정을 표시하고 사용자가 확인하도록 하세요.
MX 조회
다음 계층에서는 도메인이 메일 교환 레코드를 게시하는지 확인합니다. MX 결과는 해당 도메인에 이메일 수신을 위한 선언된 경로가 있음을 나타내지만, @ 앞에 지정된 특정 메일박스에 대해서는 아무것도 알려주지 않습니다. 도메인에 정상적으로 작동하는 메일 인프라가 있어도 특정 주소가 존재하지 않거나, 방치되었거나, 프로빙으로부터 보호될 수 있습니다.
구현 세부 정보와 이 신호의 한계를 확인하려면 MX 조회 가이드를 엔지니어링 팀이 참고할 수 있도록 준비해 두세요.
SMTP 및 RCPT TO
SMTP 검증은 메시지를 보내지 않고 수신자의 메일 서버에 연결합니다. 서비스는 자신을 식별하고, 봉투 대화를 시작한 다음, RCPT TO 단계에서 서버에 수신자를 수락할지 묻습니다. 이는 SMTP 수준 이메일 검증에 대한 이 설명에서 설명하는 핵심 메커니즘입니다.
서버의 긍정적인 응답은 해당 상호작용 중 서버가 주소를 수락했다는 의미입니다. 그렇다고 사람이 해당 메일박스를 소유하거나, 적극적으로 읽거나, 해당 주소를 제출할 의도가 있었다는 뜻은 아닙니다. 서버는 메일박스 수준의 응답을 지연하거나, 차단하거나, 숨길 수 있으므로 실패했거나 결론을 내릴 수 없는 핸드셰이크는 별도로 해석해야 합니다.
Catch-all 동작
Catch-all 도메인은 명시적으로 프로비저닝되지 않은 수신자에게도 메일을 수락합니다. 이로 인해 개별 메일박스를 알 수 없는 경우에도 서버가 허용적으로 보입니다. 검증 서비스는 이러한 동작을 테스트하고, 해당 주소를 명백히 안전한 것으로 제시하는 대신 catch-all 플래그 또는 신뢰도 신호를 반환합니다.
따라서 catch-all 결과는 위험 분류이지, 보장된 반송 예측이 아닙니다. 마찰이 적은 뉴스레터 가입에는 이를 허용하고, 가치가 높은 제품 계정에는 추가 확인을 요구하거나, 별도의 육성 세그먼트로 보낼 수 있습니다.
일회용, 역할 기반 및 제공업체 신호
일회용 도메인 감지는 단기간 액세스에 흔히 사용되는 임시 받은편지함 서비스를 식별합니다. 악의적인 의도를 입증하는 것은 아니지만, 제품 팀이 체험판 악용을 방지하거나 다른 검증 방법을 요구할 근거가 됩니다.
역할 기반 감지는 info@, support@, postmaster@와 같은 주소를 표시합니다. 이러한 주소는 메일을 받을 수 있지만, 개별 구매자라기보다 팀이나 시스템을 나타내는 경우가 많습니다. 무료 제공업체 지표는 세분화를 위한 맥락을 추가하지만, 그 자체로 부정적인 판정은 아닙니다. 최신 API는 구문, 도메인, MX, SMTP 및 위험 검사를 결합해 전달 가능성을 평가하며, 유효 또는 유효하지 않음만 반환하지 않습니다 이 검증 API 개요에 설명된 것처럼.
클라이언트 측 검증과 서버 측 검증 비교
클라이언트 측 검증과 서버 측 검증은 서로 다른 문제를 해결합니다. 브라우저는 즉각적인 피드백을 제공하기에 적합하지만, 서버는 데이터베이스 쓰기를 제어하며 자동화된 클라이언트가 규칙을 준수하도록 신뢰할 수 없기 때문에 유일하게 신뢰할 수 있는 강제 적용 지점입니다.
| 차원 | 클라이언트 측 | 서버 측 |
|---|---|---|
| 주요 역할 | 즉각적인 사용자 피드백 | 권위 있는 워크플로 게이트 |
| 가장 적합한 검사 | 기본 형식, 명백한 오타 안내, 로컬 일회용 도메인 힌트 | MX, SMTP, 캐치올, 일회용 및 역할 기반 판단 |
| 사용자 경험 | 빠르고 상호작용이 가능함 | provider 및 수신 서버 응답에 따라 달라짐 |
| 보안 | 로직이 노출되어 우회 가능함 | API 키와 정책이 보호됨 |
| 봇 저항성 | 헤드리스 브라우저와 직접 요청에 취약함 | 인증된 백엔드 로직과 연결하면 더 강력함 |
| 데이터베이스 보호 | 차단된 쓰기를 보장할 수 없음 | 판정이 내려질 때까지 저장을 방지할 수 있음 |
클라이언트 측 검사는 양식이 제출되기 전에 잘못된 입력을 감지하고 불필요한 API 호출을 줄여 주므로 유용합니다. 필드 옆에 도메인 제안을 표시하는 등 사용자가 쉽게 수정하도록 도울 수도 있습니다. 하지만 권위 있는 네트워크 작업을 안전하게 수행할 수는 없으며, 브라우저에 전달된 모든 규칙은 직접 요청을 사용하는 봇이 확인하거나 우회할 수 있습니다.
서버 측 검증은 애플리케이션 또는 API 게이트웨이에서 검증 API를 호출합니다. 트랜잭션을 보류하고, 수락 정책을 적용하며, 결과를 레코드와 함께 기록할 수 있습니다. 단점은 지연 시간입니다. 브라우저 측 검사는 거의 즉각적으로 느껴질 수 있지만, 수신 서버가 느리게 응답할 경우 SMTP 핸드셰이크에 200밀리초에서 몇 초가 걸릴 수 있습니다. 이 범위는 통합 시 고려해야 할 제약으로 받아들이고, 검사를 생략할 이유로 삼지는 마세요.
실용적인 패턴: 안내는 브라우저에서, 권한 있는 판단은 서버에서 처리하세요.
대개 하이브리드 설계가 가장 효과적입니다. 정규식과 명백한 오타 검사는 로컬에서 실행한 다음, 레코드를 확정하기 전에 서버에서 MX, SMTP 및 캐치올 평가를 수행하세요. 타임아웃을 설정하고 provider가 unknown을 반환할 때 어떻게 처리할지 정의하세요. 공격자는 수집된 목록에서 유효해 보이는 주소를 재사용할 수 있으므로, 클라이언트 코드에 로직을 숨기는 것만으로는 충분하지 않습니다.
좋은 실시간 API 응답의 모습
프로덕션 응답은 단순히 결과를 알리는 데 그치지 않고, 결정의 근거를 설명해야 합니다. 평면 JSON 객체는 애플리케이션에서 파싱하고, 기록하며, 워크플로 규칙에 전달하기 쉽습니다. 최상위 결과에는 valid, invalid, risky, unknown 중 하나가 포함될 수 있으며, 불리언 전달 가능성 필드와 근거가 되는 증거도 함께 제공할 수 있습니다.
유용한 필드는 다음과 같습니다.
| 필드 | 목적 |
|---|---|
status | 비즈니스 관점의 전체 판정을 제공합니다 |
deliverable | 전달 가능성에 대한 직접적인 해석을 제공합니다 |
syntax_valid | 주소가 형식 검사를 통과했는지 보여줍니다 |
mx_present | 도메인에 메일 교환 레코드가 있는지 나타냅니다 |
smtp_connected | 서비스가 수신 서버에 연결했는지 기록합니다 |
rcpt_to_result | 수신자 단계의 서버 응답을 저장합니다 |
catch_all | 도메인이 지정되지 않은 수신자를 허용하는지 표시합니다 |
catch_all_confidence | catch-all 동작에 대한 불확실성을 나타냅니다 |
disposable | 임시 받은편지함 도메인인지 식별합니다 |
role_based | info@ 또는 support@와 같은 주소인지 표시합니다 |
free_provider | 세분화를 위한 제공업체 정보를 추가합니다 |
insight 또는 score | 주소가 해당 판정을 받은 이유를 요약합니다 |
response_ms 및 smtp_ms | 타임아웃을 조정하고 느린 응답을 조사하는 데 도움을 줍니다 |
프로덕션 문제를 해결할 때는 타이밍 데이터가 중요합니다. 전체 응답 시간은 높지만 SMTP 시간이 짧다면, 애플리케이션이나 상위 네트워크가 병목일 수 있습니다. SMTP 시간이 대부분을 차지한다면 수신 서버가 상호작용을 지연시키고 있을 가능성이 높습니다. 이러한 필드를 사용하면 엔지니어가 잘못된 주소와 느린 종속성을 구분할 수 있습니다.
최소한의 true 또는 false 응답은 피할 수 있는 문제를 만듭니다. 사용자가 차단되었을 때 제품 팀은 입력 형식이 잘못된 것인지, 도메인에 메일 라우팅이 없는 것인지, 서버가 수신자를 거부한 것인지, 아니면 주소가 catch-all 뒤에 있는 것인지 알 수 없습니다. 풍부한 신호는 더 배려 깊은 인터페이스를 지원합니다. 예를 들어 형식 오류에는 인라인 수정 안내를 제공하고, 역할 계정에는 경고를 표시하며, 결과가 불확실한 경우 수동 승인 경로를 제공할 수 있습니다.
일시적인 피드백을 위해 인터페이스는 필드 옆에 작은 상태 메시지를 표시할 수 있습니다. 이 패턴에 익숙하지 않은 팀이라면, 일시적인 인증 업데이트를 토스트에 표시할지 양식에 직접 표시할지 결정할 때 토스트 알림이란 무엇인가가 유용할 수 있습니다.
실시간 검증이 이메일 도달 가능성을 보호하는 이유
거부된 주소 하나하나는 알 수 없는 수신자에게 전송되는 메시지 하나를 줄입니다. 이러한 연결은 검증을 단순한 데이터 정리 편의 기능이 아니라 발신자 평판 관리 수단으로 만듭니다.
메일박스 제공업체는 반송, 불만, 의심스러운 수신자 활동을 포함한 신호를 평가합니다. Amazon SES 지침에 따르면 반송률이 **5%**를 초과하면 메일박스 제공업체가 경고를 보낼 수 있으며, **10%**를 초과하면 전송을 제한하거나 차단할 수 있습니다 발신자 평판 지침에서 확인할 수 있습니다. 이러한 기준은 전송 전 검사를 구체적으로 만듭니다. 잘못된 주소가 캠페인 이벤트가 되기 전에 차단하세요.
가입 시 게이트는 온보딩 메시지를 보내기 전에 철자가 틀린 도메인과 일회용 받은편지함을 차단할 수 있습니다. 가져오기 과정에서는 동일한 로직으로 불확실한 연락처와 아웃리치에 사용할 준비가 된 주소를 분리합니다. 시간이 지나면 낭비되는 전송을 줄이고, 도달 가능성 팀이 억제하고 테스트하며 모니터링할 수 있는 더 깨끗한 세그먼트를 제공합니다.
한계도 그만큼 중요합니다. 주소 검증을 통해 주소가 실제로 존재하고 표준화되었으며 잠재적으로 전달 가능한지 확인할 수 있지만, 사용자 점유 여부나 신원을 증명할 수는 없습니다 Google Maps Address Validation 문서에서 설명하듯이. 또한 정상적으로 보이는 도메인 뒤에 숨은 모든 스팸 트랩을 식별할 수도 없습니다. 동기식 검사를 참여도 기반 억제, 지속적인 목록 위생 관리, 신중한 캠페인 모니터링과 함께 사용하세요.
주소 판정만으로 의존하지 않고 더 광범위한 전송 조건을 점검해야 할 때는 전용 이메일 도달 가능성 확인 워크플로를 사용하세요.
실제 워크플로에서 실시간 검증이 적용되는 방식
API 호출은 일관되게 유지되지만, 정책은 워크플로에 따라 달라집니다. 가입 양식은 체험 이용을 보호하기 위해 일회용 주소를 거부할 수 있지만, 뉴스레터는 catch-all 주소를 허용하고 별도로 분류할 수 있습니다.
가입 양식
이메일 필드 뒤에 검사를 배치하되, 결과는 서버에서 적용하세요. 구문 검사와 오타 제안은 상호작용을 개선하며, 일회용 주소와 명백히 유효하지 않은 결과는 계정이 사용자 테이블에 도달하기 전에 차단할 수 있습니다. catch-all 주소는 자동 거부 대신 경고나 이메일 확인 단계를 적용하는 편이 적절할 수 있습니다.
SDR 아웃바운드
잠재고객 업로드에서는 인터페이스 속도보다 메일함 및 SMTP 결과가 중요합니다. 영업 담당자가 해당 주소를 기반으로 시퀀스를 구축하기 전에 유효하지 않은 레코드를 필터링하고, support@ 및 info@는 개인 대상 아웃리치에 적합하지 않을 수 있으므로 역할 계정을 분리하세요. catch-all 결과는 영업 운영팀이 해당 계정을 수동으로 조사할 가치가 있는지 판단할 수 있도록 계속 표시해야 합니다.
Ecommerce 결제
결제팀은 오타로 인해 주문 확인, 영수증, 배송 업데이트가 전달되지 않는 상황을 방지해야 합니다. 이메일 필드의 오타가 결제나 배송을 중단시키지는 않을 수 있지만, 고객이 필수 알림을 받지 못할 수 있습니다. 수정 과정을 명확하게 유지하고, 주소가 단지 불확실한 경우에는 강제 차단을 피하세요.
CRM 데이터 정리
웹 양식 제출 및 주요 레코드 업데이트에 검증을 실행한 다음, 검증 절차가 도입되기 전에 생성된 휴면 연락처에는 비동기 검사를 사용하세요. CRM 팀은 세분화된 상태를 보존하여 너처 여정에서 유효하지 않은 주소를 제외하고, 역할 계정을 세분화하며, 불확실한 레코드를 검토 대상으로 전달할 수 있어야 합니다. 아웃바운드 가져오기의 경우 BillionVerify 아웃바운드용 목록 정리가 수집 시점 검사와 함께 사용할 수 있는 관련 배치 도구입니다.
동일한 응답 필드가 네 가지 워크플로를 모두 지원합니다. 가입은 악용 방지를, 아웃바운드는 메일함 신뢰도를, 결제는 알림의 안정성을, CRM 데이터 정리는 세분화와 과거 데이터 정리를 중점으로 둡니다.
모범 사례 및 빠른 구현 체크리스트
실시간 검증기는 주변 애플리케이션이 불확실성을 안전하게 처리할 때만 작동합니다. 서버에서 시작하고, 브라우저 코드에 API 자격 증명을 노출하지 않으며, 서버의 결정에 따라 데이터베이스 쓰기 작업을 조건부로 실행하세요.
다음 구현 체크리스트를 사용하세요.
- 자격 증명 보호: 백엔드 또는 API 게이트웨이에서 검증 엔드포인트를 호출하세요. 클라이언트 측 JavaScript에 API 키를 절대 넣지 마세요.
- 반복 검사 캐싱: 최근 결과를 짧은 기간 저장하여 새로고침, 재시도, 반복 제출로 인해 지연 시간이나 불필요한 검증 호출이 늘어나지 않도록 하세요.
- 전체 응답 파싱: 구조화된 JSON을 단일 불리언 값으로 축소하지 마세요. 상태, MX 존재 여부, SMTP 결과, catch-all 동작, 일회용 상태 및 역할 기반 플래그를 확인하세요.
- 정책 단계 정의: 악용 위험이 높은 경우 명확한 유효하지 않음 및 일회용 결과를 강하게 차단하세요. 워크플로에서 검토를 허용할 수 있다면 불확실하거나 catch-all인 결과는 소프트 차단하세요.
- 거부 사유 설명: 불투명한 제공업체 오류를 노출하는 대신 사용자가 주소를 수정하도록 안내하는 인라인 메시지를 반환하세요.
- 결정 기록: 상태, MX 결과, SMTP 결과, 지연 시간 및 정책 조치를 기록하여 전달 가능성 팀이 오탐과 제공업체 변경을 조사할 수 있도록 하세요.
- 배치 위생 유지: 오래된 레코드는 동기식 게이트를 통과한 적이 없으므로 휴면 및 가져온 세그먼트를 정기적으로 검사하세요.
SMTP 프로브는 차단되거나 지연되거나 속도 제한을 받을 수 있으므로, 응답을 절대적인 신원 증명이 아닌 충분한 근거로 취급하세요. unknown에 별도의 경로를 부여하고, 애플리케이션 타임아웃을 설정하며, 모든 타임아웃을 영구적인 거부로 변환하지 마세요.
BillionVerify의 실시간 엔드포인트, 구조화된 JSON 상태 필드 및 웹훅에 적합한 응답 구조는 맞춤형 SMTP 프로빙 시스템 없이도 이러한 서버 측 패턴에 적합합니다. 중요한 설계 선택은 여전히 여러분의 몫입니다. 각 워크플로에서 어떤 신호를 기준으로 주소를 승인하거나 추가 확인을 요구하거나 거부할지 결정하세요.
BillionVerify는 구문, MX, SMTP, catch-all, 일회용 및 역할 기반 신호에 대한 실시간 이메일 검증을 제공하여 가입 또는 캠페인 데이터가 시스템에 들어오기 전에 데이터 품질 게이트를 마련할 수 있도록 지원합니다. BillionVerify를 방문하여 잘못된 주소가 운영 및 전달 가능성에 가장 큰 위험을 초래하는 워크플로에 해당 검증 계층을 연결하세요.