Beomhee Park
아티클
서경민
사용자 행동에 기반하여 대대적인 UI 가 업데이트 되었습니다.
다들 추석 연휴는 잘 보내셨나요?
5일이나 되는 길었던 연휴이지만 눈 깜짝할 사이에 지나간 것 같습니다.
Riido는 최근 들어 새로운 기능을 계속해서 추가하기보다는 이미 개발된 것들을 100% 활용할 수 있게 하기 위해 다방면으로 노력하고 있어요.
제목에 대대적인 UI 업데이트를 진행했다고 했지만, 사실 사용자 입장에서는 바뀐 것을 체감하지 못할 수도 있습니다.
기존에 잘 사용하던 방식을 뒤엎어버리는 것이 아닌, 저희는 슬금슬금 조금씩 스며드길 원해요.
그러다 보면 어느 순간 Riido를 사용하는데 전혀 불편함이 없을 거예요.
박채운
이전 포스팅에서 자수? 한 것처럼 저희 앱이.. 성공하기 힘든 서비스라 걱정했는데 생각보다 많은 러너 분들이 응원해주셔서 힘이됐습니다!
오늘은 새롭게 런칭을 준비하고 있는 [함께 달리기] 기능을 소개해드리고 싶습니다.
함께 달리기는 하단 탭 하나를 써서 비싼 땅에 구현할 예정인만큼 규모도, 기대도 큰 기능이에요.
지난 글에서 소개드린 것처럼, 페이스메이커는 빨리 달리거나 효율적으로 달리는 것에는 관심이 없습니다. 대신, [함께 더 즐겁게 달리는 것], 그리고 (이 좋은) [달리기를 삶에서 더 오래 지속하는 것]을 진심으로 도와주고 싶어요.
함께 달리기야말로 이 두 가지 키워드 함께, 오래가 모두 필요한 기능입니다.
함께 달리기는 듀오링고의 [친구와의 퀘스트] 기능을 벤치마킹해 만들었어요.
듀오링고에서 친구와의 퀘스트를 시작하면, 1:1로 매칭이 됩니다. 이 퀘스트는 경쟁보다 협력에 가까워요. 함께 꾸준히 학습을 해야만(Streak 유지) 퀘스트를 깰 수 있습니다.
더 멋진 건 '넛지'를 통해 서로 응원?(혹은 재촉)을 할 수 있다는 거에요. 나만 잘해서는 퀘스트를 달성할 수 없기 때문입니다. 친구에게 메세지를 받으면 어느정도 조급함..과 책임감이 생기게 됩니다.
이를 통해 유저가 직접 유저를 액티베이션 시키는 선순환이 가능합니다.
언어 학습을 게임처럼 만들 수 있다면, 달리기도 게임이 될 수 있을거에요.
함께 달리기라는 게임은 친구보다 빨리 달리거나 많이 달리기 위한 기능이 아닙니다. 둘이 함께, 꾸준히 연속 달리기를 수행해야 더 높은 성과를 얻을 수 있어요.
또 같이 목표 거리를 채우는(like 의리주) 서브 퀘스트도 추가됩니다.
저희 팀은 아이디에이션을 통해 친구와 매칭 시키는 방식, '연속 달리기(streak)'의 기준, 퀘스트 달성의 조건 등의 기본 정책을 수립했어요.
초기 MVP이기 때문에 구현이 단순하고, 유저가 좀 더 쉽게 사용할 수 있도록 최대한 단순하게 하는 것을 목표삼았습니다. 이후 유저 반응을 통해 차근차근 방향성을 수립하고 개선해나갈 수 있을거라 기대해요.
함께 달리기의 궁극적인 목표는 달리기를 이미 시작한 유저가, 달리지 않는 사람을 저희 앱을 통해 달리도록 만드는 것입니다.
저희 페이스메이커 팀원들도 얼른 이 기능을 구현해서 써보고 싶은 마음이에요. 저또한 기대가 매우 크구요. 그만큼 이번 Pmc를 통해 이 기능을 메이커분들께 소개할 수 있게 되어 기쁩니다.
달리기는 그 자체로 매력있는 운동이에요. 함께 달린다면 더 즐겁고, 더 지속적으로 할 수 있을 거라 믿습니다.
저희 서비스를 통해 더 많은 사람들이 달리기의 재미를 알고, 오랫동안 즐겁게 함께 달리면 좋겠습니다.
모든 러너들을 응원합니다!!
헐크코디어
[1인 개발] PlayStore 4번의 리젝과 5번의 시도
안녕하세요!
을 개발한 1인 개발자 박현진 입니다.
PlayStore와의 배포 전쟁 이야기를 들려드리면서 저와 같은 실수를 하지 않길 바라는 마음에 이 글을 공유드립니다.
참고로 아래 진행 과정은 개인 개발자 계정에만 해당하는 정책들입니다.
TodoZIP 앱이 Flutter로 개발 되어 있어 AppleStore, PlayStore 배포를 전부 진행 했습니다.
역시나 iOS개발자 출신답게 AppleStore는 한방에 통과!
하지만 PlayStore는 예전 좋았던 기억과는 다르게 많이 달라져 있었습니다.
개발자 계정 결제 후 본인 인증까지 쉬운게 하나도 없더군요...
그래도 어찌저찌 여기만 지나면 배포 할 수 있겠지!! 라는 너무나 큰 기대감과 함께 앱을 배포 하려고 하니 프로덕션 출시 버튼이 비활성화가 되어 있었습니다...
검색 해보니 이제는 PlayStore에 출시하기 전에 비공개 테스터 20명을 모집하고, 그 후로 14일이 지나야 프로덕션 검수 신청이 가능하다고 바뀐 정책이 있었음을 확인했습니다.
저는 여기서 조금 좌절 했습니다...분명 예전에 구글은 이렇지 않았는데!!
그렇지만 TodoZIP은 좋은 서비스이니깐 양대 스토어에 다 올라가 있어야지!! 하면서 20명을 어떻게 구하나 검색 했더니 아래 두가지 방법으로 좁혀지더군요.
크몽 전문 업체 활용 VS 비공개 테스트 품앗이 카톡방
5만원 정도의 가격을 주고, 아무 신경안쓰고 전문업체에 맡기면 되겠지라는 안일한 마음 가짐과 함께
저는 첫번째 시련을 받았습니다....
PlayStore님이 너는 테스터를 제대로 모으지 않았고, 테스트 모범사례를 따르지도 않았다!!
???????????????????????????????????
저는 크몽 전문업체 분에게 물어봤습니다.
나: 왜 리젝일까요??
크몽: 다시 해보시죠!
네 그렇게 두번째 시련을 받았습니다.
나: 왜 리젝일까요??
크몽: 다시 해보시죠!
네 그렇게 세번째 시련을 받았습니다.
나: 왜 리젝일까요??
크몽: 다시 해보시죠!
네 그렇게 네번째 시련을 받았습니다.
네 저는 그렇게 14일을 자그마치 4번의 리젝과 함께 56일이란 시간과 함께 다 날려버렸습니다!
저는 이때 깨달았습니다...(너무 늦게)
아 이건 크몽에 맡기면 다음번엔 또 리젝이겠구나!
카카오톡 품앗이방에 가서 저는 하소연을 하게 되었습니다.
저 4번 리젝 당했습니다 여러분!!!
어랏?! 이 단톡방에 2 ~ 4번 리젝 당하시는 분이 엄청 많았습니다!!
심지어 다들 크몽을 쓰고 계시더군요..
큰일이다 싶어 저는 네이버 카페에 비공개 테스트 품앗이 방에 글을 올려 테스터를 구하고 14일이란 시간이 지난 후........
드디어 4번의 리젝과 5번의 시도 끝에 배포까지 성공하게 되었습니다...ㅠㅠ
앱 배포가 이렇게 기분좋은 일인걸....신입때 느꼈던 기분을 다시 느끼게 되었습니다.
결론:
크몽 업체에 맡기면 잘 될수도 있고, 안 될 수도 있다
비공개 테스트 품앗이 카페에 올릴 경우 조금 귀찮을 수 있지만 99%의 확률로 통과가 된다
해외랑 카톡방의 정보를 모아보니,
현재 구글은 정책이 더 까다로워져서 비공개테스트때 앱을 업데이트 했는지 여부
업데이트를 몇명이 설치했는지 여부
처음 리젝 후 다시 테스트시 같은 계정으로 테스트 하는지 여부를 다 체크하고 있는것 같습니다.
부디 1인 개발 하실때 저처럼 미련하게 하지 마시고 똑똑하게 하시길 바라면서
좋은 서비스 만드시길 기원합니다.
Todo.ZIP
같이 사는 누군가와 오늘의 집안일을 공유해요!
uibowl
안녕하세요, 유아이볼의 인턴 디자이너 이미영입니다. 즐거운 추석 연휴 보내셨나요? 아쉬움을 뒤로하고 모두 일상으로 돌아오셨겠지만, 지난 연휴만큼 반가운 소식을 들고 찾아왔어요.
바로 레퍼런스 이미지를 피그마로 손쉽게 가져올 수 있는 유아이볼 플러그인이 드디어 출시되었어요! 플러그인이 어떻게 탄생했는지부터 제작 과정, 그리고 사용 방법까지 함께 자세히 알아볼까요?
(플러그인 사용해 보기 : https://www.figma.com/community/plugin/1416283003258937842/uibowl)
플러그인이 왜 필요할까?
유아이볼팀은 약 한 달 전 UT를 진행했고, 그때 얻은 인사이트를 바탕으로 이번 플러그인을 개발하게 되었어요. 먼저 UT에서 어떤 인사이트를 얻었는지 공유드릴게요.
* UT 이야기는 여기서 보실 수 있어요! : https://brunch.co.kr/@boldydesign/66
첫 번째로, 사용자들의 레퍼런스 활용 및 작업 방식을 질문드렸어요.
보통 레퍼런스를 참고하며 작업하실 때, 어떤 방식으로 작업하시나요? (ex. 따로 레퍼런스 창을 띄워놓고 작업 / 디자인파일에 불러와 수시로 확인하며 작업 등)
참가자들의 답변은 이러했어요 :
이처럼 모든 참가자들이 작업 중 레퍼런스를 함께 확인하는 공통점이 있었고, 세 분은 복사-붙여넣기 방식을, 나머지 한 분 또한 플러그인을 사용해 피그마에서 확인하고 계셨어요.
두 번째는 북마크 이용 행태와 관련한 사용성 테스트를 진행했어요.
이미지 및 패턴을 북마크 한 후, 내역을 확인하는 과정을 테스트했는데요. 제가 요청한 필터링 조건 내에서 원하는 이미지와 패턴을 북마크 하고 그 내역을 확인하는 절차였어요. 여기서 얻은 핵심 인사이트는 참가자는 전부 유아이볼 이용 빈도가 높은 분들임에도 불구하고 북마크 기능의 존재를 아는 참가자는 20%에 불과했고, 모든 참가자가 북마크를 거의 사용하지 않았다는 점이었어요.
그 이유를 여쭤보니, 다음과 같은 답변을 들을 수 있었어요 :
이를 통해 사용자는 북마크 기능보다 직접 이미지를 저장하는 방식을 더욱 선호하고, 북마크의 필요성을 크게 느끼지 못한다는 점을 알 수 있었어요. 기대했던 것보다 북마크 기능의 활용도가 훨씬 낮았으며, 사용자는 작업 파일에서 이미지를 함께 확인하는 방법을 선호한다는 사실을 다시 한번 확인할 수 있었어요.
작업 프로세스를 줄일 수 있는 방법 탐색하기
UT를 통해 얻은 인사이트를 정리하고, 그에 대한 해결 방안을 모색하는 시간을 가졌어요.
작업 파일에 레퍼런스를 불러오는 방식 선호
대다수의 참가자분들은 작업 파일에 레퍼런스를 불러와 즉각적으로 쉽게 참고할 수 있는 작업 환경을 선호했어요. 따라서 북마크의 이용률도 현저히 낮게 나올 수밖에 없었어요.
비효율적인 콘텐츠 저장 방식
참가자분들이 작업 시 레퍼런스를 복사해 디자인 파일에 붙여 넣는 방식을 사용했지만, 여러 이미지를 가져오려면 생각보다 번거롭고 여러 단계를 거쳐야 했어요.
따라서 UT 결과를 바탕으로 두 가지 주요 목표를 설정했어요.
1. '유아이볼의 대표 사용자인 디자이너가 주로 사용하는 툴'인 피그마와의 연동을 통해 디자이너의 작업 환경에 밀접하게 다가가, 효율적인 작업을 지원해요.
2. '작업 프로세스를 간소화할 수 있는 방법'으로 이미지 단일/다중 임포트 기능을 제공하는 플러그인으로 작업 효율성을 높여요.
여러 UI/UX 디자인 툴 중에서 피그마를 선택한 이유는 UI/UX 디자인 소프트웨어 시장에서 피그마의 점유율이 약 83.4%에 달해, 대다수의 디자이너들이 피그마를 사용하고 있어 접근성이 높기 때문이에요.
피그마 플러그인은 반복적인 작업을 자동화하고 간소화할 수 있는 많은 편리한 기능을 제공하고 있어요. 플러그인 추천 포스팅을 읽어보면 공통적으로 '유용', '쓸모 있는', '시간 단축', '효율' 등의 단어를 많이 볼 수 있죠. 이를 통해 피그마 플러그인은 피그마에서 제공되지 않는 기능이나 특정 상황에서 효율을 높일 수 있는 기능이 필요할 때 사용된다는 것을 알 수 있어요.
유아이볼 역시 레퍼런스를 불러오는 과정을 간소화하여 불필요한 작업을 줄이고 작업 속도를 높이는 기능을 제공하고자 하는데요. 이는 기존의 피그마 플러그인의 효과와도 동일하다는 점을 확인할 수 있어요.
디자인 작업 & 플러그인 검수 요청
디자인 작업은 web 작업과 피그마 내 플러그인 작업을 함께 진행했어요. 먼저 여러 시안들을 제작한 후, 코멘트와 리뷰를 이어가며 디자인을 확정 짓는 과정으로 작업이 진행되었어요.
이번 디자인 작업에서 아쉬웠던 점은 다양한 케이스를 충분히 고려하지 못해 기능과 플로우에 구멍이 발견되었고, 이로 인해 개발 기간과 개발자분과의 커뮤니케이션이 예상보다 많이 늘어나게 된 점이에요.
기본적인 부분에서 실수를 했다는 사실에 협업하는 분들께 죄송하고 제 자신에게도 아쉬움이 많이 남았지만, 이 경험을 통해 CRUD 개념, 예외 케이스를 고려하는 부분에서 더욱 세심하게 진행해야겠다고 다시 한번 배울 수 있는 계기가 될 수 있었어요.
*CRUD : 소프트웨어에서 데이터를 처리하는 네 가지 작업. create(생성), read(읽기), update(수정), delete(삭제)를 의미하며, 이 네 가지 작업을 고려하여 디자인하면 기능이 누락되는 것을 막을 수 있어요.
플러그인 검수 요청은 어렵지 않게 진행할 수 있어요.
1️⃣ 배포할 플러그인의 오른쪽에 위치한 미트볼 메뉴에서 'publish new version'을 선택해 주세요.
2️⃣ 플러그인 이름, 설명 등 필수 항목을 모두 채워주세요.
자세한 설명은 피그마의 안내를 꼭 참고해 주세요 : https://help.figma.com/hc/en-us/articles/360042293394-Publish-plugins-to-the-Figma-Community#Creators_and_contributors
3️⃣ 모두 채우신 후, 오른쪽 하단의 'submit for review'를 눌러주시면 7~10일 내로 피그마의 검수 결과를 받으실 수 있어요.
(이미지는 이미 퍼블리시된 플러그인이라 문구가 달라요!)
저희는 주말 포함 5일 정도가 소요되었어요.
플러그인 함께 사용해 봐요!
이제 피그마 플러그인을 사용하는 방법을 알려드릴게요.
1️⃣ 유아이볼(https://uibowl.io/)에서 원하는 이미지를 hover하여 체크박스를 선택해 주세요.
2️⃣ 이미지를 고르셨다면, 사이트 하단에 생성된 '내보내기' 버튼을 눌러 주세요.
* 선택한 이미지를 초기화하고 싶다면, 초기화 버튼을 눌러 주세요.
3️⃣ 피그마로 이동해 플러그인을 실행한 뒤, '불러오기 버튼'을 선택해 주세요.
* 내보낸 후 버튼이 5초 동안 유지돼요. 동일한 이미지를 다시 내보내고 싶으시면, 사이트에서 '다시 내보내기'를 선택해 주세요.
아래의 릴스를 통해 더 쉽게 사용 방법을 익혀보세요!
이번 UT 결과의 인사이트를 바탕으로, 사용자에게 더 나은 경험을 제공하기 위한 기능 개발이 진행되었어요.
UT 전에는 유아이볼의 레퍼런스를 어떻게 활용하실지 가늠하기 어려웠지만, UT를 통해 사용자분들의 활용 방식과 선호하시는 다양한 부분들에 대해 명확히 파악할 수 있었어요. 이렇게 UT의 중요성을 다시 한번 깊이 느낄 수 있었던 기회였어요.
한 번의 UT 결과가 확실한 정답이 될 수 있는 것은 아니지만, 앞으로 멈추지 않고 계속해서 검증하고 개선한다면 분명 많은 분들께 좋은 경험을 전달드릴 수 있을 것이라 생각해요.
만약 플러그인 개선이 필요하다고 느끼신다면, 언제든지 말씀해 주세요. 소중한 피드백을 바탕으로 더 나은 경험을 제공해 드릴게요. 감사합니다!
유아이볼은 국내 최대의 UI/UX 패턴을 학습할 수 있는 플랫폼으로 국내에 MVP 버전으로 출시한 지 3개월 만에 사용자가 월 6,000명이 넘었고 현재는 30,000명이 넘는 사용자가 이용하고 있어요.
유아이볼 플러그인 다운로드 : https://www.figma.com/community/plugin/1416283003258937842/uibowl
유아이볼 링크 : https://uibowl.io/
더 빠르게 아티클과 앱 업데이트 소식을 듣고 싶다면 오픈채팅방 링크로 들어오세요.
박상훈
차별화된 '제품'을 만드는 것은 큰 의미가 없습니다.
차별화된 '가치'를 만들어야 의미가 생깁니다.
제품의 색상이 다르다는 것 그 자체는
큰 의미가 없습니다.
그 색상이 고객의 피부를 더 밝게 만들어주고,
이성에게 매력적인 사람으로 보이게 만들어준다면
그때부터 의미가 생깁니다.
우리 제품에만 있는 채팅 기능도
큰 의미는 없습니다.
그 채팅 기능이 고객사의 업무 효율을 두 배 이상 높여주고,
더 적은 인원으로 높은 매출을 달성할 수 있게 해주면
그때부터 의미가 생깁니다.
'그냥 다른 것'은 차별화가 아닙니다.
'고객에게 더 큰 이익을 가져다 주는 것'이
진짜 차별화입니다.
단지 다른 곳에는 없기 때문에,
우리만의 특별함을 위해 뭔가를 만들기 전에
딱 10분만 멈추고 고민해보세요.
'이걸 완성하면 고객한테 어떤 이익이 생길까?'
'1:1로 고객을 만나 그 이익을 이야기하면 고객은 돈을 낼까?'
이렇게 가치를 중심으로 생각하면,
그냥 '달라 보이기 위해' 하는 일을
획기적으로 줄일 수 있습니다.
이재일
안녕하세요 드로우하타 개발자 이재일입니다.
혹시 이번 디콰 뉴스레터를 보셨나요?
저희 팀 주연님의 글이 디콰 뉴스레터 아티클 챕터 첫글로 올라왔더라구요. (오예)
스스로 내린 결정과 그 이유를 공유하는게 가장 좋다는 생각이 들었습니다.
그래서 이번 주제는 드로우하타의 개발스택 입니다.
드로우하타의 개발스택은 다음과 같습니다.
1. 앱 개발: React Native
2. API: NestJs
3. 관리자: NextJs
4. DB: supabase
5. 앱 관리: firebase
6. 배포: oracle cloud, docker
그 중에서도 가장 고민되었던 지점인 앱개발 스택 고르기와 서버 스택 고르기에 대해서 말씀을 드리고자 해요.
저에게 처음 개발을 가르쳐주었던 분이 하신 말씀이 있는데요.
"자바스크립트만 알아도 먹고 산다."
하지만 당시에 저는 비전공자에 모르는 것도 많고 욕심도 많아서 javascript 말고도 python, java 도 같이 찍먹해보면서 웹개발, 서버개발... 이것저것 잡다하게 시키면 하는 개발자1로 일하다가 백엔드와 프론트 중 결정의 갈림길에서 프론트를 골라서 여기까지 온 것이죠.
그렇게 저에게 익숙한 스택인 React와 Typescript를 기본적으로 염두해두고 스택을 쌓아나가기 시작했습니다.
1. React Native VS Flutter
보통 앱개발을 시작하시려는 분들은 두 가지 중에 고민을 많이 하게 되는데요.
저는 개발이 처음이다 하면 Flutter
이미 React, TS 개발을 해봤다 하면 React Native 라고 말씀드리고 싶습니다.
왜냐하면 개발문법을 어차피 익히면서 개발을 해야하기에 아예 처음 배워야하는 입장이라면 저는 Flutter를 추천드리고 싶어요. 하지만 Typescript를 안다면 React Native가 괜찮은 선택이라고 말할 수 있습니다.
저 또한 이미 React Native의 고통스러운 ios, android 설정을 이미 경험해보았기 때문에
처음에는 Flutter로 개발을 했었습니다.
하지만 Flutter에서도 동일하게 배워야하는 Dart 문법과 디자인패턴 등은 굳이? 라는 생각이 들었어요.
거기에 가장 힘들었던 건 계속해서 Nesting 으로 들여써야하는 문법 구조도 저에겐 힘들었죠...
그러다보니 Flutter의 강점인 ios, android 의 보다 쉬운 설정을 체감하기도 전에 코딩 단계에서 너무 힘들었습니다 ;
그래서 flutter로 개발하던 것을 멈추고 다시 React Native로 돌아왔습니다.
2. Node (NestJS) VS Django VS spring boot
대한민국에서 서버 라고 하면 거의 java의 spring 이죠.
또 강력한 관리자 사이트를 지원해주는 Django도 있구요.
하지만 저는 Node 진영의 NestJs 를 선택했습니다. 분명히 불안한 부분도 있었지만, 아무래도 이미 Node로 서비스를 운영하는 회사들이 많다는 생각이었습니다.
대표적으로 인프런 서비스도 NestJs로 개발되고 있고, 배민에서도 NestJs를 새로운 백엔드 표준으로 내세웠다는 글을 보고나서 나도 해도 되겠다는 생각을 했어요.
비록 현업에서 Node 서버를 운용하는 걸 경험하지 못했고, 단일쓰레드 등 불안한 부분도 있지만, 커뮤니티의 도움을 받아 어찌저찌 해결할 수 있지 않을까 하는 마음입니다.
거기에 아직 node 서버가 부하를 감당할 수 없을 만큼의 서비스가 아니기 때문이에요. 비록 스크립트 언어와 컴파일 언어 같은 언어별 특징에 의해서 성능차이가 존재하지만, 사용자가 아직 0명인 서비스는 뭘로 만든들 (...)
사실 React Native를 선택한 시점부터, 모노레포 를 이용해서 앱과 관리자, 서버까지 하나의 코드베이스에서 관리하고 싶기도 했구요. 만드는 사람이 쉽고 편하게 만들 수 있어야 합니다.
개발자 별 프로젝트 스택 추천
이번 프로젝트를 통해 깨달은 점은, 개발 스택 선택에 있어 가장 중요한 두 가지 요소는 '익숙함'과 '개발 편의성'이라는 것입니다.
이를 바탕으로 대상별 추천 스택을 정리해보았습니다:
대상 | 앱 | 서버 |
프론트엔드 개발자 | React Native | NestJS |
백엔드 개발자 | Flutter | Django or Spring boot |
첫 개발, 비 웹개발자 | Flutter | Django |
왜 이렇게 추천하냐면
가장 중요한 건 익숙한 기술이 있느냐 하는 것이었구요.
두 번째로 중요한 건 개발하기 편한가 였습니다.
React Native와 NestJs는 타입스크립트 진영으로 VScode 하나만 이용하면 되지만,
Django와 Spring boot는 아무래도 Intellij나 Pycharm을 이용해야 하죠.
거기에 Flutter도 ide를 사용해야 하니 Vscode를 같이 이용하는 것보다는
같은 회사에서 출시한 Android Studio를 이용해야 좀 더 편리한 것 같습니다.
추가로 첫 개발을 하시는 분들은 Flutter랑 Django를 추천 드리는데요.
아무래도 Spring과 그 영향을 받은 NestJs는 모두 견고하게 작성을 해야하다보니 코드량이 늘어나서 러닝커브가 꽤 높다고 생각하구요.
Django는 python의 쉬운 문법과 더불어 관리자도 어느정도 지원을 해주기 때문에 더 유리한 측면이 있다고 생각합니다.
React Native는 사실 Typescript와 ios, android의 언어를 모두 다루게 되다보니...
로직작성이 아니라 설정에 더 많은 시간을 소비하게 될 때가 많아요. 🥲
그래서 처음 개발하시는 분들에게는 flutter와 Django로 앱과 서버를 구성하는 편이 더 좋다고 생각합니다.
마치며
글에는 담지 않았지만, 모노레포 설정도 NX로 해보려고 하다가 안되서 turbo로 변경하고,
supabase edge 이용해서 서버리스로 구축하려다가 코드 구성 등이 어려워서 다시 백엔드로 구축했어요.
또 supabase의 auth 부분을 이용해서 oauth를 설정해야하다보니 그에 맞게 orm 세팅하는 부분도 있었고,
번역키를 자동화 하고 싶어서 데이터 저장을 구글시트에 할지 데이터베이스에 할지 고민하다 리팩토링과 롤백을 반복했던 시기도 있었습니다.
그렇지만 결국 돌고 돌아서 무사히 정착한 것 같은 기분이 듭니다.
그래도 아직 반영하지 못한 모니터링과 로깅, 언젠가 벗어나야할 oracle cloud 프리티어 환경,
개발 및 스테이징 서버 구축 등의 미션도 남아있어요.
깨달은 것은 다음으로 걸어가기 위해선 현실에 한발자국 딛고 있어야 한다는 것이에요.
예전에 부동산 유튜버 하시는 렘군님 영상을 봤던게 기억에 남는데요.
본업에 80%의 시간, 노력을 쏟고, 자신이 목표로 하는 것에 20의 시간, 노력을 쏟으라고 했어요.
이게 맞는지 정확히 기억이 안나는데 80 20 법칙을 활용해서 하나씩 넘어가는 방법을 사용해야 한다고 하더라구요. (파레토 법칙)
저는 점프점프 하면서 가야 빨리 간다고 생각을 했는데요. 언젠가부터 제자리 점프를 하고 있는게 아닌지 했던 생각이 들었어요. 그래서 본인이 제자리 쳇바퀴를 돌고 있다고 느끼시는 분이 있다면 이 방법을 적용해보는 것을 추천합니다!
이제는 한걸음 한걸음 나아가고 싶어요.
인생도 길게 보려고 하구요.
읽어주셔서 감사합니다 :)
임버드
(겨우겨우) 뉴스레터 구독자 500명 모은 방법 3가지
안녕하세요! '1인 가구 필 수 앱(이 되고 싶은), 브로콜리' 출시를 앞둔 임버드입니다.
'500명이 뭐라고!' 할 수 도 있겠지만 아무래도 0부터 시작하는 것보다는 좋을 것 같아 공유하게 되었고,
대단하지 않은 성과지만 1년간의 회고정도로 읽어주시면 감사하겠습니다.
(지난글도 함께 보면 좋아요! 프러덕트를 만들기전 뉴스레터 운영이 좋은점 3가지 )
1. 당근마켓 광고진행하기
뉴스레터 플랫폼은 구독자를 모으는 게 진짜 어렵더라고요 ㅜㅜ
구독자가 없기를 약 2주, 그럼에도 뉴스레터는 운영해야 한다는 게 현타가 왔고 ‘돈이라도 써야겠다’는 생각이 들었습니다. 광고를 직접 돌려본적은 없었지만 “영등포” 1인 가구를 위한 생활정보를 큐레이션하고 있었기 때문에 아무나 구독하는 건 '무의미하겠다'는 판단이였습니다.
그래서 메타나 구글보다 로컬에 핏한 채널인 당근마켓 광고 플랫폼을 선택하게 되었습니다. (사실 메타나 구글을 시도는 해봤는데 복잡해서 포기 …)
10만원의 예산으로 시작했는데요 생각보다 빠르게 소진되어 하루 만에 43명의 구독자가 발생하였습니다.
놀라운 결과에 90,420원 비용에서 광고를 멈추었지만 총 클릭 411회에 10% 정도의 전환율로 비용대비 효과가 있는 채널이 되었습니다. 그 뒤로도 지역을 공개할 때마다 5~10만 정도의 예산을 투입해 추가 구독자를 모집하는 용도로 당근마켓 광고를 사용했습니다.
2. 네이버 블로그 운영하기
비용대비 많은 구독자를 모았지만, 오가닉 구독자는 늘지 않았습니다.
뉴스레터내에서 친구추천 이벤트를 2달간 운영해보았지만, 추천은 1명 뿐인 슬픈 상태였습니다.
'급할 거 뭐 있나? 천천히 네이버 블로그나 운영해보자' 싶은 마음이 들었습니다.
그 후로 매주 뉴스레터 콘텐츠를 블로그에 옮기고 있고 블로거들에게 '이웃신청'이나 '좋아요', '댓글'로 관계를 유지하여 마케팅을 진행했습니다. (순수 노가다 ...)
1000명의 이웃은 약 2주 만에 빠르게 만들었지만 궁극적으로 소셜이 목적이 아니었기에 이웃과 소통하는 건 매력이 없었고, 의무적인 리액션들로 비용대비 효과는 0에 가까웠습니다.
이런방식으로 조회수를 모으는 것보다 '메인타겟 사용자'가 검색결과에서 유입되도록 주제를 넓히는 방향으로 계획을 변경하였습니다.
'1인 가구'에서 추출한 '#1인 #혼자'라는 키워드를 발굴하여 '혼자 가기 좋은 카페, 개발자 없이 혼자 만든 웹사이트, 1인 법인 만들기' 등의 콘텐츠를 운영하였습니다.
24년 1월을 기점으로 이웃조회수보다 외부유입이 더 늘어나 원하는 방향으로 되었습니다.
월 천의 조회 수가 많은지? 적은지? 이것이 소식지 구독에 어떤 도움이 되었는지? 명확하게 판단하기는 어려웠지만, 그때 이후로 광고 없이도 구독자가 조금씩 늘기 시작해서 약 50명의 구독자를 더 모을 수 있었습니다.
제가 시간이 많아서 꾸역꾸역 야금야금 할 수 있는 방법이었는데요, 성실하고 시간이 많이 필요한 채널이어서 극적인 효과는 없었습니다. 다만 추가로 무언가 할 수 있는 채널을 구축했다는 것에 만족하고 있습니다.
(뉴스레터를 운영하며 처음 개발하고 출시까지한 토이 앱 와나리스트가 있는데요 이 앱도 블로그로 마케팅을 진행하였고 현재까지 하루에 3명 정도 꾸준하게 가입하고 있습니다.)
3. 플랫폼 피쳐드되버리기
그러던 어느날 구독자가 터졌습니다.
하루에 10명이상 구독 자가 늘었고 드디어 사람들이 알아주는구나 착각했습니다
스티비에서 운영중인 '비레터'에 피쳐드 되었더라구요....인플루언서나 플랫폼의 파워를 느낄수 있었습니다.
“영등포”라는 지역한계가 있음에도 약 1주간 100명이상이 구독을 해주었는데요
혼자힘으로 한명한명 모으는게 지칠때쯤 이여서 그런지 기분이 좋았습니다.
https://beletter.stibee.com/ (비레터)
https://somako.stibee.com/ (소소레터)
이렇게 뉴스레터로 꾸역구역 500명의 구독자를 모았을때쯤이였어요
맨땅에 프러덕트를 만들때와는 다른 근자감이 생기더라구요
'뭐라도 한번 해볼까??!'라는 마음이 생겼 고 '앱개발도 직접해볼까?' 라는 지경에 이르렀습니다.
다음 글은 "개발자없이 우당탕탕 프러덕트 만들기" 입니다.
팔로워, 좋아요, 업보트하고 다음 이야기를 기대해주세요
신다빈
안녕하세요, 사초생 마케터입니다.
지난 메이커로그에서 팀 구성과 사초생 서비스 기획 아이데이션 과정에 대해 이야기했었는데요.
오늘은 지난 메이커로그에 이어서 약 두달 간 준비한 서비스 모델을 변경한 이유가 무엇이었는지 이야기해보려고 합니다.
지난 글은 아래 글에서 확인할 수 있어요!
변경 전 초기 모델은 사회초년생들이 어려워 하는 사회생활 고민에 대한 정보를 제공하는 서비스였는데요.
서비스를 고도화하는 과정에서 한 가지 의문이 생겼습니다.
사회생활 정보가 자주 업데이트되는 것도 아닌데..
정보만 제공하면 한 번 확인하고 그 이후엔 접속 안하는 거 아니야?
초기 서비스는 카드 형식을 통해 사회 생활 정보를 전달하는 것이 주된 모델이었기 때문에
사회생활 정보만 제공하게 되면 일회성으로 이용하는 유저들이 대다수일 것이라고 생각했습니다.
그 외에도 추가적인 문제점을 발견할 수 있었는데요.
사회생활 정보로 활용할 DB는 어떻게 쌓을 수 있을까?
팀원들이 일일이 카테고리별 사회생활 정보를 찾고 가공해야 하기 때문에 리소스가 너무 많이 들어감
필요한 리소스에 비해 예상되는 유저 이용수가 적다는 문제
주관적인 내용을 사회생활 정보로 제공하게 되지는 않을까?
블로그나 기사 글을 가공하여 카드를 통해 사회생활 정보를 제공하는 것이기 때문에 정답이 아닌 정보를 제공하게 될 수도 있다는 점이 우려
이러한 문제점들을 발견했고, 저희는 서비스 MVP 모델을 바꾸기로 했습니다!
저희는 위의 여러 문제점 중에서, "사회생활 정보에는 정답이 없다"는 것에 초점을 맞춰
그럼 사람들이 집단지성으로 투표를 통해 나와 비슷한 유저는 어떻게 생각하는지 알아보도록 하면 어떨까? 하는 생각으로 서비스 모델을 변경하게 되었습니다.
초기에는 관리자가 투표 주제를 미리 DB에 저장해두지만,
유저가 더 쌓이면 투표를 자유롭게 업로드할 수 있도록 해 과다한 리소스 투입 우려에서도 벗어날 수 있었고요!
사초생에서 내세우는 가장 큰 차별점은 나와 같은 집단의 의견을 확인할 수 있다는 점인데요.
기획 초기 단계에서, 설문조사와 인터뷰를 진행하며 유저 타입 별로 서로 다른 니즈를 가지고 있다는 점을 알 수 있었습니다.
학생
취업준비생
1~3년차 직장인
기타
그래서 다음과 같이 유저 타입을 구분해, 투표 결과에서 나와 비슷한 유저는 어떤 선택지를 많이 선택했는지 확인할 수 있습니다!
저희 서비스는 9월 말~10월 초 릴리즈를 목표로 계속해서 준비중인 단계인데요
많은 관심 가져주시면 감사하겠습니다 :)
사초생
사회초년생 집단지성 투표 플랫폼
픽앤팝
안녕하세요.
농구 커뮤니티를 만드는 "픽앤팝"입니다.
픽앤팝은 초기에 노코드 툴을 사용하여 개발을 진행하였습니다.
노코드 툴로 작업한 화면
노코드 툴로 초기에 빠르게 레이아웃을 잡고 기능을 구현하기에는 편리하였지만 원하는 것들을 만들기에는 한계가 있었습니다. 그래서 인하우스로 같이 개발하기로 결정하였습니다.
사용할 프레임워크 정하기
먼저 백엔드와 프론트엔드에서 사용할 프레임워크를 정하기로 하였습니다. 파이썬 개발자이다보니 BE는 django와 fastapi, FE는 최근에 사용해본 Next.js를 사용하기로 하였습니다. django에서는 model과 accounts를 사용하고 fastapi는 빠르게 api를 제공하기위해 2개를 동시에 가져가도록 하였습니다.
개발 주기
1주일에 최소 1개의 기능을 개발하고자 하였습니다. 일이 바쁜 경우에는 그 다음주에 최대한 개발하지 못했던 기능들을 개발하는 식으로 유연하게 가져갔습니다. 정말 즐기자는 식으로 "픽앤팝"을 만들고자 하였기에 스트레스를 주지 않는 선에서 진행하기로 하였습니다.
초기에는 지라로 커밋을 관리하였는데 지금은 그렇지 못하고 있습니다. 이 부분은 반성할 부분이네요 ㅠ.ㅠ
테스트 진행하기
테스트는 기본적으로 테스트 코드로 1차 검증을 진행하고, 로컬에서 직접 구현해보고 있습니다. 가끔 생각지도 못한 곳에서 오류가 발생하기에 여러번 진행하고 있습니다.
AWS로 인프라 구성하기
현재는 개발서버만 만들어서 진행을 하고 있고 9월 30일전에 배포서버와 테스트 서버를 구성하여 CI/CD까지 연결하려고 합니다.
4단계를 거치면서 현재는 아래와 같은 형태로 개발되고 있습니다. 정기 회의를 거치면서 필요한 기능들이 추가되고, 디자인도 수정되면서 어느정도 만족할 단계까지 왔습니다. 이제는 막판 스퍼트를 내어 30일에 성공적으로 배포하도록 노력하고 있습니다. ^_^
9월 19일 목요일 픽앤팝
김도경
캐치볼은 사회인 야구 혹은 대학 동아리 야구인을 위한 앱 입니다.
현재는 최소 기능만 구현하여 빠르게 출시했고 피드백을 통해서 완성해 나갈 예정입니다.
주요 기능
1. 경기 성적 저장
본인의 시합 성적을 기록 할 수 있어요
타자, 투수, 주루, 수비 개별로 자세히 기록 할 수 있어요
주요 기록 지표를 계산하여 보여줘요
2. 도구
타율&OPS 계산기
방어율&WHIP 계산기
볼 카운터: 투구수를 셀 수 있어요
앞으로 추가 될 기능
1. 클라우드 저장소
회원가입을 한 유저는 클라우드 저장소 이용이 가능하며 새 기기에서도 기존 데이터가 유지됩니다.
2. 팀 & 선수 프로필 추가
유저들은 본인의 팀을 서버에 추가 가능하며 팀원들은 선수 프로필을 만들어 팀에 가입 가능
각 팀의 기록 및 성적 확인 가능
팀에서의 개인 성적 확인 가능
4. 랭킹 시스템
추가된 팀&선수들의 성적으로 랭킹 시스템 도입
3. 기록지 시스템
사회인 야구팀이 스스로 시합을 실시간 기록 할 수 있도록 전자 기록지 기능 제공
캐치볼
사회인 야구를 즐기는 사람들을 위한 야구 기록&도구 앱
노하우 정민호
💸[마이머니] 내 아이디어로, 이번 달 지원해볼 수상금있는 공모전
👩🏻💻투자 말고, 빠르게 탈 수 있는 사업 자금 혜택,,
단기 자금 지원사업도 정리해주는 곳 어디 없나?
✔한 주마다, 담당자가 선별한 단기 자금 지원사업
✔ 업데이트 된 지원사업도 꼼꼼히!
✔[최대 000만원] 정보까지 한 눈에 확인하세요!
🔎[마이머니] 서비스 1분 신청하러 가기
이지섭
아래와 같은 조건을 가진 법인을 찾습니다.
혹 아래와 같은 회사를 알고 계시는 분께서는 추천 부탁드립니다.😀
프로젝트 요약
•본 프로젝트는 대상회사의 신사업 추진 관련 IT 기업 혹은 사업부를 인수하는 건임
인수 조건
•대상 회사는 IT 관련 상장사의 자회사로 솔루션·SI·CRM·ERP 업을 영위하는 회사임.
•신규 사업 진출시 공급자(셀러)를 위한 시스템 구축을 위해 OMS 시스템을 인수하여 빠르게 접목시키기 위해 인수 희망
•이커머스 OMS(주문관리시스템) 서비스 보유 기업 또는 사업부 인수 희망
•20개 수준의 주요 이커머스 API 연동 희망 (필수 조건은 아님)
매각에 관심 있으신 법인이라면 편히 연락바랍니다.
E-mail : support@dealplus.io
Web : https://dealplus.io
Chat : dealplus.channel.io
회계사들이 만들어가는 투명한 스몰딜 문화
인수할 기업을 찾고 계신다면 👉딜플러스
빠른 매각을 원하신다면 👉딜플러스
👍 매물 정보를 받아보고 싶으시다면 팔로우해주세요!
김주형
오늘도 추석을 핑계로 개인적인 일을 좀 처리하고 왔습니다
릿코드 문제는 아직 못 풀었습니다
오늘은 성장력 0.8, 집중력 45%를 기록했습니다
부족한 점을 보완하기 위해 내일은 최고기록인 성장력 11, 집중력 91% 유지와 릿코드 submit 5회에 도전하겠습니다
구민
그라운드 플립에서 걷기와 자동차를 타는 것을 구분하는 방법
최근 그라운드 플립이라는 땅따먹기 서비스를 개발하였다. 이 프로젝트는 사용자가 지나간 영역을 사용자의 영역으로 만들어주는 프로젝트이다.
위 사진과 같이 사용자가 지나간 영역에 해당하는 사각형 만큼 지도에 색이 칠해진다.
도입 배경
현재 서비스를 개발해 배포한 상황이다. 사용자 유입을 위해 이벤트를 열려고 하고 있다. 현재 우리 앱에는 사용자가 획득한 땅의 개수를 기반으로 하는 랭킹 시스템이 존재한다.
이 랭킹 시스템을 이용해서 1등 부터 3등 까지 상품을 주는 이벤트를 기획중이다. 상품이 걸린 만큼 땅을 차지하는 로직이 누구에게나 공정해야한다고 판단했다.
우리 서비스는 땅따먹기라는 게이미피케이션 요소를 도입하여 걷기나 달리기를 장려하는 앱이다. 하지만 상품을 위해 자동차나 킥보드를 사용해서 앱을 사용하면 단 시간에 엄청많은 땅을 획득할 수 있다. 이렇게 되면 걸어서 땅을 획득하는 사용자들이 공정한 경쟁을 할 수 없기때문에 자동차나 킥보드를 타고 사용하는 행위를 막아야했다.
그래서 클라이언트 측에서 걷기나 달리기를 구분하는 로직을 개발하기로 했다!
개발 환경
개발 환경은 Flutter 를 사용한다. 위치 정보, 즉 GPS 데이터를 얻어오기 위해 Flutter 의 location 패키지를 사용했다.
이 글은 걷기나 달리기 행동을 구분하는 로직에 대한 설명글이다. 때문에 땅따먹기 로직이나 다른 로직보다는 걷는 상태와 자동차를 탄상태를 구분하는 로직에 집중하여 설명한다.
속도 기반 구현
로직
처음에 어떻게 사람이 실제 움직이는 것과 탈 것을 사용하는 행위를 구분할지 생각해보았다. 그러다가 포켓몬 고의 예시를 살펴보니 10.5km/h 이상으로 움직이면 인식을 안한다고 들어서 이 방법을 적용해보기로 했다.
Flutter 의 location 패키지는 위치 정보를 반환 할 때 속도 값을 같이 반환한다. 반환값인 LocationData 를 살펴보면
/// In meters/second
///
/// Will be null if not available.
final double? speed;
speed 값이 있다. 이 speed 값은 m/s 로 나오기 때문에 10.5 km/h 와 비교하려면 3.6 을 speed 에 곱해야한다.(3.6 을 곱하면 km/h 로 환산 가능.) 그 결과 아래와 같이 코드를 작성했다.
void _trackUserLocation() {
_locationService.location.onLocationChanged.listen((newLocation) async {
if(newLocation.speed * 3.6 <= 10.5) {
await occupyPixel();
}
});
}
결과
그 결과 테스트 하기 위해 버스와 지하철을 타고 앱을 실행해보았더니 적용하지 않았을 때 보다는 확실히 사람이 움직이는 행위를 구분해내었다.
한계
하지만 문제점이 꽤나 많았다. 문제점 들은 다음과 같았다.
터널을 진입한 경우 땅이 차지되는 문제
지하철 탑승시 GPS 가 많이 튀어 현재 위치한 곳과 멀리 떨어진 곳에 방문되는 문제
자동차의 속도가 10.5km 안으로 줄어들 때 땅이 차지 되는 문제
생각보다 땅이 획득되는 구간이 많아서 제대로 부정행위를 방지 할 수 없다고 판단해서 이 문제들을 개선하기로 했다!
원인 파악
우선 왜 위와 같은 문제점들이 발생했는지 원인을 분석 해보았다.
1. 터널 진입시, 지하철 탑승시
터널 진입시와 지하철 탑승시의 속도를 확인해보았다.
-1 이 나온다?
황당했다,,,
찾아보니 GPS 를 잘 잡지 못하는 경우에는 속도를 -1로 표시하는 것을 알았다. 속도가 -1 로 측정되니 항상 기준 속도인 10.5km 보다 작아서 땅이 획득 된 것이었다. 지하철의 경우도 GPS 가 이곳 저곳으로 튀는데 속도 값은 -1로 나오니 땅이 획득 되었다.
결국 속도를
location패키지에 의존하지 않고 직접 계산 해야할 필요가 생겼다.
2. 자동차의 속도가 느려지는 경우
이 부분은 자동차의 신호 대기나 코너를 돌면서 속도가 줄어들며 발생한다. 속도가 10.5 km 아래로 줄어들면 그 순간에 땅이 점령되었다.
단순히 10.5km 이하 일때 가 아니라 전체적으로 자동차가 잠시 느려지는 것을 감지할 필요가 있었다.
하나씩 해결해보자.
1. 직접 속도 계산하기
우선 GPS 가 약한 곳에서도 처리 할 수 있게 위치를 기반으로 직접 속도를 계산 해보았다.
현재 위치와 가장 최근의 위치를 사용하여 속도를 구한다. 이전 위치들에 접근하기 위해 이전 위치를 저장했다.
위 그림처럼 좌표값과 좌표에 방문한 시간만 있으면 속도를 쉽게 구할 수 있다. 다만 여기서 위경도를 기준으로 거리를 구하는 것이 좀 복잡하다. 지구가 둥글기 때문에 일반 적인 평면을 기준으로 계산하면 안된다. 자세한 내용은 설명하면 너무 길어서 구글에 찾아보길 바란다.
그해서 두 좌표사이의 거리를 소요시간으로 나누면 속도를 구할 수 있다.
calculateSpeed(LocationData previousLocation, LocationData currentLocation) {
final timeInSeconds =
(currentLocation.time! - previousLocation.time!) / 1000;
final distanceInMeters = calculateDistance(
previousLocation.latitude!,
previousLocation.longitude!,
currentLocation.latitude!,
currentLocation.longitude!,
);
final speedInMps = distanceInMeters / timeInSeconds;
final speedInKmH = speedInMps * 3.6;
return speedInKmH;
}
double calculateDistance(
double startLat,
double startLng,
double endLat,
double endLng,
) {
const double earthRadius = 6371000;
final double dLat = degreesToRadians(endLat - startLat);
final double dLng = degreesToRadians(endLng - startLng);
final double a = (sin(dLat / 2) * sin(dLat / 2)) +
(cos(degreesToRadians(startLat)) *
cos(degreesToRadians(endLat)) *
sin(dLng / 2) *
sin(dLng / 2));
final double c = 2 * atan2(sqrt(a), sqrt(1 - a));
return earthRadius * c;
}
double degreesToRadians(double degrees) {
return degrees * (3.141592653589793 / 180);
}
위와 같은 코드로 직접 좌표간의 속도를 구했다.
2. 주행시 잠시 느려지는 구간 가려내기
우선 자동차가 느려지는 구간을 가려내기 전에 직접 자동차를 타서 속도 데이터를 수집해봤다. 약 30분 간의 주행 데이터이다. 가로 축은 시간, 새로 축은 속도(km/h) 를 의미한다.
그 결과 위와 같은 그래프가 그려진다. 위 빨간선이 10.5 km/h 에 해당하는데 이 선 밑으로 속도가 떨어지는 구간 마다 땅이 먹어진다.
이를 막기 위해 속도를 판단할 때 순간의 속도를 판단하는 것이 아니라 특정 구간의 속도를 판단해보기로 했다.
속도가 감소하는 부분을 살펴보면 보통 50초 사이에 감소되는 것을 발견했다. 이 구간을 같이 판단하면 일시적으로 속도가 줄어드는 구간을 판단할 수 있지 않을까 하는 생각이들었다.
GPS 는 1초 간격으로 수집되기 때문에 약 1초간격으로 위치와 속도가 기록된다. 그래서 내가 세운 로직은 현재 속도가 낮아도 최근 50초 사이의 속도 중에 사람이 내지 못할 속도가 기록되었다면 속도가 감소된 걸로 파악되게 로직을 생각해봤다.
사람이 내지 못할 속도는 25 키로로 정했다. 우사인 볼트 같은 사람의 순간 최고 속력은 빠르다고 40km/h 에 가깝다고 하지만 일반 사람들이나 마라톤 선수들의 평균속도가 20 키로 정도라고 하기 때문에 그것보다 살짝 높게 25키로를 기준으로 잡았다.
그 결과 위 그림처럼 속도가 기준 속도보다 낮은 경우에도 이전 50초 사이의 기록중에 25를 넘는 기록이 있기 때문에 자동차를 탄것으로 인식된다.
주의점
위 방법에서 가장 주의할 점은 얼마만큼의 구간을 같이 확인 할 것인지이다. 위에서는 50초로 예를 들었지만 구간의 길이만큼 성능이 차이날 것이라고 예상했다.
만약 50초보다 더 짧으면 이전 주행 기록이 정상적으로 감지가 안될것이다.
50초보다 너무 길다면 자동차를 내려서 걷는데도 이전 기록이 영향을 끼쳐 걷는 것으로 인식을 못할 것이다.
때문에 적당한 구간을 설정해주어야되는 어려움이 있었다. 결론 적으로 나는 50초를 기준으로 테스트를 해보았다.
또한 단 하나의 기준치를 넘는 기록을 가지고 판단하면 안된다. 왜냐하면 GPS가 가끔씩 튀는 구간이 있어서 걷는 중이라도 속도가 급작스럽게 높은 수치가 찍힐 수 있다. 때문에 적당한 threshold 를 잡아 적용해야한다. 나는 5개를 기준으로 잡았다.
결과는?
앞서 단순히 현재 속도를 기준으로 판단하는 로직보다 걷는 것을 잘 구분한다.
터널에서는 땅이 점령이 되지 않는다.
지하철에서 튀는 부분도 급작스럽게 튀면 속도가 빠르게 찍히기 때문에 점령되지 않는다.
50초 안에 느려지면 자동차로 인식하고 땅이 점령되지 않는다.
하지만 여기에도 미쳐 발견하지 못한 문제가 많았다…
차가 막히면 어떻게 될까….?
실제 테스트를 위해 버스를 탑승하였는데 일반적으로는 잘 구분이 되었다. 하지만 차가 막히니 차가 지나가는 땅을 모두 점령해버렸다…
이유는 간단하다. 차가 막히면 지속적으로 기준점보다 낮은 속도를 계속 유지한다. 때문에 걷기랑 똑같은 데이터로 측정된다.
결국 속도기반으로 구분하는 것은 한계가 있다라는 결론에 도달했다. 다른 데이터를 기준으로 구분 할 필요가 있었다.
가속도 센서
어떤 데이터를 기준으로 나누어야 효과적으로 구분할 수 있을지 곰곰히 고민해봤다. 만보기가 떠올랐다. 만보기는 사람의 걸음수를 측정한다. 어떻게 측정할까? 사람이 움직일때마다 가속도 센서등을 사용하여 움직임을 측정한다. 이는 오직 사람이 걷거나 뛰면서 몸이 흔들리며 핸드폰이 흔들려야 측정된다.
“자동차에 탄 경우에는 어떨까?”
자동차에 탄사람은 걷거나 뛰는 것 만큼 흔들리지 않는다!
결론은 이 흔들림을 기준으로 구분해보기로 했다!
구현하기
Flutter 의 pedometer 패키지를 보면 PedestrianStatus 이라는 데이터를 제공한다. 이것이 걷는 중인지 정지상태인지 pedometer 에서 계산해주는 데이터이다. 이를 활용하면 쉽지만 꽤 정확하게 걷는 상태와 걷지 않는 상태를 구분해낼 수 있었다.
void _trackUserLocation() {
_locationService.location.onLocationChanged.listen((newLocation) async {
_locationService.updateCurrentLocation(newLocation);
if (walkingService.isWalking()) {
await occupyPixel();
}
});
}
class WalkingService {
static final WalkingService _instance = WalkingService._internal();
static const _walking = 'walking';
static const _stopped = 'stopped';
static const _unknown = 'unknown';
String pedestrianStatus = _stopped;
late Stream<PedestrianStatus> _pedestrianStatusStream;
WalkingService._internal();
factory WalkingService() {
return _instance;
}
init() {
// 걷기 상태가 변경될때마다 상태를 업데이트 한다.
_pedestrianStatusStream = Pedometer.pedestrianStatusStream;
_pedestrianStatusStream.listen((PedestrianStatus event) {
String status = event.status;
pedestrianStatus = status;
});
}
@override
isWalking() {
if (pedestrianStatus == _unknown) {
return false;
} else {
return pedestrianStatus == _walking;
}
}
}
결과
결과는 매우 잘 작동했다!
위에서 문제가 되었던
터널에서 땅 점령 문제
지하철에서 점령 문제
자동차에서 속도가 느려질때 점령 문제
차가 막혀서 계속 속도가 느릴때 점령 문제
문제들 모두 해결되었다. pedometer 가 자동차 정도의 흔들림은 걷는 것으로 인식하지 않았다.
위 영상은 자동차를 타고 실제로 로직을 개선한 버전과 개선하지 않은 버전을 동시에 녹화하여 빨리 감기한 영상이다. 개선전 영상은 속도가 느려질때 마다 땅이 점령되는데 반해 개선 후 영상은 느려져도 점령되지 않는 것을 확인할 수 있다!
한계
완벽할 것 같은 이 방법에도 문제점이 있었다.
차 안에서 강제로 핸드폰을 흔들면 걷기로 인식되어 땅이 점령된다…
일반적으로 차안에서 강하게 핸드폰을 흔들 사람은 별로 없을 것이라고 예상되지만 완벽한 공정성을 위해서는 눈감고 넘어갈 수 없는 문제였다.
개선하기
사실 이 부분은 간단하게 해결할 수 있는 것이 위에서 속도 기반으로 구분하는 로직을 만들지 않았는가? 이 로직을 적절히 합치면 해결할 수 있다.
속도 기반으로 걷는 중인지 자동차를 타고 있는 중인지 체크한다.
가속도 센서 기반으로 걷는 중인지 걷지 않는 상태인지 체크한다.
위 두 방법 모두 걷기로 인식하는 경우만 걷기로 인식한다.
몇가지 예를 통해 결과를 예측해보자!
속도가 빠른 자동차안에서 핸드폰을 흔들고 있다고 가정하자. 가속도 센서 기반에서는 걷기라고 인식하지만 속도 기반에서는 자동차라고 인식하기 때문에 걷기라고 인식하지 않는다.
출근길 차가 막히는 버스를 타고 있다고 가정하자. 속도 기반에서는 속도가 느려 걷기라고 인식하지만 가속도 센서 기반에서는 움직이지 않으니까 자동차라고 인식하기 때문에 걷기라고 인식한다.
이제 걷는 상태와 자동차등을 탄 상태를 매우 잘 구분하는 로직이 완성되었다. 이를 통해 보다 공정한 경쟁 시스템을 만들 수 있다!!!
마무리
걷는 상태와 자동차를 탄 상태를 구분하는 것은 처음에는 간단해보였지만 전혀 간단하지않은 작업이었다.
무엇보다 구분하는 기준을 생각해내는 것이 쉽지 많은 않았다. 기준을 떠올리려고 자동차를 타고 시간에 따른 속도도 측정해보고, 걸으면서 걷기의 특징도 생각하는 등 여러 작업을 해보았다. 심지어 꿈에서 까지 생각했었다. ㅋㅋㅋ
테스트 하는 것도 쉽지 않았다. 실제 걷는 것과 자동차를 타는 데이터가 필요하다보니 에뮬레이터로는 테스트 해 볼 수 없었다. 때문에 실제기기를 사용해서 실제로 걷고, 뛰고, 버스를 타고, 지하철을 타보고 테스트 할 수 밖에 없어서 시간이 오래 걸렸다. 또 많이 걸어서 몸도 피곤했다…
그래도 마지막에 만족할만한 성능으로 개선해서 만족스러운 작업이었던 것 같다. 만보기 기반으로 해결 될 때 고민 했던 것에 비해 너무 쉽게 해결되어서 좀 좌절했지만 결국 고민 했던 부분들이 헛수고 아니라 같이 합쳐지게 되어 되게 뿌듯했던 것 같다.
늘 백엔드에서 서버들끼리 최적화 방법만 생각하다가 실제 사람의 행동을 구분하는 로직을 짜니 재미있고 새로웠다!
Max
[파티][??/99]주말에 코딩 진도 빠르게 나가실 분 구함/님만오면 출발
안녕하세요!
AI Build Club 코리아의 성공적인 런칭에 이어서 다음주 토요일 9월28일 첫 코워킹 이벤트를진행합니다.
이번주 일요일에 (9월1일) AI Build Club 코리아 런칭 이벤트를 개최합니다. 헤이그라운드 서울숲점 10층에서 오후 3시부터 5시까지 커피 AI Coworking 세션을 진행합니다.
코워킹? 엥
노트북 챙겨서 다른 개발자들과 함께 만나고 배우며 함께 만들어봐요.
일정:
📍 12시 30분까지 도착
📍 12시 30분 - 12시 45분: 자리 세팅 및 그룹 허들
📍 12시 45분 - 4시 30분: 💻🏗️ Build!
📍 4시 30분 - 5시 30분: 스피드 데모 및 피드백
AI Build Club? 이게 또 뭐고
AI를 사용하는 제품을 만드는 빌더들이 모여서 코워킹, 해커튼 등 다양한 활동을 하며 서로를 도와줍니다. 교육이나 이론보다 정말 "Build in public", 즉 다른 사람들에게 쓸만한 제품을 만드는 것에 관심이 있는 사람들이 모이며 현재 4000명 이상의 AI 빌더들이 참여하고 있습니다.
Nvidia, AWS, Vercel, Supabase, Stripe 등 우리 같은 개발자들이 매일 사용하는 도구를 만드는 기업들과 함께 다양한 행사를 공동 주최해왔습니다.
국제적인 커뮤니티로서 주언어는 영어입니다. AI에서 최고의 성능을 뽑으려면 영어가 필수적이라는 것이 사실이고 선두적인 AI 빌더와 최대한 교류할 수 있는 방법입니다!
이성규
A16Z 앤드류 챈 이 이야기하는 잘못된 피봇 사례들에 대한 글이 인상적이어서 요약해 봤어요.
분명 Slack 이나 Twitch 와 같은 대표적으로 성공한 피봇 사례도 있지만 잘못된 피봇도 상당히 많은데요. 언급된 잘못된 피봇 사례들은 다음과 같았어요.
1. B2B 에서 B2C 전환 - 매우 어렵다! 당연히.
2. 채팅/소셜/알림 기능 추가 - 당연히 이런 기능이 리텐션이 낮은 제품을 구원하지 못합니다. 논리적으로 너무나 당연함에도 이런 유혹을 느끼기 쉽죠.
3. AI/Web3 등 유행하는 기술 접목 시키기 - 2번과 유사하게 핵심이 아닌 접목은 리텐션에 도움이 되지 않습니다. 순간적으로 트래픽 증가 효과는 있을 수 있어도 결국 PMF 를 해결할리 만무.
4. 이른 플랫폼화 시도 - 현재 작동하지 않음에도 zoom out 해서 범위를 높히는 방식으로 피봇. 일반적으로 오히려 zoom in 하는 방향 (구체화 시키는것)이 맞습니다.
5. 유료에서 무료로 전환 - 유료에서 반응이 전혀 없다면 무료여도 마찬가지일 것.
그리고 저는 언급된 잘못된 사례들 뿐 아니라, 피봇을 생각할 때 고려할만한 원칙들이 특히 스닙팟 입장에서 와닿았습니다.. 😅
스닙팟
#해시태그로 인기 있는 콘텐츠가 모이는 주제 탐색형 서비스
스타트유어스
[디캠프] 9월 D·DAY X 오픈이노베이션 청중 모집!
S-OIL, 하이트진로, 교보생명, 호반 건설 등
스타트업과 협업을 희망하는 11개 대기업이 한 자리에 모이는 9월 디데이!
9월 디데이 청중으로 참여하셔서,
대기업이 직접 선발한 24개의 스타트업을 만나보세요!
📅 행사 개요
행사 일시: 9월 26일(목) 15:00~20:00
행사 장소: 선릉 디캠프 6층 다목적홀(서울 강남구 선릉로 551)
신청 기간: ~ 9월 25일(수) 18:00
⏰ 행사 타임라인
1부: 디캠프에서 시작하는 오픈이노베이션의 여정
디캠프가 오픈이노베이션을 하는 진짜 이유
대기업이 원하는 진짜 스타트업
2부: 대기업/중견기업이 선발한 스타트업 피칭
3부: 프라이빗 네트워킹
🔗 지금 바로 신청하러 가기:
Key
* 한국 검색 시장 상황과는 다를 수 있습니다. 콜록
* 제목 어그로 죄송합니다. 그렇지만 분명 도움이 되실거예요.
바쁘신 분들을 위한 TL;DR
SEO로 매달 156,000 트래픽 리드를 받고 있어요.
이 Organic 트래픽을 구글 광고 캠페인으로 받으려면 80만불 이상을 써야해요.
SEO로 유입된 트래픽은 SEM에 비해 컨버젼 레잇(전환율)도 높아요!
글로벌 시장 진출시 SEO는 옵션이 아닌 필수였으면 해요.
내일 쉽게 적용 가능한 5가지 SEO 비밀 레시피를 배포할 계획이예요.
"구글 SEO 이제 끝났어." "소용없어." "할 필요 없어." 라는 얘기가 심심치 않게 들려옵니다.
글쎼요. 제 생각엔요.
아직까진 그리고 당분간은 실제로 가장 효과적으로 무료로 트래픽을 받을 수 있는 방법 중 하나라고 생각합니다.
최근 무역협회(뉴욕)에서 진행한 프로그램에서 강의할 때 사용한 파워포인트 장표 중 하나입니다.
이 장표는 제가 운영 중인 웹사이트의 SEO 관련 데이타를 보여주는데요.
위 스크린샷을 보시면, 100위권 안으로 랭킹 된 Organic 키워드가 26,600여 개인 걸 보실 수 있습니다.
이 키워드들의 개별 순위는 모두 제각각입니다.
어떤 키워드는 구글 검색 결과 첫번째로 나오는 키워드도 있고
어떤 키워드는 50위권 밖인 경우도 있고요.
물론 Top 3와 Top 10 검색 결과에 나오는 키워드는 전체 키워드에서 7% 정도 밖에 되지 않습니다.그런데 이 키워드들을 통한 Organic 트래픽은 한달에 약 156,500에 달합니다.
이 계산은 월간 키워드 검색량과 검색 순위에 따른 CTR(클릭율)을 기반(=확율과 통계)으로 한 것으로, 실제와 차이가 있을 수 있지만 큰 틀에서는 유사합니다.네, 놀라운 점은, SEO만으로 매월 약 156,500의 트래픽 리드를 공짜로 얻고 있다는거죠.
만약 이 정도 트래픽을 구글 광고로 얻으려면 한달에 80만 불 이상을 써야 합니다. SEO를 통해 Organic하게 유입된 트래픽의 가치는 이런식으로 정량적으로 평가하고 추적해야 합니다.
게다가 SEO로 들어온 트래픽의 컨버전율이 더 높다는 점도 간과할 수 없습니다. SEO의 평균 컨버전율은 약 2.4%인데 반해, 구글 광고(SEM)는 1.3%정도입니다.
저는 개인적으로 SEO를 하지 않는게 아니라 못하고 있는 거라고 생각을 합니다.
SEO로 이렇게 엄청난 가치의 트래픽 리드를 받을 수 있지만, 한국의 검색 시장을 과거 네이버가 독점하다시피 해서일까요? 특히 한국에서는 관련 핵심 노하우나 연구 레시피(비법) 등이 많이 없습니다.
내 제품이나 서비스로 세계 시장 진출을 노리고 계시다면 온라인 마케팅에서 SEO First 전략을 택하셨으면 합니다.
심지어 SEO가 잘 되어 있으면 콘텐츠 스코어도 올라가고, 콘텐츠 스코어가 높아지면 SEM을 할 때 비딩 프라이스도 경쟁사에 비해 효과적으로 낮출 수 있거든요.
14-1. 구글 광고에서 콘텐츠 스코어는 상당히 중요한데요.
14-2. 구글 입장에서는 유저의 광고 클릭 만족도를 높여야 계속 유저들이 광고를 클릭하게 됩니다.
14-3. 그렇기에 콘텐츠 스코어가 낮은 사이트는 비딩 프라이스를 아무리 높여도 콘텐츠 스코어가 높은 사이트 위로 광고 게제가 안되게 됩니다.
14-4. 가령 내 웹사이트의 콘텐츠 스코어가 5점이고 경쟁사 웹사이트의 콘텐츠 스코어가 10점이 경우 내가 아무리 비딩 프라이스를 놓여도 구글은 내 광고를 경쟁사 광고보다 상위에 게재해주지 않는거죠.
어쨌든, SEO가 여러가지로 중요하다는걸 인지했지만, 어디에서 시작해야 할지 모를 수 있습니다.
그래서 준비했어요!. 내일 우선 쉽고 간단하게 적용 가능한 간단한 5가지 핵심 팁이 담긴 SEO 레시피 가이드 북을 배포할 계획입니다. 두둥~
뉴욕에서 프로젝트 만선을 만들고 있습니다. 어기어차~ 어기~ 어차~
Peter Shin
· 꾸준한 글쓰기가 현 투자라운드에 도움되는 이유.
· 필기감 완벽한 0.3mm 하이테크 펜과 몰레스킨 보다 중요한 것.
· 프로덕트 런칭 전, 바쁠수록 손으로 글을 써야 하는 이유.
수많은 고객인터뷰와 투자자 IR을 하며 사람들과 끊임없이 교류하며 감정을 나누는 파운더분들도 어려워하는 질문이 있다.
”대표님, 지금 이 순간 어떤 감정을 느끼세요?“
이렇게 툭 던진 질문에 당신의 오늘 감정이 어떤지 즉시 대답하는 케이스는 거의 없다.
파운더 본인이 자신의 동기, 그러니까 자아가 살아있음을 느끼게하는 원인을 인지하는 것은 매우 중요한데 그 이유는,
A) 그래야 본인이 걷고 있는 창업여정 속 방향성을 스스로 제시할수 있고,
B) 포기하지 않고 그 어려운 길을 걷게하는 Why가 생기기 때문이다.
1️⃣ 투자 라운드를 돌고 있다면 일기를 쓰자.
투자 라운드시 대표의 스케쥴은 가히 살인적이다. 투자자들의 각종 문서 요청, DD에 대응하느라 업무가 2-3배 증가된다. 여기에 더해 투자 라운드는 창업자에게 감정 에너지가 가장 많이 소모되는 시기 중 하나이다. 자신이 믿어 온 꿈을 내가 알고 지낸, 소개 받은, 또는 열심히 공들인 타인에게 핏칭해야 하고, 여기엔 반드시 Win or Lose 의 뼈아픈 결과가 발생한다. 더군다나 VC 업계가 좁은 우리나라에서의 핏칭은 가히 공포스럽기까지 하다. 파운더는 자신의 평판, 내 꿈의 크기, 나라는 사람, 소속, 이 모든 것을 걸고 IR을 하고 그것을 일방적으로만 판단받기 때문에 더더욱, 이 과정에서 발생되는 자신의 감정들을 제때 기록하며 자아의 희석을 방지하는게 필요하다.
특히나, 일기는 투자자들에 대한 객관화, 즉 ‘이들도 결국 사람이다‘ 라는 점을 인지시킬 수 있어 더 좋은데, 투자자들에 대한 막연한 생각과 부담스러움 보다는 여기에 반응하는 나를 관찰, 기록하면서 창업과정에서 반드시 상생해야 하는 부류들에 대해 수용성을 기르기에도 좋다. 투자자들에 대한 감정이나 생각들을 아예 별도의 일기장/공간에 정리하는 경우도 있는데, 나는 그냥 일상을 적는 일기장에 적어도 된다고 본다.
덧붙이면, 꾸준히 이러한 감정과 생각들을 정리하다보면, VC가 원하는 narrative에 내가 어떤 감정으로 진정성있게 전달해야 하는지가 정리된다는 장점이 있다. 사실 이게 가장 큰데, IR에서 투자자는 창업자의 진정성을 가늠하며, 이런 진정성 곁에 Sour한 감정이나, 패배주의, 아니꼬움, 반사적 방어, 공격성 등을 포착하기도 하는데, 일기를 통한 꾸준한 자아성찰은 파운더의 이런 감정들을 순환시키고 정화시킨다. 참고로, 이러한 감정들이 있다는 걸 쿨하게 인정하는것도 멋진것 같다.
2️⃣ ROI가 높은 일기 작성 팁.
우리는 갓생을 사는 바쁜 파운더들이기에 지금 라이프 스택(Stack)에 더해지는 습관 하나 하나가 기존 습관들을 대체시키는 행위이며, 따라서 시일내 성과가 있어야 할것이다. 이에, 매번 쓰는 일기를 기왕 10-20배 더 효과적으로 쓰는 팁을 공유해본다.
A) 꼭 특정 미디움에 제한 시킬 필요는 없다(0.3mm 펜과 몰레스킨 등).
나는 아이패드, 맥북, 아이폰, 노트 3종류, 펜 10가지, 앱 3가지 정도를 번갈아 가며 일기를 써왔다. 자신에게 딱 맞는 일기를 위해 여러번의 Iteration과 실험이 필요하다. 이렇게 다양한 곳에 저장된 일기들을 일주일에 한번 애플노트에 to-do로 간소화하고 중앙화하여 idea들을 관리한다.
B) 맨 처음 아침에 써라.
하루를 시작하는 나의 감정을 정화시키고, 호흡의 속도를 조절하고 시작하게 되며, 하루의 우선순위를 파악하여 미팅 등을 자연스레 주도할수 있게 된다.
C) 손으로 쓴다면 원하는 필체를, 기기로 쓴다면 원하는 포맷을 연마하라. 그래야 차곡차곡 쌓이는 재미가 보인다. 차곡차곡 쌓인 일기는 훗날, 나만의 데이터와 인사이트가 되어 준다. “이 가설이 검증되었네”, “아니었네” 등.
3️⃣ 파운더에게 추천하는 글쓰기 5가지.
A) 책이나 작품에 대한 예술적 평론. 2-3달에 한번.
나라는 스타트업의 스토리를 객관화하는 연습이 된다. 또한 문학은 스토리텔링시 파운더의 어휘력에 많은 도움이 된다.
B) 과거에 대한 회상 일기. 2~3달에 한번.
과거를 자주 회상하는 기록은 자아를 강화시키기에 좋다. 당시 느낀 감정을 되살려보면 더 좋다.
C) 미래에 대한 비전 일기. 6개월에 한번.
나의 경우 매년 1월과 6월에, 한해를 계획하는 일기와 이를 중간점검하는 일기를 쓴다. 40대 50대를 상상해보는 일기는 수도 없이 많이 적었다. 파운더 본인의 미래를 구체적으로 상상하면, 팀원도, 투자자도 이에 맞춰 자연스레 나타나기도 한다.
D) 본인 일상에 대한 근황 일기. 일주일에 1~3번.
일기쓰기를 정착하는 연습시간이자, 매일의 자아 충전시간이다. 내 경우 보통 짧게, 손으로 쓴다. 임팩트.
E) 자신의 소비 성향이 담긴 컨슈머 일기. 6개월에 한번.
마린블루스와 마조앤새디의 정철연 작가가 한때 이런 류의 글을 가장 맛깔나게 썼더랬다. 올해를 빛낸 우리 가족의 IT 기기, 앱, 주부템, 여행 등 리스트는 많다. 시장과 컨슈머 트렌드에 대한 나만의 리뷰는 내가 얼마나 더 까다롭게 빌딩할 수 있는지를 깨닫게 해준다.
마지막.
가장 중요한 주제는 무조건 처음엔 일기장에 손으로 쓰는 것을 추천한다. 이유는
첫째, 간격이나 폰트, 글의 크기가 일원화되는 컴퓨터 UI 보다 다양한 생각의 흐름을 유연한 방식으로 맘껏 기록 할 수 있어 아이디어가 더 빠르게 구체화되고,
둘째, 일기라는 포맷이 내 개인적인 의견과 감정을 드러내는데엔 더 자연스럽기 때문에 내 Why가 아이디어 안에 속속들이 더 잘 묻어나기 때문이다.
____
· 사진은 올해 일본에서 나랑 와이프의 하울링 사진. Shopping of the Year.
· 실리콘벨리를 품는 창업가들을 위한 영어 뉴스레터 - https://lnkd.in/gK67Fw_u
· 다른 창업가들과 더불어, 일주일에 한번 감정나눔을 하고 싶은 파운더가 있다면 댓글 주세요.
