재귀적 자기 개선(RSI)의 단기 경로는 모델이 직접 가중치를 고치는 것보다, 사고·도구·맥락·기억·평가를 조율하는 하네스 자체를 개선해 더 나은 연구·배포 시스템을 만드는 방식에 가까움

하네스는 단순 프롬프트를 넘어 워크플로 자동화, 파일 기반 영속 메모리, 병렬 서브에이전트, 권한 제어, 평가와 상태 관리를 아우르는 런타임·소프트웨어 시스템임

ACE·MCE·Meta-Harness는 최적화 대상을 구조화된 맥락에서 맥락 관리 기술과 하네스 코드까지 넓히며, ADAS·AFlow·STOP·Self-Harness·AHE는 실행 결과를 바탕으로 워크플로와 구성 요소를 반복 개선함

진화적 탐색은 평가 가능한 코드와 하네스를 폭넓게 탐색하며, DGM은 Claude 3.5 Sonnet 기반 에이전트의 SWE-bench Verified 성능을 20%에서 50%, Polyglot을 14.2%에서 30.7%로 높였지만 느리거나 모호한 평가에는 적용하기 어려움

완전한 자기 개선에는 모델 지능과 신뢰할 수 있는 평가가 필수이며, 보상 해킹, 맥락 수명주기, 다양성 붕괴, 장기 유지보수, 부정적 결과 보존 문제 때문에 평가기·권한·보안과 중요한 인간 감독은 개선 루프 외부에 둬야 함

대규모 코드베이스에서 이를 조직 차원으로 구현할 방법을 고민 중임. AGENTS.md·스킬·도구를 최적화하면 에이전트의 성능·품질·비용 효율을 높일 여지가 분명하지만, 품질을 정의하고 에이전트가 그 기준으로 하네스를 최적화하게 만드는 일이 어려움
첫 단계는 PR을 에이전트가 풀고 개선할 수 있는 채점 가능한 과제로 바꾸는, 범용적이고 신뢰도 높은 코드베이스 적합도 함수를 만드는 것이라 봄. 우리 회사도 현재 거의 감에 의존하고 있어 다른 곳의 최적화 방식이 궁금함

세션이 끝나면 에이전트와 실제로 회고를 진행함. 실패한 도구 호출, 혼란스러운 문서나 프롬프트, 이해하기 까다로웠던 표현, 다음 에이전트가 작업하기 쉽게 바꿀 부분을 모두 물어봄
그러면 코드 변경 아이디어, 사소한 버그, 지켜야 할 불변 조건과 원칙, 린트 규칙, 도구 개선, 스킬 파일 갱신, 후속 작업 등을 제안함. 에이전트의 불평을 귀담아들을 만함

약 1년간 AI 음성 에이전트 하네스를 직접 만들었는데, 좋은 소프트웨어 아키텍처 원칙을 따르고 이를 agents.md에 명시하는 것이 좋은 출발점이었음. 최종 목표와 중요 가치를 대략 설명하는 비전·프로젝트 정신 섹션도 에이전트가 경직되고 단선적으로 행동하지 않게 해줌
가장 큰 속도 향상은 출시 직전까지 프런트엔드 디자인을 완전히 미루면서 얻었음. UI 문제는 추진력을 죽이고 최적화 고민에 빠뜨리므로, 백엔드 반복 개선과 불필요한 부분 제거에 집중하면 아이디어를 빠르게 검증하거나 폐기할 수 있음. 이제 개발 전체를 자동화하려 하지만 예외 상황까지 사람 개입 없이 처리할 지침을 설계하려면 세심한 계획이 필요함

개인 프로젝트 기준이지만 비용 절감 효과가 가장 컸던 두 가지는 모든 터미널 명령을 조용한 모드로 실행하는 것과, 코드베이스 이해를 빠르게 하고 파일 전체 읽기를 줄이는 코드베이스 인덱스 MCP를 사용하는 것이었음. 후자는 결과물 품질도 크게 높여줬음 https://github.com/DeusData/codebase-memory-mcp

https://github.com/mateffy/gesetz에서 이 접근을 재사용 가능한 형태로 시도 중이지만, 현재는 코드 결과물의 품질만 다룸
실제 평가에는 코딩 에이전트 세션에 관한 휴리스틱이 필요하지만 입력 과제가 매번 달라 KPI를 비교하기 어려움. 큰 작업에서 피드백을 세 번 받은 에이전트와 작은 변경을 피드백 없이 끝낸 에이전트 중 누가 더 나빴는지 판단하기 어려움

이것은 AI 업계에서 평가(evals) 라 부르며, 그 모음이 벤치마크를 이룸. 공개 벤치마크는 이미 포화됐거나 현실 성능을 잘 예측하지 못하는 경우가 많으므로 자체 평가를 정의하는 편이 좋음
평가 데이터가 학습 데이터에 들어갔을 가능성도 있으며, 신뢰할 만한 벤치마크가 이를 피하려 해도 얼마나 성공적인지는 확실하지 않음

가중치 학습이 정점에 도달했다기보다 가속 중이라고 볼 근거가 더 있지 않은지 궁금함. 이제 모델로 자기 자신을 개선하고 최적화를 시험하면서 손쉬운 성과를 더 많이 얻는 듯함

정점이 정확히 언제였는지 궁금함. 오늘이라면 알 수 없으니, 수개월 전에 이미 정점을 지났다고 보는 듯함

Torment Nexus를 향한 탐구가 계속됨

우리가 먼저 만들지 않으면 훨씬 무책임한 누군가가 만들 것임. Torment Nexus IPO에 먼저 도달하려면 안전 우려까지 포기하고 선두에 서야 한다는 풍자임

TormentBench를 손꼽아 기다리는 중임

하네스를 진화시키는 순환 밖에 평가기를 두는 데 동의함. 비슷한 에이전트 하네스 작업에서 겪은 실질적 실패는 불완전한 검사 모음이 전체 성공으로 보고하는 경우였으며, 약한 평가기보다 오히려 더 위험했음
시행착오 끝에 각 작업의 고정 검사가 모두 갖춰지지 않으면 아무것도 배포하거나 전송하지 않는 실패 폐쇄(fail-closed) 방식이 효과적이었음. 그렇지 않으면 실패했어야 할 테스트를 실행하지 않고도 통과할 수 있음

처음에는 autoresearch에서 영감을 받은 자기 개선 에이전트 프로젝트였지만, 이후 머신러닝 학습의 관점을 빌려 하네스 학습, 즉 이산 프로그램 탐색으로 재정의했음
로컬 Qwen3.6-35B A3B는 고정한 채 Terminal-Bench 2.0 일부 과제로 하네스를 학습했으며, 정확한 기여도 배분을 위해 LLM 추론과 과제 환경을 완전히 결정적으로 만드는 일이 필수였음. 초기 한 달을 실험 잡음에 허비하고 나서야 이를 깨달았음
전체 89개 과제에서 학습 중 접하지 않은 네 LLM에 대해 공식 Terminus 2 하네스와 같거나 더 나은 결과를 냈음. GPT-OSS-120B는 입력 토큰을 55% 적게 쓰면서 점수가 18.7%에서 36%로 상승했고, SWE-bench만으로 학습한 하네스도 Terminal-Bench 점수를 높였음. 자세한 내용은 https://www.henrypan.com/blog/2026-07-18-harness-training/에 있으며, 학습 순환은 PyTorch 스타일 프레임워크 https://github.com/workofart/harness-training으로 공개했음

지식 노동자를 위한 Cursor식 IDE인 https://Document.bot에서 언덕 오르기 실험으로 버그 탐지뿐 아니라 하네스도 개선하고 있음. Codex의 AI 하네스 엔지니어링 스킬을 활용해 앱을 다듬고 있으며, 이 글 덕분에 해당 스킬도 개선할 수 있었음

두 번째 하네스를 작성 중임. 첫 번째는 Emacs를 UI로 사용한 Emacs Lisp 구현이었고, 두 번째는 Common Lisp로 만든 명령줄 코딩 에이전트임
자체 AI 코딩 하네스를 만드는 일이 비효율적이라는 데는 동의하지만, 직접 만든 도구로 긴 코딩 세션을 수행하는 만족감이 큼

에이전트와 REPL을 사용해 본 과정과 배운 점, 실제로 즐거웠는지 더 알고 싶음

AI Lisp 머신의 꿈에 가까움. 에이전트가 실행 중 자기 하네스 코드를 직접 다시 작성하는 기능도 넣었는지 궁금함

하네스에 autoresearch를 적용하고 있는데 놀라울 정도로 강력함. 실행 추적만 살펴봐도 쉽게 발견하고 고칠 수 있는 문제가 많음
제대로 작동하려면 실제 문제를 찾도록 대량의 운영 환경 추적을 읽히고, 자체 도구를 작성하게 해야 함. 예를 들어 컨텍스트 불러오기를 도구 호출 15회와 2만 토큰에서 session_context 호출 1회와 800토큰으로 줄일 수 있음
또한 보상 해킹을 막을 평가와 검증·테스트 분할, 12시간 동안 자동 실행할 합성 사용자·합성 도구가 필요함. 최적화 대상도 100만 줄 코드베이스가 아니라 pi 하네스, 스킬 전용 구성, Kiln 하네스처럼 합리적인 크기여야 함

사용한 적합도 함수와 평가 방식이 궁금함

하네스가 최첨단 모델 기업이 가치를 확보하고 진입 장벽을 만드는 지점일 수 있는지 궁금함. 재미로 직접 만들어보고 싶지만, 공개 가중치 모델을 자체 호스팅할 때 더 흥미로울 듯함
ChatGPT나 Claude용 하네스를 직접 만드는 동기와, 최첨단 모델이 빠르게 발전하는 상황에서 이를 계속 조정하는 방법도 궁금함

pi.dev 제작자의 영상

이 주제를 잘 다룸
연구소들은 Claude Code나 Codex의 시스템 프롬프트를 계속 갱신하는데, 프롬프트가 지나치게 비대하고 갱신 때마다 기반 자체가 바뀜. 생태계의 최신 변화를 따라갈 수 있다면 자체 하네스로 LLM 개발에서 잃기 쉬운 통제권을 상당 부분 되찾을 수 있음
일관성이 목표일 때는 pi.dev의 맞춤형 하네스를 배포하지만, PR의 절대적 품질이 가장 중요할 때는 여전히 Claude Code를 대안으로 사용함

최첨단 모델 기업들이 하네스로 진입 장벽을 만들려는 경로는 네 가지로 보임
첫째, 모델을 자사 하네스에 맞춰 최고 성능을 내려면 해당 하네스를 쓰게 만들 수 있으나, 비슷하거나 충분히 좋은 대안 모델이 있으면 무너짐. 둘째, 암호화된 추론 토큰과 비밀 프롬프트를 통해 사용자가 어떤 파일과 데이터가 처리되는지조차 모르게 하고 이식성을 없앨 수 있으나, 기업을 전적으로 신뢰하고 대안도 없어야 성립함
셋째, 구독 가격을 자사 하네스 사용과 묶어 타사 하네스 이용에 금전적 불이익을 주는 Anthropic식 전략이 있음. 넷째는 Claude Code 광고처럼 마케팅에 집중하는 방식이지만, 베블런재 AI가 조 단위 사업이 될지는 의문임
공개 소스 모델과 도구의 혁신 압력 때문에 성공하기 쉽지 않을 것으로 보며, 개인적으로는 Openthropic의 몰락을 바라고 있어 편향된 판단일 수 있음

소비자용 기본 하네스는 한 하네스에게 다른 하네스를 작성시킬 수 있을 만큼 범용재라 진입 장벽이 거의 없음. 최신 모델은 작업 흐름 감각을 자체적으로 더 많이 내장해 하네스의 도움도 덜 필요함
하네스의 가치가 가장 큰 곳은 단순 프롬프트 입력창이 아닌, 개인의 개발 방식 전체를 반영한 맞춤형 작업 흐름임. 이 경우 폐쇄적이고 경직된 제품보다 직접 만든 것이 나음
작은 모델, 특히 로컬 실행 모델에는 세세하게 이끄는 하네스가 매우 유용하지만, 가장 큰 모델의 사용료를 피하게 해준다는 점에서 최첨단 모델 기업의 사업 목표와는 반대 방향임