에이전트를 팀 워크플로우에 올리는 결정은 생각보다 빨리 온다. 벤치마크 점수가 높고, 속도도 빠르고, 비용도 저렴하다. 그런데 막상 실제 작업을 시켜보면 전혀 다른 결과가 나온다. 이게 팀 리드가 반드시 경험해봐야 할 첫 번째 충격이다.
1층: 모델은 벤치마크가 아니라 행동으로 검증하라
dev.to에 올라온 Claude vs Gemma 실전 비교 실험은 이 문제를 정면으로 보여준다. Gemma 4 27B는 로컬 벤치마크에서 167 토큰/초, 코드 품질 100점 만점을 찍었다. Claude Opus보다 빠르고, 비용은 제로다. 블로그 포스트 제목은 "Gemma 4가 새 기본값"이었다.
그런데 실제 작업을 시켰더니 결과가 완전히 갈렸다. 과제는 단순했다. 사이트 전체 블로그 포스트에 검색 기능 추가. 스펙은 없고 "검색이 되게 만들어라"가 전부. 동일한 프롬프트, 동일한 코드베이스, 동일한 워크스페이스 템플릿. 단 한 번의 프롬프트로 끝까지 가는지 확인하는 실험이었다.
Claude Opus는 8분 만에 6개 파일 698줄을 작성하고 커밋까지 밀었다. Cmd+K 검색 다이얼로그, 전용 /search 페이지, 가중치 스코어링 API, 키보드 내비게이션, ARIA 접근성까지. 헤더 수정은 딱 3줄이었다. 반면 Gemma는 8번의 프롬프트 끝에 3개 파일 일부만 작성하고 커밋은 0이었다. 계획은 훌륭했다. 실행이 없었다.
흥미로운 건 AGENTS.md에 "계획만 하고 멈추지 마라, 끝까지 실행해라"는 지침을 명시해도 결과가 같았다는 점이다. Gemma는 그 지침을 읽고 나서, 다음에 뭘 할지 계획하고 멈췄다. 이걸 보고도 벤치마크 점수만 보고 모델을 결정하겠다는 팀이 있다면, 그 팀은 조만간 같은 충격을 직접 경험하게 된다.
실전 권고: 에이전트 모델 교체 전, 반드시 팀 백로그에서 실제 태스크를 하나 뽑아서 one-shot 실행 테스트를 돌려라. 벤치마크는 참고 지표일 뿐이다.
2층: AI 출력물은 시맨틱 테스트로 검증하라
에이전트가 코드를 짜는 것과 별개로, AI가 포함된 기능 자체의 E2E 테스트도 문제다. LLM 응답은 매 실행마다 텍스트가 달라진다. 기존 Playwright의 toContainText()나 toEqual() 같은 결정론적 매처는 AI 챗봇 응답 검증에 쓸 수가 없다. 같은 의미의 문장인데 단어 하나가 달라지면 테스트가 터진다.
dev.to에 공개된 playwright-ai-matchers 라이브러리는 이 문제를 실용적으로 푼다. Claude Haiku를 내부 평가 엔진으로 써서 4가지 시맨틱 매처를 제공한다. toMeanSomethingAbout(topic)은 응답이 해당 주제를 실질적으로 다루는지 검증한다. toSatisfy(criterion)은 자연어 요구사항을 기준으로 평가한다. not.toHallucinate(context)는 제공된 컨텍스트에 없는 사실을 지어냈는지 탐지한다. toBeHelpful()은 "이해합니다, 도움이 필요하시면 말씀해주세요" 같은 공허한 응답을 걸러낸다.
매처 하나당 Claude Haiku API 호출 한 번이다. 실패 시 이유도 함께 출력된다. v2.2.0에서는 평가 프롬프트 토큰을 600+에서 250~350으로 줄였다. 비용과 정확도를 동시에 개선했다.
실전 권고: 팀 CI 파이프라인에 AI 응답 검증 스테이지를 별도로 구성하라. 문자열 매칭이 아니라 의미 기반 검증이어야 AI 기능의 품질을 실제로 통제할 수 있다.
3층: 에이전트가 만든 코드 변경은 구조적으로 리뷰하라
에이전트가 커밋을 밀고 나면 팀 리드는 그 변경사항을 봐야 한다. 그런데 Claude Opus처럼 한 번에 698줄을 6개 파일에 걸쳐 쏟아내면, 일반 git diff 터미널 출력으로는 맥락을 잡기가 쉽지 않다. 코드는 있는데 의도가 안 보인다.
긱뉴스에 소개된 오픈소스 Hunk는 이 갭을 터미널 레벨에서 메운다. OpenTUI 기반의 인터랙티브 diff 뷰어로, AI 에이전트가 생성한 코드 변경사항을 리뷰 중심 UI로 탐색할 수 있다. 핵심 기능은 코드 옆에 인라인 AI/에이전트 주석을 직접 표시한다는 점이다. 멀티 파일 리뷰 스트림과 사이드바 내비게이션으로 여러 파일의 변경사항을 한눈에 훑을 수 있고, --watch 모드로 에이전트가 작업 중인 상태를 실시간으로 따라갈 수도 있다.
git config --global core.pager "hunk pager"로 설정하면 기존 git diff와 git show 명령이 자동으로 Hunk에서 열린다. 워크플로우 변경 없이 바로 쓸 수 있다는 게 도입 장벽을 낮추는 포인트다. MIT 라이선스 오픈소스다.
실전 권고: 에이전트 PR 리뷰는 일반 코드 리뷰와 프로세스를 분리해라. 변경 규모가 크고 맥락이 다르다. 구조적 diff 뷰어는 리뷰 시간과 누락 리스크를 동시에 줄인다.
세 층위를 연결하면 무엇이 달라지나
정리하면 이렇다. 1층에서 모델의 실제 에이전트 행동을 검증하지 않으면, 벤치마크 점수만 믿고 올린 모델이 프롬프트 8번에 커밋 0개를 내놓는다. 2층에서 AI 출력물의 시맨틱 검증 인프라를 갖추지 않으면, AI가 포함된 기능은 CI를 통과해도 실제로 제대로 동작하는지 알 수 없다. 3층에서 에이전트 생성 코드의 구조적 리뷰 도구를 갖추지 않으면, 698줄짜리 one-shot 커밋은 블랙박스가 된다.
세 층위는 각각 독립적으로 도입할 수 있다. 하지만 맞물릴 때 효과가 달라진다. 모델 선택 단계부터 배포 후 품질 모니터링까지 에이전트의 행동이 팀의 시야 안에 들어온다. 에이전트 도입 속도보다 이 검증 인프라 구축이 먼저여야 하는 이유다.
앞으로 에이전트 모델 경쟁은 더 빨라질 것이다. 새 모델이 나올 때마다 벤치마크 점수는 올라가고, 팀은 교체 압박을 받는다. 그 압박에 흔들리지 않으려면 팀 자체의 검증 기준이 있어야 한다. 점수가 아니라 행동으로, 문자열이 아니라 의미로, 터미널 출력이 아니라 구조적 리뷰로. 이 세 가지가 팀의 에이전트 품질 기준선이 된다.