온톨로지 기반 관측성: Netflix 규모의 엔드투엔드 지식 그래프 구축
TMT2024년 11월 Jake Paul과 Mike Tyson이 링에 올랐을 때, 저희는 약 6,500만 개의 동시 스트림으로 그 경기를 전송했습니다. 평범한 하루에도 저희 인프라는 20억 건이 넘는 요청을 받고, 매초 3,800만 건이 넘는 실시간 로깅 이벤트를 처리합니다. 이 정도 규모가 되면 전체 그림이 엔지니어링 팀 하나의 머릿속에도, 대시보드 하나에도 다 담기지 않습니다. 라이브 콘텐츠, 팟캐스트, 실시간 스트림이 늘어나면서, 좋은 사용자 경험을 제공하려면 시스템을 최대한 빨리 이해하고 갱신하는 일이 반드시 필요해졌습니다. 이런 규모에서, 그리고 저희에게 주어진 시간 제약 안에서 시스템을 이해하는 일은 눈을 가린 채 어두운 정글 속 건초 더미에서 바늘을 찾는 것처럼 막막한 작업이 되기 일쑤입니다.
이 글은 그 바늘을 찾는 이야기입니다.
수정까지 걸리는 네 시간
어느 주에나 볼 법한 회귀(regression)를 하나 예로 들어 보겠습니다. 영화 목록이 여러 줄로 늘어선 홈 화면의 렌더링 시간이 약 1.5초 늘어나기 시작합니다. 알림이 울립니다. 그러면 저희는 무엇이 이 문제를 일으켰고 어떻게 고쳐야 할지 찾아 나섭니다.
공교롭게도 애플리케이션의 회귀는 시스템의 어느 곳과도 관련될 수 있습니다. 새 버전 배포나 A/B 테스트 롤아웃으로 인한 클라이언트 앱의 회귀, 인프라의 로드 셰딩(load shedding), 6홉 떨어진 하위 서비스의 롤아웃 때문에 잘못된 데이터를 돌려주는 GraphQL 쿼리까지, 이 시점에서는 모두 용의자입니다. 그래서 무엇이 문제를 일으켰는지 답하려면 시스템 전반에서 단서를 모아야 하고, 여러 계층의 데이터를 꼼꼼히 훑어야 합니다.
MELT 계층
“무엇이 문제를 일으켰을까?”
메트릭, 이벤트, 로그, 트레이스, 업계에서 줄여 부르는 말로 MELT는 이런 조사에 딱 맞는 원재료이며, 각각이 질문의 대략 4분의 1에 답합니다. 저희는 이 네 가지 축에 걸쳐 관측 데이터를 수집하고, 이를 하나의 관측 데이터 계층으로 통합합니다. 덕분에 사용자가 무엇을 경험하는지, 애플리케이션이 어떻게 동작하는지, 백엔드 인프라와 서비스가 무엇을 처리하고 어떻게 응답하는지를 아울러 시스템을 실시간으로 관측할 수 있습니다.
MELT(메트릭, 이벤트, 로그, 트레이스)와, 각각이 시스템 전반에서 수집되는 방식입니다.
이어지는 조사는 계층마다 다음과 같은 모습일 수 있습니다.
MELT의 각 계층이 알려 주는 것과 빠뜨리는 것입니다.
조사 타임라인
그렇다면 문제를 조사하고, 근본 원인을 알아내고, 고쳐서 사용자가 더는 이 문제를 겪지 않게 하기까지 얼마나 걸릴까요?
약 4시간이 걸리는 조사의 타임라인입니다.
저희가 고른 예에서는 네 시간이 걸렸습니다. 그중 어려운 계산에 들어간 시간은 거의 없었습니다. 대부분은 관계를 다시 짜 맞추는 데 들어갔습니다. 관측 시스템은 이미 알고 있었지만, 사람이나 기계가 그냥 읽고 찾아낼 수 있는 곳에 저희가 한 번도 적어 둔 적이 없는 관계였습니다.
그 밑에 깔린 불일치
2023년 무렵이었다면 여기서 본능적으로 데이터를 더 모으거나 대시보드를 개선하려 했을 것입니다. 둘 다 조금은 도움이 되지만, 어느 쪽도 이런 조사를 느리게 만드는 원인을 해결하지는 못합니다.
지금은 2026년이니 “에이전트를 쓰면 되지” 하고 말할 수도 있습니다. 하지만 올바른 맥락을 에이전트에게 전달하지 않으면 AI 시스템은 환각을 일으킵니다. 특히 팀이 온콜 중이라 “지금 당장” 고쳐야 할 때, 부정확한 에이전트 분석 때문에 엉뚱한 길로 빠질 수는 없습니다. 아무 바늘이 아니라 정확한 바늘이 필요합니다.
저희 시스템은 각각 내부적으로는 일관되지만 외부와는 단절되어 있습니다. 텔레메트리 플랫폼인 Atlas는 애플리케이션과 그 시계열 데이터를 압니다. 알림 시스템인 Radar는 임계값과 알림 발생 이력을 압니다. incident.io는 심각도와 대응자를 압니다. PagerDuty는 온콜 순번을 압니다. Spinnaker는 무엇이 언제 배포됐는지 압니다. 그리고 Slack 기록은, 어떤 쿼리 엔진도 닿을 수 없는 형태로, 지난 분기에 아주 비슷한 문제를 어느 엔지니어가 해결했고 무엇을 찾아냈는지 알고 있습니다.
문제는 이 시스템들이 무엇을 가리켜 말하는지에 대해 서로 합의하지 않는다는 점입니다. 한 시스템에서 애플리케이션인 것이 두 번째 시스템에서는 서비스이고 세 번째 시스템에서는 클러스터입니다. 이름도 접미사 하나, 대소문자 규칙, 또는 몇 사람만 기억하는 이름 변경 때문에 서로 다릅니다(SME라고 하면 누군지 감이 오시죠?). 이 시스템들을 가로질러 정보를 연결하려면 그 매핑을 머릿속에 담고 있는 사람이 필요하고, 그 사람이 이런 교차 도메인 조사의 병목이 됩니다. 엔드투엔드 관측성의 어려운 부분은 아마 데이터 모델링 문제로 이해하는 편이 더 정확할 것입니다.
저희에게 없었던 것은 저희 운영 세계에 존재하는 엔터티에 대해, 기계가 읽을 수 있는 형태로 명시한 합의였습니다.
온톨로지
이 합의에는 이름이 있습니다. 바로 온톨로지입니다. 온톨로지는 타입과 그 타입이 지니는 속성, 그리고 타입 사이에 맺을 수 있는 관계를 형식적으로 정의한 명세입니다. 온톨로지의 단위는 트리플로, 사실 하나를 주어, 술어, 목적어로 표현합니다. 다음 예시 트리플을 보겠습니다.
api-gateway rdf:type ops:Application .
api-gateway ops:ownedBy "Team Bedrock" .
api-gateway ops:deployedIn "us-east-1" .
INC-5377 rdf:type ops:Incident .
INC-5377 ops:affects api-gateway .
INC-5377 ops:severity "SEV 2" .이 예시에서는 이미 사실 여섯 개를 인코딩했고, 예전에는 도구 세 개에 걸쳐 있던 질문에 쿼리 한 번으로 답할 수 있습니다.
“us-east-1에서 Team Bedrock이 소유한 애플리케이션에 영향을 준 인시던트는 무엇인가?” 같은 질문도 인시던트 기록, Spinnaker, Radar를 각각 찾아볼 필요 없이 쿼리 한 번이면 됩니다.
저희는 이 온톨로지 계층을 관측성 온톨로지(Observability Ontology)라고 부릅니다. 관측성 온톨로지는 애플리케이션, 서비스, 인시던트, 배포 같은 엔터티를 여러 시스템이 같은 방식으로 이해하도록 표준화하는 스키마이자 규칙 모음이자 공통 합의 역할을 합니다.
저희는 이를 위해 W3C 스택 위에 관측성 온톨로지를 구축했습니다. 데이터 모델에는 RDF, 온톨로지에는 OWL, 검증에는 SHACL, 쿼리에는 SPARQL을 씁니다. 이 표준들은 명세가 잘 갖춰져 있고 널리 구현되어 있어서, 모델을 여러 그래프 저장소로 옮겨 가며 쓸 수 있습니다.
온톨로지에서 나온 데이터 자체는 지식 그래프로 저장되며, 저희가 직접 만든 RDF 그래프 데이터베이스인 QuipuDB 에 영구 저장됩니다. QuipuDB는 Rust 기반 임베디드 키-값 DB인 redb를 바탕으로 만든 분산 쿼드 스토어입니다. 이곳의 데이터는 원시 텔레메트리, 로그, 인시던트 논의를 파싱해 트리플(주어-술어-목적어 형태의 사실)로 만든 것입니다.
수집할 때마다 보관용으로 전체 데이터를 Turtle 형식으로 직렬화한 파일도 만듭니다. 사람이 읽을 수 있고 diff로 비교하기도 좋아서, 예상보다 디버깅에 훨씬 유용했습니다.
저희 온톨로지는 열두 개의 네임스페이스로 구성되며, 네임스페이스마다 운영 도메인 하나를 맡습니다.
이 온톨로지를 만들면서 중요했던 결정이 두 가지 있어서 공유할 만합니다.
첫째, 저희는 범용 Service 타입을 두지 않았습니다. “서비스”라는 말은 저희 도구들 사이에서 네 가지 다른 뜻으로 쓰입니다. 그래서 애플리케이션은 정확히 하나의 타입인 ops:Application으로만 해석되며, 모든 애플리케이션은 엔터티가 생성되기 전에 약 4만 9천 개 항목이 있는 소프트웨어 카탈로그와 대조해 검증됩니다. 사용자 이름, 팀 이름, 네트워크 토폴로지에서 긁어 온 의존성 이름처럼 검증되지 않은 문자열은 절대 애플리케이션이 되지 않습니다. 또한 의존성 엣지 수에 양방향 모두 상한을 둡니다. 인기 있는 서비스 하나에 역의존성이 수천 개 달릴 수 있어서, 상한이 없으면 그 서비스가 그래프를 장악하기 때문입니다.
두 번째 결정은 무엇을 모델링할지에 관한 것입니다. 인시던트 채팅에는 인시던트 이면의 추론이 담겨 있습니다. 시도했다가 버린 가설, 효과가 있었던 완화 조치, 누가 왜 알고 있었는지가 모두 인시던트 Slack 채널에 맥락으로 남아 있는데, 채널이 조용해지면 그 지식은 증발해 버립니다. 그래서 메시지 200개, 참여자 50명, 관련 서비스 15개짜리 인시던트 채널을 하나의 구조로 바꿉니다. 인시던트가 벌어지는 동안의 운영상 혼돈을 질서 정연한 트리플로 변환하는 것입니다.
비결정성에서 결정성 만들어 내기
이 그래프를 만들려면 본질적으로 확률적인 도구를 써야 합니다. LLM은 논의를 요약합니다. 퍼지 매칭은 서비스 이름을 해석합니다. 확률 기반 엔진은 인과 사슬을 제안합니다. 이 중 어느 것도 같은 출력을 두 번 확실하게 내놓지 않지만, 저희 시스템의 끝에서 나오는 결과는 SPARQL 쿼리에 매번 똑같이 답하는 결정적인 그래프입니다.
온톨로지는 파이프라인 방식을 통해 이 결정성을 만들어 내는 메커니즘입니다. 저희는 이 파이프라인을 엔트로피를 낮춰 가는 사다리로 생각합니다. 여기서 엔트로피란 아직 비정형 상태에 갇혀 있는 정보의 비율을 뜻합니다. 예를 들어 이 파이프라인의 시작 지점에서 LLM은 무슨 말이든 할 수 있지만, 타입 시스템을 어기는 트리플은 내보낼 수 없습니다. 출력 공간을 충분히 좁게 제한하면, 확률적인 과정에서도 결정적인 계약이 나옵니다.
# 모델은 어떤 문장이든 만들 수 있지만, 출력은 반드시 아래 술어에 맞아야 합니다:
category IN ["incident", "question", "discussion", "decision"]
sentiment IN ["positive", "neutral", "negative", "urgent"]
# 결과: 결정적인 트리플
thread:123 slack:category "incident" .
thread:123 slack:isIncidentRelated "true"^^xsd:boolean .이 사다리를 내려가게 해 주는 계층은 다섯 개입니다. 사다리의 각 단계는 하나만 떼어 보면 비결정적입니다. 하지만 전체를 합치면 이 사슬은 결정적이 됩니다. 이렇게 뒤집히는 것이 비결의 전부입니다. 각 계층은 아래와 같습니다.
비결정성에서 결정성을 만들어 내는 다섯 계층입니다.
인리처: 엔트로피를 줄이는 에이전트
저희는 지식 그래프 전반에서 엔트로피를 줄이기 위해 인리처(enricher)라고 부르는 것을 사용합니다. 그래프 위에서 수십 개의 인리처가 돌아갑니다. 각 인리처는 노이즈가 섞인 입력을 받아 타입이 지정된 트리플을 내보내고, 앞선 인리처가 기록한 내용을 읽습니다. 인리처의 계약은 일부러 좁게 잡았습니다.
class Enricher:
async def _enrich_async(self, ...):
raw = await self.fetch(...) # 1. 노이즈가 섞인 입력 읽기
result = self.analyze(raw) # 2. 처리 (확률적일 수 있음)
graph.add((uri, RDF.type, OPS.X)) # 3. 타입이 지정된 트리플 내보내기
graph.add((uri, OPS.pred, Literal(result.value)))
return EnrichmentResult(success=True, triples_added=count)모든 인리처에 공통으로 적용되는 불변 조건은 세 가지입니다.
- 모든 엔터티는 rdf:type을 가집니다.
- 모든 URI는 하나의 명명 규칙을 따릅니다.
- 모든 ops:Application은 카탈로그를 통과해야 만들어집니다.
여기서 짚어 둘 만한 운영상의 선택도 두 가지 있습니다. 보강 파이프라인은 순차적으로 실행됩니다. 그래프를 불러오고, 트리플을 추가하고, 저장하는 순서입니다.
이렇게 순서대로 처리하면 경쟁 조건 한 부류가 통째로 사라지며, 그 대가로 늘어나는 실제 소요 시간은 기꺼이 감수할 만합니다. 그리고 메트릭, 로그, 이벤트 같은 외부 시스템 호출은 최선 노력(best-effort) 방식으로 처리할 수 있습니다. 그래서 하위 API가 느리더라도 결과가 다소 부실해질 뿐 그래프 수집이 막히지는 않습니다. 이를 위해 저희는 이 개별 시스템들을 메트릭 온톨로지(Metrics Ontology), 알림 온톨로지(Alerts Ontology)처럼 온톨로지로 옮기는 작업도 하고 있습니다. 그러면 모든 것을 온톨로지 자체에서 쿼리할 수 있게 됩니다.
상관관계 엔진: 상관 사슬 찾기
상관관계 엔진(Correlation Engine)은 다양한 입력 소스에서 들어오는 방대한 신호를 받아들여, 인과 관계나 상관관계로 이어진 이벤트 사슬로 압축합니다. 현재 이 엔진은 로그 오류, 메트릭 이상, 느리거나 실패한 트레이스, 알림, 인시던트, 배포, 설정 변경, 실험, 오토스케일링, 커밋, 엔드투엔드 병목, 오류 패턴을 포함해 열세 가지 신호 유형을 읽습니다. 그런 다음 이 신호들 사이의 경로를 탐색합니다. 일부 순서쌍은 인과 관계가 있다고 알려져 있어 높은 사전 가중치를 받습니다. 예를 들어 로그 오류보다 먼저 일어난 배포, 메트릭 이상보다 먼저 일어난 설정 변경, 인시던트보다 먼저 일어난 트레이스 실패 같은 것입니다. 그 밖에 높은 상관관계를 보이는 쌍은 상관 사슬로 봅니다. 이런 사슬은 10분 창 안에서 시간적 근접성과 심각도를 기준으로 점수를 매기며, 신뢰도가 0.6 미만인 것은 버립니다.
상관관계 엔진입니다.
여기서 엔진의 역할은 결론을 내리는 것이 아니라 증거와 함께 가설을 제안하는 것입니다. 그래서 엔진은 사슬을 저장할 때 그 사슬을 만드는 데 쓰인 그래프 레코드도 함께 저장합니다.
위 예시에서 신뢰도 0.87인 사슬은 사람이나 에이전트가 확인해 볼 만한 강력한 가설입니다. 그래프는 주장과 함께 신뢰도를 기록합니다. 그래서 그래프를 쓰는 쪽은 사슬이 왜 그런 모양인지 이해하고, 선택지를 저울질해 결정을 내릴 수 있습니다.
지식 플라이휠
수집 주기마다 같은 네 단계가 돌아가고, 한 바퀴 돌 때마다 그래프는 다음 바퀴를 위해 더 풍부해집니다. 이것이 지식 플라이휠(Knowledge Flywheel)이며, 지식 그래프에 저장된 시스템 맥락을 끊임없이 보강하고 개선합니다.
지식 플라이휠입니다.
관측(Observe) 단계는 신호를 수집합니다. 보강(Enrich) 단계는 타입이 지정된 트리플을 추가합니다. 추론(Infer) 단계는 원시 데이터에서는 보이지 않는 패턴을 찾습니다. 적응(Adapt) 단계는 지식을 다시 되먹여, 확립된 패턴이 탐지 규칙이 되게 합니다. 네 단계가 복리처럼 쌓인 결과, 시스템은 스스로 개선됩니다. 한 인시던트에서 발견한 인과 사슬은 다음 인시던트에서 이미 아는 패턴이 되고, 온톨로지는 점차 스키마에 머물지 않고 기억이 되어 갑니다.
위 예시를 보겠습니다. 타임아웃 때문에 api-gateway에서 발생한 인시던트를 처음 보고 해결하면, 저희는 이 지식을 온톨로지 항목으로 변환합니다. 이것이 인코딩된 지식이 됩니다. 이렇게 인코딩하는 주기를 여러 번 거치면 그래프는 패턴을 학습하기 시작합니다. N번의 주기가 지나면 패턴은 지혜가 됩니다. “SEV-2의 40%는 api-gateway 배포에서 비롯된다”, “api-gateway 배포 문제의 30%는 연결 타임아웃에서 나온다” 같은 것입니다. 이를 인사이트로 드러내면, 새 인시던트에 빠르게 대응하는 데 그치지 않고 인시던트 자체를 선제적으로 줄여 나갈 수 있습니다.
그래프 활용하기
그래프 위에는 저희 사내 에이전틱 AI 솔루션인 AutoRCA가 있습니다. AutoRCA는 하나의 질문을 중심으로 협업하는 전문 에이전트 여러 개로 이뤄져 있습니다. 이 글 첫머리의 홈 화면 회귀 사례를 따라가 보면, 이 에이전트 시스템의 추론 사슬은 대략 이런 모습일 것입니다.
입력별로 특화된 각 에이전트는 해당 도메인을 깊이 이해하는 사람들이 만듭니다. 이런 분업은 전문 에이전트들이 소통 방식을 미리 합의하거나 서로의 존재를 알지 않아도 발견한 내용을 주고받을 수 있을 때만 가능합니다. 온톨로지가 그 인터페이스 역할을 합니다. 각 전문 에이전트는 어휘 하나, 즉 그래프의 어휘만 익히면 됩니다. 트레이스 활용에 특화된 사용 사례를 작성하는 팀은 발견한 내용을 어떤 ops:Application에 관한 트리플로 기록하고, 로그 전문 에이전트는 같은 ops:Application에 관한 트리플을 읽습니다. 어느 쪽도 상대가 있다는 사실을 알 필요가 없습니다. 새로 합류한 전문 에이전트도 같은 어휘를 한 번만 익히면, 다른 여섯 에이전트가 기록한 모든 내용을 곧바로 읽을 수 있습니다.
처음에 소개한 조사와 비교하면, 달라진 점은 생각보다 좁습니다. 알림은 여전히 오후 3시 30분에 울리고, 엔지니어는 여전히 증거를 저울질해야 하며, 수정 코드는 여전히 그 코드를 이해하는 누군가가 작성해야 합니다. 달라진 것은 예전에 맥락을 짜 맞추는 데 들던 한두 시간입니다. 담당 팀을 찾고, 무엇이 배포됐는지 재구성하고, 시스템 여러 곳의 정보를 서로 연관 짓고, 지난 분기에 비슷한 일이 있었다는 걸 떠올리는 일 전부를 이제 온톨로지와 그래프가 떠맡습니다. 아직 초기 단계라 순위가 매겨진 가설이 틀릴 때도 있고, 그래서 가설마다 그것을 만들어 낸 증거를 함께 붙여 둡니다. 하지만 이제 엔지니어는 조사를 시작하는 순간, 예전에는 오후 반나절을 들여야 짜 맞출 수 있던 그림을 이미 손에 쥐고 있습니다.
이런 시스템을 직접 만들고 싶다면
저희가 만든 것 중 상당 부분은 먼저 잘못 만들어 보고서야 배웠습니다. 이 경험을 바탕으로, 다시 만든다면 가져갈 원칙은 다음과 같습니다.
- 무엇보다 먼저 식별 체계를 모델링하세요. 엔터티 종류마다 기준이 되는 카탈로그를 하나씩 정하고, 엔터티를 만들기 전에 그 카탈로그와 대조해 검증하세요.
- 온톨로지를 코드처럼 다루세요. 버전을 관리하고, 리뷰하고, 테스트하고, 변경은 풀 리퀘스트로 받으세요. 온톨로지를 코드로 다루면 에이전트 기반 개발과도 잘 맞고, 여러 팀이 규모를 키우며 기여할 수 있습니다.
- 개념과 인스턴스를 분리하세요. 개념은 사람의 시간 척도로 바뀌고 인스턴스는 끊임없이 바뀝니다. 둘을 뒤섞으면 어느 쪽도 발전시키기 어려워집니다.
- 개방형 표준 위에 구축하세요. RDF, OWL, SHACL, SPARQL은 명세가 있고, 여러 차례 구현되었으며, 다른 환경으로 옮기기 쉽습니다. 자체 그래프 모델을 쓰면 앞으로 그래프를 쓸 사용자가 하나의 구현에 묶이게 됩니다.
- 확률적인 도구를 타입 시스템으로 제약하세요. 저희가 가장 끝까지 지키고 싶은 원칙입니다. 모델은 결정성을 확보할 수 없는 곳에서 바로 쓸모가 있습니다. 출력 계약을 충분히 좁히면 모델의 출력을 쿼리 엔진이 믿고 쓸 수 있는 형태로 바꿀 수 있습니다.
- 보강은 최선 노력 방식으로, 순서대로 하세요. 느린 의존성은 기껏해야 그래프의 품질을 떨어뜨릴 뿐, 그래프를 막아서는 안 됩니다. 그리고 각 인리처가 앞선 인리처의 결과를 바탕으로 쌓아 가도록 순서를 정하면 정확도가 높아집니다. 속도를 얻는 병렬 처리를 포기할 만한 가치가 있습니다.
- 기계 텔레메트리와 함께 사람의 추론도 모델링하세요. 저희 그래프에서 가장 가치 있는 엣지는 논의에서 나왔습니다. 텔레메트리는 시스템이 무엇을 했는지 기록하고, 논의는 사람들이 무엇을 이해하고 해석했는지 기록합니다. 그 추론은 저장해 두었다가 필요할 때 지혜로 꺼내 쓸 가치가 더 큽니다.
- 최종 승인은 사람에게 맡기세요. 에이전트가 수정안, 인리처, 온톨로지 변경을 제안하게 하되, 모든 제안은 사람이 참여하는 리뷰 과정을 거치게 하세요.
다음 단계
이 그래프로 세 가지가 가능해집니다. 첫째는 자동 근본 원인 분석입니다. 회귀가 발생하면 그래프에 근거한 가설이 순위와 함께 따라옵니다. 다음은 자동 복구입니다. 진단의 신뢰도가 충분히 높으면, 대상을 좁힌 롤백, 트래픽 전환, 코드 변경 같은 조치를 함께 제안합니다. 그리고 궁극적으로는 스스로 치유하는 인프라입니다. 회원이 체감하기 전에 예측된 장애에 대응합니다.
이와 함께 저희는 관측성 온톨로지를 Netflix 통합 데이터 아키텍처(UDA)의 중심에 있는 도메인 모델링 언어인 Upper와 통합할 계획입니다. Upper를 쓰면 팀들은 비즈니스 도메인과 시스템 도메인을 서로 연결된, 기계가 읽을 수 있는 모델로 기술할 수 있습니다. 그리고 그 모델을 구체적인 스키마와 시스템으로 옮겨 펼칠 때도 의미와 제약 조건을 그대로 유지할 수 있습니다. 이 통합을 통해 애플리케이션, 알림, 배포, 인시던트 같은 운영 개념을 Netflix 전반에서 모델링된 더 넓은 도메인과 연결하고, 엔지니어와 에이전트에게 쿼리, 검증, 추론을 위한 공통 의미 계층을 제공하려 합니다. 먼저 Upper로 인시던트를 모델링하는 개념 증명(PoC)부터 시작하고, 거기서 배운 것을 바탕으로 두 시스템이 어디에서 합쳐져야 할지 정할 것입니다.
감사의 말
이 모든 것은 초기 단계의 시스템에 데이터와 전문 지식을 공유하고 인내심을 보여 준 팀들이 없었다면 존재하지 못했을 것입니다. 이 시스템의 수명 주기 극초기부터 이 일이 가능하도록 힘써 준 저희 팀원 Kaela Marsheck과 Aditya Gaur에게 특별히 감사드립니다. 또한 Netflix 온톨로지 워킹 그룹에서 함께한 Peter Royal과 Alex Hutter, 그리고 Upper와 도메인 모델링 전문 지식을 공유하고 관측성 온톨로지가 Netflix의 더 넓은 의미 기반의 일부가 될 방법을 함께 모색해 준 Alexandre Bertails와 통합 데이터 아키텍처(UDA)/Knowledge Foundations 팀 구성원들에게도 깊이 감사드립니다.