꼬리표라는 분류

할 일이 10개일 때는 분류가 필요 없습니다. 눈으로 훑으면 됩니다. 30개가 넘으면 이야기가 달라집니다. “이건 뭐였지?”가 자주 떠오릅니다.

프로젝트가 있긴 합니다. 하지만 프로젝트는 무겁습니다. 멤버가 있고, 약어가 있고, 하나의 할 일은 하나의 프로젝트에만 속합니다. 단순히 “종류별로 모아보고 싶다”는 용도로 쓰기에는 과합니다.

그래서 꼬리표를 만들었습니다.

이름과 색깔

꼬리표에는 이름과 색깔이 있습니다. 그게 전부입니다.

이름은 자유롭게 짓습니다. “긴급”, “개인”, “읽을거리”, “나중에”. 뭐든 됩니다. 색깔은 20가지 포인트 컬러 중에서 고릅니다. 필수는 아닙니다. 설명을 붙일 수도 있지만, 안 붙여도 됩니다.

처음에는 더 많은 속성을 넣으려고 했습니다. 아이콘, 이모지, 그룹. 하지만 꼬리표는 가벼워야 합니다. 만드는 데 3초 이상 걸리면 안 만들게 됩니다.

붙이고 떼기

할 일 상세 화면에 꼬리표 섹션이 있습니다. 플러스 버튼을 누르면 내가 만든 꼬리표 목록이 뜨고, 탭하면 붙습니다. 붙은 꼬리표에는 x 버튼이 있어서, 탭하면 바로 떨어집니다.

한 할 일에 여러 꼬리표를 붙일 수 있습니다. “긴급”이면서 “개인”일 수 있으니까요.

이 부분은 웹 링크 기능과 비슷한 UI를 씁니다. 섹션 헤더에 추가 버튼, 아래에 목록. 새로운 UI 패턴을 만들지 않았습니다. 이미 익숙한 구조를 재활용했습니다.

프로젝트와의 차이

프로젝트는 1:1입니다. 할 일 하나에 프로젝트 하나. 꼬리표는 N:N입니다. 하나의 할 일에 여러 꼬리표, 하나의 꼬리표에 여러 할 일.

프로젝트는 팀 단위의 구조입니다. 멤버가 있고, 역할이 있고, 권한이 있습니다. 꼬리표는 개인적입니다. 나만의 분류 체계입니다.

나중에 프로젝트 꼬리표도 추가할 계획입니다. 프로젝트에 속한 꼬리표는 멤버 전체가 볼 수 있고, 개인 꼬리표는 나만 보입니다. 같은 할 일에 팀의 꼬리표와 나만의 꼬리표가 공존할 수 있습니다.

모아보기

꼬리표를 만들었으면 그걸로 모아볼 수 있어야 합니다.

꼬리표 상세 화면에서 “할 일”이나 “템플릿” 버튼을 누르면, 그 꼬리표가 붙은 것들만 모아서 보여줍니다. 프로젝트에서 기록과 템플릿을 모아보는 것과 같은 구조입니다.

목록에서 꼬리표를 직접 표시하지는 않습니다. 컬러 칩을 붙이면 목록이 시끄러워질 것 같았습니다. 필요하면 나중에 추가할 수 있지만, 지금은 상세 화면에서만 보이는 게 맞다고 생각합니다.

기술적인 이야기

꼬리표 데이터는 할 일 문서에 넣지 않았습니다. 별도 컬렉션 두 개를 만들었습니다. 꼬리표 정의(label)와 연결(label_link).

할 일 목록을 불러올 때 꼬리표 정보는 가져오지 않습니다. 상세 화면을 열 때 비로소 연결 정보를 조회합니다. 이렇게 하면 목록 조회 성능에 영향이 없습니다.

꼬리표로 필터링할 때는 서버에서 처리합니다. 연결 테이블에서 해당 꼬리표의 할 일 ID를 먼저 찾고, 그 ID로 할 일을 조회합니다. 로컬 캐시를 거치지 않습니다.

이 구조가 최선인지는 아직 모르겠습니다. 꼬리표가 많아지고 연결이 수천 개가 되면 다시 생각해야 할 수도 있습니다. 하지만 지금은 충분합니다.

가볍다는 것

기능을 만들 때 가장 경계하는 건 무거워지는 것입니다.

꼬리표는 가벼운 분류 도구여야 합니다. 만드는 데 3초, 붙이는 데 1초, 떼는 데 1초. 그 이상 걸리면 실패입니다.

지금은 그 정도를 유지하고 있다고 생각합니다. 앞으로도 무거워지지 않게 조심하겠습니다.

---

분류는 찾기 위한 것입니다. 찾기 쉬우면 됩니다.