Celmis

셀프 호스팅 코드 인텔리전스 — 코드베이스에 질문하고, 풀 리퀘스트를 검토하며, 감사자가 요구하는 증거를 생성합니다

celmis-labs.github.io · 문서 · 빠른 시작 · 결과

Celmis는 저장소를 한 번 읽고 기호 그래프(symbol graph)를 유지합니다. 그 외의 모든 것 — 질문, 검토, 의존성 감사, 생성된 문서 — 은 그 그래프를 읽는 다른 방식일 뿐입니다. docker compose 아래 단일 머신에서 실행되며, 원하는 모델 제공자를 뒤에 두고, 구성한 호출 외에는 네트워크 밖으로 나가는 것이 없습니다.

가장 오래된 전승에서 Kelmis는 제련공이었습니다 — 망치의 Damnameneus와 모루의 Acmon과 함께, 철 가공의 공로가 돌려진 세 명의 이다이언 닥틸로이 중 하나입니다. 여기서 인덱스가 환원 작업을 수행하고, 표면들이 그 결과를 가공합니다.

diff 전용 도구로는 얻을 수 없는 것

두 저장소에 걸친 질문을 하면, 답변이 양쪽을 인용합니다:

그것은 검색 결과가 아닙니다. 게이트웨이와 결제 서비스는 공유 코드가 없는 별도의 저장소이며, 답변은 그들 사이의 호출 체인을 추적합니다 — 그런 다음, 요청 없이도 Kafka 토픽 이름이 양쪽에 하드코딩되어 있고 하나를 변경하면 다른 하나가 조용히 깨진다는 것을 알아차립니다.

diff만 구조적으로 읽는 검토자는 그렇게 말할 수 없습니다. 다른 저장소를 열어 본 적이 없기 때문입니다.

Related MCP server: OpenCodeHub MCP Server

사람들이 이걸로 하는 일곱 가지

처음 세 가지는 코드 검토 도구가 전혀 하지 않는 것들이며, 이것이 리뷰어가 아닌 플랫폼인 이유입니다: 한 번 인덱싱하고, 작업의 어느 쪽에 서 있든 그 인덱스를 읽는 것입니다.

세 가지 숫자

마지막 것은 의도적으로 불리하며, 그대로 유지됩니다. 그것은 아래 표면 중 하나 — 격리된 단일 저장소 PR에 대한 풀 리퀘스트 검토 — 를 측정하며, 그 세트에는 기호가 소비자를 가질 수 있는 형제 서비스가 없으므로, 이 제품이 구축된 핵심은 숫자에 전혀 포함되지 않습니다. 표, 그것이 false로 채점한 모든 발견 사항의 감사, 그리고 둘 다 재현하는 명령은 결과에 있습니다.

목차

• diff 전용 도구로는 얻을 수 없는 것

• 사람들이 이걸로 하는 일곱 가지

• 세 가지 숫자

• 빠른 시작

• 첫 사용자 및 관리자

• 저장소 연결

• 코드에 질문하기

• 풀 리퀘스트 검토

• 의존성, SBOM 및 증거 팩

• 여기서 수정하기

• 누가 무엇을 볼 수 있는가

• 언어 및 형식

• 결정적 검사 — 모델 없음, 오탐 없음

• Claude Code 및 기타 MCP 클라이언트 연결

• 결과

• 오탐 감사

• 테스트 저장소

• 구성

• 운영

• 로컬 개발

• CLI 참조

• 아키텍처

• 문제 해결

• 프로젝트 레이아웃

• 출처 및 권리

빠른 시작

필요한 것

Postgres와 Qdrant는 번들되어 있습니다 — 외부 클러스터를 프로비저닝할 필요가 없습니다. Docker 흐름에는 Python이나 Node.js 설치가 필요하지 않습니다.

시작하기

git clone <your-fork-url> celmis
cd celmis

# Generates .env and fills every secret in the format each one needs.
# Idempotent: run it again after a pull and it fills only the new blanks.
./scripts/init-env.sh

docker compose --env-file .env up -d

# Wait for healthy — first boot pulls three images and applies migrations
docker compose ps

http://localhost를 엽니다.

여기서 빌드되는 것은 없습니다. 세 개의 이미지는 CELMIS_REGISTRY가 지정한 레지스트리에서 CELMIS_TAG의 태그로, linux/amd64 및 linux/arm64용으로 가져옵니다 — Apple Silicon과 ARM 서버 모두 네이티브 이미지를 얻습니다. 실행하는 머신에서 빌드하는 것은 api만으로 485초와 4.2GB 디스크가 측정되었으며, 그래서 설치가 더 이상 컴파일을 의미하지 않습니다.

포트 80, 3000이 아닙니다: 리버스 프록시가 앱과 API를 하나의 오리진에 두고 /backend 아래에서 API를 제공합니다. 그것은 배포 선호도가 아닙니다 — 브라우저 번들이 상대 경로를 요청하며, 그것이 하나의 게시된 이미지가 빌드된 특정 설치뿐만 아니라 모든 설치를 제공할 수 있는 유일한 방법입니다.

Celmis를 실행하는 것이 아니라 작업하려면, dev 오버레이를 추가하면 로컬 빌드를 다시 얻을 수 있습니다:

docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

init-env.sh --check는 아무것도 쓰지 않고 무엇이 여전히 비어 있는지 보고합니다.

그것은 캡처된 세션의 렌더이며, 화면 녹화가 아닙니다 — 그 안의 수치는 2026년 8월 26일 실행이 생성한 것이며, compose 출력은 설치 보고서의 logs/03-up.log에서 그대로 가져온 것입니다. 사진이 아닌 그려진 이유는 실행 중인 스택 옆에 두 번째 스택을 올릴 수 없기 때문입니다: docker-compose.yml이 container_name을 고정하므로 이름이 충돌합니다.

중지

docker compose down       # stop, keep your data
docker compose down -v    # stop and DELETE every volume

첫 사용자 및 관리자

/login의 가입 양식은 스택이 건강해지면 바로 작동합니다. 그 계정은 일반 사용자입니다 — 가입은 관리자 권한을 부여하지 않으며, 첫 번째로 들어온 사람에게도 그렇습니다.

전역 관리자는 환경에서 대신 옵니다: CELMIS_MASTER_EMAIL과 CELMIS_MASTER_KEY(비밀번호로)로 로그인하세요. 둘 다 .env에 있습니다. 박스를 실행하는 사람이 관리자이며, 이는 셀프 호스팅 설치가 원하는 모델입니다 — 양식에 먼저 도달한 사람이 아니라. 그 경로는 두 변수가 모두 설정된 경우에만 존재하며, 사용할 때마다 감사 로그에 기록됩니다.

일반 계정을 승격하려면:

docker compose exec api analyzer auth make-admin you@example.com

저장소 연결

1. 설정 → LLM 설정 — 제공자 키를 붙여넣으세요. 데이터베이스에 닿기 전에 CREDENTIAL_MASTER_KEY로 암호화되며, UI는 처음과 마지막 네 문자만 다시 표시합니다.

2. 연결 — GitHub, GitLab 또는 Bitbucket 토큰을 추가하세요. 머신 계정을 사용하세요, 자신의 계정이 아닌: 개인 토큰은 볼 수 있는 모든 저장소에 도달하며, 토큰은 백업, 로그 및 스크린샷에 남게 됩니다.

3. 저장소 → 추가 — 제공자에서 저장소를 선택하거나 클론 URL을 붙여넣으세요. 인덱싱이 대기열에 들어가고, 작업이 같은 페이지에 표시됩니다.

인덱싱은 동일한 체크아웃에서 두 가지를 구축합니다: 기호 그래프(정의, 호출, 가져오기 — 검토 에이전트가 추론하는 것)와 Qdrant의 임베딩(Q&A가 검색하는 것). 120k 기호 저장소는 4코어에서 약 1분이 걸립니다.

23개 언어가 그래프로 파싱됩니다. 파서가 없는 언어의 파일은 조용히 건너뛰는 대신 명시적으로 말합니다 — analyzer graph-stats는 읽은 것과 읽지 않은 것을 나열합니다.

코드에 질문하기

채팅에서 질문하고, 가리키는 만큼의 저장소에서 파일:줄 인용으로 답변합니다. 답변은 작성되는 대로 스트리밍됩니다.

저장소를 프로젝트로 그룹화하면, 질문이 그룹에 대해 묻습니다:

답변은 실제 코드를 인용하며, 질문자가 볼 수 있는 코드만 인용합니다 — 이것이 저장소를 소유한 팀 외부의 사람에게 질문을 넘겨도 안전한 이유입니다. 누가 무엇을 볼 수 있는가를 참조하세요.

풀 리퀘스트 검토

에이전트는 diff를 읽고 GitHub, GitLab 또는 Bitbucket에 결과를 게시합니다. 이 인터페이스의 스크린샷으로 보여주는 대신, 리뷰는 게시된 위치에 그대로 남아 있습니다 — 실제 프로젝트의 풀 리퀘스트 50개에, 작성된 코드 줄에 여전히 첨부된 댓글과 함께 말입니다. 이들은 테스트 저장소 아래에 나열되어 있으며, 그 출력은 아래 감사에서 잘못된 것으로 표시한 결과를 포함하여 편집되지 않은 상태입니다.

그래프가 구축된 곳에서는 리뷰가 diff가 보여주지 않는 것도 함께 전달합니다: 변경되는 심볼을 다른 저장소를 포함하여 누가 호출하는지. 그래프가 구축되지 않은 곳에서도 리뷰는 여전히 실행됩니다 — 단지 더 좁은 질문에 답할 뿐이며, 그것이 벤치마크가 측정한 것입니다.

벤치마크가 false로 채점한 모든 결과는 소스에서 열리고 판정과 함께 게시되었습니다. 79개 중 33개가 골드 세트에 포함되지 않은 실제 결함으로 판명되었습니다. 그 작업은 오탐지 감사에 있으며, 각각에 대한 코드와 permalink가 포함되어 있어 누구든 이의를 제기할 수 있습니다.

종속성, SBOM 및 증거 팩

종속성 감사는 **결정적(deterministic)**입니다: 도구가 설치된 곳에서는 네이티브 감사 도구를, 그 외에는 OSV를 사용하며 모델이 개입하지 않습니다. 언어 모델은 키를 제공하면 요약을 작성할 뿐 — 무엇이 취약한지 결정하지 않습니다.

모든 감사에서 두 개의 파일이 생성되며, 어느 것도 LLM 키가 필요 없습니다:

• SBOM — 모든 종속성, 버전, 패키지 URL 및 알려진 취약점에 대한 CycloneDX 인벤토리. 사람들이 "SBOM을 보내주세요"라고 말할 때 의미하는 파일입니다.

• 증거 팩 — 제출용 감사: 모든 SBOM, 모든 결과, 과거 실행 타임라인, 각 파일의 sha256으로, 제3자가 이후에 아무것도 편집되지 않았는지 우리를 신뢰하지 않고도 확인할 수 있습니다. 나중에 내용이 변경될 수 있는 폴더는 아무것도 증명하지 못합니다. 매니페스트가 그것을 증거로 만드는 것입니다.

그와 함께 생성된 기술 문서 — 코드에서 작성된 모듈 PRD, 기능 문서 및 통합 가이드 — 는 귀하의 소유로 남으며 구독이 종료된 후에도 계속 작동합니다.

이것이 지금 존재하는 이유. 2026년 9월 11일부터 EU 사이버 복원력 법안(Cyber Resilience Act)은 제조업체가 적극적으로 악용된 취약점을 24시간 이내에 ENISA에 신고하도록 요구합니다. 공식 SBOM 의무는 2027년 12월에 적용되지만, 먼저 구성 요소 수준의 가시성 없이는 24시간 질문에 답할 수 없습니다 — 무엇이 영향을 받는지 신고하려면 내부에 무엇이 있는지 알아야 합니다.

Celmis는 규정 준수를 주장하지 않으며, 앞으로도 하지 않을 것입니다. 제출에 필요한 산출물을 생성할 뿐입니다. 제출이 적절한지 여부는 변호사의 판단이며, 그렇지 않다고 암시하는 도구는 거짓된 안전감을 파는 것입니다.

감사 페이지가 큰 소리로 말하는 또 한 가지, 아무도 찾지 않는 실패: 아무도 스캔하지 않은 생태계는 깨끗한 생태계와 똑같이 취약점 0건을 보고합니다. 적용 범위는 결과 옆에 표시됩니다 — 각 결과를 생성한 감사 도구가 무엇인지, 그리고 더 유용하게는 무엇이 검사되지 않았고 그 이유가 무엇인지.

여기서부터 수정하기

무언가를 찾는 것은 루프의 절반입니다. 내장된 Claude Code 세션이 설치 내부에서 실행되어 체크아웃을 편집하고, 러너가 커밋하고, 브랜치를 푸시하고 풀 리퀘스트를 엽니다.

종속성 감사의 취약점에는 Claude로 수정 버튼이 있습니다. 빈 채팅을 열지 않습니다 — 세션에 저장소, 패키지, 두 버전 및 작업 범위를 이미 작성된 상태로 전달합니다:

다음은 실제 결과에 대한 종단 간 루프입니다 — 알려진 취약점이 있는 lodash 4.17.11. 세션 시작부터 풀 리퀘스트가 열릴 때까지 220초, 다섯 턴:

Read package.json
  → "Only package.json has lodash; no requirements.txt/pyproject/go.mod exist here."
Edit package.json: "lodash": "4.17.11" → "4.18.0"
mcp__exec__run: cat package.json | grep -A2 lodash; ls
  → "Confirmed no other manifest files exist, so no other changes were needed."

푸시된 브랜치와 열린 풀 리퀘스트, GitHub에서:

그 diff에 없는 것을 보십시오. axios 0.21.1, minimist 1.2.0, node-fetch 2.6.0이 바로 위와 아래 줄에 있습니다 — 모두 구식이고, 같은 감사에서 모두 플래그되었으며 — 모두 건드리지 않았습니다. 작업은 매니페스트만 수정하라고 했고, 지나가면서 세 개를 더 정리한 에이전트는 검토하기에 더 나은 결과가 아니라 더 나쁜 결과였을 것입니다.

스크린샷이 아닌 실제 풀 리퀘스트입니다: celmis-demo-gateway#6 — 브랜치 celmis-agent/b8960e01, 커밋 1개, +1/-1.

그 기록에서 diff보다 더 가치 있는 두 가지 세부 사항이 있습니다. 에이전트는 다른 매니페스트가 없다고 가정하지 않았습니다 — 샌드박스에서 명령을 실행하여 확인했습니다. 그리고 작업이 "매니페스트만, 관련 없는 종속성은 건드리지 말 것"이라고 했으므로 변경은 정확히 한 줄입니다.

러너가 허용하는 것과 허용하지 않는 것

이것은 프롬프트가 아니라 러너가 결정합니다 — 에이전트에게 무엇이든 부여하기 전에 읽을 가치가 있는 부분입니다:

• 자체 셸이 없습니다. Bash, WebFetch, WebSearch 및 노트북 편집이 금지됩니다. 명령은 샌드박스 컨테이너를 통해 실행되며, 이는 자체 uid와 읽기 전용 루트 파일시스템을 가진 별도 서비스입니다.

• Git은 러너의 작업입니다. 에이전트는 커밋하거나 푸시하지 않습니다. 작업이 완료되면 — 또는 완료 및 푸시를 누르면 — 러너가 커밋을 만들고, 브랜치를 푸시하고 PR을 엽니다. 기본 브랜치에는 절대 푸시하지 않습니다.

• 공급자 한도는 손실이 아니라 일시 중지입니다. 위 실행의 첫 번째 시도는 세션 중간에 주간 계정 한도에 도달했습니다. 세션은 죽지 않았습니다: paused 상태로 전환되어 14일 동안 작업을 재개 가능하게 유지했고, 일반적인 실패 메시지 대신 공급자의 자체 메시지를 표시했습니다. 두 번째 키가 완료했습니다.

• 세션은 관찰 가능합니다. 출력은 재생 기능이 있는 SSE로 스트리밍되므로, 재연결 시 빈 화면에서 시작하는 대신 중단된 지점부터 이어집니다.

연결은 설정 토큰으로, 사용자 또는 워크스페이스별로 보관됩니다. API는 저장된 후에는 절대 반환하지 않습니다 — 존재 여부와 여전히 작동하는지 여부만 반환합니다.

누가 무엇을 볼 수 있는지

접근은 저장소별, 팀별로 해석되며 모든 표면을 동시에 관리합니다 — Q&A, 그래프, 검색, MCP:

이것이 이웃 팀 사례가 약속이 아니라 실제로 작동하게 만드는 이유입니다: 저장소를 로드하고, 다른 팀에게 질문할 권리를 부여하고, 읽히면 안 되는 경로를 거부합니다. 그들은 답변을 얻습니다. 해당 파일은 이미 포함된 응답에서 필터링되는 것이 아니라 소스에서 거부됩니다.

언어 및 형식

17개의 그래프 모듈과, 전용 모듈이 없는 언어를 위한 tree-sitter 태그 쿼리를 통한 일반 경로:

코드 — Python, TypeScript, JavaScript, Go, Java, C#, C++, PHP, Vue 및 일반 경로를 통한 더 많은 언어.

인프라 — Dockerfile, docker-compose, Helm, Kubernetes 매니페스트, Terraform 및 CI 워크플로우. 이것은 대부분의 코드 인텔리전스 도구가 건너뛰는 부분이며, 질문이 함수에서 그것을 실행하는 서비스 정의로 넘어갈 수 있는 이유입니다.

결정적 검사 — 모델 없음, 오탐지 없음

아래의 모든 검사는 파일을 읽어서 결정됩니다. 무언가 잘못되었다고 결정하는 데 언어 모델이 참여하지 않으므로, 오탐지율은 튜닝이 아니라 구조적으로 0입니다.

그 구분이 핵심입니다. 약 20%의 오탐지율은 개발자가 도구의 주석을 전혀 읽지 않게 되는 지점입니다 — 하나는 몇 초의 주의를 소모하고, 천 개는 도구가 말하는 모든 것을 건너뛰는 법을 배운 팀을 만듭니다. 여기서 모델은 설명하고 우선순위를 정하는 데만 사용되며, 탐지에는 절대 사용되지 않습니다.

일반 CVE 스캐닝은 의도적으로 그 목록에 없습니다. OSV-Scanner가 이미 수행하며, 무료이고, 사실상의 표준입니다 — Celmis는 이를 실행하고(각 생태계의 자체 감사 도구도 함께: pip-audit, npm audit, govulncheck, cargo audit) 결과를 기능이 아닌 입력으로 취급합니다.

규정 준수에 관하여. Celmis는 감사가 요청하는 산출물 — CycloneDX SBOM, 종속성 인벤토리, 타임스탬프와 각 결과가 근거하는 증거가 있는 결과 이력 — 을 생성합니다. 귀하의 제출이 적절하다고 주장하지 않으며, 어떤 도구도 정직하게 그렇게 할 수 없습니다: 감사자가 수용하는 것은 귀하의 업종, 관할권 및 자체 통제에 따라 달라집니다. 산출물을 생성하십시오. 그것을 평가하는 것이 직업인 사람들이 평가하게 하십시오.

Claude Code 및 기타 MCP 클라이언트 연결

Celmis는 MCP를 통해 인덱스를 노출하므로, 에이전트가 심볼을 검색하고 API 표면을 읽고 소비자를 찾을 수 있습니다 — 가지고 있지 않은 체크아웃을 grep하는 대신.

HTTP를 통해 (실행 중인 스택이 /mcp/에서 제공):

# Mint a token (or issue one from Settings → MCP in the UI)
docker compose exec api analyzer mcp issue-token \
  --scopes "read:graph read:groups" --duration 86400

// ~/.claude.json  (or .mcp.json in a project)
{
  "mcpServers": {
    "celmis": {
      "type": "http",
      "url": "http://localhost:8000/mcp/",
      "headers": { "Authorization": "Bearer <the token you just minted>" }
    }
  }
}

stdio를 통해, HTTP 홉 없이:

{
  "mcpServers": {
    "celmis": {
      "command": "docker",
      "args": ["compose", "exec", "-T", "api", "analyzer", "mcp", "serve"]
    }
  }
}

에이전트가 질문할 수 있는 것

HTTP 마운트는 18개의 도구를 제공합니다. grep이 할 수 없는 질문에 답합니다:

두 전송 방식은 동일한 집합이 아닙니다. stdio를 통한 analyzer mcp serve는 13개의 구형 그래프 형태 도구(find_symbol, find_callers, query_graph)를 제공하고, HTTP 마운트는 위의 18개를 제공합니다. 어느 쪽도 다른 쪽의 부분집합이 아닙니다 — 원하는 도구에 맞는 전송 방식을 선택하세요.

각 도구에 필요한 스코프와 실패 모드를 포함한 단계별 가이드는 .claude/skills/celmis-mcp/SKILL.md에 있습니다. 이 저장소가 열려 있으면 Claude Code가 자동으로 이를 인식합니다.

에이전트가 요청할 수 있는 것

search_symbols 호출 한 번, 계약 심볼 하나 — 두 저장소에서 두 언어로 결과가 돌아옵니다. 어느 쪽도 체크아웃하지 않은 클라이언트에게 말이죠. diff가 절대 넘지 못하는 경계를 이것이 평범한 일로 만듭니다.

Streamable HTTP로 /mcp/에서 제공되고 /api/와 동일한 bearer 토큰으로 인증되는 18개의 도구:

cross_repo_edges가 이해할 가치가 있는 이유는, 이것이 이 제품이 심볼 그래프를 지니는 이유이기 때문입니다. diff 전용 리뷰어 — 위 벤치마크 표의 모든 도구, 그래프가 비어 있을 때의 이 도구까지 포함해서 — 는 함수 시그니처가 변경되었다고 말할 수 있습니다. 그러나 다른 저장소의 서비스가 여전히 이전 형태를 호출하고 있다는 것은 말할 수 없습니다. 그 저장소를 연 적이 없기 때문입니다. 저장소를 한 번 그룹화하면 그 질문에 답할 수 있게 됩니다:

> which services outside this repo call PaymentGateway.charge?

이것이 또한 우리의 벤치마크 순위가 제품을 설명하기보다 과소평가하는 이유입니다: 벤치마크 세트는 격리된 단일 저장소 풀 리퀘스트이므로, 엣지가 넘을 형제 저장소가 없습니다. 그 능력은 실제이며 벤치마크는 그것을 볼 수 없습니다 — 이는 벤치마크에 대한 진술이지, 맹목적으로 믿어야 할 주장이 아닙니다. MCP 클라이언트를 자신의 그룹에 연결해 직접 확인하세요.

결과

Celmis는 Martian Code Review Bench 오프라인 세트로 실행되었습니다: 50개의 선별된 풀 리퀘스트, 173개의 인간이 작성한 골든 코멘트, LLM 판정자에 의해 골드 세트 대비 점수 산정. e0db376 커밋에서 gemini-3.6-flash 온도 0.1, 추론 토큰 없이 측정되었습니다.

F1은 누가 판정하느냐에 따라 4.8포인트 움직입니다. 순위는 전혀 움직이지 않습니다 — 세 판정자 모두에서 17위. 세 표 모두에서 우리 아래에는 CodeRabbit (19/25/23), 모든 버전의 Greptile (26–29), Kodus (21/23/21), Copilot, Claude Code, Gemini, CodeAnt가 있습니다.

전체 실행 비용은 $5.88 — 풀 리퀘스트당 $0.118 — 이었고 153개의 파인딩을 생성했습니다. PR당 3.06개 (결함 114, 보안 27, 계약 6, 구조 6).

이 비교가 공정한 이유. Martian은 벤치마크 저장소에 49개 도구에 대한 자체 평가를 게시하며, 동일한 세 판정자가 동일한 50개 PR에 대해 동일한 골든 대비 생산한 결과입니다. 우리는 누구도 재채점하지 않았습니다: 그들의 행은 게시된 대로 가져왔고 우리의 행은 추가되었습니다. 전체 표를 재현하려면:

python3 autoloop/offline_table.py anthropic_claude-sonnet-4-5-20250929

오프라인은 공개 리더보드가 아닙니다. Martian은 두 개의 벤치마크를 실행합니다. 공개 리더보드는 온라인 벤치마크입니다 — 개발자가 실제로 수정한 것으로 채점된 200,000개의 실제 풀 리퀘스트. 이 표는 오프라인 벤치마크입니다 — 골드 세트 대비 채점된 50개의 선별된 PR. 둘은 서로 다른 것을 측정하며 숫자는 상호 교환할 수 없습니다. "도구 X가 Martian에서 1위"라는 형태의 주장은 보통 온라인 표, 다른 지표, 또는 다른 판정자를 가리킵니다.

이 숫자가 포함하지 않는 것. 그래프는 50개 PR 모두에서 비어 있었습니다 (graph_status null, 모든 항목에서 drift 비어 있음). 벤치마크 세트가 격리된 단일 저장소 풀 리퀘스트이기 때문입니다 — 심볼이 소비자를 가질 형제 서비스가 없습니다. 이 제품이 심볼 그래프를 지니는 이유인 교차 저장소 drift는 위 점수에 정확히 아무것도 기여하지 않았습니다. 여기서는 측정할 수 없으며, 우리는 이 표에서 그것을 주장하지 않습니다. 실제 코드에서 작동하는 모습을 보려면 테스트 저장소를 참조하세요.

거짓 양성 감사

벤치마크 채점에는 구조적 한계가 있습니다: 판정자는 우리의 코멘트를 유한한 인간 작성 골든 목록과 대조하므로, 주석 작성자가 기록하지 않은 올바른 파인딩은 구조적으로 거짓으로 집계됩니다. 우리는 측정된 커밋의 소스에서 79개 전부를 열어 각각에 판정을 내렸습니다.

거짓 양성으로 채점된 79개 파인딩 중 33개는 골드 세트에 없는 실제 결함이고, 38개는 진정으로 틀렸으며, 8개는 코드만으로 판정할 수 없었습니다. 이는 이번 실행의 실제 정밀도가 측정된 48.0%가 아닌 69.7%에서 75.0% 사이임을 의미합니다 — 하지만 그 수정된 수치는 위 표의 어떤 것과도 비교할 수 없습니다. 다른 도구를 같은 방식으로 감사한 사람이 없고, 그들의 거짓 양성에도 거의 확실히 비슷한 비율의 실제 결함이 포함되어 있기 때문입니다. 다른 도구와의 비교를 위해서는 측정된 48.0%가 정직한 숫자입니다. 모든 사람에게 동일한 방법을 적용한 것이기 때문입니다.

진정으로 틀린 38개 파인딩 중 24개는 네 가지 근본 원인을 공유하며, 그중 어느 것도 "모델이 약하다"가 아닙니다 — 네 가지 모두 모델이 본 내용에 관한 것입니다. 가장 큰 원인은 에이전트가 받은 발췌문 밖이지만 같은 파일에 선언된 식별자입니다: 26줄 위의 메서드 파라미터, 3번째 줄의 import, 18번째 줄의 attr_reader.

전체 보고서는 79개 각각에 대해 주장, 해당 커밋의 코드, 판정, 근거 및 퍼머링크를 제공하므로, 어떤 판정이든 동일한 증거를 앞에 두고 이의를 제기할 수 있습니다.

테스트 저장소

위 실행의 모든 리뷰는 여전히 공개되어 있습니다. 실제 프로젝트의 실제 풀 리퀘스트를 히스토리와 함께 포크한 것으로, Celmis가 작성한 인라인 코멘트를 담고 있습니다:

먼저 열어볼 가치가 있는 것:

• keycloak#17 — Keycloak의 테스트 스토리지 프로바이더에서의 null 역참조와 복구 코드 인덱싱 질문

• grafana#16 — Legacy 메트릭에 기록된 Storage 실패, 해당 파일에서 동일한 실수의 세 가지 사례 중 하나

• cal.diy#11 — async 콜백이 있는 forEach로, 삭제가 fire-and-forget 방식이며 주변의 try가 아무것도 잡지 못함

• sentry#11 — 하나의 Kafka 컨슈머 PR에 대한 일곱 개의 인라인 코멘트

위 감사에서 틀렸다고 표시된 파인딩을 포함하여, 편집되지 않은 출력을 읽고 있습니다. 채점 후 제거된 것은 없습니다.

구성

./scripts/init-env.sh는 .env.example에서 .env를 작성하고 모든 시크릿을 생성합니다. 예제는 각 시크릿을 의도적으로 비어 있는 상태로 제공합니다: 이전 버전은 생성 명령을 변수 옆에 두었는데, dotenv 파일에는 인라인 주석이 없고, 이를 복사한 모든 설치가 저장소에 인쇄된 마스터 비밀번호로 실행되었기 때문입니다.

설정은 docker-compose.yml의 environment: 블록을 통해서만 컨테이너에 도달합니다 — 이미지에는 .env가 포함되지 않습니다. 거기에 이름이 없는 변수는 .env에 무엇이 있든 코드 기본값을 사용합니다. GET /healthz는 프로세스가 실제로 해석한 대로 리뷰 클록을 보고하며, 이것이 무엇이 도착했는지 확인하는 방법입니다.

클록은 .env.example에 집합으로 문서화되어 있으며, 이를 묶는 불변 조건이 있습니다:

REVIEW_LLM_TIMEOUT_SECONDS × (1 + RETRY_FACTOR)  ≤  REVIEW_TIMEOUT_SECONDS

하나를 올리면 다른 하나도 따라야 합니다. 테스트가 이를 강제합니다.

운영

docker compose logs -f api            # follow the API
docker compose exec api analyzer graph-stats <repo>   # what parsed, what did not
./scripts/backup.sh                   # Postgres + volumes
./scripts/restore.sh <archive>

Admin → Monitoring은 큐 깊이, 워크스페이스별 지출 및 에이전트별 모델 설정을 보여줍니다. Usage & cost는 지출을 표면별로 세분화하므로 일괄 문서 빌드가 채팅으로 표시되지 않습니다.

서버 배포는 ./scripts/deploy-on-server.sh v0.1.0이며 서버에서 실행합니다. 게시된 이미지를 가져와 Caddy 뒤에서 스택을 올리고 AGPL 푸터가 링크하는 빌드를 스탬프합니다. 해당 머신 외부에서는 이 작업에 자격 증명이 필요하지 않습니다. docs/ORACLE_CICD.md 또는 일반 VM용 docs/HETZNER.md를 참조하세요.

로컬 개발

# Postgres and Qdrant from compose, everything else on the host
docker compose up -d postgres qdrant

python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

alembic upgrade head
uvicorn src.api.main:app --reload --port 8000

cd web && npm install && npm run dev     # http://localhost:3000

pytest -q                # the suite
ruff check .             # lint, ratcheted at zero
cd web && npx tsc --noEmit

CLI 참조

analyzer는 pip install -e .로 설치됩니다. Docker 내부에서는 docker compose exec api analyzer …를 사용합니다. 모든 명령은 --help를 지원합니다.

그룹화된 하위 명령: analyzer repo, analyzer group, analyzer auth, analyzer mcp, analyzer scip.

아키텍처

                      ┌──────────────┐
   GitHub / GitLab ──▶│   webhook    │──┐
   Bitbucket          └──────────────┘  │
                                        ▼
   Browser ──▶ web (Next.js) ──▶ api (FastAPI) ──▶ Postgres   jobs, policies, audit
                                     │              Qdrant     embeddings
                                     │              sandbox    untrusted execution
                                     ▼
                              model provider
                       (direct, or via a LiteLLM gateway)

• Postgres는 작업, 정책, 실행 기록, 지출 및 감사 로그를 보관합니다. 영속 작업 큐는 테이블입니다. 디큐는 SELECT … FOR UPDATE SKIP LOCKED이며, 작업자는 미리 기간을 추측하지 않고 작업하는 동안 임대를 갱신합니다.

• Qdrant는 임베딩을 보관하며, 설치당 하나의 컬렉션으로 필터에서 워크스페이스 격리가 적용됩니다.

• sandbox는 신뢰할 수 없는 모든 것(테스트 스위트, 빌드)을 자체 uid로 자체 네트워크에서 실행하며, 데이터베이스, 키가 없고 읽기 전용 루트를 사용합니다.

• LiteLLM은 선택 사항입니다. LITELLM_PROXY_URL과 LITELLM_MASTER_KEY를 함께 설정하면 모든 호출이 게이트웨이를 통해 라우팅됩니다. 둘 중 하나를 비워 두면 공급자 키가 직접 사용됩니다.

문제 해결

컨테이너가 시작되지 않습니다. docker compose logs <service>를 실행하세요. API는 시작 시 어떤 선택 기능을 사용할 수 없는지와 그 이유를 조용히 실패하지 않고 알려줍니다.

리뷰가 아무것도 생성하지 않습니다. GET /healthz에서 확인된 클록을 확인한 다음 docker compose logs api | grep agent_를 실행하세요. 각 에이전트는 경과 시간, 모델 및 실패 코드를 기록합니다.

장애가 아닌 타임아웃. local_timeout은 공급자가 응답하기 전에 이 설치의 자체 마감 시간이 경과했음을 의미합니다. REVIEW_LLM_TIMEOUT_SECONDS를 올리세요. 이는 의도적으로 공급자 오류로 보고되지 않습니다.

Q&A가 아무것도 인용하지 않습니다. 저장소가 인덱싱되지 않았거나 임베딩 없이 인덱싱되었을 가능성이 있습니다. Repositories는 각 저장소의 상태를 보여줍니다. analyzer graph-stats <repo>는 파싱된 항목을 보여줍니다.

샌드박스가 항상 바쁩니다. SANDBOX_SLOTS는 동시에 실행되는 작업 수이며 메모리를 소비하는 조절 장치입니다. SANDBOX_SLOT_WAIT은 호출자가 돌아오라는 안내를 받기 전에 대기하는 시간입니다.

프로젝트 레이아웃

src/
  api/          FastAPI app, routers, schemas
  review/       PR review — agents, orchestrator, providers, policies
  indexing/     parsers, symbol graph, embeddings
  qa/           retrieval and answer composition
  generation/   documentation vault
  llm/          provider clients, error taxonomy, cost ledger
  sync/         git providers, the durable job queue, workers
  sandbox/      the isolated execution server
  mcp_server/   the MCP surface
  security/     redaction, patterns, log filtering
web/            Next.js UI (App Router, 16 locales)
tests/          5200+ tests
deploy/         Caddy overlay and the LiteLLM gateway config
docs/           deploy guides and the end-to-end walk-through
bench/          benchmark harness and results

출처 및 권리

이 저장소는 약 십만 줄에 걸친 단일 루트 커밋을 가지고 있습니다. 이는 출처가 불분명한 코드 드롭이 출처 스캐너에 보이는 형태이며, 어깨를 으쓱할 일이 아니라 설명이 필요한 형태입니다. 설명이 있습니다. PROVENANCE.md는 라이선스 입장과 코드의 출처를 명시합니다. 개발은 이 커밋 이전에 비공개로 진행되었으며, 그 중 어느 것도 여기 있는 것을 빌드, 감사 또는 포크하는 데 필요하지 않습니다.

그 파일은 라이선스가 아니라 사실의 기록입니다. 라이선스는 AGPL-3.0이며 한 가지 예외가 있습니다. ee/ 아래의 모든 것과 이름에 .ee.가 포함된 모든 파일은 대신 LICENSE_EE가 적용됩니다. ee/에는 현재 제품 코드가 없습니다. 경계는 첫 번째 태그 이전에 그어졌는데, 이후에 추가하면 이미 무조건 AGPL로 작업을 보낸 모든 기여자에게 다시 물어봐야 하기 때문입니다.

여기에 배포되는 모든 것은 AGPL입니다. 상업적으로 보이는 부분(감사 콘솔, 사용량 및 지출, 규정 준수 검사, 설치 메트릭)도 포함됩니다. 보안 제어는 결코 엔터프라이즈 전용이 아닙니다. 감사 로그는 AGPL로 작성되며 앞으로도 그럴 것입니다. 새 코드가 들어가는 위치는 CONTRIBUTING.md를 참조하세요.