인프런 커뮤니티 질문&답변
LHCI에서 OAuth 로그인 페이지 성능 측정은 어떻게 처리하시나요?
작성
·
64
0
안녕하세요! 현재 LHCI를 도입하여 PR 단계에서 성능을 측정하려고 설정 중인데, 인증 구조 때문에 고민이 있어 조언을 구하고 싶습니다.
제 서비스의 인증 구조는 다음과 같습니다.
- Google OAuth 로그인
- Access Token: Memory 저장
- Refresh Token: HTTP-only Cookie 저장
- RTR(Refresh Token Rotation) 적용
로그인이 필요한 페이지도 Lighthouse로 측정하고 싶어서 Puppeteer를 활용한 로그인 상태 생성을 시도하고 있습니다. 다만 Google OAuth 과정을 Puppeteer로 자동화하는 것은 현실적으로 어렵다고 판단하여 토큰을 주입하는 방식을 고려했습니다.
Access Token 주입하는 것은 메모리 기반이라 번들에 포함될 가능성이 있어 우려되어 Refresh Token 주입을 page.setCookie로 시도하였습니다. 하나의 URL은 잘 측정되었지만, 여러 URL을 측정하는 과정에서 PTR로 Refresh Token이 갱신되면서 인증이 풀리는 문제가 발생했습니다.
테스트용 로그인 API를 새로 만드는 것이 좋을지.. 이런 상황에서 LHCI로 로그인된 페이지를 안정적으로 측정하려면 어떤 접근 방식이 일반적으로 사용되는지 궁금합니다. 혹시 관련 경험이나 추천 방식이 있다면 조언 부탁드립니다 ㅠㅠ!!
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
지우개님께서 문의하신 사항은 OAuth 인증 구조에서 Lighthouse CI(LHCI)와 Puppeteer를 이용한 성능 측정에 관련된 문제로 보입니다. 이와 같은 경우에 효과적인 접근 방식 몇 가지를 제안드리겠습니다.
테스트 전용 로그인 API 생성: 테스트 환경에서만 사용할 수 있는 로그인 API를 만들어서 Puppeteer가 로그인 토큰을 쉽게 얻을 수 있도록 하는 방법입니다. 실제 프로덕션 계정 정보를 사용하지 않으므로 안전하게 테스트할 수 있습니다.
스태틱 토큰 사용: 테스트 환경에 한정하여 스태틱한 애플리케이션 데이터(Access Token, Refresh Token)를 설정해놓는 방법입니다. 갱신이 일어나지 않도록 토큰의 유효기간을 충분히 길게 설정하여 갱신 문제를 피할 수 있습니다.
Puppeteer에 의한 수동 로그인 시나리오: Puppeteer로 Google OAuth 로그인 화면까지의 흐름을 자동화하고, 이 과정에서 페이지 로컬스토리지나 세션스토리지에 출입토큰을 저장하게끔 시뮬레이션할 수 있습니다.
애플리케이션의 백엔드 우회: 백엔드에서 직접 쿠키를 세션 관리 없이 설정하는 인터페이스를 제공하여 Puppeteer가 쿠키를 직접 주입 가능케 하는 방법입니다. 이는 Refresh Token을 HTTP-only로 설정할 때 유용하다 할 수 있습니다.
위 방법들은 각자의 장단점이 있으며, 지우개님의 프로젝트 환경과 요구사항에 맞게 선택하시는 것이 가장 중요합니다.
추가로 도움이 될 이미지 URL이나 링크는 제공되지 않았으나, 인프런의 FAQ 페이지에서 관련된 문제 해결 자료를 참조하실 수 있습니다.
감사합니다! 도움이 되셨길 바랍니다.




