[Final Project] SR - 기술스택

hailey·2020년 11월 7일
0

FinalProject

목록 보기
1/4

하루 정도 숨을 돌리고 나니 곧장 마지막 프로젝트가 시작되었다.
다행히도 이전 프로젝트와 동일하게 팀이 구성되어 각자가 생각해본 보완점이나 희망사항에 대해 쉽게 공감할 수 있었고, 공유와 적용도 빨랐다.

마지막 프로젝트는 약 관리 애플리케이션인 '약올림'이다. 이 앱은 내가 먹고 있는, 가지고 있는 약의 현황을 등록하고 관리해준다. 시장에 나와있는 To do list나 메모 앱처럼 약을 기록하고 복용 주기 등을 설정하면 외출 전에 약을 챙겨가라거나, 약 먹을 시간이 되었을 때 알람이 울린다. 또 약을 촬영하면 해당 약의 이름을 비롯한 기본정보를 띄워준다.
팀원들이 모두 이미지처리에 관심이 있고 백엔드의 경우 사용해보고 싶은 스택도 겹쳐서 순조롭게 아이디어를 구체화할 수 있었다.

그래서 우리 팀은 첫 번째 프로젝트처럼 곧장 SR문서를 정리하기 보다는

1) 구현하고자 하는 앱의 기능과 특성을 정리하고
2) 그에 맞는 기술스택을 취사선택한 후에
3) 각자 일주일의 공부 시간을 가지고 나서
4) 구체적인 API와 데이터베이스 등을 구성

하기로 했다! 실제로 API를 만들어가다보니 SR문서를 몇번이고 수정해야 했던 경험 덕분이다.

Before SR

  • 애플리케이션임을 감안하여 배포, 컴파일 공부하기
  • 크롤링 공부하기
  • 의약품 관련 정보 API 찾기
  • 이미지 처리 공부하기
  • 모바일 하드웨어 접근방법 공부하기(카메라, 알람)
  • 모바일 위젯 사용법 공부하기
  • 지도 API 다루는 법 공부하기
  • 데이터베이스, 배포 등 프레임워크 정하고 공부하기
  • 그외 각 기능에 따른 기술 스택 정하기

프론트엔드 기술 스택

리액트 네이티브 VS 플러터
리액트 네이티브의 경우 ios와 안드로이드 모두에서 사용가능하다는 장점이 컸다. 그리고 세 명이 백엔드, 한 명이 프론트엔드를 전적으로 맡되 백엔드 중 두 명의 팀원이 프론트엔드를 보조하기로 한 상황이라 모두가 쓸 수 있는 언어를 기반으로 하는 것이 좋겠다는 판단이었다.

[참고] https://sambalim.tistory.com/33

자바스크립트 VS 타입 스크립트
타입 스크립트를 적용했을 때 리액트 네이티브와 상충하여 필요없는 컴파일이 발생할 수 있으므로 위험요소를 배제하기로 했다.

[참고] 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
많은 고민을 했던 부분 중의 하나다. 하지만 Graph QL은 자료형이 텍스트로 제한된다는 점이 추후에 문제가 될 수도 있다고 생각했다.

[참고] https://www.youtube.com/watch?v=EkWI6Ru8lFQ

fetch VS axios
[참고] https://bangc.tistory.com/16


백엔드 기술 스택

django VS flask
백엔드 쪽은 전부 새로 접하는 스택들이라 결정이 쉽지 않았다. 경험해보지 않아 가늠할 수 없는 영역도 있었고, 해보고 싶은 것과 시장에서 주로 쓰이는 것 등도 고려해야 했다.
우리가 플라스크를 쓰기로 한 결정적인 요인은 가볍고 배우기 쉽다는 것이었다. 이미 새로운 언어부터 익혀야 했기 때문에 탄탄하지만 복잡한 장고는 현실적으로 무리가 있을 수 있다. 또 플라스크에는 ORM과 기타 부가기능이 내장되어 있지 않다는 단점이 있지만 이미 npm을 통해 각종 모듈 설치에는 익숙해서 문제가 되리라 생각하지 않았다.

SQL VS NoSQL
약올림에서는 한 명의 사용자에 대해 약 정보, 알람, 사진 등 여러 번의 조인이 필요하다. 단 한 번이라도 조인이 생긴다면 SQL을 사용해야 한다.

aws VS heroku
소규모 프로젝트, 새로운 프레임워크에 대한 학습욕구, 배포 관련 전문가 부재. 이 삼박자가 고루 맞아 헤로쿠를 선택했다. 그리고 EC2와 RDS를 연결해줘야 하는데 애플리케이션의 경우 EC2가 필요없으므로 aws는 다소 불편하게 느껴졌다(이 부분이 맞는지 애플리케이션의 서버 통신-배포에 대한 정확한 공부가 필요하다!). 무엇보다 aws는 너무 힘들다...

이외에도 플라스크의 ORM인 SQLAlchemy, 기계학습을 위한 openCVTensorflow, 파이썬을 통한 크롤링, 전 프로젝트에서 써보지 못한 JWT를 사용하기로 했다. 알약이미지는 2만 3,000장 쯤 되어서 구글 드라이브에 올리기로 했다.


덧붙여 앞으로는 스탠드업 미팅 때마다 각자 공부한 내용, 코드 등을 공유하고 알려주기로 했다. 내가 구현한 부분이 아니더라도 설명은 해줄 수 있도록..!

profile
옳고 그름을 고민합니다

0개의 댓글