사람을 위한 CI 파이프라인 구축을 멈추세요. 당신의 AI 에이전트에게는 하네스(Harness)가 필요합니다.

요약(TL;DR): 당신의 CI 파이프라인은 GitHub에서 빨간색 텍스트를 읽는 사람을 위해 설계되었습니다. AI 에이전트에게는 검증 하네스(Verification harness)가 필요합니다: 결정론적 인프라(Deterministic infra), 일시적 프리뷰 환경(Ephemeral preview environments), OPA 폭발 반경 제한(OPA blast-radius limits), 재생 트래픽(Replay traffic), 그리고 기계가 읽을 수 있는 판결(Machine-readable verdict)이 그것입니다. 여기 제가 코드로 구현하여 배포한 사례가 있습니다.

몇 주 전, 저는 실제 플랫폼 팀의 저장소(Repo)에 코딩 에이전트(Coding agent)를 풀어놓았습니다. Terraform, EKS, 그리고 약 40개의 마이크로서비스(Microservices)가 있는 환경이었습니다. 에이전트는 훌륭했습니다. 깔끔한 PR(Pull Request)을 생성했고, 변경 사항(Diffs)도 괜찮아 보였으며, 추가한 테스트도 합리적이었습니다. 주말이 지날 무렵, 에이전트는 6개의 PR을 머지(Merge)했지만, 우리는 그중 4개를 롤백(Rollback)해야 했습니다.

문제는 모델이 아니었습니다. 문제는 모델 주변의 모든 것이 '사람이 잘못된 것을 잡아낼 것'이라고 가정했다는 점입니다. CI 게이트(CI gates)는 Grafana 패널을 뚫어지게 쳐다보고, 지난 화요일의 장애를 기억하며, 불안함을 느낄 수 있는 사람을 위해 작성되었습니다. 에이전트에게는 그런 경험적 교훈(Scar tissue)이 없습니다. r/devops의 누군가가 지난 3월에 완벽하게 설명했습니다: "LLM은 폭발 반경(Blast radius)을 이해하지 못한 채 즉각적인 오류를 해결하는 데 최적화되어 있습니다. 사람이라면 첫 번째 네트워킹 변경 사항이 잘못되었을 때 멈췄을 것입니다. 에이전트에게는 그런 본능이 없습니다."

해결책은 더 똑똑한 모델이 아닙니다. 그것은 사람들이 **에이전트 하네스(Agent harness)**라고 부르기 시작한 것입니다. 즉, 모델을 감싸는 런타임 계층(Runtime layer)으로서, 에이전트가 활동할 수 있는 결정론적 인프라(Deterministic infra)를 제공하고, 에이전트가 망가뜨릴 수 있는 범위에 엄격한 제한을 두며, 변경 사항이 성공했는지 알려주는 구조화된 신호(Structured signal)를 전달하는 것입니다. 이 용어 자체는 최근 업계 보고서에 따르면 2026년 초에야 주류 용어로 등장했으며, 제가 대화하는 대부분의 팀은 아직 이를 구축하지 못했습니다.

제가 결국 출시한 하네스(Harness)는 다음과 같습니다. AWS 기준으로 에이전트 슬롯당 월 약 180달러의 비용이 들고, 이미 Terraform과 GitOps 컨트롤러를 갖추고 있다면 연결하는 데 약 하루 정도가 소요됩니다. 이 시스템을 도입한 후 지난 17일 동안 잘못된 병합(bad-merge)으로 인한 롤백(rollback) 횟수가 주 4회에서 0회로 줄었습니다.

매번 문제를 일으키는 다섯 가지 실패 모드

항상 팀들을 괴롭히는 다섯 가지 요소는 동일합니다. 개별적으로 보면 당연해 보이지만, 이들이 결합되면 에이전트가 무능해 보이게 만듭니다.

불안정한 프리뷰 환경 (Flaky preview environments). 동일한 PR(Pull Request)임에도 두 번의 실행 결과가 다릅니다. 에이전트의 마지막 변경 사항이 "성공"했던 이유는 우연히 Redis가 먼저 실행되었기 때문입니다. 다음 실행에서는 그렇지 않습니다.
롤백 신호 부재 (No rollback signal). 에이전트가 병합을 수행합니다. 운영 환경의 p99 지연 시간이 180ms에서 410ms로 조용히 드리프트(drift)합니다. 에이전트가 읽을 수 있는 방식으로 적절한 지표를 감시하는 것이 없기 때문에 아무런 알람도 울리지 않습니다.
비결정론적 Terraform (Non-deterministic Terraform). Plan 단계에서는 깨끗해 보였습니다. 하지만 두 번째 실행에서 데이터 소스(data source)가 다르게 해석되면서 Apply 단계에서 차이가 발생합니다. aws_ami 조회, IAM 역할 ARN, 그리고 레지스트리에서 가져오는 모든 것에서 흔히 발생합니다.
폭발 반경 제한 부재 (No blast-radius limit). 에이전트가 가장 깔끔한 해결책은 VPC를 삭제하는 것이라고 결정합니다. CI 역할이 관리자(admin) 권한을 가지고 있기 때문에 기술적으로는 가능합니다. 네, 실제로 일어난 일입니다.
에이전트가 읽을 수 없는 테스트 보고서 (No agent-readable test reports). Cypress 실행이 실패했습니다. 그 이유는 ANSI 색상 코드가 포함된 4MB 분량의 표준 출력(stdout) 속에 파묻혀 있습니다. 에이전트는 200줄만 읽고는 포기한 채, PR 댓글에 "테스트 통과"라고 적어버립니다.

Northflank는 그들의 AI 에이전트를 위한 휘발성 실행 환경에 관한 2026년 3월 글에서 이 더 넓은 범주에 대해 작성했으며, 대부분의 내용이 일치합니다. 흥미로운 점은 "에이전트 코드를 샌드박스(sandbox)에서 실행한다"와 "샌드박스가 실제로 변경 사항을 검증한다" 사이의 간극입니다.

하네스 (The Harness)

다섯 가지 구성 요소가 있습니다. 그 자체로 새로운 것은 하나도 없습니다. 핵심은 에이전트가 로그의 벽이 아닌, 명확한 판결(verdict)을 받을 수 있도록 이들을 연결하는 것입니다.

1. Plan이 재현 가능할 때까지 Terraform을 잠그세요

제가 들어본 모든 드리프트(drift) 불만은 고정되지 않은 프로바이더(provider)나 암시적 데이터 소스(implicit data source)에서 시작됩니다. 한 번에 해결하세요:

terraform {
  required_version = "= 1.9.8"

...

= 1.9.8 방식은 ~> 1.9가 아닌 정확한 고정(exact-pin) 방식입니다. 에이전트는 버전 제약 조건을 "수정"하려고 시도하지만, 그래서는 안 됩니다. 하네스(harness)에서 terraform plan -refresh=false -lock-timeout=120s를 실행하여 오래된 데이터 소스가 몰래 끼어들지 못하게 하세요.

또한, 저는 모든 프리뷰 실행을 PR 번호로 명명된 워크스페이스(workspace)로 감쌉니다. 이렇게 하면 상태(state)가 격리되며, terraform workspace delete pr-1247 명령 하나로 정리할 수 있습니다.

2. 에이전트에게 별도의 클러스터가 아닌, 자체적인 임시(Ephemeral) EKS 네임스페이스를 부여하세요

일부 Northflank 문서에서는 PR마다 새로운 EKS 클러스터를 생성하는 것을 제안합니다. 하지만 실제로 이는 12~15분이 소요되며, 컨트롤 플레인(control plane) 비용만 시간당 0.10달러가 소모됩니다. 4분 이내에 판결을 받아야 하는 에이전트 워크플로(workflow)의 경우, 이미 가동 중인(warm) 클러스터에 PR당 네임스페이스를 할당하는 방식이 승리합니다.

# kustomize/preview/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
...

작은 청소부 컨트롤러(janitor controller)가 TTL 어노테이션(annotation)보다 오래된 네임스페이스를 삭제합니다. 30개의 동시 프리뷰 네임스페이스를 유지하는 5개 노드의 m6i.large 풀 기준으로 한 달에 약 14달러 정도가 듭니다.

3. OPA를 통해 에이전트가 변경할 수 있는 범위에 엄격한 제한을 두세요

이것은 아무도 쓰고 싶어 하지 않지만 모두에게 필요한 부분입니다. 에이전트는 자신의 권한을 확장하려고 시도할 것입니다. IAM 계층이 아닌 정책(policy) 계층에서 이를 차단하세요. IAM 계층은 너무 거칠기(coarse) 때문입니다:

package terraform.blastradius

import future.keywords.in
...

conftest test plan.json -p policies/로 실행하세요. conftest의 종료 코드(exit code)가 PR 체크가 됩니다. 총 비용은 제가 어느 일요일 아침에 작성한 약 80줄의 Rego 코드뿐입니다.

4. 에이전트가 읽을 수 있는 자동 롤백 신호를 위해 Argo Rollouts를 사용하세요

Argo Rollouts에는 카나리(Canary) 메트릭을 안정적인 베이스라인(Stable baseline)과 비교하는 분석 템플릿(Analysis templates)이 있습니다. 그 출력값은 구조화되어 있습니다. 그것이 바로 핵심입니다.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata
...

이 템플릿이 실패하면, Argo는 실패 모드를 Rollout 상태 필드에 기록합니다. 나의 하네스(Harness)는 해당 필드를 스크래핑(Scrape)하여 에이전트가 다음에 읽을 수 있는 구조화된 판정(Verdict)으로 변환합니다.

5. 합성 프로브(Synthetic Probes)가 아닌 실제 트래픽을 재생(Replay)하세요

모든 프리뷰 환경(Preview environment)이 하는 거짓말은 curl /health 루프가 "검증"이라는 것입니다. 그것은 검증이 아닙니다. 실제 운영(Prod) 트래픽의 1~5%를 프리뷰 네임스페이스(Namespace)로 미러링(Mirror)하세요. GoReplay가 가장 저항이 적은 방법입니다:

# 운영 인그레스(Ingress) 노드에서 2%를 샘플링하여 프리뷰로 섀도잉(Shadow)합니다
gor --input-raw :443 \
    --input-raw-track-response \
...

PII(개인정보) 규칙: 인증 엔드포인트(Auth endpoints)의 요청 본문(Request bodies)은 절대 재생하지 마세요. 카드 데이터를 포함하는 그 어떤 것도 재생하지 마세요. --http-disallow-url 플래그는 절대 건너뛰어서는 안 되는 경계선입니다. 저는 작은 Go 전처리기(Pre-processor)에 두 번째 필터를 추가하여 Authorization, Cookie, 그리고 *-token과 일치하는 모든 헤더를 제거합니다.

프리뷰 환경에서 5분 동안 운영 트래픽을 섀도잉하면 합성 테스트(Synthetic tests)로는 절대 찾을 수 없는 종류의 버그가 드러납니다. 예를 들어, 에이전트의 "최적화"로 인해 저장된 항목이 50개 이상인 사용자의 DB 호출이 두 배로 늘어나는 코너 케이스(Corner case) 같은 것입니다. 우리는 이를 PR 1183에서 잡아냈습니다.

6. 로그 테일(Log tail)이 아닌 에이전트가 읽을 수 있는 판정(Verdict)을 작성하세요

에이전트가 결과를 파싱(Parse)할 수 없다면 전체 루프는 낭비됩니다. JSON 파일을 생성하고, 에이전트가 도구 호출(Tool call)을 통해 가져올 수 있는 안정적인 키(Key)와 함께 S3에 저장하세요:

{
  "pr": 1247,
  "verdict": "fail",
...

에이전트는 이를 읽고 정확히 어떤 단계를 수정해야 하는지 알게 됩니다. 로그 스크래핑(Log scraping)도, ANSI 코드도, 느낌(Vibes)에 기반한 디버깅도 필요 없습니다.

첫 17일간의 결과

지표	harness 적용 전	harness 적용 후
주간 잘못된 머지(Bad merges/week)	4	0
...	...	...

비용 감소는 주로 PR(Pull Request)마다 생성하던 EKS 클러스터를 제거하고

마치며. CI/CD 벤더인 Harness는 "에이전트 하네스 (agent harness)"라는 용어가 생기기 전에 이미 제품 이름을 정했습니다. 이러한 명칭의 충돌은 향후 1년 동안 사람들을 혼란스럽게 만들 것입니다. 하지만 이 개념은 특정 벤더보다 훨씬 더 거대합니다. 만약 구조화된 판결 (structured verdicts)을 반환하는 검증 계층 (verification layer) 없이 AI 에이전트가 프로덕션 인프라 (production infra)에 접근하도록 허용하고 있다면, 당신은 오픈 루프 제어 시스템 (open-loop control system)을 운영하며 모델이 잘 교정 (calibrated)되어 있기를 바라고 있는 것과 같습니다. 하지만 모델은 그렇지 않습니다.

하네스 (harness)를 구축하십시오. 그런 다음 에이전트가 작업하게 하십시오.

리소스: