인수 테스트로 요구사항과 릴리스 승인 기준 검증하기

릴리스 판단은 인수 기준에서 시작한다

인수 테스트(Acceptance Test)는 제품이나 서비스가 비즈니스 요구와 규제 요건을 충족하는지 최종 확인하는 단계다. 개발, QA, 비즈니스가 품질과 가치에 대해 같은 기준으로 합의하고, 그 결과를 릴리스 승인 게이트로 사용한다.

검증 범위에는 사용자 시나리오를 다루는 UAT, 운영 적합성을 확인하는 OAT, 계약·규제 준수, 엔드투엔드(E2E) 통합 흐름이 포함된다. 이 과정은 인수 기준(Acceptance Criteria), ATDD(인수 테스트 주도 개발), BDD(행위 주도 개발), Definition of Done/Ready, 그리고 요구사항에서 테스트와 증적으로 이어지는 추적성으로 연결된다.

기준·환경·증적을 함께 설계한다

에픽이나 스토리마다 비즈니스 가설과 수용 기준을 적고, 반복해서 확인할 수 있으며 관찰 가능한 문장으로 표현한다. Gherkin 같은 구조적 형식을 사용할 수 있다. 정상 경로만으로는 충분하지 않으므로 경계와 예외 경로를 포함하고, 데이터 전제·성공 조건·불수용 조건을 구분해 남긴다.

테스트 시나리오는 사용자 여정, 규칙 기반 경계값, 예외·장애·복구를 함께 다룬다. UI, API, 메시지, 배치 레이어별 관측 지점을 정한 뒤 로그·메트릭·이벤트로 증적을 수집한다.

환경은 프로덕션과 유사하게 구성하고, 외부 연동에는 샌드박스와 계약 모킹을 혼용한다. 환경 일치성이 확보되어야 테스트 결과를 릴리스 판단에 사용할 수 있다. 데이터는 마스킹과 합성 데이터를 병행하며, 시딩과 정리를 자동화해 재현성을 유지한다.

자동화는 계약과 서비스(API)를 중심으로 배치하고, 소수의 UI E2E로 사용자 가치 경로를 보장한다. 안정화 대기, 리트라이, 격리로 Flaky를 억제하며, 재실행해도 안전하도록 테스트 아이덴포턴시를 설계한다.

승인 단계에서는 테스트 증적, 패스율, 중대도 기준을 바탕으로 워크플로우를 운영한다. 릴리스 노트와 추적성을 포함한 변경 관리도 이 과정에 속한다. 규제 산업은 리포트 서명과 로그 보존 정책을 포함해 감사 대비를 강화한다.

검증 대상에 따라 테스트의 역할이 달라진다

SaaS 신규 기능은 스토리별 인수 기준을 Gherkin 시나리오로 옮기고, 계약 테스트 통과 후 소수의 UI E2E와 비즈니스 승인 절차를 수행할 수 있다. 마이크로서비스에서는 Consumer-driven Contract로 하위 호환을 검증하고, 이를 프로바이더 파이프라인의 게이트로 삼아 배포 전 안전망을 확보한다.

금융·의료의 규제 준수에서는 OAT로 백업·복구, 장애 전이, 접근통제를 시연하고 감사용 증적 패키지를 만든다. 데이터·ETL 흐름은 수신, 검증, 적재 단계별 규칙 테스트와 샘플링 통계·무결성 검사를 거쳐 리포트를 자동 게시한다.

인수 테스트는 수정과 재검증을 반복한다

⤢✕

UAT·OAT·계약 테스트·E2E의 관측 지점

지표	UAT (사용자 인수)	OAT (운영 인수)	Contract Test (계약)	E2E (엔드투엔드)
비즈니스 적합성	높음: 가치/흐름 검증	중간: 운영 관점 보조	중간: 인터페이스 적합	높음: 실제 여정 검증
안정성/복구	중간	높음: 장애·DR 검증	낮음	중간
일관성/호환	중간	중간	높음: 하위 호환 보장	중간
성능/확장성	중간: 체감 성능	높음: 용량·부하	낮음: 비포커스	중간: 종단 SLA
운영 편의/유지보수	중간	높음	높음	낮음: 비용 높음

결함 유출률(Prod Defect Leakage)은 3060% 감소 가능하고, 릴리스 실패율은 2040% 감소 추정이다. UAT 체류 시간은 2035% 단축되고 롤백률은 1525% 감소할 수 있다. 이와 함께 이해관계자 신뢰, 명확한 승인 기준, 회고 기반의 지속 개선 문화도 기대할 수 있다.

로그인 흐름으로 구성한 최소 자동화 예

전제는 Node.js 18+, @cucumber/cucumber 10+, Playwright 1.48+, 그리고 로컬 앱(http://localhost:3000)에 로그인 폼이 존재한다고 가정한다.

설치 명령은 다음과 같다.

• npm i -D @cucumber/cucumber playwright
• npx playwright install

기능 파일 features/login.feature:

Feature: Login acceptance
  Scenario: Successful login
    Given a user "alice" exists
    When the user logs in with username "alice" and password "secret"
    Then the dashboard shows "Welcome, alice"

스텝 정의 파일 features/steps/login.steps.js:

import { Given, When, Then, BeforeAll, AfterAll, setDefaultTimeout } from '@cucumber/cucumber';
import { chromium, expect } from '@playwright/test';

setDefaultTimeout(60_000);
let browser, context, page;

BeforeAll(async () => {
  browser = await chromium.launch();
  context = await browser.newContext();
  page = await context.newPage();
});

AfterAll(async () => {
  await context?.close();
  await browser?.close();
});

Given('a user {string} exists', async (username) => {
  // 전제 조건 셋업: 필요 시 API 시딩 호출 또는 픽스처 사용
  // await fetch('http://localhost:3000/test-seed', { method: 'POST', body: JSON.stringify({ username }) });
});

When('the user logs in with username {string} and password {string}', async (username, password) => {
  await page.goto('http://localhost:3000/login', { waitUntil: 'domcontentloaded' });
  await page.fill('#username', username);
  await page.fill('#password', password);
  await Promise.all([
    page.waitForNavigation({ waitUntil: 'networkidle' }),
    page.click('button[type="submit"]')
  ]);
});

Then('the dashboard shows {string}', async (text) => {
  const content = await page.textContent('body');
  if (!content?.includes(text)) throw new Error(`Expected to see: ${text}`);
});

실행 명령은 npx cucumber-js다.

배포 게이트를 운영하는 기준

운영 지표는 인수 테스트 패스율, 결함 유출률, UAT 체류 시간, 변경 실패율, 플레키율, 평균 탐지/복구 시간(MTTD/MTTR)으로 구성할 수 있다. 게이트에서는 계약 테스트와 보안 점검을 먼저 수행하고, 중요 시나리오를 위한 최소 UI E2E 세트를 둔 뒤 릴리스 브랜치 머지 전 필수 통과 정책을 운영한다.

요구사항-ID, 시나리오, 테스트 증적(리포트/로그/스크린샷)을 연결해 관리하고, 보존 기간과 접근통제 정책을 정한다. 이 매핑이 있어야 승인 결과와 이후 변경 이력을 추적할 수 있다.

정확도와 운영 비용 사이의 선택

데이터 마스킹은 현실성을 높일 수 있지만 개인정보 노출 위험과 유지 비용을 동반한다. 합성 데이터와 혼합하는 전략이 필요하다. Prod-like 환경은 정확도를 높이는 대신 인프라 비용과 관리 복잡도를 늘리므로, 핵심 경로에만 실물 연동을 선택해 구성할 수 있다.

UI E2E의 범위를 넓히면 사용자 신뢰도는 높아지지만 Flaky와 속도 저하, 유지보수 부담이 커진다. 계약과 API 중심 자동화로 이를 대체하거나 보완한다. Consumer-driven 계약 테스트는 소비자 안전성을 높이는 대신 프로바이더 파이프라인을 복잡하게 하므로 버전 협상과 중재 정책이 필요하다. 테스트 아이덴포턴시는 재시도 안전성을 제공하지만 상태 동기화 비용이 발생하므로, 격리된 데이터 스코프와 시딩 자동화로 다룬다.

가치와 운영 적합성을 배포 결정에 연결하기

인수 테스트는 비즈니스 가치와 운영 적합성을 최종 보증하는 릴리스 게이트다. 명확한 인수 기준, Prod-like 환경, 계약 중심 자동화, 최소 UI E2E, 거버넌스 체계를 결합하고 단계적으로 도입하며 측정 기반으로 개선한다.