MVP를 만드는 과정에서 유저와 대화하고 제품 개발하는 비중을 어떻게 나눠야 할지 결정하기 어려울 때가 많은데요. 다운님과 비슷한 고민을 하고 있거나 이를 효과적으로 해결해본 분이 계시면 댓글 남겨주세요!

</> & M⬇

메이커로그에 codeblock 과 markdown 기능을 추가했습니다. (credit to @Jae Hwan Jeong 🙌)

개발하는 과정에서 어려운 부분이나 공유하고 싶은 코드를 추가하면서 작성해 보세요 :)

👉 Markdown 가이드

Heading (h1, h2)

# MyTitle
## MyTitle

Blockquote

> blockquote text

Bold

**Bold Text**
__Bold Text__

Italic

*Italics Text*
_Italics Text_

Link

[link text](https://link_url)

Inline code block

`inline code block`

Code block

```
code block
```

List

1. one
2. two
3. three

* one
* two
* three

Strikethrough

~~Strikethrough~~

👉 Code block sample

var a = 10;
	
function bar() {
  var a = 20;
  	
  function foo() {
    console.log(a);
  }
    	    
  foo();
}

bar();

Synaptic pruning

얼마 전 팟캐스트를 듣다가 synaptic pruning(시냅스 가지치기)라는 개념에 대해 알게 되었다. 뇌에서 신경 세포를 연결하는 시냅스가 청소년기까지 엄청나게 많이 생겼다가 이후부터는 사용하지 않는 시냅스들을 알아서 쳐내는 과정인데, 아동/청소년기에는 무엇이든 유연하게 빨리 배울 수 있도록 뇌의 가소성이 가장 높고, 불필요한 시냅스 가지치기를 통해 연결고리가 강한 시냅스만 남기면서 뇌가 성숙하고 효율이 높아진다고 한다.

여기서 흥미로웠던 부분은 가소성이 너무 높을 경우 오히려 학습 결과를 기억하는 능력이 떨어진다는 거였다. 이는 실제로 머신러닝 모델을 만들 때도 적용된다고 하는데, 인공신경망의 learning rate을 너무 높이면 최근 입력된 인풋의 영향을 지나치게 받아서 기존에 학습한 것들을 다 잊어버린다고 한다.

그동안 어떻게 하면 더 많은 양의 인풋을 더 빨리 학습할 수 있을까에 대해서만 고민해 왔는데, 그러다 보니 마치 소화도 못할 만큼의 음식을 꾸역꾸역 먹고 나서 더부룩할 때와 비슷한 느낌을 가끔 받았었다. 이젠 인풋의 양만 마구잡이로 늘리기보단 집중할 분야를 몇 개 정해서 그들의 연결고리를 강하게 해줄 인풋만 골라서 넣는걸 시도해 보려고 한다.

이번 연휴동안 새롭게 만난 가족들과 시간을 보낼 기회가 있었다. 20년전 은퇴한 후 조용한 해안가 도시에 살고 계신 분들이었는데, 예상과는 다르게 웬만한 2~30대 못지 않은 에너지를 갖고 활기찬 하루하루를 살고 계셨다.

가장 놀라웠던 건 일주일에 하루를 제외하곤 매일 아침 6시에 일어나서 요일별로 정해놓은 루틴에 따라 살고 계시는 거였다. 예를 들면 목요일은 7km 조깅, 금요일은 1시간 근력 운동, 토요일은 프랑스어 공부 등등. 지난 20년동안 여행할 때를 제외하곤 이 루틴을 철저히 유지하고 있다고 하셨다. 궁금해서 비결이나 원동력을 여쭤보니 젊었을 때부터 트라이애슬론에 도전할 만큼 열성적인 운동가였고 이 루틴에서 크게 벗어나지 않는 생활을 해왔다고 하셨다.

개인적으로 나이듦에 대해 깊이 생각해본적은 없지만, 지난 몇년동안 제품 개발, 스타트업에 몰입하면서 가졌던 생각을 돌아보는 계기가 되었다. 특히 제품이 커지고 커뮤니티가 성장하면서 악성 유저나 컨텐츠가 늘어나면 우리가 처음 가졌던 비전이 망가지지 않을까에 대한 막연한 두려움이 있었는데, 단순히 나이가 들었다고 갑자기 다른 사람이 되는게 아니듯, 제품이나 커뮤니티 역시도 시간이 지나면서 일부 녹슬고 고쳐야할 부분은 생기겠지만 처음 기조 자체가 변하진 않을 거라는 것. 그것만으로도 많은 위안을 얻었다.

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

그동안 디스콰이엇에서 어떤 식으로 제품을 만드는지에 대해 궁금해 하는 분들이 꽤 많았다. 아직 이렇다할 체계적인 프로세스가 있다고 보긴 어렵지만, 지난 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명으로 늘어났는데, 앞으로 팀 규모가 커질수록 기존의 방식을 확장할 수 있는 프로세스가 필요하게 되지 않을까 고민하고 있다.