왜 이 글을 쓰는가

어느 날 하루를 통째로 이 질문이 채웠다. “어떻게 분류를 잘 할 수 있을까.”

패키지를 나누는 일, 설계 결정, 업무를 쪼개는 일 — 들여다보니 모두 분류 역량에 해당했다. 그런데 이상하게도 그 역량을 체계적으로 다루는 책이 없었다. 왜 분류 전문가는 없을까?

분류는 어디에나 있다

소프트웨어를 짜다 보면 경계를 긋는 일이 끊임없이 찾아온다. 어느 기능이 어느 모듈에 속하는가. 어느 이벤트가 어느 도메인인가. 자연어 세계에서는 “철수”라는 개체가 직관적으로 무언가를 대표하지만, 소프트웨어 세계에서는 그 경계를 직접 설정해야 한다.

그 중에서도 분기(branch) 위치 결정이 분류 행위의 가장 날것 형태다. 새로운 요구사항이 들어올 때 그 분기를 어떤 위치에, 어떤 클래스에 둘지를 결정해야 한다. 잘못 두면 코드의 표현력이 줄고 복잡성이 크게 늘어난다. 이 결정의 본질은 분류다 — 책임을 어느 범주(클래스)에 귀속시키느냐. 잘 분류된 분기는 코드가 의도를 읽히게 하고, 그렇지 않으면 반대다.

아리스토텔레스 범주론 영상을 우연히 보다가 이 생각이 굳어졌다. 개념이란 상황에 맞게 행동하는 것. 언어가 사고 체계를 드러낸다. 그리고 어디서 나눌 것인가가 그 사람의 엔지니어링을 드러낸다.

이름들

도서관을 뒤졌다. 분류를 이론화한 이름들이 흩어져 있었다.

레이코프의 원형론 — 범주는 경계가 명확한 집합이 아니라 원형(prototype)을 중심으로 느슨하게 모인 것이라는 관점. 마케팅에서는 이벤트 택소노미, 웹에서는 사용자가 직접 태그를 붙이는 폴소노미(folksonomy), 지식공학에서는 온톨로지와 지식그래프. 각기 다른 분야가 같은 문제를 다른 언어로 풀고 있었다.

그것들을 묶는 교재는 없었다. 가장 가까운 자리에 있던 건 Abby Covert의 정보 아키텍처 입문서였다(국내판 제목: 엉망진창 속에서 살아남는 법). 책의 전제가 흥미로웠다 — “IA는 전문가가 아니라 무언가를 만드는 모든 사람의 기술이다.” 분류 전문가가 없는 이유가 어쩌면 이것일지도 모른다. 분류는 누군가에게 위탁할 수 있는 기술이 아니라, 무언가를 만드는 사람이 직접 해야 하는 일이기 때문에. 책은 “정렬보다 어려운 건 정렬 규칙에 대한 합의(Sorting is easier than deciding how to sort)”라고 말한다. 그 규칙이 바로 분류의 본체다.

분류 오류의 발현

며칠 뒤 이런 메모를 남겼다. “배경과 원인을 혼동하는 자주 실수를 한다.” 그리고 바로 다음 칸에 “요인분석”이라고 썼다.

돌아보니 그것도 분류 오류였다. 배경(맥락·조건)을 원인(작동 인과)으로 귀속시키는 실수 — 범주 귀속의 오류다. 5why를 돌려도 배경과 원인을 구분하지 못하면 엉뚱한 층위에서 멈추게 된다. 팩트풀니스가 “비난 본능 — 악당을 찾지 말고 시스템에 주목하라”고 말할 때 겨냥하는 것도 같은 오류다. 개인이나 집단을 원인으로 귀속하는 행위 자체가 범주를 잘못 배정하는 것이다. 생각정원에 “인과 오류”라는 이름으로 노트를 하나 새로 열었다.

아직 열려 있다

“정보가 너무 부족하다”라고 썼던 그 메모가 아직 닫히지 않았다. 레이코프의 원형론, 정보체계 구조론, 그리고 Covert가 말하는 정보 아키텍처 — 키워드는 잡혔는데 그것들을 엔지니어링 역량으로 전환하는 다리가 보이지 않는다.

책을 완독하면서 하나의 단어가 마음에 걸렸다. 정보설계사(Information Architect). 오늘 처음 마주한 단어인데 끌림이 있었다. 개발을 좋아했던 이유와 어딘가 닿아있는 것 같다고 메모했다.

분류만큼 보편적으로 필요한 역량이 없는데. 분류 전문가는 왜 없을까.