Page Object Model이란? Playwright×Python으로 코드 유지보수성을 높이는 설계 패턴 입문

📌 이런 분께 추천합니다

• 테스트 자동화를 막 시작했는데 코드 정리 방법을 모르는 분
• 스크립트가 늘어날수록 유지보수가 힘들어지고 있는 분
• Page Object Model이라는 말은 들었지만 구현 방법을 모르는 분
• Playwright·Selenium에서 POM을 실전으로 활용하고 싶은 Python 엔지니어

✅ 이 글을 읽으면 알 수 있는 것

• Page Object Model의 개념과 왜 필요한지를 이해할 수 있다
• POM 없는 코드와 있는 코드를 비교해 차이를 실감할 수 있다
• Playwright（Python）에서의 POM 구현 방법을 구체적으로 알 수 있다
• 현장에서 바로 쓸 수 있는 베스트 프랙티스를 익힐 수 있다

👤
글쓴이 소개：QA 엔지니어로서 Selenium·Playwright·Python·pytest를 활용한 테스트 자동화를 실무에서 담당하고 있습니다. Page Object Model을 도입해 유지보수 비용을 대폭 줄인 경험을 바탕으로, 초보자도 실천할 수 있는 수준으로 해설합니다. 구현 코드는 GitHub에도 공개 중입니다.

📌 이 글의 결론

Page Object Model이란 「페이지마다 클래스를 만들고, 조작을 메서드로 정의하는」 설계 패턴입니다. UI가 바뀌어도 테스트 코드 수정은 한 곳으로 끝나며, 유지보수 비용을 극적으로 줄일 수 있습니다. 테스트 자동화를 장기적으로 운용할 예정이라면 POM 도입은 필수입니다.

📐 POM의 핵심 개념

💡 포인트：POM의 본질은 「테스트의 의도（무엇을 테스트하고 싶은가）」와 「구현의 세부（어떤 HTML을 조작하는가）」를 분리하는 것입니다. 이 분리가 있기 때문에 어느 쪽이 바뀌어도 영향 범위가 최소화됩니다.

test_login_no_pom.py

import pytest
from playwright.sync_api import sync_playwright

def test_login_success():
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()

        # 로그인 페이지로 이동
        page.goto("https://example.com/login")

        # 이메일 주소 입력
        page.fill("#email", "user@example.com")

        # 패스워드 입력
        page.fill("#password", "secret123")

        # 로그인 버튼 클릭
        page.click("#login-btn")

        # 대시보드가 표시되는지 확인
        assert page.is_visible("#dashboard")
        browser.close()

def test_login_failure():
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()

        # 같은 셀렉터（#email, #password, #login-btn）가 다시 등장!
        page.goto("https://example.com/login")
        page.fill("#email", "wrong@example.com")
        page.fill("#password", "wrongpass")
        page.click("#login-btn")

        # 에러 메시지 확인
        assert page.is_visible("#error-message")
        browser.close()

⚠️ 이 작성 방법의 문제점

• 셀렉터（#email 등）가 여러 테스트에 흩어져 있다. HTML이 바뀌면 모든 테스트를 수정해야 한다
• 같은 코드가 중복되어 있다（DRY 원칙 위반）. 테스트가 100개가 되면 100곳을 수정해야 한다
• 테스트 코드가 「무엇을 하는가」가 아니라 「어떻게 조작하는가」가 되어 있다. 가독성이 낮다
• 브라우저 조작의 세부 사항이 테스트에 섞여 있어 테스트의 의도를 파악하기 어렵다

pages/login_page.py

class LoginPage:
    """로그인 페이지의 Page Object 클래스"""

    def __init__(self, page):
        self.page = page

        # 로케이터를 여기에 집약（← 변경이 필요한 경우, 여기만 수정）
        self.email_input    = "#email"
        self.password_input = "#password"
        self.login_button   = "#login-btn"
        self.dashboard      = "#dashboard"
        self.error_message  = "#error-message"

    def navigate(self):
        """로그인 페이지로 이동"""
        self.page.goto("https://example.com/login")

    def login(self, email: str, password: str):
        """로그인 조작을 하나의 메서드로 정리"""
        self.page.fill(self.email_input, email)
        self.page.fill(self.password_input, password)
        self.page.click(self.login_button)

    def is_dashboard_visible(self) -> bool:
        """대시보드가 표시되어 있는지 확인"""
        return self.page.is_visible(self.dashboard)

    def is_error_visible(self) -> bool:
        """에러 메시지가 표시되어 있는지 확인"""
        return self.page.is_visible(self.error_message)

tests/test_login.py

import pytest
from playwright.sync_api import sync_playwright
from pages.login_page import LoginPage

@pytest.fixture
def login_page():
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()
        login_page = LoginPage(page)
        login_page.navigate()
        yield login_page
        browser.close()

def test_login_success(login_page):
    # ← 셀렉터가 전혀 등장하지 않는다. 테스트의 의도만 작성되어 있다
    login_page.login("user@example.com", "secret123")
    assert login_page.is_dashboard_visible()

def test_login_failure(login_page):
    login_page.login("wrong@example.com", "wrongpass")
    assert login_page.is_error_visible()

✅ POM으로 바꾸어 얻은 개선점

• 셀렉터가 LoginPage 클래스에 집약. HTML이 바뀌어도 수정은 한 곳만
• 테스트 코드가 자연어에 가까워진다. login_page.login()을 호출하는 것만으로 무엇을 하는지 한눈에 알 수 있다
• 새로운 테스트를 추가하기 쉬워진다. Page Object의 메서드를 호출하기만 하면 됨

project/
├── pages/                    # Page Object 클래스를 모아 두는 디렉터리
│   ├── base_page.py          # 모든 Page에 공통되는 처리（공통 메서드）
│   ├── login_page.py         # 로그인 페이지
│   ├── dashboard_page.py     # 대시보드 페이지
│   └── profile_page.py       # 프로필 페이지
├── tests/                    # 테스트 코드를 모아 두는 디렉터리
│   ├── conftest.py           # fixture 공통 정의（browser, page 등）
│   ├── test_login.py         # 로그인 관련 테스트
│   ├── test_dashboard.py     # 대시보드 관련 테스트
│   └── test_profile.py       # 프로필 관련 테스트
├── pytest.ini                # pytest 설정 파일
└── requirements.txt          # 의존 패키지 목록

pages/base_page.py

class BasePage:
    """모든 Page Object의 기저 클래스：공통 처리를 모음"""

    def __init__(self, page):
        self.page = page

    def wait_for_element(self, selector: str, timeout: int = 5000):
        """요소가 표시될 때까지 대기"""
        self.page.wait_for_selector(selector, timeout=timeout)

    def take_screenshot(self, filename: str):
        """스크린샷 촬영"""
        self.page.screenshot(path=f"screenshots/{filename}.png")

    def scroll_to_bottom(self):
        """페이지 맨 아래로 스크롤"""
        self.page.evaluate("window.scrollTo(0, document.body.scrollHeight)")


class LoginPage(BasePage):
    """BasePage를 상속해 LoginPage를 만든다"""

    def __init__(self, page):
        super().__init__(page)   # ← BasePage의 초기화를 호출
        self.email_input    = "#email"
        self.password_input = "#password"
        self.login_button   = "#login-btn"

    def login(self, email: str, password: str):
        self.wait_for_element(self.email_input)  # ← 상속한 공통 메서드를 사용
        self.page.fill(self.email_input, email)
        self.page.fill(self.password_input, password)
        self.page.click(self.login_button)

💡 실무 Tip：Base Page에는 어떤 페이지에서도 사용할 것 같은 처리——대기 처리·스크린샷·로그인 상태 확인 등——을 모아 두는 것이 포인트입니다. 공통 처리가 한 곳이 되므로 변경이나 개선이 쉬워집니다.

⚠️ 주의：POM은 만능이 아닙니다. 테스트가 10개 이하인 소규모 프로젝트에서는 POM을 도입하기보다 먼저 테스트를 늘리는 것을 우선합시다. 테스트 케이스가 20~30개를 넘기 시작하면 POM의 혜택이 커집니다.

🔗 관련 기사도 함께 확인하세요

• ⑤ 테스트 자동화에서 실패하지 않는 5가지 설계 원칙
  → POM을 포함한 설계 원칙의 전체 그림을 이해하자
• ⑦ 테스트 자동화의 ROI（비용 대비 효과）사고방식
  → POM 도입으로 유지보수 비용을 줄여 ROI를 높이자
• ④ Selenium vs Playwright vs pytest｜Python 테스트 자동화 툴 선택 방법
  → POM과 궁합이 좋은 툴 선정 가이드

📋 이 글의 정리

• POM이란 「페이지마다 클래스를 만들고, 조작을 메서드로 정의하는」 설계 패턴
• 셀렉터를 Page Object에 집약함으로써, UI가 바뀌어도 수정 장소가 한 곳으로 끝남
• 테스트 코드에서 구현의 세부 사항이 사라져, 「무엇을 테스트하고 싶은가」를 쉽게 읽을 수 있게 됨
• Base Page 클래스를 사용하면 공통 처리를 더욱 집약할 수 있어 재사용성이 높아짐
• assert는 Page Object에 작성하지 않고, 테스트 코드 측에 작성하는 것이 원칙
• 테스트 케이스가 20~30개를 넘기 시작하면 POM 도입의 혜택이 커짐