디스크립션 또는 스펙 정의의 스킬

결국은 메이커와의 거리의 문제

 그렇게 되면 할 일이 너무 많아지실 거에요

 걱정스런 우리 테크리더의 표정을 보며 잠시 혼란스러워하고 있었다. 이번 문제는 명확했다. 제로 투 원의 프로젝트의 장점은 없던 서비스를 만들기에 하고 싶은 것을 마음껏 할 수 있다는 것이고, 필요한 데이터의 항목도 용도만 잘 정의한다면 굳이 개발설계에 참견하지 않고도 잘 진행될 수 있다는 것이다. 하지만 그래도 최종적으로는 우리 데이터에 무엇이 어떻게 적재되어있는 지를 알아야한다. 항상 문제는 이 것을 모를 때 발생한다. 이 문제도 그랬다.

 여기저기 터져나오는 문제의식들의 최종적인 핵심은 '스펙의 정의 부족'에 있었다. 대체 어디까지 정의해야하는가에 대해서 나는 개인적으로 '스스로 깨닫는 만큼'이라고 생각한다. 다만 그 정의가 얼마든지 바뀔 수 있도록 메이커들이 충분히 활동할 여지를 줘야한다고 생각한다.

 스펙의 정의에는 몇가지 요소가 있다.

Use case에 대한 정의

법적으로 문제되지 않으면서 우리 비즈니스에 맞는 정책

데이터 케이스에 대한 분기와 예외처리

 그리고 마지막 항목은 API와 같이 쭈욱 늘어진 데이터를 처리하는 기획을 할 때 빛을 발한다. 모든 항목을 정의하고 정리하고 정책을 정해야할 수 있다. 개인의 성장을 위해서라도 대충해서는 안된다. 문제는 본인이 정의하지 않은 정의가 뒤에 어떤 영향을 주는지 모를 때 발생한다. 제대로 스펙 정의를 하지 못하는 기획자는 메이커에서 한발짝 떨어져야한다.

  문제는 우리의 변화속도는 굉장히 빠르다는 것이다. 존재하는 서비스의 데이터 컬럼은 계속 늘어나고 그것을 파악하지 못하고 이해하지 못한다면 계속해서 한 걸음 더 물러나야한다. 결국 데이터를 이해한 스펙정의를 못하게 된다면 UX, 비즈니스, 테크의  3가지 균형은 깨져버린다.

 이 상황에서 ERD를 살피고 SQL로 데이터를 직접 보는 것은 좋은 도구가 된다. 잘못된 소통도 줄일 수 있고 개발자를 괴롭히지 않고도 데이터를 기반한 기획의 시기를 단축할 수도 있다. 물론 기본 전제조건은 우리의 데이터를 이해한다는 전제에서 말이다,

속도를 위해서는
스펙정의를 기다리면 늦어요

  하지만 문제는 속도에 있다. 세월아 내월아 하면서 한땀한땀 정리해도 새로 발견되는 케이스를 모두 준비하기엔 변화의 속도는 더 빨라야한다. 변화를 위해서는 메이커에게 룸을 내주고 뒤로 물러서는게 빠를 수 있다. 의사결정의 기준만 협의하고 방향이 맞다면 일부는 조절하며 포기하자.

 그렇다고 뒤로 물러나서 다른 일이나 하면 백엔드 설계 기획자로 성장할 수가 없다. 개발자가 만든 후에 후학습도 중요하다. 서비스의 변화를 프로드엔드만 보지 말고 데이터로도 느끼자.

 그래야 다음에 더 빠르게 논의할 때 한발짝 다가가서 정의할 때 들어갈 수 있다. 우리의 위치는 우리가 만드는 거다. 할 일이 많아지는 것을 무서워하지 말자.

 개발이 완료된 후에라도 꼭 스펙을 정리해두자. 그 마지막 절차가 스스로를 성장시킨다. 오픈해도 그 때부터 또 다음이 시작이니까.