외부 시스템까지 포함한 AI 자동화 — 개발 자동화와 QA 자동화의 범위 차이

개념

개발 자동화와 QA 자동화의 경계가 다른 이유

AI 코딩 에이전트가 기능을 만들고 단위 테스트·통합 테스트까지 작성하는 일은 이제 흔하다. 그런데 이 자동화는 대부분 우리 시스템의 경계 안 에서 끝난다. 개발자는 결제대행사(PG) 호출부를 인터페이스 뒤로 숨기고, 테스트에서는 그 인터페이스를 가짜 객체로 바꾼다. 개발 관점에서는 옳은 설계다. 내 코드가 맞는지 확인하는 데 외부 시스템이 필요 없기 때문이다.

QA의 질문은 다르다. 사용자가 실제로 겪는 여정이 끝까지 성공하는가. 사용자는 우리 시스템과 PG와 카드사와 본인인증 기관을 구분하지 않는다. 결제 버튼을 눌렀는데 돈은 빠지고 주문은 안 됐다면, 원인이 어느 시스템에 있든 그것은 우리 서비스의 결함이다.

[개발 자동화의 범위]
  ┌──────────────── 우리 시스템 ────────────────┐
  │  화면 → API → 도메인 로직 → DB              │
  │                └→ PG 클라이언트(가짜 객체)   │
  └────────────────────────────────────────────┘
 
[QA 자동화의 범위]
  사용자 → 화면 → API → 도메인 → DB
                    ├→ PG → 카드사 → (승인/거절) → 웹훅으로 결과 통보
                    ├→ 본인인증 기관 → 인증 결과 리다이렉트
                    ├→ 대외기관(신용정보·공공 API) → 조회 결과
                    └→ 제휴사 API(포인트·배송) → 비동기 콜백

현업 결함 통계를 보면 연동 지점이 결함의 주요 서식지인 경우가 많다. 응답 지연, 예상하지 못한 오류 코드, 웹훅 중복·순서 뒤바뀜, 인증서 만료, 상대 시스템의 사전 공지 없는 필드 변경이 대표적이다. 이 결함들은 가짜 객체로 테스트한 코드에서는 절대 드러나지 않는다. 가짜 객체는 개발자가 상상한 대로만 응답하기 때문이다. 그래서 AI로 자동화를 넓힐 때 개발과 QA가 같은 범위를 자동화하면 안 된다. QA 자동화는 경계 밖까지 다뤄야 하고, 그만큼 설계가 어렵다.

외부 의존성 지도 그리기

자동화를 설계하기 전에 우리 서비스가 의존하는 외부 시스템을 모두 적는다. 이 지도가 없으면 E2E 테스트는 "어쩌다 연결되는 것들"의 집합이 된다.

PG 쪽을 예로 들면, 국내 주요 PG는 개발자센터에서 테스트 키를 발급하고 테스트 키로 낸 결제는 실제 출금이 일어나지 않으며 별도의 테스트 결제 내역 화면에서 확인할 수 있게 한다. 반대로 본인인증은 실제 사람의 실명과 휴대폰이 필요해서 완전 자동화가 어려운 대표 영역이다. 지도의 "테스트 환경 제공" 칸이 바로 자동화 전략을 가른다.

실연동·샌드박스·서비스 가상화 — 세 가지 대역

외부 시스템을 테스트에서 다루는 방법은 크게 셋이다.

셋 중 하나를 고르는 문제가 아니다. 단계별로 섞는다. PR마다 실연동을 돌리면 느리고 비싸고 불안정하다. 가상화만 쓰면 상대가 필드를 바꿨을 때 아무것도 모른다. 이 레슨 끝의 계층 배치 표가 그 조합의 예다.

샌드박스의 함정 — "샌드박스에서 됐는데요"

샌드박스는 실제 프로토콜을 거친다는 점에서 가상화보다 믿음직하다. 하지만 운영과 똑같지 않다. QA가 알아야 할 차이는 다음과 같다.

마지막 줄이 실무에서 가장 성가시다. 샌드박스 장애로 야간 회귀가 실패하면 팀은 금방 "외부 연동 테스트는 원래 깨진다"고 생각하고 실패를 무시한다. 그래서 샌드박스 테스트에는 사전 상태 확인(헬스 체크) 을 넣어서, 샌드박스 자체가 죽어 있으면 실패가 아니라 "환경 불가"로 분류한다. 실패 분석 에이전트(레슨 7)가 이 분류를 쓸 수 있게 결과 형식에 칸을 둔다.

서비스 가상화 — WireMock과 Mountebank

서비스 가상화(service virtualization) 는 외부 시스템처럼 응답하는 가짜 서버를 띄우는 기법이다. 단위 테스트의 가짜 객체와 다른 점은 네트워크 수준 에서 동작한다는 것이다. 우리 시스템은 설정의 주소만 바꾸면 되고, 코드는 실제 HTTP 호출을 그대로 한다. 그래서 타임아웃·연결 끊김·잘못된 응답 같은 네트워크 문제까지 재현할 수 있다.

WireMock의 장애 주입 기능은 QA에게 특히 유용하다. 고정 지연과 무작위 지연(로그정규·균등 분포), 응답 본문을 조금씩 흘려보내는 지연, 그리고 빈 응답·잘못된 청크·무작위 데이터 후 연결 종료·연결 리셋 같은 장애 유형을 스텁 단위로 줄 수 있다. 샌드박스에서는 거의 재현할 수 없는 상황들이다.

{
  "request": { "method": "POST", "urlPath": "/v1/payments/confirm" },
  "response": {
    "status": 200,
    "fixedDelayMilliseconds": 31000,
    "jsonBody": { "status": "DONE", "paymentKey": "test_pk_001" }
  }
}

위 스텁은 "PG가 승인은 했지만 31초 뒤에 응답한다"는 상황이다. 우리 시스템의 타임아웃이 30초라면, 사용자에게는 실패를 보여 주고 PG에서는 승인이 끝난 불일치 상태가 된다. 이때 망 취소를 하는지, 웹훅으로 상태를 맞추는지, 사용자에게 무엇을 보여 주는지가 QA가 확인할 기대 결과다. 이런 케이스는 실연동으로는 거의 재현할 수 없고 가상화로만 결정적으로 시험할 수 있다.

Mountebank는 원 개발자가 10년 넘게 유지해 오다 최근 저장소가 공동 관리 체제로 넘어가는 중이라고 밝히고 있다. 도구를 고를 때는 기능 표만 보지 말고 유지보수 상태 를 확인해야 한다. 공식 문서 주소가 바뀐 경우도 있으니, 검색 결과에 나온 옛 도메인이 아니라 저장소 README에 적힌 주소로 들어간다. 오래된 도구의 옛 도메인이 엉뚱한 사이트로 넘어가 있는 일이 실제로 있다.

계약 테스트 — Pact와 그 한계

가상화의 가장 큰 약점은 드리프트 다. 스텁은 녹화한 날의 응답을 기억하고, 상대 시스템은 계속 바뀐다. 이 차이를 잡는 방법이 계약 테스트다(모듈 12 레슨 4·5).

Pact의 기본 흐름은 이렇다. 소비자(우리) 쪽 테스트가 Pact의 가짜 제공자를 상대로 돌면서 "이런 요청을 보내면 최소한 이런 응답이 와야 한다"는 기대를 계약 파일로 남긴다. 제공자 쪽은 이 계약 파일의 요청을 자기 서비스에 재생해, 실제 응답이 계약을 만족하는지 검증한다. 양쪽을 함께 띄우지 않고도 서로의 약속을 확인할 수 있다.

문제는 제공자 검증을 상대가 해 줘야 한다 는 점이다. 사내 마이크로서비스끼리는 가능하지만, PG나 대외기관이 우리 계약 파일을 검증해 줄 리 없다. Pact 문서도 계약 테스트는 메시지(요청·응답)에 집중해야 하며, 양쪽을 모두 검증할 수 있다는 전제를 깔고 있다. 외부 시스템에는 다른 방법을 섞는다.

세 번째 방법은 단순하지만 효과가 크다. 매일 밤 샌드박스에 대표 요청 몇 개를 보내고 응답의 필드 이름·타입·필수 여부 만 뽑아서 어제와 비교한다. 상대가 필드를 추가·삭제·이름 변경하면 다음 날 아침 알림이 온다. 값까지 비교하지 않으니 샌드박스 데이터가 바뀌어도 오탐이 적다.

비동기 흐름 — 웹훅·콜백·리다이렉트

외부 연동의 결함은 동기 호출보다 비동기 통보 에서 더 많이 나온다. 결제 승인 결과, 가상계좌 입금 통보, 배송 상태 변경은 대개 상대가 우리 서버로 웹훅을 보낸다. QA가 확인해야 할 시나리오는 정상 한 건이 아니다.

[웹훅 테스트 시나리오]
1. 정상: 승인 응답 후 웹훅 1회 도착 → 주문 상태 '결제 완료'
2. 중복: 같은 웹훅이 3회 도착 → 결제 완료 처리 1회, 포인트 적립 1회 (멱등성)
3. 순서 역전: '취소' 웹훅이 '승인' 웹훅보다 먼저 도착 → 최종 상태 '취소'
4. 지연: 웹훅이 10분 늦게 도착, 그 사이 사용자가 재결제 시도 → 이중 결제 방지
5. 누락: 웹훅이 끝내 오지 않음 → 상태 조회 API로 보정하는 배치가 동작
6. 위조: 서명이 틀린 웹훅 → 거부하고 보안 로그 기록

샌드박스로는 1번 정도만 재현된다. 2~6번은 가상화 서버가 우리 웹훅 수신 주소로 직접 요청을 보내는 방식으로 시험한다. 이 시나리오들은 레슨 4·5의 방식으로 test basis에서 뽑히지 않는 경우가 많다. 요구사항명세서에 "웹훅 중복 시"를 써 둔 기획 문서는 드물다. 외부 연동 영역은 QA가 오류 추정(모듈 3 레슨 8) 으로 시나리오를 보강해야 하는 대표 영역이다.

테스트 데이터와 비밀정보

외부 연동 자동화는 비밀정보를 다룬다. API 키, 시크릿 키, 인증서, 테스트 계정이다. 원칙은 다음과 같다.

녹화·재생 기능은 편리한 만큼 위험하다. 프록시로 실제 트래픽을 녹화하면 요청 헤더의 인증 토큰과 응답 본문의 개인정보가 스텁 파일에 그대로 저장된다. 그 파일이 저장소에 커밋되는 순간 사고다. 녹화 설정에서 저장할 헤더를 명시적으로 고르고, 커밋 전에 비밀정보 탐지 도구를 돌린다.

AI로 가상화 스텁을 만들 때의 함정

AI 에이전트에게 "PG API 문서를 보고 WireMock 스텁을 만들어 줘"라고 하면 몇 분 만에 그럴듯한 스텁 묶음이 나온다. 생산성은 확실하다. 그러나 다음 함정을 알고 써야 한다.

세 번째 함정이 가장 교묘하다. 에이전트가 우리 코드를 보고 스텁을 만들면, 스텁은 우리 코드가 기대하는 응답을 돌려준다. 테스트는 당연히 통과한다. 자기 자신을 검증하는 순환 이다. 우리 파서가 상대 응답의 필드 이름을 잘못 알고 있어도, 스텁이 같은 잘못을 반복하니 아무것도 드러나지 않는다. 모듈 18c 레슨 3의 항상 통과하는 가짜 테스트가 연동 영역에서 나타나는 형태다. 스텁의 원천은 언제나 상대 쪽 사실 (공식 명세, 샌드박스 실제 응답, 운영 로그의 마스킹된 표본)이어야 한다.

AI를 잘 쓰는 지점은 따로 있다. 상대 명세의 오류 코드 표를 읽어 오류 코드별 스텁 골격을 빠짐없이 만드는 일, 운영 로그에서 실제 지연 분포를 뽑아 무작위 지연 설정값을 제안하는 일, 샌드박스 탐침 결과와 스텁의 구조 차이를 사람이 읽기 좋게 요약하는 일이다. 모두 사실을 근거로 반복 작업을 하는 일이다.

AI 에이전트가 외부 시스템을 직접 호출할 때의 안전장치

스텁 생성을 넘어, AI 테스트 에이전트가 E2E 시나리오를 스스로 실행하며 샌드박스나 실연동 환경을 직접 호출하는 구성도 늘고 있다. 브라우저 자동화 에이전트가 결제창까지 진행하고, API 에이전트가 제휴사 샌드박스에 요청을 보낸다. 이때 에이전트의 실수는 우리 시스템 안에서 끝나지 않는다. 상대 시스템에 요청이 쌓이고, 경우에 따라 비용이 발생하고, 호출 제한에 걸려 다른 팀의 테스트까지 막는다.

원칙은 레슨 5의 자율성 단계와 같다. 가상화 환경에서는 에이전트가 자유롭게 탐색해도 되고, 샌드박스에서는 상한과 허용 목록 안에서, 실연동에서는 사람이 승인한 고정 시나리오만 실행한다. 대역이 실제에 가까워질수록 에이전트의 자율성을 낮춘다. 에이전트가 똑똑해져도 이 순서는 바뀌지 않는다. 바뀌는 것은 상대 시스템이 아니라 우리 쪽 능력이기 때문이다.

외부 시스템 포함 E2E — 계층 배치

지금까지의 내용을 파이프라인 단계별로 배치하면 다음과 같다.

이 표의 요점은 같은 기능을 여러 대역에서 서로 다른 목적으로 검증 한다는 것이다. 가상화로 우리 로직의 모든 분기를, 샌드박스로 실제 흐름을, 실연동으로 운영 설정을 본다. 어느 하나가 다른 것을 대신하지 않는다.

계층을 나눌 때 자주 빠지는 것이 시스템 간 테스트 데이터 동기화 다. 우리 DB에는 테스트 회원이 있는데 제휴사 샌드박스에는 그 회원의 포인트 계정이 없거나, 대외기관 샌드박스의 가상 인물과 우리 테스트 계정의 생년월일이 맞지 않아 조회가 실패하는 일이 흔하다. 이런 실패는 결함처럼 보이지만 실제로는 데이터 준비 문제다. 외부 시스템별로 "어떤 테스트 데이터가 어디에 미리 있어야 하는가"를 표로 관리하고, 야간 실행 전에 그 전제를 확인하는 준비 단계를 둔다.

이 준비 단계 결과도 실패 분석의 입력이 된다. 준비 단계가 실패했다면 그날 해당 영역의 실패는 결함 후보에서 빼고 "데이터 미준비"로 분류해, 사람이 불필요한 분석에 시간을 쓰지 않게 한다.

실무에서 왜 필요한가

AI 코딩 에이전트가 개발 속도를 높이면, 외부 연동 코드도 빠르게 바뀐다. 개발 쪽 자동 테스트는 대부분 가짜 객체로 연동부를 대체하니 통과한다. 연동 결함은 그 테스트들을 통과한 채로 QA 단계나 운영까지 내려온다. 개발 자동화가 넓어질수록 경계 밖을 보는 QA 자동화 의 상대적 가치가 커진다.

또한 외부 연동은 결함 비용이 큰 영역이다. 결제 불일치는 고객 민원과 정산 오류로, 본인인증 실패는 가입 이탈로, 대외기관 연동 오류는 규제 이슈로 이어진다. "샌드박스에서 됐다"는 말로는 이 위험을 설명할 수 없다. 대역별로 무엇을 검증했고 무엇을 검증하지 못했는지를 지도로 보여 주는 것이 QA 리더의 일이다.

채용시장에서의 위치

금융·커머스·핀테크 QA 공고에는 "PG·본인인증 등 외부 연동 테스트 경험", "API 모킹·서비스 가상화 도구 활용", "계약 테스트 도입 경험"이 꾸준히 등장한다. AI 자동화 경험을 묻는 공고가 늘면서, AI로 스텁을 만들되 그 스텁을 실제와 대조하는 체계 를 설명할 수 있는 사람이 돋보인다. 면접에서는 "타임아웃 직후 승인 완료" 같은 불일치 시나리오를 어떻게 재현하고 어떤 기대 결과를 세웠는지 구체적으로 말하는 것이 좋다.

실습 과제

과제 1 — 외부 의존성 지도 (20분)

본인이 아는 서비스(쇼핑몰, 배달 앱, 은행 앱 등) 하나를 골라 외부 시스템을 최소 5개 적고, 연동 방식·테스트 환경 제공 여부·비용·대표 위험을 표로 정리한다. 각 시스템에 대해 실연동·샌드박스·가상화 중 어떤 대역을 어느 단계에서 쓸지 정한다.

과제 2 — WireMock 장애 주입 (30분)

WireMock을 독립 실행(또는 컨테이너)으로 띄우고, 가상의 결제 승인 API에 대해 스텁 네 개를 만든다. 정상 응답, 31초 지연 응답, 연결 리셋, 문서에 있는 거절 오류 코드 하나. curl이나 간단한 스크립트로 호출해 각각 어떤 증상이 나는지 기록하고, 우리 시스템이라면 각 상황에서 무엇이 기대 결과여야 하는지 적는다.

과제 3 — 웹훅 시나리오 설계 (20분)

가상계좌 입금 통보 웹훅에 대해 본문의 여섯 가지 시나리오(정상·중복·순서 역전·지연·누락·위조)를 각각 테스트 케이스로 쓴다. 전제 조건, 가상화 서버가 보낼 요청, 결정적 오라클(DB 상태·적립 횟수·로그)을 포함한다.

과제 4 (선택) — AI 스텁 생성과 대조 (30분)

공개 API 문서가 있는 서비스 하나를 골라, LLM에게 그 문서만 주고 WireMock 스텁 다섯 개(성공 2, 실패 3)를 만들게 한다. 생성된 스텁의 필드와 오류 코드를 공식 문서와 한 줄씩 대조해 지어낸 것, 문서 버전이 다른 것, 누락된 것을 표시한다. 대조 결과를 바탕으로 스텁 생성 지시문에 넣을 규칙 세 개를 쓴다.

자가 체크리스트

• 개발 자동화와 QA 자동화의 범위가 왜 다른지 시스템 경계 그림으로 설명할 수 있다
• 외부 의존성 지도를 그리고 시스템별 테스트 환경 제공 여부와 위험을 정리할 수 있다
• 실연동·샌드박스·서비스 가상화의 장단점과 쓰는 단계를 구분할 수 있다
• 샌드박스와 운영의 차이 때문에 놓치는 결함 유형을 말할 수 있다
• WireMock·Mountebank의 녹화·재생, 상태 기반 응답, 장애 주입을 어디에 쓰는지 안다
• Pact가 외부 시스템에 바로 맞지 않는 이유와 대안(명세 대조·구조 탐침)을 설명할 수 있다
• 웹훅의 중복·순서 역전·지연·누락·위조 시나리오를 설계할 수 있다
• 테스트 키 분리, 녹화 데이터 마스킹, 실결제 스모크 통제를 설명할 수 있다
• AI로 스텁을 만들 때 우리 코드를 베끼는 순환 문제를 알아보고 막을 수 있다
• 대역이 실제에 가까울수록 에이전트 자율성을 낮추는 안전장치(호출 상한·허용 호스트·고정 시나리오)를 설계할 수 있다
• 외부 시스템별 전제 테스트 데이터를 표로 관리하고, 실패를 환경 불가·데이터 미준비·결함 후보로 나눌 수 있다

흔한 실수

개발의 가짜 객체 테스트를 연동 검증으로 착각한다. 가짜 객체는 개발자가 상상한 응답만 한다. 연동 결함은 거기서 드러나지 않는다.

샌드박스 실패를 습관적으로 무시한다. 헬스 체크로 환경 불가와 결함 후보를 나누지 않으면 진짜 결함도 묻힌다.

녹화한 스텁을 그대로 커밋한다. 토큰과 개인정보가 저장소에 남는다. 저장할 헤더를 고르고 마스킹한 뒤 비밀정보 탐지를 거친다.

스텁을 한 번 만들고 대조하지 않는다. 상대 시스템은 계속 바뀐다. 스텁마다 마지막 대조 날짜를 관리한다.

AI에게 우리 코드를 주고 스텁을 만들게 한다. 스텁이 우리 구현의 잘못을 그대로 복제해 테스트가 항상 통과한다. 스텁의 원천은 상대 쪽 사실이다.

데이터 미준비를 결함으로 보고한다. 제휴사 샌드박스에 테스트 회원의 계정이 없어서 난 실패를 결함으로 올리면, 개발팀은 재현이 안 된다며 반려하고 QA 리포트의 신뢰가 떨어진다. 준비 단계에서 전제 데이터를 먼저 확인하고, 실패를 환경 불가·데이터 미준비·결함 후보로 나눠 보고한다.

AI 에이전트에게 실연동 환경의 자유 탐색을 허용한다. 대역이 실제에 가까울수록 자율성을 낮춰야 한다. 실연동은 승인된 고정 시나리오만.

정상 경로만 자동화한다. 외부 연동의 가치는 지연·오류 코드·비동기 이상 상황에 있다. 이 부분은 test basis에 잘 안 나오므로 오류 추정으로 보강한다.

참고 자료

• WireMock — Record and Playback
• WireMock — Simulating Faults
• Mountebank (GitHub 저장소)
• Pact Docs — How Pact works
• PactFlow — Bi-Directional Contract Testing Guide
• 토스페이먼츠 블로그 — 개발 연동을 위한 API 키 확인하기
• 이 커리큘럼 안: 모듈 3 레슨 8 「경험 기반 기법 — 오류 추정」, 모듈 12 레슨 4 「OpenAPI 계약 테스트」·레슨 5 「Pact」, 모듈 18c 레슨 3 「항상 통과하는 가짜 테스트」