1년 6개월동안 만든 디깅 뮤직
너무 많은 시간을 들인 것 같지만,, 배운 게 많다.
1) 처음엔 2달이면 끝날 줄 알았다.
처음엔 정말 2달이면 끝날 줄 알았다. 기획만 잘 세우면, 머릿속에 있는 걸 금방 구현해서 곧바로 세상에 내놓을 수 있을 줄 알았다. 빠르게 만들어서 반응을 보고, 운 좋게 입소문이라도 타면 ‘빵’ 뜨는 일도 가능하겠지... 그런 상상을 하면서 시작했다.
하지만 현실은 달랐다. 막상 손을 대보니, ‘디테일을 붙인다’는 게 이렇게 어려운 일인지 처음 알았다. 서비스라는 건 결국 수많은 선택과 배제, 그리고 생각보다 훨씬 많은 시행착오 위에 완성된다는 사실을 뼈저리게 느꼈다. 무엇보다도, 처음이다 보니 방향을 잘못 잡은 채 시간을 흘려보낸 경우가 많았다. 지금 돌이켜보면 초반 1년 동안 했던 작업의 대부분이 결국 무너졌고, 진짜 의미 있는 작업은 마지막 6개월 동안 몰아쳤던 그 시기에 집중되어 있었다.
그렇게 많은 걸 거치면서, 나는 조금씩 배웠고, 깨달았고, 정리할 수 있었다. 이 글에서는 그 시행착오 끝에 얻은 몇 가지 중요한 교훈들을 정리해보려 한다. 아직 완전하지도 않고, 누군가에게는 당연한 이야기일 수도 있겠지만, 적어도 나에게는 아주 중요한 변화였다.
2) 처음엔 아이디에이션을 마구마구 하면서 세계관을 늘리는 게 필요하다.
큰 그림이 없으면, 작은 일에 지친다.
서비스를 처음 만들기 시작했을 때, 나는 일부러 상상의 크기를 제한하지 않으려고 했다. 구체적인 기능이나 구현 방식을 따지기보다는, 내가 만드는 게 얼마나 큰 세계로 확장될 수 있을지를 계속 상상했다.
‘이게 정말 음악 문화를 바꿀 수 있다면?’ ‘가사를 스트리밍 서비스에 납품해서 수익을 낼 수 있다면?’ ‘사람들이 노래를 듣는 방식 자체가 달라진다면?’ 이런 질문들을 던지며, 점점 더 큰 그림을 그려갔다.
물론 현실은 언제나 그보다 작고 복잡하지만, 그 상상 덕분에 버틸 수 있었다.
내 머릿속에서만이라도 이 서비스가 거대한 세계를 움직일 수 있다는 믿음이 있었기에, 나는 1년 반이라는 시간을 이 일에 붙들려 있을 수 있었다.
기능 하나하나에 집착하고 자꾸 바꿨던 이유도, 그 상상 속 세계에 조금이라도 더 가까워지고 싶었기 때문이다.
그 과정에서 실현되지 못한 아이디어들이 더 많았지만, 아이디어의 풍부함 자체가 나를 이끌어준 원동력이었다.
3) 핵심이 있어야 한다
작은 차이라도, “왜?”에 대한 답이 명확하면 누군가는 알아본다.
흑백요리사에서는 ‘킥’이라는 표현을 쓴다. 음식에서 느껴지는, 셰프가 의도한 강렬한 한 방. 단순히 맛있기만 한 게 아니라, 딱 먹었을 때 “아, 이건 뭔가 다르다”는 느낌을 주는 요소다. 서비스를 만들 때도 똑같다고 생각한다. 아무리 잘 만들어도, 이미 있는 대기업 서비스랑 똑같은 구조에 퀄리티만 떨어진다면 사람들은 돌아보지 않는다. 킥이 없는 제품은 기억에도 남지 않는다.
나한테 있어서 ‘킥’은 명확했다. 지니어스(Genius)처럼 가사 하나하나에 주석을 달 수 있는 구조, 거기에 더해 한국어로 제공된다는 점이었다. 단순히 콘텐츠를 모으는 게 아니라, 사람들이 그 위에 이야기를 덧붙이고, 서로의 해석을 공유할 수 있는 위키 기반의 시스템. 특히 그 정보들이 한국어로 된다는 점은, 나에겐 꽤 중요한 포인트였다. 영어권엔 이미 정리돼 있는 해석들이, 한국어로는 거의 없었고, 그 공백이 너무 크게 느껴졌다. 나는 그 빈틈을 메우고 싶었다. 그것이 내가 이 서비스를 만들며 끝까지 놓지 않았던 핵심이었고, 결국 내가 디깅뮤직을 만들어야 할 이유이기도 했다.
4) 그러고나서는, 핵심만 남기고 최대한 단순화시켜야 한다.
실제 유저가 없으면, 모든 건 그냥 추측일 뿐이다.
앞서 말했듯이, 기획 초반엔 ‘세계를 얼마나 넓힐 수 있을까’를 상상하며 아이디어를 부풀려야 한다. 하지만 그 뒤엔 반드시 남은 것들을 하나씩 걷어내야 한다. 상상은 풍성해야 하지만, 구현은 날렵해야 한다.
나도 처음엔 모든 게 사용자에 의해 자동으로 굴러가는 자율 시스템을 꿈꿨다. 사용자들이 문서를 고치면 다른 사용자들이 검토하고, 포인트를 쌓아가며 자율적으로 품질을 유지하고, 충돌이나 훼손도 알아서 처리되는 거대한 유기체. 하지만 그런 이상적인 상상은, 현실 앞에선 부질없을 때가 많다.
예를 들어보자.
- (1) 사용자 자정 시스템
- 생각: 대형 위키처럼 사용자끼리 토론하고 승인하는 구조를 만들자 → 포인트로 권한을 차등 부여하자 → 포인트 시스템 설계만 해도 최소 2주.
- 현실: 하루에 문서 10개 수정되면 많이 되는 날이다. 승인이고 뭐고 필요 없다.
- (2) 동시 편집 충돌 방지 시스템
- 생각: 두 명이 동시에 같은 문서를 수정하면 충돌나니까 '수정 중' 상태를 두자. 시간 제한도 걸자. 자동 저장도 해야겠네.
- 현실: 하루에 문서 하나도 안 겹친다. 그냥 걱정이었다.
- (3) 이미지 최적화 시스템
- 생각: 이미지가 너무 크면 로딩 느려지고 비용도 올라간다. 압축 알고리즘 넣자.
- 현실: 하루 방문자 5명. 서버는 놀고 있다. 그냥 보여주는 대로 써도 충분하다.
- (4) 악성 유저 대비 시스템
- 생각: 문서를 막 훼손하면 어떡하지? 검토 → 승인 → 반려 시스템을 넣자.
- 현실: 편집 자체가 귀한데, 그런 일은 일어나지도 않는다.
- (5) 빈 검색 결과 처리
- 생각: 검색했는데 없으면 생성 요청 기능도 넣자.
- 현실: 어차피 검색하는 유저도 거의 없다.
이런 식으로, 실제로 발생하지도 않을 문제들을 미리 막으려고 너무 많은 리소스를 쓰는 건 오히려 진행을 더디게 만든다. 결국 중요한 건, 지금 당장 가장 필요한 기능만 남기고 나머지는 모두 버리는 일이다. 단순화는 포기나 축소가 아니라, 진짜 중요한 것에만 집중하기 위한 선택이었다.
5) 아이디어를 막 말하고 다녀도 어차피 안 뺏어간다.
누가 먼저 생각했는지는 중요하지 않다. 누가 끝까지 했는지가 중요하다.
처음엔 내 아이디어가 정말 특별하고, 누가 들으면 당장 훔쳐갈지도 모른다고 생각했다. 그래서 왠지 모르게 말을 아끼게 되고, 이야기할 때도 조심조심했다. 누구한테 말했을 땐 “괜히 말한 거 아닌가...” 하고 한참을 전전긍긍하기도 했다.
그런데 시간이 지나고 보니, 그건 정말 쓸데없는 걱정이었다. 대부분의 사람은 내가 무슨 아이디어를 말하든 별로 관심이 없다. 더 정확히 말하면, 관심은 있어도 그것 때문에 실제로 움직이는 사람은 거의 없다. 기획이든 개발이든, 결국 실행하고 지속하는 데에는 엄청난 에너지와 시간이 필요하기 때문이다. 말만 듣고 그걸 따라 하는 일은 드물다.
그리고 무엇보다, 처음에 떠올린 아이디어는 거의 그대로 가지 않는다. 방향도 바뀌고, 형태도 바뀌고, 심지어 문제의 본질조차 다시 보게 되는 경우가 많다. 내가 디깅뮤직을 처음 구상했을 때와 지금 오픈한 서비스는, 구조도 기능도 핵심 메시지도 꽤 달라져 있다. 결국 아이디어는 말하는 것보다 계속 붙잡고 수정하고 실행하는 사람에게 남는 것이다.
그러니 지금은 오히려 아이디어를 많이 공유하고, 말하고, 피드백을 받으면서 정제해가는 게 훨씬 낫다고 생각한다. 말한다고 무언가를 잃는 게 아니라, 말하면서 더 얻을 수 있다는 걸 이제야 실감하고 있다.
그래서 이제는 이렇게 생각한다. 아이디어만 있는 사람은 사실 별거 아니다. 아무리 대단한 아이디어처럼 보여도, 실제로 만들고, 버티고, 계속 고치면서 현실에 맞춰가는 사람만이 그걸 ‘자기 것’으로 만든다.
누군가 나랑 비슷한 아이디어를 떠올렸다고 해도, 거의 비슷한 걸 먼저 시작해보고 망했다고 해도, 괜찮다. 똑같은 걸 시작해도 좋다. 결국 결과는 다를 수밖에 없으니까. 같은 출발선에서 출발해도 누구는 중간에 그만두고, 누구는 딴 데로 가고, 누구는 완전히 다른 모양으로 만들어낸다. 아이디어는 경쟁이 아니라, 실행이 진짜 승부다.
6) 아직 안 생긴 문제를 찾아서 고치는 것보다 문제가 발생하고 수습하는 게 낫다.
유저는 최고의 디버깅 도구다.
초반에는 사이트 전체를 혼자 점검하고, 일어날 수 있는 모든 문제를 미리 막으려고 애썼다. 여기저기 구멍이 있을까 봐 하나하나 들여다보고, 발생 가능성 높은 시나리오를 상상하면서 개발에 임했다. 나름 꼼꼼하다고 생각했고, 실제로도 한동안은 큰 문제가 없었다.
그런데 지나고 나서 보니, 이 방식은 효율도 낮고 동력도 약하다.
우선, 문제를 미리 찾는 것 자체가 에너지를 많이 잡아먹는다. 개발이 복잡해질수록 구멍은 무한히 많아지고, 그걸 다 막으려면 끝이 없다.
그리고 중요한 건, 모든 문제가 같은 무게로 다뤄지지 않는다는 사실이다. 어떤 문제는 수동으로 고쳐도 되고, 어떤 문제는 아예 원천 봉쇄가 필요하다. 근데 막상 터지기 전에는 그 중요도를 가늠하기가 어렵다. 결과적으로 엉뚱한 데 시간 쓰는 경우가 생긴다.
게다가 아직 문제가 발생하지 않았기 때문에 긴박감이 없다. 여유 있게 생각하게 되고, 느긋하게 개발하게 된다. 속도도 느려지고, 집중도 흐려진다.
그러다 서포터즈 5명을 운영하면서 완전히 달라졌다.
누군가 실제로 서비스를 쓰기 시작하니까, 진짜 문제가 쏟아지기 시작했다. 그때부터는 정신없이 고치게 된다. 긴장감도 있고, 문제 하나하나가 명확하게 드러나고, 빨리 해결해야 하니까 개발 속도도 훨씬 빨라졌다. 버그의 80%는 그때 잡혔다.
이후에 일반 유저들이 조금씩 들어오면서 나머지 15%까지 거의 다 해결됐다. 내가 찾아내려 했던 문제들은 결국 사람들이 써야만 드러났고, 그때야 비로소 진짜 해결 가능한 상태가 됐다.
무엇보다 중요한 건, 문제가 생겨도 감당 가능한 규모에서만 터지게 해야 한다는 것이다.
초기에 유저가 많았다면 아마 수습도 못하고 다 떠났을 거다. 그런데 다행히도, 초기엔 규모가 작았고, 문제를 겪은 일부 유저에겐 공지와 후속 조치로 충분히 해결이 가능했다. 이건 단순한 실수의 용인 범위가 아니라, 전략적인 테스트 환경이었다고 지금은 생각한다.
7) 레퍼런스가 중요하다.
막막할 땐, ‘이거랑 비슷한 게 다른 분야엔 없을까?’부터 떠올려라.
새로운 걸 만든다고 해서, 세상에 없던 걸 무에서 창조해야 하는 건 아니다. 오히려 진짜 창의성은, 기존의 것들 사이에서 뜻밖의 연결고리를 발견하는 데서 나오는 경우가 많다. 어떤 레퍼런스를 참고하느냐, 그리고 그걸 얼마나 의외의 방식으로 응용하느냐가 핵심이다.
예를 들어, 디깅뮤직의 ‘프로필 음반 선택 화면’은 게임 속 캐릭터 선택창에서 아이디어를 가져왔다. 스트리밍 서비스나 음악 앱이 아니라, 격투 게임을 떠올린 것이다. 그쪽이 훨씬 더 직관적이고, 사람들의 선택 욕구를 자극하는 UI였기 때문이다. 처음엔 나도 머리를 싸매고 직접 새로운 UX를 만들어보려고 했는데, 결국엔 완전히 다른 분야를 떠올리는 게 훨씬 빠르고 효과적이었다.
이건 나만의 경험이 아니었다. 최근에 본 스페이스웨이비라는 모듈러 하우스 스타트업 대표도 비슷한 이야기를 했다. 모듈러 하우스는 아직 국내에 정형화된 시장도 없고, 누구나 처음 하는 분야다. 그래서 어떤 식으로 공장을 구해야 할지 막막했던 상황에서, 이 대표는 요트 공장을 떠올렸다. 모듈러 하우스처럼 거대한 물건을 만드는 곳, 그리고 조립된 상태로 이동이 어려운 구조물이라는 점에서 요트와 닮았기 때문이다. 실제로 요트 공장이 밀집된 지역을 찾아가서 문제를 해결했다고 한다.
이처럼 레퍼런스를 창의적으로 가져오려면, 오히려 더 넓게 보고, 전혀 상관없어 보이는 분야까지도 눈여겨봐야 한다. 창업가들의 책이나 인터뷰, 다큐멘터리를 보면 이런 사고방식이 얼마나 중요하게 다뤄지는지 알 수 있다. 결국 창의성은 혼자 머리 싸매는 게 아니라, 얼마나 잘 참고하고, 얼마나 잘 연결하느냐의 문제다.
8) 자동화는 가장 마지막 단계
“하루에 두 명 들어온다고 생각해봐. 그러면 당장 뭘 지워야 할지 보일 거야.”
처음 기획할 땐 모든 게 혼자 척척 굴러가는 구조를 상상하게 된다. 사람이 개입하지 않아도 돌아가는 시스템.
기획서를 쓸 때는 그런 자동화된 플로우가 매끄럽고 예뻐 보이니까. 마치 ‘이 시스템만 잘 만들면 나는 뒤에서 지켜보기만 하면 된다’는 환상이 생긴다.
하지만 실제로는 그렇지 않다. 대부분의 시스템은 천천히, 아주 서서히 사람 손을 떠난다.
그리고 여기서 말하는 자동화는 꼭 거창하거나 인공지능이 붙은 기술만을 말하는 게 아니다. 그런 수준까지 가지 않아도, 우리가 너무 빨리 자동화하려 드는 일들이 너무 많다.
예를 들어:
- 수정이 일어나면 유저에게 알림을 자동으로 보내야 할까?
그냥 내가 직접 메세지 보내면 된다. - 추천 리뷰는 유저들이 추천해서, 좋아요 순으로 정렬하고…?
아니다. 그냥 운영자가 일주일에 한 번 골라주면 된다.
초기에는 이게 훨씬 낫다. 정교한 시스템은 나중 문제고, 지금 당장은 사람이 하는 게 빠르고 정확하다.
생각나는 일화가 있다. 배달의민족은 초창기에 앱으로 주문이 들어오면, 운영자가 직접 가게에 전화를 걸어 주문을 넣었다.
리멤버라는 명함 앱도 초반에는 명함을 자동 인식한 게 아니라, 사람이 직접 내용을 읽고 입력했다.
사람이 하는 게 더 빠르고 정확하다는 걸, 그들도 알고 있었던 거다.
결국 자동화는 편해지기 위한 게 아니라, 필요한 반복이 충분히 쌓였을 때 도입하는 효율화 도구다.
그전까지는 그냥 손으로 하면 된다. 그게 더 정확하고, 더 빠르다.
그럼에도 불구하고 자동화시켜야 하는 게 있다. 뭐,, 좋아요 버튼을 눌렀을 때 당장 달려야 하긴 하니!
이것에 대한 기준은 이거다. 아예 하루에 두명 들어온다고 생각하고 만들어야 한다.
9) 창의적으로 문제를 계속 일으켜야 한다
일을 굴리는 가장 확실한 방법은, 약속을 먼저 하는 것이다.
일이 굴러가게 만들고 싶다면, 적당한 난이도의 문제를 계속해서 만들어야 한다.
기존에 주어진 문제를 푸는 것도 중요하지만, 문제 자체를 만드는 창의성이 진짜 중요한 순간이 많다.
그 문제는 너무 어렵지 않되, 딱 ‘부담’을 느끼고 ‘의욕’이 생길 만큼의 난이도여야 한다.
나도 그런 식으로 계속 압박을 만들어왔다.
포인트 시스템을 기획하기도 전에, 서포터즈 팀 분들에게 “내일모레부터 포인트 시스템이 도입된다”고 먼저 공지했다. 심지어 줌 회의로 공식적으로 발표까지 했다. 말도 안 되는 일정이었고, 당연히 실제 개발은 이틀이 지연됐다. 하지만 아무 일도 일어나지 않았다. 내가 사정을 말씀드렸고, 다들 이해해주셨다. 중요한 건 ‘그 일정이 있었기 때문에’ 결국 그 시스템이 만들어졌다는 점이다.
사람은 압박이 없으면 일을 안 한다. 특히 혼자 하거나, 누가 시키지 않는 일을 할 땐 더 그렇다. 그래서 일정이든 기능이든 작은 위기를 인위적으로 만드는 건 필요하다.
이건 일론 머스크도 비슷하다. 괜히 스페이스X 일정이나 테슬라 신제품 발표일을 터무니없이 빠듯하게 잡고, 공공연하게 외부에 선포하는 게 아니다.
내가 흥미롭게 읽었던 일화 중 하나는, 발사조차 불가능했던 스타쉽을 미리 조립해서 전시하라고 시켰던 에피소드였다. 당연히 완성도는 낮았지만, 트위터에 “며칠 안에 조립해 공개하겠다”고 말해버리면서 모두를 긴장시키고, 그 안에서 실질적인 진도가 나가게 만든다.
이런 식으로 보면, 문제는 생기기를 기다리는 게 아니라 만들어내야 할 대상이 된다. 그게 사람을 움직이고, 서비스를 한 걸음씩 나아가게 만든다.
비슷한 경험이 또 있다. 마케팅을 본격적으로 시작하겠다고 인플루언서 분들께 메일을 보내고, 회의 일정을 먼저 잡은 다음에야 겨우 홈페이지 메인을 제대로 완성했다.
정말 아이러니하게도, “이제 보여줘야 한다”는 외부 압박이 생기니까 작업 속도가 말도 안 되게 붙었다. 그 전까진 계속 ‘조금 더 다듬어야지’, ‘이거 괜찮은가?’ 고민만 하다가 진도가 안 나갔는데, 외부 일정을 박아두자 정신이 번쩍 들면서 몰입이 시작됐다.
이런 방식은 위험해 보이지만, 적당한 긴장감을 만들고, 실제로 움직이게 만드는 데 가장 효과적인 방법이었다. 문제를 기다리는 게 아니라, 일부러 만들어내는 것.
10) 좁은 보폭으로 빠르게 움직일 것. 문제를 앞서가지는 말 것. 문제를 뒤따라가야 한다.
처음엔 뭔가 멀리 보고, 큰 그림을 미리 다 그려놓고, 가능성 있는 모든 시나리오에 대비해서 움직이려고 했다. 그렇게 하면 ‘완벽한 서비스’를 만들 수 있을 줄 알았다. 그런데 그렇게 앞서가려는 태도는, 결국 시간과 에너지를 낭비하게 만들었다.
이제는 그렇게 생각하지 않는다. 보폭은 좁게, 속도는 빠르게.
멀리 보고 가려 하지 말고, 지금 한 걸음만 잘 디딜 것. 그리고 문제를 앞서서 예측하기보다는, 문제가 생기면 바로 뒤쫓아가서 해결하는 방식이 훨씬 효율적이었다. 그런 식으로 한 걸음, 한 걸음 빠르게 움직이면, 어느새 꽤 먼 곳까지 와 있는 걸 느낄 수 있다.
‘앞서간다’는 말은 멋있어 보이지만, 정작 현장에서는 현실을 비껴가게 만들기도 한다. 문제를 너무 일찍 예측하려다 보면, 실제로 생기지도 않을 일에 대비하느라 정작 중요한 걸 놓치기 쉽다. 반면 문제를 ‘뒤따라간다’는 건 현실에 발을 딛고 있다는 뜻이다. 지금 눈앞의 상황을 정확히 보면서 빠르게 대응하고, 계속 나아가는 것. 그게 내가 느낀 가장 현실적인 속도였다.
그래서 괜히 린스타트업을 하라는 게 아니다.
처음부터 완벽하게 만들겠다고 큰 보폭으로 느릿하게 가는 것보다, 좁은 보폭으로 빠르게 움직이며 문제를 따라가는 방식이 훨씬 현실적이고 효과적이다.
무엇보다도, 이 방식은 동기부여 측면에서도 훨씬 낫다.
혼자 머릿속으로만 문제를 상상하면서 개발하면 점점 동력이 떨어지지만, 실제 유저 반응을 보면서 맞춰가면 작은 개선에도 반응이 오고, 그게 곧 다음 스텝으로 이어진다.
그리고 시장 반응을 핏하게 맞춰간다는 점에서도 강력하다.
애초에 기획한 대로만 가다 보면 괴리가 생기기 쉬운데, 사용자들이 겪는 진짜 문제를 따라가다 보면 방향도 자연스럽게 조정된다.
결국 린하게, 작게, 빠르게 움직이는 방식이야말로 진짜 현실적인 성장 전략이라는 걸 몸으로 배웠다.
앞으로도 할 게 많이 남았다.
마케팅도 해야하고, 컨텐츠도 채워야 하고, 기능도 개선할 게 많다.
'프로젝트 > 디깅 - 종합음악플랫폼' 카테고리의 다른 글
| [디깅 뮤직 25편] UI, UX, DB개선 (1) | 2025.06.30 |
|---|---|
| [디깅 뮤직 24편] 구글 애널리틱스 (0) | 2025.06.30 |
| [디깅 뮤직 22편] 사이트 오픈 (1) | 2025.06.19 |
| [디깅 뮤직 21편] 문제 해결보다 먼저 해야 할 생각 전환 (1) | 2025.06.11 |
| [디깅 뮤직 20편] 서비스 출시 임박 (2) | 2025.06.08 |