지식 재정의; 축적과 활용 — 지식 연결의 온톨로지적 접근

실무 이야기 · AVDE

다 쌓았는데 왜 조회가 안 됩니까

지난 글에서 기업의 지식을 세 층으로 구분했습니다. 판단, 방법, 기록입니다.

그런데 이 셋을 각각 축적해 두기만 하면 될까요. 부족합니다.

문서 서버에 자료는 수만 건 있습니다. 회의록도 연구노트도 남아 있습니다. 그런데 필요한 시점에 조회되지 않습니다.

축적과 활용은 별개의 문제이고, 그 차이를 만드는 것이 연결 구조입니다.

영향 범위를 산정할 수 있습니까

상황을 하나 놓고 보겠습니다.

규제 개정안이 발표되었습니다. 즉시 필요한 것은 하나입니다. 영향 범위 산정. 진행 중인 과제 중 어느 것이 걸리는가.

지금은 대체로 각 담당자에게 확인을 요청합니다. 며칠 뒤 회신이 취합되고, 미회신도 있고, 그 목록의 완결성은 아무도 확신하지 못합니다.

자료가 없어서가 아닙니다. 규제 자료도 과제 계획서도 있습니다.

어느 과제가 해당 규제를 전제로 삼았는지가 데이터로 존재하지 않기 때문입니다.

계획서에는 결론이 있고 규제 자료는 별도 저장소에 있습니다. 양자 간 참조 관계가 없으니 개인의 기억에 의존하게 됩니다.

축적은 어렵지 않습니다. 연결이 어렵습니다.

분류체계는 왜 사장되었습니까

연결을 시도한 방식이 없었던 것은 아닙니다. 분류체계가 그 시도였습니다.

문서 저장 시 분류코드를 부여하고, 작성 부서와 문서 유형과 관련 제품 같은 메타데이터를 속성으로 부착했습니다. 그 축으로 조회하면 관련 자료가 모인다는 발상이었습니다.

세 가지 문제가 순차적으로 발생했습니다.

첫째, 전사 공통 분류체계는 조직별 관점을 수용하지 못했습니다.

분류체계는 본질적으로 단일 트리 구조입니다. 하나의 문서는 하나의 위치에 귀속됩니다. 그런데 동일 자료를 연구소는 기술 관점으로, 마케팅은 제품 관점으로, 인허가는 규제 관점으로 봅니다.

전사 공통으로 설계하면 어느 한 관점이 기준이 되고, 나머지 조직에 중요한 분류는 누락됩니다. 그러면 그 조직은 그 체계를 쓰지 않습니다.

둘째, 검색 기술이 발전하면서 분류의 필요성이 희석되었습니다.

전문 검색이 가능해지자 분류코드를 부여하지 않아도 단어로 찾을 수 있게 되었습니다. 분류 부여는 부담이고 검색은 즉시 되니, 자연스럽게 후자로 이동했습니다.

그런데 자료가 누적되면서 재현율은 높은데 정확도가 낮은 상태가 되었습니다. 검색하면 수백 건이 나오고, 그중 필요한 것을 골라내는 비용이 검색으로 절약한 비용을 상회합니다. 찾을 수는 있는데 활용은 안 되는 상황입니다.

셋째, 분류체계 자체가 갱신되지 않았습니다.

조직도 바뀌고 제품군도 바뀌고 규제 구분도 바뀝니다. 그런데 분류체계는 초기 설계 이후 손대지 않습니다. 개편하면 기존 자료의 재분류가 발생하니 아무도 착수하지 않습니다.

현실과 괴리된 분류는 곧 무의미해집니다. 그렇게 분류 기반 조회는 사실상 사장되었습니다.

차원을 하나 더 늘리는 방식으로는 안 됩니다

여기서 얻을 교훈이 있습니다.

분류체계의 한계를 흔히 차원(Dimension)이 하나라는 데 있다고 봅니다. 연구소는 기술 차원으로, 마케팅은 제품 차원으로, 인허가는 규제 차원으로 보는데 전사 공통 분류는 그중 하나를 골라 고정한 것이니까요.

그래서 차원을 여러 개 두는 다차원 분류가 대안으로 제시되기도 합니다. 문서 하나에 기술 코드와 제품 코드와 규제 코드를 함께 부여하는 방식입니다.

그런데 이것으로도 부족합니다.

차원을 아무리 늘려도 그것은 여전히 문서에 부착되는 속성입니다. 문서와 문서 사이의 관계는 표현되지 않습니다. 같은 분류에 속한다는 것 외에는 아무 정보가 없습니다.

필요한 것은 분류 차원을 늘리는 것이 아니라, 관계를 표현하는 것입니다.

이 판단이 저 전제를 근거로 한다. 이 과제가 저 전략에 귀속된다. 이 의사결정이 저 의사결정에서 파생되었다. 이것은 분류가 아니라 관계입니다. 그리고 관계는 속성으로 표현되지 않습니다.

설계 판단 네 가지

무엇이 갖춰져야 연결이 성립하는지, 네 가지로 정리하겠습니다.

첫째, 무엇을 객체로 승격할 것인가.

레고로 비유하면 이해가 빠릅니다.

계획서를 하나의 통짜 문서로 두는 것은 프라모델에 가깝습니다. 완성품 하나로 존재하고, 전제는 그 표면에 인쇄된 글자입니다. 떼어낼 수 없고, 그 문서를 열어야만 확인됩니다. 다른 계획에서 같은 전제를 쓰고 있어도 서로 알 방법이 없습니다.

객체로 승격한다는 것은 레고 블록으로 만드는 것입니다. 전제가 독립된 블록으로 존재합니다. 그 자체를 집어 들 수 있고, 이 블록이 어느 계획에 끼워져 있는지를 역으로 확인할 수 있습니다.

차이는 조회 방향입니다. 속성이면 과제에서 전제로 향하는 단방향만 성립합니다. 객체이면 양방향이 성립합니다. 규제가 개정되었을 때 그것을 전제로 삼은 대상을 역방향으로 조회할 수 있습니다.

의사결정과 활동도 동일합니다. 의사결정을 회의록 내부 서술로 두면 그 회의를 열어야 확인되고, 독립 객체로 두면 의사결정 간 계보 추적이 가능합니다. 활동을 과제 내부 단계로 두면 그 과제 안에서만 보이고, 표준코드가 부여된 객체로 두면 동일 코드로 전체 과제를 횡단 조회할 수 있습니다.

그리고 블록이 서로 끼워지려면 결합부 규격이 동일해야 합니다. 그것이 넷째에서 다룰 표준코드입니다.

이 블록 하나를 저희는 Knowledge Package라고 부릅니다. 무엇이 담기는지는 뒤에서 정리하겠습니다.

둘째, 관계를 데이터로 저장할 것인가.

조회 시점에 연산하는 방식과, 관계 자체를 레코드로 저장하는 방식이 있습니다.

차이는 탐색 깊이입니다. 전자는 1단계까지는 무리가 없으나 2단계부터 급격히 어려워집니다. 후자는 그래프 탐색이 가능합니다.

실무에서 필요한 정보는 대체로 2~3단계 건너에 있습니다. 규제 개정 → 영향받는 전제(1단계) → 그 전제 위에 성립한 판단(2단계) → 그 판단에서 착수된 과제(3단계). 여기까지 도달해야 영향 범위가 산정됩니다.

셋째, 변경을 어떻게 처리할 것인가.

판단은 시간이 지나면 변경됩니다. 당시 A안이었으나 현재는 B안입니다.

갱신하면 현재 결론만 남고 변경 사유가 소멸합니다. 이력만 남기면 시점과 내용은 확인되나 계보가 표현되지 않습니다. 변경 로그일 뿐입니다.

판본을 보존하고 관계로 연결하면 다릅니다. 원 기록은 유지하고 신규 기록이 선행 판단을 참조합니다. 과오를 남기는 것이 아니라 궤적을 남기는 것입니다.

넷째, 같은 활동을 같은 이름(표준)으로 부르는가.

동일 활동이 과제별로 상이한 명칭으로 기록되어 있으면 "기관 선정"으로 조회해도 과거 사례가 회수되지 않습니다. 어느 과제는 "업체 선정", 어느 과제는 "위탁처 결정"이니까요.

표준코드는 흩어진 것을 한자리에 모으는 이름입니다. 이름이 같아야 모입니다. 그리고 과제 유형이 달라도 활동 코드가 같으면 참조 가능합니다.

이것이 온톨로지적 접근입니다

네 가지가 갖춰지면 무엇이 구성되는지 보겠습니다.

전략 하위에 과제가 귀속되고, 과제마다 전제가 연결되고, 그 전제는 특정 판단의 근거이며, 그 판단에는 기각안이 병기되고, 각 활동에는 산출 문서가 참조로 붙습니다.

개별 객체가 각자 존재하는 것이 아니라, 객체 사이에 Relation이 정의되어 하나의 네트워크를 이룹니다.

앞서 분류체계를 트리 구조라고 했습니다. 트리는 부모가 하나뿐이고 위에서 아래로만 이어집니다. 네트워크는 다릅니다. 하나의 객체가 여러 방향으로 이어지고, 어느 쪽에서든 진입할 수 있습니다.

용어를 정리하면 이렇습니다. 온톨로지는 개념을 객체와 속성과 관계로 정의한 체계이고, 그 위에 데이터가 적재되어 형성된 망이 지식그래프입니다. 온톨로지가 스키마라면 지식그래프는 인스턴스입니다.

중요한 것은 이를 별도 구축 과제로 삼지 않는다는 점입니다.

온톨로지 구축이라 하면 전문가가 착수해 개념 체계를 설계하는 그림을 떠올립니다. 그러면 기간이 소요되고, 완성 시점에는 이미 현실과 괴리가 발생합니다. 앞서 분류체계가 사장된 경로와 동일합니다.

정의할 것은 골격뿐입니다. 업무 유형, 활동, 전제 유형, 관리 방법.

인스턴스와 관계는 업무 수행 과정에서 생성됩니다. 과제를 등록하면 귀속 관계가 생기고, 판단을 기록하면 근거 관계가 생깁니다. 기록이 업무의 부산물이어야 하듯, 그래프도 부산물입니다.

Knowledge Package — 블록 하나의 정체

앞에서 블록이라 부른 것에 이름을 붙이겠습니다.

Knowledge Package는 표준화된 활동 코드 하나를 단위로, 그 활동에 관한 기업의 지식이 모여 있는 덩어리입니다.

왜 활동 단위인지부터 말씀드리는 편이 낫겠습니다.

과제 단위로 묶으면 그 과제가 종료되는 순간 죽은 자료가 됩니다. 다음 과제에서 다시 열어 볼 이유가 없습니다.

문서 단위로 묶으면 맥락이 없습니다. 견적서 한 장으로는 왜 그 기관을 골랐는지 알 수 없습니다.

활동 단위여야 반복됩니다. "기관 선정"은 과제가 바뀌어도 계속 수행됩니다. 그리고 반복되어야 축적됩니다.

이 Knowledge Package 하나에 네 개 층이 담깁니다.

1층 · 정의 — 코드, 명칭, 활동의 정의, 결합 가능한 업무 유형. 회사 전체에 하나이고 거의 불변입니다. 관리자만 손댑니다.

2층 · 유형별 설정 — 체크리스트, 관리 수준, 필수 산출물, 이행 조건. 업무 유형에 따라 달라집니다. 같은 활동 코드라도 어느 유형에 끼우느냐에 따라 확인할 것이 다릅니다. 이 층은 계속 갱신됩니다.

3층 · 수행 인스턴스 — 수행자와 기간, 확인 결과, 산출 문서, 검토 의견, 판단과 기각안, 전제와 감시 조건. 과제마다 생기고 계속 축적됩니다.

4층 · 관계 — 상위 귀속, 선행과 후행, 판단의 계보, 전제의 파급, 동일 코드 참조. 업무를 수행하면 자동으로 생성됩니다.

층마다 성격이 다릅니다. 위로 갈수록 엄격하고 안 바뀌며, 아래로 갈수록 느슨하고 계속 늘어납니다. 그리고 1·2층은 사람이 정의하고, 3·4층은 업무가 채웁니다.

Knowledge Package를 집어 들면 이 넷이 함께 딸려 옵니다. 그 활동을 어떻게 하는 것인지, 지난번에는 어떻게 했는지, 그때 무엇을 판단했는지, 그리고 그것이 어디와 이어져 있는지요.

그러면 무엇이 가능해집니까

전개 — 과제를 열면 착수 근거가, 그 판단을 열면 기각안이, 그 전제를 열면 현재 상태가 나옵니다. 인수인계 시 이 경로를 따라가면 됩니다.

역추적 — 규제 개정 시 영향 범위를 조회로 산정합니다. 개인의 기억에 의존하지 않습니다.

유사 판단 소환 — 현재 안건과 유사한 과거 판단을 불러옵니다. 이것은 문서 검색으로는 불가능합니다. 문장 유사도가 아니라 구조 유사도를 봐야 하기 때문입니다.

RAG와 그래프 탐색은 다른 연산입니다

문서를 적재하고 질의하면 유사도 검색으로 관련 구간을 찾아 답변을 생성하는 방식, 즉 **RAG(검색 증강 생성)**가 널리 쓰입니다. 유효한 방식입니다.

다만 문장 유사도로 검색합니다. "해당 물질 자료가 어디 있는가"는 잘 처리하지만, "이 규제가 우리 어느 계획에 영향을 미치는가"는 처리하지 못합니다. 그 연결이 문서에 기재되어 있지 않기 때문입니다.

그래프 위에서는 관계를 따라 탐색합니다. 명칭보다 중요한 것은 두 연산이 서로 다르다는 점입니다.

구조가 선행하고, AI는 그 위에서 작동합니다.

시스템 검토 시 확인하실 사항

전제를 기준으로 역방향 조회가 됩니까.

의사결정 간 계보가 추적되고, 이전 판본이 보존됩니까.

관계 탐색이 몇 단계까지 가능합니까.

동일 활동 코드로 횡단 조회가 되고, 산출 문서까지 회수됩니까.

절차나 양식을 변경하면 과거 데이터의 조회 가능성이 유지됩니까.

이 다섯 가지로 해당 시스템의 구조가 대체로 파악됩니다. 기능 목록에는 드러나지 않는 부분입니다.

정리하면 이렇습니다.

축적과 활용은 별개이며, 그 차이를 만드는 것이 연결 구조입니다.

분류체계는 그 해법이 아니었습니다. 차원이 하나라 조직별 관점을 수용하지 못했고, 갱신되지 않아 현실과 괴리되었으며, 차원을 늘려도 문서 간 관계는 표현되지 않습니다.

설계 판단은 넷입니다. 객체 승격, 관계의 데이터화, 판본과 계보 보존, 그리고 같은 활동을 같은 이름으로 부르는 것.

그 결과 만들어지는 단위가 Knowledge Package입니다. 활동 코드 하나에 정의와 설정과 수행 이력과 관계가 함께 담긴 덩어리입니다.

그 결과가 온톨로지적 접근입니다. 별도 구축 과제가 아니라, 골격만 정의하면 업무가 채웁니다.

AI는 그 위에서 작동합니다. 문장 유사도 비교와 관계 탐색은 다른 연산입니다.

여기까지가 개념입니다. 다만 층위에 따라 실제 모습은 상당히 다릅니다. 다음 두 글에서 각각의 적용 사례를 다루겠습니다. 전략과 Project Pool 단계, 그리고 실험과 연구노트 단계입니다.

저희는 25년 동안 제약·바이오·화장품·화학·건설·제조 분야에서 R&D 관리 체계를 함께 만들어 왔습니다. 축적 구조가 아니라 활용 구조를 함께 설계합니다. 이야기 나눌 자리가 필요하시면 언제든 연락 주십시오.

읽어주셔서 감사합니다.