# \#harness

**URL:** https://discuss.pytorch.kr/tag/harness/7867.md

[최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md)

---

## [InfraRSI: LLM 분산 학습의 설정과 코드를 함께 최적화하고 검증하는 에이전트 하네스](https://discuss.pytorch.kr/t/infrarsi-llm/12473)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [11월 11, 2026, 7:30오전 UTC](https://discuss.pytorch.kr/t/infrarsi-llm/12473 "2026-11-11T07:30:51Z")

</div>

핵심 요약 InfraRSI 논문은 LLM 분산 학습 작업의 실행 설정과 소스 코드를 함께 탐색하고, 통과한 변경만 반영하는 에이전트 하네스를 제안합니다. 코드는 InfraRSI GitHub 저장소에 공개되어 있습니다. 연구팀이 자체 측정한 결과로는 H100과 H200에서 수행한 4개 워크로드의 기하평균 속도 향상이 1.83\\times (최대 2.75\\times )이고, 평균 MFU(Model FLOPs Utilization)는 17.4\\% 에서 30.0\\% 로 올랐습니다. 같은 태스크 계약에서 RE-Bench는 1.37\\times, Auto-Research는 1.34\\times, OptiCo는 1.23\\times 였습니다. 속도 향상은 16개 불변 조건을 모두 통과하고, 기준 설정과 연달아 다시 실행했을 때도 재현된 경우에만 인정합니다. 저장된 실행 1,212건을 다시 판정했을 때 400건( 33.0\\% )이 거부되었고, 그중 352건은 실행이 완료되지 않은 경우였습니다. 검증은 짧은 측정 구간의 손실 일치와 스텝 시간을 대상으로 하고, 실험은 Hopper 세대 GPU 8~16대 규모의 4개 워크로드에 한정됩니다. 결과 표에는 조건별 단일 값만 실려 있습니다. InfraRSI 소개 대규모 언어 모델(LLM)을 여러 GPU로 학습시켜 본 분이라면, 옵션 하나를 바꿨다가 메모리 부족(OOM, Out-Of-Memory)으로 작업이 죽거나, 빨라진 줄 알았던 변경이 다시 실행해 보니 측정 오차였던 경험이 있을 것입니다. InfraRSI는 이런 학습 인프라 튜닝을 LLM 에이전트에게 맡기되, 에이전트가 내놓은 변경이 같은 작업을 실제로 더 빠르게 실행하는지를 하네스(harness)가 측정하고 검증하도록 만든 시스템입니다. TokenRhythm Technologies, 베이징대, Infinigence AI, 상하이교통대, 칭화대 연구진이 2026년 11월 8일 arXiv에 공개했습니다. 논문의 출발점은 재귀적 자기 개선(RSI, Recursive Self-Im…

---

## [HarnessTax: 7가지 모델 x 3가지 하네스로 실험한, 모델과 하네스에 따른 성능과 비용에 대한 연구 (feat. UC Berkeley)](https://discuss.pytorch.kr/t/harnesstax-7-x-3-feat-uc-berkeley/11957)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 19, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/harnesstax-7-x-3-feat-uc-berkeley/11957 "2026-09-19T09:30:15Z")

</div>

HarnessTax 소개: 코딩 에이전트에서 모델이 아니라 하네스를 바꾸면 무엇이 달라지는가 HarnessTax는 UC Berkeley Sky Computing Lab과 Arena의 연구진이 공개한 코딩 에이전트 프로파일링 연구로, 같은 모델을 서로 다른 하네스(harness) 위에서 돌렸을 때 과제 성공률과 비용이 각각 얼마나 달라지는지를 21개 조합에 걸쳐 측정한 결과입니다. 결론부터 말하면 성공률은 하네스를 바꿔도 거의 움직이지 않는 반면, 같은 품질을 얻는 데 드는 비용은 최대 5배까지 벌어졌습니다. 여기서 말하는 하네스는 모델을 감싸고 있는 소프트웨어 계층 전체를 가리킵니다. 모델에게 어떤 도구를 쥐여 줄지, 시스템 프롬프트에 무엇을 적을지, 컨텍스트를 어떻게 관리하고 잘라낼지, 몇 턴까지 루프를 돌릴지, 샌드박스와 권한을 어떻게 구성할지를 결정하는 것이 전부 하네스의 몫입니다. Claude Code, Codex CLI, Cursor, Gemini CLI 같은 도구가 모두 이 계층에 해당합니다. 즉, 우리가 "코딩 에이전트를 쓴다"고 말할 때 실제로는 모델 하나가 아니라 모델과 하네스의 조합 을 고르고 있는 셈입니다. 그런데 지금까지의 평가는 대부분 모델 쪽만 바라봤습니다. 벤치마크 점수표는 모델 이름으로 줄을 세우고, 하네스는 "어떤 걸 썼는지" 정도의 각주로만 남습니다. SWE-agent 이후로 에이전트와 컴퓨터 사이의 인터페이스 설계가 성능을 좌우한다는 인식은 자리를 잡았고, Anthropic의 장시간 실행 에이전트를 위한 하네스 설계 글이나 OpenAI가 공개한 Codex 에이전트 루프 해설처럼 하네스 자체를 정면으로 다루는 자료도 늘었습니다. 그럼에도 "같은 모델을 다른 하네스에 꽂으면 무슨 일이 벌어지는가"를 통제된 조건에서 정량적으로 비교한 자료는 드물었습니다. PyTorchKR에서도 Artificial Analysis가 모델과 하네스의 조합으로 평가한 코딩 에이전트 벤치마크를 소개한 적이 있는데, HarnessTax는 비슷한 문…

---

## [LangChain이 설명하는 루프 엔지니어링의 기술, 에이전트를 감싸는 네 겹의 루프](https://discuss.pytorch.kr/t/langchain/11100)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 7, 2026, 2:30오전 UTC](https://discuss.pytorch.kr/t/langchain/11100 "2026-07-07T02:30:43Z")

</div>

LangChain이 말하는 루프 엔지니어링 소개 루프 엔지니어링(Loop Engineering) 은 하나의 에이전트를 여러 겹의 반복 구조(loop)로 감싸서, 그저 "돌아가기만 하는" 에이전트를 "믿고 맡길 수 있는" 에이전트로 끌어올리는 설계 기법입니다. 최근 LangChain이 공개한 글 "The Art of Loop Engineering" 은 이 겹겹의 루프를 네 단계로 나누고, 각 단계를 어떤 LangChain 기본 요소(primitive)로 구현할 수 있는지 정리합니다. 여기서 제목의 art 는 미술이나 미학이 아니라, 에리히 프롬의 사랑의 기술(The Art of Loving) 이나 손자의 전쟁의 기술(The Art of War) 처럼 "무언가를 잘 해내는 솜씨와 노하우" 를 뜻합니다. 실제로 원문은 swyx가 쓴 글 "loopcraft: the art of stacking loops" 를 출발점으로 삼는데, 여기서 craft(기예, 솜씨)라는 단어가 곧 이 art 와 같은 의미로 쓰였습니다. 에이전트(Agent)가 유용한 이유는 현실 세계에서 실제로 행동을 취해 사람의 일을 자동화해 주기 때문입니다. 그런데 에이전트가 그 일을 믿을 수 있게 해내도록 만드는 것은 좋은 모델 하나만으로는 부족합니다. 특정한 작업 묶음에 꼭 맞게 설계된 하네스(harness) 가 필요합니다. 여기서 하네스란 모델을 감싸서 도구 호출, 결과 검증, 실행 트리거, 개선 신호 수집 같은 주변 장치를 붙여 주는 실행 골격을 말합니다. 가장 근본이 되는 에이전트 알고리즘은 단순합니다. 모델에게 맥락(context)을 주고, 작업이 끝날 때까지 반복해서 도구를 호출하게 두는 것입니다. 이것이 에이전트의 심장에 해당하는 가장 기본적인 루프이지만, 에이전트를 움직이는 유일한 루프는 결코 아닙니다. LangChain이 제시하는 발상의 핵심은, 이 기본 루프를 더 큰 루프로 겹겹이 감싸는 것입니다. 마치 러시아 인형 마트료시카처럼, 안쪽의 에이전트 루프를 검증 루프가 감싸고,…

---

## [Code as Agent Harness: 코드를 AI 에이전트의 운영 기반(하네스)으로 보는 서베이 논문](https://discuss.pytorch.kr/t/code-as-agent-harness-ai/10920)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [6월 29, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/code-as-agent-harness-ai/10920 "2026-06-29T06:30:58Z")

</div>

Code as Agent Harness 소개 처음으로 규모가 큰 소프트웨어 프로젝트를 맡았던 순간을 떠올려 봅시다. 머릿속으로 멋진 설계를 떠올리는 것만으로는 아무 일도 일어나지 않습니다. 코드를 직접 작성해 실행해 보고, 테스트가 빨간불을 내면 원인을 추적하고, 로그를 뒤지고, 작은 수정을 반복하면서 비로소 동작하는 시스템에 도달합니다. 우리가 일을 해내는 진짜 무대는 머릿속이 아니라 파일, 터미널, 테스트, 실행 환경이 모여 있는 작업 공간입니다. 이 서베이는 최근의 AI 에이전트에게도 똑같은 일이 벌어지고 있다고 주장합니다. Code as Agent Harness(코드를 에이전트의 하네스로) 는 코드를 더 이상 대형 언어 모델(Large Language Model, LLM)이 만들어 내는 최종 산출물로만 보지 않고, 에이전트가 추론하고, 행동하고, 환경을 표현하고, 실행 결과로 스스로를 검증하는 운영 기반(operational substrate)으로 보자는 통합적 관점입니다. 이 글은 University of Illinois Urbana-Champaign(UIUC), Meta, Stanford University의 연구자 45명이 공동으로 작성한 102페이지, 450편 이상의 논문을 인용한 대형 서베이 Code as Agent Harness를 정리한 것입니다. 여기서 핵심 개념은 하네스(harness) 입니다. 하네스란 LLM을 도구, API, 샌드박스, 메모리, 검증기(validator), 권한 경계, 실행 루프, 피드백 채널로 둘러싸서, 상태가 없는 모델(stateless model)을 장시간 과제를 수행할 수 있는 기능적 에이전트로 바꿔 주는 소프트웨어 계층을 말합니다. 마구(馬具)가 말의 힘을 마차에 연결해 실제로 쓸 수 있게 만드는 것처럼, 하네스는 모델의 출력을 실제 행동과 지속적인 상태에 연결합니다. 이 관점에서 자율성의 병목은 단지 기반 모델의 추론 능력만이 아니라, 모델 출력을 장기적 행동과 상태로 안정적으로 이어 주는 시스템의 …

---

## [Claude Code Harness: 계획과 구현, 검토와 출시를 강제하는 Claude Code 개발 하네스](https://discuss.pytorch.kr/t/claude-code-harness-claude-code/10648)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [6월 11, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/claude-code-harness-claude-code/10648 "2026-06-11T21:30:38Z")

</div>

Claude Code Harness 소개 Claude Code Harness는 Claude Code의 에이전트 작업을 계획에서 출시까지 하나의 반복 가능한 운영 경로로 묶는 개발 하네스(harness)입니다. 저자는 강력한 에이전트라도 그냥 두면 작업이 흐트러진다고 지적합니다. 계획은 채팅 안에만 남고, 테스트는 선택사항이 되며, 검토는 너무 늦게 이루어지고, 릴리즈 근거는 기억에 의존해 다시 만들어진다는 것입니다. Harness는 이 과정을 명시적인 단계와 산출물로 고정합니다. 설치 후에는 기본 동작이 "에이전트에게 코딩을 시키는 것"에서 다음 순서로 바뀝니다. 먼저 명세와 계획을 쓰고, 승인된 작업 조각만 구현하며, 결과를 검증하고, 구현과 분리해 독립적으로 검토한 뒤, PR이나 릴리즈를 위한 증거를 패키징합니다. 이 흐름의 중심에는 spec.md 와 Plans.md 라는 진실 공급원(source of truth) 파일이 있으며, Harness는 이 파일들을 기준으로 삼습니다. 이 프로젝트가 강조하는 원칙 중 하나는 에이전트가 보지 못한 데이터를 함부로 사실로 끌어올리지 않는다는 것입니다. 관찰되지 않은 정보는 조용히 지어내는 대신 unknown 으로 남깁니다. 저자는 이를 "관찰되지 않음은 없음과 다르다(not\_observed != absent)"는 문장으로 표현합니다. Harness의 핵심은 Go로 작성된 가드레일 엔진이라 별도의 Node.js가 필요 없으며, Claude Code를 주 대상으로 하면서 Codex와 OpenCode를 향한 제한된 경로도 함께 제공합니다. Claude Code Harness의 작업 루프 Harness는 작은 표면을 유지하기 위해 다섯 개의 동사형 스킬(plan, work, review, sync, release)로 작업을 정리합니다. 사용자가 원하는 결과를 일상 언어로 설명하면, /harness-plan 이 범위와 수용 기준, 미지수, 중단 조건을 담아 spec.md 와 Plans.md 초안을 작성합니다. …

---

## [\[GN⁺\] AI 이후의 소프트웨어: 하네스(Harness) 시대의 개막](https://discuss.pytorch.kr/t/gn-ai-harness/10580)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [6월 8, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/gn-ai-harness/10580 "2026-06-08T09:30:14Z")

</div>

AI 이후의 소프트웨어: 하네스(Harness) 시대의 개막 글 소개 소프트웨어 시대의 종말은 하네스(harness) 시대의 시작 이며, 고정된 워크플로우와 관리형 DB로 작동하던 SaaS가 지능을 갖춘 AI로 대체되는 중 AI는 강력하지만 야생마처럼 길들여지지 않은 상태로, 그 힘을 활용하기 위해서는 체계적 통제(domestication) 가 필요함 AI 에이전트 하네스는 중심의 LLM을 둘러싼 7가지 핵심 구성요소 로 정의되며, 각 요소가 프로덕션 수준의 신뢰성과 성능을 좌우 모든 기업이 동일한 모델에 접근 가능한 시대에는 모델 자체가 아니라 하네스를 더 잘 설계하고 운용하는 쪽(best rider) 이 승리 빅랩들이 우선시하지 않는 수천 개의 분리된 시장 이 스타트업에게 기회로 남음 하네스 시대의 의미 AI는 고정 워크플로우 기반의 SaaS와 관리형 데이터베이스를 지능(intelligence)으로 대체 하며 소프트웨어 패러다임을 재정의 AI를 머스탱(야생마)에 비유, 강력하지만 거칠어 그대로는 사용할 수 없으며 길들이는 작업이 곧 하네스 길들임의 본질은 LLM을 중심에 두고 그 주위에 7개 구성요소를 방사형으로 배치하는 아키텍처 AI 에이전트 하네스의 7가지 구성요소 1. Context & Memory (맥락과 메모리) 범용 모델은 용도별 맞춤 검색(bespoke retrieval) 이 필요하며, 방사선 전문의용 컨텍스트 검색 시스템과 법무 보조원용 시스템은 동일할 수 없음 단기 메모리 ("에이전트가 45초 전에 무엇을 하고 있었나"), 대규모 이미지 검색(방사선, 영상 생성), 수십억 문서 키워드 검색 등 케이스별로 시스템이 달라짐 검색 옆에는 컨텍스트 데이터베이스 가 위치, 비즈니스가 실제로 어떻게 운영되는지 담은 "레시피북" 역할 사람들이 머릿속에 들고 출근하는 표준운영절차(SOP)가 곧 그 레시피 초기 캡처와 사람과 프로세스 변화에 따른 진화가 컨텍스트 DB의 본질 2. Tools & Action (도구와 행동) 도구는 에…

---

## [Harness: 도메인 프롬프트 입력로부터 Claude Code 에이전트 팀과 스킬을 자동 생성하는 메타 스킬](https://discuss.pytorch.kr/t/harness-claude-code/10372)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [5월 26, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/harness-claude-code/10372 "2026-05-26T00:30:12Z")

</div>

Harness 소개 Harness는 사용자로부터 도메인 프롬프트 한 문장을 받아 에이전트 팀의 구조와 그 팀이 사용할 스킬을 한꺼번에 생성해 주는 Claude Code용 메타 스킬입니다. 사용자가 "build a harness for this project" 또는 한국어로 "하네스 구성해줘" 라고 말하면, 사전 정의된 6가지 팀 아키텍처 패턴 중 도메인에 맞는 것을 골라 .claude/agents/ 안의 에이전트 정의 파일과 .claude/skills/ 안의 스킬 파일을 생성하는 방식으로 동작합니다. Harness는 자신을 Claude Code 생태계의 L3 메타 팩토리(Meta-Factory) 계층, 그중에서도 팀 아키텍처 팩토리(Team-Architecture Factory) 라는 하위 계층에 위치시키고 있습니다. 같은 L3 계층의 이웃 프로젝트인 Archon이 결정론적 런타임 구성 자체를 만들어 내는 데 초점을 둔다면, Harness는 그 위에서 누가 어떤 역할로 협업할지의 팀 구조 와 그 팀이 사용할 스킬을 생성한다는 점에서 다른 위치를 차지합니다. Harness의 6가지 팀 아키텍처 패턴 Harness는 도메인을 분석한 뒤 다음 6가지 패턴 중 하나(또는 여러 개의 조합)를 팀 청사진으로 선택합니다. 패턴 설명 Pipeline 순차 의존성이 있는 작업을 단계별로 흘려보냅니다. Fan-out / Fan-in 병렬로 처리할 수 있는 독립 작업을 분기 후 취합합니다. Expert Pool 맥락에 따라 필요한 전문가 에이전트만 선택적으로 호출합니다. Producer-Reviewer 생성 에이전트와 검수 에이전트를 짝으로 둬서 품질을 확보합니다. Supervisor 중앙 슈퍼바이저가 동적으로 작업을 분배합니다. Hierarchical Delegation 상위 에이전트가 하위 에이전트에게 재귀적으로 위임합니다. 이 패턴들은 단순한 분류표가 아니라 Harness가 자동으로 인스턴스를 만들어 내는 단위입니다. R…
