Agent· 읽는 데 3분
에이전트 플랫폼 경쟁: 어디에 올릴지 고르기 전에 정할 것
클라우드 회사들이 앞다투어 기업용 에이전트 플랫폼을 내놓고 있습니다. 플랫폼을 고르기 전에 회사가 먼저 정해야 할 것을 정리했습니다.
4월 22일부터 24일까지 열린 Google Cloud Next에서 Google은 Gemini Enterprise Agent Platform을 발표했습니다. 작년 12월 AWS도 re:Invent에서 에이전트 관련 서비스를 대거 내놓았습니다. 클라우드 회사들의 경쟁 무대가 "모델"에서 "에이전트를 만들고 운영하는 플랫폼"으로 옮겨 갔습니다.
선택지가 많아진 만큼 "어느 플랫폼이 좋은가"라는 질문도 늘었습니다. 그런데 플랫폼을 고르기 전에 먼저 정해야 할 것이 있습니다.
플랫폼이 해 주는 것
- 에이전트를 만드는 도구
- 사내 시스템과의 연결
- 권한 관리와 접근 통제
- 실행 기록과 모니터링
- 여러 에이전트의 조율
하나하나 직접 만들기에는 부담스러운 것들이라, 플랫폼을 쓰는 것 자체는 합리적인 선택입니다.
먼저 정할 것
1. 에이전트에게 맡길 일
플랫폼부터 고르고 쓸 곳을 찾는 순서는 대개 실패합니다. 맡길 업무가 정해져야 필요한 기능이 보입니다. 단순한 문의 응대에 필요한 것과, 여러 시스템을 오가며 주문을 처리하는 에이전트에 필요한 것은 다릅니다.
2. 데이터가 있는 곳
에이전트는 데이터 가까이에 있는 편이 유리합니다. 업무 데이터가 이미 특정 클라우드에 있다면, 그 클라우드의 플랫폼이 연결과 권한 관리에서 수월합니다.
3. 갈아탈 때 가져갈 수 있는 것
플랫폼에 묶이는 것을 완전히 피할 수는 없습니다. 다만 무엇이 묶이는지는 알고 들어가야 합니다.
| 가져가기 쉬운 것 | 묶이기 쉬운 것 |
|---|---|
| 업무 절차를 정리한 문서와 프롬프트 | 플랫폼 전용 설정과 워크플로 |
| MCP 같은 표준으로 만든 시스템 연동 | 플랫폼 고유 방식의 연동 |
| 직접 만든 평가 세트 | 플랫폼 안에 쌓인 실행 기록 |
연동을 표준 방식으로 만들어 두고, 평가 세트를 플랫폼 밖에 갖고 있으면 나중에 옮길 때의 부담이 크게 줄어듭니다.
4. 누가 운영하는가
플랫폼이 도구를 주더라도, 에이전트가 틀렸을 때 확인하고 고치는 사람은 필요합니다. 운영 담당이 정해지지 않은 에이전트는 몇 달 뒤 아무도 쓰지 않게 됩니다.
작은 회사라면
수십 명 규모의 회사가 기업용 플랫폼을 전부 도입할 필요는 없습니다. 업무 하나를 정해 에이전트 하나를 만들고, 그 경험으로 필요한 것을 파악한 뒤에 플랫폼을 검토해도 늦지 않습니다. 처음부터 큰 그림을 그리는 것보다, 작게 만들어 실제로 써 보는 편이 판단에 도움이 됩니다.
참고 자료