디스콰이엇 팀에서 제품 개발하는 방법

그동안 디스콰이엇에서 어떤 식으로 제품을 만드는지에 대해 궁금해 하는 분들이 꽤 많았다. 아직 이렇다할 체계적인 프로세스가 있다고 보긴 어렵지만, 지난 1년 9개월동안 우리 팀이 제품을 만들어온 과정의 특징이라고 할만한 점들을 몇가지 정리해봤다.

1) 기획은 최대한 추상화하기

우리는 어떤 기능을 개발하기로 결정하면 기획 내용을 명세하기보단 일단 만들기 시작한다. 우리 개발 프로세스는 대략 아래처럼 진행된다.

• 구상
• 기능을 만드는 배경(이유), 풀려는 문제, 현재 존재하는 해결책의 문제, 우리가 생각한 해결책 정도를 one-pager로 간단히 적는다. 이 과정에서 기능에 대한 상세 스펙보다는 기능의 방향성과 이를 개발함으로서 이루고자 하는 게 뭔지를 팀원들끼리 명확히 한다.
• 개발
• 이 안에서 리서치, 구조 설계, 디자인, 코딩을 한꺼번에 한다. 어떤 기술을 쓸지도 알아서 정하고, 시안도 필요하면 만들고 필요없으면 머릿속에 있는걸 바로 구현하면서 그 자리에서 수정해 나간다. 각자 영역에서 코딩이 끝나면 약 1~3일 정도 전체 구조를 통합하면서 정리하는 작업을 한다.
• 테스트 & 배포

이 프로세스가 워킹하려면 우리가 지금 뭘 왜 만들려고 하는지를 전체 팀원이 명확히 인지하는 첫번째 구상 단계가 정말 중요하다고 생각한다. 이 단계가 제대로 진행되면 실제 구현 중에 생기는 기획적인 부분은 만드는 과정에서 하나씩 챙겨도 별 문제가 없다. 개발 시작도 전에 이런 디테일을 미리 완벽히 예상하기가 어렵기도 하고, 만들다 보면 세부적인 사항은 계속 바뀌기도 하기 때문이다(얼마전 Relate팀이 블로그를 통해 소개한 Shape Up 프로세스와도 맥락이 비슷하다). 무엇보다 기획을 고민하는 시간에 일단 개발을 시작하는게 우리에겐 꽤나 시간 효율적이었다.

2) 가중치에 따라 테스트 리소스 분배하기

디스콰이엇엔 아직 테스트 코드가 없다. 작년 말에 TDD 도입을 잠깐 고민한 적은 있었지만 현재 단계에서 인풋 대비 아웃풋이 적을거라 판단해서 일단 미뤄둔 상태다. 그래서 현재는 새로운 기능을 만들면 그 기능 자체에 대한 기본적인 flow + 관련해서 공통 코드를 건드린 부분이 있다면 영향받는 부분까지만 딱 테스트한 후에 바로 런칭하고 있는데, 작업한 부분에 따라 테스트에 필요한 리소스도 매번 달라지곤 한다. 이에 대해 프로덕트 팀원들과 이야기하던 중 @Jae Hwan님이 아래의 수식을 만들어줬다.

UI < Frontend < Backend API < DB 구조 < 새로운 인프라

문제를 인지했을 때 바로 고치면 그만인 게 있고, 회복하는게 어렵고 오래 걸리거나 아니면 심지어 100% 회복이 불가능한 경우도 있다. 보통은 뒤로 갈수록 회복 탄력성이 낮기 때문에 이 순서대로 가중치를 둬서 테스트에 리소스를 들이는 중이다. (그리고 앞쪽의 문제들은 유저 분들이 직접 잡아주시기도 한다 😉)

3) 스프린트 사이에 1주일 정도 쿨타임 갖기

빠른 제품 개발이라고 하면 보통 코드 퀄리티랑 무조건 타협해야 한다고 생각하기 쉬운데, 코드 퀄리티에도 분명 꼭 챙겨야 할 부분이 있고 당장 타협해도 괜찮은 부분이 있다. 이 중 반드시 챙겨야할 부분을 맨먼스 미신 책에서는 ‘개념적 일관성’이라고 정의하는데, 사용자가 인지하는 제품의 모든 측면에서 일관성을 갖춰 소프트웨어를 설계하는 것이 가장 중요하며 이것이 망가질 경우 지속적인 확장을 하는게 어렵다고 한다. 다소 추상적일 수 있지만 지금까지의 경험으로 볼 땐 공감이 많이 가는 내용이다.

그래서 우리는 하나의 스프린트가 끝나면 다음 스프린트 전까지 1주일 정도의 쿨타임을 가지면서 코드를 어느정도 정리한 후 다음 스프린트로 넘어간다. 이 기간동안 잔버그 수정이나 중복 코드 제거, 스타일 정리 등의 작업도 하지만 코드 전반적으로 구조가 제대로 유지되고 있는지, 새롭게 확장한 부분이 기존 코드베이스와 잘 어우러지는지 등을 우선순위로 두고 정리 작업을 하는 편이다.

4) 자주 런칭하는 것에 익숙해지기

보통 2주 단위로 개발하고 런칭하는게 좋다는 얘기들을 많이 하고, 디스콰이엇 역시도 비슷한 주기로 스프린트를 진행하고 있다. 하지만 개발하다 보면 딱 2주 안에 떨어지지 않는 기능도 많다(예를 들어 우리도 메이커로그, 메이커스퀘어 같은 큰 피처는 구상부터 배포까지 4주 이상 걸렸다). 일반적으로 여기서 오해가 많이 생긴다고 생각하는데, 이건 피처의 크기와 관계 없이 정해놓은 기간 안에 엉망으로라도 개발해서 런칭해야 한다는 게 아니라, 자주 런칭하는 것 자체에 익숙해지는 게 중요하단 뜻이다.

글쓰기를 예로 들어보면, 글의 길이와 관계 없이 원래 꾸준히 글을 써오던 사람은 새로운 글을 써서 올리는 것에 대한 부담감이 상대적으로 적다. 반면 이런 습관이 없는 사람에게는 글을 써서 올린다는 것 자체가 대단한 이벤트로 느껴지기 때문에 본인 마음에 드는 완벽한 글이 써질 때까지 계속 다듬기를 반복하다 결국 몇 번 쓰지 못하기가 쉽다. 제품 개발도 사실 마찬가지다. 그닥 마음에 들지 않더라도 일단 끊어서 내보내는 행위 자체가 익숙해지고 나면 큰 단위의 기능이라도 next step으로 나눌 수 있는 부분을 한번 더 정의하고 쪼개면서 더 작게, 자주 배포할 수 있게 되는 것 같다.

한 가지 caveat이 있다면 위 내용 중 일부는 우리가 정말 소규모 팀이라 가능했던 것일 수도 있다. 우린 1년 반동안 @Hyunsol님과 나 2명이서 이런 식으로 제품을 만들어왔고 최근에야 @Jae Hwan & @Hongmin님까지 4명으로 늘어났는데, 앞으로 팀 규모가 커질수록 기존의 방식을 확장할 수 있는 프로세스가 필요하게 되지 않을까 고민하고 있다.