테스트 자동화에는 주로 「단위 테스트」「API 테스트」「통합 테스트」「UI 테스트（E2E）」등 여러 종류가 있으며, 목적과 테스트 대상에 따라 적절한 방법을 사용하는 것이 중요합니다.
📌 이런 분께 추천합니다
- 테스트 자동화를 시작하고 싶지만 무엇부터 해야 할지 모르는 분
- 단위·통합·API·E2E 테스트의 차이를 제대로 정리하고 싶은 엔지니어
- 팀에 테스트 자동화를 도입할 때 종류를 설명해야 하는 분
- 테스트 피라미드 개념을 실무에서 활용하고 싶은 QA 담당자
✅ 이 글을 읽으면 알 수 있는 것
- 단위·통합·API·E2E 테스트 각각의 목적과 특징
- 4종류의 테스트를 어떻게 조합하는가（테스트 피라미드）
- 각 테스트에 적합한 도구와 사용 타이밍
- 실무에서 어떤 테스트부터 자동화해야 하는가
📌 이 글의 결론
테스트 자동화의 종류는 크게 4가지——단위·통합·API·E2E 테스트. 각각 커버 범위·속도·비용이 다릅니다. 「테스트 피라미드」의 개념에 따라 조합함으로써 품질을 극대화하면서 비용을 최소화할 수 있습니다.
「테스트 자동화를 도입하고 싶다」고 생각했을 때 가장 먼저 고민하는 것이 「어떤 종류의 테스트를 자동화하면 좋을까」라는 문제입니다.
단위 테스트·통합 테스트·E2E 테스트·API 테스트——이것들은 모두 「테스트 자동화」의 한 종류이지만, 목적도 사용하는 도구도 전혀 다릅니다. 이 글에서는 4종류의 테스트 차이를 정리하고 실무에서 어떻게 조합하는지 해설합니다.
4종류의 테스트 자동화：비교 빠른 참조표
먼저 4종류의 차이를 한눈에 파악해 봅시다.
| 종류 | 테스트 대상 | 실행 속도 | 비용 | 대표 도구 |
|---|---|---|---|---|
| 🧱 단위 테스트 | 함수·클래스 단위 | ⚡ 최속 | 💰 최저 | pytest / JUnit / Jest |
| 🔗 통합 테스트 | 모듈 간 연계 | 🏃 중간 정도 | 💰💰 중간 정도 | pytest / Postman |
| 🌐 API 테스트 | API 요청/응답 | ⚡ 빠름 | 💰💰 중간 정도 | requests / Postman |
| 🖥 E2E 테스트 | 사용자 조작 전체 | 🐢 저속 | 💰💰💰 높음 | Selenium / Playwright / Cypress |
테스트 피라미드：4종류의 이상적인 비율
4종류의 테스트를 어떤 비율로 준비해야 하는지를 나타낸 것이 「테스트 피라미드」입니다. 아래로 갈수록 수가 많고·고속·저비용, 위로 갈수록 수가 적고·저속·고비용입니다.
▼ 테스트 피라미드
① 단위 테스트（유닛 테스트）
어떤 테스트인가
- 개별 함수나 클래스의 동작을 검증하는 테스트
- 개발자가 구현 직후에 실행하는 경우가 많다
- 외부 의존성（DB·API 등）은 목(mock)으로 대체하여 로직만을 순수하게 테스트한다
함수·메서드·클래스 등 코드의 최소 단위가 올바르게 동작하는지를 확인하는 테스트입니다. 외부 의존성을 목으로 대체하여 대상 로직만을 순수하게 테스트합니다.
✅ 적합한 케이스
- 계산 로직·유효성 검사 함수
- 조건 분기가 많은 처리
- 경계값·이상 케이스 확인
- 리팩토링 시 안전망
❌ 적합하지 않은 케이스
- UI 외관 확인
- 복수 모듈에 걸친 처리
- 외부 API와의 실제 통신 확인
| 대표 도구 | Python：pytest / Java：JUnit / JS：Jest |
| 실행 속도 | ⚡ 최속（밀리초~초 단위） |
| 권장 커버리지 | 전체 테스트의 70% 정도를 단위 테스트로 채우는 것이 이상적 |
② 통합 테스트（인테그레이션 테스트）
어떤 테스트인가
- 여러 모듈이나 컴포넌트가 연계하여 올바르게 동작하는지를 검증하는 테스트
- 단위 테스트는 통과해도 모듈을 조합했을 때 발생하는 버그를 검출한다
- DB 읽기/쓰기나 서비스 레이어와 리포지토리 레이어의 연계 확인에 많이 사용된다
복수의 모듈·컴포넌트가 연계하여 올바르게 동작하는지를 확인하는 테스트입니다. 단위 테스트에서는 개별 부품은 동작해도 조합했을 때 문제가 생기는 경우가 있습니다. 그 「이음새」를 검증하는 것이 통합 테스트입니다.
✅ 적합한 케이스
- DB와의 데이터 읽기/쓰기 확인
- 서비스 레이어와 리포지토리 레이어의 연계
- 복수 클래스에 걸친 처리 흐름
- 외부 라이브러리와의 통합 확인
❌ 적합하지 않은 케이스
- 개별 함수의 세밀한 로직 확인
- 브라우저 UI의 동작 확인
- 사용자의 일련의 조작 흐름 전체
| 대표 도구 | Python：pytest / Postman / Spring Boot Test |
| 실행 속도 | 🏃 중간 정도（초~수십 초 단위） |
| 권장 커버리지 | 전체 테스트의 15~20% 정도가 기준 |
③ API 테스트
어떤 테스트인가
- API의 응답과 상태 코드를 검증하는 테스트
- UI를 통하지 않아 고속으로 실행할 수 있다
- 프론트엔드가 미완성이어도 백엔드의 품질을 직접 확인할 수 있다
HTTP 요청을 전송하여 API의 응답이 기대한 대로인지를 확인하는 테스트입니다. 상태 코드·응답 바디·응답 시간 등을 검증합니다. 브라우저를 사용하지 않아 E2E보다 고속이며, 백엔드의 품질을 직접 확인할 수 있습니다.
✅ 적합한 케이스
- REST API의 GET/POST/PUT/DELETE 동작 확인
- 상태 코드의 정확성（200/404/500 등）
- 응답 JSON의 스키마·값 검증
- 인증 토큰·에러 핸들링 확인
❌ 적합하지 않은 케이스
- 브라우저 UI의 동작 확인
- 내부 로직의 세밀한 단위 테스트
- 사용자의 화면 조작 흐름 전체
| 대표 도구 | Python：requests + pytest / Postman / REST Assured |
| 실행 속도 | ⚡ 빠름（초 단위·브라우저 불필요） |
| 권장 커버리지 | 주요 엔드포인트를 망라적으로 커버 |
④ E2E 테스트（엔드투엔드 테스트）
어떤 테스트인가
- 사용자의 조작을 재현하여 실제 동작에 가까운 테스트를 할 수 있다
- 로그인→구매→완료와 같은 일련의 흐름을 자동으로 검증한다
- 실제 브라우저를 실행하기 때문에 다른 종류보다 실행 시간이 걸린다
실제 브라우저를 조작하여 사용자의 일련의 조작 흐름 전체가 올바르게 동작하는지를 확인하는 테스트입니다. 로그인→상품 검색→장바구니 추가→결제 완료와 같은 「사용자 스토리」 단위로 테스트합니다.
✅ 적합한 케이스
- 로그인·회원가입·구매 등 중요 흐름
- 릴리스 전 회귀 확인
- 복수 페이지에 걸친 조작 흐름
- 스크린샷 포함 에비던스가 필요한 경우
⚠️ 주의가 필요한 케이스
- 수가 너무 많으면 CI가 무거워진다
- UI가 자주 바뀌면 유지보수 비용이 높아진다
- 실패 원인 특정이 단위 테스트보다 어렵다
| 대표 도구 | Selenium（Python/Java/JS） / Playwright（Python/JS/TS） / Cypress（JS） |
| 실행 속도 | 🐢 저속（분 단위·브라우저 기동 필요） |
| 권장 커버리지 | 중요한 사용자 흐름에 한정（전체 테스트의 10% 이내가 이상적） |
실무에서 어떤 테스트부터 자동화해야 하는가
「전부 한꺼번에 자동화한다」는 것은 현실적이지 않습니다. 실무에서는 비용 대비 효과가 높은 순서로 단계적으로 도입하는 것이 정답입니다.
▼ 권장 도입 순서
| 스텝 | 테스트 종류 | 이유 |
|---|---|---|
| 1️⃣ | 🧱 단위 테스트 | 작성하기 쉽고·빠르고·저렴. 우선 개발자와 함께 정비하여 자동화 문화를 정착시킨다 |
| 2️⃣ | 🌐 API 테스트 | 브라우저 불필요로 빠름. 백엔드의 품질을 직접 확인할 수 있어 비용 대비 효과가 높다 |
| 3️⃣ | 🔗 통합 테스트 | 모듈 간 연계 버그를 조기에 검출. 단위 테스트만으로는 찾을 수 없는 버그를 커버 |
| 4️⃣ | 🖥 E2E 테스트 | 중요한 사용자 흐름에 한정하여 도입. 최종적인 품질 확인으로 기능한다 |
🔑 실무의 철칙
- 단위 테스트로 「로직」을 지키고, API 테스트로 「인터페이스」를 지키고, E2E로 「사용자 체험」을 지킨다
- E2E는 어디까지나 최후의 보루——수를 줄여서 중요 흐름만 커버한다
- CI/CD에 통합함으로써 코드 push마다 자동 실행되는 품질 게이트를 만든다
📖 각 테스트의 구현 예시는 여기
정리
이 글에서는 테스트 자동화의 4종류——단위·통합·API·E2E 테스트의 차이와 사용 구분을 해설했습니다.
📋 이 글의 정리
- 단위 테스트：함수·클래스 단위로 최속·최저비용. 우선 충실히 만들어야 할 기반
- 통합 테스트：모듈 간 연계를 확인. 단위 테스트에서는 찾을 수 없는 버그를 커버
- API 테스트：브라우저 불필요로 백엔드를 직접 검증. 비용 대비 효과가 높다
- E2E 테스트：사용자 조작 전체를 재현. 중요 흐름에 한정하여 도입하는 것이 요령
- 테스트 피라미드의 이상 비율은 단위 70% / 통합·API 20% / E2E 10%
- 도입 순서는 단위 테스트 → API 테스트 → 통합 테스트 → E2E 테스트가 비용 대비 효과가 높다
「어떤 종류부터 시작하면 좋을지 모르겠다」는 분은 우선 단위 테스트부터 시작해 보세요. 작게 시작해서 조금씩 자동화 범위를 넓혀가는 것이 실무에서의 정답입니다.
다음 글에서는 실제로 Selenium과 Python을 사용하여 E2E 테스트를 구현하는 방법을 해설합니다. 먼저 Selenium으로 링크 끊김을 자동 감지하는 방법 부터 읽어보세요👇
