하네스만 바꿔 13.7포인트 — 자기진화 루프와 비대칭 거버넌스

"하네스를 바꾸면 성능이 좋아진다"는 주장은 검증하기 어렵다. 대개 모델도 같이 바뀌기 때문이다. 그래서 모델을 고정한 채 하네스만 교체한 실험 하나가 이 논의에서 유독 무겁게 인용된다 — 벤치마크 52.8%에서 66.5%, 순위는 Top 30 밖에서 Top 5로.

이 글은 그 실증을 중심에 놓고 양옆을 채운다. 앞쪽에는 그 하네스가 컨텍스트를 어떻게 배치하는지 — 상시 레이어와 조건부 레이어로 나누는 사실상 표준 구조. 뒤쪽에는 그 구조가 스스로 갱신될 때 필요한 것 — 진화 루프와 거버넌스, 그리고 둘 중 하나만 빠져도 작동하지 않는다는 경고. 앞 편이 Agent = Model + Harness라는 등식을 세웠다면 이 글은 그 등식의 우변을 실제로 움직여 본 기록이다.

이 다음부터는 시선이 조직으로 넘어간다. 위임 격차 편이 "쓰긴 쓰는데 맡기지는 못한다"는 간극을 다룬다.

이 글은 2026년 4월 자료를 정리한 것이다. 벤치마크 수치·서베이·도입 사례는 모두 원 자료가 인용한 외부 자료이며, 도입 사례는 각 기업이 자사 사례로 발표한 값이다.

용어 정리

앞 편의 용어표에서 이 글이 쓰는 행만 추리고, 레이어·진화 용어를 더했다.

상시와 조건부 — 사실상 표준 아키텍처

여러 코딩 에이전트가 수렴한 구조를 자료는 "하네스의 사실상 표준 아키텍처"로 부른다.

도식과 표는 같은 두 레이어를 다루지만 담고 있는 항목이 서로 다르다. 도식에만 있는 것이 다섯이다 — Conventions·Guidelines·Project Info·Directives·Examples, 즉 상시 레이어에 실제로 무엇이 들어가는지의 내역이다. 표에만 있는 것도 셋이다 — AGENTS.md·MEMORY.md, 그리고 조건부 레이어의 구체적 스킬 디렉터리들. 도식은 계층 구조를, 표는 운용 성격을 말하고 있어 어느 한쪽만 두면 여덟 항목이 사라진다.

이 분할이 하네스 설계의 근간이고, 다음 개념으로 이어진다.

컨텍스트를 키운다고 성능이 따라오지 않는다

Progressive Disclosure는 제한된 자원을 효율적으로 쓰기 위한 단계적 로드다. 초기에는 요약만, 필요할 때 전체를 로드한다.

회피 대상은 Context Rot — 컨텍스트가 채워질수록 모델 추론 능력이 저하되는 현상이며, 관련 정보가 중간에 있을수록 찾기 어려워지는 lost in the middle을 포함한다.

컨텍스트를 키운다고 성능이 따라오지 않는다는 것이 이 수치의 요지다.

벤치마크 이름을 캡션에 못 박은 이유가 있다. 같은 주장이 여러 자료에 조금씩 다른 숫자로 돌아다니는데, 출처가 특정된 값만 검증이 가능하다. 위 값은 앞 시리즈의 다섯 구성물 편에 모델 네 종의 전체 표로 실려 있고, 거기서 보면 다른 모델에서는 순서가 뒤집히기도 한다 — 단일 벤치마크의 한 모델에서 관측된 값이지 보편 법칙이 아니다. 설계 변수로 삼을 것은 절대 수치가 아니라 상시와 조건부의 비중 조절이다.

모델을 고정하고 하네스만 바꿨다

개선 기법 일곱 가지는 그대로 루프 설계 체크리스트로 쓸 수 있다.

마지막 항목이 이 표에서 가장 반직관적이다. 추론을 더 많이 시키는 것이 항상 이득이 아니다.

예산이 없으면 더 깊은 추론이 오히려 미완성으로 끝난다. 같은 논리가 조직 자동화에도 적용되는데, 품질을 위해 검토 단계를 늘리면 어느 지점부터는 완료율이 떨어져 총 산출이 줄어든다. 자료가 덧붙인 시사점 하나도 같은 방향이다 — 모델을 후속 학습시킨 하네스가 반드시 그 모델에 최적은 아니다. 짝지어 나온 조합이라고 최적일 것이라는 가정을 검증 없이 쓰지 말라는 뜻이다.

하네스를 이루는 세 층위

세 번째 열에 유일하게 단정문이 들어간 행이 두 번째다 — Eval이 없으면 Harness가 아니다. 앞 편의 네 계층에서 검증이 가장 자주 빠진다고 했던 것과 같은 지적이고, 여기서는 그것을 자격 요건으로 격상시킨다.

스스로 갱신되는 루프

레퍼런스 루프는 다섯 단계이며, 앞 넷이 진화 루프이고 마지막 하나가 거버넌스다.

Self-Evolving과 Governance는 둘 중 하나만 빠져도 제대로 작동하지 않는다.

이유는 대칭적이다. 거버넌스 없이 진화 루프만 돌리면 아무도 모르는 사이에 동작이 바뀌어 있고, 진화 루프 없이 거버넌스만 두면 검토할 변경이 생기지 않아 절차만 남는다. 5단계가 재배포로 루프를 닫는다는 표현도 중요한데, 승인이 끝이 아니라 배포까지 가야 다음 사이클의 관찰 대상이 생긴다는 뜻이다. 승인은 났는데 반영은 다음 분기인 조직에서는 이 루프가 돌지 않는다.

만능이 아니라는 점이 그다음에 곧바로 나온다.

네 쌍이 하나씩 짝을 이룬다. 자동 개선의 대가가 과적합이고, 회귀 방지의 대가가 변경 빈도이며, 지식 자산화의 대가가 검토 부담이고, 스케일의 대가가 비용이다. 장점만 취하는 조합은 없다는 것이 이 표의 배치가 말하는 바이며, 완화책으로 제시된 것은 홀드아웃·배치 처리·단계적 위임·샘플링·감사 로그 다섯이다. 설계된 루프를 신중하게 운영하는 것이지 켜두면 저절로 되는 것이 아니다.

스킬이 자산이 되는 방식

세 층위가 전부 같은 방향으로 흐른다는 것이 이 도식의 요점이다. 회사 자산이 아래로만 내려가는 것이 아니라 개인 자산도 구성원 전체로 흘러간다. 다음 두 절이 그 흐름을 어떻게 관리할 것인가를 다룬다.

개인 하네스가 먼저다

이 자료에서 반전이 가장 강한 대목은 팀을 위해 만들다가 방향을 바꾼 경험이다. 결론은 우선순위 세 줄로 정리된다.

전제가 되는 관찰 — '내가 일하는 방식'과 '팀이 일하는 방식'이 완벽히 일치하지 않으며 100% 공통 분모는 존재하지 않는다 — 은 앞 시리즈의 마지막 편에 원문 그대로 실려 있다. 여기서는 그 관찰이 거버넌스 설계로 어떻게 이어지는지만 이어 간다.

그래서 거버넌스는 대칭이 아니다

안정성과 속도를 동시에 확보하려면 승인 절차를 양쪽에 똑같이 걸지 않는다.

전사 표준화를 서두르면 채택률이 죽고, 방치하면 품질이 죽는다. 비대칭이 답이다.

오른쪽 열에서 유일하게 강제되는 것은 세 가지뿐이다 — 자동 diff, 영향 범위 주석, 15분 롤백. 승인자도 주기도 없다. 대신 되돌릴 수 있게만 만들어 두고, 되돌릴 수 없는 것(보안·비즈니스 로직·핵심 가치)만 왼쪽 열의 4층위 게이트로 보낸다. 판단 기준은 중요도가 아니라 가역성이며, 이 기준이 뒤에 승인 게이트 설계에서 다시 나온다.

2026년 엔터프라이즈의 실제 위치

도입 사례로 제시된 것들이다. 모두 각 기업이 자사 사례로 발표한 값이다.

이 절의 핵심은 78% → 14%라는 64포인트 격차와, 실패의 89%가 비기술 요인이라는 두 숫자다.

두 숫자를 붙이면 진단이 나온다. 파일럿에서 프로덕션으로 넘어가지 못하는 이유가 모델 성능이 아니라 운영·거버넌스라는 것이다. 실무적 함의는 승인 기준에 있다 — PoC 성공을 성과로 보고하는 관행이 위험하고, PoC 승인 단계에서 권한·승인·감사·롤백 네 가지를 함께 설계하지 않으면 그 PoC는 64포인트 격차의 왼쪽에 남는다.

준비할 것 셋

세 항목에 붙은 정량 기준이 각각 다르다 — 첫째는 규모(100 케이스), 둘째는 기간(3~4개월), 셋째는 사람이다. 셋 다 착수 전에 정할 수 있는 값이라는 것이 이 표의 실용성이고, "충분히 준비되면 시작하겠다"는 무기한 연기를 막는 장치이기도 하다.

한 장 요약은 이렇다.

모델은 상품이 되고, 동작하는 방식이 경쟁 우위가 된다. Harness Engineering은 모델이 동작하는 방식을 설계하는 일이고, 그 방식이 진화 가능해야 쓸수록 좋아지며, 엔터프라이즈의 경쟁 우위는 이 진화 루프에 있다.

그리고 액션 포인트는 둘로 좁혀진다 — 기술보다 조직(역할 지정), 그리고 흡수되지 않을 자산(조직 데이터·평가셋·조직 구조·도메인 특화 SKILL). 두 번째가 특히 판단 기준으로 쓸모 있는데, 다음 세대 모델이나 다음 버전 제품이 흡수해 버릴 것에는 장기 투자하지 않는다는 뜻이다. 프롬프트 최적화는 흡수되고, 우리 도메인의 평가셋은 흡수되지 않는다.

조직에 옮기면 무엇이 되는가

여덟 행 중 다섯이 **"먼저 만들지 말고 먼저 재라"**는 형태다(2·3·4·5·7). 세 번째 열에 신규 구축이 들어간 행은 하나도 없고, 전부 인벤토리·분해·분류·연결이다. 하네스 도입이 실패하는 지점이 구축이 아니라 그 앞이라는 진단이 표 전체에 깔려 있다.

여기까지가 하네스 쪽이다. 상시와 조건부로 컨텍스트를 나누고, 하네스만 바꿔도 성능이 오르고, 그 하네스가 스스로 갱신되며, 갱신에는 비대칭 거버넌스가 붙는다.

그런데 이 모든 것은 사람이 앉아서 호출하는 것을 전제한다. 하네스가 아무리 좋아도 매번 프롬프트를 쳐야 한다면 처리량은 여전히 사람의 시간에 묶인다. 그리고 실제 데이터는 더 냉정하다 — 개발자는 업무의 60%에 AI를 쓰지만 **완전히 위임 가능한 일은 0~20%**에 불과하다. 다음 편에서 그 간극의 정체와, 사람 없이 도는 시스템이 성립하려면 무엇이 먼저 있어야 하는지를 본다.