내가 사이드 프로젝트를 하는 이유
현우
지금 주인장은 Nest.js 공부 중 ···
아카이브
Category
Empty
입사 후에도 사이드 프로젝트를 하실건가요?
면접에서 수차례 받았던 질문이다. 이에 따른 대답은 "YES"..
면접관들의 질문은 그저 궁금한 질문일 수 있었으나, 사이드 프로젝트가 업무 몰입에 방해가 될 수도 있다는 의도로 질문을 했던 면접관도 분명 있을 것이다. 하지만 나는 계속 내가 운영하는 프로덕트들을 그로스할 것이다.
왜냐하면 현업에서 겪지 못하는 것들을 사이드 프로젝트에서 겪을 수 있으니까
사이드 프로젝트의 첫 시작, 무작정 웹 개발 시작하기
나는 사실 창업에 관심이 많은 학생이었다, 2017년에 학교를 입학해서 무작정 웹 개발 동아리에 들어가서 Ruby on Rails로 웹 개발의 첫 한걸음을 하고, 벤쳐 창업 동아리 SOPT에 들어가 엔젤 투자자, 여러 CEO 분들을 보면서 창업에 대한 꿈을 키웠다. "내가 만든 서비스로 돈을 벌고, 내가 만든 서비스를 사랑해준다니.. 이 도대체 멋진 일이 아닌가.."
그런데 막상 현실은 정말 어렵다. 프리랜서가 자신을 PR하기 위해 셀프 브랜딩을 하듯, 창업은 CEO인 자신과 서비스를 동시에 브랜딩하면서 프로덕트의 경쟁성을 키워야한다. 또 가정 형편상 집에서는 그다지 도전적인 분위기를 좋아하지 않았다.
그러면서 안정적으로 학교 생활을 하고, 또 안정적으로 개발자로의 직장생활을 하게 되었다. 그러면서 우연히 현직자들과 함께 빠르게 프로덕트를 런칭할 수 있는 디프만이라는 활동을 하게 되었다. 약 5~6주 동안 기획부터 디자인 · 개발 및 런칭까지의 프로세스를 치열하게 고민하고 밤샘작업하는 과정에서 무언가 조그마한 불씨가 타올랐다.
"실패하면 어때, 그냥 시중에 프로덕트로 운영부터 해보자"
그렇게 만들어진게 글을 작성하고, 회고를 좋아하는 나에게 정말 꼭 필요했던 서비스 "레이어" 이다.
그리고 최근에는 빅테크 채용 공고 서비스도 그로스 하는 과정을 겪고 있다.
반짝이고 사라지는 서비스 보다는,
5명이라도 지속적으로 사용할 수 있는 서비스를 만들고싶어.
시작이 창대하면 얼마나 좋을까, 항상 모든 프로덕트의 시작은 그리 창대하지 않다. 디프만에서 처음으로 만들었던 서비스가 "칭찬감옥" 이라는 재미난 요소에서 시작했던 프로덕트였는데, 잠깐 반짝하고 사라지는 서비스가 되어버렸고 그렇게 빠르게 서비스도 종료가 되었다.
사실 사이드 프로젝트를 취업 목적으로 하는 사람이라면 결과는 달성을 했을 것이다. "프로덕트 런칭" 말이다. 하지만, 몇 주간의 피나는 노력들이 서비스 종료와 함께 사라진다는 과정 자체가 나는 너무 허무하게 느껴졌다. 물론 서비스 개발 과정 중에 개발자로써의 큰 성장이 있었으나, 프로덕트가 어떻게 성장할 수 있을까 고민을 했던 측면에서는 무척이나 실패였다.
그래서 다음 프로덕트는 내가 정말 많이 고민했던 프로덕트를 기획하고, 팀원들과 함께 구상하고 만들었다. 바로 "누구나 회고를 작성하고, 성장할 수 있어요" 라는 모토로 시작했던 AI 분석 서비스 레이어이다. 레이어 서비스 또한 초반에는 AI가 분석해주는 회고 서비스로 반짝 빛났지만 (하루에 3~40명씩 회고를 작성해주고 갔었던..) 5명이라도 꾸준히 사용을 해준다면 그 자체로 성공한 서비스라는 것을 애초에 초기 전제의 그라운드 룰로 가져갔다.
그렇게 모바일 뷰부터, 적응형 유저 인터페이스를 기반으로 데스크탑 뷰까지의 여러 여정들이 지나갔다. 그 과정에서 여러 스타트업들과 단체들이 많이 사용을 해주는 경험들이 있었다.
레이어 서비스에서는 회고 생성이나 스페이스 생성을 할 때마다 디스코드에 웹훅을 걸어놓아서 알림이 뜨곤하는데.. 사람들이 가입을 하고, 서비스 안에서 팀원들과 회고를 하는 과정들을 보면 너무나도 기분이 좋다. 그냥 서비스의 시작부터 끝까지를 함께 해주는 과정 자체가 너무나도 고맙고 가슴이 뛴다.
또, 빅테크 공고들이 파편화되어있어 빅테크 공고들만 모아서 집중적으로 공고들을 볼 수 있는 빅테크 채용공고 서비스도 제작을 했는데, 이 서비스의 경우에는 달마다 20%씩 성장하면서 매일 150명, 어느덧 4000~4500명이 매달 찾아주는 서비스로 발전할 수 있었다.
서비스를 개발하고 운영하면서 실제 유저와 소통을 한 적이 있는가?
사실 즐거움은 회사에서도 누릴 수 있다. 하지만 그 즐거움은 실제 유저와 직접적으로 소통을 하면서 서비스를 함께 디벨롭 하는 과정을 느꼈을 때 비로소 큰 성취감으로 다가오게 된다. 그게 아니라면 서비스의 문제를 해결하기 보다는 코드만 보고 기능 개발만 하는 그냥 "코더" 인 것이다.
실제 유저와의 소통은 내가 사이드 프로젝트를 하는 주된 이유이기도 하면서, 사이드 프로젝트의 정말 중요한 요소 중 하나이다. 프로덕트 그로스를 위해서는 항상 유저의 목소리에 귀를 기울여야한다. 만약 서비스에 직접적으로 유저가 목소리를 내지 않는다면, 내가 직접 다가가 우리 서비스에 대해서 느낀 점들을 말해줄 수 있는지 다가가는 방법도 존재한다.
전직장에서 정말 인상깊게 들었던 이야기가 하나 있다. "내 서비스를 내가 좋아하지 않으면 대체 누가 좋아해?" 라는 말이다. 내가 자주 사용하고, 잘 사용할 수 있는 서비스라면 다른 사람들도 자연스레 잘 사용할 수 밖에 없다. 많은 사이드 프로젝트가 단순한 소재로 런칭되고 잠깐 반짝이고 점차 그 빛은 사그라들며 어둠 속으로 대부분 사라진다.
그 어둠 속에서도 프로덕트를 제작하고 개발한 "나"의 존재는 계속 빛이 나야한다. 지금 내가 만들고, 운영하고 있는 빅테크 채용 공고 서비스도 자주 들여다보는 서비스가 되었고, 회고를 하고 싶으면 레이어 서비스에서 회고를 진행하곤한다. 다른 사람들에게도 내 서비스를 권유하고 싶다면, 우선적으로 내가 "헤비 유저"가 되어야한다는 말이다.
내 서비스에서 내가 헤비유저가 되다보니, 실제로 빅테크 채용공고 서비스에서는 빅테크의 인사팀에서 공고가 누락되었다고 올려달라는 사례도 있었고, 회고 서비스에서는 직접 유저가 버그를 발견해 제보해주기도 한다. 이런 과정들이 오래 걸렸지만 너무나도 행복하고 왠만한 스타트업이 아닌 회사에서는 겪지 못하는 상황일 것이다.
내가 느낀 회사는.. 프로덕트를 몸소 느끼기에 너무 아쉬웠다.
회사는 이미 완성된 조직이다. 프로덕트가 이미 완성되어있고, 프로덕트를 그로스하기 위한 인력들이 블록처럼 맞춰져 능수능란하게 일을 하게 된다. 그래서 개발자는 개발만을 진행하고, 마케터는 마케팅만 진행하는.. 이런 집중적인 모습들이 담긴다. 그런데 너무나도 아쉽다.
시니어 개발자들은 사실 오랜 연차 경험으로 다양한 경험들을 했을거라고 생각이 들지만, 주니어 개발자들이 들어가 정의되어있는 기능 개발만 진행하고, "왜"에 대한 물음은 제기하지 않은 채 그냥 "기획자가 이렇게 하라고 했으니까, 들어가면 좋은거야" 라고 생각하기 마련이다.
프로덕트의 시작부터 여러 협업 과정에서의 필요한 의사소통 과정 · 도구 · 그로스 과정들을 느끼지 못하고 프로덕트의 일부분에서 경험을 쌓고 있다는게 너무나도 아쉽다. 물론 전문적인 역량을 쌓는데는 도움이 될 수 있으나, 이런 경우에는 프로덕트의 전반적인 부분을 경험한 사람이 훨씬 유리할 수 있다고 생각한다.
디자이너 : "이 화면은 이렇게 구현이 가능할까요? 해당 화면을 구현하는데 어려움이 있을까요?"
이 과정에서 디자이너는 화면에 대한 구현 사항들을 물어보고 있으나, 기술적인 용어들이 마구 섞여나오면 이해가 잘 되지 않고 "된다, 안된다" 에만 초점을 맞추게 된다.
개발자 : "이 부분은 서버에서 어떻게 데이터를 가져와서 DB에는 ~을 하고, 클라이언트 쪽에서는 ~ 최적화를 해서 구현을 하면 될 것 같은데요, 될 것 같네요.. 로컬 호스트 환경에서 잠깐 화면을 보여드려볼까요?"
보통의 개발자는 디자이너와 함께 만들어간다는 소통보다는 구현 측면의 소통을 중요시한다. "어떻게 구현을 할 지에 대해 초점을 맞춘다"
→ "이 부분은 ~ 데이터가 존재하는데요, 이 데이터를 가져와서 OO 디자이너님이 그려주신 디자인에 넣으면 될 것 같아요. 충분히 구현이 될 것 같습니다. 잠깐 제가 화면을 보여드릴 수 있을 것 같은데 보여드릴까요?" 와 같이 쉽게 풀어 말하는 것은 협업 경험의 차이에서 나온다. 가끔 시니어 개발자분들의 이야기를 들으면 "왜 이렇게 어렵게 설명을 할까" 라는 생각이 들기도 한다.
회사에서는 초점이 한 곳에 집중적으로 맞춰져있어 다양한 것들을 보지 못한다면 사이드 프로젝트는 여러 방면에서 다양한 생각들을 할 수 있어 선택의 폭과 견문을 넓힐 수 있다는 점에서 정말 좋다. 특히 기획자와 소통을 하는 과정에서 사이드 프로젝트 과정에서 내가 느꼈던 기획의 특이점이나 좋았단 점들을 기반으로 소통을 할 수도 있고, 내가 사용했던 애널리틱스 툴을 UX 디자이너에게 소개하는 등 여러 의사 결정 과정에서 더 좋은 경험과 의견을 제시할 수 있다.
실제로 회사에서도 사용자들이 서비스를 대체 어떻게 사용할까에 대한 의문점들이 제기되었는데, 사이드 프로젝트에서 경험했던 Clarity를 통해 사용자가 어떻게 사용하는지 애널리틱스를 통해 빠르게 확인할 수 있었던 경험이 있다.
내가 만든 서비스로 누군가에게 도움을 줄 때, 너무 행복하다.
사이드 프로젝트로 수익을 벌면 물론 좋겠지만, 그것보다는 내 서비스로 누군가 도움을 받았을 때. 그리고 그 사실을 알게 되었을 때 정말 신이나고 행복하다. 오늘도 누군가 내 서비스를 자주 보고 도움을 많이 받았다는 사실을 접했는데, 너무 성취감이 많이 들었다. (이 맛에 개발자를 하는 느낌이 들기도 하고 ^,^..)
얼마전에 백준 코딩 테스트 서비스가 종료되었는데, 선한 마음으로 만들고 계셨던 백준님의 마음이 어느 정도 이해가 가기도 한다. 회사를 다니면서 사이드 프로젝트를 하는 것이 업무에 지장을 준다고 안좋은 시선들이 많은데, 전혀 아니다. 새로운 프로덕트를 통해 새로운 시각들을 배우고, 이 시각들은 또 회사에서 다양한 사람들에게 긍정적인 시선으로 전파가 된다.
이 긍정적인 시선들은 곧 회사의 성장으로도 이어지기도 한다. 내가 동료들한테 그러고 있으니까..!
실제로 그로스하고 있는 서비스가 궁금하다면, 아래 링크들을 통해 서비스에 접속할 수 있다.
이 서비스들이 또 하나의 새로운 견문을 제공해주었으면 좋겠는 마음이다.
•
빅테크 채용 공고 모음 : https://nklcb.kr
•
悠悠
Subscribe to '悠悠自適'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to '悠悠自適'!
Join Slashpage and subscribe to '悠悠自適'!
