LLM 호출 증가에 따른 비용과 불안정성
- 문제
- 초기에는 LLM으로 처리할 수 있는 범위를 넓혔지만 호출이 늘수록 비용과 불안정성이 커짐
- 해결
- 문서 해석·계획·테스트 생성에 LLM을 사용하고 샘플 조회·실행·판정은 코드로 전환
- 결과
- 각 단계의 책임이 명확한 LangGraph 기반 MVP를 구현
개요
개발 단계에서 작성한 명세를 실제 동작의 확인 기준으로 활용하고자 했습니다. DevOps Engineer와 협업해 회사 백엔드를 대상으로 테스트 생성·실행·실패 보고까지 설계하고 MVP를 구현했습니다.
담당 업무
회사 백엔드를 대상으로 명세 해석, 테스트 생성·실행, 실패 보고까지 MVP를 구현. 일반 요청 중심의 smoke와 경계·오류를 살피는 full 모드를 분리
- 검증 기준
- SPEC과 GraphQL 스키마에서 정상·경계·오류 상황의 기대 결과를 도출
- 실행 범위
- 문서 해석은 LLM이, 실제 데이터 조회와 요청 실행·결과 판정은 코드가 담당
- 환경 고려
- 개발 환경에 미치는 영향을 고려해 핵심 요청 확인과 넓은 검증을 구분
- 설계·구현 범위
- MVP
- 핵심 정상 동작 / 경계·오류
- 2개 모드
- 프로젝트 기여도
- 70%
구조
- 01명세 해석SPEC · GraphQL 스키마
- 02샘플 데이터 조회사전 정의된 데이터 매핑
- 03테스트 생성요청과 기대 결과 구성
- 04실행·결과 확인전체 통과 시 종료
- 05실패 보고서통계 · 선택적 LLM 분석
문제 및 해결
격리된 검증 환경을 마련하기 어려운 조건
- 문제
- 별도 환경을 구축하기 어려워 개발 환경에서 테스트해야 함
- 해결
- API당 일반 요청 한 건을 보내는 smoke를 기본으로 하고, 경계·오류를 포함하는 full을 분리
- 결과
- 필요한 검증 범위와 개발 환경에 주는 영향을 함께 선택하도록 설계
구현 내용
- 선언형 JSON
- 테스트가 사용할 변수, 준비 작업, 요청과 기대 결과를 데이터로 표현하고 실행 헬퍼가 처리
- 샘플 데이터
- LLM이 존재하지 않는 값을 추정하지 않도록 사전 정의한 매핑으로 실제 값을 조회
- 제한된 병렬 실행
- 현재 실행 풀은 최대 5개 작업을 병렬 수행하며 테스트별 통과 여부·시간·오류를 수집
- 종료 조건
- 단계 오류 시 중단하고 allPassed가 참이면 추가 분석 없이 종료. 실패할 때 보고서를 생성
- 모드 선택
- smoke는 핵심 정상 요청, full은 경계·오류 상황까지 포함하도록 검증 목적을 분리