[LLM Router #3] 바이브 코딩과 Harness 전략

[LLM Router #3] 바이브 코딩과 Harness 전략

1. 시작하며

LLM Router 프로젝트에서도 코드 대부분은 AI Coding Assistant와 함께 작성할 예정이다.

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

"LLM Router 만들어줘."
        ↓
AI가 전체 구조 설계
        ↓
여러 Model 연결
        ↓
완성

하는 방식은 아니다.

Playback Gate, Live Event Stream, ContentOps Agent까지 세 프로젝트를 진행하면서 AI Coding Assistant를 사용하는 방식도 계속 바뀌었다.

처음에는 단순히 AI가 프로젝트 Context를 잃지 않도록 문서를 제공하는 정도였다.

하지만 실제 프로젝트를 진행하고 회고하면서 다음과 같은 문제들이 계속 보였다.

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

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

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

실험 결과보다 처음 세운 가설을 정답처럼 유지한다.

대화가 길어질수록 이전 결정이 사라진다.

실패한 상태가 최종 코드에 덮여서 Git에서 보이지 않는다.

README와 문서를 마지막에 몰아서 작성한다.

Project Rule과 반복 Workflow가 섞인다.

그래서 프로젝트를 진행할수록 개발 방식 자체도 계속 수정했다.

이번 LLM Router에서는 세 프로젝트를 거치면서 남은 회고를 한 번 더 정리하고, 그 결과를 처음부터 Harness에 반영해보려고 한다.

핵심 원칙은 이전과 같다.

AI가 구현 속도를 높이도록 하되, 요구사항·설계·성공 기준·기술 선택·검증 기준에 대한 통제권은 개발자가 유지한다.

---

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

Playback Gate에서는 처음으로 Repository 내부 문서를 AI의 Context로 사용했다.

Playback Gate

Docs
+
Test
+
Performance Metric

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

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

를 구분하는 것이었다.

Test와 k6 결과가 실제 완료 조건이었다.

Live Event Stream에서는 이 방식을 조금 더 확장했다.

Live Event Stream

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

성능뿐 아니라:

Consumer Lag

Duplicate Event

Failure Event

Replay

Schema Evolution

같은 문제를 직접 재현하고 Experiment로 남겼다.

ContentOps Agent에서는 AI 기능을 다루면서 한 가지가 더 필요해졌다.

ContentOps Agent

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

AI에서는:

API가 동작한다

와:

정답을 찾는다

가 같지 않았기 때문이다.

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

LLM Router에서는 이 구조를 다시 사용하되 Routing이라는 새로운 판단을 검증 대상으로 추가한다.

---

3. 세 프로젝트 회고에서 가장 크게 남은 결론

세 프로젝트에서 사용한 기술은 모두 다르다.

Playback Gate
→ API / DB / Cache / 동시성

Live Event Stream
→ Kafka / Consumer / Idempotency / Failure

ContentOps Agent
→ RAG / Evaluation / Tool Calling

하지만 회고에서 반복된 결론은 거의 같았다.

처음 예상한 기술
≠
실제로 필요한 기술

Playback Gate에서는 Redis를 사용할 것이라고 생각했지만 Caffeine과 DB Lock이 남았다.

Live Event Stream에서는 Redis Deduplication, Retry Topic, Schema Registry를 사용할 수도 있다고 생각했지만 현재 문제에서는 필요하지 않았다.

ContentOps Agent에서는 Hybrid Search, RRF, Reranker, LangGraph를 학습 대상으로 생각했지만 실제 Evaluation에서는 도입 근거가 충분하지 않았다.

그래서 이번 프로젝트에서는 처음부터:

기술 사용 여부를 프로젝트의 성공 기준으로 두지 않는다.

를 더 강하게 적용한다.

---

4. 바이브 코딩에서 가장 위험한 것은 구현 속도가 아니다

AI Coding Assistant를 사용하면 코드는 빠르게 늘어난다.

이 자체는 장점이다.

문제는:

코드 증가 속도
>
개발자의 시스템 이해 속도

가 되는 순간이다.

예를 들어 AI에게 LLM Router를 설계해달라고 하면 자연스럽게 다음과 같은 구조를 제안할 수 있다.

Rule Routing

Semantic Routing

LLM Routing

Model Cascade

Fallback

Retry

Routing Cache

Dynamic Threshold

Provider Abstraction

Cost Optimizer

Multi-Agent

하나씩 보면 모두 사용할 수 있는 기술이다.

하지만 프로젝트의 목적은 이런 기술을 최대한 많이 사용하는 것이 아니다.

이번에도:

기술 후보
↓
구현
↓
문제 찾기

가 아니라:

문제
↓
측정
↓
원인
↓
기술 후보

순서를 지킨다.

---

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

Harness를 처음 접했을 때는 AI에게 충분한 Context와 Rule을 주는 개념으로 이해하기 쉽다.

하지만 세 프로젝트를 진행하면서 Harness는 조금 더 넓게 보게 됐다.

Model
+
Context
+
Rules
+
Tools
+
Verification

이 모두가 AI가 작업할 수 있는 환경이다.

Repository 기준으로 보면:

REQUIREMENTS

DESIGN

ROADMAP

TASKS

RULE

TEST

EVALUATION

EXPERIMENT

ADR

GIT

README

가 모두 Harness의 일부가 될 수 있다.

중요한 것은 문서가 많아지는 것이 아니다.

AI와 개발자가 같은 프로젝트 상태와 같은 성공 기준을 공유하도록 만드는 것

이 목적이다.

---

6. 이번 프로젝트에는 두 종류의 AI 판단이 있다

LLM Router에서는 이전 프로젝트와 다른 재미있는 점이 하나 있다.

AI 판단이 두 곳에 존재한다.

첫 번째는 개발 과정이다.

Developer
    ↓
AI Coding Assistant
    ↓
Code

여기에서는 개발자가 Coding Assistant를 통제한다.

두 번째는 Runtime이다.

User Request
    ↓
LLM Router
    ↓
Model

여기에서는 Router가 어떤 Model을 선택할지 판단한다.

즉:

개발 중 판단
+
Runtime 판단

두 종류의 판단을 모두 검증해야 한다.

이번 Harness는 Coding Assistant만 통제하는 것이 아니라, 우리가 만드는 Router의 판단 역시 관찰 가능하게 만들어야 한다.

---

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

대화 Context는 계속 길어질 수 있고 결국 사라질 수도 있다.

실제로 프로젝트를 진행하면서:

이전에 왜 이렇게 결정했지?

현재 Phase가 어디였지?

왜 이 기술을 안 넣었지?

이 Metric은 어떤 조건에서 측정했지?

같은 정보를 대화에만 의존하는 것은 위험하다고 느꼈다.

그래서 이번에도 Repository 안에 Context를 남긴다.

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

evaluation/
└── ...

.cursor/
└── rules/
    └── llm-router.mdc

README.md

대화는 작업 인터페이스일 뿐이고,

프로젝트의 기억은 Repository에 남긴다.

---

8. 문서의 역할을 섞지 않는다

Playback Gate에서는 초기에 문서 이름과 실제 역할이 뒤섞인 부분이 있었다.

그 회고를 Live Event Stream에서 수정했고 이후에는 각 문서의 역할을 더 명확하게 나눴다.

이번 프로젝트에서도 그대로 유지한다.

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

DESIGN
→ 현재 시스템은 어떻게 구현되어 있는가

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

TASKS
→ 지금 무엇을 할 것인가

ADR
→ 왜 이런 선택을 했는가

EXPERIMENT
→ 실제로 어떤 결과가 나왔는가

특히 DESIGN.md에는:

앞으로 이렇게 만들 예정이다.

를 넣지 않는다.

DESIGN은 미래 계획이 아니라:

현재 코드가 실제로 어떻게 동작하는지를 설명하는 Single Source of Truth

로 유지한다.

---

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

ROADMAP 역시 처음에는:

Cache 적용
Lock 적용
DLT 적용
RAG 개선

처럼 기술 적용 순서로 작성하기 쉽다.

하지만 이렇게 작성하면 Phase에 도착한 순간 해당 기술을 구현해야 할 것처럼 보인다.

그래서 이후 프로젝트에서는 ROADMAP을:

무엇을 확인할 것인가

중심으로 만들었다.

LLM Router에서도:

Semantic Router 구현

Cascade 구현

Fallback 구현

보다는:

Baseline Routing 품질 확인

잘못된 Routing Case 분석

Quality / Cost Trade-off 확인

Provider Failure 재현

Fallback 필요성 확인

처럼 작성하는 편이 맞다.

Phase 도달
≠
특정 기술 도입

이기 때문이다.

---

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

세 프로젝트에서 계속 사용했던 방식 중 하나다.

Baseline부터 완성형 구조를 만들지 않는다.

LLM Router의 초기 구조도 가능한 한 단순하게 시작한다.

Request
   ↓
Routing Decision
   ↓
Selected Model
   ↓
LLM
   ↓
Response

초기 목표는:

최고의 Router

가 아니다.

먼저:

Router가 어떤 판단을 했는지 관찰할 수 있는 상태

를 만든다.

그래야 다음 단계에서 실제 문제를 확인할 수 있다.

---

11. 문제는 해결하기 전에 먼저 존재해야 한다

Playback Gate에서는 Lock을 넣기 전에 Race Condition을 직접 재현했다.

BASIC 최대 동시 재생 = 1

40개 동시 요청
↓
ACTIVE Session = 40

Live Event Stream에서도 Consumer Lag과 Duplicate Event를 먼저 재현했다.

ContentOps Agent에서도 Retrieval Failure를 Dataset에서 먼저 확인했다.

이 경험을 이번 프로젝트에도 그대로 가져간다.

예를 들어 Fallback을 넣고 싶다면:

Provider가 실패할 수 있음
↓
Fallback 구현

으로 시작하지 않는다.

먼저:

Provider Failure 재현
↓
현재 Router 동작 확인
↓
실패 영향 측정

을 한다.

문제가 실제로 존재한다는 증거가 기술 도입보다 먼저다.

---

12. Test와 Evaluation을 섞지 않는다

ContentOps Agent에서 가장 중요한 변화 중 하나였다.

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

API가 실행되는가?

Client 호출이 되는가?

DB가 저장되는가?

Model 응답을 받을 수 있는가?

하지만 LLM 기능에서는 이것만으로 부족하다.

LLM Router에서도 마찬가지다.

Router API 성공
≠
적절한 Model 선택

따라서 역할을 나눈다.

Test
→ 코드가 정상적으로 동작하는가

Evaluation
→ Router의 판단이 적절한가

Test가 PASS했다고 Routing 품질이 좋다고 말하지 않는다.

---

13. Evaluation Dataset은 구현보다 먼저 보호한다

ContentOps Agent에서 가장 잘 지킨 것 중 하나는 실패 Query를 지우지 않은 것이다.

Metric을 올리기 위해:

Expected 결과 변경

어려운 Query 삭제

Dataset 수정

을 하지 않았다.

LLM Router에서도 Evaluation Dataset은 Baseline의 일부로 본다.

한 번 Baseline 평가 기준으로 사용한 Dataset을 Routing 구현 결과에 맞춰 임의로 수정하지 않는다.

필요한 변경이 있다면:

왜 변경해야 하는가
↓
기존 평가와 비교 가능한가
↓
Human Gate

를 거친다.

Evaluation이 구현을 따라가면 결국:

내가 만든 Router를
내 Router가 잘하도록 만든 시험으로 평가

하게 되기 때문이다.

---

14. Expected Model 하나만 정답으로 두는 것도 조심한다

LLM Router에서는 평가 방법 자체가 이전과 조금 다르다.

예를 들어 어떤 요청을:

Model A

가 처리할 수도 있고:

Model B

도 충분히 처리할 수 있다.

그런데 Dataset에:

정답 = Model A

만 적어두면 실제 Routing 품질보다 Dataset 작성자의 취향을 측정할 가능성이 있다.

따라서 가능하면:

Expected Model

뿐 아니라:

Quality 조건

Latency 조건

Cost 조건

기능 조건

을 함께 본다.

즉 질문은:

이 요청은 어떤 Model 이름으로 가야 하는가?

보다:

이 요청이 만족해야 할 조건은 무엇인가?

에 가깝다.

---

15. Routing 결과를 관찰할 수 있어야 한다

ContentOps Agent에서는 최종 Answer만 보면 왜 실패했는지 알기 어려웠다.

그래서:

Question
↓
Retriever
↓
Document
↓
Ranking
↓
Tool
↓
Context
↓
Answer

를 추적하려고 했다.

LLM Router도 같은 방식이 필요하다.

최소한:

Input

Routing Feature

Routing Decision

Selected Model

Routing Reason

Model Response

Latency

Input Token

Output Token

Cost

Failure / Fallback

를 확인할 수 있어야 한다.

그래야:

답변이 나빴다

에서 끝나지 않고:

Router가 틀렸는가?

Model이 부족했는가?

Prompt가 문제인가?

Fallback이 문제인가?

를 분리할 수 있다.

---

16. 실패 위치를 먼저 분리한다

ContentOps Agent에서는 RAG 전체를 하나의 Black Box로 평가하지 않았다.

Retrieval Failure

Ranking Failure

Generation Failure

Grounding Failure

Tool Selection Failure

를 나눴다.

LLM Router도 마찬가지다.

예를 들어 최종 답변 품질이 낮을 때 가능한 원인은 여러 개다.

Routing Failure

Model Quality Failure

Prompt Failure

Latency Failure

Cost Inefficiency

Provider Failure

Fallback Failure

따라서:

답변이 나쁨
↓
Routing Algorithm 수정

으로 바로 가지 않는다.

먼저 어느 계층의 실패인지 확인한다.

---

17. Quality, Cost, Latency를 하나의 숫자로 합치지 않는다

ContentOps Agent에서:

Retrieval Hit

Answer 품질

Tool Selection

을 하나의 Accuracy로 묶지 않았던 것과 같은 이유다.

LLM Router에서도:

Quality

Cost

Latency

는 서로 다른 Metric이다.

예를 들어:

Model A

Quality 높음
Cost 높음
Latency 높음

이고:

Model B

Quality 충분
Cost 낮음
Latency 낮음

일 수 있다.

Router의 목적은 반드시 최고 품질 Model을 선택하는 것도 아니고 가장 싼 Model만 선택하는 것도 아니다.

각 Metric을 따로 본 뒤 Trade-off를 결정한다.

---

18. 동일 조건 비교를 유지한다

Playback Gate부터 계속 유지한 원칙이다.

변경
↓
좋아 보임

을 개선이라고 하지 않는다.

가능하면:

동일 Dataset

동일 입력

동일 Model Version

동일 Prompt

동일 환경

동일 평가 기준

을 유지한 상태에서 한 변수를 바꾼다.

예를 들어 Routing Policy를 변경하면서 동시에 Prompt와 Model까지 바꾸면:

무엇 때문에 결과가 달라졌는가?

를 설명하기 어렵다.

이번에도 Experiment는 가능한 한 한 가지 질문에 답하도록 만든다.

---

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

Playback Gate 회고에서 생긴 규칙이다.

처음에는:

redis-cache.md

db-index.md

처럼 작성하려고 했다.

하지만 이 이름에는 이미 정답이 들어가 있다.

그래서:

cache-analysis.md

db-analysis.md

concurrency.md

처럼 문제 중심으로 바꿨다.

ContentOps Agent에서도:

add-bm25

가 아니라:

exact-keyword-retrieval

처럼 가져갔다.

LLM Router에서도:

semantic-router.md

cascade.md

보다:

routing-failure-analysis.md

quality-cost-tradeoff.md

provider-failure.md

처럼 만든다.

Experiment의 목적은 기술을 적용하는 것이 아니라 질문에 답하는 것이기 때문이다.

---

20. 기술 도입의 Gate는 Evaluation이다

이번에도 기술을 먼저 정답으로 두지 않는다.

예를 들어:

Semantic Routing이 더 좋아 보인다.

LLM Router니까 LLM Routing을 써야 한다.

비용 절감을 위해 Cascade가 필요하다.

라는 이유만으로 도입하지 않는다.

흐름은:

Evaluation
   ↓
Failure Case
   ↓
Metric
   ↓
원인
   ↓
후보
   ↓
Human Gate
   ↓
기술 선택

이다.

실패 Case가 없다면:

해당 기술을 안 쓰는 것

도 정상 결과다.

---

21. 사용하지 않은 기술도 결과다

Playback Gate에서는 Redis를 사용하지 않았다.

Live Event Stream에서는 Retry Topic과 Schema Registry를 사용하지 않았다.

ContentOps Agent에서는 Hybrid, RRF, Reranker, LangGraph를 사용하지 않았다.

이 경험을 통해:

사용한 기술

만 프로젝트 결과라고 생각하지 않게 됐다.

다만 표현은 정확해야 한다.

사용하지 않았다

와:

효과가 없었다

는 다르다.

비교 실험을 하지 않았다면 효과가 없었다고 말할 수 없다.

이번 LLM Router에서도 어떤 기술을 최종적으로 사용하지 않는다면:

현재 Dataset과 실패 Case에서는 도입을 정당화할 근거가 충분하지 않았다.

정도로 설명한다.

---

22. Human Gate의 역할도 바뀌었다

처음에는 Human Gate를:

AI 작업
↓
사람 확인

정도로 생각하기 쉽다.

하지만 모든 코드 변경마다 사람이 확인하면 AI를 사용하는 의미가 줄어든다.

그래서 프로젝트를 진행하면서 Human Gate는:

시스템의 의미가 달라지는 결정

에만 두는 쪽으로 바뀌었다.

LLM Router에서는 예를 들어:

Routing 기준 변경

Model 추가 / 제거

Provider 변경

Quality 기준 변경

Cost 기준 변경

Latency 기준 변경

Fallback 정책 변경

Evaluation Dataset 변경

새 Routing 구조 도입

정도다.

DTO나 단순 Test 구현까지 매번 Gate를 열지 않는다.

---

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

ContentOps Agent에서는 Human Gate를 열 때 가능한 한 같은 형식을 사용했다.

현재 Failure Case
        ↓
Metric
        ↓
원인
        ↓
후보
        ↓
장점 / 단점
        ↓
추천안
        ↓
STOP
        ↓
Developer Decision

이번에도 이 형식을 유지한다.

AI가:

Semantic Routing을 적용하는 것이 좋습니다.

라고 말하는 것만으로는 부족하다.

최소한:

어떤 Failure를 해결하려는가?

현재 Metric은 무엇인가?

왜 현재 구조가 원인이라고 보는가?

다른 후보는 무엇인가?

복잡도와 비용은 어떻게 달라지는가?

를 설명해야 한다.

---

24. Human Gate를 줄이는 것이 목표지만 없애는 것이 목표는 아니다

AI 개발에서 사람의 개입이 많으면 전체 속도가 떨어진다.

따라서 반복 가능하고 판단 기준이 명확한 작업은 자동화하거나 AI에게 위임하는 것이 맞다.

하지만:

요구사항

성공 기준

Architecture Trade-off

평가 기준

까지 모두 AI에게 넘기면 프로젝트의 통제권 자체가 사라진다.

따라서 목표는:

Human Gate 제거

가 아니라:

불필요한 Human Gate 감소
+
중요한 Gate의 품질 향상

이다.

---

25. Git은 결과 저장소가 아니라 Experiment History로 사용한다

Playback Gate에서는 프로젝트를 거의 끝낸 뒤 GitHub에 올려서 변화 과정이 잘 보이지 않았다.

Live Event Stream에서는 개선됐지만 일부 문제에서는:

문제 재현
+
해결

이 하나의 Commit에 가까웠다.

그래서 이번에는 규칙을 단순하게 만든다.

문제가 재현된 상태 자체를 하나의 Checkpoint로 Commit한다.

예:

Baseline
↓
Commit

Routing Failure 재현
↓
Commit

해결 방법 적용
↓
Commit

Re-Evaluation
↓
Commit

그러면 최종 코드뿐 아니라:

왜 바뀌었는가?

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

---

26. ADR은 기술을 썼다는 기록이 아니다

ADR도 마찬가지다.

Semantic Router 적용

만 적는 문서가 아니다.

기록해야 하는 것은:

어떤 문제가 있었는가

어떤 Metric에서 확인됐는가

어떤 후보를 비교했는가

왜 이 후보를 선택했는가

무엇을 포기했는가

이다.

즉 ADR은:

기술 이름의 기록이 아니라 판단 과정의 기록

으로 사용한다.

---

27. README는 마지막에 쓰는 소개 문서가 아니다

Playback Gate와 Live Event Stream에서는 README를 프로젝트 후반에 많이 보강했다.

회고에서 계속 아쉬움으로 남았다.

ContentOps Agent에서는 이를 반영해 Phase 1부터 README를 관리했다.

LLM Router에서도 Baseline이 끝났다면 최소한 다음을 README에서 확인할 수 있어야 한다.

프로젝트 목적

실행 방법

환경 변수

Model / Provider 설정

Router 요청 방법

Test 실행 방법

Evaluation 실행 방법

Experiment 위치

현재 알려진 한계

README를:

프로젝트 홍보 문서

가 아니라:

사람과 AI 모두가 Repository에 진입하기 위한 Harness

로 본다.

---

28. Rule과 Skill을 구분한다

Live Event Stream에서는 SKILL.md를 사용했다.

하지만 실제 내용을 회고해보니:

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

문제를 미리 해결하지 않는다.

측정 없이 개선됐다고 하지 않는다.

중요한 변경은 Human Gate를 거친다.

처럼 Skill보다는 Rule에 가까웠다.

그래서 ContentOps Agent에서는 처음부터:

.cursor/rules/

로 시작했다.

이번에도 같은 방식이다.

Rule:

프로젝트 전체에서 항상 지켜야 하는 제약

Skill:

특정 반복 작업을 수행하는 Workflow

로 구분한다.

---

29. 반복 Workflow가 생긴 뒤에 Skill을 만든다

ContentOps Agent에서는:

Evaluation
↓
실패 Query 분류
↓
Metric 계산
↓
Experiment Markdown 작성

이 반복됐다.

하지만 끝까지 별도 Skill로 추출하지 않았다.

회고에서는 이 부분이 다음 프로젝트에서 시도할 수 있는 개선점으로 남았다.

LLM Router에서는 처음부터 Skill을 만들지는 않는다.

대신 실제로:

Routing Evaluation 실행
↓
Expected / Actual 비교
↓
Quality / Cost / Latency 집계
↓
Failure Case 분류
↓
Experiment Markdown 작성

이 반복된다면 그때 Skill 후보로 본다.

Rule
↓
반복 Workflow 발견
↓
Skill 추출

을 이번에는 실제로 적용해볼 수 있다.

---

30. Agent를 만들기 전에 Script로 해결할 수 있는지 본다

Live Event Stream에서는 Graph나 여러 Agent보다 실제로 더 유용했던 것이:

measure.sh

lag-experiment.sh

같은 반복 실험 Script였다.

복잡한 자동화를 위해 Agent를 만들기 전에:

단순 Script

Test

Evaluation Runner

로 충분한지 먼저 본다.

LLM Router에서도 반복 Evaluation은 먼저:

Evaluation Runner

형태로 만드는 것이 자연스럽다.

Agent가 필요해서 Agent를 만드는 것과 Agent를 학습했기 때문에 Agent를 넣는 것은 구분한다.

---

31. Graph와 Multi-Agent는 기본값이 아니다

Playback Gate에서도 Graph를 사용하지 않았다.

Live Event Stream에서도 필요하지 않았다.

ContentOps Agent에서도 LangGraph는 후보였지만 Multi Tool 실패 한 번을 이유로 바로 도입하지 않았다.

세 프로젝트를 거치면서:

Workflow가 복잡하다
=
Graph가 필요하다

는 아니라는 결론이 더 강해졌다.

LLM Router에서도 처음부터:

Request Analyzer Agent
        ↓
Model Selection Agent
        ↓
Quality Review Agent
        ↓
Fallback Agent

를 만들지 않는다.

우선:

Harness
+
Human-controlled Loop
+
필요한 Script

로 진행한다.

명시적인 State와 여러 Loop의 연결이 실제 문제로 확인됐을 때 Graph를 검토한다.

---

32. 정리 — 이번 프로젝트에서 검증하려는 것은 Router만이 아니다

Playback Gate부터 ContentOps Agent까지 진행하면서 프로젝트의 관심 영역은 계속 넓어졌다.

처음에는:

코드가 동작하는가?

를 봤다.

그 다음에는:

실제로 성능이 좋아졌는가?

동시성 정책이 지켜지는가?

Consumer가 부하를 따라가는가?

를 측정했다.

AI 프로젝트에서는:

정답 문서를 찾는가?

근거 있는 답을 하는가?

적절한 Tool을 선택하는가?

까지 Evaluation했다.

LLM Router에서는 여기에 하나의 판단이 더 추가된다.

왜 이 요청을
이 Model로 보냈는가?

그리고 그 선택이:

Quality

Cost

Latency

에 어떤 영향을 주는지 확인한다.

하지만 이번 프로젝트의 또 하나의 목적은 Router 자체만 평가하는 것이 아니다.

Playback Gate부터 쌓아온 개발 방식도 다시 검증한다.

Docs가 실제 Context 역할을 하는가?

Rule이 AI의 선제 구현을 막는가?

ROADMAP이 문제 중심으로 유지되는가?

Evaluation Dataset을 보호할 수 있는가?

Human Gate가 필요한 곳에서만 작동하는가?

Git에서 문제와 해결을 따라갈 수 있는가?

README가 처음부터 진입점 역할을 하는가?

반복 Workflow를 실제 Skill로 추출할 수 있는가?

즉 이번 프로젝트의 전체 Loop는 다음과 같다.

REQUIREMENTS
      ↓
ROADMAP
      ↓
TASK
      ↓
PLAN
      ↓
IMPLEMENT
      ↓
TEST
      ↓
EVALUATE
      ↓
FAILURE CASE
      ↓
ANALYZE
      ↓
후보 비교
      ↓
HUMAN GATE
      ↓
DECIDE
      ↓
IMPLEMENT
      ↓
RE-EVALUATE
      ↓
ADR / DESIGN
      ↓
COMMIT
      ↓
NEXT TASK

그리고 이 과정에서 계속 유지할 기준은 같다.

기술을 사용했다
≠
문제를 해결했다

코드가 동작한다
≠
품질이 좋다

변경했다
≠
개선됐다

복잡한 구조를 만들었다
≠
좋은 설계다

LLM Router를 완성했을 때 목표는:

Semantic Routing을 구현했다.

Cascade를 구현했다.

여러 Model을 연결했다.

라고 말하는 것이 아니다.

대신:

어떤 요청에서 Routing이 실패했고, 어떤 기준으로 원인을 분리했으며, 어떤 후보를 비교했고, 왜 현재 Routing 정책을 선택했고, 그 결과 Quality·Cost·Latency가 어떻게 달라졌는지를 설명할 수 있어야 한다.

그리고 개발 방식 역시:

AI에게 구현 속도는 맡기되, 무엇을 만들고 무엇을 성공으로 판단할지에 대한 통제권은 개발자가 유지한다.

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