LLM-Based Robustness Testing of Microservice Applications: An Empirical Study

기술 요약: 마이크로서비스 애플리케이션에 대한 LLM 기반 견고성 테스트

문제 제기
마이크로서비스 아키텍처는 malformed(형식이 손상된), 누락된, 또는 경계값 입력이 종속된 서비스 간에 연쇄적으로 전파될 때 신뢰성 위협에 취약합니다. 견고성 테스트는 이러한 입력을 체계적으로 실행하여 서버 측 결함을 노출시키지만, 다양하고 효과적인 테스트 케이스를 생성하는 것은 여전히 큰 과제로 남아 있습니다. 대규모 언어 모델 (LLM) 이 API 명세에서 테스트를 생성할 수 있지만, 서로 다른 모델 아키텍처와 프롬프트 전략이 다양한 실패 모드 집합을 생성하는지, 아니면 동일한 버그로 수렴하는지는 명확하지 않습니다. 기존 연구는 코드 정확성과 컴파일률에 초점을 맞추고 있지만, 실행 중인 마이크로서비스 시스템에서 모델 - 프롬프트 구성을 통해 발견된 실패 모드의 다양성에 대한 경험적 증거는 부족합니다.

방법론
저자들은 두 가지 아키텍처적으로 구별되는 오픈소스 마이크로서비스 시스템에 LLM 기반 테스트 생성을 적용한 통제된 경험적 연구를 수행했습니다:

1. TeaStore: 폼 인코딩 HTTP 를 통해 통신하는 6 개 서비스로 구성된 자바 기반 단일 언어 애플리케이션.
2. OTel Astronomy Shop: JSON API 와 gRPC 를 통해 통신하는 Go, C++, Rust, JS, .NET 등으로 구성된 27 개 서비스의 다언어 애플리케이션.

본 연구는 3 개의 오픈소스 LLM(14B, 32B 코드 특화, 70B 파라미터) 과 세 가지 범주로 그룹화된 7 가지 프롬프트 전략을 활용했습니다:

• 기준선 (Baselines): ZeroShot(API 명세만 제공) 과 Structured(엔드포인트를 변형에 매핑하는 미리 구축된 위반 테이블).
• 확립된 기법: FewShot(실패 패턴의 예시), Chain-of-Thought(CoT), Self-Refine.
• 도메인 지식 전략: Guided(Vieira 등 [1] 의 변형 분류 체계를 컨텍스트로 포함) 와 GuidedFewShot(CRASH 실패 분류를 추가하고 키 누락 대 값 비어 있음 변형을 구분하는 구체적인 예시를 포함).

실험 파이프라인은 Java/JUnit 5 테스트 코드를 생성하고, 출력을 정제하며, 라이브 Docker 배포에 대해 실행한 후, HTTP 상태 코드 $\ge$ 500("Abort" 클래스) 을 기반으로 견고성 실패를 분류하는 과정으로 구성되었습니다. 연구는 소스 코드와 대조하여 검증된 고유한 (엔드포인트, 파라미터, 변형 유형) 3 중항을 **실패 모드 (FMs)**로 정의하여 TeaStore 의 경우 9 개, OTel 의 경우 14 개의 FMs 를 식별했습니다. 다양성은 트리거된 FM 집합의 쌍별 자카드 유사도를 사용하여 측정했습니다.

주요 기여

1. 프롬프트 전략의 우세: 프롬프트 전략이 모델 크기보다 테스트 다양성에서 더 많은 변동을 설명한다는 경험적 증거. 고정된 모델의 프롬프트를 변경하는 것이 고정된 프롬프트 하에서 모델을 변경하는 것보다 더 큰 실패 모드 집합 변동을 유발합니다.
2. 구조적 붕괴 (Structured Collapse): 처방적 프롬프트 (Structured) 가 모든 모델로 하여금 동일한 실패 모드 집합을 생성하게 하여 (자카드 유사도 = 1.00) 다양성을 효과적으로 제거하는 현상의 식별.
3. 새로운 프롬프트 전략: 변형 분류 체계를 도메인 컨텍스트로 포함하는 Guided 및 GuidedFewShot 전략의 도입. GuidedFewShot은 키 제거 대 값 비어 있음 설정과 같은 변형 규칙의 모호성을 구체적인 예시를 통해 해결합니다.
4. 성능 전환: 도메인 지식이 0% 커버리지 구성을 최고 성능 구성으로 전환할 수 있다는 증거. 코드 특화 모델 (qwen2.5-coder:32b) 은 Self-Refine 하에서는 0 개의 실패를 유발했으나 GuidedFewShot 하에서는 단일 실행 최고 커버리지 (TeaStore 57%, OTel 57%) 를 달성했습니다.
5. 단일 모델 대 다중 모델: 단일 모델에 대해 다양한 프롬프트 전략을 적용하는 것이 단일 프롬프트로 여러 모델을 사용하는 것보다 우수함을 입증. 예를 들어, qwen2.5-coder:32b는 세 가지 전략에 걸쳐 프롬프트를 변경함으로써 OTel 에서 100% FM 커버리지를 달성하여 고정된 프롬프트 하의 어떤 다중 모델 앙상블보다 우수한 성과를 거두었습니다.

결과

• 커버리지: 어느 시스템에서도 단일 실행으로 완전한 커버리지를 달성한 경우는 없었습니다 (최대 단일 실행 커버리지는 57%). 그러나 연합 커버리지는 전략에 따라 크게 달라졌습니다. FewShot은 TeaStore 에서 89% 연합 커버리지를 달성한 반면, GuidedFewShot은 OTel 에서 64% 를 달성했습니다.
• 다양성: Structured 프롬프팅은 0% 다양성 (J=1.00) 을 초래했습니다. OTel 에서의 Self-Refine은 가장 높은 다양성 (J=0.00) 을 보였으나 커버리지는 낮았습니다. GuidedFewShot은 높은 커버리지를 유지하면서 낮은 유사성 (높은 다양성) 을 유지했는데, 특히 OTel 에서 (J=0.12) 두드러졌습니다.
• "키 누락"의 한계: 분류 체계 규칙만 제공받은 (Guided) LLM 들은 "키 제거" 변형 (파라미터 키 생략) 을 일관되게 생성하지 못했으며, "null 로 대체"를 값이 빈 문자열로 설정하는 것으로 해석했습니다. GuidedFewShot은 두 변형 유형의 명시적 예시를 제공함으로써 이를 해결했습니다.
• 상태 기반 실패: ZeroShot은 파라미터 중심 전략이 놓친 상태 기반 실패 모드 (예: 인증 없이 장바구니 항목 제거) 를 발견한 유일한 전략이었습니다.

의의 및 주장
이 논문은 마이크로서비스의 견고성 테스트에 있어 모델 선택보다 프롬프트 엔지니어링이 더 중요하다고 주장합니다. 저자들은 단일 모델 - 프롬프트 구성에 의존해서는 안 된다고 강조하며, 이는 시스템의 실패 표면에 대한 불완전한 시각을 제공한다고 말합니다. 대신 다음과 같은 권장 사항을 제시합니다:

• 높은 단일 실행 커버리지와 유지된 다양성으로 인해 단일 모델 - 단일 프롬프트 시나리오에 대한 강력한 기준선으로 GuidedFewShot을 사용하십시오.
• 단일 프롬프트로 여러 모델을 실행하는 것보다 높은 커버리지에 이르는 더 효율적인 경로로 다중 구성 테스트(단일 모델에 대한 프롬프트 변경) 를 활용하십시오.
• 변형 중심 전략이 간과하는 상태 기반 실패를 포착하기 위해 적어도 하나의 ZeroShot 실행을 포함하십시오.
• 도메인 지식(변형 분류 체계) 이 LLM 이 훈련 데이터 분포에 기반하여 오해할 수 있는 프로토콜 수준 구현 (예: HTTP 파라미터 처리) 을 명확히 하기 위해 구체적인 예시와 함께 제공되어야 함을 인식하십시오.

이 연구는 LLM 이 견고성 테스트를 생성할 수 있지만, 그 효과는 도메인 지식이 프롬프트에 어떻게 구성되느냐에 크게 의존하며, 실패 발견을 극대화하기 위해서는 전략의 조합이 필요하다고 결론 내립니다.