많은 코딩 에이전트가 이전 채팅에서 모델이 문장을 잊어버려서 실패하는 것이 아닙니다. 그들은 에이전트가 코드 사실이 어디서 왔는지, 얼마나 광범위하게 적용되는지, 그리고 여전히 최신 상태인지 설명할 수 있는 컨텍스트 레이어가 없기 때문에 실패합니다. Sverklo는 다음과 같은 것을 결합한 로컬 우선(local-first) MCP 서버라는 공학적 가설로 흥미롭습니다: 레포지토리 인덱싱, 심볼 그래프, 의존성 추적, diff 인식 리뷰, 그리고 영구 메모리입니다. 유용한 질문은 이것이 지능적인 검색 상자처럼 들리는가 여부가 아닙니다. 에이전트가 인간이 재생하고 검증할 수 있는 레포지토리 컨텍스트를 받을 수 있는지 여부입니다.

업스트림 진입점(upstream entry point)은 npm install -g sverklo이며, 명시된 런타임은 Node.js >= 24입니다. 성공적인 설치는 CLI가 찾을 수 있다는 것만을 증명합니다. 인덱스가 완전하다거나, 현재 레포지토리가 서비스되고 있거나, MCP 클라이언트가 의도한 도구를 호출하고 있다는 것을 증명하지 않습니다. 저는 첫 실행을 프로덕션 워크스페이스나 글로벌 레지스트리에 연결하기보다는 폐기 가능한 테스트 레포지토리에서 시작할 것입니다.

저는 네 가지 계층에서 첫 번째 수용(acceptance) 실행을 관찰 가능하게 만들 것입니다. 첫째, 파일 발견: 인덱스가 예상되는 경로를 포함하고, 무시 규칙(ignore rules)을 준수하며, 재인덱싱 후 그럴듯한 파일 수를 생성하는가? 둘째, 코드 구조: lookup이 알려진 심볼을 찾을 수 있으며, refs, deps, impact가 파일 이름 목록 대신 관계를 반환하는가? 셋째, 컨텍스트 전달: context 도구가 유용한 온보딩 번들(onboarding bundle)을 제공하며, 공급된 토큰 budget이 더 작은 PageRank-pruned 레포지토리 맵을 생성하는가? 넷째, 메모리 원장(memory ledger): 프로젝트 범위, 종류, 관련 파일 및 시간 메타데이터를 가진 메모리를 회상할 수 있으며, 해당 파일을 변경했을 때 그 메모리가 눈에 띄게 오래되었는지(stale) 확인되는가?

Sverklo는 단일 벡터 검색기(vector retriever)로 설명되지 않습니다. Doramagic 매뉴얼은 그 검색 표면을 BM25 키워드, ONNX 임베딩, 그리고 신호 전반에 걸쳐 융합된 PageRank 심볼 그래프에 매핑합니다. 검색 결과에는 found_by가 노출되는데, 이는 운영자에게 여러 검색기가 동의하는지 여부를 알려주는 방법을 제공합니다. 여기에는 중요한 경계가 있습니다: 정확한 문자열(exact strings)은 여전히 Grep/Read에 속합니다. Sverklo는 탐색(exploration), 의존성 그래프(dependency graphs), 리팩토링 영향 범위(refactor blast radius), 그리고 의미론적 질문(semantic questions)에 더 적합합니다. 모든 쿼리를 임베딩을 통해 보내면 워크플로우가 덜 예측 가능해지고 서버 자체의 MCP 가이드라인과 모순됩니다.

수용 스크립트(acceptance script)는 작고 반복 가능하게 유지될 수 있습니다:

1. 몇 개의 모듈, 테스트, README, 그리고 의도적으로 깨진 의존성 하나를 가진 임시 저장소(temporary repository)를 생성합니다.
2. sverklo init을 실행하여 프로젝트를 등록하고 인덱싱이 완료되기를 기다립니다. Node 버전, 프로젝트 이름, 인덱스 타임스탬프, 파일 수를 기록합니다.
3. 온보딩을 위해 context를 호출하고 작은 budget을 전달한 후, 반환된 맵이 실제로 예산(budget)과 일치하는지 확인합니다.
4. 알려진 심볼에 대해 lookup을 사용한 다음, refs, deps, 그리고 impact를 사용하여 호출자(callers), 의존성(dependencies), 그리고 변경 범위(change scope)를 추적합니다.
5. remember로 파일 고정 결정(file-pinned decision) 하나를 작성하고, 해당 파일을 편집한 후, 명시적인 오래된 신호(stale signal)를 확인하기 위해 sverklo://context 또는 리콜을 검사합니다.
6. 작은 변경 사항에 대해 review_diff를 실행하고, 그 결과가 읽기 가능한 Markdown과 경로(path), 줄(line), 심각도(severity) 앵커를 가진 구조화된 발견 사항을 모두 포함하는지 확인합니다.

라이프사이클(lifecycle) 단계에서 겉으로는 건강해 보이는 설정이 자동화 시스템을 오도할 수 있습니다. Sverklo는 등록된 프로젝트를 ~/.sverklo/registry.json에 저장합니다. 매뉴얼 기록에는 이슈 #74가 있는데, 이는 reindex 작업이 완료되더라도 lastIndexed 값이 오래되어(stale) sverklo list의 타임스탬프는 현재 인덱스가 최신이라는 증거라기보다는 참고용(advisory)일 뿐임을 지적합니다. 재인덱싱 후에는 자동화 시스템이 다시 등록하거나 인덱스 상태와 파일 증거를 직접 읽어야 합니다. 이슈 #73은 unregister가 절대 경로가 아닌 내부 프로젝트 이름을 사용한다는 점을 보고합니다. 따라서 워크트리 정리 스크립트는 sverklo list에서 이름(name)을 추출하여 unregister하기 전에 해결해야 합니다.

MCP 명명 규칙에는 또 다른 조용한 프로덕션 경계가 있습니다. Sverklo는 이미 내부 sverklo_ 도구 접두사(prefix)를 노출합니다. 만약 호스트 시스템도 서버 키를 사용하여 도구 이름을 접두사 처리한다면, sverklo_sverklo_impact와 같은 이름이 나타날 수 있습니다. 연결된 배지(badge)만으로는 충분하지 않습니다. 통합 후에는 도구를 열거(enumerate)하고 context, lookup, 또는 status 중 하나에 대해 실제 호출을 수행하여 호스트의 이름과 응답 형태가 검증되도록 해야 합니다.

저의 운영 원칙은 Sverklo를 설치했다고 해서 신뢰할 수 있는 에이전트의 두뇌(agent brain)로 취급하는 것이 아니라, 관찰 가능한 로컬 코드 컨텍스트 후보(observable local code-context candidate)로 다루는 것입니다. 실제 작업 공간에 배치하기 전에 네 가지 종류의 피드백을 유지해야 합니다: 인덱스 범위와 최신성, 심볼/종속성 결과, 오래된 메모리 동작(stale-memory behavior), 그리고 구조화된 diff 검토 출력입니다. 이러한 아티팩트(artifacts) 없이는 CLI가 시작되었다는 것 외에는 방어할 수 있는 주장이 없습니다.

이것은 공식 Sverklo 릴리스나 보증이 아닌 독립적인 Doramagic 기능 패키지입니다. 프로젝트 페이지: https://doramagic.ai/en/projects/sverklo/ ; 사용자 매뉴얼(Human Manual): https://doramagic.ai/en/projects/sverklo/manual/ ; 상위 프로젝트(upstream): https://github.com/sverklo/sverklo.