AI가 분석한 글이지만, 인사이트가 있어서 대충 수정해서 올림.
아래 내용과도 연관 되어 있음.
LLM 시대를 예측한 Peter Norvig의 다음 예측
-----------------------------------------------------------
Harness Engineering, self-improving agent 뿐만 아니라, trace → eval → judge → regression → patch로 이어지는 운영 시스템임.
1. 왜 지금 “하네스”인가
최근 AI 개발 흐름을 보면 “좋은 프롬프트를 쓰는 법”에서 “좋은 하네스를 만드는 법”으로 무게중심이 이동하고 있다. 여기서 하네스란 모델 바깥에서 모델을 실제 작업 가능한 에이전트로 만드는 모든 시스템을 뜻한다. LangChain은 이를 간단히 “Agent = Model + Harness”라고 표현한다. 하네스에는 시스템 프롬프트, 도구, 스킬, MCP, 파일시스템, 샌드박스, 브라우저, 메모리, 서브에이전트, 모델 라우팅, 미들웨어, 검증기, 피드백 루프가 포함된다. (LangChain)
OpenAI의 “Harness Engineering” 글은 이 전환을 가장 강하게 보여준다. OpenAI 팀은 내부 베타 제품을 만들면서 “수동 작성 코드 0줄”이라는 제약을 걸었고, Codex가 애플리케이션 로직, 테스트, CI 설정, 문서, 관측 도구까지 작성했다고 설명한다. 핵심은 “사람이 코드를 덜 썼다”가 아니다. OpenAI가 명시한 진짜 변화는 엔지니어의 일이 직접 코딩에서 환경 설계, 의도 명세, 피드백 루프 구축으로 이동했다는 점이다. (OpenAI)
이 관점에서 보면 하네스 엔지니어링은 새로운 이름을 붙인 프롬프트 엔지니어링이 아니다. 하네스는 모델이 일할 수 있는 환경이다. 좋은 신입 개발자에게도 코드베이스, 테스트, 리뷰 규칙, 배포 파이프라인, 장애 로그가 필요하듯이, 좋은 모델에게도 작업 환경, 제약, 도구, 검증기, 피드백이 필요하다. OpenAI는 같은 글에서 초기에는 Codex가 능력이 부족해서 느렸던 것이 아니라, 환경이 덜 명세되어 있었기 때문에 느렸다고 말한다. 실패할 때마다 “더 열심히 해”가 아니라 “어떤 능력이 빠졌고, 그것을 에이전트가 읽고 따를 수 있게 어떻게 만들 것인가?”를 물었다는 점이 중요하다. (OpenAI)
Anthropic도 같은 방향을 보고 있다. Anthropic의 long-running agent 글은 Claude Agent SDK를 “도구를 사용해 컨텍스트를 모으고, 계획하고, 실행하는 범용 agent harness”로 설명하면서, 단순한 context compaction만으로는 장기 작업을 안정적으로 완수하기 어렵다고 말한다. 그래서 initializer agent와 coding agent를 분리하고, 다음 세션을 위해 명확한 artifact를 남기는 구조를 제안한다. (Anthropic)
즉, 지금의 변화는 단순하다.
모델의 지능은 계속 올라간다.
하지만 실제 성능은 모델 단독이 아니라 모델을 둘러싼 실행 시스템에서 나온다.
2. 하네스 엔지니어링 다음은 무엇인가
내가 보는 다음 단계는 “자기개선 에이전트”가 아니다. 더 정확히는 eval-gated self-improving harness, 즉 평가로 통제되는 자기개선 하네스다.
자기개선이라는 말은 위험하게 들릴 수 있다. 실제로 프롬프트를 에이전트가 마음대로 바꾸고, 그 결과를 “개선”이라고 부르면 금방 망가진다. 다음 세대 하네스의 핵심은 자율성이 아니라 검증 가능한 개선 루프다.
구조는 다음과 같다.
production trace
실제 사용 중 무슨 일이 일어났는가?
↓
failure taxonomy
왜 실패했는가? 어떤 유형의 실패인가?
↓
golden / regression set
다시는 같은 실패가 반복되지 않도록 테스트로 만들었는가?
↓
calibrated judge
그 테스트를 믿을 수 있게 채점하는가?
↓
harness change
프롬프트, 도구, 컨텍스트, 라우팅, 메모리, 검증기를 바꾼다
↓
eval gate
기존 기능이 깨지지 않았는지 확인한다
↓
deploy or rollback
OpenAI의 Agent Improvement Loop cookbook은 이 구조를 거의 그대로 보여준다. 이 예제는 실제 trace를 수집하고, human feedback과 model feedback을 붙이고, 그 피드백을 재실행 가능한 Promptfoo eval로 바꾼 뒤, HALO가 다음 하네스 변경 후보를 랭킹하고 Codex가 구현할 수 있는 handoff를 만든다. OpenAI는 여기서 하네스를 “instructions, tools, routing, output requirements, validation checks를 포함하는 모델 바깥의 전체 계약”으로 정의한다. (OpenAI 개발자)
이 말은 중요하다. 하네스의 다음은 “더 긴 시스템 프롬프트”가 아니다. 하네스의 다음은 실패를 재사용 가능한 테스트로 바꾸고, 테스트를 통과한 변경만 채택하는 운영 루프다.
3. Production trace: 모든 개선의 원자료
AI 앱이나 에이전트를 개선하려면 먼저 실제로 무엇이 일어났는지 알아야 한다. 이때 필요한 것이 production trace다.
에이전트 시대의 trace는 단순한 input → output 로그가 아니다. Anthropic은 agent eval에서 transcript, trace, trajectory를 “trial 전체 기록”으로 정의한다. 여기에는 출력, 도구 호출, 중간 결과, 추론 과정, 상호작용이 포함된다. 또 outcome은 최종 답변이 아니라 환경의 최종 상태다. 예를 들어 항공권 예약 에이전트가 “예약했습니다”라고 말하는 것보다 실제 SQL 데이터베이스에 예약이 생겼는지가 outcome이다. (Anthropic)
따라서 좋은 trace에는 최소한 다음 정보가 있어야 한다.
{
"trace_id": "tr_...",
"timestamp": "2026-05-14T...",
"app_version": "web@1.8.3",
"harness_version": "agent_harness@0.12.0",
"prompt_version": "support_prompt@2026-05-10",
"model": {
"provider": "openai | anthropic | openrouter | local",
"model_id": "gpt-5.5 | claude | gemini | ...",
"temperature": 0.2,
"router_policy": "primary-fallback"
},
"spans": [
{
"type": "retrieval",
"query": "...",
"doc_ids": ["policy_v3.md", "faq_12.md"],
"scores": [0.82, 0.71]
},
{
"type": "llm_call",
"input_tokens": 4200,
"output_tokens": 620,
"latency_ms": 3100
},
{
"type": "tool_call",
"tool": "refund.create",
"args_schema_version": "v3",
"status": "error",
"error_type": "invalid_amount"
}
],
"final_output": "...",
"outcome_state": {
"ticket_status": "resolved",
"refund_status": "not_created"
},
"user_feedback": {
"thumb": "down",
"comment": "정책 설명이 틀림"
},
"failure_labels": [
"policy_misinterpretation",
"tool_args_invalid"
]
}
OpenTelemetry도 GenAI observability를 위해 agent 호출, LLM chat span, tool execution span을 trace tree로 기록하는 방향을 제시하고 있다. 2026년 5월 공개된 OpenTelemetry 글은 VS Code Copilot 예시에서 top-level invoke_agent span 아래에 chat span과 execute_tool span이 붙는 구조를 보여준다. (OpenTelemetry)
여기서 중요한 점은 trace가 단순한 관측 데이터가 아니라는 것이다. trace는 나중에 regression test로 승격될 수 있는 씨앗이다. LangSmith는 production failure를 발견한 뒤 해당 trace를 dataset에 추가하고, 그 dataset을 regression testing의 ground truth로 만들 수 있다고 설명한다. 즉, 한 번 고친 버그가 다시 깨지지 않게 만드는 loop가 trace에서 시작된다. (LangChain)
4. Failure taxonomy: “나빴다”를 “고칠 수 있다”로 바꾸는 언어
trace를 많이 모아도 실패를 분류하지 않으면 개선은 느리다. “답변이 별로였다”, “환각이 있었다”, “도구 호출이 이상했다” 정도의 라벨은 충분하지 않다. 좋은 하네스는 실패를 원인별로 나눈다.
예를 들어 고객지원 에이전트가 환불 정책을 틀리게 설명했다고 하자. 표면 증상은 “정책 설명 오류”지만, 가능한 원인은 여러 가지다.
- retrieval이 잘못된 문서를 가져왔다.
- 올바른 문서를 가져왔지만 context ranking이 낮았다.
- 정책 문서 버전이 오래됐다.
- 모델이 문서를 읽었지만 예외 조건을 잘못 해석했다.
- 도구 호출 없이 답변하면 안 되는 케이스였는데 그냥 답했다.
- judge가 실제로 맞는 답을 fail로 채점했다.
따라서 failure taxonomy는 surface symptom이 아니라 root cause 중심이어야 한다.
실전에서는 다음 정도의 taxonomy로 시작할 수 있다.
intent_misread:
description: 사용자의 실제 의도나 제약을 잘못 파악함
retrieval_miss:
description: 필요한 문서를 검색하지 못함
context_stale:
description: 오래된 문서, 오래된 메모리, 오래된 정책을 사용함
memory_contamination:
description: 이전 대화나 사용자 상태가 현재 작업을 오염시킴
planning_error:
description: 불가능하거나 비효율적인 계획을 세움
tool_selection_wrong:
description: 잘못된 도구를 선택함
tool_args_invalid:
description: 올바른 도구를 골랐지만 인자 형식이나 값이 틀림
unsafe_action:
description: 승인 없이 부작용 있는 행동을 수행함
hallucination:
description: 근거 없는 사실을 생성함
missing_required_info:
description: 반드시 포함해야 할 정보를 누락함
cost_loop:
description: 불필요한 반복, 검색, 도구 호출로 비용과 시간이 증가함
judge_error:
description: 평가기 또는 rubric이 잘못 채점함
이 taxonomy는 단순한 분석용 표가 아니다. 자기개선 하네스의 입력 언어가 된다. 예를 들어 최근 실패의 40%가 retrieval_miss라면 프롬프트를 고칠 게 아니라 retriever, reranker, chunking, freshness policy를 봐야 한다. 실패의 30%가 tool_args_invalid라면 tool schema, 예시, validator, preflight check가 우선이다.
5. Golden set과 regression set: 제품 품질의 계약서
하네스가 자기개선하려면 무엇이 “개선”인지 판단할 기준이 필요하다. 그 기준이 golden set과 regression set이다.
Braintrust는 golden dataset을 특정 use case에서 “what good looks like”를 정의하는 curated, high-quality eval dataset으로 설명한다. 좋은 golden set은 크기보다 대표성과 검증된 expected output이 중요하며, 핵심 use case와 known edge case를 포함해야 한다. (Braintrust)
DeepEval도 dataset을 goldens의 collection으로 정의하고, 평가 시점에는 golden을 test case로 변환해 eval을 실행한다고 설명한다. (DeepEval)
Golden set과 regression set은 다르다.
golden set:
우리 제품이 반드시 잘해야 하는 대표 시나리오
regression set:
과거에 실패했으므로 다시는 깨지면 안 되는 시나리오
처음부터 1000개짜리 dataset을 만들 필요는 없다. 오히려 작고 날카로운 30~50개가 더 낫다.
10개: 핵심 happy path
10개: 비즈니스 가치가 큰 케이스
10개: 실제 production 실패
10개: edge / ambiguous case
5개: safety / policy case
5개: cost / latency / tool-loop case
중요한 것은 평균 점수가 아니라 slice별 점수다.
전체 pass rate: 91%
이 숫자만 보면 안 된다. 진짜 중요한 것은 아래다.
refund / Korean / delivered_order: 62%
refund / English / delivered_order: 89%
policy-sensitive / Korean: 58%
tool_arg_validity: 98%
groundedness: 73%
AI 제품은 전체 평균이 좋아지면서 특정 slice가 깨지는 경우가 많다. 그래서 golden item에는 반드시 task_type, failure_label, slice, priority, expected_behavior, required_tools, forbidden_tools 같은 metadata가 있어야 한다.
예시는 다음과 같다.
{
"id": "support_refund_042",
"dataset": "regression",
"source": "production_trace",
"source_trace_id": "tr_abc123",
"task_type": "support_agent",
"input": {
"messages": [
{
"role": "user",
"content": "부분 환불 가능한가요? 이미 배송은 받았어요."
}
],
"user_state": {
"order_status": "delivered",
"country": "KR"
}
},
"expected_behavior": {
"must_include": [
"부분 환불 가능 조건",
"배송 완료 후 예외 조건",
"정책 문서 근거"
],
"must_not_include": [
"무조건 전액 환불 가능",
"정책에 없는 보상 약속"
],
"required_tools": [
"policy.search",
"order.lookup"
],
"forbidden_tools": [
"refund.create_without_confirmation"
]
},
"failure_labels": [
"policy_misinterpretation",
"missing_tool_call"
],
"slices": [
"refund",
"korean",
"delivered_order",
"policy_sensitive"
],
"priority": "critical"
}
이런 구조가 있어야 하네스 변경이 실제로 좋아졌는지 판단할 수 있다.
6. Calibrated judge: LLM-as-judge를 믿기 위한 조건
LLM-as-judge는 필요하다. 하지만 judge를 그대로 진실로 믿으면 안 된다.
OpenAI의 eval best practices는 eval-driven development, task-specific eval, logging, automated scoring, continuous process, human feedback calibration을 권한다. 동시에 vibe-based eval, production traffic을 반영하지 않는 biased dataset, human feedback 없이 자동 metric만 쓰는 방식을 anti-pattern으로 지적한다. (OpenAI 개발자)
LangSmith도 비슷하게 deterministic check, LLM-as-judge, human annotation을 조합해야 한다고 말한다. 특히 production failure를 regression test로 바꾸는 operational workflow가 단순한 judge prompt 설계보다 중요하다고 본다. (LangChain)
실전 judge stack은 아래처럼 계층형이어야 한다.
1. deterministic check
- JSON valid?
- required field 있음?
- forbidden phrase 없음?
- required tool 호출함?
- forbidden tool 호출 안 함?
2. state / execution check
- DB state가 맞음?
- unit test 통과?
- file diff가 expected와 일치?
- browser flow가 성공?
3. reference-grounded check
- retrieved context와 답변이 일치?
- citation이 맞음?
- 정책 문서와 충돌 없음?
4. LLM judge
- helpfulness
- tone
- instruction following
- hallucination risk
- multi-turn coherence
- trajectory quality
5. human calibration
- judge가 틀린 샘플 수집
- rubric 수정
- few-shot judge examples 추가
- judge-human agreement 추적
Promptfoo는 CI/CD에서 prompt quality, security vulnerability, quality gate, cost tracking을 자동화할 수 있다고 설명한다. 즉 eval은 실험실에서 한 번 돌리는 것이 아니라 PR, 배포, 보안 점검에 붙어야 한다. (promptfoo.dev)
내가 추천하는 judge 출력은 1~10점이 아니라 pass / fail / unsure다.
{
"task_success": "pass | fail | unsure",
"groundedness": "pass | fail | unsure",
"tool_use": "pass | fail | unsure",
"severity": "none | minor | critical",
"rationale": "짧은 근거"
}
너무 세밀한 점수는 judge noise에 약하다. 반면 binary 또는 ternary 판정은 CI gate에 붙이기 쉽고, human review queue로 넘기기도 쉽다.
7. 연구 흐름: Meta-Harness, AutoHarness, ACE
하네스의 다음을 이해하려면 최근 연구 세 가지를 봐야 한다.
첫 번째는 Meta-Harness: End-to-End Optimization of Model Harnesses다. 이 논문은 LLM 시스템 성능이 모델 weight뿐 아니라 “무엇을 저장하고, 검색하고, 모델에게 보여줄지 결정하는 harness code”에 크게 의존한다고 본다. Meta-Harness는 agentic proposer가 이전 후보들의 source code, scores, execution traces를 파일시스템에서 읽고 다음 harness code를 제안하는 outer-loop system이다. 논문은 text classification에서 기존 context management system보다 7.7점 개선하면서 context token을 4배 적게 썼고, RAG math reasoning에서는 held-out 5개 모델 평균 4.7점 개선, TerminalBench-2에서는 hand-engineered baseline을 넘었다고 보고한다. (arXiv)
두 번째는 AutoHarness다. AutoHarness는 Gemini-2.5-Flash가 환경 피드백을 받아 code harness를 자동 합성하는 방식이다. 논문은 TextArena의 145개 게임에서 illegal move를 막는 harness를 만들었고, 그 결과 작은 Gemini-2.5-Flash가 더 큰 Gemini-2.5-Pro보다 나은 평균 보상을 냈다고 보고한다. (OpenReview)
세 번째는 Agentic Context Engineering, ACE다. ACE는 context를 고정 prompt가 아니라 계속 진화하는 playbook으로 본다. 이 논문은 context collapse와 brevity bias를 문제로 보고, Generator, Reflector, Curator를 통해 context를 누적·반성·정리하는 구조를 제안한다. 논문은 agent benchmark에서 +10.6%, finance benchmark에서 +8.6% 개선을 보고하며, labeled supervision 없이 execution feedback으로 context를 개선할 수 있다고 설명한다. (arXiv)
이 세 흐름을 합치면 다음 인사이트가 나온다.
다음 세대 하네스는 사람이 직접 짜는 wrapper가 아니라,
trace와 eval을 읽고 스스로 개선 후보를 생성하는 시스템이 된다.
다만 자기개선에는 리스크가 있다. “Your Agent May Misevolve” 논문은 self-evolving agent가 model, memory, tool, workflow 경로에서 의도치 않게 나쁜 방향으로 진화하는 misevolution 위험을 지적한다. 예를 들어 memory accumulation이 safety alignment를 약화하거나, tool creation/reuse 과정에서 취약점이 생길 수 있다고 보고한다. (arXiv)
또 “Do Self-Evolving Agents Forget?”은 lifelong adaptation 과정에서 새로운 task distribution에 적응하다가 기존 능력이 저하되는 문제를 다룬다. (arXiv)
따라서 자기개선 하네스의 핵심은 “스스로 바꾼다”가 아니다.
핵심은 스스로 바꾸되, regression gate를 통과하지 못하면 버린다이다.
8. 표준 substrate: MCP, Skills, AGENTS.md, OpenTelemetry
하네스의 다음을 준비하려면 표준 substrate도 봐야 한다.
MCP는 AI application이 외부 시스템에 연결하기 위한 open-source standard다. 공식 문서는 MCP를 AI 앱을 위한 USB-C에 비유하며, Claude나 ChatGPT 같은 AI 앱이 local files, databases, search engines, calculators, workflows에 연결될 수 있게 한다고 설명한다. (Model Context Protocol)
Agent Skills는 instruction, script, resource를 묶은 portable package다. Microsoft 문서는 Skills가 progressive disclosure pattern을 따른다고 설명한다. 즉 에이전트가 모든 지식을 항상 context에 넣는 것이 아니라, 필요할 때 필요한 skill만 load한다. (Microsoft Learn)
AGENTS.md는 coding agent를 위한 README 같은 open format이다. 공식 페이지는 AGENTS.md를 agent에게 프로젝트 context와 instruction을 제공하는 dedicated, predictable place라고 설명하고, 6만 개 이상의 open-source project에서 사용된다고 말한다. (Agents)
OpenAI도 Agents SDK 업데이트에서 MCP, skills, AGENTS.md, shell, apply_patch 같은 primitive를 agentic system의 공통 구성요소로 묶었다. 업데이트된 Agents SDK는 파일을 읽고, 명령을 실행하고, 코드를 편집하고, long-horizon task를 controlled sandbox 안에서 수행하게 하는 model-native harness와 native sandbox execution을 제공한다고 설명한다. (OpenAI)
Linux Foundation 산하 Agentic AI Foundation도 이 흐름을 강화한다. Linux Foundation은 Anthropic의 MCP, Block의 goose, OpenAI의 AGENTS.md를 founding contributions로 받아 AAIF를 출범시켰다고 발표했다. OpenAI도 AAIF가 agentic AI가 실험에서 production으로 이동하는 과정에서 open, interoperable infrastructure를 위한 neutral stewardship을 제공한다고 설명한다. (Linux Foundation)
여기서 중요한 결론은 다음이다.
미래의 하네스는 특정 벤더 SDK 하나가 아니라,
MCP + Skills + AGENTS.md + sandbox manifest + trace schema + eval gate의 조합으로 구성될 가능성이 크다.
9. Agent OS와 control plane
하네스가 성숙하면 다음 병목은 “에이전트 하나를 어떻게 잘 실행할까?”가 아니라 “여러 에이전트 실행을 어떻게 운영할까?”가 된다.
OpenAI Symphony는 이 전환을 보여준다. Symphony는 Linear 같은 project-management board를 coding agents의 control plane으로 바꾸는 agent orchestrator다. OpenAI는 여러 Codex 세션을 사람이 직접 관리하는 방식은 3~5개 세션을 넘으면 context switching이 병목이 된다고 설명한다. Symphony는 open task를 agent workspace와 연결하고, task board를 state machine으로 사용해 agent가 작업하고, PR을 만들고, 인간이 결과를 리뷰하게 한다. 일부 OpenAI 팀에서는 Symphony 도입 후 첫 3주 동안 landed PR 수가 500% 증가했다고 보고했다. 단, 이 수치는 OpenAI 내부 일부 팀의 결과이므로 일반화해서 받아들이기보다 “agent work management가 병목이 될 수 있다”는 신호로 보는 것이 안전하다. (OpenAI)
이 방향에서 하네스는 점점 Agent OS처럼 변한다.
issue 생성
↓
agent run 할당
↓
worktree / sandbox 생성
↓
implementation
↓
tests / eval
↓
reviewer agent
↓
human approval
↓
PR merge
↓
production trace
↓
regression 추가
즉 다음 세대 하네스의 경쟁력은 agent loop 자체보다 control plane에 있다. 어떤 agent가 어떤 task를 맡는지, 어떤 sandbox에서 실행되는지, 어떤 trace를 남기는지, 어떤 eval gate를 통과해야 merge되는지가 중요해진다.
10. 보안: tool layer와 MCP layer가 새로운 공격면이 된다
하네스가 도구, 브라우저, 파일시스템, MCP server, shell을 붙이기 시작하면 공격면은 크게 넓어진다.
Anthropic은 browser agent에서 prompt injection이 가장 중요한 보안 문제 중 하나라고 설명한다. agent가 웹을 탐색할 때는 웹페이지, 문서, 광고, 동적 스크립트 등 untrusted content를 처리하며, 그 안에 agent를 속이기 위한 악성 지시가 숨어 있을 수 있다. Anthropic은 prompt injection이 browser-based AI agents의 가장 중요한 보안 과제 중 하나이며, 문제가 해결된 상태가 아니라고 말한다. (Anthropic)
MCP도 마찬가지다. MCP threat modeling 논문은 MCP가 AI assistant와 외부 tool/data source를 연결하는 universal standard로 빠르게 부상했지만, client-side security vulnerability를 도입한다고 분석한다. 특히 tool metadata 안에 악성 instruction을 심는 tool poisoning이 가장 흔하고 영향력 있는 취약점이라고 보고하며, static metadata analysis, model decision path tracking, behavioral anomaly detection, user transparency를 포함한 multi-layer defense를 제안한다. (arXiv)
OWASP도 2026년 Agentic Applications Top 10을 발표하면서 autonomous and agentic AI systems가 plan, act, decide하는 복잡한 workflow에서 새로운 보안 리스크를 만든다고 설명한다. (OWASP Gen AI Security Project)
그래서 다음 세대 하네스에는 보안 계층이 기본으로 들어가야 한다.
- tool allowlist
- MCP server allowlist
- path allowlist
- command allowlist
- argument schema validation
- secret redaction
- sandbox isolation
- network policy
- human approval for side effects
- trace audit
- tool metadata scanner
- prompt injection detector
좋은 하네스는 모델에게 “조심해”라고 말하지 않는다. 좋은 하네스는 위험한 행동이 실행되기 전에 구조적으로 막는다.
11. 핵심 인사이트: 좋은 agent보다 좋은 실패 루프가 중요해진다
하네스 엔지니어링의 다음을 한 문장으로 정리하면 다음과 같다.
승자는 가장 똑똑한 agent를 가진 팀이 아니라, 가장 좋은 실패 루프를 가진 팀이다.
이 실패 루프는 네 가지 자산으로 구성된다.
1. production trace
2. failure taxonomy
3. golden / regression set
4. calibrated judge
이 네 가지가 있으면 모델을 바꿔도, provider를 바꿔도, tool schema를 바꿔도, prompt를 바꿔도 “좋아졌는지”를 알 수 있다.
반대로 이 네 가지가 없으면 개발은 계속 이렇게 된다.
Reddit에서 좋다던 모델을 써봄
HN에서 본 prompt를 적용함
OpenRouter에서 싼 모델로 바꿈
체감상 좋아진 것 같음
며칠 뒤 특정 케이스에서 깨짐
원인 모름
다시 prompt 수정
앞으로의 AI 앱 개발은 “모델 선택”에서 “루프 설계”로 간다.
프롬프트 엔지니어링
→ 컨텍스트 엔지니어링
→ 하네스 엔지니어링
→ EvalOps / TraceOps / JudgeOps
→ eval-gated self-improving harness
→ agent control plane / Agent OS
→ verifier-driven autonomous work
하네스의 다음은 더 화려한 demo가 아니다.
하네스의 다음은 실패를 기록하고, 분류하고, 테스트로 만들고, judge를 보정하고, 검증된 변경만 배포하는 시스템이다.
부록 1. 현재 봐야 할 레포와 자료
1. Meta-Harness
Stanford IRIS Lab의 meta-harness는 task-specific model harness를 자동 검색하는 연구 프레임워크다. 이 레포는 Meta-Harness 논문의 reference experiment를 포함하고, 고정된 base model 주변에서 무엇을 저장·검색·제시할지 결정하는 code around model을 탐색 대상으로 본다. (GitHub)
2. OpenAI Symphony
openai/symphony는 project work를 isolated autonomous implementation run으로 바꾸는 orchestrator다. README는 “coding agents를 직접 감독하는 대신 work를 관리하게 해주는 시스템”이라고 설명한다. (GitHub)
3. LangChain Deep Agents
langchain-ai/deepagents는 agent harness를 batteries-included 형태로 제공한다. planning, filesystem, subagents, middleware, memory 같은 요소를 묶은 실전형 하네스 레포로 볼 수 있다. (GitHub)
4. HKUDS OpenHarness
HKUDS/OpenHarness는 agent loop, tools, skills, plugins, memory, session resume, permissions, hooks, multi-agent coordination을 포함하는 open agent harness다. 하네스 구성요소를 폭넓게 살펴보기 좋은 레포다. (GitHub)
5. Promptfoo
Promptfoo는 prompt/model/RAG/agent eval과 red teaming을 CI/CD에 붙이기 좋은 도구다. 공식 문서는 regression 조기 탐지, 보안 스캔, quality gate, cost control을 CI/CD에서 수행할 수 있다고 설명한다. (promptfoo.dev)
부록 2. 내가 개발하면 좋은 repository 아이디어
아래는 인재님이 직접 만들면 좋은 레포 아이디어다. 단순 toy project보다, 지금 흐름에서 실제로 가치가 생길 가능성이 높은 순서로 정리했다.
1순위: harness-forge — Trace-to-Eval Self-Improving Harness Starter Kit
가장 추천한다.
한 줄 설명
production trace를 golden/regression set으로 승격하고, eval gate를 통과한 harness patch만 채택하는 오픈소스 starter kit.
왜 좋은가
현재 생태계는 조각나 있다.
Tracing: Langfuse, LangSmith, OpenTelemetry
Eval: Promptfoo, DeepEval, Braintrust
Harness: DeepAgents, OpenHarness, Agents SDK
Research: Meta-Harness, AutoHarness, ACE
Orchestration: Symphony
하지만 “실제 개발자가 repo 하나 clone해서 trace → taxonomy → regression → judge → patch gate 루프를 바로 시작하는 템플릿”은 아직 비어 있다.
이 레포는 그 빈 공간을 노릴 수 있다.
MVP 기능
1. trace schema
- LLM call, tool call, retrieval, final output, outcome state 기록
2. failure taxonomy
- YAML 기반 failure label 정의
- trace에 multi-label annotation
3. trace-to-golden
- 실패 trace를 regression item으로 변환
- expected_behavior, required_tools, forbidden_tools 생성
4. judge stack
- deterministic scorer
- LLM judge
- human correction file
- judge agreement report
5. eval runner
- Promptfoo 또는 DeepEval 연동
- pass/fail/unsure 기반 gate
6. harness patch handoff
- 실패 cluster 요약
- 제안 변경사항 생성
- Codex/Claude Code가 읽을 수 있는 patch request 생성
7. CI integration
- GitHub Actions에서 regression fail 시 PR fail
추천 repo 구조
harness-forge/
README.md
AGENTS.md
HARNESS_CARD.md
EVAL_CARD.md
harness.yaml
traces/
schema.json
examples/
support_trace.redacted.jsonl
taxonomies/
failure_taxonomy.yaml
datasets/
smoke.jsonl
core_golden.jsonl
regression.jsonl
adversarial.jsonl
judges/
task_success_judge.md
groundedness_judge.md
tool_trajectory_judge.md
calibration_set.jsonl
judge_report.md
scorers/
schema_check.py
required_tool_check.py
forbidden_tool_check.py
cost_latency_check.py
llm_judge.py
forge/
ingest_trace.py
label_failure.py
promote_to_regression.py
run_eval.py
build_judge_report.py
propose_harness_patch.py
generate_codex_handoff.py
integrations/
promptfoo/
promptfooconfig.yaml
deepeval/
langfuse/
langsmith/
opentelemetry/
.github/
workflows/
eval.yml
redteam.yml
차별화 포인트
이 레포의 핵심은 “agent를 실행한다”가 아니라 agent를 개선하는 루프를 제공한다는 것이다.
기존 agent framework:
agent를 어떻게 실행할까?
harness-forge:
실패한 agent를 어떻게 더 좋게 만들까?
첫 릴리즈 목표
v0.1
- JSONL trace ingest
- failure taxonomy YAML
- regression item generator
- deterministic scorer 3개
- LLM judge 1개
- Promptfoo config export
- GitHub Actions gate
- HARNESS_CARD.md generator
스타 받을 만한 README 문구
Most agent frameworks help you run agents.
Harness Forge helps you improve them.
Turn production traces into regression tests.
Turn failures into harness patches.
Ship only changes that pass your eval gate.
2순위: trace2golden — Production Trace Mining for LLM Apps
한 줄 설명
Langfuse/LangSmith/OpenTelemetry trace에서 golden/regression 후보를 자동으로 뽑아주는 CLI.
왜 좋은가
LangSmith도 production failure를 regression dataset으로 바꾸는 loop가 핵심이라고 말한다. 하지만 많은 팀은 trace를 모아도 어떤 trace를 regression으로 승격해야 할지 모른다. (LangChain)
MVP 기능
trace2golden ingest --source langfuse
trace2golden cluster --by failure_mode
trace2golden promote --trace tr_123 --dataset regression
trace2golden export --format promptfoo
trace2golden export --format deepeval
좋은 기능
- high-cost trace 탐지
- repeated failure cluster 탐지
- user thumbs-down trace 우선순위화
- judge unsure trace human queue 생성
- slice별 dataset coverage report
타깃 사용자
- RAG 앱 운영팀
- 고객지원 agent 팀
- SaaS AI feature 팀
- eval을 시작하려는 스타트업
3순위: harness-card — Agent Harness Disclosure Standard
한 줄 설명
agent benchmark나 내부 배포에서 harness 정보를 표준 문서로 공개·검증하는 linter/generator.
왜 좋은가
같은 모델도 harness에 따라 결과가 크게 달라진다. LangChain은 하네스를 모델 바깥의 code, config, execution logic으로 정의하고, OpenAI와 Anthropic도 하네스 설계가 long-running agent 성능에 영향을 준다고 말한다. (LangChain)
모델 벤치마크가 앞으로 신뢰를 얻으려면 “모델명 + 점수”만으로는 부족하다. prompt version, tool list, memory policy, retry policy, eval set, judge, sandbox, permission policy를 같이 공개해야 한다.
HARNESS_CARD 예시
harness:
name: support-agent-harness
version: 0.3.1
model:
provider: openrouter
primary: gpt-5.5
fallback:
- claude-opus
- gemini-pro
context:
memory_policy: scoped_user_memory
compaction: summarize_after_24k_tokens
rag:
retriever: hybrid_bm25_dense
reranker: cross_encoder_v2
tools:
- name: policy.search
permission: read_only
- name: refund.create
permission: side_effect
approval_required: true
eval:
core_golden: datasets/core_golden.jsonl
regression: datasets/regression.jsonl
judge: judges/task_success_judge.md
gate:
critical_regression_fail: 0
min_pass_rate: 0.95
security:
sandbox: e2b
network: restricted
mcp_allowlist:
- internal_policy_server
MVP 기능
harness-card init
harness-card lint
harness-card diff old.yaml new.yaml
harness-card score --checks eval,security,trace
차별화 포인트
이건 “Model Card”의 agent/harness 버전이다.
4순위: mcp-guard — MCP Tool Poisoning Scanner and Runtime Firewall
한 줄 설명
MCP server와 tool metadata를 검사하고, 위험한 tool call을 승인/차단하는 보안 레이어.
왜 좋은가
MCP는 agent tool layer의 표준으로 빠르게 확산되고 있지만, tool poisoning과 prompt injection 문제가 크다. MCP threat modeling 논문은 tool metadata에 악성 instruction이 들어가는 tool poisoning을 가장 영향력 있는 client-side vulnerability로 지적한다. (arXiv)
MVP 기능
mcp-guard scan ./mcp.json
mcp-guard inspect-tools --server local
mcp-guard policy init
mcp-guard proxy --config guard.yaml
검사 항목
- tool description 안의 hidden instruction
- overly broad permission
- shell / file / network side effect
- token exfiltration pattern
- suspicious OAuth scope
- rug-pull 가능성 있는 remote server
- schema와 description 불일치
Runtime 기능
- high-risk tool approval gate
- argument schema validation
- command allowlist
- path allowlist
- secret redaction
- audit trace
타깃 사용자
- MCP 서버를 붙여 쓰는 개발자
- Claude Code / Codex / Cursor / Goose 사용자
- 기업 보안팀
- agent platform 팀
5순위: eval-router — Eval-Driven Multi-Model Router
한 줄 설명
OpenRouter 같은 멀티모델 환경에서 task slice별로 모델을 자동 선택하는 router.
왜 좋은가
OpenRouter Agent SDK는 multi-turn loop, tools, conversation state를 제공하고, tool approval/state persistence 기능도 제공한다. OpenRouter는 하나의 endpoint로 여러 모델을 다룰 수 있기 때문에, 앞으로는 “최고 모델 하나”보다 “task별 최적 모델 조합”이 중요해진다. (OpenRouter)
MVP 기능
eval-router benchmark --dataset core_golden.jsonl
eval-router recommend --by slice
eval-router route --input request.json
eval-router report --cost-quality
라우팅 예시
routing:
default: gpt-5.5
slices:
summarization:
model: cheap-fast-model
code_review:
model: strong-reasoning-model
policy_sensitive:
model: frontier-model
judge_required: true
side_effect_tool:
model: reliable-tool-model
approval_required: true
차별화 포인트
이 레포는 “모델 라우터”가 아니라 eval 결과 기반 라우터다.
인재님에게 가장 추천하는 개발 로드맵
가장 현실적이고 임팩트 큰 선택은 다음 순서다.
1. harness-forge
전체 루프를 잡는 메인 레포
2. trace2golden
harness-forge 안의 핵심 모듈로 시작했다가 독립 CLI로 분리
3. harness-card
표준화/문서화 계층으로 확장
4. mcp-guard
보안 특화 사이드 프로젝트
5. eval-router
OpenRouter 기반 멀티모델 최적화로 확장
처음부터 다 만들기보다 harness-forge 하나로 시작하는 게 좋다. 그 안에 trace2golden, harness-card, judge calibration, Promptfoo export를 작게 넣고, 사용자가 늘면 각각을 독립 레포로 분리하면 된다.
최종 메시지
AI 하네스의 다음은 “더 똑똑한 agent”가 아니다.
다음은:
실행하고
기록하고
분류하고
평가하고
고치고
검증하고
되돌리고
다시 학습하는 시스템
이다.
OpenAI, Anthropic, LangChain의 공식 자료는 모두 같은 방향을 가리킨다. 모델은 점점 강해지지만, 제품 성능은 모델 바깥의 하네스에서 결정된다. Meta-Harness와 AutoHarness는 하네스 자체가 자동 최적화 대상이 될 수 있음을 보여준다. ACE는 context가 고정 prompt가 아니라 진화하는 playbook이 될 수 있음을 보여준다. 하지만 misevolution과 forgetting 연구는 자기개선이 gate 없이 돌아가면 위험하다는 점을 경고한다. (arXiv)
그래서 앞으로의 핵심은 이것이다.
Self-improving harness가 아니라, eval-gated self-improving harness.
Autonomous agent가 아니라, verifier-driven autonomous work.
Prompt 감각이 아니라, trace/eval/judge/regression 루프.
'개발 > AI' 카테고리의 다른 글
| Spring AI로 Pi 스타일 에이전트 하네스 만들기 (0) - init (0) | 2026.06.26 |
|---|---|
| 에이전트 토큰을 줄이는 방법 (Caveman vs RTK) (0) | 2026.05.26 |
| LLM 시대를 예측한 Peter Norvig의 다음 예측 (0) | 2026.05.08 |
| 읽지 않는 코드의 시대를 읽고 (0) | 2026.03.11 |
| 웹사이트를 AI 친화적으로 만드는 법 - Content Negotiation (0) | 2026.02.09 |