모니터링 데이터에 온톨로지를 올린다는 게 구체적으로 뭘까?
대시보드만 보고 있었습니다
서버 상태 모니터링은 하고 있거든요. server_id, timestamp, cpu_usage, memory_usage, status 같은 메트릭이 쌓이고 있고, 대시보드에서 그래프로 보고 있습니다.
그런데 문제가 생기면 사람이 전부 합니다. 대시보드에서 이상 수치를 발견하면 슬랙에 직접 올리고, 로그를 뒤져서 원인을 추적하고, 영향받는 서비스를 머릿속으로 파악하고, 장애 보고서를 수동으로 작성합니다. 대시보드는 "지금 상태"를 보여줄 뿐이고, "무슨 일이 생겼고, 어디에 영향이 있고, 어떻게 대응해야 하는지"는 사람이 매번 조립하는 거예요.
이전 글에서 팔란티어 온톨로지의 3개 층을 정리했거든요. 시맨틱(명사), 키네틱(동사), 다이나믹(가정법). 대시보드만 있는 지금 상태는 시맨틱 레이어의 일부만 쓰고 있는 셈입니다. 데이터는 있는데 의미가 없고, 의미가 있어도 행동이 연결되지 않은 거예요.
"추출"이 아니라 "매핑"입니다
지금까지 해온 도메인 온톨로지와 접근이 근본적으로 다릅니다. 이메일에서 엔티티를 뽑을 때는 LLM이 비정형 텍스트를 분석해서 "이게 서버다", "이게 담당자다"를 판단했거든요. 데이터가 없는 데서 데이터를 만들어내는 과정이었습니다.
모니터링 데이터는 반대예요. 테이블이 이미 있고, 컬럼이 이미 있고, 값이 이미 들어있습니다. 여기서 할 일은 추출이 아니라 매핑이에요. "이 테이블의 한 row가 하나의 서버 객체다", "이 컬럼이 서버의 CPU 사용률 속성이다"라고 선언하는 거예요.
도메인 온톨로지 (지금까지) | 모니터링 온톨로지 (이번에) | |
|---|---|---|
데이터 소스 | 비정형 (이메일, 문서) | 정형 (메트릭 테이블, 로그) |
핵심 작업 | LLM으로 엔티티 추출 | 기존 컬럼을 속성에 매핑 |
LLM 역할 | 추출기 | 거의 불필요 (매핑은 규칙 기반) |
결과물 | 새로 만든 지식그래프 | 기존 데이터 위의 의미 계층 |
LLM이 거의 필요 없다는 게 처음에 이상하게 느껴졌거든요. 지금까지 온톨로지 작업의 핵심이 LLM 추출이었으니까요. 그런데 이미 구조화된 데이터에 LLM을 돌리면 비용만 나가고 가치가 없습니다. 정형 데이터에서 온톨로지를 올리는 건 설계의 문제지 추출의 문제가 아니었어요.
시맨틱 레이어 — 모니터링 데이터에 이름을 붙이면
구체적으로 어떤 모습인지 그려봤습니다.
서버 메트릭 테이블이 있다고 하면, 여기서 Object Type을 정의할 수 있어요.
테이블: server_metrics
컬럼: server_id, timestamp, cpu_usage, memory_usage, disk_usage, status
→ Object Type: Server
→ Property: cpu_usage → "CPU 사용률"
→ Property: memory_usage → "메모리 사용률"
→ Property: status → "서버 상태"이게 끝이면 대시보드랑 다를 게 없습니다. 핵심은 기존 지식그래프와 연결하는 것이에요.
Neo4j에는 이미 서버, 서비스, 담당팀 노드가 있고, "서버가 서비스를 운영한다", "서비스에 담당팀이 있다" 같은 관계가 정의돼 있거든요. 모니터링 데이터의 server_id가 지식그래프의 서버 노드와 같은 객체라고 매핑하면, 메트릭 데이터가 자동으로 그래프 맥락을 갖게 됩니다.
물류서버-A의 CPU가 95%라는 사실만으로는 "경고"가 전부예요. 그런데 지식그래프를 통해 "물류서버-A → 주문처리서비스 → 결제연동서비스"라는 연결이 보이면, "이 서버가 죽으면 주문이 멈추고 결제도 멈춘다"는 맥락이 붙습니다. 대시보드에서 빨간 그래프를 보는 것과, 영향 범위를 아는 것은 완전히 다르거든요.
장애 로그는 형태가 없다는 게 오히려 기회입니다
장애 이력은 지금 구조화된 형태가 없어요. 장애가 나면 로그를 뒤지고, 원인을 추적하고, 슬랙에 올리고, 보고서를 쓰는데 이 모든 과정이 사람의 머릿속과 메신저 안에서 일어납니다.
이걸 온톨로지로 정의하면 이런 모습이 될 수 있어요.
Object Type: Incident (장애)
Property: 발생시간, 감지경로, 증상, 원인, 해결시간, 심각도
Link: 영향받은 서비스 → Service
Link: 원인 서버 → Server
Link: 대응 담당자 → Person지금은 장애가 발생하면 사람이 이 정보를 수동으로 조립합니다. 그런데 Incident라는 Object Type이 정의되어 있으면, 장애 발생 시 자동으로 틀이 만들어지거든요. "이 서버에서 발생, 이 서비스에 영향, 이 팀이 담당" 같은 기본 정보는 지식그래프의 관계를 따라가면 채워집니다. 사람은 원인과 해결 과정만 입력하면 돼요.
장애 이력이 구조화되면 축적이 되기 시작합니다. "이 서버에서 최근 3개월간 장애가 몇 번 났는지", "이 서비스가 영향받은 장애 패턴이 뭔지"를 그래프 쿼리로 바로 뽑을 수 있게 되는 거예요.
키네틱 레이어 — 대시보드에서 운영 시스템으로
시맨틱 레이어만 올리면 "더 똑똑한 대시보드"에서 끝납니다. 진짜 변화는 키네틱 레이어를 붙일 때 생겨요. 이전 글에서 정리한 "동사"를 모니터링에 적용하면 이런 흐름이 됩니다.
1. 감지 — 서버 메트릭 임계치 초과 감지
2. 알림 — 슬랙/문자로 담당팀에 자동 알림
3. 진단 — 지식그래프에서 영향 서비스 자동 파악
4. 분석 — 과거 유사 장애 패턴 조회
5. 대응안 — LLM이 그래프 맥락 기반 복구 플랜 초안 생성
6. 보고서 — 장애 보고서 초안 자동 작성
7. 확인 — 사람이 검토하고 최종 등록지금은 1~6을 전부 사람이 합니다. 온톨로지가 있으면 1~4는 자동화가 가능하고, 5~6은 LLM이 초안을 만들어서 사람이 검토만 하는 구조로 바뀝니다.
핵심은 각 단계가 온톨로지의 관계를 따라간다는 점이에요. "이 서버가 운영하는 서비스"는 Link로 정의돼 있고, "이 서비스의 담당팀"도 Link로 정의돼 있으니까, 알림 대상을 찾는 것도 그래프 쿼리 한 번이면 됩니다. 사람이 머릿속으로 "이 서버는... 주문 서비스가 돌아가고 있으니까... 담당은... 물류팀이니까..."를 떠올리는 과정을 온톨로지가 대체하는 거예요.
아직 안 해본 이유, 그리고 다음 순서
솔직히 모니터링 온톨로지는 아직 구현 전이에요. 지금까지는 이메일과 문서 기반의 도메인 온톨로지에 집중하고 있었거든요. 그쪽이 먼저 안정화돼야 모니터링까지 확장할 수 있으니까요.
그런데 이번에 팔란티어 문서를 뜯어보면서 설계 방향은 잡혔습니다. 정리하면 순서는 이렇습니다.
첫 번째, 서버 메트릭 테이블의 server_id를 기존 지식그래프의 서버 노드에 매핑합니다. 이것만으로도 메트릭 데이터에 그래프 맥락이 붙거든요.
두 번째, Incident Object Type을 정의해서 장애 이력을 구조화합니다. 발생 시 그래프 관계를 따라 영향 범위와 담당자를 자동으로 채우는 구조예요.
세 번째, 알림→진단→보고서 초안까지의 액션을 키네틱 레이어로 정의합니다. 이건 Action Registry를 확장하는 방향이에요.
도메인 온톨로지에서는 "데이터가 없어서 추출이 어렵다"가 문제였는데, 모니터링 온톨로지에서는 "데이터는 있는데 연결이 없다"가 문제입니다. 해결해야 할 과제의 성격이 완전히 다르고, 그래서 접근 방식도 달라야 했습니다.
