How Credit Genie keeps codebase docs fresh with OpenWiki

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Credit Genie는 OpenWiki로 코드 변경에 따른 문서 생성·갱신을 자동화하고, 엔지니어와 코딩 에이전트가 최신 코드베이스 지식을 활용하도록 지원한다.

📌 핵심 요약

• Credit Genie의 AI·ML 엔지니어링 팀은 기존 Notion·README·AGENTS.md 문서의 노후화와 개인에게 집중된 지식 문제를 해결하기 위해 LangChain의 오픈소스 저장소 문서화 에이전트 OpenWiki를 도입했다.
• 문서는 각 저장소의 openwiki/ 폴더에 보관되며, 사람은 GitHub Pages 기반 통합 검색 포털을 이용하고 코딩 에이전트는 작업 전에 openwiki/ 폴더를 확인한다.
• OpenWiki는 매일 밤 커밋 변경을 확인해 의미 있는 차이가 있으면 문서 갱신 PR을 생성한다. 자동 승인·병합 액션과 일일 순회 작업이 업데이트 병합 및 포털 재구축을 지원하며, 새 저장소는 포털 설정 한 번의 변경으로 등록 절차를 시작한다.
• 팀은 초기 효과로 저장소 전반의 맥락 접근 속도 향상, 개인에게 묶인 지식의 해소, 온보딩 개선, 부서 간 대화의 자신감 향상을 보고했지만 정량적인 성과 수치는 제시하지 않았다.
• 다음 목표는 내부 저장소 간 지식 그래프를 OpenWiki에 통합하고 모든 엔지니어링 팀과 코드 저장소로 도입을 확대하는 것이다. 저장소 간 의존성과 코드 변경의 파급 범위를 문서에서 보여주는 기능은 향후 단계로 제시됐다.

🧩 주요 포인트

1. 코드 변경 감지부터 문서 PR 병합·포털 갱신까지 자동화 → 문서 유지관리를 별도 업무에서 개발 생명주기의 일부로 전환.
2. 저장소의 openwiki/와 통합 검색 포털을 병행 → 코딩 에이전트의 작업 맥락 확보와 사람의 시스템 이해를 함께 지원.
3. 초기 효과는 정성적 보고이고 저장소 간 지식 그래프 통합은 향후 목표 → 현재의 지식 접근 개선과 앞으로의 변경 영향 파악을 구분해 평가할 필요.

🧠 상세 정리

1. 코드베이스 성장과 문서 노후화

Credit Genie는 개인이 재정적 미래를 관리하도록 돕는 모바일 중심 금융 웰니스 플랫폼으로, AI·ML 엔지니어링 팀과 코드베이스가 커지면서 문서를 최신 상태로 유지하기 어려워졌다. 팀은 프로젝트별 Notion 페이지와 README, AGENTS.md 파일을 관리했지만 빠르게 변하는 개발 환경에서 내용이 곧 낡았고, 필요한 정보를 찾는 일도 쉽지 않았다. 수동 문서화 절차를 정착시키려는 시도 역시 문서 작성과 유지에 드는 시간이 다른 시급한 업무와 경쟁하면서 충분한 성과를 내지 못했다. 저장소의 역할이나 기능의 위치, 하위 시스템의 작동 방식에 관한 지식이 개인에게 집중됐으며, 코딩 에이전트도 신뢰할 기준 정보가 부족해 오래되거나 불완전한 맥락으로 행동하는 문제를 겪었다.

2. 저장소 문서와 통합 포털의 결합

AI·ML 책임자 Mattia Ciollaro의 부수 프로젝트로 시작한 작업은 팀의 조직 지식을 보존하는 장치로 발전했다. Mattia는 LangChain의 오픈소스 저장소 문서화 에이전트 OpenWiki를 활용해, 도입된 모든 저장소의 문서를 GitHub Pages에서 하나의 검색 가능한 웹 인터페이스로 제공하는 셀프서비스 포털을 구축했다. 문서 자체는 각 프로젝트 저장소의 openwiki/ 폴더에 두고, 팀원은 중앙 포털에서 여러 저장소의 정보를 검색하고 읽으며, 코딩 에이전트는 행동에 앞서 해당 폴더를 확인하도록 했다. 이 구조는 사람이 읽기 쉬운 지식 창구와 에이전트의 작업 맥락을 함께 제공하며, 구현 판단이 추측보다 실제 코드를 기준으로 이루어지도록 돕는 방식으로 설명된다.

3. 문서 갱신을 개발 과정에 연결하는 자동화

OpenWiki는 매일 밤 실행돼 커밋 변경을 확인하고, 의미 있는 차이를 발견하면 문서 업데이트를 생성해 해당 저장소에 PR을 연다. 새 저장소를 추가할 때는 포털 설정을 한 번 변경하면 대상 저장소에 맞춤형 OpenWiki GitHub Actions 워크플로를 추가하는 PR이 자동으로 생성된다. Credit Genie는 문서 업데이트 PR의 병합이 병목이 되지 않도록 자동 승인·병합 액션을 추가했으며, 매일 실행되는 순회 작업은 도입된 저장소 전체의 대기 중인 업데이트를 병합하고 포털을 다시 구축한다. Mattia는 이 방식의 의미를 문서를 별도의 번거로운 업무로 취급하는 대신 코드 생명주기의 일부로 만드는 데 있다고 설명했다.

4. 코딩 에이전트와 사람의 활용 방식

저장소 수준에서 OpenWiki는 코딩 에이전트가 변경을 시작하기 전에 낯선 시스템의 구조와 맥락을 빠르게 파악하는 데 사용된다. 에이전트에는 저장소를 체크아웃할 때 openwiki/ 폴더를 찾으라는 명시적인 안내가 주어져, 작업에 필요한 정보를 먼저 접하도록 한다. 포털 수준에서는 Mattia와 엔지니어, 비기술 이해관계자가 복잡한 소프트웨어 시스템에 대한 이해를 되짚고 시스템의 역할과 상호 관계를 공유하는 지식 허브로 쓰인다. Mattia에 따르면 최신 자동 생성 문서는 많은 코드를 직접 읽거나 해당 분야의 전문가를 찾아 설명을 듣는 데 필요한 노력과 조율을 줄여, 필요할 때 누구나 시스템을 학습하고 부서 간 대화에 참여하도록 돕는다.

5. 초기 효과와 도입 확대의 근거

Mattia의 팀은 OpenWiki가 이미 활발하게 사용되고 있으며 실무적 가치를 제공한다고 보고했다. 주요 효과로는 저장소 전반의 맥락에 더 빠르게 접근하는 것, 개인에게 묶인 지식의 해소, 엔지니어와 이해관계자의 온보딩 개선, 낯선 시스템에 관한 부서 간 대화의 자신감 향상이 제시됐다. 수동 유지관리 없이 최신 상태를 유지하는 단일 검색 포털도 장점으로 꼽혔지만, 시간 절감이나 정확도 개선을 보여주는 정량 수치는 제공되지 않았다. Web 팀의 Ian Yoder와 Anela Trakic, Application 팀의 Patrick VanDusen은 소속 팀의 여러 저장소를 추가하고 생성 문서의 정확성을 확인했으며, Mattia는 이들의 기여가 시스템을 더 넓게 확장할 수 있다는 판단에 도움이 됐다고 설명했다.

6. 다음 단계는 저장소 간 관계와 변경 영향 파악

Credit Genie의 다음 목표는 내부 저장소 간 지식 그래프를 OpenWiki에 반영하고, 모든 엔지니어링 팀과 코드 저장소를 점진적으로 도입하는 것이다. 이 작업은 엔지니어링 책임자 Adil Hashem 및 LLM 게이트웨이, 맞춤형 CLI, GraphRAG 코드 그래프 등 내부 AI 도구를 개발하는 엔지니어링 팀들과 공동으로 진행된다. 현재 팀들은 이미 저장소와 프로젝트 사이의 의존 관계를 정리하고 있으며, 다음 단계에서는 이 그래프를 OpenWiki에 연결해 각 저장소가 하는 일뿐 아니라 다른 시스템과의 연결 및 변경의 파급 가능성까지 문서에 나타내려 한다. 이는 엔지니어와 코딩 에이전트가 코드 변경 전에 영향 범위를 더 명확히 이해하도록 하려는 계획이며, 기사에서는 이미 완성된 기능이 아닌 향후 방향으로 제시된다.

🧾 핵심 주장 / 시사점

• 문서 생성뿐 아니라 승인·병합과 포털 재구축까지 연결한 점은 문서 최신성 유지가 전체 운영 과정의 자동화에 달려 있음을 보여준다.
• 같은 저장소 문서를 openwiki/와 검색 포털로 제공하는 구조는 코딩 에이전트와 사람의 서로 다른 정보 접근 방식에 대응한다.
• 저장소 간 지식 그래프 통합은 개별 시스템의 설명에서 시스템 사이의 관계와 변경 영향 설명으로 문서의 역할을 넓히려는 시도다.

✅ 액션 아이템

• OpenWiki의 커밋 변경 감지, 문서 갱신 PR, 자동 승인·병합, 포털 재구축 흐름을 문서 유지관리 자동화의 적용 대상으로 검토.
• 코딩 에이전트의 openwiki/ 사전 확인과 사람의 GitHub Pages 통합 검색 포털 활용을 지식 접근 방식에 반영.
• 저장소 간 지식 그래프 통합과 도입 확대를 검토할 때 초기 효과의 정량 수치 부재 및 변경 파급 범위 기능이 향후 단계라는 점을 반영.

❓ 열린 질문

• OpenWiki 도입 이후 맥락 접근 속도 향상과 온보딩 개선을 정량적으로 확인할 수 있는가?
• OpenWiki는 커밋 변경에서 문서 갱신이 필요한 의미 있는 차이를 어떤 기준으로 판단하는가?
• 내부 저장소 간 지식 그래프를 OpenWiki에 통합하면 코드 변경의 파급 범위를 어느 수준까지 보여줄 수 있는가?