테스트 레벨 — 단위·통합·시스템·인수

개념

테스트 레벨은 "무엇을 대상으로, 어느 범위까지 함께 실행해서" 확인하는가를 기준으로 나눈다. 범위가 좁을수록(단위) 빠르고 싸고, 넓을수록(인수) 느리고 비싸지만 더 현실에 가까운 조건을 본다.

레벨	확인 대상	보통 누가	속도·비용
단위(Unit)	함수·클래스 하나가 격리된 상태에서 맞게 동작하는가	개발자	매우 빠름·저렴
통합(Integration)	두 개 이상의 모듈·서비스가 서로 맞물려 동작하는가	개발자, QA	빠름·중간
시스템(System)	전체 애플리케이션이 엔드투엔드로 요구사항대로 동작하는가	QA	느림·비쌈
인수(Acceptance)	실제 사용자·발주자 관점에서 받아들일 만한가	QA, 사용자, 발주자	가장 느림·비쌈

같은 버그, 다른 레벨에서 다르게 보인다

"주문 금액 30,000원 이상이면 무료배송"이라는 기능을 예로 들어본다.

단위: calculateShippingFee(30000) 함수 하나만 떼어서 0을 반환하는지 확인. 다른 함수·DB·네트워크는 전혀 관여하지 않는다.
통합: 장바구니 모듈이 계산한 금액이 배송비 모듈에 정확히 전달되는지 확인. 두 모듈은 각자 단위 테스트를 통과했어도, 금액을 "원" 단위로 주고받기로 한 약속을 한쪽이 "센트"로 착각하면 통합 단계에서만 드러난다.
시스템: 로그인 → 상품 담기 → 결제까지 전체 흐름에서 무료배송이 실제로 적용되는지 확인. 프론트엔드가 계산 결과를 화면에 제대로 반영하는지까지 포함된다.
인수: 실제 사용자가 "이 조건이 헷갈리지 않고 명확한가"까지 포함해서 받아들일 만한 경험인지 확인. 예를 들어 "30,000원 이상"이 배송비 제외 금액인지 포함 금액인지가 헷갈린다면, 계산은 다 맞아도 인수 단계에서 문제로 제기될 수 있다.

네 레벨 모두 통과해도 여전히 확인(Validation, 레슨 2)은 별개다 — 인수 테스트가 확인에 가장 가깝지만, 인수 테스트를 통과했다고 실제 만족도가 보장되진 않는다.

왜 아래 레벨에서 최대한 많이 잡아야 하는가

단위 테스트 하나를 고치는 데는 몇 초, 시스템 테스트에서 같은 결함을 잡으면 환경 셋업과 전체 흐름 재현까지 몇 분~몇 시간이 걸릴 수 있다. 그래서 흔히 "가능한 한 아래 레벨에서 많이, 위로 갈수록 적게" 테스트하라고 한다 — 이걸 그림으로 그리면 피라미드 모양이 된다. 이 피라미드를 실제로 어떻게 설계하고 조직에 맞게 조정하는지는 모듈 11(자동화 전략)에서 자세히 다룬다. 지금은 "레벨마다 비용이 다르다"는 사실만 가져간다.

실무에서 왜 필요한가

QA가 실무에서 자주 받는 질문이 "이 버그는 왜 지금까지 안 잡혔나요?"다. 답은 대체로 "그 조건이 실행되는 레벨에서 테스트를 안 했기 때문"이다. 단위 테스트만 빼곡한 프로젝트에서 서비스 간 계약(API 응답 형식 등)이 깨지는 결함은 통합 테스트 없이는 잡히지 않는다. 반대로 시스템 테스트만 몰아서 하는 프로젝트는 느리고, 실패했을 때 "정확히 어디가 문제인지" 좁히기 어렵다. 어느 레벨에 얼마나 투자할지 판단하는 것 자체가 QA의 전략적 역할이다.

실습 과제

과제 1 — 레벨 분류하기 (10분)

"회원가입" 기능에 대해 아래 각 항목이 어느 테스트 레벨에 해당하는지 적는다.

비밀번호 유효성 검사 함수가 8자 미만을 거부하는지 확인
회원가입 API가 DB에 실제로 사용자를 저장하는지 확인
가입 완료 후 환영 이메일이 실제로 발송되고, 로그인까지 되는지 전체 흐름 확인
실제 사용자가 가입 절차를 어렵지 않게 느끼는지 베타 테스트로 확인

과제 2 — 실패 지점 좁히기 (10분)

"결제 시 할인 쿠폰이 적용 안 됨" 결함이 보고됐다고 하자. 단위·통합·시스템 중 어느 레벨의 테스트가 있었다면 이 결함을 가장 빨리, 가장 저렴하게 잡을 수 있었을지 추론해 적고, 그 이유를 한 문장으로 쓴다.

자가 체크리스트

네 가지 테스트 레벨을 확인 대상 기준으로 구분해 설명할 수 있다
같은 기능의 결함이 레벨에 따라 다르게 드러나는 이유를 예시로 설명할 수 있다
"아래 레벨에서 많이, 위로 갈수록 적게" 원칙이 비용과 관련 있다는 걸 설명할 수 있다
주어진 결함이 어느 레벨의 테스트 부재로 발생했는지 추론할 수 있다

흔한 실수

통합과 시스템 레벨을 혼동한다. "두 모듈이 붙는지"는 통합, "전체 흐름이 되는지"는 시스템이다. 통합 테스트에서 이미 DB·네트워크까지 다 동원해 시스템 테스트처럼 만들어버리면 느려지고 실패 원인 좁히기가 어려워진다.
모든 걸 시스템/인수 레벨에서만 확인하려 한다. 느리고, 실패해도 "어디가 문제인지" 알아내는 데 시간이 오래 걸린다.
인수 테스트를 QA 혼자만의 일로 여긴다. 인수 기준은 원래 발주자·실제 사용자 관점을 반영해야 하는데, QA가 혼자 "이 정도면 됐다"고 판단하면 확인(Validation)의 의미가 옅어진다.

참고 자료

ISTQB Glossary — Test Levels — 단위/통합/시스템/인수 테스트의 공식 정의
Mike Cohn, Succeeding with Agile — 테스트 피라미드 개념이 처음 널리 알려진 출처. 자동화 전략(모듈 11)에서 다시 다룬다