AI 에이전트 외주 개발, 모델보다 구조가 먼저다

한줄 요약

AI 에이전트 품질은 모델 선택이 아니라 실행 구조 설계에서 갈린다.

AI 에이전트 개발을 의뢰하거나 직접 수행할 때, 가장 흔한 착각은 "좋은 모델을 붙이면 잘 된다"는 생각이다. 실제로는 모델이 어떤 루프 위에서 작동하고, 어떤 도구에 어떤 권한으로 접근하며, 상태를 어떻게 이어가는지가 완성도를 결정한다. IT 개발 에이전시 입장에서 이 구조 설계는 선택이 아니라 납품 품질의 기준이다.

데모와 운영은 왜 이렇게 다른가

프로젝트 초반 데모에서 잘 돌아가던 에이전트가 실제 운영 환경에서 무너지는 이유는 대부분 하나다. 모든 작업을 단일 모델 호출 하나에 몰아넣었기 때문이다.

"이 데이터 읽고, 분석하고, 보고서 써서, 슬랙에 보내"라는 지시를 하나의 프롬프트로 처리하면 데모는 그럴듯하다. 하지만 반복 실행이 시작되면 왜 그 판단을 내렸는지, 어디서 실패했는지, 누가 쓰기 권한을 가졌는지가 전부 뒤섞인다. 추적도 안 되고 수정도 어렵다.

에이전시가 클라이언트에게 납품하는 에이전트는 데모가 아니라 운영 시스템이다. 그 차이를 만드는 것이 바로 실행 루프 설계다.

실행 루프란 무엇이고 왜 별도로 설계해야 하나

에이전트의 핵심 작동 방식은 단순하다. 입력을 받고 → 모델을 호출하고 → 도구 사용 요청이 있으면 실행하고 → 결과를 다시 모델에 넘기는 반복이다. 이 루프 자체는 복잡하지 않다.

문제는 이 루프를 프롬프트 안에 녹여 넣으려 할 때 생긴다. 최대 반복 횟수, 연속 실패 시 중단 조건, 도구 실행 타임아웃, 사람 개입이 필요한 시점은 프롬프트가 아니라 런타임 레벨에서 명시적으로 정의해야 한다. 그래야 시스템이 예측 가능하고, 장애 발생 시 원인을 특정할 수 있다.

외주 개발 관점에서 이 설계는 클라이언트에게 전달해야 할 스펙이기도 하다. "몇 번까지 재시도하고, 어떤 조건에서 사람에게 넘기는가"는 기술 명세인 동시에 비즈니스 요건이다.

도구 권한 설계, 기능보다 위험도 기준으로 나눠야 한다

에이전트에 도구를 붙이는 것 자체는 어렵지 않다. 진짜 설계는 어떤 도구를 어떤 조건에서 열어줄지를 정하는 데 있다.

실용적인 기준은 기능 분류가 아니라 위험도 분류다. 읽기 전용 도구는 별도 승인 없이 실행 가능하다. 파일 수정이나 외부 API 호출처럼 부작용이 생기는 도구는 조건부 승인이 필요하다. 운영 데이터를 건드리거나 되돌리기 어려운 작업은 원칙적으로 차단하거나 사람의 명시적 승인을 요구해야 한다.

클라이언트 시스템에 연결되는 에이전트를 납품할 때 이 기준이 없으면, 에이전트가 의도치 않은 데이터를 수정하거나 삭제하는 사고가 실제로 발생한다. 도구 권한 정책은 보안 문서가 아니라 에이전트 설계의 일부다.

멀티 에이전트 구조, 역할 분리는 구조도가 아니라 책임 분리다

작업이 복잡해질수록 단일 에이전트로는 한계가 온다. 이때 흔히 등장하는 해법이 멀티 에이전트 구조인데, 여기서도 착각이 생긴다. "팀처럼 나눴으니 잘 돌아가겠지"라는 생각이다.

멀티 에이전트 설계에서 중요한 건 그림이 아니라 세 가지 질문이다. 누가 최종 응답의 책임을 지는가. 누가 도구를 직접 실행할 수 있는가. 누가 읽기만 하고 누가 쓰기까지 가능한가.

예를 들어 자료 수집 에이전트는 읽기 전용 도구만 써야 하고, 문서 작성 에이전트는 수집된 근거 없이는 내용을 생성하지 못하게 제약해야 하며, 실제 변경을 실행하는 에이전트는 오케스트레이터의 승인 신호 없이는 작동하지 않아야 한다. 역할 분리는 예쁜 다이어그램이 아니라 권한과 책임의 경계선이다.