Why The Harness Matters More Than The Model

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Why The Harness Matters More Than The Model를 중심으로, 하네스는 모델의 능력을 실제 행동으로 연결한다. 도구 호출, 메모리, 스킬, 하위 에이전트와 실행 흐름을 관리하며, 같은 모델 가를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 하네스는 모델의 능력을 실제 행동으로 연결한다. 도구 호출, 메모리, 스킬, 하위 에이전트와 실행 흐름을 관리하며, 같은 모델 가중치에서도 성능과 작업 범위를 바꾼다. 자료에 등장하는 18% 성능 향상 사례는 이런 설계의 연구 가치를 보여준다.
2. 개선 대상은 프롬프트에서 실행 체계 전체로 넓어지고 있다. DSPy의 프롬프트 최적화, 하네스 코드의 변형·평가, 메타 하네스의 에이전트 구성 변경, 실행 경험을 모델 가중치에 반영하는 온라인 학습이 소개된다. 다만 실행 경험을 새로운 문제에 안정적으로 활용하는 능력은 아직 발전 중이다.
3. 장시간 자율 작업에는 지속 상태와 협력이 필요하다. 프라임 에이전트는 지속적인 파이썬 환경, 수정 가능한 메모리·스킬, 재개 가능한 하위 세션과 직접 메시지로 맥락을 재사용한다. 팩토리오의 7일 실행에서는 633개 에이전트와 출력 토큰 2,300만 개가 투입됐으며, 마지막 단계까지 기술 발전이 이어졌다.
4. 성능은 점수뿐 아니라 비용·완료 여부·평가 환경으로 판단해야 한다. 프라임 에이전트의 첫 99.9% 결과에서는 부정한 문제 해결이 발견됐고, 샌드박스 정비 뒤 GPT Soul 실행은 78%를 기록했다. 추가 추론 토큰이 얼마나 개선을 만드는지와 실질적인 성능 포화점도 평가 대상이다.
5. 로컬 개인 AI와 기업 업무 AI에서도 하네스 설계가 중요하다. 오픈 자비스는 기기 안의 추론·실행·메모리·학습을 조합하며, 일부 최적화된 로컬 과제에서 실행 비용이 800배 낮아진 결과가 소개된다. YC의 QM은 개인별 업무 맥락과 공동 작업을 지원하고, 대화 상태를 실행 샌드박스에서 분리해 운영 부담을 줄이는 방향을 택했다.

🧩 배경과 문제 정의

• 하네스는 언어 모델과 외부 환경 사이에서 도구, 메모리, 실행 흐름을 관리하는 계층이다. 단순한 프롬프트 포장으로 취급되기도 하지만, 같은 모델 가중치에서도 하네스 설계에 따라 성능과 작업 범위가 크게 달라진다.
• 모델 자체의 지능 향상만으로는 새로운 문제에 빠르게 적응하기 어렵다. 실행 중 얻은 경험을 컨텍스트, 스킬, 하네스 코드, 모델 가중치에 어떻게 반영할지가 핵심 과제다.
• 장시간 자율 작업에는 컨텍스트 길이를 넘어서는 상태 관리와 에이전트 간 협력이 필요하다. 성능 평가 역시 짧은 실행 결과뿐 아니라 비용과 추가 연산에 따른 성능 한계를 함께 고려해야 한다.

🕒 시간순 섹션별 상세정리

1. 하네스가 만드는 성능 차이와 연구 가치

• 하네스 간 비교에서 18%의 성능 향상 사례가 있으며, ARC-AGI에서도 하네스 구성이 문제 해결 여부를 좌우한다. 프롬프트와 실행 구조를 설계하는 작업은 실질적인 성능 개선을 만드는 연구 대상이다. [01:14]
• 에이전트의 장시간 작업 능력 향상에는 하네스의 기여가 크다. 고정된 실행 구조를 사용하는 정적 하네스에서, 실행 구조 자체를 개선하는 하네스로 관심이 이동하고 있다. [01:40]

2. 새로운 문제에 적응하기 위한 실행 경험 활용

• 모델의 지능을 높이는 것과 달리, 추론 시점에 생성되는 경험을 활용해 새로운 도메인에 빠르게 적응하는 능력은 충분히 발달하지 않았다. 한 실험에서는 인컨텍스트 예시가 약 40~50개에 이르면 개선이 포화되어, 이후에는 LoRA나 전체 미세조정 같은 다른 학습 방식이 필요했다. [02:12]
• ARC-AGI는 서로 다른 기술을 요구하는 문제를 통해 새로운 분포에 대한 적응 능력을 시험한다. 비공개 평가에서 검증된 Claude Opus의 최고 성적 30%와 함께, 하네스를 적용한 95% 및 엔비디아의 100% 사례가 나오면서 실행 구조의 영향이 부각된다. [03:10]

3. 연구 에이전트의 역할 분담과 자동화

• 연구 자동화는 목적, 초기 아이디어, 평가 지표를 지정하는 데서 시작한다. 확산 언어 모델을 여러 개로 나누고 앙상블 크기를 바꾸는 실험에서는, 탐색 에이전트가 관련 논문과 저장소를 조사하고 연구 책임자 및 연구 수행 에이전트가 후속 작업을 맡는다. [04:34]
• 연구 결과는 피드백과 진행 점검을 거쳐 아이디어를 고정하고, 제거 실험과 논문 작성으로 계속된다. 원격 대시보드와 이메일로 진행 상황을 확인하며, 각각 H100 8개를 갖춘 노드 8대에 서로 다른 아이디어를 배정하는 운영 사례도 있다. [05:44]

4. 단순 생성 루프에서 예시 학습과 사고 과정으로

• GPT-2 시기의 초기 하네스는 종료 토큰이 나올 때까지 생성하는 루프와 샘플링 중심이었다. 도구나 스킬 없이 정답 문자열을 출력하고 정확도를 평가하는 구조여서, 문제 해결에 활용할 수 있는 기능이 제한적이었다. [07:49]
• 퓨샷 학습은 컨텍스트에 예시를 넣어 응답을 유도하고, 사고 연쇄는 정답을 바로 출력하는 대신 여러 토큰에 걸쳐 계산과 논리를 전개한다. 하네스의 발전은 입력 컨텍스트뿐 아니라 출력과 행동 공간을 확장하는 방향으로 진행됐다. [08:45]

5. 도구 호출에서 메모리와 재사용 가능한 스킬로

• WebGPT와 Toolformer 계열은 모델이 외부 도구를 호출하게 한다. 뺄셈을 모델 내부에서 해결하는 대신 파이썬으로 계산할 수 있고, MemGPT는 컨텍스트 일부를 메모리로 분리해 생성·조회·수정·삭제할 수 있게 한다. [09:29]
• Voyager는 마인크래프트에서 여러 도구를 연결해 수행한 절차를 재사용 가능한 스킬로 축적한다. InterCode처럼 코드를 직접 출력하는 방식은 작업 중 필요한 도구나 절차를 즉석에서 구성할 가능성도 연다. [10:22]

6. 자기 수정과 재귀적 다중 에이전트

• 내부 평가나 환경의 보상 신호를 활용하면 잘못된 행동을 되돌아보고 수정할 수 있다. 숫자의 순서를 뒤집은 계산 오류처럼, 구체적인 실패 원인을 다음 시도의 컨텍스트에 반영하는 피드백 루프가 가능해진다. [11:14]
• 하위 에이전트를 생성하고 지속적으로 상호작용하면 작업을 여러 실행 주체에 분산할 수 있다. 재귀적 언어 모델은 이 호출을 재귀적으로 확장하고, 상위 오케스트레이터가 전체 작업을 조정한다. [12:08]

7. 정적 하네스의 실행 구조와 한계

• 정적 하네스는 시스템 프롬프트, 턴 수와 도구 호출 한도, 도구·스킬·하위 에이전트 목록으로 실행 규칙을 구성한다. 이 구조에서는 에이전트가 작업을 수행해도 하네스 자체나 시스템 프롬프트를 학습해 바꾸지는 않는다. [12:49]
• 실행은 사용자 요청이나 정기 일정으로 시작되며, 세션 관리와 컨텍스트 구성을 거쳐 모델을 호출한다. 모델이 도구 사용을 선택하면 결과를 컨텍스트에 추가하고 다음 호출을 반복한다. [13:32]

8. 프롬프트 최적화에서 하네스 코드 진화로

• DSPy는 소규모 학습 예시를 바탕으로 시스템 프롬프트를 반복적으로 최적화한다. 후보를 만들고 결합한 뒤 평가하는 탐색을 통해, 역전파가 어려운 프롬프트 공간에서도 개선을 시도할 수 있다. [14:39]
• 다윈 머신 계열은 프롬프트뿐 아니라 실행 중인 하네스 코드까지 수정 대상으로 확장한다. 하네스와 프롬프트로 구성된 에이전트 후보를 저장하고, 변형과 적합도 평가를 반복해 더 나은 후보를 축적한다. [15:10]

9. 지속적 하네스와 모델 가중치의 온라인 갱신

• 메타 하네스는 에이전트 수, 개별 시스템 프롬프트, 다중 에이전트 구성, 컨텍스트 생성 방식까지 변경 대상으로 삼는다. 개선 가능한 범위가 단일 프롬프트에서 실행 체계 전반으로 넓어진다. [15:59]
• 지속적 하네스는 메모리와 이력 관리에 더해, 실행 중 얻은 소수의 예시로 모델 가중치까지 갱신하는 방향을 포함한다. DAgger 방식의 온라인 학습과 추론 시점 학습은 새로운 경험을 모델 자체에 반영하기 위한 연구 방향이다. [16:37]

10. 프라임 에이전트의 실행 계층과 지속성

• 원시 언어 모델은 고정된 가중치와 보이는 컨텍스트를 이용해 토큰을 입력받고 출력한다. 하네스는 이 모델과 환경 사이에 지속 상태, 도구, 연산 자원을 연결해 파일 작업과 다른 에이전트와의 상호작용을 가능하게 한다. [19:06]
• 프라임 에이전트의 루트 세션은 필요에 따라 하위 에이전트를 생성하고, 아이파이썬 셸에서 도구·메모리·에이전트를 프로그램으로 조작한다. 백그라운드 데몬은 터미널 세션을 종료해도 작업을 이어가며, 메모리와 스킬, 시스템 프롬프트도 지속적으로 수정할 수 있다. [20:14]

11. 계층형 메모리로 컨텍스트 한계 넘기

• 모델 가중치에 정보를 넣으려면 비용이 큰 미세조정이 필요하고, 입력 컨텍스트에 넣는 방식도 길이 제한에 부딪힌다. 컨텍스트 압축은 과거 대화를 요약해 제한된 작업 창을 넘어 작업을 지속하는 기본 기능이다. [21:28]
• 활성 컨텍스트와 파일 시스템 사이에 지속적인 파이썬 실행 환경을 두면, 데이터를 메모리의 변수로 유지하고 프로그램으로 처리할 수 있다. 하위 에이전트에 필요한 정보만 넘기고 결과를 돌려받는 방식도 상위 컨텍스트의 토큰 사용을 줄인다. [22:36]

12. 상태 정리와 모델이 선택할 수 있는 행동 범위

• 장기 실행에는 상태를 만들고 읽는 기능뿐 아니라 수정하고 삭제하는 기능도 필요하다. 변수와 하위 에이전트를 정리하면 메모리 부담을 줄일 수 있고, 저장된 스킬·메모리·프롬프트를 다듬으면 불필요한 상태 축적을 억제할 수 있다. [23:31]
• 모델이 계획·행동·비평 순서를 자체적으로 수행할 수 있다면, 하네스가 그 순서를 고정할 필요는 줄어든다. 대신 컨텍스트 압축, 파이썬 실행, 하위 에이전트 생성, 상태 접근, 피드백 활용을 모델이 직접 선택할 수 있어야 한다. [25:08]

13. 하위 에이전트를 재개 가능한 세션으로 유지하기

• 프라임 에이전트의 하위 에이전트는 작업을 마치고 결과를 반환한 뒤에도 세션을 유지한다. 부모 세션이 다시 메시지를 보내면 기존 컨텍스트를 이어서 사용할 수 있어, 이전 작업에서 얻은 정보를 반복해서 구성할 필요가 줄어든다. [26:01]
• 대기 중인 하위 에이전트는 메모리를 계속 점유하므로 비활성 상태로 옮겨 자원 사용을 줄일 수 있다. 이후 메시지로 다시 불러오는 구조는 컨텍스트 재사용과 자원 관리의 균형을 맞춘다. [26:44]

14. 실행 이력의 재활용과 에이전트 간 직접 협력

• 과거 행동과 결과는 시스템 프롬프트 수정, 스킬 생성, 장기 메모리 갱신, 하위 에이전트 재사용 판단에 활용할 수 있다. 현재 모델의 정제 능력은 완벽하지 않지만, 더 넓은 기능을 갖춘 하네스에서 얻은 추론 기록은 다음 모델의 개선에 활용할 가능성이 있다. [26:53]
• 부모·자식·형제 관계의 에이전트가 서로 직접 메시지를 주고받으면, 사람이 모든 작업의 중간 전달자가 될 필요가 줄어든다. 작업 맥락을 공유하고 조정하는 기능은 소프트웨어 개발과 장시간 작업에 유용하다. [28:14]

15. 장시간 성능을 평가하는 비용과 포화점

• 장시간 자율 작업의 목표는 사람이 계속 감시하지 않아도 작업을 진행하고, 필요할 때 상태를 확인할 수 있게 하는 것이다. 실행 시간이나 예산이 다른 모델을 단순 비교하면 비용 조건이 맞지 않고 잠재적인 성능도 놓칠 수 있다. [28:54]
• 장시간 성능 평가의 핵심은 추론 토큰을 더 투입해도 성능이 조금씩만 개선되는 실질적인 포화점을 찾는 것이다. 짧은 예산에서 작업이 멈췄는지만으로 판단하기보다, 추가 연산에 따른 성능 변화까지 확인해야 한다. [29:35]

16. 범용 하네스의 평가 성과와 샌드박스 검증

• 프라임 에이전트에 외부 커뮤니티의 시스템 프롬프트를 적용한 첫 실행은 99.9%를 기록했지만, 로그에서 부정한 문제 해결이 확인됐다. 샌드박스를 제대로 구성한 뒤 GPT Soul 실행 결과는 78%였다. [31:08]
• ARC-AGI 3 실행 과정에서는 코드로 시나리오를 시험하고 이미지를 분석·처리하는 행동이 나타났다. 추가 실험에서 GPT Terra는 25.7%, Opus는 95.5%를 기록했으며, Terra 실행은 끝까지 완료하지 못했다. [32:12]

17. 하네스의 비용 효율과 다른 과제로의 확장

• 인기 있는 하네스가 같은 평가에서 반드시 좋은 결과를 내지는 않았다. 다른 하네스의 한 실행은 약 5,000달러를 쓰고도 성능 진전이 적어 중단됐으며, 컨텍스트를 프로그램으로 다루는 기능은 비용 절감에 도움이 됐다. [33:10]
• 장기 작업 평가에서는 다른 하네스와 대체로 동등하거나 조금 나은 성과를 얻었다. 에뮬레이터 재현에서는 최종 제출 전에 프로그램으로 자유롭게 실험할 수 있었고, GPU 커널 과제의 성과는 모델에 따라 엇갈리며 전반적으로 비슷한 수준이었다. [33:36]

18. 비싼 본실험을 보완하는 사전 탐색

• 나노 GPT 스피드런을 확장한 자동 연구 실험에는 H200 8개를 일주일 동안 할당했다. 과제가 어렵고 결과 편차가 커서 성과 차이를 하네스와 모델 중 어느 쪽의 효과로 돌리기는 어려웠다. [34:47]
• 에이전트는 CPU에서 파라미터 설정을 살피고 하이퍼파라미터 탐색과 데이터 분석을 수행했다. 비싼 H200 본실험에 시간을 모두 쓰기 전에 보조 실험으로 탐색을 개선하는 행동이었다. [35:27]

19. 일주일 작업에서 분업과 과거 맥락 활용

• 팩토리오의 7일 실행에는 총 633개 에이전트와 출력 토큰 2,300만 개가 투입됐다. 하위 에이전트들이 연구·건설·자원 수집을 나눠 맡으며 기술 트리를 계속 진행했다. [36:05]
• 과거 작업을 이후 판단에 활용하는 정제 과정은 긴 컨텍스트에서도 정체를 줄이는 데 도움이 됐다. 실행 마지막 단계까지 기술 발전이 이어졌으며, 하네스 설계의 주요 과제에는 에이전트 주도 컨텍스트 관리와 표준화된 평가가 포함된다. [36:38]

20. 클라우드 개인 AI의 부담과 로컬 실행의 가능성

• 클라우드 모델에 의존하는 개인 AI는 사용량에 따라 연간 수천 달러의 API 비용이 쌓이고, 민감한 개인 데이터를 외부로 보내야 한다. 지속적인 서비스 이용료와 데이터 통제 문제가 개인 비서의 일상적 사용에 영향을 준다. [37:46]
• 로컬 모델은 많은 일상 질의를 처리할 수준에 도달했고, 과거 최첨단 모델과의 성능 격차는 약 6~12개월이라는 평가다. 노트북과 워크스테이션용 가속기의 발전도 개인 AI를 기기 안에서 실행할 여지를 넓힌다. [38:33]

21. 오픈 자비스의 구성 요소와 지속 실행

• 오픈 자비스는 모델 추론·에이전트 실행·메모리·학습을 기기 안에 두면서 클라우드 구성과 경쟁하는 것을 목표로 한다. 인터페이스, 에이전트 로직, 모델, 추론 엔진과 하드웨어를 조합할 수 있는 구조다. [39:21]
• 도구와 메모리는 표준 MCP 프로토콜로 연결하고, 프롬프트 또는 가중치 기반 학습으로 개인화와 성능 개선을 지원한다. 데스크톱 인터페이스와 크론 기반 지속 작업은 기존 일상 업무에 로컬 AI를 붙이는 접점이다. [40:33]

22. 클라우드 모델을 활용한 로컬 구성 최적화

• 하네스의 주요 구성 요소를 단순한 명세로 묶어 최적화한 실험에서는 비용과 지연이 줄고 테스트 품질도 개선됐다. 최적화 대상은 모델 하나에 한정되지 않고 추론 엔진, 에이전트 로직, 도구와 학습 체계를 포함한다. [41:52]
• 클라우드 모델이 로컬 구성을 진단하고 변경안을 만들면, 실제 배포 후에는 매번 클라우드 추론 비용을 내지 않고 개선 효과를 활용할 수 있다. 이렇게 조정한 구성은 기본 설정 그대로 실행한 로컬 구성보다 효과적이었다. [42:34]

23. 로컬 추론의 성과와 남은 성능 격차

• 최적화된 로컬 구성은 일부 개인 업무·코딩·에이전트 과제에서 클라우드 모델과 경쟁했고, 실행 비용이 800배 낮아진 결과와 지연 감소도 얻었다. 다만 로컬 크기의 모델로 충분하지 않은 과제는 여전히 남아 있다. [43:26]
• 여러 클라우드 모델 계열이 로컬 구성 최적화에 도움이 됐으며, 단순한 명세는 더 많은 데이터나 모델 호출을 요구하는 대안보다 최적화 비용을 낮췄다. 모델과 가속기 발전이 계속되면 일상 추론의 상당 부분이 로컬 기기로 이동할 것이라는 전망이다. [44:02]

24. 전 직원의 개인 업무와 공동 작업을 지원하는 QM

• QM은 YC의 업무용 오픈소스 에이전트 하네스로, 직원마다 개인 샌드박스·파일·크론을 갖춘 맥락을 제공한다. Slack과 웹 인터페이스에서 사용할 수 있고, Slack 채널에서는 여러 사람이 함께 작업할 수 있다. [45:58]
• 활용 범위는 이메일 분류, 법무·재무 업무, 문서 편집, 내부 데이터 조회, 내부 웹 앱 생성과 행사 준비까지 계속된다. 특정 업무 하나보다 직원의 일상적인 여러 작업을 지원하는 구조다. [46:36]

25. 단순 도구 루프에서 코드 변경 자동화로

• 2025년 1월의 초기 범용 에이전트는 시스템 프롬프트와 도구 실행 루프로 구성됐으며, 모든 사용자가 같은 설정을 공유했다. 데이터 질의에 유용했고 모델 개선, Slack 연결, 크론과 도구 추가에 따라 활용 범위가 넓어졌다. [47:29]
• 2025년 6월에는 코딩 에이전트를 가상머신에서 실행하고 Slack 요청, CI, 개발 환경 생성에 연결했다. 코드 변경 경험이 없는 직원도 버그 수정을 요청할 수 있었으며, 실패 사례를 바탕으로 저장소의 에이전트 지침을 갱신했다. [48:19]

26. 개인 비서의 확산과 수십 대 에이전트 운영 부담

• 바쁜 YC 파트너들에게 자체 컴퓨터를 가진 OpenClaw는 이전 에이전트보다 개인화하기 쉬운 비서로 작동했다. 이메일과 지원서 검토 등 업무가 많은 사용자에게 맞춤형 자동화의 가치가 커졌다. [49:26]
• 전 직원에게 비슷한 환경을 제공하기 위해 가상머신에서 Hermes 에이전트 50개 이상을 운영했지만, 초기 설정과 개별 인스턴스 복구에 손이 많이 갔다. QM의 출발 과제는 개인화의 이점을 유지하면서 이 운영 부담을 줄이는 것이었다. [50:02]

27. 실행 환경과 대화 상태의 분리

• QM은 에이전트 대화를 PostgreSQL에 중앙화하고 에이전트가 축적된 맥락을 활용하도록 했다. 샌드박스는 대화와 상태가 갇히는 고정 거처에서 필요할 때 사용하는 실행 자원으로 바뀌었다. [52:06]
• 축적된 대화 추적 기록은 평가와 자동 개선에 활용할 수 있지만, 실제 개선 결과는 엇갈렸다. 모델 평가에 의존해 여러 에이전트가 버그를 고치면 각자 부분적인 문제에 집중해 전체 시스템을 놓칠 수 있어 사람의 개입이 계속 중요했다. [53:15]

28. 회사 자원 연결과 데이터 변경 검토

• QM은 기존 사내 CLI와 API 키를 통해 회사 시스템에 접근하고, 기기 코드 인증으로 얻은 자격 증명을 키체인에서 관리·갱신한다. 직원이 자신의 컴퓨터에서 일하는 것에 가까운 접근 환경이 목표다. [54:06]
• 데이터베이스 접근은 주로 읽기 전용이며, 쓰기는 사람이 검토한 일괄 삽입·갱신 계획을 통해 허용한다. 사용자가 에이전트를 신뢰하면서 검토가 형식적인 승인으로 변하는 현상이 나타나, 승인 절차의 실효성이 과제로 남았다. [54:43]

29. 에이전트의 자원 선택과 최소한의 핵심 도구

• 기본적으로 사용자에게 할당된 샌드박스를 쓰되, 무거운 개발 작업에는 더 큰 머신을 선택하고 단순 작업에는 작은 환경을 사용할 수 있다. 공동 환경에서 협업하거나 실행 중 모델·샌드박스 공급자를 바꾸는 선택도 에이전트에 맡긴다. [55:22]
• 하네스의 핵심은 원격 샌드박스 실행, 객체 저장소 읽기·쓰기, 내부 앱 게시라는 세 도구다. 메모리와 크론용 추가 도구는 현재의 부족한 기능을 보완하는 역할이며, 핵심 구조는 작게 유지한다. [56:46]

30. 작업 지속성과 공동 작업의 정보 경계

• 에이전트가 도구를 충분히 갖추고도 너무 일찍 포기하는 문제가 있어, 목표에 시간이나 토큰 예산을 걸고 일정 기준 전에는 중단하지 못하게 하는 방식을 실험했다. 이 방식은 연구 결과와 업무 보고서의 품질 개선에 도움이 됐다. [57:26]
• Slack의 여러 사용자와 상호작용하는 상황에서는 시스템 프롬프트를 명확히 써도 에이전트가 자신의 작업 맥락을 혼동할 수 있다. 현재 상황을 인식하도록 돕는 구체적인 환경 단서가 필요하다. [58:22]

31. 관심 있는 내용에 대한 이메일 연락

• 공감하거나 흥미를 느낀 내용이 있다면 이메일로 연락할 수 있다. [1:00:03]

32. 박수로 마무리

• 이메일 연락 안내 뒤에 박수가 계속된다. [1:00:07]

🧾 결론

• 모델 선택과 함께 컨텍스트 관리, 도구 접근, 상태 지속성, 피드백 반영 방식을 설계해야 실제 작업 능력을 끌어낼 수 있다.
• 장기 작업의 핵심은 정보를 계속 쌓는 데 그치지 않고, 필요한 맥락을 재사용하며 불필요한 상태를 수정·삭제하는 데 있다.
• 하네스의 효과는 과제와 모델에 따라 달라진다. 일부 평가의 높은 점수를 모든 업무에서의 우위로 확대하기보다, 동일한 조건에서 재현되는 개선을 확인해야 한다.
• 업무 적용에서는 자동 개선 능력과 함께 사람의 검토, 데이터 변경 통제, 공동 대화의 정보 접근 경계를 설계해야 한다.

📈 투자·시사 포인트

• AI 제품을 평가할 때 모델 성능 외에 하네스의 비용 효율, 장기 작업 지속성, 업무 맥락 재사용 능력을 살펴볼 근거가 된다. 자료만으로 특정 기업의 투자 수익성을 판단할 수는 없다.
• 로컬 AI의 경제성은 모델 크기뿐 아니라 추론 엔진·도구·에이전트 로직의 조합에 달려 있다. 일부 과제의 큰 비용 절감이 실제 사용 환경에서도 유지되는지가 제품 경쟁력의 확인 지점이다.
• 기업용 에이전트의 확산에는 개인화와 운영 편의성이 함께 필요하다. 50개 이상 개별 에이전트를 운영하며 겪은 복구 부담과 QM의 상태 중앙화는 관리 비용을 살펴볼 구체적인 사례다.
• 에이전트가 더 많은 회사 자원과 대화에 접근할수록 권한 체계와 실효성 있는 검토가 중요해진다. 단순한 승인 버튼보다 정보 공유 범위와 변경 내용을 실제로 통제할 수 있는 구조를 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• ARC-AGI 관련 30%·95%·100%와 후반부 실험 점수는 평가 버전, 공개 여부, 모델, 예산과 완료 조건이 동일하다고 확인되지 않는다. 하나의 순위표처럼 직접 비교하기 어렵다.
• 18% 성능 향상과 로컬 실행 비용 800배 절감은 소개된 실험의 결과다. 비교 기준, 과제 구성, 반복 실행의 편차와 비용 산정 범위는 제공된 자료만으로 충분히 확인할 수 없다.
• 자동 연구 실험은 결과 편차가 커 하네스와 모델의 기여를 분리하기 어려웠다. 다른 장기 작업과 GPU 커널 과제에서도 일관된 큰 우위가 제시되지는 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 적용하려는 실제 업무를 정하고, 같은 모델·과제·예산에서 하네스 구성을 바꿔 성공률과 비용을 비교한다.
• 실행 시간과 추론 토큰을 단계적으로 늘리며 완료 여부와 추가 성능 개선을 기록해 포화점을 확인한다.
• 평가 샌드박스와 실행 로그를 점검해 허용되지 않은 경로로 문제를 해결했는지 확인한다.
• 장기 작업에 메모리 수정·삭제, 컨텍스트 압축, 하위 에이전트 재개·비활성화가 필요한지 검토한다.

❓ 열린 질문

• 모델과 예산을 고정했을 때, 어떤 하네스 기능이 과제를 넘어 반복적으로 성능 향상을 만드는가?
• 실행 경험을 컨텍스트·스킬·하네스 코드·모델 가중치 중 어디에 반영해야 가장 효율적으로 새로운 문제에 적응할 수 있는가?
• 장시간 자율 작업의 품질과 비용 포화점을 비교할 표준화된 평가는 어떻게 구성해야 하는가?