정보 구조

초기의 웹사이트와 소프트웨어는 조직도를 그대로 메뉴로 옮겨 놓은 모양이었습니다. 영업팀이 만든 페이지는 영업 항목 아래, 기술팀이 만든 문서는 기술 항목 아래 놓였습니다. 만드는 쪽에서는 자연스러웠습니다. 각 팀이 자기 내용을 자기 자리에 올리면 되니 누구와도 상의할 일이 없었습니다.

문제는 찾는 쪽에서 터졌습니다. 보증 기간을 늘리고 싶은 사람은 그 안내가 제품 소개에 있는지 고객 지원에 있는지 구매 안내에 있는지 알 수 없었습니다. 회사 안에서만 통하는 경계였기 때문입니다. 사용자는 회사가 팀을 어떻게 나눠 놨는지 모르고, 알 이유도 없습니다.

그래서 문의 창구에서 이런 대화가 반복됐습니다. 사용자가 "그 화면을 못 찾겠습니다" 라고 하면 상담원이 "주소를 불러 드릴 테니 그대로 입력해 보세요" 라고 답했습니다. 길을 안내하는 대신 좌표를 불러 주는 방식입니다. 한 사람에게는 통하지만 같은 것을 찾는 나머지 사람은 여전히 못 찾습니다. 이런 상태는 지표에 오류로 잡히지 않습니다. 화면은 멀쩡히 열리고 서버는 정상이고 오류 기록에는 아무것도 남지 않는데, 사람들만 원하는 자리에 닿지 못합니다.

고칠 사람이 정해지지 않은 것도 오래 이어진 이유입니다. 화면을 보기 좋게 만드는 일은 디자이너가, 동작하게 만드는 일은 개발자가 맡았지만, 무엇을 어느 갈래에 넣고 그 갈래를 뭐라고 부를지는 누구의 일도 아니었습니다. 회의에서 결정되지 않고 각자 자기 화면을 만들면서 그때그때 정해졌습니다. 그러다 보니 같은 제품 안에서 같은 것이 어떤 화면에서는 폴더, 다른 화면에서는 프로젝트, 또 다른 화면에서는 공간으로 불렸습니다.

이름이 없으니 같은 문제가 매번 다른 말로 보고됐습니다. 어떤 분기에는 메뉴가 복잡하다는 문의가, 다음 분기에는 검색이 안 된다는 문의가, 그다음에는 새 기능을 아무도 안 쓴다는 보고가 올라왔습니다. 셋은 한 가지 원인의 다른 증상이었지만 따로 접수되어 따로 처리됐고, 그래서 메뉴를 줄이고 검색을 고치고 안내 문구를 붙이는 작업이 각각 진행된 뒤에도 사람들은 여전히 원하는 자리를 찾지 못했습니다.

정보 구조라는 이름은 이 빈자리에 붙었습니다. 건물을 지을 때 층을 몇 개 둘지와 각 층을 무엇이라 부를지를 먼저 정하는 것처럼, 화면을 그리기 전에 내용의 뼈대를 정하는 단계를 따로 세운 것입니다. 이름이 생기자 세 가지가 따라왔습니다. 결정을 맡을 사람이 생겼고, 결정을 적어 둘 문서가 생겼고, 잘못됐다고 말할 근거가 생겼습니다. "이 메뉴 이상한데요" 는 취향 다툼으로 끝나지만 "사용자 열두 명 중 아홉 명이 이 항목을 다른 자리에서 찾았습니다" 는 고칠 지점을 가리킵니다.

정보 구조 아래 용어는 세 갈래로 묶입니다. 내용을 나누고 이름 붙이는 분류, 나눈 결과를 도면으로 옮기는 표현, 사용자가 그 안에서 목적지에 닿게 하는 탐색입니다.

분류는 두 자리입니다. 뼈대 자체를 결정하는 자리라 나머지 갈래가 전부 여기에 얹힙니다.

1. 택소노미 — 항목을 계층으로 나눈 분류 체계입니다. 페이지덱의 문서를 팀별로 나눌 수도 있고 업무 종류별로 나눌 수도 있습니다. 팀별로 나누면 옮겨 간 사람의 문서가 어디로 가야 할지가 매번 문제가 되고, 업무 종류별로 나누면 같은 프로젝트의 회의록과 기획서가 서로 다른 자리에 흩어집니다. 어느 쪽이 맞는지는 사용자가 무엇을 기준으로 다시 찾아오는지에 달려 있습니다.
2. 레이블링 — 나눠 둔 갈래에 이름을 붙이는 일입니다. 같은 자리를 워크스페이스라 부를지 팀 공간이라 부를지 조직이라 부를지를 정합니다. 내부 회의에서 쓰던 말을 그대로 쓰면 만든 사람들에게는 한 번에 읽히고 처음 쓰는 사람에게는 아무 뜻도 없는 이름이 됩니다. 분류가 옳아도 이름이 어긋나면 사용자는 맞는 자리 앞에서 지나쳐 갑니다.

표현은 한 자리입니다. 사이트맵은 화면 전체의 구조를 나무 형태로 그린 도식입니다. 머릿속에 있는 구조는 늘 깔끔해 보이지만 종이에 옮기면 사정이 다릅니다. 항목 하나에 닿기까지 다섯 번을 눌러야 하는 갈래가 드러나고, 한 층에 열아홉 개가 나란히 놓인 자리가 보이고, 어느 갈래에도 속하지 않아 기타라는 이름 아래 모아 둔 무더기가 눈에 띕니다. 그림 한 장이 하는 일은 결정을 대신하는 것이 아니라 결정해야 할 곳을 드러내는 것입니다.

탐색은 세 자리이고, 사용자가 목적지에 닿는 방식이 서로 다릅니다.

1. 내비게이션 — 화면 사이를 이동하게 해 주는 장치입니다. 위쪽 메뉴, 왼쪽 목록, 현재 위치를 상위 경로와 함께 보여 주는 표시가 여기 들어갑니다. 분류가 사용자 눈에 실제로 보이는 형태가 이것이라, 갈래를 잘 나눠 놓고 메뉴에 절반만 꺼내 놓으면 나머지 절반은 없는 것과 같아집니다.
2. 검색 UX — 검색어를 입력하는 순간부터 결과를 확인하기까지의 경험을 설계합니다. 사용자가 분류를 모르거나 분류에 동의하지 않을 때 쓰는 우회로입니다. 오타를 적었을 때, 팀에서 쓰는 말과 제품에 적힌 말이 다를 때, 결과가 하나도 없을 때 무엇을 보여 줄지가 이 자리의 질문입니다.
3. 패싯 필터 — 속성별 조건을 겹쳐 가며 범위를 좁힙니다. 문서 목록에서 작성자를 고르고 기간을 고르고 상태를 고르면 남는 것이 줄어드는 방식입니다. 계층이 하나의 길만 허용하는 데 비해 이쪽은 여러 기준을 동시에 걸 수 있어서, 한 문서가 여러 갈래에 걸치는 제품에서 계층의 한계를 메웁니다.

사용자가 목적지에 닿는 길은 크게 둘입니다. 갈래를 짚어 내려가는 길과 검색어를 적어 건너뛰는 길입니다. 둘 중 어느 쪽이 주로 쓰이는지는 제품마다 다릅니다. 항목이 수백 개를 넘고 사용자가 이름을 정확히 아는 제품에서는 검색이 앞서고, 무엇이 있는지부터 둘러보는 제품에서는 메뉴가 앞섭니다. 페이지덱처럼 자기가 만든 문서를 다시 찾는 제품은 두 길이 섞입니다. 어제 쓴 문서는 최근 목록에서 바로 열고, 반년 전 회의록은 제목의 일부만 기억해 검색으로 찾습니다. 그래서 둘 중 하나만 손보는 선택은 대개 절반만 고치는 결과가 됩니다.

세 갈래는 순서대로 얹힙니다. 분류가 뼈대를 정하고, 표현이 그 뼈대를 눈에 보이게 만들고, 탐색이 사용자를 그 위로 걸어 다니게 합니다. 어느 하나가 어긋나면 나머지가 힘을 잃습니다. 분류가 사용자의 생각과 다르면 메뉴를 아무리 예쁘게 짜도 사람들은 검색창으로 도망가고, 분류가 맞아도 메뉴가 다섯 단계 깊이면 있는 줄도 모르고 지나갑니다. 반대로 탐색만 강화하는 선택도 한계가 분명합니다. 검색을 잘 만들어 두면 당장은 버티지만, 이름이 제각각인 상태에서는 검색어와 항목 이름이 어긋나 결과가 비는 일이 계속됩니다.

"이 기능을 설정에 넣을지 문서 메뉴에 넣을지부터 정하고 시안을 그릴게요."

화면 모양보다 그 기능이 어느 갈래에 속하는지가 먼저 정해져야 한다는 말입니다.

"카드 소팅 해 보니 열두 명 중 아홉 명이 템플릿을 문서 아래에 놨어요."

팀이 정한 자리가 아니라 사용자가 예상하는 자리를 확인한 결과라는 뜻입니다.

"사이드바 항목이 열아홉 개인데 여기에 하나 더 붙여도 안 보일 거예요."

한 층에 너무 많이 놓여 항목을 추가하는 것 자체가 효과를 잃었다는 지적입니다.

페이지덱에서 이 말이 가장 자주 오간 때는 문서 수가 늘어 기존 구조가 버티지 못하던 분기였습니다. 계정당 문서가 평균 마흔 건을 넘어가자 폴더를 더 깊게 파는 팀이 늘었고, 민서가 사이트맵을 그려 보니 깊은 곳은 다섯 단계였습니다. 다섯 단계 아래에 있는 문서는 검색으로만 열리고 있었습니다. 폴더를 타고 들어가 여는 비율은 위쪽 두 단계에서 대부분 나왔고, 세 단계를 넘어가면 그 자리에 무엇이 들어 있는지 아는 사람은 그 폴더를 만든 본인뿐이었습니다.

논의는 폴더를 계속 쓸지 태그로 바꿀지에서 시작해 권한 문제로 옮겨 갔습니다. 페이지덱은 폴더에 공유 권한을 걸고 그 안의 문서가 권한을 물려받게 만들어 뒀는데, 태그는 하나의 문서에 여럿 붙일 수 있어서 상속의 기준이 사라집니다. 태오가 이 점을 짚자 분류 방식을 고르는 문제가 권한 설계를 고르는 문제와 같은 것이라는 게 드러났습니다.

결론은 둘 중 하나를 택하는 대신 역할을 나누는 쪽이었습니다. 폴더는 문서가 하나만 속하는 위치로 두고 권한은 여기에만 걸며, 태그는 위치와 무관하게 여러 개 붙이는 꼬리표로 쓰기로 했습니다. 지현은 이 결정을 문서로 남기고 새 기능을 만들 때마다 어느 쪽에 붙는지를 먼저 적게 했습니다. 구조를 한 번 정하는 것보다 다음 기능이 들어올 자리를 정하는 규칙을 남기는 쪽이 오래간다는 판단이었습니다.

정보 구조를 메뉴 구성으로 좁혀 읽는 경우가 가장 많습니다. 작업 결과가 메뉴와 사이드바로 드러나니 그렇게 굳기 쉽습니다. 실제 범위는 사용자 눈에 보이는 메뉴 바깥까지 이어집니다. 검색 결과를 무엇으로 묶어 보여 줄지, 필터에 어떤 항목을 둘지, 주소에 어떤 단어를 넣을지, 알림을 문서 단위로 보낼지 폴더 단위로 보낼지, 권한을 어디에 걸지가 모두 같은 뼈대 위에서 결정됩니다. 좁게 읽으면 메뉴만 정리하고 나머지는 그대로 두게 되는데, 그러면 정돈된 메뉴 옆에서 검색은 여전히 옛 이름으로 항목을 찾고 알림은 폴더를 옮길 때마다 끊깁니다. 판단이 필요한 자리인지 아닌지는 질문 하나로 갈립니다. 이 결정이 무엇을 무엇과 같은 묶음으로 보느냐를 정하고 있다면, 그 화면이 메뉴든 필터든 알림 설정이든 정보 구조의 결정입니다.

한 번 정하면 끝나는 초기 작업으로 보는 오해도 흔합니다. 프로젝트 초반에 사이트맵 한 장으로 산출물이 나오니 그 시점에 끝난 일처럼 보입니다. 하지만 구조가 흔들리는 시점은 처음이 아니라 기능이 하나씩 붙을 때입니다. 어느 갈래에도 딱 맞지 않는 기능이 들어오면 임시로 둘 자리가 필요하고, 그 자리가 기타나 더보기라는 이름을 얻습니다. 한 번은 임시지만 두 해가 지나면 그 안에 열한 개가 쌓여 있고, 그때는 옮기려 해도 주소가 바뀌어 외부에서 걸어 둔 링크가 끊깁니다. 그대로 두면 구조를 다시 짜는 일은 점점 더 비싸지고, 비싸질수록 더 미뤄집니다. 처음에 완벽한 구조를 그리는 것보다 새 기능이 들어올 때 어느 갈래에 속하는지 판정하는 규칙을 남겨 두는 편이 오래갑니다.