[Paper] RESTifAI: LLM 기반 워크플로우를 통한 재사용 가능한 REST API 테스트

Source: arXiv - 2512.08706v1

Overview

이 논문은 RESTifAI라는 새로운 워크플로우를 소개한다. 이 워크플로우는 대형 언어 모델(LLM)을 활용해 REST API에 대한 재사용 가능하고 CI/CD‑ready 테스트를 자동으로 생성한다. 먼저 happy‑path 시나리오에 집중한 뒤 부정적인 경우를 도출함으로써, 성공적인 (2xx) 응답과 오류 (4xx) 응답을 모두 검증하는 신뢰할 수 있는 테스트 스위트를 제공한다—이는 기존 도구들이 종종 간과하는 부분이다.

Key Contributions

• LLM‑구동 테스트 생성: CI 파이프라인에 바로 사용할 수 있는 엔드‑투‑엔드 REST API 테스트를 만든다.
• Happy‑path 중심 전략: 유효한 요청 시퀀스를 먼저 구축하고, 이후 엣지‑케이스(부정) 테스트를 합성한다.
• 재사용 가능한 테스트 아티팩트: 생성된 테스트는 모듈화되어 여러 서비스나 버전에서 쉽게 통합할 수 있다.
• Oracle 단순화: 응답 상태 코드(2xx/4xx)를 주요 테스트 Oracle로 사용해 복잡한 커스텀 어설션의 필요성을 줄인다.
• 최신 도구와의 실증 비교(AutoRestTest, LogiAgent): 커버리지는 비슷하면서 재사용성 및 통합 편의성을 향상시킨다.
• 오픈소스 구현(GitHub) 및 짧은 데모 영상 제공으로 즉시 채택이 가능하도록 한다.

Methodology

1. API Specification Ingestion – RESTifAI는 OpenAPI/Swagger 정의를 소비하거나(또는 실시간 트래픽에서 추론) 활용한다.
2. Prompt Engineering for LLM – 정교하게 설계된 프롬프트가 대형 언어 모델(예: GPT‑4)에게 API 계약을 만족하는 현실적인 요청 페이로드와 시퀀스를 생성하도록 안내한다.
3. Happy‑Path Test Synthesis – LLM은 의도된 워크플로우를 실행하는 유효한 요청/응답 쌍을 만들어 2xx 상태를 반환한다는 것을 검증한다.
4. Negative Test Derivation – 각 happy‑path 테스트에 대해 입력을 변형(예: 필드 누락, 범위 초과 값)하여 4xx 응답을 유도하고, API가 잘못된 혹은 비즈니스 규칙을 위반한 요청을 올바르게 거부하는지 확인한다.
5. Test Code Generation – 도구는 Python/pytest 또는 JavaScript/Jest와 같은 형태의 실행 가능한 테스트 스크립트를 최소한의 보일러플레이트로 출력해 CI/CD에 바로 사용할 수 있게 만든다.
6. Evaluation – 산업용 REST 서비스 벤치마크에서 기능 커버리지, 결함 탐지, 재사용성을 경쟁 LLM 기반 테스트 생성기와 비교한다.

Results & Findings

• Coverage parity: RESTifAI는 AutoRestTest와 LogiAgent와 유사한 기능 커버리지(≈ 85 % 문서화된 엔드포인트)를 달성했다.
• Fault detection: 결함을 주입한 시나리오에서 도구는 92 %의 결함을 포착했으며, 최고 수준 도구와 동등한 성능을 보였다.
• Reusability boost: RESTifAI가 생성한 테스트 스위트는 API 버전 업그레이드 시 수정 비율이 10 %에 불과했으며, 베이스라인 대비 > 30 % 수준이었다.
• Oracle simplicity: 상태 코드 어설션에 집중함으로써 페이로드 수준 비교에서 흔히 발생하는 플레이키 테스트를 회피했다.
• Integration ease: 출력 스크립트는 GitHub Actions, Jenkins, GitLab CI 등 일반적인 CI 파이프라인에서 추가 스캐폴딩 없이 바로 실행될 수 있었다.

Practical Implications

• Faster onboarding: 팀은 새로 설계된 API에 대해 몇 분 안에 기본 테스트 스위트를 구축할 수 있어, 수작업으로 보일러플레이트 테스트를 작성하는 노력을 크게 줄인다.
• Continuous testing: 생성된 테스트가 CI‑ready이므로, API가 진화할 때 회귀를 조기에 포착할 수 있다.
• Improved reliability: happy‑path와 negative‑case 전략을 결합해 기능 성공과 적절한 오류 처리 모두를 검증함으로써 서비스의 견고성을 높인다.
• Cost‑effective QA: LLM 활용으로 도메인‑특화 테스트 작성 부담이 감소하고, QA 엔지니어는 고수준 시나리오 설계에 집중할 수 있다.
• Open‑source adoption: 코드가 공개돼 조직은 프롬프트 템플릿을 커스터마이징하거나 기존 API 관리 도구(Kong, Apigee 등)와 워크플로우를 연동할 수 있다.

Limitations & Future Work

• LLM dependence: 테스트 품질은 기반 언어 모델에 크게 좌우된다; 오래되었거나 작은 모델은 현실감 있는 페이로드를 생성하지 못할 수 있다.
• Oracle granularity: 상태 코드만을 사용하면 깊은 비즈니스 로직 오류를 놓칠 수 있어, 보다 정교한 페이로드 검증이 필요하다.
• Specification quality: 불완전하거나 부정확한 OpenAPI 문서는 의미 있는 테스트 생성 능력을 제한한다.
• Future directions: 저자들은 스키마 검증·계약 기반 어설션 같은 풍부한 Oracle 도입, GraphQL·엔드‑투‑엔드 워크플로우 지원, 이전 테스트 결과로부터 학습하는 적응형 프롬프트 등을 계획하고 있다.

Authors

• Leon Kogler
• Maximilian Ehrhart
• Benedikt Dornauer
• Eduard Paul Enoiu

Paper Information

• arXiv ID: 2512.08706v1
• Categories: cs.SE
• Published: December 9, 2025
• PDF: Download PDF