AI가 주도하는 테스트 환경의 미래에 대한 고찰

이 기사는 GeeCON Kraków 2026에서 진행된 Tom Akehurst의 강연을 각색하였으며, 원래 WireMock 블로그에 게시되었습니다. 강연의 전체 녹화 영상은 YouTube에서 시청하실 수 있습니다.

테스트 환경 (Test environments)은 우리 대부분이 당연하게 여기는 것입니다. 만약 당신이 전문 소프트웨어 개발자라면, 당신의 코드가 dev, QA, staging, 그리고 조직의 예산이 넉넉하다면 UAT 레이어에 이르기까지 익숙한 사전 프로덕션 환경 (pre-production environments) 체인을 거쳐 이동할 가능성이 높습니다. 각 환경은 프로덕션 (production)의 축소된 복제본이며, 각각은 당신의 릴리스 (release)를 더 안전하게 만들어준다고 가정됩니다.

최근 GeeCON에서 이 강연을 했을 때, 저는 청중에게 두 가지 질문을 던졌습니다. 첫째: 이런 환경 설정 (environment setup)과 함께 일하는 분이 계십니까? 거의 모든 사람이 손을 들었습니다. 둘째: 이 환경이 당신에게 문제를 일으킨 적이 없고, 속도를 늦춘 적이 없으며, 배포 (ship)를 못 하게 만든 적이 없다면 계속 손을 들어주세요. 단 한 명만이 손을 들고 있었습니다. 그분은 즐겁게 일하고 계신 것 같아 다행이군요.

그 외의 모든 분들을 위해, 저는 다음과 같은 주장을 하고 싶습니다. 이러한 환경들은 이미 마이크로서비스 (microservices)와 더 빠른 전달 주기 (delivery cycles) 하에서 비명을 지르고 있었으며, AI 코딩 에이전트 (AI coding agents)의 등장은 이를 완전히 끝내버릴 것입니다. 모델을 바꿔야 합니다. 그리고 기존 모델을 망가뜨리고 있는 바로 그 AI가 우리가 새로운 대체제를 구축하는 데 도움을 줄 수 있습니다.

공유 테스트 환경은 이미 우리를 실망시키고 있었습니다

전형적인 장기 유지형, 공유형, 프로덕션 복제 환경은 네 가지 만성적인 문제를 가지고 있으며, 이 목록은 지난 15년 중 어느 시점에 작성했더라도 동일했을 것입니다:

느림 (Slow). 런타임이 느리고, 설정이 느리며, 테스트 데이터를 입력하는 것도 느립니다. 모든 상호작용에 마찰이 발생합니다.
불안정함 (Unstable). 공유 환경은 말 그대로 공유됩니다. 다른 팀들이 미완성된 코드를 배포하고, 데이터를 변경하며, 예측 불가능한 방식으로 부하를 가합니다. 당신의 테스트 워크로드는 다른 모든 사람들에 의해 끊임없이 방해받습니다.
비결정론적 (Non-deterministic). 테스트는 일관성에 의존합니다. 즉, 동일한 동작을 수행하면 동일한 결과가 나와야 합니다. 실행 사이에 데이터가 변해버리면, 테스트의 통과(pass)나 실패(failure)를 신뢰할 수 없게 됩니다.
관찰하기 어려움 (Hard to observe). 결과를 검증한다는 것은 종종 UI에서 볼 수 있는 범위로부터 세 단계나 떨어진 다른 서비스의 데이터베이스에 레코드가 제대로 들어갔는지 확인해야 함을 의미합니다.

짜증스럽지만 견딜 만한 수준입니다. 인간은 고장 난 것을 우회하여 작업하는 데 꽤 능숙하기 때문입니다. 우리는 재시도하고, 판단을 내리며, 고장 난 계단을 생각 없이 넘어갑니다. 하지만 이러한 대처 능력은 바로 지금, 확장성(scaling)의 한계에 부딪히게 될 것입니다.

AI 코딩 에이전트가 짜증을 병목 현상으로 바꾸다

생성형 AI가 여러분의 환경과 충돌하는 방식에는 두 가지 뚜렷한 형태가 있으며, 이를 구분할 가치가 있습니다.

첫 번째는 SDLC(소프트웨어 개발 생명 주기)에 AI를 사용하는 것입니다. 코딩 에이전트, AI 코드 리뷰 등 팀이 더 빠르게 움직이기 위해 시도하는 모든 방법이 여기에 해당합니다. 여기서의 제약 조건은 단순한 산술 문제입니다. 만약 검증되지 않은 코드를 10배 더 많이 생성한다면, 이를 검증하기 위해 존재하는 모든 다운스트림(downstream) 요소들은 엄청난 압박을 받게 됩니다. 그리고 통합 테스트 환경(integrated test environments)은 바로 그 다운스트림의 중심에 위치합니다. 저는 Jason Gorman의 표현 방식을 좋아합니다. 자동차를 더 빠르게 만들었다고 해서 교통 흐름까지 빨라지는 것은 아니라는 말입니다.

플래키니스 (Flakiness, 테스트 불안정성) 또한 악화됩니다. 에이전트(agent)는 사람이 하는 것보다 이를 훨씬 덜 유연하게 처리하기 때문입니다. 사람은 네트워크의 일시적인 끊김으로 테스트가 실패하는 것을 보면, 어깨를 으쓱하며 다시 실행합니다. 하지만 AI 코딩 에이전트는 테스트 실패를 보면 자신이 코드를 망가뜨렸다고 결론 내립니다. 저는 이런 일을 한두 번 겪은 게 아닙니다. 에이전트에게 변경 사항을 적용하고 회귀 테스트 스위트 (regression suite)를 다시 실행하라고 요청했는데, 어떤 일시적인 이유로 테스트 하나가 실패하자, 에이전트가 그것을 "수정"하겠다며 완벽하게 작동하던 코드 더미를 친절하게도 다시 작성해 버린 적이 있습니다. 30분 뒤에 돌아와 보면 엉망진창이 되어 있죠. 플래키한 환경은 에이전트의 속도를 늦추는 정도가 아니라, 아예 잘못된 방향으로 가도록 만듭니다.

두 번째 충돌은 **AI 기반 애플리케이션 구축 (building AI-powered applications)**입니다. LLM 기반 시스템을 중심으로 새로운 테스트 관행이 등장하고 있습니다. 바로 에발 (evals, 평가)인데, 이는 하나의 LLM이 테스트를 주도하고 다른 LLM의 출력을 점수화하는 방식입니다. 이러한 방식은 구조적으로 느립니다 (루프 안에 두 개의 모델이 있기 때문입니다). 따라서 모델과 작업의 매트릭스 전반에 걸쳐 처리량 (throughput)을 확보하려면 엄청난 병렬성 (parallelism)이 요구되며, 이는 기존의 클래식한 테스트가 요구했던 것보다 훨씬 더 많습니다. 이를 속도 제한 (rate-limited)이 걸려 있는 하나의 공유 스테이징 환경 (staging environment)에서 실행하려고 시도해 보십시오.

또한 에발 (evals)은 훨씬 더 강력한 결정론 (determinism)을 요구합니다. 테스트 대상 시스템 자체가 이미 비결정론적 (non-deterministic)입니다. 만약 그 주변 환경이 더 많은 무작위성 (randomness)을 도입한다면, 당신은 혼란 변수 (confounding variables)를 수정하고 있는 셈이 됩니다. 프롬프트 변경 때문에 점수가 변한 것인지, 아니면 밤사이 테스트 데이터가 바뀌어서 변한 것인지 더 이상 구분할 수 없게 됩니다.

정리하자면 이렇습니다. 검증해야 할 코드는 더 많아지고, 에이전트는 플래키니스 (flakiness)를 견디지 못하며, 기존 모델이 공급할 수 없는 수준의 병렬성과 결정론이 필요한 테스트 스타일이 필요합니다. 이것이 바로 생성형 AI (GenAI) 시대에 공유된 프로덕션 복제 환경 (production-replica environment)이 유지 불가능해지고 있다고 제가 말하는 이유입니다.

테스트 환경이란 진정 무엇인가?

대안에 대해 이야기하기 전에, 우리는 작동 가능한 정의를 내릴 필요가 있습니다. 왜냐하면 만약 제가 다섯 명의 사람에게 환경이 무엇인지 묻는다면, 저는 다섯 개의 일관성 있으면서도 완전히 다른 답변을 듣게 될 것이기 때문입니다.

저의 정의는 다음과 같습니다: 테스트 환경이란 테스트 대상 소프트웨어가 기대하는 모든 계약(contracts)의 구현체를 제공하는 무엇이든을 의미합니다. 이러한 계약들은 매우 다른 특성을 가진 계층(layers)으로 나뉩니다:

런타임 (The runtime) - 컴퓨팅(compute), 컨테이너(containers), 오케스트레이션(orchestration). 스택에서 가장 해결된 계층입니다. Docker와 그 친구들은 거의 공짜로 실제 운영 환경과 유사한 런타임을 제공하므로, 이에 대해 길게 설명하지는 않겠습니다.
인프라 서비스 (Infrastructure services) - 데이터베이스(databases), 큐(queues), 캐시(caches). 표면적으로는 "그저 네트워크 서비스"일 뿐이지만, 이들은 범용 제품(commodities)입니다. 컨테이너에 담을 수 있는 오픈 소스 버전이 존재하며, 이를 실행하는 경험은 다른 모든 사람의 경험과 동일합니다. 실제 제품을 축소하여 실행하거나, 클라우드 서비스의 경우 LocalStack 같은 것을 사용하면 됩니다.
도메인 서비스 (Domain services) - 비즈니스를 실제로 실행하는 API들: 귀하의 마이크로서비스(microservices)와 결제, 주문, 풀필먼트(fulfillment), 분석을 처리하는 제3자(third-party) API들입니다. 이곳이 모든 어려운 환경 문제들이 존재하는 곳입니다. 이들은 고유한 의존성 폭포(dependency cascades)와 데이터 요구 사항을 가지고 있습니다. 제3자 샌드박스(sandboxes)는 불안정하거나, 엄격한 속도 제한(rate-limited)이 걸려 있거나, 아예 존재하지 않을 수도 있습니다. 레거시 시스템(Legacy systems)은 복제할 수 없는 베어 메탈(bare metal)에서 실행됩니다. 심지어 귀하의 마이크로서비스조차도 아무도 원치 않는 관리와 유지보수의 부담으로 증식합니다.

이 마지막 두 카테고리를 "둘 다 그냥 네트워크 서비스일 뿐이다"라고 혼동하는 것은 많은 팀이 저지르는 실수입니다. 인프라 서비스는 해결된 문제입니다. 도메인 서비스에는 다른 도구가 필요합니다: API 시뮬레이션 (API simulation).

시뮬레이션을 통해 테스트에 적합한 규모로 환경을 조정할 수 있습니다

API를 시뮬레이션(Simulate)한다는 것은 구현체를 대체함으로써 의도적인 트레이드오프(trade-off)를 수행하는 것입니다. 즉, 어느 정도의 현실성을 포기하는 대신 속도, 신뢰성, 그리고 결정론적 특성(determinism)을 얻는 것이며, 이는 정확히 AI 시대가 요구하는 속성들입니다. 또한 시뮬레이션은 전부 아니면 전무(all-or-nothing)의 방식이 아닙니다. 시뮬레이션을 통해 다음과 같이 단계적으로 확장되는 다양한 환경 형태를 구현할 수 있습니다:

까다로운 부분들을 시뮬레이션하세요. 현대적이고 운영 가능한 서비스들은 실제 상태로 유지하되, 제어할 수 없는 제3자 API(third-party APIs)나 레거시 시스템(legacy systems)은 시뮬레이션하십시오. 많은 고객이 이 단계부터 시작합니다.

테스트 대상의 협업 경계를 제한하세요. 웹 UI와 결제 서비스(checkout service)가 올바르게 통합되는지 테스트하나요? 그렇다면 이 두 가지는 실제로 실행하고, 그 경계(boundary)에 있는 모든 것은 시뮬레이션하십시오. 이처럼 작은 규모의 환경은 풀 리퀘스트(pull request)마다 구축했다가 이후에 바로 폐기할 수 있습니다. 이를 통해 휘발성 환경(ephemeral environments)이 막연한 이상이 아닌 실질적인 방안이 됩니다.

단일 서비스를 격리하세요. 해당 서비스의 직접적인 의존성(dependencies)만을 시뮬레이션하십시오. 이는 가장 작고, 빠르며, 가장 결정론적인 작업 방식입니다.

이 방법들 중 어느 하나가 유일한 정답은 아닙니다. 핵심 기술은 실제 테스트하려는 대상에 맞춰 환경을 매칭하는 것입니다. 판매세(sales tax)가 정확히 추가되는지 확인하는 결제 테스트를 예로 들어보겠습니다. 실제 세금 계산 API가 루프(loop)에 포함되어 있다면, 여러분은 세금 엔진의 동작과 해당 엔진과의 통합을 테스트하게 되며, 여러분의 검증(assertion)은 제품 및 위치에 관한 수많은 전제 조건에 의존하게 됩니다. 만약 여러분이 실제로 관심을 두는 것이 결제 로직(checkout logic)이라면, 세금 API를 시뮬레이션하여(예: 첫 번째 항목은 $2.40 반환, 두 번째 항목은 0 반환) 그 합계에 대해 검증할 수 있습니다. 이는 더 빠르고, 더 단순하며, 의도를 더 정확하게 표현합니다. 만약 객체 모킹(object mocking)을 많이 해보셨다면 이 논리가 익숙하게 느껴질 것입니다. 동일한 판단 기준이 한 단계 높은 수준에도 적용됩니다.

제가 항상 덧붙이는 주의 사항이 하나 있습니다. 모든 시뮬레이션(simulation)은 가정의 경계(assumption boundary)라는 점입니다. 시뮬레이션은 의존성(dependency)이 어떻게 동작하는지에 대한 여러분의 이해를 인코딩하며, 이러한 가정은 반드시 검증되어야 합니다. 이를 위해 어느 정도의 통합 테스트(integrated testing)를 유지하십시오. 또한 실제 서비스들이 함께 실행될 때에만 나타나는 워크플로우 수준의 실패(workflow-level failures)와 용량 문제(capacity questions)를 위해서도 마찬가지입니다. 통합 환경에서 반드시 테스트해야 할 항목에 대해서는 의도적이고 최소한으로 접근하고, 작업 부하의 대부분은 작고 수명이 짧은 시뮬레이션 환경으로 전환하십시오.

함정 — 그리고 AI가 이를 제거하는 방법

이 접근 방식이 이토록 매력적이라면, 왜 모두가 이미 이런 방식으로 일하지 않을까요? 바로 엔지니어링 노력(engineering effort) 때문입니다. 좋은 시뮬레이션을 구축하는 데는 노력이 필요하고, 학습 곡선(learning curve)이 존재하며, 유지보수는 더 어렵습니다. 거대한 마이크로서비스(microservice) 환경에서는 실제 API가 끊임없이 변경되며, 관리되지 않는 시뮬레이션은 더 이상 존재하지 않는 API를 대상으로 테스트가 통과될 때까지 괴리(drift)가 발생합니다.

하지만 반전이 있습니다. 이것이 바로 생성형 AI(generative AI)가 잘하는 바로 그 종류의 작업이라는 점입니다. 이는 단순 반복 작업(grunt work)입니다. 즉, API에 대한 설명을 가져와 다른 형식으로 렌더링하는 것입니다. 이는 에이전트(agent)에게 복잡한 코드베이스 내부의 변경을 요청하는 것보다 훨씬 간단합니다. 우리는 WireMock Cloud에서 우리가 육성해 온 Agent Skills 세트를 사용하여 이런 방식으로 사전 구축된 API 시뮬레이션 라이브러리를 구축해 왔습니다. 하지만 이러한 기술은 도구에 구애받지 않으며(tool-agnostic), WireMock 오픈 소스나 다른 스택에서도 적용할 수 있습니다.

효과적인 워크플로우는 다음과 같이 단계별로 나뉩니다:

생성 (Generation). Claude Code, Cursor, GitHub Copilot와 같은 코딩 에이전트 (coding agent)를 신뢰할 수 있는 정보원 (source of truth)으로 지정하고 시뮬레이션을 요청하세요. 권장되는 정보원은 대략 다음과 같은 순서입니다: 조직 경계 내부라면 실제 서비스 소스 코드 (한 고객은 Sourcegraph를 에이전트에 연결하여 모킹 (mocking)이 필요한 모든 API의 구현부를 찾아 읽도록 설정했습니다); 검증된 OpenAPI 명세서 (저장소에서 한 번 작성되고 방치되는 명세가 아니라, 문서를 생성하거나 운영 프로세스에서 실제로 사용되는 것); 그리고 벤더 SDK (vendor SDKs)로, 이는 고객이 의존하기 때문에 잘 검증되어 있는 경향이 있습니다.
검증 (Verification). 에이전트는 지루함을 느끼거나, 엔드포인트 (endpoints)를 놓치거나, 어떤 스키마 (schema)에도 없는 필드를 환각 (hallucinate)할 수 있습니다. 따라서 기계적으로 검증해야 합니다: 생성된 트래픽을 OpenAPI 검증기 (validator)를 통해 실행하고 모든 오류를 시뮬레이션의 결함으로 취급하거나, 에이전트가 벤더 SDK를 대상으로 테스트 스위트 (test suite)를 생성하도록 하세요. 정적 타입 SDK (statically typed SDKs)는 구조적 문제가 바인딩 실패 (binding failures)로 드러나기 때문에 이 과정에서 매우 유용합니다. 동일한 검증 루프 (verification loop)는 이후의 모든 업데이트에서 발생하는 드리프트 (drift)를 방지합니다.
개선 (Enhancement). 테스트 목표에 따라 현실성 척도 (realism scale)를 높여가세요. 시뮬레이션을 상태 유지형 (stateful)으로 만들고, 에러 응답과 기본값 (defaults)을 추가하며, 데이터를 풍부하게 만드세요. 이때 개선 사항이 계약 준수 (contract conformance)를 깨뜨리지 않도록 매번 검증을 다시 실행해야 합니다. 만약 실제 샌드박스 (sandbox)를 사용할 수 있다면, 먼저 프록시 (proxy)를 통해 트래픽을 기록한 다음 그 매우 현실적인 시작점으로부터 개선해 나가세요.