AI 기반 에이전트 개발(Agentic Development)이 보편화되면서 코드 작성, 리뷰, 배포의 속도가 기하급수적으로 빨라졌습니다. 이에 따라 수십 년간 유지되어 온 전통적인 테스트 방법론이 근본적인 도전에 직면하고 있습니다. 정적으로 작성되고 유지보수되는 테스트 슈트는 이제 변화의 속도를 따라잡기 어렵죠. 이 글에서는 이러한 문제를 해결할 혁신적인 접근법인 **Just-in-Time 테스팅(JiTTesting)**의 개념, 특히 'Catching JiTTest'가 어떻게 작동하는지 실무 관점에서 살펴봅니다. 자세한 근거자료는 Meta Engineering 블로그에서 확인할 수 있습니다.
Catching JiTTest는 어떻게 버그를 잡나요?
핵심은 LLM이 코드 변경 사항(풀 리퀘스트)을 분석해 그 변경의 의도와 잠재적 결함을 추론한다는 점입니다. 정적 테스트가 모든 가능성을 미리 정의해야 한다면, JiTTest는 '이번 변경에서 무엇이 잘못될 수 있을까?'에 집중합니다.
주요 프로세스는 다음과 같습니다:
- 의도 추론: 새로 작성된 코드를 분석해 개발자의 의도를 파악합니다.
- 뮤턴트 생성: 의도적으로 결함을 삽입한 변형 코드(뮤턴트)를 생성해 '무엇이 잘못될 수 있는지' 시뮬레이션합니다.
- 테스트 생성 및 실행: 생성된 뮤턴트를 탐지할 수 있는 맞춤형 테스트를 LLM이 즉시 생성하고 실행합니다.
- 신호 평가: 규칙 기반 및 LLM 기반 평가자(Assessor) 앙상블을 통해 실제 결함(True Positive)에만 집중하여 노이즈(False Positive)를 최소화합니다.
- 명확한 리포트: 엔지니어는 복잡한 테스트 코드 없이, 발견된 실제 버그에 대한 명확하고 실행 가능한 피드백만 받게 됩니다.
전통적 테스트 vs. JIT 테스팅 비교
| 항목 | 전통적 테스트 (정적 테스트 슈트) | JIT 테스팅 (Catching JiTTest) |
|---|---|---|
| 생성 시점 | 코드 개발 후 수동 작성 | 코드 변경(PR) 시점에 LLM이 자동 생성 |
| 유지보수 | 지속적인 업데이트와 리뷰 필요 | 코드베이스에 저장되지 않아 유지보수 비용 제로 |
| 포커스 | 일반적인 코드 품질 보장 | 특정 변경 사항에서 발생하는 회귀(Regression) 탐지 |
| False Positive | 높을 수 있음, 관리 비용 큼 | 의도 추론과 앙상블 평가로 최소화 |
| 인적 리소스 | 테스트 작성, 리뷰, 유지보수에 많은 시간 투입 | 버그가 실제로 발견될 때만 인간이 개입 |
| 적응성 | 코드 변경 시 테스트가 깨질 수 있음( Brittle ) | 코드 변경에 따라 테스트 자동 적응 |
이 표에서 알 수 있듯, JIT 테스팅은 테스트의 목적을 '코드 품질 측정'에서 '변경 사항의 위험성 평가'로 근본적으로 전환합니다.
실무 적용을 위한 전망과 고려사항
JIT 테스팅은 특히 마이크로서비스 아키텍처, 빠른 배포 주기(CI/CD), 그리고 AI 에이전트가 상당량의 코드를 생성하는 환경에서 강력한 가치를 발휘할 것입니다. 테스트 팀의 역할도 테스트 코드 유지보수에서, 테스트 생성 LLM의 품질을 관리하고 평가 기준(Assessor)을 설계하는 방향으로 진화할 것으로 예상됩니다.
물론, 아직은 LLM의 추론 능력과 생성된 테스트의 신뢰도에 대한 검증, 그리고 프라이빗 코드베이스에 대한 보안 문제 등 해결해야 할 과제도 많습니다. 그러나 테스트 부담을 기계로 옮기고 엔지니어가 진짜 버그 해결에 집중할 수 있게 한다는 방향성은 분명히 다음 시대의 테스트 인프라를 설계하는 데 중요한 통찰을 줍니다. 에이전트 개발 시대에 테스트가 '속도'를 따라잡을 수 있는 유일한 방법은, 테스트 자체를 동적이고 지능적으로 만드는 것일지 모릅니다.