[트로우] 투트랙 개발로 빠르게 서비스 개선하기

영준님이 작성하셨던 글을 읽으면서 트로우를 시작했던 때가 생각났습니다. 저희팀은 영준님께서 말씀해주신 action-faking에 빠져있었습니다. 꾸준히 내부적으로 서비스가 발전하는 방향성을 고민하며 개선해 나갔습니다.

그러나 이런 발전의 과정에서 여러 차례 전략을 수정해야 했습니다. '서비스 장례식'이라는 개념을 도입해 서비스의 일부 기능들을 제거한 경험이 그 예입니다. 당시에는 이렇게 기능을 정리하는 과정이 꼭 필요하다고 느꼈지만, 스타트업의 입장에서 그 과정이 무겁게 느껴졌습니다. 시간이 금인 스타트업으로서 너무 많은 시간을 보내버렸으니까요.

이러한 배움을 토대로 저희 팀은 좀 더 효율적으로 서비스를 개발하고자 투트랙 개발을 도입하게 되었습니다.

트랙 1 : 고객의 니즈에 따른 개발

팀 내부에서 생각하는 서비스 개선과 고객이 직접 느끼는 서비스 개선 사이에는 큰 차이가 있다는 것을 절감했습니다. 그래서 저희 팀은 고객의 의견을 최대한 반영하기 위해 고객 문의 및 인터뷰를 지속적으로 수행하고 있습니다.

문의나 기능 요청이 들어오면, 저희는 두 가지를 빠르게 체크합니다. 첫째, 이 요청이 다른 고객에게도 도움이 될 것인지, 둘째, 이 요청이 장기적인 서비스 방향성을 해치지 않는지를 확인합니다. 이 두 가지 조건을 모두 충족할 경우 바로 개발에 착수합니다.

최근에는 고객의 요청을 받아 zapier 연동 기능을 도입해 자동화를 구현했습니다. 그 분은 자신이 찍는 유튜브 영상을 블로그, 인스타그램 등에서 활용하고 싶어하셨습니다.

내부적으로 회의를 거쳐 장기적으로 저희 서비스가 나아가야 할 방향과 고객님의 요청이 일치한다는 결론을 내렸습니다. 그래서 자동화 기능을 더 빨리 구현해야겠다는 결정을 내렸고, 해당 고객에게 베타버전을 제공했습니다. 그 결과, 그분은 저희 서비스의 열렬한 팬이자 테스터가 되어주셨습니다.

트랙 2 : 장기적인 플랜에 따른 개발

하지만 절대적인 원칙은 장기적인 플랜에서 벗어나지 않는 것입니다. 고객들의 요청은 절대적인 모든 고객의 요구를 반영하지 않을 수 있으며, 저희가 목표로하는 방향과 다를 수 있습니다. 그래서 고객 요청에 빠르게 대응하는 것이 중요하면서도, 저희의 목표를 항상 기억하고 있습니다.

이를 위해 저희는 우선순위 설정에 많은 노력을 기울입니다. 투트랙의 한 쪽에 치우치지 않기 위해 우선순위에 맞추어 업무를 수행하고, 고객 요청이더라도 우선순위가 낮다고 판단되면 가능한 한 미룹니다. 예를 들어, 서비스 초기부터 비디오를 다른 컬렉션으로 이동하도록 하는 기능에 대한 요청이 있었지만, 이 기능은 최근에야 추가하였습니다.

개발 리소스가 충분해서 가능한 것 아닌가요?

'개발 리소스가 충분해서 그렇게 할 수 있는 거 아닌가요? 저희는 한 가지만 처리하는 것도 힘든데...' 라는 말이 들립니다. 그러나 개발 리소스가 넉넉한 회사는 그렇게 많지 않습니다. 저희도 더 많은 개발을 더 빠르게 하고 싶습니다. 그럼에도 불구하고 리소스의 한계를 인식하고, 그 한계 내에서 올바른 방향으로 개발을 추진해야 한다는 것을 경험을 통해 배웠습니다.

네트워킹에 나가보니 초기 서비스를 빌딩하시는 분들이 참 많이 있었습니다. 언제나 밸런스를 맞추어 나가는 것은 중요하더라구요. 모두들 개발에 있어서도 회사의 입장과 고객의 요청에 밸런스를 맞추어 고객을 확보하면서도 큰 그림을 그려나가시길 응원합니다.