[Intro]프로젝트 준비하기(week1-1)_스택선정/서비스 기능 구체화(페이지 beta)

10월 한달간 진행했던 S*FU 프로젝트가 끝나기 무섭게 바로 2달간 진행될 파이널 프로젝트가 시작되었다.

 

아이디어 선정

우선 구현하게 될 서비스는 "복용관리 알람 서비스" 이며, 서비스 명은 "약올림" 이다.

 ( 약간 병맛스럽고, 듣자마자 뇌리에 꽂히고 개인적으로 너무 마음에 들었다! 팀원 분의 센스가 최고)

 

그리고 아이디어는 현정님이 생각해오신 아이디어였고, 따라서 전체적인 구조에 대해서는 덕분에 금방 잡힐 수 있었다.

아래의 이미지가 우리 서비스의 가장 메인 서비스이다.

"약올림" 서비스 개요

 - Main 

    : 내가 복용할 약을 캘린더/ 알람에 저장하고, 복용 주기에 맞춰서 어플이 알람을 울려준다.

    : 그리고 저장한 캘린더에 복용 여부 및, 내 복용 현황을 전체적으로 볼 수 있다.

- Sub

   : 약을 저장할 시에, 카메라로 약을 촬영하면, 이미지 인식을 통해서 촬영된 약에 대한 정보를 불러와 준다

    (여기서 딥러닝, 이미지 처리, 크롤링이 동반)

   : 근처 약국/병원에 대한 정보 또한 지도 API를 통해 정보 제공

     (이는 논의 끝에 시간적인 이유로 추가기능으로 뺐다)

 

기술 스택 선정

대략적인 아이디어를 선정하고 논의한 다음에, 우리는 이전과는 다른 방향으로 이번 프로젝트를 진행할 예정이므로

기술 스택 선정부터 논의했다.

 

 

client side(모바일 앱)

 - react native VS flutter

    : 우선 우리는 ios나 안드로이드에 특화된 각 네이티브 언어를 기반으로 앱을 만들지 않고,

      react native를 통해 크로스 플랫폼 앱을 만들기로 했다.

     해당 이유에 대해서는 시간적인 이유가 가장 컸다. 이 시간이라 함은 학습을 위한 시간 뿐 아니라 제작을 위한 시간 또한

     포함되어 있을 정도로 매우 중요한 이유였다.

     실제로도 베타버전식의 서비스를 만들 경우, 빠른 제작과 상용화를 위해 RN언어를 활용한다는 이야기 또한 많이 들었기 때문이다.

   : flutter도 RN과 유사하게 크로스 플랫폼 앱을 위한 언어인데, RN을 선정한 이유에 대해서는 아래의 블로그를 참고했다. 

  [reference]

   https://sambalim.tistory.com/33

 

- JS vs TS

 : 요즘 자바스크립트의 높은 자율도에 따른 문제점을 어느정도 보완한 타입스크립트에 대한 사용률이 높아지고 있다.

   따라서 우리도 RN 기반으로 타입스트립트 사용을 고려했지만, RN사용에는 오히려 TS를 같이 사용하는 것에 대한 우려의 목소리가 컸다. 

   또한 RN 자체도 새로 시작한 기술스택이라 학습시간이 필요한데 거기에 TS까지 더해지면, 레퍼런스가 많아도 잘 해낼 수있을지에 대해

   의문이 드는데, RN+TS 에 대한 레퍼런스는 아직 많이 없었다.

  [reference]

 https://velog.io/@honeysuckle/React-Native%EB%A1%9C-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EB%A5%BC-%EC%A7%84%ED%96%89%ED%95%98%EA%B8%B0%EC%A0%84-%EA%B3%A0%EB%A0%A4%EC%82%AC%ED%95%AD-%EB%8B%A8%EC%A0%90-%EC%95%84%EB%8B%98

 

- Rest API VS Graph ql

 : Graphql이 아주 간략하고 간편한 http통신 언어로써 최근에 조금씩 주목받고 있기 때문에 사용을 고려했었다

   그러나 우리의 통신 특성상, 불필요한 데이터가 과하게 끌려올 걱정보다는, 정확한 요청을 통해 정확한 데이터를 주고 받는것이 더 중요했으므로 REST api 방식을 택했다.

[reference]

https://www.youtube.com/watch?v=EkWI6Ru8lFQ

 

- fetch vs axios

 : axios는 rest api 통신 방식 중의 하나이다. axios의 가장 큰 장점은 통신되는 데이터를 자동으로 JSON 처리 해주는 것이 아닐까,

   그리고 페이지간 연결되어있는 경우에 추천한다고 하는데, 실제로 동적인 웹페이지의 경우 각 컴포넌트나 페이지 간, 연동된 경우가

많을 것이므로 우리는 당연히 axios를 택했다.

[reference]

https://bangc.tistory.com/16

 

server side(python 메인)

우선 우리는 server의 main언어를 python으로 선정했고, 이를 기반으로 다른 스택을 선정했다.

굳이 파이썬을 새롭게 선정한 이유는, 기본적인 서버 구성만이 아니라 부가적으로 제공할 서비스를 구현하려면

파이썬을 사용하는 것이 딥러닝이나 크롤링에 대한 학습을 처음하는 우리에게 더 많은 레퍼런스가 제공되기 때문이다.

물론 자바스크립트 또한 딥러닝 라이브러리가 존재해서 가능하지만 이에 대한 레퍼런스가 부족해서,

처음하는 우리들에게는 문제가 생겼을 경우 도움을 받을 곳이 그만큼 적다는 것을 의미했다. 

 

 - django vs flask 

 : 즉, 파이썬 자체를 처음 배우는 우리들에게 학습시간 뿐 아니라 구현 시간까지 고려한다면 flask를 도입하는 것이

   좀 더 유용할 것이라 결정했다.

 

- JWT

 : 1차 때, session 인증 방식을 도입했다면, 이번엔 좀 더 보완성을 강화하기 위해 JWT 방식을 도입했다.

 

- sql vs Nosql

 : 실제로 가장 중요한 부분이고, 이는 면접 때도 많이 물어보는 부분이라고 한다.

 : 이미지를 DB에 저장해야 하는건가? & scale up 때문에 nosql을 고려했지만, 가장 핵심적인 데이터간의 관계성때문에 sql을 선택했다.

[reference]

www.youtube.com/watch?v=CjsVx9sARDU

 

 

- sqlAlchemy (flask ORM) : 이는 flask에서 DB를 사용할 때 필요한 ORM 라이브러리

 

deployment

 

 - heroku vs aws

  : 배포 당시 이 두개의 서비스 중에 고민할 때, 가장 큰 포인트가 되었던 것은, 장기적으로 진짜 서비스로 이용할 것인지, 아니면 프로젝트 및 스터디를 위한 단발성인지였다. 우리는 후자였고 그래서 헤로쿠를 배포 서비스로 택했다.

[reference]

incoffee.tistory.com/3

[인프라] heroku를 써야할까 AWS를 써야할까?

 

서비스 기능 구체화

- 우선 지도기능은 우선 제외

- Main

  - 약 복용 현황 캘린더 저장

  - 약 복용 알람

 

 

 

DB 구성이 메인일거 같다...생각만해도 머리가 아프당 ㅠㅠ