컨테이너를 활용한 AI 워크로드 소프트웨어 엔지니어링 강화

AI 워크로드가 실험적인 프로토타입에서 프로덕션 환경으로 이동함에 따라, 기업은 기존 소프트웨어 애플리케이션과 동일한 엄격한 기준으로 새로운 구성 요소를 보호하고 관리하며 거버넌스를 적용해야 하는 과제에 직면해 있습니다. 이 문제의 핵심 해결책은 조직에서 이미 널리 사용하고 있는 컨테이너, 특히 OCI(Open Container Initiative) 컨테이너에 있습니다.

Open Container Initiative란 무엇인가요?

Open Container Initiative는 이미지 형식, 컨테이너 런타임, 배포에 대한 개방형 사양을 정의하여 조직이 특정 벤더에 종속되는 현상을 방지하도록 지원합니다.  OCI 컨테이너는 소프트웨어 애플리케이션 패키징을 위한 업계 표준 형식이므로 다양한 환경, Docker 또는 Podman과 같은 컨테이너 엔진, 클라우드 플랫폼 전반에서 일관되게 실행할 수 있습니다.

OCI 아티팩트는 컨테이너와 유사하지만, 실행 가능한 이미지 대신 파일 및 디렉터리와 같은 기타 콘텐츠를 저장합니다.  OCI 호환 아티팩트 리포지토리(Quay, Artifactory, Docker Hub 및 주요 클라우드 공급업체의 레지스트리 포함)는 OCI 컨테이너 및 아티팩트를 저장하고 버전 관리를 수행할 수 있습니다.

OCI는 표준화되고 이식 가능한 방식으로 소프트웨어를 패키징하고 배포하는 방법을 제공합니다. OCI 컨테이너를 사용하여 AI 모델, 모델 컨텍스트 프로토콜(MCP) 서버, AI 에이전트를 패키징하면 기존 소프트웨어 공급망 보안 프로세스, CI/CD 파이프라인, 컨테이너 오케스트레이션 인프라를 그대로 활용할 수 있습니다. 이러한 접근 방식을 통해 애플리케이션 워크로드에 이미 적용 중인 것과 동일한 거버넌스 및 감사 기능을 AI 스택에도 구현할 수 있습니다.

ModelCar를 사용한 AI 모델 컨테이너화

대규모 언어 모델(LLM) 및 기타 AI 모델은 고유한 패키징 과제를 안고 있습니다. 이러한 모델은 대규모 바이너리 파일, 구성 메타데이터, 특정 파일 구조 요구 사항으로 구성됩니다. 과거에는 조직이 S3 호환 오브젝트 스토리지를 사용하여 모델을 배포했지만, 이러한 방식은 기존 컨테이너 기반 워크플로우 및 보안 프로세스와의 마찰을 초래합니다. Red Hat은 ModelCar라고 부르는 특정 파일 구조를 사용하여 AI 모델을 OCI 컨테이너로 빌드할 것을 권장합니다.

ModelCar 컨테이너란 무엇인가요?

ModelCar 컨테이너 구조는 매우 단순합니다. AI 모델 파일을 컨테이너 내의 /models 폴더에 배치하면 됩니다. 추가 패키지나 런타임 구성 요소는 필요하지 않으며, 컨테이너는 OCI 준수 형식의 모델 아티팩트를 보관하는 역할만 수행합니다.

이러한 접근 방식은 상당한 이점을 제공합니다. 모델이 컨테이너로 패키징되면, 기존 애플리케이션 컨테이너에 사용하던 동일한 소프트웨어 공급망 보안 프로세스를 활용해 이를 관리할 수 있습니다. CI/CD 파이프라인의 태스크로 컨테이너에 대한 소프트웨어 자재 명세서(SBOM) 및 AI 자재 명세서(AI-BOM)를 생성할 수 있습니다. 또한 컨테이너에 서명하고 유효성을 검사하며, 신뢰할 수 있는 빌드 시스템에서 컨테이너가 빌드되었음을 증명하는 출처 증명을 생성할 수 있습니다. 아울러 컨테이너를 내부 OCI 아티팩트 리포지토리에 저장하고, 승인된 리포지토리에서만 컨테이너를 가져오도록 배포 정책을 구성할 수 있습니다.

Red Hat Trusted Artifact Signer를 사용하면 모델에 서명하고, Sigstore 및 Rekor를 활용하여 모델의 신뢰성과 투명성을 검증할 수 있습니다. 

Red Hat OpenShift AI 2.14 이상 버전은 KServe를 통해 ModelCar 컨테이너에서 직접 모델을 서빙할 수 있도록 지원하여 S3 호환 스토리지에 대한 종속성을 완전히 제거합니다. 이 방식은 배포를 간소화하고, 특히 컨테이너가 노드에 캐시된 경우 추론 서버 시작 시간을 단축하며, 조직 전반에서 아티팩트 관리에 대한 통합된 접근 방식을 제공합니다.

GitHub 리포지토리에서 제공되는 예시 ModelCar 컨테이너 카탈로그를 통해 다양한 모델 유형 패키징을 위한 템플릿과 모범 사례를 확인할 수 있습니다.

모델 크기 고려 사항

OCI 사양은 이미지 크기에 엄격한 제한을 두지 않지만, 실질적인 제약 조건이 존재합니다. 컨테이너 레지스트리는 일반적으로 수 GB에서 수십 GB 범위의 이미지를 지원하며, 대부분의 엔터프라이즈 레지스트리는 최대 15~20GB의 이미지를 문제없이 처리합니다. 이러한 실질적인 제한을 초과하는 초대형 모델의 경우, 파일 크기를 줄이기 위한 모델 양자화 기술 또는 대체 배포 메커니즘을 고려해야 할 수 있습니다. 그러나 대부분의 프로덕션 모델, 특히 8비트 부동 소수점(FP8) 또는 4비트 정수(INT4)와 같은 양자화된 변형의 경우 ModelCar를 사용한 컨테이너화가 실용적이며 권장됩니다.

모델용 OCI 아티팩트

ModelCar는 OCI 아티팩트를 완전히 지원하지 않는 이전 시스템과의 호환성을 극대화하기 위해 OCI 컨테이너를 사용하지만, 모델 스토리지에는 OCI 아티팩트가 더 효율적이고 우수한 선택입니다. 

빌드 엔지니어는 모델을 컨테이너 대신 OCI 아티팩트로 패키징하여 OCI 아티팩트 리포지토리에 저장할 수 있습니다. 배포 시 쿠버네티스 이미지 볼륨을 사용하여 OCI 아티팩트를 스토리지로 모델 서비스 포드에 직접 마운트할 수 있습니다. OCI 아티팩트 마운트는 현재 최신 버전의 podman 및 CRI-O 컨테이너 런타임에 구현되어 있으며, Containerd를 비롯한 기타 런타임에 대한 작업이 진행 중입니다.

엔터프라이즈 배포를 위한 MCP 서버 컨테이너화

MCP는 AI 어시스턴트와 에이전틱 AI를 외부 툴, 데이터 소스, API와 연결하는 표준 방식으로 부상했습니다. MCP 서버는 AI 시스템과 엔터프라이즈 리소스를 연결하는 가교 역할을 하므로, 해당 서버의 보안과 거버넌스가 매우 중요합니다.

여러 팀에서 공유하거나 프로덕션 환경에 배포할 MCP 서버의 경우, 다른 애플리케이션에 사용하는 것과 동일한 빌드 툴과 프로세스를 사용하여 컨테이너로 빌드하는 것이 좋습니다. 이러한 접근 방식은 이러한 구성 요소를 관리, 배포, 보호하는 방식에 일관성을 제공합니다. 이 프로세스는 컨테이너 파일을 작성하고, 이미지를 빌드하고, 레지스트리로 푸시하고, Red Hat OpenShift, 쿠버네티스, Podman 또는 Docker를 사용하여 배포하는 등 애플리케이션을 컨테이너화해 본 경험이 있다면 누구에게나 익숙할 것입니다.  일반적인 빌드 툴을 사용하여 MCP 서버를 서명 및 검증하고, SBOM을 생성하고, OCI 아티팩트 리포지토리에 저장하는 등의 작업을 수행할 수 있습니다.

다른 소프트웨어와 마찬가지로 악성 코드가 MCP 서버에 침투할 가능성이 있습니다. Red Hat Trusted Profile Analyzer를 사용하여 MCP 서버를 분석하고 지속적으로 검증함으로써 취약점, 악성 종속성, 정책 위반을 식별하세요.

컨테이너화된 MCP 서버의 장점

컨테이너화된 MCP 서버는 수평적으로 확장하여 증가된 부하를 처리하고, 표준 관측성 툴을 사용하여 모니터링하며, 기존 보안 정책을 통해 거버넌스를 수행할 수 있습니다.

OpenShift Kubernetes MCP 서버는 이 패턴을 보여줍니다. 개발을 위해 로컬에서 실행하거나 팀 액세스를 위해 Streamable HTTP 전송을 사용하여 클러스터 내에 배포할 수 있습니다. 이 서버는 구성 가능한 액세스 모드(읽기 전용, 비파괴 또는 전체 액세스)를 지원하며, 권한 부여를 위해 쿠버네티스 역할 기반 액세스 제어(RBAC)와 통합됩니다.

컨테이너화된 MCP 서버를 중심으로 에코시스템이 이미 성장하고 있습니다. 예를 들어 MCP 라이프사이클 오퍼레이터를 사용하면 컨테이너화된 MCP 서버를 배포하고 쿠버네티스 네이티브 구성을 통해 에이전트에 연결하는 작업을 원활하게 수행할 수 있습니다. Kuadrant MCP 게이트웨이는 고급 엔터프라이즈 보안 기능을 제공합니다. Docker와 같이 널리 사용되는 다른 툴도 컨테이너 내의 MCP 서버와 연동됩니다.

MCP 서버를 컨테이너화하지 않는 경우

모든 MCP 서버가 컨테이너화의 이점을 누리는 것은 아닙니다. MCP 사양은 stdio(표준 입력/출력) 및 HTTP 기반 전송(Streamable HTTP 및 레거시 SSE(Server-Sent Events) 전송 포함)이라는 두 가지 기본 전송 메커니즘을 지원합니다. 이러한 차이는 배포 결정에 있어 중요한 요소입니다.

Stdio 기반 MCP 서버는 프로세스 스트림을 통해 통신하며, AI 클라이언트는 서버를 하위 프로세스로 생성합니다. 이 모델은 개발자의 코딩 어시스턴트, 로컬 생산성 도구 또는 개인용 자동화 스크립트와 같은 단일 사용자 시나리오에 적합합니다. 이러한 시나리오에서 MCP 서버는 사용자의 노트북에서 실행되어 로컬 파일과 리소스에 액세스하며, 더 이상 필요하지 않으면 종료됩니다. stdio MCP 서버를 컨테이너화하는 것은 이러한 단일 사용자 로컬 활용 사례에 큰 이점 없이 복잡성만 가중시킵니다.

반면 HTTP 기반 MCP 서버는 여러 클라이언트 연결을 동시에 처리할 수 있는 독립적인 프로세스로 실행됩니다. 이 서버는 네트워크 엔드포인트를 노출하며 전통적인 웹 서비스와 유사하게 작동합니다. 이러한 서버는 컨테이너화하기에 적합하며 중앙 집중식 배포, 확장 및 관리의 이점을 누릴 수 있습니다.

의사 결정 프레임워크는 다음과 같습니다. 

• 공유/프로덕션 환경: MCP 서버를 팀에서 공유하거나, 네트워크를 통해 액세스하거나, 서버 환경에 배포해야 하는 경우 해당 서버를 컨테이너화하세요.
• 컨테이너화된 에이전트: 에이전트가 컨테이너에서 실행 중인 경우 stdio 기반 MCP 서버는 에이전트와 동일한 컨테이너에서 실행되어야 하며, HTTP 기반 MCP 서버는 별도의 컨테이너에서 실행되어야 합니다.
• 단일 사용자 로컬 사용: MCP 서버가 stdio 전송을 사용하여 단일 개발자의 머신에서 로컬로 실행되는 경우 컨테이너화는 선택 사항이며 불필요한 오버헤드가 발생할 수 있습니다. 

에이전트 스킬 컨테이너화

에이전트 스킬은 MCP 서버를 보완하는 대안으로 부상했습니다. 에이전트 스킬은 "에이전트가 작업을 더 정확하고 효율적으로 수행하기 위해 검색하고 사용할 수 있는 지침, 스크립트 및 리소스 폴더"를 의미합니다. 스킬 사양에 따라 해당 스킬은 zip 파일로 패키징됩니다. 

빌드 시스템을 확장하여 모델 및 MCP 서버와 마찬가지로 스킬을 OCI 컨테이너 또는 아티팩트로 패키징할 수 있습니다. 그러면 스킬에 서명하고 검증하며, SBOM을 생성하고, OCI 아티팩트 리포지토리에 저장할 수 있습니다. 또한 모델과 마찬가지로 스킬을 다운로드하여 포드에 연결할 수도 있습니다. 스킬에는 플랫폼에 따라 달라질 수 있는 스크립트가 포함될 수 있으므로, OCI는 각 플랫폼에 맞는 파일 세트를 제공하는 기능도 갖추고 있습니다. 스킬 지원 애플리케이션이 아직 OCI 컨테이너 또는 아티팩트와 호환되지 않는 경우 ORAS 커맨드라인 유틸리티를 사용하여 스킬을 올바른 디렉터리에 추출할 수 있습니다. 

또는 향후 다양한 프로그래밍 언어의 공유 라이브러리 관리 방식과 유사하게 패키지 관리자를 통해 스킬을 관리할 수도 있습니다. 이 경우 스킬은 컨테이너 내에서 가져와 사용되지만, 반드시 컨테이너 자체로 배포될 필요는 없습니다. 

이는 새로운 기술이므로 향후 발전 과정을 지켜봐 주세요! 

AI 에이전트 컨테이너화

AI 에이전트는 AI 모델과 기타 도구를 사용하여 다단계 작업을 계획하고 실행할 수 있는 자율 시스템으로, 차세대 AI 애플리케이션을 대표합니다. 에이전트가 프로토타입 단계에서 프로덕션 단계로 전환됨에 따라 기업은 에이전트 구축, 배포 및 관리를 위한 체계적인 접근 방식이 필요합니다.

Kagenti 프로젝트는 바로 이러한 목적을 위해 쿠버네티스 네이티브 프레임워크를 제공합니다. Kagenti는 모든 에이전트 프레임워크 또는 SDK와 호환되며 프로덕션 배포를 위한 모듈식 구성 요소를 제공합니다. Kagenti는 기본적으로 에이전트를 쿠버네티스 사용자 정의 리소스를 사용하여 선언적으로 정의할 수 있는 컨테이너화된 워크로드로 취급합니다.

Kagenti는 Shipwright 및 Buildah를 사용하여 에이전트를 컨테이너로 빌드합니다. 조직에서 CI/CD에 Tekton 또는 Jenkins를 사용하는 경우 기존 파이프라인에 유사한 Buildah 작업을 추가할 수 있습니다. AI 모델 및 MCP 서버와 마찬가지로 일반적인 빌드 도구를 사용하여 에이전트 컨테이너에 서명 및 확인하고, SBOM을 생성하고, OCI 아티팩트 리포지토리에 저장하는 등의 작업을 수행할 수 있습니다.

MCP 서버와 마찬가지로 컨테이너화된 에이전트는 부하 증가를 처리하기 위해 수평적으로 확장하고, 표준 관측성 도구를 사용하여 모니터링하며, 기존 보안 정책을 통해 관리할 수 있습니다.  또한 Red Hat Trusted Profile Analyzer를 사용하여 에이전트를 분석하고 지속적으로 검증함으로써 취약점, 악성 종속성 및 정책 위반을 식별할 수 있습니다.

단일 사용자 에이전트 및 하위 에이전트

MCP 서버와 마찬가지로 모든 에이전트에 컨테이너화가 필요한 것은 아닙니다. 코딩 어시스턴트 또는 개인용 자동화 에이전트에서 생성된 하위 에이전트와 같이 단일 사용자의 노트북에서 로컬로 실행되는 에이전트에는 컨테이너 패키징 및 쿠버네티스 배포와 같은 오버헤드가 필요하지 않을 수 있습니다. 이러한 경량 에이전트는 주로 상위 애플리케이션의 하위 프로세스로 실행되며 해당 애플리케이션의 보안 컨텍스트를 공유합니다.

이러한 단일 사용자 시나리오에서는 모든 하위 구성 요소를 컨테이너화하기보다 상위 애플리케이션(IDE, 코딩 어시스턴트 또는 자동화 도구)이 적절하게 보호되는지 확인하는 데 중점을 두어야 합니다. 이러한 로컬 에이전트의 엔터프라이즈 관리는 지속적으로 발전하는 영역이므로, 조직은 에이전트 프레임워크 및 도구의 개발 동향을 모니터링해야 합니다.

샌드박싱용 컨테이너

코드를 작성하고 실행하는 에이전트, MCP 서버 및 모델은 새로운 취약점을 유발할 수 있으므로, 시스템 액세스를 제한하고 발생 가능한 피해를 방지하는 것이 가장 좋은 방법입니다. 이러한 방식은 '에이전트 샌드박스' 또는 '코드 샌드박스'라고도 불립니다. 

컨테이너화된 소프트웨어는 포트 개방 및 차단부터 특정 웹사이트 및 서비스의 허용 목록 지정에 이르기까지 외부 서비스와의 통신을 제한하는 네트워크 정책과 함께 배포할 수 있습니다. 쿠버네티스 RBAC 및 서비스 메시 기능은 액세스에 대한 세밀한 제어를 제공합니다. Red Hat OpenShift 컨테이너는 일반적으로 루트 권한 없이 실행되므로 데이터 및 컴퓨팅 리소스에 대한 액세스가 제한됩니다.  

컨테이너는 CPU 및 메모리 사용량도 제한할 수 있습니다. 개발자 워크스테이션에서 Podman은 기본적으로 루트 권한 없이 컨테이너를 실행하며, 네트워크 및 파일 시스템에 대한 컨테이너의 액세스도 제한합니다. Red Hat OpenShift는 오랫동안 컨테이너 격리 기능을 제공해 왔으며, Red Hat build of Podman Desktop를 통해 개발자 워크스테이션에서도 컨테이너 격리가 가능합니다.

또 다른 우려 사항은 에이전트의 프로세스 폭주로 인해 서비스 거부 공격이 발생하는 경우입니다. 클러스터 관리자는 Red Hat OpenShift를 사용하여 각 네임스페이스에 resource quotas를 설정함으로써 개별 프로젝트가 소비할 수 있는 GPU, CPU, 메모리 및 스토리지 리소스를 제한할 수 있습니다. 적절한 리소스 할당량을 설정하면 폭주하는 에이전트가 다른 워크로드의 클러스터 리소스를 고갈시키는 상황을 방지할 수 있습니다.

개인용 노트북에서도 실행할 수 있지만, 코딩 어시스턴트와 개인용 에이전트를 컨테이너에서 실행하는 것이 효율적인 경우가 많습니다. 샌드박스 처리된 컨테이너에서 에이전트를 실행하면 노트북의 중요한 문서가 손상되거나 원치 않는 데이터에 에이전트가 액세스하는 것을 방지할 수 있습니다. 즉, 파일 읽기/쓰기와 같은 일반적인 작업을 사전에 승인한 후 최소한의 감독으로 에이전트를 실행하고 할당된 작업의 최종 결과만 검토하면 됩니다.

또한 여러 에이전트를 동시에 시작하여 서로 간섭하지 않고 병렬로 작업을 수행하도록 할 수 있습니다. 장기 실행 에이전트를 Red Hat OpenShift의 개인 네임스페이스에 배포하면 노트북을 닫고 퇴근하더라도 에이전트가 작업을 계속 수행합니다. 에이전트의 컨테이너를 저장하여 상태를 유지하고 나중에 다시 시작할 수도 있습니다. 이 영역에서 새롭게 떠오르는 두 가지 프로젝트는 코딩 에이전트용 paude와 OpenClaw용 openclaw-installer입니다.

AI 워크로드 컨테이너화의 장점

모델, MCP 서버, 에이전트와 같은 AI 구성 요소를 컨테이너화하면 조직 전반에 걸쳐 큰 시너지 효과를 내는 이점을 얻을 수 있습니다.

소프트웨어 공급망 보안

배포 전에 컨테이너를 서명, 증명 및 검증할 수 있습니다. 신뢰할 수 있는 CI/CD 시스템에서 모든 AI 구성 요소를 구축하고, 취약점을 검사하며, 승인된 레지스트리에 저장하도록 요구할 수 있습니다. 출처 증명은 각 아티팩트의 생성 과정을 정확히 보여주는 감사 추적 기능을 제공합니다.

버전 제어 및 롤백

컨테이너 이미지는 불변하며 태그가 지정됩니다. 특정 버전을 배포하고, 문제가 발생하면 이전 버전으로 롤백하며, 배포된 항목과 시기에 대한 명확한 이력을 유지할 수 있습니다.

일관된 배포

동일한 컨테이너 이미지가 개발, 스테이징, 프로덕션 환경에서 동일하게 실행되므로 환경 간에 파일이 잘못 복사될 위험이 줄어듭니다.

관측성

컨테이너화된 워크로드는 기존 모니터링 및 로깅 인프라와 통합됩니다. 예를 들어, Kagenti는 즉시 사용 가능한 OpenTelemetry(OTEL) 추적을 지원하므로 표준 관측성 스택을 사용하여 에이전트 작업을 모니터링할 수 있습니다.

격리 및 액세스 제어

마지막으로, 컨테이너는 샌드박싱을 위한 강력한 기능을 제공하여 문제 발생 시 영향 범위를 제어하는 데 도움이 됩니다.

향후 전망: 워크로드 Identity 및 제로 트러스트

컨테이너화는 더 발전된 보안 패턴을 위한 기반을 마련합니다. Kagenti 프로젝트는 에이전트 및 MCP 서버를 위한 워크로드 아이덴티티 및 제로 트러스트 아키텍처를 위해 SPIFFE/SPIRE와의 통합을 모색하고 있습니다. 이러한 기능은 아직 초기 단계이지만, AI 구성 요소를 컨테이너화하여 쿠버네티스에서 실행하면 기술이 성숙함에 따라 이러한 보안 기능을 훨씬 쉽게 도입할 수 있습니다.

워크로드 아이덴티티는 각 에이전트나 MCP 서버가 암호화 방식으로 검증 가능한 Identity를 갖도록 보장하여, 공유 암호 없이도 안전한 서비스 간 통신을 가능하게 합니다. AI 구성 요소를 컨테이너화하고 기존 Identity 및 액세스 관리 인프라와 통합하면, '절대 신뢰하지 않고 항상 검증하는' 제로 트러스트 원칙을 실무에 적용할 수 있습니다.

최종 의견

OCI 컨테이너는 AI 워크로드로 자연스럽게 확장되는, 검증되고 표준화된 소프트웨어 패키징 및 배포 방식을 제공합니다. AI 모델, MCP 서버, 에이전트를 컨테이너화하면 기존 애플리케이션에 적용하던 것과 동일한 수준의 거버넌스, 보안, 운영 성숙도를 AI 스택에 적용할 수 있습니다.

핵심은 컨테이너화가 가치를 더하는 시점을 인식하는 것입니다. 컨테이너는 공유 및 네트워크 기반의 프로덕션 배포에 필수적입니다. 단일 사용자나 로컬 환경에서 컨테이너 사용은 선택 사항이지만, 샌드박싱 기능과 '한 번 빌드하면 어디서나 실행되는' 기기 간 이식성을 제공합니다. 이러한 실용적인 접근 방식을 통해 불필요한 복잡성을 피하면서 각 구성 요소에 적절한 수준의 거버넌스를 적용할 수 있습니다.

Red Hat OpenShift AI, Red Hat Trusted Artifact Signer, Red Hat Trusted Profile Analyzer 그리고 Red Hat build of Podman은 프로토타입부터 프로덕션 단계까지 AI 워크로드를 관리할 수 있는 견고한 기반을 제공합니다. Red Hat은 활발한 커뮤니티가 형성된 오픈소스 툴에 엔터프라이즈 지원을 더하여 사용자가 최신 AI 발전 속도에 발맞출 수 있도록 지원합니다.