System Prompt
추상적 지시를 버리고 Planning & Discovery → Build → Verify → Fix의 강제된 작업 순서를 넣는다.
01
52.8%에서 66.5% — 모델은 한 번도 바꾸지 않았다
Terminal Bench 2.0은 89개의 복잡한 coding-agent 과제로 구성된 표준 벤치마크다. ML, debugging, 생물학, 보안, 게임 등 여러 영역을 포함하고, 일부 과제는 실행 시간이 10분에 가깝고 도구 호출도 100회를 넘는다고 원문은 설명한다.
52.8%Top 30최적화 전
→
66.5%Top 5최적화 후
+13.7percentage points
Terminal Bench 2.0 점수 상승폭.
+25ranking positions
Top 30에서 Top 5로 상승.
SameGPT-5.2-Codex
원문 기준 모델은 전후 동일.
89복합 coding-agent 과제
≈10m일부 과제 실행 시간 규모
100+일부 과제 도구 호출 횟수
원문이 강조하는 것은 세 번째 행이다. 모델은 그대로이고 System Prompt, Tools, Middleware만 바뀌었다. 같은 능력도 어떤 순서로 생각하고, 어떤 환경을 보고, 언제 멈추지 못하게 하는가에 따라 다른 결과를 낸다.
02
최적화 공간을 일부러 줄인다
Agent Harness에는 바꿀 수 있는 것이 너무 많다. System Prompt, tools, hooks, middleware, skills, subagent delegation, memory까지 한꺼번에 움직이면 어떤 변화가 효과를 냈는지 알 수 없다. LangChain은 변수 세 개만 남겼다.
Tools
작업 환경을 자동 주입하고, 종료 직전에는 사양과 테스트를 다시 확인하는 완료 검사를 강제한다.
Middleware
Doom loop 탐지, history trimming, PII filtering, caching, retry, tool access, human-in-the-loop 같은 횡단 관심사를 Agent 핵심 로직에서 분리한다.
좋은 실험은 많이 바꾸는 실험이 아니다. 원인을 알 수 있을 정도로 변화의 범위를 제한하는 실험이다. Harness 개선도 기능 추가보다 인과관계를 읽을 수 있는 설계가 먼저다.
03
System Prompt — 생각의 순서를 구조화한다
첫 번째 변화는 문장의 화려함이 아니라 작업 순서의 강제다. 코드를 곧바로 쓰기 시작하지 않고, 계획·구현·검증·수정이라는 순서를 Harness가 외부에서 잡아준다.
1. Planning & Discovery과제 읽기 · 저장소 스캔 · 검증 계획
→
2. Build테스트를 의식하며 구현
→
3. Verify테스트 실행 · 사양 대조
→
4. Fix오류 분석 · 요구 재검토
중요한 변화는 Agent에게 “잘하라”고 말한 것이 아니다. 어떤 순서로 생각하고 행동해야 하는지를 구조화했다. 자유로운 추론보다 반복 가능한 작업 리듬을 먼저 만든다.
04
Tools — 환경을 먼저 알려주고, 끝났다는 자기판단을 막는다
Agent가 자신이 어디에 있는지 파악하는 데 시간을 낭비하고, 코드를 다시 읽은 뒤 “괜찮아 보인다”고 스스로 승인한 채 테스트 없이 멈추는 실패가 반복됐다.
환경 감지와 자동 주입
시작 시 작업 디렉터리와 하위 구조를 매핑하고 bash 명령을 실행해 Python 버전과 사용 가능한 명령 등 설치 환경을 파악한다.
- working directory 파악
- subdirectory 구조 매핑
- 사용 가능한 도구 탐지
- 설치 환경 자동 확인
완료 직전의 강제 검증
Agent가 종료하려는 순간을 가로막고 작업 사양을 기준으로 다시 검증하게 한다. 자기 코드를 다시 읽고 “그럴듯하다”고 판단하는 것은 완료의 근거가 되지 않는다.
- 사양 대조
- 테스트 실행
- 경계 조건 확인
- 자기확인 편향 차단
Agent의 내부 판단“다시 읽어보니 괜찮아 보인다.”
⟂Harness의 외부 검증“사양과 테스트를 통과했는가?”
모델은 자신의 첫 번째 그럴듯한 해법을 좋아한다. 원문은 이를 더 똑똑한 모델로 고치려 하지 않는다. 완료의 기준을 자기확신에서 외부 검증으로 옮긴다.
05
Middleware — Doom Loop를 끊고 관심사를 분리한다
Agent는 한 방향에 커밋한 뒤 같은 잘못된 접근을 조금씩 변형하며 반복할 수 있다. LangChain은 이를 doom loop로 보고 동일 파일의 반복 편집을 추적한다.
Doom Loop
잘못된 방향을 포기하지 못한 채 같은 파일을 여러 번 조금씩 수정한다. 매번 거의 됐다고 느끼지만 문제의 축은 바뀌지 않는다.
12345678910+
LoopDetectionMiddleware
특정 파일이 N회 편집되면 “다른 방법을 고려하라”는 개입을 넣는다. 수정 자체를 금지하지 않고, 반복 횟수라는 단단한 조건에서만 방향을 다시 생각하게 한다.
부드러운 개입 + 단단한 트리거. Harness는 모든 행동을 막는 울타리가 아니라 잘못된 관성이 충분히 드러났을 때 생각의 방향을 틀어주는 장치가 될 수 있다.
| Hook | 실행 시점 | 대표 용도 |
|---|---|---|
| before_agent | 호출 시작 시 1회 | 메모리 로딩, 리소스 연결 |
| before_model | 각 모델 호출 전 | 히스토리 절단, PII 필터링 |
| wrap_model_call | 모델 호출 전체 | 캐시, 재시도, 동적 도구 가용성 |
| wrap_tool_call | 도구 실행 전체 | 컨텍스트 주입, 도구 접근 제어 |
| after_model | 모델 응답 후 | human-in-the-loop 개입 |
| after_agent | 완료 시 1회 | 결과 저장, 리소스 정리 |
PIIMiddlewareSummarizationMiddlewareModelRetryMiddleware관심사 분리조직 간 재사용
Middleware의 가치는 기능 수보다 분리에 있다. 보안·메모리·재시도·요약·도구 정책을 업무 로직과 분리하면 서로 다른 팀이 같은 안전장치를 공유할 수 있다.
06
Reasoning Sandwich — 가장 깊게 생각하는 것이 항상 최선은 아니다
전 구간을 최고 추론 강도인 xhigh로 실행한 구성은 전 구간 high보다 크게 낮았다. 이유는 품질이 아니라 시간이었다.
추론 강도별 Terminal Bench 2.0
원문 비교
추론 샌드위치
Planning · xhigh
처음에 깊게 생각해 방향과 검증 계획을 세운다.
Build · high
실행에서는 충분한 수준으로 낮춰 시간과 token을 아낀다.
Verify · xhigh
마지막 검증에서 다시 깊은 추론을 쓴다.
전 구간 xhigh는 많은 과제가 제한 시간을 넘겼다. 원문은 자원의 총량보다 배분이 중요하다는 결론을 끌어낸다.
힘은 많다고 좋은 것이 아니라 알맞은 자리에 놓일 때 힘이 된다. 계획에서는 깊게, 실행에서는 빠르게, 검증에서는 다시 깊게. 추론 예산도 하나의 Harness 자원이다.
07
Boosting처럼 고친다 — 실패 trace가 다음 Harness를 만든다
LangChain의 개선은 한 번의 영감이 아니었다. 기준선을 세우고 실패를 읽고 특정 원인만 겨냥해 바꾸고 다시 회귀 검증하는 반복 방법론이었다.
1. Baseline기본 prompt + 표준 tools · 52.8%
→
2. Trace AnalysisLangSmith 실험 trace 분석
→
3. Targeted Change실패 패턴별 Harness 수정
→
4. Regression Test다른 과제 퇴행 여부 확인
Trace Analyzer Skill
LangSmith에서 실험 데이터를 가져와 각 실패 사례의 실행 궤적을 분석한다. 최종 답만 보는 것이 아니라 어떤 도구를 언제 호출했고 어느 순간 잘못된 방향에 고착됐는지를 본다.
병렬 Agent가 실패 사례를 나눠 분석
주 Agent가 공통 실패 패턴을 종합
패턴마다 특정 Middleware / Tool / Prompt 수정
사람이 회귀 결과를 확인해 과적합 방지
다시 trace 분석으로 돌아가 반복
자동화가 커져도 사람의 판단은 사라지지 않는다. 어떤 실패를 일반화할지, 어떤 수정이 특정 과제에만 과적합된 것인지 판단하는 일은 여전히 인간의 몫이다.
08
실패 패턴과 대응 Harness
전체 최적화 과정에서 발견된 문제는 막연한 “모델이 부족하다”가 아니었다. 반복되는 실패에는 이름이 있었고 이름이 붙은 실패마다 대응 장치가 있었다.
자기확인 편향
코드를 쓴 뒤 다시 읽고 괜찮다고 판단하지만 테스트를 실행하지 않는다.
→ PreCompletionChecklistMiddleware
Doom Loop
같은 파일을 10회 이상 수정하며 동일한 잘못된 접근의 작은 변형을 반복한다.
→ LoopDetectionMiddleware
환경 미숙지
낯선 디렉터리 구조와 설치 환경을 이해하는 데 많은 시간을 소모한다.
→ LocalContextMiddleware
시간 관리 실패
모든 단계에서 과도한 추론을 사용해 제한 시간 안에 작업을 끝내지 못한다.
→ Reasoning Sandwich
52.8에서 66.5로 오른 사실보다 더 중요한 것은 우리가 “모델이 부족하다”고 부르던 문제의 일부가 실제로는 환경이 부족한 문제일 수 있다는 점이다. 좋은 개발자도 준비되지 않은 컴퓨터에서는 제 능력을 다 쓰지 못한다. Agent 역시 다르지 않다.
기준선을 만든다
현재 성능을 먼저 숫자로 고정한다.
실패 trace를 읽는다
최종 실패보다 실패가 만들어진 과정을 본다.
한 원인을 겨냥해 바꾼다
효과를 식별할 수 있도록 수정 범위를 제한한다.
회귀 검증한다
한 과제 개선이 전체를 해치지 않는지 본다.
다시 반복한다
Harness를 완성품이 아니라 실험의 누적으로 다룬다.
이 사례의 가장 큰 가치는 재현 가능성이다. 기준선 → 실패 분석 → 정밀 수정 → 회귀 검증 → 반복. 천재의 한 번의 직관이 아니라 누구나 따라 할 수 있는 공학적 순환이다. 차이는 실패 trace를 얼마나 오래, 정확하게 들여다보는가에서 생긴다.
같은 말이라도 길이 다르면 달리는 모습이 달라진다.
같은 사람이라도 도구와 규칙과 시간이 다르면 일의 결과가 달라진다.
LangChain의 숫자가 보여주는 것은
지능의 한계보다 환경의 책임이다.
실패를 모델 탓으로 돌리기 전에
어디에서 헤맸는지, 왜 멈췄는지,
무엇을 보지 못했고 무엇을 검증하지 않았는지 본다.
그리고 그 실패가 다시 일어나지 않도록
환경에 한 줄을 더한다.
좋은 Harness는 더 많이 명령하는 구조가 아니라, 실패를 더 정확히 기억하는 구조다.
이 웹페이지는 첨부 문서 《Harness Engineering》의 §10 「LangChain：同一匹马，换套缰绳 / LangChain: Same Model, Different Harness」(PDF 46–51쪽)에만 근거해 재구성했다. 52쪽에서 §11이 시작되는 것을 확인해 10장의 범위를 분리했다. Terminal Bench 2.0의 52.8%→66.5%, Top 30→Top 5, 동일 GPT-5.2-Codex, System Prompt·Tools·Middleware 세 변수, 4단계 workflow, LocalContextMiddleware, PreCompletionChecklistMiddleware, LoopDetectionMiddleware, 6개 hook, Reasoning Sandwich, trace 기반 반복 개선, 실패 패턴과 원문의 결론을 보존했으며 외부 자료를 통한 사실 검증·수정·확장은 수행하지 않았다.