RDB 조인 vs 온톨로지 탐색 — 같은 질문, 두 가지 데이터 접근

같은 데이터를 두고도 “조인을 설계하는” 방식과 “관계를 걸어가는” 방식은 실무자가 체감하는 속도와 접근성이 완전히 다릅니다. RDB와 온톨로지 차이를 확인하기 위해, 이 글은 법인카드 한도를 조회하는 흔한 사내 질문 하나를 RDB 조인 방식과 Palantir Foundry 온톨로지 탐색 방식으로 각각 풀어보면서, 온톨로지 탐색이 실제로 무엇을 바꾸는지 구체적으로 비교합니다.

문제 정의: 한 문장 질문, 네 개 테이블

사내 채팅으로 이런 질문이 들어왔다고 가정합니다.

“김민준 사원이 속한 팀의 팀장이 이번 달에 쓸 수 있는 법인카드 한도, 얼마나 남았어?”

일상적인 문장이지만 답을 찾으려면 최소 네 개 테이블을 오가야 합니다.

네 조각의 정보를 “관계”로 이어 붙여야 비로소 답이 나오는 질문이라는 점에서, 이 질문은 RDB와 온톨로지의 차이를 보여주는 데 적합한 사례입니다.

RDB 조인 방식: 사람이 경로를 설계한다

출발점 — 5개 테이블 스키마

EMPLOYEE   (user_id PK, user_nm, team_id FK)
TEAM       (team_id PK, team_nm, leader_id FK → EMPLOYEE)
CARD       (card_id PK, holder_id FK → EMPLOYEE, card_type)
CARD_LIMIT (card_id FK, month, limit_amt, used_amt)

관계는 FK 컬럼명에만 존재합니다. “속한다”, “팀장이다”, “카드를 보유한다” 같은 업무적 의미는 스키마 어디에도 문자로 적혀 있지 않고, 개발자가 FK를 보고 유추해야 합니다.

실제로 작성되는 쿼리

SELECT  c.card_id,
        cl.limit_amt - cl.used_amt AS 잔여한도
FROM    employee e
JOIN    team t          ON e.team_id   = t.team_id
JOIN    employee mgr    ON t.leader_id = mgr.user_id   -- 셀프 조인
JOIN    card c           ON c.holder_id = mgr.user_id
JOIN    card_limit cl    ON cl.card_id  = c.card_id
WHERE   e.user_nm = '김민준'
  AND   cl.month  = '2026-08';

한 문장짜리 질문이 4개 JOIN(그중 하나는 셀프 조인)을 가진 쿼리로 번역됩니다. 이 쿼리를 작성하려면 스키마를 아는 사람이 필요하고, “팀장 말고 팀 전체 한도라면?” 같은 질문이 하나만 바뀌어도 조인 경로를 다시 설계해야 합니다.

RDB 방식이 부딪히는 벽

온톨로지 방식: 질문 그대로 걸어간다

같은 데이터를 온톨로지로 모델링하면

테이블은 Object Type으로, FK는 이름 있는 Link Type으로 바뀌면서 관계에 업무적 의미가 명시됩니다.

• 직원(Employee Object) —[소속팀이다]→ 팀(Team Object)
• 팀(Team Object) —[팀장이다]→ 직원(Employee Object)
• 직원(Employee Object) —[카드를 보유한다]→ 법인카드(Card Object)
• 법인카드 Object의 Property: 이번 달 한도, 사용액, 그리고 파생 Property인 잔여한도(한도 − 사용액)가 객체 안에 한 번만 정의됩니다.

FK 컬럼명 뒤에 숨어 있던 관계가 “소속팀이다·팀장이다·카드를 보유한다”라는 업무 언어로 승격되는 것이 핵심입니다.

조회: 질문의 어순 그대로 탐색

김민준 → 소속팀 → 팀장 → 보유 카드 → 잔여한도

질문 “김민준이 → 속한 팀의 → 팀장이 → 쓸 수 있는 법인카드 한도가 → 얼마나 남았어?”의 어순이 곧 객체 탐색 경로(Traverse)입니다. 조인 경로를 새로 설계하는 대신, 이미 정의된 관계 위를 그대로 걸어가면 됩니다.

이 탐색은 Foundry 안에서 세 가지 방식으로 재사용됩니다.

한눈에 비교

실무 적용 시 고려사항

• 온톨로지는 데이터를 바꾸는 작업이 아니다. 원본 테이블과 파이프라인은 그대로 두고, 그 위에 “질문할 수 있는 언어”를 한 겹 씌우는 작업이다. Ontology Manager에서 Object Type·Link Type을 설계하는 절차는 Ontology Manager 실전 가이드에서 다룬다.
• Link Type 이름이 곧 문서다. manager_id라는 FK 컬럼명 대신 “팀장이다”라는 Link Type 이름을 쓰면, 그 자체가 스키마 문서 역할을 한다. 이름을 대충 지으면 이 이점이 사라진다.
• 파생 Property는 한 번만, 신중하게 정의한다. ‘잔여한도’ 같은 계산식을 Object Type 안에 정의해두면 이후 모든 화면·리포트·AI Agent가 같은 계산 결과를 공유한다. 반대로 계산식이 잘못 정의되면 그 오류도 똑같이 전사에 퍼진다.
• 셀프 조인이 사라지는 게 아니라, 이름을 얻는다. RDB에서 골치 아팠던 셀프 조인(팀장=직원)이 온톨로지에서 없어지는 것은 아니다. 다만 “팀장이다”라는 이름 있는 관계로 명시되면서 매번 별칭(alias)을 헷갈릴 필요가 없어진다.

질문이 한 단계 더 복잡해지면 — 유지보수 차이가 드러나는 지점

처음 질문에 조건이 하나 더 붙는다고 해봅시다. “그런데 올해 신규 입사자는 제외하고 알려줘.” RDB 조인 방식이라면 EMPLOYEE 테이블에 입사일 조건을 추가하는 WHERE 절 한 줄을 더해야 합니다. 쉬워 보이지만, 이 조건이 조인 체인의 어느 지점에 들어가야 결과가 꼬이지 않는지(김민준 기준인지, 팀장 기준인지)를 다시 판단해야 합니다. 조인이 복잡할수록 조건 하나를 추가할 때마다 전체 쿼리를 다시 검토해야 하는 부담이 커집니다.

온톨로지 탐색 방식이라면 기존 관계 탐색 경로(사원 → 소속 팀 → 팀장 → 카드 한도)는 그대로 둔 채, 시작점인 “사원” 객체 집합에 필터 하나(입사일 조건)만 추가하면 됩니다. 경로 자체를 다시 설계할 필요가 없다는 점이 질문이 복잡해질수록 체감됩니다.

RDB와 온톨로지, 언제 뭘 쓰나

마무리

RDB 조인과 온톨로지 탐색은 같은 데이터에 대한 두 가지 접근 방식입니다. RDB는 질문을 스키마에 맞게 사람이 번역해야 하고, 온톨로지는 질문의 구조 자체가 이미 탐색 경로가 되도록 관계에 이름을 붙여둡니다. “김민준이 속한 팀의 팀장이 쓸 수 있는 법인카드 한도가 얼마나 남았어?” — 온톨로지에서는 이 문장이 곧 쿼리입니다.

함께 보면 좋은 글

• 설계도인가, 완공된 건물인가 — 온톨로지와 지식그래프는 뭐가 다른가