그 자료가 있다는 걸 아는 사람만 찾을 수 있습니다

구축의 순서 - 4

3년 전에 비슷한 검토를 했다는 이야기를 들었습니다. 그 자료를 찾아봅니다.
공유 폴더를 뒤집니다. 연도별로 들어가 보고, 과제별로 들어가 보고, 부서별로도 봅니다. 비슷한 것은 몇 개 나오는데 그건 아닙니다.
검색을 해봅니다. 제목에 그 말이 안 들어 있으면 안 나옵니다.
한 시간쯤 지나면 결국 이렇게 됩니다. 전임자에게 전화를 겁니다.
그리고 대개 이런 답이 옵니다. "아, 그거요. 제 폴더에 있을 거예요. 찾아서 보내드릴게요."

폴더는 하나의 자리만 줍니다

폴더가 잘못 만들어져서가 아닙니다. 폴더라는 방식 자체가 그렇습니다.
하나의 자료는 하나의 폴더에 들어갑니다. 그러니 만들 때 정해야 합니다. 연도로 나눌 것인가, 과제로 나눌 것인가, 제품으로 나눌 것인가.

무엇으로 나누든 나머지로는 못 찾습니다.

과제별로 넣었다면 "이 기술을 다룬 자료 전부"가 안 나옵니다. 여러 과제에 흩어져 있으니까요. 제품별로 넣었다면 "작년에 검토한 것 전부"가 안 나옵니다.

지난 글에서 하나의 트리로는 안 된다고 했습니다. 폴더가 바로 그 트리입니다. 위에서 아래로 뻗고, 자료 하나는 자리 하나만 갖습니다.

개인 폴더는 다른 문제입니다

공유 폴더 이야기를 했는데, 실제로 더 많은 자료는 개인 폴더에 있습니다. 그리고 개인 폴더는 성격이 다른 문제입니다.

공유 폴더는 구조가 안 맞아 못 찾는 것입니다. 어딘가에 있다는 건 압니다. 시간을 들이면 찾을 수도 있습니다.

개인 폴더는 다릅니다. 그 자료가 존재한다는 것조차 모릅니다.

3년 전 담당자가 조사한 자료, 검토했다가 접은 후보, 실패한 시도의 기록. 보고서로 올라간 것 말고 그 과정에서 만들어진 것들은 대개 개인 폴더에 남습니다. 회사 어디에도 그것이 있다는 표시가 없습니다.

그러니 찾을 방법이 없습니다. 없는 것을 찾을 수는 없으니까요.

여기서 한 가지 짚고 가겠습니다. 담당자가 숨긴 것이 아닙니다. 그 자료가 모일 자리가 회사에 없었기 때문입니다. 특정 과제의 것도 아니고 부서 공유 폴더에 넣자니 폴더 이름이 부서지 기술이 아닙니다. 그래서 자기 폴더에 둡니다. 그게 가장 합리적인 선택이었습니다.

그리고 그 담당자가 회사를 옮기면, 파일은 하드디스크에 남습니다. 사라지는 것은 그 파일들이 무엇과 관련되어 있었는지입니다.

검색으로 해결되지 않습니다

여기서 흔히 나오는 답이 있습니다. 검색을 잘 만들면 된다, 전문 검색을 붙이자, 요즘은 AI로 찾아준다더라.

부분적으로는 맞습니다. 그런데 검색에는 전제가 하나 있습니다.

무엇을 찾을지 알아야 검색어를 넣습니다. 3년 전에 그런 검토가 있었다는 사실 자체를 모르면, 검색창 앞에서 무슨 말을 넣어야 할지 모릅니다.

그리고 지난 글에서 본 문제도 그대로입니다. 그때 담당자는 "방출제어"라고 적었는데 지금 사람은 "서방화"로 검색합니다. 같은 것인데 안 나옵니다.

필요한 것은 검색이 아니라 조회입니다.

찾으러 가는 것이 아니라, 기술 하나를 열었을 때 거기 연결된 것이 다 나오는 것입니다. 무엇이 있는지 몰라도 됩니다. 열면 보이니까요.

그러면 무엇을 남겨야 합니까

자료를 잘 정리하는 것으로는 안 됩니다. 자료 말고 관계를 남겨야 합니다.

지난 글에서 관리 대상을 만들었습니다. 기술 하나가 독립된 항목으로 존재하고 자기 코드와 정의를 갖습니다.

이제 그 대상들을 잇습니다.

• 이 과제는 어느 기술을 다루는가
• 이 결정은 어느 과제에서 나왔는가
• 이 결정은 어떤 전제 위에 서 있는가
• 이 조사 자료는 어느 기술에 대한 것인가
• 이 위탁 이력은 어느 기술의 시험이었는가

이런 연결 하나하나가 데이터입니다. 파일이 아니라 연결이요.

그리고 이 연결이 있으면 조회가 됩니다. 기술 하나를 열면 거기 걸린 과제·결정·조사 자료·위탁 이력이 전부 나옵니다. 누가 무엇을 어디에 넣었는지 몰라도 됩니다.

관계를 남긴다는 것에는 세 층이 있습니다

여기서 층을 나눠야 합니다. 셋이 다 필요한데, 흔히 첫 번째만 이야기됩니다.

1층 — 관계를 표현할 수 있는가

무엇이 무엇과 어떤 관계인지를 데이터로 적을 수 있어야 합니다. 폴더로는 안 되고, 표로도 부족합니다. 여러 방향으로 뻗는 관계를 그대로 담는 방식이 필요합니다.

이걸 다루는 방식을 온톨로지라고 부릅니다. 지난 글에서 대표 용어와 별칭을 정리했는데, 사실 그것이 첫 단계였습니다. 무엇을 무엇이라 부를지 정하고, 그다음에 무엇이 무엇과 어떤 관계인지를 정합니다.

2층 — 그 관계가 저절로 생기는가

여기서부터가 다른 이야기입니다.

관계를 표현할 수 있다는 것과, 그 관계가 실제로 만들어지는 것은 별개입니다. 누군가 앉아서 관계를 그려 넣어야 한다면 그건 3년 뒤에 멈춥니다. 앞선 글에서 본 분류체계와 같은 운명입니다.

그래서 관계는 업무의 부산물로 생겨야 합니다. 과제를 등록할 때 기술을 고르면 연결이 생깁니다. 결정을 기록할 때 전제를 적으면 연결이 생깁니다. 관계를 만드는 별도 작업이 없어야 합니다.

3층 — 그 관계가 무언가를 부르는가

마지막 층입니다.

관계가 데이터로 있으면 조회가 됩니다. 그런데 조회는 사람이 열어봐야 일어납니다. 아무도 안 열면 아무 일도 안 일어납니다.

한 걸음 더 가면, 관계가 스스로 무언가를 부릅니다. 규제 개정 소식이 들어오면, 그 조건을 전제로 삼은 결정들이 조회되고, 그 결정에 걸린 과제 담당자에게 검토 요청이 갑니다. 사람이 "이거 우리랑 관련 있나" 하고 찾아보는 것이 아니라, 관계가 알려줍니다.

정리하면 이렇습니다.

온톨로지는 1층의 이야기입니다. 표현 방식이고, 필요한 기술입니다. 다만 그것만으로는 2층과 3층이 따라오지 않습니다.

관계도를 잘 그리는 것과, 그 관계가 업무에서 저절로 생기고 신호가 들어오면 판단을 부르는 것은 다른 문제입니다. 앞의 것은 기술이고 뒤의 것은 구조와 운영입니다.

먼저 설계하려 들면 3년 걸립니다

여기서 흔한 함정이 있습니다.

관계를 남긴다고 하면, 회사의 모든 관계를 먼저 그려보자는 시도가 나옵니다. 무엇과 무엇이 어떤 관계인지 전부 정의하고 나서 시작하자는 것이죠.

그러면 시작을 못 합니다.

회사가 다루는 것들 사이의 관계는 끝이 없습니다. 그리고 대부분은 실제로 쓰이지 않습니다. 완벽한 관계도를 그리는 데 3년을 쓰고, 그사이 현실은 또 달라집니다.

업무에서 실제로 나오는 관계만 남기면 됩니다.

과제를 등록할 때 기술을 고릅니다 — 관계 하나가 생깁니다. 결정을 기록할 때 전제를 적습니다 — 관계 하나가 생깁니다. 조사 보고서를 올릴 때 기술을 고릅니다 — 관계 하나가 생깁니다.

이 정도면 충분합니다. 그리고 이것들은 어차피 해야 하는 일입니다. 관계를 만들려고 따로 하는 일이 아닙니다.

지난 글의 원칙이 여기서도 같습니다. 처음에 잘 만드는 것보다 계속 생기는 것이 중요합니다.

정리하면

폴더는 하나의 자리만 줍니다. 무엇으로 나누든 나머지로는 못 찾습니다.

개인 폴더는 더 심각합니다. 공유 폴더는 못 찾는 것이지만, 개인 폴더는 있다는 것조차 모릅니다. 그리고 그건 담당자 탓이 아니라 모일 자리가 없었기 때문입니다.

검색으로는 안 됩니다. 검색은 찾을 것이 있다는 걸 알 때 쓰는 도구입니다. 필요한 것은 열면 다 나오는 조회입니다.

자료가 아니라 관계를 남깁니다. 그리고 그 관계는 세 층을 다 갖춰야 합니다. 표현할 수 있고, 저절로 생기고, 무언가를 부르는 것까지요.

전부 먼저 설계하지 않습니다. 업무에서 나오는 관계만 남기면 됩니다.

다음 편에서는

여기까지가 무엇을 만들 것인가의 이야기였습니다. 담을 것을 골랐고, 담을 자리를 만들었고, 그것들을 잇는 방식까지 봤습니다.

그러면 이제 시작할 수 있습니까.

아직 아닙니다. 시작하기 전에 갖춰야 할 것이 있고, 그것을 어디까지 갖추면 되는지가 다음 편의 이야기입니다. 마스터 없이 시작하면 데이터가 쌓여도 조회가 안 됩니다.