AI 에이전트 외주 개발, 모델보다 구조가 완성도를 가른다

한줄 요약

AI 에이전트 완성도는 모델 선택이 아니라 실행 구조 설계에서 갈린다.

AI 에이전트 개발 의뢰가 늘면서, 클라이언트가 가장 자주 묻는 질문이 하나로 수렴되고 있다. "어떤 모델 쓰세요?" 그런데 실제로 프로젝트를 운영해보면, 이 질문은 완성도와 별로 관계가 없다. 데모에서 그럴듯하게 돌아가던 에이전트가 실제 운영 환경에서 무너지는 이유는 모델 탓이 아니다. 실행 루프가 없거나, 역할이 뒤섞이거나, 도구 권한이 무분별하거나, 컨텍스트가 관리되지 않기 때문이다.

에이전트란 결국 무엇인가

에이전트는 "모델에 질문을 던지는 것"이 아니다. 모델이 도구를 호출하고, 결과를 받아 다음 행동을 결정하고, 그 과정을 반복하는 실행 구조다.

단순하게 정리하면 이렇다. 사용자 입력이 들어오면 → 컨텍스트와 결합해 모델을 호출하고 → 모델이 도구 사용을 요청하면 → 도구를 실행해 결과를 다시 모델에 넘기고 → 최종 답변이 나올 때까지 반복한다. 이 루프가 없으면 에이전트가 아니라 챗봇이다.

여기서 중요해지는 게 몇 가지다. 최대 반복 횟수는 어디서 끊는가. 도구 실행이 실패하면 어떻게 복구하는가. 위험한 행동은 누가 막는가. 이 모든 게 런타임 레벨에서 명시적으로 설계되어야 한다.

에이전시가 자주 틀리는 지점은 어디인가

외주 에이전트 프로젝트에서 반복되는 실패 패턴이 있다. 대부분 설계 단계에서 이미 예정된 실패다.

첫째, 역할 분리 없이 하나의 모델에 모든 걸 맡긴다. "전체 업무 흐름을 자동화해줘"라는 요청을 받고, 단일 프롬프트에 모든 조건을 욱여넣는 방식이다. 초반엔 작동하는 것처럼 보이지만, 업무가 조금만 복잡해지면 추론 품질이 무너진다.

둘째, 도구 권한을 나누지 않는다. 검색 도구와 파일 수정 도구, 외부 API 호출 도구가 동일한 조건에서 실행된다. 조회와 실행이 같은 레벨에 있으면, 의도치 않은 변경이 발생해도 추적이 불가능하다.

셋째, 상태 관리를 모델에 위임한다. 이전 대화를 통째로 컨텍스트에 쑤셔넣고 모델이 알아서 기억하길 기대한다. 작업이 길어질수록 응답 품질이 떨어지고, 어디서 잘못됐는지 파악조차 어렵다.

제대로 된 에이전트 구조는 어떻게 다른가

잘 설계된 에이전트는 팀처럼 움직인다. 단, "팀처럼 나눠라"는 말의 핵심은 역할 분리가 아니라 책임 분리다.

예를 들어 문서 기반 Q&A 에이전트를 만든다고 하자. 매니저 에이전트가 전체 흐름을 조율하고, 검색 전문 에이전트는 근거 문서 ID만 반환하며, 답변 에이전트는 그 근거 없이는 응답을 생성하지 못하게 막아야 한다. 만약 외부 시스템에 데이터를 쓰는 작업이 필요하다면, 해당 에이전트는 담당자 승인 없이는 실행 자체가 되지 않아야 한다.

도구도 마찬가지다. 위험도 기준으로 등급을 나누고, 등급마다 다른 승인 정책을 두는 것이 기능별 분류보다 훨씬 실용적이다. 읽기 전용 도구는 자동 실행, 파일 수정·코드 실행은 검토 필요, 배포·삭제 같은 파괴적 작업은 원칙적으로 차단하는 식이다. "도구를 붙였다"보다 "어떤 조건에서 어떤 도구를 여는가"가 시스템 안전성을 결정한다.

컨텍스트 관리가 에이전트 품질의 천장을 정한다

컨텍스트는 많이 넣을수록 좋아지지 않는다. 오히려 무엇을 넣고 무엇을 버릴지를 명확히 설계할수록 응답 품질이 안정된다.

프로젝트 전반에 걸쳐 유지해야 할 규칙, 현재 작업의 진행 상태, 이번 턴에만 필요한 임시 정보는 각각 다르게 취급해야 한다. 전문 에이전트에게 작업을 넘길 때도 전체 대화 내역이 아니라, 필요한 정보만 담은 요약 카드를 전달하는 편이 낫다.

이 부분이 외주 개발에서 가장 차이가 나는 지점이기도 하다. 단순히 모델을 붙이는 팀과, 컨텍스트 흐름을 설계하는 팀의 결과물은 운영 3개월 시점에 완전히 달라진다.