CoreProse KB-incidents에 최초 게시됨

향후 몇 년 동안 AI의 핵심적인 활동은 채팅 UI와 코파일럿 (copilots)에서 기업의 운영 중추인 전력망, 공장, 물류 네트워크 및 기업 제어 평면 (control planes)으로 이동할 것입니다.[5]

조직이 AI를 의사결정 파이프라인 (decision pipelines), CI/CD, 그리고 클라우드 거버넌스 (cloud governance)에 연결함에 따라, 오늘날의 "마법 상자"와 같은 LLM (Large Language Models)은 내일의 안전 필수 인프라 (safety‑critical infrastructure)가 됩니다.[4][5]

추론하고, 계획하며, 행동하는 에이전트 시스템 (Agentic systems)은 단순히 변경 사항을 제안하는 데 그치지 않고, 티켓을 생성하고, IaC (Infrastructure as Code)를 수정하며, 오토스케일링 (autoscaling)을 조정하고, 수천 개의 리소스에 걸쳐 정책을 집행할 것입니다.[1][2][3]

이 글은 이를 안전하게 수행하는 데 필요한 스택과 왜 전통적인 MLOps 및 "LLM-as-an-API" 패턴만으로는 더 이상 충분하지 않은지에 대해 설명합니다.[1][3][4]

1. 실험적 AI에서 운영 중추로

현대 기업들은 AI를 핵심 의사결정 파이프라인, 팀 간 워크플로우, 분석 엔진 및 실행 계층에 내재화하고 있습니다.[5]

• AI는 단순한 조력자에서 트랜잭션, 정책 및 고객 상호작용을 중재하는 운영의 _중추 (backbone)_로 전환되고 있습니다.[5]
• 일단 인프라, 컴플라이언스 (compliance), 재무 시스템과 연결되면, AI의 오류는 단순한 잘못된 제안을 넘어 가동 중단(outages)과 사고(incidents)를 유발합니다.

📊 주요 변화

• 초기: 고립된 코파일럿 (copilots), PoC (Proof of Concepts)
• 현재: 자금을 이동시키고, 인프라를 프로비저닝하며, 컴플라이언스 워크플로우를 트리거하는 프로세스 내의 AI
• 다음: 클라우드, 데이터 및 장치를 위한 기본 제어 계층으로서의 AI[3][5]

이는 실험적인 앱보다는 산업 제어 시스템 (industrial control systems)에 더 가까운 안정성, 관측 가능성 (observability), 그리고 예측 가능성을 요구합니다.[5]

에이전트 AI (Agentic AI)는 이를 가속화합니다:

• 다단계 추론 (Multi-step reasoning) 및 도구 사용 (tool use)은 소프트웨어 개발 생명주기 (SDLC)의 각 단계를 자율적인 흐름으로 전환합니다.[2]
• 이제 질문은 AI가 엔지니어링 워크플로우에 참여할 것인가가 아니라, 우리가 얼마나 의도적으로 AI가 행동하도록 허용할 것인가로 바뀝니다.[2]

💼 일화 (Anecdote)

• 300명 규모의 엔지니어를 보유한 SaaS 기업의 한 "DevOps 어시스턴트"는 실제 Terraform PR을 생성하기 시작했습니다.
• 이 어시스턴트는 GPU 노드 풀 (node pools)과 VPC 규칙을 제어하는 준 (quasi-) SRE 에이전트가 되었습니다.
• 인프라 팀은 사후에 가드레일 (guardrails), 승인 절차, 로깅 시스템을 소급하여 구축해야 했습니다.

에이전트가 다음 요소들에 대한 제어권을 얻음에 따라:[1][3][4]

• GPU 플릿 (fleets) 및 오토스케일러 (autoscalers)
• 배포 파이프라인 (deployment pipelines) 및 라우팅 (routing)
• 컴플라이언스 (compliance) 집행 및 증거 수집

…AI 스택은 물리적 인프라와 분산 장치를 위한 제어 패브릭 (control fabric)이 되며, 산업용 제어 기술 (industrial control tech)과 같이 취급되어야 합니다.[3][5]

⚠️ ML/플랫폼 팀을 위한 시사점

표준 MLOps (모델 레지스트리 + 상태가 없는 (stateless) 추론 + 기본 모니터링)는 다음을 커버하지 못합니다:[1][3]

• 장시간 실행되는 에이전트 세션 (long-running agent sessions)
• 도구 호출 (tool-calling) 보안 및 정책
• 인간 참여형 (human-in-the-loop) 승인
• 인프라와 컴플라이언스를 아우르는 교차 시스템 워크플로우

이 기사의 나머지 부분에서는 AI가 안전하게 "하드웨어 (the metal)"를 직접 다루기 전에 반드시 추가해야 할 사항들을 설명합니다.

2. 에이전트형 인프라 (Agentic Infrastructure): 물리적 영향력 뒤에 숨겨진 스택

에이전트형 인프라는 밀리초 단위가 아닌, 몇 분 또는 몇 시간 동안 작동하는 에이전트에게 필요한 런타임 (runtime), 오케스트레이션 (orchestration), 상태 (state), 도구 통합 (tool-integration), 메모리 (memory), 보안 (security), 그리고 관측 가능성 (observability)을 의미합니다.[1]

이는 단순한 LLM 서빙 (serving)과는 구별되며, 전용 플랫폼 항목으로 다뤄질 가치가 있습니다.[1]

상태가 없는 호출에서 상태가 있는 서비스로

전형적인 LLM 서빙은 다음 사항에 최적화되어 있습니다:[1]

• 하나의 요청 $\rightarrow$ 하나의 응답
• 요청당 최소한의 상태 (state)
• API 게이트웨이 뒤에서의 용이한 수평 확장 (horizontal scaling)

에이전트 실행은 세션 (sessions)과 작업 (tasks)을 기본 단위로 취급합니다:[1][2]

• 수많은 모델 호출 및 도구 사용 전반에 걸친 지속적인 세션 상태
• 몇 분 동안 실행될 수 있는 도구 호출 (tool invocations)
• 재시도, 실패 및 핸드오프 (handoffs) 상황에서도 유지되어야 하는 계획 (plans)

각 에이전트는 점차 자체적인 라이프사이클 (lifecycle)과 상태 저장소 (state store)를 가진 마이크로서비스 (microservice)와 유사해지고 있습니다.[1]

💡 에이전트 스택의 5가지 계층[1][4]

1. 컴퓨트 (Compute) – GPU/CPU 풀 (pools), 모델 게이트웨이 (model gateways), 지연 시간 인지 라우팅 (latency‑aware routing)
2. 오케스트레이션 (Orchestration) – 플래너 (planners), 라우터 (routers), 멀티 에이전트 조정 (multi‑agent coordination), 재시도 (retries)
3. 컨텍스트 (Context) – 벡터 저장소 (vector stores), RAG 파이프라인 (RAG pipelines), 메모리 (memory), 세션 상태 (session state)
4. 관측 가능성 (Observability) – 로그 (logs), 트레이스 (traces), 메트릭 (metrics), 단계별 텔레메트리 (step‑level telemetry), 리플레이 (replay)
5. 보안 및 정책 (Security & policy) – 인증/인가 (authN/Z), 도구 범위 (tool scopes), 코드형 정책 (policy‑as‑code), 승인 (approvals)

에이전트가 IaC (Infrastructure as Code)를 수정하거나, 리소스를 프로비저닝하거나, CI/CD를 트리거할 수 있게 되면 이 다섯 가지 요소가 모두 중요해집니다.[1][4]

📊 비용의 현실

규모가 커지면 세션, 도구 커넥터 (tool connectors), 워크스페이스 저장소, 관측 가능성, 리뷰 UI와 같은 플랫폼 비용이 토큰 소비 비용에 필적하거나 이를 초과할 수 있습니다.[1]

이를 무시하면 예상치 못한 청구서와 운영 환경에서의 관측 불가능한 "섀도 에이전트 (shadow agents)"가 발생하게 됩니다.

예시: 사양 기반 워크스페이스 (Spec‑driven workspaces)

벤더들은 이러한 계층들을 다음과 같은 사양 기반 (spec‑driven) 멀티 에이전트 워크스페이스로 패키징하고 있습니다:[1][2]

• 구조화된 "작업 사양 (task spec)" (예: 변경 요청) 수락
• 격리된 샌드박스/워크트리 (sandbox/worktree) 생성
• 공유 컨텍스트를 가진 여러 에이전트 오케스트레이션
• 영향력이 큰 작업은 인간의 승인을 거치도록 라우팅

💼 의사 아키텍처 (Pseudo‑architecture)

하단: 모델 + 도구 (models + tools)

중간: 에이전트 코디네이터 + 상태 저장소 (agent coordinators + state store)

상단: 정책 엔진 + 관측 가능성 + 인간의 승인 (policy engine + observability + human approvals)[1][5]

코드 스타일의 의사 코드 (pseudocode)로 표현하면:

def handle_task(task_spec):
    session_id = state_store.create_session(task_spec)
    plan = planner_agent.propose_plan(task_spec, session_id)
...

⚡ 소결론

에이전트가 실제 인프라를 다루기 전에 필요한 것은 단순한 모델 엔드포인트 (model endpoint)가 아니라, 상태 유지 오케스트레이션 (stateful orchestration), 풍부한 텔레메트리 (telemetry), 그리고 정책 기반의 도구 접근 권한 (policy‑mediated tool access)입니다.[1][4][5]

3. AI를 통한 인프라 오케스트레이션: CI/CD, 클라우드 및 컴플라이언스

이제 AI를 배포한다는 것은 단순히 모델 API를 호스팅하는 것이 아니라, 모델, 프롬프트 (prompts), RAG, 에이전트, 도구, 그리고 가드레일 (guardrails)을 기존의 운영 레일 (production rails)에 통합하는 것을 의미합니다.[4]

통합된 CI/CD 및 릴리스 오케스트레이션 (release orchestration)이 기초적인 요소가 되었습니다.[4]

[4]에서 인용된 최근의 DORA 스타일 연구 결과에 따르면, AI 지원 코딩 (AI-assisted coding)에도 불구하고 처리량 (throughput)은 감소하고 안정성은 악화되었습니다. 이는 코드의 양이 아니라 안전한 통합과 배포 (rollout)가 주요 병목 현상임을 시사합니다.[4]

에이전트를 마이크로서비스와 동일한 레일에 배치하기

현대의 CI/CD 플랫폼은 점점 더 다음과 같은 방식을 취하고 있습니다:[4]

• AI 워크플로 (RAG 설정, 에이전트 그래프, 도구 카탈로그)를 버전 관리되는 아티팩트 (artifacts)로 취급
• 자동화된 테스트, 드라이 런 (dry-runs), 정책 검사 (policy checks)를 통해 실행
• 점진적 배포 (progressive delivery) 및 SLO 기반 가드레일 (guards)로 배포 제어

💡 패턴: AI + CI/CD[4]

• CI
  • 도구에 대한 단위 테스트 (Unit tests)
  • API에 대한 계약 테스트 (Contract tests)
  • 프롬프트 및 정책에 대한 평가 스위트 (Eval suites)
• CD
  • 에이전트 설정에 대한 카나리 배포 (Canary releases)
  • 기능에 대한 피처 플래그 (Feature flags)
  • 지표 악화 시 즉각적인 롤백 (rollback)

ML 라이프사이클 전반의 워크플로 자동화

엔터프라이즈 AI 워크플로 자동화는 데이터, 학습, 배포, 거버넌스를 다음과 같은 연속적이고 감사 가능한 파이프라인으로 결합합니다:[3]

• 학습 클러스터 및 추론 노드 (inference nodes)를 필요에 따라 생성
• RAG 인덱스 및 임베딩 (embeddings) 갱신
• 사용하지 않는 리소스 및 오래된 모델을 자동으로 폐기

인프라, 데이터, 모델을 코드로서 취급하고 GitOps 조정 루프 (reconciliation loops)를 통해 실행함으로써, 팀은 자가 치유 (self-healing)가 가능하고 정책 중심적인 제어 권한을 얻게 됩니다.[3]

에이전트가 노드 풀 (node pool)을 확장하거나 GPU를 프로비저닝할 때, 조정 계층 (reconciliation layer)은 원하는 상태 (desired state)가 규정을 준수하고 비용 범위 내에 있도록 유지합니다.

⚠️ 정책 코드화 (policy-as-code)를 통한 가드레일

정책 엔진 (예: OPA, 클라우드 설정 도구)은 다음과 같은 사항을 강제할 수 있습니다:[3][5]

• "비운영 환경(non-prod)에서 A100 GPU 사용 금지"
• "학습 데이터는 저장 시 암호화되어야 함"
• "RAG 인덱스는 지역 승인 데이터셋으로 제한됨"

이러한 제약 조건은 인간과 AI가 생성한 Terraform 모두에 동일하게 적용되어, 에이전트 기반 자동화가 설정된 비용, 보안 및 컴플라이언스 범위 내에서 유지되도록 합니다.[3][5]

💼 구체적인 사례

• 30명 규모의 한 핀테크 기업은 AI ops 봇을 Terraform에 연결했습니다.
• 해당 봇은 GPU 노드 수를 3배로 늘려 비용을 급증시킴으로써 SLO (Service Level Objective) 위반을 "해결"했습니다.
• 이제 이들은 모든 GPU급 작업에 대해 정책 검사(policy checks)와 인간의 승인을 요구합니다.

4. AI 제어 시스템을 위한 신뢰성, 안전성 및 엔지니어링 패턴

AI가 운영의 중추(backbone)가 됨에 따라, 장애, 잘못된 데이터, 적대적 프롬프트(adversarial prompts)와 같은 스트레스 상황에서의 회복탄력성(resilience)은 특히 규제 대상이거나 안전이 중요한(safety-critical) 맥락에서 가치를 직접적으로 결정합니다. [5]

가드레일(guardrails) 없는 빠른 반복(iteration)은 운영 리스크로 변질됩니다. [5]

에이전트 기반 워크플로(agentic workflows)의 새로운 실패 모드

장시간 실행되며 도구를 사용하는 에이전트는 다음과 같은 실패 패턴을 유발합니다: [1][2]

• 계획 정체 (Stuck plans) – 충족할 수 없는 목표에 대해 루프(looping)를 도는 현상
• 연쇄적 도구 오류 (Cascading tool errors) – 하나의 잘못된 API 호출이 후속 단계들을 오염시키는 현상
• 목표 드리프트 (Objective drift) – 비즈니스 또는 컴플라이언스와 일치하지 않는 대리 지표(proxy metrics)를 최적화하는 현상

완화(Mitigation)를 위해서는 명시적인 플래너(planners), 실행 모니터(execution monitors), 그리고 명확한 에스컬레이션 임계값(escalation thresholds)을 가진 제한된 자율성(bounded autonomy)이 필요합니다. [1][2]

💡 일급 시민 기능(first-class feature)으로서의 Human-in-the-loop

정책 업데이트, 대규모 리소스 변경, 프로덕션 라우팅과 같이 영향력이 큰 인프라 작업에는 다음 사항이 포함되어야 합니다: [1][3]

• 구조화된 승인 (개인 또는 위원회)
• 파괴적인 작업에 대한 다요소 확인 (multi-factor confirmation)
• 감사 가능성(auditability)을 위한 각 변경 사항에 대한 근거(justification) 첨부

작업의 관찰 가능성(Observability) 및 설명 가능성(explainability)

심층적인 관찰 가능성은 다음을 반드시 캡처해야 합니다: [1][4]

• 모든 모델 호출 및 도구 호출(tool invocation)
• 적절한 경우 중간 계획/사고 과정(intermediate plans/thoughts)
• 작업(예: "노드 풀 X 확장")에서 프롬프트, 정책 및 컨텍스트로 이어지는 연결 고리

이러한 텔레메트리(telemetry)는 사고 대응, 근본 원인 분석(root cause analysis) 및 규제 준수를 위한 설명 가능성을 가능하게 합니다. [4][5]

📊 책임 있는 AI 집행 지점으로서의 컨트롤 플레인(Control planes)

책임 있는 AI(Responsible AI)—책임성(accountability), 리스크 계층(risk tiers), 규제 정렬(regulatory alignment)—은 인프라에 대한 AI 작업을 중재하는 컨트롤 플레인에 반드시 인코딩되어야 합니다. [5] 다음을 고려하십시오:

• 각 에이전트(agent)에 대한 명확한 소유자 및 온콜(on-call) 순번 지정
• 위험 분류 (자문형 vs. 변경 수행형 vs. 완전 자율형)
• 에이전트 동작을 위한 킬 스위치(Kill-switches) 및 서킷 브레이커(circuit breakers)

결론

AI가 보조 도구에서 클라우드, 장치 및 실제 운영을 위한 제어 구조(control fabric)로 전환됨에 따라, 기업은 기존의 MLOps를 넘어 에이전트 기반 인프라(agentic infrastructure), CI/CD 통합, 코드로서의 정책(policy-as-code), 그리고 강력한 관측성(observability)으로 영역을 확장해야 합니다. [1][3][4][5]

상태 유지 오케스트레이션(stateful orchestration), 인간 참여형(human-in-the-loop) 승인, 그리고 산업 등급의 신뢰성 패턴을 갖춤으로써, 조직은 안정성, 규정 준수 및 비용 제어를 유지하면서 AI가 안전하게 "하드웨어(touch the metal)"를 제어할 수 있도록 할 수 있습니다.

CoreProse 소개: 검증된 인용을 포함한 연구 중심의 AI 콘텐츠 생성. 환각(hallucination) 제로.

🔗 CoreProse 체험하기 | 📚 더 많은 KB Incidents 보기