바이브 코딩을 하는 나…

먼저 기능과 시나리오를 정한 후, 프롬프트를 작성해 개발을 시키고 시스템 테스트를 해. 단위·통합 테스트는 AI를 믿고, 단위 테스트 케이스 정도만 만들어 실행하고 있어.

이런 방법이 맞지 않다는 것은 알고 있는데… QA 관점에서는 어디에 문제가 있는지, 그리고 언제 어디에서 어떤 테스트를 해야 하는지 모르겠어.

핵심 문제점

  • AI가 요구사항을 직접 해석하고 코드를 만든다
  • 이 코드의 통과를 확인하는 테스트도 AI가 만든다.
    • 이 경우 오류가 테스트 기대값까지 전파되는 현상이 나타나는 것으로 보였음(https://arxiv.org/abs/2607.05139).
    • 결함 탐지율도 독립적인 테스트보다 낮았음.

1. 현재 방식의 QA 문제

1. 요구사항 보강이 필요함

  • 입력값의 범위와 경계
  • 오류 발생 시 동작
  • 권한별 차이
  • 중복 요청과 재시도
  • 데이터 정합성
  • 동시 처리
  • 성능과 보안
  • 기존 기능에 미치는 영향
  • 지원하지 않아야 하는 동작

2. AI가 만든 코드와 테스트가 같은 오류를 공유

이 코드의 단위 테스트를 작성해 줘

이렇게만 끝나면 AI는 구현 코드를 기준으로 기대값을 추론할 가능성이 높다.

따라서 개발 프로세스는 다음과 같으면 더 안전하다.

요구사항 → 테스트 조건 및 기대 결과 → 테스트 코드 → 구현 코드

사전에 다음 정보를 제공해야 한다.

  • 요구사항
  • 공개 인터페이스
  • 입력 및 출력 계약
  • 예외 조건
  • 비즈니스 규칙

3. 단위 테스트 방법

통과 여부를 확인하는 데 그치면 안 됨.

result = calculate_price(order)
assert result is not None

다음과 같은 문제가 있는지도 봐야 한다.

  • 실제 비즈니스 결과가 아닌 호출 횟수만 검증
  • 내부 구현을 지나치게 mocking
  • 예외가 발생하지 않는지만 확인
  • 하나의 정상값만 테스트
  • 경계값과 조합 조건 누락
  • 잘못된 기대값을 하드코딩

4. 시스템 테스트에만 의존하면 문제 발견이 늦어진다

기능 정의 → AI 구현 → AI 단위 테스트 → 시스템 테스트(사람 수행)

AI에서 발생한 문제들이 걸러지지 않으면 시스템 테스트에 문제가 집중된다.

그러면 원인이 어디에 있는지 찾기도 어렵다.

  • 프롬프트 문제
  • 요구사항 문제
  • 구현 문제
  • API 계약 문제
  • DB 문제
  • 외부 시스템 문제
  • 환경 설정 문제

5. 비기능적 품질 요소가 누락됨

ISO/IEC 25010:2023은 제품 품질의 비기능적 요소를 다음과 같이 정의함.

  • 성능
  • 보안
  • 사용성
  • 접근성(사용자의 연령이나 장애 여부와 관계없이…)
  • 호환성
  • 유지보수성
  • 장애 복구성
  • 관찰 가능성(쉽게 모니터링할 수 있는가)

2. 그러면 언제, 어떻게 테스트해야 할까(바이브 코딩에서)

단계 1. 기능을 정할 때 테스트 조건을 같이 정의(필요한 항목을 골라 적용)

기능 ID:
사용자 역할: 관리자/일반?
사전 조건: N/A, 다른 부분들은 어떻게 되는가
정상 시나리오:
대체 시나리오:
실패 시나리오:
입력 범위:
상태 변화: 기능 후에 상태가 어떻게 바뀌는가? (구매 → 완료 / 구매 → 거절)
외부 시스템:
보안 및 권한:
성능 조건:
완료 조건:

단계 2. 프롬프트 자체 검증

1. 구현해야 하는 비즈니스 규칙
2. 구현하지 않아야 하는 범위
3. 입력·출력 계약
4. 오류 및 예외 동작
5. 보안 요구사항
6. 기존 시스템과의 인터페이스
7. 인수 조건
8. 테스트 실행 방법
9. 사용 가능한 라이브러리와 금지 라이브러리

AI가 바로 코딩하지 않도록 다음을 확인

코드를 작성하기 전에 다음을 먼저 출력해줘

1. 요구사항에 대한 이해
2. 명시되지 않은 가정
3. 모호하거나 충돌하는 조건
4. 예상되는 실패 시나리오
5. 변경될 파일과 영향 범위
6. 구현 후 실행할 테스트 목록

단계 3. 코드 생성 후 검증

AI가 코드를 생성하거나 수정한 후에는 최소한 다음을 실행하게 한다.

빌드 또는 컴파일
→ formatter
→ lint
→ 정적 타입 검사
→ 단위 테스트
→ 의존성 취약점 검사

단위 테스트에서는 다음을 검증한다.

  • 정상값
  • 경계값(구간별로 결과가 다르다면 구간 경계에 걸친 값을 넣음)
  • 잘못된 입력
  • 예외 처리
  • 비즈니스 규칙(있는 경우)

단계 4. 기능 단위가 완성되었으면 통합 테스트

테스트용 DB와 샌드박스 API를 활용하고, 가급적 mock은 피한다.

  • API와 API
  • API와 DB
  • 서비스와 메시지 큐
  • 백엔드와 외부 API
  • 프론트엔드와 백엔드
  • 인증 서비스와 업무 서비스
  • 파일 시스템 및 클라우드 저장소

이 단계에서는

멱등성: 동일한 동작을 여러 번 해도 동일한 결과가 나오는가

트랜잭션: DB에 결제 결과가 반영되었는가? 취소 시에는 어떻게 되는가?

중복 처리: 할인 쿠폰의 중복 사용이 제대로 처리되는가?

단계 5. 기능 묶음이 완료되었을 때 시스템 테스트

이는 사용자가 통합된 시스템을 대상으로 직접 수행하는 테스트다.

다음을 테스트한다.

  1. 핵심 사용자 여정
    • 가입 → 로그인 → 상품 선택 → 주문 → 결제 → 취소
  2. 부정 시나리오
    • 잘못된 입력
    • 권한 없는 접근
    • 만료 세션
    • 중복 요청
    • 중간 단계 실패
  3. 상태 전이
    • 주문 대기 → 결제 완료 → 배송 중 → 배송 완료
    • 배송 완료 → 결제 대기
    • 취소 완료 → 배송 시작
  4. 교차 기능
    • 주문 취소 후 재고 복구 결제 취소 후 포인트 복구 회원 탈퇴 후 개인정보 접근 차단 권한 변경 후 기존 세션 처리

이 경우 AI에만 맡기지 말고, 사람이 수행하는 탐색적 테스트도 포함하는 게 좋다.

추가: 배포 전 릴리스 품질 게이트

영역 최소 검증
기능 핵심 회귀 테스트
성능 기준 응답시간과 처리량 비교
보안 정적 분석, 의존성 검사, 인증·인가 테스트
데이터 마이그레이션 및 롤백 테스트
호환성 브라우저·OS·API 버전
안정성 타임아웃, 재시도, 장애 복구
운영 로그, 메트릭, 알람 확인
배포 롤백 가능 여부

3. 최소한 적용해야 할 QA

  1. 코드 생성 전에 인수 조건과 실패 시나리오를 작성한다.
  2. 중요 테스트의 기대 결과는 구현 코드를 보기 전에 정한다.
  3. 구현과 테스트를 동일한 프롬프트에서 한 번에 만들지 않는다.
  4. 모든 변경마다 빌드·lint·타입·단위 테스트를 자동 실행한다.
  5. 기능 완료 시 실제 DB와 외부 인터페이스를 포함한 통합 테스트를 한다.
  6. 배포 전 권한·보안·성능·복구·롤백을 별도로 검증한다.