Ontology Atlas

요약

Ontology Atlas는 코드베이스가 무엇을 만들고 왜 그런 경계를 갖는지를 저장소 안의 Markdown 폴더 하나로 유지하는 로컬 워크벤치다. wlsdks가 MIT로 공개했고, macOS 서명 앱과 Windows 미서명 베타, 정적 웹앱, 소스 체크아웃의 CLI로 배포된다.

Markdown 파일 하나가 그래프의 노드 하나가 된다. frontmatter가 자기 종류와 무엇을 가리키는지 선언하고, Atlas는 그 폴더를 읽어 그래프로 컴파일한다. 종류와 관계 타입이 작은 고정 집합이기 때문에 폴더는 읽을 수 있는 데서 그치지 않고 계산 가능해진다.

계산 가능해진 폴더는 일반 노트 도구가 답하지 못하는 질문을 받는다. 이 노드를 바꾸면 무엇이 깨지는지, 어느 capability의 영향 범위가 어디까지인지, 두 대상을 잇는 경로가 무엇인지, 무엇이 끊겼고 무엇이 낡았는지를 묻는다.

읽는 쪽이 둘이라는 점이 이 제품의 설계 전제다. 코딩 에이전트는 MCP로 그 질문을 던지고, 사람은 같은 답을 map으로 읽는다. 에이전트가 쓴 것은 전부 Markdown 파일의 한 줄로 떨어지므로 최종 판정은 git diff가 한다.

배경

소스 코드는 시스템이 어떻게 작동하는지 보여 준다. 그러나 그 코드가 어느 제품 capability를 위한 것인지, 경계가 왜 거기 그어졌는지, 무엇을 바꾸면 어디가 영향을 받는지는 대개 코드에 남지 않는다.

이 빈틈을 메우는 기존 수단은 둘 다 오래가지 못한다는 것이 README의 출발점이다. 사람만 쓰는 위키는 쓰인 그 주에 낡고, 에이전트만 쓰는 저장소는 판단할 사람이 없어 드리프트한다.

Atlas는 두 독자가 같은 층을 함께 읽고 쓰게 만들고 중재자를 git diff로 둔다. 사람이 파일과 diff로 판단하고, 에이전트는 MCP로 같은 그래프를 질의하고 갱신한다.

변경 전에 이 답을 열어 두는 것이 사용 시나리오다. 사람과 에이전트가 같은 지점에서 출발하도록 코드가 무엇을 위한 것인지, 어디서 시작할지, 무엇을 더 건드리는지, 무엇을 확인해야 하는지를 함께 본다. 그 답은 경계가 정해져 있다. 관찰된 capability 목록을 전수로 취급하지 않고, 뒷받침되지 않는 범위는 눈에 보이는 불확실성으로 남긴다.

배포와 상태

README가 스스로 못박는 조건이 둘 있다. 지금까지 나온 모든 공개 빌드는 prerelease이고, vault 포맷은 v2.0-rc로 공개 의견을 받는 RFC 상태다.

릴리스 권위는 README가 아니라 다운로드 페이지다. 그 페이지가 현재 게시된 태그, 실제 파일 크기, 체크섬, 플랫폼, 서명 상태를 생성된 기록으로 렌더한다. README는 태그도 체크섬도 복사하지 않는데, 오래된 문서가 사람들이 곧 설치할 파일과 어긋나지 않게 하려는 의도적 설계다.

앱 안의 업데이터는 가장 최근 비초안 GitHub Release에서 준비한 Pages 매니페스트를 읽으며 release candidate도 포함한다. 다만 어떤 아카이브든 설치 전에 번들된 업데이터 서명 검사를 통과해야 한다.

핵심 개념

vault

vault는 에이전트와 사람이 같이 읽고 쓰는 Markdown 파일 폴더를 뜻한다. Atlas에서 vault는 그래프로 컴파일되는 대상이자 유일한 저장소다. 앱을 폴더에 겨누면 그 자리에서 읽고 쓴다. import 단계도, 미리 만들어 둘 인덱스도, 계정도 없다.

파일 하나가 노드 하나다. frontmatter는 기계가 읽는 레코드이고 본문은 사람이 판단하는 설명이다.

---
uid: 71890f3e-7b5d-4c0a-8f14-123456789abc
slug: capabilities/token-issue
kind: capability
title: Token issue
domain: domains/auth
path: src/auth/token-service.ts          # a path — code evidence
elements:
  - elements/jwt-signer                  # a slug — an implementation-role node
dependencies:
  - capabilities/session-refresh  # a slug — another node
---

Issues access and refresh tokens for authenticated users.

다섯 kind와 척추

ontology는 도메인의 개체 종류와 관계 타입을 고정된 집합으로 정의한 구조다. Atlas의 고정 집합은 사람이 직접 쓸 수 있는 다섯 kind이고, 여기에 reader 전용 예약 kind가 하나 더 있다.

비즈니스에서 코드로 내려가는 척추는 일부러 작게 잡았다.

project
└── domain
    └── capability
        └── element

모든 심볼을 인덱싱하는 것이 목표가 아니다. 사람이나 에이전트가 capability를 이해하고 영향을 추적하고 올바른 증명을 실행하는 데 도움이 될 때 소스 산출물이 노드 자격을 얻는다. README는 이 원칙을 "curated, not exhaustive"로 요약한다.

slug와 uid와 path

세 식별자의 역할이 갈린다. 이 구분이 vault를 쓸 때 가장 먼저 익혀야 하는 문법이다.

path는 코드를 가리키고 slug는 노드를 가리킨다. 둘을 섞는 것이 가장 흔한 첫 실수이고, validate 명령이 dangling reference로 잡아낸다.

저장소 루트 디렉토리도 유효한 명시 경로다. 리뷰를 거친 path: 값이 src나 generate 같은 디렉토리여도 소스 receipt와 finalization에 참여한다. 다만 임의의 관계 slug가 파일 증거가 되지는 않는다.

typed 관계

관계 데이터베이스도, 동기화 단계도 없다. 선언하는 Markdown 파일이 frontmatter 한 줄을 갖고 있으면 Atlas가 vault를 읽을 때 엣지와 backlink를 파생시킨다.

---
slug: capabilities/vault-live-updates
kind: capability
domain: domains/local-vault-management
dependencies:
  - capabilities/topology-canvas-render   # directed: this depends on that
relates:
  - capabilities/mcp-conflict-guard       # symmetric: read these together
---

방향 있는 관계와 대칭 관계를 분리해 둔 이유는 map이 유사성을 인과로 바꾸지 않게 하려는 것이다. 함께 읽어야 하는 개념이라는 사실만으로 한쪽이 다른 쪽의 원인이 되지는 않는다.

containment는 구조 층이지 천장이 아니다. 의미 관계는 도메인과 가지를 넘나들 수 있다. 구현 증거는 노드의 path와 본문에 있고, 별도의 evidence 관계를 만들어 두지 않았다.

blast radius

blast radius는 한 노드를 바꿀 때 파급이 닿는 범위를 뜻한다. Atlas는 승인된 의존 선언만 따라가고, 폴더 구조를 인과적 확신으로 바꾸지 않는다.

여기서 Atlas가 취하는 태도가 이 제품의 성격을 잘 보여 준다. 모르는 것을 모른다고 출력에 적는다.

$ node $ATLAS/cli/src/index.mjs blast-radius capabilities/mcp-server docs/ontology --depth 2
capabilities/mcp-server — blast radius (depth 2, incoming)
  risk unknown · 1 node · 1 relation · 0 cross-domain

impact certainty unknown · declared 1 · rationale 0 · source-backed 0
Counts below follow declared depends_on only. Use reachability/subgraph for structure;
do not read unknown as low risk.

출력 마지막 두 줄이 사용 지침이다. 여기 세는 값은 선언된 depends_on만 따른다는 것, 구조를 보려면 reachability나 subgraph를 쓰라는 것, 그리고 unknown을 낮은 위험으로 읽지 말라는 것이다.

import에 대한 태도도 같다. 리뷰를 거친 정확한 element import는 직접 소스 의존 하나를 뒷받침할 수 있다. 그러나 런타임 영향, 역방향 영향, 전이 영향, 비즈니스 영향은 별도 증거 없이는 unknown으로 남는다.

로컬 우선 설계

local-first는 데이터 원본을 사용자 디스크에 두고 서버 없이 동작하는 설계를 뜻한다. Atlas는 이 원칙을 여섯 항목으로 명시한다.

이 여섯 항목이 앞서 본 세 설계와 맞물린다. 저장소가 사용자 디스크이기 때문에 판정을 git diff에 맡길 수 있고, 서버가 없기 때문에 MCP 서버를 데몬이 아니라 파일로 둘 수 있다.

방법

폴더를 여는 것으로 시작한다

앱의 첫 질문은 폴더다. Markdown 디렉토리를 가리키면 그 자리에서 읽는다. README의 모든 스크린샷이 쓰는 예제 vault는 저장소의 samples/storefront이며, 온라인 스토어를 제품, 재고, 주문, 결제, 배송, 회원, 마케팅, 지원으로 서술하고 각 도메인 안에 capability와 그 capability가 다루는 대상을 둔다.

README는 이 예제의 노드 개수를 본문에 적지 않는다. 누가 노드를 추가할 때마다 값이 달라지기 때문이고, 현재 수치가 필요하면 overview 명령으로 직접 세라고 안내한다. 문서가 낡은 수치를 들고 있지 않게 하려는 원칙이 여기서도 반복된다.

Docs 화면은 캔버스를 뺀 같은 폴더다. 여기서 할 수 있는 일은 넷이다.

• Markdown 미리 보기와 편집
• 그래프가 되는 frontmatter 확인
• backlink 따라가기
• map의 같은 개념으로 돌아가기

동기화할 사본이 따로 없다는 점이 이 화면의 전제다.

에이전트를 연결한다

Atlas는 이 컴퓨터에 이미 설치된 코딩 에이전트를 찾아낸다. 지원하는 것들은 map 옆에서 바로 열 수 있고, MCP 설정은 선택한 폴더 범위로 묶인다.

연결 절차는 세 단계이고, 마지막 단계가 이 설계의 요점이다.

생성되는 파일은 눈으로 확인할 수 있는 평문이다. Claude Code, Cursor, Codex를 비롯한 지원 클라이언트는 직접 설정 경로를 받고, 다른 MCP 클라이언트는 생성된 스니펫을 쓴다.

번들된 서버는 현재 읽기와 쓰기 표면을 tools/list로 알린다. 도구별 계약은 저장소의 mcp/README.md가 문서화하고, mcp-verify가 살아 있는 목록을 증명한다.

서버는 stdio로 말한다. 에이전트가 필요할 때 시작하고 끝나면 종료되며, 포트를 열지 않고 네트워크 요청도 하지 않는다. 코딩 에이전트 자신은 사용자가 요청할 때만 자기 제공자와 통신한다.

데스크톱 앱이 시작할 수 있는 코딩 에이전트 목록은 ACP registry의 커밋된 스냅샷이지 런타임 fetch가 아니다. 앱이 오프라인에서도 쓸 수 있고 사용자가 요청하지 않은 연결을 열지 않게 하려는 선택이다. 갱신은 pnpm acp:registry, 낡았는지 검사는 pnpm acp:registry:check이며, 이 저장소가 실제로 측정한 런타임만 verified 표시를 받는다.

map을 읽는다

노드를 고르면 무관한 것들이 흐려진다. 노드를 inspector 뒤로 숨기지 않은 채 레코드가 열리므로 같은 사실이 두 독자에게 동시에 쓰인다. 사람에게는 시각적 위계로, 에이전트에게는 typed parent와 evidence로 읽힌다.

map을 좁히는 수단은 둘이고 성격이 다르다. Recent changes는 프로젝트와 도메인 맥락을 유지하면서 최근 변경으로 범위를 좁힌다. Footprints는 사용자가 개념을 연 순서를 기록한다. 둘 다 로컬 파일과 세션 증거를 보는 뷰이지 호스팅된 활동 추정이 아니다.

공간 해석은 셋으로 나눠 두고 섞지 않는다.

뷰를 바꿔도 그래프는 바뀌지 않는다. 보는 방식과 데이터를 분리해 둔 것이다.

리뷰를 거친 architecture에 맞춰 계획한다

architecture는 ontology 위에 올린 또 하나의 층이 아니라 별도 계약이다. 리뷰를 거친 architecture-profile/v1 문서가 네 가지를 선언한다.

• 구현 역할
• 범위를 정한 경로
• 허용 의존 방향
• 그 규칙이 관장하는 import 사용

inspect_architecture와 architecture CLI가 이 선언을 사용 이력이 붙은 현재 소스 import와 대조한다. 결과는 셋 중 하나다.

커버리지나 import 사용이 unknown인 상태를 초록으로 표시하지 않는다는 규칙이 blast radius와 같은 자리에서 반복된다.

화면 쪽에서는 Living Blueprint가 Understand에서 Plan을 거쳐 Verify로 이동하는 동안 역할 순서를 유지한다. Plan이 architectureChangePlan:v1 handoff를 복사하면 연결된 에이전트가 편집 전후로 inspect_architecture를 실행한다. 소스 체크아웃에서의 정확한 대체 명령은 아래와 같다.

node cli/src/index.mjs architecture . --vault docs/ontology --profile atlas-web --json

Feature-Sliced Design, Hexagonal, Clean Architecture, MVP 같은 패턴 이름은 리뷰를 거친 선언이다. Atlas는 소스 증거에서 적합성을 도출하며, 폴더 이름을 보고 유행하는 라벨을 추론하지 않는다.

Architecture 화면은 기존 기능에 더해 놓은 것이라 기존 Git 목적지와 변경 배지, 키보드 경로는 그대로 남는다.

관계를 노드 옆에서 리뷰한다

선택한 노드에서 관계 하나를 고쳐 쓸 수 있다. Atlas는 먼저 map 위에 방향이 보이는 미리보기를 띄우고, 그다음 source와 타입과 target과 이유와 실제로 바뀔 frontmatter 필드를 압축해 보여 준다.

Markdown 파일이 바뀌는 유일한 지점은 확정 버튼이다. 편집으로 돌아가거나 취소하면 아무것도 바뀌지 않는다.

에이전트가 관계를 추가하려 할 때는 dry-run이 먼저 판정을 낸다.

$ node $ATLAS/cli/src/index.mjs relate capabilities/return-request capabilities/refund dependencies ./storefront --dry-run

capabilities/return-request --dependencies--> capabilities/refund
  verdict matches_existing_schema · exists no
  schema  capability --dependencies--> capability
  pattern count 51 · resolved 51 · external 0 · unresolved 0
  recommendation safe_to_add · No exact or inverse edge found; capability --dependencies--> capability is an existing schema pattern.

nearby schema patterns
  3 · capability --dependencies--> capability (count 51)
  2 · capability --relates--> capability (count 12)
  1 · capability --elements--> element (count 54)
  1 · capability --domain--> domain (count 49)
  1 · domain --capabilities--> capability (count 49)

dry-run would write dependencies on capabilities/return-request → capabilities/refund (no file changed)

출력은 판정과 근거를 함께 낸다. verdict가 기존 스키마와 일치하는지 알려 주고, pattern count가 그 모양이 vault에서 몇 번 쓰였는지 센다. 예시의 엣지는 capability 사이의 dependencies 형태라 51회 선례가 있고, 그래서 safe_to_add 권고가 나왔다. nearby schema patterns는 가까운 다른 모양들을 순위와 함께 보여 준다.

vault가 한 번도 쓴 적 없는 모양이라면 판정이 new_schema_pattern으로 바뀌고 권고는 검토 요청이 된다. 드리프트하는 에이전트가 쓰고 난 다음이 아니라 쓰기 전에 눈에 띈다는 것이 이 판정의 요점이다.

변경을 읽고 나서 기록한다

사람이 썼든 map 편집기가 썼든 CLI나 MCP 에이전트가 썼든, 모든 변경은 History에 diff로 먼저 선다. 읽고 나서야 이력이 된다.

git은 vault 범위로 묶인다. 사용자가 고른 폴더 밖의 파일은 건드리지 않으며, 화면이 그 사실을 명시한다.

그래프 건강도를 관리한다

Insights는 그래프 건강도를 작업 대기열로 바꾼다. 무엇이 끊겼고 낡았고 증거가 없는지, 다음에 어떤 보수를 할지 보여 준다.

Composition은 두 가지 균형을 본다. 폴더가 kind 사이에서 균형 잡혀 있는지, 그리고 각 도메인의 capability가 구현 element로 뒷받침되는지다. 모든 수치는 같은 컴파일 그래프에서 갈라져 나온다.

Projects 화면은 손으로 유지하는 값이 하나도 없다. frontmatter에 project: 키 자체가 없고, 런타임이 각 project 루트에서 containment 그래프를 따라가 문서들이 서로를 어떻게 링크했는지로 커버리지를 파생시킨다.

워크벤치 화면과 진입 경로

일곱 화면과 두 프로그램 표면이 모두 같은 Markdown 폴더 하나를 읽는다.

설치 앱이 전체 워크벤치다. 호스팅 웹앱은 설치 없는 입구이면서, 네이티브 브리지를 쓸 수 없는 환경에서 두 번째 선택지가 되는 워크벤치다.

에이전트가 받는 것

MCP 도구는 stdio JSON-RPC 위에서 typed 표면으로 제공된다. 답이 typed라는 점이 값이다. 에이전트가 그 답을 바로 다음 동작의 입력으로 쓸 수 있기 때문이다.

그래프 데이터베이스나 호스팅 메모리는 이 경로 어디에도 개입하지 않는다.

CLI가 담당하는 동작은 scaffold, validate, dry-run 쓰기, 범위를 제한한 순회, blast radius, 커밋 preflight, vault 범위 git 스냅샷, agent handoff다.

scaffold한 vault는 agent skills를 함께 갖고 온다. init이 review, grow, absorb 절차를 vault에 써 두므로 연결된 코딩 에이전트가 추가 설정 없이 명령 메뉴에서 찾는다.

소스에서 실행하기

설치 앱이 없는 환경을 위한 대체 경로다. Node.js 24와 pnpm이 필요하고, README는 도구를 기술 대상 프로젝트 밖에 두라고 명시한다.

git clone https://github.com/wlsdks/ontology-atlas ~/tools/ontology-atlas
cd ~/tools/ontology-atlas && pnpm install
pnpm --dir mcp install   # mcp/ carries its own lockfile — the line above skips it
ATLAS=~/tools/ontology-atlas/cli/src/index.mjs

cd /path/to/your/repo

node $ATLAS init ./ontology
node $ATLAS index . --vault ./ontology
node $ATLAS index . --vault ./ontology --apply
node $ATLAS agent-brief ./ontology

init은 Atlas 클론 안이 아니라 사용자 저장소에서 실행해야 한다. 클론에는 Atlas 자신의 vault를 가리키는 .mcp.json이 이미 커밋돼 있고 init이 그것을 덮어쓰기를 거부한다. 이 경고를 무시하면 에이전트가 사용자 ontology 대신 Atlas의 ontology를 조용히 답하게 된다.

커밋된 .mcp.json은 chrome-devtools도 선언한다. chrome-devtools-mcp를 버전 고정해 --isolated --no-usage-statistics --redact-network-headers로 실행하며, .claude/agents/의 디자인과 craft 리뷰 좌석이 렌더된 기하와 계산된 스타일을 이것으로 측정한다. 없으면 디자인 게이트를 실행할 수 없다. 좌석이 요청할 때만 Chrome 인스턴스가 시작되고, 이 파일이 선언하지 않은 서버 이름을 좌석이 부르면 pnpm agents:check가 실패한다.

변경 검증

저장소 인식 게이트 선택기가 시작점이자 pull request 직전에 마지막으로 실행하는 명령이다.

두 언어 게이트는 영어 canonical 산문과 주석이 퇴행하지 않게 지키면서, typed 한국어 로케일 데이터와 런타임 문자열은 보존한다.

동시에 작업하는 worktree 둘이 변경 이력과 결정 원장에 각각 유효한 레코드를 앞에 붙이면 커밋된 docs-vault 미러도 함께 충돌한다. 충돌한 경로가 그 원장과 생성 산출물뿐이면 JSON을 손으로 고치거나 한쪽을 고르는 대신 복구 명령을 쓴다. 이 명령이 보장하는 것은 넷이다.

• 이전 이력을 한 바이트도 잃지 않는다
• 완결된 새 날짜 레코드만 합친다
• 파생 파일을 다시 만든다
• 관련 없는 충돌은 거부한다

knip은 저장소 전체 진단이며 명시적 예외 원장과 축소 전용 래칫을 갖는다. 설정 힌트와 빈 subject 레인은 설정 오류로 실패한다. 파일과 의존성과 순환 발견은 통과를 막는다. 코드를 다시 쓰지는 않는다.

브랜드 픽셀이나 마스코트 모션을 바꾼 변경은 별도 검사를 더 실행한다. 팔레트와 연속성 계약 테스트를 vitest로 돌리고, 렌더된 모션 검사를 playwright로 실행한다.

pnpm exec vitest run tests/contract/mascot-palette-boundary.contract.test.ts tests/contract/mascot-motion.contract.test.ts
pnpm exec playwright test tests/e2e/agent-mascot-presence.spec.ts

게이트의 전체 기준은 저장소의 docs/DEVELOPMENT-CHECKS.md가 갖고 있다. 캔버스 성능과 가독성, 명암비, 브라우저 계측은 docs/MAP-TESTABILITY.md가 담당한다. 작업 흐름 자체는 CONTRIBUTING.md가 설명한다.

기여와 문서 지도

README가 가장 값진 제보로 꼽는 것은 기능 요청이 아니다. Atlas를 실제 저장소에 겨눠 보고 제안된 의미나 에이전트 handoff나 검증이 어디서 부족한지를 보여 주는 보고다.

외부 pull request는 fork에서 온다. README는 이것을 형식이 아니라 보안 경계로 규정한다. 저장소 안에서 작업하는 사람과 AI 에이전트 모두에게 AGENTS.md가 정본 안내다.

문서는 목적별로 세 묶음이다.

결과

repo 자료라 성능 수치는 없다. README가 내놓는 것은 포지셔닝 비교와 ontology 품질 계약이다.

포지셔닝 비교

README는 로컬 Markdown과 git diff와 MCP를 그 자체로는 기본 조건으로 규정한다. Basic Memory 같은 MCP 연동 노트 도구가 이미 그 셋을 제공하고, 호스팅 graph-memory 제품은 데이터베이스 안에서 typed 순회를 제공한다.

Atlas가 주장하는 자리는 세 열의 중간이 아니다. 사람이 읽는 로컬 vault에 제품 ontology와 워크벤치를 결합해 사람과 에이전트가 같은 사실을 판단하게 하는 자리다. 에이전트가 대화를 기억하기만 하면 되는 상황이면 노트 도구가 가볍다는 점도 README가 함께 적는다.

Atlas가 결합한 표준 출구도 이 비교에 들어간다. JSON-LD와 GraphML이 같은 결정적 컴파일 산출물에서 나오므로 rdflib, Protégé, Gephi, Cytoscape, NetworkX, Neo4j에서 별도 변환기 없이 열린다.

ontology 품질 계약

품질 계약은 수치 목표가 아니라 판정 기준이다. README가 아홉 항목을 든다.

아홉 항목을 관통하는 하나의 태도가 있다. 수를 세어 통과시키지 않고, 근거가 있는지로 판정한다는 것이다. 노드가 몇 개인지도, 자식이 몇 개 달렸는지도 그 자체로는 합격이나 불합격의 이유가 되지 못한다.

같은 문제 영역의 네 도구

이 wiki에는 코드베이스를 그래프로 다루는 도구가 넷 있다. 네 도구의 차이를 같은 기준으로 세우면 Atlas의 자리가 분명해진다.

세 도구가 코드에서 그래프를 뽑는 방향이라면 Atlas는 반대 방향이다. 사람이 먼저 의미를 쓰고, 코드는 그 의미를 뒷받침하는 증거로 붙는다. README가 CodeGraph를 대체 대상이 아니라 역할이 다른 이웃으로 명시한 이유가 여기 있다. 심볼이 어디 있는지는 코드 인덱스가 답하고, 그 심볼이 왜 중요한지는 Atlas가 답한다.

한계

• 모든 공개 빌드가 prerelease다. release candidate가 최종 빌드와 같은 서명, notarize, 설치, 업데이트, 호스팅 다운로드 검사를 통과하긴 하지만 아직 널리 실행된 적이 없다.
• Windows 베타는 형식적 위험이 아니다. SmartScreen이 알 수 없는 게시자로 경고할 수 있고, 관리되는 업무용 PC는 설치를 아예 거부할 수 있다.
• Linux를 비롯한 나머지 플랫폼에 패키지 빌드가 없다. 같은 vault를 쓰되 화면이 줄어든다.
• 웹과 데스크톱이 같은 화면을 약속하지 않는다. git 이력과 오프라인 작업은 데스크톱 능력이다. 웹은 File System Access 핸들을 IndexedDB에 기억해 브라우저 권한이 유지되는 동안 복원하지만, git이나 네이티브 브리지를 실행할 수 없다. 이것은 백로그가 아니라 경계 선언이다.
• vault 포맷 v2.0-rc는 kill criterion을 달고 있다. 저장소의 계약 테스트가 이미 강제하는 동작을 문서화한 RFC이고, 명시된 피드백 기간 안에 외부 참여가 없으면 표준화 트랙을 조용히 유지하는 대신 접는다.
• npm에 없다. npx ontology-atlas는 404이고 앞으로의 기능도 아니다.
• 서드파티 플러그인 런타임을 두지 않는다. 확장은 MCP 도구, agent skills, 사용자 vault 안의 파일로만 일어난다.
• RDF, OWL, SKOS, SHACL 구현이 아니다. Markdown vault는 RDF 직렬화가 아니고, validator는 SHACL 프로세서가 아니며, 질의 엔진은 reasoner가 아니다. 저장된 관계는 선언된 주장이지 entailment가 아니고, 없는 관계는 눈에 보이는 빈틈이지 부정 사실이 아니다.
• 코드 인덱스가 아니다. grep, language server, AST 인덱스, CodeGraph가 답하는 자리를 대체하지 않는다.
• 일반 목적 ontology 편집기가 아니다. 코드베이스와 무관한 지식 관리는 더 일반적인 도구의 몫이다.
• 서비스가 아니다. 백엔드도 계정도 텔레메트리도 데몬도 포트도 없다. 데스크톱 앱은 공개 업데이터 매니페스트를 하루 한 번 자동으로 확인하고, Atlas는 vault 내용을 업로드하지 않는다.
• 이 페이지의 근거는 README 하나다. raw 자료가 저장소 클론이 아니라 README 스냅샷이라, 명세와 기능 목록과 결정 원장의 내부 세부는 확인할 수 없다. 스크린샷도 제품 여정을 보여 주지 릴리스 가용성을 보여 주지 않는다는 점을 README가 직접 명시한다.

핵심 용어

관련 페이지

• colbymchenry/codegraph: tree-sitter로 코드 심볼 그래프를 만드는 MCP 서버. README가 CodeGraph를 대체 대상이 아니라 역할이 다른 이웃으로 명시했다
• Lum1104/Understand-Anything: 코드베이스를 multi-agent 파이프라인으로 분석해 knowledge graph와 투어를 만든다. 분석 산출물이 그래프인 쪽이고, Atlas는 사람이 쓰고 리뷰하는 vault가 원본인 쪽이다
• graphify (Safi Shamsi): 임의의 폴더를 지식 그래프로 만드는 Claude Code 스킬: 임의 폴더를 knowledge graph로 컴파일하는 스킬. 엣지마다 발견인지 추론인지 라벨을 붙이는 점이 Atlas의 unknown 표기와 같은 계열이다
• graphify (Graphify-Labs): Any input → knowledge graph + /graphify skill: 같은 graphify의 다른 저장소 스냅샷
• langchain-ai/openwiki: 코드베이스 문서를 에이전트를 위해 자동으로 만들고 갱신하는 CLI. 자동 생성과 큐레이션이라는 기준에서 Atlas의 반대편이다
• claude-obsidian: Self-Organizing AI Second Brain for Obsidian + Claude Code: Markdown vault와 Obsidian 위에 에이전트 스킬을 결합한 구현체. vault 형식이 고정된 그래프 스키마인지 자유 노트인지가 갈리는 지점이다
• AKB: Agent Knowledge Base: Git bare repo와 PostgreSQL 위에 올린 MCP-first 지식베이스. 디스크가 곧 데이터베이스인 Atlas와 저장 전략이 대비된다
• getzep/graphiti: 비교표의 hosted graph memory 자리에 대응하는 오픈소스 엔진. typed 순회를 데이터베이스에서 제공한다
• AKB, llmwiki, GBrain 비교 및 AKB 발전 방향: AKB와 llmwiki와 GBrain을 여섯 기준으로 채점한 비교 리포트
• RAG, LLM Wiki, or GBrain? 에이전트 메모리 결정 프레임워크 (Liu): 에이전트가 하는 일을 기준으로 RAG와 LLM Wiki와 Fat Skills를 가르는 결정 프레임워크
• LLM Wiki: Karpathy LLM Knowledge Base 패턴의 한국어 레퍼런스 구현: Karpathy LLM Wiki 패턴의 한국어 구현. 사람과 에이전트가 같은 Markdown을 함께 쓰는 계보의 이웃이다
• LLM-Wiki Labs: 연구실 위키 운영을 인터랙티브 페이지로 공개한 저장소: 같은 계보의 또 다른 구현