TREX가 보여준 실행형 코드리뷰의 방향

Greptile이 2026년 6월 17일 공개한 TREX 글이 흥미로웠습니다. 핵심은 단순합니다. AI 코드리뷰가 diff를 읽는 데서 끝나지 않고, 실제로 코드를 실행해 증거를 남기는 쪽으로 가고 있다는 점입니다.

코드리뷰의 빈틈

정적 리뷰는 여전히 중요합니다. 하지만 화면이 깨지는 UI 회귀, 특정 상태에서만 터지는 로직 오류, 실제 요청이 있어야 보이는 레이스 컨디션은 코드만 읽어서는 놓치기 쉽습니다.

TREX는 이 지점을 “실행”으로 보완합니다. PR을 보고 의심되는 부분을 찾은 뒤, 샌드박스 환경에서 코드를 돌려보고 결과를 확인하는 방식입니다.

에이전트는 혼자 두면 낭비가 생긴다

Greptile 글에서 특히 실무적으로 보인 부분은 오케스트레이션입니다. 별도 에이전트를 무작정 붙이면 같은 코드를 두 번 탐색하고, 하나의 에이전트에 모두 맡기면 컨텍스트가 과부하됩니다.

그래서 메인 리뷰 에이전트가 diff를 읽고, 조사할 이슈별로 TREX 서브에이전트를 병렬로 띄우는 구조를 택했습니다. 코딩 에이전트가 “혼자 똑똑한 도구”보다 “작게 나뉜 실행 파이프라인”에 가까워지는 흐름입니다.

말보다 증거

TREX가 남기는 결과도 눈여겨볼 만합니다. 단순히 “테스트했다”는 문장이 아니라 스크린샷, 로그, API trace, 실행 스크립트 같은 artifact를 붙입니다.

이건 리뷰어에게 꽤 중요합니다. AI가 맞는 말을 했는지보다, 어떤 환경에서 무엇을 실행했고 어디서 실패했는지를 확인할 수 있어야 실제 작업에 쓸 수 있습니다.

모델보다 하네스

또 하나의 포인트는 모델 비종속성입니다. Greptile은 리뷰 에이전트와 서브에이전트가 서로 다른 모델을 쓸 수 있게 만들고, 내부 eval로 recall과 precision을 본다고 설명합니다.

요즘 모델 성능 순위는 자주 바뀝니다. 그래서 장기적으로는 “어떤 모델을 썼나”보다 실행 환경, 평가 방식, 증거 생성 파이프라인을 얼마나 잘 갖췄는지가 더 큰 차이가 될 수 있습니다.

짧은 생각

AI 코드리뷰의 다음 기준은 더 그럴듯한 코멘트가 아니라 재현 가능한 검증일 가능성이 큽니다. 개발팀 입장에서는 속도보다 신뢰가 더 중요하고, 신뢰는 결국 실행 로그와 재현 가능한 증거에서 나옵니다.

출처: https://www.greptile.com/blog/trex-code-execution