메타, LLM 기반 'JiTTests' 프로덕션 배포로 버그 탐지 강화

JiTTests 프로덕션 배포와 변화

메타는 대규모 언어 모델(LLM)을 활용한 'Just-in-Time Tests (JiTTests)'를 연구 프로토타입에서 프로덕션 인프라의 핵심 부분으로 전환하여 배포했다. 이 시스템은 코드 변경(diff)이 실제 프로덕션 환경에 적용되기 전에 잠재적인 버그를 자동으로 탐지하고 수정할 수 있도록 돕는다. 이번 배포는 'Just-in-Time Catching Test Generation at Meta'라는 제목의 논문으로 FSE 2026에서 발표되고 Product@Scale에서 소개된 바 있다. JiTTests는 기존의 AI 기반 코드 검토 방식과 달리, 코드 변경으로 인해 발생하는 구체적인 동작 차이를 입증하는 실행 가능한 테스트를 생성하는 독자적인 접근 방식을 취한다.

이러한 변화는 메타의 엔지니어들이 더 적은 부하와 낮은 오탐률로 더 많은 버그를 포착할 수 있게 한다. JiTTests는 코드 변경의 의도와 위험을 추론하는 '의도 인식(intent-aware)' 워크플로우와 모든 코드 변경을 잠재적 버그로 간주하여 동작 차이를 노출하는 '수상한 변경(dodgy diff)' 워크플로우를 결합하여 테스트를 생성한다. 이 두 가지 접근 방식은 다양한 유형의 버그를 효과적으로 찾아내도록 설계되었다.

대규모 코드베이스의 테스트 과제

메타는 수억 라인에 달하는 방대한 코드베이스를 지속적으로 발전시키고 있으며, 이는 플랫폼 개선과 동시에 새로운 복잡성을 야기한다. 이러한 환경에서 전통적인 테스트 방식만으로는 코드 변경 속도를 따라잡기 어렵다. 코드가 배포되기 전에 잠재적 위험을 사전에 파악하는 것은 문제를 조기에 식별하고, 효과적으로 대응하며, 대규모 환경에서 안정적인 사용자 경험을 제공하는 데 필수적이다.

지난 1년간 메타는 LLM을 활용한 소프트웨어 테스트 생성 연구를 진행해왔으며, 특히 JiTTests는 기존 테스트로는 놓칠 수 있는 버그까지 실시간으로 포착하는 새로운 테스트 접근법으로 주목받았다. 이번 프로덕션 배포는 JiTTests의 확장성과 광범위한 산업 적용 가능성을 검증하는 중요한 단계이다.

JiTTests의 구체적인 동작 방식

JiTTests 시스템은 총 다섯 단계로 구성된 워크플로우를 통해 작동한다. 첫 번째 '타겟팅 및 트리거링' 단계에서는 시스템이 야간에 유휴 자원을 활용하여 Diff Risk Score (DRS)와 유사한 메커니즘으로 '위험하다고 판단되는' 전날 제출된 코드 변경 사항을 대상으로 테스트 생성을 집중한다. 이는 심각한 회귀(regression)를 포함할 가능성이 높은 변경 사항에 초점을 맞추기 위함이다.

두 번째 '두 가지 변경 인식 테스트 생성 워크플로우' 단계에서는 '수상한 변경' 워크플로우가 각 변경 사항을 변이(mutant)로 간주하고 LLM 기반 테스트 생성을 통해 부모 코드와 변경된 코드의 동작 차이를 식별하는 테스트를 만든다. 동시에 '의도 인식' 워크플로우는 LLM을 사용하여 코드 변경, 제목, 요약에서 변경의 의도를 추론하고, 그 의도를 구현하는 과정에서 발생할 수 있는 '위험'을 설명한다. 이 위험 설명을 바탕으로 잠재적 버그를 나타내는 변이를 구성하고, 이 변이를 '죽이는' 테스트를 생성하여 실제 변경 사항에 적용한다. 실패한 테스트는 '약한 포착(weak catches)'으로 수집된다.

세 번째 'LLM-as-Judge 앙상블' 단계에서는 생성된 약한 포착이 오탐(false positive)인지 실제 버그(strong catch)인지 자동적으로 평가한다. 여러 SOTA LLM으로 구성된 이 앙상블은 약한 포착 테스트 코드, 테스트 실행 결과, 코드 변경 사항, 추론된 변경 의도를 검토하여 분류한다. 네 번째 '규칙 기반 평가자 (RubFake)' 단계는 LLM-as-Judge를 보완한다. RubFake는 검증되고 결정론적인 판단을 제공하며, LLM-as-Judge와 함께 약한 포착 후보들의 전반적인 순위를 매겨 추가 검토 가치가 있는 항목을 식별한다.

마지막 다섯 번째 'Human-on-the-Loop (엔지니어 연락)' 단계에서는 LLM-as-Judge와 RubFake의 순위 결과를 바탕으로 시스템이 인간 엔지니어에게 연락할지 여부를 결정한다. 이는 모든 출력을 인간 엔지니어가 검토하는 'Human-in-the-Loop' 방식과 달리, 엔지니어가 기준을 설정하고 집계된 수준에서 결과를 검토하며, 개별 출력보다는 정책 수준에서 개입하는 'Human-on-the-Loop' 접근 방식을 통해 마찰을 줄인다.

개발자 및 사용자에게 미치는 영향

JiTTests의 배포는 메타의 소프트웨어 개발 프로세스에 긍정적인 영향을 미치고 있다. 현재까지 메타 엔지니어 589명(전체 연락 대상의 64%)이 JiTTests와 상호작용했으며, 이들은 JiTTests가 실제로 조치 가능한 발견 사항을 제공한다고 보고했다. 특히, 60%의 높은 진양성(true positive)률을 기록하여 시스템의 신뢰성을 입증했다.

2026년 상반기 동안 JiTTests는 프로덕션 배포 전 단계에서 74개의 심각한(SEV) 개인정보 버그를 포착하는 데 핵심적인 역할을 수행했다. 이로 인해 해당 기간 동안 개인정보 관련 SEV 발생률이 전체적으로 20% 감소하는 성과를 보였다. 이는 LLM이 기존 테스트로는 놓칠 수 있는 버그를 포착하는 추가적인 안전 계층을 제공하며, AI 기반 테스트가 조직의 위험을 줄일 만큼 확장 가능하다는 것을 보여준다.

이러한 시스템은 최종 사용자가 버그로 인해 겪을 불편함을 사전에 방지하여 더 안정적인 서비스를 경험하게 한다. 또한, 엔지니어들은 버그 탐지에 드는 시간과 노력을 줄여 핵심 개발 업무에 더 집중할 수 있게 된다.

적용 조건과 한계

JiTTests 접근 방식은 기술적으로나 사회적으로 확장 가능하도록 설계되었다. 'Human-on-the-Loop' 방식은 엔지니어가 테스트 코드를 직접 읽을 필요성을 줄이고, 관찰된 동작 변경이 의도된 것인지 여부만 확인하면 되도록 한다. 이는 엔지니어가 성공 기준을 조기에 정의하고, AI가 테스트를 실행하며, 집계된 수준에서 결과를 모니터링하고, 개별 항목이 아닌 정책 수준에서 개입하는 일반화된 모델을 제시한다.

다만, JiTTests는 LLM 또는 에이전트 기반 코드 검토 방식보다 더 많은 계산 단계를 요구한다. 이는 실행 가능한 테스트를 생성하고 검증하는 과정에서 발생하는 추가적인 컴퓨팅 자원 소모를 의미한다. 시스템은 주로 야간의 유휴 용량을 활용하여 이러한 작업을 수행함으로써 엔지니어의 일상적인 작업 흐름에 미치는 영향을 최소화한다.