iOS 웹뷰에서 결제 후 리다이렉트 문제 해결하기 - 도메인 불일치 사례

개요

2024년 9월의 어느 평화로운 오후, 우리 팀은 갑작스러운 장애 보고로 인해 긴장 상태에 돌입했다.

"iOS에서 결제 완료 후 로그인 페이지로 리다이렉트됩니다."

이 간단한 문장이 앞으로 5시간 동안 우리를 휘몰아칠 디버깅 여정의 시작이었다.

문제 정의

이 버그는 별별 사람들이 달라붙어 고민해도 원인을 예측하기 힘들었다.
개발 및 스테이징 환경에서는 재현되지 않고, 오직 프로덕션 환경의 iOS 기기에서만 발생했다.
안드로이드, 웹, 데스크톱 브라우저에서는 정상 작동하는 반면, iOS 웹뷰에서만 세션이 유지되지 않는 독특한 양상을 보였다.

디버깅 프로세스: 데이터 기반 접근

우리는 나름대로 체계적인 접근 방식을 채택했다:

1. 로그 분석: 서버 사이드와 클라이언트 사이드 로그를 심층 분석했다. 특히 iOS 사용자의 요청-응답 사이클에 주목했다.
2. 네트워크 트래픽 모니터링: Charles Proxy를 사용하여 iOS 기기와 서버 간의 HTTP/HTTPS 통신을 자세히 관찰했다.
3. 세션 관리 메커니즘 검토: 우리의 세션 관리 로직, 특히 쿠키 설정과 관련된 부분을 재검토했다.
4. 브라우저 개발자 도구 활용: Safari의 Web Inspector를 통해 웹뷰 내부의 JavaScript 실행과 DOM 변화를 추적했다.

돌파구: URL 구조의 미묘한 차이

벌써 시간은 11시. 집중력이 박살나서 테트리스나 하고 있던 시점에, 우리는 결정적인 단서를 발견했다.
iOS 웹뷰에서 'www.도메인.com'과 '도메인.com'이 서로 다른 출처(origin)로 취급되고 있었던 것이다. 이는 Same-Origin Policy의 엄격한 적용으로 인한 것으로, 결과적으로 세션 쿠키가 공유되지 않는 문제를 야기했다.

해결책: URL 정규화 및 리다이렉트 최적화

문제의 근본 원인을 파악한 후, 우리는 다음과 같은 해결책을 구현했다:

1. URL 정규화: 모든 내부 링크와 리다이렉트에서 일관된 도메인 형식을 사용하도록 수정했다.
2. 서버 측 리다이렉트: nginx 설정을 조정하여 'www' 서브도메인과 루트 도메인 간의 자동 리다이렉트를 구현했다.
3. 웹뷰 설정 최적화: WKWebViewConfiguration을 조정하여 쿠키 정책을 보다 유연하게 관리했다.

let configuration = WKWebViewConfiguration()
configuration.websiteDataStore = WKWebsiteDataStore.default()
configuration.processPool = WKProcessPool()
let webView = WKWebView(frame: .zero, configuration: configuration)

교훈

이번 사건은 몇 가지 중요한 교훈을 남겼다:

1. 크로스 브라우징 테스트의 중요성: 특히 모바일 웹뷰 환경에서의 철저한 테스트가 필요하다.
2. URL 구조의 일관성: 도메인 사용의 일관성이 웹 애플리케이션의 안정성에 큰 영향을 미칠 수 있다.
3. 세션 관리의 복잡성: 특히 하이브리드 앱 환경에서 세션 관리는 세심한 주의가 필요하다.

결론

이 사례는 현대 웹 개발의 복잡성을 여실히 보여준다.
표면적으로 단순해 보이는 문제도 때로는 깊은 기술적 이해와 창의적 문제 해결 능력, 그리고 운과 경험을 요구한다.
이번 경험을 통해 기술적으로 성장했을 뿐만 아니라, 협업과 끈기의 가치를 재확인한 것 같다.

앞으로 "또 다른 iOS의 미스터리"를 기대하며, 웹과 네이티브의 경계에서 벌어지는 흥미진진한 기술적 도전을 즐겨보겠다.
iOS 웹뷰에서 JS 브릿지를 통해 네이티브 내비게이션을 직접 제어하는 방법은 [[KnowledgeBase/Blog/Web - App 브릿지 활용을 통한 네이티브 내비게이션 구현]]에서 다룬다.