{"title":"자기개선을 위한 하네스 엔지니어링 - 모델을 둘러싼 시스템이 진짜 무대다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/harness-engineering-for-self-improvement/","section":"posts","date":"2026-07-08T23:48:50+09:00","lastmod":"2026-07-08T23:48:50+09:00","description":"Lilian Weng의 글을 바탕으로, AI 자기개선에서 모델 가중치뿐 아니라 도구, 메모리, 워크플로, 평가 루프를 묶는 하네스가 왜 중요한 최적화 대상인지 정리한다.","summary":"Lilian Weng의 글 Harness Engineering for Self-Improvement는 AI 자기개선을 모델 가중치의 문제로만 보지 않는다. 모델 주변에서 실행을 조율하는 하네스, 즉 도구 호출, 메모리, 워크플로, 권한, 평가 루프까지 포함한 시스템이 가까운 미래의 핵심 개선 대상이라는 주장이다.\nHarness 핵심 정리 하네스의 역할: 베이스 모델이 어떻게 생각하고, 어떤 도구를 쓰고, 무엇을 기억하고, 어떤 결과를 통과시킬지 정하는 실행 시스템이다.\n가까운 경로: 자기개선은 모델이 곧장 자기 가중치를 수정하는 장면보다, 하네스와 연구 파이프라인을 개선하는 형태로 먼저 올 가능성이 크다.\n중요 패턴: 워크플로 자동화, 파일 시스템 기반 장기 기억, 서브에이전트와 백엔드 작업 관리가 반복해서 등장한다.\n최적화 대상: 프롬프트에서 구조화 컨텍스트, 워크플로, 하네스 코드, 옵티마이저 코드로 점점 내려간다.\n현실적 한계: 평가가 흐릿한 영역에서는 보상 해킹, 실패 은폐, 다양성 붕괴, 장기 유지보수 비용을 피하기 어렵다. 1) 하네스는 프롬프트보다 실행 시스템에 가깝다 초기 에이전트 설명은 보통 LLM + memory + tools + planning + action 같은 공식으로 끝났다. Weng은 여기에 한 층을 더 얹는다. 실제 제품에서 중요한 것은 모델에게 좋은 말을 건네는 것만이 아니라, 모델이 어떤 루프 안에서 관찰하고, 실행하고, 실패를 기록하고, 다시 시도하게 만드는가다.\n","content":"Lilian Weng의 글 Harness Engineering for Self-Improvement는 AI 자기개선을 모델 가중치의 문제로만 보지 않는다. 모델 주변에서 실행을 조율하는 하네스, 즉 도구 호출, 메모리, 워크플로, 권한, 평가 루프까지 포함한 시스템이 가까운 미래의 핵심 개선 대상이라는 주장이다.\nHarness 핵심 정리 하네스의 역할: 베이스 모델이 어떻게 생각하고, 어떤 도구를 쓰고, 무엇을 기억하고, 어떤 결과를 통과시킬지 정하는 실행 시스템이다.\n가까운 경로: 자기개선은 모델이 곧장 자기 가중치를 수정하는 장면보다, 하네스와 연구 파이프라인을 개선하는 형태로 먼저 올 가능성이 크다.\n중요 패턴: 워크플로 자동화, 파일 시스템 기반 장기 기억, 서브에이전트와 백엔드 작업 관리가 반복해서 등장한다.\n최적화 대상: 프롬프트에서 구조화 컨텍스트, 워크플로, 하네스 코드, 옵티마이저 코드로 점점 내려간다.\n현실적 한계: 평가가 흐릿한 영역에서는 보상 해킹, 실패 은폐, 다양성 붕괴, 장기 유지보수 비용을 피하기 어렵다. 1) 하네스는 프롬프트보다 실행 시스템에 가깝다 초기 에이전트 설명은 보통 LLM + memory + tools + planning + action 같은 공식으로 끝났다. Weng은 여기에 한 층을 더 얹는다. 실제 제품에서 중요한 것은 모델에게 좋은 말을 건네는 것만이 아니라, 모델이 어떤 루프 안에서 관찰하고, 실행하고, 실패를 기록하고, 다시 시도하게 만드는가다.\n그래서 하네스는 프롬프트 템플릿이라기보다 런타임에 가깝다. 운영체제가 복잡한 장치와 프로세스를 단순한 인터페이스로 감싸듯, 하네스는 도구, 파일, 컨텍스트, 권한, 평가를 모델이 다룰 수 있는 형태로 감싼다.\n이 관점은 코딩 에이전트를 보면 바로 이해된다. Claude Code, Codex, OpenCode, Cursor류 도구는 모두 비슷한 루프를 갖는다. 파일을 찾고, 읽고, 수정하고, 셸을 실행하고, 테스트하고, 실패 로그를 다시 읽는다. 모델이 똑똑해도 이 루프가 없으면 실제 저장소에서 오래 버티기 어렵다.\n2) 세 가지 기본 패턴: 루프, 파일, 병렬 작업 첫 번째 패턴은 워크플로 자동화다. 목표를 세우고, 실행하고, 관찰하거나 테스트하고, 다시 고치는 루프다. 중요한 점은 이 루프가 정적인 프롬프트가 아니라 실패 궤적을 읽고 자기 행동을 바꾸는 런타임이라는 것이다.\n두 번째 패턴은 파일 시스템을 장기 기억으로 쓰는 것이다. 긴 작업에서는 모든 로그와 산출물을 컨텍스트에 넣을 수 없다. 실험 로그, 코드 diff, 오류 추적, 이전 시도는 파일로 남아야 한다. 그래야 중간에 끊겨도 복구할 수 있고, 모델이 grep, cat, rg 같은 익숙한 도구로 자기 과거를 다시 읽을 수 있다.\n세 번째 패턴은 서브에이전트와 백엔드 작업이다. 긴 리서치나 실험에서는 여러 가설을 병렬로 돌려야 한다. 하지만 병렬성은 보이지 않으면 위험하다. 부모 에이전트가 작업을 띄우고, 로그를 보고, 실패한 실행을 취소하고, 결과를 다시 합치는 작은 프로세스 매니저가 필요하다.\n3) 자기개선은 하네스에서 먼저 일어날 수 있다 Weng의 가까운 전망은 꽤 실용적이다. 자기개선이 당장 \u0026ldquo;모델이 자기 가중치를 직접 다시 쓴다\u0026quot;는 모습으로 시작되기보다, 더 나은 답을 얻는 방법론 자체를 고치는 방향으로 먼저 나타난다는 것이다.\n이때 하네스는 최적화 대상이 된다. 단순히 답을 더 잘 내는 것이 아니라, 좋은 답을 만들기 위한 기계 장치를 더 잘 만든다. 컨텍스트를 어떻게 줄이고, 실패를 어떻게 분류하고, 어떤 테스트를 통과해야 수정안을 받아들일지 고치는 식이다.\n글이 제시하는 진행 방향은 이렇다.\n프롬프트를 고친다. 구조화된 컨텍스트를 고친다. 워크플로를 고친다. 하네스 코드를 고친다. 하네스를 고치는 옵티마이저 자체를 고친다. 단계가 내려갈수록 설계 공간은 커진다. 대신 잘못 고쳤을 때의 위험도 커진다. 그래서 권한과 평가 장치는 자기수정 루프 바깥에 두어야 한다는 경고가 붙는다.\n4) 컨텍스트 엔지니어링은 긴 프롬프트 만들기가 아니다 긴 작업에서 모든 도구 응답과 모든 모델 생성을 계속 붙이면 컨텍스트가 무너진다. Weng이 소개하는 Agentic Context Engineering은 컨텍스트를 하나의 거대한 문장 덩어리가 아니라, 식별자와 설명을 가진 항목들의 플레이북으로 관리한다.\n핵심은 재작성 방식이다. 매번 전체 프롬프트를 다시 쓰면 중요한 내용이 사라지거나 짧은 문장으로 과도하게 압축된다. 대신 성공과 실패에서 배운 내용을 항목 단위로 추가하고, 주기적으로 정리하고, 중복을 제거한다.\nMeta Context Engineering은 여기서 한 단계 더 나아간다. 어떤 내용을 컨텍스트에 넣을지뿐 아니라, 컨텍스트를 관리하는 방식 자체를 진화시킨다. 구현상으로는 skill.md, 정적 지식, 동적 롤아웃, 데이터 파일이 들어 있는 디렉터리가 하나의 컨텍스트 함수처럼 작동한다.\n5) 하네스는 코드라서 탐색할 수 있다 하네스가 코드라면, 모델은 하네스 설계 공간을 탐색할 수 있다. Meta-Harness는 어떤 정보를 저장하고, 꺼내고, 모델에게 보여줄지 결정하는 코드까지 최적화 대상으로 본다. ADAS와 AFlow는 에이전트 워크플로를 사람이 손으로 짜는 대신, 후보를 만들고 평가하며 더 나은 흐름을 찾는다.\nSelf-Harness는 더 직접적이다. 현재 하네스의 실패를 모으고, 반복되는 약점을 찾고, 좁은 수정안을 제안하고, held-in과 held-out 평가에서 회귀가 없을 때만 받아들인다. 중요한 건 \u0026ldquo;스스로 고친다\u0026quot;는 낭만이 아니라, 실패 패턴을 검증 가능한 수정으로 바꾸고 회귀를 막는 절차다.\n진화적 탐색도 같은 맥락이다. AlphaEvolve, ShinkaEvolve, Darwin Gödel Machine 같은 계열은 후보 프로그램이나 에이전트 하네스를 만들고, 평가하고, 좋은 것만 남긴다. 자동 평가가 빠르고 명확한 영역에서는 강하다. 반대로 평가가 느리고 애매한 연구 취향, 제품 판단, 장기 유지보수에서는 훨씬 어렵다.\n6) 병목은 결국 평가와 권한이다 자기개선 루프는 자신에게 주어진 신호를 최적화한다. 그 신호가 단위 테스트면 테스트에 과적합할 수 있고, 심판 모델이면 심판 모델의 취향을 공략할 수 있고, 벤치마크면 벤치마크의 빈틈을 찾을 수 있다.\n그래서 Weng은 평가자와 권한 제어가 하네스 진화 루프 바깥에 있어야 한다고 본다. held-out 테스트, trace audit, 중요한 의사결정 지점의 인간 검토가 필요하다. 특히 연구 자동화에서는 그 차이가 더 크다. 논문을 쓰는 시스템이 있다고 해서 과학적 발견을 하는 시스템이 되는 것은 아니다. 그럴듯한 원고, 깨진 인용, 약한 실험 결과는 얼마든지 나올 수 있다.\n글의 미래 과제도 여기로 모인다. 흐릿한 평가자, 늘어나는 메모리의 생명주기, 실패 결과를 보존하지 않는 연구 문화, 다양성 붕괴, 보상 해킹, 저장소의 장기 건강, 인간의 적절한 개입 지점이 모두 아직 열린 문제다.\n결론 및 시사점 하네스 엔지니어링은 모델을 포장하는 주변 작업이 아니라, 모델이 현실의 긴 작업을 해내게 만드는 실행 조건이다. 가까운 자기개선은 더 큰 모델 하나로 끝나지 않고, 모델이 자기 실행 환경을 읽고 고치고 검증하는 방식에서 먼저 나타날 가능성이 높다.\n실무적으로는 두 가지를 기억하면 된다. 첫째, 에이전트의 성능은 모델 이름만으로 결정되지 않는다. 도구, 파일 상태, 컨텍스트 관리, 평가 루프가 함께 성능을 만든다. 둘째, 자기개선 루프를 열수록 권한과 평가는 더 단단히 분리해야 한다. 고치는 능력보다 중요한 것은, 무엇을 고치면 안 되는지 아는 경계다.\n한 줄 결론: AI 자기개선의 가까운 전장은 모델 내부가 아니라, 모델이 일하고 기억하고 검증받는 하네스 전체다.\n","wordCount":880,"tags":["AI","에이전트","하네스","자기개선","컨텍스트 엔지니어링","Lilian Weng"],"categories":["AI"],"frameworks":["Systems Thinking","Feedback Loop","Context Engineering"],"mental_models":["Recursive Self-Improvement","Search Space","Goodhart's Law"],"philosophy_type":"engineering-discipline","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["하네스는 모델이 도구를 호출하고, 컨텍스트를 관리하고, 결과를 평가하고, 파일 시스템에 상태를 남기게 만드는 실행 시스템이다.","가까운 자기개선은 모델이 곧바로 자기 가중치를 고치는 방식보다, 하네스와 연구 파이프라인을 개선하는 방식으로 먼저 나타날 가능성이 높다.","컨텍스트 엔지니어링은 긴 프롬프트를 계속 덧붙이는 일이 아니라, 성공과 실패의 궤적을 구조화된 플레이북과 파일 상태로 남기는 일에 가깝다.","Self-Harness, Meta-Harness, ADAS, AFlow, DGM 같은 연구는 하네스 자체를 코드 기반 탐색 공간으로 다룬다.","가장 큰 병목은 평가다. 보상이 흐릿하면 자기개선 루프는 실력 향상보다 보상 해킹과 다양성 붕괴로 흐르기 쉽다."],"related":["posts/anatomy-of-an-agent-harness","posts/todays-harness-is-tomorrows-prompt","posts/some-new-agentic-patterns","posts/components-of-a-coding-agent"]}