자동화하지 않는 것이 좋은 테스트 케이스 7선｜QA 엔지니어가 실무에서 판단하는 기준 해설

QA 엔지니어가 놓치기 쉬운 「자동화해서는 안 되는 테스트」「자동화에 적합하지 않은 테스트 케이스」를 7선으로 해설합니다. 탐색적 테스트·외부 서비스 연동·UX 평가 등, 자동화하면 오히려 ROI(투자 대비 수익)가 악화되는 구체적인 케이스와, 수동·부분 자동화·모니터링을 구분하여 사용하는 실무 판단 기준을 소개합니다.

「자동화할 수 있다 ＝ 자동화해야 한다」가 아닙니다. 자동화해서는 안 되는 테스트를 파악하는 것이, 지속 가능한 자동화의 조건입니다.

📌 이런 분께 추천합니다

자동화를 추진했지만 「뭐든 자동화」로 인해 유지보수 비용이 폭발한 경험이 있는 분
자동화 대상 선정에 고민하고 있는 QA 엔지니어·테스트 리드
팀에 「자동화하지 않는 판단 기준」을 공유하고 싶은 분
비용 대비 효과가 높은 자동화 전략을 구축하고 싶은 분

✅ 이 기사를 읽으면 얻을 수 있는 것

자동화하지 않는 것이 좋은 테스트 케이스 7가지의 구체적인 내용과 이유를 알 수 있다
「자동화할 수 있다」와 「자동화해야 한다」의 차이가 명확해진다
각 케이스에 대한 실무에서의 대처법·대안 수단을 알 수 있다

👤 이 기사를 쓴 사람

QA 엔지니어·테스트 자동화 엔지니어로서 15년 이상의 실무 경험을 가진 Yoshi가 집필. 「전부 자동화하자」고 했다가 유지보수 비용이 급증한 실패를 경험했기에, 「자동화하지 않는 판단」의 중요성을 몸소 느끼고 있습니다.

📌 결론 (3가지 포인트)

자동화하지 않는 것이 좋은 테스트 케이스란 「감성·판단·일회성·외부 의존·높은 비용 설정」이 얽혀 있는 것
「자동화할 수 있는 기술이 있다」 ≠ 「자동화해야 한다」. ROI(Return on Investment：투자 대비 수익)가 맞는지 여부가 판단 기준
자동화하지 않는 테스트를 수동으로 효율 좋게 수행하는 것도, QA 엔지니어의 중요한 스킬셋

「Playwright로 E2E 테스트를 작성할 수 있게 됐다」「pytest로 API 테스트를 자동화했다」——스킬이 높아질수록 「이것도 자동화할 수 있다」는 유혹이 커집니다.

하지만 자동화할 수 있다고 해서 자동화해야 하는 것은 아닙니다. 이 기사에서는 실무 경험에서 엄선한 「자동화하지 않는 것이 좋은 테스트 케이스 7선」을 구체적인 케이스 레벨로 해설합니다.

💡 이 기사의 전제：「자동화하지 않는다」는 「아무것도 하지 않는다」가 아닙니다. 실무에서는 완전 자동화·부분 자동화(목업화·전처리만 자동화)·Synthetic Monitoring·수동의 조합이 현실적인 선택지입니다. 이 기사에서는 「완전한 자동화 테스트 코드를 작성해서는 안 되는 케이스」에 초점을 맞춰 해설합니다.

📖 관련 기사와의 사용 구분

자동화해야 할 테스트와 해서는 안 되는 테스트의 구분 방법：판단 프레임워크·체크리스트 → 전체적인 사고방식을 알고 싶은 분은 이쪽부터
이 기사：구체적인 테스트 케이스 7선 심화 해설 → 「이 케이스는 자동화해야 할까?」를 판단하고 싶은 분에게

📋 이 기사의 목차

① 화면 외관·레이아웃의 육안 확인
② UI/UX의 「사용하기 편함」 평가
③ 감성·직관을 사용하는 탐색적 테스트
④ 사양 확정 전·프로토타입 단계의 기능 테스트
⑤ 일회성 데이터 이행·환경 구축 테스트
⑥ 외부 결제·SNS 인증 등 서드파티 서비스의 실환경 테스트
⑦ 설정 비용이 테스트 실행 시간을 크게 초과하는 테스트
무리한 자동화가 Flaky 테스트를 만드는 이유
판단 체크리스트
FAQ

자동화하지 않는 것이 좋은 테스트 케이스 7선이란？조견표
① 화면 외관·레이아웃의 육안 확인이란？
1. 자동화가 어려운 구체적인 케이스
② UI/UX의 「사용하기 편함」 평가란？
1. 자동화가 어려운 구체적인 케이스
③ 감성·직관을 사용하는 탐색적 테스트란？
1. 탐색적 테스트가 특히 효과적인 구체적인 장면
④ 사양 확정 전·프로토타입 단계의 기능 테스트란？
1. 자동화가 너무 이른 신호의 구체적인 예
⑤ 일회성 데이터 이행·환경 구축 테스트란？
1. 일회성 테스트의 구체적인 예
⑥ 외부 결제·SNS 인증 등 서드파티 서비스의 실환경 테스트란？
1. 자동화를 가로막는 구체적인 장벽
⑦ 설정 비용이 테스트 실행 시간을 크게 초과하는 테스트란？
1. 설정 비용이 높은 구체적인 케이스
무리한 자동화가 Flaky 테스트를 만드는 이유란？
1. Flaky 테스트가 생기기 쉬운 상황
자동화해야 할지 판단하는 체크리스트란？
FAQ

자동화하지 않는 것이 좋은 테스트 케이스 7선이란？조견표

먼저 7가지 케이스를 한눈에 확인해 봅시다.

#	테스트 케이스 종류	자동화 NG 이유	수동 대체
①	화면 외관·레이아웃의 육안 확인	「아름다운가」의 판단은 사람만이 할 수 있다	✅
②	UI/UX의 「사용하기 편함」 평가	사용자 만족도는 Pass/Fail로 측정할 수 없다	✅
③	감성·직관을 사용하는 탐색적 테스트	「왠지 이상하다」는 자동화할 수 없다	✅
④	사양 확정 전·프로토타입 단계의 기능 테스트	매주 바뀌는 사양을 따라갈 수 없다	✅
⑤	일회성 데이터 이행·환경 확인 테스트	다시 사용하지 않을 코드에 투자할 의미 없음	✅
⑥	외부 결제·SNS 인증 등 서드파티 서비스의 실환경 테스트	CAPTCHA·레이트 제한·실결제가 장벽이 됨	✅
⑦	설정 비용이 테스트 실행 시간을 크게 초과하는 테스트	준비 공수가 ROI를 완전히 갉아먹는다	✅

① 화면 외관·레이아웃의 육안 확인이란？

「버튼이 올바른 위치에 있는가」「폰트 크기가 통일되어 있는가」「호버 시 애니메이션이 부드러운가」——이러한 시각적 확인은 도구로 합격/불합격을 판정할 수 있는 성질의 것이 아닙니다.

자동화가 어려운 구체적인 케이스

브랜드 컬러의 「따뜻함」「세련됨」평가
반응형 디자인이 「자연스럽게 무너지는 방식」확인
애니메이션·트랜지션의 부드러움 평가
여러 폰트가 혼재할 때의 가독성 평가
다크 모드 전환 시의 배색 밸런스 확인

⚠️ VisReg에 대한 보충：Visual Regression Testing(VisReg) 도구(Percy·Applitools 등)는 픽셀 차분이나 AI 기반 비교로 「이전과의 변화」를 감지할 수 있습니다. 디자인 시스템과 베이스라인 비교를 조합하면 일정한 자동 판정도 가능합니다. 다만 「그 변화가 디자인 의도로서 좋은지 나쁜지」의 최종 판단은 사람이 하는 경우가 대부분입니다. VisReg는 육안 확인을 생략하는 데 도움이 되는 유효한 도구이지만, 디자인 품질 평가를 완전히 대체하는 것은 아닌이라는 이해가 실무에서 적절합니다.

💡 실무에서의 대처법：UI의 수치적 확인(요소 존재·텍스트 내용·클릭 가능 여부)은 자동화하고, 외관 품질 평가는 정기적인 수동 리뷰 세션으로 분리하는 것이 베스트 프랙티스입니다.

② UI/UX의 「사용하기 편함」 평가란？

「이 폼은 직관적으로 조작할 수 있는가」「에러 메시지는 이해하기 쉬운가」「내비게이션의 동선은 자연스러운가」——사용자 경험의 품질은 Pass/Fail로 수치화할 수 없습니다.

자동화가 어려운 구체적인 케이스

신규 사용자가 「헤매지 않고 조작할 수 있는가」평가
에러 메시지의 「이해하기 쉬움」확인
화면 전환의 「흐름의 자연스러움」체크
모바일에서의 「탭하기 쉬움」평가
고령자·장애를 가진 사용자의 접근성 체험 확인

⚠️ 주의：접근성(WCAG 준수·ARIA 레이블·대비율)의 체크는 자동화할 수 있습니다(axe-core 등). 하지만 「실제로 사용해보니 어떤 느낌인가」라는 UX 체험의 평가는 자동화할 수 없습니다. 이 둘을 혼동하지 않도록 주의하세요.

💡 실무에서의 대처법：유저빌리티 테스트는 소규모(5명 정도)의 수동 세션이 효과적입니다. 「조작 중 막힌 부분」「소리 내어 말한 불만」을 기록하는 방법(Think-Aloud법)이 실무에서 자주 사용됩니다.

③ 감성·직관을 사용하는 탐색적 테스트란？

「왠지 여기 동작이 이상하다」「이 파라미터를 바꾸면 어떻게 될까」——QA 엔지니어의 경험과 직관에서 탄생하는 테스트입니다.

⚠️ 보충：monkey testing·fuzz testing·AI-assisted testing 등 「탐색적에 가까운 접근법」은 존재합니다. 다만 이것들은 「랜덤 입력이나 학습 기반으로 예기치 않은 동작을 찾는」것이며, 「숙련 QA 엔지니어가 가설을 세우면서 시험하는」인간 주도의 탐색적 테스트의 본질 부분은 대체할 수 없습니다. 이 기사에서는 후자의 「인간의 판단·직관이 핵심이 되는 탐색적 테스트」를 대상으로 합니다.

탐색적 테스트가 특히 효과적인 구체적인 장면

버그가 집중되는 경계 부근 조사：자동화 테스트가 통과했는데 본번에서 버그가 발생한 직후
새 기능의 첫 릴리즈 전：사양서에 기재되지 않은 조합을 시험한다
리팩토링 후의 회귀 확인：코드 변경의 의도치 않은 영향을 찾는다
보안·취약점 조사：공격자의 관점으로 시스템을 시험한다

💡 실무 Tip：탐색적 테스트를 「어쩐지 하는」것이 아니라 차터(목적·대상·시간)를 정해 세션 기반으로 실시하면 품질이 높아집니다. 「30분 동안 로그인 주변의 에러 핸들링을 탐색한다」는 형식으로 구조화하는 것이 실무에서의 베스트 프랙티스입니다.

④ 사양 확정 전·프로토타입 단계의 기능 테스트란？

개발 초기에는 UI도 사양도 매주 바뀝니다. 이 단계에서 자동화 테스트를 작성하면, 사양 변경 때마다 테스트 코드 수정이 발생하여 결과적으로 「테스트 코드 유지보수 전담자」가 되어버립니다.

자동화가 너무 이른 신호의 구체적인 예

상황	자동화 판단	이유
디자인 캠프가 주 단위로 바뀌고 있다	❌ 아직 이르다	셀렉터가 매주 망가진다
API의 응답 구조가 미확정	❌ 아직 이르다	스키마 변경 때마다 테스트가 깨진다
스테이징 환경이 불안정	❌ 아직 이르다	Flaky 테스트가 대량 생산된다
사양이 3개월 이상 바뀌지 않았다	✅ 자동화 검토	안정된 사양에 투자할 수 있다
릴리즈 완료 후 매번 수동으로 확인하고 있다	✅ 자동화해야 함	반복 비용을 절감할 수 있다

💡 실무 Tip：「사양이 3개월 변하지 않았는가」는 자동화 시작의 하나의 기준입니다. 다만 팀의 개발 사이클이나 제품 단계에 따라 적절한 타이밍은 달라집니다. 중요한 것은 「사양 변경 때마다 테스트 코드가 망가지는 빈도가 너무 높지 않은가」를 확인하는 것입니다.

⑤ 일회성 데이터 이행·환경 구축 테스트란？

본번 데이터 이행 확인, 구 시스템에서 신 시스템으로의 전환 검증, 특정 이벤트 기간 중에만 필요한 테스트——이것들은 「일생에 한 번만 실행하는」 테스트입니다.

일회성 테스트의 구체적인 예

DB 스키마 변경 후의 기존 데이터 정합성 확인(이행 후 1회만 실행)
클라우드 이행 시의 데이터 건수·내용의 대조 체크
연 1회의 대형 세일 기간 중에만 필요한 재고·가격 테스트
외부 시스템 통합 시의 초회 데이터 읽기 확인

⚠️ 주의：「데이터 이행 테스트」라는 이름이어도, 유사한 이행이 정기적으로 발생하는 배치 처리의 경우는 자동화를 검토해야 합니다. 「일회성인지 여부」가 판단의 포인트입니다.

💡 실무에서의 대처법：일회성 테스트는 SQL 스크립트나 스프레드시트를 이용한 체크리스트가 현실적입니다. 자동화 코드를 작성하는 공수를 테스트 설계와 실행 결과의 문서화에 할당하는 편이 가치가 높습니다.

⑥ 외부 결제·SNS 인증 등 서드파티 서비스의 실환경 테스트란？

Stripe·PayPal·LINE Login·Google OAuth 등, 외부 서비스와 연동한 기능의 실환경 테스트에는 자동화의 큰 장벽이 있습니다.

자동화를 가로막는 구체적인 장벽

장벽 종류	구체적인 문제	대안
CAPTCHA	봇 판정으로 자동화가 차단된다	테스트 환경에서 CAPTCHA 비활성화
레이트 제한	단시간에 대량 요청으로 BAN된다	목업 서버로 대체
실결제	테스트마다 실제 결제가 발생할 위험	샌드박스 환경 이용
SMS/이메일 인증	실기기로의 OTP 도달을 자동으로 취득할 수 없다	테스트용 가상 번호 서비스
OAuth 인증 플로우	외부 서비스의 UI 변경으로 갑자기 망가진다	인증 부분을 목업화하여 API 층에서 테스트

💡 실무 Tip：외부 서비스 연동의 테스트는 「완전 자동화냐 수동이냐」의 이분법이 아닙니다. 실무에서는 다음과 같은 중간 전략이 자주 사용됩니다.

목업화 + API 층 테스트：외부 서비스를 목업으로 교체하여 자동화 가능한 범위를 커버
Synthetic Monitoring：본번 환경에 대해 정기적으로 가벼운 소통 확인 스크립트를 실행
Observability(모니터링)로 보완：외부 연동의 오류율·응답 시간을 대시보드에서 모니터링
월 1회 수동 확인：결제 플로우의 최종 확인(실제 결제→취소까지)은 월 1회 수동 확인으로 충분한 경우가 많다

「자동화하지 않는다 ＝ 아무것도 하지 않는다」가 아니라, 모니터링·목업·부분 자동화를 조합하여 품질을 담보하는 것이 실무의 베스트 프랙티스입니다.

⑦ 설정 비용이 테스트 실행 시간을 크게 초과하는 테스트란？

「테스트 자체는 3초면 끝나는데, 전제 조건을 만드는 데 3시간 걸린다」——이런 케이스에서는 자동화의 ROI가 완전히 역전됩니다.

설정 비용이 높은 구체적인 케이스

특수한 하드웨어 환경이 필요한 테스트：특정 GPU 모델·NFC 대응 디바이스·산업용 기기와의 연결 확인
복잡한 초기 데이터가 필요한 테스트：「3년분의 구매 이력을 가진 사용자」로만 재현되는 처리 확인
외부 사람의 조작이 필요한 테스트：「다른 담당자가 승인한다」「고객 지원이 대응한다」등 사람을 끼우는 플로우
타이밍에 의존하는 테스트：「야간 배치 실행 후」「월말 결산 처리 후」에만 확인할 수 있는 상태
라이선스 비용이 높은 도구가 필요한 테스트：특정 업무 시스템과의 연동에 고가 라이선스 환경이 필요

⚠️ 판단의 기준：「테스트 자동화 비용 ＞ 수동으로 몇 번 실행하는 비용의 합계」가 된다면, 수동 쪽이 합리적입니다. 특히 설정에 공수가 걸리는 경우, 이 역전이 일어나기 쉽습니다.

💡 실무 Tip：설정 비용이 높은 테스트는 「테스트 데이터 작성 스크립트」「환경 설정의 문서화」만 자동화하고, 테스트 실행 자체는 수동으로 하는 절충안이 실무에서 유효합니다.

무리한 자동화가 Flaky 테스트를 만드는 이유란？

「자동화하지 않는 것이 좋은 테스트를 자동화한다」면 무슨 일이 일어날까——그 전형이 Flaky 테스트(실행할 때마다 결과가 바뀌는 불안정한 테스트)입니다.

Flaky 테스트가 생기기 쉬운 상황

사양 확정 전에 자동화：사양 변경 때마다 테스트가 망가져, 계속 수정한 결과 「왠지 깨지는 테스트」가 된다
외부 서비스에 의존한 채로 자동화：외부 API·네트워크·응답 속도의 변동으로 랜덤하게 실패한다
설정이 복잡한 테스트를 무리하게 자동화：전제 조건의 재현이 불완전하여 테스트 환경마다 결과가 달라진다

⚠️ Flaky 테스트가 초래하는 최악의 상태：Flaky가 늘면 「테스트가 실패해도 아무도 신경 쓰지 않는다」「CI가 빨간색이어도 무시하고 머지한다」는 문화가 생깁니다. 이것은 자동화를 하지 않은 상태보다 위험합니다. 테스트에 대한 신뢰를 잃으면, 자동화에 투자한 비용 전체가 낭비가 됩니다.

💡 대처법：Flaky 테스트가 많다고 느껴지면 「왜 이 테스트가 불안정한가」를 분석합시다. 대부분의 경우 「자동화해서는 안 되는 테스트를 무리하게 자동화하고 있는 것」이거나 「테스트 설계에 문제가 있는 것」중 하나입니다. 전자라면, 과감하게 수동 테스트 또는 부분 자동화로 전환하는 것이 정답입니다.

자동화해야 할지 판단하는 체크리스트란？

고민될 때는 이 체크리스트를 사용하세요. 3개 이상 「예」라면 자동화 검토, 2개 이하라면 수동 우선입니다.

체크 항목	예	아니오
같은 테스트를 월 2회 이상 실행하는가?	✅	❌
합격/불합격의 판단 기준이 명확하게 숫자·문자로 정의할 수 있는가?	✅	❌
사양이 3개월 이상 변하지 않았는가? (하나의 기준으로서)	✅	❌
외부 서비스·실결제·물리 디바이스에 대한 의존이 없는가?	✅	❌
테스트 환경을 안정적으로 재현할 수 있는가?	✅	❌
인간의 감성·직관·판단 없이 합격/불합격을 결정할 수 있는가?	✅	❌
자동화 코드의 유지보수에 할애할 수 있는 공수가 있는가?	✅	❌

FAQ

Q. Flaky 테스트는 왜 CI/CD에 악영향을 미치나요?

Flaky 테스트가 많아지면 「테스트가 실패해도 실제 버그인지 알 수 없다」는 상태가 됩니다. 결과적으로 「실패해도 무시하고 머지한다」는 문화가 뿌리내려 테스트 전체에 대한 신뢰가 사라집니다. Flaky의 근본 원인으로 많은 것은 「사양이 불안정한 단계에서의 조기 자동화」「외부 의존이 강한 테스트의 자동화」입니다. 먼저 「이 테스트는 자동화해야 하는가」를 재검토하는 것이 첫 번째 대처법입니다.

Q. 탐색적 테스트는 완전히 자동화할 수 없나요?

monkey testing·fuzz testing·AI-assisted testing 등 「탐색적에 가까운 접근법」을 자동화하는 것은 가능합니다. 다만 이것들은 「랜덤 입력이나 학습 기반으로 예기치 않은 동작을 찾는」것입니다. 「숙련 QA 엔지니어가 가설을 세우고, 직관과 경험을 바탕으로 시험한다」는 인간 주도의 탐색적 테스트의 본질은, 현재 도구로는 재현할 수 없습니다. 탐색적 테스트의 형식(세션 기반 테스트·차터드 탐색 등)은 자동화할 수 없지만, 그 전후의 준비나 기록 지원에 도구를 활용하는 것은 유효합니다.

Q. Visual Regression Testing은 자동화 대상이 되나요?

「이전과의 차분을 감지하는」용도라면 자동화할 수 있습니다. Percy·Applitools 등의 도구가 대표적입니다. 다만 「그 차분이 문제인지 여부」의 판단은 사람이 할 필요가 있습니다. VisReg는 「변화 알림 도구」로 자동화하고, 「판단」은 수동으로 하는 하이브리드 접근법이 실무에서는 일반적입니다.

Q. 외부 결제 서비스의 테스트는 완전히 수동으로 해야 하나요?

샌드박스 환경이 제공되는 경우(Stripe·PayPal 등)는 그 범위에서 자동화할 수 있습니다. 자동화해서는 안 되는 것은 「본번 환경의 실결제 플로우」에 한정됩니다. 「샌드박스에서 자동화 ＋ 본번의 최종 확인을 월 1회 수동」이라는 조합이 현실적인 선택입니다.

Q. 「자동화하지 않는 판단」을 하면 팀의 이해를 얻기 어려운데요?

「왜 자동화하지 않는가」를 정량적으로 설명하는 것이 효과적입니다. 예를 들어 「이 테스트 케이스의 자동화에 3일 걸린다. 수동 실행은 15분, 월 1회만 실행한다」는 경우, 자동화 비용을 회수하려면 3년 이상 걸립니다. 「3년 후에도 같은 사양으로 이 테스트를 계속 사용할 것인가?」라고 물으면 판단이 흔들리지 않게 됩니다. 실행 빈도·사양 안정성·유지보수 공수의 3가지 축으로 시산하는 것을 권장합니다.

Q. 자동화하지 않는 테스트는 어떻게 관리하면 되나요?

「수동 테스트 실시 기록」으로 별도 관리하는 것이 일반적입니다. TestRail이나 Notion 등의 테스트 관리 도구에 「수동 테스트 전용」카테고리를 만들어, 실시자·일시·결과를 기록합니다. 「수동 테스트의 표준화」가 되어 있으면 특정인에게 의존하는 것을 방지하고 품질이 안정됩니다.

📖 관련 기사

「전부 자동화하자」고 하는 것보다, 「이것은 자동화하지 않는다」고 판단하는 쪽이, 실은 더 어렵고 가치가 높습니다. 자동화하지 않는 판단을 망설임 없이 할 수 있는 QA 엔지니어는, 팀의 자동화 전략 전체를 건전하게 유지할 수 있습니다. 「자동화할 수 있다」와 「자동화해야 한다」를 항상 구별하는 것이, 지속 가능한 자동화의 조건입니다.

📋 이 기사의 정리