In English.
소프트웨어 업계에서 최근 ‘소프트웨어 팩토리(Software Factory)’라는 개념이 크게 주목받고 있습니다. 주어진 목표에 따라 여러 단계의 작업을 스스로 수행하는 AI 에이전트가 소스 코드를 전담해서 작성하고, 개발자는 그 코드를 안정적으로 양산하는 시스템, 즉 ‘공장’을 구축하고 고도화하는 데 집중하는 새로운 패러다임입니다. AI 개발 도구 기업 Tessl의 드루 녹스(Dru Knox)는 이러한 새로운 개발 규율을 하니스 엔지니어링(Harness Engineering)이라고 명명했습니다. 하니스(Harness)는 말에 채우는 마구처럼 AI 에이전트를 통제하고 구동하는 전체 프레임워크를 의미하며, 이 프레임워크의 핵심에는 세 가지 루프(Loop, 같은 절차를 반복해서 도는 순환 고리)가 존재합니다.
본 아티클은 동일한 질문을 ‘지식 관리(Knowledge Management)’ 영역에 던져봅니다. 코드가 아닌 하이퍼링크로 상호 연결된 위키 페이지를 양산하는 공장은 과연 어떤 모습이어야 할까요? 결론부터 말하면, 소프트웨어 팩토리의 세 가지 루프는 지식 생산 공정에도 그대로 적용할 수 있습니다. 다만 지식 자산에는 코드와 다른 결정적 특성이 하나 있습니다. 바로 발행한 이후 시간이 지나면 낡고 정확성이 떨어진다는 점입니다. 따라서 이를 보완할 4번째 루프가 추가로 필요합니다. 본 아티클에서는 이처럼 4개의 루프를 기반으로 작동하는 지식 생산 체계를 ‘지식 팩토리(Knowledge Factory)’라 정의하고, 개념적 정의에서 출발해 실제 구현인 LLM Wiki Newsroom까지 단계별로 설명합니다.
핵심 요약(Key Takeaways)
- 개념의 전환: 지식 팩토리는 AI 에이전트가 위키 페이지를 작성하고, 사람은 이를 양산하는 ‘편집국 시스템’을 설계·운영하는 체계입니다. 운영자는 직접 기사를 쓰지 않으며, 작성 지침과 자동화된 검수 메커니즘을 관리합니다.
- 성숙도 평가 축: 시스템 성숙도는 자율성(사람 개입 없는 페이지 완성), 자동화(사람 검토 없이 발행을 허용하는 범위), 품질(생산된 지식의 수준)의 세 축으로 측정합니다. 이 세 축을 연결하는 핵심 요소는 신뢰입니다.
- 4대 루프 구조: 신뢰 구축은 4개의 루프를 통해 이루어집니다.
- 이너 루프(Inner Loop): 작성 과정 중 자가 점검
- 아우터 루프(Outer Loop): 발행 직전의 이중 관문 검증
- 메타 루프(Meta Loop): 반복된 오류를 규칙화하는 자기 개선
- 리그라운드 루프(Reground Loop): 노후화된 지식을 재검증하고 고쳐 쓰는 피드백 체계
- Human-in-the-Loop: 사람의 승인이 필요한 예외 상황을 감에 의존하지 않고 명확한 체크리스트로 정의해 관리합니다.
- 현 시점의 한계: 자동 검사가 다룰 수 있는 범위의 제한, 아직 닫히지 않는 미결 항목, 변경 이력의 분산, 가설 검증 단계라는 한계도 함께 밝힙니다.
1. 지식 팩토리란 무엇인가
지식 팩토리에서 ‘팩토리’의 의미는 명확합니다. 지식 콘텐츠라는 제품을 AI 에이전트가 생산하고, 사람은 그 제품을 생산하는 공장을 구축합니다.
지식 팩토리가 생산하는 최종 제품은 상호 연결된 마크다운(Markdown, 일반 텍스트로 문서 서식을 표현하는 형식) 기반의 위키 문서입니다. 원문을 요약한 소스 페이지, 주요 인물·개념 페이지, 여러 연관 주제를 한데 묶어 주는 허브 페이지와 타임라인, 소스 간 상충된 정보를 기록해 두는 모순(Contradiction) 페이지, 전체 맥락을 아우르는 종합 분석 페이지까지, 사람이 직접 작성하는 페이지는 단 하나도 없습니다. 운영자의 역할은 오직 두 가지, ① 원문 데이터 입력과 ② 공장 시스템의 고도화뿐입니다.
운영자는 이 흐름 안에서 문서를 직접 쓰지 않고 '팩토리' 자체를 만들고 고도화합니다.
공장 내부 조직은 신문사 편집국의 5가지 역할 체계를 벤치마킹했습니다.
- 기자(Reporter): 외부 데이터를 수집·취재하고 소스 페이지를 작성합니다.
- 칼럼니스트(Columnist): 다수의 소스를 종합해 심층 분석 페이지를 작성합니다.
- 교열(Copy Editor): 정해진 규칙에 따라 원고를 기계적으로 검증합니다.
- 데스크(Desk): 발행 전 최종 원고의 논리와 흐름을 독자의 시각에서 평가합니다.
- 편집장(Editor-in-Chief): 전체 워크플로우와 작업 할당을 총괄 지휘하는 오케스트레이터(Orchestrator, 들어온 일을 알맞은 담당에게 배분하는 지휘자)입니다.
여기서 핵심은 5가지 역할이 모두 ‘판단하는 AI’는 아니라는 점입니다. ‘교열’은 AI가 아니라 룰 기반의 파이썬 코드이며, ‘편집장’은 일을 나눠 주는 조율자입니다. AI가 독립적인 평가 판단을 내리는 자리는 ‘데스크’ 한 곳뿐입니다. 효율적인 공장 설계란 무작정 에이전트 수를 늘리는 것이 아니라, 판단 영역을 어디에 배치하고 어디에서 배제할지 명확히 정의하는 것입니다.
Note: 본 프로젝트는 소프트웨어 팩토리 개념을 보고 설계한 것이 아닙니다. 안드레이 카파시(Andrej Karpathy)가 제시한 LLM Wiki 개념을 구현하는 과정에서 “AI가 생성한 지식을 어디까지 신뢰할 수 있는가”라는 본질적 문제를 독립적으로 풀다가 소프트웨어 팩토리와 동일한 구조에 도달했습니다. 지식 자율 생산 체계라면 결국 비슷한 골격이 필요하다는 방증일 수는 있겠지만, 독립적인 사례 두 가지가 겹친 것일 뿐 정답이라고 하기에는 무리가 있습니다.
2. 성숙도의 세 축, 그리고 신뢰
소프트웨어 팩토리의 성숙도 측정 기준을 지식 팩토리에 적용하면 다음과 같은 세 가지 축으로 정리됩니다.
- 자율성(Autonomy): 사람의 개입 없이 페이지가 완성되는 정도입니다. 원문 하나를 입력했을 때 소스 페이지 작성부터 연관 페이지 10여 개의 갱신, 신규 개념 추출까지 AI 에이전트가 완결 지을 수 있는가를 측정합니다.
- 자동화(Automation): 사람이 결과물을 별도 검토하지 않고 즉시 발행을 허용하는 범위입니다. 자율성이 높아도 운영자가 불안하여 모든 페이지를 전수 검수한다면 자동화 수준은 낮은 상태입니다. 이 격차를 메우는 핵심 요소가 바로 ‘신뢰’입니다.
- 품질(Quality): 자동 검사 통과율, 데스크가 발견한 결함 수, 문서 간 불일치 발생 비율 등의 성과 지표입니다.
지식 팩토리의 성숙도를 올리는 순서는 명확합니다. 자율성을 먼저 확보하고, 신뢰가 축적된 범위만큼 자동화 구역을 확충하며, 그 과정에서 품질 수준을 일정하게 유지합니다. 그리고 이 신뢰를 담보하는 메커니즘이 바로 ‘루프(Loop)’입니다.
3. 지식 팩토리의 4대 루프 시스템
3개의 루프는 서로 감싸는 형태로 중첩되고, 4번째 루프만 바깥에서 이미 발행된 문서를 다시 안으로 되먹임합니다.
3-1. 이너 루프(Inner Loop): 실시간 자가 점검
이너 루프는 에이전트가 초안을 제출하기 전, 작성 과정 중 수시로 실행하는 빠르고 경량화된 검증 절차입니다. 이 루프가 정교할수록 AI 에이전트는 사람의 개입 없이 스스로 오류를 수정하며, 결과적으로 자율성이 향상됩니다.
- 작성 표준 참조: 기자와 칼럼니스트 에이전트는 작업에 착수할 때 해당 문서 타입의 작성 표준과 5가지 전용 스킬셋(Skillset, 에이전트가 글을 쓸 때 참조하는 작성 지침 묶음)을 불러옵니다. 기사 작성법, 컨설팅 보고서 작성법, 백과사전식 중립 서술법, 출처 인용 규율, 지침 문서 작성법입니다.
- 자가 검증: 각 스킬셋에는 평가 기준과 검사 코드가 매핑되어 있어, 뒤이어 수행될 검수 단계와 동일하게 스스로를 점검합니다. 작성 중에는 파이썬 검사 도구(
tools/lint.py)로 자신이 만든 문서만 검사하며, 동일 오류가 2회 이상 반복될 경우 즉시 다음 단계로 이관해 처리 속도를 유지합니다.
3-2. 아우터 루프(Outer Loop): 발행 직전의 이중 관문
아우터 루프는 초안 완결 후 발행 직전 진행되는 무겁고 정밀한 검증 단계입니다. 소프트웨어 개발로 치면 작성한 코드 변경을 합쳐 달라고 올리는 요청, 즉 Pull Request(PR) 검수 시점 및 CI/CD 파이프라인(코드가 합쳐질 때마다 자동으로 빌드와 테스트를 돌리는 체계)과 대응됩니다. 지식 팩토리는 이를 2단계 이중 관문으로 설계했습니다.
| 관문 | 담당 | 무엇을 하나 |
|---|---|---|
| 1관문 | 교열(Rule-Based) | 파이썬 코드(tools/lint.py)가 링크, 인용, 문서 구조, 데이터 상충 등 10개 영역을 결정론적 규칙에 따라 정적 검사합니다. 통과 여부가 명확하며 결과는 리포트로 자동 생성됩니다. |
| 2관문 | 데스크(AI-Based) | 편향성, 정보 밀도, 가독성, 논지 흐름 등 6개 관점에서 제3자 독자의 시각으로 정성 평가합니다. 직접 수정하지 않고 개선 항목 리스트만 반환합니다. |
이는 소프트웨어 팩토리의 ‘베리파이어(Verifier, 1관문)’·‘체인지 리뷰(Change Review, 2관문)’ 2단 구조와 동일합니다. 교열(1관문)은 기존에 발생했던 오류의 재발을 방지하고, 데스크(2관문)는 아직 규칙화되지 않은 신규 품질 이슈를 포착합니다.
여기서 결정적 설계 원칙이 한 가지 있습니다. 데스크에게는 완성된 원고와 평가 기준만 전달되고 글쓴이의 작성 의도는 전달되지 않습니다. 같은 맥락 안에서 자기 글을 자기가 검토하면 판정이 후해지기 때문에, 아예 정보를 차단해 그 편향을 방지하는 것입니다. 이 시스템의 실질적인 차별성은 에이전트를 몇 개 띄웠느냐가 아니라 이러한 맥락 격리에 있습니다. 두 관문을 통과하지 못한 원고는 작성자에게 반려되며, 동일 사유로 3회 거절될 경우 자동 진행을 중단하고 사람 운영자에게 판단을 넘깁니다.
3-3. 메타 루프(Meta Loop): 자기 개선 메커니즘
메타 루프는 이너·아우터 루프의 작동 과정을 통째로 모니터링하며 시스템 전체를 고도화하는 학습 레이어입니다. “동일한 실수를 두 번 반복하게 하지 않는다. 발견된 오류는 시스템의 규칙으로 승격시킨다”는 원칙을 따릅니다.
- 결함 데이터베이스 구축: 검수 단계에서 걸러진 결함과 운영자의 피드백은 결함 기록 도구(
tools/log_defect.py)에 축적되며, 분석 엔진이 반복 실패 패턴을 추적합니다. - 가이드라인 제안 및 평가: 동일 결함이 지속 발생하면 저작 지침 수정안을 자동 제안합니다. 제안된 수정안은 어느 쪽이 수정된 규칙으로 쓴 글인지 숨긴 채 진행하는 블라인드 대조 평가와, 검증에 한 번도 쓰지 않은 새로운 실패 사례 테스트를 거칩니다. 실제로 점수가 향상될 때에만, 그리고 반드시 사람 운영자의 최종 승인을 얻어야만 시스템에 반영됩니다.
- 코드 정착(Code Hardening): 반복적인 지적 사항은 파이썬 훅(Hook, 특정 동작이 일어나는 순간 자동으로 끼어들어 검사하거나 차단하는 장치)이나 교열 규칙(1관문)으로 승격시켜 코드로 정착시킵니다. 이를 통해 정성적 판단 영역을 규칙 검사 영역으로 이관하여, 데스크(2관문)가 상시 고차원적 문제에 집중할 수 있도록 돕습니다.
3-4. 리그라운드 루프(Reground Loop): 지식 생태계 유지를 위한 4번째 루프
소프트웨어 코드는 한 번 빌드되어 배포되면 스펙 변경 전까지 안정 상태를 유지하지만, 지식 자산은 시간이 흐름에 따라 현실의 사실관계와 격차가 벌어지며 노후화됩니다. 이를 해결하기 위해 발행된 문서를 다시 지식 생산 공장의 입력값으로 되먹임하는 ‘리그라운드(Reground, 근거에 다시 발을 붙인다는 뜻) 루프’를 4번째 루프로 추가했습니다.
- 업데이트(Update): 원본 데이터 소스에 변경이 발생한 경우입니다. 검사 도구가 식별한 노후 페이지를 칼럼니스트 에이전트가 재분석하여 갱신합니다. (후속 보도)
- 팔로업(Follow-up): 문서 내에 ‘추후 확인 필요’ 또는 시한성 조건이 명시된 문장이 존재하는 경우입니다. 기한 도래 시 데스크 및 운영자가 재검증합니다. (추적 취재)
- 정정(Correction): 우리 페이지들 사이에 정보 상충이 포착된 경우입니다. 데스크가 발행된 클러스터(Cluster, 비슷한 주제의 페이지 무리) 단위의 문서 묶음을 통째로 다시 읽으며, 하나씩 봐서는 드러나지 않는 어긋남을 잡아냅니다. (정정 보도)
4. 컨트롤 플레인(Control Plane): 이력 관리 체계
지식 생산 공장을 지속적으로 개선하기 위해서는 모든 작업 이력이 투명하게 기록되어 메타 루프가 접근할 수 있어야 합니다. 소프트웨어 팩토리에서는 이를 컨트롤 플레인(Control Plane)이라 부릅니다.
지식 팩토리의 모든 워크플로우는 저장소 내 파일 기반(File-based) 데이터로 관리됩니다.
- 입력 대기열(Queue) 파일
- 작업 수행 일지(Log) 및 검수 보고서
- 결함 데이터베이스
에이전트 역할 정의, 문서 타입별 저작 기준, 명명 규칙 등 모든 정책 파일은 Git 저장소(파일의 변경 이력이 모두 남는 보관소)에 커밋되어 관리되며, 개인 PC에만 존재하는 비공식 설정은 엄격히 배제됩니다. 이를 통해 시스템의 모든 변경과 개선 이력이 누적되어 선순환 구조를 형성합니다.
5. Human-in-the-Loop: 승인 절차의 표준화
Human-in-the-Loop, 즉 자동화된 흐름 중간에 사람이 개입하는 지점을 주관적 판단에 맡길 경우, 불필요한 작업에서 인간 병목(Bottleneck)이 발생하거나 고위험 작업이 무검증으로 처리되는 리스크가 발생합니다. 지식 팩토리는 사람의 승인이 필수적인 조건을 명확한 규칙 목록으로 명시했습니다.
사람의 승인이 필수적인 7가지 예외 상황(Rule Set)
- 동일 오류로 인한 연속 3회 검수 실패 시
- 신규 주제 분류 카테고리 생성 시
- 인용 누적이 기준치를 넘어 신규 인물·개념 페이지를 생성할 시
- 위키 전체를 아우르는 최상위 종합 페이지 발행 시
- 저작 가이드라인 및 평가 스킬셋의 핵심 구조 변경 시
- 최종 결과물을 Git 저장소에 반영해 외부에 공개(Commit·Push)할 시
- 기존 문서 분량의 50% 이상을 전면 재작성할 시
현재 지식 팩토리는 높은 자율성을 확보하되, 발행 및 규칙 변경의 최종 권한은 사람에게 두어 자동화 수준을 의도적으로 통제하는 단계입니다. 이는 신뢰를 확보해 나가는 안정적인 전환 과정이며, 신뢰도가 검증됨에 따라 위 목록의 제약 조건을 단계적으로 완화해 나갈 수 있습니다.
6. 시스템의 한계 및 개선 과제
시스템의 투명성을 위해 현재 파악된 구조적 한계점을 명확히 기록합니다.
- 규칙 검사의 한계: 현재 교열 단계는 AI를 전혀 호출하지 않는 순수 파이썬 규칙 검사입니다. 비용과 속도 측면에서는 유리하지만, 문맥과 의도를 파악해야 하는 검사는 자동화하지 못하고 AI 영역으로 이관되어 데스크의 부하가 가중됩니다.
- 닫히지 않는 미결 항목: 팔로업(Follow-up)으로 걸러진 항목을 ‘처리 완료’로 닫는(Close) 절차가 아직 없습니다. 그래서 한 번 걸러진 항목은 검사를 돌릴 때마다 다시 올라옵니다. 실제로 항목이 쌓이기 시작하는 시점에 재심 이력을 관리하는 절차를 만들 계획입니다.
- 변경 이력의 분산: 코드 개발의 PR처럼 변경 이력이 단일 객체에 묶여 저장되는 방식이 아닌, 일지·보고서·결함 장부로 이력이 분산 저장되는 구조적 아쉬움이 있습니다.
- 가설 검증 단계: 본 프로젝트의 4대 루프 체계와 정성적 검수 구조가 지식 생산에 있어 더 나은 결과를 낸다는 가설을 현재 블라인드 테스트와 운영 데이터 수집으로 검증하고 있습니다.
맺음말: 결국 바뀌는 것은 사람의 역할
소프트웨어 팩토리가 전달하는 핵심 메시지는 “개발자의 역할이 코드를 작성하는 사람에서, 코드를 생산하는 시스템을 설계하는 사람으로 변화한다”는 점입니다. 지식 팩토리 역시 동일합니다. 운영자는 콘텐츠를 직접 작성하는 사람이 아니라, 지식을 생산하는 편집국 시스템을 구축하고 고도화하는 건축가(Architect)입니다.
단일 페이지를 직접 수정하면 하나의 결과물만 개선되지만, 데스크의 반복 지적 사항을 규칙(Rule)으로 전환하면 향후 생산될 모든 지식 자산의 품질이 동시에 향상됩니다.
지식 팩토리가 소프트웨어 팩토리로부터 습득한 가장 핵심적인 가치는 단순한 생산 속도가 아닙니다. 오류의 재발을 방지하는 메타 루프(Meta Loop), 그리고 지식 자산의 노후화를 막는 리그라운드 루프(Reground Loop)를 통해 스스로 진화하는 규칙과, 낡으면 스스로 고쳐 쓰는 지식 생태계를 구축하는 것, 이것이 바로 지식 팩토리가 지향하는 목표입니다.
소프트웨어 팩토리와 세 가지 루프 개념은 Tessl 드루 녹스의 AI Engineer SF 발표에서 제시되었습니다(발표 영상). 박재홍님의 블로그에 한국어로 잘 정리되어 있습니다. 본 아티클이 설명한 개념의 실제 구현은 README(영문)과 소개 페이지에서 확인할 수 있습니다.