QA가 싫어하는 테스트 자동화｜현장에서 피해야 할 7가지 안티패턴

테스트 자동화는 QA 엔지니어의 강력한 무기다. 하지만 잘못된 방식으로 도입하면 “또 자동화 때문에 CI가 막혔다”, “테스트를 믿을 수가 없다”는 말을 들으며 팀 전체에서 외면당하게 된다. 이 글에서는 QA 실무 경력 15년 이상을 바탕으로, 현장에서 자동화 테스트가 미움받는 7가지 안티패턴을 원인과 해결책과 함께 소개한다. CI/CD, Flaky Test, 유지보수 비용 문제를 한번에 정리하고 싶은 분께 꼭 읽어보시길 권한다.

“테스트 자동화를 도입했는데 오히려 팀 분위기가 나빠졌다” — 그 원인은 기술력이 아니라 자동화의 ‘방식’에 있을 가능성이 높다.

📌 이런 분께 추천합니다

자동화 테스트가 “느리다”, “불안정하다”, “읽기 어렵다”는 말을 듣고 있는 QA 엔지니어
CI/CD 파이프라인이 테스트 때문에 계속 막히는 팀
자동화 테스트 유지보수가 감당이 안 될 정도로 쌓여가는 상황
개발팀과 QA팀 사이에 마찰이 생기고 있는 분

✅ 이 글을 읽으면

현장에서 실제로 발생하는 안티패턴 7가지를 파악할 수 있다
각 패턴의 “왜 미움받는가”와 “어떻게 개선하는가”를 알 수 있다
팀에 환영받는 자동화 테스트의 설계 방향을 잡을 수 있다

👤 이 글을 쓴 사람

QA 엔지니어 · 테스트 자동화 엔지니어로 15년 이상 실무 경험 보유. 개발자 출신으로 “만드는 쪽”과 “버그를 찾는 쪽” 양쪽 시각을 갖고 자동화 설계에 임해왔다. 이 글에서 소개하는 안티패턴은 모두 실제 현장에서 직접 마주친 사례를 바탕으로 한다.

⚡ 이 글에서 다루는 7가지 안티패턴

① Flaky Test 방치	② CI를 1시간 이상 막히게 하기
③ 읽기 불가능한 테스트 코드	④ 자동화를 위한 자동화
⑤ 테스트 결과를 아무도 안 보는 구조	⑥ 테스트 환경을 망가뜨리는 자동화
⑦ 개발자를 프로세스에 참여시키지 않기

테스트 자동화를 제대로 활용하면 개발 속도를 높이고 품질을 안정시킬 수 있다. 그런데 실제 현장에서는 “자동화를 도입하고 나서 오히려 힘들어졌다”는 목소리가 끊이지 않는다. 원인의 대부분은 기술력 부족이 아니라 자동화 설계의 사고방식에 있다.

📌 이 글의 결론

미움받는 자동화의 근본 원인은 “팀의 관점 결여”에 있다
Flaky · 느림 · 읽기 어려움 · ROI가 맞지 않는 상태, 이 4가지가 특히 현장에서 마찰을 만든다
해결책은 “자동화를 위한 자동화”를 그만두고 팀의 가치에 연결된 설계로 전환하는 것이다

왜 테스트 자동화는 미움받는가
미움받는 테스트 자동화 7가지 안티패턴
팀에 환영받는 자동화 테스트의 설계 원칙
어디서부터 개선할까 | 우선순위 사고방식
FAQ | 자주 묻는 질문
마치며

왜 테스트 자동화는 미움받는가

안티패턴을 살펴보기 전에, 왜 선의로 도입한 자동화가 문제가 되는지 원인을 정리해보자. 크게 3가지로 분류할 수 있다.

원인	구체적인 증상	영향 범위
개발자 워크플로우 방해	CI 느림 · 파이프라인 막힘	팀 전체
테스트 신뢰도 저하	Flaky Test로 “또 떨어졌네”	개발 · QA
유지보수 비용 과다	작은 변경으로 대량 실패	QA 엔지니어

이 3가지가 쌓이면 “테스트 자동화 = 비용만 드는 것”이라는 낙인이 찍히고, 결국 “QA 때문에 릴리즈가 늦어진다”는 평가로 이어진다.

미움받는 테스트 자동화 7가지 안티패턴

① Flaky Test를 방치한다

⚠️ 왜 미움받는가
같은 코드인데 “통과됐다가 실패했다가” 하는 테스트는 개발자의 신뢰를 순식간에 잃게 만든다. “어차피 또 flaky겠지”라는 인식이 자리잡으면, 진짜 버그가 나와도 무시되는 상황이 발생한다.

Flaky Test의 주요 원인:

UI 렌더링 타이밍 의존성 (time.sleep() 남용)
테스트 간 상태 공유 · 실행 순서 의존
외부 API · 네트워크 지연
테스트 실행 순서에 의존하는 로직

💡 어떻게 고칠까
time.sleep()을 없애고 WebDriverWait(Selenium) 또는 Playwright의 자동 대기로 교체한다. fixture로 테스트마다 상태를 초기화한다. Flaky Test는 “버그”로 취급해 발견 즉시 수정하거나 격리한다. @pytest.mark.flaky(pytest-rerunfailures 플러그인 필요)를 활용해 추적하면서 근본 원인을 제거하는 것이 실무적인 접근이다.

② CI를 1시간 이상 막히게 한다

⚠️ 왜 미움받는가
“PR을 올렸더니 테스트가 90분 동안 돌아간다”는 개발자에게 최악의 경험 중 하나다. 피드백 루프가 망가지고, 릴리즈가 늦어질 때마다 QA가 타깃이 된다.

CI 실행 시간이 길어지는 전형적인 원인:

모든 E2E 테스트를 직렬로 실행
불필요한 테스트가 삭제되지 않고 쌓여 있음
테스트마다 브라우저를 처음부터 기동
테스트 데이터 셋업에 시간이 걸림

💡 어떻게 고칠까
pytest-xdist로 병렬 실행을 도입한다. 테스트 피라미드를 의식하고 E2E 테스트는 꼭 필요한 것만 남긴다. PR별로 변경된 코드와 관련된 테스트만 실행하는 선택적 실행 전략도 효과적이다. 목표는 모든 커밋에 완전한 커버리지를 다는 것이 아니라, 빠르고 신뢰할 수 있는 피드백을 얻는 것이다.

③ 아무도 읽을 수 없는 테스트 코드를 작성한다

⚠️ 왜 미움받는가
“이 테스트, 뭘 테스트하는 거야?”라는 질문에 바로 답하지 못한다면 문제다. 테스트 코드는 살아있는 사양서다. 읽기 어려우면 유지보수가 불가능해지고, 유지보수가 안 되는 테스트는 결국 방치된다.

# ❌ 안티패턴: 무엇을 테스트하는지 알 수 없음
def test_1():
    d = get_driver()
    d.get("https://example.com/login")
    d.find_element(By.ID, "u").send_keys("admin")
    d.find_element(By.ID, "p").send_keys("pass123")
    d.find_element(By.ID, "btn").click()
    assert "dashboard" in d.current_url

# ✅ 좋은 예: 의도가 명확함
def test_로그인_성공_후_대시보드로_리다이렉트된다(login_page, valid_user):
    login_page.enter_credentials(valid_user.email, valid_user.password)
    login_page.submit()
    assert login_page.is_redirected_to_dashboard()

💡 어떻게 고칠까
테스트 이름은 “~할 때 ~가 된다” 형식으로 작성한다. Page Object Model(POM) 등을 활용해 UI 구현 세부사항을 숨긴다. fixture로 전제 조건을 명시한다. “새로운 팀원이 30초 안에 이해할 수 있는가”를 기준으로 삼는 것이 좋다.

④ 자동화를 위한 자동화를 한다

⚠️ 왜 미움받는가
“자동화율 100%”를 목표로 ROI(투자 대비 효과)를 고려하지 않고 저빈도 테스트나 변경이 없는 화면을 대량으로 E2E 자동화한다. 결과적으로 유지보수 비용만 쌓이고 “자동화해도 의미가 없다”는 말을 듣게 된다.

자동화하지 않는 것이 나은 케이스의 전형적인 예:

월 1회만 실행되는 회귀 테스트
스프린트마다 바뀌는 개발 초기 UI
탐색적 테스트로 가치가 나오는 시나리오
수동으로 5분이면 끝나는 테스트

💡 어떻게 고칠까
자동화하기 전에 “이 테스트는 몇 번 실행되고, 매번 얼마나 시간을 절약하는가”를 수치화하는 습관을 갖는다. 자동화 ROI가 높은 것은 “고빈도 · 안정적 · 경계값이 명확한” 테스트다. 전략적으로 자동화하고, 무분별하게 늘리지 않는 것이 핵심이다.

⑤ 테스트 결과를 아무도 안 보는 구조로 만든다

⚠️ 왜 미움받는가
CI에서 테스트는 돌아가는데 결과 리포트가 어디 있는지 모르거나 보기 불편하면, 테스트의 가치가 팀에 전달되지 않는다. “테스트가 통과했는지”, “몇 건 실패했는지”가 보이지 않으면 자동화가 유명무실해진다.

💡 어떻게 고칠까
Allure Report나 GitHub Actions Summary로 테스트 결과를 시각화한다. Slack 알림으로 실패를 즉시 공유하는 구조를 만든다. 원칙은 “팀 누구나 10초 안에 테스트 상태를 확인할 수 있을 것.” 결과가 보여야 신뢰가 생긴다.

⑥ 테스트 환경을 망가뜨리는 자동화를 만든다

⚠️ 왜 미움받는가
테스트 후 데이터 정리를 잊어 공유 스테이징 환경에 불필요한 데이터가 남아있게 된다. “QA 테스트 돌린 이후로 DB가 이상해졌다”는 말은 자동화에 대한 신뢰를 가장 크게 손상시키는 말 중 하나다.

💡 어떻게 고칠까
fixture의 teardown에서 반드시 테스트 데이터를 삭제·초기화한다. 가능하면 테스트 전용 격리 환경을 준비한다. 테스트 데이터에는 식별 가능한 접두사(예: test_auto_)를 붙여 항상 구분이 쉽도록 한다. 공유 환경을 사용한다면, 깔끔하게 유지하는 것을 스스로의 책임으로 인식해야 한다.

⑦ 개발자를 프로세스에 참여시키지 않는다

⚠️ 왜 미움받는가
“QA가 혼자서 테스트를 만들고, 개발자는 아무것도 관여하지 않는다”는 사일로 구조는 테스트가 사양과 괴리되는 온상이 된다. 버그가 나왔을 때 “그건 QA 문제 아닌가요”라는 분열을 낳는다.

💡 어떻게 고칠까
먼저 작은 협력 요청부터 시작한다. “data-testid를 이 버튼에 추가해 주실 수 있나요?”는 “테스트 코드를 리뷰해 주세요”보다 훨씬 받아들여지기 쉽다. 작은 성공을 쌓으면서 QA에 대한 신뢰를 쌓고, 자연스럽게 협업 관계로 발전시켜 나가는 것이 근본 해결책이다.

팀에 환영받는 자동화 테스트의 설계 원칙

7가지 안티패턴을 뒤집으면, 팀에 받아들여지는 자동화 테스트의 원칙이 보인다.

설계 원칙	구체적인 실천
속도	병렬화 · 테스트 피라미드 · 최소한의 E2E
안정성	Flaky Test 지속적 감소 · 대기 전략 통일 · 상태 독립
가독성	POM 등 활용 · 테스트명 명확화 · fixture 활용
가시성	Allure Report · Slack 알림 · CI Summary
협업	data-testid 협력 · 테스트 리뷰 · 공동 책임

🔑 핵심 사고방식

테스트 자동화는 “QA 엔지니어를 위한 도구”가 아니라 팀이 빠르고 안전하게 릴리즈하기 위한 도구다. 이 관점이 빠지면, 아무리 기술적으로 완벽한 자동화도 짐이 되고 만다.

어디서부터 개선할까 | 우선순위 사고방식

7가지 안티패턴을 한꺼번에 해결하려는 것은 현실적이지 않다. 팀에 가장 큰 영향을 주는 것부터 순서대로 착수하는 것이 효과적이다.

우선도	개선 테마	이유
🥇 최우선	Flaky Test 감소	테스트 자체에 대한 신뢰가 무너지면 모든 것이 의미 없어진다
🥈 다음	CI 실행 시간 단축	느린 피드백은 개발자 생산성을 직접 방해한다
🥉 병행하여	테스트 결과 가시화	자동화의 가치를 팀에 전달해 신뢰를 쌓는 데 필요하다

이 3가지가 안정되면 코드 품질 · ROI · 협업으로 개선 범위를 넓혀가는 것이 실무적인 로드맵이다.

📖 관련 글

FAQ | 자주 묻는 질문

Q. Flaky Test는 완전히 없앨 수 있나요?

완전히 없애기는 어렵지만, 올바른 문화와 도구가 있으면 거의 제로에 가깝게 줄일 수 있다. 핵심은 “Flaky Test를 버그로 취급해 발견 즉시 수정하거나 격리”하는 것이다. @pytest.mark.flaky(pytest-rerunfailures 플러그인 사용)로 불안정한 테스트를 추적하면서 근본 원인을 제거하는 것이 현장에서 현실적인 접근이다.

Q. Unit · Integration · E2E 테스트의 이상적인 비율은?

테스트 피라미드에서는 Unit:Integration:E2E = 70:20:10이 대표적인 목표 수치 중 하나로 알려져 있다. 다만 이것은 규칙이 아닌 참고 지표다. 올바른 비율은 제품 유형 · 팀 구성 · 리스크 프로파일에 따라 달라진다. 핵심 원칙은 E2E 테스트는 비용이 높으므로, 자동화의 대부분은 Unit · Integration 레벨에 투자하는 것이 효율적이라는 점이다.

Q. 개발자가 테스트에 관여해 주지 않을 때는 어떻게 하면 좋을까요?

가장 작은 협력 요청부터 시작하는 것이 효과적이다. “이 버튼에 data-testid를 추가해 주실 수 있나요?”는 “테스트 코드를 리뷰해 주세요”보다 훨씬 받아들여지기 쉽다. 작은 성공을 쌓고, 그 가치를 보여주면(빌드 실패 감소, 피드백 속도 향상 등) 협업은 자연스럽게 따라온다. 강요는 역효과가 나는 경우가 많다.

Q. 테스트 자동화 아키텍처에 관한 자격증이 있나요?

ISTQB(JSTQB의 국제 모체)에 Advanced Level Test Automation Engineer라는 전문 자격증이 있다. 자동화 설계 · 아키텍처 · 툴 선정을 전문적으로 다룬다. 아직 일본과 한국에서 보급 초기 단계이지만, 자동화를 체계적으로 배우고 싶은 분들에게 좋은 참고가 된다.

Q. 팀에서 자동화가 이미 미움받고 있는지 어떻게 알 수 있나요?

다음 징조가 나타나고 있다면 주의가 필요하다. “CI가 빨간색이어도 다들 무시하고 머지한다”, “테스트 수정보다 기능 개발을 우선시하자는 말이 나온다”, “이번 릴리즈는 테스트를 생략하자는 논의가 생긴다” — 이런 신호가 보이면 자동화에 대한 신뢰가 무너지고 있다는 뜻이다. 일찍 팀과 과제를 공유하고 개선에 착수하는 것이 중요하다.