LLM 멀티 에이전트로 E2E 테스트 자동 생성 — MAFT

요약

네이버가 검색 엔진 Noir의 E2E 테스트 공백을 메우려 LLM 멀티 에이전트 파이프라인 MAFT를 만듦. 요약 → 의존성 → 시나리오 → 코드 생성 → 검증 5단계로 작업을 쪼개고, 각 단계에 작업 시작·비평·수정 3종 에이전트 배치(AutoGen 기반, GitHub Actions 자동 PR). Noir 6개 API에서 60개+ 테스트 케이스·15개+ 버그 발견, API당 약 10분·$1. 형식 불일치·검증 부담 등으로 CI 통합은 보류.

내용

검색 엔진 Noir는 API 간 의존이 강함. 검색 API를 테스트하려면 문서 입력 API를 먼저 호출해 데이터를 넣어야 하고, 그 입력 API는 또 다른 API들에 의존. API가 늘 때마다 케이스가 곱절로 증가해, 사람이 모든 시나리오를 설계·작성하기 어려운 상황. 그래서 운영 API 다수에 테스트 공백이 생기고, 다른 로직 변경으로 API 동작이 바뀌어도 감지가 늦어지는 리스크가 누적. 출발점은 이 공백.

MAFT(Multi Agents For Testing)는 "API 문서만 주면 테스트 코드와 PR까지 자동"을 목표로 한 사이드 프로젝트. 멀티 에이전트 프레임워크는 AutoGen·MetaGPT·LangGraph를 비교 — LangGraph는 복잡, AutoGen은 도구 기반 책임 분리(에이전트에 도구를 부여하면 그 도구가 곧 역할), MetaGPT는 역할 기반(ProductManager·DataInterpreter처럼 추상화된 Role). 도구 기반이 더 직관적이라 AutoGen 채택. 본문은 5단계 파이프라인과 에이전트 구조, 적용 결과·한계 설명.

해결 / 접근

5단계 파이프라인 (스텝 고정)

1. 요약 문서 생성 — 사람이 쓴 API 문서에서 테스트에 필요한 정보만 표준화된 JSON으로 추출(설명·엔드포인트·파라미터·성공/오류 응답·limitations·note)
2. API 의존성 문서 생성 — 테스트 대상 API에 영향을 주는 API와 호출 순서·이유를 정리, 시나리오의 난도를 끌어올리는 핵심 단계
3. 테스트 시나리오 생성 — preconditions·request·expected_response·required_apis_for_verification·side_effects·verification·cleanup 포함
4. E2E 테스트 코드 생성 — 사용자 프롬프트로 언어·프레임워크·엔드포인트 전달 방식 등 구체 지정 (Python pytest)
5. 테스트 코드 검증 — JSON 형식, 네이밍 컨벤션, API 파라미터 이름 유효성 등 정적 검증

스텝을 고정한 이유: LLM은 큰 단위 작업보다 작은 단위로 쪼갰을 때 정확도가 올라감. "E2E 테스트 생성"이라는 명확한 목표가 있어 동적 스텝 분할은 불필요.

스텝당 3종 에이전트 — 작업 시작 / 비평 / 수정

• 작업 시작: 단계의 주 작업 수행, 첫 결과물은 부족한 경우가 많음 (좋은 모델 권장)
• 비평: 결과물의 잘못된 점·부족한 점 피드백 (가벼운 모델로도 충분)
• 수정: 비평 피드백을 반영해 결과물 수정 (좋은 모델 권장)
• 시작과 수정을 분리한 이유 — 프롬프트가 미세하게 다름 (수정은 피드백을 봐야 하지만 시작은 그렇지 않음). 합치면 에이전트가 역할을 혼동

입력

• 테스트 대상 API뿐 아니라 영향 가능 API까지 포함한 전체 API 문서
• 커스텀 정보(네이밍 컨벤션, 테스트 성공 조건, 라이브러리 지정 등) — 모든 에이전트 프롬프트에 주입
• 요약 문서 정확성 확보 — 비평 단계에서 원본 문서를 다시 참고

GitHub Actions 통합

• 워크플로 실행기가 API 문서 디렉터리·테스트 코드 디렉터리를 docker 컨테이너에 마운트, MAFT 이미지 실행
• 완료 시 저장소에 PR 자동 생성 → 개발자 검토 후 머지

테스트 실행 디버깅 미포함

• 검증을 통과해도 발생하는 버그는 문서 부족 또는 이전 단계 오류 — LLM 자율 디버깅으로 풀리지 않고 도메인 지식 가진 개발자 개입이 필요해 추가하지 않음

결과 / 참고

• 적용: Noir 6개 API에서 60개+ 테스트 케이스 생성, 15개+ 버그 발견 (API당 평균 10개+ 케이스, 2개+ 버그)
• 발견 버그 유형 — 파라미터 조건/기본값/응답 코드와 사용자 문서 불일치 / 배치 입력에서 일부 문서 누락 시 오류 / 입력 공백·특수 문자 시 오류 / 일부 케이스 응답 형식 다름 / 장시간 호출 시 오류
• 부수 효과 — 사이드 이펙트 cleanup이 강제돼 케이스 간 상호 영향 제거, 테스트 반복 호출 안정성 확보
• 비용·시간 — API당 약 10분, $1 / Noir 6개 API 1시간·약 $7
• 한계 (CI 통합 보류 사유)
  • 비용 — API마다 스텝 반복으로 비용이 API 수에 비례
  • 형식 불일치 — 기존 테스트 코드를 참고하지 않아 생성 코드 간 패턴이 다름
  • 검증 부담 — 10개 케이스당 약 1시간 검증 필요
• 부수 학습 — API 문서가 짧고 형식 일관될수록 MAFT 이해도 상승, 엔드포인트·파라미터 cheat sheet를 더하면 정확도 추가 향상, 모델 차이가 버그 개수에 직접 영향(GPT-4o vs GPT-4.1). LLM을 잘 쓰려고 한 결과 사용자 문서 자체가 더 좋아짐
• 다음 단계 — 범용성 대신 Noir·Dot 도메인 특화로 전환해 문서량·스텝 수·비용 절감, 기존 테스트 코드 분석 스텝 추가로 형식 일관성 해결
• 출처: NAVER D2 helloworld