들어가기 앞서...
홍보 링크들.
1Day 1Streak
매일 하나의 챌린지로 꾸준함을 기록하는 1Day 1Streak
1day1streak.com
1D1S - Google Play 앱
하루 하나를 기록하고, 챌린지와 스트릭으로 꾸준한 습관을 만들어 보세요.
play.google.com
1D1S 앱 - App Store
App Store에서 Noh Hyunkeun의 1D1S 앱을 다운로드하십시오. 스크린샷, 평가 및 리뷰, 사용자 팁 및 1D1S 앱과 비슷한 다른 앱을 볼 수 있습니다.
apps.apple.com
개요
길었던 개발이 거의 끝났다.
정확히 말하면 마지막 큰 목표였던 채팅 기능까지 배포가 끝났다. 물론 끝났다고 말하기가 조금 애매하긴 하다. 그래도 처음 머릿속에 그렸던 핵심 기능을 기준으로 보면, 1D1S는 이제 어느 정도 서비스라고 부를 수 있는 상태까지 왔다.
이 글은 잘 풀린 프로젝트에 대한 회고가 아니다. 오히려 첫 런칭만 놓고 보면 실패에 가깝다. 런칭한 지 며칠 지나지 않았고 모집 기간도 남아 있지만, 참여자 수는 생각보다 적다. 홍보를 크게 한 것도 아니고, 앱이 없는 상태에서 웹앱만으로 시작한 것도 한계가 컸다.
그럼에도 회고를 남기려는 이유는, 이 프로젝트가 나에게 꽤 오래된 숙제 같은 것이었기 때문이다. 1D1S는 갑자기 나온 서비스가 아니다. 2023년에 운영했던 동아리 활동을 서비스로 만들고 싶다는 생각에서 시작됐다. 당시에는 17명 정도로 시작했던 모임이 입소문을 타고 40명, 50명 이상까지 늘어났다. 나는 내성적인 편인데, 그때만큼은 그런 성격을 잊을 정도로 동아리 운영이 재밌었다.
그런데 그 즐거움은 오래 이어지지 못했다. 취업 준비도 있었고, 연이은 앱 개발 실패도 있었다. 결국 시즌3까지만 운영하고 시즌4는 무기한 연기됐다. 언젠가 다시 해야지, 언젠가 서비스로 만들어야지 생각했지만, 그 언젠가는 생각보다 오래 오지 않았다.
동아리에서 서비스로
처음 1D1S는 서비스라기보다 모임에 가까웠다. 매일 무언가를 하고, 서로 인증하고, 운영진이 관리해주는 방식이었다. 지금 생각해보면 꽤 손이 많이 가는 구조였다. 운영진이 있긴 했지만, 사실상 모든 결정과 책임과 비용은 내가 떠안고 있었다. 운영진들은 운영을 같이 설계하는 사람이라기보다는, 인증을 확인하고 문의를 받아주는 상담원에 가까운 역할을 했다.
당시에는 그게 크게 문제라고 느껴지지 않았다. 모임 규모가 엄청 크지도 않았고(활동 인원 50명에 비활동 인원까지 합치면 70명 가까이 됐다), 대부분 지인이거나 지인의 지인이었다. 운영이 조금 불편해도 관계의 힘으로 굴러갔다. 지인들이 있는 곳이다 보니 이상한 행동을 하는 사람도 없고, 서로가 서로의 시선을 의식할 수 밖에 없는 그런 관계의 힘이 컸다. 누군가가 불편한 점을 말해주면 그때그때 고치면 됐고, 운영진이 수작업으로 메워주면 됐다.
하지만 이걸 서비스로 만들려고 하니 이야기가 달라졌다. 지인이 아닌 사람을 데려오려면 훨씬 더 명확해야 했다. 무엇을 하는 서비스인지, 왜 해야 하는지, 어떻게 참여하는지, 참여하면 무엇이 좋은지 바로 보여줘야 했다. 이전처럼 설명을 길게 하고, 운영진이 옆에서 도와주고, 친밀감과 감시로 불편함을 덮는 방식은 통하지 않는다.
웹 개발을 배우면서 이 아이디어를 다시 꺼내게 됐다. 앱으로만 만들려고 했을 때는 배포가 늘 부담이었다. 어느 정도 만들었다고 해도 앱스토어 구독비와 심사, 배포 과정이 계속 걸렸다. 그래서 웹앱을 만들고, 나중에 Flutter로 shell을 씌워 웹, 안드로이드, iOS를 모두 커버하는 방향이 좋겠다고 생각했다.
지금 와서 보면 이 판단은 절반은 맞고 절반은 틀렸다. 개발자 입장에서는 분명 효율적이었다. 웹으로 만들면 배포가 쉽고, 수정도 빠르고, 접근도 간단하다. 하지만 사용자 입장에서 웹앱은 그렇게 익숙한 개념이 아니었다. 이에 대한 이야기는 조금 더 뒤에 하겠다.
개발은 끝났지만, 운영은 끝나지 않았다
AI의 등장도 개발 속도를 많이 올려줬다. 예전 같으면 오래 걸렸을 화면 작업이나 반복적인 수정 작업을 훨씬 빠르게 처리할 수 있었다. 덕분에 멈춰 있던 프로젝트를 다시 움직일 수 있었다. 팀을 이끌고 다시 개발을 시작했고, 퇴근 후에는 UI를 개선하고, 백엔드 개발 내용들을 정리해서 전달하면서 조금씩 서비스를 만들어갔다.
하지만 순탄하게만 흘러가지는 않았다. 운영 능력이 부족했던 탓도 있고, 내가 백엔드 지식이 부족했던 탓도 있었다. 프론트엔드 쪽은 내가 부족해도 팀장으로 데려온 친구가 잘 메워줬다. 반면 백엔드 쪽은 그런 멘토 역할을 해줄 사람이 부족했다. 나 역시 백엔드 관련 지식이 충분하지 않았기 때문에 온전히 백엔드 팀에 의존할 수밖에 없었고, 큰 문제가 생겼을 때 해결 방법이 없었다.
결국 이곳저곳 자문을 구하다가 구조를 갈아엎게 됐다. 그 과정에서 출시가 많이 늦어졌다. 지금 돌아보면 기술적인 문제라기보다, 내가 팀을 운영하는 능력이 부족했던 문제에 가까웠다. 팀원들에게 무엇을 맡길지, 어떤 기준으로 검증할지, 내가 어디까지 알고 있어야 하는지에 대한 감이 부족했다.
또 하나의 문제는 완벽주의였다. 먼저 출시하고 개발을 이어갔어야 하는데, 어느 정도 완성되고 나서 출시해야 한다는 생각이 계속 있었다. 그런데 그 "어느 정도"의 기준이 무엇이냐고 물으면 나조차도 명확히 답하지 못했다. 이 기능도 있으면 좋을 것 같고, 저 화면도 더 다듬어야 할 것 같고, 정책도 더 정리해야 할 것 같았다.
그렇게 기획은 여러 번 바뀌었고, 개발도 계속 늘어졌다. 팀원들의 피로감도 쌓였을 것이다. 나는 더 좋은 서비스를 만들고 싶다는 마음이었지만, 팀 입장에서는 끝이 보이지 않는 프로젝트처럼 느껴졌을 가능성이 높다. 이 부분은 꽤 아쉽다. 좋은 의도였다고 해서 좋은 운영이 되는 것은 아니었다.
출시했지만, 기대한 반응은 아니었다
그래도 손에서 놓지는 않았다. 퇴근 후에 UI를 고치고, 필요한 내용을 정리하고, 기능을 하나씩 붙였다. 그렇게 공식 챌린지까지 개발이 완료됐고, 결국 배포까지 했다. 이 지점만 놓고 보면 분명 의미가 있다. 몇 년 동안 머릿속에만 있던 것을 실제 서비스로 만들었기 때문이다.
하지만 결과가 좋았냐고 물으면 아니라고 답해야 할 것 같다.
2023년에 같이 즐겁게 했던 사람들은 이제 대부분 각자의 삶을 살고 있다. 그때의 기억을 가지고 "우리 그때 재밌었잖아. 다시 하자"라고 말해도, 사람들은 예전의 상태로 돌아가지 않는다. 당시에는 대학생이었고, 시간이 있었고, 관계도 가까웠다. 지금은 대부분 대학 시절이 끝났고, 각자 해야 할 일이 생겼다. 나 역시 그때와는 많이 달라졌다.
출시 후 참여자 수는 기대보다 적었다. 모집 기간이 아직 남아 있긴 하지만, 기존 인원들이 이렇게까지 참여하지 않을 거라고는 생각하지 못했다. 물론 홍보도 미미했다. 에브리타임과 내가 속해 있는 커뮤니티 정도에만 공유했고, 겹지인이 많다 보니 사실상 같은 사람들에게 여러 번 보여준 것에 가까웠다.
인스타 광고를 태우려고도 했지만, 앱이 없는 문제가 걸렸다. 광고를 보고 들어온 사람이 웹앱을 설치해야 하는 구조는 생각보다 큰 장벽이다. 개발자에게는 웹앱이 익숙할 수 있지만, IT 직군이 아닌 사람들에게는 그렇지 않다. 지인들에게 앱을 권유했을 때 가장 많이 들은 말도 결국 이거였다.
"앱으로는 없어?"
이 질문을 여러 번 듣고 나서야 앱이 없다는 것이 꽤 큰 실수였다는 걸 인정하게 됐다. 웹으로 하면 배포가 편하다는 생각은 어디까지나 내 편의였다. 사용자 입장에서 편한 것은 앱스토어에서 앱을 내려받는 것이다. 내가 편한 방식과 사용자가 편한 방식은 다르다. 이걸 너무 늦게 체감했다.
앱 개발
너무 늦게 체감했다고 엎질러진 물이라는 것은 아니다. 늦었지만 만들면 되는 것이다. 그래서 바로 만들기를 시작했다. 처음에는 생각했던대로 하이브리드 앱으로 개발을 진행했다. Flutter Shell에 내부는 웹앱으로 개발을 했다. 하지만 브릿지 정의나 인증 오류와 같은 문제들이 계속해서 발생하고, 안드로이드에서는 앱이 전반적으로 버벅거려 사용하기가 어려울 정도였다. 안드로이드는 웹뷰를 여러개 구동하면 GPU에 부하가 걸려 스크롤 렉이 걸린다는 사실을 나중에야 알았다.
심사를 받지 않아도 배포를 바로바로 할 수 있고, 웹 개발로 앱도 같이 개발이 된다는 점 외에는 장점이 없는 상황이었는데, 웹 개발로 앱도 같이 개발이 된다는 것도 미미한 장점이 됐다. 기초와 구조를 짜놓으면 나머지는 AI가 해주기 때문에 예전처럼 오래걸릴 일이 없어진 것이었다.
결국에 장점은 심사를 받지 않아도 배포가 빠르다는 것과 사용자에게 업데이트를 강제하거나 유도하지 않아도 자동으로 업데이트가 된다는게 장점인데 그 장점 하나만 보고 개발을 계속 진행하기에는 인증 버그나 웹뷰 버그가 계속해서 속출했다.
그래서 결국 하이브리드 앱 개발은 포기하고 순수 Flutter로 완전히 마이그레이션 했다. 1.0 버전은 하이브리드 앱으로 출시를 한 다음, 1.1.0 개발 때 Flutter로 완전 마이그레이션을 진행, 1.1.1때 기존에 있던 브릿지나 하이브리드 앱에 맞춰져 있던 구조를 전면 리팩토링 하는 과정을 거쳤다. 사용자는 많이 없긴 하지만 대부분의 사용자가 앱이 많이 빨라졌다는 평을 했다.
처음에는 하이브리드 앱에 대한 기대가 있었는데, 역시나 코어기능은 네이티브로 가는게 맞다는 생각이다. 거의 매일매일 변화하는 지면이 있는게 아니거나, 개발자가 적고 유지보수할 인원이 적은게 아니라면 이제는 하이브리드 앱은 굳이라는 생각이 든다. 개발 속도를 따지기엔 AI가 너무나도 빠르기 때문이다. 심지어 리액트 네이티브면 코드 푸쉬로 바로 배포도 가능하다. 이번 경험을 통해 역시 모든 상황에서 최고인 개발 스택이란 것은 존재하지 않고 상황에 맞게 가져간 개발 스택이 최고라는것을 다시 한 번 느꼈다.
이런 저런 시행착오 끝에 앱 개발도 마치고 출시를 했다. 하지만 문제는 그렇다고 웹에 비해 좋은 반응인 것은 아니었다.
사용자를 배려하지 않은 설명서
“앱은 왜 없어?” 하던 사람들은 결국에 깔지 않았다.
그들이 말을 바꿨다고 말하려는 것이 아니다. 단순히 앱은 왜 없냐고 물어본거지 앱이 있다고 깔겠다고 한 건 아니다. 나도 앱 개발을 하면서 그들이 순순히 깔 거라고 생각하진 않았다. 결국 앱을 깔기 위해서는 동기가 필요한데 내가 그 동기를 제대로 채워줬는가가 중요한 부분이기 때문이다.
하지만 왜 기대만큼 반응이 없었을까를 더 생각해봤다. 원하던 앱도 있고, 위젯도 만들었는데도 깔 이유가 왜 없었을까. 짚이는 이유는 여러가지였다. 그 중 하나는 UI/UX였다. UI/UX가 훌륭한가를 생각해보면 그렇지 않았다. 전달력이 충분했냐고 물어봐도 아니었다. 과거의 1D1S는 "매일 무언가를 하는 모임"이었다. 1 Day 1 Something이라는 의미가 중요했다. 스트릭의 개념은 있었지만, 스트릭 자체가 핵심은 아니었다. 핵심은 매일 무언가를 한다는 것이었다.
그런데 서비스 이름을 다듬는 과정에서 1 Day 1 Streak 쪽으로 의미가 이동했다. 이름이 더 그럴듯해졌는지는 모르겠지만, "매일 무언가를 한다"는 원래의 직관은 살짝 퇴색됐다. 그리고 여전히 사용자 입장에서는 1D1S가 뭔데? 라는 의문이 먼저 생길 수밖에 없다. 저걸 다 풀어서 말하는게 아니라 줄여서 1D1S, 일디일스라고 말했으니 말이다.
지금 와서 보면 나는 사용자를 전혀 배려하지 않은 설명서를 들고 다니면서 사용해달라고 빈 것에 가깝다. 제품을 살 때 사용 설명서를 꼼꼼히 읽는 사람은 많지 않다. 먼저 제품이 무엇인지, 왜 필요한지, 나에게 어떤 이득이 있는지가 보여야 한다. 그런데 나는 이름과 기능과 정책을 설명하면 사람들이 알아서 이해해줄 거라고 생각했다.
노션으로 운영하던 시점부터 사용성은 사실 좋지 않았다. 그때는 지인들이었고, 친했고, 운영진들이 자동화 봇처럼 중간에서 도와줬기 때문에 그나마 굴러갔다. 지금은 다르다. 생판 모르는 사람을 데려와야 한다. 그 사람이 굳이 참여하려면 더 큰 보상이나 더 명확한 동기가 있어야 한다.
상위 챌린저 5명에게 상품을 지급하는 방식도 큰 미끼가 되지 못했다. 상위 5명 안에 들려면 경쟁해야 하고, 꽤 열심히 해야 한다. 그런데 사용자 입장에서는 왜 그래야 하지? 라는 생각이 들 수 있다. 오히려 완주만 해도 보상을 주는 방식이 더 맞을지도 모른다. 문제는 자본이다. 현재는 광고도 어렵고, 구독제도 어렵다. 신분상 어쩔 수 없는 부분도 있고, 개인적으로 매달 5만 원에서 10만 원씩 계속 넣는 것도 생각보다 쉽지 않다.
결국 서비스는 의지만으로 굴러가지 않는다. 사용자에게 줄 수 있는 명확한 가치와 보상이 있어야 한다. 그리고 그 가치를 설명서가 아니라 경험으로 보여줘야 한다.
그리고 두 번째 이유는 서비스의 핵심 가치에 대한 망각이다. 필자는 지금 여러개의 사이드 프로젝트를 하고 있다. 사이드 프로젝트는 전에 올렸던 글에서도 말했다시피 하나의 취미처럼 하고 있다. 공책 게임을 만드는 감각이 이 다수의 사이드프로젝트를 돌리는 원동력에 대한 가장 정확한 설명이다. 그런데 그중 일부는 완전히 즐거움을 위해하는게 아니다. 조급함이다. 더 좋은 곳에서 일하고 싶은 조급함. 내 미래에 대한 조급함. 그런 조급함은 즐겁게 시작한 사이드프로젝트에도 번진다. 그러다보니 사이드프로젝트들 각각에 대한 핵심 가치를 잊게 된다. 결국에는 ‘내가 이걸 왜 하고 있더라?’ 하는 생각에 지배당한다.
스스로도 이걸 왜 하고 있는지 모르는데, 이 서비스를 사용하는 사용자가 알리는 만무하다. 운이 좋아서 소 뒷걸음질 치듯이 서비스를 사용하는 사용자들이 스스로 의미를 부여해서 사용할 수는 있겠지만, 그건 운의 영역이다. 그걸 기대해서는 안된다. 그리고 1D1S에는 그런 운이 적용되지 못했다.
이것저것 풀어서 쓰다보니 말이 길어졌는데 결국엔 기획자인 필자의 조급함 때문에 기획에 이 서비스에서 얻을 수 있는 가치가 제대로 녹여지지 못했고, 그 가치가 사용자에게 전달되지 못했다는 것이다. 필자가 원하는 가치는 하루 하나가 모여 큰 내가 되는 것. 매일 꾸준히 한 것이 모여 큰 전환점을 얻는 것인데 그런 가치가 이 서비스 어디에서 드러나는가? 통계에서의 임팩트도 없는데 매일 꾸준히 할 동기까지 없다는 것이다. 나는 다시 서비스의 핵심 가치에 대해 떠올리고 이를 더 잘 녹여내는 기획을 해야한다.
실패를 받아들이는 법
저번 챌린지에도 사람이 그렇게 많이 오진 않았지만, 다음 챌린지도 역시나 사람이 많이 오지 않을 가능성이 높다. 솔직히 말하면, 오지 말라고 막고 있는 것과 크게 다르지 않은 상태였다고 생각한다. 서비스가 무엇인지 바로 와닿지도 않고, 보상 구조도 강하지 않다. 사용자 편의성을 충분히 개선하지 않은 상태에서 사람들에게 와달라고 한 셈이다.
이 부분을 인정하는 것이 필요했다. 내가 편한 방식으로 만들고, 내가 이해하는 방식으로 설명하고, 내가 좋다고 생각하는 기능을 붙이는 것만으로는 부족하다. 이해도가 전혀 없는 사람의 입장에서 어떤 점이 불편한지 봐야 한다. 서비스에 애정이 없는 사람이 처음 들어왔을 때 무엇을 보고 나갈지, 무엇 때문에 참여할지 생각해야 한다.
이번 런칭은 실패에 가깝다고 보는 게 맞다. 서비스가 완전히 끝났다는 뜻은 아니지만, 적어도 내가 기대했던 방식으로는 전혀 굴러가지 않았다. 이건 받아들여야 한다.
모든 시도가 잘 될 수는 없다. 중요한 것은 실패를 빠르게 인정하고 개선하는 것이다. 이번에는 앱만으로 충분할 거라고 생각했지만 그렇지 않았다. 설명하면 이해할 거라고 생각했지만 그렇지 않았다. 과거의 즐거움이 현재의 참여로 이어질 거라고 생각했지만, 그것도 아니었다.
그래도 얻은 것은 크다. 적어도 이제는 무엇이 부족한지 조금 더 선명하게 보인다. 앱이 필요하고, 첫 화면에서 전달력이 더 좋아야 하고, 보상 구조를 다시 봐야 하고, 사용자가 굳이 참여해야 할 이유를 더 명확히 만들어야 한다.
마치며
1D1S는 오래 붙잡고 있던 프로젝트다. 그래서 더 잘하고 싶었고, 더 완성된 상태로 보여주고 싶었다. 하지만 그 마음 때문에 출시가 늦어졌고, 출시 후에는 사용자 관점이 부족했다는 사실을 마주하게 됐다.
그래도 후회만 남지는 않는다. 몇 년 동안 머릿속에 있던 것을 실제 서비스로 만들었고, 공식 챌린지까지 배포했다. 이건 분명 의미가 있다. 다만 출시했다는 것과 사용자가 쓰는 서비스가 됐다는 것은 다르다. 이번에는 그 차이를 꽤 크게 느꼈다.
웹앱이 앱을 대체할 것이라는 이야기는 계속 나온다. 하지만 적어도 지금은 앱이 가진 자리가 여전히 단단해 보인다. 하이브리드 웹앱은 많아질 수 있어도, 앱 그 자체는 쉽게 사라지지 않을 것 같다. 사용자는 개발자가 편한 방식을 쓰지 않는다. 자신에게 익숙하고 편한 방식을 쓴다.
이제 해야 할 일은 명확하다. 앱을 만들고, 첫 경험을 고치고, 설명이 아니라 경험으로 설득해야 한다. 그리고 실패를 너무 늦게 인정하지 않아야 한다. 이번 런칭은 잘 되지 않았다. 다만 그 덕분에 무엇을 고쳐야 하는지는 훨씬 선명해졌다.
'회고' 카테고리의 다른 글
| 2026 상반기 개발 회고 (0) | 2026.07.09 |
|---|---|
| 2025년 하반기 개발회고 (0) | 2026.01.01 |
| 2025년 상반기 개발회고 (2) | 2025.07.21 |
| 하지톤 회고 (0) | 2024.08.02 |
| 1D1S 시즌2 한 달 회고 (0) | 2024.02.02 |