내가 만든 Harness 절반은 Opus 4.7 깔리자마자 쓰레기가 됐다

지난주에 한 짓이 좀 허무합니다. 한 달 동안 공들여 만든 sprint decomposition 로직, evaluator 에이전트 분리, 컨텍스트 리셋 루틴 — 4월 16일에 Opus 4.7 깔고 다시 돌려봤더니 절반은 그냥 안 켜도 결과가 똑같거나 더 좋았어요. 어떤 케이스는 오히려 harness가 끼어들면서 출력이 더 산만해졌고요.

처음엔 "내가 잘못 만들었나?" 했는데, 알고 보니 이게 업계 전체가 지금 겪는 일이더라고요. Harness Engineering이라는 신생 분야가 90일 전에 등장했는데, 이미 자기 규칙을 갈아엎고 있는 중. 이 글은 에이전트 워크플로우 진지하게 짜는 분들 + 자기가 만든 도구가 며칠 만에 쓸모없어지는 경험 해본 분들용이에요.

---

Harness가 뭔데#

ThoughtWorks가 정의한 한 줄이 제일 깔끔해요:

Agent = Model + Harness

모델 빼고 다 — 제약, 피드백 루프, 문서 구조, 도구 권한 — 이걸 통칭해서 harness라고 부릅니다. OpenAI 팀은 "말한테 채우는 마구"라는 비유를 썼어요. 말을 똑똑하게 만드는 게 아니라, 그 힘을 쓸모 있는 방향으로 채널링하는 장비.

LangChain이 같은 모델로 Terminal Bench 2.0 두 번 돌렸는데, harness만 바꿨더니 점수가 52.8%에서 66.5%로 뛰었어요. Vercel은 반대로 도구 80%를 들어내고 더 좋은 성능을 받았고요. 모델은 이제 더 이상 어려운 부분이 아닙니다. harness가 어려운 부분이에요.

---

세 진영, 다른 답#

같은 문제로 출발해서 세 군데가 완전히 다른 아키텍처에 도착했어요.

OpenAI — 환경 우선

Codex 팀이 사람 손으로 한 줄도 안 쓰고 100만 줄짜리 프로덕션 코드를 출하했어요. 이게 가능하려면 환경 자체에 제약을 박아넣어야 한다는 결론. 코드베이스 곳곳에 AGENT.md 깔고, 의존성 흐름(Types → Config → Repo → Service → Runtime → UI) 강제하고, CI/CD에 직접 물려둠. 사람 역할은 코더가 아니라 아키텍트.

Anthropic — 다중 에이전트

자기 평가시키면 모델이 자기 깨진 결과물을 칭찬하는 패턴을 발견. 그래서 Planner / Generator / Evaluator 셋으로 분리했어요. GAN처럼 평가자랑 생성자를 따로 두는 발상. 솔로 에이전트($9, 20분) vs 풀 harness($200, 6시간) 비교에서, 솔로 결과물은 UI만 멀쩡하고 핵심 기능 깨진 데모. 다중 에이전트 결과물은 실제 굴러가는 제품. 22배 비용 차이가 깨진 데모 vs 작동하는 소프트웨어의 차이.

ThoughtWorks — 분류학

이쪽은 시스템이 아니라 사고 프레임워크를 만들었어요. feedforward(가이드) vs feedback(센서) + computational(결정적) vs inferential(LLM 기반) 의 2x2 매트릭스. 솔직히 처음 봤을 땐 너무 학술적이라 와닿지 않았는데, 기존 codebase에 linter랑 test가 있으면 "어, 나 이미 절반은 만들어놨네" 알아챌 수 있게 해주는 장점이 있어요.

(잠깐 딴 얘긴데, 세 군데 다 자기 출발 문제가 달랐어요. 그래서 나오는 답도 달랐던 거고요. "어느 진영이 맞나"가 아니라 "내 문제가 어디에 가깝나"가 진짜 질문인 듯)

---

세 진영이 결국 같은 결론으로 수렴한 5가지#

다른 길로 갔는데 도착지는 거의 같아요:

1. 컨텍스트가 지시문을 이긴다 — 추상적 설명 말고, 실제 파일 경로/코드 패턴/진행 상황을 보여줄 것
2. 계획과 실행은 분리 — 한 패스에 다 시키면 결과물 신뢰 못 함
3. 피드백 루프는 협상 불가 — feedforward만으로는 가이드가 진짜 작동하는지 영원히 모름
4. 한 번에 하나씩 — 강제 점진주의. sprint마다 커밋
5. 코드베이스가 곧 문서 — 별도 지식 베이스 만들지 말고 repo 안에 다 넣어라

세 팀이 우연히 같은 답에 도착했다는 건 그냥 의견이 아니라 공학적 제약이라는 뜻이에요. 이거 어기면 다 똑같이 망합니다. 이 다섯 개는 시작점으로 박아두면 됨.

---

진짜 흥미로운 부분: Harness Decay#

여기서부터가 이 분야의 진짜 무서운 함정이에요.

Opus 4.5에서 4.6으로 올라가면서 sprint decomposition이 통째로 불필요해졌어요. 모델이 long-context 처리를 잘하게 되면서 그 기능을 자연스럽게 흡수해버린 거죠. 결과적으로 같은 DAW(디지털 오디오 워크스테이션) 만드는 데 비용이 38% 줄고 시간도 36% 줄었습니다. harness가 일을 덜 한 게 아니라, 모델이 harness 역할을 일부 흡수한 거예요.

그리고 이번 4월 16일 Opus 4.7. 모델이 자기 출력을 스스로 검증해서 보고해요. Evaluator 에이전트를 따로 두는 이유 자체가 흔들리는 중. CursorBench 점수가 58→70%로 뛰었고, 도구 에러도 1/3로 줄었음. 제가 위에서 말한 "내 harness 절반이 쓰레기 됨" 사건이 정확히 이거였어요.

Anthropic은 이걸 "harness decay" 라고 부릅니다. harness의 모든 컴포넌트는 "모델이 이건 못 한다"는 가정을 하나씩 깔고 있어요. 모델이 그 가정을 무너뜨리면, 보완하던 컴포넌트는 그 순간부터 순수한 오버헤드가 됩니다. 토큰값, 지연시간, 유지보수 비용 — 다 깎아먹기만 하는.

Manus는 6개월 동안 harness를 5번 갈아엎었고, LangChain은 1년에 3번 재구조화했어요. 잘못 만들어서가 아니라, 모델이 너무 빨리 자라서.

---

그래서 어떻게 만들어야 함 — Build to Delete#

Philipp Schmid가 한 말이 핵심이에요: "삭제할 수 있게 만들어라."

모든 harness 컴포넌트는 kill switch를 달아두고, 정기적으로 꺼봐야 합니다. 끄고도 출력 품질이 유지되면? 삭제. 죽은 컴포넌트 끌고 다니면 매 실행마다 토큰 새고 유지보수 부담만 늘어요. 정 떨어져도 들어내야 함.

Rich Sutton의 "bitter lesson"이랑 정확히 같은 맥락이에요. 컴퓨트와 함께 스케일하는 단순한 방법이, 정교하게 손으로 깎은 복잡한 솔루션을 결국 이깁니다. harness에도 그대로 적용돼요.

---

솔직한 한계와 답 안 나온 부분#

장점만 적으면 거짓말이고요:

• 신생 분야의 함정: 90일 된 분야라 베스트 프랙티스가 빨리 바뀝니다. 6개월 전 가이드는 이미 outdated인 경우가 많아요. 어쩔 수 없는 부분
• 자기 진영에 갇히기 쉬움: OpenAI 방식 익히면 Anthropic 방식이 과도하게 보이고, 반대도 마찬가지. 셋 다 자기 출발 문제가 다르다는 걸 잊지 말 것
• 풀리지 않은 큰 질문: 모델이 계속 좋아지면 harness가 OS 커널처럼 얇은 표준 레이어로 수렴할까, 아니면 영원히 세대마다 다시 짜야 할까. 세 진영이 답을 다르게 보고 있어요. 솔직히 저도 모름
• ThoughtWorks 프레임워크는 처방이 아닌 진단: 무슨 종류의 통제가 있는지는 알려주지만 구체적으로 어떤 도구 쓰라는 말은 안 해요. 턴키 기대하면 실망함

---

끝맺으며#

2026년에 가장 안정적인 AI 시스템 만드는 사람들은 가장 좋은 코드 쓰는 사람들이 아니에요. 가장 좋은 제약을 설계하고, 그 제약이 쓸모를 다하는 순간 미련 없이 버리는 사람들입니다.

이게 보기보다 어려워요. 한 달 공들여 만든 거 들어내는 게 사람 정서로는 쉽지 않거든요. 근데 안 들어내면 비용으로 그대로 청구돼요. 그래서 처음부터 들어내기 쉽게 모듈로 짜야 한다는 거고요.

당분간 매주 자기 harness 점검하는 시간을 일정에 박아두려고 해요. 모델 업데이트 떴을 때 "어 그러고 보니 이거 아직 필요한가?" 묻는 게 새로운 직무 같아요. 약간 허탈하지만 받아들이는 중입니다.