SRE, DevOps, Kubernetes, Terraform, GitOps, 파이프라인(pipelines) 및 관찰성(observability) 분야에서 수년간 일하면서, 저는 스스로에게 불편한 질문을 던지기 시작했습니다:

우리는 정말로 AI를 통해 엔지니어링을 변화시키고 있는 걸까요, 아니면 그저 새로운 기술을 사용하여 예전과 똑같은 산출물들을 더 빠르게 만들어내고 있는 것뿐일까요?

오늘날 우리는 다음과 같은 것들을 만들기 위해 인공지능(AI)을 사용합니다:

• 배포 파이프라인 (deploy pipelines);
• Terraform 모듈;
• Helm Charts;
• Kubernetes 매니페스트 (manifestos);
• 대시보드 (dashboards);
• 알림 (alertas);
• 쿼리 (queries);
• 테스트 (testes);
• 런북 (runbooks);
• 풀 리퀘스트 (pull requests);
• 문서화 (documentação).

이것은 생산성을 높입니다. 의심의 여지가 없습니다.

하지만 이는 또한 **AI에 의한 오버엔지니어링 (overengineering assistido por IA)**의 새로운 형태를 만들어내고 있을지도 모릅니다.

운영 복잡성을 줄이는 대신, 우리는 인간이 시스템을 운영하기 위해 원래 만들어졌던 YAML, 스크립트, 템플릿, 대시보드 및 레이어들을 더 많이 생성하기 위해 AI를 사용하고 있습니다.

우리는 AI에게 우리처럼 일하는 법을 가르치고 있습니다.

어쩌면 이것이 실수일지도 모릅니다.

우리는 잘못된 프로세스를 자동화하고 있습니다

애플리케이션의 새 버전을 프로덕션에 배포해야 한다고 가정해 봅시다.

현재 모델에서는 다음과 같은 구조를 가질 수 있습니다:

코드 (Código)
  ↓
풀 리퀘스트 (Pull request)
...

이 흐름이 반드시 나쁜 것은 아닙니다.

이 흐름이 존재하는 이유는 인간이 복잡한 시스템을 안전하게 운영하기 위해 예측 가능한 프로세스, 시각적 인터페이스, 명시적인 단계 및 감사 추적(trilhas de auditoria)이 필요하기 때문입니다.

문제는 우리가 이 프로세스에 AI 에이전트를 투입하고 다음과 같이 요청할 때 발생합니다:

빌드를 수행하고, 테스트를 실행하며, 이미지를 게시하고, Helm Chart를 업데이트하며, ArgoCD를 동기화하는 GitHub Actions 파이프라인을 생성해 줘.

AI는 이 작업을 완벽하게 수행할 수 있습니다.

하지만 AI는 여전히 인간을 위해 만들어진 동일한 사고 모델에 갇혀 있습니다.

어쩌면 요청은 다음과 같아야 했을지도 모릅니다:

결제 서비스의 버전 2.8을 가동 중단 없이 프로덕션 (production)에 배포하세요. 점진적 배포 (rollout)를 수행하고, 에러율이 1%를 초과하면 중단하며, 지연 시간 (latency) 또는 전환율 (conversion)이 저하될 경우 롤백 (rollback)을 실행하세요.

차이점을 주목하세요.

첫 번째 요청에서 우리는 **아티팩트 (artifact)**를 요청하고 있습니다.

두 번째 요청에서 우리는 **결과 (result)**를 위임하고 있습니다.

프로세스 중심 자동화에서 의도 중심 운영으로

전통적인 모델은 다음과 같이 요약할 수 있습니다:

인간이 단계를 정의함
        ↓
파이프라인 (Pipeline)이 단계를 실행함
...

에이전트 중심 (agent-oriented) 모델에서는 다음과 같습니다:

인간이 목표, 제한 사항 및 정책을 정의함
        ↓
에이전트가 컨텍스트 (context)와 리스크를 분석함
...

주요 인터페이스는 더 이상 파이프라인이 아닙니다.

인터페이스는 **의도 (intent)**가 됩니다.

다음과 유사한 형태입니다:

yintent:
  goal: deploy
  service: payments-api
...

인간은 모든 명령어를 기술할 필요가 없습니다.

대신 다음을 정의합니다:

• 무엇이 일어나야 하는지;
• 무엇이 성공을 의미하는지;
• 어떤 리스크가 허용 가능한지;
• 어떤 행동이 금지되는지;
• 에이전트가 언제 멈춰야 하는지;
• 언제 사람이 승인해야 하는지.

에이전트는 이 안전한 범위 내에서 목표를 달성하는 방법을 결정합니다.

AI는 우리와 동일한 인터페이스를 사용할 필요가 없습니다

파이프라인 (Pipelines), 대시보드 (dashboards), 티켓 (tickets), 런북 (runbooks), 그리고 YAML 파일들은 인간을 위해 구축된 추상화 (abstractions)입니다.

에이전트는 다음과 같은 요소들에 직접 접근할 수 있습니다:

• 클라우드 제공업체 (cloud providers)의 API;
• Kubernetes API;
• Git 리포지토리 (repositories);
• 관측성 (observability) 시스템;
• 데이터베이스 (databases);
• 피처 플래그 (feature flags);
• 서비스 카탈로그 (service catalogs);
• 정책 엔진 (policy engines);
• 보안 스캐너 (security scanners);
• 인시던트 (incident) 시스템;
• 비용 관리 도구.

에이전트가 원하는 상태에 도달하기 위해 필요한 역량을 직접 사용할 수 있음에도 불구하고, 다음과 같은 과정을 강요하는 것은 의미가 없습니다:

1. 파일을 생성하고;
2. 풀 리퀘스트 (pull request)를 열고;
3. 파이프라인을 기다리고;
4. 인터페이스를 해석하고;
5. 대시보드를 수동으로 조회하는 것.

이것이 제어, 검토 또는 감사 (audit)를 무시한다는 의미는 아닙니다.

이는 오늘날 우리가 동일한 것으로 취급하는 두 가지를 분리한다는 것을 의미합니다:

운영 제어 (Operational control)는 인간의 절차 (Human procedure)와 같은 것이 아닙니다.

우리는 에이전트에게 우리의 움직임을 정확히 반복하도록 강요하지 않으면서도 제어를 유지할 수 있습니다.

이것이 파이프라인의 종말을 의미하나요?

아니요.

이것은 중요한 구분입니다.

에이전트에게 사람이 수동으로 생성하고 유지 관리하는 파이프라인가 필요하지 않을 수도 있지만, 여전히 다음과 같은 것들은 필요합니다:

• 상태 관리 (State management);
• 멱등성 (Idempotency);
• 재시도 (Retries);
• 동시성 제어 (Concurrency control);
• 관심사 분리 (Separation of responsibilities);
• 단기 자격 증명 (Short-lived credentials);
• 최소 권한 범위 (Minimum scope of access);
• 감사 추적 (Audit trail);
• 롤백 (Rollback);
• 비용 제한 (Cost limits);
• 보안 정책 (Security policies);
• 실행 증거 (Execution evidence).

에이전트는 또한 임시 워크플로 (Workflow), 상태 머신 (State machine) 또는 해당 변경 사항을 위한 특정 DAG (Directed Acyclic Graph)를 생성할 수 있습니다.

차이점은 이 흐름이 모든 시나리오에 대해 사전에 프로그래밍되는 대신, 의도(Intention)로부터 동적으로 컴파일 (Compiled dynamically) 된다는 점입니다.

파이프라인은 계속 존재할 수 있습니다.

하지만 그것이 제품(Product)이 되어서는 안 됩니다.

그것은 실행을 위한 내부적인 세부 사항이 됩니다.

Terraform, Kubernetes, GitOps 또한 사라질 필요는 없습니다

우리가 이미 사용하고 있는 도구들에게도 마찬가지입니다.

Terraform은 인프라의 선언적이고 감사 가능한 표현으로 계속 남을 수 있습니다.

Git은 이력과 증거의 원천으로 계속 남을 수 있습니다.

ArgoCD는 원하는 상태를 계속 조정 (Reconciling)할 수 있습니다.

Prometheus는 메트릭 (Metrics)을 계속 수집할 수 있습니다.

Kubernetes는 애플리케이션을 계속 오케스트레이션 (Orchestrating)할 수 있습니다.

문제는 이러한 기술들이 아닙니다.

문제는 이러한 도구들의 아티팩트 (Artifact) 생성을 작업의 최종 결과물로 취급하는 것입니다.

기업은 Terraform 모듈을 원하는 것이 아닙니다.

기업은 사용 가능하고, 안전하며, 재현 가능하고, 예산 범위 내에 있는 인프라를 원합니다.

기업은 파이프라인을 원하는 것이 아닙니다.

기업은 안전하게 전달되는 소프트웨어를 원합니다.

기업은 대시보드를 원하는 것이 아닙니다.

기업은 비즈니스 목표나 SLO (Service Level Objective)가 위험에 처했을 때 이를 빠르게 알고 싶어 합니다.

아티팩트 (Artifacts)는 여전히 유용하지만, 목표에서 메커니즘 (mechanism)으로 격하됩니다.

스크립트보다 스킬 (Skills)이 더 중요합니다

이 모델에서 스킬 (skill)은 단순히 셸 명령 (shell commands)을 포함하는 프롬프트 (prompt)여서는 안 됩니다.

그것은 완전한 운영 능력 (operational capability)을 나타내야 합니다.

예를 들어, deploy-production 스킬은 다음과 같이 선언될 수 있습니다:

skill:
  name: deploy-production

...

에이전트 (Agent)는 목표를 전달받고 문맥 (context)에 따라 스킬을 조합합니다.

리스크가 낮은 내부 애플리케이션의 경우, 단순한 롤아웃 (rollout)을 선택할 수 있습니다.

결제 서비스의 경우, 카나리 (canary), 합성 테스트 (synthetic tests), 메트릭 분석 (metrics analysis) 및 인간의 승인을 사용할 수 있습니다.

심각한 보안 패치의 경우, 범위가 제한되고 강화된 모니터링이 포함된 긴급 흐름을 선택할 수 있습니다.

원하는 결과는 같을 수 있습니다.

하지만 경로가 반드시 같을 필요는 없습니다.

파이프라인이 초록색이 된다고 해서 배포가 끝나는 것은 아닙니다

이것이 현재 모델의 가장 큰 문제 중 하나입니다.

많은 자동화 시스템은 모든 작업 (jobs)이 성공적으로 실행되면 작업이 종료된 것으로 간주합니다.

하지만 파이프라인이 초록색 (green)이라고 해서 변경 사항이 제대로 작동했다는 의미는 아닙니다.

배포가 완료되었음에도 불구하고 다음과 같은 상황이 발생할 수 있습니다:

• 지연 시간 (latency) 증가
• 조용한 오류 (silent errors) 발생
• 통합 (integration) 파괴
• 사용자의 일부에게만 영향
• 비즈니스 여정 (business journey) 저하
• 비용 증가
• 몇 분 후 인시던트 (incident) 발생

에이전트는 폐쇄 루프 (closed-loop) 방식으로 작동해야 합니다:

관찰 (Observe)
   ↓
해석 (Interpret)
...

에이전트는 단순히 다음과 같이 보고해서는 안 됩니다:

배포가 성공적으로 완료되었습니다.

대신 다음과 유사한 내용을 보고해야 합니다:

버전 2.8.0이 100% 인스턴스에 배포되었습니다. 에러율(error rate)은 0.28%를 유지했고, p95 지연 시간(latency)은 퇴보(regression)를 보이지 않았으며, 합성 테스트(synthetic tests)를 통과했고, 20분간의 관찰 기간 동안 전환율(conversion)은 안정적으로 유지되었습니다.

이것은 성공의 정의를 완전히 바꿉니다.

성공은 더 이상 시퀀스(sequence)의 실행이 아닙니다.

목표가 달성되었음을 확인하는 것이 성공이 됩니다.

에이전트 지향 플랫폼(agent-oriented platform)은 어떤 모습일까요?

진정으로 에이전트 중심적인(agentic) 플랫폼은 몇 가지 계층으로 나뉠 수 있습니다:

1. 의도 계층 (Intention Layer)

목표, 제한 사항 및 성공 기준을 수신합니다.

예시:

가용성(availability) 및 지연 시간(latency) SLO를 해치지 않으면서 이 클러스터의 비용을 15% 절감하십시오.

2. 컨텍스트 카탈로그 (Context Catalog)

에이전트에게 다음과 같은 정보를 제공합니다:

• 서비스;
• 의존성 (dependencies);
• 담당자;
• 중요도 (criticality);
• 민감 데이터;
• 비용;
• 이전 변경 사항;
• 인시던트 (incidents);
• SLOs;
• 아키텍처 (architecture).

신뢰할 수 있는 컨텍스트가 없다면 자율성(autonomy)은 즉흥적인 임기응변으로 변질됩니다.

3. 플래너 (Planner)

목표, 리스크, 컨텍스트 및 정책을 기반으로 계획을 수립합니다.

이 계획은 항상 동일할 필요는 없습니다.

다음 요소에 따라 변경될 수 있습니다:

• 환경;
• 중요도 (criticality);
• 시간대;
• 예상 영향 (estimated impact);
• 현재 시스템 상태 (system health);
• 애플리케이션 이력.

4. 스킬 카탈로그 (Skills Catalog)

다음과 같은 역량을 제공합니다:

• 애플리케이션 배포;
• 인프라 생성;
• 용량 확장 (scale up);
• 비용 절감;
• 인증서 갱신;
• 인시던트 조사;
• 백업 복구;
• 취약점 수정;
• 롤백 (rollback) 실행.

5. 정책 엔진 (Policy Engine)

에이전트가 무엇을 할 수 있는지, 어떤 조건에서, 어떤 수준의 승인을 거쳐야 하는지를 정의합니다.

이것은 아마도 가장 중요한 구성 요소 중 하나일 것입니다.

에이전트는 경로를 선택할 수 있습니다.

기업은 계속해서 경계(limits)를 정의합니다.

6. 실행 계층 (Execution Layer)

사용 가능한 메커니즘을 활용합니다:

• APIs;
• 컨트롤러 (controllers);
• GitOps;
• 파이프라인 (pipelines);
• 클라우드 제공업체 (cloud providers);
• Kubernetes;
• 데이터베이스 (bancos);
• 내부 도구 (internal tools).

7. 검증 및 증거 (Verification and evidence)

결과를 확인하고, 영향을 추적하며, 다음 사항을 기록합니다:

• 계획 (plan);
• 결정 (decisions);
• 조치 (actions);
• 승인 (approvals);
• 지표 (metrics);
• 최종 상태 (final state);
• 예외 사항 (exceptions).

이 아키텍처는 일종의 **엔지니어링 에이전트를 위한 운영체제 (operating system for engineering agents)**가 될 것입니다.

진화는 아마도 단계별로 일어날 것입니다

기업이 AI 모델에게 프로덕션에 대한 무제한적인 접근 권한을 단순히 넘겨줄 것이라고는 믿지 않습니다.

진화는 점진적으로 일어나는 경향이 있습니다.

1단계 — 아티팩트 생성기로서의 AI

AI는 코드, Terraform, 파이프라인 (pipelines), 매니페스트 (manifestos), 대시보드 (dashboards)를 작성합니다.

현재 대부분의 기업이 위치한 단계입니다.

2단계 — 운영 코파일럿 (copilot)으로서의 AI

AI는 장애를 분석하고, 변경 사항을 제안하며, 풀 리퀘스트 (pull requests)를 준비하고, 실행을 추적합니다.

인간이 여전히 프로세스를 조정합니다.

3단계 — 운영자로서의 에이전트

에이전트는 기존 워크플로 (workflows)를 실행하고, 파이프라인 (pipelines)을 트리거하며, 결과를 해석하고, 승인을 요청합니다.

4단계 — 오케스트레이터 (orchestrator)로서의 에이전트

에이전트는 목표를 달성하는 데 필요한 계획을 동적으로 구성합니다.

컨텍스트 (context)를 기반으로 도구와 전략을 선택합니다.

5단계 — 경계 내에서의 자율 운영

에이전트는 운영 또는 비즈니스 목표를 수신하며, 사전에 정의된 위험 구역 내에서 시스템을 수정, 배포, 관찰 및 수정할 수 있는 자율성을 가집니다.

인간은 주로 다음 역할을 수행합니다:

• 예외 사항 처리;
• 영향력이 큰 결정;
• 정책 수립;
• 에이전트 평가;
• 기술 (skills)의 진화.

SRE, DevOps 및 플랫폼 엔지니어링 (Platform Engineering)의 새로운 역할

이 모델은 엔지니어의 업무를 없애지 않습니다.

우리가 일하는 수준을 변화시킵니다.

각 단계를 직접 작성하는 대신, 우리는 다음과 같은 것을 정의하게 됩니다: