awesome-x-ops
현대적인 X-Ops의 큐레이션된 지도: AI Ops, LLM/Agent Observability, Platform Engineering, GitOps, DataOps, FinOps, DevSecOps, 그리고 프로덕션급 오픈소스 운영 도구들을 다룹니다.
Languages: English | 简体中文
Awesome
PRs Welcome
License: CC BY-NC 4.0
awesome-x-ops를 사용하는 이유?
운영(Operations) 작업은 더 이상 단순히 인프라 모니터링이나 CI/CD 연결고리 역할에 그치지 않습니다. 현대의 팀들은 AI 네이티브 애플리케이션, LLM Observability, Platform Engineering, 소프트웨어 배포, 클라우드 비용, 보안, 그리고 개발자 경험 전반에 걸친 실질적인 지도가 필요합니다.
이 목록은 팀들이 프로덕션 시스템을 구축하고, 실행하며, 관찰하고, 보호하고, 최적화하는 데 도움을 주는 도구들에 초점을 맞추고 있습니다.
주요 지도 (Featured Maps)
- LLM 및 Agent Observability 스택: LLM 및 에이전트 시스템을 위한 추적(tracing), 프롬프트 모니터링, 평가, 피드백, 그리고 프로덕션 텔레메트리.
- LLM 지식 (Knowledge): 문서를 RAG 지식 기반, 자율 추론 에이전트, 그리고 자체 유지형 위키로 변환하는 오픈소스 플랫폼.
- AI 인프라 (Infrastructure): 웹 크롤링, AI 준비 추출(extraction), 검색 지능, 그리고 RAG 데이터 획득.
- Platform Engineering 스택: 내부 개발자 플랫폼(internal developer platforms), IAM, IaC, 아티팩트, API 도구링, CI/CD, 그리고 테스트.
- GitOps 및 Kubernetes 운영 스택: 클러스터 네트워킹, 오토스케일링, 배포, 그리고 런타임 운영.
- FinOps 스택: 클라우드 및 Kubernetes 비용 가시성, 할당(allocation), 그리고 예측(forecasting).
- DevSecOps 및 공급망 스택 (Supply Chain): 정책, 런타임 보안, SBOM, 스캐닝, 그리고 소프트웨어 공급망 위험 관리.
- DataOps 스택: 데이터 흐름(dataflow), 오케스트레이션, 그리고 데이터 자산 생명주기 도구링.
누가 사용해야 할까요?
- 내부 개발자 플랫폼을 구축하는 플랫폼 엔지니어링 팀.
- 운영 스택을 현대화하는 DevOps, SRE 및 인프라 팀.
- 프로덕션 환경에서 LLM, RAG 및 에이전트 애플리케이션을 운영하는 AI 엔지니어링 팀.
- 구매하거나 직접 구축하기 전에 신뢰할 수 있는 오픈 소스 옵션을 찾는 엔지니어링 리더.
- 자신들의 프로덕션급 운영 도구를 발견 가능하게 만들고 싶은 오픈 소스 유지보수자.
이 맵 사용 방법
가장 유행하는 프로젝트부터 시작하기보다는, 제어해야 할 운영 실패 지점부터 시작하세요. 추적 및 평가 증거를 위해 **LLM 및 에이전트 관측 가능성(Observability)**을, 롤아웃 및 런타임 용량을 위해 **AI 서빙 및 추론 운영(Inference Operations)**을, 수집 및 검색을 위해 AI 인프라 또는 **LLM 지식(Knowledge)**을, 정책, 격리 및 감사를 위해 **보안 및 공급망(Security and Supply Chain)**을 사용하세요. 그런 다음 귀하의 롤백, 소유권, 데이터 보존 요구 사항을 충족하는 가장 작은 도구 세트를 비교합니다.
큐레이션 원칙
- 항목은 간결하고, 효율적이며, 정확하고, 관련성이 높게 유지합니다.
- 신뢰할 수 있는 프로젝트 저장소가 존재하는 경우 GitHub 링크를 선호합니다.
- 입증되었고, 신뢰할 수 있으며, 고품질의 프로젝트만 포함합니다.
- 중복되거나 동등한 항목으로 이미 다루어진 프로젝트는 무시합니다.
- 유용할 때 카테고리를 추가하거나 개선하지만, 관련 없는 내용은 피합니다.
- 데모, 포기된 실험 또는 벤더 전용 마케팅 페이지보다는 프로덕션급 오픈 소스를 선호합니다.
성장 및 기여
이 프로젝트는 현대적인 X-Ops를 위한 실용적인 오픈 소스 맵이 되는 것을 목표로 합니다. 목록을 링크 더미(link dump)로 만들지 않는 한, 정확성, 커버리지 또는 탐색성을 향상시키는 기여는 환영합니다.
LLM 및 에이전트 관측 가능성
프로덕션 환경에서 LLM, RAG 및 에이전트 애플리케이션을 추적, 평가, 디버깅 및 운영하기 위한 도구.
선택 가이드라인: 트레이스를 프롬프트, 모델 버전, 평가 결과, 비용 또는 지연 시간 신호에 연결하는 도구를 선호하세요. RAG의 경우, 취약한 정답 세트(golden-answer sets)를 요구하지 않으면서 검색 및 답변 품질을 측정하는 평가 워크플로우가 좋습니다. 관측 가능성(observability)이 주요 운영 목적이 아닌 경우에는 게이트웨이, 보안, 서빙 도구를 해당 전용 섹션에서 사용하세요. 에이전트별 도구링의 경우, 대시보드가 존재하는 것뿐만 아니라 도구 호출(tool calls), 상태 전환(state transitions), 실패, 및 작업자 행동(operator actions)이 검사 가능하게 유지되는지 확인해야 합니다.
운영 환경 체크리스트: 도구를 채택하기 전에 OpenTelemetry 또는 내보내기 가능한 트레이스 형식을, 보존 및 마스킹 제어(retention and redaction controls), 재현 가능한 평가 실행(reproducible evaluation runs), 프레임워크 커버리지, 그리고 경고(alert)에서 근본적인 프롬프트, 도구 호출, 모델, 비용까지의 명확한 경로를 확인하세요. 실패 증거가 없는 대시보드는 그저 매우 화려한 어깨 으쓱거림일 뿐입니다.
회귀 방지 게이트: CI에 작고 버전이 지정된 평가 세트를 유지하고, 검색 및 답변 품질 지표를 개별적으로 비교하며, 프롬프트, 모델, 리트리버(retrievers), 또는 게이트웨이 정책을 변경하기 전에 롤백 임계값(rollback thresholds)을 정의하세요. “데모에서 보기 좋았다”는 출시 전략이 아닙니다.
평가 운영(EvalOps) 선택 가이드라인: 검색, 생성, 도구 사용, 안전성, 지연 시간, 비용 신호를 분리하는 평가 도구를 선호하세요. 고정된 데이터 세트와 샘플링된 프로덕션 트레이스를 모두 지원하고, CI 또는 출시 게이트를 위해 기계가 읽을 수 있는 결과(machine-readable results)를 내보내는 것이 좋습니다. LLM-as-a-judge는 유용한 증거일 뿐 근본적인 진실(ground truth)이 아닙니다. 판단 모델과 루브릭(rubric)을 고정하고, 인간 검토 샘플을 사용하며, 실패 사례가 재현 가능하도록 유지하세요.
운영 증거 체크리스트: 프로덕션 배포를 위해서는 추적(trace) 및 평가 스키마, 샘플링 및 PII-삭제 정책, 각 경고에 대한 소유자, 보존 및 재생 제한, 그리고 롤백 트리거를 기록해야 합니다. 코딩 에이전트나 기타 불투명한(opaque) 런타임의 경우, SDK 계측(instrumentation)이 누락되었을 때도 실패가 진단 가능하도록 애플리케이션 추적에 프로세스, 네트워크 및 리소스 신호를 결합해야 합니다. 만약 어떤 도구가 다른 시스템에서 검사할 수 있는 증거를 내보낼 수 없다면, 그것은 단순히 빠진 체크박스가 아니라 통합 위험(integration risk)입니다.
게이트웨이 경계: 라우팅, 속도 제한(rate limits), 예산(budgets), 재시도(retries), 그리고 제공업체 장애 조치(provider failover)를 게이트웨이 관련 문제로 취급하고, 추적, 평가, 프롬프트 또는 응답 분석은 해당 도구의 주요 운영 목적일 때만 여기에 유지해야 합니다. 이렇게 함으로써 하나의 게이트웨이를 여러 가지 역할을 하는 세 개의 관측 가능성 플랫폼으로 계산하는 것을 방지할 수 있습니다.
게이트웨이 선택 가이드라인: 제공업체 추상화, 라우팅 정책, 할당량(quotas), 재시도, 감사 가능성을 포괄하는 가장 작은 제어 표면적(control surface)을 선택해야 합니다. 프로덕션 배포 전에 스트리밍 동작, 타임아웃 및 폴백 의미론(semantics), 테넌트 격리, 비밀 순환(secret rotation), 비용 귀속(cost attribution), 그리고 상위 제공업체가 저하되었을 때도 유용하게 유지되는 메트릭 또는 추적을 검증해야 합니다.
