온톨로지 스키마 버전 관리: 운영 중 관계를 안전하게 바꾸는 법
온톨로지 스키마 버전 관리는 diff와 활성 포인터만으로 끝나지 않습니다. 스키마·매핑·L3 데이터의 발행과 롤백 경계를 같은 표로 정리합니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
2026년 8월 29일 기준, 데이터 책임자는 복구 단위부터 정해야 합니다. L3 변환 뒤에는 포인터 롤백만으로 복구할 수 없습니다.
객체 이름을 바꾸거나 관계를 없애는 일은 YAML 한 줄의 수정으로 보입니다. 운영 중에는 매핑, 기존 객체와 엣지, 검색 질의, 외부 소비자가 같은 의미를 읽는지까지 확인해야 합니다. 이 글은 변경 유형을 발행과 복구 조건으로 나눕니다.
변경을 요청한 역할에 따라 먼저 볼 경계#
- 데이터 스튜어드는 동의어 추가인지 기존 의미 교체인지 봅니다.
- 애플리케이션 책임자는 이전 이름과 관계를 쓰는 소비자를 봅니다.
- 데이터 엔지니어는 매핑과 L3 backfill의 기준 버전을 봅니다.
- 운영 책임자는 포인터·데이터·그래프의 복구 단위를 봅니다.
작은 온톨로지부터 시작한다면 ERP 데이터 AI 에이전트 구축 기준을 먼저 확인할 수 있습니다.
어떤 스키마 변경이 포인터 롤백만으로 끝나나요?#
새 버전을 저장했다는 사실만으로 복구 가능성이 생기지는 않습니다. 아래 표는 2026년 8월 29일 알파카랩스의 D 자사 가설이며, 실제 DSL·매핑·데이터와 소비 질의로 각 조건을 확인해야 합니다.
| 변경 유형 | 발행 전 검증 | 함께 발행할 것 | 롤백 조건 | 근거·확인일 |
|---|---|---|---|---|
| 선택 속성 추가 | 기존 객체의 무속성 조회 | 스키마·필요한 매핑 | 새 값 미사용 시 포인터 전환 | D, 2026-08-29 |
| 이름·코드 변경 | 이전 이름 소비자·원천 열 | 별칭·매핑·소비자 변경 | 역매핑·호환 별칭 확인 | D, 2026-08-29 |
| 관계 방향·제약 변경 | 기존 엣지·위반 객체 표본 | 스키마·backfill 계획 | 이전 방향 재구성 가능 | D, 2026-08-29 |
| 타입·관계 삭제 | 활성 객체·질의·Action 참조 | 은퇴·보존 정책 | 삭제 전 데이터·근거 보존 | D, 2026-08-29 |
데이터 변환이 시작됐다면 ERP 데이터 이관 검증 절차처럼 기준 시각, 검증식과 역변환 책임자를 따로 둡니다.
Ontokit 내부 구현에서 확인되는 버전 경계#
C 자기표기, 2026년 8월 29일 확인. Ontokit의 스키마 레지스트리는 DSL을 컴파일·검증한 뒤 정규화된 의미 해시를 저장합니다. 직전 active 버전과 해시가 같으면 새 행을 만들지 않습니다. 변경이 있으면 부모 버전, 구조 diff, 커밋 주체와 시각을 버전 행에 남깁니다.
같은 내부 구현에서 롤백은 SchemaVersion 행이나 L3 Object·Edge를 지우지 않고 active와 superseded 상태 포인터를 전환합니다. 화면 계약에는 스키마와 매핑을 staged 쌍으로 검토·발행하고 이력 화면에서 서버가 허용한 최근 변경부터 롤백하는 경로가 적혀 있습니다.
실제 고객 데이터의 롤백 성공률, 복구 시간과 무중단 전환 결과는 미확인입니다. 제품 범위는 Ontokit 온톨로지 솔루션에서 확인할 수 있습니다.
버전 이력이 있어도 실패하는 조건#
스키마와 매핑을 따로 활성화하면 같은 원천 열을 서로 다른 의미로 읽는 구간이 생깁니다. 발행 단위는 스키마 파일 하나가 아니라 스키마·매핑·backfill·그래프 반영 상태를 묶어야 합니다.
B 공식 원문, 2026년 8월 29일 확인. PostgreSQL 공식 문서는 publication을 테이블 변경 집합으로 설명하며 스키마와 구분합니다. UPDATE·DELETE 전달에는 행을 식별할 replica identity도 필요합니다. 변경 전달 장치가 의미 변경과 데이터 복구까지 해결한다고 확대하면 안 됩니다. PostgreSQL publication 공식 문서에서 범위를 확인할 수 있습니다.
자주 묻는 질문