임팩트: BrowserStack 실기 디바이스에서 네이티브 앱 웹뷰로 로컬 dev 서버를 접속할 수 있는 환경을 구축했습니다. DNS NXDOMAIN, SSL 인증서 불신뢰, 쿠키 도메인 불일치, ALB 접근 제어 4개 계층의 장벽을 순차적으로 진단하고, 프록시 body rewrite + cookie rewrite 솔루션으로 해결했습니다. 팀 전체가 사용할 수 있도록 wiki 가이드 문서화까지 완료했습니다.
면접 훅: 네이티브 앱 웹뷰에서 로컬 서버를 띄워야 하는데, DNS/SSL/쿠키/ALB 4겹으로 차단되는 상황에서 proxy body rewrite 방식으로 전부 우회한 경험입니다.
배경 (Situation)
BrowserStack App Live에서 네이티브 앱 웹뷰로 로컬 dev 서버를 띄워야 했으나, WKWebView는 커스텀 도메인 라우팅이 불가능하고 bs-local.com만 지원했습니다. JSP 로그인 페이지에는 절대 URL이 하드코딩되어 있었고, ALB에서는 커스텀 헤더와 IP 화이트리스트를 강제하고 있었습니다.
협업 규모는 솔로였으며, 환경 구축 후 팀에 공유하는 방식이었습니다. 문제 진단부터 솔루션 설계, wiki 문서화까지 전 과정을 주도했습니다.
- HTTPS 시도
- force-local
- 커스텀 도메인
- 4계층 분해
- proxy rewrite
문제 (Task)
네이티브 앱의 웹뷰에서 로컬 Vue dev 서버를 실기 디바이스에서 접속 가능하게 만들어야 했습니다. 4개 계층의 장벽이 순차적으로 존재했습니다: DNS(NXDOMAIN), SSL(인증서 불신뢰), 쿠키(도메인 불일치), ALB(접근 제어).
Layer 1 — DNS (NXDOMAIN)
WKWebView는 커스텀 도메인 라우팅 불가, bs-local.com만 지원. 해결: bs-local.com(HTTP)으로 접근 경로 변경.
Layer 2 — SSL (인증서 불신뢰)
자체 인증서를 WKWebView가 거부. 해결: HTTP로 전환하여 SSL 계층 자체를 우회.
Layer 3 — 쿠키 (도메인 불일치)
JSP 로그인이 emart.com 도메인 쿠키를 설정, bs-local.com에서 전달 불가. 해결: cookieDomainRewrite로 쿠키 도메인 재작성.
Layer 4 — ALB (접근 제어)
ALB가 커스텀 헤더 + IP 화이트리스트를 강제. 해결: proxy에서 emart-dev 헤더 자동 주입.
판단과 행동 (Action)
최초에는 HTTPS + force-local + 커스텀 도메인으로 접근했으나 3회 연속 실패했습니다. 이후 피봇하여 문제를 DNS/SSL/쿠키/ALB 4개 계층으로 분해하고 각각 진단하는 방식으로 전환했습니다.
최종 솔루션은 bs-local.com(HTTP) + proxy selfHandleResponse로 응답 body 내 절대 URL을 상대경로로 변환하고, cookieDomainRewrite로 쿠키 도메인을 재작성하며, emart-dev 헤더를 주입하는 구성이었습니다. Confluence wiki에 Mermaid 도식을 포함한 가이드를 작성하여 팀 전체가 사용 가능한 환경을 구성했습니다.
4중 장벽
DNS/SSL/쿠키/ALB
솔루션
proxy body rewrite
팀 공유
2커맨드로 재현 가능
결과 (Result)
팀원 누구나 npm run bs:local + npm run serve:dev 두 커맨드로 실기 네이티브 웹뷰 테스트가 가능해졌습니다. 네이티브 앱 환경에서의 프론트엔드 검증이 가능해져, 웹과 네이티브 브릿지 이슈를 배포 전에 발견할 수 있게 되었습니다.