개발 공부하다 보면 꼭 마주치는 벽이 있어요.
“단위 테스트, 통합 테스트, UI 테스트… 대체 뭐가 다른 거지?”
결론부터 말씀드릴게요.
세 테스트는 검증 범위가 다릅니다. 단위 테스트는 함수 하나, 통합 테스트는 모듈 간 연결, UI 테스트는 사용자 화면 전체를 확인합니다.
그리고 이 셋을 어떤 비율로 섞을지 알려주는 지침이 바로 ’테스트 피라미드’예요. 오늘은 이 개념을 제 경험과 함께 쉽게 풀어보겠습니다.
핵심 요약부터 짚고 갈게요
바쁘신 분들을 위해 먼저 정리합니다.
- 단위 테스트: 함수·클래스 하나만 검증. 빠르고 많이 작성.
- 통합 테스트: 여러 모듈이 연결됐을 때 잘 도는지 검증. 중간 개수.
- UI 테스트: 실제 화면을 클릭하듯 전체 흐름 검증. 느리고 적게.
- 테스트 피라미드: 아래(단위)를 넓게, 위(UI)를 좁게 쌓으라는 원칙.
이 네 줄만 기억해도 절반은 이해하신 거예요. 이제 하나씩 뜯어볼게요.
단위 테스트 통합 테스트 UI 테스트, 뭐가 다른가요?
가장 헷갈리는 부분이니 비유로 시작할게요.
자동차를 만든다고 생각해보세요.
단위 테스트는 나사 하나, 볼트 하나가 규격에 맞는지 보는 검사예요. 아주 작은 단위죠.
통합 테스트는 엔진과 변속기를 연결했을 때 잘 맞물려 돌아가는지 보는 검사고요.
UI 테스트는 완성된 차에 직접 올라타 시동 걸고 운전해보는 검사입니다.
표로 비교하면 이렇게 정리됩니다.
| 구분 | 검증 범위 | 속도 | 작성 개수 |
|---|---|---|---|
| 단위 테스트 | 함수·클래스 하나 | 매우 빠름(ms) | 많음 |
| 통합 테스트 | 모듈 간 연동 | 보통(초 단위) | 중간 |
| UI 테스트 | 사용자 흐름 전체 | 느림(수십 초) | 적음 |
핵심 차이는 ’얼마나 넓게 보느냐’예요.
범위가 넓어질수록 실제 사용 환경에 가깝지만 그만큼 느려지고 관리도 까다로워집니다.
단위 테스트는 이런 느낌이에요
말로만 하면 감이 안 오니 짧은 예시를 볼게요.
아래는 두 숫자를 더하는 함수 하나만 콕 집어 검증하는 단위 테스트입니다.
// 더하기 함수 하나만 검증하는 단위 테스트
func add(_ a: Int, _ b: Int) -> Int {
return a + b
}
@Test func 덧셈_2_더하기_3은_5() {
#expect(add(2, 3) == 5)
}보시면 외부 데이터베이스도, 화면도 필요 없어요. 함수 하나만 딱 떼어내 확인하죠.
그래서 실행이 눈 깜짝할 사이에 끝납니다. 수백 개를 돌려도 몇 초면 되더라고요.
저는 이 빠른 맛에 단위 테스트를 제일 많이 씁니다. 코드를 고치고 바로바로 확인할 수 있으니까요.
테스트 피라미드가 뭐예요?
이제 오늘의 주인공, 테스트 피라미드입니다.
2009년 마이크 콘(Mike Cohn)이 저서 『Succeeding with Agile』에서 제시한 개념이에요. 테스트를 삼각형 모양으로 쌓으라는 지침입니다.
- 맨 아래(넓게): 단위 테스트 — 가장 많이
- 가운데: 통합 테스트 — 적당히
- 맨 위(좁게): UI 테스트 — 최소한
왜 이런 모양일까요?
아래로 갈수록 빠르고 저렴하기 때문이에요. 단위 테스트는 수천 개를 돌려도 부담이 없죠.
반대로 UI 테스트는 느리고 화면이 조금만 바뀌어도 쉽게 깨져요. 유지보수 비용이 큽니다.
값싸고 빠른 테스트를 많이, 비싸고 느린 테스트를 적게. 이게 테스트 피라미드의 전부예요.
참고로 피라미드를 거꾸로 쌓으면 ‘아이스크림 콘’ 안티패턴이라고 불러요. UI 테스트만 잔뜩 있고 단위 테스트가 없는 상태죠. 느리고 잘 깨지는 테스트에 발목 잡히기 딱 좋습니다.
그럼 비율은 어떻게 잡나요?
많이들 궁금해하시는 부분이에요.
흔히 인용되는 기준은 단위 70% : 통합 20% : UI 10% 정도입니다.
다만 이건 절대 법칙이 아니에요. 프로젝트 성격에 따라 유연하게 조절하셔야 합니다.
예를 들어 백엔드 API 서버라면 통합 테스트 비중을 좀 더 높이는 게 실용적이에요. 실제로 구글 같은 곳도 정확한 숫자보다 ’피라미드 모양을 유지하라’는 방향성을 강조합니다.
제가 직접 겪은 조언 하나 더 드릴게요.
숫자에 집착하지 마세요. 중요한 건 ’느리고 깨지기 쉬운 테스트에 너무 의존하고 있지 않은가’를 점검하는 습관입니다.
자주 묻는 질문 (Q&A)
Q. E2E 테스트랑 UI 테스트는 같은 건가요?
거의 비슷하게 쓰이지만 엄밀히는 달라요. E2E(End-to-End)는 사용자 관점의 전체 흐름 검증을 뜻하고, UI 테스트는 그중에서도 화면 조작에 초점을 둡니다. 실무에선 혼용되는 경우가 많아요.
Q. 통합 테스트만 잘 짜면 단위 테스트는 안 해도 되지 않나요?
권장하지 않아요. 통합 테스트는 어디서 문제가 났는지 콕 집기가 어렵거든요. 단위 테스트가 있어야 원인을 빠르게 좁힐 수 있습니다.
Q. 테스트는 처음부터 다 짜야 하나요?
아니에요. 저는 핵심 로직 단위 테스트부터 시작하시길 권해요. 처음부터 완벽한 피라미드를 만들려다 지쳐버리는 경우를 많이 봤습니다.
이 셋의 차이는 글로만 보면 뜬구름 같아도, 직접 코드를 짜보면 몸으로 이해가 됩니다.
오늘 배운 걸로 작은 함수 하나에 단위 테스트를 붙여보는 것부터 시작해보세요. 그 감각이 쌓이면 나머지는 자연스럽게 따라옵니다. 응원할게요!