최적화 대상은 사다리로 올라간다 — prompt → structured context → workflow → harness code → optimizer code. 위 칸이 더 세지만, 아래 칸을 손으로 못 짜는 게 확인될 때만 올라간다.

언제: harness를 짜다 “이걸 자동화해야 하나” 싶을 때. 먼저 지금 문제가 어느 칸인지 짚는다.

칸	올라갈 신호	그 칸에서 하는 일
1 프롬프트	—
2 구조화된 컨텍스트	컨텍스트가 윈도우를 넘게 자란다	상태를 파일시스템에 두고 컨텍스트엔 포인터만
3 워크플로	컨텍스트 관리 규칙이 태스크마다 달라 손으로 못 짠다	subagent + process manager, 병렬 가설
4 harness 코드	워크플로 설계 공간이 방대해 수작업으로 못 짠다	코드로 workflow 생성, 그래프 + 탐색
5 optimizer 코드	—	진화 탐색, meta-prompt 공진화

확인: 한 칸 올라간 뒤 held-in(약점이 풀렸나) + held-out(새 이슈가 없나) 양쪽이 no-regression일 때만 채택한다. 한쪽만 보면 그 신호에 overfit된다 — unit test면 test에, judge면 그 judge 특화 트릭에.

함정

• 재귀 구조만으론 부족하다. 베이스 모델이 메커니즘을 개선할 만큼 유능하지 않으면 자기개선 루프는 퇴화한다 — STOP은 GPT-4에서 올랐고 GPT-3.5·Mixtral에서 내렸다.¹
• 평가가 빠르고 객관적일 때만 돈다. taste·novelty·장기 가치처럼 verifier가 없는 축에선 루프가 헛돈다.
• evaluator와 권한 제어는 루프 바깥에 둔다. harness를 진화시키는 루프가 자기 채점기를 못 만지게.
• 컨텍스트를 통째로 다시 쓰지 마라. 매 스텝 blob을 rewrite하면 디테일이 뭉개지고 점점 짧아진다(context collapse). 증분 항목만 병합한다.¹
• 단순·generic이 이긴다. 커스텀 메모리 API를 발명할수록 코어 모델 향상에 무임승차할 기회를 버린다. bash·파일시스템·표준 툴셋을 선호.

그런데 고정 모델에서도 harness만 진화시켜 크게 오른다 — DGM이 발견한 에이전트가 SWE-bench Verified에서 20 → 50%.¹ 사다리를 올라갈 값어치가 있다는 쪽의 근거다.

---

칸마다 붙는 사례(ACE·MCE·ADAS·AFlow·Autodata·Self-Harness·DGM·AlphaEvolve·ShinkaEvolve…)는 원문에 있다. 여기 남긴 건 어느 칸에서 언제 올라가느냐뿐이다.

Footnotes

1. “A harness should not carry the entire workflow and all logs in context; instead, it should keep durable state in files.” / “the curator does not rewrite a full prompt blob.” / “STOP improved mean downstream performance across iterations with GPT-4 but degraded with weaker models like GPT-3.5 and Mixtral.” / “the DGM-discovered agents are comparable to or outperform handcrafted agents on SWE-bench Verified (20% to 50%)” (Harness Engineering for Self-Improvement — Lilian Weng) ↩ ↩² ↩³