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명으로 늘어났는데, 앞으로 팀 규모가 커질수록 기존의 방식을 확장할 수 있는 프로세스가 필요하게 되지 않을까 고민하고 있다.

👫 원하는 메이커를 팔로우해 보세요.

그동안 많은 요청을 받았던 기능 중 하나인 유저 팔로우 기능을 드디어 런칭했습니다 🙂

이제 디스콰이엇에서 원하는 유저 분들을 팔로우하고, 팔로우한 유저의 컨텐츠만 필터링해서 확인해 보세요.

What’s new

1) 프로필, 메인 피드, 포스트 페이지, 알림창 등에서 유저 팔로우하기

유저 프로필을 보다가, 또는 포스트를 확인하다가 관심있는 유저를 찾으면 바로 팔로우할 수 있어요.

2) 팔로우 중인 유저의 포스트만 필터링하기

메인 피드에서 내가 팔로우 중인 유저들의 포스트만 모아서 확인할 수 있어요.

3) 추천 메이커 섹션 추가

현재 디스콰이엇에서 활발히 활동 중인 유저 분들을 모아서 볼 수 있는 추천 메이커 섹션을 만들었습니다. 아직 누구를 팔로우할지 잘 모르겠다면 여기서 관심가는 메이커를 찾아서 팔로우해 보세요.

4) 피드백 로봇 추가

앞으로 디스콰이엇을 이용하면서 피드백이나 문의, 요청사항이 생기면 사이트 오른쪽 하단에 있는 로봇에게 바로 알려주세요. (디스콰이엇 팀 내에서는 불만이로 불리고 있어요 ㅋㅋ)

팔로우 기능을 개발한 배경

최근 디스콰이엇에 올라오는 포스트가 늘어나면서 크게 두 가지 문제가 생겼습니다.

• 피드에 올라오는 모든 포스트에 관심이 있는건 아닌데 내가 원하는 컨텐츠만 우선적으로 볼 방법이 없음
• 컨텐츠를 아무리 주기적으로 올려도 조금만 지나면 포스트가 피드 아래로 묻히면서 이에 대한 피드백이나 리워드를 얻기 어려움

위 문제들을 가장 빨리 해결하면서 유저들 간에 밀접한 관계를 만들 수 있는 방법이 팔로우 기능을 개발하는 것이라고 생각했어요. 지금까지는 유저들 간에 일회성 커피챗 요청 또는 포스트 상에서 upvote나 댓글로만 관계를 형성할 수 있었다면 팔로우를 통해선 보다 지속적인 관계를 맺을 수 있고, 가치있는 컨텐츠를 꾸준히 생산하는 유저에게는 추가적인 리워드의 역할을 하면서 사이트 상에서의 파급력을 높일 수 있어요. 또한 유저 간에 연결고리가 많아질수록 포스트에 대한 관심도 뿐 아니라 유저 관심도까지 표현이 가능해지면서 추후에 나와 잘 맞는 메이커를 찾을 확률 역시 높아집니다.

What’s next

이번 개발 범위에 넣고 싶었지만 빠른 런칭을 위해 일단 잘라낸 기능들이에요.

• 팔로우 중인 사람이 포스팅할 경우 바로 알림을 받을 수 있는 알림 설정 기능
• 팔로우 중인 사람의 포스트들이 메인 피드 상단에 추천되게 하기
• 추천 메이커 리스트에서 팔로우를 클릭할 경우 팔로우한 유저는 없어지고 새로운 유저가 다음에 추천되는 기능

팔로우 기능 개발 과정 중에도 재미있는 부분이 많았는데, 이에 대한 자세한 내용은 별도의 메이커로그로 곧 공유해볼게요 😎

🙋‍♀️기존에 사용하는 글쓰기 플랫폼이 궁금해요!

‘모든 사람들은 어딘가엔 글을 쓰고 있다’는 말을 듣고, 플랫폼을 갈아타지 않고도 쓴 글들이 디스콰이엇으로 연동될 수 있으면 좋겠다는 생각이 들었어요.

여러분은 기존에 글을 쓸 때 주로 어떤 플랫폼을 사용하시나요? 

아래 댓글에 좋아요로 투표해주세요 ㅎㅎ

메이커 스퀘어 기능 업데이트 ✱✱

이제 디스콰이엇에서 직접 팀빌딩을 하실 수 있어요!

지금까지 디스콰이엇에서 메이커 분들을 만나면서 가장 많은 분들이 공통적으로 이야기해주신 어려움 중 하나가 팀빌딩에 대한 부분이었는데요, 이제 디스콰이엇에서 자체적으로 팀빌딩을 하실 수 있게 메이커 스퀘어라는 공간을 만들었습니다!

메이커 스퀘어에서는 참여하고 싶은 사이드 프로젝트부터 코파운더, 협업 파트너, 스터디 멤버까지 다양한 유형의 팀원 또는 프로젝트를 찾아보고, 관심있는 팀빌딩 포스트가 있을 경우 메이커에게 바로 연락을 해볼 수도 있습니다. 또한 상대방이 어떤 관심사나 고민의 흔적을 가지고 있는지 메이커 프로필이나 이전에 작성한 메이커로그 등을 통해 알아볼 수 있기 때문에 서로 상호보완이 잘 되는 관계일지 어느정도 미리 확인도 가능해요.

아래에서 자세한 메이커 스퀘어 사용 방법을 확인해보세요 🙂

팀빌딩 포스트 작성하기

• 메인 페이지 상단 새 포스트에서 팀빌딩하기를 선택한 후 찾고 있는 팀원이나 프로젝트, 또는 팀에 대한 내용을 자유롭게 설명해주시면 됩니다.
• 원하는 팀빌딩 유형 및 메이커 스킬, 관련 프로덕트, 프로젝트 토픽 등을 함께 설정할 수 있어요.

원하는 팀빌딩 포스트 찾기

• 메인 피드에서 메이커 스퀘어 탭을 클릭하면 원하는 팀빌딩 유형 또는 찾는 메이커 스킬에 따라 팀빌딩 포스트를 필터링할 수 있어요.

관심있는 메이커에게 커피챗 요청 또는 프로젝트 제안하기

• 관심있는 프로젝트나 팀원에 대한 포스트를 찾았다면 찜하기를 눌러 저장해놓을 수 있고, 바로 커피챗을 요청하거나 프로젝트를 제안해볼 수도 있어요.
• 받은 요청이나 제안을 수락하면 이메일을 통해 대화를 시작할 수 있습니다.

+ 미니 기능

새로 디스콰이엇에 조인한 분들의 이름 옆에 환영하는 의미로 새싹 뱃지를 달아보았습니다 🌱 (앞으로 더 많은 뱃지들이 생길 예정이에요!)

🌳 정창경 워크샵에서 나눈 대화들

디스콰이엇에서 정주영 창업경진대회 워크샵에 다녀왔어요!

1박 2일동안 비슷한 단계에 있는 창업자 분들과 이야기하면서 인사이트 뿐 아니라 심리적인 위안과 에너지를 많이 얻었습니다. 각자의 역할이나 풀고 있는 문제, 고민의 형태는 다 달랐지만 이런 내용을 서로 공유하는 것만으로도 도움이 많이 되더라구요.

세션을 비롯해 다양한 주제로 대화를 많이 나눴는데, 잊어버리기 전에 기록으로 남기고 싶어서 기억나는 내용들을 적어봤어요.

팀원들과 친구같은 분위기에서 효율도 챙기는 법

• 친구들끼리 재밌게 시작한 팀인데 사람이 늘어나면서 프로세스를 만들어야 하는 경우
• PM이 따로 있지 않는 이상 누군가는 일정을 계속 챙기며 bad cop 역할을 해야함
• 데드라인을 맞추지 못할것 같을때 대처하는 방법
• 팀에게 미안해하지 말고 최대한 미리 커뮤니케이션하기 -> 커뮤니케이션이 안되서 나중에 늦게 알게 되는 경우 딜레이되는것 이상으로 문제가 커짐
• 필수적이지 않은 부분을 다 빼버리고라도 데드라인에 맞춰보기
• 이런 방식을 괜찮아하는 사람이 아닐 경우 설득이 어려울 수 있음
• 4~5명 정도만 되도 전체회의로 어느정도 커버가 가능. 8명이 넘어가는 순간부터는 확실히 시스템이 필요해지고 회의가 여기저기서 엄청나게 많아짐
• 실제로 많은 기업에서 하나의 팀을 6~8명 이내로 유지하려 하기도 함

불안감을 해소한 경험

• 태스크를 잘게 쪼개 작은 성취를 계속 맛볼수 있게 하기
• 성취한 것들 또는 현재 느끼는 불안한 감정에 대해 글로 적어보기
• 주위 사람들과의 대화를 통해 불안한 감정에 대한 객관적 시각을 되찾기
• 좋아하는 드라마 장면이나 영상을 계속 반복해서 보기
• 좋아하는 노래를 틀어놓고 청소하기
• 리더로서 나를 믿고 따라와주는 팀원들이 고마우면서도 묘하게 부담이 느껴짐 -> 이런 감정을 어느정도 팀에 솔직히 표현하는 것도 도움이 됨
• 항상 다양한 관점, 겸손한 자세를 가지려고 노력하기
• 겸손과 자신감 사이의 균형을 찾기

커뮤니티 vs 유틸리티 서비스

• “Community first”
• 유틸리티는 특정 니즈가 있을때만 찾게 되지만, 커뮤니티는 외로움/지루함 등의 감정을 느낄때마다 찾게되기 때문에 사용 주기가 훨씬 짧음
• 커뮤니티 서비스는 보통 하나의 silver bullet으로 정의하기가 어려워서 어느정도 커지기 전까진 위의 논리로 설득하기가 쉽지 않음
• 유틸리티를 먼저 잘 만들고 나중에 커뮤니티를 붙이는 경우가 많은데 이 방법이 항상 워킹하는지는 의문

확장하지 않는 제품 만들기

최근 우리가 잘 아는 성공한 프로덕트들이 초기에 기술적으로 어떻게 “확장하지 않는 일”을 하면서 제품 문제를 해결했는지에 대한 영상을 봤는데, 흥미로운 내용이 많아 한번 정리해봤다.

Gmail

• 문제: 서버 용량이 부족했음
• 해결책: 한명의 지메일 가입자에게 4명 더 초대할 수 있는 invite을 주는 식으로 확장함(요즘 생각하는 바이럴을 위한 growth hack이 아니라 가입자 폭증을 방지하기 위한 장치였음)

Facebook

• 문제: 처음에 대학 소셜네트워크로 시작했을 때, 유저 증가 속도가 너무 빨라서 하나의 유저 테이블을 계속 확장하는게 불가능했음
• 해결책: 새로운 학교로 런칭할 때마다 기존 코드를 복붙하면서 웹서버, DB서버를 학교마다 따로 셋업하는 식으로 확장함(하버드/예일/스탠포드 서버가 다 따로 있는 식). 그러다 나중에 유저들이 다른 학교끼리 왔다갔다 할 수 있는 기능을 만들었고, 그 후 몇 년이 지나서야 하나의 테이블에 전체 유저 데이터를 통합할 수 있었음

Twitch

• 문제: 유명 연예인이 스트리밍을 할 때면 평소 20x 정도의 트래픽에 대비해야 했는데, 스트리밍에 접속한 유저들 이름이나 조회수 같은 정보를 실시간으로 가져오려면 서버가 죽는 상황이었음.
• 해결책: 영상은 실시간으로 보여주고, 유저네임이나 조회수 정보는 임의의 값을 사용하는 페이지를 만들어서 전부 실시간인 것처럼 보이게 함

Myspace

• 문제: 로그인했을때 내 친구의 친구인 사람들 목록을 보여주려고 함
• 해결책: 당시 비슷한 소셜네트워크였던 Friendster에서는 엔지니어들을 고용해서 이를 기술적으로 해결하려고 애쓴 반면, Myspace는 친구목록에 있으면 친구라고, 아니면 “your extended network”에 있다는 문구를 띄우는 걸로 대체

Instagram(다른데서 본 일화인데 비슷한 맥락이라 추가)

• 문제: DB서버를 하나만 띄웠는데 가입자가 폭증하면서 터져버림
• 해결책: 처음엔 멋있는 최신 기술을 이용해 데이터를 여러 DB로 자동 분산하려고 몇 달동안 시도해봤지만 잘 안됨. 결국 DB서버 하나를 새로 띄우고 유저ID가 짝수면 첫번째 서버로, 홀수면 두번째 서버로 보내는 식으로 작업했더니 2시간 만에 해결됨

우리도 디스콰이엇을 만드는 과정에서 비슷한 고민을 계속 하고 있다. 특히 새로운 기능을 개발할 때 ‘어디까지 끊어서 만들어야 하지?’, ‘다른 서비스는 어디까지 고려했지?’ 등을 고민하면서 제품 완성도와 개발 속도 사이에서 적절한 균형을 찾아나가는 중인데, 이 과정에서 딜레마가 자주 발생한다. 크게 두 가지 이유에서인것 같다.

1) ‘어디까지 막 만들어도 괜찮은지’에 대한 기준이 모호함

이전에 프로덕트를 만들 때 ‘일단 만들고 나중에 수습하자'는 식으로 했다가 다 갈아엎어야 했던 적이 있어서, 이번에 디스콰이엇은 처음부터 확장 시나리오를 어느 정도 그려가면서 체계적으로 만들려고 노력했었다. 결과적으로 예상대로 확장한 부분도 있지만 그렇지 못한 부분도 많은데, 다시 생각해봐도 1년 전에 이런 것들을 미리 예측할 수는 없었다. 결국 제품이 커가면서 기술 부채가 생기는 건 어느 정도 필연적이란 얘기다.

그래서 최근엔 새로운 기능을 만들기 전에 미리 확장성을 걱정하기보다는, 일단 빨리 만들어보고 중간중간 어떻게 다듬을지에 대한 고민을 더 많이 하게 되었다. 어차피 처음부터 모든걸 완벽히 설계하는건 불가능하고, 문제를 풀어나가면서 해결책이 계속 바뀔 수밖에 없다고 생각하니 해결책 하나하나를 완성도있게 만들어야 한다는 부담이 많이 적어진 것 같다.

2) 직접 만들다 보면 애착이 생겨서 자꾸 정성을 들이게 됨

몇 달 만들고 버릴 프로덕트가 아닌 이상 오래 키울 생각으로 만들다 보면 보통 애정이 생기기 마련이다. 애정을 갖는 것 자체가 나쁜건 아니지만, 이런 감정에 빠질수록 당장 중요하지 않은 것에까지 정성을 쏟기가 쉽고 자주 런칭하기 어려워지는 경우가 많았다.

이럴 때 우리가 썼던 방법 중 하나는 기능 단위가 아닌 기간 단위로 끊어서 런칭하는 거였다. 예를 들어 2주 안에 신규 기능을 런칭하려고 했는데 중간에 다 못 만들겠다 싶으면 기능이 돌아가는데 정말 필수적인 부분을 제외하고 다 잘라버린 버전으로라도 2주 안에 런칭하는 식이었다. 흥미로운건 처음에 잘라낼 때는 마음이 좀 아픈데 일단 런칭하고 나면 잘라낸 부분에 대해 요청이 들어오는 경우는 별로 없어서 자연스럽게 최소 버전으로 개발이 가능했다는 점이다.

성공한 프로덕트들은 처음부터 철저한 기술적 설계를 통해 차근차근 만들어졌을 것 같았는데 저렇게 허술하게 만든 때도 있었다는게 인상적이었다. 아래는 영상에서 제일 공감갔던 quote:

“A lot of the best product decisions are made fast and under duress”

1주일간 13번의 유저 인터뷰를 진행하고 배운점

지난주에 총 13명의 유저 분들과 디스콰이엇에서 진행한 메이커클럽에 대해 이야기를 나눠볼 수 있었다. 그 중 기억에 남는 몇가지를 짧게 정리해 봤다.

네트워킹 그룹 나누기

메이커클럽을 시작하기 전부터 계속 궁금했던 부분이 어떤 식으로 그룹을 이뤄야 효과적인 네트워킹이 일어날 수 있을지였다. 처음에는 비슷한 프로덕트 단계(아이디어, MVP 개발, 유저 리서치 등)에 있거나 비슷한 분야의 프로덕트(B2B/SaaS, 소셜, 게임 등)를 만드는 사람들끼리, 혹은 같은 직군끼리 묶는것 정도를 생각해 봤는데, 그 안에서도 네트워킹 목적이 다 다를수 있기 때문에 사람들이 어떤 경우에 누구와 네트워킹을 원하는지 알고 싶었다.

인터뷰 과정에서 이런 내용을 직접적으로 질문하기보다는 메이커클럽에서 진행한 네트워킹 세션에서 아쉬웠던 점에 대한 답변을 통해 파악해보려고 했다. 그 결과를 취합해서 정리해보니 대략 다음과 같이 구분해볼 수 있었다.

여기서 흥미로웠던 부분은 호기심이나 공감대 형성처럼 감정적인 동기로 네트워킹을 원하는 메이커 분들 중 프로덕트에 대한 몰입 정도(commitment)가 비슷한 분들끼리 연결되기 원하는 경우가 많다는 거였다. 예를 들면 사이드프로젝트를 하는 분이 다른 사람들은 프로덕트를 어떻게 만드는지 궁금해서 들어왔을 경우 창업자보다는 비슷하게 사이드로 만드는 분들의 이야기를 더 궁금해한다거나, 창업가들이 각자 겪는 문제나 고민을 캐주얼하게 나누고 싶을 경우 창업가로만 구성된 그룹을 원하는 식이었다.

반면 인사이트나 피드백 얻기, 팀빌딩처럼 보다 실질적인 목적의 네트워킹을 원하는 경우 다른 건 다양해도 상관없지만 비슷한 분야의 프로덕트 관심사를 가진 분들과 연결되길 선호하는 분이 많았다. 그리고 모수가 작아서일수도 있지만 같은 직군끼리 네트워킹을 하려는 니즈는 생각보다 많지 않았다. 이런 직군 단위의 커뮤니티는 이미 다른데도 많이 있어서일까 싶기도 하다.

플랫폼 vs 커뮤니티

평소 개발에 몰입하다 보면 내가 풀려고 했던 문제의 본질에 대해 잊어버리기가 정말 쉬운것 같다. 유저 인터뷰를 하면서 다시 한번 깨달은게, 디스콰이엇 사이트에 대한 피드백을 요청했을때 내가 자주 걱정했던 퍼포먼스, 버그, 새로운 기능 요청보다는 더 많이 올라왔으면 하는 컨텐츠의 특성이나 커뮤니티에서 전반적으로 느껴지는 분위기 등에 대한 피드백이 훨씬 많았다. 생각해보면 당연한게 우리는 플랫폼이기 이전에 ‘메이커를 위한 커뮤니티'이다. 우리가 컨텐츠를 자동으로 큐레이션해서 올리는 플랫폼도 아니고 유저들이 직접 컨텐츠를 생산하고 공유하면서 커뮤니티의 색을 만들어가는 곳이기 때문에 플랫폼 자체의 정교함보다 위의 요소가 중요할 수 밖에 없다. 기능 개발은 위의 목적을 달성하기 위한 수단으로만 생각해야겠다는 걸 다시한번 스스로 리마인드할 수 있었다.

최근 현재 단계에서 가장 집중해야 되는게 뭘까에 대한 고민을 많이 했었는데, 확실히 유저 분들의 이야기를 듣고 이해하는 과정에서 생각을 어느정도 정리할 수 있었다. 그리고 이번에 얻은 인사이트는 앞으로 새로운 모임을 기획할때 뿐 아니라 디스콰이엇 사이트를 개발할 때도 활용할 수 있을것 같다. 현재는 사이트 상에서 프로덕트나 메이커로그 두가지 포스트 양식에서 파생된 형태의 대화만 일어날 수 있는데, 나중에 커뮤니티적인 기능(팀빌딩 기능, 관심사별 그룹 채널 생성 등)을 추가할 때 참고해봐야겠다.

디스콰이엇 기능 업데이트 공지 📣

디스콰이엇에서 다른 유저 분들과 교류할 수 있는 기능이 추가되었어요!

1) 프로덕트 팀원 추가하기

프로덕트를 함께 만든 메이커가 있다면 프로덕트 공유/수정 페이지에서 팀원을 추가해 보세요.

• 프로덕트 페이지에 메이커로 함께 등록됩니다 😎
• 팀원으로 추가된 메이커 분은 프로필 페이지에서 ‘현재 만들고 있는 프로덕트’나 메이커로그 작성시 관련 프로덕트에 해당 프로덕트를 추가하실 수 있어요.

2) 유저 멘션하기

이제 메이커로그 본문이나 포스트 댓글에서 다른 유저분을 멘션하실 수 있어요! 유용한 포스트를 팀원에게 알려주거나, 메이커로그에서 다른 메이커를 소환하고 싶을때 사용해 보세요.

• @ + 멘션하고 싶은 유저 이름이나 닉네임으로 검색할 수 있어요.
• 멘션된 유저에겐 알림이 나갑니다.

한번 써보시고 피드백 많이 부탁드려요~!

새해 디스콰이엇 기능 업데이트 소식

메이커 여러분 새해복 많이 받으세요! 🙇

올해 첫 기능 업데이트 소식을 전해드릴게요.

1) 포스트 투표 & 댓글 좋아요한 사람 확인 기능

그동안 내 포스트에 투표한 사람을 확인하려면 디스콰이엇 내 알림 내역에서 최신 1명까지만 볼 수 있었는데, 이젠 포스트의 upvote 버튼 왼쪽에서 모두 확인이 가능합니다. 어떤 사람들이 어떤 포스트에 관심을 갖고 있는지 한번 확인해보세요.

댓글에 좋아요한 사람들도 댓글 옆 👍 아이콘을 클릭하면 확인할 수 있어요.

2) 포스트 조회수 확인 기능

이제 프로덕트나 메이커로그를 올린 분들은 자신의 포스트가 얼마나 조회되었는지 알 수 있습니다. 내 프로필 페이지나 메인 피드에서 해당 포스트 카드 하단의 👁 아이콘 옆에서 확인해 보세요.

• 포스트를 올린 유저의 조회수는 포함되지 않습니다.
• 1월 13일에 배포되었기 때문에 그 이전의 조회수는 반영되어 있지 않습니다 :(

+ 디스콰이엇 팀은 이번주 동안 강릉에서 일하고 있습니다. 눈쌓인 겨울 바다가 너무 예뻐서 살짝 공유해봅니다 :)

2021 회고

2021년은 그 어느 해보다 다이나믹했다. 다니던 회사를 퇴사하고, 디스콰이엇을 만들고, 사이드로 시작했던 프로젝트가 하나의 사업이 되고 투자를 받고 팀원을 채용하는 전 과정을 난생 처음 경험하면서 끊임없이 배우고 또 배웠다. 배운 것들을 무작정 나열하면 너무 길어질 것 같아 몇 개 기억에 남는 키워드 위주로 정리해보려고 한다.

창업

임팩트있는 하나의 프로덕트를 처음부터 제대로 만들어보고 싶다는 생각은 지난 몇년간 계속 해왔다. 이 욕구는 회사 일이나 작은 사이드 프로젝트로는 잘 채워지질 않아서 자연스럽게 창업에 관심을 갖게 됐는데, 제품을 만들 줄만 알았지 그걸 사업화 한다는건 한없이 막막하게만 느껴졌다. 그러던 중 만들고 싶었던 프로덕트 비전이 같은 현솔님을 만나 디스콰이엇을 함께 창업하면서 내가 막막해했던 부분이 하나씩 실현되는 걸 직접 경험할 수 있었다. 그 과정에서 배운게 정말 많은데 크게 세가지가 있다. 

1. 비즈니스와 프로덕트는 따로 노는 게 아니다.

예전엔 제품 만드는 것과 사업적인 부분을 자꾸 분리해서 생각하는 경향이 있었던 것 같다. 그래서 사업화에 대한 부분을 더 어렵게 느꼈던것 같은데, 실제론 이 둘을 그렇게 나눠놓을 수 없다는 걸 깨달았다. 단순히 말해 어떤 문제를 해결하기 위해 만들어지는게 프로덕트이고, 이게 많은 사람들이 갖고 있는 문제면 자연스럽게 사업이 될 수 있는 거였다. 그렇다 보니 이 프로덕트가 비즈니스적으로 어떤 목적을 달성해야 하는지 모르면서 좋은 프로덕트를 만들 수 없고, 문제를 해결하는 프로덕트가 어떻게 돌아가는지 전혀 모르면서 좋은 사업을 만들기는 정말 어렵겠다는 생각이 들었다.

2. 사업은 특별한 성향이 있어야 잘 하는게 아니다.

정확한 계기는 모르겠지만 사업가라고 하면 떠오르는 특정 성향의 사람들이 있었다. 인맥이 넓거나, 약을 잘 팔거나(?), 엄청나게 외향적이거나 하는 특성의 사람들인데 올해 그런 편견이 많이 깨졌다. 현솔님을 봐도 그렇고 주위에 창업가들을 봐도 정말 다양한 성향의 사람들이 다양한 이유로 멋지게 사업을 해나가는 걸 볼 수 있었다. 개인적으로는 어떤 성향이나 백그라운드 보다는, 풀려는 문제에 대해 확고한 주관을 갖고 끊임없이 정보를 습득하면서 사업 방향을 잡아나가는 게 제일 중요한 기본기가 아닐까 싶다.

3. 나는 불확실한 상황이 생각보다 잘 맞는다.

이전에 외국계 대기업에도 있어보고 커리어 전향 후 스타트업에서도 몇번 일해보다 올해 창업으로 이어졌는데, 회사의 안정성만 놓고 보면 지금이 가장 바닥이지만 나는 지금이 심리적으로 가장 만족스럽다. 오히려 안정적인 조직에서 일할수록 이대로 안정감에 파묻혀 정체될지도 모른다는 생각에 항상 전전긍긍했던것 같다. 앞으로 불안정한 정도가 점점 커지면 어떻게 될지 모르겠지만, 적어도 지금까지는 다양한 아이디어를 시도해보면서 답을 찾아나가고 제품이 조금씩 커가는 모습을 보면서 얻는 성취감이 불확실한 상황에 대한 불안감을 많이 상쇄시키는것 같다.

제품 개발

지금까지 개발자로 일을 할때 제일 힘들었던 게 항상 내가 만들고 싶은 것만 만들 수가 없다는 거였다. 결정적으로 내가 가장 동기부여되는 시점이 단순히 기술적 문제만 해결할 때가 아니라 지금 뭘 왜 만드는지 정확히 이해하고 공감할 때였는데, 그러다 보니 이게 조금이라도 어긋날 때마다 의욕이 급격히 떨어지는 상황이 반복되었던 것 같다. 

그래서 디스콰이엇을 만드는 과정이 고난했지만 정말 즐거웠다. 처음에는 내가 과연 하나의 서비스를 책임지고 개발해서 키워나갈 역량이 될지에 대해 걱정이 많았는데, 만드는 제품에 대한 확실한 목적 의식을 가진 상태에서 개발을 하니 아무리 어렵고 짜증나는 문제에 부딪혀도 계속 파고들어 해결할 에너지가 생겨났다. 현솔님 역시도 개발 백그라운드가 전혀 없는데 제품을 만들겠다는 의지만 갖고 뛰어들어서 엄청난 속도로 배우는 걸 보면서, 제품의 목적과 완벽히 align된 상태에서 개발을 할 때 어느 정도의 생산성이 날 수 있는지 알게 됐고 스스로 놀라기도 했다. 무엇보다 지금처럼 초기 단계에서는 경력이 많은 시니어 엔지니어가 팀에 없더라도 계속 배우면서 유저가 원하는 제품을 개발해나가면 되겠다는 자신감이 생긴게 제일 큰 수확인 것 같다.

공개적인 글쓰기

올해 메이커로그 기능을 기획하고 개발하면서 자연스럽게 글쓰기라는 주제에 대해 많이 고민해봤던것 같다. 특히 ‘공개적 글쓰기’에 대해 그동안 해왔던 생각들을 많이 정리할 수 있었다.

나는 보통 떠오르는 생각이 있으면 여기저기 끄적여놓고 나중에 모아서 정리하는 편인데 이걸 공개적인 곳에 올린 적은 거의 없었다. 왜 그랬을까 생각해보면 내 글이 모르는 누군가에게 평가받을 수 있다는 것에 대한 약간의 두려움 + 공개하기 위해선 정말 완성도 높은 글을 써야 된다는 부담감이 컸던 것 같다. 그런데 이렇게 나만을 위한 글쓰기를 하다 보니 독자가 나 자신뿐이라, 내가 아는 범위 내에서 많은 문맥을 생략하고 자꾸 굉장히 간소화된 버전의 글을 쓰게 됐다. 문제는 내 기억력이 생각만큼 좋지 않기 때문에 몇 달만 지나도 당시에 안다고 생각했던 걸 많이 잊어버려서, 지금까지 내가 쓴 글들을 다시 읽어보면 당시 생각을 제대로 이해하기 어려운 글이 많다.

공개적으로 글을 쓰다 보면 이런 부분이 자연히 해결된다. 내 생각을 누가 봐도 이해할 수 있게 풀어서 정리하는 과정은 귀찮을 수 있지만, 그 노력 자체만으로 글의 완성도보다 더 큰 의미를 가진다고 생각한다. 특히 제품을 만드는 메이커로서 왜 이걸 만드는지, 이걸로 어떤 문제를 해결하려고 하는지 제품을 통해 계속 설명하고 표현해야 되는데, 글을 쓰면서 생각을 정리하고 나중에 그 생각 과정을 돌아보는게 제품 방향을 잡는 데에도 많은 도움이 된다. 그래서 내년에는 최대한 주기적으로 공개 글을 쓰고 제품이 발전해나가는 과정을 많은 분들과 공유해 보려고 한다.

이번달 16일을 기점으로 디스콰이엇 유저가 10,000명을 찍게 됐다! 런칭한지 정확히 9달 만이다. 아직 갈길이 멀긴 하지만 한 해가 가기 전에 이 정도의 마일스톤을 달성해서 기쁘고, 우리 팀이 정말 자랑스럽다 :)

내년에도 올해만큼 많이 배우고, 삽질도 많이 하고, 더 많은 메이커 분들을 만나서 자극받고, 어떤 피드백이든 받아들일 수 있는 말랑말랑한 상태를 유지하면서 열심히 달릴 수 있었으면 좋겠다.

2021년 안녕~ 👋

메이커로그 기능 업데이트 소식 💌

지난 달에 메이커로그 베타 버전을 런칭한 후 다양한 피드백을 받았는데요, 이를 바탕으로 불안정한 부분을 개선하고 새로운 기능들을 추가해 오늘 정식 런칭을 하게 되었습니다 🎉

이번에 업데이트된 내용을 아래에서 확인해 보세요.

1) 메이커로그 텍스트 에디터 기능

이제 기본적인 텍스트 에디터 기능을 통해 메이커로그를 보다 풍부하게 작성하실 수 있습니다.

• 현재 에디터 기능은 pc버전에서만 사용 가능합니다(모바일은 아직 최적화 작업이 필요해요 🧑‍🔧)

2) 메이커로그 작성창 확장 기능

기존의 모달 창이 작아서 긴 글을 적기 불편하셨다면 작성창을 확장해서 써보세요.

3) 메이커로그에 프로덕트 추가하기

특정 프로덕트에 대한 메이커로그를 쓸 경우 관련 프로덕트를 추가할 수 있습니다. 이렇게 작성한 메이커로그는 프로덕트 페이지 내 관련 최신 메이커로그로 뜨게 됩니다.

• 관련 프로덕트는 디스콰이엇 상에서 메이커로 공유한 프로덕트 중에서 선택 가능합니다.
• 관련 프로덕트와 토픽 중 하나만 선택하실 수 있어요.

4) 내 프로필에 만들고 있는 프로덕트 추가하기

현재 만들고 있는 프로덕트를 내 프로필에서 추가해 다른 메이커 분들께 작업 중인 프로덕트에 대해 알릴 수 있습니다.

• 디스콰이엇에서 메이커로 공유한 프로덕트 중 선택 가능합니다.

관련해서 궁금한 점이나 피드백이 있으신 분은 아래 댓글로 남겨주세요!

프로덕트의 객관화

프로덕트를 만들면서 자주 느끼는 것 중 하나가 시간이 지날수록 내 프로덕트를 객관적으로 보기가 점점 어려워진다는 거다. 초반에는 아직 만들어진게 많이 없다 보니 처음 목표한 방향에 맞는 아이디어들을 내서 만들 수 있는데, 프로덕트가 발전할수록 여기저기서 피드백과 기능 요청을 받게 되고 이를 무작정 다 반영하려다 보면 어느 순간 초심을 잃고 애매한 프로덕트를 만들기가 쉬워지는 것 같다. 그래서 프로덕트가 확장 단계에 들어설수록 유저와의 지속적인 대화가 특히 중요해지는걸 느낀다. 유저 분들과 이야기하다 보면 ‘당장 없어서 크리티컬한’ 굵직한 니즈와 ‘있으면 좋지만 없어도 괜찮은’ 자잘한 니즈가 확실히 구분되서 다음 개발 방향을 정하는데 큰 도움이 된다. 그 중엔 우리가 예상한 니즈도 있지만 가끔은 ‘어떻게 이걸 생각 못했지?’ 싶을 정도로 중요한 포인트를 놓치고 있었음을 깨닫기도 한다. 이건 심지어 나 자신이 우리 프로덕트의 타겟 고객이라도 마찬가지다. 아무래도 프로덕트를 직접 만드는 과정에서 너무 깊숙히 관여하기 때문에 나도 모르게 객관성을 잃어버리게 되는게 아닐까 싶다. 위의 이유가 가장 중요하긴 하지만, 유저 분들과 이야기하고 나면 내적 동기가 정말 많이 충전되기도 한다. 우리가 한땀한땀 만든 프로덕트에 지속적인 관심을 갖고 변천사를 지켜봐주시는 분들을 만난다는건 언제나 가슴벅찬 일이다. 그래서 아직 부족한 부분을 하루빨리 채워서 더 나은 프로덕트를 보이고 싶은 마음이 강해지는 것 같다.

창작가로서의 개발자

개발을 배우고 여러 프로덕트들을 만들어보면서 가장 희열을 느꼈던 순간은 머릿속에만 있던 아이디어를 직접 구현해 실제 모습을 두 눈으로 확인할 때였습니다. 특히 처음 1년간은 내가 작성한 코드 몇 줄이 하나의 프로덕트로 재탄생한다는 사실이 마법처럼 느껴졌고, 그 때의 감정을 잊지 못해 그 후로도 사이드프로젝트, 해커톤 등을 하면서 갈증을 채우곤 했습니다.

그런 관점에서 개발이라는 행위가 기술적 지식을 갖고 코딩을 하는 것에만 국한되지 않는다고 생각합니다. 코딩 능력은 아이디어를 구현하는데 필요한 중요 수단이지만, 이를 이용해 원하는 걸 자유롭게 만들어낼 수 있다는 점에서 개발자는 창작가에 가깝게 느껴집니다. 일의 형태를 볼 때도 마치 작가나 작곡가가 어느 순간 영감을 받고 몰입할 때 최상의 결과물을 내듯이, 개발 역시도 단순 작업 시간이 많을 때보다 생산성이 급격히 올라가는 시점에 몰입해서 작업했을 때의 성과가 훨씬 좋습니다. 실제 해외에는 본인의 예술 감각을 개발에 접목시켜 제품을 만드는 creative developer라는 직군이 있기도 하고, 이런 개발자들의 작품들은 제게 많은 영감과 동기부여를 주곤 합니다.

• https://bruno-simon.com
• https://mattdesl.svbtle.com

꼭 만드는 제품 자체가 예술적이지 않더라도, 하나의 프로덕트를 개발하는 과정인 문제 발견 -> 솔루션 탐색 및 개발 -> 피드백을 통한 개선을 반복하다보면 이 중 상당 부분에서 창의성이 요구되는 걸 느낍니다. 보통 이 과정 중에 예상치 못한 난관에 끊임없이 부딪히게 되는데, 그럴 때마다 필요한 지식을 미리 다 예상하고 사전에 습득하는 건 사실상 불가능합니다. 이 때 필요한 건 처음 보는 문제라도 빠르게 파악하고 이에 대한 정보를 찾아서 어떻게 해결할지 대책을 세우는 능력인데, 이를 잘하기 위해선 때로 정말 기발한 접근방법이 필요합니다.

이러한 문제 해결력을 기르는데 필요한 것 중 하나가 다양한 관점을 가지는 것이라고 생각합니다. 일반적으로 다양한 관점을 얻기 위해 하는 것이 새로운 경험을 하거나 여러 분야의 책을 읽는 것인데, 책은 읽으면 되지만 모든 경험을 직접 다 해보긴 어렵기 때문에 다른 사람들의 경험담을 간접적으로라도 듣는게 도움이 됩니다. 이를 제품 개발에 적용해 보면 다른 메이커들의 개발 스토리와 그 과정에서 겪은 문제, 이를 해결하면서 얻은 인사이트에 대해 아는 것이 큰 도움이 되고 실제 많은 메이커 분들이 이를 궁금해하는 것을 보았습니다.

수많은 개발자들이 블로그나 SNS에서 각자의 개발 여정과 해결한 문제들에 대해 기록하고 도움을 주고받는 것처럼, 제품 개발 과정에 대해서도 활발히 기록하고 공유하는 문화가 확산되길 바랍니다. 이를 통해 서로 영감을 받고 창작 활동을 하듯 제품 개발을 즐기는 개발자들이 많아지고, 더 나아가 무언가 만들기 위해 개발을 배우는 사례가 늘어난다면 세상에 더욱 다채로운 프로덕트들이 탄생할 수 있지 않을까 생각해봅니다.