Playwright 도입에서 실패한 이야기 7선｜QA 엔지니어의 실무 실패담과 대책 해설

Playwright로 E2E 테스트 자동화를 도입한 QA 엔지니어가 실제로 경험한 「실패담」을 7선으로 해설합니다. auto-waiting 과신·언어 선택 실수·CI 환경 차이·팀 도입 저항 등, Playwright 고유의 함정과 대책을 실무 경험을 바탕으로 소개합니다.

「Playwright로 갈아타면 해결된다」——그 착각이 다음 실패의 시작이었습니다. 도구를 바꿔도 사용법을 틀리면 결과는 같습니다.

「Selenium에서 Flaky 지옥에 빠졌으니 Playwright로 갈아타자」——2년 전의 판단은 반은 맞고, 반은 틀렸습니다.

Playwright 자체는 확실히 뛰어난 도구입니다. 하지만 「갈아타면 만사해결」이라는 착각으로 진행했기 때문에, Playwright 고유의 새로운 실패를 양산했습니다. 이 기사에서는 그 체험담을 7가지로 정리하여 가감 없이 공유합니다.

Playwright 도입에서 실패한 이야기 7선이란？조견표

① 「Playwright로 갈아타면 만사해결」이라는 과신이란？

무슨 일이 일어났나

Selenium에서 Flaky 테스트가 늘어 한계를 느꼈을 때, 「Playwright는 auto-waiting이 있으니 Flaky가 해소된다」「모던한 API로 유지보수하기 쉽다」는 평판을 믿고, 기존 200건의 Selenium 테스트를 전부 Playwright로 재작성하는 프로젝트를 시작했습니다. 결과는 Flaky가 줄었지만 제로는 되지 않았습니다. 그리고 재작성에 3개월을 쏟은 공수는 테스트 설계 개선에는 사용되지 않았습니다.

Playwright로 개선되는 Flaky와 개선되지 않는 Flaky의 차이

② auto-waiting을 과신하여 타임아웃 투성이가 됐다란？

무슨 일이 일어났나

「Playwright는 auto-waiting이 있으니 명시적인 대기 처리는 불필요」——이 이해로 작성하기 시작한 테스트는, 얼마 후 알 수 없는 타임아웃 에러를 양산하기 시작했습니다.

# ❌ auto-waiting에 너무 의존한 작성법
# locator.click()은 actionability check를 실행하지만,
# 비동기 상태 변화나 커스텀 UI 컴포넌트에서는 명시적 대기가 필요한 경우가 있다
page.locator("#submit-btn").click()
# ↑ 비동기로 disabled→enabled 로 바뀌는 버튼은
#   변화 타이밍에 따라 타임아웃이 될 수 있다

# ✅ 현대적인 Locator API + expect()로 의도를 명시한다
from playwright.sync_api import expect
expect(page.locator("#submit-btn")).to_be_enabled()
page.locator("#submit-btn").click()

③ TypeScript로 시작했더니 팀 아무도 유지보수할 수 없게 됐다란？

무슨 일이 일어났나

「Playwright는 TypeScript/Node.js 버전의 샘플·문서량이 가장 풍부」「타입이 있는 편이 유지보수하기 쉽다」는 이유로 TypeScript를 선택했습니다. 나는 JavaScript 경험이 있어서 작성할 수 있었지만, 팀의 다른 멤버들은 Python 엔지니어뿐. 반년 후에는 테스트 코드 리뷰어가 나 혼자가 되어, 사실상의 특정인 의존이 완성됐습니다.

④ page.route()로 목업했다고 생각했는데 실제 API를 호출하고 있었다란？

무슨 일이 일어났나

page.route()로 API를 목업했는데, 왜인지 테스트 결과가 실제 본번 데이터에 의존하고 있었습니다. 조사해 보니, 테스트 대상 API가 JavaScript（브라우저）경유가 아니라 서버 사이드 렌더링（SSR）으로 직접 호출되고 있던 케이스였습니다.

# page.route() 는 브라우저의 HTTP 통신만을 인터셉트
await page.route("**/api/users", lambda route: route.fulfill(
    status=200,
    body='{"users": []}'
))
# ↑ SSR이나 Next.js의 getServerSideProps 내에서의 fetch는 가로챌 수 없다
# ↑ Playwright API Testing（request fixture）의 HTTP 통신도 가로챌 수 없다

⑤ CI 환경에서 브라우저가 실행되지 않는 문제를 방치했다란？

무슨 일이 일어났나

로컬에서는 완벽하게 동작하는데, GitHub Actions에 올리면 「브라우저가 실행되지 않는다」「의존 라이브러리가 부족하다」는 에러가 속출했습니다. 원인은 알고 있었지만 미루다 보니, 「로컬에서 실행하여 수동으로 CI에 결과를 보고하는」 본말전도 운용을 2주 동안 계속해버렸습니다.

CI 환경에서 자주 발생하는 Playwright 실행 에러

⑥ 버전 업데이트로 한꺼번에 30개 테스트가 실패했다란？

무슨 일이 일어났나

pip install playwright --upgrade로 버전을 올렸더니, 다음날 CI에서 30건의 테스트가 한꺼번에 실패했습니다. 원인은 버전 간의 API 변경과 브라우저 바이너리의 버전 불일치입니다.

# ❌ 버전 고정 없음（업데이트할 때마다 깨질 위험）
playwright

# ✅ 버전을 고정（requirements.txt）
playwright==1.44.0

# 브라우저 바이너리도 반드시 재설치
# pip install playwright==1.44.0 후에 반드시 실행
# playwright install chromium

⑦ 「왜 Playwright인가」를 팀에 설명할 수 없었다란？

무슨 일이 일어났나

「Playwright가 더 좋으니까」라고 혼자 결정하고 팀에 전개하려 했을 때, 선배 엔지니어로부터 「왜 Selenium은 안 돼요？」라는 질문을 받고 제대로 대답할 수 없었습니다. 「왠지 모던한 느낌이라서」「소셜미디어에서 평판이 좋아서」——이것으로는 기술적인 의사결정으로는 너무 약합니다. 결과적으로 「일단 지금의 Selenium으로 계속하자」가 되어, 마이그레이션 프로젝트가 반년간 허공에 떠버렸습니다.

팀을 설득할 수 있는 「왜 Playwright인가」의 근거

FAQ

Playwright 자체는 정말 뛰어난 도구입니다. 이 기사에서 소개한 실패는 모두 「Playwright의 문제」가 아니라 「사용법·도입 계획·팀 설계」의 문제였습니다. 실패 패턴을 알고 시작하면, 같은 전철을 밟지 않아도 됩니다. 작게 시작하여, CI에 올려, 팀에서 사용할 수 있는 상태를 만든다——이 순서로 진행하는 것이 Playwright 도입을 성공시키는 가장 효율적인 방법입니다.