JiTTesting — AI가 코드를 쓰는 시대, 테스트는 누가 하나

테스트 코드를 작성하는 시간이 기능 코드를 작성하는 시간보다 길다는 건 흔한 불만이다. 그런데 AI 에이전트가 기능 코드를 몇 초 만에 생성하는 세상이 되면, 테스트의 병목은 더 심해진다. 코드는 쏟아지는데 테스트를 따라잡을 수가 없다. Meta Engineering이 공개한 **JiTTesting(Just-in-Time Testing)**은 이 문제에 대한 근본적인 접근이다. 테스트도 AI가 그때그때 만들어서 쓰고 버리면 어떨까?

전통적 테스팅의 구조적 한계

기존 테스트 방법론은 50년 이상 된 패러다임이다. 핵심 전제는 "사람이 코드를 작성하고, 사람이 테스트를 작성하고, 테스트를 계속 유지보수한다"는 것이다. 이 전제 위에서 단위 테스트, 통합 테스트, E2E 테스트 피라미드가 설계되었다.

문제는 에이전트 개발(Agentic Development)이 이 전제를 무너뜨린다는 것이다.

전통적 개발	에이전트 개발
코드 작성 속도 느림	코드 생성 속도 극도로 빠름
변경 범위 예측 가능	변경 범위 예측 불가
수동 테스트 작성·유지	테스트 유지보수가 병목
테스트가 코드보다 오래 산다	코드가 테스트보다 빠르게 바뀐다

비유하면 이렇다. 기존에는 요리사가 새 메뉴를 만들 때마다 레시피 카드를 작성하고 파일함에 보관했다. 일주일에 메뉴가 하나 바뀌니까 관리할 수 있었다. 그런데 갑자기 매일 50개씩 새 메뉴가 쏟아진다면? 레시피 카드 시스템 자체가 무너진다.

[💡 잠깐! 이 용어는?] 에이전트 개발(Agentic Development): AI 에이전트가 코드 작성, PR 생성, 배포까지 자율적으로 수행하는 개발 방식이다. GitHub Copilot Workspace, Cursor, Claude Code 등이 이 범주에 속한다.

---

JiTTesting의 핵심 아이디어

JiTTesting은 테스트를 미리 작성하고 유지하는 게 아니라, 코드가 변경될 때마다 즉석에서 생성하고 실행한 뒤 폐기하는 방식이다. "Just-in-Time"이라는 이름 자체가 핵심을 말해준다. 비유하면 시험 문제를 학기 초에 만들어두는 게 아니라, 학생이 답안을 제출하는 그 순간에 맞춤형 문제를 출제하는 것이다.

6단계 파이프라인

1. 코드 변경 감지: 새 코드가 리포지토리에 들어온다
2. 의도 추론: LLM이 "이 변경이 뭘 하려는 건지" 파악한다
3. 의도적 결함 주입(Mutation): 코드에 일부러 버그를 심는다
4. 테스트 자동 생성: 주입된 결함을 잡아낼 테스트를 LLM이 생성한다
5. 앙상블 평가(Ensemble Assessment): 여러 평가자가 노이즈를 걸러내고 진짜 이슈를 분류한다
6. 리포트 전달: 문제가 발견된 경우에만 엔지니어에게 알린다

3단계의 의도적 결함 주입이 핵심이다. 코드에 일부러 버그를 넣어보고, 생성된 테스트가 이걸 잡아내는지 확인한다. 잡아내면 그 테스트는 유효한 것이고, 못 잡으면 테스트 자체가 약한 것이다. Meta는 이 접근을 Catching JiTTests라고 부른다.

[💡 잠깐! 이 용어는?] 뮤테이션 테스팅(Mutation Testing): 정상 코드에 의도적으로 작은 변경(뮤턴트)을 가해서, 기존 테스트가 이 변경을 감지하는지 확인하는 테스트 품질 측정 기법이다. "테스트를 테스트하는 테스트"라고 볼 수 있다.

---

전통적 테스트와 무엇이 다른가

기준	전통적 테스트	JiTTesting
생성 시점	코드 작성 전/후 수동	코드 변경 시 자동
유지보수	수동 업데이트 필요	유지보수 불필요 (일회용)
코드베이스 저장	영구 보관	생성 → 실행 → 폐기
변경 특화	범용 테스트	해당 변경에 맞춤 설계
오탐(false positive)	코드 변경 시 깨지는 테스트	앙상블 평가로 노이즈 필터링

기존 테스트 코드가 쓸모없어지는 건 아니다. 회귀 테스트, 통합 테스트, E2E 테스트는 여전히 필요하다. JiTTesting이 대체하려는 건 "새 변경사항이 기존 동작을 깨뜨리지 않는가"를 빠르게 확인하는 회귀 감지 영역이다.

---

현실적으로 어디에 쓸 수 있나

JiTTesting은 아직 Meta 내부 연구 단계다. 바로 npm install 해서 쓸 수 있는 오픈소스 도구는 아니다. 하지만 아이디어 자체는 이미 적용 가능한 범위가 있다.

실험해볼 수 있는 접근

1. PR에 LLM 기반 테스트 리뷰 추가: PR이 올라오면 변경된 코드에 대해 LLM이 "이 변경에서 깨질 수 있는 시나리오"를 생성하고 코멘트로 남기는 봇
2. 뮤테이션 테스팅 도입: Stryker(JavaScript), mutmut(Python) 같은 기존 뮤테이션 테스팅 도구를 CI에 넣어서 기존 테스트의 품질을 측정
3. AI 코드 리뷰 파이프라인: 에이전트가 생성한 코드를 다른 LLM이 검증하는 "이중 검증" 구조 도입

접근	난이도	효과
PR 코멘트 봇	낮음	코드 리뷰 보조
뮤테이션 테스팅 CI	중간	테스트 품질 정량 측정
LLM 이중 검증	높음	에이전트 코드의 안전장치

---

한계와 열린 질문

JiTTesting이 만능은 아니다. 몇 가지 열린 질문이 남아 있다.

• LLM의 테스트 품질: LLM이 생성한 테스트 자체가 정확하지 않으면 전체 파이프라인이 무의미하다. "테스트를 생성하는 AI를 테스트하는 건 누구인가"라는 재귀적 문제다.
• 비용: 매 커밋마다 LLM을 호출하면 API 비용이 선형으로 증가한다. 대형 모노레포에서는 비용 제어가 중요하다.
• 비결정적 결과: 같은 코드 변경에 대해 LLM이 매번 다른 테스트를 생성할 수 있다. 앙상블 평가가 이를 완화하지만 완벽하지는 않다.

정리

• AI 에이전트가 코드를 쓰는 속도가 빨라지면서, 테스트 유지보수가 새로운 병목이 됐다
• JiTTesting은 테스트를 미리 만들어두는 대신 변경 시점에 즉석 생성 → 실행 → 폐기하는 패러다임이다
• 의도적 결함 주입 + LLM 테스트 생성 + 앙상블 평가의 3단 구조가 핵심이다
• 아직 연구 단계이지만, 뮤테이션 테스팅이나 LLM 기반 PR 리뷰를 현재 파이프라인에 추가하는 것만으로도 비슷한 효과를 낼 수 있다

---

참고:

• Meta Engineering: https://engineering.fb.com/2026/02/11/developer-tools/the-death-of-traditional-testing-agentic-development-jit-testing-revival/
• Stryker (JavaScript Mutation Testing): https://stryker-mutator.io/