퀘스트 | 이번주의 렛플의 퀘스트를 달성해보세요.

퀘스트참여와 보상 그리고 레벨업

프로덕트 출시 회고

지금, 나의 프로덕트를 소개해보세요!내 소중한 프로덕트를 대놓고 배너로 홍보하세요.
내 손 안의 특별한 여행북, 《트립북》 회고
🎵볼빨간사춘기의 ‘여행’을 들으면서 봐주시면 더욱 좋습니다 :)🎵사실, 방탄소년단(BTS)의 ‘피땀눈물’의 곡과 아주 잘 어울린답니다….안녕하세요, <이상한 나라의 트립북> 팀에서 🐥초보 PM을 맡은 은하수(본업은 마케터)입니다.<이상한 나라의 트립북> 팀은 개인 역량 향상의 포트폴리오 목적으로 모인 팀으로,기획, 디자인, iOS개발, AOS개발, 백엔드개발팀 포함해서 총 8명으로 구성된 팀입니다.(8명보다 더 많은 인원이 긴 시간동안 함께했지만 최종적으로 끝까지 진행한 분만 8명입니다.ㅎㅎ제가 거대한 팀을 만드려고 했던 건 결코 아닙니다..ㅠㅠ)(기획하다가 마음대로 안 돼서 슬플 때 그리던 낙서..(?))사실, 이 팀은 팀 빌딩 이후 초창기에 팀이 없어질 뻔 했었는데요.23년 3월에 기존 PM이 나가신 후에 기존 팀 인원의 ½ 정도가 빠졌고,제가 PM을 맡게 되었던 23년 3월부터 새로 팀 빌딩을 진행한 이후부터 운이 좋게 팀을 유지하면서 달려온 팀입니다.제가 PM을 맡는다고는 했지만 솔직히 진행 중간에 팀 해체할 가능성이 크다고 생각했었는데,이상하게 오래 유지가 되는 팀을 보면서 <이상한 나라의 트립북 팀>으로 팀 이름을 지었습니다.구성된 팀이 많다보니팀 특성에 맞게 팀별 이름도 지었습니다.<😨기획할 결심> 기획팀 + 마케팅 : 저(PM) / 1명<👑최종 보스> 디자인팀 : 1명<🏃돌격대장> 백엔드 개발팀 : 1명<🌱MZ 세대의 역습> 안드로이드 개발팀 : 3명<🍎전설의 포켓몬> iOS 개발팀 : 2명팀의 비하인드가 궁금하시면, 트립북 공식 SNS에 올라오는 트립북의 다음 이야기들을 기대해해주세요👀🤗 프로덕트 소개좀 해주세요~"기록되지 않는 건 기억되지 않는다."고 하는데요.내 손 안의 특별한 여행북(✈️+📙), ‘트립북’은시간이 지날수록 잊혀지는 ✈️여행기억을책📙 형태로 소중하게 기록하며내 손 안의 특별한 여행북을 만들어가는개인 여행 콘텐츠 아카이빙 서비스입니다.초기 트립북의 서비스 성격이바로 정해지지 않고여러모로 변화가 많았는데요…😢프로젝트가 장기화되면서빠르게 결과를 도출할 수 있는 방향으로‘여행기록 기능’에 집중한MVP로 출시하게 되었습니다.‘여행’은 새로운 나의 모습을발견하는 과정이며,‘기록’은 성장하기 위한강력한 도구라고 생각합니다.그래서 내 손 안의 특별한 여행북, 트립북은단순히 여행기록하는 것으로 끝나는 것이 아니라,사용자분들이 여행과 기록을 통해서내 안의 ‘새로운 가능성’을발견하는 특별한 여정을시작하기를 바라는 마음을 담았습니다.(이는, 저희 팀의 사이드프로젝트의 여정과도닮아있습니다🙂)트립북에나만의 특별한 여행콘텐츠를 기록하여,나만의 특별한 드림북을만들 수 있으면 좋겠다고 생각했습니다.서비스에 담긴 의도가잘 전달되었으면 좋겠습니다.🤝 팀원분들은 어떻게 만나셨나요?초창기에 렛플을 통해서 대부분의 팀원분들을 만날 수 있었고,프로젝트가 진행되면서 이후 팀 빌딩은 렛플을 포함한다양한 사이트 혹은 지인소개를 통해 모시게 되었습니다.많은 팀들 중에서특히, 안드로이드 개발자, iOS 개발자분들을 모시기가 어려웠습니다.(모집공고 조회수가 100도 안 될 때가 있더라구요..^^)✔️ 모집과정1. 지원 시 요청사항을 받고2. 기존 팀원분과 간단한 커피챗 진행(프로젝트 참여 목적, 기술 스텍 Q&A 등 Fit 확인)3. 합류의사 확인4. 팀 합류 진행 했습니다.팀원충원은사이드프로젝트를 하다보면필연적으로 겪게 되는 숙명 같은데요.<이상한 나라의 트립북> 팀은인원이 많은 팀 치고는생각보다 팀원충원을 많이 하지 않은 편입니다.진행할 때 커피챗을 꼼꼼하게 진행하며,특히, 프로젝트 참여목적에 대해 확인하는 과정을 거쳤기 때문인지좋은 팀원분들을 모시게 된 것 같습니다.😱 개발은 어떻게 진행이 됬나요?✅ 스프린트 형식주요기능별로 스프린트 형식으로 진행되었습니다.예를 들어, ‘로그인 기능’이라 한다면,로그인 기획 → 디자인 → 개발 → QA이후, 여행소식 기획 → 디자인 → 개발 → QA 이런 식으로요.✅ 커뮤니케이션 채널: 디스코드, 깃허브✔️디스코드 : 소통 채널저희는 소통 채널로 ‘디스코드’를 활용했습니다.디스코드로 자료 전달, 문의 전달 뿐만 아니라,음성 채팅 기능을 사용해서 전체회의도 진행했습니다.@태그, 스레드 기능이 있어서 편했습니다.✔️깃허브 : 일정관리, 회의록 작성 등처음에는 노션을 활용해서 일정 관리 및 회의록 기록하다생각보다 빠르게 노션의 무료 사용량 한계치에 도달하면서깃허브로 옮겨서 진행했습니다.깃허브는 개발자분들이 많이 사용하는 툴이고,개인적으로 한 번도 사용해본 적이 없어서 매우 낯설었는데요.리드미는 뭐고, 레포지토리는 뭐지..?😨 싶었는데,디스코드에 깃허브 봇 연결도 할 수 있고,회의록도 올릴 수가 있어서디스코드와 함께 깃허브를 잘 이용했습니다.이외에 기획+마케팅팀은피그마, 구글 문서(스프레드시트, 프레젠테이션 등),디자인팀은 피그마를 사용했습니다.✅ 회의✔️ 전체회의매주 일요일 9시마다디스코드를 통해 전체회의를 진행했습니다.팀 인원이 많아서각 팀별로 최소 1명 이상 참여하는 방향으로 진행했고,주마다 팀별 진행사항 공유및 다른 팀에게 요청하거나 문의하는 목적으로 진행했습니다.주로 온라인으로 소통하는데다 팀이 많다보니팀별 진행사항을 서로 공유하는 게 중요하다고 생각해서가급적이면 전체회의를 진행하려고 했습니다.(저는 전체회의에 참여하려고 일요일에는 약속을 안 잡았답니다..!ㅎㅎ)✔️ 팀별회의팀별로도 팀별회의를 진행했는데,팀별로 자유롭게 진행했습니다.고정회의시간을 정해서 진행하는 팀도 있었고,필요 시에 회의를 진행하는 팀도 있었습니다.✅ 일정 관리초반에는 ‘기준일’을 정해놓고 진행했습니다.대부분이 직장인인 만큼일정이 딜레이 되는 경우가 많더라도어쩔 수 없다고 생각했고,실제로 일정이 딜레이되더라도꾸준하게 진행이 되었는데요.프로젝트 중반 이후부터는배포 자체를 목적으로,일정에 맞춰서 기능을 제외하는 방향으로진행되었습니다.(하지만 일정 부분은전혀 마음대로 되지 않았습니다😭)👍 재미있었던 것은 무엇이었나요?✅ ”꿈을 꾸면 현실이 된다?” - 생각했던 것이 실제로 구현되어가는 과정처음에는 뭐가 진행이 되고 있는 건지 잘 몰랐는데,스토리보드에 있던 기능이 실제로 구현되었을 때 짜릿했습니다.실제 서비스에서는 잘 다루지 않는Auth0를 통해 간편 로그인을 구현해본다거나,하나의 기능을 처음부터 끝까지 개발해보는 등회사에서 하지 못하는 것들을 해볼 수 있고,다 함께 꼬물꼬물 무언가를 만들어나가는 느낌이 좋았습니다.나중에는 디스코드가 안락하게 느껴질 정도였는데요.(?)생각했던 서비스를 더욱 잘 구현하기 위해서,혹은 각종 오류를 대응하기 위해서고민하고 커뮤니케이션하고 협업했던 일련의 과정들이‘꿈을 현실로 만들어가는 과정’이었다고 생각합니다.✅ 회사가 아니라서 쌉가능! 팀 간에 자유로운 의사소통회사가 아니었지만거의 회사에 준할 정도로<이상한 나라의 트립북 팀>은다양한 팀원분들이 함께했는데요.여러 팀이 있는 만큼 ‘각 팀과 직접적으로 의사소통 할 수 있는 점’이<이상한 나라의 트립북> 팀의 큰 장점이라고 생각했는데요.기획을 하다가 개발 관련해서 궁금한 점이 있을 때,백엔드 개발팀에 다이렉트로 질의를 한다거나,백엔드 개발팀에서 클라이언트 개발팀에다이렉트로 물어보면서 커뮤니케이션 할 수 있었습니다.실제 회사였다면 이 정도로서로에게 물어보기가 어려웠을 것 같은데,진행하다 궁금한 점에 대해서서로 물어볼 수 있다는 점이 재미있었고,소통해나가는 과정 자체가 같이 고민하고성장해나가는 과정 같아서 재밌었습니다.✅ 하는 만큼 쌓이는 성장 Point(사이드프로젝트를 진행하면서여러모로 인생을 배우게 되었습니다..ㅎㅎ)부족한 역량임을 알면서도 시작했고,중간중간 어려움이 많았지만 사이드프로젝트를 하면서어쩔 수 없이(?) 기획에 대한 고민을 강제로 하게 되더라고요.혼자 했으면 금방 포기했을 것 같은데,이걸 진행하면서 사이드프로젝트에 알맞는 운영 방법도어렴풋이 알게 되었고,IA, 서비스 정책서, 스토리보드 등의 기획문서를완성할 수 있게 되었습니다.다른 분들의 경우, 신입 개발자이신데도회의를 주도하거나 진행상황을 챙기는 등팀을 이끌어가는 리드 역할을 수행하거나,팀원이 하차하면서 혼자 팀을 꾸려가며여러 팀의 이슈에 대응해보는 등다양한 성장 Point를 쌓을 수 있었습니다.앱 출시 자체보다도진행 과정에서 다양한 성장 경험을쌓을 수 있었다는 점이<이상한 나라의 트립북> 팀의가장 큰 장점이라고 생각합니다.👎 아쉽거나 어려웠던 점은 무엇이었나요?✅ ’서비스 배포가 될 수 있을까?’ 하는 불안함‘반드시 서비스 배포를 하겠다’는 패기로얼떨결에 PM을 맡게 되었지만,사실, 제가 PM을 맡았을 당시에팀 자체가 안정화되어 있지 않아서언제 엎어져도 이상하지 않다고 생각했습니다.서비스 배포를 하지 못하면이 자체로 저나 저희 팀원분들이모두 시간낭비하는 것 같다고 생각했기에서비스 배포를 반드시 하고 싶었지만사이드프로젝트라 강제적으로 유지할 수 없는 만큼‘배포가 될까?’하는 불안함 때문에 심리적으로 힘들었습니다.(살도 많이 빠졌습니다..ㅎㅎ)✅ 기획에서 욕심은 NO!!!!!!! (진지하니까 궁서체..)(기획하다 울고 싶을 때 그리던 낙서…)PM도 초보지만 기획도 초보였던 저는사이드프로젝트에 걸맞는 기획 범위를 몰랐었는데요.그걸 모르고 완성도 높은 서비스를 만들고자기획 단계에서 많은 욕심을 부렸습니다.차라리 사이드프로젝트에 걸맞는 MVP로 기능을 확정한 뒤,확정된 기능의 완성도를 높이는 편이 좋았을 것 같다는 생각을 합니다.✅ ‘커뮤니케이션’은 아무리 강조해도 된다.개인적으로는 커뮤니케이션이 가장 어려웠습니다..ㅎㅎ특히, 개발팀에서 말하는 프론트 / 백엔드 팀의 차이도 몰랐던 저는사실 초반에 개발팀이 뭔 말을 하는지 대부분 알아듣지 못했고,중간에 저를 태그할 때마다 심장이 뛰었습니다(?)..ㅠㅠ그럴 때마다 팀 내 개발자분들이친절하게 설명해주셔서그나마 다행이었습니다.프로젝트 중반 이후부터는커뮤니케이션 리소스를 줄이고 싶다는 생각을간절하게 하게 되었습니다.개발 관련해서 폭풍 검색과 함께한 결과,지금은 개발자팀의 새로운 요청에도당황하지 않을 정도가 되었습니다.💯 앞으로의 계획을 알려주세요은 아니고요...!트립북의 지난 경험들을 돌아보면서트립북 서비스에 어떤 의도를 담았는지,트립북을 진행하면서 느꼈던 점 등트립북을 만들어오며 쌓아온 이야기 보따리를트립북 SNS에 하나둘씩 풀어보려고 합니다🫡사실,트립북이 정말로 출시될 거라고는크게 기대하지 않았던 서비스입니다.(출시되기를 간절히 기도하기는 했습니다.)제가 초보PM으로 이걸 만든다고 했을 때,‘이쯤하면 그만해라’는 소리를 들었습니다.초보PM으로 일정 관리를 못한 덕분에프로젝트가 장기화되면서점점 지쳐가는 분위기 속에서도‘출시’라는 마침표를 찍을 수 있었던 건함께했던 팀원분들이라고 생각합니다.(어쩔 수 없는 사정으로 하차하신 팀원분들도끝까지 책임감 있게 마무리해주셨습니다.)사이드프로젝트 비하인드 이야기들을기록해보고 싶네요ㅎㅎ저희가 열심히 만든‘트립북’ 봐주실 거죠?👀👉앱 사용후기 설문조사 이벤트(10명 추첨/스타벅스 기프티콘 증정)https://forms.gle/Zb1uV68NCaS4iBqn6🌟별점으로 응원해주시면 힘이 납니다!감사합니다.
😀 개발팀에게 피드백 주기
딱 세 단어로 기록하는 음성 여행 가계부 “노마드월렛" 개발 후기
iOS앱 노마드월렛 기획자이자 팀 유목민의 PM, 김예진입니다. 유목민은 '유저를 목표로 민첩하게'의 줄임말로, 애자일 정신을 기반으로 일상의 작은 문제를 빠르게 해결해 유저의 삶을 개선하는 팀이 되자는 포부를 담은 이름입니다. 저희 팀은 2023년 하반기, 애플 디벨로퍼 아카데미 @POSTECH 에서 만난 5명으로 꾸려졌습니다. iOS 개발자 3명과 UX 디자이너 1명, 그리고 제가 함께합니다.🤗 프로덕트 소개좀 해주세요~👛 App 노마드월렛양손 무거운 배낭 여행 중 소비 기록을 빠짐 없이, 음성으로 간편하게! 배낭 여행자의 무거운 양손 대신 음성으로 기록하는 똑똑한 여행 가계부 노마드월렛은 음성 녹음 버튼을 누르고 무엇을, 얼마에, 어떻게 결제했는지 딱 세 마디만 말하면 알아서 가계부에 정리합니다. 예를 들어, "에스프레소, 3.5, 카드로." 라고 말하면 녹음이 된 시점의 위치 정보를 기반으로 어떤 나라의 어떤 지역에서 어떤 화폐로 지출했는지 파악합니다. 또 머신러닝을 통해 '에스프레소'를 자동으로 '식비'로 분류하죠.여행을 미리 등록해두면 어떤 친구와 썼는지 자동으로 태깅해 나중에 정산이 완료된 엑셀 파일을 추출할 수도 있습니다. 음성으로 1초만에 기록하면 끝나는 간단한 사용성 덕분에, 양손 무거운 배낭 여행자가 휴대폰을 꺼내 길에서 타이핑할 일도 없어 편리하고 안전합니다. 하루 종일 돈 쓰고 말 한 마디로 기록해두면, 저녁에 숙소에 돌아왔을 때 나만의 비서가 정리해준 것처럼 깔끔하게 분류된 지출 기록들을 확인하고 발 뻗고 잠에 들 수 있습니다.⁉ 프로덕트를 만들게 된 계기는 무엇인가요?초기 아이템 선정을 위해 우리 팀은 일상 속에서 불편을 느꼈던 상황들을 회고하는 시간을 가졌습니다. 3주가 넘는 시간동안 다양한 아이디어를 내보고, 우선순위와 기준을 정해 평가하는 과정을 반복했지만 뾰족한 인사이트가 떠오르지 않아 힘들었습니다. 그 과정에선 향수 시향 과정의 어려움을 해결하는 서비스, 취업 준비를 위한 일정 관리 서비스 등 다양한 도메인의 아이템들을 구체화하고 검증하려는 시도들이 있었습니다. 다만 모든 팀원의 가슴을 울리는 아이템이 떠오르지 않아 시간만 흐르던 중, 함께 식사를 하고 정산하는 과정에서 '왜 이렇게 정산은 매번 복잡하고 귀찮을까?' 하는 생각에 모두가 집중하게 된 겁니다. 정산이라는 대주제를 잡고 초기 기획의 목표를 '정산자도, 피정산자도 깔끔하고 빠른 정산 과정을 경험하게 하자!'에서 시작했습니다. 하지만 한국의 정산 문제를 깊게 들여다보니 돈 계산이 걸려있는 문제를 깔끔하게 해결할 수 없는 상황들이 보이기 시작했습니다. 연장자와의 식사, 친하지 않은 사람들간의 회식, 늦게 참석한 사람이 있을 때의 1/n 정산 상황, 함께 먹는 요리를 시켰는데 누구 한 명은 먹지 못할 때...처럼 복잡한 케이스 속에서 우리는 '어떤 상황'에서의 정산 문제를 해결할 것인가를 명확히 정해야 하는 시점에 도달했습니다. 그 과정에서 해외 여행과 총무의 경험이 많았던 저와 한 팀원이 느꼈던 해외 배낭여행 중의 정산의 어려움에 대한 이야기가 수면 위로 올라왔습니다. 가난한 배낭 여행자였던 저는 매일 얼마를 썼는지 기록하고 영수증을 찾아다니며 빈 돈이 없는지 확인하는 일이 여행 중 매일의 고행이었습니다. 여행 커뮤니티에서 비슷한 고민을 하는 여행자들의 이야기를 수집하고, 주변 친구들의 공감을 얻으며 우리 팀은 간단한 해결책으로 '음성 여행 가계부'를 떠올렸습니다. 정산이 어려운 이유는 결국 얼마를 썼는지 기록하는 것을 여행 중에 자꾸 잊고 지나치게 되는 문제에서 시작됩니다. 현금과 카드, 통화를 바꿔가며 쓰는 배낭 여행자들이 돈 쓰자마자 말 한 마디로 쉽게 소비 기록을 남길 수 있는 형태의 가계부가 있다면 여행이 끝난 뒤 정산은 식은 죽 먹기가 될 것이었습니다. 노마드월렛은 음성 녹음 버튼을 누르고 무엇을, 얼마에, 어떻게 결제했는지 딱 세 마디만 말하면 알아서 가계부에 정리합니다. 1) ML을 사용해 입력하는 항목을 자동 분류하고2) 음성으로 1초만에 기록하면 끝나는 간단한 사용성을 구현했습니다. 3) 세계 어디에 가더라도 실시간 환율을 반영해 한화로 얼마를 썼는지 바로 파악할 수 있어 계산기를 두드릴 일도 없습니다. 팀 유목민은 노마드월렛을 통해 배낭 여행자가 자유를 찾아 떠나는 여정 중에 더 이상 소비 기록의 부담을 느끼지 않고 해방감과 즐거움을 만끽할 수 있는 여행 문화를 만들어가고자 합니다. 배낭 여행 준비물 체크리스트에 “노마드월렛 앱 다운받기”가 들어가는 그 날까지, 설렘을 가득 안고 출발하는 새로운 여정에 매번 함께할 수 있는 여행자 필수앱으로 자리잡는 것을 목표로 삼고 있습니다. 🤝 팀원분들은 어떻게 만나셨나요?팀 유목민은 2023년 3월부터 애플 디벨로퍼 아카데미에서 함께 동고동락해온 팀원들로 구성되었습니다. 팀 포밍 초기에는 팀 유목민의 CTO를 중심으로 이전에 함께 프로젝트를 진행했던 iOS 개발자가 함께하며 팀 구성을 시작했고, 어떤 서비스든 이 친구들과 함께라면 기깔나게 일해볼 자신이 생겨 제가 함께하게 되었습니다. 팀 전원의 합의를 통해 직전 프로젝트에서 UX 고민을 함께 나누며 함께 성장해온 UX 디자이너가 합류하게 됐고, 마지막으로 개발 완성도를 끌어올려줄 개발자 추가 영입으로 팀 유목민이 완성되었습니다.😱 개발은 어떻게 진행이 됬나요?구체적인 여행자들의 소비 기록 문제를 파악하고자 해외여행 커뮤니티를 통해 초기 데이터를 수집했습니다. 엑셀로 여행 지출 기록을 남기고 정산하는 배낭 여행자들로부터 기록물들을 받아보며 어떤 요소들을 중요하게 저장하고 기록하는지 파악하며 음성으로 입력해야 하는 필수 요소를 지출 내용, 금액, 수단으로 추려냈습니다. 음성 인식을 위해서도 고도의 기술이 필요했습니다. 사용자의 음성을 텍스트로 옮기는 STT 과정 중에 1) 숫자를 말하면 지출 금액으로 인식하고2) 지출 수단은 현금과 카드로만 구분해 가능한 다른 요소들이 잘못 인식되지 않도록 분기점을 조정했습니다. 데이터셋을 학습시켜 지출 내용을 입력하면 8개의 카테고리(항공, 쇼핑, 관광, 숙소, 식비, 교통, 선물, 기타)로 자동 분류하는 기능까지 구현했습니다. 물론 개발 과정에서 많은 고민 지점이 있었습니다. 지출 내용, 금액, 수단을 순서대로 말하지 않으면 인식 오류가 발생하는 문제가 있어 이 과정에서 유저들이 쉽게 인지하도록 디자인을 보완해야 했습니다. 또, 여행방을 미리 생성하고 관리하는 탭에서 각 여행의 정보가 섞이는 문제를 해결하는 데에도 많은 공을 들였습니다. 실시간으로 여행 중인 지역의 위치정보를 받아와 화폐와 환율을 적용하는 과정에서 데이터가 사용되고 시간이 지연되는 문제도 있었습니다. 여러 문제를 해결하면서 최종적인 노마드월렛이 완성되고 출시되어 전세계를 누비는 노마드 유저들이 사랑과 관심, 피드백을 전해주고 있습니다. 다양한 의견을 반영해가며 노마드월렛은 계속 성장하고 있습니다.👍 재미있었던 것은 무엇이었나요?유저들의 후기를 듣는 것이 가장 큰 즐거움이었습니다. 그 중에서도 노마드월렛을 데일리 가계부로도 쓸 수 있도록 서비스를 확장하면 좋을 것 같다는 피드백이 기억에 남습니다. 매일 영수증을 수기로 기록하는 아내와 딸이 기록을 놓치지 않을 수 있는 습관을 노마드월렛으로 만들어갈 수 있을 것 같다는 말씀을 함께 전해주셨습니다. 그 피드백을 통해 팀원 모두가 초기에 목표했던 '유저의 일상의 작은 문제를 해결하는 솔루션'을 만들어냈다는 보람을 느꼈던 것 같습니다. 노마드월렛을 개발하며 실제로 유저들의 문제를 해결할 수 있는 서비스를 구현하는 과정에서 얼마나 많은 고민과 합의가 필요한지 이해하며 팀 전체가 성장할 수 있었습니다. 디자인, 개발, 기획 모든 파트에서 시간 내에 구현할 수 있는 수준의 결과물을 동일선 상에서 계속해서 머릿속에 그려갈 수 있도록 대화하고 질문하는 과정이 가장 중요하다는 것을 깨달았습니다.👎 아쉽거나 어려웠던 점은 무엇이었나요?가장 어려웠던 것은 해외에서 여행 중 사용했을 때의 사용성을 확인하기 위해 해외에서 유저 테스트를 진행해야 했다는 점입니다. 환율 반영이 되는 과정에서의 문제는 없는지, 도시간 이동 시 기록의 순서가 자연스러운지, 길거리에서 이동 중 사용했을 때 위험 요소는 없는지 등 현장에서 파악 가능한 요소들을 국내에서 테스트하기가 어려웠습니다. 결국 테스트를 위해 직접 일본 여행을 다녀오며 문제를 해결할 수 있었는데, 시간과 비용 측면에서 더 효율적인 방법을 찾았다면 빠른 서비스 개선이 가능했을 것이라는 아쉬움도 있습니다.💯 앞으로의 계획을 알려주세요노마드월렛이 전세계를 누비는 더 많은 노마드 사용자들의 사랑을 받을 수 있도록 서비스를 유지보수하고자 합니다. 더 나은 사용성을 만들어내기 위해 끊임 없이 유저 테스트와 피드백을 반영해 업데이트하고, 애플워치에서 바로 접근할 수 있도록 확장 버전을 만들어갈 계획에 있습니다.
😀 개발팀에게 피드백 주기
대학생개발자가 캘린더로 앱스토어 17위,유저6만명까지
안녕하세요. 대학생을 위한 단 하나의 캘린더, NETY 를 운영중인 Unipus 입니다.저는 NETY 개발자 고려대학교 컴퓨터학과 19학번 김민규입니다.2023년 하반기에 연고대실전창업학회 인사이더스에서 하진님을 만나 팀을 결성했습니다.🤗 프로덕트 소개좀 해주세요~2023년 8월에 런칭하여 10개월차 운영중입니다.NETY 는 현재- 누적 6만명의 사용자- 1,700+ 개의 동아리- 2024 4월 기준 MAU 1.8만명을 기록하고 있습니다.4월 12일 앱스토어 생산성 부분 17위 등극!인생을 살면서 가장 고민이 많고, 새로운 것을 많이 접해야하는 시기가 대학생입니다.대학생을 타겟으로 하는 정보는 너무나도 분산되어 있어서, 이를 찾는데 시간이 많이 걸리거나 아예 접하지 못하는 경우가 정말 많습니다.ex."학사 일정" -> 학교 포털"축제/이벤트 일정" -> 에브리타임, 링커리어, 이벤터스 ..."동아리 일정" -> 카카오톡 투표"내 일정" -> 구글 캘린더NETY는 "대학생을 위한 단 하나의 캘린더" 를 목표로 삼고,1. 대학생에게 필요한 일정 정보를 잘 모아서 보여주자2. 대학생 개인의 일정과 동아리 일정을 잘 관리할 수 있도록 도와주자위 2가지 가치를 제공하고 있습니다.iOS: https://apps.apple.com/kr/app/id6451339766?l=en-GBAOS: https://play.google.com/store/apps/details?id=com.unipus.netyWEB (베타): https://nety.unipus.net⁉ 프로덕트를 만들게 된 계기는 무엇인가요?NETY 는 정말 많은 피봇을 거쳐 현재의 서비스가 되었습니다.처음에는 "고질적인 동아리 운영진의 문제"를 해결하고자 시작했습니다.모임을 관리해주는 솔루션은 정말 다양하나, 각 동아리 운영진의 니즈에 모두 부합하는 솔루션은 없었습니다.저희가 1,700 개가 넘는 동아리를 만나면서 느꼈던 니즈의 예시는 다음과 같습니다.1. 배드민턴 동아리는 가용한 코트가 한정되어 있기에, 선착순으로 동아리 일정에 참여할 수 있는 부원을 모집하고 싶어합니다.2. 출결 관리가 엄격히 이뤄지는 학회는, 각 부원의 출석을 엑셀을 통한 수작업이 아닌 자동화된 방법으로 관리하고 싶어합니다.3. 독서토론 동아리는 매주 같은 책을 택한 부원이 한 조를 이뤄 독서 모임을 합니다. 이때, 매 일정마다 여러 개의 단톡방을 만들어 관리하기가 어렵습니다.이외에도 동아리별 파일 드라이브, 기수 관리 시스템, 동아리 공지 시스템 등 각 동아리 운영진의 니즈에 맞추어NETY는 "동아리 운영에 특화된 공유 캘린더 관리 솔루션"을 제공하고 있습니다.하지만, 수익화에 어려움을 겪었고 이후 다음과 같은 앱 내에 녹여보았습니다.1. 소개팅 서비스2. 번개 서비스3. 동아리는 취향 공동체 -> 취향 기반 커뮤니티 서비스를 만들어보자!각 서비스 모두가 "유지될 만큼의 지표" 는 발생하였지만, 저희 팀이 원하는 J-Curve 를 보여주지 못했습니다.이때 성장세가 지지부진해서, 유저 수가 2만 명에서 3만 명 넘어가는 것이 정말 힘들었습니다.그렇게 운영을 이어나가던 중,1. "동아리 운영진의 문제" 중 가장 중요한 것은 "동아리 일정 관리" 이고2. "동아리 일정" 은 대학생 일정의 일부분이다.→ 그렇다면, 대학생의 분산된 일정을 우리가 한 곳에 모아보자!라는 생각으로 가입만 하면- 해당 학교의 학사일정- 해당 학교내에서 열리는 이벤트 (교내 버스킹, 강연 등)- 수도권에서 열리는 이벤트 (일일호프, 강연, 공연, 공모전 등)- 개인 일정- 동아리 일정모두를 한 번에 볼 수 있는 캘린더로 서비스의 큰 축을 바꾸었습니다.지금까지 시도한 것 중 가장 높은 전환률과 리텐션을 보여주고 있습니다.*기존의 서비스들도 유지보수 중입니다.4월 30일 앱스토어 생산성 부분 20위😱 개발은 어떻게 진행이 됬나요?저희 팀의 목표는 항상 "빠르게 개발하고, 유저 피드백을 듣는 것" 이었습니다.1. 최대한 빠르게 개발하고2. 지표와 유저의 피드백을 통해 서비스를 개선해나감과 동시에3. 다른 기획을 계속 시도해보기위의 3가지가 매우 중요했기 때문에확장성 있는 아키텍처를 설계하고 개발하는 것이 중요했습니다.하지만, 저희 팀은 "이 서비스다!" 하는 확신도 없었고, 가는 와중에 정말 많은 변화를 겪을 것이라고 생각했기 때문에,팀의 사이즈에 비해 과도한 Clean Architecture 를 추구하지 않고, 추상화 Layer 를 적당히 두어서 어느정도의 유동성을 확보하였습니다.각 개발 분야에서 좋았던 점 아쉬웠던 점 몇가지만 얘기해보겠습니다.프론트엔드- Flutter6월에 개발을 시작하여 8월 런칭을 목표로 잡았기 때문에, 빠른 개발이 정말 중요했습니다.원래 웹 개발만 해보았었으나, 무조건 앱이 필요하다고 생각해 iOS, Android 두 플랫폼 출시를 목표로 하였고,Native 로 개발 한다면 절대 2개월 안에 런칭할 수 없다고 생각해 Flutter 를 선택했습니다.프론트엔드 개발에서 후회하는 것1. code generation 을 너무 많이 썼다. (json_serializable, copywith, retrofit, isar): 처음에는 편하다고 생각했지만, 이후에 코드가 너무 많아져서 build 가 너무 길어져서 관리하기 힘들었습니다.2. 앱 업그레이드를 어떻게 할 것인지 고려하지 않고 첫 출시를 진행했다.: 앱 출시가 처음이다보니, 업그레이드까지 생각을 미처 하지 못하고 출시를 했었습니다.초기 유저는 이미 많았는데, 에러도 처음에 정말 많아서.. 이후 유저분들에게 한 분 한 분 연락드리며 업데이트를 부탁하기도 했었습니다.3. 처음부터 flutter_hooks 를 적용하지 않았다.프론트엔드 개발에서 후회하지 않는 것1. 바로 개발하기 보단, 많은 리서치를 하여 기존 개발자분들의 레버리지를 활용했다.: 먼저, 기획을 프론트엔드 - 백엔드 - DB 의 가장 작은 단위까지로 쪼개었습니다.이후 바로 개발하지 않고, 참고할 만한 best practice 가 있는지, 기획 사항에 대한 미리 구현된 library 가 있는지 조사하고 정말 많이 도움을 받았습니다.2. 배포 자동화를 해두었다.: 벌써 빌드가 100 회가 넘었습니다. fastlane 으로 미리 자동화 해두는 것을 정말 추천합니다.https://deku.posstree.com/ko/flutter/fastlane/(주요 라이브러리: riverpod, flutter_hooks, retrofit, dio, fcm, isar)백엔드- Fast API(Python)원래 다니던 회사에서 FastAPI 를 사용했어서 익숙했고, 사용 경험이 정말 좋았어서 깊게 공부해보고 싶은 마음이 있어 선택했습니다.NETY 는 크게 5가지의 서비스로 나뉘어져 있습니다.1. 일정 관리 서비스2. 소개팅 서비스3. 번개 서비스4. 커뮤니티 서비스5. 각 서비스에 부착된 채팅 서비스메인 서비스 (1, 2, 3, 4), 채팅을 담당하는 서비스 (5) 2가지로 나눠 만들었습니다.*처음엔 채팅 서비스를 FastAPI 하나로 구현했었으나 이후에 Go 기반 Centrifugo 및 Centrifugo front-end 로 FastAPI 를 사용해 채팅 서비스를 분리하였습니다.https://centrifugal.dev/채팅 서비스는 저희 주력 기능이 아니기 때문에, 제가 직접 구현하는 것 보다는 거인의 어깨 위에 올라타는 것이 중요하다고 생각했습니다.이미 구현된 Scalable real-time messaging server 인 Centrifugo 를 저희 Cluster 에 올리고,FastAPI 를 통해 Centrifugo 와 통신하는 방식으로 구현하였습니다.백엔드 개발에서 후회하는 것1. 확장이 어려운 Table 구조를 만들어 두었었다. : 예를 들면,- Account 테이블에 firebase token 을 하나만 저장해두었어서, 다중 기기 알람을 지원하려고 할 때 어려움을 겪었었습니다.- Kakao Location 주소만 저장할 수 있게 만들어 두었어서, 이후 Naver Map 으로 장소 정보를 옮길 때 힘들었었습니다.할 수 있는 만큼 테이블 분리를 해두는 것이 중요하다고 생각합니다.2. 제일 중요한 기능을 소화하는 부분에 너무 특이한 라이브러리 (sqlmodel) 를 사용했다.: sqlalchemy 가 python 의 대표 ORM (java Hibernate 유사) 입니다.이를 Wrapping 하여 편의 기능을 추가한 것이 sqlmodel 인데, 결국 불편하게 sqlalchemy 를 사용하는 모양이 되어버렸습니다.→ 중요한 라이브러리는 커뮤니티에서 공신력 있는 것을 사용해야 한다고 생각합니다.백엔드 개발에서 후회하지 않는 것1. ORM 을 적극 활용했다.: 인턴하였던 예전 회사에서 raw sql 을 작성하며 서비스 로직을 완성시킨 적이 있는데, schema migration 할 때마다 정말 고역이었고 로직 적는 것도 한세월이었습니다.2. dto based schema migration 을 적용하였다. (`alembic`): 서비스 자체의 변경, 새로운 서비스 추가하는 일이 정말 많았는데 큰 도움이 돼주었습니다.(주요 라이브러리: FastAPI, sqlalchemy, alembic, asyncio)DataBase, Infra- 일정 로컬 저장을 위한 프론트엔드 데이터베이스 —> Isar- 메인 서비스 정보 저장 → PostgreSQL- cache, pub sub, rate limit → Redis- 실시간 채팅 메시지 저장 → MongoDB- Kubernetes → AWS EKS- ArgoCD 를 설치하여 gitops 방식으로 배포하였습니다.- 이미지 저장 → AWS S3- Redis instance → AWS Elasticache- PostgreSQL instance → AWS RDS- MongoDB instance → MongoDB Atlas- Docker 저장소 → DockerHub- Error Logging → NewRelicDB, Infra 후회하는 것1. AWS 는 비싸다.2. Full Managed MongoDB 인 Atlas 도 정말 비싸다.3. IaaC (Terraform) 을 적용했다.: Terraform 으로 AWS 인프라 구성하였을 때는 뿌듯하고 편리했습니다. 처음에 S3 에 terraform state 저장해서 막 이것저것 해볼 떄는 재밌었습니다.하지만, 서비스가 추가되면서 Terraform 을 사용하는 것이 더 복잡해졌고, 결국 AWS Console 에서 직접 인프라를 구성하는 경우가 많아졌습니다.즉, Terraform 자체에 대한 공부에 쏟는 시간이 너무 많았습니다.→ 본질적인 문제 해결이 아닌, 툴에 대한 공부에 시간을 쏟는 것은 피해야 한다는 생각이 들었습니다.소규모라면 더욱이, Console 에서 빠르게 구성하고 서비스에 집중하는 것이 낫다는 생각이 듭니다.DB, Infra 후회하지 않는 것1. VPC 를 잘 나누어, service node, Elasticcache, RDS 를 분리해두었다.: 이런 구조를 갖고 시작할 때, bastion host tunneling 으로 RDS 에 접속하여 개발하는 것이 귀찮다고 생각했었지만, 지금 돌이켜보니 보안상 마음이 편해져서 좋습니다.단, 이젠 돈이 많이 나와도 AWS 에서 벗어날 엄두가 나질 않습니다.2. AWS Credit 을 많이 이용했다.: 사업자 있으면 많이 지원해주십니다. 처음엔 인프런, 이후엔 메가존클라우드에서 지원을 받았었습니다. 꼭 이용해보세요.https://www.inflearn.com/partners/aws3. GitOps 를 적용했다.: ArgoCD 를 사용하였습니다.정말 편리하고, github 커밋수가 정말 많아 보이는 효과를 줍니다.렛플에 시니어 개발자분들이 많은 것으로 알고있습니다. 이후에 저의 더 많은 개발 관련 생각들을 들고와 보겠습니다!개발자 선배님들의 많은 피드백 부탁드립니다.👍 재미있었던 것은 무엇이었나요?저는 혼자 카카오톡 채널에 응대하며 유저들의 피드백을 바로 반영합니다.며칠이 지나고 기획, 기능, 디자인, 마케팅 을 개선해서 유저를 만족시키고,그 기획이 또 다른 유저들을 끌어들여서, 서비스가 성장하는 것을 보는 것이 개발자로서 가장 행복한 일이었습니다.저희 팀은 항상 "당장 실행할 수 있는 것" 을 미덕으로 생각했고, 단기적인 목표를 잡고 달려가는 것에 최적화 되어 있습니다.단기적인 목표를 향해 돌진하면서 때로는 먼 숲을 보지 않아 헤맬 때도 있었습니다.지금 돌이켜보면, 미션과 비전을 명확히 하고 달렸어야 더욱 효율적으로 목표를 향해 나아갔겠구나 하는 아쉬움도 남습니다.하지만 스타트업이란 아쉬움의 집합이고, 아쉬움이라는 합집합의 크기를 줄이는 자들의 싸움이니까요.결코 아쉽지 않은 한 가지 부분은,저희 팀은 이 길에 들어와 후회없이 달렸다는 점입니다.대세라고 보기는 어려운 B2C 서비스를 선택해 지금까지 저희가 달려온 길에 자부심과 뿌듯함을 느낍니다.많은 변모를 거듭한 저희의 서비스 네티, 종착지는 누구도 모르지만,적어도 대학생 분야에서는 모두가 알 수 있는, 삶의 질을 개선시킨 서비스가 되어 보겠습니다.꾸준히 네티, 그리고 저희를 지켜봐주세요.감사합니다.
😀 개발팀에게 피드백 주기
마음으로 채우는 특별한 선물박스 앱, 패키 회고
안녕하세요! 저는 세상을 따뜻하게 하는 기획을 하고 싶은 PM, 밀리입니다.저희 팀 이름은 Team 딜리인데요! 선물박스를 전달하는 배달부 🚚 의 느낌을 살려 딜리버리의 ‘딜리’를 따서 지어보았어요!저희 팀은 기획자, 디자이너, Server, iOS, Android, Web 총 여섯명으로 이루어져있는 팀이에요.앱 개발 동아리에서 처음 만나 한 달 정도의 기획과 디자인 기간,한달 반 정도의 앱 개발을 진행하였습니다! 개발 기간이 좀 짧은데요ㅎㅎ 짧은 만큼 핵심 기능에 집중하여 MVP 개발을 마쳤습니다.현재는 1차 MVP 검증을 마치고 서비스 확장을 위해 웹 개발을 진행하고 있어요.🤗 프로덕트 소개좀 해주세요~온라인으로 선물을 보내는 것이 당연해진 요즘,'선물(물건)'에만 초점이 맞춰져있는 온라인 선물 문화를 바꾸고 싶어 패키 서비스를 기획하였습니다!패키는 디지털 선물박스를 만들 수 있는 앱이에요.함께 찍은 사진, 정성을 담은 편지, 들려주고 싶은 음악과 선물 사진까지 담아 선물박스를 만들 수 있답니다!패키 프로덕트의 비전은 ‘감정을 연결하는 디지털 선물문화’를 만드는 것이에요.현재까지 총 280개의 선물박스가 만들어졌고,많은 분들이 패키 서비스를 통해 마음을 듬뿍 담은 선물을 보내고 계세요 🎁⁉ 프로덕트를 만들게 된 계기는 무엇인가요?온라인에서 더 특별하게, 마음을 담아 선물을 주고 받을 수는 없을까? 라는 페인 포인트를 계기로 시작하게 되었어요.친구에게 받은 소중한 마음이 오래 오래 간직되고, 기억될 수 있는 서비스를 만들고 싶었습니다 :)기존에 서비스들은 아무래도 "선물하기" 기능이 "커머스" 서비스 안에 있는 기능 중 하나이다보니,물건의 구매에만 집중되어있는 것 같았어요. 이런 부분을 좀 깨뜨리고 싶었던 것 같습니다.기획 과정에서 온라인에서 선물을 주고 받는 사람들은 정말 '물건'만을 선물로 생각할까? 궁금했어요.물건 만이 아니라 선물과 함께 전달되는 마음, 채팅방으로 보내는 메시지, 편지까지모두 선물로 여길 것이라는 생각이 들었습니다.이런 생각들을 확인해보기 위해 설문조사를 진행해보았는데요.약 80%가 선물을 보낸 후, 카카오톡으로 메시지(편지)를 한번 더 보내고 있었고,마음이 담긴 편지도 충분히 선물이 된다! 라는 의견을 주셨어요.설문조사를 통해제가 생각했던 가설, 즉 "물건"만을 선물로 여기지 않을 것이다, 마음이 담겨있는 편지도 선물이 될 수 있다!라는 가설을 검증하고, 또 좀 더 정성을 담아 선물을 전달하고 싶다는 니즈도 파악할 수 있었습니다.선물에 진심인, 선물을 좀 더 특별하게 보내고 싶은 사람을 핵심 유저로 설정하고,‘선물박스를 만드는 기능’을 MVP로 개발 스펙을 설정했어요.사진과 편지, 음악까지 한번에 모든 요소들이 선물처럼 보일 수 있도록,한 화면을 선물박스 내부처럼 만들어 채우고 꾸밀 수 있도록 화면을 디자인 했습니다각 디자인 요소들도 너무 귀엽고 유치한 것 보다는 20대 여성부터, 커플(특히 남자친구) 분들도 쓰실 수 있도록심플하고, 트렌디한 감각을 넣어서 디자인 했어요!🤝 팀원분들은 어떻게 만나셨나요?저희 팀은 앱 개발 동아리 CMC에서 만나게 되었습니다!아무래도 동아리다 보니 기간이 약 3개월 정도로 정해져있었어요.저에게 팀원을 모집할 때 가장 중요했던 것은, 동아리가 끝나도 프로젝트를 계속 할 의향이 있는지였는데요.단순히 서비스 ‘배포’만을 위한 프로젝트가 되지 않기를 바랬고,서비스를 운영하면서 배울 점들이 정말 많다고 생각을 해서프로젝트를 주체적으로 이끌고, 사용자 피드백을 통해 서비스를 디벨롭하고 개선해나가는 과정을 팀원분들과 경험하고 싶었어요!다행히 프로젝트를 쭉 하고 싶은 열정 뿜뿜하신 팀원 분들을 만났고더 좋은 사용자 경험과 프로덕트의 목표를 이루고,각자 개인의 역량까지 키울 수 있는 것들에 도전하면서 정말 재미나게 프로젝트를 하고 있습니다!😱 개발은 어떻게 진행이 됬나요?패키는 App store, Google Play Store에 런칭이 모두 완료된 상태입니다.iOS, Android, 서버 개발자분에 개발 진행 과정을 담아왔어요!iOS 🌎빠른 뷰 개발을 위해 SwiftUI 를 사용했고, Composition 기반의 단방향 플로우 구현을 위해 TCA 아키텍처를 사용했어요.6주라는 짧은 개발 기간동안 프로덕트를 출시해야 했기에,백엔드&모바일이 미리 통일된 스펙을 갖고 함께 개발하는 병렬적인 형태로 개발을 진행했어요.Android 🦒최근 동향을 생각하면 compose 로 앱을 개발하였으면 compose에 어울린다고 생각한 아키텍쳐인 mvi를 도입하였습니다.초기 기획 단계에서 필요할거라 판단한 공통모듈을 구성하였습니다.이후 생산성을 고려하여 디자인 시스템을 빠르게 구축하고 아키텍쳐을 바로 구현할 수있도록 템플릿을 구성하였습니다.기획단계에서 개발 스펙을 잘 조절하고, 핵심 MVP에 집중해서 진행한 덕분에 실제 개발에서는 피쳐작업에 집중할수 있었습니다Server 🐰추후 서비스의 확장성을 고려하여 멀티 모듈로 아키텍처를 설계하였습니다.필요한 API 스펙을 모바일 개발자분들과 사전에 협의한 뒤 개발을 진행했습니다.디자인 요소가 다양한 서비스인만큼 앱 업데이트 없이 디자인을 바꿀 수 있도록 많은 요소에 Server Driven UI를 적용하였습니다👍 재미있었던 것은 무엇이었나요?Design 🎠지금의 선물박스 내부 디자인이 나오기까지 많은 시안들이 있었는데요, 그 과정이 길었지만 재미있었던 것 같아요.제한 상황에 맞춰서 디자인하면서 새롭게 배운 점들도 많았고,사용자 피드백을 바탕으로 디벨롭하는 과정도 의미 있게 느껴졌어요.iOS 🌎프로젝트를 시작하며 예쁜 Animation & Transition 을 구현 해 보고 싶다는 니즈가 있었는데,동작이 부드럽다는 긍정적인 피드백을 많이 받아서 뿌듯했어요!마침 회사에서 시작하는 신규 프로젝트도 애니메이션 부분을 꽤 구현하게 되었는데,상호 긍정적인 영향이 있었던 것 같아요ㅎㅎAndroid 🦒compose를 실 개발에 사용 해보는것은 처음이있습니다.처음 해보는 거라 걱정도 조금 되었는데 진행하다보니compose의 생산성과 재사용성을 느끼면 재미있게 개발하였습니다.Server 🐰서비스 배포 후 운영을 위해 어드민 툴을 만들어보고 싶었는데, Retool이라는 서비스를 이용해서 만들어보았어요.처음에는 직접 간단한 웹 개발을 할까 했지만, 작업 시간을 고려하여 SaaS 서비스를 사용했어요.DB 툴을 사용하지 않고 다른 팀원들이 데이터를 볼 수 있는 환경을 만들어 뿌듯했어요.👎 아쉽거나 어려웠던 점은 무엇이었나요?Design 🎠선물박스 만들기 플로우를 만드는 과정이 어려웠고, 사용자들이 ‘패키’라는 새로운 서비스를 어려움 없이 사용하게 하기 위해 많은 고민의 시간을 들인 작업이었어요.기존에 없던 완전히 새로운 프로덕트이다 보니 레퍼런스를 찾는 것부터 어려움이 있었고플로우 흐름부터 UI, 기능적인 부분까지 많은 수정과 시행착오를 겪으면서 지금의 모습을 갖추게 되었어요.물론 지금도 부족한 점이 많아서 계속해서 수정하고 디벨롭하고 있답니다~iOS 🌎애플이 제공하는 최신 API 를 사용하기 위해 과감하게 iOS 17 버전을 타겟으로 개발했는데,데모데이 때 실제 사용자들을 만나보니 생각보다 버전 17 미만을 사용하는 아이폰 유저들이 종종 있어서, 설치하지 못해 아쉽다는 피드백을 받았어요.시간이 지나며 자연스레 점유율이 바뀌면 해결될 문제로 보이지만, 조금은 아쉬웠어요.Android 🦒프로덕트의 개발 스펙을 정확하게 파악하고 앱을 구성 하려고 하였지만동아리 기간이라는 정해진 시간도 있다보니 놓친 부분들이 꽤 있어 생각보다 코드가 꼬인 부분이 있는 것 같습니다.이후 프로젝트의 지속성이나 확장성을 생각하면서 하니씩 고쳐나가려고 합니다!Server 🐰MVP 구현 기간이 짧아 처음에 써보고자 했던 기술들을 모두 사용해보지 못해 아쉬웠어요.하지만 서비스를 계속 운영해나가면서 느리더라도 하나씩 적용해보고 싶어요.💯 앞으로의 계획을 알려주세요패키는 2월 말 출시 이후, 자잘한 버그들을 수정하고, 실제 사용자 데이터 분석을 위해 GA를 심는 업데이트를 마쳤습니다.그리고 총 4분의 유저 테스트를 진행하고 사용자 데이터를 분석하며 서비스 디벨롭에 대한 인사이트, 사용성 개선을 위한 작업 등을 진행하고 있어요!또 현재는 선물박스를 보내면 받는 사람 역시 무조건 패키 앱을 설치해야만 선물박스를 열어볼 수 있는데요,사용자들의 접근성을 높이기 위해서 선물박스를 여는 것(받는 사람은)앱을 설치하지 않아도 선물박스를 열어볼 수 있도록!웹 개발 역시 추가로 진행하고 있습니다!온라인 선물문화를 바꿔갈 패키, 앞으로도 많은 관심 부탁드려요 💕패키 서비스를 사용해보시고 건의사항이 있다면https://docs.google.com/forms/d/1tUBuqqNJSJx8WIC13r9Sl35ZX0Y8OnVXpUifpDZ2Wr8/edit의견 남겨주세요 🥰
😀 개발팀에게 피드백 주기
행운을 기록해요, [로또일기] 앱 개발과 출시 후기
안녕하세요:) iOS 앱 개발자를 꿈꾸는 신정연(매들린)입니다.작년 하반기부터 iOS 개발을 본격적으로 시작해서, 최근에 개인 앱 프로젝트로 <로또일기>를 출시했습니다.저는 작년 애플 디벨로퍼 아카데미 2기를 수료하고, 현재는 새싹 교육과정을 이수하는 중입니다.사람들과 함께 지식과 경험을 공유하는 것을 잘해서, 협업을 좋아하고, UX를 좋아합니다.기획부터 디자인, 개발 모두 2주라는 기간 안에 해야했기에, 앱의 완성도가 다소 떨어지지만 꾸준히 업데이트해 나갈 예정입니다! 응원 부탁드립니다!🤗 프로덕트 소개좀 해주세요~당신은 오늘 로또를 사면서 무엇을 꿈꾸셨나요?우리의 삶에서 희망을 품고 로또를 구매하는 순간이 주는 작은 설렘이 있습니다.'로또 일기' 앱은 그 설렘과 희망을 담아, 당첨되면 실현하고 싶은 꿈들을 기록하고, 나만의 행운을 찾아가는 여정을 돕는 친구가 되어 드립니다.제가 좋아하는 유투버는 로또를 사면, 뒷면에 당첨되면 하고 싶은 일을 적는다고 합니다. 이건 욕심이 아니라 로또에 대한 예의라는 설명을 덧붙이면서요.이렇게 저도 제가 구매하는 로또 하나하나가, 제가 바라던 일들 하나하나가, 헛되이 사라지지 않게 기록하고 싶었습니다.로또를 구매해보신 분들은 사기 전에 어떤 계기가 있었거나,또는 로또를 사면서 어떤 희망이나 설렘을 가져본 경험이 있으셨을 텐데요,저는 그 경험을 기록할 수 있는 앱을 만들었습니다!주요 기능으로는- 로또 결과를 바로 확인할 수 있는 기능(번호를 직접 입력하거나 QR코드 인식),- 나한테 의미 있는 번호는 저장하고,- 랜덤으로 재미있게 로또 번호를 생성하는 기능,- 현위치와 주변 로또 판매점을 조회할 수 있는 기능,- 로또를 사게 된 계기나, 사고 나서 느낀 감정을 기록할 수 있는 일기와,- 사진과 로또 번호, 그리고 소원 태그를 기록할 수 있는 기능,그 외에도 로또 결과 발표 시간에 알림을 주는 기능이 있습니다.추후에는 소원 태그와 구매 통계를 차트로 보여주는 기능을 1.1ver에 추가할 예정입니다.앱을 출시하고 나서, 아직 제대로된 홍보는 하지 않아서, 지인 선공개를 해보았었는데요,제 주변분들이 로또를 처음 구매해보기도 하고,제 앱으로 추천받은 번호로 5등까지 당첨되었다는 소식도 들어서, 저도 흥미롭게 리뷰를 보고 있습니다.ㅎㅎ⁉ 프로덕트를 만들게 된 계기는 무엇인가요?제가 좋아하는 유투버는 로또를 사면, 뒷면에 당첨되면 하고 싶은 일을 적는다고 합니다. 이건 욕심이 아니라 로또에 대한 예의라는 설명을 덧붙이면서요.이렇게 저도 제가 구매하는 로또 하나하나가, 제가 바라던 일들 하나하나가, 헛되이 사라지지 않게 기록하고 싶었습니다.로또를 구매해보신 분들은 사기 전에 어떤 계기가 있었거나,또는 로또를 사면서 어떤 희망이나 설렘을 가져본 경험이 있으셨을 텐데요,저는 그 경험을 기록할 수 있는 앱을 만들었습니다!😱 개발은 어떻게 진행이 됬나요?1. 기획과 디자인 및 개발 준비우선 Figma를 활용해서 디자인과 기획에 대한 큰 틀을 잡았습니다.가능한 많은 레퍼런스 앱과 동행복권 사이트 등을 참고하면서,이렇게 기획과 디자인을 먼저 큰 틀이라도 확정지은 다음,개발에 필요한 기술 스택과 기능들을 찾아봤습니다.2. 개발 과정1) 개발 구조 설계앱에 대한 큰 가닥으로, 로컬 데이터베이스는 어떤 것을 사용할지, API 호출을 위한 네트워크 통신은 라이브러리를 쓸지, 또는 어떤 아키텍처를 사용할 지 등에 대한 고민을 했습니다.그러고 나서는 제가 선택한 로컬 데이터베이스인 Realm에 저장해야 하는 데이터 모델을 정리한 후, 데이터베이스 테이블을 만들었어요.그리고 앱의 규모가 mvp 단계에서는 그리 크지 않았지만, 점점 기능을 추가하면 로직이 다양해질 것으로 예상해서, MVC와 MVVM을 섞어서 활용했습니다.또 제가 사용할 네트워크 통신 라이브러리인 Alamofire와, 동행복권 API의 콜 제한과 같은 조건을 조사했고,그리고 가장 러닝커브가 있다고 생각되었던, 카카오맵SDK를 활용해서 주변 복권 판매점을 키워드로 검색 후 지도에 띄을 수 있는 로직을 공부했습니다.특히 카카오맵SDK는 최근에 ver2가 나왔던지라, 레퍼런스가 전혀 없어서, 샘플 코드와 공식문서로만 개발을 해보았다는 점에서 의미있었습니다.2) UI와 비즈니스 로직누구는 UI부터, 누구는 비즈니스 로직부터 설계합니다.개발자마다 다른 것 같은데, 저는 UI부터 크게 잡아두고, 비즈니스로직을 개발하는 편입니다.눈에 보이는게 있어야 스스로 이해하면서 개발하기 편하더라구요.UI 레이아웃은 SnapKit과 다양한 CollectionView레이아웃을 잡을 수 있는 Diffable DataSource + Compositional Layout도 활용해보았습니다.이 과정에서 Realm 데이터 수정 및 삭제 로직과의 충돌을 여러번 만났는데요, 이런 과정을 트러블슈팅으로 블로그 글로 잘 정리해두었습니다.https://velog.io/@maddie/iOS-Diffable-Realm-Delete-Error3) 예외처리출시 이후 업데이트를 준비하던 도중 '렛어스고'라는 iOS 컨퍼런스에 참여해서, 우연히 예외처리에 대한 세션을 들었습니다.저는 UX를 고려한 개발을 할 때 유난히 재미를 느끼는 편인데, 특히 예외처리에는 개발자 버전과 유저 버전이 있다는 점이 흥미로웠습니다.예를 들어, 네트워크 통신이 실패한 상황을 가정해봅시다.예외처리 - 개발자 버전에는 네트워크 단절 상황인지, 잘못된 url인지, 인증에 실패했는지 등에 대한 내용을 다루지만,예외처리 - 유저 버전에는 네트워크가 하여튼 왜 안되는지에 대해서는 자세히 알리지 않고, 그래서 어떤 액션을 취해야 하는지("연결 상태를 확인해주세요", "로그인 상태를 확인해주세요", "문제가 계속되면 지원팀에 연락해주세요" 등) 안내하는 것이 좋습니다.바로 제 앱에도 업데이트해보았습니다.👍 재미있었던 것은 무엇이었나요?온전히 제 힘으로 앱을 출시해보니, 없던 주인의식이 생겼습니다. 😂기존 프로젝트들은 보통 팀원 중 한명으로, 팀에 도움되는 일이나, 앱에서 필요한 기능을 개발하는 편이었는데,온전히 제가 넣고 싶은 기능과 제가 생각했을 때 옳은 UX를 생각하면서 개발하니까, 자유를 느꼈습니다.👎 아쉽거나 어려웠던 점은 무엇이었나요?주변 개발자와 이야기할 때 "공수산정 대실패"다, 라는 말을 썼는데요,저에게 주어진 기간은 단 2주, 그 안에 완성해서 출시하는 것이 목표였다면, 앱의 규모를 좀 더 작게, 심플하게 가져가는 게 맞지 않았을까 하는 생각이 듭니다.그리고 실제로 제가 개발할 수 있는 능력치와 그에 걸리는 시간을 미리 계획하고, 실행하는 것이 정말 어렵더라구요.또 애플 스토어 입장에서 Lottery를 주제로 한 앱이니, 무조건 리젝을 한 번 당하겠다는 예상은 했지만, 막상 정말 받아보니 좀 당황스러웠습니다.리젝 사유에는 법적인 사항도 들어있었기에, 기존에 있었던 '로또구매(동행복권 사이트) 웹뷰'는 사라지게 되었습니다.앱 입장에서는 크리티컬한 기능이 빠져야했기 때문에, 리젝 이후에 UI 수정이 불가피해졌습니다.이 부분도 미리 알았다면, 구매와 직결된 기능은 넣지 않고 기획하지 않았을까, 하는 생각이 듭니다.첫 출시와 첫 리젝이라니, 좀 겁을 먹었던 것 같기도 합니다🥹(그리고 전 역시 협업이 더 좋습니다ㅎ🤣)💯 앞으로의 계획을 알려주세요현재 Google Analytics와 Crashlytics를 통해 유저의 사용 현황과 Crash를 추적해서 관찰하고 있습니다.아직 버그 투성이이고, 세세하게 개발하지 못한 기능도 있어서, 이 부분에 집중해서 업데이트를 꾸준히 이어나갈 예정입니다.(나중에는 광고도 달아볼 생각이에요. 아직 광고가 없는 버전을 이용할 수 있으니, 많은 관심 부탁드립니다😇)🧑‍💻 기타 공유하고싶으신 내용 말씀해주세요제가 다른 팀원분들과 같이 만든 “청각장애인을 위한 앱” 비스담도 많이 사용해보세요.아래에서 다운로드 가능해요(현재 IOS만 지원하고 있어요)https://apps.apple.com/kr/app/%EB%B9%84%EC%8A%A4%EB%8B%B4-bisdam/id6470152960https://letspl.me/booth/bisdam
😀 개발팀에게 피드백 주기
디지털 디톡스 앱 Blocker 후기
안녕하세요. 저는 김혁진이라고 합니다.3년 차 백엔드 개발자인데, 혼자 이것저것 개발하는 걸 원래 좋아해요.그동안 10개가 넘는 웹, 앱 다양한 제품을 개발했었어요.이번에도 혼자 개발을 진행했습니다.🤗 프로덕트 소개좀 해주세요~내가 선택한 시간에, 선택한 앱들을 차단하는 앱이에요.습관적으로 앱을 실행시켜도 사용할 수 없게 되죠.무의식적인 사용을 방지하려는 의도에 가까워요.⁉ 프로덕트를 만들게 된 계기는 무엇인가요?요즘 인스타그램이나 유튜브 쇼츠 등 사람들이 하루 종일 휴대폰에 빠져 있잖아요.어느 날 저는 분명 산책에 집중해서 혼자만의 시간을 가지고 싶었는데, 자꾸 걸어가면서 무의식적으로 휴대폰을 켜서 앱들을 열게 되더라고요.분명히 저는 사용할 생각도, 목적도 없었는데 말이죠.그래서 저도 '아, 나도 스마트폰 중독인가?'라고 생각했었죠.저는 새로운 제품 아이디어를 찾을 때 가끔 레딧 같은 해외 커뮤니티에 들어가서 사람들이 어떤 고민과 문제를 겪는지 찾아보곤 하는데, 다들 비슷한 문제를 겪더라고요.알아보니 기존에 앱을 차단해주고 사용 시간을 관리해주는 앱은 이미 존재했었어요.저도 앱을 다운받아서 사용해봤는데, 제가 사용하려는 목적에 비해 앱이 무거운 경향이 있었어요.또 사람들도 앱의 구독 가격이 너무 비싸다는 등의 의견이 많았었죠.그래서 제가 직접 단순한 앱 차단기를 만들려고 했었어요.😱 개발은 어떻게 진행이 됬나요?우선 저는 기존의 앱들은 대부분 Flutter로 개발했어요.아무래도 Aos, iOS 둘 다 빠르고 쉽게 만들 수 있기 때문에 선택했었죠.내가 목표로 했던 기능은 비교적 최근에 나온 기술에 속해서 네이티브 언어로 사용하고자 했고, 한 가지 스토어에 집중하고 싶었어요.그래서 기왕이면 제가 아이폰을 사용하기 때문에 iOS swift를 사용하기로 했죠.총 개발 기간은 5일 안쪽이었던 것 같아요.단순한 UI와 기능인데도 앱 사용을 제한하는 기능에 대한 자료가 부족했어요.그래서 공식 문서를 확인하기도 하고, 얼마 없는 예제 코드를 사용했어요.별도의 서버는 두지 않았어요. 앱 사용 관련 정보는 사용자들에게 민감한 데이터일 수 있고, 작업량을 늘리고 싶지 않았죠.이후 앱 스토어 심사에 넣으려고 업로드를 하는데, 평소와 다르게 업로드 오류가 나왔었죠. 자세히 알아보니, 해당 기능에 접근하려면 애플에 관련 심사를 요청해야 했었습니다.심사 요청 이후 일주일 동안 기다리게 되었지만 안타깝게도 리젝이 되었어요.혹시 내가 선택한 옵션 중에 문제가 있었던 옵션이 있었나 싶어 다시 자세히 심사지를 읽어보고, 다시 신청해서 다행히 통과하게 되었습니다.하지만 심사 이후에도, 문제 해결이 되지 않았어요. 앱 권한도 추가해뒀고, 심사 요청도 성공적이었지만 여전히 오류가 나왔어요.원인을 찾기 위해 애플 커뮤니티에도 찾아보았지만, 애초에 자료 자체가 별로 없었어요.그래도 꼼꼼히 관련 게시물들의 댓글들을 읽다가 가족 관리 기능을 위해 추가한 extension 설정 또한 심사를 받아야 한다고 했었죠.다시 한번 extension을 포함해서 심사를 넣고, 승인 후 앱 권한을 추가하였더니 무사히 업로드에 성공했습니다.스토어 심사는 많이 올려본 짬밥이 생긴 건지 다행히 심사가 한 번에 통과했었습니다.👍 재미있었던 것은 무엇이었나요?아무래도 이번에는 개발 자체에 집중하기보다는, 제가 겪은 문제에 대해 집중하고,해외 커뮤니티에서 사람들이 어떤 문제를 겪는지, 기존의 앱은 어떤 문제가 있는지 알아보는 과정에 집중해봤어요.그리고 한 번에 복잡하게 만들기보다는 가장 단순한 기능 하나 출시를 하고, 이후 개발하기로 마음먹었죠.실제로 다른 기능은 현재 개발하지 않고 버튼만 추가해두었는데, 클릭하면 '이런 기능을 원하면 요청하세요!'라는 느낌이죠.많은 수의 요청이 있으면 해당 기능을 출시할 생각이에요.👎 아쉽거나 어려웠던 점은 무엇이었나요?심사 기간이 상당히 길었던 부분이 아쉬워요.심사 옵션을 꼼꼼히 읽어볼걸 그랬고, extension 심사도 해야 한다는 걸 빠르게 인지했으면 더 좋았을 걸 그랬다는 생각이 들어요.💯 앞으로의 계획을 알려주세요저는 그동안 스토어에 다양하고 많은 앱들을 출시했었어요.조금 더 지켜봐야겠지만 출시한 지 일주일 정도가 지났는데, 다른 앱들보다 노출 수와 판매량 지표가 월등히 좋은 상태에요.아직 데이터를 정확히 수집하는 부분을 신경쓰지 않아서 더 확인해봐야 알 것 같아요.만약 많은 사람들이 사용하고, 다양한 피드백이 들어온다면 종합해서 추가하면 좋을 것 같은 기능을 추가해볼 생각이에요.실제로 저도 사용 중이라 필요하다고 생각되는 기능이 있다면 업데이트 해볼 것 같네요.
😀 개발팀에게 피드백 주기
지금, 나의 프로덕트를 소개해보세요!내 소중한 프로덕트를 대놓고 배너로 홍보하세요.
내 손 안의 특별한 여행북, 《트립북》 회고
🎵볼빨간사춘기의 ‘여행’을 들으면서 봐주시면 더욱 좋습니다 :)🎵사실, 방탄소년단(BTS)의 ‘피땀눈물’의 곡과 아주 잘 어울린답니다….안녕하세요, <이상한 나라의 트립북> 팀에서 🐥초보 PM을 맡은 은하수(본업은 마케터)입니다.<이상한 나라의 트립북> 팀은 개인 역량 향상의 포트폴리오 목적으로 모인 팀으로,기획, 디자인, iOS개발, AOS개발, 백엔드개발팀 포함해서 총 8명으로 구성된 팀입니다.(8명보다 더 많은 인원이 긴 시간동안 함께했지만 최종적으로 끝까지 진행한 분만 8명입니다.ㅎㅎ제가 거대한 팀을 만드려고 했던 건 결코 아닙니다..ㅠㅠ)(기획하다가 마음대로 안 돼서 슬플 때 그리던 낙서..(?))사실, 이 팀은 팀 빌딩 이후 초창기에 팀이 없어질 뻔 했었는데요.23년 3월에 기존 PM이 나가신 후에 기존 팀 인원의 ½ 정도가 빠졌고,제가 PM을 맡게 되었던 23년 3월부터 새로 팀 빌딩을 진행한 이후부터 운이 좋게 팀을 유지하면서 달려온 팀입니다.제가 PM을 맡는다고는 했지만 솔직히 진행 중간에 팀 해체할 가능성이 크다고 생각했었는데,이상하게 오래 유지가 되는 팀을 보면서 <이상한 나라의 트립북 팀>으로 팀 이름을 지었습니다.구성된 팀이 많다보니팀 특성에 맞게 팀별 이름도 지었습니다.<😨기획할 결심> 기획팀 + 마케팅 : 저(PM) / 1명<👑최종 보스> 디자인팀 : 1명<🏃돌격대장> 백엔드 개발팀 : 1명<🌱MZ 세대의 역습> 안드로이드 개발팀 : 3명<🍎전설의 포켓몬> iOS 개발팀 : 2명팀의 비하인드가 궁금하시면, 트립북 공식 SNS에 올라오는 트립북의 다음 이야기들을 기대해해주세요👀🤗 프로덕트 소개좀 해주세요~"기록되지 않는 건 기억되지 않는다."고 하는데요.내 손 안의 특별한 여행북(✈️+📙), ‘트립북’은시간이 지날수록 잊혀지는 ✈️여행기억을책📙 형태로 소중하게 기록하며내 손 안의 특별한 여행북을 만들어가는개인 여행 콘텐츠 아카이빙 서비스입니다.초기 트립북의 서비스 성격이바로 정해지지 않고여러모로 변화가 많았는데요…😢프로젝트가 장기화되면서빠르게 결과를 도출할 수 있는 방향으로‘여행기록 기능’에 집중한MVP로 출시하게 되었습니다.‘여행’은 새로운 나의 모습을발견하는 과정이며,‘기록’은 성장하기 위한강력한 도구라고 생각합니다.그래서 내 손 안의 특별한 여행북, 트립북은단순히 여행기록하는 것으로 끝나는 것이 아니라,사용자분들이 여행과 기록을 통해서내 안의 ‘새로운 가능성’을발견하는 특별한 여정을시작하기를 바라는 마음을 담았습니다.(이는, 저희 팀의 사이드프로젝트의 여정과도닮아있습니다🙂)트립북에나만의 특별한 여행콘텐츠를 기록하여,나만의 특별한 드림북을만들 수 있으면 좋겠다고 생각했습니다.서비스에 담긴 의도가잘 전달되었으면 좋겠습니다.🤝 팀원분들은 어떻게 만나셨나요?초창기에 렛플을 통해서 대부분의 팀원분들을 만날 수 있었고,프로젝트가 진행되면서 이후 팀 빌딩은 렛플을 포함한다양한 사이트 혹은 지인소개를 통해 모시게 되었습니다.많은 팀들 중에서특히, 안드로이드 개발자, iOS 개발자분들을 모시기가 어려웠습니다.(모집공고 조회수가 100도 안 될 때가 있더라구요..^^)✔️ 모집과정1. 지원 시 요청사항을 받고2. 기존 팀원분과 간단한 커피챗 진행(프로젝트 참여 목적, 기술 스텍 Q&A 등 Fit 확인)3. 합류의사 확인4. 팀 합류 진행 했습니다.팀원충원은사이드프로젝트를 하다보면필연적으로 겪게 되는 숙명 같은데요.<이상한 나라의 트립북> 팀은인원이 많은 팀 치고는생각보다 팀원충원을 많이 하지 않은 편입니다.진행할 때 커피챗을 꼼꼼하게 진행하며,특히, 프로젝트 참여목적에 대해 확인하는 과정을 거쳤기 때문인지좋은 팀원분들을 모시게 된 것 같습니다.😱 개발은 어떻게 진행이 됬나요?✅ 스프린트 형식주요기능별로 스프린트 형식으로 진행되었습니다.예를 들어, ‘로그인 기능’이라 한다면,로그인 기획 → 디자인 → 개발 → QA이후, 여행소식 기획 → 디자인 → 개발 → QA 이런 식으로요.✅ 커뮤니케이션 채널: 디스코드, 깃허브✔️디스코드 : 소통 채널저희는 소통 채널로 ‘디스코드’를 활용했습니다.디스코드로 자료 전달, 문의 전달 뿐만 아니라,음성 채팅 기능을 사용해서 전체회의도 진행했습니다.@태그, 스레드 기능이 있어서 편했습니다.✔️깃허브 : 일정관리, 회의록 작성 등처음에는 노션을 활용해서 일정 관리 및 회의록 기록하다생각보다 빠르게 노션의 무료 사용량 한계치에 도달하면서깃허브로 옮겨서 진행했습니다.깃허브는 개발자분들이 많이 사용하는 툴이고,개인적으로 한 번도 사용해본 적이 없어서 매우 낯설었는데요.리드미는 뭐고, 레포지토리는 뭐지..?😨 싶었는데,디스코드에 깃허브 봇 연결도 할 수 있고,회의록도 올릴 수가 있어서디스코드와 함께 깃허브를 잘 이용했습니다.이외에 기획+마케팅팀은피그마, 구글 문서(스프레드시트, 프레젠테이션 등),디자인팀은 피그마를 사용했습니다.✅ 회의✔️ 전체회의매주 일요일 9시마다디스코드를 통해 전체회의를 진행했습니다.팀 인원이 많아서각 팀별로 최소 1명 이상 참여하는 방향으로 진행했고,주마다 팀별 진행사항 공유및 다른 팀에게 요청하거나 문의하는 목적으로 진행했습니다.주로 온라인으로 소통하는데다 팀이 많다보니팀별 진행사항을 서로 공유하는 게 중요하다고 생각해서가급적이면 전체회의를 진행하려고 했습니다.(저는 전체회의에 참여하려고 일요일에는 약속을 안 잡았답니다..!ㅎㅎ)✔️ 팀별회의팀별로도 팀별회의를 진행했는데,팀별로 자유롭게 진행했습니다.고정회의시간을 정해서 진행하는 팀도 있었고,필요 시에 회의를 진행하는 팀도 있었습니다.✅ 일정 관리초반에는 ‘기준일’을 정해놓고 진행했습니다.대부분이 직장인인 만큼일정이 딜레이 되는 경우가 많더라도어쩔 수 없다고 생각했고,실제로 일정이 딜레이되더라도꾸준하게 진행이 되었는데요.프로젝트 중반 이후부터는배포 자체를 목적으로,일정에 맞춰서 기능을 제외하는 방향으로진행되었습니다.(하지만 일정 부분은전혀 마음대로 되지 않았습니다😭)👍 재미있었던 것은 무엇이었나요?✅ ”꿈을 꾸면 현실이 된다?” - 생각했던 것이 실제로 구현되어가는 과정처음에는 뭐가 진행이 되고 있는 건지 잘 몰랐는데,스토리보드에 있던 기능이 실제로 구현되었을 때 짜릿했습니다.실제 서비스에서는 잘 다루지 않는Auth0를 통해 간편 로그인을 구현해본다거나,하나의 기능을 처음부터 끝까지 개발해보는 등회사에서 하지 못하는 것들을 해볼 수 있고,다 함께 꼬물꼬물 무언가를 만들어나가는 느낌이 좋았습니다.나중에는 디스코드가 안락하게 느껴질 정도였는데요.(?)생각했던 서비스를 더욱 잘 구현하기 위해서,혹은 각종 오류를 대응하기 위해서고민하고 커뮤니케이션하고 협업했던 일련의 과정들이‘꿈을 현실로 만들어가는 과정’이었다고 생각합니다.✅ 회사가 아니라서 쌉가능! 팀 간에 자유로운 의사소통회사가 아니었지만거의 회사에 준할 정도로<이상한 나라의 트립북 팀>은다양한 팀원분들이 함께했는데요.여러 팀이 있는 만큼 ‘각 팀과 직접적으로 의사소통 할 수 있는 점’이<이상한 나라의 트립북> 팀의 큰 장점이라고 생각했는데요.기획을 하다가 개발 관련해서 궁금한 점이 있을 때,백엔드 개발팀에 다이렉트로 질의를 한다거나,백엔드 개발팀에서 클라이언트 개발팀에다이렉트로 물어보면서 커뮤니케이션 할 수 있었습니다.실제 회사였다면 이 정도로서로에게 물어보기가 어려웠을 것 같은데,진행하다 궁금한 점에 대해서서로 물어볼 수 있다는 점이 재미있었고,소통해나가는 과정 자체가 같이 고민하고성장해나가는 과정 같아서 재밌었습니다.✅ 하는 만큼 쌓이는 성장 Point(사이드프로젝트를 진행하면서여러모로 인생을 배우게 되었습니다..ㅎㅎ)부족한 역량임을 알면서도 시작했고,중간중간 어려움이 많았지만 사이드프로젝트를 하면서어쩔 수 없이(?) 기획에 대한 고민을 강제로 하게 되더라고요.혼자 했으면 금방 포기했을 것 같은데,이걸 진행하면서 사이드프로젝트에 알맞는 운영 방법도어렴풋이 알게 되었고,IA, 서비스 정책서, 스토리보드 등의 기획문서를완성할 수 있게 되었습니다.다른 분들의 경우, 신입 개발자이신데도회의를 주도하거나 진행상황을 챙기는 등팀을 이끌어가는 리드 역할을 수행하거나,팀원이 하차하면서 혼자 팀을 꾸려가며여러 팀의 이슈에 대응해보는 등다양한 성장 Point를 쌓을 수 있었습니다.앱 출시 자체보다도진행 과정에서 다양한 성장 경험을쌓을 수 있었다는 점이<이상한 나라의 트립북> 팀의가장 큰 장점이라고 생각합니다.👎 아쉽거나 어려웠던 점은 무엇이었나요?✅ ’서비스 배포가 될 수 있을까?’ 하는 불안함‘반드시 서비스 배포를 하겠다’는 패기로얼떨결에 PM을 맡게 되었지만,사실, 제가 PM을 맡았을 당시에팀 자체가 안정화되어 있지 않아서언제 엎어져도 이상하지 않다고 생각했습니다.서비스 배포를 하지 못하면이 자체로 저나 저희 팀원분들이모두 시간낭비하는 것 같다고 생각했기에서비스 배포를 반드시 하고 싶었지만사이드프로젝트라 강제적으로 유지할 수 없는 만큼‘배포가 될까?’하는 불안함 때문에 심리적으로 힘들었습니다.(살도 많이 빠졌습니다..ㅎㅎ)✅ 기획에서 욕심은 NO!!!!!!! (진지하니까 궁서체..)(기획하다 울고 싶을 때 그리던 낙서…)PM도 초보지만 기획도 초보였던 저는사이드프로젝트에 걸맞는 기획 범위를 몰랐었는데요.그걸 모르고 완성도 높은 서비스를 만들고자기획 단계에서 많은 욕심을 부렸습니다.차라리 사이드프로젝트에 걸맞는 MVP로 기능을 확정한 뒤,확정된 기능의 완성도를 높이는 편이 좋았을 것 같다는 생각을 합니다.✅ ‘커뮤니케이션’은 아무리 강조해도 된다.개인적으로는 커뮤니케이션이 가장 어려웠습니다..ㅎㅎ특히, 개발팀에서 말하는 프론트 / 백엔드 팀의 차이도 몰랐던 저는사실 초반에 개발팀이 뭔 말을 하는지 대부분 알아듣지 못했고,중간에 저를 태그할 때마다 심장이 뛰었습니다(?)..ㅠㅠ그럴 때마다 팀 내 개발자분들이친절하게 설명해주셔서그나마 다행이었습니다.프로젝트 중반 이후부터는커뮤니케이션 리소스를 줄이고 싶다는 생각을간절하게 하게 되었습니다.개발 관련해서 폭풍 검색과 함께한 결과,지금은 개발자팀의 새로운 요청에도당황하지 않을 정도가 되었습니다.💯 앞으로의 계획을 알려주세요은 아니고요...!트립북의 지난 경험들을 돌아보면서트립북 서비스에 어떤 의도를 담았는지,트립북을 진행하면서 느꼈던 점 등트립북을 만들어오며 쌓아온 이야기 보따리를트립북 SNS에 하나둘씩 풀어보려고 합니다🫡사실,트립북이 정말로 출시될 거라고는크게 기대하지 않았던 서비스입니다.(출시되기를 간절히 기도하기는 했습니다.)제가 초보PM으로 이걸 만든다고 했을 때,‘이쯤하면 그만해라’는 소리를 들었습니다.초보PM으로 일정 관리를 못한 덕분에프로젝트가 장기화되면서점점 지쳐가는 분위기 속에서도‘출시’라는 마침표를 찍을 수 있었던 건함께했던 팀원분들이라고 생각합니다.(어쩔 수 없는 사정으로 하차하신 팀원분들도끝까지 책임감 있게 마무리해주셨습니다.)사이드프로젝트 비하인드 이야기들을기록해보고 싶네요ㅎㅎ저희가 열심히 만든‘트립북’ 봐주실 거죠?👀👉앱 사용후기 설문조사 이벤트(10명 추첨/스타벅스 기프티콘 증정)https://forms.gle/Zb1uV68NCaS4iBqn6🌟별점으로 응원해주시면 힘이 납니다!감사합니다.
😀 개발팀에게 피드백 주기