AI 에이전트 시대, 이제는 '잘 평가하는 법'이 중요하다

anpigon (71)in #ai • 4 days ago

요즘 더 자주 느끼는 것

올해 들어 AI 코딩 에이전트를 붙여서 작은 자동화부터 리팩터링, 문서 정리, 테스트 보강까지 이것저것 돌려보면 공통적으로 느끼는 게 하나 있다. 이제 모델이 똑똑한지 아닌지만 보는 단계는 거의 끝났다는 점이다. 실제로 일을 맡겨보면 성능 차이보다 더 크게 체감되는 건, 이 결과를 우리가 어떻게 검증하느냐였다.

예전에는 “한 번 잘 되면 됐다”였는데

작년까지만 해도 샘플 몇 개 잘 나오면 “오, 이거 되네” 하고 넘어가는 경우가 많았다. 그런데 2026년의 에이전트는 검색도 하고, 파일도 바꾸고, 테스트도 돌리고, PR 초안도 만든다. 여기서 문제는 실패가 훨씬 조용해졌다는 거다. 겉으로는 멀쩡한데 요구사항을 살짝 빗나가거나, 기존 스타일을 깨거나, 장기적으로 유지보수성을 망치는 식이다.

최근 트렌드도 같은 방향이다

요즘 보이는 흐름도 명확하다. Eval-Driven Development 같은 이야기가 더 많이 나오고, SWE-Bench Pro나 SWE-CI처럼 “진짜 개발 환경에 가까운 평가”를 하려는 움직임이 커졌다. 단발성 문제 풀이보다 긴 작업 흐름, 여러 번의 수정, CI 루프 안에서 얼마나 안정적으로 버티는지가 더 중요해진 거다. 한마디로 말하면 이제는 데모 성능보다 운영 성능을 봐야 한다.

실무에서 제일 위험한 순간

제일 위험한 순간은 에이전트가 80점짜리 결과를 95점처럼 보이게 만들 때다. 테스트 몇 개는 통과하고, 설명도 그럴듯하고, diff도 깔끔하면 사람은 쉽게 안심한다. 그런데 며칠 뒤 다른 모듈에서 이상한 부작용이 터진다. 저는 요즘 이 구간을 “AI가 틀렸는데 팀이 눈치채기 어려운 구간”이라고 본다. 여기서 필요한 건 더 긴 프롬프트가 아니라 더 좋은 평가 기준이다.

그래서 바뀐 제 워크플로우

요즘은 에이전트에게 일을 맡기기 전에 먼저 체크리스트를 만든다. 예를 들면 기능 정확성, 회귀 여부, 보안 영향, 로그/예외 처리, 팀 컨벤션 준수 같은 항목이다. 그리고 가능하면 이걸 테스트, 린트, 정적 분석, PR 템플릿으로 바꿔둔다. 에이전트를 똑똑하게 쓰는 팀은 프롬프트를 잘 쓰는 팀이 아니라, 실패를 빨리 드러내는 팀이라는 생각이 점점 강해진다.

멀티에이전트에서도 똑같다

여러 에이전트를 병렬로 돌리면 생산성은 올라가는데, 평가가 없으면 오히려 더 위험하다. 각자 부분 최적화를 해버려서 전체 맥락이 깨지기 쉽기 때문이다. 특히 코드 생성 담당, 리뷰 담당, 테스트 담당을 나눴을 때 서로 “누가 최종 책임을 지는지”가 흐려진다. 그래서 멀티에이전트의 핵심은 협업 그 자체보다, 마지막에 무엇으로 합격/불합격을 판정하느냐다.

앞으로 남는 팀의 차이

2026년에는 좋은 모델을 쓰는 팀보다 좋은 평가 파이프라인을 가진 팀이 더 오래 앞서갈 가능성이 크다. 모델은 점점 평준화되지만, 우리 서비스에 맞는 실패 사례와 금지 패턴, 품질 기준은 팀마다 다르기 때문이다. 결국 경쟁력은 모델 선택보다도 “우리 팀은 AI 산출물을 어떤 기준으로 믿는가”에 쌓인다.