안녕하세요! 지난 번에 audience building 에 대해 얘기했었는데, 관련해서 재밌는 트윗이 하나 올라와 소개할게요.
https://twitter.com/levelsio/status/1505075350790828033
아주 대강 의역하자면 자기 프로덕트 소개하는 진부한 한줄짜리 트윗이나 스레드는 너무나 넘쳐 흐르니, 그냥 매일 매일 그 날 뭐 했는지 트윗하는 게 훨씬 흥미롭다는 내용인데, 사실 꾸준히 그렇게 쓰는 게 쉽진 않죠. 이건 저도 계속 고민하는 부분인데 어떻게들 잘 해내시는지 이야기를 좀 수집하게 되면 따로 다뤄볼게요.
오늘의 주제는 “코딩 덜 하기”입니다. 사이드 프로젝트는 태생이 사이드에요. 우리 본업이 아니죠. 시간을 충분히 넣을 수 없어요. 칼퇴를 하더라도 저녁 먹고 숨 고르고 나면, 넷플릭스나 보거나 아니면 쉬고 싶지 열심히 사이드 프로젝트 하기 어려워요. 설령 열정에 가득차고 너무 너무 하고 싶은 프로젝트가 있더라도, 원하는 만큼 시간 쏟기가 어려워요. 그나마 한 두시간 만들어내서 ‘오늘은 진도를 좀 빼보겠다’ 싶어도, 막상 아주 자잘한 부분에서 시간 낭비하다가 원래 하려던 기능은 개발 못한 채 또 지나가죠.
기능과 결과물을 잠깐 제쳐두고, 배포와 런칭을 목표로 삼는다면, 우리가 할 수 있는 건 뭘까요?
- 범위 (scope) 작게 잡기
정말 최소한의 기능만 넣어봐요. 모든 기능을 다 넣어야 할 필욘 없어요. 트위터에 트윗 수정하는 기능이 없죠. 기술이 없어 안만든 게 아니에요. 무슨 이유인진 모르지만 여튼 그들은 만들지 않았어요. 근데 재밌는 건, 무언가를 안만듦으로써 캐릭터가 생길 수 있어요. 좀더 프로덕트와 그 유저를 이해하기 전에 급하게 필요할 것 같아 보이는 기능을 마구 넣다보면, 사용하기 어려운 거대한 괴물이 될 수도 있어요. 당연해보이는 기능이더라도, 정말 필요한 순간이 올때까지 기다려보는 것도 좋은 것 같아요.
- 성능과 확장성 고려하지 않기
거지같은 코드, 절대로 해서는 안되는 것들, 사이드 프로젝트니까 해보세요. 성능과 확장성보다는 당장 내놓아서 한 명이라도 더 써보게 하는 게 좋아요. 어짜피 유저가 나 혼자일거라면 그 성능과 확장성이 무슨 소용이겠어요. 생각보다 아주 더 늦게 고민해도 늦지 않아요. 그리고 실제 업무에서도 늘 나오는 얘기지만 premature optimization(너무 이른 최적화)은 머지 않아 우릴 괴롭힐 거에요.
- 직접 코딩하는 대신 다른 것 가져다 붙이기
핵심 비즈니스 로직만 개발하고 최대한 다른 오픈 소스나 SaaS(Software as a service)를 활용해봐요. 범위도 작게 잡고, 성능, 확장성도 일단 제쳐놓기로 했으니 좀 더 독특한 접근도 가능하겠죠? 예를 들어 url shortener 를 만들려고 해요. 짧은 주소와 긴 주소를 맵핑하려면 데이터베이스가 필요하겠죠? 이게 회사 프로젝트였으면 Relational Database 로 갈지 key-value 형태의 NoSQL 로 갈지 뭐 이런 고민을 하겠죠? 하지만 아예 틀을 벗어나보자구요. AirTable 어떤가요. 아니면 Google Sheet 를 쓰고 그 위에 Sheety 같은 서비스를 써서 API 로 만들어 버리면 어떨까요? Free tier 만으로도 한동안은 할 수 있는 게 꽤 되거든요. 이 정도 버전을 일단 첫번째 버전이라 부르죠. 그러면 이제 캐싱 같은 것도 고려해보면서 성능도 올리고, 저런 서비스들의 Free tier 에 제공되는 API rate limit 도 피할 수 있겠죠. 어찌 보면 정말 quick & dirty 하게 가지 않으면, 사이드 프로젝트 하려고 잠깐 잠깐 시간 보낼 때 마다 생각보다 진전이 없고 만족감이 떨어져요. 작업의 사이즈를 아주 작게, 회사 업무에 비해서 훨씬 작게 가져가야만 뭔가를 체크리스트에서 지워나갈 수 있고, 만족감에 더 지속이 가능해져요.
이렇게 좀 의외의 것들을 활용하다보면 많은 작업들을 스킵할 수 있어요. 대표적인 예가, GitHub issue 를 CMS(Content Management System) 삼아 블로그를 만드는 일인데요. GitHub issue 는 issue 라는 모델에 대한 CRUD (create, read, update, delete) 가 다 웹 + API 상에 구현이 되어 있고, 에디터도 좋고 이미지 업로드 기능도 다 되어 있죠. 게다가 댓글이라는 개념도 다 있구요. 그래서 이를 backend 로 활용하는 블로그들이 꽤 많고, 그걸 도와주는 오픈소스 프로젝트도 다양하죠. 그 중에 요즘 꽤 괜찮다고 생각하는 최신 프로젝트를 하나만 소개 해드리자면 Shawn Wang (swyx) 의 swyxkit 이에요.
SvelteKit + Tailwind + Netlify 조합으로 만들어져있는데, 기본 디자인도 좋아요. 흥미로운 아이디어를 잘 구현해놨으니 궁금하시면 살펴보셔도 좋을 것 같아요.
이렇게 GitHub issue 를 통한 블로깅은, 데이터를 쓰는 주체가 나 혼자이니까 별다른 문제가 없어요. 심지어 협업을 하게 된다면, 다른 사람을 그 repository 에 collaborator 로 초대하면 되죠. 만약, 모든 유저가 각자 자기 계정 만들어서 글을 올리는 네이버 블로그 같은 그런 서비스를 만드려는 건 아니니까 이게 가능하죠. 상황에 참 적절히 맞는 선택 같아요.
한 가지만 짧은 예를 더 들어볼게요. 제가 써본 적은 없지만 질문 상자 같은 목적으로 https://peing.net/ko/ 같은 서비스를 많이 쓰시더라구요. 이건 어떻게 만들어 볼 수 있을까요? 전제는, 여러 유저를 위한 서비스가 아니라 그냥 사람들이 저에게 질문을 하는 사이트라고 범위를 일단 좁히자구요. AirTable, Google Sheet, Coda 같은 스프레드시트 서비스들은 대부분 Form 을 제공해요. 그래서 그 Form 의 링크를 공유하면, 누군가가 와서 작성을 하게 되면 여러분의 스프레드시트로 데이터가 들어오죠. 그러면 그걸 언제 어떻게 처리해야 할까요? Zapier 를 사용해서, 새로운 row 가 추가될 때마다 Zapier 가 trigger 되고, 그에 대한 액션으로 저에게 알림이 오게 할 수 있겠죠. 알림은 메일로 올 수도 있고, 아니면 개인용 슬랙 혹은 Discord 서버를 만들어 두고 거기로 메시지가 오게 하는 거에요. 그러면 그 알림을 받고서 제가 스프레드시트 서비스를 열어 새로 추가된 row 에 답변 column 에 답변을 입력해요. 그러면 이 row 의 update 가 Zapier 를 또 trigger 해서, 이번엔 그 답변 column 의 내용이 트위터에 발행되는거죠. 말로 설명하면 복잡하지만 한 두 번 해보다 보면 금세 손에 익고 편해요. 사실상 코딩을 전혀 안하고 나만의 질문 박스를 만들 수 있겠어요.
그래서 꼭 코딩을 많이 해야만 하는 건 아니고, 그걸 피하면 피할 수록 초기에 속도를 높이고 proof of concept 에 빨리 도달해서 유저 피드백을 받을 수 있지 않겠느냐, 하는 생각을 말씀드리고 싶었습니다 :)
마지막으로 제가 좋아하는 Daniel Vassallo 씨의 트윗을 인용하려고 해요.
https://twitter.com/dvassallo/status/1502078858668830720
살고 싶은 라이프 스타일을 먼저 정하고, 그걸 이루기 위해서 어떻게 해야 할지 거꾸로 그 방법을 생각해 보라는 얘기인데, 참 공감이 되고 저도 고민을 많이 해봐야겠더라구요. 이 내용에 관심이 있으시면 Daniel 씨가 Indie Hackers 팟캐스트에 나가 했던 인터뷰를 추천해드려요. 유튜브 영상으로 혹은 팟캐스트 음성으로 두 가지 링크 달아드립니다.
Mastering the Lifestyle-First Approach to Indie Hacking with Daniel Vassallo
Indie Hackers | #177 - Mastering the Lifestyle-First Approach to Indie Hacking with Daniel Vassallo
어떻게 읽으셨는지 모르겠는데, 코딩 덜 하기, 혹은 Lifestyle-driven development 에 대해 어떻게 생각하세요? 간단히 답변 주세요. 궁금합니다 :)