이번 시간에는 온톨로지가 무엇인지를 데이터 모델·택소노미·지식 그래프와의 비교로 배워가는 시간입니다. 온톨로지는 종류의 계층과 개체(서비스, 팀, 사람처럼 이름이 있는 하나하나의 대상) 사이의 관계를 적고, 그 관계가 무엇을 뜻하는지까지 적어서 기계가 계산하게 하는 방식이에요. 같은 운영 지식을 네 가지 방식으로 적어 본 다음, 정부가 공개한 장애 보고서 한 편을 읽으면서 설계를 어디서부터 시작하는지 따라가 볼게요.
판단의 근거를 AI 모델 밖에 적어 두는 이유
새벽에 통신사 회선이 느려졌을 때 어느 서비스가 영향을 받는지 AI 모델에게 물으면 그럴듯한 목록이 나오지만, 그 목록이 어떤 사실에서 나왔는지 알 수 없고 다음 날 같은 질문에 다른 목록이 나올 수도 있어요.
스키마(데이터를 어떤 구조로 적을지 정한 정의)를 고친 뒤 거쳐야 할 검사를 프롬프트에 "반드시 검사하라"고 적어 두어도, AI 모델이 지켰는지는 확률의 문제예요. "이 장애는 12시 45분에 복구됐다"는 답도 어느 문서의 어느 문단에서 나왔는지 말하지 못하면 근거가 없습니다.
세 경우 모두 판단의 근거가 AI 모델 안에만 있어요. 그래서 근거를 사실과 규칙으로 모델 바깥에 적어 두어야 하고, 온톨로지는 그렇게 적는 방법의 하나예요.
무대: 서비스 일곱 개를 운영하는 가상커머스
비교에 쓸 회사는 "가상커머스"라는 가상의 커머스 회사예요. 주문, 결제, 정산, PG 게이트웨이, 알림, 배송, 판매자 입점, 이렇게 서비스 일곱 개를 운영합니다.
결제팀에는 Mina와 Jun, 주문팀에는 Sora, 플랫폼팀에는 Theo가 있어요. 결제 서비스는 결제팀이 담당합니다.
서비스는 전부 가상커머스 전산센터에서 돌아가고, 전산센터는 KT 기업 인터넷 회선으로 나가요. 알림 서비스는 카카오톡 알림톡을 쓰고, 알림톡은 판교 데이터센터에서 돌아갑니다.
주문 서비스는 배송 서비스를 쓰고, 배송 서비스는 우체국 택배를 써요. 판매자 입점 서비스는 정부24를 씁니다. 우체국 택배와 정부24는 둘 다 국가정보자원관리원 대전센터에서 돌아가요.
이 지식으로 답할 질문은 두 개입니다.
- 첫째 질문: 결제 서비스를 담당하는 팀의 팀원은 누구인가?
- 둘째 질문: 국가정보자원관리원 대전센터가 멈추면 영향을 받는 우리 서비스는 무엇인가?
데이터 모델은 값을 저장한다
가장 익숙한 방식은 테이블이에요. 서비스 테이블에 담당 팀 번호를 두고, 사람 테이블에 소속 팀 번호를 두고, 의존 관계 테이블에는 서비스 번호와 의존 대상 번호를 둡니다.
첫째 질문은 서비스, 팀, 사람 테이블을 조인 두 번으로 이으면 답이 나와요.
둘째 질문은 어떨까요? 의존 관계 테이블에서 대전센터에 걸린 행을 찾으면 우체국 택배와 정부24가 나옵니다. 둘 다 외부 서비스라서 우리 서비스는 아직 나오지 않았어요.
우리 서비스를 찾으려면 그 결과를 의존 관계 테이블에 다시 조인해야 합니다. 그러면 배송 서비스와 판매자 입점 서비스가 나오고, 배송 서비스를 쓰는 주문 서비스를 찾으려면 한 번 더 조인해야 해요.
몇 번 조인할지는 의존이 몇 단계까지 이어지는지 미리 알아야 정할 수 있어요.
SQL의 재귀 쿼리(앞 단계의 결과를 다음 단계의 입력으로 넣어 되풀이하는 질의)를 쓰면 단계 수를 몰라도 끝까지 따라갈 수 있어요. 다만 "의존은 이어서 전파된다"는 지식은 테이블 정의에 없고, 질의를 쓰는 사람이 알고서 질의마다 직접 적어야 합니다.
한 질의에서 빠뜨리면 그 질의만 틀린 답을 줘요. 테이블에는 값만 있고 값 사이의 의미는 없기 때문입니다.
택소노미는 종류만 나눈다
택소노미는 대상을 종류별로 나눠 위아래 계층으로 정리한 분류 체계예요. 예를 들어 시설 아래에 데이터센터를 두고, 서비스 아래에 내부 서비스와 외부 서비스를 두는 식입니다.
그래서 "국가정보자원관리원 대전센터는 시설의 한 종류다" 같은 질문에는 답해요.
"배송 서비스는 우체국 택배를 쓴다"는 어디에 적을까요? 택소노미는 종류를 나누는 것이 전부라서 서비스 사이의 관계를 적을 방법이 없습니다. 두 질문 모두 택소노미로는 답할 수 없어요.
지식 그래프는 관계를 담지만 의미는 담지 않는다
지식 그래프는 개체를 점으로, 개체 사이의 관계를 선으로 적은 그래프예요. 여기서 관계는 "담당한다", "쓴다"처럼 두 개체를 잇는 말입니다.
결제 서비스에서 결제팀으로 담당 선을, 배송 서비스에서 우체국 택배로 의존 선을 긋는 식이에요. 그래서 첫째 질문은 선을 두 번 따라가면 답이 나오고, 둘째 질문은 대전센터로 들어오는 선을 거슬러 가면 돼요.
지식 그래프면 충분할까요? 한계가 두 가지 있습니다.
첫째, 선의 의미를 적어 두지 않아서 선을 어떻게 따라갈지는 그래프를 읽는 코드가 정해야 합니다. 의존 선을 한 번만 따라갈지, 끝까지 따라갈지는 코드마다 달라질 수 있어요.
둘째, 틀린 사실을 막지 못합니다. 예를 들어서 정산 서비스의 담당을 팀이 아니라 사람 Mina에게 연결했다고 해볼게요. 지식 그래프는 이것도 그냥 선 하나로 받아들여요.
또 "담당한다"와 "담당 팀이다"가 같은 관계를 양쪽에서 말한 것이라는 점도 모르기 때문에, 두 방향을 둘 다 적어야 합니다.
온톨로지는 관계의 의미를 공리로 적는다
온톨로지는 그래프에 관계의 의미를 문장으로 더합니다. 이 문장을 공리라고 불러요.
클래스는 팀, 사람, 서비스처럼 같은 종류의 개체를 묶어 부르는 이름이에요. 대표적인 공리 다섯 가지는 이렇습니다.
- 관계의 양쪽에 올 수 있는 클래스: 담당 팀 관계의 상대는 팀이어야 한다고 적어 둡니다.
- 전이: 관계가 이어지면 처음과 끝도 그 관계로 이어진다는 공리예요. 의존을 전이 관계라고 적어 두면, A가 B에 의존하고 B가 C에 의존할 때 A가 C에 의존한다는 사실이 도출됩니다.
- 역관계: 같은 관계를 반대 방향에서 부르는 이름이에요. "담당한다"는 "담당 팀이다"의 반대 방향이라고 적어 두면, 한쪽만 적어도 다른 쪽이 생겨요.
- 함수형: 한 개체가 그 관계로 가질 수 있는 값이 하나뿐이라는 공리예요. 장애 하나의 심각도는 하나뿐이라고 적어 둡니다.
- 서로 겹칠 수 없는 클래스: 팀이면서 동시에 사람인 개체는 없다고 적어 둡니다.
이 공리와 사실을 읽고 계산하는 프로그램이 추론기입니다. 추론기는 공리에서 새 사실을 만들고, 공리와 맞지 않는 사실은 모순으로 알려 줘요.
둘째 질문에서는 직접 의존만 적어 두어도 전이 공리 때문에 주문 서비스가 대전센터에 의존한다는 사실이 만들어지고, 질의는 한 줄로 끝납니다.
질의를 쓰는 사람이 단계 수를 알 필요가 없어요. 의미가 데이터 쪽에 적혀 있으니 질의마다 다시 적지도 않고요.
그럼 정산 서비스의 담당을 사람 Mina로 잘못 적은 사실은 어떻게 될까요? 담당 상대는 팀이라는 공리 때문에 Mina가 팀으로 취급되는데, Mina는 사람이고 팀과 사람은 겹칠 수 없으니 모순으로 드러납니다.
온톨로지를 쓴다고 앞의 셋을 버리지는 않아요. 매일 쌓이는 기록은 지금처럼 테이블에 있어도 됩니다. 온톨로지는 종류의 계층과 개체 사이의 관계를 적고, 거기에 공리를 더해서 그 기록이 무엇을 뜻하는지 적는 방식이에요.
추론기가 모든 문제를 알아서 잡아 주는 것도 아닙니다.
무엇을 적을지는 실제 문서에서 정한다
온톨로지는 범위를 정하지 않고 시작하면 개념이 끝없이 늘어나요. 그래서 범위를 머릿속에서 정하는 대신 실제 문서를 읽으면서 정합니다.
읽을 문서는 2021년 10월 29일에 과학기술정보통신부가 낸 보도자료입니다. 같은 달 25일에 일어난 KT 네트워크 장애의 원인을 조사한 결과예요. 정부가 공개한 문서이고 공공누리 제1유형이라, 출처를 밝히면 쓸 수 있어요.
원문 주소는 이렇습니다.
https://www.msit.go.kr/bbs/view.do?sCode=user&mId=113&mPid=112&bbsSeqNo=94&nttSeqNo=3180886
페이지 본문은 첨부파일을 참고하라는 한 줄뿐이에요. 첨부된 hwp 파일 옆의 바로보기를 누르면 새 창에 문서 본문이 열려요. 맨 위의 담당자 표는 건너뛰셔도 돼요.
본문에 따르면 장애는 10월 25일 "11시 16분경부터 시작되어" "12시 45분경 KT의 복구조치가 완료되어" 약 89분 동안 이어졌어요.
원인은 KT가 "부산국사에서 기업 망 라우터 교체작업 중"(부산국사는 KT가 부산에 둔 통신 설비 건물), 작업자가 "잘못된 설정 명령을 입력"한 것이라고 적혀 있어요. 그 뒤로 라우팅 오류가 전국으로 퍼졌습니다. 나머지는 DNS 트래픽 분석, 재발 방지 대책, 피해 보상 계획이에요.
명사는 클래스, 동사는 관계, 값은 속성 후보
문서를 읽으면서 명사, 동사, 숫자와 시간에 서로 다른 색을 칠한다고 생각해 주세요. 칠한 말은 각각 클래스 후보, 관계 후보, 속성 후보가 돼요. 속성은 개체 하나에 붙는 값(시간이나 숫자)입니다.
명사에서는 이런 것들이 나와요.
- 조직: 과학기술정보통신부, KT, 방송통신위원회
- 서비스: 인터넷 서비스
- 시설: 부산국사
- 장비: 라우터, DNS 서버
- 작업: 라우터 교체 작업
- 장애: 네트워크 장애
- 문서: 보도자료
동사에서는 이런 관계 후보가 나옵니다.
- 교체 작업 중 잘못된 명령을 입력해 장애가 났다(장애가 작업 때문에 일어났다)
- 장애가 인터넷 서비스에 영향을 줬다
- 작업이 라우터를 대상으로 했다
- 라우터가 부산국사에 있다
- KT가 인터넷 서비스를 운영한다
값에서는 장애가 시작된 11시 16분경과 복구된 12시 45분경이 나와요. 이 값은 장애 개체에 붙는 속성입니다.
질문 네 개로 남길 것을 고른다
표시한 후보를 전부 설계에 넣지는 않아요. 그래프가 답해야 할 질문을 먼저 정하고, 그 질문에 쓰이는 후보만 남깁니다. 질문은 네 개로 정했어요.
- 외부에서 장애가 나면 우리 서비스 중 어디까지 영향이 가는가
- 그 장애는 언제 시작해 언제 복구됐는가
- 장애를 일으킨 작업이나 사건은 무엇인가
- 우리 서비스는 누가 담당하는가
같은 기준으로 버린 것은 이렇습니다.
- DNS 트래픽이 평시의 22배였다거나 대역폭의 8%가 쓰였다는 분석 수치: 네 질문 어디에도 쓰이지 않아요.
- 재발 방지 대책과 피해 보상 계획: 일어난 사건이 아니라 앞으로의 계획이에요.
- DDoS(여러 곳에서 한꺼번에 요청을 보내 서비스를 멈추게 하는 공격)가 무엇인지 설명하는 부분: 일반 지식이라 그래프에 둘 사실이 아니에요.
문서에 없는 사실도 필요하다
질문 1에 답하려면 "우리 서비스가 KT 회선을 쓴다"는 관계가 있어야 하는데, 이 문장은 보도자료에 없어요. 이건 우리 회사가 이미 알고 있는 사실입니다.
문서는 장애 쪽을 알려 주고, 회사는 어느 서비스가 그 회선을 쓰는지를 알아요. 문서의 사실과 회사의 사실이 KT 회선이라는 개체 하나에 함께 붙어야 질문 1에 답할 수 있습니다.
질문 4도 마찬가지예요. 우리 서비스를 누가 담당하는지는 문서에 없고, 팀과 사람이라는 클래스가 필요합니다.
그래서 이 단계에서 남길 설계 노트에는 문서에 없는 관계 중 질문 1에 필요한 의존 관계(dependsOn) 하나만 함께 적어요. 팀·사람·심각도 같은 사내 정보는 노트에 적지 않고, 온톨로지를 만들 때 클래스로 따로 더해야 합니다.
설계 노트로 남긴다
결과는 design/model.md라는 마크다운 파일 하나로 남겨요.
# 온톨로지 설계 노트
읽은 문서: 과기정통부 "KT 네트워크 장애 원인분석 결과 발표"(2021-10-29)
## 이 그래프가 답해야 할 질문
1. 외부에서 장애가 나면 우리 서비스 중 어디까지 영향이 가는가
2. 그 장애는 언제 시작해 언제 복구됐는가
3. 장애를 일으킨 작업이나 사건은 무엇인가
4. 우리 서비스는 누가 담당하는가
## 클래스 후보 (명사)
- 조직: 과학기술정보통신부, KT, 방송통신위원회 → Organization
- 서비스: 인터넷 서비스 → Service
- 시설·장비: 부산국사, 라우터, DNS 서버 → Facility, Equipment
- 작업: 라우터 교체 작업 → Change
- 장애: 네트워크 장애 → Incident
- 문서: 보도자료 → Document
## 관계 후보 (동사)
- 작업이 장애를 일으켰다 → causedBy (장애 → 사건)
- 장애가 서비스에 영향을 줬다 → affects (장애 → 자산)
- 작업이 라우터를 대상으로 했다 → target (작업 → 자산)
- 라우터는 부산국사에 있다 → partOf (장비 → 자산)
- KT가 인터넷 서비스를 운영한다 → operatedBy (자산 → 조직)
- 우리 서비스가 KT 회선을 쓴다 → dependsOn (자산 → 자산)
## 속성 후보 (값)
- 11시 16분경 시작 → occurredAt
- 12시 45분경 복구 → resolvedAt
## 버린 것
- DNS 트래픽 22배, 대역폭 8% 같은 분석 수치: 질문 1~4에 쓰이지 않는다
- 재발 방지 대책, 피해 보상 계획: 사건이 아니라 계획이다
- DDoS 개념 설명: 일반 지식이라 그래프에 둘 사실이 아니다
제목 바로 아래에 읽은 문서를 적어 두면 나중에 설계의 근거를 찾을 수 있어요.
클래스 후보는 명사를 클래스 이름으로 옮긴 목록이고, 화살표 오른쪽이 영문 클래스 이름입니다.
시설과 장비는 한 줄에 적었지만 화살표 오른쪽 클래스는 둘이에요. 부산국사는 시설이고 라우터와 DNS 서버는 장비라서 Facility와 Equipment로 나눴습니다.
관계 후보에는 소괄호 안에 방향을 적었어요. causedBy (장애 → 사건)은 장애를 주어로, 원인이 된 사건을 목적어로 읽는다는 뜻입니다. 방향에 나오는 자산은 서비스·시설·장비를 한데 묶어 부르는 말이에요.
작업이 장애를 일으켰다는 문장이 왜 causedBy가 될까요? 장애에서 작업으로 선을 긋는 쪽이 장애의 원인을 묻는 질문에 바로 쓰이기 때문이에요.
속성 후보는 값을 붙일 이름이에요. 시간은 개체 사이의 관계가 아니라 장애 하나에 붙는 값이라서 관계 후보와 따로 뒀어요.
맨 아래 "버린 것"에는 버린 후보와 그 이유를 적었습니다. 이유를 적어 두면 나중에 문서를 다시 읽을 때 같은 판단을 반복하지 않아도 돼요.
정리
범위: 같은 운영 지식을 데이터 모델·택소노미·지식 그래프·온톨로지로 적어 본 비교와, 2021-10-29 과학기술정보통신부 KT 장애 원인분석 보도자료에서 설계 노트를 만드는 과정.
- 테이블은 값을 저장할 뿐 "의존은 이어서 전파된다" 같은 의미는 저장하지 않아요. 재귀 쿼리로 끝까지 따라갈 수는 있지만, 그 지식은 질의마다 사람이 직접 적어야 합니다.
- 택소노미는 종류만 나눠서 서비스 사이의 관계를 적지 못해요. 지식 그래프는 관계를 잇지만, 선을 따라가는 방식은 코드에 맡기고 잘못 이은 선도 막지 못합니다.
- 온톨로지는 관계의 양쪽 클래스, 전이, 역관계, 함수형, 서로 겹칠 수 없는 클래스 같은 공리를 더해요. 추론기는 이 공리로 주문 서비스가 대전센터에 의존한다는 사실을 만들고, 사람 Mina를 담당 팀으로 적은 사실을 모순으로 알려 줍니다.
- 온톨로지가 테이블을 대체하지는 않아요. 매일 쌓이는 기록은 테이블에 두고, 온톨로지에는 그 기록이 무엇을 뜻하는지를 적으세요.
- 설계는 실제 문서에서 시작하세요. 명사·동사·값을 클래스·관계·속성 후보로 표시하고 답할 질문에 쓰이는 것만 남기되, 문서에 없는 사내 사실(서비스의 의존 관계, 팀·사람)은 따로 더해야 합니다.