[Cloud Ops Lab #3] 바이브 코딩과 Harness 전략

[Cloud Ops Lab #3] 바이브 코딩과 Harness 전략

1. 시작하며

Cloud Ops Lab에서도 코드와 설정 대부분은 AI Coding Assistant와 함께 작성할 예정이다.

다만 이번 프로젝트에서 말하는 바이브 코딩은 단순히:

"Kubernetes 운영 환경 만들어줘."
        ↓
AI가 Dockerfile 작성
        ↓
Deployment / Service 작성
        ↓
HPA 추가
        ↓
Prometheus / Grafana 연결
        ↓
AWS 배포
        ↓
완성

하는 방식은 아니다.

Playback Gate부터 LLM Router까지 여러 프로젝트를 진행하면서 AI Coding Assistant를 사용하는 방식도 계속 바뀌었다.

처음에는 Repository 안에 요구사항과 설계 문서를 남기고 Test와 Metric으로 결과를 확인하는 정도였다.

하지만 실제 프로젝트를 반복하면서 다음과 같은 문제가 계속 보였다.

AI가 필요하지 않은 기술을 먼저 추가한다.

문제를 재현하기 전에 해결책부터 구현한다.

코드는 동작하지만 실제로 좋아졌는지는 알 수 없다.

실험 결과보다 처음 예상한 Architecture를 정답처럼 유지한다.

README와 ADR을 프로젝트 후반에 몰아서 작성한다.

실패한 상태가 해결 코드에 덮여 Git에서 사라진다.

반복 Workflow가 생겨도 계속 수작업으로 처리한다.

그리고 가장 최근에는
블로그의 목표와 Repository의 요구사항이
서로 다른 프로젝트를 가리키는 문제까지 생겼다.

특히 LLM Router에서는 Repository 안의 Harness는 비교적 잘 작동했지만:

Blog Goal
≠
Repository REQUIREMENTS

상태가 프로젝트 초반부터 존재했다.

결국 프로젝트가 끝난 뒤:

어느 기준으로 성공을 판단해야 하지?

를 다시 정리해야 했다.

그래서 Cloud Ops Lab에서는 이전 Harness를 그대로 사용하는 것이 아니라,
그 회고까지 처음부터 반영하려고 한다.

핵심 원칙은 이전과 같다.

AI가 구현 속도를 높이도록 하되, 무엇을 만들고 무엇을 성공으로 판단할지에 대한 통제권은 개발자가 유지한다.

다만 이번 프로젝트에서는 한 가지를 더 명확하게 추가한다.

프로젝트의 목표가 바뀌는 것 역시 Architecture 변경만큼 중요한 결정으로 취급한다.

---

2. 지금까지 Harness는 어떻게 변했는가

Playback Gate에서는 처음으로 Repository의 문서와 Test, Metric을 AI 개발의 기준으로 사용했다.

Playback Gate

Docs
+
Test
+
Performance Metric

여기서 가장 중요했던 것은:

AI가 완료했다고 말한다
≠
실제로 완료됐다

를 구분하는 것이었다.

k6 결과와 동시성 조건이 실제 완료 기준이었다.

Live Event Stream에서는 여기에 Experiment와 Git History를 추가했다.

Live Event Stream

Docs
+
Project Rule에 가까운 Skill
+
Test
+
Experiment
+
Git

Consumer Lag, Duplicate Event, Failure Event 같은 문제를 직접 재현하고
해결 전 상태도 기록하려고 했다.

ContentOps Agent에서는 Test만으로 AI 품질을 평가하기 어렵다는 문제가 생겼다.

ContentOps Agent

Docs
+
Project Rule
+
Test
+
Evaluation
+
Experiment
+
Git

그래서 Evaluation Dataset과 Metric을 Harness 안으로 가져왔다.

LLM Router에서는 이 구조를 유지하면서 Routing Decision까지 관찰 대상으로 확장했다.

하지만 회고에서는 새로운 문제가 하나 더 보였다.

Repository 안의 개발 과정은 일관됨

하지만

Blog Goal
≠
Repository Goal

이었다.

Cloud Ops Lab에서는 이 문제까지 Harness 안으로 가져간다.

---

3. Cloud Ops Lab에서는 Harness의 범위가 다시 넓어진다

이번 프로젝트는 AI 품질을 평가하는 프로젝트가 아니다.

대신 운영 환경 자체를 실험한다.

Application
+
Container
+
Kubernetes
+
Observability
+
Failure
+
Recovery

를 같이 본다.

따라서 이번 Harness에는 새로운 구성 요소가 들어간다.

Docs

Rule

Test

Experiment Scenario

Metrics

Failure Injection

Recovery Record

ADR

Git

README

특히 Experiment Scenario가 중요하다.

이전 AI 프로젝트에서 Evaluation Dataset을 보호했다면,
이번에는 다음 조건을 보호해야 한다.

Load 조건

Replica 수

Resource 설정

Failure 방식

관찰 시간

측정 Metric

그래야:

설정 바꿨더니 좋아 보인다.

가 아니라:

같은 Scenario에서
변경 전후가 실제로 어떻게 달라졌는가?

를 비교할 수 있다.

---

4. 이번에는 Blog Goal부터 Repository와 맞춘다

LLM Router 회고에서 가장 크게 남은 문제는 기술이 아니었다.

블로그에서 정의한 프로젝트

vs

Repository에서 실제로 개발한 프로젝트

가 달랐다.

Cloud Ops Lab에서는 개발을 시작하기 전에 다음 세 문서의 첫 목표를 맞춘다.

Blog #1 Goal
=
REQUIREMENTS Project Goal
=
ROADMAP의 전체 방향

이번 프로젝트의 목표를 줄이면 다음과 같다.

Kubernetes 환경에 Application을 배포하고

↓

Load와 Failure를 직접 재현하고

↓

Prometheus / Grafana와 Kubernetes 상태를 이용해 관찰하고

↓

운영 설정 변경 전후의
Latency / Error / Resource / Recovery를 비교한다.

이 문장이 블로그와 Repository에서 서로 달라지면 개발을 진행하지 않는다.

---

5. Scope 변경도 Human Gate 대상이다

프로젝트를 진행하다 보면 처음 계획보다 더 중요한 문제가 나타날 수 있다.

Scope가 바뀌는 것 자체는 실패가 아니다.

문제는 그 변경이 조용히 일어나는 것이다.

LLM Router에서는:

Multi-Provider Gateway / Resilience

        ↓

Model Routing Evaluation

으로 중심이 이동했지만
이를 명시적인 Scope 변경으로 남기지 않았다.

Cloud Ops Lab에서는 Scope가 달라질 경우 다음 형식으로 멈춘다.

현재 목표

↓

새롭게 중요해진 문제

↓

Scope 변경 후보

↓

기존 요구사항 중 포기되는 것

↓

새 성공 기준

↓

Human Gate

↓

Decision

↓

ADR

예를 들어 프로젝트가 진행되다가:

Kubernetes 운영 실험

보다:

AWS 비용 최적화

가 중심이 되기 시작한다면
그냥 기능을 추가하지 않는다.

현재 프로젝트 안에서 다룰지,
다음 프로젝트로 분리할지를 먼저 결정한다.

---

6. Harness는 AI에게 긴 Prompt를 잘 쓰는 방법이 아니다

Harness를 단순히:

좋은 System Prompt

+
많은 Context

라고 보면 너무 좁다.

프로젝트를 진행하면서 Harness는 다음과 같이 보게 됐다.

Model
+
Context
+
Rules
+
Tools
+
Verification

그리고 Repository 기준으로는:

REQUIREMENTS

DESIGN

ROADMAP

TASKS

RULE

TEST

EXPERIMENT SCENARIO

EXPERIMENT RESULT

ADR

GIT

README

가 모두 Harness의 일부다.

Cloud Ops Lab에서는 여기에:

Kubernetes Manifest

Monitoring 설정

Failure Script

Load Script

도 프로젝트 Context가 된다.

중요한 것은 파일이 많아지는 것이 아니다.

AI와 개발자가 같은 현재 상태와 같은 성공 기준을 공유하도록 만드는 것

이 목적이다.

---

7. Repository를 프로젝트의 기억으로 사용한다

이번에도 대화 Context만 믿지 않는다.

Repository 안에 프로젝트의 상태를 남긴다.

기본 구조는 다음 정도로 시작한다.

docs/
├── REQUIREMENTS.md
├── DESIGN.md
├── ROADMAP.md
├── TASKS.md
├── adr/
└── experiments/

experiments/
└── scenarios/

k8s/
├── base/
└── ...

monitoring/
├── prometheus/
└── grafana/

scripts/
└── ...

.cursor/
└── rules/
    └── cloud-ops-lab.mdc

README.md

구체적인 Directory는 실제 구현하면서 바뀔 수 있다.

하지만 역할은 분리한다.

REQUIREMENTS
→ 무엇을 만족해야 하는가

DESIGN
→ 현재 운영 구조는 무엇인가

ROADMAP
→ 어떤 운영 문제를 어떤 순서로 확인할 것인가

TASKS
→ 지금 Phase에서 무엇을 할 것인가

SCENARIO
→ 어떤 조건으로 실험할 것인가

EXPERIMENT
→ 실제 결과가 어떻게 나왔는가

ADR
→ 왜 이 운영 정책을 선택했는가

RULE
→ AI가 어떤 제약 안에서 작업해야 하는가

README
→ 사람이 Repository에 어떻게 진입하는가

---

8. DESIGN에는 현재 구조만 기록한다

이 원칙은 이전 프로젝트에서 계속 유지했다.

Cloud Ops Lab의 ROADMAP에는:

HPA

Pod Failure

Readiness / Liveness

Rolling Update

AWS

가 등장한다.

하지만 ROADMAP에 있다는 이유만으로 처음 DESIGN에 전부 넣지 않는다.

예를 들어 Baseline이:

Client
   ↓
Service
   ↓
Deployment
   ↓
Pod 1
   ↓
Backend

이라면 DESIGN에도 이 구조만 적는다.

HPA를 실제로 적용한 뒤에는:

HPA
↓
Deployment

를 현재 구조에 반영한다.

즉:

DESIGN은 계획 문서가 아니라 현재 상태의 Single Source of Truth로 사용한다.

---

9. ROADMAP은 기술 설치 순서가 아니라 문제 확인 순서다

Cloud Native 프로젝트는 특히 기술 목록 중심으로 ROADMAP을 만들기 쉽다.

예:

Docker

↓

Kubernetes

↓

Prometheus

↓

Grafana

↓

HPA

↓

Argo CD

↓

AWS

하지만 이런 구조는:

Phase 도달
=
기술 설치

가 되기 쉽다.

이번 ROADMAP은 문제 중심으로 만든다.

예:

Baseline 운영 상태 확인

↓

고정 Replica의 Capacity 확인

↓

Resource 제약 영향 확인

↓

Health Check 동작 확인

↓

Pod Failure 영향 확인

↓

자동 Scaling 필요성 확인

↓

배포 중 서비스 영향 확인

↓

AWS 환경에서 핵심 Scenario 검증

즉 HPA를 사용하는 Phase에서도 질문은:

HPA를 적용했는가?

가 아니라:

고정 Replica의 문제를
자동 Scaling이 실제로 줄였는가?

가 된다.

---

10. Baseline은 일부러 단순하게 만든다

Cloud Ops Lab에서도 처음부터 완성형 운영 환경을 만들지 않는다.

초기 구조는 가능한 한 단순하게 시작한다.

Client
   ↓
Service
   ↓
Deployment
   ↓
Pod
   ↓
Backend

처음에는 고정 Replica를 사용한다.

Replica = Fixed

그리고:

Application Metric

CPU

Memory

Ready Pod

정도를 관찰할 수 있는 상태를 만든다.

처음부터 HPA를 넣으면:

현재 Replica의 Capacity 한계

를 보기 어렵다.

처음부터 복잡한 Probe와 복구 정책을 넣으면:

기본 Kubernetes가 Failure에서 어떻게 동작하는가

를 보기 어렵다.

따라서 Baseline의 목적은:

운영 문제를 최대한 많이 예방하는 것

이 아니라:

문제를 관찰할 수 있는 가장 단순한 기준점을 만드는 것

이다.

---

11. Test와 운영 Experiment를 분리한다

Cloud Ops Lab에서도:

Test 통과
≠
운영 상태가 좋다

를 분리한다.

일반 Test에서는 다음을 확인할 수 있다.

Application API가 동작하는가?

Health Endpoint가 정상인가?

Container가 실행되는가?

Manifest가 유효한가?

하지만 Test가 통과해도 다음 질문에는 답할 수 없다.

Traffic이 증가하면 어디에서 Saturation이 생기는가?

Pod 하나가 죽으면 사용자 Error가 발생하는가?

HPA는 Spike Traffic을 따라갈 수 있는가?

Rolling Update 중 p99는 어떻게 변하는가?

따라서 이번에는:

TEST
→ 코드와 설정이 정상 동작하는가

EXPERIMENT
→ 운영 환경에서 실제로 어떤 일이 발생하는가

를 구분한다.

---

12. Dashboard가 있다는 것과 Observability가 있다는 것은 다르다

이번 프로젝트에서 Prometheus와 Grafana를 사용할 예정이다.

하지만:

Grafana Dashboard 생성
=
Observability 확보

라고 보지는 않는다.

Dashboard에:

CPU

Memory

Pod Count

가 보인다고 해서 장애 원인을 설명할 수 있는 것은 아니다.

예를 들어 p99가 증가했다면:

p99 증가
↓
Traffic 증가?
↓
CPU Saturation?
↓
Ready Pod 감소?
↓
HPA Scale-out 지연?
↓
Application 내부 병목?

를 좁혀갈 수 있어야 한다.

그래서 이번 프로젝트에서는:

관측 도구를 설치했는지가 아니라 관측 데이터를 이용해 시스템 내부 상태를 설명할 수 있는가

를 Observability의 기준으로 본다.

---

13. Experiment Scenario를 Dataset처럼 보호한다

ContentOps Agent와 LLM Router에서는 Evaluation Dataset을 구현에 맞게 고치지 않는 것을 중요하게 봤다.

Cloud Ops Lab에서는 같은 역할을 Experiment Scenario가 한다.

예를 들어 Replica 1과 Replica 3을 비교한다면:

Application Version

Load 조건

Resource 설정

관찰 시간

을 가능한 한 동일하게 유지한다.

결과가 마음에 들지 않는다고:

Load를 낮추거나

Observation 시간을 줄이거나

Failure 타이밍을 바꾸거나

Metric을 다른 방식으로 집계

해서 개선된 것처럼 만들지 않는다.

Scenario 자체의 오류가 있다면 수정할 수 있다.

다만 그때는:

왜 바꿨는가?

기존 결과와 비교 가능한가?

를 기록한다.

---

14. Failure는 기다리지 않고 직접 만든다

LLM Router 회고에서는 외부 Provider Failure를 제대로 통제하지 못했다.

실제 429, 503 같은 Error는 관찰했지만:

오늘 발생한 Failure

를:

내일 같은 조건으로 재현

할 수 없었다.

Cloud Ops Lab에서는 이 문제를 처음부터 반대로 접근한다.

실제 장애가 생기면 관찰한다.

가 아니라:

통제 가능한 Failure Scenario를 만든다.

로 시작한다.

예:

Pod Kill

Readiness Failure

Liveness Failure

CPU Constraint

Memory Constraint

Traffic Spike

Broken Deployment

이런 Failure는 같은 조건으로 다시 실행할 수 있어야 한다.

그래야:

Before

vs

After

비교가 가능하다.

---

15. Failure Injection의 목적은 장애를 많이 만드는 것이 아니다

Failure를 만든다고 해서 Chaos Engineering Platform부터 도입하지 않는다.

처음에는 가장 단순한 방식이면 충분하다.

예:

kubectl delete pod

설정된 Failure Endpoint

Resource Limit 변경

Load Script

중요한 것은:

장애를 멋지게 만들었다.

가 아니다.

각 Failure가 다음 질문에 답할 수 있어야 한다.

언제 발생했는가?

어떤 Metric이 먼저 변했는가?

사용자 Request에는 어떤 영향이 있었는가?

Kubernetes는 어떻게 반응했는가?

언제 정상화됐는가?

즉 Failure Injection 역시 검증을 위한 도구다.

---

16. Recovery도 하나의 Metric으로 본다

이전 프로젝트에서는 주로:

Latency

RPS

Lag

Accuracy

Cost

를 봤다.

Cloud Ops Lab에서는 Recovery도 중요한 결과다.

예를 들어 Pod 하나가 죽었다고 하자.

Pod Failure
      ↓
새 Pod 생성

여기까지만 보면 Kubernetes는 정상적으로 동작한 것처럼 보인다.

하지만 실제 서비스에서는:

Failure 발생

↓

Ready Pod 감소

↓

Request Error / Latency 변화

↓

새 Pod 생성

↓

Application Startup

↓

Readiness PASS

↓

서비스 정상화

까지 시간이 필요하다.

따라서:

Infrastructure Recovery

와:

Service Recovery

를 가능한 한 구분해서 본다.

---

17. 같은 시간축에서 Metric을 연결한다

운영 문제는 최종 숫자만 비교하면 원인을 놓치기 쉽다.

예를 들어:

p99 = 800ms

만 보면 왜 느린지 알 수 없다.

하지만 시간축에서:

Traffic 증가
      ↓
CPU 증가
      ↓
p99 증가
      ↓
HPA Desired Replica 증가
      ↓
새 Pod 생성
      ↓
Ready Pod 증가
      ↓
p99 감소

를 같이 보면 해석할 수 있다.

Cloud Ops Lab에서는 가능한 Experiment에서:

Load Event

Kubernetes Event

Resource Metric

Application Metric

을 같은 시간 흐름으로 연결해보려고 한다.

이번 프로젝트에서 Observability를 학습하는 핵심도 여기에 있다.

---

18. Metric을 많이 모으는 것이 목표는 아니다

Cloud 운영 프로젝트를 시작하면 수집할 수 있는 Metric이 너무 많다.

예:

CPU

Memory

Network

Disk

GC

Thread

Pod

Node

Container

Request

Error

Latency

Restart

Replica

HPA

하지만 모든 Metric을 처음부터 Dashboard에 넣지는 않는다.

각 Experiment에서:

이 문제를 설명하기 위해
어떤 Metric이 필요한가?

를 먼저 본다.

예를 들어 Pod Failure라면:

Ready Pod

Error Rate

Latency

Restart

Recovery Time

가 우선일 수 있다.

Resource Constraint라면:

CPU

Memory

Latency

Error

가 우선일 수 있다.

관측 가능한 정보의 양보다 문제와 Metric의 연결을 중요하게 본다.

---

19. HPA도 기술이 아니라 가설로 다룬다

HPA는 이번 프로젝트에서 직접 학습할 핵심 기술이다.

하지만:

Cloud Ops Lab
=
HPA 반드시 효과 있음

이라고 가정하지 않는다.

먼저:

Fixed Replica
      ↓
Traffic 증가
      ↓
Capacity 한계 확인

을 한다.

그 다음 HPA를 적용하고:

Scale-out Time

Ready Pod

p95 / p99

Error Rate

Resource

를 같은 Scenario에서 비교한다.

결과는 여러 형태가 가능하다.

Latency 개선

Error 감소

일 수도 있고:

Scale Out이 늦어 Spike에는 효과 부족

일 수도 있다.

또는:

Replica는 늘었지만
Application 외부 병목 때문에 Latency 거의 동일

일 수도 있다.

HPA를 사용했다는 사실이 아니라 결과가 중요하다.

---

20. Resource를 늘렸다는 것과 효율이 좋아졌다는 것은 다르다

Replica를 늘리거나 CPU / Memory를 더 주면 성능이 좋아질 수 있다.

하지만:

Resource 증가
=
개선

으로 보지는 않는다.

예를 들어:

Replica 1
p99 = 900ms

Replica 3
p99 = 800ms

라면 성능은 좋아졌다.

하지만 Resource는 세 배 가까이 늘었을 수도 있다.

그래서 이번에는:

Performance

Resource

Recovery

를 같이 본다.

AWS 단계에서는 여기에:

Cost

도 연결될 수 있다.

다만 이번 프로젝트에서 완전한 FinOps 시스템을 만드는 것이 목표는 아니다.

---

21. Human Gate는 운영 정책의 의미가 바뀌는 곳에 둔다

모든 YAML 변경마다 Human Gate를 열지는 않는다.

단순한 Manifest 수정이나 Test 추가는 AI에게 맡길 수 있다.

대신 다음과 같이 시스템의 운영 의미가 달라지는 결정은 Human Gate 대상이다.

Resource Request / Limit 기준 변경

Replica 기본값 변경

Readiness 정책 변경

Liveness 정책 변경

HPA Metric 변경

HPA Threshold 변경

Min / Max Replica 변경

Rolling Update 전략 변경

Failure Scenario의 성공 기준 변경

AWS Architecture 선택

Monitoring / Alert 기준 변경

새 운영 도구 도입

프로젝트 Scope 변경

이런 변경은 결과에 직접 영향을 준다.

---

22. Human Gate의 입력 형식을 고정한다

Human Gate를 열 때 AI가:

HPA Threshold를 60%로 낮추는 것이 좋습니다.

처럼 제안만 하는 것으로 끝내지 않는다.

가능하면 다음 형식을 유지한다.

현재 Failure / 문제

↓

현재 Metric

↓

원인 가설

↓

후보

↓

장점 / 단점

↓

추천안

↓

STOP

↓

Developer Decision

예:

문제
Spike Load에서 p99 급증

Metric
CPU 95%
Scale-out 시작까지 X초

후보 A
HPA Threshold 조정

후보 B
Min Replica 증가

후보 C
현재 유지

Trade-off
Resource / Cost / Recovery

↓

Human Gate

중요한 것은 Gate의 개수가 아니다.

운영 정책에 대한 책임이 어디에 있는지 명확하게 하는 것

이 목적이다.

---

23. Human Gate 직후 ADR을 작성한다

LLM Router에서는 ADR을 일부 프로젝트 후반에 정리했다.

결정은 이미 끝났는데:

왜 그렇게 했지?

를 나중에 다시 복원해야 했다.

이번에는 순서를 고정한다.

Failure

↓

Analysis

↓

Human Gate

↓

Decision

↓

ADR

↓

Implementation

예를 들어 HPA 정책을 변경했다면
변경 코드보다 먼저 또는 같은 작업 단위에서 ADR을 남긴다.

ADR에는 기술 이름보다 판단 과정이 들어가야 한다.

어떤 문제가 있었는가

어떤 Metric에서 확인됐는가

어떤 후보를 비교했는가

왜 이 값을 선택했는가

어떤 Trade-off를 받아들였는가

를 기록한다.

---

24. Git은 운영 Experiment History로 사용한다

Git에는 최종 Manifest만 남기지 않는다.

가능하면:

Baseline
↓
Commit

Failure 재현
↓
Commit

운영 정책 변경
↓
Commit

Re-Experiment
↓
Commit

형태로 남긴다.

예:

experiment: reproduce replica saturation

experiment: reproduce pod failure impact

feat: apply readiness policy

experiment: re-evaluate pod failure recovery

문제가 재현된 상태를 별도 Checkpoint로 남기면:

왜 이 설정이 생겼는가?

를 Git에서도 확인할 수 있다.

---

25. Experiment 이름에는 해결 기술을 미리 넣지 않는다

이번에도:

003-hpa.md

004-readiness.md

005-keda.md

처럼 기술명을 먼저 정답으로 두지 않는다.

대신:

003-replica-capacity.md

004-traffic-protection.md

005-scale-out-delay.md

처럼 문제를 기준으로 작성한다.

예를 들어 scale-out-delay를 해결하는 방법은:

HPA Threshold 조정

Min Replica 조정

Application Startup 개선

다른 Scaling Metric

중 하나일 수 있다.

Experiment 이름에서부터 해결 방법을 결정하지 않는다.

---

26. README는 Baseline Commit부터 실행 가능해야 한다

이 문제는 이전 프로젝트에서 반복해서 남았다.

README를:

프로젝트가 끝난 뒤 정리하는 소개 문서

처럼 다루면 실제 개발 중 Harness 역할을 하지 못한다.

이번에는 Baseline 완료 조건에 README를 포함한다.

최소한 다음은 확인할 수 있어야 한다.

프로젝트 목적

Application 실행 방법

Container Build 방법

Kubernetes 실행 방법

Request 방법

Load Test 방법

Prometheus / Grafana 확인 방법

Experiment 실행 방법

현재 알려진 한계

즉:

Baseline Commit
=
새로운 사람이 README만 보고
기본 실험을 재현할 수 있는 상태

를 목표로 한다.

---

27. Rule과 Skill을 다시 구분한다

이번에도 Project Rule은 처음부터 둔다.

예:

현재 Phase를 벗어나지 않는다.

문제를 재현하기 전에 해결 설정을 넣지 않는다.

측정하지 않은 운영 개선을 주장하지 않는다.

Experiment Scenario를 변경 결과에 맞춰 수정하지 않는다.

DESIGN에는 현재 구조만 기록한다.

중요한 운영 정책 변경은 Human Gate를 거친다.

Scope 변경은 ADR 없이 진행하지 않는다.

이런 내용은 프로젝트 전체에서 항상 적용된다.

반면 Skill은 반복 Workflow가 실제로 생긴 뒤 만든다.

Rule
→ 항상 지켜야 하는 제약

Skill
→ 반복되는 특정 작업 절차

로 구분한다.

---

28. 세 번째 반복에서 Skill 후보를 확인한다

LLM Router 회고에서는:

Evaluation 실행

↓

결과 집계

↓

Failure 분류

↓

Experiment Markdown 작성

이 여러 번 반복됐지만 끝까지 별도 Skill로 만들지 않았다.

Cloud Ops Lab에서는 같은 실수를 줄여보려고 한다.

예를 들어 다음 Workflow가 반복될 수 있다.

Scenario 실행

↓

Metric 수집

↓

Before / After 비교

↓

Failure / Recovery 시점 정리

↓

Experiment Markdown 생성

이 작업이 세 번째 정도 반복되면:

이걸 Skill 또는 Script로 빼면 실제 이득이 있는가?

를 확인한다.

처음부터 Skill을 설계하지는 않는다.

반복이 실제로 존재한 뒤 추출한다.

---

29. Agent보다 Script를 먼저 본다

Cloud Ops Lab에서도 자동화할 일이 많을 수 있다.

예:

Load 실행

Metric 수집

Pod Kill

Experiment 결과 저장

Grafana Snapshot

Kubernetes Event 수집

하지만 이것을 모두 Agent로 만들지는 않는다.

먼저:

Shell Script

Makefile / Task Runner

Test Script

Experiment Runner

정도로 해결할 수 있는지 본다.

예:

run-baseline.sh

run-load.sh

inject-pod-failure.sh

collect-metrics.sh

같은 단순 자동화가 충분할 수 있다.

자동화가 필요하다는 것과 Agent가 필요하다는 것은 다르다.

---

30. Graph와 Multi-Agent는 이번에도 기본값이 아니다

운영 자동화 프로젝트라고 해서 처음부터:

Monitoring Agent
      ↓
Failure Analyzer
      ↓
Scaling Agent
      ↓
Recovery Agent

같은 구조를 만들지 않는다.

이번 프로젝트의 핵심은:

운영 문제를 이해하고

↓

관측하고

↓

변경하고

↓

다시 검증하는 것

이다.

현재 규모에서는:

Harness
+
Human-controlled Loop
+
Script

가 더 단순할 가능성이 높다.

명시적인 State와 복잡한 Loop가 실제 문제로 나타났을 때만 더 복잡한 Orchestration을 검토한다.

---

31. AWS도 마지막 목표라고 해서 처음부터 고정하지 않는다

Cloud Ops Lab의 학습 목표에는 AWS가 포함되어 있다.

하지만 처음부터:

EKS

ALB

Terraform

Argo CD

Managed Prometheus

CloudWatch

같은 Architecture를 모두 확정하지 않는다.

먼저 로컬 Kubernetes에서:

Deploy

Load

Failure

Scaling

Observability

Recovery

를 반복할 수 있는 상태를 만든다.

그 다음 AWS 단계에서 실제 필요한 구조를 결정한다.

AWS 서비스 선택 역시 Human Gate 대상이다.

비교 기준은 예를 들면:

학습 목표 적합성

비용

구현 복잡도

관측 가능성

재현 가능성

이다.

Cloud를 썼다는 사실 자체를 결과로 두지 않는다.

---

32. 이번 Cloud Ops Lab의 개발 Loop

지금까지의 원칙을 이번 프로젝트에 맞게 정리하면 다음과 같다.

BLOG GOAL
      ↓
REQUIREMENTS
      ↓
ROADMAP
      ↓
TASK
      ↓
PLAN
      ↓
IMPLEMENT
      ↓
TEST
      ↓
BASELINE / SCENARIO
      ↓
LOAD / FAILURE INJECTION
      ↓
OBSERVE
      ↓
FAILURE CASE
      ↓
ANALYZE
      ↓
후보 비교
      ↓
HUMAN GATE
      ↓
DECIDE
      ↓
ADR
      ↓
IMPLEMENT
      ↓
RE-EXPERIMENT
      ↓
DESIGN UPDATE
      ↓
COMMIT
      ↓
NEXT TASK

이전 프로젝트보다 새로 강조되는 것은 세 가지다.

Scope 정합성

통제 가능한 Failure Scenario

Recovery / Observability

이다.

---

33. 이번 프로젝트에서 개발자가 계속 통제할 것

AI Coding Assistant를 적극적으로 사용하더라도 다음은 직접 통제한다.

무엇을 만들 것인가
→ BLOG GOAL + REQUIREMENTS

어떤 문제를 어떤 순서로 확인할 것인가
→ ROADMAP

현재 시스템 구조는 무엇인가
→ DESIGN

실험 조건은 무엇인가
→ SCENARIO

무엇을 개선이라고 부를 것인가
→ METRIC / SUCCESS CRITERIA

운영 정책을 어떻게 바꿀 것인가
→ HUMAN GATE + ADR

프로젝트 Scope를 바꿀 것인가
→ HUMAN GATE + ADR

AI에게는:

Manifest 작성

Script 작성

Test 작성

Metric Query 작성

Experiment 결과 정리

문서 초안 작성

같은 반복 작업을 적극적으로 맡길 수 있다.

하지만:

무엇이 문제인가?

어떤 Trade-off를 받아들일 것인가?

무엇을 성공으로 판단할 것인가?

는 개발자가 책임진다.

---

34. 정리

Playback Gate부터 계속 유지해온 원칙은 크게 바뀌지 않았다.

문제를 먼저 확인하고

↓

측정하고

↓

원인을 분석하고

↓

후보를 비교하고

↓

중요한 결정에서는 사람이 판단하고

↓

변경 후 다시 검증한다.

Cloud Ops Lab에서는 여기에 운영 환경의 관점이 추가된다.

기존에는:

API가 느린가?

Consumer가 Lag을 따라가는가?

AI가 정답 문서를 찾는가?

Router가 적절한 Model을 고르는가?

를 확인했다면,

이번에는:

Traffic이 증가할 때
어디에서 Saturation이 발생하는가?

Pod Failure가
사용자 Request에 어떤 영향을 주는가?

Kubernetes가 복구한 시점과
서비스가 정상화된 시점은 같은가?

HPA가 Scale Out한 뒤
Latency와 Error가 실제로 좋아졌는가?

Resource를 더 사용한 만큼
성능이나 안정성이 좋아졌는가?

장애가 발생했을 때
Metric과 Event를 이용해 원인을 설명할 수 있는가?

를 확인한다.

그리고 LLM Router 회고에서 추가로 배운 것도 처음부터 적용한다.

Blog Goal
=
REQUIREMENTS
=
ROADMAP

을 맞추고,

Scope가 달라지면:

Human Gate
↓
ADR

로 기록한다.

README는 Baseline부터 유지하고,

Failure는 외부에서 우연히 발생하기를 기다리지 않고:

통제 가능한 Scenario

로 만든다.

반복되는 Experiment Workflow가 실제로 나타난다면 이번에는 Skill이나 Script로 추출할지도 확인한다.

결국 이번 Cloud Ops Lab에서도 기술 목록이 프로젝트의 성공 기준은 아니다.

Kubernetes를 사용했다
≠
운영을 이해했다

HPA를 적용했다
≠
Scaling 문제가 해결됐다

Grafana를 만들었다
≠
Observability가 확보됐다

Pod가 다시 생겼다
≠
서비스 장애가 없었다

AWS에 배포했다
≠
Cloud 운영을 검증했다

이번 프로젝트가 끝났을 때 목표는:

어떤 Load와 Failure에서 문제가 발생했고, 어떤 Metric으로 원인을 확인했으며, 어떤 운영 정책을 선택했고, 그 결과 Latency·Error·Resource·Recovery가 어떻게 달라졌는지를 같은 Scenario에서 설명할 수 있어야 한다.

그리고 개발 방식 역시:

AI에게 구현 속도와 반복 작업은 맡기되, 프로젝트의 목표·Scope·성공 기준·운영 정책에 대한 통제권은 개발자가 유지한다.

라는 원칙이 실제 Cloud 운영 프로젝트에서도 작동하는지 다시 확인해보려고 한다.