드디어 디자이너를 채용했습니다

이 메이커로그의 후속편쯤 되겠군요. 드디어 gwyng이 디자이너가 있는 회사가 되었습니다.

뭐, 사실 별달리 한건 없고요. 우선 제품을 클로즈드 베타 상태로 출시를 했고요. 그 상태로 포트폴리오 사이트를 돌아다니면 여러 프로필을 훑어봤습니다. 결국 서핏에서 눈에 띄는 이력을 발견하고 링크드인을 통해 콜드 메일을 보냈는데요. 화상으로 이야기를 나눠보니 똑똑하고 수월하게 협업할수 있는 분이란 생각이 들었습니다.

지분을 포함한 형태로 계약을 했고요. 핵심 멤버가 되어 함께 성장할 수 있길 기대하고 있습니다.

제가 이분을 고용할 수 있었던 것은 운도 따랐는데요. 마지막 직장이 얼마전까지 잘 나가다가 갑자기 상황이 안좋아진 기업이었습니다. 이름을 들으시면 다들 아실거에요. 디자이너 분은 입사한지 몇달 되지 않은 상태에서 희망 퇴직의 대열에 합류하셨습니다.

별이 죽으면 그 성분이 다른 행성에 생명이 싹트게 한다잖아요? 스타트업에게는 이런 기회를 잘 잡아야하는건가 싶네요.

그것 외에는, 그래도 완성은 된 제품을 보여드린 점. 그것의 참담한 디자인이 동정심과 도전 의식을 불러 일으킨점? 정도가 성공적인 채용을 이루어낸 요인으로 보이네요.

하나 더. 디자이너 분도 디스콰이엇으로 모셨습니다. 앞으로 관심갖고 지켜봐주세요!

PMC 23 후기

지난 목요일 PMC 라스트 네트워킹에 참석했습니다. 새로운 인연도 맺고 다른 팀의 데모도 감상하고 즐거운 시간이었습니다.

이제 이번주를 마지막으로 PMC가 끝나는데요. 잠깐 되돌아보는 시간을 가지려합니다.

우선 첫번째 만남과 마지막 만남 행사가 마음에 들었습니다. 그사이 메이커스 나잇에도 참여하고 싶었는데 여건이 안되어서 아쉽네요.

또 총 4분의 다른 PMC 참가자와 커피챗을 진행한게 보람찼습니다. 매 커피챗마다 새로운 관점을 들을수 있었습니다. 이 글을 쓰고나서도 또 제안해보려고 해요.

아쉬웠던 점은, 데모를 출시하지 못한 것입니다.

저는 PMC를 절반 정도 진행했을쯤에 클로즈베타를 시작해 나머지 절반동안 피드백을 들을 계획이었습니다. 그런데 출시가 자꾸 늦어지더군요. 미뤄놨던 일들이 끝나질 않아서, 어휴. 그래도 이젠 정말 거의 끝났습니다!

PMC 참가 인터뷰를 할때 한가지 걱정되는 점이 있다고 말씀드렸었는데요. 저처럼 제품 개발 마지막 단계에 있는 사람은 막상 개발만 하고 네트워킹을 활발히 못할거 같다는 점이었습니다.

안타깝게도, 제 예상이 (웬일로) 이번엔 맞아버렸는데요. 사실 매일매일 버그잡는게 일이다보니, 커피챗에서 다른 분들의 좋은 의견을 들어도 반영할 여유도 없었습니다. 그냥 그렇구나, 하고 제 코앞에 닥친 일들을 해결해야했죠.

좀더 여유가 있을때 참여했으면, 또는 프로젝트 초기에 참여했으면 더 좋았을것 같아 아쉽습니다. 다른 메이커분들은 좀더 열린 마음으로 임해서, 팀원도 수월하게 구하는 모습이 부러웠네요.

그래도 네트워킹의 가치를 깨닫게된점은 확실한 이득이라고 생각합니다. PMC가 끝나고도 다른 메이커들과의 교류를 꾸준히 이어나갈 생각입니다. 아마 이것도 디스콰이엇 팀이 의도한 것중 하나가 아닐까싶네요.

아무튼 즐거웠습니다.

개발자가 어떻게 좋은 디자이너를 채용할 수 있을까?

끝까지 읽고 실망하실까봐 미리 말씀드리자면, 그 방법을 알아냈다는 얘기는 아닙니다.

전 뛰어난 개발자를 알아보고 채용하는데에는 어느 정도 자신이 있습니다.

음, 채용은 빼지요. 아직 성사시킨건 없으니까요. 잘 알아보기만 한다고 해둡시다.

특히 저는 이력이나 학벌을 전혀 보지 않고, 짧은 커피챗 한번으로도 뛰어난 개발자를 알아볼 수 있다고 생각합니다.

이력이나 학벌이 상대적으로 좋지 않은 개발자와 대화할 기회가 생기면 오히려 더 설렐 것 같습니다. 시장에서 저평가되어있는 종목을 찾아낼 수 있는 순간이니까요.

그런데 디자이너는 어떻게 채용하죠?

어떤 디자이너가 뛰어난지 작업물을 보고 제가 판단할 수 있을까요?

구인 사이트에서 디자이너의 이력서들을 한번 살펴봤었는데, 저도 모르게 학벌에 눈이 먼저 가더라고요. 포트폴리오는 제 눈엔 모두 모자람없이 훌륭했기 때문입니다. 자기가 잘 모르는 분야일수록 명패가 더 신경쓰이나 봅니다.

차라리 쇼미더머니 심사위원을 하는게 부담이 덜하겠단 생각마저 들었습니다.

그러다 이번주에 함께 PMC에 참여중인 디자이너 출신의 메이커 @오혜수 님과 커피챗을 나누었는데요. 말씀을 나누며 몇가지 감을 잡은게 있습니다.

우선 제가 가진 디자이너에 대한 오해 중 하나가, 풀스택 디자이너는 드물고 구하기가 어렵다는 것이었습니다. 여기서 풀스택이란, 로고, UI/UX, 그리고 기타 발에 채이는 일들까지 모두 다 할 수 있는 디자이너를 말합니다.

하지만 이력서를 봤을땐 그렇게 보이는 사람이 없었습니다. 이 사람은 로고 디자인만 할수 있고, 저사람은 UI/UX 디자인만 해본 걸로 보였죠.

그런데 혜수 님의 말씀이, 사실 하나를 잘하는 사람은 다른 것도 잘할 것이고, 이력서에 하나만 써놓은 것은 다른 걸 아직 본격적으로 해보지 않아서 그렇다는 것이었습니다. 오히려 대부분의 디자이너들이 풀스택 디자이너에서 크게 멀리 떨어져있지 않다고 들렸브니다.

또, 이건 제가 혜수 님의 말씀에서 행간을 읽어본 것인데요, 디자이너도 미리 많은걸 알고 있기보다는 그때 그때 필요한걸 빠르게 익히고 적용하는 능력이 중요하다고 느꼈습니다.

이 얘기를 듣고나니, 사실 개발자 뽑는거랑 크게 다르지 않겠다는 생각이 들고 자신감이 생겼습니다.

그후에 전 노트폴리오에 가입해서 UI/UX(일단 당장 하게될 일은 이거니까요) 디자이너들의 포트폴리오를 살피기 시작했습니다.

역시, 다 똑같이 잘 한것으로 보였습니다.

하지만, 디자이너들끼리의 평가가 있었는데요. 그걸로 작업물을 정렬하는 기능이 있더라고요. 재밌게도, 지금 제일 위에 올라와있는 건 비전공자의 작업물이더라고요. 이런점이 오히려 저에게 이 목록에 대한 신뢰를 주었습니다.

지금 제 전략은, 디자이너 사이에서 평가가 좋은 작업물을 만든 디자이너들에게 커피챗을 제안하는 것입니다. 작업물 각각에 대한 제 자신의 호오는 평가에 반영하지 않으려합니다.

대신에 성사된 커피챗에서, 제가 좋은 개발자를 알아볼 때 쓰는 질문을 그대로 쓰려고 합니다. 의사소통이 잘 되고, 차근차근 생각하는 능력이 있는 사람인지 알아볼 수 있는 질문들이요.

말은 자신만만하게 했는데, 사실 커피챗 성사부터 쉽지 않아보이긴 합니다. 그래도 열심히 두드려보고 재미있는 결과가 있으면 또 공유하겠습니다.

이번주에 한 것들

원래 이번주에 배운걸 쓰면 더 좋겠지만요. 아마 분명 뭘 배우긴 배웠을겁니다.

하지만 거기에 대해 메타인지가 안되네요 그래서 뭘 했는지를 정리해보겠습니다.

VC와 커피챗

지인을 통해 얻은 기회입니다. VC와 커피챗 해보는건 이번이 4번째인데요.

느낀점은, 저는 투자자를 설득할 준비가 별로 되어있지 않다는 것입니다.

사실 좀 황당하게 들릴수 있겠지만, 저는 제가 만들고 있는 제품이 반드신 성공한다는 확신이 없습니다.

그런데 왜 하냐고 묻는다면, 제가 쏟아야하는 노력과 시간을 고려해 기댓값을 생각했을때 할만하기 때문입니다.

생각해보면 이건 오직 자기 자신만 설득할 수 있는 이야기죠. VC를 설득하려면 저기서 '제가 쏟아야하느 노력과 시간'을 VC의 돈으로 바꿔서도 성립해야겠죠.

그런데 그때의 기댓값은 별로 생각해본적이 없습니다. 그래서 설득하는 것도 마냥 피하고 싶고 피곤한 일이기만 할뿐이네요.

아무튼 그래서, 일단은 제품 완성에 좀더 집중하자는 지극히 당연한 결론에 이르렀습니다.

그래도 연결해주신 지인분을 봐서인지 심사역까지 연결을 해주신다고 하니, 소득이 없었던건 아닙니다.

콜드 메일을 통해 접촉한 개발자와 채용을 염두에 둔 커피챗

인터넷에서 본 이력서를 통해 개발자분께 콜드 메일을 보냈습니다. 제가 원하는 해커 스타일의 개발자라는 느낌이 강하게 왔습니다.

대화를 하며 좀 의외었던 부분은, 그 개발자분이 제 제품이 성공할 가능성에 대해선 별로 의심을 품지 않는다는 점이었습니다.

저는 대화를 시작하기전에, 대부분의 사람이 제 제품에 의심을 품고있겠지만, 혹시 그게 아니라면 대화가 순조롭게 흘러갈 것이고, 그때는 채용 이야기를 본격적으로 시작하는데 무리가 없으리라 생각했었습니다.

그런데 그 개발자분은 제품은 잘 될거라고 생각하는 와중에(어느 정도 립서비스가 포함되었겠지만), 근무 환경이 좋을지에 대해 고민하시는 것 같았습니다. 저는 이런 경우엔 어떻게 이야기를 진행할지 준비가 전혀 되어있지 않더라고요.

대화를 나눌 상대방의 성향에 대해 좀더 고민해보고, 그에 맞는 대화를 준비해야겠다는 생각을 했습니다.

F-Lab 온보딩

온보딩을 F-Lab의 대표님이 진행하시더라고요. 덕분에 사업적으로도 여쭤볼 기회가 있었습니다.

대표님이 F-Lab이 해결하려는 개발자들의 성장할 기회를 잃어버리는 문제에 진심이라는게 느껴졌습니다.

처음에 F-Lab이 제공하는 가격이 다소 비싸다고 생각했는데요. 설명을 듣고나니, 단순히 더많은 수익을 내기 위한 설정이 아니라, 실제로 성장에 도움이 되는 서비스를 구성하고 거기에 맞춘 비용이라는 생각이 들었습니다.

이제 다다음주 부터, 매니징도 배우면서 부수입도 챙겨보려합니다.

아, 쓰고보니 배운게 하나 떠올랐습니다. 사람 만나는 것과 개발 사이에 컨텍스트 스위칭 비용이 상당하다는 겁니다. 프론트엔드 개발과 백엔드 개발 사이의 비용보다 훨씬 더요.

그래서 개발에 시간을 별로 못 쏟았네요. 이부분도 장기적으로 개선을 해야겠습니다.

F-Lab에서 개발자 멘토링을 시작했어요

이번주 월요일에 F-Lab에 합격했습니다. 개발자 멘토링 매칭 서비스인데요. 기본적으로 F-Lab에서 자체 커리큘럼을 활용해 수강생들을 가르치고, 파트타임으로 일하는 멘토들이 배운 내용에 대해 질의응답을 해주고 학습 방향을 잡아주면 됩니다.

그래서 이걸 왜 하느냐. 투자를 못하고 늘어지다 보니 수입이 필요해졌습니다. 그렇다고 제품 완성을 위해 막판 스퍼트를 해야하는 시점에서 취직이나 외주를 하는건 얼토당토않은 선택지였죠. 그런 저에게 F-Lab에서 제시하는 조건은 굉장히 매력적이었습니다. 파트타임이면서 수입도 쏠쏠한게, 실제로 해보면 상상한거랑 똑같진 않겠지만, 일단은 큰 기대를 갖게 하더군요. 또한 단순히 돈 버는 것 이상으로도 제 성장에 도움을 줄 수 있다고 보았습니다.

저는 멘토링을 하면서 제 자신도 사람을 가르치는 방법에 대해 배우려고합니다. 지난 메이커로그에서 '난 팀원을 왜 못구하고 있을까'에 대한 고민을 공유했는데요. 쓰다보니 제가 주니어 개발자를 채용하는걸 매우 두려워 한다는걸 깨달았습니다. 뭐랄까, 갑자기 아이를(?) 입양하는 상황처럼 느껴져요. 저는 개발자들의 성장 곡선이 어떤지, 잠재력을 어떻게 엿볼수 있는지를 잘 모릅니다. F-Lab에서 멘토링을 하면서, 멘티들은 개발자로서, 저는 일종의 매니저로서 성장할 기회를 얻기를 기대합니다. 특히, 제한된 방식으로나마 제가 가르치고 그 결과를 볼 수 있다는 점이 마음에 듭니다. 제가 구잉에 영입해서 성장시킬 주니어 개발자들의 모습을 추측할 수 있는 좋은 모델로 볼 수 있죠.

다시 읽어보니, 마치 F-Lab의 멘티들을 실험대상으로 쓰겠다는 것 같은데요. 저는 제가 생각하는 좋은 방식으로 최선을 다해 멘토링할 생각입니다. 그 과정에서 흥미로운 결과를 보게 된다면 이후에 다른 메이커로그에서 공유할게요.

그리고, F-Lab에서 멘티들을 채용하거나 다른 회사로 추천하는 것도 가능합니다. F-Lab을 통해서 하기만 하면 말이죠. 흠, 김칫국을 좀더 마실수도 있겠지만 오늘은 참겠습니다. 그리고 모각코 등의 이벤트도 진행하는데, 여기서 멘토로 활동하는 뛰어난 개발자들과의 네트워킹도 기대해볼만 하겠습니다. 일단 이번주 모각코부터 나가보려구요.

혼자서 만든 제품을 출시하기를 앞두고

제가 근 1년간 만든 혼자서 카메라앱 '슈티'가 클로즈베타를 앞두고 있습니다.

사실 처음부터 혼자 만들려고한 건 아니었구요. 한달 정도 걸려 PoC를 완성한 이후부터는 늘 함께할 동료를 찾아다녔음에도 결국 한 명도 구하지 못했습니다.

동료를 구하는데 노력하는 동시에, 혼자서 또는 소규모로도 제품을 완성할 수 있는 스택을 구성하는데 신경을 많이 썼구요.

전자는 실패했지만, 다행히 후자에 관련해서는 괜찮은 판단을 해낸것인지 어찌저찌 완성은 하게되었습니다. 후자에 대한 나름의 성공에 대해선 여기 정리해놓았습니다. 이 메이커로그는 전자의 실패에 대한 회고입니다.

직장 다니던 시절

저는 '슈티'를 처음 개발해야겠다고 생각했을 시점에 직장에 다니고 있었습니다. 일반적으로 같은 회사의 동료를 꼬시는걸 생각해볼만 하죠. 그런데 그전에 코로나로 인해 거의 100% 재택을 해왔기 때문에, 깊은 친분이 있는 동료가 거의 없었습니다. 퇴사할때 되서 출근을 좀 하니까 친해지더라고요. 다만 이것도 좀 핑계일 수 있는 것이, 제가 그때 동료로 삼고 싶은 스타일의 개발자가 팀에 없다고 생각하고 있기도 했습니다. 대기업인만큼 다들 충분한 개발실력을 갖추고 계셨지만, 제가 원하는 해커 스타일의 개발자는 아니었습니다. 저는 '슈티'의 개발엔 해킹이 필요할 거라 생각했습니다. 여기저기서 튀어나오는 문제를 임기응변으로 해쳐나가는 방식의 개발이요.

퇴근후에 '슈티'를 개발하다가 잠드는 일상을 한달 정도 반복하고나서 드디어 데모라 할만한 물건이 나왔습니다. 그리고는 제가 친하게 지내던 해커 B한테 보여줬죠. 그런데 B는 그 아이디어를 아주 별로라고 생각했습니다. 저를 걱정하며 퇴사를 재고해보는게 어떻겠냐는 말까지 했죠. B가 건너건너 아는 해커들한테 얘기해볼 기회를 받기도 어렵겠다 싶었습니다. B는 대기업에 재직중이었고, B가 아는 해커들 중에서도 지금 놀고 있는 사람은 없다고 했습니다. 이후에도 종종 물어봤지만 같은 대답을 들었습니다.

퇴사를 무를 순 없었고, 일단은 1인 개발 체제를 유지하는 수밖에 없었죠.

퇴사 후

전 직장에서 제 부사수였던 친구 A를 투입해보기도 했습니다. A는 그때 취업준비중이었고요. 저는 '슈티'가 주니어 수준인 A를 성장시키기에 좋은 곳은 아니라고 생각했습니다. 일단 저도 직장에서 매니징 경험이 일천해서, 사람을 어떻게 굴리는지에 대한 감이 전혀 없었습니다. 지금도 그렇고요. 그리고 코파운더로 하기에는 A는 아직 성장이 많이 필요하다고 생각했습니다. 그래서 지분 1%를 주고 A를 파트타임으로 고용했습니다.

여기서 문제는 저는 이미 퇴사하고 풀타임으로 일을 하고 있다는 점이었습니다. A는 취업준비중이라곤 하나, 남는 시간이 많지 않고 면접 준비, 이력서 쓰기 등 바쁜 상태였습니다. 그리고 도중에 취직에 성공하기도 했습니다. A가 파트타임에 해놓은 작은 일들이 제가 보기엔 성에 차지 않았던 것입니다. 오히려 코드 리뷰에 시간이 쓰이는게 아쉬웠습니다. 제가 일을 10만큼 해놓고나서 돌아보면 1도 되어있지 않아있었습니다.

제가 매니징 능력이 있었다면 상황이 더 나았을텐데 아쉽습니다. 뭐 1%받았는데 1/10를 바라는 것도 염치가 없죠. A의 수고를 꾸준히 누적해서 출시 시점에 충분한 공헌이 쌓여있기만 하면 되는 겁니다. 그런데 저는 일이 더 빨리 진행된다는 느낌이 들지 않는게 너무 답답했습니다. A에게도 같은 이야기를 했고 없던일로 하기로 했습니다. 그렇게 다시 혼자가 되었습니다.

기대를 그만두고 혼자 개발하던 시절

일단 팀원 구하는 걸 포기하고, 혼자서 제품을 잘 만들어서 그걸로 꼬셔보겠다고 마음을 굳혔습니다. 뭐 의도한건 아니지만, 그냥 하던대로 하겠다는 셈이 됐죠. 그런데 이게 정신건강에 정말 안 좋습니다. React Native로 개발하긴 하지만, iOS / Android 네이티브 코드를 볼일이 종종 있는데다가, 두 플랫폼에서 동작이 다른 일도 부지기수였습니다. 또 서버도 제가 하고 인프라도 제가 했죠. 이게 사실 따로따로는 충분히 할수 있는 일입니다. 그런데 한번에 다하려니 컨텍스트 스위칭의 부하가 너무 컸습니다.

이런 식이죠. 앱 빌드를 돌려놓고 그 사이 서버 버그를 고칩니다. 서버 버그를 고치고 배포를 해놓은 다음 습관적으로 깃헙 이슈트래커를 확인합니다. 혹시 제가 올린 버그리포트가 해결되었는지요. 그리고 다시 돌아와 앱 빌드 오류를 확인합니다. 그걸 또 구글에 검색합니다.

정신이 나갈거 같았지만, 대안이 있나요. 아, 지원사업에 낼 서류도 써야죠. 지원사업이 되었다면 그걸로 고용을 해서 좀 사정이 나았을텐데 다 떨어졌습니다. 쨋든, 중간에 ADHD 약도 먹기시작하고 나름의 컨디션 관리법도 깨우치면서 결국 반년정도를 버틸수 있었습니다.

클로즈 베타를 앞두고

그래서, 드디어 곧 클로즈베타를 시작할 수 있을것 같습니다. 그리고 이제는 진짜 동료를 구해야겠단 생각이 듭니다. 지금 '슈티'의 코드는 사상누각입니다. 더 이상 스케일이 불가능해요. 트래픽이 생김에 따라 서버 자원도 스케일해야하는데, 이것도 제가 경험이 부족한 부분입니다.

처음으로 인터넷에서 이력서를 보고 콜드 메일도 보냈습니다. 다음주엔 투자사에서 일하는 분과 커피챗을 할 기회를 얻었습니다. 원래 계획은 클로즈베타를 통해 투자를 받고, 동료를 구하는 거였는데요. 만약 지금의 완성도가 그러기에 부족한거면 어떡하죠?

혼자서 오래 일하다보니 지분으로 영입하는 것에도 문제가 생겼습니다. 처음부터 코파운더로 시작한거면 몰라, 지금 몇10%씩 덜컥덜컥 줄수가 없습니다. 그런데 작은 지분에 상응하는 큰 연봉을 줄 방법도 당장은 마땅치 않지요. 투자를 받으면 모를까. 저는 클로즈베타에서 슈티가 충분한 매력을 보여줄 수 있기를 바랄 뿐입니다.

그래서?

잘 모르겠네요. 일단 동료가 있었으면 좋겠습니다. 그런데 구하기 힘들기도 했습니다. 제가 나름의 변명을 군데군데 달아놨는데, 제가 좋지못한 판단을 한 부분이 보이시면 댓글로 알려주세요. 제게 귀중한 피드백이 될겁니다. 동료가 없는 상태로 여기까지 온건, 그것 자체는 그나마 다행인데, 거기까지입니다. 코드는 그걸 읽을 줄 아는 사람이 없으면 소용이 없지요. 저는 어떻게보면, 코드를 '덜' 짜온겁니다. 저만 볼수있으니까요. 제품 개발이 팀 빌딩과 함께 이루어졌으면 훨씬 좋았을거란 생각이 듭니다. 구체적인 과정은 여전히 깨닫지 못하고 있지만요.

소셜 미디어의 수렴 진화

이하 내용은 PMC에서 만난 @백민기 님과 커피챗을 진행하며 떠오른 생각들을 정리한 것입니다. 좋은 아이디어 공유해주셔서 감사합니다!

'소셜 미디어'란 단어를 처음 나온지도 어느덧 10년이 훌쩍 지났습니다. 페이스북은 내년이면 20주년을 맞습니다. 세월이 무상하군요.

이쯤에서 지금까지 살아남은 소셜 미디어들이 처음에 어떤 컨셉을 지향하고 출범했는지를 한번 돌아볼까요?

• 유튜브
  그냥(좋은 의미로) 동영상 공유 서비스.

• 인스타그램

  폴라로이드 사진의 감성을 디지털로 옮겨놓은 서비스.

• 틱톡
  음악에 맞춰 춤을 추거나 챌린지를 하는 짧은 동영상을 공유하는 서비스.

• 스냅챗
  시간이 지나면 사라지는 사진을 공유하는 서비스.

• 트위터
  140자 제한으로 부담없이 중얼거릴 수 있는 서비스.

이렇게 가지각색의 컨셉을 갖고 출발한 서비스들은 각자의 영토에서 새로운 가능성을 발견하고 문제점을 해결하며 성장해왔습니다.

그런데 약 5년 전부터 시작된 숏폼 비디오의 유행은 새로운 기류를 일으키고 있는데요. 틱톡이 열어 젖힌 이 새로운 영역은 많은 기성 서비스들을 유혹했습니다. 결국 2023년 현재 상기한 모든 서비스들이 각기 다른 이름으로 숏폼 비디오 + 무한 스와이프를 지원하고 있습니다.

아시겠지만, 어떤 서비스건 그 기능은 다들 비슷하게 생겼습니다. 언뜻보면 구분도 안될 정도에요.

수직 스와이프로 다음 동영상으로 넘기는 조작도 똑같구요. 뭐, 그건 그렇다 칩시다. 좋은 UI/UX를 서비스들끼리 서로 가져다쓰는게 사용자 입장에서 나쁠린 없으니까요.

흥미로운건 저 숏폼 비디오의 내용마저 서비스를 가리지않고 거의 유사하다는 점입니다.

• 밈 / 유머

• 춤 / 노래

• 토막 상식 및 가벼운 정보

• 인기있는 영화나 드라마의 클라이막스

이건 아마 30초 내외의 짧은 동영상이라는 형식이, 그 내용의 범위를 강하게 제약하기 때문일 것입니다. 또한 틱톡에서 시작된 배경음악을 필수적으로 넣는 유행도 이런 현상에 일조했을거라 짐작합니다. 음악은 우리가 전혀 맥락이 없는 동영상에도 순식간에 집중하게 하는데 대체불가능한 효과가 있습니다. 이렇게 또 '음악이 들어간' 짧은 동영상으로 좀더 범위가 좁혀집니다.

결국 저 개성적인 소셜 미디어들이, 유튜브의 '쇼츠'에 해당하는 탭을 여는 순간 몰개성한 서비스가 되고맙니다. 동시에 (트위터 정도를 제외하면) 그게 해당 서비스에서 가장 인기있는 기능이기도 합니다. 이게 뭘 의미하는걸까요?

약간의 무모함을 무릅쓰고 단순명쾌한 결론을 한번 내려보겠습니다. 소셜 미디어는 광고 수익으로 먹고 살고, 광고 수익을 늘리기 위해선 사용자의 사용 시간을 늘려야합니다. 그리고 '쇼츠' 류의 UX는 그걸 극대화하는 하는데 드디어 끝장을 봤다구요. 사실 전 이보다 더 시간을 쉽게 뺐을 수 있는 방법이 상상이 가지 않습니다. 물론 제 상상력의 한계일 수도 있겠지만, 여러 서비스들이 '수렴 진화'했다는 사실이 시사하는 바가 있습니다. 어쩌다 유튜브 쇼츠를 켜서 보고 있으면, 하루종일 이러고 있는 것도 가능하겠단 생각이 듭니다. 이전에 다른 서비스에선 그런 생각을 해보지 못햇어요.

그래서 뭘 해야할까요? 지금 소셜 미디어를 개발하고 있는 메이커들은 이 숏폼 비디오란 녀석을 어떻게 바라보아야 할까요?

나름의 결론을 몇번 썼다 지웠습니다. 자명하지 않은 제 스스로 만족할만한 결론을 내리는게 어렵내요. 그래서, 섣불리 대답하기보다는 일단을 질문을 던지는 것에서 시작해보기로 마음을 바꿨습니다.

• 숏폼 비디오가 표현할 수 있는 내용의 영토는 이미 다 개척된걸까요? 제가 느끼기로, 지난 1년간은 밈과 음악만 바뀌었을뿐 사실상 같은 형식의 동영상들이었던것 같습니다. 혹시 헤비 유저들에겐 다르게 보일지가 궁금합니다.

• 비리얼(BeReal)은 무한 스와이프의 시대에 작정하고 반대로 가고 있는 서비스입니다. 무한해지면서 그만큼 무가치해진 컨텐츠에게 다시 가치를 부여하는 방법으로, 컨텐츠를 일부러 유한하게 만들었습니다. 이게 지속가능한 해결책일까요? 틱톡과 달리 비리얼 피드를 하루종일 볼수는 없을 것 같습니다. 대신 비리얼 입장에선 몇시간이고 볼수 있는 피드를 제공해야하는 부담을 내려놓을수 있는건 좋겠군요.

• 10년 전쯤에 누군가 '나는 인스타그램이 좋아'라고 한다면 거기서 어떤 정보를 읽을 수 있었습니다. 지금 누군가가 '나는 틱톡이 좋아'라고 한다면, 그게 무얼 의미하는걸까요?

• 아무리 스와이프해도 계속 재밌는 피드는 더 개선할게 없는 완벽한 개념인 걸까요? 그냥 활자로 읽었을땐 '절대 부서지지 않는 방패'같은 느낌이네요. 그냥 '더' 재밌는 피드를 제공하는 알고리즘을 개발하는게 경쟁의 유일한 방법일까요?

PlayTorch: 모바일 기기에서 AI를?

AI는 가늠하기 어려울 만큼 거대한 잠재력을 지닌 기술이지만, 인디 개발자가 손대기는 다소 껄끄러운 것도 사실입니다.

우선, 혼자서 제품을 뚝딱 만들수 있는 소위 풀스택 개발자의 스택에도 AI는 빠져 있는 경우가 많구요(저도 그렇습니다). 서비스에 AI를 적용하면 운영비가 급격히 늘어나는데, 이또한 큰 부담이 될 수 있습니다.

만약 AI에 대한 깊은 지식없이도 적용할 수 있는 방법이 있다면 어떨까요? 또한 서버가 아닌 모바일 기기에서 직접 추론하게 만든다면, 그 비싼 AI 추론 비용이 아예 0이 되어버립니다.

오늘 소개드릴 PlayTorch는 모바일 기기에서 AI를 적용할 수 있도록 도와줍니다. 페이스북에서 개발했으며, 역시 페이스북에서 만든 React Native용 라이브러리입니다.

튜토리얼엔 이미지 분류, 번역, 스타일 변환(사진을 만화로 바꿔줍니다), 오브젝트 감지 등의 예제가 있습다. 또한, 임의의 PyTorch ScriptModule을 실행시킬 수 있는 기능도 (당연히) 제공합니다. 특히, AI 추론을 할때 데이터를 전처리하는 과정이 필요한데, 이 과정을 PlayTorch에서 제공하는 기능으로 간단히 처리할 수 있습니다.

저는 PlayTorch의 예제들을 보며 모바일 기기의 GPU 성능으로도 생각보다 멋진 기능들을 만들수 있다는 점에 놀랐습니다. 이 글을 보고 계신 분 중에서도 그동안 모바일 기기의 성능을 저처럼 과소평가하셨던 분들이 계실 것 같습니다.

물론 ChatGPT나 Stable Diffusion 등의 거대한 모델과 비교하면 굉장히 작고 귀여운 수준이지만, 이런 모델들도 사용자의 기기에서 바로 돌릴수 있게 되면 새로운 가능성을 열어줄 수 있습니다. 아이디어로 승부하는 인디 개발자에겐 특히 매력적인 기술이라고 생각합니다.

비슷한 목적의 라이브러리로 구글에서 만든 ML Kit도 한번 살펴보시길 바랍니다.

React Native 라이브러리인 PlayTorch에 비해, 네이티브 코드 두벌을 직접 작성해줘야해서 사용성은 떨어집니다. 또한 Crop, Rotate, Normalize 등의 기능이 없어서 직접 구현해야 하는 애로사항이 있습니다(제가 해봤는데 만만치 않습니다).

대신 Tensorflow Lite 모델을 돌릴수 있다는 것은 장점입니다. 아무래도 지금까지 좀더 많이 보급된 모바일 AI 플랫폼이기 때문에 모델을 구하는 것도 좀더 쉽습니다.

원맨 밴드 개발 백엔드 스택 공유해요

현재 개발중인 사진공유 앱 '슈티'의 백엔드 스택을 공유합니다.

간단히 요약 하면, GraphQL + Prisma + Node.js(TypeScript + Fastify + Mercurius) + Pulumi 인데요.

...간단했나요? 이것저것 많지만 마라탕 토핑 넣듯이 만든 조합은 아닙니다. 각각의 선택이 긴밀히 연결되어 있거든요.

혼자서 다 해먹을수 있도록 하는것에 초점을 맞추어 구성했습니다. 이제 막 제품 개발을 시작하려는 메이커분들께 도움이 되었으면 좋겠습니다.

지금부터 하나씩 설명드릴게요.

GraphQL

원맨밴드 개발을 한다는건, 프론트엔드도 제가 해야한다는 뜻이겠죠?

그런데 프론트엔드 개발자 입장에서는 GraphQL 만한게 없습니다. REST는 비교하기도 민망할 정도고, trpc 등도 부분적으로 나은 점이 있을지 몰라도, GraphQL + Relay의 조합만큼 데이터 페칭을 우아하게 다루진 못하는걸로 압니다.

'슈티'의 프론트엔드는 React Native로 개발되고 있기 때문에, GraphQL 클라이언트로 Relay를 사용할 수 있었습니다

사실 GraphQL을 아주 자-알 쓰지 못하더라도요, GraphQL 생태계의 좋은 툴들이 스키마 관리를 즐거운 일로 만들어 주는 것만으로도 충분한 가치가 있습니다.

Prisma

GraphQL을 쓰기로 결정한 순간, 나머지 스택들의 선택지가 크게 좁혀집니다.

일단 GraphQL 서버를 잘 만들기가 쉽지가 않아요. 백엔드 개발자들이 괜히 투덜대는게 아닙니다.

프로토타이핑 단계에선 Hasura가 눈에 들어왔습니다. Hasura는 RDBMS 스키마로부터 GraphQL 서버를 공짜로 만들어주는 SaaS 서비스입니다. PostgreSQL 서버를 띄우고 클릭 몇번만 하면 GraphQL API 서버가 생성됩니다.

하지만 이런류의 솔루션이 늘 그렇듯, 솔루션이 제공하는 기능을 벗어나면 문제가 발생합니다.

가령 이미지가 포함된 포스트 업로드를 구현할때, 이미지 업로드를 수행하는 서버를 별도로 만들고 Hasura 서버와 연동해야 합니다. 일종의 MSA가 강제되는 셈인데, 제가 당장 MSA를 잘해낼 자신이 없어서 다른 선택지를 찾게 되었습니다.

그래도 Hasura는 여전히 고려해볼만한 솔루션이니, 한번 살펴보시는걸 추천드립니다.

Prisma는 일종의 ORM인데요. 전통적인 ORM과 달리 n+1 문제에 대한 해결책인 Data Loader를 내장하고 있습니다.

이 Data Loader가 Prisma로 효율적인 GraphQL 서버를 개발하는것을 가능케합니다. 반대로 말해서, Data Loader가 없는 ORM을 사용해 GraphQL 서버를 개발하는 것은 매우 험난한 일이 됩니다.

RDBMS 데이터베이스를 소스로 하는 GraphQL 서버 개발에서 Prisma는 사실상 유일한 선택지라고 생각합니다.

Node.js

여기서 또 Prisma가 어떤 언어를 써야할지에 대한 고민을 고맙게도(?) 크게 줄여줍니다.

Prisma 클라이언트가 지원하는 런타임이 현재 Node.js와 Go 밖에 없거든요.

바로 전직장까지 쓰던 손에 익은 TypeScript를 쓰기 위해 Node.js를 선택했습니다. 제가 Go를 잘 모르긴하지만 사실 무슨 언어를 쓰는지는 크게 상관은 없을 것으로 예상하는데요, 이유는 바로 밑에서 설명드리겠습니다.

Node.js엔 Express, Koa, NestJS, Fastify 등 다양한 웹 프레임워크가 있습니다.

저는 이중에 Fastify를 골랐습니다. 거기에 Fastify의 GraphQL 플러그인 Mercurius를 얹었죠.

그런데, 사실 뭘 고르건 개발엔 큰 상관이 없습니다! GraphQL 서버에선 웹 프레임워크의 역할이 크게 줄어들거든요.

보통 GraphQL 스키마를 바탕으로 코드를 생성하고, 거기에 빈칸를 채워넣는 식으로 개발을 진행합니다. 그런데 그 빈칸이 웹 프레임워크와 무관하게 똑같이 생겼습니다. 그래서 무슨 프레임워크를 고르건 짜게되는 코드는 대동소이할겁니다.

제가 Fastify + Mercurius를 고른건 취향의 문제에 가깝고요. 백엔드 개발 경험이 짧은 분께는 오히려 자료가 많은 NestJS를 추천합니다.

Pulumi

Pulumi는 Terraform, CDK와 같은 IaC 프로비저닝 툴입니다. 직접 EC2 인스턴스를 올렸다 내렸다 하지 않고, 필요한 자원을 코드로 기술하는 것만으로 인프라를 관리할 수 있습니다.

즉 현재 인프라에 어떤 변경을 가할 것인가의 문제에서 인프라가 어떤 상태가 되어야 하는가의 문제로 바뀌는 것이죠. 그럼 이제 어떤 변경을 가할지는 Pulumi 등의 툴이 알아서 계산하고 적용해줍니다.

처음에 배워야할게 좀 있긴 하지만, 작은 규모의 서비스라도 IaC를 구성해놓고 개발하는게 시간 낭비를 크게 줄여준다고 생각합니다

이 중 Terraform은 HCL이라는 설정 언어로 요구사항을 기술하는데 반해, Pulumi와 CDK는 TypeScript, Python 등의 프로그래밍 언어를 사용해서 같은 일을 합니다.

이는 Pulumi나 CDK를 쓸 경우엔 인프라 배포 단계에 다른 액션들을 자유롭게 넣을 수 있단걸 의미하는데요.

저는 CI/CD 파이프라인을 따로 작성하지 않고, 그냥 Pulumi 스크립트에서 Docker 이미지 빌드까지 포함시켰습니다. 그래서 배포는 pulumi up 이라는 CLI 명령어 하나로 끝납니다.

얼핏 무식한 방법처럼 보이지만, 캐시를 이용해 빌드를 효율적으로 수행하게만 한다면(아직 여기까진 안 했습니다) 오히려 기존 방법보다도 낫다고 생각합니다.

RedwoodJS

지금까지 말씀드린게 사실 RedwoodJS와 크게 다르지 않습니다.

RedwoodJS는 GitHub의 공동창업자 중 한명인 Tom Preston-Werner가 공개한 NestJS, Prisma, React로 구성된 풀스택 프레임워크인데요.

스타트업들이 최대한 고민없이 빠르게 개발을 시작할 수 있도록 설계되었습니다.

RedwoodJS로 서비스를 개발하면 투자 유치의 기회가 생긴다는 것도 매력적입니다.

어쩌다보니 RedwoodJS 광고가 되었는데요.

RedwoodJS를 선택하게 될 경우에도, 스택을 이루는 요소들이 어떤 목적으로 선택되었는지에 대해 이해하는데 이 메이커로그가 도움이 될것이라 생각합니다.