Meta의 JiTTest — LLM이 코드 변경마다 테스트를 자동 생성하고 폐기하는 방식

요약

Meta가 에이전틱 개발 속도에 맞춰 테스트 패러다임을 재구성. 정적 테스트 스위트를 코드베이스에 두는 대신, PR 제출 시점에 LLM이 변경 의도를 추론 → 의도적 결함 버전(mutant) 생성 → 결함을 잡는 테스트 생성·실행 → 규칙·LLM 평가자 앙상블로 위양성 필터링. 테스트는 보고 후 폐기되어 유지보수·코드 리뷰 비용이 사라짐.

내용

에이전틱 소프트웨어 개발이 확산되면서 코드 작성·리뷰·배포 속도가 가속, 기존 테스트 프레임워크가 따라가지 못함. 전통적 방식은 새 코드가 들어올 때마다 사람이 직접 테스트를 만들고 지속 실행, 정기 업데이트·유지보수 필요. 만드는 사람은 현재 코드뿐 아니라 미래의 모든 변경에 대해서도 동작을 검증해야 함 — 미래 변경에 대한 불확실성 때문에 결국 아무것도 잡지 못하거나 위양성을 내는 테스트가 누적.

에이전틱 개발은 코드 변경 빈도를 급격히 끌어올려, 테스트 개발 부담과 위양성·유지보수 비용을 한계점까지 가중. JiTTest는 이 부담의 출처 자체 — 코드베이스 안에 테스트가 상주한다는 가정 — 를 들어내는 접근.

해결 / 접근

Catching JiTTest 6단계 파이프라인

1. 새 코드가 코드베이스에 도착
2. 시스템이 코드 변경의 의도 추론
3. mutant(고의로 결함을 주입한 코드 버전) 생성 — 가능한 오작동 시뮬레이션
4. 그 결함을 잡는 테스트 생성·실행
5. 규칙 기반 + LLM 기반 평가자 앙상블로 진짜 실패 신호에 집중, 위양성 필터링
6. 엔지니어에게 예상치 못한 변화에 대한 명확한 리포트 전달

핵심 원칙

• 테스트는 코드베이스에 상주하지 않음 — 매 변경마다 새로 생성, 결과만 보고하고 폐기. 유지보수 비용 자체가 발생하지 않음
• 변경 단위에 맞춰 생성되므로 의도된 업데이트로 깨질 가능성이 낮음
• 코드가 바뀌면 테스트도 자동으로 그에 맞춰 다시 만들어짐 (적응 비용 0)
• 사람이 리뷰할 시점은 실제로 버그를 잡았을 때만

Mutation Testing 기반 검증 내장

• LLM이 생성한 테스트가 진짜로 결함을 탐지하는지 확인하기 위해, mutant에서 테스트가 실패하는지 본 단계에서 검증
• 위양성 압박을 줄이는 방향으로 신호를 집중

전통 패러다임 대비 효과

• 일반적 코드 품질 검증 → 특정 변경에서 진짜 결함을 잡으면서 위양성을 안 내는지로 초점 이동
• 사람의 노력을 테스트 코드 작성·리뷰가 아니라 실제 버그 처리에 집중

결과 / 참고

• 테스트 코드 작성·리뷰·유지보수 비용 제거, 위양성 압박 완화
• 논문: Just-in-Time Catching Test Generation at Meta (arxiv:2601.22832)
• 50년 된 소프트웨어 테스팅 이론·실무를 에이전틱 개발 환경에 맞춰 재구성
• 출처: Engineering at Meta (2026-02-11)