좋은 프로덕트를 만드는 팀

속도, 디테일, 안정성의 3박자

IT에서 흔히 프로덕트는 기획자, 디자이너, 개발자 3개의 직군이 만든다고 한다. 좋은 프로덕트를 생산하는 팀을 평가하는 기준을 3가지 꼽자면 속도, 디테일, 안정성인 것 같다. 

- 속도

속도를 내지 못하면 시장 상황에 기민하게 대응하지 못할 뿐더러 팀의 동기부여가 떨어지고, 마감기한을 맞추지 못하면 반복적인 지연의 늪에 빠지게 된다.

빠르면 빠를 수록 좋다기보다는 팀의 속도를 지키는 것이 중요하다. 팀이 낼 수 있는 속도 이상으로 무리하면 디테일이나 안정성을 놓치게 된다. 팀이 낼 수 있는 속도보다 낮게 가면 최적화가 안된 것이다. 팀의 속도를 지키는 가장 확실한 방법은 커뮤니케이션 비용을 줄이고, 병목이 생기지 않게 하는 것이다. 그래서 좋은 PM은 디자인, 서버 개발, 프론트엔드 개발, 내부 컨텐츠, 외부 컨텐츠, 번역 중 어느 단계가 병목 현상이 발생하고 있는지 수시로 체크하고 조정해야 한다.

- 디테일

디테일을 놓친 프로덕트는 유저에게 감동을 주지 못하고 대개 '구리다'는 이유로 버려진다. 반대로 적절한 여백이 주는 깔끔함, 컬러로 표현되는 중요도 위계, 친절한 가이드 텍스트와 직관적인 아이콘, 애니메이션 효과의 살아있는 느낌은 유저에게 감동을 준다. 디테일에있어서는 디자이너와 프론트엔드 개발자의 역할이 중요하다. 불필요한 뎁쓰를 줄이고 기능을 추가하면서도 화면을 지저분하지 않게 만드는 일을 디자이너가 구현해주면, 프론트엔드 개발자가 가능한 선까지 그걸 프로덕트에 녹여낸다. 프론트엔드 개발자의 '이렇게 까지 해야하나'와 디자이너의 '왜 디자인대로 안나올까'의 중간 타협점에서 프로덕트가 탄생한다. 

- 안정성

안정성이 떨어지면 서비스에 대한 접근이 매우 느려지거나 심지어는 아예 접근이 안되는데, 대부분의 서비스에서 앱을 껐다 켜거나, 심지어는 지웠다 다시 깔거나, 될 때까지 충분히 기다렸다 다시 돌아와줄 유저는 거의 없다. 안정성은 인프라 개발자와 서버 개발자가 주로 책임을 지는데, 스케일업 했을 때 버틸 수 있는 구조를 미리 설계해놓는 것이 중요하다. 시스템이 잘 갖춰진 곳에서 도제식으로 배울 수도 있지만 그렇지 않은 스타트업 같은 작은 조직은 보통은 소를 잃어봐야 외양간을 고칠 줄 알게 된다. 외양간을 고치는 짬이 쌓여가면서 진짜 서버 개발자로 거듭나게 된다. 대규모의 트래픽을 경험해봤는지가 정말 중요한 것 같다. 

기획자의 속도, 디자이너의 디테일과 개발자의 안정성이라는 3박자가 맞아 떨어질 때 좋은 프로덕트가 나온다. 다만 '좋은'이라는 판단은 사용자가 하는 것이고, 이는 배포 후의 지표로 검증이 되기에, 그로스해커가 주도하는 지속적인 업데이트로 진화해나가야 한다.