테스트 레벨의 의미와 적용법, 단위·통합·시스템을 어디까지 봐야 할까

테스트를 처음 맡거나 SW 테스팅 수업을 들을 때 가장 많이 부딪히는 주제가 바로 테스트 레벨의 의미와 적용법입니다. 단위, 통합, 시스템, 인수라는 말은 익숙한데, 막상 프로젝트에 넣으려 하면 “이 결함은 어느 레벨에서 잡았어야 했나?”라는 질문 앞에서 흐려집니다. 현장에서는 테스트를 많이 했느냐보다 어떤 수준에서 무엇을 확인했느냐가 더 중요했습니다. 같은 결함도 단위에서 잡으면 몇 분 만에 끝나고, 시스템 단계까지 끌고 가면 수정 범위와 확인 비용이 커지기 때문입니다.

먼저 구분해야 하는 기준: 대상이 아니라 질문이 다릅니다

테스트 레벨은 단순한 단계 이름이 아닙니다. 저는 설명할 때 항상 “무엇을 시험하느냐”보다 “어떤 질문에 답하려는가”로 나눠서 보라고 말합니다.

• 단위 테스트: 이 코드 조각의 로직이 맞는가
• 통합 테스트: 서로 연결된 요소가 약속한 방식대로 동작하는가
• 시스템 테스트: 완성된 제품이 요구사항과 사용자 흐름을 만족하는가
• 인수 테스트: 실제 업무나 사용 관점에서 받아들일 수 있는가

이 구분이 필요한 이유는 결함의 성격이 다르기 때문입니다. 계산식 오류, 예외 처리 누락, 경계값 실수는 단위에서 잘 보입니다. 반면 필드명 불일치, 인증 토큰 처리 오류, 트랜잭션 충돌 같은 문제는 통합에서 드러나는 경우가 많습니다. 사용자의 주문 흐름이 중간에 끊기거나 권한에 따라 화면이 다르게 보여야 하는 문제는 시스템 레벨에서 봐야 판단이 됩니다.

단위 테스트는 “작게 본다”가 아니라 “빨리 확인한다”에 가깝습니다

단위 테스트를 가장 작게 나눈 코드 검증이라고만 설명하면 실무 감각이 잘 안 들어옵니다. 실제로는 피드백 속도가 핵심입니다. 함수, 메서드, 클래스 같은 작은 단위를 분리해서 보는 이유도 수정 후 다시 돌려보기 쉽기 때문입니다.

예를 들어 할인 금액 계산, 포인트 적립 규칙, 비밀번호 정책 검사, 배송비 조건 분기처럼 규칙 중심의 로직은 단위 테스트 효율이 높습니다. 여기서는 보통 이런 점을 확인합니다.

• 정상 입력에서 기대 결과가 나오는지
• 경계값에서 다른 결과가 튀지 않는지
• 예외 상황에서 오류를 제대로 처리하는지
• 상태 변경이 의도와 같은지

다만 단위 테스트가 강력하다고 해서 실제 환경의 문제까지 대신해주지는 않습니다. 목(Mock)이나 스텁(Stub)을 잘 써도 외부 API 지연, 실제 DB 설정, 브라우저 렌더링 차이까지 그대로 재현되지는 않습니다. 그래서 단위 테스트를 많이 작성했더라도 연동 결함이 남을 수 있습니다.

통합 테스트에서 생각보다 많이 터지는 것들

실무에서 장애 보고를 보면 개별 모듈 자체보다 연결부에서 문제가 생기는 일이 적지 않습니다. 각자 보면 멀쩡한데 함께 붙이면 깨지는 경우입니다. 통합 테스트는 바로 그 지점을 겨냥합니다.

자주 보는 유형은 이렇습니다.

• 프론트엔드 요청 필드명과 백엔드 수신 필드명이 다름
• API 문서에는 선택 필드인데 실제 서버에서는 필수 처리됨
• DB 반영 시점과 메시지 발행 시점이 어긋남
• 외부 인증 만료 토큰 처리 누락
• 재시도 로직이 중복 실행을 만들어냄

여기서 중요한 것은 “두 모듈이 연결되었다”는 사실만 확인하는 것이 아닙니다. 실패했을 때 어떻게 반응하는가도 함께 봐야 합니다. 성공 경로만 통과시키면 실제 운영에서 흔한 타임아웃, 일시 장애, 잘못된 응답 형식 같은 문제가 빠지기 쉽습니다.

직접 테스트 케이스를 정리할 때 저는 통합 레벨에서 항상 세 가지를 먼저 봅니다. 첫째, 요청과 응답의 형식이 문서와 맞는지. 둘째, 인증·권한·세션처럼 상태가 걸리는 요소가 있는지. 셋째, 실패 후 복구나 재시도 기준이 정의되어 있는지입니다. 이 세 가지가 불명확하면 통합 테스트는 “연결됨 확인” 수준에서 끝나고, 실제 위험은 그대로 남습니다.

시스템 테스트는 사용자 여정을 끊기지 않게 보는 작업입니다

시스템 테스트는 완성된 애플리케이션을 하나의 제품으로 보고 확인하는 활동입니다. 여기서는 개별 기능이 아니라 흐름이 중요합니다. 예를 들어 쇼핑 서비스라면 회원가입, 로그인, 상품 조회, 장바구니, 결제, 주문 확인이 하나로 이어져야 합니다.

이 레벨에서는 보통 다음과 같은 항목을 함께 봅니다.

• 주요 기능 요구사항 충족 여부
• 정상 흐름과 비정상 흐름의 연결성
• 권한별 접근 차이
• 오류 메시지와 복구 경로
• 설정이나 환경 차이에 따른 동작 변화

시스템 테스트를 하다 보면 초보자가 자주 놓치는 부분이 있습니다. 화면 하나하나의 세부 결과만 열심히 확인하고, 앞 단계에서 만든 데이터가 다음 단계에서 어떻게 이어지는지는 덜 보는 경우입니다. 하지만 실제 사용자는 버튼 하나의 내부 로직보다 “처음부터 끝까지 일이 되는가”를 먼저 체감합니다. 그래서 시스템 테스트는 엔드 투 엔드 시나리오 설계가 중요합니다.

인수 테스트는 품질팀의 마지막 검사가 아니라 수용 판단입니다

인수 테스트는 종종 시스템 테스트의 마지막 단계 정도로 오해되지만, 성격이 조금 다릅니다. 시스템 테스트가 제품의 동작을 검증하는 성격이라면, 인수 테스트는 업무적으로 받아들일 수 있는지를 판단하는 과정에 가깝습니다.

여기서 자주 나오는 질문은 이런 것들입니다.

• 실제 사용자 업무 순서와 맞는가
• 필수 요구사항이 빠지지 않았는가
• 운영자가 관리 가능한 수준인가
• 배포 후 바로 사용해도 되는가

즉, 인수 테스트는 “돌아간다”와 “쓸 수 있다”를 구분합니다. 기능은 정상인데 현업이 쓰는 절차와 맞지 않거나 운영상 필요한 로그, 권한, 관리 화면이 부족하면 수용되기 어렵습니다. 이 차이를 놓치면 테스트는 통과했는데 배포가 지연되는 일이 생깁니다.

수업에서 이 개념을 다룰 때 학생들이 가장 많이 실수하는 부분은

수업이나 스터디에서 테스트 레벨을 설명하면, 많은 분이 네 가지를 단순 순서로만 외웁니다. 단위 다음 통합, 그다음 시스템, 마지막 인수처럼요. 그런데 실제로는 순서보다 책임과 목적의 차이가 중요합니다.

특히 많이 헷갈리는 지점은 두 가지였습니다. 하나는 통합 테스트와 시스템 테스트를 같은 것으로 보는 경우입니다. 화면에서 API를 호출해 결과가 보이면 통합도 했고 시스템도 했다고 생각하기 쉽습니다. 하지만 연결 확인과 전체 사용자 흐름 검증은 범위가 다릅니다. 다른 하나는 커버리지 수치가 높으면 품질이 충분하다고 믿는 경우입니다. 직접 실습해 보면 단위 테스트가 촘촘해도 계약 스키마 변경이나 권한 설정 오류는 별도로 남아 있는 일이 많습니다. 숫자는 참고가 되지만, 위험이 어디에 있는지까지 대신 설명해주지는 않습니다.

프로젝트에 적용할 때는 기능보다 위험 기준으로 나누는 편이 현실적입니다

문서에는 테스트 레벨이 깔끔하게 정리되어 있어도, 운영 일정 안에서는 그렇게 예쁘게 분리되지 않습니다. 그래서 현장에서는 기능 목록보다 위험이 큰 지점을 먼저 찾아 레벨별 비중을 정하는 편이 실용적입니다.

예를 들어 이런 식으로 접근할 수 있습니다.

계산 규칙이 많은 기능

쿠폰, 요금, 정산처럼 규칙이 복잡하면 단위 테스트를 두껍게 가져가는 편이 낫습니다. 작은 로직 오류가 누적되기 쉽고, 빠르게 반복 검증할 수 있기 때문입니다.

외부 연동이 많은 기능

결제, 인증, 알림, 파일 업로드처럼 외부 서비스 의존성이 크면 통합 테스트 비중을 높여야 합니다. 이 경우 성공 케이스보다 실패 케이스 설계가 더 중요할 때도 많습니다.

사용자 흐름이 핵심인 기능

회원가입부터 결제 완료까지처럼 한 번의 여정이 중요한 서비스는 시스템 테스트 시나리오를 먼저 정리하는 것이 좋습니다. 기능별 세부 테스트보다 흐름의 끊김 여부가 더 큰 리스크가 되기 때문입니다.

승인 조건이 까다로운 기능

현업 승인, 규정 준수, 운영 준비 확인이 중요한 영역은 인수 테스트 기준을 미리 문서화해야 합니다. 승인자가 누구인지, 어떤 조건이면 보완 요청이 나오는지도 초기에 맞춰두는 편이 안전합니다.

테스트 레벨을 적용할 때 제가 먼저 확인하는 기준

현장에서 빠르게 점검할 때는 복잡한 용어보다 아래 질문이 도움이 됐습니다.

• 이 결함을 가장 싸게 잡을 수 있는 레벨은 어디인가
• 실제 의존성이 없으면 놓치는 위험이 있는가
• 사용자 흐름이 끊기면 업무 영향이 큰가
• 최종 승인자는 품질팀인가, 현업인가, 운영 담당자인가
• 자동화했을 때 유지 비용이 감당 가능한가

이 기준으로 보면 단위·통합·시스템을 기계적으로 모두 늘리는 것보다, 어디에 힘을 줘야 하는지가 보입니다. 시스템 자동화는 멋져 보이지만 유지보수 비용이 커서 핵심 시나리오 중심이 더 현실적일 수 있습니다. 반대로 단위와 통합은 반복 실행 이점이 커서 CI 환경에 얹기 좋습니다.

자주 놓치는 오해 몇 가지

테스트 레벨을 정리할 때 꼭 짚고 넘어가야 할 부분도 있습니다.

첫째, 테스트 레벨과 테스트 유형은 다릅니다. 성능, 보안, 사용성은 레벨이 아니라 유형입니다. 성능 테스트는 시스템 레벨에서 많이 하지만, 어떤 연동 구간은 통합 수준에서도 충분히 볼 수 있습니다.

둘째, 단위 테스트가 많아도 전체 품질을 보장하지는 않습니다. 로직은 맞아도 인터페이스 계약이나 권한 흐름은 별도로 깨질 수 있습니다.

셋째, 인수 테스트는 QA 팀 혼자 끝낼 일이 아닙니다. 수용 기준과 승인 책임자가 불명확하면 마지막에 해석 차이가 생깁니다.

넷째, 종료 기준은 레벨별로 분리하는 편이 낫습니다. 단위는 로직 검증 범위, 통합은 핵심 인터페이스 통과 여부, 시스템은 주요 사용자 시나리오, 인수는 승인 조건 충족 여부처럼 기준이 달라야 관리가 됩니다.

테스트 레벨은 많이 나누는 것보다 맞게 배치하는 것이 중요합니다

실무에서는 테스트가 부족해서 문제가 생기기도 하지만, 자주 보는 문제는 잘못된 레벨에 과도한 기대를 거는 것입니다. 계산 오류를 시스템 단계에서 뒤늦게 찾거나, 외부 연동 문제를 단위 테스트로 모두 막을 수 있다고 보는 식입니다. 그러면 테스트 양은 늘어나는데도 위험은 줄지 않습니다.

정리해 보면 흐름은 단순합니다. 코드 로직은 단위에서, 연결부는 통합에서, 전체 사용자 경험은 시스템에서, 실제 수용 가능성은 인수에서 본다고 기억하면 됩니다. 그 위에 프로젝트 특성, 자동화 비용, 운영 제약을 얹어 조정하는 것이 현실적인 적용법입니다.

참고 자료

• [ISTQB Certified Tester Foundation Level](https://www.istqb.org/certifications/certified-tester-foundation-level)
• [ISTQB Glossary](https://glossary.istqb.org/)