택소노미

항목이 적을 때는 분류가 필요하지 않습니다. 문서가 20개면 한 목록에 최근 순으로 늘어놓기만 해도 다 보입니다. 문제는 200개가 되는 순간에 옵니다. 스크롤을 세 번 내려도 찾는 것이 안 보이고, 제목을 정확히 기억하지 못하면 그 문서는 사실상 사라진 것이 됩니다.

그래서 각자 폴더를 만들기 시작합니다. 여기서 두 번째 문제가 생깁니다. 기준을 정해 주지 않으면 사람마다 다른 기준으로 만들기 때문입니다. 한 사람은 2026 처럼 연도로 만들고, 다른 사람은 기획 처럼 업무 종류로 만들고, 또 다른 사람은 신규기능_최종 처럼 그때그때의 일감 이름으로 만듭니다. 세 폴더가 한 화면에 나란히 놓이면 새로 들어온 사람은 자기 문서를 어디에 둬야 할지 판단할 근거가 없습니다. 결국 아무도 남의 폴더를 열지 않고 전부 검색으로만 찾습니다.

택소노미는 그 기준을 한 번 정해 문서로 남긴 것입니다. 무엇을 기준으로 나눌지, 층을 몇 개까지 둘지, 한 층에 몇 갈래를 둘지를 미리 못 박습니다. 결정을 사람마다 하지 않고 한 번만 하려고 만든 장치입니다.

기준 축을 하나 고르는 것에서 시작합니다. 같은 문서 더미를 팀별로 나눌 수도 있고 업무 종류별로 나눌 수도 있는데, 둘을 같은 층에 섞으면 항목마다 어디로 갈지가 다시 논쟁이 됩니다.

순서는 다섯 단계입니다.

1. 항목의 실제 이름을 모아 훑습니다. 머릿속 분류가 아니라 지금 쓰이고 있는 제목 200개를 늘어놓고 반복되는 말을 찾습니다. 이 단계를 건너뛴 분류는 대개 만든 사람에게만 맞습니다.
2. 기준 축을 하나 고릅니다. 사용자가 무엇을 기억한 상태로 다시 찾아오는지가 판단 근거입니다. 반년 전 회의록을 찾을 때 어느 팀 것인지는 기억하고 언제였는지는 기억하지 못한다면 팀이 축입니다.
3. 층 수를 정합니다. 두세 층이 보통이고, 네 층을 넘기면 항목 하나에 닿기까지 네 번 이상 눌러야 해서 사람들이 중간에 포기합니다.
4. 한 층에 놓을 갈래 수를 정합니다. 다섯에서 아홉 사이가 관행입니다. 한 층에 열아홉 개가 나란히 놓이면 훑어보는 것 자체가 일이 됩니다.
5. 어디에도 맞지 않는 항목을 어떻게 할지 정합니다. 기타 같은 갈래를 하나 두되 그 안의 비율을 셉니다. 전체의 20퍼센트가 기타에 들어가 있으면 갈래가 부족한 것이 아니라 2번에서 고른 축이 틀린 것입니다.

한 항목이 두 갈래에 동시에 속하는 일이 잦아지면 그것도 신호입니다. 계층은 한 항목에 한 자리만 주는 구조라서, 마케팅 팀이 만든 신규 기능 기획서를 팀별 분류와 종류별 분류 중 어디에 둘지 매번 고민하게 됩니다. 이때는 계층을 더 쪼개는 대신 패싯 필터로 보완합니다. 속성별 조건을 겹쳐 좁혀 가는 방식이라 한 항목에 여러 기준을 동시에 걸 수 있습니다.

세 자리에서 주로 쓰입니다.

첫째는 내비게이션을 짤 때입니다. 내비게이션은 화면 사이를 옮겨 다니게 해 주는 메뉴와 목록인데, 분류가 사용자 눈에 실제로 보이는 형태가 이것입니다. 갈래를 여덟 개로 나눠 두고 메뉴에 넷만 꺼내 놓으면 나머지 넷은 없는 것과 같아집니다.

둘째는 사이트맵을 그릴 때입니다. 사이트맵은 화면 전체의 구조를 나무 형태로 옮긴 도식입니다. 분류를 정해 두지 않은 상태에서 도식부터 그리면 그림이 실제 구조가 아니라 그린 사람의 취향이 됩니다.

셋째는 검색 UX를 설계할 때입니다. 검색 결과를 그룹으로 묶어 보여 주거나 결과 옆에 필터를 달 때, 그 그룹과 필터 항목이 택소노미에서 그대로 나옵니다. 분류가 없으면 결과 100건을 한 줄로 늘어놓는 것 말고 할 수 있는 일이 없습니다.

이름을 붙이는 일은 다음 단계입니다. 갈래를 나눈 뒤 각 갈래를 무엇이라 부를지 정하는 것이 레이블링이고, 분류가 맞아도 이름이 어긋나면 사용자는 맞는 자리 앞에서 지나쳐 갑니다.

"택소노미를 팀 기준으로 갈까요, 업무 종류 기준으로 갈까요?"

무엇을 기준 축으로 삼을지 정하자는 제안입니다. 뒤의 모든 화면이 이 답에 따라 달라집니다.

"기타 폴더에 지금 전체의 3분의 1이 들어 있어요. 택소노미를 다시 봐야 합니다."

분류가 실제 항목을 담아내지 못하고 있다는 문제 제기입니다.

"택소노미가 세 층인데 메뉴는 두 층까지만 보여 주고 있습니다."

정해 둔 구조와 사용자에게 보이는 구조가 어긋나 있다는 지적입니다.

페이지덱에서는 문서 수가 회사당 평균 400건을 넘긴 뒤 민서가 이 작업을 맡았습니다. 실제 문서 제목 300개를 뽑아 늘어놓았더니 회의록, 기획서, 회고, 고객 응대 기록 네 종류가 전체의 78퍼센트였습니다. 팀 이름이 제목에 들어간 경우는 11퍼센트뿐이었습니다.

지현은 그래도 팀 기준을 밀었습니다. 조직 개편이 두 번 있었던 고객사에서 주인 없는 팀 폴더가 쌓인 것을 본 민서가 개편 뒤 그 문서들이 어디로 가는지를 되물었고, 답이 없었습니다. 그래서 첫 층은 업무 종류 네 갈래로 잡고 팀은 필터 쪽으로 넘겼습니다.

한 번 정하면 끝나는 일로 보는 경우가 많습니다. 뼈대라는 말이 붙으니 자주 고치는 것이 아니라고 여기기 쉽습니다. 그런데 항목은 계속 늘고, 늘어나는 항목은 처음 정한 갈래를 벗어납니다. 문서 400건 기준으로 나눈 네 갈래는 4,000건이 되면 한 갈래 안에 1,500건이 들어 있는 상태가 됩니다. 기타의 비율과 가장 큰 갈래의 크기를 반년에 한 번 재는 팀은 이 시점을 미리 보고, 재지 않는 팀은 사용자가 검색으로만 다니기 시작한 뒤에 알게 됩니다.

내부 조직도를 그대로 옮기면 된다고 보는 것도 흔합니다. 조직도는 이미 있고 합의도 끝나 있으니 가장 빠른 길처럼 보입니다. 하지만 조직은 바뀌고 분류는 그대로 남습니다. 팀이 합쳐지면 폴더 두 개가 주인 없이 남고, 새로 생긴 팀의 자리는 아무도 만들어 두지 않았습니다. 무엇보다 제품을 쓰는 사람 대부분은 그 조직도를 모릅니다.