에이전트를 위한 문서 작성법 — OpenWiki 내부 공개

URL: https://www.youtube.com/watch?v=S_PeI8JUqMg 날짜: 2026-08-17 채널: Tech Bridge 영상 길이: 996초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트가 코드를 읽고 수정하는 시대에는 사람을 위한 문서를 에이전트용 기억 시스템으로 다시 설계해야 하며, OpenWiki는 그 기억을 자동 생성·갱신하는 CLI다.==

• OpenWiki는 저장소(repository) 문서를 사람과 에이전트가 함께 읽는 문서가 아니라 에이전트가 효율적으로 검색·소비하도록 우선 설계한다.
• 에이전트용 문서는 작은 조각으로 회수해도 독립적으로 이해되어야 하고, 예측 가능하고 정확한 헤딩과 결정론적 메타데이터를 가져야 한다.
• init과 update 명령, Git 이력 분석, OKF front matter, GitHub Actions, 변경 로그와 PR 흐름이 문서 생성과 유지보수를 자동화한다.
• 초기 DeepSWE 평가에서는 성공률을 유지하거나 소폭 높이면서 도구 호출·검색·출력·토큰 사용량을 줄이는 신호가 나타났다.

에이전트가 대부분의 코드를 작성하는 개발 환경에서는 문서가 단순한 설명서가 아니라 코드베이스를 탐색하고 의사결정하는 일반 목적 기억(general-purpose memory)의 일부가 된다. OpenWiki는 범용 기억 문제를 먼저 구조가 분명한 코드 문서에서 풀고, 이후 더 넓은 기억 영역으로 확장하려는 접근이다.

1. OpenWiki가 겨냥하는 문제와 출발점

OpenWiki는 저장소 문서를 생성하고 유지하는 CLI이며, 문서의 최우선 독자는 사람보다 에이전트다.

1.1. 일반 목적 기억에서 코드 문서로

1. 다음 AI 주제에 대한 문제의식

   1. CEO Harrison은 “AI 분야의 다음 큰 것은 무엇인가?”라고 물었다. 지난해의 큰 주제가 OpenClaw와 개인용 에이전트였다면, 다음 주제는 무엇인지 묻는 질문이었다.
   2. 답은 일반 목적 기억(general-purpose memory)이었다. 에이전트 기억은 지난 4년 또는 3년 반 동안 개척 연구 영역이었지만, 어떤 코드베이스에도 적용되는 범용적인 기억을 제대로 구현한 사례는 아직 부족했다.
   3. 일반 목적 기억은 이제 실제로 작동할 수 있는 다음 큰 주제라는 판단이 OpenWiki의 출발점이 됐다.

2. 코드 문서를 첫 적용 영역으로 선택한 이유

   1. 코드 기반 문서는 문제의 경계가 비교적 분명하다. 어떤 종류의 코드베이스에도 적용되는 일반 목적 기억을 만들 수 있다고 판단할 수 있는 영역이다.
   2. 코드 문서에서 얻은 구조와 운영 방식을 장차 다른 기억 영역으로 확장할 계획이다.
   3. 현대의 대규모 언어 모델(LLM)과 에이전트 아키텍처가 과거보다 훨씬 많은 문서 생성·분류·갱신 작업을 가능하게 만들었다.

1.2. OpenWiki의 세 가지 설계 논제

1. 에이전트를 위한 설계

   1. 기존 저장소 문서 사이트나 기억 시스템은 사람과 에이전트를 동시에 대상으로 삼는 경우가 많지만, 두 독자의 문서 구조와 제시 방식은 크게 다르다.
   2. 사람이 에이전트를 통해 코드를 작성하는 비중이 커질수록 에이전트가 소비하기 쉬운 문서 구조가 더 중요해진다.

2. 개발자 도구로서의 간단한 온보딩

   1. 개발자는 매일 CLI(Command-Line Interface)를 사용하므로 NPM 설치 한 번과 초기화 한 번으로 시작하는 방식이 진입 장벽을 낮춘다.
   2. API 키, 모델, 저장소를 탐색하는 방식에 관한 위키 브리프(wiki brief)를 묻는 설정 마법사가 초기 구성을 맡아야 한다.

3. 사람의 추가 작업 없는 자동 갱신

   1. Cloud Code 같은 코딩 에이전트에게 문서를 한 번 생성하게 하는 일은 이미 가능하지만, 코드 변경에 맞춰 문서를 계속 최신 상태로 유지하는 일은 훨씬 어렵다.
   2. OpenWiki는 저장소 변경을 감지하고 문서를 갱신한 뒤 PR(Pull Request)을 열어야 하며, 개발자는 결과를 검토하고 병합하는 정도만 하면 된다.

2. 사람용 문서와 에이전트용 문서의 구조적 차이

사람용 문서가 이야기의 흐름과 시각적 안내를 중시한다면, 에이전트용 문서는 정확한 조각 회수와 제한된 컨텍스트 사용을 중시한다.

2.1. 사람이 읽는 문서가 전제하는 경험

1. 서사 중심의 빠른 시작

   1. 사람용 문서는 저장소의 배경을 설명하는 빠른 시작(quickstart)에서 출발하고, 문서 페이지들이 순서와 이야기의 흐름을 갖도록 만든다.
   2. 독자는 앞뒤 문맥을 따라가며 전체 구조를 이해하므로 서로 고립된 짧은 조각만으로는 충분하지 않다.

2. 시각 자료와 연속적인 설명

   1. 스크린샷과 동영상은 사람이 기능과 흐름을 빠르게 파악하게 돕는다.
   2. 사람에게 자연스러운 이야기 구조와 시각 자료는 에이전트가 필요한 작은 사실 하나를 찾아 넣는 작업에는 최적화되지 않는다.

2.2. 에이전트가 소비하는 문서의 요구사항

1. 조각 단위 회수(fragment retrieval)

   1. 에이전트는 문서 전체보다 필요한 조각을 검색해 가져오므로 각 콘텐츠는 어느 위치에서 잘려 와도 스스로 이해할 수 있어야 한다.
   2. 한 파일의 내용은 하나의 구체적인 주제에 집중해야 하며, 에이전트가 여러 영역에서 문맥을 조립하는 부담을 줄여야 한다.

2. 검색과 필터링에 적합한 표면

   1. 헤딩은 예측 가능하고 정밀하며 정확해야 한다. 그래야 에이전트가 검색과 필터링 결과를 안정적으로 해석한다.
   2. 문서 간 링크는 한 문서에서 관련 문서로 즉시 이동할 수 있는 탐색 경로를 제공한다.

3. 컨텍스트 윈도우 예산 관리

   1. 문서 구조는 모델의 컨텍스트 윈도우(context window)에 맞아야 한다.
   2. 무작위 Base64 문자열 하나가 에이전트 도구 호출에 포함되어 50,000토큰을 추가하는 상황처럼, 의미 없는 대용량 데이터가 검색 결과를 오염시키지 않아야 한다.

3. OpenWiki가 생성하는 문서 구조

OpenWiki는 특정 주제 목록을 사람 손으로 고정하기보다 에이전트가 저장소를 읽고 필요한 문서 영역을 판단하도록 하며, 형식과 메타데이터는 결정론적으로 통제한다.

3.1. Markdown 기반 위키와 핵심 파일

1. Markdown 파일 묶음

   1. 결과물은 특정 구조를 가진 Markdown 파일 여러 개와 파일 사이의 링크로 구성된다.
   2. Karpathy의 LLM Wiki를 본 사람이라면 익숙할 형태이며, 저장소에 함께 커밋할 수 있는 텍스트 문서다.

2. quickstart.md

   1. 모든 OpenWiki에는 quickstart.md가 생성된다.
   2. 에이전트는 이 파일에서 저장소의 높은 수준의 개요와 위키의 다른 문서 콘텐츠가 어디에 있는지 먼저 파악한다.

3. 디렉터리별 index.md와 log.md

   1. 에이전트가 필요하다고 판단한 디렉터리로 문서를 나누고, 각 디렉터리의 index.md는 해당 영역의 파일 목록을 제공한다.
   2. log.md는 변경 로그(change log)로서 최근 갱신에서 무엇이 바뀌었는지 알려준다. 사람은 매번 모든 위키 문서를 읽지 않고 변경 로그를 기준으로 필요한 파일만 더 깊게 확인할 수 있다.

3.2. 문서 크기와 주제 범위의 제어

1. 에이전트의 자율적인 문서 분류

   1. OpenWiki는 어떤 디렉터리를 만들고 어떤 개념을 문서화할지에 대한 세부 목록을 과도하게 제공하지 않는다.
   2. 저장소의 실제 구조와 에이전트의 판단에 문서 분류를 맡겨 다양한 코드베이스에 일반화한다.

2. 생성 가이드라인

   1. 파일의 대략적인 개수와 각 파일의 크기는 안내해 문서가 지나치게 커지는 것을 막는다.
   2. 각 파일을 한 가지 주제에 집중시키면 에이전트가 개별 사실을 얻기 위해 여러 파일을 읽을 필요가 줄어든다.

3.3. Google Open Knowledge Format(OKF)

1. 결정론적 front matter

   1. OpenWiki는 Google의 Open Knowledge Format(OKF)을 채택해 모든 Markdown 파일 상단에 YAML front matter를 추가한다.
   2. 발표 시점에는 OKF 0.1 형식이 화면에 표시됐지만, Google이 OKF 0.2를 막 출시했고 다음 날 정도에 지원을 추가할 계획이었다.

2. 주요 필드

   1. 기본 필드는 type, title, description, resource tags, timestamp다.
   2. 필요한 개념이나 태그에 맞춰 임의의 필드도 추가할 수 있으므로 저장소별 메타데이터를 확장할 수 있다.

3. 검색·필터링을 가능하게 하는 메타데이터

   1. type을 사용하면 모든 아키텍처 문서처럼 특정 유형의 문서를 한 번에 요청할 수 있다.
   2. 태그를 기준으로 필요한 문서를 좁힐 수 있어, 작은 front matter 하나가 문서 검색과 회수의 효율을 누적해서 높인다.

4. 문서 간 연결

   1. resource tags는 저장소 안의 개별 파일을 가리킬 수 있고, Markdown 링크는 위키 문서끼리 연결한다.
   2. 에이전트가 문서 A의 조각을 읽다가 문서 B에 대한 링크를 만나면 관련 문맥을 빠르게 따라갈 수 있다.

4. 생성 품질과 초기 평가

OpenWiki의 핵심 병목은 문서를 만드는 일보다 필요한 문서를 정확히 검색하고 회수하는 일이며, 초기 평가 결과는 토큰 효율성에서 특히 긍정적인 신호를 보였다.

4.1. DeepSWE 작업 비교

1. 평가 구성

   1. 코딩 에이전트 벤치마크인 DeepSWE에서 OpenWiki 없이 작업을 수행한 일부 과제를 먼저 실행한다.
   2. 같은 과제의 저장소에 위키를 생성한 뒤 다시 실행해 OpenWiki 유무에 따른 차이를 비교한다.

2. 초기 성공률

   1. 약 20개 과제에서 OpenWiki가 없을 때 보통 7~8개가 성공했고, OpenWiki가 있을 때는 9~10개가 성공했다.
   2. 성공률 상승은 아직 작고 초기 표본에 불과하지만, 결과가 같거나 더 좋아지는 방향을 확인했다.

3. 효율성 신호

   1. OpenWiki를 사용하면 도구 호출, 검색 횟수, 출력량이 줄어드는 경향이 나타났다.
   2. 더 나은 저장소 문맥을 제공하면 에이전트가 코드베이스를 더 효율적으로 탐색하고 변경을 구현할 수 있어 토큰 소비량이 크게 감소한다.
   3. 더 많은 벤치마크 결과는 추후 공개할 예정이며, 현재 결과는 유망하지만 아직 확정적인 결론은 아니다.

4.2. 생성보다 어려운 검색·회수

1. 생성의 상대적 용이성

   1. 현대 에이전트는 코드베이스를 읽고 문서 초안을 만드는 작업을 비교적 잘 수행한다.
   2. 문서가 많아질수록 필요한 조각을 정확히 골라 컨텍스트에 넣는 검색·회수(retrieval)가 더 큰 문제로 남는다.

2. OKF와 링크의 역할

   1. OKF 필드는 유형·태그·설명 같은 결정론적 진입점을 제공해 검색과 필터링을 안정화한다.
   2. 문서 링크는 검색된 조각에서 연결된 개념으로 확장할 수 있게 해 회수된 문맥의 주변부를 빠르게 탐색하게 한다.

5. 사람도 읽는다는 사실을 반영한 수정

에이전트 전용으로 시작한 OpenWiki는 엔지니어가 결과 문서를 직접 읽고 싶어 한다는 피드백을 받아 사람의 이해를 돕는 다이어그램을 추가했다.

5.1. 잘못 세운 초기 가정

1. 에이전트만 독자라는 가정

   1. 코드 작성에 에이전트를 거의 전적으로 사용하는 관점에서는 문서를 에이전트 소비용으로만 만들면 된다고 판단하기 쉽다.
   2. 실제 사용자들은 여전히 엔지니어링 과정에 참여하고 코드와 문서를 직접 읽기 때문에, 사람을 완전히 제외할 수 없었다.

2. 사람을 위한 조정

   1. Markdown은 자연어라 사람도 읽을 수 있지만, 긴 텍스트만으로 저장소의 순서·상태·흐름을 이해하기에는 부담이 있다.
   2. 사람 독자를 지원하려면 에이전트용 구조를 훼손하지 않으면서 시각적 요약 층을 더해야 한다.

5.2. 다이어그램의 추가

1. 사람의 이해를 돕는 표현

   1. 시퀀스 다이어그램(sequence diagram), 상태 다이어그램(state diagram), 플로차트(flowchart)는 실행 순서와 상태 전이를 한눈에 보여준다.
   2. 다이어그램은 텍스트만 있을 때보다 사용자가 문서의 핵심 구조를 훨씬 쉽게 파악하게 한다.

2. 에이전트에도 가능한 이점

   1. 다이어그램은 에이전트가 생성하기 어렵지 않으며, 생성할 수 있는 표현은 소비할 가능성도 있다.
   2. 다만 다이어그램이 에이전트 평가 결과를 개선하는지 입증하는 실험 수치는 아직 없고, 확실하게 확인된 주된 이점은 사람의 문서 소비성 향상이다.

6. CLI 동작과 자동화 파이프라인

OpenWiki CLI는 init으로 저장소를 온보딩하고 update로 변경분을 반영하는 단순한 두 명령 구조를 갖는다.

6.1. openwiki init과 설정 마법사

1. 초기 설정

   1. 설정 마법사는 LLM API 키, 사용할 모델, 저장소에 대한 추가 지침을 입력받는다.
   2. 지침은 위키 생성을 위한 유일한 프롬프트가 아니라, 저장소를 어떻게 탐색해야 하는지 알려주는 고수준의 추가 문맥이다.

2. 자동으로 작성되는 파일

   1. GitHub Actions 워크플로가 저장소에 생성되고 매일 cron으로 실행되어 위키를 최신 상태로 유지한다.
   2. agent.md, claw.md 또는 둘 다 존재하면 OpenWiki가 무엇인지, 어떻게 접근하는지, 언제 참조해야 하는지를 알리는 문맥을 삽입한다.
   3. 현재 에이전트가 OpenWiki를 알게 되는 유일한 통로는 이 파일에 주입되는 안내다.

3. 온보딩 완료 후의 경험

   1. 설정 파일과 워크플로를 커밋하고 병합하면 매일 저장소 변경에 맞춰 위키가 자동으로 갱신된다.
   2. 에이전트는 이미 위키의 존재와 사용 시점을 알고, 개발자는 별도의 운영 작업 없이 문맥 효율성의 이점을 얻는다.

6.2. 초기 생성 단계

1. 저장소와 이력의 분석

   1. 에이전트는 저장소를 살펴보고 작업 계획을 작성한다.
   2. 현재 코드 스냅샷뿐 아니라 Git 이력, Git 커밋 메시지와 제목을 읽어 코드가 어떻게 변화하고 발전했는지 파악한다.

2. 문서화와 결정론적 검증

   1. 분석 결과로 실제 문서를 작성한 뒤 모든 문서가 OKF 형식에 맞는지 결정론적 패스(deterministic pass)가 검사한다.
   2. index.md, 변경 로그, 기타 메타데이터 파일은 자동으로 정리되고, 에이전트는 자신이 변경한 구체적인 내용도 기록한다.

6.3. openwiki update와 변경분 반영

1. 변경 여부 선별

   1. 예약된 실행이 먼저 Git 이력을 확인하고 last-update.json에 기록된 마지막 실행 시점 이후 변경이 있었는지 판단한다.
   2. 변경이 없으면 에이전트를 다시 실행하지 않는다. 바뀐 내용이 없을 때 위키를 불필요하게 재생성하지 않는 방식이다.

2. 커밋 기반 갱신

   1. 변경이 있으면 마지막 실행 이후 병합된 모든 커밋을 가져와 저장소 문서를 변경분에 맞게 수정한다.
   2. 기본 주기는 하루 한 번이지만 하루에 2,000개 커밋이 들어오는 저장소라면 4시간·6시간·8시간 주기로 GitHub Actions를 조정할 수 있다.

3. PR을 통한 안전한 반영

   1. 갱신 결과는 자동으로 PR로 열리고, 개발자는 변경 내용을 검토한 뒤 병합한다.
   2. 병합이 끝나면 위키가 최신 상태가 되므로 자동 생성과 사람의 최종 승인 사이에 안전한 검토 지점이 생긴다.

7. 공개 현황, 배포 방식과 다음 단계

OpenWiki는 MIT 라이선스의 오픈소스 프로젝트로 배포되며, 현재의 범용 설계와 저장소별 포크를 함께 허용한다.

7.1. 오픈소스 배포 모델

1. 사용과 배포

   1. GitHub에서 별(star)과 포크가 늘고 있고, 사용자는 저장소를 포크해 자신의 용도에 맞게 수정하거나 NPM으로 바로 사용할 수 있다.
   2. MIT 라이선스라 원하는 제공자(provider)를 선택해 설치하고 사용할 수 있다.

2. 제공자와 커스터마이징

   1. OpenWiki는 약 10~15개의 서로 다른 모델 제공자를 지원한다.
   2. 특정 워크플로와 에이전트 사용 이유가 있다면 범용 프로젝트를 그대로 쓰기보다 포크한 뒤 필요한 수정을 직접 반영하는 방식이 적합하다.
   3. 개발자는 오픈소스를 선호하므로 공개 배포는 도입을 넓히고, 동시에 각 팀의 문서·검색·운영 방식에 맞춘 커스터마이징을 가능하게 한다.

7.2. 예정된 개선

1. 프롬프트와 평가 강화

   1. 더 나은 프롬프트로 큰 저장소를 분석하고 문서를 스스로 갱신하는 능력을 높인다.
   2. DeepSWE 같은 평가에 더 투자해 문서 품질과 실제 코딩 에이전트 효율성의 관계를 검증한다.

2. 전용 검색·회수 도구

   1. 지금은 agent.md나 claw.md에 OpenWiki를 설명해 에이전트가 위키를 읽게 하지만, 이것만으로는 최종 상태가 아니다.
   2. 위키를 검색하고 필터링하고 질의할 수 있는 전용 도구를 제공하면 에이전트가 필요한 조각만 더 정확하게 가져올 수 있다.
   3. 아직 병합되지 않은 평가에서 전용 검색·회수 도구의 이득이 이미 관찰됐으며, 다음 출시의 핵심 방향은 더 나은 프롬프트와 구체적인 위키 retrieval 도구다.

3. 실제 적용 권고

   1. 문서화 상태가 가장 나쁜 저장소를 골라 OpenWiki를 시험하면 문맥 정리의 효과를 가장 분명하게 볼 수 있다.
   2. 화면의 QR 코드는 GitHub 저장소로 연결되고, NPM에서 OpenWiki 패키지를 설치해 바로 시작할 수 있다.

주요 발언 모음

“일반 목적 기억은 실제로 작동할 다음 큰 것이 될 것이다.”

“사람들은 이제 모든 일에 에이전트를 사용한다. 아마 더는 코드를 많이 직접 작성하지 않고, 에이전트가 그 많은 일을 맡고 있을 것이다.”

“에이전트를 위해 문서를 만들면 구조와 콘텐츠를 제시하는 방식, 콘텐츠를 생성하고 유지하는 방식이 모두 달라진다.”

“문서 생성은 에이전트로 꽤 쉽게 할 수 있지만, 그 문서에서 회수하는 일은 훨씬 더 어렵다.”

“문서가 변경될 때마다 사람이 추가 작업을 하지 않아도 기억 또는 위키가 자동으로 갱신되어야 한다.”

“사람은 여전히 엔지니어링 과정에 있고, 결국 이 문서도 직접 읽고 싶어 한다.”

“문서화가 가장 나쁜 저장소에서 시험해 보라.”

핵심 데이터 & 수치

• 영상 길이: 996초(약 16분 36초)다.
• 일반 목적 기억의 연구 기간: 에이전트 기억은 약 4년 또는 3년 반 동안 개척 연구 영역으로 다뤄졌다.
• DeepSWE 평가 표본: OpenWiki 유무를 비교한 초기 작업은 약 20개다.
• 초기 성공 작업 수: OpenWiki 없이 보통 7~8개, OpenWiki 사용 시 9~10개가 성공했다.
• 컨텍스트 비용 사례: 무작위 Base64 문자열이 도구 호출에 들어가면 50,000토큰을 추가할 수 있다.
• OKF 버전: 발표 화면은 0.1이었고, 0.2 지원이 다음 날 정도에 추가될 예정이었다.
• 자동 갱신 기본 주기: GitHub Actions cron은 하루 한 번 실행된다.
• 고빈도 저장소 예시: 하루 2,000개 커밋이 들어오면 4시간·6시간·8시간 주기를 고려할 수 있다.
• 모델 제공자 지원 수: 약 10~15개 제공자를 지원한다.
• 문서 메타데이터 필드: type, title, description, resource tags, timestamp가 OKF의 주요 필드다.

결론 및 시사점

1. 에이전트가 코드 작성의 중심이 될수록 저장소 문서는 사람의 순차 독해보다 에이전트의 조각 회수와 컨텍스트 예산을 기준으로 설계해야 한다.
2. 범용 기억을 한 번에 해결하려 하기보다 코드 문서처럼 구조와 검증 기준이 분명한 영역에서 시작하는 접근이 현실적이다.
3. quickstart.md, 집중된 Markdown 파일, index.md, log.md, OKF front matter, 문서 간 링크는 에이전트 탐색 비용을 낮추는 기본 구성요소다.
4. 문서 생성만 자동화해서는 충분하지 않으며 Git 이력 기반 변경 감지, 결정론적 포맷 검증, PR 승인 흐름까지 연결해야 유지 가능한 기억이 된다.
5. 에이전트 전용 설계는 사람의 검토를 배제하지 않는다. 다이어그램 같은 표현을 더해 에이전트의 구조적 접근성과 사람의 가독성을 함께 확보해야 한다.
6. 초기 DeepSWE 결과는 성공률의 소폭 개선보다 도구 호출·검색·출력·토큰 감소가 더 중요한 가치일 수 있음을 보여준다.
7. 다음 경쟁력은 agent.md나 claw.md에 위키 존재를 알리는 수준을 넘어 전용 검색·필터·질의 인터페이스를 제공하는 데 있다.
8. 가장 문서화가 나쁜 저장소에서 실제로 시험하고, 자동 생성 PR을 사람이 검토하는 운영 루프를 구축하는 것이 도입의 첫 단계다.

핵심 요약 (20줄)

OpenWiki는 에이전트가 소비하도록 저장소 문서를 생성하고 유지하는 CLI다. OpenWiki의 더 큰 목표는 코드 문서에서 시작하는 일반 목적 기억 시스템을 만드는 것이다. 일반 목적 기억은 에이전트 연구에서 약 4년 동안 중요한 개척 영역이었지만 범용 구현은 아직 부족했다. 현대 LLM과 에이전트 아키텍처는 범용 기억을 코드베이스에서 구현할 수 있는 조건을 만들었다. 에이전트용 문서는 사람용 문서처럼 긴 서사보다 조각 단위 회수에 맞춰야 한다. 각 문서 조각은 어느 위치에서 검색돼도 독립적으로 이해될 수 있어야 한다. 정확하고 예측 가능한 헤딩은 에이전트의 검색과 필터링 품질을 높인다. 불필요한 Base64 데이터가 컨텍스트에 들어가 50,000토큰을 소비하는 상황은 피해야 한다. quickstart.md는 저장소 개요와 위키의 나머지 콘텐츠를 안내하는 출발점이다. index.md는 디렉터리별 문서 목록을 제공하고 log.md는 최근 변경을 설명한다. OKF front matter의 type, title, description, resource tags, timestamp는 결정론적 회수를 가능하게 한다. 문서 간 Markdown 링크는 검색된 조각에서 관련 문맥으로 이동하는 경로를 만든다. DeepSWE 약 20개 작업에서 성공 수는 OpenWiki 없이 7~8개, 사용 시 9~10개였다. 초기 평가에서 OpenWiki는 성공률을 유지하거나 높이면서 도구 호출과 토큰 사용량을 줄였다. 에이전트만 문서를 읽는다는 초기 가정은 사람이 직접 읽고 싶다는 사용자 피드백으로 수정됐다. 시퀀스·상태·플로차트 다이어그램은 사람이 문서를 이해하는 속도를 높인다. init은 설정 마법사와 GitHub Actions를 생성해 저장소를 자동으로 온보딩한다. update는 마지막 실행 이후 Git 커밋을 확인하고 변경이 있을 때만 위키 갱신 PR을 연다. MIT 라이선스와 약 10~15개 제공자 지원은 포크와 저장소별 커스터마이징을 가능하게 한다. 전용 검색·필터·질의 도구와 대형 저장소 평가가 OpenWiki의 다음 핵심 개선 방향이다.