Selenium 운용 붕괴 이야기 7선｜QA 엔지니어가 실무에서 경험한 실패와 복구 방법

Selenium으로 E2E 테스트 자동화를 운용하고 있는 QA 엔지니어가 실제로 경험한 「운용 붕괴」 실패담을 7선으로 해설합니다. ChromeDriver 버전 관리·Wait 혼재·xpath 셀렉터 의존·특정인 의존 등, Selenium 고유의 「작동하다가 무너지는」 패턴과 복구 방법을 실무 경험을 바탕으로 소개합니다. 참고로 「유지보수 부채」란 수정 비용이 눈덩이처럼 불어나는 상태를 말합니다.

「처음에는 잘 작동했는데, 어느새 아무도 건드릴 수 없는 코드가 됐다」——Selenium 운용 붕괴는 갑자기 일어나는 것이 아니라, 서서히 진행됩니다.

「처음 반년은 순조로웠다. 하지만 1년 후, 아무도 그 테스트 코드를 건드리지 않게 됐다」——여러 프로젝트에서 반복해서 목격해 온 광경입니다.

Selenium 운용 악화에 공통되는 것은, 「갑자기 무너지는」것이 아니라 「서서히 무너져 간다」는 것입니다. 이 기사에서는 유지보수 부채의 7가지 패턴과 각각의 복구 방법을 실체험을 바탕으로 해설합니다.

Selenium 운용 붕괴 이야기 7선이란？조견표

① ChromeDriver 버전 관리 지옥이란？

무슨 일이 일어났나

월요일 아침, CI가 갑자기 실패합니다. 로그를 보면 SessionNotCreatedException: This version of ChromeDriver only supports Chrome version XX. 주말 사이 Chrome이 자동 업데이트되어 ChromeDriver와 버전이 맞지 않아진 것입니다.

처음에는 「ChromeDriver를 다운로드해서 교체하면 된다」고 생각했습니다. 하지만 이것이 매주 반복됩니다. 다운로드 페이지를 찾고→버전을 확인하고→교체하고→CI를 재실행하고——이 작업에 매주 월요일 오전이 사라졌습니다.

붕괴의 예조

• ChromeDriver의 경로가 하드코딩되어 있다
• requirements.txt에 ChromeDriver 버전이 기재되어 있지 않다
• CI 환경의 Chrome 버전 관리가 「대략 최신」으로 되어 있다
• ChromeDriver 다운로드가 수동 작업이 되어 있다

# ❌ 붕괴 패턴：ChromeDriver 경로를 하드코딩
from selenium import webdriver
from selenium.webdriver.chrome.service import Service

driver = webdriver.Chrome(service=Service("/usr/local/bin/chromedriver"))
# 버전이 맞지 않으면 매번 여기서 에러가 난다

# ✅ 선택지①：Selenium 4.6+ 의 Selenium Manager（표준 탑재）
# Selenium 4.6 이후는 ChromeDriver 자동 관리가 표준 기능으로 탑재
# 단, CI·Docker 환경에서는 OS 의존 등으로 추가 조정이 필요한 경우가 있다
from selenium import webdriver
driver = webdriver.Chrome()
# 추가 라이브러리 불필요（단, 환경 의존의 조정이 필요한 케이스 있음）

# ✅ 선택지②：webdriver-manager（기존 프로젝트·CI 환경에서 널리 이용）
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager

driver = webdriver.Chrome(
    service=Service(ChromeDriverManager().install())
)
# 기존 환경이나 Selenium 4.6 미만에서도 계속 유효

② implicitWait와 explicitWait를 혼재시켜 Flaky 지옥이 됐다란？

※ Flaky 테스트란 「성공하기도 하고 실패하기도 하는 불안정하고 재현성 없는 테스트」를 말합니다. CI를 실행할 때마다 결과가 바뀌기 때문에 「실제 버그인지 불안정한 것인지」판단이 어려워집니다.

무슨 일이 일어났나

「대기 처리를 제대로 하자」고 문서를 읽은 결과, implicitly_wait와 WebDriverWait를 모두 코드 내에 혼재시켜버렸습니다. 작동하는 날도 있고 실패하는 날도 있는——재현성 없는 Flaky 테스트가 대량 발생하여, 「테스트가 실패해도 실제 버그인지 알 수 없는」상태가 됐습니다.

# ❌ 붕괴 패턴：implicitWait와 explicitWait의 혼재
driver.implicitly_wait(10)  # 글로벌 설정

# 다른 곳에서
wait = WebDriverWait(driver, 5)
element = wait.until(EC.presence_of_element_located((By.ID, "submit")))
# 타임아웃 계산이 간섭하여 Flaky의 원인이 된다

# ✅ 복구 방법：explicitWait로 통일한다
# implicitly_wait 는 사용하지 않는다
# 모든 것을 WebDriverWait로 명시적으로 대기

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

wait = WebDriverWait(driver, 10)
element = wait.until(
    EC.element_to_be_clickable((By.ID, "submit"))
)
element.click()

③ xpath 셀렉터 의존으로 UI 리뉴얼마다 전체 붕괴란？

무슨 일이 일어났나

「어쨌든 요소를 지정할 수 있으면 된다」는 방침으로, xpath를 풀 패스로 지정한 테스트 코드가 축적됐습니다. 6개월 후, 프론트엔드 리뉴얼로 HTML 구조가 바뀌었을 때, 300건의 테스트 중 280건이 동시에 실패했습니다. xpath의 경로가 무효가 된 것입니다.

# ❌ 붕괴 패턴：풀 패스 xpath 의존
driver.find_element(
    By.XPATH,
    "/html/body/div[2]/main/section[1]/form/div[3]/button"
)
# HTML 구조가 조금만 바뀌어도 전체 붕괴

# ⚠️ 상대 xpath도 취약한 경우가 있다
driver.find_element(By.XPATH, "//div[@class='btn-wrapper']/button[1]")
# class가 바뀌면 깨진다

# ✅ 권장：data-testid를 사용한 CSS Selector가 가장 안정적
driver.find_element(By.CSS_SELECTOR, "[data-testid='submit-btn']")
# data-testid는 테스트 전용 속성 → UI 리뉴얼에서도 바꾸지 않는 규칙을 만들 수 있다

# ✅ 차선：ID나 name 속성
driver.find_element(By.ID, "submit-btn")
driver.find_element(By.NAME, "submit")

셀렉터 안정성 비교

④ Page Object화하지 않고 1000행 스크립트가 탄생했다란？

무슨 일이 일어났나

「우선 작동시키는 것이 우선」이라는 방침으로 테스트를 계속 추가한 결과, 하나의 테스트 파일이 1000행을 초과했습니다. 로그인 처리가 5곳에 복사&붙여넣기 되어 있어, 로그인 화면의 셀렉터가 바뀌면 5곳 모두를 수정해야 합니다. 수정 누락으로 버그가 숨어들게 됐습니다.

# ❌ 붕괴 패턴：같은 조작이 코드 내에 분산
def test_purchase():
    driver.find_element(By.ID, "email").send_keys("user@example.com")
    driver.find_element(By.ID, "password").send_keys("pass")
    driver.find_element(By.ID, "login-btn").click()
    # ...구매 처리...

def test_profile():
    driver.find_element(By.ID, "email").send_keys("user@example.com")  # 중복
    driver.find_element(By.ID, "password").send_keys("pass")           # 중복
    driver.find_element(By.ID, "login-btn").click()                    # 중복
    # ...프로필 처리...

# ✅ 복구 방법：Page Object Model로 조작을 집약
class LoginPage:
    def __init__(self, driver):
        self.driver = driver

    def login(self, email: str, password: str):
        self.driver.find_element(By.ID, "email").send_keys(email)
        self.driver.find_element(By.ID, "password").send_keys(password)
        self.driver.find_element(By.ID, "login-btn").click()

# 테스트 코드는 의도만 작성한다
def test_purchase(driver):
    LoginPage(driver).login("user@example.com", "pass")
    # ...구매 처리만...

⑤ 담당자가 퇴직하여 아무도 건드릴 수 없는 코드가 됐다란？

무슨 일이 일어났나

「이 Selenium 테스트는 A씨밖에 모른다」——A씨가 퇴직한 다음 달, 테스트가 실패해도 아무도 고칠 수 없는 상태가 됐습니다. 코드에 주석은 없고, 로컬 환경 구축 순서도 문서화되어 있지 않았습니다. 「테스트가 실패해도 방치한다」는 문화가 생겨나 자동화가 형식화되어 갔습니다.

특정인 의존의 구체적인 증상 체크리스트

※ Yes/No만이 아니라 「팀의 몇 퍼센트가 대응할 수 있는가」라는 관점으로도 확인해 보세요. 1명만 대응할 수 있는 상태가 특정인 의존의 본질입니다.

⑥ 헤드리스화 못 해 CI에 편입할 수 없었다란？

무슨 일이 일어났나

「로컬에서는 작동한다」지만, CI 서버（헤드리스 환경）에서 실행하면 일제히 에러가 납니다. 조사해 보니, 브라우저의 윈도우 크기와 화면 렌더링에 의존한 조작이 테스트 내에 분산되어 있는 것이 판명났습니다. 구체적으로는 다음과 같은 문제들이 얽혀 있었습니다.

# ❌ 붕괴 패턴：헤드리스에서 작동하지 않는 구현
# 화면 크기를 전제로 한 스크롤 조작
driver.execute_script("window.scrollTo(0, 500)")
driver.find_element(By.ID, "submit").click()
# 헤드리스에서는 500px 위치에 요소가 없을 수 있다

# ❌ viewport 밖 요소를 클릭（헤드리스에서 실패）
element = driver.find_element(By.ID, "footer-btn")
element.click()  # 화면 밖일 경우 에러

# ✅ 복구 방법①：스크롤하고 나서 조작
element = driver.find_element(By.ID, "submit")
driver.execute_script("arguments[0].scrollIntoView(true);", element)
element.click()

# ✅ 복구 방법②：윈도우 크기를 명시적으로 설정
from selenium import webdriver

options = webdriver.ChromeOptions()
options.add_argument("--headless")
options.add_argument("--window-size=1920,1080")  # CI 환경에서 크기를 고정
driver = webdriver.Chrome(options=options)

⑦ Selenium 4 업그레이드로 전체 테스트가 작동하지 않게 됐다란？

무슨 일이 일어났나

pip install selenium --upgrade로 Selenium 3에서 4로 버전을 올린 직후, 다음날 CI에서 200건의 테스트 중 150건 이상이 한꺼번에 실패했습니다. Selenium 4에서 폐지된 API가 여러 개 있는데, 이전 계획 없는 업그레이드가 대참사를 일으켰습니다.

Selenium 3→4에서 폐지·변경된 주요 API

# ❌ 붕괴 패턴：Selenium 3의 폐지 API를 계속 사용
driver.find_element_by_id("submit")          # Selenium 4에서 삭제
driver.find_element_by_xpath("//button")     # Selenium 4에서 삭제
driver.find_element_by_class_name("btn")     # Selenium 4에서 삭제

# ✅ Selenium 4 대응 작성법（By.XXX 사용）
from selenium.webdriver.common.by import By

driver.find_element(By.ID, "submit")
driver.find_element(By.XPATH, "//button")
driver.find_element(By.CLASS_NAME, "btn")

Selenium을 계속하는 것이 좋은 케이스란？

이 기사에서는 운용상의 문제점을 중심으로 해설했지만, 모든 현장에서 Playwright 이전이 정답은 아닙니다. 다음과 같은 경우에는 Selenium을 계속하는 것이 보다 현실적인 선택입니다.

FAQ

Selenium은 20년 이상의 역사를 가진 실적 있는 도구입니다. 이 기사에서 소개한 7가지 패턴은 모두 「Selenium이 나쁘다」는 것이 아니라 「운용 설계 없이 확대한 결과」였습니다. 오늘부터라도 예조를 확인하고, 하나씩 대처해 나가면 유지 불가능해진 운용도 반드시 복구할 수 있습니다.