문서는 쌓여 있는데 왜 못 찾는가

지식관리 시리즈 2/3

들어가며

지난 글에서 저희는 지식이 전달되는 것이 아니라 쌓이는 것이라고 말씀드렸습니다. 업무를 수행하는 행위 자체가 시스템에 족적을 남기고, 그 족적이 조직의 지식이 된다고요.

그런데 여기서 끝이 아닙니다.

쌓는 것과 꺼내 쓰는 것은 전혀 다른 문제입니다.

실제로 많은 조직에서 벌어지는 상황이 이것입니다. 자료는 다 있습니다. 서버 어딘가에, 시스템 어딘가에 분명히 존재합니다. 그런데 아무도 찾지 못합니다.

오늘은 이 문제를 다뤄보겠습니다.

1. 결국 옆 사람에게 물어봅니다

연구소에 자료실이 있습니다. 몇 년치 보고서가 들어 있고, 검색 기능도 있습니다.

그런데 실제로 무언가가 궁금할 때 사람들은 어떻게 할까요.

옆자리 선배에게 물어봅니다.

"예전에 이거 비슷한 거 해본 적 있죠?" 그러면 선배가 대답합니다. "아, 그거 몇 년 전에 김 책임이 했었는데. 아마 서버 어디 있을 거예요."

이 장면이 지식관리의 실제 모습입니다. 시스템이 있는데도 사람에게 묻습니다. 그리고 그 사람이 없으면 자료가 있어도 찾지 못합니다.

여기서 두 가지가 드러납니다.

첫째, 자료의 존재를 아는 것과 자료를 찾을 수 있는 것은 다릅니다. 선배는 "그런 자료가 있다"는 사실을 알고 있었습니다. 그 지식은 시스템이 아니라 여전히 사람 안에 있습니다.

둘째, 그래서 1편의 문제가 반복됩니다. 자료가 어디 있는지 아는 사람이 나가면, 자료는 있는데 없는 것과 같아집니다. 축적은 되었는데 접근이 안 되는 상태입니다.

2. 검색은 무엇을 찾을지 알 때만 작동합니다

"검색하면 되지 않나요?"

이 질문에 답하려면 검색이 언제 작동하는지를 봐야 합니다.

검색은 검색어를 떠올릴 수 있을 때 작동합니다. 특정 원료명을 알면 찾습니다. 과제명을 알면 찾습니다. 담당자 이름을 알면 찾습니다.

그런데 새로 과제를 맡은 사람의 상황은 다릅니다.

무엇을 찾아야 하는지조차 모릅니다. 회사가 이 분야에서 무엇을 축적했는지 모르니 검색어를 떠올릴 수가 없습니다. 정작 필요한 자료가 바로 옆에 있어도 그냥 지나칩니다.

그리고 회사 안에서 쓰는 말이 제각각입니다.

같은 원료를 누구는 국문 표기로, 누구는 영문 약어로, 누구는 사내 코드로 씁니다. 같은 시험을 부르는 이름이 팀마다 다릅니다. 검색어 하나가 어긋나면 결과는 0건입니다.

결과적으로 무슨 일이 벌어지느냐면, "없다"고 결론짓습니다.

몇 번 검색해 보고 안 나오면 회사에 그런 자료가 없다고 판단합니다. 그리고 처음부터 다시 시작합니다. 1편에서 말씀드린 문제가 정확히 여기서 반복됩니다. 이번에는 축적이 안 되어서가 아니라, 축적된 것을 못 찾아서요.

3. 필요한 것은 검색이 아니라 연결입니다

그렇다면 무엇이 필요할까요.

검색은 점입니다. 하나를 겨냥해서 하나를 꺼냅니다. 겨냥할 줄 알아야 작동합니다.

연결은 선입니다. 하나를 열면 그것과 이어진 것들이 함께 보입니다. 무엇을 찾아야 할지 몰라도, 손에 잡힌 하나에서 출발해 관련된 것들에 닿게 됩니다.

구체적으로는 이런 연결입니다.

• 이 과제가 어떤 상위 과제에 속하고, 어떤 후속 과제로 이어졌는가
• 이 원료가 다른 어떤 과제에서 쓰였는가
• 이 판단이 어떤 자료를 근거로 했는가
• 이 결정이 어떤 후속 결정에 영향을 주었는가
• 이 시험 결과가 어떤 가정을 확인하거나 뒤집었는가

새로 과제를 맡은 사람이 과제 하나를 열었을 때, 지금까지 무슨 일이 있었고 무엇과 이어져 있는지가 함께 보이는 것. 이게 목표입니다.

그러면 "물어볼 사람"이 시스템 안으로 들어옵니다. 선배가 머릿속으로 하던 연결을 시스템이 대신하는 것입니다.

이것을 온톨로지라고 부릅니다

이렇게 무엇이 무엇과 어떤 관계로 이어지는지를 정리해 둔 것을 온톨로지(Ontology)라고 합니다. 개념들 사이의 관계를 그려놓은 지도라고 생각하시면 됩니다.

이름은 낯설지만 하는 일은 단순합니다.

• 이 원료는 이 처방에 쓰인다
• 이 시험은 이 가정을 검증한다
• 이 결정은 이 자료를 근거로 했다
• 이 과제는 이 과제의 후속이다

이런 관계들을 사람의 머릿속이 아니라 시스템이 알고 있게 만드는 것입니다.

앞 장에서 선배가 "그거 몇 년 전에 김 책임이 했었는데"라고 답할 수 있었던 것은, 그 선배 머릿속에 이런 관계 지도가 들어 있었기 때문입니다. 온톨로지는 그 지도를 조직의 것으로 만드는 일입니다.

4. 그러려면 데이터가 층을 이뤄야 합니다

연결이 되려면 조건이 있습니다. 데이터가 문서 파일로만 존재해서는 안 됩니다.

저희는 지식 데이터를 네 개의 층으로 봅니다.

① 원본 — 문서 그 자체입니다. 보고서 파일, 시험 결과, 회의록. 대부분의 회사에 이건 있습니다.

② 메타데이터 — 그 문서에 붙는 정보입니다. 언제, 누가, 어떤 과제에서, 어떤 유형의 산출물로 만들어졌는지. 이게 있어야 문서가 맥락을 갖습니다. 파일명만으로는 아무것도 알 수 없습니다.

③ 관계 — 앞 장에서 말한 온톨로지가 실제 데이터로 담기는 층입니다. 이 문서가 근거로 삼은 것, 이 판단이 영향을 준 것, 이 원료가 쓰인 곳. 연결은 여기서 성립합니다.

④ 의미 기반 검색을 위한 형태 — 같은 뜻이지만 다른 말로 쓰인 것을 찾아낼 수 있도록 문서를 변환해 둔 층입니다. 앞서 말한 "검색어가 어긋나면 0건" 문제를 완화합니다.

대부분의 회사는 1층만 가지고 있습니다.

문서는 있는데 메타데이터가 부실하고, 관계는 아예 없습니다. 그래서 검색밖에 할 수 없고, 검색은 앞서 본 한계를 그대로 갖습니다.

중요한 것은 이 층들이 나중에 만들어지지 않는다는 점입니다.

문서를 다 쌓아놓고 나중에 관계를 붙이려고 하면 엄청난 작업이 됩니다. 누가 몇 년치 문서를 열어보고 무엇과 무엇이 이어지는지 판단할까요.

1편에서 말한 족적의 원리가 여기서도 같습니다. 업무를 하는 과정에서 관계가 함께 남아야 합니다. 과제를 등록할 때 상위 과제가 지정되고, 자료를 첨부할 때 어떤 판단의 근거인지가 표시되고, 결정을 기록할 때 무엇을 참고했는지가 남는 식으로요.

5. 분류체계는 만들기보다 유지하기가 어렵습니다

여기서 현실적인 이야기를 하나 더 해야 합니다.

연결과 분류가 작동하려면 분류체계와 표준 용어가 필요합니다. 그리고 이 영역에서 대부분의 조직이 겪는 문제가 있습니다.

먼저, 하나의 계층 구조로는 안 됩니다

가장 흔한 시작이 이렇습니다. 폴더를 만들듯 대분류 아래 중분류, 그 아래 소분류를 두는 하나의 나무 구조를 만듭니다.

그런데 실제 자료는 그 나무에 잘 안 들어갑니다.

어떤 시험 보고서가 있다고 해봅시다. 이 자료는 어떤 기술 영역에 속하고, 어떤 제품군을 위한 것이며, 어떤 과제 유형에서 나왔고, 문서 종류로는 시험 보고서이고, 어느 개발 단계의 산출물입니다.

이게 전부 사실입니다. 그런데 하나의 계층 구조는 이 중 하나만 고르라고 요구합니다.

기술 분류를 기준으로 나무를 만들면 제품으로 찾는 사람이 못 찾고, 제품 기준으로 만들면 기술로 찾는 사람이 못 찾습니다. 그래서 담당자는 매번 "이걸 어디에 넣어야 하나" 고민하게 되고, 사람마다 다른 곳에 넣습니다.

분류는 여러 관점(Dimension)으로 나뉘어야 합니다.

기술 관점, 제품 관점, 과제 유형 관점, 문서 종류 관점, 개발 단계 관점. 각각이 독립된 축이고, 하나의 자료는 여러 축에서 동시에 위치를 갖습니다. 그러면 어느 축으로 접근하든 찾게 됩니다.

이렇게 설계하면 "어디에 넣을까"라는 고민 자체가 없어집니다. 각 축에서 해당하는 값을 고르면 되니까요.

그리고 각 축은 관점이 섞이지 않아야 합니다

여기서 실무적으로 가장 자주 어긋나는 지점이 있습니다.

하나의 축 안에 서로 다른 관점이 섞이는 것입니다.

예를 들어 한 분류 목록에 기술 이름과 제품 이름과 조직 이름이 뒤섞여 있는 경우가 있습니다. 처음에는 그럴듯해 보이지만, 시간이 지나면서 어느 것을 골라야 할지 알 수 없게 됩니다. 하나의 자료가 두 항목에 다 해당하는 상황이 계속 생기기 때문입니다.

하나의 축은 하나의 질문에만 답해야 합니다. 기술 축은 "무슨 기술인가"에만, 제품 축은 "어떤 제품을 위한 것인가"에만 답합니다.

이 원칙을 지키면 얻는 것이 큽니다. 기술이 발전하고 사업이 바뀌어도, 해당 축 안에서 항목을 추가하거나 세분화하면 됩니다. 축의 구조 자체를 흔들지 않아도 됩니다.

새로운 기술이 등장하면 기술 축에 항목을 추가합니다. 하나의 항목이 너무 커지면 둘로 나눕니다. 이때 다른 축은 영향을 받지 않습니다. 변화가 한 축 안에 갇히는 것입니다.

반대로 관점이 섞인 축은 무언가 바뀔 때마다 전체가 흔들립니다. 그래서 손대기가 무서워지고, 손대지 않으니 점점 더 현실과 멀어집니다.

그래서 이렇게 됩니다

이 두 가지를 놓치면 어떤 일이 벌어질까요.

처음에는 잘 만듭니다. 시스템을 구축할 때 시간을 들여 분류체계를 설계합니다. 그럴듯하게 만들어집니다.

문제는 그 다음입니다.

새로운 분야가 들어옵니다. 기존 분류 어디에도 안 맞습니다. 사업이 확장되면서 없던 유형의 자료가 생깁니다. 업계 용어가 바뀝니다.

그런데 분류체계는 그대로입니다. 아무도 손대지 않습니다. 바꾸려면 어디를 건드려야 하는지도 모르고, 바꿨을 때 기존 자료가 어떻게 될지도 모르니까요.

그러면 사람들은 '기타'를 고릅니다.

그리고 몇 년 뒤, 자료의 상당수가 '기타'와 '미분류'에 들어가 있습니다. 분류체계는 형식적으로만 남고 실제로는 작동하지 않습니다.

'기타'가 늘어나는 것은 신호입니다. 분류체계가 현실과 어긋났다는 뜻입니다. 그런데 이 신호를 보는 사람이 없으면 그냥 방치됩니다.

앞선 글에서 저희는 과제 유형 체계도 계속 바뀌어야 한다고 말씀드렸습니다. 분류체계도 정확히 같습니다. 바꿀 수 있는 구조여야 하고, 누가 어떤 신호를 보고 언제 손볼 것인지가 정해져 있어야 합니다.

이 작업은 생각보다 전문 영역입니다

분류체계 설계는 흔히 시스템 구축의 준비 작업 정도로 여겨집니다. 자료 정리하는 일이니 담당자가 알아서 하면 된다고요.

저희 경험으로는 그렇지 않습니다.

그 회사가 무슨 일을 하는지 이해해야 하고, 앞으로 어디로 갈지를 감안해야 하고, 관점을 나누고 각 축을 독립적으로 유지하는 원칙을 알아야 합니다. 그리고 무엇보다 몇 년 뒤에도 버틸 구조인지를 판단할 수 있어야 합니다.

이건 한 번 잘못 잡으면 되돌리기가 매우 어렵습니다. 이미 수천 건의 자료가 그 체계로 분류된 뒤에 축을 바꾸려면, 자료를 전부 다시 분류해야 하기 때문입니다.

저희가 25년간 여러 산업의 연구소에서 이 작업을 함께해 온 이유가 여기 있습니다. 구축 이후에도 변화관리를 함께 수행한다고 말씀드리는 것도 같은 맥락입니다. 분류체계는 완성되는 것이 아니라 유지되는 것이기 때문입니다.

6. AI는 이 지점에서 실제로 도움이 됩니다

최근 이 영역에서 기술적으로 달라진 부분이 있습니다.

분류와 연결은 원래 사람의 일이었습니다. 자료를 등록하면서 분류코드를 고르고, 관련 자료를 지정하고, 키워드를 붙이는 일이요. 그리고 이건 부담이 큽니다. 앞선 글에서 계속 말씀드린 것처럼, 부담이 크면 지속되지 않습니다.

여기서 최근의 기술이 할 수 있는 일이 있습니다.

• 자료를 등록하면 1차 분류를 자동으로 제안하고, 사람은 확인만 합니다
• 표현이 다른 같은 개념을 묶어서 인식합니다
• 새 자료가 들어오면 관련 있을 만한 기존 자료를 제시합니다

이렇게 되면 사람의 일이 "만드는 것"에서 "확인하는 것"으로 바뀝니다. 부담이 크게 줄어듭니다.

다만 여기에 중요한 조건이 있습니다

"AI를 붙이면 알아서 정리해 줄 것"이라는 기대가 있습니다. 그렇지 않습니다.

AI가 분류를 제안하려면 분류체계가 있어야 합니다. 관련 자료를 제시하려면 관계를 표현할 구조가 있어야 합니다. 의미로 찾으려면 그렇게 변환해 둔 층이 있어야 합니다.

순서가 있습니다. 데이터 구조가 먼저이고, AI는 그 위에 얹히는 것입니다.

구조 없이 AI만 도입하면, 잘 정리되지 않은 문서 더미에서 그럴듯한 답을 만들어내는 도구가 됩니다. 그리고 그 답이 맞는지 확인할 방법이 없습니다.

이 이야기는 범위가 커서 별도의 시리즈에서 자세히 다루겠습니다.

정리하며

• 자료가 있는 것과 찾을 수 있는 것은 다릅니다. 시스템이 있어도 결국 사람에게 묻습니다
• 검색은 검색어를 떠올릴 수 있을 때만 작동합니다. 새로 맡은 사람은 그게 안 됩니다
• 필요한 것은 검색이 아니라 연결입니다. 찾을 줄 몰라도 만나게 하는 구조
• 연결이 되려면 데이터가 원본·메타데이터·관계·의미 네 층을 갖춰야 합니다
• 그리고 이 층들은 나중에 만들어지지 않습니다. 업무 과정에서 함께 남아야 합니다
• 분류체계는 하나의 계층 구조로는 안 됩니다. 기술·제품·문서종류 등 여러 관점(Dimension)의 독립된 축이 필요합니다
• 그리고 각 축은 하나의 질문에만 답해야 합니다. 관점이 섞이지 않아야 나중에 항목을 추가하거나 나눌 수 있습니다
• 분류체계는 만들기보다 유지하기가 어렵습니다. 누가 언제 손볼지가 정해져 있어야 합니다
• AI는 이 영역에서 실제로 도움이 됩니다. 다만 구조가 먼저이고 AI는 그 위에 얹힙니다

다음 편 예고

마지막 편에서는 한 걸음 더 들어가 보겠습니다.

1편에서 저희는 "결론만이 아니라 전제가 남아야 한다"고 말씀드렸습니다. 모든 판단은 어떤 가정 위에서 이루어지고, 그 가정이 바뀌면 판단도 다시 봐야 하기 때문입니다.

그런데 실제로는 어떨까요. 규제가 바뀌었을 때, 원료 공급 상황이 달라졌을 때, 경쟁사가 먼저 출시했을 때. 그 변화가 우리의 어떤 판단을 흔드는지 아는 사람이 조직 안에 있을까요.

전제를 기록한다는 것이 무슨 의미인지, 그리고 그것이 어떻게 작동할 수 있는지. 다음 편에서 이어가겠습니다.