결제 인증 화면 일관성 개선과 인증 방식 현대화

결제 플랫폼의 계정 검증 단계를 손봤다. 디자인 시스템 통일과 인증 수단 전환이 함께 들어간 작업이었는데, 이 과정에서 여러 고민이 있었다.

변경의 범위

한 커밋에 UI 개선과 기능 전환이 함께 들어간 것을 처음엔 "이게 한 번에 가면 되나?" 싶었지만, 이 두 작업이 사실 분리가 어렵다는 걸 깨달았다. 인증 방식이 바뀌면 UX도 따라 변해야 하고, 그러려면 일관된 디자인 언어가 필수였거든.

왜 두 가지를 함께 처리했나

처음 계획할 때는 분리하려고 했다. UI 개선은 UI 개선대로, 인증 방식 전환은 별개로. 하지만 실제로 코드를 봤을 때:

• 기존 인증 화면(JSP)이 여러 곳에서 불일치하는 스타일로 작성되어 있었음
• 새로운 jeju 인증 방식을 적용하면서 화면 레이아웃도 조정이 필요했음
• 이 과정에 tt.css(내부 디자인 시스템)을 적용하는 게 가장 자연스러웠음

결국 선택지는:
1. 분리하기 — UI와 기능을 별도 커밋으로, 하지만 같은 파일을 여러 번 건드려야 함 (불필요한 충돌 위험)
2. 함께하기 — 한 번에 정리하되, 변경의도를 명확히 하기

두 번째를 선택했고, 커밋 메시지에 각각을 명시했다. 덕분에 리뷰어가 "아, UI도 고치고 인증도 전환하는 구나"를 한눈에 알 수 있었다.

기술적 고민 — 인증 방식 전환

1원인증이라는 게 단순해 보이지만, 백엔드에서는 꽤 신경 쓸 부분이 많다:

• 기존 인증 방식과의 호환성 — 기존 사용자들은 어떻게 하나? (마이그레이션 정책 필요)
• 실패 시나리오 처리 — 인증 결과 타이밍, 재시도 정책, 타임아웃
• 테스트 커버리지 — 1원 결제가 실제로 차감되는지, 환불되는지 등

자바 클래스에서 이런 로직을 어디에 위치시킬지도 중요했다. 기존 내부 클래스 구조에 맞춰 jeju 인증 로직을 추가했을 텐데, 이게 결제 흐름과 명확하게 분리되어야 한다. 한 번 섞이면 나중에 다시 떼기 어려우니까.

배운 점과 다음 팀을 위한 가이드

이런 조합 작업은 커밋 메시지가 생명이다. 나중에 git blame이나 히스토리를 볼 때:
- "이 줄이 UI 개선 때문인가, 인증 전환 때문인가?"를 구분해야 함
- 리뷰 때 "UI 스타일은 OK, 근데 인증 로직 부분에서…" 이렇게 분리해서 봐야 함

그래서 이번엔 메시지에 두 가지를 명시하고, 실제 코드에서도:
- JSP는 UI/스타일 변화가 명확하게
- 자바 클래스는 인증 로직 변화가 명확하게

분리해서 작성했다. 함께 변경되지만 관심사는 분리된 느낌으로.

결제 시스템은 한 번 배포되면 되돌리기 어렵다. 이번 작업도 테스트/스테이징을 여러 번 거쳤고, 팀 내 인수 인계도 꼼꼼히 했다. UI는 눈으로 보면 확인되지만, 인증 방식이 제대로 작동하는지는 로그와 모니터링으로만 알 수 있으니까.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.