기획을 하다 보면 "이 정도는 금방 되겠지" 하고 문서에 적었다가, 개발자에게 "그건 생각보다 오래 걸려요"라는 말을 듣는 일이 종종 있어요.
그 간극을 몸으로 이해하고 싶어서 작은 서비스를 직접 만들어 보기로 했습니다.
주제는 북마크 서비스예요.
아직 시작하는 단계이고 완성한 것은 아무것도 없어서, 이 글은 결과가 아니라 출발선에서 적는 생각과 계획입니다.
저는 읽을거리를 많이 저장하는데, 브라우저 즐겨찾기에 쌓아 두면 나중에 다시 찾기가 어렵더라고요.
내가 매일 겪는 불편이 있으면 만드는 동기가 오래 갑니다.
또 하나는 기능이 작다는 점이에요.
저장하고, 보고, 찾는 것이 핵심이라 처음 만들어 보는 사람도 범위를 감당할 수 있을 것 같았습니다.
이미 비슷한 서비스가 많이 있어서 새로움을 목표로 하지는 않아요.
오히려 남이 만든 서비스를 쓰면서 아쉬웠던 점을 내 방식으로 풀어 보는 연습에 가깝습니다.
처음 정한 원칙은 "한 가지 흐름만 끝까지"입니다.
저장해서, 목록으로 보고, 다시 찾는 것까지가 하나의 흐름이에요.
이 흐름에 필요한 최소 기능은 이렇게 적었습니다.
- 주소를 붙여 넣으면 저장된다
- 저장할 때 제목과 짧은 메모를 남길 수 있다
- 태그를 붙일 수 있다
- 목록에서 최신순으로 볼 수 있다
- 제목, 메모, 태그로 검색할 수 있다
반대로 이번에는 하지 않기로 한 것도 적어 두었어요.
- 다른 사람과 공유하거나 팔로우하는 기능
- 추천 기능
- 여러 기기 동기화
- 화려한 디자인
기획자의 습관이라 자꾸 기능을 더하고 싶어지는데, 하지 않을 것을 적어 두면 범위가 흔들릴 때 붙잡아 주더라고요.
화면보다 먼저 한 일은 데이터 구조를 종이에 그려 보는 것이었어요.
ERD를 그리는 감각으로, 서비스 안에 어떤 "것"이 있는지부터 정리했습니다.
북마크 하나가 가질 정보를 가정해 보면 이렇습니다.
- 주소
- 제목
- 메모
- 저장한 날짜
- 읽었는지 여부
그리고 태그가 따로 있고, 북마크와 태그는 서로 여러 개씩 이어집니다.
하나의 북마크에 태그가 여러 개 붙고, 하나의 태그에 북마크가 여러 개 붙으니까요.
그림을 그리다 보니 "태그를 글자로 그냥 적을지, 별도의 목록으로 관리할지"라는 선택이 눈에 들어왔어요.
별도의 목록으로 관리하면 오타로 비슷한 태그가 생기는 것을 막을 수 있지만, 구조가 조금 복잡해집니다.
이런 고민은 개발자가 항상 하는 일인데, 직접 부딪혀 보니 문서 한 줄에 "태그 기능"이라고 적을 때 얼마나 많은 결정이 숨어 있었는지 실감이 났어요.
삭제를 어떻게 처리할지도 고민이에요.
지우면 완전히 사라지게 할지, 휴지통처럼 잠시 보관할지에 따라 구조가 달라집니다.
사소해 보이지만 사용자의 실수를 얼마나 너그럽게 받아 줄지에 대한 정책 결정이기도 해요.
사용할 도구와 기술은 아직 고민하고 있습니다.
처음부터 완벽한 선택을 하기보다는, 자료가 많고 입문이 쉬운 것을 골라서 작게 시작하려고 합니다.
만들고 싶은 경험을 구체적으로 상상해 봤어요.
가정해 보겠습니다.
점심시간에 흥미로운 글을 발견해서 주소를 복사해 두었다고 해요.
서비스에 들어가 주소를 붙여 넣으면 제목이 자동으로 채워지고, 사용자는 태그만 한두 개 고르면 저장이 끝나요.
저녁에 다시 열었을 때는 "아직 안 읽은 것"만 모아 볼 수 있습니다.
일주일에 20개를 저장하고 그중 절반만 읽는다고 가정해 보면, 안 읽은 목록이 금방 쌓이겠죠.
그래서 "저장해 둔 지 오래된 것" 같은 정리 기능이 나중에는 필요해질 수 있다는 가설도 세웠어요.
이 정도 상상만으로도 첫 버전에 꼭 필요한 것과 나중에 해도 되는 것이 갈립니다.
몇 가지를 스스로 다짐해 두었어요.
첫째, 완성을 목표로 하지 않고 계속 움직이는 것을 목표로 삼습니다.
바쁜 일상 속에서 시간이 날 때 조금씩 하는 프로젝트라서 속도가 느릴 수 있어요.
둘째, 막히면 범위를 줄입니다.
기능이 안 되면 더 어려운 방법을 찾기보다 "이 기능을 빼면 어떻게 될까"를 먼저 생각해 봅니다.
셋째, 개발자의 입장에서 기록을 남깁니다.
어디에서 오래 걸렸고 무엇이 의외로 쉬웠는지를 적어 두면, 나중에 현업에서 일정을 이야기할 때 큰 도움이 될 것 같아요.
넷째, 잘 만드는 것보다 이해하는 것이 목적임을 잊지 않습니다.
결과물이 엉성해도 그 과정에서 얻은 감각이 기획서의 질을 바꿀 거라고 믿어요.
시간을 어떻게 쓸지도 미리 정했어요.
일주일에 몇 번, 한 번에 한두 시간 정도를 목표로 하고, 한 번에 하나의 작은 과제만 끝내는 식입니다.
예를 들어 이번 주는 저장 화면만, 다음 주는 목록 화면만 만들어 보는 거죠.
작은 단위로 끝내는 경험이 쌓여야 흐름이 끊기지 않을 것 같아요.
이제 막 출발한 프로젝트라서 앞으로 어떻게 될지는 저도 몰라요.
중간에 멈출 수도 있고, 방향이 바뀔 수도 있습니다.
그래도 기획자가 직접 만들어 보는 경험은 문서만 쓸 때는 보이지 않던 것을 보여 줄 것 같아서 기대가 됩니다.
남는 질문도 있어요.
작은 프로젝트를 꾸준히 이어 가는 힘은 어디서 나올까요.
그리고 직접 만들어 본 경험을 실제 협업에서 어떤 방식으로 쓸 수 있을까요.
진행하면서 막힌 지점과 배운 점을 이 블로그에 차근차근 기록해 보겠습니다.