지난 에피소드에 Lifestyle-driven development에 대한 이야기를 말미에 담았는데, 어떤 분이 좀 더 설명해 달라고 하셨어요. 이런 요청 환영합니다! 그래서 좀 더 얘기해볼게요. 아마 Daniel 씨가 TDD (Test-driven development)를 가지고 말장난 비슷하게 한 것 같은데, 말 그대로 라이프스타일을 중심 삼아 커리어 패스를 만들어보자는 얘기예요. 한번 예를 들어볼게요. 만약 ‘5년 뒤, 시골에서 큰 개 두 마리 키우고 큰 텃밭을 가꾸면서 주 3일만 개발하는 삶’이 여러분의 라이프스타일 목표라면? 그러면 지금부터 어떻게 준비해야 5년 후에 그렇게 될까요? 돈, 명성, 지위 이런 게 아니라, 그 라이프스타일을 목표로 잡았으니 그에 맞는 준비를 해야 하는데…
한번 생각나는 대로 상상을 펼쳐볼까요. 네쿠카라배라는 표현을 며칠 전에 배웠는데요, 네이버 쿠팡 카카오 라인 배달의 민족 줄임말이라면서요. 아무튼, 시골로 내려간다면, 그런 회사들을 다니긴 어렵겠죠? 그런 회사들이 Full Remote를 허용해주려나요? 잘 모르겠네요. 그런 회사든, 아니면 그냥 서울, 판교 등에 있는 작은 스타트업이든 Full Remote 허용해주는 곳이 한국엔 아직 많지는 않을 것 같아요. 아, 그런데 Full Remote는 해주더라도, 주 3회 근무는 거의 99.9% 확률로 허용해주지 않을 거 같아요. 음, 해준다고 해도 급여를 3/5로 깎이게 되면 생계가 불가능할 듯? 그러면 앞으로는 그런 회사에 다니는 걸로는 그 라이프 스타일을 만들 수가 없겠네요? 그러면, 시급을 세게 부르는 프리랜서가 되는 방법이 있겠죠? 지금부터 시작해서 고객을 점점 늘려서 5년 뒤쯤엔 주 3일만 일해도 그걸로 먹고살 수 있을지도? 시급을 세게 부르려면 한국보단 그냥 외국 쪽으로 클라이언트를 잡으면 더 유리할 수도 있겠네요. 혹은, 서비스 개발을 해서 거기서 수익을 내고 인디 해커로써의 삶을 산다? 제가 예를 들기 위해 좀 급진적인(?) 라이프 스타일을 예로 들었고, 그러다 보니 현실적으로 쉽지만은 않은 이야기를 늘어놓게 됐는데, 여하튼 포인트는 아시겠죠. 이런 식으로 원하는 라이프스타일을 정해놓고 그에 맞게 거꾸로 경로를 살펴보다 보면 명확한 길까지는 안 보여도, 적어도 피해야 할 길은 뭔지 보일 것 같아요. 저도 개인적으로 정해놓은 라이프스타일 목표가 있어서 가지 치기 하면서 고민을 해보는 중이고요. 여러분의 라이프 스타일 목표는 뭘지 궁금하네요.
자, 그러면 다음 주제로 넘어가 보죠. 지난 에피소드에서도 언급했지만, 서비스의 데이터베이스를 구축하는 방법은 다양해요. 데이터가 어떤 형태이고, 누가 읽을 수 있고, 누가 쓸 수 있는지 등에 따라 선택지가 달라지겠죠. 예를 들어 개인 블로그라면, GitHub repository 내의 markdown 파일로 포스팅을 관리해도 큰 문제는 없을 거예요. 나 혼자 쓸 수 있는 private repository 에다가, CI (Continous Integration. 예를 들어 CircleCI 나 GitHub Actions)와 엮어서 배포하면 누구나 볼 수 있는 웹사이트가 되겠죠.
뉴스 사이트 내지는 작성자가 여러 명인 블로그를 만든다면 어떨까요? GitHub에 Private repository로 설정한 후 작성자들을 초대하고, markdown으로 작성할 수 있겠죠. 하지만 markdown에 익숙지 않은 멤버가 있거나, markdown 으로 표현할 수 없는 복잡한 레이아웃의 포스팅을 정기적으로 하고 싶다면 다른 방법으로 데이터 베이스를 구축해야 할 거예요. 물론, 서버를 마련하고 거기에 말 그대로 MySQL이나 PostgreSQL 등을 설치하는 것부터 시작할 수 있지만, 저는 CMS(Content Management System)을 제안해보려 해요. 우리가 흔히 익히 알고 있는 Wordpress 가 대표적이죠. 요즘은 CMS 중에서도 Headless CMS의 전성 시대라고 볼 수 있는데, 그중에 제가 가장 애정 하는 Sanity라는 서비스를 소개하고 싶어요.
우선 Headless CMS가 뭔지 간단하게만 짚고 넘어갈게요. 예전에 Wordpress 같은 CMS를 쓴다는 건, 그들이 제공하는 일종의 어드민 툴에서 글을 작성하면, 그들이 그 글 내용과 사이트의 레이아웃(헤더, 내비게이션, 푸터 등)을 조립해서 HTML + CSS 형태로 렌더링 해줬죠. 하지만 우리는 늘 우리 입맛에 맞게 바꾸고 싶기 때문에, Custom theme 이라던가 plugin 을 하나 둘 붙이게 되고, 그러다 보면 자연스레 서로 충돌하는 theme과 plugin 때문에 유지 보수가 굉장히 어려웠죠. 이에 대한 대안으로 나온 Headless CMS는 그런 HTML + CSS 대신에 그냥 데이터를 그대로 내려주면 (보통 JSON) 그걸 사용자가 직접 렌더링을 하게끔 하는 거예요.
아니 그러면 프론트엔드를 전부 다 개발해야 하는 거 아닌가?
네, 맞습니다. 그게 요구 조건에 맞지 않으시다면 전통적인 CMS 혹은 다른 방법을 찾아보시는 걸 추천해요. 지금은, 그 프론트엔드 부분보다는, 순수히 날(raw) 데이터베이스를 세팅하는 것의 대안으로써의 관점으로 Headless CMS를 들여다보고 싶어요. 데이터베이스를 직접 세팅하는 것에 비해, Headless CMS를 쓰면 생기는 이점은,
- 어드민 페이지 → 데이터의 CRUD (Cread, Read, Update, Delete)를 손쉽게 할 수 있는 UI 가 제공돼요. 그리고 보통 Rich Text Editor 내지는 잘 만들어진 Preview 가 딸린 Markdown Editor 가 제공되죠.
- REST API → 요즘 웬만한 Headless CMS는 API First를 표방하기 때문에, 어드민 페이지에서 할 수 있는 대부분을 API로 할 수 있어요. 그 말은 여러분의 서비스의 서버단에서 대부분의 데이터 조작을 수행할 수 있다는 거죠. 아, 그리고 REST API라고 적긴 했지만, 요즘엔 GraphQL도 많이 지원돼요.
- Access Control → 멤버들의 접근 권한을 디테일하게 설정할 수 있어요. 예를 들어, 내가 운영하는 블로그에 객원 작가를 2명 초대하는데, 한 명은 A라는 카테고리만 글을 쓸 수 있고, 다른 한 명은 B라는 카테고리만 글을 쓸 수 있게 하는 거죠. GitHub 내의 Markdown 파일로 관리를 한다면 이건 애초에 불가능할 일이고, 날(raw) 데이터베이스를 놓고, 그 위에 이런 Access Control을 직접 구현한다고 하면, 혹은 라이브러리를 가져다 사용한다고 해도, 사이드 프로젝트를 제대로 시작하기도 전에 지쳐버릴 거예요.
아, 그러면 많고 많은 Headless CMS 중에 왜 제가 Sanity를 추천하느냐? 이건 다음 에피소드에서 다룰게요. 너무 길어져서 이 얘기는 이쯤 끊어야 할 것 같거든요. 물론 제가 Sanity를 추천하는 이유는 다음 에피소드에 적겠지만, 다 제 니즈에 그게 잘 맞아떨어져서 그랬던 거고, 모든 Headless CMS 중에 Sanity 가 무조건적으로 최고라는 얘기는 아닙니다. 각자 필요에 따라 고르는 건데, 꽤나 매력적인 기능들을 겪었어서 추천을 해드리고 싶네요.
끝으로 James라는 디자이너이자 인디 해커를 소개하고 싶어요. 유명 앱들의 아이콘을 직접 다시 디자인해서 아이콘 세트를 판매한 사람이에요. 안드로이드 폰에서는 테마 바꾸고 앱 아이콘 바꾸는 게 처음부터 있던 기능이지만, 아이폰에서는 여전히 시스템 레벨에서의 그런 변화는 불가능하죠. 하지만 iOS Shortcut 이 나오면서 조금은 엉성하지만 커스텀 아이콘을 사용하는 게 가능은 해졌는데요. 이 시기에 James 가 만든 유료 아이콘 세트가 불과 4주 만에 28만 USD, 그러니까 3억 4천만 원 정도를 벌었다고 해요.
이 스토리에서 우리가 집중해야 할 건,
- 정말 짧은 시간에 엄청난 돈을 벌었네.
- 그거 사실 별거 아닌데?
- 나도 할 수 있었겠다.
가 아니에요. 제가 디자이너가 아니지만 디자이너라 치고, 저 똑같은 아이콘 세트를 제가 그 시기에 만들어 냈다고 쳐요. 제가 James와 같은 비즈니스적인 성공을 할 수 있었을까요? 저는 100% 아니라고 생각해요. 그러면 어디서 차이가 오는 걸까요? 이 부분이 우리가 지속적으로 고민해봐야 할 부분이라 생각해요.
James 가 IndieHackers 팟캐스트에 나와 인터뷰하면서 했던 얘기 중 하나는, 원래부터 그런 아이콘 디자인을 꾸준히 해왔고, 트위터 통해서 사람들에게 계속 보여줘 왔다고 하더라고요. 실력도 좋지만, 꾸준히 해왔기 때문에, 신뢰가 구축되어 있었죠. 그러다 드디어 유료로 출시되니, ‘이제 드디어 구매할 프로덕트가 생겼구나’ 하면서 사람들이 열심히 샀죠. 물론, 그건 판매의 시작이었고, 그 시기에 그 트렌드가 붐이었기 때문에 그 사람의 원래 트위터 Audience를 훨씬 뛰어넘어 그 프로덕트가 널리 퍼져나갔어요. 하지만, 그 Audience 가 없었다면 초기 바이럴이 만들어지기 굉장히 어려웠을 거예요.
James는 몇 시간 만에 그 아이콘들을 만들어 낸 능력도 뛰어났지만, 그걸 결제 기능을 갖춘 웹사이트로 만들어 내놓은 그 프로듀싱 능력이 대단하다고 생각해요. 여러분에게 아이콘 세트 zip 파일이 이미 있다면, 구매 및 다운로드가 작동되는 웹사이트를 어떤 식으로 만드시겠어요? 몇 시간 만에 가능하려나요? 며칠에 걸쳐 천천히 바닥부터 예쁘게 만든 웹사이트에 결제 모듈도 직접 연동할 수 있겠지만, James 가 일단 판매할 수 있는 수준으로 빠르게 만들어서 내놓을 수 있었던 건, 평소에 그런 걸 해봤기 때문에, 그리고 그런 걸 쉽게 도와주는 서비스들을 잘 섞어 활용해 본 경험이 있고, 그렇게 진행하겠다는 결단력이 있었기 때문 같아요. 또 뭐가 있을까요? 답변으로 여러분의 생각을 들려주세요.
James는 트위터 @traf 에서 팔로우하실 수 있고, 제가 들었던 IndieHackers 팟캐스트의 해당 에피소드는 아래 링크에서 들으실 수 있고, 자막도 보실 수 있습니다.
Making $280k in Four Weeks with Traf
오늘 에피소드를 줄이려고 노력했는데 너무나 길어졌어요. 더 잘게 쪼갤 걸 그랬나 싶기도 한데, 어떤가요? 지금 길이 좋다, 혹은 좀 더 짧게 짧게 끊어 읽고 싶다. 피드백 환영합니다 :)
읽고 흥미로웠던 점이나, 중간중간 제가 던진 질문에 대해 답장 주세요. 이 뉴스레터 쓰는 데 있어 크고 즐거운 원동력이 된답니다. 감사합니다!
날씨가 이제 풀려서 열심히 파종하고 베란다 농부로서 풍년을 꿈꾸는 이은재 드림.
고추가 열심히 자라고 있어요.