ko

신뢰할 수 있는 임시 인박스 API 자동화

고유 주소, 제한된 폴링, 정밀한 메시지 매칭, 안전한 키 처리, 유용한 실패 증거를 활용하여 결정론적인 회원가입 및 비밀번호 재설정 테스트를 구축하세요.

2026. 7. 17.

인박스를 생성, 수신, 확인 및 정리하는 간결한 자동화 루프

신뢰할 수 없는 이메일 테스트 버전은 간단합니다: 주소를 만들고, 5초 동안 대기한 뒤, 첫 번째 메시지를 읽고, 그것이 이번 실행에 해당하길 기대합니다.

신뢰할 수 있는 버전도 여전히 간단하지만, 전달을 비동기로 처리합니다. 고유 주소를 생성하고, 시작 시간을 기록하며, 마감 시간 내에 폴링하고, 의도된 메시지를 매칭하고, 제품 동작을 검증하며, 문제가 발생했을 때 충분한 컨텍스트를 보고합니다.

API 키를 URL에 포함하지 않기

GPTMail 키를 X-API-Key 헤더에 전송하세요. ?api_key= 쿼리 매개변수에 넣지 마세요. URL은 브라우저 기록, 접근 로그, 모니터링 시스템, 리퍼러 데이터 등에 정기적으로 저장됩니다.

X-API-Key: YOUR_API_KEY

키를 CI 비밀 관리자로 저장하고 로그에서는 마스킹하세요. 공개 일일 키는 탐색에 편리하지만, 제어된 자동화 스위트는 할당량과 사용량을 추적할 수 있는 키를 사용해야 합니다.

현재 엔드포인트와 응답 예시는 GPTMail API 문서 페이지에서 관리됩니다.

실행당 하나의 주소

각 독립 실행 가능한 테스트마다 새 주소를 생성하세요. 전체 테스트 스위트가 공유하는 인박스에서 정확성을 판단하지 마세요.

주소, 시나리오 ID, 환경, 테스트 시작 시간을 기록하세요. 이러한 값은 오래된 메시지를 거부하고, 메시지 비밀을 로그에 남기지 않으면서 충돌을 진단하는 데 도움이 됩니다.

고정된 대기 대신 마감 시간에 맞춰 폴링하기

이메일 전달 시간은 다양합니다. 고정된 5초 대기는 전달이 빠를 때는 낭비이고, 느릴 때는 불안정합니다.

제한된 루프를 사용하세요:

deadline = now + 90 seconds
delay = 2 seconds

while now < deadline:
  messages = list inbox
  candidate = newest message matching sender, subject, and start time
  if candidate exists:
    read candidate and continue the product test
  wait delay with a small random jitter
  delay = min(delay * 1.5, 10 seconds)

마감 시간은 테스트 계약에 포함됩니다. 비밀번호 재설정 흐름은 대량 뉴스레터 미리보기와 다른 제한이 필요할 수 있습니다. 제한을 명시적으로 유지하여 느린 의존성이 CI 작업 전체를 조용히 늘리지 않도록 하세요.

정확히 매칭하기

“인박스의 첫 번째 메시지”는 유용한 선택자가 아닙니다. 여러 신호를 매칭하세요:

  • 수신자가 이번 실행을 위해 생성된 주소와 일치한다;
  • 생성 시간이 트리거 시간보다 이후이다;
  • 보낸 사람이 예상 서비스에 속한다;
  • 제목 또는 메시지 유형이 흐름과 일치한다;
  • 메시지 ID가 이미 사용되지 않았다.

보낸 사람이 여러 코드를 발행할 수 있는 경우, 가장 최신의 매칭 메시지를 선택하세요. 재시도 시 실수로 재사용되지 않도록 해당 ID를 테스트 출력에 보관하세요.

목록 매칭 후에만 읽기

인박스 목록 조회는 저비용 탐색 단계여야 합니다. 선택된 후보에 대해서만 전체 메시지를 가져오세요. 이렇게 하면 불필요한 작업을 줄이고 관련 없는 홍보 메일 파싱을 방지할 수 있습니다.

6자리 문자열의 존재만 확인하지 말고 비즈니스 결과를 검증하세요. 코드를 제출하거나 예상 링크를 열고, 계정이 올바른 상태에 도달했는지 확인합니다.

속도 제한을 신호로 처리하기

API가 할당량 또는 속도 제한 응답을 반환하면 현재 시도를 중단하고 재설정 정보를 표시하세요. 과도한 재시도는 명확한 용량 신호를 잡음으로 만들고, 관련 없는 테스트를 지연시킬 수 있습니다.

특히 스위트가 한 번에 많은 주소를 생성할 경우, 테스트 러너에서 동시성을 제한하세요. 작은 워커 풀은 수백 개의 동시 폴링 루프보다 디버깅이 쉽습니다.

실패를 숨기지 않는 정리

정리는 증거를 수집한 후에 실행되어야 합니다. 성공 시 메시지를 삭제하거나 짧은 보존 기간에 맡기세요. 실패 시 조사에 충분히 오래 보관할 수 있도록 주소와 메시지 ID를 보호된 CI 아티팩트에 유지한 뒤 삭제합니다.

검증 코드, 개인 링크, 전체 HTML 본문을 공개 빌드 로그에 절대 출력하지 마세요.

재시도를 멱등하게 만들기

새 주소로 새로운 실행으로 테스트를 재시도하세요. 같은 계정과 인박스에 동일 요청을 반복한다고 깨끗한 상태에서 시작된다고 가정하지 마세요. 보낸자는 오래된 코드를 무효화하거나, 반복 요청을 제한하거나, 중복 초대를 거부할 수 있습니다.

네트워크 요청이 타임아웃될 경우, “응답을 받지 못함”과 “작업이 발생하지 않음”을 구분하세요. 파괴적인 재시도를 수행하기 전에 관찰 가능한 상태를 확인합니다.

실패 지점을 보고하기

유용한 자동화 실패는 다음 단계 중 하나를 식별합니다:

  1. 주소 생성 실패;
  2. 이메일 대기열에 넣기 전 제품 동작 실패;
  3. 마감 시간 전에 매칭 메시지 도착 없음;
  4. 메시지는 도착했지만 내용이 일치하지 않음;
  5. 검증 동작 실패;
  6. 정리 실패.

이 분류는 간헐적인 “이메일 테스트 실패”를 팀이 담당할 수 있는 작업으로 전환합니다.

더 큰 테스트 매트릭스에 대해서는 실제 이메일 테스트 계획을 읽어보세요. 전달 진단을 위해서는 인증 이메일이 도착하지 않음: 문제 단계 찾기를 사용하세요.

GPTMail