온톨로지

참여 기록 표를 열면 emp_no, prj_cd, rl_cd, join_dt 네 열이 보입니다. emp_no는 직원 같지만 rl_cd가 무엇인지는 표 어디에도 없습니다. 데이터셋은 열 이름과 타입까지만 말해 주고, 뜻은 질문할 때마다 사람이 다시 해석합니다. 온톨로지는 그 해석을 표 밖에 한 번 적어 두는 층입니다.

온톨로지를 정의하면 emp_no는 직원이라는 개념의 식별자가 되고, 같은 직원이 여러 표에 흩어져 있어도 하나의 대상으로 취급됩니다. 스키마가 데이터의 모양을 정한다면 온톨로지는 데이터가 무엇을 뜻하는지를 정합니다.

스키마가 답하지 못하는 질문

스키마는 emp_no가 문자열이고 비어 있을 수 없다는 사실까지 말합니다. 여기까지는 기계가 데이터를 저장하고 검증하는 데 충분합니다.

부족해지는 지점은 사람이 질문할 때입니다. 참여 기록의 emp_no와 팀 명단의 staff_id가 같은 대상을 가리키는지, 이 표의 한 행이 직원 한 명인지 직원의 한 발령인지는 스키마에 없습니다. 이 해석은 보통 담당자의 머릿속이나 쿼리 주석에 남고, 담당자가 바뀌면 다시 물어야 합니다. 온톨로지는 그 해석을 데이터 옆에 남기는 자리입니다.

의미를 세 겹으로 적습니다

온톨로지에서 개념 하나는 이름, 별칭, 설명 세 가지를 함께 가집니다. 셋은 서로 다른 독자를 위한 것입니다.

이름이 만든 뒤 고정된다는 점은 제약이 아니라 성질입니다. 참조가 깨지지 않아야 하므로 식별자는 고정하고, 사람에게 보이는 표현은 별칭으로 따로 바꿉니다. 설명은 사소해 보이지만 실제로는 온톨로지가 스키마와 갈라지는 지점입니다. 사번으로 식별되는 재직 직원입니다 라는 한 문장이 있으면 다음 사람이 같은 질문을 반복하지 않습니다.

컬렉션 하나에 온톨로지 하나

온톨로지는 독립된 저장소가 아니라 컬렉션에 붙는 층입니다. 컬렉션을 만들면 그 컬렉션의 온톨로지 스코프가 함께 생기고, 엔티티와 관계는 반드시 소속 컬렉션을 가집니다.

이 구조는 의미의 유효 범위를 컬렉션과 같게 만듭니다. 인사 컬렉션에서 정의한 project와 영업 컬렉션에서 정의한 project는 이름이 같아도 서로 다른 개념일 수 있고, 시스템은 둘을 섞지 않습니다. 개념을 공유해야 한다면 컬렉션 구성을 먼저 검토하는 편이 온톨로지를 억지로 맞추는 것보다 낫습니다.

모델과 데이터는 따로 움직입니다

온톨로지를 정의해도 그 자체로는 행이 하나도 없습니다. 구조를 만드는 일과 실제 데이터를 채우는 일이 분리되어 있고, 채우는 쪽은 파이프라인이 담당합니다.

그래서 온톨로지 설계는 데이터가 완성되기를 기다릴 필요가 없습니다. 어떤 개념이 있고 무엇으로 구분되는지를 먼저 정하면, 원본 표가 나중에 바뀌어도 개념은 그대로 남습니다. 반대로 데이터부터 모으고 의미를 뒤에 붙이면, 표 구조가 그대로 개념이 되어 원본이 바뀔 때마다 해석도 흔들립니다.