처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.06.18 27

코드를 직접 '실행'해서 검증하는 AI 리뷰어, Greptile의 TREX

Hacker News 원문 보기
코드를 직접 '실행'해서 검증하는 AI 리뷰어, Greptile의 TREX

'여기 버그 있는 것 같아요' — 근데 진짜 맞을까?

깃허브에 PR(Pull Request, 내가 짠 코드를 본체에 합쳐달라고 올리는 요청)을 올리면, 요즘은 AI가 자동으로 리뷰 코멘트를 달아주는 경우가 많죠. CodeRabbit이나 Graphite 같은 도구들이 대표적인데요. 바뀐 코드를 쭉 훑어보고 '여기 null 체크가 빠진 것 같아요', '이 변수 범위를 벗어날 수 있어요' 하고 친절하게 짚어줍니다.

그런데 막상 써보면 다들 비슷한 불만을 느껴요. 지적의 절반은 헛다리거든요. AI가 자신만만하게 '버그예요!'라고 하는데, 코드를 들여다보면 멀쩡한 경우가 정말 많아요. 이렇게 멀쩡한 걸 문제라고 잘못 짚는 걸 '거짓 양성(false positive)'이라고 부르는데, 이게 쌓이면 사람들은 AI 리뷰를 아예 안 읽게 돼요. 늑대가 나타났다고 거짓말하던 양치기 소년처럼요.

왜 이럴까요? 기존 AI 리뷰어는 코드를 '눈으로 읽기만' 하기 때문이에요. 사람이 글을 읽고 추측하듯, 코드 텍스트만 보고 '아마 이럴 것이다'라고 짐작하는 거죠. 실제로 돌려본 게 아니니까 확신이 없고, 그래서 애매한 것까지 일단 다 지적하게 됩니다.

TREX는 직접 '돌려보고' 말합니다

Greptile이라는 코드 리뷰 회사가 내놓은 TREX는 이 지점을 정면으로 뒤집어요. 핵심은 한 문장이에요. '추측하지 말고, 진짜로 실행해서 확인하자.'

이게 어떻게 작동하냐면요. TREX는 PR을 받으면 먼저 '여기 이런 버그가 있을 것 같다'는 가설을 세워요. 여기까지는 기존 도구와 비슷해요. 그런데 그다음이 달라요. 격리된 실행 환경(sandbox, 다른 시스템에 영향을 주지 않도록 따로 떼어놓은 안전한 실행 공간)을 띄우고, 그 가설을 검증하는 작은 코드나 테스트를 직접 짜서 돌려봅니다. 그리고 실행 결과를 눈으로 확인하죠.

예를 들어 '이 함수에 빈 배열을 넣으면 에러가 날 것 같다'는 의심이 들면, 진짜로 빈 배열을 넣어서 호출해봐요. 에러가 나면 '거봐, 진짜 버그네' 하고 코멘트를 달고, 멀쩡하게 돌아가면 '아, 내가 잘못 봤네' 하고 조용히 그 지적을 버립니다. 이렇게 '실행해서 재현된' 버그만 보고하니까 거짓 양성이 확 줄어드는 거예요.

이건 요즘 유행하는 '에이전트(agent)' 방식이에요. AI가 한 번 답하고 끝내는 게 아니라, 가설 세우기 → 실험 코드 작성 → 실행 → 결과 관찰 → 판단을 여러 번 반복하면서 스스로 결론에 도달하는 구조죠. 사람 개발자가 버그를 의심할 때 직접 디버거 켜고 재현해보는 과정을 AI가 흉내 내는 셈이에요.

비슷한 흐름의 도구들

사실 '실행하는 AI'는 TREX만의 이야기는 아니에요. 업계 전체가 이 방향으로 가고 있어요. Cursor의 BugBot, 깃허브 코파일럿의 자동 리뷰, Devin 같은 자율 코딩 에이전트들도 점점 '코드를 읽기만 하던 단계'에서 '실제로 빌드하고 테스트를 돌려 확인하는 단계'로 넘어가고 있거든요.

차이가 있다면 TREX는 '코드 리뷰'라는 한 가지 일에 이 실행 능력을 집중했다는 점이에요. 거대한 자율 에이전트가 프로젝트 전체를 짜겠다고 덤비는 것과 달리, '리뷰의 정확도를 높이는 데만 실행을 쓴다'는 좁고 실용적인 목표죠. 큰 그림에서 보면, AI 코딩 도구의 신뢰도를 '말'이 아니라 '증거'로 끌어올리려는 흐름의 한 조각이에요.

한국 개발자에게는?

당장 팀에 AI 리뷰 도구를 도입했다가 헛다리 코멘트 때문에 피로감을 느끼고 꺼버린 경험, 한 번쯤 있으실 거예요. 그렇다면 '실행 기반 검증'을 내세우는 도구들을 다시 한번 눈여겨볼 만해요. 정확도가 올라가면 그제야 팀이 AI 리뷰를 신뢰하기 시작하거든요.

다만 현실적인 고민도 있어요. 내 코드를 외부 샌드박스에서 실제로 실행한다는 건, 보안과 비밀키(secret) 관리가 그만큼 중요해진다는 뜻이에요. 사내 코드를 외부 서비스에서 돌려도 되는지, 테스트 중에 실제 DB나 외부 API를 건드리진 않는지 꼭 따져봐야 해요. 또 실행에는 시간과 비용이 드니까, 모든 PR에 적용할지 중요한 것만 골라 적용할지도 판단해야 하고요.

정리하며

핵심은 이거예요. AI 코드 리뷰의 다음 단계는 '더 똑똑한 추측'이 아니라 '직접 실행한 증거'다. 읽고 짐작하던 AI가 이제 직접 돌려보고 '재현됐다'고 말하기 시작했어요.

여러분 팀에서는 AI 리뷰 코멘트를 얼마나 믿고 계세요? '실행해서 검증된 버그만 알려준다'면, 여러분의 신뢰도가 달라질까요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

이 기술을 직접 배워보세요

바이브코딩으로 직접 만들어보세요

이 기술, 강의에서 실습으로 배울 수 있습니다.

바이브코딩 강의 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.