월요일 아침의 문의: 실제 사용자가 겪는 그대로 가입부터 결제까지 테스트하기

제목이 네 단어뿐인 지원 문의를 떠올려 보세요. 결제함, 아무 일 없음, 도와주세요. 월요일 오전 8시 52분에 도착합니다. 자사 결제 흐름에 대해 새로운 사실을 배우기 시작하기에는 최악의 순간이죠. 유료 제품을 어느 정도 다뤄 본 사람이라면 이 이야기의 어떤 버전이든 익숙할 겁니다.

고객은 특별한 일을 하지 않았습니다. 일요일 저녁에 가입했고, 인증 메일을 열기 전에 다른 일에 정신이 팔렸고, 다음 날 아침에 돌아와 곧장 요금제 페이지로 가서 결제했습니다. 승인은 났습니다. 그리고 그걸로 끝. 영수증도, 플랜 업그레이드도, 환영 메시지도 없습니다. 제품 입장에서 이건 어쩌다 결제까지 마친 절반짜리 가입일 뿐입니다.

모든 테스트가 초록불입니다. 가입은 테스트되어 있습니다. 메일 발송도 테스트되어 있습니다. 결제 화면은 진심으로 신경 쓰는 사람들이 꼼꼼히 테스트해 두었습니다. 버그는 아무도 소유하지 않은 유일한 자리에 있습니다. 영수증을 만드는 작업이 인증 링크를 클릭해야만 채워지는 필드를 읽는데, 이 고객은 클릭 전에 결제한 겁니다. 그에게는 지극히 평범한 순서였지만, 스위트의 어떤 테스트도 그 순서를 밟아 본 적이 없습니다. 모든 테스트가 이미 인증된 사용자에서 시작하니까요.

이음매란 원래 그렇습니다. 가입 팀은 가입을, 빌링 팀은 청구를 소유합니다. 그 사이의 공간은 우연히 그곳을 지나가는 사람의 몫입니다. 아무도 의도적으로 걸어보지 않으면, 처음 그 길을 걷는 사람은 월요일 아침의 유료 고객이 됩니다.

이런 버그를 못 찾는 이유: 당신은 신규가 될 수 없다

여기서부터가 불편한 부분입니다. 그런 버그의 존재를 알고 나서도 재현은 번거롭습니다. 당신은 쉽게 신규 사용자가 될 수 없기 때문입니다. 당신의 이메일 주소는 이미 사용자 테이블에 있습니다. 결제 대행사의 고객 레코드이기도 하고, 마케팅 툴의 연락처이자, 애널리틱스의 한 행이며, 잊고 지낸 두 개의 기능 플래그 코호트 구성원이기도 합니다. 브라우저는 세션, 저장된 카드, 지난 분기에 닫아 둔 온보딩 툴팁을 그대로 안고 있습니다.

자기 주소로 가입을 테스트하면, 실제 고객이 결코 걷지 않을 길을 걷게 됩니다. 고객이 막히는 바로 그 구간을 건너뛰고, 빈 화면 상태도, 첫 사용자 업셀도, 3월에 조용히 발송이 멈춘 환영 메일도 결코 보지 못합니다.

진짜로 새로워지려면 두 가지가 동시에 필요합니다. 시스템이 한 번도 본 적 없는 신원, 그리고 시스템을 한 번도 만난 적 없는 브라우저. 둘 다 준비에 1분이면 충분합니다. 둘 중 하나라도 빠지면 그 실행은 아무것도 알려주지 못합니다.

무대 준비하기

임시 이메일 받은편지함이 신원 쪽 절반을 해결해 줍니다. 당신의 스택 어디에도 존재하지 않는 주소가 1초 만에 준비되고, 20분 뒤 영수증이 도착해도 여전히 읽을 수 있습니다. 나머지는 상태를 얼마나 엄격하게 관리하느냐의 문제입니다.

• 시크릿 창만이 아니라, 깨끗한 브라우저 프로필. 시크릿 모드는 쿠키를 처리해 주지만, 별도 프로필은 확장 프로그램도 없고 자동 완성된 카드도 없다는 뜻입니다. 둘 다 결제 화면의 동작을 조용히 바꿔 놓습니다.
• 이 제품이 한 번도 본 적 없는 주소. 기존 레코드와 충돌하는 대신 새 레코드를 만들기 위해서입니다.
• 결제 쪽 신원도 새것으로. 테스트 고객을 재사용한다는 건 그의 저장된 카드와 청구 이력을 재사용한다는 뜻입니다. 첫 구매자에게는 결코 없는 상태죠.
• 다른 이름과 다른 회사명. 테스트 데이터처럼 보이는 값과 사람처럼 보이는 값은 서로 다른 유효성 검사를 건드립니다.
• 결제 대행사를 테스트 모드로 연결한 스테이징 환경. 운영 환경은 절대 안 되고, 실제 카드도 절대 안 됩니다.

1단계: 가입하고, 메일을 진짜로 읽는다

주소를 붙여넣고 제출합니다. 메시지는 몇 초 안에 도착해야 합니다. 30초가 걸린다면 기록해 두세요. "받은편지함을 확인하세요" 화면을 30초 동안 바라보는 사용자는 당신을 의심하기 시작한 사용자입니다. 도착하면 버튼만 찾지 말고 제대로 읽으세요.

• 도착까지 걸린 시간. 측정하세요. 부하가 걸리면 가장 먼저 나빠지는 지표이고, 출시 당일까지 아무도 알아채지 못합니다.
• 보낸 사람. 사람이 읽을 수 있는 브랜드명인가요, 아니면 no-reply 호스트명인가요? 답장하면 사람에게 닿나요, 아니면 사라지나요?
• 링크는 두 번 클릭. 한 번은 인증하려고. 또 한 번은 토큰이 일회용이며 두 번째 시도가 500 에러 대신 정중하게 거절되는지 확인하려고.
• 만료. 하나를 유효 기간이 지나도록 쓰지 않고 두었다가, 거절되는지 그리고 새 링크를 받는 방법을 안내하는지 확인하세요.
• 대소문자. 대소문자를 바꿔 다시 가입해 보세요. 도메인은 RFC 5321에 따라 대소문자를 구분하지 않고, 거의 모든 제품이 로컬 파트도 그렇게 다룹니다. 여기서 두 번째 계정이 생기면 안 됩니다.
• 미인증 상태 — 도입부 시나리오가 바로 이것입니다. 아무것도 클릭하기 전에, 앱이 이미 무엇을 허용하는지 확인하세요. 팀원을 초대할 수 있나요? 결제가 되나요? 의도된 설계일 때도 있습니다. 월요일 아침 문의를 기다리는 상태일 때도 있고요.

인증이 주된 관심사라면 별도의 세션을 들일 가치가 있습니다. 토큰과 엣지 케이스는 개발자가 이메일 인증 흐름을 테스트하는 방법에서 더 깊이 다뤘습니다.

2단계: 돈이 움직이기 전의 조용한 구간

인증과 결제 사이에는 자동 발송 메시지가 작은 무리를 이루고 있습니다. 환영 메일, 온보딩 리마인더, "계정 설정을 마무리하세요". 대부분의 제품에서 가장 덜 테스트된 메일들입니다. 테스트 중 누군가 누르는 버튼이 아니라 백그라운드 작업이 보내기 때문이죠.

받은편지함을 열어 두고 지켜보세요. 중복된 환영 메일, 가입 90초 만에 날아오는 리마인더, 입력한 적 없는 이름으로 부르는 인사말 — 전부 실제 결함이고, 전부 사람이 편지함을 읽지 않으면 보이지 않습니다.

3단계: 결제 단계 — 언제나 샌드박스에서

이제 다들 조심스럽게 피해 가는 부분입니다. 결제는 건드리기 위험해 보이니까요. 위험한 건 환경을 잘못 골랐을 때뿐입니다. 제대로 된 결제사는 바로 이걸 위해 샌드박스를 제공합니다. Stripe는 테스트 카드 전체 목록을 공개하고, PayPal도 샌드박스 계정을 제공합니다. 한 푼도 움직이지 않으면서 실제와 똑같이 동작하죠.

그걸 쓰세요. 테스트 환경에 진짜 카드 번호를 절대 입력하지 마세요. 본인 것도 안 되고, 동료나 고객의 것은 더더욱 안 됩니다. 실제 카드 데이터는 당신이 쓰는 장비까지 PCI DSS 적용 범위로 끌어들이는데, 스테이징 장비는 그런 데이터가 있어야 할 마지막 장소입니다. 테스트 번호는 이런 판단을 아예 할 필요가 없도록 존재합니다.

핵심은 해피 패스에서 멈추기를 거부하는 데 있습니다. 모든 게 잘 풀릴 때만 동작하는 결제 화면은 제대로 테스트된 게 아닙니다.

• 깔끔한 성공. 결제 승인, 플랜 실제 활성화, 사용자가 빈 대시보드가 아니라 의미 있는 화면에 도착.
• 평범한 거절. 사용자가 명확한 설명을 받고 입력값을 유지하나요, 아니면 스택 트레이스와 빈 장바구니를 받나요?
• 잔액 부족. 일반 거절과는 다른 상황이고, 별도 문구를 쓸 만한 가치가 있습니다.
• 3-D Secure 인증 절차. 강력한 고객 인증은 많은 시장에서 의무입니다. 한 번은 끝까지 완료하고, 다시 실행해서 중간에 이탈해 보세요. 이탈한 인증이 절반만 만들어진 구독을 남겨서는 안 됩니다.
• 만료된 카드와 잘못된 CVC. 하나의 쓸모없는 메시지로 뭉개지기 쉬운 두 개의 오류 경로입니다.
• 이중 제출. 결제 버튼을 빠르게 두 번 클릭. 청구는 한 건이어야 하고 두 건이면 안 됩니다. 이 목록에서 실제로 새어 나갔을 때 가장 비싼 버그입니다.
• 뒤로 가기 버튼. 결제하고, 뒤로 가고, 다시 제출. 같은 질문을 다른 문으로 던지는 셈입니다.
• 통화와 세금. 지역별로 다르게 청구한다면 두 지역을 돌려 보세요. 세금은 한 곳에서 계산되어 세 곳에 표시되고, 그 셋은 어긋납니다.

Stripe를 쓴다면 아래 번호들이 목록 전체를 커버하므로 실행 도중에 문서를 뒤질 필요가 없습니다. 미래 만료일과 아무 세 자리 CVC를 조합해 사용하세요.

• 4242 4242 4242 4242 — 깔끔한 성공. 기준선입니다.
• 4000 0000 0000 0002 — 일반 거절.
• 4000 0000 0000 9995 — 잔액 부족. 사용자에게는 일반 거절과 다르게 읽혀야 합니다.
• 4000 0000 0000 0069 — 만료된 카드.
• 4000 0000 0000 0127 — 잘못된 CVC.
• 4000 0025 0000 3155 — 3-D Secure 인증을 강제합니다. 두 번 실행하세요. 한 번은 완료, 한 번은 중간 이탈로.

다른 결제사도 동등한 세트를 공개하므로 같은 여섯 가지 시나리오는 그대로 옮겨 갑니다. 바뀌는 건 번호뿐입니다. 결제사가 목록을 개정하기도 하니 가끔 최신 테스트 문서와 대조해 보는 편이 좋습니다.

4단계: 영수증도 제품의 일부다

결제가 승인되는 순간, 받은편지함은 이 테스트에서 가장 흥미로운 화면이 됩니다. 영수증은 가장 나중에 만들어지고 가장 먼저 잊히지만, 고객에게는 이 모든 일이 실제로 일어났음을 증명하는 산출물입니다. 재무팀에 전달하는 파일이자 경비 정산에 첨부하는 문서죠.

• 금액이 결제 페이지와 일치한다. 당연해 보이지만, 할인과 일할 계산과 환율 변환이 끼어드는 순간 생각보다 자주 어긋납니다.
• 세금이 올바르게 분리 표시된다 — 테스트한 지역 기준으로.
• 플랜 이름이 고객이 보는 이름이다. plan_pro_v2_2024가 아니라.
• 인보이스 번호, 날짜, 회사 정보가 들어 있고 사람이 읽을 수 있다.
• PDF나 호스팅된 인보이스 링크가 로그인하지 않은 사람에게도 열린다. 전달받는 재무 담당자에게는 계정이 없습니다.
• 모든 링크가 공개된 곳을 가리킨다. 스테이징은 localhost URL을 메일에 아주 열정적으로 흘려보냅니다.

5단계: 한 달을 기다리지 않고 갱신과 결제 실패 확인하기

구독 버그는 미래에 숨습니다. 그래서 그렇게 오래 살아남죠. 갱신 청구, 카드 만료 경고, 미납 독촉 시퀀스, 최종 해지 통지 — 전부 릴리스 몇 주 뒤에 일어나고, 그때쯤이면 아무도 받은편지함을 보고 있지 않습니다.

기다릴 필요는 없습니다. Stripe의 테스트 클록은 테스트 고객을 몇 초 만에 여러 청구 주기만큼 앞으로 감아 주고, 대부분의 결제사에 비슷한 기능이 있습니다. 이걸 일회용 받은편지함에 겨누면 1년치 청구 메일이 몇 분 만에 도착합니다.

• 갱신 영수증이 올바른 날짜에 올바른 금액으로 발송된다.
• 예정 청구 안내를 보낸다면, 쓸모 있을 만큼 충분히 일찍 도착한다.
• 미납 독촉 시퀀스가 실패하는 카드에 대해 합리적으로 단계를 높이고, 결제가 성공하는 순간 멈춘다. 이미 낸 사람이 세 번째 성난 독촉을 받아서는 안 됩니다.
• 다운그레이드와 이용 제한 안내가 계정이 실제로 아직 할 수 있는 일과 일치한다.

6단계: 해지하고, 그다음 환불하기

끝까지 걸어가세요. 해지한 뒤, 확인 메일이 결제한 기간이 끝날 때까지 이용이 유지되는지 아니면 즉시 중단되는지에 대해 진실을 말하는지 확인하세요. 그 한 문장이 빌링 영역의 어떤 문장보다 많은 성난 후속 문의를 만듭니다. 그다음 결제사 쪽에서 환불하고, 대변 전표나 환불 확인 메일이 실제로 고객에게 도달하는지 확인하세요. 고객이 볼 수 없는 대시보드 안에서 돈만 조용히 움직여서는 안 됩니다.

모든 메시지에 적용하는 공통 점검

무엇이 발송했든, 모든 메일은 똑같은 빠른 점검을 거칩니다. 습관이 되면 몇 초면 끝납니다.

• 도착했다. 조용히 폐기되지 않고 받은편지함에.
• 날것의 자리표시자가 그대로 렌더링되지 않는다. 인사말에 치환되지 않은 토큰이 남는 것은 이 글에서 가장 창피한 버그이면서, 끊임없이 배포되는 버그입니다.
• 텍스트 버전이 존재하고 제대로 읽힌다. 많은 메일 클라이언트와 스크린 리더가 HTML 대신 이걸 사용합니다.
• 링크가 절대 경로이고 공개되어 있다.
• 마케팅 메일에 동작하는 수신 거부가 있다. RFC 8058의 원클릭 헤더를 포함해서요. Google의 발신자 가이드라인에 따라 대량 발신자에게는 사실상 필수입니다. 거래 영수증에는 넣지 않아야 합니다.
• 인증을 통과한다. 테스트 메일의 도달률이 나쁘다면 지금 원인을 찾으세요. 거래 메일이 스팸으로 가는 이유에서 원인을 다룹니다.

왜 일회용 받은편지함이 이 루프에 맞는가

이 방식을 현실적으로 만들어 주는 건, 받은편지함이 일회용이면서도 쓸모없을 만큼 짧게 살지는 않는다는 점입니다. 메시지가 실시간으로 도착하므로 시스템이 보내는 그 순간에 하나씩 떨어지는 걸 볼 수 있고, 원인과 결과가 명확하게 유지됩니다. 주소는 한 시간 동안 살아 있어서 가입, 결제, 3-D Secure 우회, 빨리 감은 청구 주기까지 여유 있게 커버합니다. 10분짜리 받은편지함은 하필 영수증이 도착하려는 순간에 만료되기 일쑤입니다.

그리고 뒷정리할 것이 없습니다. 실제 주소에 테스트 계정이 쌓이지도 않고, 여섯 사람의 실행이 뒤섞이는 공용 QA 편지함도 없고, 화면의 메시지가 오늘 실행 건인지 지난 목요일 것인지 헷갈릴 일도 없습니다. 다음 시도는 진짜로 백지에서 시작합니다. 그게 전부의 요점이죠. 한 시간이 끝난 뒤 이 모든 게 어떻게 되는지 궁금하다면 한 시간 후에 무슨 일이 일어나는가에 정리해 두었습니다.

이 방식이 실제로 잡아내는 것들

이런 실행은 특정 계열의 결함을 확실하게 끌어냅니다. 시스템 안이 아니라 시스템과 시스템 사이에 사는 결함들이죠.

• 후속 작업이 전혀 관계없는 단계에서 채우는 필드를 필요로 해서, 영수증이 영영 발송되지 않는 경우. (안녕하세요, 월요일.)
• 성급한 두 번째 클릭 때문에 생긴 이중 청구.
• 인증 전에 결제한 사람에게 환영 메일이 두 번 가거나 아예 가지 않는 경우.
• 결제는 성공했는데 플랜 활성화가 조용히 실패해서, 돈을 낸 고객이 무료 등급에 남는 경우.
• 중간에 이탈한 3-D Secure 인증이 주인 없는 반쪽 구독을 남기는 경우.
• 설정 플래그 하나 차이로 고객에게 갈 뻔했던 메일에 스테이징 URL이 남아 있는 경우.
• 이미 결제한 사람을 아직도 쫓아다니는 미납 독촉 시퀀스.

한 가지 주의, 분명히 말해 둡니다

이것은 당신이 책임지는 소프트웨어를, 당신이 통제하는 환경에서, 결제 샌드박스를 상대로 테스트하는 기법입니다. 무료 체험을 긁어모으거나, 유료 장벽을 우회하거나, 남의 서비스에 계정을 찍어 내는 수단이 아닙니다. 그건 남용이고, 임시 이메일 제공자가 차단당하는 이유이며, 이 도구가 만들어진 목적이 아닙니다.

한계는 반대 방향으로도 작용합니다. 일회용 받은편지함은 의도적으로 임시이므로, 계속 유지해야 하는 계정에는 절대 연결하지 마세요. 그 편지함 없이 복구할 수 없다면 실제 주소를 쓰세요. 자신이 그 선의 어느 쪽에 서 있는지 헷갈린다면 별칭과 임시 주소 비교가 알맞은 읽을거리입니다.

영웅적인 노력이 아니라 의례로 만들기

이런 문제를 잡아내는 팀은 가장 정교한 테스트 계획을 가진 팀이 아닙니다. 의미 있는 무언가를 배포하기 전에 낯선 사람으로서 전체 경로를 걸어 보는 팀입니다. 새 받은편지함, 깨끗한 프로필, 가입, 인증, 테스트 카드 결제, 모든 메시지 정독, 해지, 환불. 30분, 전부 수동. 그런데도 자동화 스위트가 구조적으로 찾을 수 없는 것들을 계속 찾아냅니다. 스위트는 코드와 똑같은 가정 위에 세워져 있으니까요.

캘린더에 넣으세요. 2주에 한 번, 또는 가입이나 청구를 건드리는 릴리스마다. 첫 실행은 거의 언제나 아무도 눈치채지 못한 무언가를 끄집어내고, 월요일 아침의 그 문의는 더 이상 당신에게 일어나는 일이 아니게 됩니다. 새 일회용 이메일을 받아서 그 경로를 걸어 보세요.