온톨로지, 엔지니어링의 영역인가 철학의 영역인가?

온톨로지

AI 얘기를 하다 보면 이제는 철학까지 알아야 한다는 이야기가 나온다.

코드는 AI가 작성해 주고, 필요한 데이터도 에이전트가 알아서 찾아오니까 결국 중요한 것은 문제를 정의하는 능력이라는 것이다. 여기까지는 나도 동의한다. 그런데 그다음부터는 조금 이상하다. 문제를 정의하는 것이 중요하다는 말이 언제부터 컴퓨터 사이언스를 몰라도 된다는 말이 되었을까? 자연어로 지시할 수 있게 되었으니 이제는 글을 잘 쓰고 인문학적인 소양을 갖추는 것이 더 중요하다고 한다. 사실 이런 식으로 한쪽의 중요성을 설명하기 위해 다른 쪽을 치워버리는 이야기를 별로 좋아하지 않는다.

온톨로지는 이런 논쟁이 붙기 좋은 주제다. 어원부터 존재론이고, 무엇을 어떤 개념으로 구분할 것인지 고민해야 하며, 막상 구현하려고 보면 데이터베이스와 쿼리와 논리적인 추론이 등장한다. 그러니 철학의 영역이라고 해도 그럴듯하고 엔지니어링의 영역이라고 해도 그럴듯하다. 그런데 내 생각에는 어느 쪽이 더 중요한지 결정하는 것 자체가 별로 쓸모 있는 일이 아니다. 우리가 풀려는 문제가 뭔지, 지금 가진 데이터와 기술로 어디까지 할 수 있는지, 그리고 그걸 계속 유지할 수 있는지를 알아야 하는 것이지 어느 전공이 이겼는지 정할 필요는 없으니까.

그렇다고 그냥 ‘둘 다 중요합니다’ 하고 끝내려는 것은 아니다. 온톨로지가 실제로 뭘 하는 것인지 따라가다 보면, 두 영역을 나누는 것부터가 그렇게 간단하지 않다는 생각이 든다. 설명에는 가상의 제조사 A사와 제품 Z, 공급사 B사를 사용할 것이다. 아래의 회사나 업무 수치는 전부 예시다.

Ontology는 보통 존재론으로 번역한다. 존재를 뜻하는 그리스어와 학문·논의를 뜻하는 말에서 유래한 이름인데, 무엇이 존재하고 그것을 어떻게 구분할 것인지 묻는 철학적인 문제와 연결되어 있다. 물론 위 그림에 아리스토텔레스가 있다고 해서 이 사람이 RDF를 만들었다는 뜻은 아니다. 현대의 컴퓨터과학에서 말하는 온톨로지는 어떤 목적에 필요한 개념과 관계를 명시적으로 표현한 모델에 가깝다. Gruber의 정의로는 ‘개념화의 명시적 명세’인데, 솔직히 이 말만 읽으면 뭘 하겠다는 건지 잘 안 와닿는다.

그냥 회사에서 ‘고객’이 누구인지 정하는 상황을 생각해 보면 된다. 영업팀은 아직 계약하지 않은 회사도 고객이라고 부를 수 있고, 재무팀은 돈을 낸 회사를 고객으로 볼 수 있다. 고객센터 입장에서는 실제 제품을 사용하는 사람이 고객이다. 다들 같은 단어를 쓰는데 가리키는 대상은 다르다. 이 상태에서 고객이 몇 명이냐고 물으면 어느 팀에 물었는지에 따라 숫자가 달라질 것이다. DB에 customer라는 테이블이 있다고 해결되는 문제가 아니다. 애초에 뭘 넣기로 했는지가 다르니까.

그래서 잠재 고객, 계약 상대방, 결제 주체, 최종 사용자를 구분하고 이들 사이의 관계를 적는다. 여기까지 보면 개념을 구분하는 일이니 철학적인 사고가 중요해 보인다. 그런데 바로 다음에는 어느 시스템의 어떤 레코드가 그 대상을 가리키는지 찾아야 한다. 같은 법인에 붙은 서로 다른 ID도 연결해야 하고, 잘못 연결했을 때 어떻게 확인할지도 정해야 한다. 뜻을 정하는 일과 그 뜻대로 데이터를 다루는 일은 생각보다 붙어 있다. 사실 논리학이나 지식 표현도 원래부터 두 분야의 경계에 있던 영역이다. 온톨로지가 등장했다고 갑자기 문과와 이과의 역할이 뒤집힌 것은 아니다.

그래서 CS는 이제 필요 없는가?

이런 이야기에 주니어 채용이나 CS 전공의 인기가 줄었다는 소식까지 붙으면 결론은 더 과격해진다. 코딩은 AI가 할 테니 이제는 인문학을 배워야 한다는 식이다. 기술이 발전하면서 오히려 인문학적인 소양의 가치를 다시 이야기하게 되는 것은 꽤나 아이러니하다. 다만 그 이야기가 실제 채용 수요를 설명하는 것인지, 우리가 중요하다고 생각하는 능력을 말하는 것인지는 구분할 필요가 있다.

관측된 변화는 분명 있다. Stanford Digital Economy Lab의 2026년 8월 분석에서는 미국의 AI 노출도가 높은 직종에 종사하는 22–25세 고용이, 노출도가 낮은 또래 직종의 추세를 따라갔을 경우보다 약 19% 낮았다고 보고했다. ASEE가 2018–2025년 연속으로 응답한 미국 CS 프로그램 135개를 분석한 결과에서도 약 91%가 2024년 대비 2025년 신입생 감소를 보였다. 그렇다고 앞의 수치가 개발자 19%가 AI 때문에 해고됐다는 뜻은 아니고, 뒤의 수치가 전 세계에서 CS를 외면한다는 뜻도 아니다. 고용 분석에서 AI의 인과효과가 확정된 것도 아니며, 전공 선택에는 팬데믹 시기의 급증 이후 조정이라는 맥락도 있다.

여기서 ‘그러므로 기업은 철학 전공자를 더 원한다’고 넘어가면 그건 별개의 주장이다. 주니어 고용이 줄어드는 것과 인문학 전공자의 채용이 늘어나는 것은 같은 통계가 아니다. 인문학적인 사고가 필요하다는 의견에는 동의할 수 있어도, 앞의 자료로 뒤의 결론까지 증명할 수는 없다. 내가 불편하게 느끼는 부분도 여기다. 굉장히 복잡한 계산 기술이 널리 쓰이게 되었는데, 그 결과가 그 계산 기술을 몰라도 된다는 이야기로 소비된다.

AI가 자연어를 받아주니까 문장을 잘 쓰면 잘 동작할 것처럼 보이기는 한다. 실제로 명확하게 지시하고 적절한 예시를 주는 것은 중요하다. 하지만 LLM은 사람이 쓴 문장의 뜻을 계약 조건처럼 이행하는 시스템이 아니다. 자기회귀 언어모델을 아주 단순하게 표현하면 다음과 같다.

$$P_\theta(y\mid x)=\prod_{t=1}^{T}P_\theta(y_t\mid x,y_{<t})$$

$x$는 질문이나 지시, 참고 자료 같은 입력이고 $y_t$는 생성할 토큰, $\theta$는 학습된 매개변수다. 입력과 앞서 생성한 토큰을 조건으로 다음 토큰의 확률을 계산해 출력을 이어가는 것이다. 이 수식 하나로 모델의 능력을 전부 설명할 수 있다는 뜻은 아니다. 다만 우리가 결과에 개입할 수 있는 방식이 각각 다르다는 것은 이해해야 한다. 프롬프트를 바꾸는 것은 입력 조건을 바꾸는 것이고, RAG로 문서를 가져오는 것은 참고할 정보를 제공하는 것이다. 학습이나 파인튜닝은 매개변수를 바꾸고, 디코딩 설정은 출력 분포에서 토큰을 선택하는 방식에 영향을 준다. 다 같은 ‘AI를 잘 쓰는 방법’처럼 보여도 건드리는 부분이 다르다.

예를 들어 에이전트가 예전 계약서를 읽고 답했다면 말투를 더 정중하게 바꿀 것이 아니라 왜 예전 문서가 검색됐는지를 봐야 한다. temperature를 낮춘다고 최신 계약서가 생기지는 않는다. JSON으로 출력하게 했다고 안에 들어 있는 공급사 ID까지 맞는 것도 아니다. 결과가 틀렸을 때 질문이 모호했는지, 검색이 잘못됐는지, 데이터 매핑이 틀렸는지, 모델이 근거를 잘못 해석했는지를 구분할 수 있어야 한다. 이걸 전부 프롬프트 문제로 보면 결국 지시문만 계속 수정하게 된다.

내가 기술 자체를 알아야 인사이트도 나온다고 생각하는 이유가 이런 부분이다. 물론 모든 사람이 Transformer를 직접 구현해야 한다는 뜻은 아니다. 역할에 따라 알아야 하는 깊이는 다르다. 하지만 팀 안에는 확률적인 출력과 검증된 사실의 차이를 이해하고, 실패를 측정하고, 모델 밖에서 코드와 권한으로 행동을 통제할 수 있는 사람이 있어야 한다. 인문학적인 소양 역시 예쁜 문장을 작성하는 능력보다는 전제를 의심하고 개념을 구분하고 다른 사람의 관점을 이해하는 능력에 가깝다. 어느 한쪽만 배우면 나머지를 몰라도 된다는 식으로 설명할 문제는 아닌 것 같다.

온톨로지는 AI를 위한 새 DB인가

그럼 온톨로지를 붙이면 이런 문제가 해결되는가? 일단 온톨로지는 에이전트가 등장하면서 새로 발명된 DB가 아니다. 지식을 표현하고 공유하기 위해 오래전부터 연구해 온 방식이고, RDB 위에서 동작하도록 만들 수는 있지만 RDB가 반드시 있어야 성립하는 것도 아니다. 기존 시스템의 데이터에 어떤 뜻을 부여하고 서로 어떻게 연결할 것인지 설명하는 계층으로 이해하면 조금 편하다.

A사의 ERP에는 B사가 VENDOR로 들어 있고 생산관리 시스템에는 PARTNER로 들어 있다고 하자. 계약서에는 법인명으로만 적혀 있다. 사람은 문맥을 보고 같은 회사라고 생각할 수 있지만 시스템에는 그 연결을 명시해야 한다. 이때 온톨로지는 공급사가 무엇인지, 제품이나 부품과 어떤 관계를 갖는지 표현한다. 그렇다고 이름이 비슷한 데이터를 알아서 같은 회사로 만들어주는 것은 아니다. 실제로 같은 대상인지는 식별자와 근거를 확인해야 한다.

지식 그래프와도 조금 다르다. 지식 그래프에는 ‘제품 Z가 배터리 B-21을 사용한다’, ‘B사가 B-21을 공급한다’ 같은 개별적인 진술이 연결된다. 온톨로지는 그 진술에서 사용하는 배터리, 부품, 공급사 등의 개념과 관계, 추론의 전제를 정의한다. 실제로는 같이 쓰는 경우가 많아서 헷갈리는데, 구체적인 대상을 연결하는 것과 그 연결을 해석할 뜻을 정하는 것은 구분할 수 있다.

그래프에 선을 많이 그었다고 의미까지 잘 정리된 것은 아니다. 잘 설계된 RDB 스키마에도 이미 도메인 지식은 들어 있다. 그래서 나는 그래프 형태로 바꾸었다는 이유만으로 기존 데이터베이스보다 더 똑똑해졌다고 설명하는 것도 조심해야 한다고 생각한다. 중요한 것은 저장하는 모양보다 그 관계를 어떤 목적으로 정의했고 실제로 무엇을 할 수 있느냐에 있다.

에이전트와 함께 다시 주목받는 이유는 이해가 된다. 생성형 AI가 답변만 작성하는 데서 그치지 않고 직접 DB를 조회하거나 업무 요청을 등록하려면, 여러 시스템에서 같은 대상과 규칙을 일관되게 다뤄야 한다. 흔히 말하는 Agentic AI도 생성형 AI와 완전히 다른 종의 모델이라기보다는, 생성 모델에 계획과 도구 사용, 상태 관리 등을 결합한 시스템에 가깝다. 그 과정에서 온톨로지가 도움이 될 수 있는 것이지 모든 에이전트의 필수 구성요소인 것은 아니다.

RAG로 관련 계약서를 찾았다고 생각해 보자. 문서를 찾은 것은 좋은데, 문서 속 B사가 ERP의 B사와 같은 법인인지, 계약이 아직 유효한지, 대체 공급 인증이 어느 부품 규격에 적용되는지는 따로 확인해야 한다. 문서를 가져오는 일과 업무에 맞는 답을 만드는 일 사이에는 이런 과정이 남아 있다.

관련된 내용을 찾았다고 원인까지 증명한 것은 아니다. 공급 지연과 생산량 감소를 그래프로 연결해 놓더라도 마찬가지다. 연결이 있다는 것과 인과관계가 있다는 것은 다른 이야기인데, 답변이 자연스러우면 이 차이를 그냥 넘어가기 쉽다.

개념을 실제로 표현하는 방식

온톨로지에서 자주 나오는 TBox와 ABox도 이런 구분에서 시작하면 된다. TBox는 ‘배터리는 부품이다’, ‘공급사는 조직이다’처럼 일반적인 개념을 정의하는 부분이고, ABox는 ‘B-21은 배터리다’, ‘B사가 B-21을 공급한다’처럼 개별 대상에 대한 주장을 담는 부분이다. RBox는 관계의 성질을 다룬다. ‘공급한다’와 ‘공급받는다’가 역관계인지, 어떤 관계를 여러 번 이어도 같은 관계가 성립하는지 등을 정한다. 문헌에 따라 RBox를 TBox에 포함해서 설명하기도 한다. 별도의 DB 세 개를 만들어야 한다는 이야기는 아니다.

이때 데이터를 표현하는 기본적인 모델이 RDF다. 주어, 술어, 목적어로 이루어진 세 칸을 트리플이라고 하는데, ‘B사 / 공급한다 / B-21’처럼 적는 것이다. RDF 자체가 XML 파일 형식을 뜻하는 것은 아니다. Turtle이나 JSON-LD 같은 형식으로도 표현할 수 있고, 아래는 Turtle로 작성한 예시다.

@prefix ex: <https://example.com/supply/> .

ex:ProductZ a ex:Product ;
    ex:usesPart ex:BatteryB21 .
ex:BatteryB21 a ex:Battery .
ex:SupplierB a ex:Supplier ;
    ex:supplies ex:BatteryB21 .

제품 Z는 Product에 속하고 B-21을 부품으로 사용한다. B-21은 Battery이고 B사는 Supplier이며 B-21을 공급한다. 그냥 위에서 설명했던 내용을 일정한 문법에 맞춰 적은 것이다. 여기서 a는 rdf:type의 줄임말로 어떤 종류에 속하는지를 나타낸다. ex:SupplierB 같은 IRI는 대상을 식별하기 위해 쓴다. 물론 ID가 있다고 같은 회사의 중복 데이터가 해결되는 것은 아니기 때문에, 식별자를 어떻게 부여하고 연결할지도 관리해야 한다.

RDFS는 여기에 클래스나 상하 관계를 표현할 어휘를 더하고, OWL은 동치나 배타성, 관계의 특성 등 더 풍부한 논리적인 정의를 표현할 수 있게 한다. 이 과정에서 공리(axiom)라는 말이 나온다. 뭔가 굉장히 거창해 보이지만 모델이 전제로 채택한 형식적인 진술이다. 우리가 그렇게 정의하기로 한 것이지 현실이 반드시 그렇다고 보증받은 것은 아니다. ABox에 들어 있는 주장도 원천 데이터가 틀렸다면 같이 틀릴 수 있다.

예를 들어 이 서비스에서는 배터리를 핵심 부품으로 정하고, 핵심 부품을 하나 이상 공급하는 공급사를 ‘핵심 부품 공급사’라고 정의했다고 하자. 그러면 위 데이터의 B사는 핵심 부품 공급사로 분류할 수 있다. 전제에서 따라오는 결론이니까 가능한 것이다. LLM이 문맥을 보고 그럴듯한 설명을 생성하는 것과는 다른 종류의 추론이다. 다만 여기서 B사가 위험한 공급사라는 결론까지 나오는 것은 아니다. 핵심 부품을 공급하는 것과 납기 위험이 높은 것은 별도로 정의해야 하는 조건이다.

사실 이런 차이는 데이터 입력을 검사할 때 더 분명하게 드러난다. OWL은 열린 세계 가정(Open World Assumption)을 따른다. 어떤 내용이 기록되어 있지 않다고 해서 없다고 단정하지 않는 것이다. 공급사의 인증 정보가 없다면 인증을 안 받았을 수도 있지만, 아직 그 정보를 연결하지 않았을 수도 있다. ‘직원에게 관리자가 최소 한 명 있다’는 공리를 적었다고 현재 데이터의 관리자 ID가 반드시 채워져 있어야 하는 것도 아니다.

그런데 실제 업무에서는 인증 만료일이 입력되지 않았으면 심사를 진행하지 못하게 해야 할 수 있다. 이럴 때는 SHACL로 검사할 RDF 데이터와 shape를 정하고 필수값이나 개수, 자료형 같은 조건을 검증한다. 이건 주어진 데이터를 검사하는 것이지 현실에 대한 모든 정보를 알고 있다는 선언은 아니다. ‘인증이 있는지 모른다’와 ‘그러니까 지금 승인하면 안 된다’는 동시에 성립할 수 있다. 추론과 업무상 검증을 같은 것으로 생각하면 구현할 때부터 어긋나는 셈이다.

RDFS의 domain과 range도 DB의 입력 제약처럼 이해하면 곤란하다. 가령 supplies의 domain을 Supplier로 정했을 때 X가 무언가를 공급한다는 진술이 있으면, X를 Supplier로 추론할 수 있다. 잘못된 값을 넣으면 거부할 거라고 기대했는데 오히려 타입이 붙는 것이다. 용어의 뜻을 아는 것과 그 시스템이 실제로 어떻게 동작하는지 아는 것이 다르다는 이야기는 이런 데서 나온다.

결국 데이터는 어디서 가져오는가

개념을 정의했으면 이제 실제 데이터를 가져와야 한다. RDF 그래프를 조회할 때 사용하는 언어가 SPARQL이다. 제품 Z에서 사용하는 핵심 부품과 그 부품의 공급사를 찾고 싶다면 다음처럼 관계의 패턴을 적을 수 있다.

PREFIX ex: <https://example.com/supply/>
SELECT ?part ?supplier
WHERE {
  ex:ProductZ ex:usesPart ?part .
  ?part a ex:CriticalPart .
  ?supplier ex:supplies ?part .
}

여기서 주의할 것은 앞의 Turtle에는 Battery라는 타입만 적혀 있다는 점이다. CriticalPart로도 찾고 싶으면 추론된 타입을 미리 저장하거나 적절한 추론 설정을 적용해야 한다. SPARQL을 사용한다고 OWL 추론이 알아서 실행되는 것은 아니다. 정의를 적어둔 것과 그 정의를 활용해서 질의하는 환경을 만드는 것은 별개의 작업이다.

그렇다고 기존 사내 RDB를 전부 버리고 그래프 DB로 옮겨야 하는 것은 아니다. 필요한 데이터를 RDF로 복제해서 저장할 수도 있고, 원래 DB에 매핑을 걸어서 접근할 수도 있다. 이런 의미 모델을 통해 데이터에 접근하는 방식을 OBDA(Ontology-Based Data Access)라고 한다. R2RML은 관계형 데이터를 RDF로 연결하는 매핑을 기술하는 언어이고, 실제 질의 재작성은 이를 지원하는 엔진이 맡는다. 물론 어떤 OWL 정의든 전부 효율적인 SQL로 바뀌는 것은 아니다. 표현할 수 있는 범위와 실행 비용을 같이 봐야 한다.

자연어 질문을 SQL로 바꾸는 것이 Text-to-SQL이고, SPARQL로 바꾸는 것이 Text-to-SPARQL이다. 납품 이력을 대량으로 집계하는 일은 RDB에 맡기고, 제품과 공급사 사이의 관계는 그래프에서 찾고, 계약 조건은 문서 검색으로 가져올 수 있다. 그렇게 찾은 결과와 출처를 모델이 참고할 context로 구성하는 것이다. RAG라고 해서 반드시 벡터 유사도 검색만 해야 하는 것도 아니다.

물론 위 그림은 가능한 구성 중 하나다. 서로 독립적인 조회라면 병렬로 실행할 수 있지만 공급사 ID를 먼저 알아야 계약을 찾을 수 있다면 순서가 생긴다. OBDA 엔진이 SPARQL을 SQL로 바꿔주는 경우에는 LLM이 다시 SQL을 생성할 필요도 없다. 이런 구성을 이해하지 않고 이름이 알려진 기술을 전부 붙여놓는다고 더 좋은 시스템이 되는 것은 아니다.

그리고 쿼리 문법이 맞는 것과 답이 맞는 것도 다르다. 출고일과 입고일을 혼동했을 수도 있고, 같은 공급사를 중복으로 조인했을 수도 있다. 사용자가 볼 권한이 없는 계약서를 가져올 수도 있다. 스키마 연결부터 실행 계획, 권한 검사, 결과 검증, 출처 기록까지 실제로 구현해야 하는 부분이 남아 있다. 조회가 아니라 데이터를 수정하는 행동이라면 승인과 실패했을 때의 복구도 필요하다. 자연어로 물어볼 수 있다는 것은 이 과정이 사용자에게 덜 보인다는 뜻이지, 이 과정이 없어졌다는 뜻은 아니다.

뭘 만들 것인지부터 정해야 한다

그래서 온톨로지 설계에서 중요한 작업 중 하나가 도메인의 암묵지를 꺼내는 것이다. 현업 담당자는 당연하게 알고 있지만 데이터나 문서에는 명시되어 있지 않은 지식들이 있다. ‘원래 이렇게 해요’라고 말하는 부분인데, 막상 시스템에 넣으려고 물어보면 생각보다 예외가 많다.

납기 지연만 해도 그렇다. 구매팀은 계약 납기일을 넘겼는지 보고, 물류팀은 물류센터에 도착한 날짜를 본다. 생산팀은 늦게 도착했더라도 안전재고로 버텼으면 생산에는 문제가 없었다고 할 수 있다. 계약을 지켰는지와 생산이 위험한지는 서로 다른 판단인데, 이를 전부 ‘지연’이나 ‘위험’이라는 말로 묶어버리면 모델을 아무리 잘 만들어도 원하는 답이 나오기 어렵다.

이때 사용하는 것이 CQ(Competency Question)다. 우리가 만드는 온톨로지가 어떤 질문에 답할 수 있어야 하는지 적어보는 것이다. ‘위험한 협력사를 알려줘’라고만 하면 위험의 뜻부터 정해져 있지 않다. 그래서 지난 30일 동안 계약 납기일을 이틀 이상 넘긴 납품이 있는지, 해당 부품의 재고가 5일 미만인지, 그로 인해 영향받는 제품은 무엇인지 묻는 식으로 구체화한다. 대체 공급사를 찾는 것이 목적이라면 유효한 인증과 근거 데이터의 출처도 필요할 것이다.

이렇게 질문을 적으면 납품, 재고, 제품, 협력사, 인증 사이에 어떤 연결이 필요한지 보이기 시작한다. 하지만 재고 5일을 평균 사용량으로 계산할지 확정된 생산계획으로 계산할지는 여전히 정해야 한다. CQ를 잘 썼다고 정의가 전부 끝난 것은 아니다. 실제 데이터와 기대하는 정답을 연결하면 질의 테스트로 발전시킬 수 있고, 기존 업무에 걸리던 시간이나 오류 비용과 비교하면 효과를 평가하는 데도 사용할 수 있다. 다만 CQ 자체가 ROI를 보장하는 것은 아니다.

이런 목적과 범위, 사용자, 용도, 요구사항 등을 합의해서 적어두는 문서가 ORSD(Ontology Requirements Specification Document)다. NeOn 방법론에서 제안한 산출물이지 모든 프로젝트에서 반드시 따라야 하는 국제 표준 양식은 아니다. 이름보다 중요한 것은 이번에 뭘 하고 뭘 하지 않을 것인지 정하는 일이다. A사라면 국내 공장 하나, 제품 두 종류, 핵심 부품 세 종류부터 시작할 수 있다. ERP의 납품과 재고, 인증 문서는 연결하되 환율이나 날씨 예측은 제외하고 공급사를 자동으로 제재하는 기능도 넣지 않는 식이다. 관련 있어 보인다고 다 넣기 시작하면 비용을 가늠하기가 더 어려워진다.

설계하는 방향도 하나로 정해져 있지는 않다. 상위 개념부터 내려오는 top-down, 실제 데이터에서 개념을 잡아가는 bottom-up, 핵심 CQ에 필요한 개념부터 양쪽으로 확장하는 middle-out이 있다. 어느 방식을 쓰든 데이터와 질문을 오가면서 확인해야 한다. 개념만 잘 정리해 놓고 필요한 데이터를 못 구해도 문제고, 기존 ERP 컬럼을 그래프로 옮겨놓기만 하고 정작 필요한 질문에 답하지 못해도 문제다.

만들어놓은 다음은 누가 책임지는가

내가 온톨로지에 회의적인 부분은 사실 이런 모델을 만들 수 있느냐보다는, 만드는 데 얼마나 들고 계속 사용하는 데 얼마나 들 것인지 가늠하기 어렵다는 점이다. 시스템마다 뜻이 어긋나 있고 관계를 반복해서 따라가야 하며 여러 서비스가 같은 규칙을 재사용한다면 분명 도움이 될 수 있다. 하지만 정해진 매출 집계는 SQL 뷰로 충분할 수도 있고, 규정 문서에 대한 질문은 검색을 잘 만드는 것으로 해결할 수도 있다. 온톨로지가 할 수 있다는 이유만으로 온톨로지로 해야 하는 것은 아니다.

처음에는 현업 인터뷰를 하고 용어에 합의하고 식별자를 정리해야 한다. 매핑과 권한, 테스트도 만들어야 한다. 운영을 시작하면 원천 DB가 바뀌고 데이터 오류가 들어오고 규칙도 바뀐다. 추론이나 저장, 모델 사용료뿐 아니라 그 변경을 이해하고 반영하는 사람의 시간도 비용이다. 클래스가 몇 개이고 그래프 DB 가격이 얼마인지만 알아서는 전체 공수를 예상하기 어렵다.

예를 들어 A사가 납기 기준을 출고일에서 물류센터 도착일로 바꾸었다고 하자. 주말은 제외하고 긴급 주문에는 예외를 둔다. 언뜻 보면 정의만 수정하면 되는 것 같은데, 실제 도착 시각이 데이터에 있는지부터 확인해야 한다. 휴일 캘린더가 필요하고, 매핑과 계산을 고치고 테스트해야 한다. 과거 보고서까지 새 기준으로 다시 계산할 것인지도 정해야 한다. 같은 ‘지연’이라는 이름으로 숫자를 비교했는데 사실은 기준이 달라진 것이라면 정책 변경을 성능 개선으로 착각할 수도 있다. 그래서 버전과 적용 시점, 데이터 출처를 남겨야 한다.

필요한 데이터가 애초에 없다면 다시 현업과 이야기해야 한다. 다른 지표를 대신 쓸 것인지, 입력 절차를 바꿀 것인지, 아니면 서비스 범위를 줄일 것인지 결정해야 한다. 철학적인 정의를 먼저 완성한 다음 엔지니어에게 넘기면 끝나는 구조가 아니라, 정의하고 구현하고 확인하는 과정이 계속 돌아가는 것이다.

이 상황에서 뭐가 더 중요하냐고 묻는 것이 얼마나 도움이 될까? 개념 변경을 승인할 사람과 데이터 매핑을 수정할 사람, 배포하고 롤백할 사람은 분명하게 정해야 한다. 책임을 구분하는 일은 중요하다. 다만 그걸 어느 학문이 본체이고 나머지가 부속인지를 가리는 문제로 바꿀 필요는 없다는 것이다. 지금 어디가 막혔는지는 판단할 수 있어도 언제나 더 중요한 분야 하나를 정해둘 수는 없다.

물론 한 사람이 전부 잘해야 한다는 이야기도 아니다. 현업 담당자와 모델링 담당자, 데이터 엔지니어와 ML·서비스 엔지니어가 각자 어떤 전제로 판단했고 어디까지 가능한지를 전달할 수 있어야 한다. 내가 모르는 부분이 있다는 것을 아는 것과 모든 분야의 전문가가 되는 것은 다른 요구다.

그래서 ‘구축하고 써봐야 안다’는 말 자체를 틀렸다고 생각하지는 않는다. 실제로 해봐야 드러나는 문제가 있으니까. 다만 그 말이 비용이나 효과에 대한 질문을 피하는 답변이 되어서는 안 된다. 불확실하면 작게 검증해야 한다. A사라면 우선 CQ 15개 정도를 골라 현재 업무 방식, SQL이나 RAG 기반 대안, 온톨로지를 사용한 방식을 같은 데이터 시점과 권한 조건에서 비교해 볼 것이다. 정답률뿐 아니라 근거가 맞는지, 사람이 재확인하는 데 얼마나 걸리는지, 응답 시간은 어떤지, 규칙과 매핑을 수정하는 데 몇 시간이 필요한지도 같이 봐야 한다. 이 숫자는 실험 계획의 예시이지 실제 성과는 아니다.

여기서 데이터 정리의 효과를 전부 온톨로지의 효과로 계산하지 않는 것도 중요하다. 중복 공급사 코드를 정리해서 좋아진 결과라면 그 정제된 데이터를 기존 방식에 넣었을 때와도 비교해야 한다. 가능하면 같은 데이터에서 온톨로지 계층을 사용한 경우와 사용하지 않은 경우를 나눠봐야 한다는 뜻이다. 그리고 핵심 질문에서 대안보다 낫지 않거나 줄인 업무 시간보다 유지보수 시간이 더 크다면 확대를 멈출 수 있어야 한다. 규칙을 책임질 사람도 정하지 못했다면 더더욱 그렇다. 구축할 수 있다는 것과 운영할 이유가 있다는 것은 다르다.

마지막으로

온톨로지를 정리하면서 느낀 것은 결국 내가 어떤 문제를 풀고 있는지 알아야 한다는, 어쩌면 당연한 이야기였다. 다만 그 문제를 안다는 것이 요구사항을 자연어로 잘 적는 것만을 뜻하지는 않는다. 무엇을 같은 대상으로 볼 것인지 정해야 하고, 실제로 관측할 수 있는 데이터가 무엇인지 알아야 하며, 그 데이터로 어떤 계산을 할 수 있는지도 이해해야 한다. 그리고 결과가 틀렸을 때 어디서 잘못됐는지 구분할 수 있어야 한다.

인문학적인 사고가 중요하지 않다는 것이 아니다. 오히려 중요하기 때문에 ‘AI에게 말을 잘 거는 능력’ 정도로 축소해서 설명하지 않았으면 한다. 반대로 엔지니어링을 안다고 사람과 조직이 원하는 것을 저절로 이해하게 되는 것도 아니다. 수학적으로 타당한 모델이라도 애초에 다른 문제를 풀고 있었다면 쓸모가 없을 수 있다. 둘 중 하나만 잘 배워서 나머지를 대체할 수 있는 구조가 아닌 것이다.

주니어 채용이 어렵다는 소식을 보고 CS를 배울 이유가 사라졌다고 말하는 것은 그래서 성급하다고 생각한다. 결과를 만드는 일이 쉬워질수록 그 결과를 판단할 지식은 더 필요하다. 주니어에게도 실제 문제를 정의하고 구현하고 실패해 보는 과정이 있어야 그 판단을 배울 수 있다. AI가 해주니까 몰라도 된다고 하면 결과는 받아볼 수 있어도 왜 잘못됐는지는 계속 모를 것이다.

아 그래서 온톨로지는 철학이냐 엔지니어링이냐고? 나는 그걸 굳이 하나로 정해야 하는 이유를 모르겠다. 실무에서 필요한 것이 뭔지 알고, 기술로 가능한 범위를 알고, 그 둘이 바뀔 때 시스템도 같이 고칠 수 있으면 된다. 어느 쪽이 더 중요하다는 결론보다 내가 그 일을 할 수 있는 사람인지부터 고민하는 편이 낫지 않을까.