💡 원문은 devtocash.com에 게시되었습니다 — 이 가이드의 최신 정보가 유지되는 곳입니다. 저는 그곳에서 매주 실무 중심의 DevOps/SRE 심층 분석 글을 작성합니다.

FinOps 에이전트가 실제로 해야 하는 일

유용한 FinOps 에이전트는 단순히 "클라우드 청구서를 관리"하는 것이 아닙니다. 에이전트는 하나의 좁고 검증 가능한 작업, 즉 비용 및 사용량 데이터를 읽고, 돈을 낭비하고 있는 소수의 워크로드(workloads)를 찾아내며, 구체적이고 검토 가능한 라이트사이징(rightsizing, 적정 규모 산정) 변경 사항을 생성하는 일을 수행합니다. 이때 변경 사항은 실시간 kubectl apply가 아니라 풀 리퀘스트(pull request) 형태여야 합니다. 지능은 낭비 요소를 순위 매기고 수정 사항을 정당화하는 데 있으며, 실제 _실행(action)_은 인간의 승인 단계와 기존의 GitOps 흐름 뒤에 머물러야 합니다.

이러한 프레임워크가 설계의 핵심입니다. 비용 데이터는 읽기 전용이며 쿼리 비용이 저렴하기 때문에 에이전트의 입력값으로 거의 이상적입니다. 과다 할당된 resources.requests는 판단의 영역이 아닌 객관적인 사실이기 때문입니다. 위험 요소는 데이터를 읽는 과정에 있는 것이 아니라, 가끔 숫자를 환각(hallucinate)하는 모델이 프로덕션 환경에 직접 쓰기 작업을 수행하도록 허용하는 데 있습니다. 따라서 우리는 분석에는 강력하지만, 변조(mutation)에는 의도적으로 무력한 에이전트를 구축합니다. 이는 자율형 에이전트 플레이북(autonomous-agent playbook)을 엄격한 FinOps 비용 규율(FinOps cost discipline)과 결합하는 방식입니다.

에이전트가 갖는 두 가지 도구 — 그리고 갖지 못하는 한 가지

에이전트는 그 도구에 의해 정의됩니다. 이 에이전트에게는 정확히 두 개의 읽기 도구(read tools)만 부여하고, 쓰기 도구(write tools)는 전혀 부여하지 마십시오.

TOOLS = [
    {
        "name": "get_cost_allocation",
...

get_cost_allocation은 OpenCost(또는 Kubecost)를 얇게 감싼 래퍼(wrapper)입니다. 이는 아마도 Kubernetes 비용 가시성(Kubernetes cost visibility)을 위해 이미 실행 중일 오픈 소스 할당 API일 것입니다. 이 함수는 가공되지 않은 메트릭 덤프가 아니라, 구조화되고 미리 처리된 행(rows)을 반환합니다.

import requests

def get_cost_allocation(window="14d", namespace=None):
...

[:25]와 정렬(sort)을 사용하는 목적은 컨텍스트 엔지니어링 (context engineering) 때문입니다. 모델은 300개의 가공되지 않은 행보다 순위가 매겨지고 라벨이 붙은 25개의 행을 바탕으로 훨씬 더 잘 추론합니다. 모델에게는 patch_deployment나 kubectl_apply 도구가 주어지지 않습니다. 모델의 출력에서 실제 라이브 클러스터로 이어지는 코드 경로가 존재하지 않습니다. 이 단 하나의 생략만으로도 "에이전트가 운영 환경의 스케일을 0으로 줄여버리는" 부류의 실패를 완전히 제거할 수 있습니다.

시스템 프롬프트(System Prompt)에 FinOps 정책을 인코딩하기

프롬프트는 일반적인 모델을 특정 스타일을 가진 FinOps 검토자로 변환하는 곳입니다. 안전 마진(safety margin)에 대해 명시적으로 작성하십시오. 이것이 바로 여러분이 병합(merge)할 수 있는 권장 사항과 새벽 3시에 호출(page)을 받게 만드는 권장 사항 사이의 차이를 만듭니다.

당신은 Kubernetes 플랫폼을 위한 FinOps 분석가입니다. 당신의 임무는
과다 프로비저닝된(over-provisioned) 워크로드를 찾아내고
더 안전한 리소스 요청(resource requests)을 제안하는 것입니다.

...

두 줄의 규칙이 핵심적인 역할을 수행합니다. '25%의 여유 공간을 둔 P95' 규칙은 에이전트가 워크로드를 최적화하다가 CrashLoopBackOff 또는 OOMKill 상태로 몰아넣는 것을 방지합니다. "명세(spec)가 없으면 권장 사항도 없다"는 규칙은 단언(assertion)하기 전에 도구 사용을 강제합니다. 즉, 에이전트는 실제로 검사하지 않은 워크로드에 대해 변경을 권장할 수 없으며, 이는 환각(hallucination)된 리소스 수치가 발생하는 지점을 차단합니다.

출력은 액션(Action)이 아니라 디프(Diff)입니다

에이전트의 결론을 기계가 소비할 수 있도록 구조화된 출력(structured output)을 강제하십시오. 각 권장 사항은 여러분의 파이프라인이 PR(Pull Request)로 렌더링할 수 있는 패치(patch)가 됩니다.

{
  "recommendations": [
    {
...

당신의 하네스(harness)는 이를 values 파일에 대한 GitOps 커밋으로 변환하고, PR(Pull Request)을 생성한 뒤 멈춥니다. 사람은 다른 인프라 변경 사항을 검토하는 것과 동일한 방식으로 차이점(diff)을 검토하며, Argo CD는 머지(merge) 시 이를 적용합니다. 에이전트는 쓰기 권한이 있는 kubeconfig를 결코 보유하지 않았습니다. 이는 비용에 적용된 harness-as-infrastructure 원칙입니다: 최소 권한(least privilege), 작은 폭발 반경(small blast radius), 그리고 Git 히스토리에서 모든 변경 사항을 감사(auditable)할 수 있는 구조입니다.

def to_gitops_pr(rec):
    path = f"apps/{rec['workload'].replace('/', '/values-')}.yaml"
    patch = {
...

검토자의 육안보다 더 엄격한 강제성을 원한다면, 요청(request) 값이 하한선 미만으로 떨어지는 모든 매니페스트(manifest)를 차단하는 Kyverno 정책 (Kyverno policy)을 추가하십시오. 이렇게 하면 단순히 승인만 된 잘못된 PR이라도 중요한 서비스의 자원을 안전한 최소치 미만으로 줄일 수 없습니다.

가드레일을 보호하기: 여전히 발생하는 문제들

이처럼 제약이 많은 에이전트는 재앙으로부터는 안전하지만, 여전히 당신의 시간을 낭비하는 방식으로 틀릴 수 있습니다. 다음 사항들에 대비하여 설계하십시오:

• 짧은 윈도우(Short windows)는 거짓말을 합니다. 조용한 기간 동안의 7일 윈도우는 모든 것이 과다 프로비저닝(over-provisioned)된 것처럼 보이게 만듭니다. 기본값을 14~30일로 설정하고, N일 미만의 데이터로는 워크로드의 크기 조정(rightsize)을 거부하십시오. 주간 및 계절적 피크(peak) 시점은 바로 요청(requests) 값을 더 타이트하게 조절해서는 안 되는 시점입니다.
• P95는 꼬리(tail)를 숨깁니다. 배치 작업(Batch jobs), 크론(cron) 기반의 스파이크, 콜드 스타트(cold-start) 버스트는 P99+ 영역에 존재합니다. "P95 × 1.25"를 제안하는 에이전트는 가끔 실제 피크를 잘라낼(clip) 수 있습니다. 이것이 바로 필수적인 risk 필드와 인간의 검토(human review)가 필요한 이유입니다. 이들을 절대 제거하지 마십시오.
• 효율성(Efficiency) ≠ 고가용성(HA) 워크로드의 낭비. 장애 조치(failover)를 위해 여유 공간(headroom)을 확보하도록 의도적으로 과다 프로비저닝된 서비스는 비용 데이터상으로는 낭비와 동일하게 보입니다. 프롬프트 내의 tier=critical 제외 설정은 선택 사항이 아닙니다. 에이전트가 의도를 파악할 수 있도록 워크로드에 라벨을 지정하십시오.
• 절감액은 추정치이지, 인보이스(invoice)가 아닙니다. 에이전트가 제시하는 "월 $84"는 모델링된 수치입니다. 머지(merge) 후 실제 클라우드 청구서에서 발생하는 실현된(realized) 절감액을 추적하십시오. 예측치와 실현치 사이의 격차는 에이전트가 제대로 교정(calibrated)되었는지를 판단할 수 있는 가장 좋은 평가 신호(eval signal)입니다.

신뢰하기 전에 증명하십시오

이것을 바로 운영 환경(production)에 적용하고 PR(Pull Request)을 읽지 마십시오. 먼저 평가하십시오: 정답을 이미 알고 있는 고정된 비용 스냅샷 세트를 재생(replay)하고, 다음 두 가지를 점수화하십시오. 정밀도(Precision) — 에이전트가 플래그를 지정한 워크로드 중 실제로 낭비였던 비율(중요 서비스를 축소시키는 오탐(false positive)은 절감 기회를 놓치는 것보다 훨씬 더 나쁩니다). 안전성(Safety) — 관측된 피크보다 낮은 요청(requests) 값을 제안하거나, 제외된 네임스페이스(namespace)를 건드린 적이 있는가? 평가 세트에서 단 한 번의 안전 위반이라도 발생했다면 프롬프트나 도구 필터(tool filter)가 고장 난 것이며, PR을 생성하기 전에 이를 먼저 수정해야 합니다.

실행 중인 에이전트를 일반적인 파이프라인과 동일한 방식으로 계측(Instrument)하십시오. 각 분석 과정을 OpenTelemetry로 추적(trace)하여, 에이전트가 어떤 도구 호출(tool calls)을 수행했는지, 어떤 권장 사항이 병합(merge)되었는지, 그리고 예측된 절감액이 다음 달의 실제 청구서와 어떻게 비교되는지 확인할 수 있어야 합니다.

핵심 요약 (Takeaway)

비용 관리를 위한 에이전트의 승리 공식은 자율성(autonomy)이 아닙니다. 기존의 GitOps 및 리뷰 흐름에 연결된 정교한 읽기 전용 분석가(read-only analyst)를 구축하는 것입니다. 에이전트에게 두 개의 읽기 도구(read tools)만 부여하고 쓰기 도구(write tools)는 전혀 주지 마십시오. 프롬프트에 FinOps 정책(P95 + 여유분(headroom), 엄격한 제외 항목)을 인코딩하고, 출력 결과가 검토 가능한 diff가 되도록 하며, 모든 변경 사항은 사람과 Kyverno 가드레일(floor)을 거치도록 제한하십시오. 이렇게 하면 200개의 워크로드(workload)가 있는 클러스터에서 실제 낭비 요소를 몇 초 만에 찾아내는 어시스턴트를 얻으면서도, 가장 중요한 한 가지, 즉 사람이 승인하지 않은 것은 운영 환경(production)에 절대 도달하지 않도록 유지할 수 있습니다. 처음에는 보고 전용 모드(report-only mode)로 시작하여, 실제 실현된 절감액을 에이전트의 추정치와 비교 측정하고, 수치가 증명될 때만 제어 범위를 점진적으로 넓혀가십시오.

📌 이 가이드의 최신 버전 — 그리고 DevOps, SRE, Kubernetes, 관측성(observability) 및 클라우드 비용 가이드 전체 라이브러리 — 를 devtocash.com에서 확인하세요.