예비 정글 프로젝트 기획1: 맛의 일기화 테이스팅 노트

소개

위 프로젝트는 2022년도 서울예술대학교에서 진행된 인공지능 프로그래밍(이라 쓰고 UI/UX 파이썬 찍먹이라 쓴다)수업에서 개인 프로젝트로 진행했던 어플입니다.
이후 개인프로젝트로 끌고와서 소셜 로그인 부분까지는 이미 구현이 되어있고, 내부는 대략 60%정도 구현 완료한 상태입니다.
하지만, 코틀린 밖에 모르던 시절 진행했던 거여서 어차피 코드 재탕은 불가능한 점 참고 부탁드리겠습니다.

서비스 고안 사유

• 카페인 용량 관련 체크
  수업을 듣던 당시 하필 건강상 문제로 카페인 용량을 계산하여 마시던 박이나양
  당시에는 칼로리 계산 어플 같은 것들음 많아도 카페인 용량에 대해서는 기록할 수 있는 곳이 없어 하나하나 카톡 나에게 보내기로 메모를 해야한다는 것에 충격을 받아…
  결국 본인이 할 줄 아는 코틀린을 활용해보자라는 무리수를 두기 시작

• 커피는 왜 커뮤니티만 있을까?
  한국어 지원이 부실하기는 하지만, 와인의 경우 비비노라는 어플이 있다.
  그러나 커피의 경우 네이버 카페나 다음 카페 등으로 매니악한 정보는 산발되어있고, 그 외의 칼로리 등은 네이버 블로그나 각 브랜드 별 홈페이지에 가서 찾아봐야 하는 상황
  심지어는 다이어트 어플을 찾는 것이 영양 정보에 대해서는 더 빠르고 정확한 경우도 있었다.
• 정보가 지나치게 산발적
  카페인 함량 한번 찾으랴 칼로리 찾으랴 혹은 본인이 선호하는 원두의 맛이 따로 있다면 정보가 산발되어 있어서 검색을 하면 할수록 일이 더 늘어나는 느낌이었다.
  나는 분명 쉬려고 커피를 마시고 기록을 하는 것인데 오히려 일이 늘어나게 되는 어처구니 없는 상황들
• 커뮤니티제가 뭐가 문제지?
  네이버 카페 다음 카페 등은 등업 시스템을 활용하여 정보를 한번 거를 수는 있지만, 그만큼 아무것도 모르는 사람 입장에서는 그들만의 리그라는 생각이 들게 함
  완전 초보자의 경우 무언가를 배우거나 정보를 얻고 싶어도 도리어 아무것도 모르기에 아무것도 배울 수 없는 역설적인 상황이 발생한다.

주 서비스 및 설명

• 취향의 발견
  예전에 넷플릭스나 왓챠를 처음 사용했을 당시 나의 취향으로부터 비슷한 다른 것들을 이끌어내는 부분이 굉장히 흥미로웠다.
  내가 좋아하는 커피의 맛(산미나 단맛 등등)을 태그로 만들어서 데이터 비주얼라이제이센을 하거나 역으로 내가 좋아하는 음료가 대충 어떤 맛에 속하는 지를 태그로 등록할 수 있도록(예를 들어 케냐 원두 커피 마음에 듦->산미 태그 연동)만들어서 자신의 취향을 발견할 수 있도록 도와준다.
  
• 맛의 기록
  좋다나 맛있어라는 말은 사실 굉장히 모호하다.
  어떻게 좋았나를 기록함으로써 일종의 과거 일기장을 보듯 본인에게도 보다 구체적인 기억을 떠올릴 수 있도록 도와준다.
  더 나아가서 미각을 묘사하는 과정이나 카페에서 느낀 점들을 가볍게 기록하다보면 자연스럽게 글쓰기 능력의 향상도 기대할 수 있다.
• 전문 리뷰어 제도
  티나 커피 등등 분야에서 별을 몇 개 이상 받으면 전문 리뷰어로 승격을 시켜준다.
  자신과 취향이 맞는 전문 리뷰어의 후기를 상단 광고에 띄워준다거나(티 리뷰가 많은 유저에게는 티 전문 리뷰어 광고), 팔로우 기능을 작성하여 인스타처럼 피드나 알고리즘에 먼저 뜨도록 세팅을 해준다.
• 개인카페 사장님들을 위한 홍보 제도
  맛있는 로스팅 카페들 중에 일부는 개인 카페이다보니 정말 맛있는 곳인데도 홍보가 덜 되어 망한다거나 생각보다 장사가 안되는 경우가 있다.
  사장님들께서 직접 본인들의 원두는 어떠어떠한 느낌이다 이런 것들을 자신있게 설명할 수 있는 정도의 가게라면 소비자들도 믿고 갈 수 있을 것이다.(특히 커피 매니아일수록)
  대신 자신 카페에 대한 리뷰를 달 때에는 사장님임을 알 수 있는 뱃지가 뜨도록 하는 등의 방식으로 허위적인 뻥튀기 리뷰를 방지하는 시스템을 마련해야할 것이다.

당시 사용한 기술스택 및 보완

• 데이터 비주얼라이제이션
  당시에는 터치 디자이너와 sql활용 하여 만듦
  파이썬으로 작업을 진행한다면 Matplotlib등 몇몇 관련 라이브러리가 있음
  
• 소셜로그인
  당시에는 코틀린과 코틀린 내의 라이브러리 활용하였으나, 보안이나 안정성을 고려하여 이 부분은 백엔드에서(node js또는 spring) 하는 것이 좋을 것 같음
• 스플래쉬 화면
  당시 코루틴을 통해 쓰레드로 넘겨주어 처리하였더니 지나치게 빠르게 화면이 사라져서 인위적으로 밀리세컨드 사용하여 제작하였음
• ui/ux
  당시에는 figma로 미리 스케치가 되어있었고(수업시간에 진행했으니 당연하지), 이 부분을 안드로이드 스튜디오와 코틀린을 사용하여 80%정도 구현만 되어 포토샵을 이용해서 스케치본을 스마트폰 목업에 첨부만 하였음
  아마 프론트 엔드를 누가 맡느냐에 따라서 일이 달라질 것 같아서 이 부분에 대해서는 따로 논의가 필요할 것 같음