"우리 회사 분류체계 좀 봅시다"라고 하면 벌어지는 일

구축의 순서 - 3

"저희는 부서별로 씁니다"
분류체계를 보자고 하면 대개 이 답이 먼저 돌아옵니다.
그러면 부서별 것을 봅니다. 제제팀 것과 분석팀 것이 다릅니다. 같은 물질을 다르게 부르고, 같은 기술에 다른 이름이 붙어 있습니다.
좀 더 들어가면 부서 것도 통일이 안 되어 있습니다. 결국 담당자별 폴더 규칙입니다. 그리고 그 규칙을 아는 사람은 만든 사람뿐입니다.
언제 만들었는지 물어보면 이렇게 답합니다.
"몇 년 전에 신입이 정리했던 것 같은데요."

이게 왜 이렇게 됐나

관리를 소홀히 해서가 아닙니다. 그렇게 될 수밖에 없는 순환이 있습니다.

전사 체계가 없습니다. 회사 전체가 쓰는 하나의 분류가 없으니 각 조직이 자기 것을 만듭니다.

조직개편이 일어나면 사라집니다. 제제팀이 만든 체계는 제제팀 것입니다. 팀이 없어지거나 합쳐지면 그 체계도 같이 없어집니다. 파일은 남는데 규칙은 남지 않습니다.

그러니 중요하다고 여기지 않습니다. 어차피 몇 년 뒤에 없어질 것을 공들여 만들 이유가 없습니다.

고참은 참여하지 않습니다. 잡무로 취급되니 자연스럽게 신참에게 갑니다.

그런데 분류체계를 만드는 일은 회사가 무엇을 다루는지 아는 사람이 해야 하는 일입니다. 가장 잘 아는 사람이 빠지고, 가장 모르는 사람이 만듭니다. 그러니 부실해집니다.

부실하니 더 안 쓰게 되고, 안 쓰니 더 중요하지 않아집니다. 처음으로 돌아갑니다.

돌고 있습니다. 어느 한 지점만 고쳐서는 끊기지 않습니다.

조직이 아니라 관리 대상에 연결해야 합니다

이 순환에서 가장 먼저 끊어야 할 고리는 조직개편 때 사라지는 것입니다. 여기가 끊기지 않으면 나머지가 다 따라옵니다.

원인은 분명합니다. 분류체계가 조직에 연결되어 있어서입니다. 조직이 없어지면 연결이 끊기고, 끊긴 체계는 아무도 관리하지 않습니다.

그러면 무엇에 연결해야 합니까. 관리 대상(Object)입니다.

회사가 다루는 기술, 회사가 만드는 제품, 회사가 거치는 개발 단계. 이런 것들이 관리 대상입니다. 조직은 바뀌지만 관리 대상은 남습니다. 고분자 서방화 기술은 제제팀이 있든 없든 회사가 다루는 기술이고, 서방정은 어느 팀이 만들든 서방정입니다.

앞선 글에서 두 번 이야기한 것과 같은 원리입니다. 조직 분리가 아니라 기능 분리입니다. 여기서는 그 원리가 분류체계의 수명을 결정합니다.

사일로는 그 결과입니다

규모가 있는 회사에서는 문제가 한 겹 더 있습니다.

본부별로 각자 체계를 갖고 있으면, 같은 기술을 서로 다르게 부릅니다. 그러면 넘어갈 방법이 없습니다.

A본부에서 3년 전에 검토한 기술을 B본부가 지금 다시 검토합니다. A본부에 자료가 있다는 것을 B본부는 모릅니다. 알 방법이 없습니다. 이름이 다르니 검색해도 안 나옵니다.

사일로를 조직 문화 문제로 보는 경우가 많은데, 상당 부분은 분류 문제입니다. 사이가 나빠서 공유를 안 하는 것이 아니라, 공유할 언어가 없는 것입니다.

같은 것을 같은 이름으로 부르는 일부터 — 용어 표준화

그래서 코드를 설계하기 전에 해야 할 일이 있습니다. 무엇을 무엇이라 부를지 정하는 일입니다.

예전에는 이걸 정할 필요가 없었습니다. 20년 같이 일한 사람들끼리는 다 통했으니까요. 몰라도 옆자리에 물어보면 됐습니다.

지금은 그 말이 시스템 안에서 쓰입니다. 그리고 시스템은 옆자리에 물어보지 못합니다. 등록된 글자 그대로만 압니다.

사람은 원래 알고 있었습니다. 몰랐던 것은 시스템입니다.

실제로 이런 식입니다. 제제팀은 서방화, 분석팀은 방출제어, 특허 문서에는 controlled release. 세 이름이 같은 것을 가리킨다는 사실을 아무도 문서로 정해두지 않았습니다. 정할 이유가 없었으니까요.

이 상태에서 코드를 만들면 어떻게 되나. 세 팀이 각자 다른 코드를 만듭니다. 사일로가 코드 체계로 굳어집니다.

그래서 대표 용어를 하나 정하고, 나머지는 별칭으로 붙여둡니다.

별칭에는 영문 표기, 약어, 옛 이름, 자주 쓰는 줄임말까지 넣습니다. 무엇으로 검색해도 같은 관리 대상에 닿게 하는 것이 목적입니다.

여기서 중요한 원칙이 하나 있습니다. 기존 이름을 없애지 않습니다.

제제팀은 계속 서방화라고 부르면 됩니다. 다만 시스템이 그 말을 대표 용어로 연결해 줍니다. 부르는 방식을 바꾸라고 하면 저항이 생기고, 저항이 생기면 안 씁니다. 지난 글에서 이야기한 것과 같습니다. 문화를 바꾸는 것이 아니라 부딪히는 면적을 줄이는 것입니다.

그리고 용어도 계속 늘어납니다. 검색했는데 안 나온 말, 등록할 때 후보에 없던 말. 그런 것들이 별칭 후보로 쌓입니다. 뒤에서 다룰 코드 갱신과 같은 방식입니다.

폴더를 만드는 것이 아닙니다

용어를 맞췄으면 이제 코드입니다. 여기서 흔한 오해가 하나 있습니다. 전사 분류체계를 만들자고 하면 더 크고 정교한 폴더 구조를 떠올립니다.

다릅니다.

폴더는 자료를 담는 곳입니다. 하나의 자료가 하나의 폴더에 들어갑니다. 그게 전부입니다.

여기서 만들 것은 폴더가 아니라 관리 대상입니다. 기술 하나가 독립된 항목으로 존재하고, 자기 코드와 정의와 상태를 갖습니다. 그리고 과제·결정·산출물·위탁 이력이 그 대상에 연결됩니다.

폴더에는 자료만 들어가지만, 관리 대상에는 관계가 붙습니다. 그래서 기술 하나를 열면 거기 연결된 것이 전부 나옵니다.

지난 글에서 이력이 남아야 할 결정들을 골라냈습니다. 그 결정들이 어느 관리 대상에 연결될 것인가를 정하는 일입니다.

하나의 트리로 만들지 않습니다

분류체계를 설계하자고 하면 대개 하나의 트리를 그립니다. 대분류 아래 중분류, 그 아래 소분류. 흔히 말하는 기술트리가 이 형태입니다. 위에서 아래로 뻗어 내려가고, 어느 항목이든 자리가 하나뿐입니다.

그렇게 만들면 곧 막힙니다.

어떤 자료는 제품으로 나누고 싶고, 어떤 자료는 기술로 나누고 싶고, 또 어떤 것은 개발 단계로 나누고 싶습니다. 하나의 트리에 다 넣으려면 무엇을 맨 위에 둘지부터 정해야 하는데, 무엇을 위에 둬도 나머지가 불편해집니다.

제품을 위에 두면 같은 기술이 여러 제품 아래로 흩어집니다. 기술을 위에 두면 한 제품의 자료가 여기저기 흩어집니다. 어느 쪽을 골라도 절반은 불편합니다.

그래서 트리를 하나 더 잘 그리는 것이 아니라, 축(Axis)을 나눕니다.

성격이 다른 축을 각각 두고, 하나의 관리 대상에 각 축의 코드가 독립적으로 붙습니다.

축이 독립이라는 것은, 한 축의 값이 다른 축의 값에 영향을 주지 않는다는 뜻입니다. 서방정(제품 축)이면서 동시에 고분자 매트릭스 서방화(요소기술 축)이고 처방 설계 단계(적용 단계 축)일 수 있습니다. 셋이 서로 간섭하지 않습니다.

이렇게 독립된 축들이 모여 이루는 구조를 차원(Dimension)이라고 부릅니다.

트리와 무엇이 다른지 나란히 놓으면 이렇습니다.

그리고 마지막 줄이 나중에 중요해집니다. 기술 축을 나중에 손봐도 제품 축과 단계 축은 영향을 받지 않습니다.

사람이 고르는 것은 하나뿐이어야 합니다

축이 셋이면 등록할 때 셋을 다 골라야 할 것 같지만, 그렇지 않습니다.

실험이나 산출물은 이미 과제에 속해 있습니다. 그리고 과제는 제품 정보와 단계 정보를 갖고 있습니다. 그러니 제품 축과 단계 축은 자동으로 따라옵니다.

사람이 손으로 고르는 것은 요소기술 축 하나입니다.

이게 중요한 이유가 있습니다. 아무리 잘 설계해도 안 붙이면 없는 것과 같습니다. 그리고 고를 것이 다섯 개면 안 붙입니다. 등록 부담이 선택 하나로 줄어야 실제로 붙습니다.

그리고 건너뛸 수 없게 합니다

부담을 줄였으면 이제 필수로 만듭니다.

"나중에 붙이겠다"는 나중이 오지 않습니다. 등록 시점에 안 고르면 영영 안 붙습니다. 과제를 등록할 때, 산출물을 올릴 때, 코드 선택을 건너뛸 수 없게 규정과 프로세스에 넣습니다.

다만 순서가 있습니다. 필수로 만들려면 그만큼 쉬워야 합니다. 고를 것이 다섯 개인 채로 필수만 걸면 아무 값이나 골라 넣습니다. 그러면 데이터가 있으나 마나입니다.

쉽게 만들고, 그다음에 필수로 겁니다. 순서가 반대면 우회가 생깁니다.

갱신 경로가 없으면 3년 뒤에 죽습니다

여기가 이 글에서 가장 중요한 절입니다.

앞의 악순환에서 조직개편 고리를 끊었어도, 또 하나가 남아 있습니다. 현실과 어긋나는 것입니다.

전문가가 한 번 잘 설계하고 끝나면, 3년 뒤에 같은 자리로 갑니다. 회사가 다루는 기술이 그사이 달라졌는데 코드는 그대로니까요.

그래서 갱신이 별도 작업이 아니라 업무의 부산물로 일어나야 합니다. 두 개의 경로를 둡니다.

경로 1 — 붙일 코드가 없다는 것이 신호입니다

새 조사 자료를 등록하는데 붙일 코드가 없습니다. "해당 없음"으로 등록됩니다. 그 순간 신규 코드 후보로 자동 상정됩니다.

코드에 안 붙는 정보가 들어온다는 것은, 회사가 다루는 기술의 경계에 무언가 나타났다는 뜻입니다. 그 신호를 버리지 않고 후보로 쌓습니다. 분기마다 검토해서 신설할지, 기존 코드에 붙일지, 아직 지켜볼지를 정합니다.

경로 2 — 조회 결과가 넓어지면 나눕니다

어떤 코드에 연결이 계속 늘어 조회하면 너무 많이 나옵니다. 그러면 하위로 나눕니다.

두 경로 모두 사람이 따로 점검하러 가지 않습니다. 업무가 신호를 만들고, 사람은 판단만 합니다. 앞에서 본 별칭 후보도 같은 방식입니다.

과거 데이터는 재분류하지 않습니다

코드를 나눈다고 하면 대부분 여기서 멈춥니다. 기존 자료를 다 다시 분류해야 하니까요.

분류체계 개편이 착수조차 안 되던 이유가 이것이었습니다. 필요한 건 알겠는데, 지난 10년치를 다시 손댈 엄두가 안 납니다.

재분류하지 않습니다.

옛 연결은 상위 코드에 그대로 둡니다. 새 연결부터 세분 코드로 붙입니다. 그리고 조회할 때는 상위 코드로 열면 옛것과 새것이 전부 나옵니다.

이것만 정해두면 개편이 언제든 가능해집니다. 과거를 정리해야 미래로 갈 수 있다는 전제가 없어지니까요.

그리고 앞의 대비표 마지막 줄이 여기서 일을 합니다. 축이 독립되어 있으니 기술 축을 나눠도 제품 축과 단계 축은 그대로입니다. 손대는 범위가 좁습니다. 하나의 트리였다면 아래가 다 흔들렸을 일입니다.

처음에 잘 만드는 것보다

정리하면 이렇습니다.

분류체계가 없는 것이 아니라 조직마다 따로 있습니다. 그리고 조직에 연결되어 있어서 조직이 바뀌면 사라집니다. 그 순환이 부실함을 만들어 왔습니다.

용어부터 맞춥니다. 사람은 원래 알고 있었지만 시스템은 모릅니다. 다만 기존 이름을 없애지 않고 별칭으로 이어줍니다.

조직이 아니라 관리 대상에 연결합니다. 회사가 다루는 기술과 제품은 조직개편보다 오래갑니다.

하나의 트리가 아니라 독립된 축입니다. 그리고 사람이 고르는 것은 하나뿐이어야 합니다.

갱신 경로를 처음부터 넣습니다. 붙일 코드가 없다는 신호에서 신설이, 조회가 넓어졌다는 신호에서 분리가 일어납니다.

과거는 재분류하지 않습니다.

다음 편에서는

용어를 맞추고 코드를 붙였으면, 이제 관리 대상들이 서로 이어져야 합니다.

폴더는 하나의 자료를 한 곳에만 담습니다. 그런데 관계는 여러 방향으로 뻗습니다. 그래서 "이 전제 위에 선 과제 전부" 같은 조회가 안 나옵니다.

특히 개인 폴더는 다른 문제입니다. 공유 폴더는 구조가 안 맞아 못 찾는 것이지만, 개인 폴더는 그 자료가 있다는 것조차 모르는 것입니다. 다음 편에서 다루겠습니다.