웹 개발 파이프라인에서 인수 테스트(Acceptance Test) 는
“이 기능이 사용자·비즈니스 관점에서 실제로 써도 되는 상태인가”를 확인하는 마지막 검증 단계야.
인수 테스트가 뭐냐면
개발자가 생각한 “정상 동작”이 아니라
기획자·PO·클라이언트·최종 사용자 기준에서
요구사항이 그대로 충족됐는지를 확인하는 테스트야.
그래서 기준은 항상
“요구사항 명세 / 사용자 시나리오”야.
파이프라인에서의 위치
일반적인 웹 개발 파이프라인 흐름은 이래:
코드 작성 → 빌드 → 유닛 테스트 → 통합 테스트 → 인수 테스트 → 배포
인수 테스트는
“배포해도 되는지”를 판단하는 게이트 역할을 해.
인수 테스트에서 보는 것
기술 내부 구현은 거의 안 봐. 전부 사용자 시점이야.
예를 들면
- 회원가입이 실제 사용자 흐름대로 가능한가
- 로그인 후 권한에 맞는 화면이 보이는가
- 결제 버튼을 눌렀을 때 실제 결제가 정상 완료되는가
- 에러 상황에서 사용자에게 올바른 메시지가 나오는가
즉
“기능이 있다”가 아니라
“쓸 수 있다”를 검증함.
다른 테스트랑 차이
유닛 테스트
→ 함수 하나, 컴포넌트 하나가 제대로 동작하는지
통합 테스트
→ 여러 모듈이 연결됐을 때 문제없는지
인수 테스트
→ 실제 사용 시나리오 전체가 문제없는지
그래서 인수 테스트는
- 테스트 범위가 넓고
- 실행 시간이 길고
- 실패하면 배포를 막는 경우가 많아
자동화 vs 수동
둘 다 있음.
자동화 인수 테스트
- Cypress, Playwright, Selenium 같은 E2E 도구 사용
- CI 파이프라인에서 자동 실행
- PR 머지나 배포 전에 통과해야 함
수동 인수 테스트
- 기획자나 QA가 직접 화면을 보면서 체크
- 신규 기능, UI/UX 변경 시 많이 사용
실무에선
자동화 + 중요한 시나리오는 수동 검증
이 조합이 가장 흔해.
프론트엔드 기준 예시
React 웹앱 기준으로 보면 인수 테스트는 이런 느낌이야:
- 사용자가 /login에 접속한다
- 이메일과 비밀번호를 입력한다
- 로그인 버튼을 누른다
- 메인 페이지로 이동한다
- 사용자 이름이 화면에 표시된다
이 “스토리 전체”를 한 번에 검증하는 테스트.
한 줄로 정리하면
인수 테스트는
“이 기능, 지금 사용자에게 내놔도 되나?”를 판단하는 최종 확인 단계야.
웹 개발에서 인수 테스트와 TDD의 관계
웹 서비스를 개발하다 보면 “기능이 완성됐다”는 말이 정확히 무엇을 의미하는지 고민하게 된다.
버그 없이 동작하는 상태일까, 아니면 사용자가 실제로 문제없이 사용할 수 있는 상태일까.
이 질문에 답하기 위해 등장하는 개념이 인수 테스트(Acceptance Test) 이고,
이를 개발 과정에 자연스럽게 녹여내는 방식이 TDD(Test-Driven Development) 다.
이 글에서는 웹 개발 파이프라인에서 인수 테스트가 무엇인지,
그리고 TDD와 어떤 관계를 가지는지 정리한다.
인수 테스트란 무엇인가
인수 테스트는
“이 기능을 사용자에게 배포해도 되는가” 를 판단하기 위한 테스트다.
단위 테스트나 통합 테스트가
코드와 시스템의 정확성을 검증하는 데 초점을 둔다면,
인수 테스트는 사용자와 비즈니스 관점에서 요구사항이 충족되었는지를 확인한다.
즉, 내부 구현이 아니라
기획서, 요구사항 명세, 사용자 시나리오를 기준으로 한다.
예를 들면 다음과 같은 질문에 답하는 테스트다.
- 사용자가 회원가입부터 로그인까지 막힘없이 진행할 수 있는가
- 권한에 따라 접근 가능한 화면이 올바르게 분리되어 있는가
- 결제 버튼을 눌렀을 때 실제 결제가 정상적으로 완료되는가
인수 테스트는 기능 하나가 아니라
하나의 사용자 흐름 전체를 검증한다는 점에서 범위가 넓다.
웹 개발 파이프라인에서의 위치
일반적인 웹 개발 파이프라인은 다음과 같은 흐름을 가진다.
코드 작성 → 빌드 → 유닛 테스트 → 통합 테스트 → 인수 테스트 → 배포
이 흐름에서 인수 테스트는
배포 직전의 최종 검증 단계에 위치한다.
인수 테스트를 통과하지 못한 기능은
기술적으로는 동작하더라도 “완성”으로 간주되지 않는다.
그래서 인수 테스트는 종종 배포를 막는 기준선, 즉 게이트 역할을 한다.
TDD란 무엇인가
TDD는 테스트의 종류가 아니라
개발 방식이다.
일반적인 개발 방식이
“코드를 먼저 작성하고 테스트를 붙이는 것”이라면,
TDD는 그 순서를 뒤집는다.
- 실패하는 테스트를 먼저 작성한다
- 테스트를 통과하는 최소한의 코드를 구현한다
- 리팩토링을 통해 코드를 정리한다
이 과정을 반복하며 기능을 완성해 나간다.
TDD의 핵심은
“테스트가 개발의 기준이 된다”는 점이다.
인수 테스트와 TDD의 연결점
중요한 점은
TDD는 유닛 테스트에만 국한되지 않는다는 것이다.
유닛 테스트로 TDD를 할 수도 있고,
통합 테스트로도 가능하며,
인수 테스트를 기준으로도 TDD를 적용할 수 있다.
이때 등장하는 개념이 ATDD(Acceptance Test-Driven Development) 다.
ATDD: 인수 테스트 기반 개발
ATDD는
인수 테스트를 먼저 정의하고 그 테스트를 통과하도록 개발하는 방식이다.
기능 구현에 들어가기 전에
“이 기능이 언제 완료된 것으로 판단되는가”를
인수 조건으로 명확히 합의한다.
예를 들어 로그인 기능의 인수 조건은 다음과 같을 수 있다.
- 올바른 이메일과 비밀번호 입력 시 메인 페이지로 이동한다
- 잘못된 정보 입력 시 에러 메시지가 표시된다
- 로그인 실패 시 인증 토큰은 저장되지 않는다
이 조건들이 곧 테스트가 되고,
프론트엔드와 백엔드는 이 테스트를 통과하는 것을 목표로 개발된다.
ATDD의 장점은
개발자, 기획자, QA 사이의 “완성 기준”에 대한 오해를 줄여준다는 점이다.
BDD와의 관계
ATDD와 함께 자주 언급되는 개념이 BDD(Behavior-Driven Development) 다.
BDD는
테스트를 기술할 때 구현이 아닌 행동(Behavior) 에 집중한다.
보통 다음과 같은 형태를 사용한다.
- Given 어떤 상태가 주어졌을 때
- When 사용자가 어떤 행동을 하면
- Then 어떤 결과가 발생해야 한다
BDD는
TDD나 ATDD를 사람이 읽기 쉬운 언어로 표현하기 위한 방식에 가깝다.
특히 기획자나 비개발자와 협업할 때 효과적이다.
정리
인수 테스트와 TDD는 서로 다른 개념이지만, 목적은 같다.
“올바른 기능을, 올바른 기준으로 완성하는 것” 이다.
- 인수 테스트는 배포 가능 여부를 판단하는 최종 검증 단계다
- TDD는 테스트를 기준으로 개발을 진행하는 방식이다
- 인수 테스트를 기준으로 TDD를 적용하면 ATDD가 된다
- BDD는 이를 행동 중심으로 표현하는 협업 친화적인 스타일이다
웹 개발에서 인수 테스트와 TDD를 함께 이해하면
단순히 “동작하는 코드”를 넘어서
“사용 가능한 서비스”를 만드는 데 한 걸음 더 가까워진다.