코딩 에이전트 데모는 대개 인상적이다. 그런데 실제 프로젝트에 붙여보면 금방 다른 그림이 나온다. 에이전트가 작업 완료를 선언했는데 실제로는 절반도 처리되지 않거나, 단순한 반복 작업을 비효율적으로 처리하거나, 아무런 예고 없이 멈추거나. 이런 경험이 쌓이면 팀은 "에이전트가 아직 덜 됐다"는 결론으로 도입을 미룬다.
그 판단이 맞는지 확인할 방법이 없다는 것이 진짜 문제다. 무엇이 부족했는지, 어떤 조건에서 다시 시도하면 달라지는지를 사전에 정의한 적이 없기 때문이다.
모델과 에이전트를 구분하지 않으면 평가 자체가 흔들린다
"GPT가 좋아졌으니 코딩 에이전트도 좋아졌겠지"라는 가정이 많다. 절반만 맞다.
LLM(대규모 언어 모델)은 코드를 생성하는 두뇌에 해당한다. 에이전트는 그 결과물을 실제 파일, 터미널 명령, 테스트 실행에 연결하는 몸체다. Claude Sonnet이나 GPT 계열 모델의 코드 생성 품질이 올라가도, 그 모델을 감싸는 에이전트가 작업을 어떻게 분해하고 실행하며 결과를 판단하는지는 별개의 설계 문제다.
실무에서 이 둘을 구분하지 않으면 성능 문제의 원인을 찾을 수 없다. 모델을 바꿔도 달라지지 않는 문제를 모델 탓으로 돌리거나, 에이전트 설계의 한계를 LLM 업그레이드로 해결하려다 시간을 낭비하게 된다.
벤더를 비교할 때 "어떤 모델을 쓰나요"보다 먼저 물어야 할 것은 "에이전트가 작업 실패를 어떻게 감지하고 어떻게 복구하나요"다.
현세대 코딩 에이전트에서 반복 확인되는 구조적 한계
어떤 시나리오로 평가하든, 아래 한계를 먼저 알고 있어야 쓸 만한 에이전트를 탈락시키거나 현장에서 실패할 에이전트를 통과시키는 실수를 줄일 수 있다.
작업 병렬화를 스스로 판단하지 못한다. 독립적으로 처리할 수 있는 하위 작업들도 순차적으로 실행하는 경향이 있다. 단순히 느린 문제가 아니라, 에이전트가 작업 간 의존성을 실제로 분석하고 있는지 여부를 드러내는 신호다.
모델 선택을 작업 난이도에 맞춰 조정하지 않는다. 대부분이 단순 반복 처리인 작업에도 고성능 모델이 그대로 투입된다. 비용과 속도 모두 비효율이지만, 더 큰 문제는 에이전트가 작업의 성격을 스스로 분류하지 못한다는 점이다.
자신의 기능과 현재 상태를 파악하지 못한다. 에이전트에게 자신의 기능을 물으면 외부 검색으로 답을 찾으려 한다. 이 특성은 장기 프로젝트나 반복 작업 자동화에서 운영상 주의가 필요한 부분이다. 세션 간 맥락 유지 방식이 어떻게 설계돼 있는지는 벤더에게 직접 확인해야 한다.
실행 계획을 검토 가능한 형태로 전달하지 못한다. 에이전트가 제시하는 계획은 고수준 목표와 저수준 구현 결정이 뒤섞인 경우가 많다. 검토자가 무엇에 동의하고 무엇을 수정해야 하는지 판단하기 어렵다. 계획 검토 단계가 형식적으로 흘러가는 팀이라면, 에이전트가 계획을 어떻게 구조화하는지를 평가 항목으로 넣어야 한다.
벤더 데모가 보여주지 않는 조건들
코딩 에이전트 데모는 대개 독립적이고 범위가 명확한 작업을 시연한다. 빈 파일에 함수를 추가하거나, 잘 정의된 버그 하나를 수정하거나. 이런 시나리오에서 에이전트는 인상적으로 작동한다.
실제 프로젝트의 조건은 다르다. 코드베이스는 수만 줄이고, 요구사항은 불완전하며, 작업 중간에 외부 서비스가 실패하거나 테스트가 통과해도 의도한 동작이 아닌 경우가 생긴다. 에이전트가 이런 상황에서 어떻게 행동하는지는 데모에서 나오지 않는다.
벤더가 제시하는 데모 흐름을 그대로 따라가 평가하면, 팀의 실제 워크플로우와 무관한 기준으로 선택을 내리게 된다. 평가 시나리오는 팀이 직접 설계해야 한다.
요구사항 단계에서 팀이 먼저 정해야 할 것들
에이전트 도입 결정을 벤더 선택 이후로 미루는 팀이 많다. 그러나 성공 기준 없이 벤더를 고르면 나중에 "기대보다 못하다"는 결론밖에 나오지 않는다.
어떤 작업 유형을 자동화하려는가. 신규 기능 구현, 리팩터링, 버그 수정, 코드 리뷰 보조, 테스트 작성은 에이전트에게 요구하는 능력이 각각 다르다. 모든 것을 하나의 에이전트로 해결하려는 가정을 먼저 내려놓아야 한다.
성공을 어떻게 측정할 것인가. "빠르다", "편하다"는 에이전트 비교에 쓸 수 없다. 에이전트가 작업 완료를 선언한 뒤 검토자가 추가로 수정한 비율, 에이전트가 중단하거나 재시작을 요구한 빈도, 실제 처리 시간 대비 청구된 토큰 비용의 비율처럼 수치로 확인할 수 있어야 한다.
실패 상황을 어디까지 허용할 것인가. 에이전트가 잘못된 코드를 생성하거나 작업을 중간에 멈추는 상황은 어떤 프로젝트에서도 일어난다. 이것이 CI 파이프라인 바깥에서만 일어나는지, 프로덕션 근처까지 영향을 미칠 수 있는지에 따라 허용 기준과 필요한 감시 구조가 달라진다.
사람이 어느 지점에서 개입하는가. 에이전트 도입이 완전 자동화를 의미하는 팀은 드물다. 어떤 결정을 사람이 검토하고 승인해야 하는지를 미리 정해두지 않으면, 에이전트가 자율적으로 처리한 영역이 감사(audit)의 공백으로 남는다.
실제 워크플로우 기반 검증 시나리오를 직접 설계해야 하는 이유
위 기준을 정했다면, 다음은 팀의 실제 워크플로우에서 평가 시나리오를 골라야 한다. 벤더가 제공하는 샘플 프롬프트나 튜토리얼 프로젝트가 아니라, 지난 분기에 팀이 처리한 작업 유형에서 직접 뽑는다.
결과를 객관적으로 판단할 수 있는 작업이어야 한다. "코드가 좋아 보인다"는 기준은 에이전트 비교에 쓸 수 없다. 테스트 통과 여부, 리뷰어가 발견한 추가 결함 수, 실제 배포까지 걸린 시간처럼 수치로 확인할 수 있는 항목이 있어야 한다.
경계 조건이 포함된 작업을 의도적으로 넣어야 한다. 에이전트가 작업 완료를 판단하기 모호한 상황, 외부 API가 느리게 응답하는 상황, 기존 코드 패턴과 충돌하는 요구사항 같은 것들이다. 이런 상황에서의 동작이 실제 운영 환경에 가장 가깝다.
한 번의 실행이 아니라 반복 실행에서 일관성을 봐야 한다. 에이전트의 출력은 확률적이다. 같은 입력으로 여러 번 돌렸을 때 결과의 범위가 어느 정도인지를 확인하지 않으면 신뢰성을 판단할 수 없다.
