인증 코드를 사람이 읽어 옮겨 적는 단계가 남아 있는 한, 그 시험은 자동화가 아닙니다. 임시 메일과 테스트 수신함을 이용하면 그 단계를 코드가 대신하게 만들 수 있습니다. 대신 시간 초과와 이전 편지 간섭이라는 두 가지 함정이 늘 따라붙습니다.
테스트용 메일함에서 코드를 읽어 내는 순서
순서는 단순합니다. 시험용 주소로 가입을 요청하고, 그 주소의 편지함에서 가장 최근 편지를 찾고, 본문에서 코드로 보이는 숫자 묶음을 뽑아 입력 칸에 넣습니다.
어려운 부분은 각 단계의 실패를 구분하는 일입니다. 편지가 아직 오지 않은 것과, 왔지만 코드가 없는 것과, 코드가 있지만 형식이 다른 것은 원인이 각각 다릅니다. 셋을 한 덩어리로 처리하면 실패 로그에 아무 정보도 남지 않습니다.
편지를 고를 때는 목록의 첫 번째를 그냥 집지 마세요. 발신자와 제목처럼 미리 아는 값으로 거르고, 그 조건에 맞는 편지가 여러 통이면 가장 최근 것을 씁니다. 순서를 도착 시각에만 기대면 시계 차이 때문에 뒤집히는 일이 생깁니다.
시간 초과와 이전 편지 간섭은 왜 생기나요?
시간 초과는 대개 정상적인 지연입니다. 편지 배달은 즉시 끝나지 않고, 보내는 쪽 대기열이 밀리면 몇 분이 걸립니다. 그래서 한 번 확인하고 없다고 결론 내리면 안 되고, 일정 간격으로 다시 확인하되 횟수에 상한을 두어야 합니다.
이전 편지 간섭은 시험 쪽 설계 문제인 경우가 많습니다. 같은 주소를 여러 시험이 함께 쓰면 앞선 시험이 남긴 코드가 뒤 시험에 읽힙니다. 앞선 코드로 인증을 시도하면 실패하거나, 더 나쁘게는 이미 인증된 상태를 다시 인증하려다 엉뚱한 결과가 나옵니다.
재발송도 함정입니다. 코드가 오지 않아 재발송을 요청하면 편지가 두 통이 됩니다. 두 통 중 어느 것을 읽어도 통과해야 정상이고, 먼저 온 코드만 유효한 구현이라면 뒤에 온 편지를 읽은 시험이 실패합니다.
여기에 시계 문제가 겹칩니다. 시험을 돌리는 컴퓨터와 편지를 보내는 서버의 시각이 조금만 달라도, 방금 도착한 편지가 목록의 맨 아래에 놓일 수 있습니다. 도착 시각만으로 편지를 고르는 규칙은 이 차이에 그대로 흔들립니다. 시각은 참고로만 쓰고, 최종 선택은 발신자와 제목 같은 값으로 하는 편이 안전합니다.
편지 하나에 코드가 여러 개 들어 있는 경우도 있습니다. 본문 위쪽의 큰 숫자와 아래쪽의 작은 숫자가 서로 다른 뜻일 때, 규칙이 엉뚱한 쪽을 집으면 시험은 이유 없이 실패합니다. 여러 후보를 찾았을 때 어느 것을 쓸지 정해 두지 않으면, 같은 편지로도 실행마다 결과가 달라집니다.
자동화와 사람의 몫을 어떻게 나누나요?
자동화가 잘하는 일은 반복과 대량 처리입니다. 같은 시나리오를 여러 언어와 여러 지역 설정으로 돌리는 일, 매번 같은 순서로 코드를 읽어 넣는 일은 코드에 맡기는 편이 낫습니다.
코드를 넣는 단계에서도 시험할 것이 남아 있습니다. 만료된 코드를 넣었을 때, 이미 쓴 코드를 다시 넣었을 때, 자릿수가 모자란 값을 넣었을 때 각각 다른 안내가 나와야 합니다. 세 경우를 모두 같은 오류로 처리하면 이용자는 무엇을 고쳐야 하는지 알 수 없습니다. 시험은 통과와 실패 양쪽을 모두 확인해야 의미가 있습니다.
사람이 남아야 하는 자리도 있습니다. 차단 화면이 나왔을 때, 코드가 예상과 다른 형식으로 왔을 때, 재발송 제한에 걸렸을 때는 자동화가 스스로 판단하기 어렵습니다. 이런 경우에는 시험을 실패로 끝내고 원본 편지를 남겨 사람이 보게 하는 편이, 억지로 통과시키는 것보다 훨씬 낫습니다.
재발송 제한을 시험에서 꺼 버리는 것도 피해야 합니다. 제한이 없는 환경에서 통과한 시험은 실제 환경에서 처음 만나는 제한을 견디지 못합니다.
우리 도구에서 코드를 확인하는 방법
임시 메일에서는 편지가 도착하면 본문에서 코드로 보이는 부분을 따로 뽑아 보여 줍니다. 접두사를 시험 이름으로 정해 두면 어느 시나리오의 편지인지 목록에서 바로 구분됩니다. 자동화가 읽어 낼 값을 정하기 전에, 사람이 먼저 실제 형식을 확인하는 단계로 쓰기 좋습니다.
여기서 받는 편지와 주소는 테스트 전용이며 실제 사람의 신원을 증명하지 못합니다. 실제 계정의 인증에는 쓰지 마세요.
국가와 언어 설정도 함께 확인합니다
코드의 자릿수와 생김새는 서비스마다 다르고, 지역 설정에 따라 안내 문구도 달라집니다. 국가별 주소 형식에서 다루듯 주소 표기 규칙이 지역마다 다르므로, 여러 지역을 대상으로 한다면 지역마다 한 번씩 같은 시나리오를 돌려 보세요. 언어 설정에 따라 숫자 사이에 구분 기호가 들어가거나 문자와 섞여 오는 경우도 있으므로, 코드를 읽는 규칙은 넉넉하게 잡는 편이 안전합니다.
개발자를 위한 메모: 읽기 규칙과 재시도 상한
- 코드를 뽑는 규칙은 본문 전체를 훑되, 가장 최근 편지에만 적용합니다. 오래된 편지까지 함께 훑으면 지난 코드를 집습니다.
- 숫자만 찾지 말고 앞뒤 문맥을 함께 봅니다. 주문 번호나 금액처럼 코드가 아닌 숫자가 본문에 섞여 있으면 엉뚱한 값을 집습니다.
- 확인 간격과 총 대기 시간을 각각 상한으로 둡니다. 상한이 없으면 실패한 시험이 끝나지 않고, 상한이 너무 짧으면 정상 지연을 실패로 만듭니다.
- 같은 조건으로 다시 확인하는 편이 조건을 바꿔 가며 확인하는 것보다 낫습니다. 조건이 바뀌면 무엇을 기다렸는지 알 수 없습니다.
- 코드 형식이 바뀌면 시험이 먼저 실패하게 만들어 둡니다. 조용히 다른 값을 집어 통과하는 것이 가장 나쁜 결과입니다.
- 실패할 때 원본 편지를 남깁니다. 남긴 편지는 다음에 형식을 고칠 때 가장 좋은 자료가 됩니다. 확인 메일 자체의 흐름은 인증 흐름 테스트에서 이어집니다.
다음 단계
자동화하려는 시나리오가 있다면 먼저 임시 메일에서 같은 흐름을 손으로 한 번 돌려 보세요. 실제로 도착하는 편지의 제목과 본문 형식을 눈으로 확인한 뒤에 읽기 규칙을 정하면, 나중에 형식이 바뀌었을 때 어디를 고쳐야 하는지도 분명해집니다. 그다음에는 재발송을 한 번 섞어 두어 두 통이 와도 시험이 흔들리지 않는지 확인해 보시길 권합니다.