모델 진화 시대의 SKIX Agent Engineering 전략
Harness, Context, Loop, Graph 같은 용어가 빠르게 늘고 있다. 이 문서는 이 개념을 모두 도입하기 위한 제안서가 아니다. 모델 성능이 계속 높아지는 상황에서도 SKIX가 무엇을 직접 설계해야 하고, 무엇은 모델에 돌려주며, 무엇은 제거해야 하는지 판단하기 위한 기준이다.
한 문장 결론
SKIX의 방향은 맞다. 다만 목표는 거대한 Agent Framework가 아니라 얇은 의미 계층, 강한 실행 계약, 증거 기반 폐루프, 교체 가능한 모델이다.
이 원칙이 화자·제품 지식·Experience Goal·A2A Planner·TaskManager의 실제 관계로 어떻게 나타나는지는 Experience Goal × Knowledge Graph에서 확인한다.
모델이 좋아질수록 모델 능력을 보충하던 규칙과 분해 장치는 줄여야 한다. 반면 기기 권한, 물리 안전, 현재 상태, 실행 순서, 취소, timeout, 실제 완료 증거와 평가는 모델 성능과 무관한 제품 책임이므로 유지해야 한다.
왜 지금 혼란스러운가
최근의 Harness, Loop, Graph Engineering은 완전히 분리된 표준 기술 계층이나 정해진 성숙도 단계가 아니다. 특히 Loop와 Graph는 아직 하나의 안정된 산업 정의가 확립된 용어라기보다 Agent 시스템의 제어 문제를 설명하는 관점에 가깝다. 따라서 SKIX가 이 이름마다 별도 모듈이나 조직을 만들 필요는 없다.
혼란은 서로 다른 문제를 같은 단어로 부르면서 생긴다.
| 관점 | 실제로 묻는 질문 | SKIX에서 보이는 형태 |
|---|---|---|
| Context | 이번 판단에 어떤 사실을 넣을 것인가 | 발화, 공간, 배터리, 작업, 사용자, freshness |
| Harness | 모델이 일할 환경과 경계를 어떻게 제공할 것인가 | catalog, tool contract, 권한, trace, eval, console |
| Loop | 실행 결과를 보고 언제 계속·중단·복구할 것인가 | callback, terminal evidence, bounded replan |
| Graph | 여러 단계와 결과의 의존관계를 어떻게 표현할 것인가 | typed step, depends_on, condition, output |
| Runtime | 실제 기기 동작을 누가 책임질 것인가 | TaskManager, DeviceAgent, domain executor |
용어 자체보다 이 질문의 소유자가 겹치지 않는 것이 중요하다.
하네스 무용론에서 맞는 부분
강한 모델은 과거에 외부 코드가 대신하던 일을 점차 직접 수행한다.
- 긴 작업을 스스로 분해한다.
- 필요한 파일·정보·도구를 선택한다.
- 중간 결과를 검토하고 다음 행동을 수정한다.
- 단순한 형식 오류와 누락을 자체적으로 복구한다.
- 적은 예시와 짧은 지시로도 도메인 규칙을 일반화한다.
Anthropic은 더 강한 모델에서 기존 sprint 분해 구조를 제거하는 식으로 harness를 단순화했고, 일부 문제는 다음 모델이 해결할 수 있다고 설명한다. Claude의 SWE-bench 구성도 모델 판단을 살리기 위해 Bash와 편집 도구 중심의 최소 scaffold를 선택했다. 이는 고정 분해, 과도한 prompt 규칙, 반복 reflection, 모델별 보정 코드가 영구 자산이 아닐 수 있음을 보여준다.
따라서 다음 요소는 모델 업그레이드 때마다 제거 가능성을 검증해야 한다.
| 감축 후보 | 이유 |
|---|---|
| 발화 표현별 cue와 예외 목록 | 강한 모델의 의미 일반화와 충돌하고 회귀를 만든다. |
| 고정된 사고 단계와 과도한 chain 강제 | 모델이 더 나은 경로를 선택할 자유를 줄인다. |
| 동일 판단을 수행하는 Router·Shadow·Planner 중복 호출 | 비용과 권한 충돌을 늘린다. |
| 매 단계의 self-critique와 무조건 retry | 지연과 토큰을 늘리고 잘못된 행동을 반복할 수 있다. |
| 장황한 전체 context 주입 | 관련 정보 탐색을 방해하고 오래된 상태를 섞는다. |
| 단순 명령까지 Graph·Experience로 승격하는 경로 | 작은 문제를 큰 runtime 문제로 만든다. |
이 의미에서 하네스 무용론은 보상형 하네스의 축소론으로는 타당하다.
그래도 없어지지 않는 부분
모델이 더 똑똑해져도 모델은 기기의 현재 물리 상태, 권한, 자원 충돌과 실제 완료를 스스로 보장하지 못한다. OpenAI는 긴 다단계 작업에서 harness의 상태 보존과 compaction이 관측되는 성능 자체를 바꿀 수 있다고 설명한다. Anthropic의 로봇 실험도 모델이 관절을 직접 제어할 때보다 사전 학습된 controller나 고수준 도구를 감독할 때 성공률이 높음을 보여준다.
즉 다음 항목은 모델 보정물이 아니라 제품 시스템의 책임이다.
| 지속 자산 | 모델이 대신할 수 없는 이유 |
|---|---|
| Capability 계약 | 실제 존재하는 기능, 입력 형식과 허용 범위를 정의한다. |
| 권한과 안전 정책 | 확률적 판단에 모터·보안·개인정보 권한을 위임할 수 없다. |
| State freshness와 provenance | 오래된 위치와 현재 위치를 구분할 사실 소유자가 필요하다. |
| Queue와 resource arbitration | 이동·청정·화면·음성의 동시 실행 충돌을 결정적으로 조정한다. |
| 취소·timeout·preemption | 사용자의 통제권과 장기 작업 수명을 보장한다. |
| Terminal evidence | API 수락과 물리 완료를 구분한다. |
| Trace·eval·replay | 개선인지 회귀인지 재현 가능한 증거가 필요하다. |
| Legacy compatibility | 앱, IoT, PUI와 기존 서비스가 모델 교체와 무관하게 동작해야 한다. |
이것은 두꺼운 AI harness가 아니라 제품 실행 기반이다.
같은 용어 안에서도 없어지는 것과 남는 것
| 개념 | 모델 향상으로 줄어드는 부분 | 제품에서 남는 부분 | SKIX 원칙 |
|---|---|---|---|
| Harness | 분해 prompt, 예외 rule, 모델별 parser 보정 | tool·권한·eval·trace·실행 계약 | Thin Harness |
| Context | 장황한 전문 주입, 중복 history | 최신 상태, 출처, 권한 범위 | Compact State Snapshot |
| Loop | 매 단계 LLM reflection | event 기반 실행·검증·중단 | Event-driven Bounded Loop |
| Graph | 모델 사고 과정을 고정한 reasoning graph | 실제 task 의존성·조건·결과 lineage | Typed Execution Graph |
| Multi-agent | 역할극 형태의 무조건 분업 | 서로 다른 권한·데이터·runtime의 명확한 owner | Necessary Ownership Only |
핵심 구분은 다음과 같다.
Reasoning을 보조하는 구조
-> 모델이 좋아지면 축소 가능
제품의 상태·권한·실행·증거를 소유하는 구조
-> 모델이 좋아져도 유지
현재 SKIX의 위치
현재 문서화된 구조는 단순 챗봇보다 앞서 있지만 범용 자율 시스템은 아니다.
| 영역 | 현재 위치 | 판단 |
|---|---|---|
| Router·Planner | owner와 typed step을 만들고 일부 catalog에 grounding | 필요하지만 중복 authority는 줄여야 한다. |
| TaskManager | queue, workflow, 상태, callback, timeout의 실행 기반 | 가장 보존 가치가 높은 결정론적 Core다. |
| DeviceAgent | 실제 domain 기능과 기기 상태의 사실 소유자 | capability와 evidence coverage를 넓혀야 한다. |
| Experience Goal | 여러 task 뒤에도 상위 결과를 보존하는 sidecar | 제한된 장면에서 실증 후 확장해야 한다. |
| Eval·Console·Trace | route, plan, request와 event를 관찰 | 제품 harness로 유지하되 자동 회귀 판정을 강화해야 한다. |
| Rule·cue | 의미 경계를 보정하는 과도기 장치 | 모델 업그레이드마다 삭제 실험이 필요하다. |
방향이 잘못되는 시점은 TaskManager를 만든 때가 아니다. 다음과 같은 경우다.
- Experience가 기존 Planner와 별도의 만능 Planner가 될 때
- 정상 progress callback마다 LLM을 호출할 때
- capability와 terminal evidence 없이 Graph node만 늘릴 때
- 실패 원인을 계약으로 고치지 않고 발화별 rule로 가릴 때
- 단순 실행까지 장기 Goal로 승격할 때
- 용어와 문서 수가 늘었지만 사용자 성공률은 측정하지 않을 때
권장 목표 구조
SKIX는 다섯 책임으로 압축한다.
Meaning Owner
Router / Planner가 목표, owner와 필요한 effect를 결정
Typed Plan
단계, 의존관계, 조건, 입력과 기대 evidence를 표현
Execution Kernel
TaskManager / DeviceAgent가 policy, queue와 실제 실행을 소유
Evidence Loop
callback과 현재 상태로 continue, complete, fail을 판정
Evaluation Harness
전체 경로를 replay, 비교, 추적하고 회귀를 차단
Experience Supervisor는 여섯 번째 상시 실행 계층이 아니다. 여러 task 뒤에도 상위 목표가 남고, 실패 이후 의미 판단이 다시 필요한 경우에만 활성화되는 제한된 감독 기능이다.
효율성을 위한 계층 상승 원칙
요청마다 처음부터 가장 복잡한 경로를 사용하지 않는다.
| 단계 | 적용 조건 | 기본 처리 |
|---|---|---|
| L0 · Direct | 단일하고 명확하며 위험이 낮은 실행 | 기존 owner와 deterministic API |
| L1 · Grounded Tool | 하나의 판단과 도구 호출로 충분 | 단일 모델 호출과 schema validation |
| L2 · Typed Workflow | 여러 단계, 순서, 대기 조건이 존재 | Planner 1회 + TaskManager 로컬 실행 |
| L3 · Bounded Replan | 실패·차단·상태 모순으로 기존 plan이 무효 | 의미 경계에서 최대 제한 횟수 재계획 |
| L4 · Experience | 장시간·다중 Agent 결과를 상위 목표로 평가 | 명시 admission과 사용자 통제 아래 실행 |
하위 단계로 해결할 수 있으면 상위 단계로 올리지 않는다. 이 원칙이 모델 호출, 토큰, 지연, 장애면과 디버깅 비용을 동시에 줄인다.
모델 업그레이드에 대응하는 감산형 개발
새 모델을 도입할 때 기존 harness를 그대로 유지한 채 점수만 비교하면 안 된다. 강한 모델 위에 과거 모델의 보정 장치를 모두 남기면 비용과 제약만 누적된다.
모델별 검증은 다음 순서로 수행한다.
- 현재 구조와 신규 모델의 기준 성능을 측정한다.
- cue, 고정 분해, 중복 retry를 하나씩 제거한다.
- 단순 prompt와 최소 도구 구성으로 다시 측정한다.
- 안전·권한·terminal evidence는 제거 실험 대상에서 제외한다.
- 성공률을 유지하면서 토큰·지연·복잡도를 줄인 최소 구성을 채택한다.
이를 Harness Ablation이라고 관리한다.
| 판정 | 조치 |
|---|---|
| 제거해도 성공·안전·오완료가 악화되지 않음 | 삭제한다. |
| 특정 모델에서만 필요 | model adapter 또는 profile로 격리한다. |
| 모든 모델에서 반복적으로 필요 | domain contract나 tool 설계 문제인지 먼저 본다. |
| 물리 안전·권한·감사에 필요 | hard invariant로 유지한다. |
| 효과를 측정할 수 없음 | 기본값은 추가하지 않는 것이다. |
측정해야 할 성능
Router accuracy 하나로는 이 구조의 가치를 판단할 수 없다.
| 축 | 지표 |
|---|---|
| 목표 달성 | goal success, task success, recovery success |
| 정확한 종료 | false completion, stale-state decision, duplicate execution |
| 사용자 부담 | 재명령률, 확인 turn 수, 취소 성공률 |
| 실행 품질 | timeout, queue wait, callback 누락, terminal evidence coverage |
| AI 효율 | model calls/goal, input·output token/goal, P50·P95 latency |
| 구조 비용 | rule 수, prompt 크기, graph node 수, model-specific adapter 수 |
| 운영성 | trace 재현률, 실패 reason coverage, rollback 시간 |
모델 성능 향상은 AI 효율과 일부 목표 달성을 개선한다. 제품 구조는
정확한 종료, 실행 품질, 사용자 통제와 운영성을 책임진다.
다음 의사결정 실험
먼저 세 장면만 기준으로 삼는다.
| 장면 | 확인할 구조 | 핵심 실패 |
|---|---|---|
| 이동 → 청정 → 복귀 | Typed Workflow + TaskManager | 단계 누락, 조기 완료, callback 누락 |
| 현재 상태 확인 → 조건 실행 | Context + Evidence Loop | stale state, 조건 오판, 불필요한 LLM 호출 |
| 실행 실패 → 대안 또는 질문 | Bounded Replan | 무한 retry, 의미 없는 재계획, 통제권 상실 |
각 장면에서 다음 구성을 비교한다.
A. 현재 모델 + 현재 harness
B. 강한 모델 + 현재 harness
C. 강한 모델 + 감축 harness
D. 강한 모델 + 감축 harness + 결정론적 실행 계약
목표는 D가 가장 복잡해지는 것이 아니다. C로 충분하면 C를 선택한다. D는 물리 실행과 장기 상태 때문에 필요한 부분에만 남긴다.
당분간 만들지 않을 것
- 모든 발화를 처리하는 범용 Graph runtime
- 기능 이름만 다른 다수의 Agent 역할
- 정상 callback마다 실행되는 LLM Supervisor
- 자유 형식 plan을 그대로 DeviceAgent에 전달하는 구조
- 실제 evidence가 없는 자율 복구 시나리오
- 성능 비교 없이 추가되는 발화별 cue와 예외
- 범용 Agent Platform이라는 과도한 제품 주장
실행 로드맵
전략을 실제 운영으로 전환하는 두 개의 companion 문서를 함께 사용한다.
| 운영 문서 | 역할 |
|---|---|
| Harness 구성요소 원장과 감축 관리 | cue, prompt, repair, retry, contract와 eval을 분류하고 keep·simplify·isolate·retire를 관리 |
| 모델 교체 Ablation과 승격 플레이북 | 기존·신규 모델과 기존·감축 harness를 분리 비교하고 제품 Gate와 rollback을 관리 |
| 로보틱스 제어에서 Harness 구조의 타당성 | LLM·Action runtime·domain controller·physical safety의 시간 주기와 권한을 분리 |
1 · 책임과 용어 고정
owner, plan, task, evidence, goal의 단일 소유자를 정하고 중복 authority를
표시한다. 새 개념은 기존 책임으로 표현할 수 없을 때만 추가한다.
2 · Harness 원장 작성
현재 prompt rule, cue, retry, shortcut, parser, context field를 나열하고 각각을
안전 invariant, 도메인 계약, 모델 보정, 관측 도구로 분류한다.
3 · 모델 교체 및 감산 실험
동일 holdout과 세 대표 E2E 장면으로 모델과 harness를 독립 변수로 비교한다. 성능을 유지하는 최소 구성을 기준선으로 고정한다.
4 · 실행 증거 우선 보강
새 Agent보다 capability별 terminal event, cancel, timeout, freshness와 reason coverage를 먼저 닫는다.
5 · Experience 제한 확장
일반 명령 회귀, 토큰 예산, false admission과 사용자 통제 기준을 통과한 장면만 shadow에서 live로 올린다.
최종 판단
모델 발전은 SKIX 구조를 무효화하지 않는다. 오히려 모델이 담당할 부분과 제품이 책임질 부분을 더 명확하게 분리할 기회다.
앞으로의 경쟁력은 복잡한 harness의 크기에서 나오지 않는다. 강한 모델을 빠르게 교체할 수 있고, 불필요한 보정은 지울 수 있으며, 어떤 모델을 사용해도 기기가 안전하고 설명 가능하게 실행되는 구조에서 나온다.
SKIX가 유지할 기준은 다음과 같다.
모델에게는 의미와 선택의 자유를 주고, 제품에는 상태·권한·실행·증거의 책임을 남긴다.
로보틱스 제어에서도 이 원칙은 유효하다. 모델이 향상될수록 고수준 Goal 해석과 capability 조합은 더 자유롭게 할 수 있지만, Action lifecycle, feedback, cancel, local controller, physical safety와 terminal evidence는 더 엄격해야 한다. 상세 경계는 로보틱스 제어에서 SKIX Harness 구조의 타당성에서 다룬다.
내부 연결 문서
- Harness 구성요소 원장과 감축 관리
- 모델 교체 Ablation과 승격 플레이북
- 로보틱스 제어에서 SKIX Harness 구조의 타당성
- A2A System Overview
- Planner Deep Dive
- Experience Goal Existing Planner Integration
- TaskManager 기준 사양서
- A2A Success Criteria
- Planner Research Reading List
외부 근거
- Anthropic, Building effective agents: 단순하고 조합 가능한 패턴부터 시작하고 복잡성은 필요할 때만 추가한다.
- Anthropic, Harness design for long-running application development: 강한 모델에 맞춰 기존 scaffold를 제거하는 감산 실험과 harness의 새로운 확장 가능성을 함께 설명한다.
- Anthropic, Claude SWE-bench performance: 모델 판단을 살리는 최소 scaffold 접근을 설명한다.
- Anthropic, Effective context engineering for AI agents: 다중 turn Agent에서 context를 지속적으로 정제해야 하는 이유를 설명한다.
- OpenAI, Harness engineering: Agent가 환경을 읽고 검증할 수 있도록 도구·로그·구조를 노출하고 invariant를 강제하는 방식을 설명한다.
- OpenAI, Trustworthy third-party evaluations: 긴 다단계 작업에서 harness 선택이 관측 성능을 바꿀 수 있음을 설명한다.
- Anthropic, How Claude performs on robotics tasks: 모델의 고수준 판단과 사전 학습된 controller·도구의 결합이 직접 저수준 제어보다 유리한 근거를 제공한다.
- AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents: 모델·harness·환경을 하나의 실행 시스템으로 보는 연구 관점을 제시한다.
- Context, Loop and Graph Engineering: 최근 용어가 유용한 관점이지만 아직 공식 표준이나 안정된 단일 정의는 아님을 명시한다.