담장 너머의 하네스 워 — 세 거인은 왜 서로 다른 곳에 해자를 파는가

3줄 요약 • 우리가 열여섯 편 동안 정원 안에서 '하네스'라 불러 온 그 계층이, 지금 산업에서 가장 뜨거운 전장의 이름이 되었다. 다음 국면의 질문은 "누가 가장 강한 모델을 갖는가"가 아니라 **"누가 모델을 교체하면서도 업무 품질·보안·기억·평가를 계속 보유하는가"**다. • OpenAI와 Anthropic은 모델이 가장 잘 작동하는 운영 환경을 자기 생태계 안에 두려 하고(통합형), Microsoft는 하네스를 제품 스택에 남기고 모델을 업무별로 갈아 끼우려 한다(분리형) — 서로 다른 곳에 파는 해자(垓字, 성 둘레의 방어용 도랑)는 서로 다른 소유권 전략이다. • 그리고 이 지도에서 대부분의 조직이 새겨야 할 결론은 자체 모델이 아니라 자체 판단권 — 도메인 평가기, 컨텍스트 계약, 권한 경계, 관찰성과 비용 원장, 교체 가능한 연결부의 다섯 계층이다.

1. 담장 너머에서 전쟁의 이름을 들었다

당신의 팀이 이렇다면 이 글은 당신을 위한 것이다. 에이전트를 만들기로 했다. 그런데 첫 회의부터 막힌다 — 어느 회사의 SDK(Software Development Kit)에 올라탈 것인가. 벤더가 주는 에이전트 프레임워크에 얼마나 맡기고, 무엇을 직접 쥐고 있어야 하는가. 지금 편한 길을 골랐다가 1년 뒤 모델 지형이 바뀌면, 우리가 쌓은 것 중 무엇이 남는가.

이 시리즈는 열여섯 편 동안 담장 안의 이야기였다 — 글쓰기라는 업무에 지식·에이전트·엔진의 3층을 심고, 게이트와 로그와 회고를 쌓아 온 우리 정원의 기록. 그런데 담장 밖에서 같은 단어가 들리기 시작했다. 하네스(harness). 우리가 정원의 뼈대를 부르던 그 이름이, OpenAI·Anthropic·Microsoft가 각자의 해자를 파는 전장의 이름이 되어 있었다. 이번 편은 시리즈 최초의 정찰이다 — 씨앗 글 하네스 워 다음의 전장: OpenAI·Anthropic·Microsoft는 왜 서로 다른 곳에 해자를 파는가를 안내도 삼아, 세 회사의 공식 자료를 따라 담장 밖 지형을 읽는다.

16편의 예고를 기억하는 독자를 위해 정직하게 적어 둔다. 예고했던 스킬 내장 Eval(평가, evaluation) 장착 실전기는 이번 편이 아니다 — 그러나 이월이 아니라 전제다. 무엇을 장착할지는 지형을 알아야 정해진다. 그리고 미리 말해 두면, 이 정찰의 보고서는 뜻밖의 방식으로 우리의 장착 계획을 승인해 줄 것이다(7절).

2. 모델은 엔진이 되었다 — 하네스의 산업 정의

씨앗 글의 출발점은 관점의 전환이다. 에이전트를 만드는 회사에게 모델은 이제 완성품이 아니라 추론 엔진이다. LLM(Large Language Model, 대규모 언어 모델) 하나는 문장을 만들고 다음 행동을 제안할 뿐, 실제 업무는 모델 호출 한 번으로 끝나지 않는다. 파일을 읽고, 사내 데이터를 검색하고, 권한을 확인하고, 도구를 실행하고, 실패를 복구하고, 결과가 맞는지 검증해야 한다. 세션이 길어지면 무엇을 기억하고 무엇을 버릴지도 정해야 한다.

이 전체를 책임지는 바깥 계층이 하네스다 — 도구, 메모리, 컨텍스트 관리, 권한 승인, 샌드박스(sandbox, 격리 실행 환경), 관찰성(observability, 실행 과정의 기록과 추적), 평가, 재시도 정책, 그리고 모델 라우팅(routing, 요청을 어느 모델로 보낼지의 배정)까지. 에이전트는 모델 그 자체가 아니라, 모델과 이 제어 계층(control plane)이 결합해 만든 실행 단위다.

사용자 업무
    │
    ▼
[하네스 — 제어 계층]
    ├─▶ 프런티어 모델
    ├─▶ 특화 모델
    ├─▶ 소형·로컬 모델
    ├─▶ 도구와 데이터
    └─▶ 평가 (결과는 제어 계층으로 되먹임 ↺)

엔진이 바뀌어도 사용자는 기억을 잃지 않아야 하고, 권한 정책은 유지되어야 하며, 같은 업무는 같은 품질로 끝나야 한다 — 당연해 보이는 이 요구가 왜 전장이 되는가. 이 계층을 누가 소유하느냐에 따라, 모델이 바뀔 때 무엇이 남는지가 달라지기 때문이다. 세 거인의 답이 갈리는 지점이 정확히 여기다.

3. 모델 곁에 하네스를 — OpenAI와 Anthropic의 해자

Anthropic은 장기 실행 에이전트를 위한 하네스 설계에서 이 계층의 설계 철학을 공개했다. 몇 시간에서 며칠에 걸친 작업을 여러 컨텍스트 윈도에 걸쳐 이어 가려면, 첫 실행에서 환경을 구조화하는 초기화 에이전트와 세션마다 증분 진행을 쌓는 실행 에이전트를 분리하고, 진행 상태를 대화 기억이 아니라 외부 산출물(작업 목록, 파일, 버전 관리, 테스트 리포트, 핸드오프 노트(인수인계))에 남기라는 것. 생성과 평가를 별도 에이전트로 나누라는 조언도 명시적이다 — 자기 작업을 스스로 채점하는 에이전트는 낙관 쪽으로 치우친다.

그리고 이 설계 전체를 관통하는 전제가 흥미롭다. 하네스의 각 부품은 "모델이 아직 혼자 못 한다"는 가정 위에 서 있고, 모델이 강해질수록 그 가정은 제거 대상이라는 것 — 처음에는 작게 만들고, 실패가 확인된 부분에만 구조를 추가하라.

OpenAI는 2026년 4월 Agents SDK의 다음 진화를 발표하며 더 넓은 운영면(에이전트 운영에 필요한 기능 표면)을 제시했다. 네이티브 샌드박싱으로 에이전트의 파일·도구·시스템 접근을 격리하고, 구성 가능한 메모리·승인·추적(트레이싱) 기능을 묶었다고 소개했다. 가장 주목할 대목은 인디스트리뷰션 하네스(in-distribution harness) 논지다 — 프런티어 모델(frontier model, 당대 최전선의 최고 성능 범용 모델)이 학습 과정에서 익숙해진 방식의 하네스 위에서 돌릴 때, 길고 다단계이고 도구가 많은 작업의 신뢰도가 올라간다는 것. 도구 프로토콜은 열어 두더라도, 모델이 가장 잘 작동하는 운영 환경 자체는 자사 생태계 안에 두겠다는 메시지로 읽힌다.

두 회사의 결은 다르다 — 한쪽은 "작게 시작해 필요한 곳에만"의 조립 철학이고, 다른 쪽은 "모델에 맞춰 미리 재단된"의 워크벤치(workbench, 미리 갖춰진 작업대) 철학이다. 그러나 해자를 파는 자리는 같다. 하네스는 부속품이 아니라 모델의 성능·안전·기업 거버넌스를 한데 묶는 핵심 제품 계층이고, 그 계층은 모델 곁에 있어야 한다는 것.

4. 제품 곁에 하네스를 — Microsoft의 반대편 베팅

Microsoft는 반대편에 판다. 2026년 7월 사티아 나델라가 "Frontier Diffusion & Control"이라는 제목으로 공개한 메시지의 핵심은 거창한 모델 독립 선언이 아니라 경제학이다 — 추론 비용이 생기면서 소프트웨어에 실질적인 한계비용이 돌아왔고, 모든 작업에 가장 큰 모델을 쓰는 방식은 오래갈 수 없다는 것.

실제 움직임은 양손이다. 한 손으로는 GPT-5.6을 Microsoft 365 Copilot의 기본 모델로 채택했다고 발표했고(2026년 7월 초), 다른 손으로는 자체 MAI(Microsoft AI) 모델을 GitHub Copilot과 Excel의 실트래픽에 라우팅하기 시작했다. Microsoft의 발표에 따르면 일반적인 Excel 업무에서 MAI 모델이 GPT-5.6과 대등한 품질을 내면서 비용 효율이 좋고, 외부 모델 대비 최대 89%까지 비용을 줄였다고 한다 — 분명히 해 두자. 이 수치들은 Microsoft가 공개한 자사 제품 지표이지 독립 벤치마크가 아니다. 씨앗 글의 해석대로, 이것을 보편적 모델 서열표가 아니라 대규모 제품에서의 라우팅 전략 신호로 읽어야 한다: 교체 기준은 모델의 절대 순위가 아니라 특정 업무에서의 품질·지연 시간·비용 조합이라는 신호.

이 전략이 성립하는 이유는 트래픽의 규모다. Excel·Outlook·Copilot처럼 한 요청당 비용 차이가 작아도 수억 건이 반복되는 제품에서는, 그 차이가 곧바로 원가와 마진이 된다. MAI로 충분한 업무부터 내부 모델로 넘기고, 깊은 추론이 필요한 업무에는 외부 프런티어 모델을 남겨 두는 구조 — 그리고 이 구조가 돌수록 강해지는 플라이휠(flywheel, 회전할수록 가속되는 바퀴)이 있다.

제품 트래픽 ─▶ 실행 기록 ─▶ 업무별 평가
  ─▶ 모델 라우팅 ─▶ 비용·품질 개선
  ─▶ (다시 제품 트래픽으로 ↺ 플라이휠)

여기서 Microsoft가 정말 지키려는 것이 보인다. MAI 모델 하나가 아니다. 업무 컨텍스트, 사용자 메모리, 권한 체계, 도구 연결, 평가 데이터, 배포 채널을 가진 제품 하네스 — 모델은 그 위에서 갈아 끼우는 엔진이다.

5. 소유권의 지도 — 두 해자의 결정적 차이

이 차이는 구현상의 취향이 아니라 소유권의 문제다. 씨앗 글의 대조를 지도로 옮긴다.

구분	벤더 통합형 하네스 (OpenAI·Anthropic)	분리형 하네스 (Microsoft)
중심 질문	이 모델이 가장 잘 작동하는 운영 환경은 무엇인가	이 업무에 비용 대비 가장 좋은 모델은 무엇인가
하네스의 위치	모델·SDK 생태계 곁	제품과 업무 데이터 곁
모델 교체	가능하지만 성능·운영 방식이 함께 흔들릴 수 있다	라우터가 교체를 흡수하도록 설계
축적되는 자산	모델 사용 방식과 플랫폼 경험	제품별 컨텍스트·평가·권한·실행 로그
잠금의 중심	SDK, 워크벤치, 배포·거버넌스 계층	Microsoft 365·GitHub·Azure 등 업무 스택

분리형에서 모델은 호출 가능한 부품이다. 모델이 중요하지 않다는 말이 아니다 — 모델의 능력은 여전히 상한선을 정한다. 요점은 제품 품질이 모델 교체와 함께 0으로 리셋되지 않게 만든다는 것이다. 기업용 문서 에이전트의 답변 품질은 모델 파라미터만으로 결정되지 않는다. 사용자의 직무, 문서 권한, 최근 프로젝트, 승인 규칙, 검색 범위, 인용 형식, 평가 기준이 함께 작동한다. 이 맥락을 하네스가 보유하면, 엔진을 바꿔도 에이전트의 운영 지식은 남는다.

경고 하나를 지도 여백에 적어 둬야 한다. '멀티모델'이라는 말만으로 잠금 — 락인(lock-in, 특정 벤더에 묶여 이탈 비용이 커지는 상태) — 이 사라지지는 않는다. 라우터, 평가 데이터, 권한 체계, 업무 데이터, 배포 채널을 플랫폼이 쥐면, 잠금은 모델에서 제품 스택으로 이동할 뿐이다. 고객 입장에서 단일 모델 의존보다 나을 수는 있지만, 그만큼 업무 스택의 운영면에 더 깊이 묶일 수도 있다 — 해자는 사라진 것이 아니라 자리를 옮겼다.

6. 모델이 싸질수록 하네스는 비싸진다

모델 비용이 내려가면 하네스는 덜 중요해질 것 같지만, 실제로는 반대다. 싸진 추론은 더 많은 에이전트 호출, 더 긴 작업, 더 넓은 도구 사용을 유도한다. 그러면 비용의 중심은 토큰 단가에서 이런 항목들로 이동한다.

• 어떤 요청을 어느 모델에 보낼지 판단하는 라우팅 오류의 비용
• 너무 많은 컨텍스트를 넣어 발생하는 낭비
• 권한 오류와 샌드박스 실패의 복구 비용
• 잘못된 결과를 늦게 발견해 생기는 재작업 비용
• 평가·감사·추적을 기업 수준으로 유지하는 운영 비용

낯익은 무늬다. 15편에서 우리는 "실행이 싸질수록 병목은 결정으로 이동한다"고 적었다 — 산업 규모에서는 같은 이동이 "추론이 싸질수록 비용은 제어로 이동한다"로 나타난다. 10편의 언어로는, 프롬프트 한 번의 품질이 아니라 루프 전체의 품질이 조직의 성적표가 되는 것이다. 그래서 Microsoft의 라우팅은 단순한 원가 절감기가 아니라, 제품 데이터로 더 나은 라우팅·평가·컨텍스트 구성을 학습하는 플라이휠이고 — 그래서 하네스 계층의 전쟁은 모델이 싸질수록 오히려 격렬해진다.

7. 자체 모델이 아니라 자체 판단권 — 그리고 우리 정원의 답안지

그렇다면 이 전쟁에서 우리 같은 팀은 무엇을 해야 하는가. 씨앗 글의 답은 명료하다. 모든 회사가 MAI 같은 자체 모델을 만들 필요는 없다. 대부분의 조직이 직접 보유해야 할 것은 훨씬 작고 구체적인 계층 — 자체 판단권이다. 다섯 가지로 정리된다.

1. 도메인 평가기 — 좋은 결과가 무엇인지, 벤더의 일반 평가가 아니라 우리 업무의 기준으로 판정한다.
2. 컨텍스트 계약 — 어떤 데이터가 어떤 역할에 어떤 권한으로 들어가는지 명시한다.
3. 도구·권한 경계 — 읽기·쓰기·배포·결제 같은 행동은 모델의 자신감이 아니라 정책과 승인으로 통제한다.
4. 관찰성과 비용 원장 — 모델별 성공률·수정률·지연·비용을 같은 단위로 비교할 수 있게 기록한다.
5. 교체 가능한 연결부 — 프롬프트, 도구 호출, 평가 입력을 특정 SDK의 내부 객체에 묶지 않는다.

이 다섯을 갖추면 OpenAI든 Anthropic이든 Microsoft든 오픈소스든, 어느 쪽이 어떤 작업에서 유리해졌는지 스스로 판단할 수 있다. 반대로 이 계층이 없으면, 씨앗 글의 표현을 빌리면 멀티모델은 "여러 API(Application Programming Interface) 키를 가진 단일 벤더 의존"일 뿐이다.

정찰을 마치고 담장 안으로 돌아와, 이 다섯 계층을 우리 정원의 열쇠걸이에 하나씩 걸어 본다. 시리즈를 처음 만난 독자라면 이 문단의 낯선 이름들은 그냥 지나쳐도 좋다 — 요점은 하나다: 글쓰기라는 작은 업무의 정원에도 다섯 계층 중 세 개가 이미 자라 있었다는 것. 놀랍게도 — 그리고 조심스럽게 적자면 — 익숙한 모양들이다. 도메인 평가기의 자리에는 3인 검수의 9축 루브릭과 16편이 베팅한 스킬 내장 Eval이 있고, 컨텍스트 계약의 자리에는 브리프와 화자 게이트가, 권한 경계의 자리에는 승급 게이트와 원탁의 소집 규율이, 관찰성의 자리에는 아흔여덟 장의 로그 서고가 있다. 교체 가능한 연결부도 절반은 있다 — 원고의 단일 출처는 처음부터 특정 도구가 아니라 마크다운 파일이었다. 우리가 산업의 지도를 보고 정원을 지은 것이 아니다. 같은 문제를 작게 앓으면 같은 모양의 답이 나오는 것이다.

그러나 자랑으로 끝내면 정찰이 아니다. 열쇠걸이의 두 고리는 비어 있다. 우리에게는 모델별 성공률·비용을 같은 단위로 비교하는 비용 원장이 없고 — 로그는 사건을 적지만 원가를 적지 않는다 — 업무별로 엔진을 고르는 모델 라우팅은 개념조차 없다(이 정원은 단일 모델 위에서 돈다). 담장 밖 지도가 우리 정원의 다음 공백을 알려준 셈이다. 그리고 확인 하나 — 16편의 회고가 로그를 근거로 골랐던 두 개의 베팅 — 등재 협곡 해소(검수가 남긴 개선 제안이 규약 파일로 등재되지 못한 채 잠드는 간극을 없애는 일)와 체크리스트의 기계화 — 는 이 지도의 첫 번째 칸, 도메인 평가기에 해당한다. 안에서 로그가 고른 것을 밖에서 지도가 승인했다. 정찰이 장착을 정당화하는 순간이다.

8. 마치며 — 모델이 바뀌어도 남는 것

지도를 접자. OpenAI와 Anthropic은 모델이 가장 강해지는 작업 환경을 하네스 안에 넣으려 하고, Microsoft는 제품 하네스를 중심에 두고 모델을 바꾸려 한다. 한쪽은 모델과 하네스의 결합에서 성능을 얻고, 다른 쪽은 하네스와 제품의 결합에서 협상력과 원가 통제력을 얻는다. 어느 쪽이 자동으로 옳은 것은 아니다 — 초기 제품이나 복잡한 장기 작업이라면 잘 다듬어진 벤더 하네스가 훨씬 빠른 출발점이다. 그러나 기업의 핵심 업무로 갈수록, 메모리와 권한과 평가와 추적과 비용 판단을 남의 블랙박스에만 둘 이유는 줄어든다.

그러니 씨앗 글의 마지막 질문을 그대로 독자에게 돌려 드린다 — 다음 벤더 미팅에서, 다음 SDK 선정 회의에서 물어야 할 것은 "우리는 어떤 모델을 쓸 것인가"가 아니다. "모델이 바뀌어도, 무엇이 우리 손에 남는가." 그 답이 다섯 계층 중 몇 개를 가리키는지 세어 보면, 지금 조직이 전장의 어디에 서 있는지 보인다.

다음 편은 담장 안으로 완전히 돌아온다. 정찰이 승인해 준 그 장착 — 16편의 로그가 지목한 자리(검수에서 여섯 번 차단된 약어 축 같은)에 실행되는 센서를 다는 스킬 내장 Eval 실전기다. 지형은 알았고, 열쇠걸이의 빈 고리도 확인했다. 이제 첫 번째 열쇠를 우리 손으로 깎을 차례다.

정원 은유로 맺는다. 담장 밖에서는 성채들이 해자를 파고 있었다. 담장 안으로 돌아와 우리가 확인한 것은, 정원의 해자는 물길의 폭이 아니라 열쇠걸이에 걸린 열쇠의 수라는 것이다. 엔진은 언제든 떠나고 도착한다 — 서고와 울타리와 물길이 남아 있는 한, 정원은 정원이다.

Praemonitus, praemunitus — 미리 아는 자가 미리 무장한다. 정찰은 끝났다.

하네스의 이야기는 계속됩니다. 감사합니다 💙

참고 자료

씨앗 글과 원작

• 하네스 워 다음의 전장 — OpenAI·Anthropic·Microsoft는 왜 서로 다른 곳에 해자를 파는가 (웹노리 기고, 본편의 씨앗)
• 하네스 워 — OpenAI vs Anthropic, 그리고 우리가 준비해야 할 것 — 씨앗 글이 확장하는 원작

1차 자료 (세 회사의 공식 발표)

• Anthropic — Effective harnesses for long-running agents — 초기화/실행 분리, 외부 산출물, 생성·평가 분리, 컨텍스트 리셋
• Anthropic — cwc-long-running-agents (GitHub) — 장기 실행 하네스 참조 구현
• OpenAI — The next evolution of the Agents SDK (2026-04) — 네이티브 샌드박싱, in-distribution harness
• Microsoft AI — Hill-Climbing MAI models for GitHub Copilot and Excel — MAI 실트래픽 라우팅

보도 (Microsoft MAI 전략 맥락)

• VentureBeat — Microsoft launches new in-house AI models it says cut costs up to 89% versus OpenAI (2026-07) — 비용 절감 주장 보도
• Firstpost — Satya Nadella outlines Microsoft's MAI strategy as Excel model matches GPT-5.6 at lower cost (2026-07) — "Frontier Diffusion & Control" 메시지와 Excel 대등 주장 보도
• ※ Excel 품질·비용 수치는 Microsoft가 공개한 자사 제품 지표로, 독립 벤치마크가 아니다 — 본편은 이를 모델 서열이 아니라 라우팅 전략의 신호로 해석했다

시리즈 내부 연결

• 10편: 루프 엔지니어링으로의 전환 — 루프 전체의 품질이 성적표
• 15편: 원탁은 아무 때나 열리지 않는다 — 병목의 이동, 이 편 6절의 원형
• 16편: 아흔여덟 장의 기억 — 로그가 고른 베팅, 이 편 7절이 승인하는 그것