Meta, Catching JiTTests 상세 공개: 변경마다 실패하도록 만든 테스트, 상반기 심각한 개인정보 버그 74건 포착에 핵심 역할을 했다고 설명

Meta 엔지니어링 팀은 2026년 10월 29일 ‘Catching JiTTests’(즉시 포착 테스트)가 실제 운영에서 어떻게 돌아가는지 소개했다. 대규모 언어 모델이 제안된 코드 변경마다 실패하도록 설계한 실행 가능한 테스트를 만들고, 그 실패로 변경이 들여온 버그를 드러내는 방식이다. Meta에 따르면 글을 쓸 시점에 589명의 엔지니어가 참여했고, 엔지니어들이 보고한 진짜 양성 비율은 60%였다. 2026년 상반기에는 diff 단계에서 심각한(SEV) 개인정보 버그 74건을 잡는 데 핵심적인 역할을 했다고 한다.

Meta는 이 방식을 흔한 AI 코드 리뷰와 구분한다. LLM을 쓰는 방법 대부분은 사람 검토자처럼 코드를 읽고 경험에 비추어 어디가 틀리기 쉬운지 판단한다. Catching JiTTests는 변경이 만든 구체적인 동작 차이를 보여 주는 실행 가능한 테스트를 생성한다. Meta는 계산 단계가 더 필요하다고 인정하면서도 LLM이나 에이전트 리뷰가 놓칠 수 있는 종류의 버그를 잡는다고 말한다. 어려운 점은 규모다. 수억 줄의 코드가 계속 바뀌는 환경에서 생성된 테스트에는 진짜 버그를 보여 주는 ‘강한 포착’과 오탐일 수 있는 ‘약한 포착’이 섞이는데, 엔지니어의 속도를 늦추지 않고 이를 자동으로 가려내야 한다.

시스템은 다섯 단계로 움직인다. 1단계는 대상 선정과 실행으로, 여유 계산 자원으로 밤새 돌면서 전날 제출된 diff 중 위험하다고 판단된 것만 다룬다. 판단에는 Diff Risk Score와 비슷한 방식을 쓰고 과거 코드 변경으로 학습했다. 2단계는 두 개의 병렬 테스트 생성 흐름이다. ‘dodgy diff’ 흐름은 각 diff를 변이체(버그가 있는 버전)로 보고, 변이 기반 LLM 테스트 생성으로 diff와 부모 버전의 동작을 가르는 테스트를 만든다. 의도는 추론하지 않으며 약한 포착의 풀을 넓히는 것이 목표다. ‘intent-aware’ 흐름은 먼저 LLM이 코드 변경, 제목, 요약으로 diff의 의도를 추론하고 그 의도를 구현할 때 잘못될 수 있는 ‘위험’을 서술한 뒤, 이를 바탕으로 변이체를 만들고 각 변이체를 잡아내는 테스트를 생성한다. 이 테스트를 실제 diff에서 돌려 실패한 것을 약한 포착으로 모은다.

3단계는 ‘LLM-as-Judge’ 앙상블로, 여러 최신 모델이 약한 포착의 테스트 코드, 실행 결과(실패 코드, 메시지, 추적), 부모와 자식의 차이, 추론된 의도를 보고 오탐인지 진짜 버그인지 판단한다. 4단계는 규칙 기반 평가기 RubFake로, LLM 판단이 비결정적이고 검증하기 어렵다는 약점을 검증된 결정적 판단으로 보완하며, 둘이 함께 약한 포착의 순위를 매긴다. 5단계는 ‘human-on-the-loop’로, 시스템이 순위에 따라 엔지니어에게 연락할지 정하고 엔지니어는 기준을 세우고 결과를 집계 수준에서 검토할 뿐 모든 출력을 감독하지 않는다.

보고된 수치 중 몇 가지는 범위를 분명히 봐야 한다. 589명은 Meta가 연락한 대상의 64%이지만 글은 연락한 전체 인원을 밝히지 않는다. 60%의 진짜 양성 비율은 엔지니어들이 보고한 값이다. 심각한 개인정보 버그 74건을 잡는 데 핵심적 역할을 했다고 하며 글은 이를 같은 기간 개인정보 SEV 전체가 20% 줄었다는 말과 한 문장에 적었지만, 대조 기준을 주지 않았고 이 시스템만이 원인이라고도 말하지 않는다. 비교 표와 효과 그래프는 원문에서 이미지이며 여기서는 그 값을 쓰지 않았다.

글은 배경도 밝힌다. Meta는 이 작업을 1년 가까이 공유해 왔고 처음 공개한 지 약 5개월이 지난 지금 Catching JiTTests는 연구 시제품이 아니라 Meta 인프라의 일부가 되어, 엔지니어가 더 적은 부담과 더 낮은 오탐 확률로 더 많은 버그를 잡도록 돕는다고 말한다. 관련 논문 「Just-in-Time Catching Test Generation at Meta」는 2026년 1월 arXiv에 제출됐고 FSE 2026에서 발표됐다. 글은 이 방식 덕분에 엔지니어가 테스트 코드를 읽을 일이 드물고, 관찰된 동작 변화가 의도한 것인지만 확인하면 된다고 강조한다. 일반화된 생각은 엔지니어가 성공 기준을 미리 정하고, AI가 테스트를 실행하게 하며, 결과를 집계 수준에서 감시하고, 항목별이 아니라 정책 수준에서 개입한다는 것이다. 원문은 핵심 문제를 이렇게 적는다. 제안된 diff마다 가장 심각한 버그를 찾는 테스트를 자동으로 만들면서도 진짜 양성 비율을 높게 유지하고 엔지니어의 속도를 늦추지 않으려면 어떻게 해야 하는가. dodgy diff 흐름은 ‘이 변경에는 버그가 있다’고 암묵적으로 단정하기 때문에 그런 이름이 붙었고, 약한 포착의 풀을 넓혀 그 안에서 강한 포착이 나올 가능성을 키운다. Meta는 사람의 검토도 유지하되 사람 판정의 일관성은 지키면서 약한 포착을 검토하러 불려 나가는 엔지니어의 가능성을 줄이려 한다.

다른 팀이 참고할 것은 절차의 모양이다. 위험 점수로 소수의 diff를 고르고, 동작 차이를 증명하는 테스트를 만들고, 모델과 규칙 양쪽으로 오탐을 거르고, 순위가 높은 경우에만 사람을 방해한다. 한계도 분명하다. 수치는 Meta 자체 도입에서 나왔고, 비용은 추가 계산이며, 결과는 개인정보 버그에 관한 것이라 모든 결함으로 넓혀 해석해서는 안 된다.