이메일 인증 테스트 로직을 운영 환경에 맞게 개선
목차
개발 환경에서만 돌아가는 코드를 오래 방치해두면 꼭 탈이 난다. 이번 작업이 딱 그런 케이스였음.
이메일 인증 로직에서 개발용 테스트 분기가 운영 코드와 뒤섞여 있었고, 환경 조건 체크가 제대로 안 붙어있어서 "개발에서만 통과되는" 케이스가 사실상 열려있는 상태였다. 당장 장애가 터지는 건 아니지만, 이런 구멍이 하나씩 쌓이면 나중에 인증 흐름 전체를 뜯어봐야 하는 상황이 온다.
뭘 바꿨나
변경은 백엔드 로직 파일 1개에 집중됐다. JSP나 쿼리 XML 쪽은 손 안 댔음. 이메일 인증 처리의 핵심 흐름이 담긴 파일 하나에서, 개발 테스트용으로 심어둔 분기 로직을 정리하고 운영 환경 조건을 명시적으로 추가하는 게 이번 작업의 전부였다.
구체적으로는 이런 부분들:
- 개발 환경에서 인증 코드를 고정값으로 통과시키던 분기 제거
- 운영/개발 환경을 구분하는 조건을 명시적으로 선언
- 중복으로 존재하던 인증 실패 처리 로직 공통화
- 에러 메시지 포맷 정리 (로그에서 원인 파악이 바로 되게)
- 불필요한 주석과 죽은 코드 제거
변경 범위가 한 파일이라도 영향 범위는 인증 전체 흐름이라서, 변경 전후 동작을 직접 타고 들어가서 확인했음.
환경 분기를 코드로 처리하는 패턴은 대략 이런 방식이다:
// Bad: 개발 조건이 암묵적으로 열려있음
if (verificationCode.equals(inputCode) || isDev) {
return true;
}
// Good: 환경 조건을 명시적으로 분리, 운영에선 절대 우회 불가
if (isProductionEnv()) {
return verificationCode.equals(inputCode);
}
// 개발 환경에서만 아래 분기 진입 가능
return verificationCode.equals(inputCode) || isDevBypassEnabled();
얼핏 보면 별 차이 없어 보이지만, 첫 번째 방식은 isDev 플래그가 잘못 설정되면 운영에서도 우회가 열릴 수 있다. 두 번째는 운영 환경 체크를 먼저 처리하고, 개발 분기는 명시적으로 그 아래 격리된다. 인증처럼 보안이 엮이는 로직일수록 이 차이가 크다.
이메일 인증에서 자주 빠뜨리는 엣지 케이스
이 작업 하면서 보강한 엣지 케이스 처리를 정리해두면 나중에 비슷한 작업할 때 참고가 됨.
| 케이스 | 처리 방식 |
|---|---|
| 인증 코드 만료 후 재요청 | 이전 코드 무효화 후 새 코드 발급, 만료 시간 명시 |
| 동일 이메일로 중복 요청 | 기존 코드 남은 TTL 확인 후 재발급 여부 결정 |
| 코드 입력 오타 반복 | 실패 횟수 제한, 초과 시 재발급 강제 |
| 인증 완료 후 코드 재사용 | 인증 완료 즉시 코드 무효화 플래그 처리 |
| 이메일 주소 대소문자 혼용 | 저장 전 normalize (lowercase) |
이 중 "인증 완료 후 코드 재사용" 케이스는 개발 중에 잘 안 잡힌다. 테스트할 때 코드를 재입력하는 경우가 드물기 때문인데, 운영에서 자동화 툴로 시도하면 잡힌다. 로직 단에서 완료 즉시 무효화 처리를 해두는 게 맞다.
에러 메시지도 이번에 다듬었는데, 이게 생각보다 중요하다. 개발 중엔 "인증 실패"라고 퉁쳐도 스택 트레이스 보면 되지만, 새벽에 운영 로그 뒤질 때는 에러 메시지 자체가 단서가 된다. "인증 코드 불일치 (expired: true, attempts: 3)" 같은 식으로 컨텍스트가 담겨있으면 원인 파악 시간이 확 줄어든다.
작업 회고
티 안 나는 작업이다. 기능이 추가된 것도 아니고 화면이 바뀐 것도 아니다. 그냥 코드가 좀 더 단단해진 것뿐.
그런데 이런 작업들이 쌓이는 게 맞다고 생각한다. 인증 흐름처럼 건드리기 조심스러운 영역일수록, 개발 편의를 위해 심어둔 임시 코드가 장기 부채가 된다. 임시라고 쓰고 영구라고 읽는 게 개발 현실이니까.
코드를 다듬을 때 내가 기준으로 삼는 건 세 가지다. 6개월 후에 내가 이 코드를 다시 봤을 때 바로 읽히는가, 나 말고 다른 사람이 봤을 때 의도가 명확한가, 새벽 장애 상황에서 이 코드가 문제를 빨리 찾게 해주는가. 이번 변경은 세 가지 기준을 다 충족했다고 생각한다.
작은 커밋, 변경 전후 동작 직접 확인, 배포 후 로그 모니터링. 별거 아닌 것 같지만 이걸 습관으로 유지하는 게 결국 시스템을 오래 건강하게 굴리는 방법이다.
댓글 0
첫 댓글 달아줘.