Playwright 세션 저장으로 매번 로그인하는 번거로움 해결하기: storageState 활용법

Playwright에서 반복되는 로그인 과정을 생략하려면 browserContext.storageState() 메서드를 사용하여 현재의 쿠키와 로컬 스토리지 상태를 JSON 파일로 저장한 뒤, 새로운 브라우저 컨텍스트를 생성할 때 이 파일을 불러오면 됩니다. 이 방법을 통해 테스트마다 로그인을 수행할 필요 없이 즉시 인증된 상태로 페이지를 열 수 있습니다.

웹 자동화나 테스트 스크립트를 작성할 때 가장 시간이 많이 소요되고 오류가 자주 발생하는 구간이 바로 로그인 단계입니다. 특히 MFA(다중 요소 인증)가 설정되어 있거나 봇 탐지 로직이 까다로운 사이트의 경우, 매번 로그인을 시도하는 것은 비효율적일 뿐만 아니라 계정 차단의 위험까지 초래할 수 있습니다.

많은 개발자가 단순히 쿠키만 복사하면 된다고 생각하지만, 현대의 웹 애플리케이션은 로컬 스토리지(LocalStorage)나 세션 스토리지에 중요한 인증 토큰을 저장하는 경우가 많습니다. Playwright의 세션 저장 기능은 이러한 모든 상태를 한 번에 캡처하여 파일 시스템에 저장하고 재사용할 수 있게 설계되었습니다.

이 글에서는 세션 상태를 파일로 추출하는 구체적인 방법부터, 실제 프로젝트에서 이를 어떻게 구조화하여 적용해야 하는지, 그리고 보안상 주의해야 할 점은 무엇인지 실무적인 관점에서 살펴보겠습니다.

Playwright 세션 저장 주제를 읽기 전에 먼저 보면 좋은 대표 이미지 · 핵심 포인트: 기본 개념, 세션 캡처, 재사용 방법

핵심 내용 먼저 보기

핵심 키워드 Playwright 세션 저장 · 연관 검색어 Playwright 세션 저장, Playwright storageState, Playwright 로그인 유지, 브라우저 컨텍스트 재사용, 웹 자동화 로그인 생략

세션 캡처: 로그인 상태를 JSON 파일로 기록하기

세션을 저장하는 첫 번째 단계는 정상적인 로그인 과정을 한 번 수행한 뒤, 그 시점의 브라우저 상태를 스냅샷으로 찍는 것입니다. Playwright는 context.storageState({ path: 'state.json' }) 코드를 통해 이 작업을 수행합니다. 이때 지정한 경로에 쿠키와 로컬 스토리지 데이터가 포함된 JSON 파일이 생성됩니다.

실무에서는 보통 'Global Setup' 단계에서 이 작업을 처리합니다. 예를 들어, 테스트가 시작되기 전 별도의 스크립트를 실행하여 로그인을 완료하고 auth.json 같은 이름으로 상태를 저장해두는 방식입니다. 이렇게 하면 이후 실행되는 수십, 수백 개의 테스트 케이스는 로그인 과정 없이 이 파일만 읽어서 바로 본론으로 들어갈 수 있습니다.

저장된 세션 재사용과 컨텍스트 주입

저장된 세션을 사용하는 방법은 매우 간단합니다. 새로운 브라우저 컨텍스트를 생성할 때 storageState 옵션에 저장해둔 파일 경로를 전달하기만 하면 됩니다. browser.newContext({ storageState: 'state.json' })와 같이 작성하면, 브라우저가 뜨는 순간 이미 해당 사이트에 로그인된 상태가 됩니다.

여기서 주의할 점은 세션 파일이 존재하는지 먼저 확인하는 로직을 추가하는 것입니다. 파일이 없는데 불러오려고 하면 에러가 발생하므로, 파일 존재 여부에 따라 로그인을 새로 할지 아니면 기존 세션을 쓸지 결정하는 조건문을 구성하는 것이 운영상 안전합니다. 또한, 여러 계정을 테스트해야 한다면 계정별로 별도의 JSON 파일을 만들어 관리하는 것이 효율적입니다.

실무에서 마주치는 세션 만료와 갱신 문제

세션 저장 기능을 사용할 때 가장 흔히 하는 실수는 '한 번 저장하면 영원히 쓸 수 있다'고 생각하는 것입니다. 서버 측에서 세션 토큰을 만료시키면 로컬에 저장된 JSON 파일은 무용지물이 됩니다. 따라서 스크립트 실행 중 인증 에러(401 Unauthorized 등)가 발생하면 세션 파일을 삭제하고 다시 로그인하여 갱신하는 로직이 필요합니다.

또한, 특정 사이트는 IP 주소나 브라우저 지문(Fingerprint)이 달라지면 기존 세션을 무효화하기도 합니다. 로컬 환경에서 생성한 세션 파일을 CI/CD 서버(GitHub Actions 등)로 옮겼을 때 작동하지 않는다면 이러한 보안 정책을 의심해봐야 합니다. 이럴 때는 CI 환경 내에서 직접 세션 생성 스크립트를 먼저 돌리는 것이 가장 확실한 해결책입니다.

보안 관리: 세션 파일의 취급 주의사항

저장된 JSON 파일에는 실제 사용자의 로그인 세션 토큰이 평문으로 포함되어 있습니다. 만약 이 파일이 외부로 유출된다면 누구나 해당 계정으로 접속할 수 있는 심각한 보안 사고로 이어집니다. 따라서 .gitignore 파일에 세션 데이터 파일(예: *.json)을 반드시 추가하여 공용 저장소에 업로드되지 않도록 해야 합니다.

민감한 정보를 다루는 프로젝트라면 세션 파일을 로컬 디스크가 아닌 메모리 내에서 처리하거나, 암호화된 저장소를 활용하는 방안을 검토해야 합니다. 단순히 자동화의 편의성만 생각하다가 보안을 놓치지 않도록, 세션 파일의 생성 주기와 삭제 시점을 명확히 관리하는 것이 중요합니다.

Playwright의 세션 저장 기능을 제대로 활용하면 전체 테스트 수행 시간을 획기적으로 단축할 수 있습니다. 특히 복잡한 로그인 과정을 거쳐야 하는 엔터프라이즈 애플리케이션 자동화에서 그 효과는 더욱 극대화됩니다.

다만 세션은 살아있는 데이터라는 점을 잊지 마세요. 서버의 정책 변화나 토큰 만료 시간에 맞춰 유연하게 갱신될 수 있도록 코드를 설계하는 것이 실무자의 역량입니다. 보안 가이드라인을 준수하면서 효율적인 자동화 환경을 구축해 보시기 바랍니다.

이후에는 Playwright의 네트워크 인터셉트 기능을 활용해 API 응답을 모킹하거나, 다중 브라우저 환경에서의 병렬 테스트 최적화 방법을 살펴보는 것도 자동화 수준을 높이는 좋은 다음 단계가 될 것입니다.

자주 묻는 질문

로컬 스토리지 데이터도 함께 저장되나요?

네, Playwright의 storageState()는 쿠키뿐만 아니라 로컬 스토리지(LocalStorage)의 모든 데이터도 함께 JSON 파일로 캡처하여 저장합니다.

세션 파일이 유효한지 어떻게 확인하나요?

스크립트 시작 시 특정 보호된 페이지로 이동한 뒤, 로그인 페이지로 리다이렉트되는지 여부를 체크하여 세션 만료를 감지하고 필요 시 재로그인을 수행하도록 구현할 수 있습니다.

CI/CD 환경에서 세션 파일을 공유해도 되나요?

보안상 권장하지 않습니다. 가급적 CI 파이프라인 내에서 로그인 스크립트를 먼저 실행하여 해당 빌드에서만 사용할 임시 세션 파일을 생성하는 방식이 안전합니다.

---

해시태그

#Playwright세션저장 #PlaywrightstorageState #Playwright로그인유지 #브라우저컨텍스트재사용 #웹자동화로그인생략 #Playwright쿠키저장