실제 제품은 본질적으로 멀티유저입니다 — 팀, 워크스페이스, 권한, 초대까지. 이런 흐름을 제대로 테스트하려면 동시에 사용할 수 있는, 서로 구분되는 여러 개의 메일함이 필요합니다. 임시 메일함은 테스터의 도구함에서 의외로 가장 유용한 존재가 됩니다 — 스팸을 피하려는 목적과는 전혀 상관없이 말이죠.

메일함 하나로는 부족한 이유

이미 시스템에 등록된 본인 주소로는 완전히 새로운 사용자를 시뮬레이션할 수 없습니다. 하물며 서로 다른 신규 사용자 세 명을 동시에 만드는 건 더더욱 불가능하고요. 그래서 팀들은 종종 plus 주소(예: [email protected])를 활용한 공용 QA Gmail 계정을 씁니다. 이 방법은 어느 정도까지는 통하지만, 많은 앱이 "+" 태그를 제거하거나 아예 거부해버립니다. 설령 허용되더라도 모든 메일이 결국 하나의 편지함에 뒤섞여 들어오니, 어떤 메일이 어떤 "사용자"에게 온 건지 일일이 풀어내야 합니다.

임시 메일함을 활용한 워크플로

temp-email.ai/temp-mail에서 여는 탭 하나하나가 고유한 주소를 가진 완전히 독립된 메일함입니다. 탭을 몇 개만 열어도 메일을 주고받을 수 있는 실제 사용자 여러 명이 바로 생깁니다 — 계정을 만들 필요도, 나중에 정리해야 할 공용 메일함도 없습니다. 모든 메일은 한 시간 후 자동으로 삭제되니, 개인 이메일에 딸린 테스트 계정 더미가 쌓일 일도 없고요.

테스트해볼 만한 시나리오

• 팀·워크스페이스 초대: 각 초대장이 정확한 주소로, 정상 작동하는 링크와 함께 도착해야 하고, 수락 시 올바른 워크스페이스와 권한으로 연결돼야 합니다.
• 권한과 역할: 소유자, 관리자, 읽기 전용 멤버를 각각 별도의 사용자로 가입시킨 뒤, 각자 자신의 역할에 맞는 것만 보이고 나머지는 보이지 않는지 확인하세요(OWASP Authorization Cheat Sheet 참고).
• 중복 계정 처리: 서로 다른 주소로 계정 두 개를 만든 다음, 하나를 재사용하려 할 때 앱이 어떻게 반응하는지 확인하세요 — 대소문자만 다른 동일 주소의 경우도 포함해서요.
• 추천·초대 리워드 흐름: 추천인은 피추천인이 가입하고 인증을 완료했을 때만 리워드를 받아야 하므로, 양쪽이 어떻게 작동하는지 지켜보려면 살아있는 메일함 두 개가 필요합니다.
• 멀티테넌트 격리: 서로 다른 두 조직에서 계정을 만들어보고, 한 테넌트의 데이터가 다른 테넌트의 이메일이나 알림에 절대 노출되지 않는지 확인하세요(NIST의 멀티테넌트 보안 가이드라인에서도 다루는 부분입니다).
• 동시 가입: 같은 초 단위로 여러 사용자를 가입시켜, 토큰 생성 과정의 경쟁 조건(race condition)이나 다른 메일보다 훨씬 늦게 도착하는 인증 메일 문제를 잡아내세요.

메일이 도착하면 확인할 것들

• 정확한 수신자: 초대 메일이 의도한 주소로만 갔는가?
• 정확한 링크: 수락/인증 URL이 올바른 환경을 가리키고, 올바른 워크스페이스와 권한 정보를 담고 있는가 — 프로덕션에 하드코딩된 링크는 아닌가?
• 정확한 결과 상태: 수락 후 사용자가 올바른 조직에, 역할에 맞는 정확한 권한으로 들어갔는가?
• 렌더링과 격리: 이메일이 제대로 렌더링되는가(버튼 클릭 가능, 이름 올바르게 채워짐), 실수로 다른 사용자의 데이터를 참조하는 일은 없는가?

이 방식은 탐색적 테스트나 출시 전 수동 회귀 테스트에 특히 잘 맞습니다 — 몇 분 만에 현실적인 사용자 그룹을 꾸려서 실제 팀이 쓰는 것처럼 제품을 직접 돌아볼 수 있으니까요. 솔직하게 짚고 넘어갈 부분도 있습니다. 일부 앱은 가입 시 알려진 임시 이메일 도메인을 차단하는데, 이는 그 앱의 정책일 뿐이고, 출시 전에는 실제 메일 제공자에서만 드러나는 전달 이슈를 확인하기 위해 Gmail 같은 실제 메일함으로 마지막 점검을 해보는 것이 좋습니다. 이렇게 활용하면 임시 메일함은 실제 사용자가 버그를 마주치기 전에 멀티유저 흐름을 꼼꼼히 테스트할 수 있는 간단하고 정직한 방법이 됩니다.