DeepWiki·CodeWiki·deepwiki-open — 같아 보이는 코드 위키 도구 세 개의 진짜 차이

2024년 4월에 Cognition Labs(같은 회사의 AI 소프트웨어 엔지니어 Devin으로 유명한)가 deepwiki.com을 공개했다. GitHub repo URL 앞에 prefix만 붙이면 LLM이 자동 생성한 위키가 떠오르는 서비스이다. 곧 커뮤니티에서 deepwiki-open이 self-host 버전을 들고 등장했고, 2025년 11월에는 Google이 codewiki.google로 비슷한 영역에 들어왔다.

세 도구는 첫인상이 거의 똑같다. "GitHub repo 던지면 LLM이 8섹션짜리 위키 만들어 줌"이라는 한 줄 컨셉. 그런데 막상 깊이 보면 누가 만들었고, 어디서 돌고, 어떤 LLM을 어떻게 쓰는지가 완전히 다르다. 이 글은 그 세 가지를 정직하게 비교하는 글이다 — 어느 게 "더 좋다"가 아니라, 각각이 어떤 사용 환경을 가정하고 있는지 정리한다.

1. 세 도구의 한 줄 정의

다이어그램 설명. 세 도구를 출시 시점·운영 주체·핵심 차별점으로 한 줄씩 묶었다. 가장 먼저 만든 건 Cognition의 DeepWiki, 그 뒤로 커뮤니티가 OSS로 deepwiki-open을 내고, 1년 반 후 Google이 CodeWiki로 들어왔다. "누가 만들었나"가 "어디서 돌고 무엇이 자유로운가"를 결정한다.

2. 공통점 — 셋 다 "LLM이 8섹션 마크다운 만든다"

세 도구를 같은 카테고리로 묶을 수 있는 이유는 분명하다. 모두 다음 다섯 가지를 공유한다.

• 입력: Git repo (대부분 GitHub). 클라이언트가 URL을 던지거나 self-host 인스턴스가 repo 폴더를 가리키면 됨.
• 생성 방식: 100% LLM. AST 같은 결정적 추출 도구를 안 거치고, 코드와 README를 LLM에 통째로 던져 위키 마크다운을 받음.
• 출력 구조: 한 repo당 약 8섹션의 마크다운 페이지 — Overview / Structure / Architecture / API / Subsystems / Operations / Testing / Glossary. 이 8섹션은 deepwiki.com을 기준으로 굳어진 사실상의 표준이다.
• 다이어그램: 페이지마다 mermaid(텍스트로 다이어그램을 표현하는 마크다운 호환 문법) 다이어그램 몇 개가 있다. LLM이 코드를 보고 즉석에서 그림.
• 검색 인터페이스: 자연어 질문을 받아 위키 안에서 RAG로 답하는 Q&A. DeepWiki는 Devin Search, CodeWiki는 Google 검색 친화, deepwiki-open은 자체 검색.

위 다섯이 공통이라는 게 핵심이다. "코드 위키 AI"라는 카테고리는 사실상 DeepWiki가 정의했고 나머지 둘이 그 정의를 따른다. 위키의 모양·페이지 구조·다이어그램 스타일이 거의 동일한 이유다.

3. 차이점 — 운영 주체가 만드는 자유도의 차이

다이어그램 설명. 7개 축에서 셋이 어떻게 갈리는지 한눈에 본다. "누가 운영하나"가 모든 다른 축의 root다 — Cognition은 자체 SaaS로 자체 모델만 쓸 수 있고, Google은 Google Cloud 위에서 자기 LLM 쓰고, 커뮤니티 OSS는 self-host라 모든 선택을 본인이 한다.

4. 각 도구가 잘하는 것 — 사용 환경별 정리

비교표만 보면 추상적이다. 실제 사용 환경을 그려 보면 어느 도구가 어디에서 빛나는지 분명해진다.

DeepWiki — 처음 보는 OSS repo를 빠르게 훑을 때

가장 큰 강점은 "이미 인덱싱돼 있다"는 점이다. 유명 OSS repo(react·django·kubernetes 등)는 deepwiki.com에 들어가면 위키가 떠 있다. 1초만에 8섹션 개요를 볼 수 있다. GitHub repo URL을 deepwiki.com 도메인으로 바꿔 치면 끝 — 가입·로그인 불필요. OSS 학습용으로는 진입 장벽이 가장 낮은 도구다.

한계는 운영 주체가 무엇을 인덱싱했는지를 통제할 수 없다는 것. private repo는 적용 안 되고, 8섹션 구성도 Cognition이 결정한 대로 받는다. .devin/wiki.json으로 페이지 목록을 일부 override 가능하지만 SaaS 한계 안에서다.

Google CodeWiki — Google 생태계 안에서 쓸 때

2025년 11월 후발 주자라 인덱싱된 repo 양은 적지만, Google Drive·Google 검색·Google Cloud 인증 통합이 차별 강점이다. 회사가 Google Workspace를 쓰고 사내 코드를 Google Cloud에 둔다면 CodeWiki의 private 인덱싱 옵션이 의미를 가진다. 일반 검색에서 위키 결과가 자연스럽게 떠오르는 흐름도 Google다운 장점.

한계는 Google 생태계 안에서만 의미가 있다는 점. AWS 위 인프라거나 사내 GitLab 자체 호스팅이면 CodeWiki를 끌어다 쓰기 어렵다. ToS·사용량 정책도 Google이 정한 대로 따라야 한다.

deepwiki-open — 사내망·자체 통제가 필요할 때

가장 큰 강점은 "내가 모든 걸 정한다"는 점이다. self-host니까 사내 망 안에서도 돌릴 수 있고, 외부 API에 코드 한 줄도 안 보내고 로컬 LLM(Llama·Qwen 등)으로만 돌릴 수도 있다. prompt도 수정 가능, 출력 페이지 구조도 fork해서 바꿀 수 있다.

한계는 운영 부담을 본인이 진다는 점이다. 서버 띄우기, LLM API 비용 결제, 업그레이드 관리 모두 본인 일. 100만 repo 인덱싱 같은 규모는 현실적으로 불가능 — 본인이 명시한 repo만 직접 처리한다.

5. 어느 도구를 언제 쓰나 — 의사결정 한 줄

다이어그램 설명. 세 도구는 같은 카테고리지만 사용 자리는 거의 겹치지 않는다. "운영 주체"라는 한 축이 사용 환경의 적합성을 거의 다 결정한다. 무료 OSS 학습엔 DeepWiki, Google 생태계엔 CodeWiki, 자체 통제엔 deepwiki-open.

마무리 — 같은 이름 비슷한 컨셉, 그래도 다른 도구

비슷한 이름의 도구 셋이 같은 카테고리에 줄지어 있는 풍경은 종종 함정이다. 첫째 함정: "이름이 비슷하니 다 같은 거 아닌가"라는 인상을 가질 수 있다. 둘째 함정: "이미 있으니 새로 만들 필요 없네"라는 단정이다. 둘 다 거짓일 수 있다.

같은 한 줄 컨셉("GitHub repo 던지면 LLM이 8섹션 위키") 아래에 운영 주체·호스팅·LLM 자유도·사내 코드 처리·커스터마이즈 가능 범위가 모두 다른 세 도구가 나란히 서 있다. 어느 게 더 좋다가 아니라, "내가 어떤 환경에서 어떤 자유도가 필요한가"의 답이 도구 선택을 결정한다. OSS 학습이면 DeepWiki, Google 환경이면 CodeWiki, 자체 통제가 필요하면 deepwiki-open. 그리고 이 셋의 공통 가정이 본인의 상황과 안 맞으면 그때 새 도구를 만드는 게 의미를 가진다. 비교의 끝이 종종 새로운 선택의 시작이 되는 이유다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.