사진대학이 뭔지, 이게 대체 뭔 글인지 모르겠는 사람들은 1편을 읽고 오길 바란다.
사진대학의 피봇팅
- 사진대학은 피봇팅을 진행한 상태다.
Q. 피봇팅을 왜 했냐고?
A. 사람들이 안 써요.
매우 단순한 이유이지 않을까...
사실 사업을 시작하면서도 의문이었던,
"굳이 휴대폰에 있는 사진을 인화하고 싶을까...?" 라는 우려는 현실이 되었던 것이다.
초기 오픈빨로 시장 규모의 10% 이상을 한 달 매출로 확보했으나, 정확하게 매출은 한 달이 지날 때마다 반감했다. 솔직히 이것도 너무 신기한 게, "정확히 반감"된 거다. 어떻게 정확히 반감되지? 너무 신기하다.
아무튼, 이런 시행착오를 겪고 우리가 내린 결론은,
굳이 휴대폰에 있는 사진을 인화하려 하지 않는다.
라는 결론이었다.
사진대학은 어떻게 피봇팅을 했나
우리는 그래서 어떻게 피봇팅을 했을까.
우리가 제공한 사진 틀 중에, 우리 학교의 특색을 살린 사진 틀이 있었다.
앗 학교 이름이 ㅠ
아무튼 이 사진 틀이 정말 잘 팔렸던 기억이 있다. 그리고 설문조사 결과 재구매자는 그냥 무틀(사진 틀이 없이 그냥 휴대폰의 사진을 그대로 인화) 사용률이 높았고, 애초에 사진 인화를 매우 좋아하는 사람이었다. 일종의 우리의 고정 고객층이라고도 볼 수 있는 것이다.
그러나 대부분의 사람들은 사진을 매우 좋아하는 사람이 아닌 이상 요즘 시대에 애초에 인화하는 사람들이 좀 드물다.
그래서 우리는 다양한 틀을 통해 사진 찍기를 즐겨하지 않더라도, 추억을 소장하는 수요가 있을 것이라 판단해 다양한 사진 틀을 제공했던 거였는데... 저 사진 틀만 잘 팔린 것이다.
그래서 우리는 한 가지 아이디어를 얻었는데, 바로 굿즈 판매가 그것이다.
학교 로고가 박힌 사진 틀의 매상이 높다는 건, 우리 학교 굿즈를 원한다는 것이 아닐까?
한편 작년에 학교 마스코트가 그려진 키링을 판매했을 때 높은 수요를 기록했으므로, 우리 학교 학생들은 학교 굿즈에 굉장한 수요를 보인다는 사실을 확인했다.
굿즈 판매 키오스크로.
사진대학은 현재 굿즈 판매 키오스크로써 기능하고 있다.
소프트웨어(웹)는 새로 개발하더라도 키오스크를 다시 만들 여력과 자본은 없었기에, 우리는 현재 키오스크 (사진 인화기+모니터)를 유지하면서 소프트웨어만 바꾸어야 했다.
그래서 우리의 방향은 기존의 4x6 사진 인화지를 그대로 사용하면서 굿즈가 될 수 있는 다양한 사진 콘텐츠를 개발하려 애썼으며, 대학생이라는 타깃에 맞추어 다양한 콘텐츠를 개발했다.
다행히도 매출은 이전보다는 꾸준히 찍히고 있다. 더불어 새로운 콘텐츠를 개발하며 지속적으로 사람들에게 구매 동기를 제공하고자 하는 방향으로 나아가고 있다.
디자인도 이전 버전보단 훨씬 신경쓴...
확실히 훨씬 나아졌다. 이전 버전 웹 피드백 중 "예쁘지가 않다"도 있었기 때문에, 디자인도 꽤 신경써봤는데 웹 디자인은 나쁘지 않은 것 같다.
개발은 어떻게?
이번에 프로덕트 수준 개발은 처음이었다.
여행 스타트업에 재직하면서 데이터 처리와 자연어 모델 개발 및 파인튜닝 등등은 해봤지만, 실제 수준의 프로덕트를 만들어 본 적은 없기 때문이다.
애초에 프론트엔드와 백엔드 모두를 작업해야 했고, ReactJS도 잘 다루는 상황은 아니었기에 사실 웹 개발에 애를 많이 먹었다ㅠ. (게다가 사진 데이터도 왔다갔다 하다보니)
일단, 프론트엔드 개발은 이전에 플러터 웹으로 하다가 크게 데였던 적이 있어서 ReactJS로 하기로 했다. 게다가 SpringBoot 등을 배울 시간이 넉넉한 것도 아니었어서, 나에게 익숙한 Python을 백엔드 개발 언어로 택해야 했는데, 그래서 Flask로 서버 앱을 구축하기로 했다.
사실 키오스크에 응용프로그램으로 돌려도 상관없는 아이템이긴 하지만, 도메인을 사놨던 것도 있고 또 이 기회에 프로덕트 레벨의 프론트 및 백엔드 작업을 해보고 싶어서 굳이굳이 서버를 Amazon EC2 인스턴스로 돌리고... 한 것도 있긴 하다.
일단 스택을 설명하자면, 프론트엔드는 ReactJS를 통해서 구축했고 서버는 nginx, 서버 앱은 Flask로 만들었고 Amazon EC2 인스턴스를 통해 호스팅하고 있다.
개발에 한 달 정도 걸렸고, 시행착오가 꽤 있었던 걸로 기억한다. 기억나는 대로 개발 시 시행착오들을 올려 보도록 하겠다...
마이그레이션 후 좋아진 점이 있다면?
-
Flutter to ReactJS
일단 확실히 DX가 좋다. 개발자 입장에서 Flutter Web보다는 유지보수나 코드 작성의 측면에서 리액트가 훨씬 좋은 것 같고 무엇보다 역시 레퍼런스가 많다. Flutter도 레퍼는 많지만, Flutter를 웹 개발용으로 사용하는 사례는 드물다 보니...
플러터에서는 웹 개발 시 해결해야 하는 여러 가지 문제 (Event Handling) 같은 것들을 모바일 앱의 관점에서 해결하는 느낌이었다. 즉, onClick 이벤트를 받아도 클릭이 아니라 터치라고 생각하고 개발해야 했다. 마치 블루스택을 사용하는 것처럼. 그런 것들이 너무 불편했는데, JavaScript니까 당연히 이 부분은 편해졌다. -
Non-Serverless
논서버리스. 이중 부정이다. ㅋㅋㅋㅋ 플러터는 아무래도 서버리스 형식으로 개발하게 될 일이 많고, (특히나 스타트업 등에서도 MVP 등에 적극적으로 활용하기 때문에) Firebase에서 제공하는 기본적이고 가벼운 DB로 편하게 개발할 수 있는 장점이 있지만 그렇기에 확장성이 떨어진다는 단점이 있다고 느꼈다.
우리는 피봇팅 이후 사람들의 수요를 더 면밀히 체크하고, 피봇팅 이후 아이템의 특성상 여러 가지 콘텐츠를 서빙하고 또 콘텐츠별로 각각 DB를 만들어야 했는데, 그렇기 때문에 프론트단과 백단을 나눠놓는게 편할 것 같았다. 그래서 리액트JS와 Flask로 나누게 된 것이다. -
굳이 리액트였나?
솔직히 바닐라 JS를 사용해도 이상할 건 없다. 그냥 메인 화면, 이미지 몇 개 띄워주고 API 왔다갔다가 다기 때문에. 디자인 패턴도 MVVM 같은 거 안 쓰고 그냥 View와 Model로만 구성했는데, 디자인을 예쁘게 해야 하는 이번 프로젝트의 특성상 리액트JS를 쓰는 게 styled component도 쓸 수 있고 여러모로 UI짜기 편할 거 같아서,,,
결론
뭐 이번에도 가벼운 창업 다이어리지만 앞으로 생각나면 사진대학을 하면서 느낀 점과 배운 점을 많이 써보도록 해야겠다.
