# Knowledge Factory - 하니스 엔지니어링을 지식 생산에 적용하기 > Clean Markdown view of GeekNews topic #31691. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31691](https://news.hada.io/topic?id=31691) - GeekNews Markdown: [https://news.hada.io/topic/31691.md](https://news.hada.io/topic/31691.md) - Type: news - Author: [alfadur](https://news.hada.io/@alfadur) - Published: 2026-07-22T16:52:44+09:00 - Updated: 2026-07-22T16:52:44+09:00 - Original source: [alfadur7.github.io](https://alfadur7.github.io/llm-wiki-newsroom/ko/knowledge-factory/) - Points: 3 - Comments: 0 ## Topic Body - 소프트웨어 업계에서 최근 '소프트웨어 팩토리(Software Factory)'라는 개념이 크게 주목받고 있습니다. 주어진 목표에 따라 여러 단계의 작업을 스스로 수행하는 AI 에이전트가 소스 코드를 전담해서 작성하고, 개발자는 그 코드를 안정적으로 양산하는 시스템, 즉 '공장'을 구축하고 고도화하는 데 집중하는 새로운 패러다임입니다. - AI 개발 도구 기업 Tessl의 드루 녹스(Dru Knox)는 이러한 새로운 개발 규율을 하니스 엔지니어링(Harness Engineering)이라고 명명했습니다. - 하니스(Harness)는 말에 채우는 마구처럼 AI 에이전트를 통제하고 구동하는 전체 프레임워크를 의미하며, 이 프레임워크의 핵심에는 세 가지 루프(Loop, 같은 절차를 반복해서 도는 순환 고리)가 존재합니다. - **영상이 다루는 것**: 소프트웨어 팩토리란 무엇이고 그것을 규정하는 세 가지 지표 / Tessl이 사내에서 대화형 코딩 세션을 금지한 이유와 그 이후 / 이너·아우터·메타 루프라는 세 개의 층 / 하니스 엔지니어링이 어려운 이유 / Tessl의 체인지 리뷰와 베리파이어가 이를 실제로 구현한 방식 - 영상: https://www.youtube.com/watch?v=D_cw-k0F1DM&t=236 --- **같은 구조를 지식 생산에 적용하면** - 지식 팩토리는 AI 에이전트가 위키 페이지를 작성하고, 사람은 이를 양산하는 '편집국 시스템'을 설계·운영하는 체계입니다. 운영자는 직접 기사를 쓰지 않으며, 작성 지침과 자동화된 검수 메커니즘을 관리합니다. - 공장 내부 조직은 신문사 편집국의 5가지 역할 체계를 벤치마킹했습니다. 기자, 칼럼니스트, 교열, 데스크, 편집장입니다. - 여기서 핵심은 5가지 역할이 모두 '판단하는 AI'는 아니라는 점입니다. '교열'은 AI가 아니라 룰 기반의 파이썬 코드이며, '편집장'은 일을 나눠 주는 조율자입니다. **AI가 독립적인 평가 판단을 내리는 자리는 '데스크' 한 곳뿐입니다.** - 효율적인 공장 설계란 무작정 에이전트 수를 늘리는 것이 아니라, 판단 영역을 어디에 배치하고 어디에서 배제할지 명확히 정의하는 것입니다. **성숙도의 세 축, 그리고 신뢰** - 시스템 성숙도는 자율성(사람 개입 없는 페이지 완성), 자동화(사람 검토 없이 발행을 허용하는 범위), 품질(생산된 지식의 수준)의 세 축으로 측정합니다. - 자율성이 높아도 운영자가 불안하여 모든 페이지를 전수 검수한다면 자동화 수준은 낮은 상태입니다. 이 격차를 메우는 핵심 요소가 바로 '신뢰'입니다. - 자율성을 먼저 확보하고, 신뢰가 축적된 범위만큼 자동화 구역을 확충하며, 그 과정에서 품질 수준을 일정하게 유지합니다. 그리고 이 신뢰를 담보하는 메커니즘이 바로 '루프'입니다. **1. Inner Loop — 실시간 자가 점검** - 이너 루프는 에이전트가 초안을 제출하기 전, 작성 과정 중 수시로 실행하는 빠르고 경량화된 검증 절차입니다. 이 루프가 정교할수록 AI 에이전트는 사람의 개입 없이 스스로 오류를 수정하며, 결과적으로 자율성이 향상됩니다. - 작성 중에는 파이썬 검사 도구(`tools/lint.py`)로 자신이 만든 문서만 검사하며, 동일 오류가 2회 이상 반복될 경우 즉시 다음 단계로 이관해 처리 속도를 유지합니다. **2. Outer Loop — 발행 직전의 이중 관문** - 1관문은 교열입니다. 파이썬 코드가 링크, 인용, 문서 구조, 데이터 상충 등 10개 영역을 결정론적 규칙에 따라 정적 검사합니다. - 2관문은 데스크입니다. 편향성, 정보 밀도, 가독성, 논지 흐름 등 6개 관점에서 제3자 독자의 시각으로 정성 평가하고, 직접 수정하지 않고 개선 항목 리스트만 반환합니다. - 이는 소프트웨어 팩토리의 베리파이어(1관문)·체인지 리뷰(2관문) 2단 구조와 동일합니다. - 여기서 결정적 설계 원칙이 한 가지 있습니다. **데스크에게는 완성된 원고와 평가 기준만 전달되고 글쓴이의 작성 의도는 전달되지 않습니다.** 같은 맥락 안에서 자기 글을 자기가 검토하면 판정이 후해지기 때문에, 아예 정보를 차단해 그 편향을 방지하는 것입니다. - 이 시스템의 실질적인 차별성은 에이전트를 몇 개 띄웠느냐가 아니라 이러한 맥락 격리에 있습니다. 동일 사유로 3회 거절될 경우 자동 진행을 중단하고 사람 운영자에게 판단을 넘깁니다. **3. Meta Loop — 자기 개선 메커니즘** - "동일한 실수를 두 번 반복하게 하지 않는다. 발견된 오류는 시스템의 규칙으로 승격시킨다"는 원칙을 따릅니다. - 동일 결함이 지속 발생하면 저작 지침 수정안을 자동 제안합니다. 제안된 수정안은 어느 쪽이 수정된 규칙으로 쓴 글인지 숨긴 채 진행하는 블라인드 대조 평가와, 검증에 한 번도 쓰지 않은 새로운 실패 사례 테스트를 거칩니다. - 실제로 점수가 향상될 때에만, 그리고 반드시 **사람 운영자의 최종 승인을 얻어야만** 시스템에 반영됩니다. - 반복적인 지적 사항은 파이썬 훅이나 교열 규칙으로 승격시켜 코드로 정착시킵니다. 정성적 판단 영역을 규칙 검사 영역으로 이관하여, 데스크가 상시 고차원적 문제에 집중할 수 있도록 돕습니다. **4. Reground Loop — 지식에만 필요한 4번째 루프** - 소프트웨어 코드는 한 번 빌드되어 배포되면 스펙 변경 전까지 안정 상태를 유지하지만, **지식 자산은 시간이 흐름에 따라 현실의 사실관계와 격차가 벌어지며 노후화**됩니다. - 이를 해결하기 위해 발행된 문서를 다시 지식 생산 공장의 입력값으로 되먹임하는 리그라운드(Reground, 근거에 다시 발을 붙인다는 뜻) 루프를 4번째 루프로 추가했습니다. - **업데이트**: 원본 데이터 소스에 변경이 발생한 경우. 검사 도구가 식별한 노후 페이지를 칼럼니스트가 재분석하여 갱신합니다. (후속 보도) - **팔로업**: 문서 내에 '추후 확인 필요' 또는 시한성 조건이 명시된 문장이 존재하는 경우. 기한 도래 시 데스크 및 운영자가 재검증합니다. (추적 취재) - **정정**: 우리 페이지들 사이에 정보 상충이 포착된 경우. 데스크가 발행된 클러스터 단위의 문서 묶음을 통째로 다시 읽으며, 하나씩 봐서는 드러나지 않는 어긋남을 잡아냅니다. (정정 보도) **Human-in-the-Loop** - 사람의 승인이 필요한 예외 상황을 감에 의존하지 않고 명확한 체크리스트로 정의해 관리합니다. - 현재는 자율성은 높이되 자동화는 의도적으로 억제한 상태로 운영합니다. 에이전트가 페이지를 스스로 작성하지만, Wiki 발행과 작성 규칙 변경은 여전히 사람의 최종 승인이 필요합니다. --- **전문**: https://alfadur7.github.io/llm-wiki-newsroom/ko/knowledge-factory/ ## Comments _No public comments on this page._