OSIRIS, 벤더 중립적인 JSON 형식 인프라 스냅샷 (IT/OT)

Source: Dev.to

반복되는 문제

인프라 데이터를 기반으로 도구를 만들려고 시도해 본 적이 있다면(다이어그램, 인벤토리, 감사, 드리프트/디프, 문서화 등) 다음과 같은 문제들을 겪었을 가능성이 높습니다:

• 모든 벤더가 데이터를 서로 다르게 내보냅니다(심지어 JSON이라 해도).
• 모든 도구가 자체 파서와 매핑을 작성하게 되며, 대부분은 폐쇄형 소스입니다.
• 관계(무엇이 무엇에 연결되는지, 어디에 존재하는지, 어떻게 의존하는지)가 가장 먼저 일관성을 잃거나 암시적으로 처리됩니다.
• 시간이 지나면서 통합을 반복해서 다시 만들거나, 사람들의 머릿속에만 존재하는 문서화되지 않은 트리벌 지식에 의존하게 되고, 무한한 질문에 대한 모호한 답변만 남게 됩니다.

그 결과, 유지 보수가 비용이 많이 들고 인프라의 단일 시각을 얻기 어려운 파편화된, 도구‑특정 파이프라인이 생깁니다.

OSIRIS란

OSIRIS는 이기종 IT 및 OT 환경 전반에 걸친 인프라 자원과 그 위상 관계를 기술하기 위한 벤더 중립적인 JSON 포맷입니다. 정적인 스냅샷 교환 포맷을 생성합니다.

스냅샷은 다음을 설명합니다:

• 무엇이 존재하는가(resources)
• 그것이 어떻게 연결되는가(connections / relationships)
• 특정 시점에(point‑in‑time)

OSIRIS는 다음을 목표로 설계되었습니다:

• 벤더 중립(스키마가 계약)
• 도구 친화적(소비자는 벤더‑특정 파서를 필요로 하지 않음)
• 확장 가능(벤더 또는 도메인‑특정 필드를 위한 네임스페이스 확장, OT 포함)

OSIRIS가 아닌 것 (v1.0.0 기준)

OSIRIS는 다음이 아닙니다:

• Infrastructure‑as‑Code
• Configuration management
• Telemetry / metrics / streaming events

이는 내보내고, 검증하고, 저장하고, 차이점을 비교하고, 소비할 수 있는 포맷입니다.

Producer / Consumer 분리 (핵심 아이디어)

모든 도구가 모든 벤더 포맷을 구현하는 대신, OSIRIS는 책임을 다음과 같이 분리합니다:

• Producer는 소스 데이터를 OSIRIS 문서로 변환합니다(예: 하이퍼스케일러 또는 퍼블릭 클라우드 제공자 인벤토리 API, 네트워크 장비 출력, OT 게이트웨이, CMDB 내보내기).
• Consumer는 OSIRIS 문서를 읽습니다(예: 다이어그램 생성기, 인벤토리 플랫폼, 감사 도구, 디프 툴, 문서화 시스템).

이렇게 하면 벤더‑특정 로직이 한 곳에 모이고, 여러 도구가 동일한 스냅샷 포맷을 공유할 수 있습니다.

현재 포함된 내용

• Specification & documentation:
• Canonical core JSON Schema (v1.0):
• Examples:
• 스키마 수준 검증으로 시작하고, 이후에 더 풍부한 의미론적 검증을 추가할 수 있는 검증 접근 방식.

피드백 받고 싶은 부분

인프라 데이터를 다루는 분이라면 다음에 대한 의견을 주시면 감사하겠습니다:

1. Core model: “resources + relationships”가 실제 토폴로지를 충분히 표현하고 사용하기 편리한가요?
2. Extensibility: 확장/네임스페이스 접근 방식이 실용적이며 미래에도 견고한가요?
3. Adoption path: 첫 번째 Producer로 가장 유용할 것 같은 대상은 무엇인가요(클라우드 인벤토리, 장비 CLI, Terraform state 등)?

앞으로의 계획

• 기여자를 위한 개발 가이드라인
• Producer와 Consumer를 쉽게 만들 수 있도록 하는 핵심/SDK 작업 초기화

스펙/스키마를 검토하거나 첫 번째 Producer 목표를 제안하고 싶다면 댓글을 남겨 주세요.

OSIRIS: