테스트용 임시 이메일: 개발자와 QA 팀이 가입 흐름을 점검하는 방법

이메일을 보내는 제품이라면 누군가가 새 주소로 가입하는 일을 계속 반복해야 합니다. 개발자는 자기 Gmail에 플러스 태그를 붙이고, QA 테스터는 버리는 계정을 스프레드시트로 관리하고, 제품 관리자는 동료의 받은편지함을 빌립니다. 신규 사용자가 운영 또는 스테이징 메일 환경에서 정확히 무엇을 받는지 확인하는 일 하나만 놓고 보면, 테스트용 임시 이메일 주소가 그 어떤 방법보다 빠릅니다.

저희는 PureTempMail의 메일 서버를 직접 운영하므로, 아래의 한계는 추측이 아니라 실제 설정값입니다. 이 가이드에서는 테스트 계획에서 공개 임시 받은편지함이 어디에 들어맞는지, 5분이면 끝나는 수동 테스트 절차, 저희가 직접 가입 메일에 쓸 체크리스트, 그리고 다른 도구를 써야 하는 경우를 다룹니다.

여러 테스트 방법 중 임시 받은편지함의 자리

테스트 계정에 주소를 마련하는 흔한 방법은 다섯 가지입니다. 대부분의 팀은 같은 릴리스의 여러 단계에서 그중 두세 가지를 함께 쓰게 됩니다.

임시 받은편지함은 다른 방법들이 남겨 둔 빈틈 하나를 채웁니다. 실제 메일 서비스가 보낸 실제 메시지가, 내가 관리하지 않는 도메인에 도착해, 몇 초 만에 브라우저에 보인다는 점입니다. 어딘가에 또 계정을 만들지 않고도 신규 고객이 보는 화면에 가장 가깝게 확인할 수 있습니다.

PureTempMail로 하는 수동 테스트

가입 흐름을 직접 점검할 때 저희가 권하는 절차입니다. 한 번에 5분 정도 걸립니다.

1. 1

   테스트 사용자마다 새 메일함 열기

   별도의 브라우저 창에서 PureTempMail을 여세요. 페이지가 열리면 새 주소가 만들어집니다. 메일함은 브라우저별로 기억되므로, 테스트 사용자마다 새 주소를 누르거나, 테스터 두 명이 한 컴퓨터를 같이 쓴다면 시크릿 창을 사용하세요.

2. 2

   테스트 케이스 옆에 주소 기록하기

   사용하기 전에 주소를 테스트 케이스나 티켓에 붙여넣으세요. 나중에 테스터가 재설정 메일이 왜 안 왔는지 물을 때, 어느 메일함으로 갔는지 알아야 합니다.

3. 3

   가입을 진행하고 보낼 수 있는 메일을 모두 발생시키기

   양식을 작성한 다음, 신규 사용자가 첫 세션에서 일으킬 수 있는 메일을 요청하세요. 인증 메일 재전송, 비밀번호 찾기, 매직 링크 로그인, 이메일 변경 요청 등입니다. 각각이 별도의 템플릿이며 따로 고장 날 수 있습니다.

4. 4

   새로고침하지 않고 받은편지함 지켜보기

   새 메일은 저희 서버가 받아들이는 순간 실시간 연결로 페이지에 전달되므로, 메시지가 나타난 시각은 실제 전송 시각에 가깝습니다. 각 메일이 얼마나 걸렸는지 기록하세요. 전달 경로는 작동 방식에서 설명합니다.

5. 5

   각 메시지를 두 가지 보기로 열기

   HTML로 읽은 다음 일반 텍스트로 전환하세요. 일반 텍스트 보기는 일부 메일 프로그램과 화면 낭독기가 대신 사용하는 형태로, 텍스트 파트가 빠졌거나 코드를 읽을 수 없는 문제가 가장 먼저 드러나는 곳입니다. 모든 링크를 눌러 어디로 가는지 확인하세요.

6. 6

   흐름이 느리면 연장하기

   단계별 발송 메일, 지연 승인, 이틀째 알림에는 더 많은 시간이 필요합니다. +1시간을 누르면 타이머가 다시 1시간으로 초기화됩니다. 메일함을 만든 뒤 24시간까지 계속 그렇게 할 수 있습니다.

7. 7

   만료시킨 뒤 반송 테스트하기

   만료 후 저희 서버는 해당 주소로 오는 메일을 SMTP 단계에서 "No such mailbox"라는 영구 오류로 거부합니다. 그 주소로 메일을 한 통 더 보내고, 앱이나 메일 발송 서비스가 하드 바운스로 기록하고 그 사용자에게 메일 보내기를 멈추는지 확인하세요.

가입 메일 테스트 체크리스트

어떤 제품이든 릴리스 전에 가입 메일에서 저희가 확인할 항목입니다. 모두 실제 받은편지함에서는 쉽게 보이지만 코드 리뷰에서는 놓치기 쉽습니다.

• 인증 코드 또는 링크. 메일이 도착하고, 코드가 일반 텍스트에서도 읽히고, 링크는 한 번만 작동하며, 두 번째로 누르면 오류 페이지 대신 알기 쉬운 안내가 나와야 합니다.
• 매직 링크와 일회용 코드. 새 링크가 이전 링크를 무효로 만들고, 만료된 링크는 다음에 무엇을 해야 하는지 알려 주며, 다른 브라우저에서 링크를 열었을 때 의도한 대로 동작해야 합니다.
• 비밀번호 재설정. 어느 계정에 대한 메일인지 적혀 있고, 링크가 만료되며, 가입되지 않은 주소로 재설정을 요청해도 그 주소에 계정이 있는지 드러나지 않아야 합니다.
• 환영 메일과 단계별 발송 메일. 첫 메일은 인증 전이 아니라 인증 후에 도착해야 하고, 인증하지 않은 사용자에게는 이후 단계가 발송되지 않아야 합니다.
• HTML 파트와 텍스트 파트. 둘 다 있고, 같은 내용을 담고 있으며, 중요한 내용이 이미지 안에만 있으면 안 됩니다. 저희 HTML 보기에서는 외부 이미지가 로드되므로 거기서 이미지를 확인하고, 일반 텍스트로 이미지 없는 메시지를 볼 수 있습니다.
• 첨부파일. 청구서와 PDF가 적절한 파일 이름과 콘텐츠 유형으로 도착해야 합니다. 테스트 파일은 메시지당 1 MB 미만으로 하거나 다운로드 링크를 보내세요. 실제 사용자에게도 그쪽이 더 친절합니다.
• 링크 대상. 운영 메일의 어떤 링크도 localhost, 내부 호스트 이름, 스테이징 도메인을 가리키면 안 되며, 추적용 리디렉션은 올바른 페이지로 이어져야 합니다.
• 수신 거부 헤더. 마케팅 메일과 단계별 발송 메일에는 작동하는 수신 거부 링크가 있어야 하고, 대량 발신자라면 RFC 8058에 정의된 원클릭 List-Unsubscribe 헤더도 있어야 합니다. Google 발신자 가이드라인은 대량 발신자에게 이를 요구합니다. 재설정 메일 같은 트랜잭션 메일은 수신 거부 때문에 막혀서는 안 됩니다.
• 전송 시간. 인증 메일이 1~2분 넘게 걸리면 사용자가 떠납니다. 느리다면 앱이 메일을 다른 작업 뒤에 대기시키는지, 메일 서비스가 새 발신자를 제한하는지 확인하세요.
• 자체 속도 제한. 재전송 버튼을 연타해 보세요. 앱은 횟수를 제한하고 사용자에게 기다리라고 안내해야 하며, 코드를 열 개 보내거나 아무 말 없이 실패해서는 안 됩니다.
• 주소 재사용. 한 세션 안에서 같은 주소로 두 번 가입해 두 번째 시도를 확인하세요. "이미 가입된 주소"라는 분명한 안내가 나오고, 두 번째 계정이 생기지 않아야 합니다.
• 일회용 도메인 차단 규칙. 제품이 임시 주소를 차단한다면, 오류 메시지가 명확한지, 실수로 실제 메일 서비스까지 차단하지 않는지 확인하세요. 자세한 내용은 아래에 있습니다.

저희 서비스의 한계와 테스트에 미치는 영향

저희 서버의 실제 설정값입니다. 테스트는 이를 고려해 계획하세요.

유효 기간

생성 후 1시간. +1시간을 누르면 다시 1시간으로 초기화되며, 생성 후 24시간까지 가능합니다. 한 번의 세션에는 충분하지만, 다음 스프린트에 다시 쓸 테스트 계정에는 맞지 않습니다.

메시지

메일함당 최대 50통, 5 MB. 둘 중 하나라도 한도에 도달하면 새 메일은 거부되므로, 주소 하나를 겨냥한 부하 테스트는 금방 집계가 멈춥니다. 테스트 사용자마다 새 메일함을 여세요.

메시지 크기

첨부파일을 포함해 메일당 최대 1 MB. 첨부파일은 처음 10개만 보관됩니다.

수신 전용

이 주소로는 메일을 보내거나 답장할 수 없습니다. 지원 티켓 스레드처럼 사용자가 메일로 답장해야 하는 흐름은 여기서 처음부터 끝까지 테스트할 수 없습니다.

도메인

모든 주소가 하나의 도메인을 씁니다. 제품이 알려진 임시 도메인을 차단한다면 저희 도메인도 차단됩니다. 바로 그 동작을 테스트하고 싶을 때 유용합니다.

새 메일함

IP 주소 하나당 1분에 새 메일함 5개. 같은 사무실 회선을 쓰는 QA 팀은 이 한도를 함께 나눠 씁니다.

삭제

만료 후 5분마다 실행되는 정리 작업이 메일함과 메시지, 첨부파일을 삭제합니다. 버그 보고에 증거가 필요하다면 타이머가 끝나기 전에 스크린샷을 찍어 두세요.

자동화

메일함에 스크립트로 접근할 수 있는 공개 API는 없습니다. PureTempMail은 브라우저를 보고 있는 사람을 위해 만들어졌기 때문에, 자동화 테스트 스위트에는 아래에 소개하는 도구가 맞습니다.

테스트 메일의 SPF, DKIM, DMARC 확인하기

보기 좋게 표시되는 메시지라도 인증에 실패해 실제 사용자의 스팸함으로 갈 수 있습니다. 확인하려면 Gmail의 원본 보기처럼 원본 소스를 보여 주는 메일함으로 같은 메일을 보내고, 헤더를 저희 이메일 헤더 분석기에 붙여넣으세요. SPF, DKIM, DMARC 통과 여부를 보여 주고, 다른 도메인의 Reply-To를 표시하며, 어디서 전송이 느려졌는지도 알려 줍니다. 분석은 브라우저에서 이루어지므로 헤더는 저희에게 전송되지 않습니다.

자체 일회용 도메인 차단 테스트하기

가입 양식에 일회용 이메일 검사를 넣고도 실제 임시 주소로 한 번도 테스트하지 않는 팀이 많습니다. 임시 받은편지함은 당연히 써 볼 만한 테스트 입력입니다.

• 문구를 확인하세요. 거부 메시지는 대신 무엇을 써야 하는지 알려 줘야 합니다. 예를 들어 "개인 또는 회사 주소를 사용해 주세요" 같은 문구입니다. 그냥 "잘못된 이메일"이라고만 하면 정직한 사용자는 있지도 않은 오타를 찾아 헤맵니다.
• 오탐을 확인하세요. 소규모 지역 메일 서비스와 회사 자체 도메인의 주소로 시도해 보세요. 패턴으로 일치 여부를 판단하는 차단 목록은 가끔 이런 주소까지 걸러 냅니다.
• 모든 진입 지점을 확인하세요. 가입 양식, 이메일 변경 설정, 초대, API에 같은 규칙이 적용되어야 합니다. 그렇지 않으면 사람들은 빠뜨린 경로를 쓰면 그만입니다.
• 차단이 정말 필요한지 판단하세요. 웹사이트가 일회용 이메일을 차단하는 이유 글에서 차단할 만한 비용과, 정직한 사용자만 잃게 되는 경우를 다룹니다.

공개 임시 받은편지함이 맞지 않는 경우

이런 경우에는 다른 도구를 쓰세요.

• 실제 비밀 정보나 고객 데이터가 담긴 메일. 운영 토큰, 실제 청구서, 관리자 초대 등. 팀만 읽을 수 있는 샌드박스를 쓰세요.
• 자동화 테스트와 CI. 개발과 CI에서는 앱이 Mailpit 같은 로컬 캐처로 메일을 보내게 하고, 배포된 환경을 대상으로 테스트해야 할 때는 Mailtrap이나 Mailosaur 같은 호스팅형 샌드박스를 쓰세요. 예전부터 쓰이던 로컬 캐처인 MailHog는 더 이상 관리되지 않으며, 보통 Mailpit으로 대체합니다.
• 실제 사용자 데이터 사본이 있는 스테이징 환경. 그곳의 문제는 복사된 데이터 자체입니다. 데이터를 정리하고 스테이징 메일은 캐처로 보내, 테스트가 실제 고객에게 메일을 보내는 일이 없게 하세요.
• 계속 유지해야 하는 테스트 계정. 영업용 데모 계정이나 앱 스토어 심사용 계정에는 다음 달에도 쓸 수 있는 주소가 필요합니다. 팀 메일함의 플러스 주소나 직접 소유한 테스트 도메인의 캐치올을 쓰세요.
• 절대 전송되면 안 되는 픽스처. 시드 데이터와 단위 테스트에는 example.com 같은 예약 도메인과 RFC 2606에서 따로 지정한 .test 최상위 도메인을 쓰세요. 이 도메인으로 보낸 메일은 설계상 어디에도 도착하지 않습니다.

출처

• GitHub의 Mailpit. 개발자용 이메일 테스트 도구이자 API이며, MailHog 대체에 관한 설명도 있습니다.
• Mailtrap Email Sandbox 문서.
• GitHub의 Mailosaur 클라이언트 라이브러리.
• RFC 8058, Signaling One-Click Functionality for List Email Headers.
• Google, 이메일 발신자 가이드라인.
• RFC 2606, Reserved Top Level DNS Names.
• 메일함 유효 기간, 크기와 개수 한도, 속도 제한, 만료 후 SMTP 거부, 정리 주기는 PureTempMail 자체 서버 설정에서 가져온 것이며, 자주 묻는 질문에도 요약되어 있습니다.