Repository Learning Dossier · 2026-07-15

OpenSRE를 읽기 전에

4,059개 blob의 지도를 만든 뒤, 실행·권한·telemetry·CI 경계를 고정 커밋에서 따라간 한국어 심층 독해. 결론은 빠르되 근거는 생략하지 않는다.

SourceTracer-Cloud/opensre
Snapshotbfa25c4782b7
Methodstatic-only · no repo code run
TrustB static · runtime unknown
01 / 13

대상·고정점·분석 경계

이 문서는 움직이는 GitHub 화면이 아니라, main이 가리킨 정확한 커밋과 root tree를 기준으로 작성한 정적 채택 실사다.

Object identity

Requested ref
not supplied
Analysis ref
main
Commit
bfa25c4782b73bc7be509d338d77bac9274eb602
Root tree
1b605eba1543bbbf96efa4936b54322bb3b77666

Four independent axes

Visibility
public
Acquisition auth
unauthenticated
Sensitivity
clear after redaction
Publication
allow — Apache-2.0 attribution, third-party media omitted
Execution
static-only; repository code not run

깨끗한 재캡처 기록

이전 임시 획득 디렉터리에서 receipt와 모순되는 checkout 흔적을 발견해 그 증거를 최종 근거에서 제외했다. 이 문서는 별도 opensre-v2 작업공간의 bare object database에서 다시 캡처했으며 checkout·worktree·설치·빌드·테스트·import를 수행하지 않았다.

02 / 13

10분 학습 가이드

핵심 질문은 하나다. OpenSRE는 “SRE용 챗봇”인가, 아니면 실제 운영 증거를 수집해 RCA를 만드는 에이전트 런타임인가? 정적 코드가 보여주는 답은 후자에 가깝다. 다만 현재는 Public Alpha이고, 안전·프라이버시 경계의 일부는 문서보다 훨씬 느슨하다.

먼저 알아야 할 것

  • 관측성의 세 축: 로그·메트릭·트레이스
  • LLM tool-calling / ReAct 루프
  • incident intake → evidence → diagnosis → delivery
  • opt-in과 opt-out 텔레메트리의 차이

멘탈 모델

여러 진입면이 하나의 조사 capability를 부른다. capability는 평평한 상태 객체를 단계별 patch로 갱신하고, 연결된 도구에서 증거를 모은 뒤 구조화된 진단과 보고서를 만든다.

“한 개의 거대한 agent class”가 아니라, surface → capability → staged state machine → integrations다.

점검 질문

  1. README의 주장과 실제 기본 동작이 다른 곳은 어디인가?
  2. 도구 실행 승인과 민감정보 마스킹은 어디에서 강제되는가?
  3. 내 환경에서 관측 데이터가 외부 LLM·PostHog·Sentry로 나가는 경계는 무엇인가?
10분판정 → 실제 구현 → 위험 5개이 문서 02, 03, 09절
30분아키텍처 → 설치 → 건강도04–10절
기여자상태·registry·gather loop06절의 순서대로 코드 읽기
03 / 13

Executive Verdict

OpenSRE는 활발히 개발되는 실제 코드베이스다. 그러나 지금 production에 바로 넣을 “안전한 자동 SRE”가 아니라, 격리된 환경에서 평가해야 할 강력한 Public Alpha다.

MaturityALPHA프로젝트 자체 표기
MaintenanceA빠른 커밋·릴리스
Evidence trustB고정 SHA 정적 근거 강함 · runtime 미실행
Production adoptionHOLD승인·shell·privacy 경계가 fail-open

잘 맞는 경우

  • AI SRE 조사 파이프라인을 연구·벤치마크하는 팀
  • 자체 인프라에 배포하고 코드를 검토·수정할 수 있는 팀
  • 60여 통합 후보를 빠르게 실험할 격리된 랩 환경

지금은 맞지 않는 경우

  • 검토 없이 production shell 권한을 맡길 팀
  • 민감 prompt/response의 외부 전송을 허용할 수 없는 조직
  • 안정 API·공개 성능 수치·보수적 릴리스가 필수인 조직

inference 활발함은 안전함과 동의어가 아니다. 이 판정은 고정 커밋의 정적 코드·설정·테스트·문서와 시각이 붙은 GitHub 메타데이터에 근거하며, 저장소 코드를 실행해 확인하지 않았다.

Implementation confidencehigh진입점부터 핵심 lifecycle·상태·도구 경계까지 고정 소스로 연결
Runtime confidenceunknown설치·실행·테스트·벤치마크를 수행하지 않음
Maintenance coveragehigh릴리스·체크·이슈·PR·기여·community 표본을 시각과 함께 기록
Security / privacy confidencemedium정적 enforcement 경계는 확인했으나 비공개 alert와 실제 egress는 미확인
04 / 13

무엇이 실제로 구현돼 있는가

판정프로젝트 주장정적 증거로 본 상태
verified다단계 incident investigation

resolve → intake → plan → gather → diagnose → deliver가 lifecycle에 실제 조합돼 있다. 근거

verifiedCLI·REPL·HTTP·채팅 진입면

콘솔 entrypoint와 동기/비동기 HTTP, gateway runtime이 같은 조사 capability에 수렴한다. 근거

partial60+ integrations

대규모 registry와 도구 구현은 존재하지만 README 표에는 roadmap 항목도 섞여 있다. “이름이 보인다”를 “모두 production-ready”로 계산할 수 없다.

partial가역 identifier masking

masking 모듈과 제한된 호출 경로·테스트는 있으나, 주 조사 pipeline에서 실제 MaskingContext.mask() 호출을 이번 bounded call-site 탐색으로 확인하지 못했다. 부재 확정이 아니라 inference다.

claimedAI SRE benchmark/training ground

synthetic/E2E 구조는 크지만 README의 공개 benchmark 표는 현재 “결과 없음”이다. 구조의 존재와 모델 성능은 다른 주장이다. 근거

unknown실제 RCA 정확도·안정성

테스트 파일과 CI 정의는 확인했지만 실행하지 않았다. badge·test presence·merged PR은 runtime 성능 증명이 아니다.

05 / 13

아키텍처와 실행 흐름

네 계층의 하향 의존과, 하나의 flat AgentState를 단계별로 갱신하는 조사 lifecycle이 중심이다.

USER / ALERT
    │
    ├── CLI / REPL ─────┐
    ├── FastAPI HTTP ───┼──▶ investigation capability
    └── Slack/Telegram ─┘              │
                                       ▼
  resolve integrations → intake → plan evidence → gather evidence
                                                │       ▲
                                                └─ ReAct loop (≤20)
                                                        │
                                                        ▼
                                        diagnose → report → deliver

  Tier 1  surfaces + gateway
  Tier 2  tools/investigation + integrations registry
  Tier 3  core state/LLM/session + platform ports/adapters
  Tier 4  config

핵심 상태 계약

AgentStateModel은 alert, plan, runtime/evidence, diagnosis, delivery, eval 필드를 한 객체에 둔다. 단계 patch는 대부분 last-write-wins이고, messages만 append된다.

공개 결과는 내부 상태 전체가 아니라 report, problem, root cause, validity/noise, tool calls로 투영된다.

증거 수집의 경계

  • 최대 조사 루프: 20
  • agent tool schema hard cap: 32
  • 기본 tool budget: 10
  • 중복-only stagnation: 2
  • secondary tool reserve: 3

독립 정적 검토가 바꾼 판정

하나의 pipeline, 두 control path

동기 경로는 canonical lifecycle을 호출하지만 스트리밍 경로는 단계를 다시 조합하고 base agent·별도 report 경로를 사용한다. 기능상 비슷해도 drift 가능성은 실제 구현 위험이다. 고정 코드

32-tool cap의 정확한 범위

상한은 fallback relevance ranking에 적용된다. 명시적 planned-actions subset에는 같은 max_tools 절단이 보이지 않아 “항상 hard cap”으로 표현하지 않는다. 고정 코드

취소는 끝까지 전파됐는가?

outer pump 정리와 5초 wait는 보이지만 inner thread·진행 중 provider/tool call을 멈추는 cooperative token은 선택 코드에서 확인되지 않았다. 실제 누출 여부는 runtime test 전까지 unknown이다.

승인 metadata와 실제 enforcement

shared executor는 optional hook을 제공하지만 compatibility path는 hook 없이 실행될 수 있다. 따라서 metadata 존재를 effective authorization으로 계산하지 않았다. 고정 코드

06 / 13

설치와 첫 성공 — 명령은 실행하지 않음

공급망 경고

README 기본 설치는 최신 main 스크립트를 바로 shell/PowerShell에 넘긴다. 편리하지만 실행 시점의 원격 코드가 즉시 권한을 얻는다. production 평가라면 release/tag를 고정하고 installer를 먼저 읽고, checksum·서명·배포 artifact 출처를 별도 검증해야 한다.

프로젝트가 제시하는 Unix 명령

curl -fsSL https://install.opensre.com | bash
COMMAND — NOT RUN

프로젝트가 제시하는 Homebrew 명령

brew tap tracer-cloud/tap
brew install tracer-cloud/tap/opensre
COMMAND — NOT RUN
  1. 전제 확인

    패키지는 Python >=3.12를 선언한다. 사용할 LLM provider와 관측/클라우드 통합의 credential·network egress를 먼저 목록화한다.

  2. 격리된 평가 환경

    실운영 계정·shell·Slack workspace 대신 최소 권한의 test account와 disposable host/container를 쓴다.

  3. 텔레메트리 결정

    민감한 incident prompt를 쓰기 전에 OPENSRE_NO_TELEMETRY=1 등 실제 코드가 읽는 disable 경로를 확인한다.

  4. 프로젝트 onboarding

    설치 후 프로젝트가 제시하는 첫 단계는 opensre onboard다. 성공 기준은 설정 완료와 REPL/one-shot 조사 명령의 정상 시작이지만, 본 분석에서는 실행하지 않았다.

  5. 정리 경로 검토

    opensre uninstall은 README상 binary와 로컬 데이터를 제거한다. 실행 전 session/integration store 보존 여부를 확인해야 한다.

README 설치·Quick Start 원문

07 / 13

권장 코드 읽기 순서

사용자 · 15분

  1. README.md — 약속과 상태
  2. surfaces/cli/__main__.py — 실제 진입
  3. surfaces/cli/commands/general.py — investigate UX
  4. tools/investigation/capability.py — 공개 결과

운영자 · 25분

  1. gateway/runtime/manager.py
  2. gateway/http/webapp.py
  3. integrations/store.py
  4. platform/harness_ports.py
  5. Dockerfile / infra/terraform

기여자 · 45분

  1. docs/ARCHITECTURE.md
  2. core/state/models.py
  3. tools/investigation/lifecycle.py
  4. tools/registry.py
  5. tools/investigation/stages/gather_evidence/agent.py
  6. tools/investigation/stages/diagnose/node.py

보안 검토자 · 45분

  1. tools/interactive_shell/shared/execution_policy.py
  2. core/execution.py
  3. surfaces/interactive_shell/utils/telemetry/
  4. platform/observability/errors/sentry.py
  5. integrations/store.py
  6. .github/workflows/ci.yml
신규 엔지니어용 전체 20개 순서
  1. docs/ARCHITECTURE.md
  2. pyproject.toml
  3. surfaces/cli/__main__.py
  4. surfaces/cli/commands/general.py
  5. tools/investigation/capability.py
  6. tools/investigation/state_factory.py
  7. core/state/models.py
  8. tools/investigation/lifecycle.py
  9. tools/investigation/stages/resolve_integrations/node.py
  10. platform/harness_ports.py
  11. integrations/harness_adapters.py
  12. integrations/_catalog_impl.py
  13. tools/registry.py
  14. tools/registry_discovery.py
  15. tools/investigation/stages/plan_evidence/node.py
  16. tools/investigation/stages/gather_evidence/tools.py
  17. tools/investigation/stages/gather_evidence/agent.py
  18. tools/investigation/stages/diagnose/node.py
  19. tools/investigation/reporting/node.py
  20. gateway/runtime/manager.py
08 / 13

건강도와 릴리스

프로젝트는 매우 활발하다. 다만 속도가 빠르다는 사실은 API 안정성·회귀 부재·운영 안전성을 보증하지 않는다.

105 / 100checks reported / details captured
≈1.0일안정 릴리스 표본 중앙 간격
91.72%issue closure · Search 총계
68.05%closed PR 중 merge
1.79h첫 비작성자 응답 · 4/5 편의 표본
289GitHub SPDX SBOM packages

동적 값 · 2026-07-15 UTC 캡처. issues 1667/closed 1529, PR 2353/closed 2344/merged 1595. 응답시간은 공개 댓글이 있는 4/5개 편의 표본이며 범위는 0.43–33.46시간이다. 별·fork·release·check는 캡처 시점 값이며 품질 보증이 아니다.

Attention, not health8,451 stars · 1,161 forks · 42 watching

관심도를 보여줄 뿐 코드 품질·보안·유지보수 응답성을 직접 증명하지 않는다. 첫 100명 contributor 페이지의 기여량은 상위 1명이 32.97%, 상위 10명이 77.16%였지만 이는 bus factor가 아니다.

강한 신호

  • 고정 SHA는 105개 checks를 보고했으며, 세부 캡처 100개는 66 success, 33 skipped, 1 cancelled
  • quality, 5개 test shard, Kubernetes, synthetic, CodeQL Python/JS, binary build가 success 목록에 존재
  • CodeQL·Dependabot 구성과 289-package dependency-graph SBOM
  • Apache-2.0, SECURITY, CONTRIBUTING, code of conduct, PR template 존재

체크는 GitHub에서 과거에 관찰된 결과이며 본 분석의 로컬 실행 결과가 아니다.

주의 신호

  • README는 Public Alpha, CLI는 Public Beta로 같은 커밋에서 충돌
  • README benchmark 결과가 비어 있음
  • main 최신 build가 일반 설치 기본이며 릴리스 간격이 매우 짧음
  • branch protection·code/secret scanning·Dependabot alert 상태는 비인증 API에서 401로 unknown
  • 공개 issue/PR 숫자와 높은 활동량은 수정 품질의 증거가 아님

외부 기준으로 본 “증명해야 할 것”

AWS DevOps Agent와 Google Cloud Assist의 공식 문서는 관측 데이터·코드·배포 상관관계, 근거 링크, 명시적 권한 범위를 제품 기준으로 둔다. Datadog은 실제 incident를 재생하는 noisy world snapshot과 사람 검증 label이 없으면 에이전트 회귀를 잡기 어렵다고 설명한다. SREGym은 90개 live-system 문제를, ITBench는 94개 IT 시나리오와 낮은 SRE 해결 baseline을 공개한다.

따라서 OpenSRE의 synthetic/E2E 구조는 방향이 맞지만, README에 공개 결과가 없는 현재 상태에서는 성능·안전성을 채택 근거로 쓸 수 없다.

출처: AWS 공식 문서 · Google Cloud 공식 문서 · Datadog 공식 엔지니어링 글

09 / 13

보안·프라이버시·공급망

가장 중요한 결과는 “취약점 몇 개”가 아니라, 문서가 독자에게 주는 안전 모델과 실제 기본 실행 모델 사이의 거리다.

CRITICAL

Alpha interactive shell은 사실상 allow-all

tools/interactive_shell/shared/execution_policy.pyshell/policy.py는 sudo·dd·kill을 포함한 명령도 확인 없이 허용하고, shell/execution.py는 실제 login shell로 실행한다. production credential이 있는 host에서 기본 REPL을 신뢰 경계로 보면 안 된다. 코드

CRITICAL

승인 metadata가 기본 실행 경로에서 강제되지 않음

Slack/Telegram 외부 전송 tool은 requires_approval=True를 선언하지만, core/execution.py는 optional before_tool_call hook만 차단점으로 사용한다. 기본 REPL은 그 hook을 넘기지 않는다. GitHub issue mutation은 mutating surface인데 승인 metadata도 빠져 있다. 코드

HIGH

“PII를 수집하지 않는다”는 문서와 prompt logging 기본값 충돌

docs/DEVELOPMENT.md의 설명과 달리 interactive-shell PostHog prompt logging이 기본 활성화돼 있고, user prompt와 assistant response를 최대 약 32K까지 AI event 속성으로 전송하는 경로가 있다. redaction은 알려진 token pattern 중심이어서 임의 incident PII/hostname/내부 문맥 전부를 보장하지 않는다. 코드

HIGH

end-to-end masking 주장은 주 pipeline에서 정적으로 확인되지 않음

masking 구현·테스트·일부 제한 경로는 보이지만, main investigation pipeline에서 실제 MaskingContext.mask() 호출을 이번 bounded 탐색으로 찾지 못했다. inference이므로 “없다”가 아니라 “production 도입 전에 직접 trace해야 한다”가 결론이다. 코드

HIGH

원격 main installer를 shell에 직접 연결

편의성은 높지만 commit pin·사전 검토·checksum verification을 건너뛴다. 정적 분석에서는 installer를 실행하지 않았다. installer 자체도 verifier/checksum asset이 없을 때 경고 후 계속할 수 있다. 코드

HIGH

배포 기본값이 파괴적이고 공개 범위가 넓다

make deploy는 기존 stack을 자동 파괴한 뒤 다시 만들며, gateway web ingress 기본값은 0.0.0.0/0다. disposable account가 아니면 평가 명령 자체가 운영 변경이 된다. 문서

평가 전 최소 조치

  1. production network가 없는 disposable host + 만료 짧은 read-only 계정
  2. 첫 실행 전 OPENSRE_NO_TELEMETRY=1·OPENSRE_SKIP_GITHUB_LOGIN=1
  3. OPENSRE_MASK_ENABLED=true와 조직별 extra regex를 켜고 실제 provider payload를 검증
  4. REPL·shell·remediation·deploy 기능을 제거하거나 OS sandbox 밖으로 못 나가게 격리
  5. LLM/Slack/GitHub/Telegram mutation tool을 enforced fail-closed approval 뒤에 배치
  6. moving main 대신 release·commit·checksum을 별도 pin

두 독립 검토의 합의와 hard blockers

합의: 이 커밋은 학습·격리 read-only pilot에는 검토 가치가 있지만 production credential, public exposure, unattended remediation, autonomous incident command에는 부적합하다.

  • branch protection·CodeQL alert·Dependabot·secret-scanning의 현재 private state는 401로 unknown.
  • 고정 SHA check 105개 중 세부 100개만 캡처되어 나머지 5개 결론은 partial.
  • masking library는 존재하지만 모든 outbound provider/MCP/retry/error path의 wiring은 unverified.
  • public advisories 0건은 “공개된 repository advisory가 반환되지 않음”일 뿐 취약점 0개의 증거가 아니다.
10 / 13

라이선스와 도입 조건

Apache License 2.0

고정 snapshot의 root LICENSE와 package metadata가 Apache-2.0을 가리킨다. 이 문서의 README 한국어 번역은 원저작자·저장소·고정 커밋을 표시한 비공식 파생 문서다.

docs/LICENSE에는 Mintlify 문서 범위의 MIT 문구가 따로 있고, 완전 트리에서 root NOTICE는 찾지 못했다. GitHub SBOM은 289 packages를 반환했다. README 이미지·외부 badge·통합 logo는 라이선스·상표·signed-query 불확실성 때문에 재게시하지 않고 alt text와 occurrence 원장만 남겼다.

  • 기술 gate approval 강제, shell 격리, masking trace
  • 데이터 gate incident prompt의 vendor별 전송·보존·redaction 확인
  • 공급망 gate main installer 대신 pinned artifact와 checksum
  • 운영 gate 자체 benchmark·failure injection·rollback

법률 자문이 아니다. LICENSE 원문

11 / 13

Claim Ledger

주장상태판정
Public Alpha이며 API·통합이 변할 수 있다project-statedconfirmed
프로젝트 성숙도 표기가 일관되다contradictedREADME Alpha ↔ CLI Beta
CLI/REPL/HTTP/chat이 같은 staged investigation으로 수렴한다static-supportconfirmed
60+ integrations가 모두 동일한 완성도로 동작한다project-stated + static samplepartial / overstated if read literally
공개 benchmark가 성능을 증명한다project-statednot supported — no results
민감 identifier가 외부 LLM 전 end-to-end 마스킹된다inferenceunresolved
prompt/response PII를 수집하지 않는다contradictedmaterial conflict
외부 mutation은 requires_approval metadata로 보호된다contradictedmetadata not enforced by default path
프로젝트는 매우 활발히 유지된다external-confirmed + static historyconfirmed at capture time
고정 SHA의 CI 상태가 건강하다historical GitHub checks105 total · first 100: 66 success / 33 skipped / 1 cancelled; local run 아님
공개 benchmark가 OpenSRE 성능을 입증한다unknownREADME 결과 없음; 외부 live benchmark 기준만 확인
활발하므로 production-safe하다inferencerejected
동기·스트리밍이 하나의 lifecycle 구현을 공유한다static-supportcontradicted — 단계 재구현·agent/report 차이
32-tool schema hard cap은 모든 selection path에 적용된다static-supportpartial — planned-actions path 예외
CLI cancel이 inner thread·LLM·tool까지 중단한다static-supportunknown — runtime cancellation test 필요
requires_approval metadata가 shared executor에서 자동 강제된다static-supportcontradicted — optional hook wiring 필요
production 도입보다 격리 read-only pilot이 타당하다two independent reviewssupported recommendation

문서 충돌과 열려 있는 질문

문서가 주는 인상고정 snapshot의 실제 근거판정
main은 normal install용 “latest stable”main push release가 full CI workflow에 명시적으로 종속되지 않음과도한 표현
프로젝트 상태는 Public AlphaCLI landing은 같은 SHA에서 Public Beta 출력직접 충돌
/trust 또는 elevated-action prompt가 변경을 막음실행-stage 정책은 alpha에서 모든 action과 shell을 즉시 allow도입 차단급 충돌
anonymous metadata만 수집하고 alert/file/hostname/PII는 수집하지 않음전용 privacy 문서와 recorder는 prompt/response의 PostHog 기본 전송을 명시직접 충돌
masking on이면 evidence가 LLM 전 mask되고 결과에서 복원library·final unmask는 있으나 main input mask call-site 미확인미검증
make test-full은 e2e 포함 full suitepytest.ini가 e2e/deployment 자동 수집을 제외직접 충돌
gateway도 main 품질 gate의 정상 범위gateway/**가 CI trigger와 Python quality path에서 빠짐coverage gap
benchmark/training environment가 성능을 보여줌fixture·workflow는 풍부하지만 공개 benchmark 결과는 없음정량화 없음

도입 전 반드시 답해야 할 질문

  1. 실제 provider request payload에서 identifier·prompt가 어떻게 보이는가?
  2. hook이 없는 모든 external/mutating tool을 fail-closed로 막을 수 있는가?
  3. release artifact가 어떤 CI run·source SHA·SBOM·signature에 묶여 있는가?
  4. 내 fixture에서 RCA 정확도, false positive, 비용, latency는 얼마인가?
  5. gateway-only 회귀와 Windows/macOS 동작을 누가 blocking gate로 검증하는가?

test-full 문서 · gateway CI

독립 심층검토

아키텍처·구현 경로와 보안·개인정보·운영 위험을 서로 다른 두 정적 리서치 트랙으로 검토했다. 둘 다 같은 고정 커밋과 선택 파일을 사용했고 저장소 코드는 실행하지 않았다. 원문 리서치 보고서의 해시는 출처 원장에 남겼다.

12 / 13

원본 README 한국어 완역

번역 범위: 캡처 커밋의 README.md 308줄 전체. authored occurrence 81개(링크 51, 이미지 28, picture source 2)를 원장화했다. 링크는 번역 또는 원장에서 보존했고, 이미지는 27개를 명시적으로 생략했으며 signed-query 3개는 차단·redaction했다.

번역은 학습 편의를 위한 비공식 한국어판이다. 원 저작권과 Apache-2.0 조건은 OpenSRE 기여자에게 있으며, 의미가 충돌하면 고정 SHA 원문이 우선한다.

이미지 생략: OpenSRE · occurrence 1

OpenSRE v0.1: 나만의 AI SRE 에이전트 구축

AI SRE 에이전트를 위한 오픈 소스 프레임워크이자, 이들이 개선되는 데 필요한 훈련 및 평가 환경입니다. 이미 사용 중인 60개 이상의 도구를 연결하고, 자체 워크플로를 정의하며, 자신의 인프라에서 인시던트를 조사하세요.

CI status이미지 생략: CI status · occurrence 3 Project status: public alpha이미지 생략: Project status: public alpha · occurrence 5 Apache 2.0 License이미지 생략: Apache 2.0 License · occurrence 7 Discord이미지 생략: Discord · occurrence 9 Sponsored by Greptile이미지 생략: Sponsored by Greptile · occurrence 11
Tracer-Cloud%2Fopensre | Trendshift이미지 생략: Tracer-Cloud%2Fopensre | Trendshift · occurrence 13
원문의 Trendshift 저장소 배지. 원문 대상: https://trendshift.io/repositories/25889

🚧 공개 알파(Public Alpha): 핵심 워크플로는 초기 탐색에 사용할 수 있지만, 아직 완전히 안정적이지는 않습니다. 프로젝트는 활발히 개발 중이며 API와 통합은 변경될 수 있습니다.

목차


왜 OpenSRE인가?

프로덕션에서 무언가 고장 나면 증거는 로그, 메트릭, 트레이스, runbook, Slack 스레드에 흩어집니다. OpenSRE는 프로덕션 인시던트를 해결하는 AI SRE 에이전트를 위한 오픈 소스 프레임워크이며, 자신의 인프라에서 실행하도록 만들어졌습니다.

우리가 이렇게 하는 이유는 SWE-bench1가 코딩 에이전트에 확장 가능한 훈련 데이터와 명확한 피드백을 제공했기 때문입니다. 프로덕션 인시던트 대응에는 아직 그와 동등한 것이 없습니다.

분산 장애는 로컬 코드 작업보다 느리고, 잡음이 많으며, 시뮬레이션하고 평가하기도 더 어렵습니다. 이것이 AI SRE, 더 넓게는 프로덕션 디버깅을 위한 AI가 여전히 해결되지 않은 이유입니다.

OpenSRE는 바로 빠진 계층을 만들고 있습니다.

현실적인 프로덕션 장애를 위한 end-to-end 테스트와 합성 인시던트 시뮬레이션을 갖춘, 에이전트 기반 인프라 인시던트 대응용 개방형 강화학습 환경

이를 위해 다음을 수행합니다.

  • 프로덕션 인시던트 조사와 대응을 위한, 배포하기 쉽고 사용자 지정 가능한 AI SRE 에이전트를 구축합니다.
  • 근본 원인의 정확성, 필수 증거, 적대적 red herring을 검사하는 점수화된 합성 RCA suite를 실행합니다. (tests/synthetic)
  • Kubernetes, EC2, CloudWatch, Lambda, ECS Fargate, Flink를 포함하는 cloud-backed 시나리오 전반에서 실제 환경 end-to-end 테스트를 실행합니다. (tests/e2e)
  • e2e와 synthetic, local과 cloud의 경계가 분명하게 보이도록 의미 기반 테스트 catalog 이름을 유지합니다. (tests/README.md)

우리의 사명은 이 기반 위에 AI SRE 에이전트를 만들고, 이를 현실적인 수천 개의 인프라 장애 시나리오로 확장하며, OpenSRE를 AI SRE의 벤치마크이자 훈련장으로 확립하는 것입니다.

1 https://arxiv.org/abs/2310.06770


설치

루트 installer URL은 Unix shell인지 PowerShell인지 자동 감지하고 main의 최신 빌드를 설치합니다. OpenSRE는 빠르게 변화하므로 일반 설치에서는 main이 최신 안정 버전입니다.

macOS / Linux:

curl -fsSL https://install.opensre.com | bash

macOS/Linux installer에는 sudo가 필요하지 않습니다. 쓰기 가능한 bin 디렉터리가 이미 PATH에 없으면 ~/.local/bin에 설치하고, PATH 업데이트를 적용할 shell 명령을 출력합니다.

동등한, 명시적인 main-channel 형식:

curl -fsSL https://install.opensre.com | bash -s -- --main

Homebrew:

brew tap tracer-cloud/tap
brew install tracer-cloud/tap/opensre

Windows (PowerShell):

irm https://install.opensre.com | iex

원문에서 HTML 주석 처리되어 표시되지 않는 설치 명령:

pipx install opensre

빠른 시작

한 번 구성한 다음, 조사 실행 방식을 선택하세요.

opensre onboard

대화형 shell — 서브커맨드 없이 실행하면 opensre가 REPL을 시작합니다(TTY 필요). 자연어로 인시던트를 설명하고, 조사 과정을 스트리밍하며, 세션 제어용 slash command(/help, /status, /cost, /sessions, /resume, /compact, /new, /exit), 통합용 명령(/integrations list, /integrations verify), 로컬 에이전트 fleet 모니터링(/agents), 추론 깊이(OpenAICodex에서 low부터 max까지 설정하는 /effort)를 사용할 수 있습니다. Ctrl+C는 세션 상태를 잃지 않고 진행 중인 조사를 취소합니다. 전체 참고 문서는 interactive shell 명령에서 확인하세요.

opensre

일회성 조사 — alert 파일을 대상으로 에이전트를 한 번 실행합니다.

opensre investigate -i tests/e2e/kubernetes/fixtures/datadog_k8s_alert.json

원격 runtime 조사 — 배포된 서비스를 이름으로 조사합니다(live health, logs, deployment status).

opensre investigate --service api-backend

Hermes log watch — Hermes errors.log의 끝을 따라가며 인시던트를 분류하고, 선택적으로 Telegram alert를 보냅니다.

opensre hermes watch

그 밖의 유용한 명령:

opensre integrations setup
opensre agents scan
opensre update
opensre uninstall   # remove opensre and all local data

배포

두 가지 주요 AWS EC2 경로와 일반적인 hosted 선택지가 있습니다.

  • EC2 (Docker/ECR): make build-image 다음 make deploy — 한 instance에서 opensre-webopensre-gateway container를 실행합니다.
  • Gateway (AMI + systemd): make bake-gateway 다음 make deploy-gateway — Docker 없이 사용자 지정 AMI에 구워 넣은 Telegram gateway만 실행합니다.
  • Hosted (Railway / ECS / Vercel): 저장소의 Dockerfile로 배포합니다. LLM_PROVIDER와 이에 맞는 API key(.env.example 참고)를 설정하고, persistence가 필요하면 DATABASE_URIREDIS_URI도 설정합니다.

전체 배포 단계와 사전 요구 사항 → DEPLOYMENT.md


OpenSRE의 작동 방식

이미지 생략: opensre-how-it-works-github · occurrence 37
원문에 배치된 OpenSRE 작동 방식 다이어그램.

alert가 발생하면 OpenSRE는 자동으로 다음을 수행합니다.

  1. 가져오기: alert context와 연관된 logs, metrics, traces, recent deploys를 가져옵니다.
  2. 마스킹: 외부 LLM 호출 전에 민감한 identifier를 선택적으로 마스킹합니다.
  3. 추론: 연결된 시스템 전반을 살피며 tool-calling loop에서 가설을 검증합니다.
  4. 생성: 가능성이 높은 root cause와 연결된 evidence가 포함된 구조화된 조사 report를 생성합니다.
  5. 제안: 다음 단계를 제안하고, 선택적으로 remediation action을 실행합니다.
  6. 게시: context switching 없이 요약을 Slack, PagerDuty 또는 Telegram에 직접 게시합니다.

기존 graph 및 chain framework 계층을 제거한 뒤의 현재 코드 수준 에이전트 아키텍처는 AGENTS.md를 참조하세요.


벤치마크

make benchmark로 수치를 다시 생성하고, make benchmark-update-readme로 cached result에서 이 표를 갱신하세요. 자세한 내용은 docs/DEVELOPMENT.md를 참조하세요.

아직 벤치마크 결과가 없습니다.


기능 및 통합

🔍 구조화된 인시던트 조사logs, metrics, traces, deploys, config 전반을 연관 분석하는 root-cause analysis
📋 Runbook-aware 추론OpenSRE가 사용자의 runbook을 읽고 자동으로 적용합니다.
🔗 증거 기반 root cause모든 결론이 그 근거가 되는 데이터에 연결됩니다.
🛡️ 되돌릴 수 있는 identifier 마스킹외부 LLM 호출 전에 pods, clusters, account IDs를 가리고, 출력에서 복원합니다.
📊 세션 비용 및 기록세션별 token 추적(/cost)과 재개할 수 있는 REPL 세션(/sessions)
👥 로컬 agent fleet사용자 machine에서 Claude Code, Cursor, Codex 및 기타 coding agent를 모니터링합니다.
🌐 원격 runtime RCAlive health probe와 최근 logs를 사용해 배포된 서비스를 이름으로 조사합니다.
📡 Hermes log watchHermes error log의 끝을 따라가고, 인시던트를 분류하며, Telegram alert를 전달합니다.
🤖 완전한 LLM 유연성자신의 model을 사용하세요 — Anthropic, OpenAI, Codex, Ollama, Gemini, OpenRouter, NVIDIA NIM, Bedrock

OpenSRE는 LLM, observability, cloud infrastructure, data platform, incident management, MCP 전반의 60개 이상 도구에 연결됩니다. roadmap 링크가 포함된 전체 matrix는 제품 문서에 있으며, 프로젝트가 성장함에 따라 상세 catalog도 저장소 안에서 유지됩니다.


통합

OpenSRE는 LLM provider와 observability platform부터 infrastructure, database, incident management까지 현대적인 cloud stack 전반의 60개 이상 도구 및 서비스에 연결됩니다.

범주통합Roadmap
AI / LLM Providers Anthropic · OpenAI · OpenAI Codex · Ollama · Google Gemini · OpenRouter · NVIDIA NIM · Bedrock
Observability 이미지 생략: 원문 이미지 · occurrence 41 Grafana (Loki · Mimir · Tempo · annotations) · 이미지 생략: 원문 이미지 · occurrence 42 Datadog · Honeycomb · Coralogix · 이미지 생략: 원문 이미지 · occurrence 43 CloudWatch · 이미지 생략: 원문 이미지 · occurrence 44 Sentry · Elasticsearch · Better Stack · Splunk · Victoria Logs · SignOz · OpenObserve · OpenSearch · Azure Monitor · Hermes New Relic
Infrastructure 이미지 생략: 원문 이미지 · occurrence 46 Kubernetes · 이미지 생략: 원문 이미지 · occurrence 47 AWS (S3 · Lambda · EKS · EC2 · CloudTrail · Bedrock) · 이미지 생략: 원문 이미지 · occurrence 48 GCP · 이미지 생략: 원문 이미지 · occurrence 49 Azure · ArgoCD · Helm · Jenkins
Database MongoDB · ClickHouse · PostgreSQL · MySQL · MariaDB · MongoDB Atlas · Azure SQL · Snowflake · Redis · RDS · Supabase
Data Platform Apache Airflow · Apache Kafka · Apache Spark · Prefect · RabbitMQ · Dagster
Dev Tools 이미지 생략: 원문 이미지 · occurrence 50 GitHub · GitHub MCP · Bitbucket · GitLab
Incident Management 이미지 생략: 원문 이미지 · occurrence 51 PagerDuty · Opsgenie · Jira · Alertmanager · incident.io Trello · ServiceNow · Linear
Communication 이미지 생략: 원문 이미지 · occurrence 55 Slack · Google Docs · Discord · Telegram · WhatsApp Notion · Teams · Confluence
Agent Deployment 이미지 생략: 원문 이미지 · occurrence 59 Vercel · 이미지 생략: 원문 이미지 · occurrence 60 EC2 · 이미지 생략: 원문 이미지 · occurrence 61 ECS · Railway
Protocols 이미지 생략: 원문 이미지 · occurrence 62 MCP · 이미지 생략: 원문 이미지 · occurrence 63 ACP · 이미지 생략: 원문 이미지 · occurrence 64 OpenClaw

OpenSRE는 커뮤니티가 함께 만듭니다. 안전한 첫 기여를 찾고 있나요? good first issue 티켓을 둘러보거나 Good First Issues 가이드를 확인하세요. 전체 워크플로는 CONTRIBUTING.md를 참조하세요.

로컬 환경: SETUP.md (모든 플랫폼, Windows, MCP/OpenClaw).

이 저장소에서 개발하기: docs/DEVELOPMENT.md.

Join our Discord이미지 생략: Join our Discord · occurrence 71
이미지 차단: Star History Chart
이미지 소스 차단: (prefers-color-scheme: dark) · occurrence 73이미지 소스 차단: (prefers-color-scheme: light) · occurrence 74이미지 차단: Star History Chart · occurrence 75
원문의 Star History chart. 원문 대상: https://www.star-history.com/?type=date&repos=Tracer-Cloud%2Fopensre

다음의 훌륭한 분들께 감사드립니다.

Contributors이미지 생략: Contributors · occurrence 77
OpenSRE contributors. 원문 대상: https://github.com/Tracer-Cloud/opensre/graphs/contributors

보안

OpenSRE는 프로덕션 환경을 염두에 두고 설계됐습니다. 구조화되고 감사 가능한 LLM prompt, 기본적으로 로컬에서 처리되는 transcript, raw log를 알리지 않고 대량으로 내보내지 않는 방식을 사용합니다. 책임 있는 공개는 SECURITY.md를 참조하세요.


Telemetry

PostHog(product analytics)와 Sentry(errors)는 opt-out 방식입니다. 빠르게 비활성화하려면:

export OPENSRE_NO_TELEMETRY=1

전체 matrix, DSN override, 로컬 event logging → docs/DEVELOPMENT.md


라이선스

Apache 2.0 — LICENSE를 참조하세요.

인용

1 https://arxiv.org/abs/2310.06770

13 / 13

Provenance · Coverage · Static Analysis Receipt

재현 가능한 출처

입력
https://github.com/Tracer-Cloud/opensre/?twclid=…
정규화
https://github.com/Tracer-Cloud/opensre — 추적 query 제거
기준 ref
refs/heads/mainbfa25c4782b73bc7be509d338d77bac9274eb602
commit 시각
2026-07-14 17:07:46 +01:00
정적 캡처
2026-07-14 23:11:41 UTC, bare Git object database
동적 확인
2026-07-15 KST, GitHub 공개 UI·공식 API

저장소 전체 범위

tree
817
blob
4,059
총 blob bytes
177,693,696
README occurrence
81 = link 51 + image 28 + source 2
최근 이력
250 commits
직접 증거 파일
61개

정적 분석 영수증

수행bare clone의 object·tree·blob·commit 읽기, README 구조 보존, 고정 SHA 링크 생성, 코드/설정/문서/테스트의 정적 비교
공개GitHub 경로를 판별하기 전에 탐색용 checkout 1회가 만들어졌으나, 저장소 명령은 실행하지 않았고 권위 캡처·근거 산정에서는 제외했다.
미수행install · build · test · run · import · container · hook · submodule · LFS · filter · textconv · 저장소 제공 script/command
미확인runtime 동작·실제 RCA 정확도·비공개 보안 advisory·branch protection·secret 설정·운영 환경의 권한/네트워크 정책

선택 파일 원장

전체 4,059개 blob은 inventory 수준으로 캡처했다. 아래 파일은 문서 결론에 직접 인용된 53개 경로이며, canonical 재캡처 집합은 56개·15,491줄이었다. 아래 표에는 complete tree inventory에서 발견된 참고 경로도 포함되므로 각 행이 모두 full-read를 뜻하지 않는다.

경로Git objectbytes추정 tokens읽기 상태선택 이유
.github/dependabot.yml 8f77436b0c23 392 ≈98 인용 구간+주변 문맥 주장 검증에 직접 인용된 구현 파일
.github/workflows/ci-labels-windows.yml bb9460a6d3d1 3,420 ≈855 인용 구간+주변 문맥 CI·릴리스·자동화 경계
.github/workflows/ci.yml a4486cad4500 15,008 ≈3,752 인용 구간+주변 문맥 CI·릴리스·자동화 경계
.github/workflows/codeql.yml 7914e20767a3 1,042 ≈261 인용 구간+주변 문맥 CI·릴리스·자동화 경계
.github/workflows/interactive-shell-live.yml ceea4dcabcbe 4,782 ≈1,196 인용 구간+주변 문맥 CI·릴리스·자동화 경계
.github/workflows/release.yml e99f2abe9d49 25,832 ≈6,458 인용 구간+주변 문맥 CI·릴리스·자동화 경계
.github/workflows/synthetic-deterministic.yml 0dece1df490f 2,316 ≈579 인용 구간+주변 문맥 CI·릴리스·자동화 경계
CONTRIBUTING.md bb44a04fb50b 13,314 ≈3,329 전문 보안·법적 조건·기여·설치 기준
DEPLOYMENT.md 0c77008015ed 4,955 ≈1,239 인용 구간+주변 문맥 주장 검증에 직접 인용된 구현 파일
Dockerfile f0f5f8add367 1,734 ≈434 인용 구간+주변 문맥 주장 검증에 직접 인용된 구현 파일
LICENSE 2bdf3ee6f611 10,932 ≈2,733 전문 보안·법적 조건·기여·설치 기준
Makefile 629aa92ad8ef 26,096 ≈6,524 전문 패키지·테스트·개발 명령 계약
README.md aa9e3124704f 23,064 ≈5,766 전문 원문·주장·설치·통합·라이선스의 기준 문서
SECURITY.md 3595ba57eb63 1,170 ≈293 전문 보안·법적 조건·기여·설치 기준
SETUP.md 8e24b849810f 6,579 ≈1,645 전문 보안·법적 조건·기여·설치 기준
config/constants/posthog.py 7c76e2ee1abf 480 ≈120 인용 구간+주변 문맥 공통 상태·실행·구성 경계
config/constants/sentry.py 0988a4e22171 451 ≈113 인용 구간+주변 문맥 공통 상태·실행·구성 경계
core/execution.py d299c2d62fc3 15,462 ≈3,866 인용 구간+주변 문맥 공통 상태·실행·구성 경계
core/state/models.py 3bdf82086434 6,860 ≈1,715 인용 구간+주변 문맥 공통 상태·실행·구성 경계
docs/ARCHITECTURE.md 44cc741cfe9b 8,712 ≈2,178 인용 구간+주변 문맥 프로젝트가 서술한 아키텍처·보안·운영 계약
docs/DEVELOPMENT.md e5e2a4cee6ba 8,929 ≈2,233 인용 구간+주변 문맥 프로젝트가 서술한 아키텍처·보안·운영 계약
docs/LICENSE 54113742743d 1,064 ≈266 인용 구간+주변 문맥 보안·법적 조건·기여·설치 기준
docs/interactive-shell-action-policy.md 3084d1a04b56 14,758 ≈3,690 인용 구간+주변 문맥 프로젝트가 서술한 아키텍처·보안·운영 계약
docs/interactive-shell-privacy.mdx 0d59bb696530 7,822 ≈1,956 인용 구간+주변 문맥 프로젝트가 서술한 아키텍처·보안·운영 계약
docs/masking.mdx bbbc9a88e1ae 3,795 ≈949 인용 구간+주변 문맥 프로젝트가 서술한 아키텍처·보안·운영 계약
gateway/http/webapp.py d80a22257be7 7,569 ≈1,893 인용 구간+주변 문맥 gateway 진입면·상태·저장소 경계
infra/terraform/main.tf 8d84794eed04 12,176 ≈3,044 인용 구간+주변 문맥 주장 검증에 직접 인용된 구현 파일
infra/terraform/variables.tf deae5166031a 3,085 ≈772 인용 구간+주변 문맥 주장 검증에 직접 인용된 구현 파일
install.sh 5850cdd10677 35,116 ≈8,779 인용 구간+주변 문맥 주장 검증에 직접 인용된 구현 파일
integrations/datadog/tools/__init__.py 504f5c04312c 25,481 ≈6,371 인용 구간+주변 문맥 외부 시스템 연결·변경 도구·권한 경계
integrations/github/tools/work_status.py ba0eb61b4d0f 25,101 ≈6,276 인용 구간+주변 문맥 외부 시스템 연결·변경 도구·권한 경계
integrations/pi/client.py 7d8456d8f416 15,634 ≈3,909 인용 구간+주변 문맥 외부 시스템 연결·변경 도구·권한 경계
integrations/slack/tools/slack_reply_message_tool/tool.py 2fb4c93b5517 4,991 ≈1,248 인용 구간+주변 문맥 외부 시스템 연결·변경 도구·권한 경계
integrations/slack/tools/slack_send_message_tool/tool.py 2d8a6493259e 4,602 ≈1,151 인용 구간+주변 문맥 외부 시스템 연결·변경 도구·권한 경계
integrations/telegram/tools/telegram_send_message_tool/tool.py 49e8a3cf15e7 4,866 ≈1,217 인용 구간+주변 문맥 외부 시스템 연결·변경 도구·권한 경계
platform/__init__.py bd58f5901297 3,204 ≈801 인용 구간+주변 문맥 공통 상태·실행·구성 경계
platform/analytics/cli.py e07b65585d8e 32,296 ≈8,074 인용 구간+주변 문맥 공통 상태·실행·구성 경계
platform/analytics/provider.py e5bdb7c586ac 31,428 ≈7,857 인용 구간+주변 문맥 공통 상태·실행·구성 경계
platform/deployment/aws/config.py e533eb95dfd7 5,297 ≈1,325 인용 구간+주변 문맥 공통 상태·실행·구성 경계
platform/masking/context.py 3ccf50f6d19a 5,990 ≈1,498 인용 구간+주변 문맥 공통 상태·실행·구성 경계
platform/masking/policy.py d981445002ab 5,107 ≈1,277 인용 구간+주변 문맥 공통 상태·실행·구성 경계
platform/observability/errors/sentry.py 5b6067044a4c 22,881 ≈5,721 인용 구간+주변 문맥 공통 상태·실행·구성 경계
pyproject.toml 3535b1aaf473 5,727 ≈1,432 전문 패키지·테스트·개발 명령 계약
pytest.ini a71b90540326 924 ≈231 전문 패키지·테스트·개발 명령 계약
surfaces/cli/__main__.py 005eef91113a 9,943 ≈2,486 인용 구간+주변 문맥 사용자 진입면·기본 실행/telemetry 경계
surfaces/interactive_shell/prompt_history/policy.py 70bcdb2e38fb 7,780 ≈1,945 인용 구간+주변 문맥 사용자 진입면·기본 실행/telemetry 경계
surfaces/interactive_shell/runtime/shell_turn_execution.py 65f421429c85 4,366 ≈1,092 인용 구간+주변 문맥 사용자 진입면·기본 실행/telemetry 경계
surfaces/interactive_shell/runtime/turn_host.py 70c980916705 8,897 ≈2,225 인용 구간+주변 문맥 사용자 진입면·기본 실행/telemetry 경계
surfaces/interactive_shell/utils/telemetry/config.py 3632e415697b 2,593 ≈649 인용 구간+주변 문맥 사용자 진입면·기본 실행/telemetry 경계
surfaces/interactive_shell/utils/telemetry/recorder.py 183ecc11c9a8 13,471 ≈3,368 인용 구간+주변 문맥 사용자 진입면·기본 실행/telemetry 경계
tests/README.md 1e9bdcd376bc 2,600 ≈650 인용 구간+주변 문맥 주장에 대응하는 정적 테스트 근거
tests/tools/test_github_workflow_tools.py c37aa7a410d1 18,663 ≈4,666 인용 구간+주변 문맥 주장에 대응하는 정적 테스트 근거
tools/cross_vendor/fix_sentry_issue/context.py 2457c60155f0 5,049 ≈1,263 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책
tools/interactive_shell/shared/execution_policy.py e0bec22ed0c6 6,251 ≈1,563 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책
tools/interactive_shell/shell/execution.py d4194d32ec1b 3,693 ≈924 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책
tools/interactive_shell/shell/policy.py fd9eeb2aba7a 2,361 ≈591 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책
tools/investigation/capability.py eb58895233f5 19,126 ≈4,782 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책
tools/investigation/lifecycle.py ccf7d22e8fd5 2,741 ≈686 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책
tools/investigation/reporting/node.py d34b3853ec31 3,401 ≈851 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책
tools/investigation/stages/gather_evidence/agent.py 48a4039f8292 19,058 ≈4,765 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책
tools/investigation/stages/gather_evidence/tools.py 9013274d234f 11,694 ≈2,924 인용 구간+주변 문맥 조사 lifecycle·도구 실행·shell 정책

누락·한계 원장

  • 브라우저 표현: source.json에 GitHub의 가시 README 구조를 보조 캡처했다. 권위 원문은 동일 SHA의 Git object다.
  • CI 상태: current SHA의 check-runs는 총 105개였고 REST 상한 내 첫 100개를 조회해 66 success, 33 skipped, 1 cancelled를 기록했다. 과거 GitHub 결과이며 로컬 실행 관찰은 아니다.
  • 이슈·PR: GitHub Search 총계는 issues 1,667/closed 1,529, PR 2,353/closed 2,344/merged 1,595였다. 응답시간은 5개 편의 표본이므로 일반화하지 않았다.
  • 시간 변동: stars·forks·issues·releases·contributors는 캡처 뒤 바뀐다. 주목도 지표는 코드 안전성의 근거로 쓰지 않았다.
  • 확장 한도: 사용자의 심층 조사 요청에 따라 canonical 범위를 56개 파일·20,000 inspected-line cap·dependency 3 hops·REST 60회·90분으로 명시적으로 늘렸다. 실제 재캡처는 15,491줄이었다.

근거 계층

  1. 고정 Git object: 코드·문서·workflow·manifest의 최종 근거
  2. GitHub 공식 UI/API: 시각이 붙은 동적 유지보수·릴리스 상태
  3. 프로젝트 웹사이트: 프로젝트가 스스로 설명하는 사용 모델
  4. 정적 추론: call-site 탐색이나 부재 관찰은 inference로 별도 표기

캡처 JSON, occurrence manifest, claim ledger, health/risk ledger와 번역 원본은 이 HTML과 함께 로컬 artifact로 보존했다.

공개 증거 인덱스 · 전달 영수증

소스 화면 획득 실패의 처리

Aside 데몬은 로컬 연결 오류, in-app Browser는 사용 가능한 탭 부재로 실패했다. 따라서 Git 객체와 versioned GitHub REST를 권위 근거로 삼고, 서버 렌더링 GitHub HTML은 README 계층·보이는 링크를 확인하는 보조 근거로만 사용했다. 이 실패를 숨기거나 브라우저 성공으로 기록하지 않았다.