개발자의 로컬 환경에서는 완벽하게 돌아가던 AI 에이전트가 프로덕션 환경으로 나가는 순간 예상치 못한 장벽에 부딪히는 일을 겪어본 분들이 많을 것입니다. 분명히 로컬에서는 잘 되던 것이 프로덕션 환경의 인프라에 배포하는 순간 예상치 못했던 문제로 제대로 돌아가지 않는 이유는 무엇일까요?
AI 에이전트라는 새로운 유형의 워크로드와 AI 인프라의 특성 때문입니다. 이를 수용해 운영 환경에서도 안정적으로 AI 에이전트를 배포해 운영하려면 비용, 확장성, 보안, 관측성(Observability) 같은 다양한 요소를 고려해야 합니다. 문제는 이게 쉽지 않다는 것이죠.
이를 직접 내부 플랫폼 엔지니어링 역량으로 해결할 수 없다고 고민할 필요는 없습니다. 클라우드라는 대안이 있기 때문입니다. 이번 포스팅에서는 Agentic AI 시대를 위한 인프라와 플랫폼 구축과 운영에 있어 클라우드 컴퓨팅 환경에서 비용, 확장성, 보안, 관측성을 확보하여 Agentic AI 시대에 대비하는 방법을 알아보겠습니다.
서버리스에서 답을 찾다!
AI 에이전트 배포와 운영을 위한 인프라와 플랫폼을 구축하며 맞닥뜨리는 문제 중 가장 장벽이 높은 것은 비용입니다. 요청이 몰릴 때를 대비해 값비싼 AI 가속기 자원을 항상 켜두는 방식은 자원과 비용 모두를 낭비할 수밖에 없습니다. 이러한 난제를 해결할 해답은 “사용할 때만 자원을 할당하는 구조”를 설계하는 것입니다. 현실적으로 이를 실현할 수 있는 빠르고 확실한 방법은 서버리스 컴퓨팅입니다. 구글 클라우드의 Cloud Run을 통해 그 이유를 정리하면 다음과 같습니다.
- 과금의 경제성: 요청이 들어오는 순간에만 자원을 할당하고 작업이 끝남과 동시에 즉시 반납하는 사용한 만큼 과금하는 방식으로 자원과 비용 낭비 걱정이 없습니다.
- 유연한 확장성(Scale to Zero): 사용자가 없는 한산한 시간에는 자원 사용량을 0으로 줄여 유휴 비용을 완전히 없앱니다. 반대로 트래픽이 쏟아지는 피크 타임에는 수초 이내에 다수의 장치로 자동 확장하여 빈틈없이 대응합니다.
모델 서빙 전략
Cloud Run을 선택한 다음 엔지니어는 모델을 직접 호스팅할 것인지 외부 API를 불러올 것인지 결정해야 합니다. 보통 보안과 거버넌스 이유로 직접 호스팅을 택하는 조직이 많습니다. 직접 호스팅을 하면 데이터가 VPC 밖으로 나가지 않고 이용 규모가 커질 경우 토큰당 비용이 API 호출보다 저렴하다는 이점을 누릴 수 있습니다.
자체 호스팅을 선택했다면 서빙 전략을 선택해야 합니다. 일반적으로 Ollama와 vLLM을 놓고 고민을 합니다. 내부용 도구나 데모 시스템을 신속하게 구축할 때 Ollama 방식이 적합합니다. Ollama는 다양한 오픈 모델을 간단한 명령어로 로컬 및 클라우드 환경에서 손쉽게 실행할 수 있도록 설계된 프레임워크입니다. Cloud Run에 Ollama를 배포할 때 모델 파일을 컨테이너 이미지 안에 직접 번들링하는 방식을 선택하면 인스턴스 기동 후 별도의 다운로드 없이 곧바로 모델을 사용할 수 있어 설정이 단순합니다.
하지만 대규모 트래픽을 감당해야 하는 실제 운영 환경에서는 vLLM이 정답입니다. vLLM은 메모리를 관리하는 혁신적인 알고리즘을 사용하여 하드웨어 자원의 낭비를 줄이고 처리량을 극대화합니다. 실제 사례를 보면 기존 방식보다 추론 비용을 절감하면서도 더 많은 동시 요청을 처리한 성과가 뚜렷합니다.
vLLM의 또다른 장점은 모델 가중치와 서빙 코드를 분리한다는 것입니다. vLLM은 모델 파일은 전용 저장소에 따로 보관하고, 서비스가 시작될 때 이를 네트워크로 연결하여 읽어오는 방식을 취합니다. 이렇게 설계하면 새로운 모델이 나왔을 때 무거운 컨테이너 전체를 다시 만들지 않고도 저장소의 파일만 교체하여 실시간으로 모델의 지능을 업데이트할 수 있습니다.
네트워크 계층에서 구현하는 보안 방어선
인프라와 서빙 플랫폼을 토대를 마련했다면 다음 해야 할 일은 보안성을 확보하는 것입니다. AI 에이전트를 외부에 노출하는 순간 다음과 같은 공격을 받을 수 있습니다.
- 프롬프트 인젝션(Prompt Injection): 모델에게 “시스템 파일을 출력해” 같은 지시를 숨겨 넣어, 원래 설계와 다른 동작을 유도하는 공격입니다.
- 탈옥(Jailbreak): “우리는 지금 소설을 쓰고 있으니 안전 필터를 무시해”처럼 맥락을 조작해 모델의 안전장치를 우회하려는 시도입니다.
구글 클라우드의 Model Armor는 AI 전용 보안 게이트웨이 역할을 수행할 수 있습니다. Gemini, OpenAI, Anthropic, Llama 등 특정 모델에 종속되지 않는 모델 무관(model-agnostic) 서비스로 REST API를 통한 직접 통합뿐 아니라 Vertex AI 및 Apigee API 게이트웨이와도 연동하여 조직 전체의 AI 트래픽에 일관된 보안 정책을 적용할 수 있습니다.
모든 요청이 AI 모델에 도달하기 전에 이 관문을 반드시 통과하도록 경로를 설정하면 사용자의 질문을 실시간으로 가로채어 그 안에 숨겨진 악의적인 의도가 있는지 혹은 기업의 기밀이나 개인정보 유출 시도가 포함되어 있는지를 검사합니다.
만약 부적절한 요청이라고 판단하면 모델 근처에도 가지 못하도록 즉시 차단하고 사용자에게 안내 메시지를 보냅니다. 모델이 답변을 생성한 뒤에도 다시 한번 검사를 거쳐 유해한 콘텐츠나 민감한 정보가 외부로 나가는 것을 원천 봉쇄합니다. 또한, 자율성이 높은 AI 에이전트는 실제 시스템과 격리된 샌드박스에서 구동하여 혹시 모를 위협이 전체 시스템으로 번지는 것을 막아야 합니다. 특히 결제나 데이터 삭제 같은 위험한 작업은 인공지능이 독단적으로 처리하지 못하도록 사용자의 최종 승인 단계를 반드시 포함해야 합니다.
배포 자동화
인프라와 플랫폼을 아무라 질 설계해도 배포를 수작업 방식으로 하면 엔지니어의 마음은 늘 불안할 수밖에 없습니다. 구글 클라우드 환경에서는 Cloud Build로 AI 에이전트 배포 자동화하여 불안감을 해소할 수 있습니다.
Cloud Build로 배포 파이프라인을 자동화하는 구조는 단순합니다. 코드를 컨테이너로 빌드하고, Artifact Registry에 푸쉬하고, Cloud Run에 배포합니다. 참고로 보안성을 고려해 환경 변수를 설정할 수 있습니다. AI 에이전트가 vLLM을 직접 호출하는 것이 아니라 로드밸런서를 바라보도록 설정하면 모든 요청이 Model Armor를 통하도록 할 수 있습니다.
완성한 파이프라인을 Git 리포지토리에 연결하면 코드를 푸시 할때마다 AI 에이전트가 자동으로 빌드, 테스트, 배포됩니다.
관측성 확보
AI 에이전트는 한번 배포해 잘 돌아간다고 신경을 더이상 쓰지 않아도 되는 워크로드가 아닙니다. AI 에이전트는 지속해서 추적하고 성능을 개선해야 합니다. 이를 위해 필요한 요소가 관측성입니다.
구글 클라우드의 경우 ADK의 Cloud Trace 기능과 OpenTelemetry 라이브러리를 연동해 AI 에이전트에 대한 관측성을 확보할 수 있습니다. 개발자는 각 요청이 AI 에이전트에 도달한 시점, 모델이 생각하는 데 걸린 시간, 네트워크 호출 시간 등을 파악해 품질과 성능을 개선할 수 있습니다.
한편, 관측성 확보는 인프라 상태 파악에도 중요합니다. 구글 클라우드 환경에서는 Prometheus 사이드카 컨테이너를 vLLM 컨테이너와 함께 배포하면 vLLM 메트릭 엔드포인트를 주기적으로 스크리핑하여 Cloud Monitoring으로 전송합니다. 이러한 수집한 정보를 토대로 첫 번째 토큰 생성 시간, 토큰 생성 속도, GPU 활용률 같은 중요 관리 지표를 확인할 수 있습니다.
지속 가능한 인프라 & 플랫폼
AI 에이전트를 로컬에서 구현해 실행하는 것은 쉽습니다. 하지만 살펴본 바와 같이 실제 운영 환경에 배포하려면 여러 요소를 포괄적으로 고려해야 합니다. 그래야만 유행을 타지 않는 지속 가능한 AI 인프라와 플랫폼 환경을 구축해 안정적으로 AI 에이전트를 배포하고 운영할 수 있습니다.
지금 바로 실행에 옮기고자 한다면 메가존소프트 문의포탈을 통해 궁금한 부분을 남겨주세요.
