Playwright 세션 저장으로 반복 로그인 없이 테스트 속도 높이는 방법

Playwright에서 매번 로그인을 반복하지 않으려면 browserContext.storageState() 메서드를 사용해 쿠키와 로컬 스토리지 정보를 JSON 파일로 저장한 뒤, 새로운 컨텍스트를 생성할 때 이를 불러오면 됩니다.

자동화 테스트를 구축하다 보면 가장 먼저 마주치는 난관이 바로 로그인 과정입니다. 모든 테스트 케이스마다 아이디와 비밀번호를 입력하고 메인 페이지로 진입하는 과정을 넣으면 전체 실행 시간이 기하급수적으로 늘어날 뿐만 아니라, 테스트 계정이 보안 정책에 의해 차단될 위험도 커집니다.

이러한 비효율을 해결하기 위해 Playwright는 브라우저의 '상태'를 그대로 캡처하는 기능을 제공합니다. 한 번 로그인에 성공한 상태를 파일로 구워두고, 이후의 모든 테스트는 그 시점부터 바로 시작하게 만드는 원리입니다.

브라우저 자동화의 전반적인 흐름을 이해하고 있다면, 이제는 개별 페이지 조작을 넘어 '상태 관리'라는 상위 개념으로 넘어가야 할 때입니다. 효율적인 E2E 테스트 환경 구축을 위해 세션 저장 기능을 어떻게 실무에 녹여낼 수 있는지 구체적으로 살펴보겠습니다.

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

핵심 내용 먼저 보기

핵심 키워드 Playwright 세션 저장 · 연관 검색어 Playwright 세션 저장, storageState 사용법, Playwright 로그인 유지, 브라우저 자동화 인증, E2E 테스트 최적화

인증 상태를 파일로 추출하는 storageState의 원리

Playwright는 기본적으로 'Incognito(시크릿 모드)'와 유사한 깨끗한 브라우저 컨텍스트에서 시작합니다. 하지만 storageState 기능을 사용하면 현재 브라우저에 쌓인 쿠키(Cookies)와 로컬 스토리지(Local Storage) 데이터를 통째로 추출해 로컬 파일 시스템에 저장할 수 있습니다.

로그인 과정을 수행하는 별도의 스크립트를 작성한 뒤, 성공 직후에 await context.storageState({ path: 'state.json' }); 코드를 실행하면 프로젝트 루트에 인증 정보가 담긴 JSON 파일이 생성됩니다. 이 파일에는 세션 토큰이나 사용자 설정값 등이 포함되어 있어, 브라우저를 새로 열어도 로그인된 상태를 그대로 재현할 수 있게 해줍니다.

저장된 세션을 불러와 테스트에 적용하는 실무 패턴

저장된 세션을 사용하는 방법은 크게 두 가지입니다. 개별 테스트 코드에서 browser.newContext({ storageState: 'state.json' })를 호출하여 특정 세션을 주입하거나, playwright.config.ts 설정 파일에서 전역적으로 적용하는 방식입니다.

실무에서는 보통 전역 설정을 선호합니다. 설정 파일의 use 객체 안에 storageState: 'state.json'을 명시하면, 모든 테스트 파일이 시작될 때 자동으로 해당 파일을 읽어 로그인된 상태로 브라우저를 띄웁니다. 만약 관리자 계정과 일반 사용자 계정을 번갈아 가며 테스트해야 한다면, 프로젝트(projects) 설정을 나누어 각각 다른 세션 파일을 바라보게 구성하는 것이 효율적입니다.

보안과 협업을 위해 반드시 체크해야 할 주의점

세션 저장 기능을 사용할 때 가장 흔히 저지르는 실수는 생성된 JSON 파일을 Git 저장소에 그대로 올리는 것입니다. 이 파일에는 실제 서비스에 접근 가능한 유효한 세션 토큰이 포함되어 있으므로, 반드시 .gitignore에 추가하여 외부 유출을 막아야 합니다.

또한, 세션 파일은 영구적이지 않습니다. 서버 측에서 세션 만료 시간을 짧게 설정했거나 토큰이 갱신(Refresh)되는 구조라면, 저장된 파일이 있어도 로그인이 풀린 상태로 접속될 수 있습니다. 따라서 테스트 실행 전 세션 파일의 유효성을 체크하고, 만료되었다면 자동으로 로그인을 다시 수행하여 파일을 갱신하는 'Setup' 단계를 구성하는 것이 운영 측면에서 훨씬 안정적입니다.

세션 재사용이 실패하는 상황과 판단 포인트

모든 사이트가 단순히 쿠키와 로컬 스토리지 저장만으로 세션 유지가 되는 것은 아닙니다. 예를 들어, 보안이 강력한 금융 사이트나 특정 브라우저 핑거프린트를 대조하는 사이트에서는 세션 파일을 불러와도 추가 인증을 요구할 수 있습니다. 이때는 세션 저장 방식이 잘못된 것이 아니라, 해당 사이트의 인증 메커니즘을 분석해야 합니다.

만약 특정 테스트에서만 로그아웃 기능을 테스트해야 한다면, 해당 테스트 케이스에서만 storageState를 무시하도록 설정해야 합니다. 모든 테스트가 세션을 공유하면 한 테스트에서의 로그아웃이 다음 테스트의 실패로 이어지는 연쇄 반응이 일어날 수 있기 때문입니다. 각 테스트의 독립성을 유지하면서도 공통된 인증 상태를 활용하는 균형 감각이 필요합니다.

Playwright의 세션 저장 기능을 마스터하면 테스트 실행 시간을 절반 이하로 줄일 수 있습니다. 이는 단순히 빠른 피드백을 넘어, CI/CD 파이프라인의 비용 절감과 직결되는 중요한 최적화 요소입니다.

인증 상태 관리는 E2E 테스트 자동화의 기초 체력과 같습니다. 이 글에서 다룬 내용을 바탕으로 프로젝트의 로그인 구조를 점검해 보시고, 세션 만료 대응 로직까지 추가한다면 훨씬 견고한 자동화 환경을 만드실 수 있을 것입니다.

더 나아가 브라우저 자동화의 안정성을 높이고 싶다면, 요소 선택자(Selector) 최적화 전략이나 네트워크 가로채기(Network Interception)를 통한 데이터 모킹 방법도 함께 살펴보는 것을 추천합니다.

자주 묻는 질문

세션 저장 파일(JSON)에 로컬 스토리지 정보도 포함되나요?

네, Playwright의 storageState()는 쿠키뿐만 아니라 로컬 스토리지(Local Storage) 데이터도 함께 캡처하여 저장합니다. 따라서 로컬 스토리지를 기반으로 인증을 관리하는 최신 웹 앱에서도 문제없이 작동합니다.

세션이 만료되면 어떻게 자동으로 갱신하나요?

Playwright의 'Global Setup' 기능을 활용하면 좋습니다. 테스트 시작 전 특정 스크립트를 실행해 세션 파일의 존재 여부나 유효성을 확인하고, 필요 시 로그인을 수행하여 파일을 새로 고치는 로직을 구현할 수 있습니다.

여러 계정의 세션을 동시에 관리할 수 있나요?

가능합니다. 계정별로 다른 파일명(예: admin.json, user.json)으로 저장한 뒤, 테스트 코드의 context 생성 시점에 필요한 파일을 선택적으로 로드하거나 playwright.config.ts의 projects 설정을 통해 분리하여 관리하면 됩니다.

---

해시태그

#Playwright세션저장 #storageState사용법 #Playwright로그인유지 #브라우저자동화인증 #E2E테스트최적화 #Playwright쿠키저장