하나로 맞출수록 기술은 더 숨어든다
여러 팀이 AI 에이전트를 만들기 시작하면 관리 부서는 개발 프레임워크와 모델, 오케스트레이션을 하나로 맞추려 한다. 오케스트레이션은 모델 호출과 도구 실행의 순서를 조율하는 기능이다. 선택지를 줄이면 중복 개발과 관리 비용도 줄어들 것처럼 보인다.
그런데 프레임워크나 모델을 강제하면 팀이 제약을 우회하고 승인되지 않은 구조를 택한다는 것이 AWS가 정리한 기업 사례의 공통점이다. 통일 명령은 기술의 종류를 줄이지 못한 채 중앙 관리에서 보이지 않게 만들 뿐이다.
팀마다 다른 모델을 쓰는 상황도 예외가 아니다. 데이터독이 수천 개 조직의 운영 데이터를 분석한 결과 69%가 모델을 세 개 이상 사용했고, 여섯 개를 넘겨 쓰는 비율은 1년 사이 거의 두 배가 됐다. 정확도와 속도, 비용의 우선순위가 업무마다 다르므로 단일 모델 지정은 일부 서비스의 성능 저하로 이어진다.
애초에 한 모델이 모든 평가 항목에서 우세하지도 않다. 코드 작성, 문서 검색, 빠른 분류는 서로 다른 수준의 정확도와 응답 시간, 가격을 요구한다. 여러 모델의 병용은 관리 실패가 아니라 업무 차이에서 비롯된 셈이다.
실행은 나누고, 신원과 비용은 한곳에 두어라
업무가 다르면 급소도 다르다. 사내 업무 자동화 플랫폼은 여러 사업부가 데이터와 업무 규칙을 따로 관리한다. 각 부서는 애플리케이션 로직과 배포를 맡고, 중앙 조직은 모델 접근과 감사, 비용 관리를 공용 기능으로 제공한다. 여기서는 중복을 줄이면서 공통 정책을 적용해야 한다.
반면 고객용 멀티테넌트 플랫폼은 한 시스템을 여러 고객사가 함께 쓴다. 모든 요청에 고객 신원 정보를 붙여 데이터와 도구의 접근 범위를 분리하고, 규제가 엄격한 고객에게는 전용 환경을 제공한다. 속도 제한과 장애가 나면 일부 기능을 제한해 서비스를 유지하는 처리도 플랫폼 설계에 포함된다.
그런데 실시간 서비스는 응답 지연을 우선해서 설계한다. 요청별 난이도와 비용에 맞춰 모델을 고르고, 서로 의존하지 않는 작업은 병렬로 처리하며, 반복 계산은 여러 단계의 캐시로 줄인다. 사내 자동화에서 허용되던 긴 다단계 추론은 응답 시간을 맞추지 못할 수 있다.
같은 장애 대응책도 서비스에 따라 가치가 달라진다.
| 유형 | 장애 대응 우선순위 |
|---|---|
| 내부 자동화 | 처리 시간을 늘려 정확도 확보 |
| 고객용 서비스 | 격리 |
| 실시간 서비스 | 즉시 쓸 수 있는 대체 경로 |
세 유형의 실행 방식을 하나로 합치기는 어렵다. 다만 누가 어떤 권한으로 모델과 도구를 호출했는지, 비용을 어느 부서나 고객에게 배분할지는 모두 기록해야 한다. 신원, 정책, 감사 기록, 비용 관리는 공용 층에 둘 수 있다.
도구는 팀에, 실패 비용은 중앙에 두어라
AWS가 Amazon Bedrock과 Amazon SageMaker를 나눈 방식도 이 구분을 따른다. 새 모델은 관리형 모델 접근 서비스인 Bedrock에서 신속히 시험하고, 직접 조정하거나 운영해야 하는 모델은 SageMaker에서 관리한다. 모델 접근 경로와 실행 환경을 분리하면 애플리케이션을 고치지 않고 모델을 교체하기 쉽다.
그런데 특정 공급자를 쓰지 않는 것만으로 종속을 피할 수는 없다. 공급자나 모델을 바꿀 때 애플리케이션 전체를 다시 만들지 않아도 되는지가 더 실용적인 기준이다. 공통 인터페이스와 독립된 실행 환경은 교체 비용을 낮춘다.
그렇다면 무엇을 팀에 맡기고, 무엇을 중앙에 둘까. 잘못 골라도 해당 팀이 다시 만들 수 있는 프레임워크, 모델, 배포 파이프라인은 팀이 선택한다. 반면 신원 체계와 정책, 감사 기록, 비용 배분처럼 변경 실패가 조직 전체에 영향을 주는 기능은 중앙에서 관리한다.
표준화가 필요한 대상은 AI 에이전트를 만드는 도구가 아니라 여러 실행 방식을 함께 관리하는 공용 기능이다. 팀은 업무에 맞는 기술을 고르고, 조직은 모든 호출에 같은 권한·감사·비용 규칙을 적용한다. 도구만 맞춘 채 이 층을 비우면 통제는 사라진다.