연말 ~ 연초쯤에 글을 하나 쓰고자 한다면 그 주제가 자연스레 지난 1년을 돌아보는 회고가 되기 마련이지만, 벌써 N년째 일기장에 따로 쓰고 있는 연말 회고록이 있기 때문에 다른 주제를 선택했다. 2024년 회고록 대신 오랜만에 과거 프로젝트 회고록 하나 쓰자구. 근데 이 글 시작을 2024년 연말에 하긴 했는데 요즘 글 쓰는 속도를 봐선 2025년 연초에 끝낼 수나 있을까 모르겠다. 아무튼 시작.

QUE

QUE, 당신의 콘서트를 시작하세요.

오늘의 주제는 내 개인 프로젝트 인생 최고의 야심작이자 폭망작이었던 QUE.

인생에서 가장 시간이 많았던 시절

때는 바야흐로 2021년 연말, 이 블로그를 막 시작했을 때쯤이었다. 아마 살면서 가장 열심히 살았던 기간 중 하나였던 소프트웨어 마에스트로 과정이 끝나고, 할 게 없었다. 사실 지금 생각해 보면 그때 그 기세 그대로 구직 준비를 하는 것이 옳았겠지만, 왠지 그러고 싶지가 않더라고. 아마 그때 당시 내가 가지고 있었던 콤플렉스 탓이었을지도 모른다. 제대로 배포해 본 웹 서비스 하나 가지고 있지 않았다는 것이 계속 내 마음에 짐처럼 남아 있었다. 그래서 하나 만들어 보려고 했던 거지. 연수 과정을 거치며 한껏 끌어올린 개발력을 동원해.

하고 싶은거 하세요

노홍철은 말했다. 하고 싶은 거 하라고. 나는 솔직히 말해 돈 버는 아이템 떠올리는 재주는 없는 것 같다. 그냥 내가 생각하기에 왠지 있으면 쓸 것 같은 거 떠올린 다음 거기다 그냥 개인 취향이나 잔뜩 부어놓을 뿐이지. 조금 TMI지만 내가 개발력 못지않게 그 당시 한껏 끌어올렸던 것이 가창력이었고, 이걸 개인 프로젝트에 녹여보면 어떨까 싶은 생각을 가졌던 것이다.

망상

사실 제대로 된 사업을 벌이려면 이 아이템이 정말 수익이 되는지, "TAM-SAM-SOM"이니 "SWOT"이니 하는 각종 도구를 도입해 그 당위성을 확보하는 것이 가장 중요할 것이다. 하지만 당시 아이디어 노트엔 이처럼 합리화의 흔적들이 가득했을 뿐이었다. 뭐, 이제 와서 후회하는 건 아니지만. 오히려 생각해 보면 앞서 회고록을 썼던 이나 도마도 같은 프로젝트에선 이런 도구를 사용하는 것이 좋겠단 생각 자체를 하지도 않았으니 이 QUE라는 프로젝트에 내가 얼마나 진심이었는지를 나타내는 것 같기도 하다.

뮤직 큐

onboarding
솔직히 아직도 이 화면 보면 조금 설렌다.

그래서 이렇게 합리화와 변명으로 시작한 프로젝트 QUE는 무엇인가. 누구나 한 번쯤은 주목받고 싶은 욕망을 가져본 적이 있을 것이다. 특히 내가 뭔가 잘한 것 혹은 잘하는 것이 있다는 생각이 드는 순간, 이걸 혼자 썩히고 있는 것이 너무 아깝고 이걸 다른 사람들에게 보여주고 싶단 욕구가 생기기 마련이다. 그래서 저마다 SOOP 같은 서비스에서 개인 방송을 하거나, 유튜브에 영상을 찍어 올리는 것이겠지. 그리고 그게 어쩌다 사람들의 수요를 저격해 버리면 돈도 좀 만지는 거고, 그렇게 성공한 사람들의 스토리를 본 다른 사람들이 혹해선 서비스의 사용자가 더 늘어나고... QUE는 노래에 특화된 유튜브를 만들고자 했던 시도였다. 평소 스스로 노래를 좀 부른다고 생각했던 나는 노래라는 콘텐츠에 집중해 그런 기회를 제공하는 서비스를 만들어 보고 싶었다. 이런 캐치프레이즈와 함께.

QUE, 당신의 콘서트를 시작하세요.

하지만 그냥 자기가 부르는 노래를 업로드하는 서비스라고 한다면 유튜브나 사운드 클라우드 놔두고 굳이 이런 사이트를 사용할 필요는 없다. 이 서비스만이 줄 수 있는 경험이 있어야겠지. 뭔가 유사 가수로서의 체험을 해볼 수 있는... 이처럼 흐릿한 이미지를 구체화해 보려고 이것저것 노력을 했었던 것 같다.

브레인스토밍

시나리오
내용이 좀 민망해서 올릴까 말까 계속 고민했는데...

처음 기획할 때 갈피를 잡으려면 시나리오를 써보라고 하더라고. 대충 어떤 기능들이 필요한지 정리가 되는 느낌. 이렇게 도출된 기능들을 가지고 아래처럼 애플리케이션의 화면 간 구조도를 그려볼 수도 있었다. 이걸 IA(Information Architecture)라고 하던가.

IA

아무튼 아이디어를 요약하자면 첫째는 관종에게 어울리는 경험을 선사해야 한다는 것, 둘째는 그 경험이 재밌어야 한다는 것. 영상을 업로드하고 공유하는 기능을 가장 중심에 두고, 조금 고상해 보이는 표현을 쓰자면, 개인화와 게임화로 그것을 보조하고자 하였다.

그림 놀이 삼매경

그 결과 이런 그림들이 여러 장 나왔다.

명화

정말... 수준 높은 그림이 아닐 수가 없군... 하지만 범인들은 이 초현실적인 프레임을 감히 받아들일 수 없을 터이기에 나는 이를 인간의 언어로 번역할 수 있는 도구를 도입했다. 디자인하면 요즘 거의 표준으로 쓰고 있는 듯한 도구 Figma.

figma 1

앞서 말했듯이 영상을 업로드하고 공유하는 기능은 기본이다. 엄한 영상 올라오면 신고도 할 수 있어야 하고... 앞뒤 정도는 자를 수 있는 기초적인 영상 편집도 지원하고... 가요 데이터베이스와 연동되어서 어떤 노래를 불렀는지 표시할 수 있으면 좋고... 아 그리고 영상을 보는 중간에 좋아요 같은 리액션을 주는 기능도 계획했었는데, 얼마 안 가 유튜브에서 비슷한 기능이 나오더라고. 가히 시대를 앞선 기획이었음이 틀림없다.

figma 2

"스튜디오"라고 이름을 붙였던 사용자의 개인 공간에도 꽤 정성을 들였었다. 뭐... 그럭저럭.. 다른 서비스에 있는 기능들 따라해서... 대신 게시판 영역은 좀 더 고도화를 해봤었다. 이름이 게시판이라면 진짜 게시판다워야지. 포스트잇이나 스티커를 붙인다는 느낌으로 만들면 어떨까 싶었다. 주제에선 조금 벗어나지만, 이 게시판에 대한 상상력이 계속 발전해서 또 다른 프로젝트로 이어지기도 했었다.

figma 3

그래서 이 모든 활동이 재미가 있으려면 어떻게 만들어야 좋을까. 업로드된 영상들은 다른 사용자들에게 평가를 받을 수 있다. 영상 업로드, 시청 수, 좋아요 수, 그리고 평가 등 다양한 활동과 그에 대한 반응을 종합해 사용자에게 "스탯"과 "경험치" 그리고 그를 기반으로 한 "레벨"을 부여하고자 했었다. 그래서 사용자가 이런 흐름으로 성장하는 모습을 바랐다.

  • 연습생🔰 : 영상 업로드 불가, 시청 및 평가 가능
  • 아마추어 : 하루 최대 5분, 영상 하나 업로드 가능
  • 버스커 : 영상 업로드 한도 증가
  • ...
  • 스타 : 랜선 콘서트 지원

명칭은 다 가칭이고 상세한 기능도 러프하게 상상한 것들이긴 하다. 아무튼 중요한 건 차등을 두고 성장하는 재미를 줄 수 있으면 좋겠단 생각을 했다는 것. 이 과정에 일종의 수익화 요소도 넣을 수 있으면 좋겠고 말이야. 레벨 상관없이 기능을 해금할 수 있게끔 해준다던가.

이처럼 기획 및 디자인에 적지 않은 정성을 들였었다. 작업이 영 안 되는 느낌이 드니까 집중 좀 해보겠다고 놀거리 없는 세종시 누나 집까지 찾아가서 피그마 작업을 하고 있던 기억이 난다. 이게 지금 회고록 작성 기준 3년 전 일인데, 솔직히 이런 산출물들 없었으면 회고록 쓸 엄두조차 못 냈을 것 같다. 사실 지금도 기분은 산출물 무더기 위에 엎드려 그 내용을 엉금엉금 더듬어 가면서 한 자씩 겨우 써 내려가는 느낌이긴 하지만.

인생에서 진짜 가장 시간이 많았던 시절

아무튼 이제부턴 개발자 모드. 피그마로 질러놓은 것들을 어떻게 구현하면 될지 고민이 시작되었다. 본격적인 개발 시작과 동시에 나는 수능 공부할 때도 가본 적이 없었던 스터디 카페를 등록해 개발 시간을 확보했다. 주어진 시간이 많은 것 같으면서도 막 쓸 순 없었거든. 소프트웨어 제품 개발이란 게 주구장창 코드만 잘 짠다고 만사형통은 아니기도 하니까.

약간 체계적이고 약간 애자일한 개발

개발 기간 시작과 함께 나는 내가 앞은 제대로 보고 걷고 있는지 혹은 너무 느리게 걷고 있진 않은지 판단할 수 있도록 도와줄 도구들을 도입하기로 했다. 그래서 프로젝트 관리 도구로 깃허브 프로젝트를 썼는데...

gh project 1
링크는 죽었고

gh project 2
숫자는 카운팅 되는데 리스트엔 없음

아니 그게 없어졌다... 듣자 하니 이 "프로젝트"라는 서비스가 한 번 크게 버전업이 됐었나 보더라. 그와 동시에 과거 버전의 프로젝트가 사라진 것 같다. 마이그레이션을 해야 했던건데 아마 그때 한창 내가 다른 일 때문에 바빴을 시기라 신경을 쓰지 못했나 보다. 아니 그리고 깃허브는 무슨 서비스명을 여기저기서 다 쓰는 단어 "프로젝트"로 지어서 관련 정보 찾기도 어렵게 만들어놨어. 일단은 이 회고록 작성의 예상치 못한 벽을 넘어서 대충 말과 남은 단서 조각들로 계속 설명을 이어나가 보겠다.

issue
다행히 이슈들은 남아있다.

이 이슈들은 모두 깃허브 프로젝트가 제공해 주는 칸반보드에서 관리되던 것들이다. 매일같이 스터디 카페에 출근을 해서 칸반보드로 현재 이슈들을 한눈에 확인하고, 어떤 작업을 진행하면 되는지 결정했었다.

git flow

이렇게 이슈 번호를 커밋 메시지나 브랜치 이름에 기록해 두면 작업 내용을 추적하기도 편하다구. 깃 작업은 기본적으로 master, dev, release로 브랜치를 나누는 깃 플로우(Git-flow) 방식을 채택했는데, 아무래도 혼자서 진행하던 프로젝트이다 보니 dev에서 굳이 feature 브랜치는 잘 만들지 않게 되더라고.

빛이있으라

"빛이 있으라", 다음 기본 파일들 생성, 다음 앱 제일 기본 화면 생성 후 진행한 작업이 유닛 테스트 환경 초기화. 이 프로젝트엔 애자일 방법론 중 하나인 TDD를 도입했다. 뭔가 빠르게 결과물을 도출해 내는 목표엔 조금 멀어지는 것 같긴 한데... 이때 당최 프론트엔드 테스트 코드는 어떻게 짜는 건지 모르겠단 생각을 좀 가지고 있었던 영향이 크긴 했다. 이럴 때 아니면 언제 해보겠어! 하는 마인드.

이것저것 만들어 봤다

repos

이 블로그 초창기 썼던 글 중 하나가 생각나는군. WSL에 Expo 개발 환경을 세팅하는 중에 일어난 문제에 대한 글이었지. 그 글이 바로 이 QUE 프로젝트 진행하면서 있었던 일을 다뤘던 것이었다. QUE는 Expo 기반의 리액트 네이티브(React Native)를 사용해 개발되었다. 그리고 이게 내 첫 번째 리액트 프로젝트였다. 그전까지 뷰(Vue.js)만 써오다가 사람들이 리액트를 많이 쓴다더라는 말에 바로 머리를 들이밀어 버렸지. 이때 과감히 시작한 덕분에 내가 지금 리액트 쓰면서 먹고살고 있구나 싶고... 이때 체계적으로 배우진 않은 탓에 아직도 리액트 코드가 날마다 새로운 개발 생활을 보내고 있지 않나 싶다. 아무튼 이 QUE 앱에 대한 소스와 개발 당시 작성했던 이슈들은 Que 저장소에 들어 있다.

firebase
이 분이 우리 서비스 백엔드 개발자 되는 분이십니다.

개발 동안 프론트엔드 앱을 만드는 데에만 집중하고 싶었기 때문에 백엔드는 상용 서비스를 사용하기로 했다. 파이어베이스를 통해 계정 관리, DB, 그리고 이 서비스에서 가장 중요할 영상 데이터 스토리지 관리까지 커버하려고 했었지. 다만 이 파이어베이스가 마냥 만들어 놓는다고 100% 내 의도대로 동작하는 것은 아니어서 약간의 조작을 가하는 코드를 작성했던 기억은 있다. 그 흔적이 바로 Que-firebase 저장소인데, 다시 살펴보니 생각보다 별거 없긴 하군.

email-verifier

그렇다고 모든 서버 기능을 파이어베이스로 처리한 것은 아니었다. 회원 가입 과정에서 이메일 인증을 구현하기 위한 서버는 별도로 직접 만들었었다. 복잡도가 높지 않다고 판단했기에 당시 눈여겨보고 있었던 Deno를 시범적으로 사용했고 MongoDB를 곁들여 구현했다. 지금 생각해 보니 MongoDB 말고 다른 DB를 쓰는 게 좋았을 것 같기도 하네.

약 3개월 간의 여정의 끝

무덤
여기에 잠들다

결론부터 말하자면 결국 이렇게 개발한 QUE 어플리케이션은 마켓에 올라가지 못했고 나는 이 프로젝트를 끝맺지 못하고 다른 일을 하러 떠나 버렸다. 그나마 리액트 네이티브로 개발해 둔 덕분에 쉽게 빌드한 웹 페이지로 흔적 하나 정도 남긴 채. 앞서 이 카테고리에서 다뤘던 이나 도마도는 어느 정도 쓸 만한 수준 까진 결과물이 나와서 아직도 가끔씩 내가 사용하는 중이지만, QUE는 그런 것 없다. 그저 "그땐 그랬지" 정도의 추억으로나 남아버렸다.

이렇듯 프로젝트는 실패했다고 말해야겠으나, 그때 당시를 생각해 보면 내가 게을렀던 탓은 아니라고 생각한다. 내 삶에서 "개발"이라는 행위에 대해서 이보다 더 정성을 들였던 기간이 있을까. 처음에 말했던 소프트웨어 마에스트로 시절보다, 심지어 돈 받고 일할 때보다 더 집중했던 것 같다. 코드를 많이 짰다는 것뿐만이 아니라 개발이라는 행위를 체계적으로 정성을 들여서 해보고자 노력했던 시기였다. 앞서 말했던 스터디카페도 그 일환 중 하나였고, 프로젝트 관리, 테스트 코드 작성 등등. 노력은 많이 했어.

이 글의 앞부분에서 QUE를 보고 노래에 특화된 서비스라고 표현했다. 아마 세상에서 가장 큰 데이터 규모를 가지고, 가장 많은 사용자를 대상으로 운영 중일 그 유튜브. 단도직입적으로 말하자면 나는 그걸 혼자서, 아무런 투자금도 없이 만들어 보려고 했던 것이다. 시간이 부족할 수밖에. 나의 기호 하나만을 가지고 시작한 다음 프로젝트의 당위성까지 오직 그 한 가지 이유에 매달아 놓은 사람의 최후처럼 되어버린 것이다. 혹은, 소모한 시간의 4배 정도를 더 투자해서 마침내 제품을 완성하더라도 성공할 리 없다는 것을 이미 알고 있음에도 계속 일을 진행했던 비합리적 낭만주의자의 최후라고도 할 수 있겠지.

만들기 위해 배우지 말고 배우기 위해 만들어라. {실용주의 사고와 학습}

하지만 내가 지겹도록 인용하는 이 말처럼, 나는 일단 뭐라도 만들었기 때문에 결국 뭐라도 얻어냈다고 생각하고 있다. 그 사실을 자랑하려고 굳이 이 3개월짜리 수명의 프로젝트를 3년 만에 파묘해 다시 설명하는 것일지도 모른다. 이때 배웠던 코드들을 당장 지금 업무에도 사용하고 있으니까. QUE를 만들면서 리액트를 처음 배웠고, QUE를 만들면서 프론트엔드 테스트 코드를 처음 짜 봤으니까. QUE에서 풀스택 엔지니어링을 했기 때문에 혼자서 풀스택으로 웹 서비스를 유지보수 하는 일을 하면서 돈을 벌 수도 있었던 거로 생각한다. 까놓고 말해 망한 건 이 프로젝트지 내가 아니잖아.


QUE는 돌아옵니다.

그리고 굳이 망한 프로젝트를 2025년 시작하자마자 다시 이렇게 꺼내본 또 다른 이유. 얘가 뭔가 계획을 하고 있다는 거지. 노래 부르는 걸 얼마나 좋아하면 이런 무모한 일까지 저질렀겠어. 지금도 일요일 집 근처 카페에서 이 글을 쓰고 있는데 빨리 탈고한 다음 동전 노래방을 가고 싶다. 사실 QUE 말고도 흐지부지된 개인 프로젝트들은 수두룩하다. 그렇지만 결국 가장 미련이 남는 프로젝트는 이렇게 내 취향이 잔뜩 들어간 쪽이기 마련이더라. 그래서 나는 이번 글을 통해 되짚어본 경험을 교훈 삼아 다른 형태로 QUE를 배포하는 것을 올해의 목표로 삼고 있다. 대신 이번엔 좀 현실적인 방향으로. QUE는 개인 블로그의 형태로 돌아올 것이다. 안 그래도 개발 블로그를 자체 개발한다고 시간 쓴 것도 모자라 영화 감상문 올리는 블로그까지 별도로 운영하는 입장에서 하나 더 늘린다는 게 정말.. 무모하단 생각도 들긴 하지만. 비합리적인 낭만주의자란 말을 했지. 결국 이 일을 다시 할 수밖에 없는 운명인 거야.