2020 동계 SU인터십 (주)오픈버스와 함께한 8주간의 프로젝트를 회고해보려고한다. 맨날 블로그 써야지하면서 만들어놓고 손도 안대고 있었는데, 이번 기회에라도 기록을 남겨보려고 한다.
MiseCho
미세먼지 측정 서비스 미세초는 아두이노를 이용해 미세먼지를 측정하고 어플로 현재상황과 통계를 확인할 수 있는 서비스이다.
프로젝트명은 UV의 노래 미세초(Fine Dust)에서 따왔는데, 개발 초기 프로젝트명은 CheckPM이였다. 너무 안팔리게 생긴 이름이라는 피드백 때문에 바꾸게 됬는데 뭐...기업들도 출시전에 프로젝트명은 따로 있으니까ㅎㅎ 바꾼 덕분에 더 귀엽고 로고가 이뻐진 것 같다.
.gif)
프로젝트 기획
아이디어는 간단했다. 아두이노를 이용해서 미세먼지를 측정하고 서버에서 통계와 몇가지 설정이 가능하게하는 것이 목표였다. 프론트 개발을 해본적이 없어서 기획초기엔 Flask에 Admin page만을 이용해서 기능을 구성하려고 했었다. 전에 일하던 AI이노베이션스퀘어의 lms가 그렇게 개발되어있었고, 그 개발자분께 Flask를 배웠었는데 신기하게도 내가 하려니까 하나도 모르겠더라...
그래서 웹보다는 앱이 배우고 만들기 빠르겠다 싶어서(지금 생각하면 부트스트랩으로 더 빨리 끝냈을 수도 있을텐데...) 앱으로 프론트를 구성했고, 서버는 개발경험이 있는 Django를 이용하기로 했다.
-2.jpg)
아이디어만큼이나 시스템 구조도 간단하다. 아두이노가 매 정해진 시간마다 서버에서 설정값을 가져오고 미세먼지값을 측정해서 서버로 POST하게된다.
서버는 아두이노가 보낸 데이터들을 매시간마다 평균값을 구해서 앱으로 측정데이터, 아두이노 측정 설정값, 알림기능을 제공한다.
아두이노와 서버간 구성에 AWS IoT나 GCP IoT를 이용하고싶었는데, 자료 찾기가 어려웠고 아두이노에서 사용했다는 경우도 본적이 없어서 결국 HTTP 통신으로 연결하게 됬다.
와이어프레임
Index 페이지에서 전체 통계와 측정기별 상황을 체크할 수 있게했다.
알림 페이지에서는 일정수준 이상으로 올라간 디바이스명과 내용을 담아서 알림 리스트를 보여줬다.
측정기 디테일 페이지에서는 기기관련 설정 기능을 넣었다.
개인적으로 장난스레 스케치한 것 같은 느낌 때문에 발사믹목업을 선호한다.
실제로 첫 브리핑때 완전 크게 낙서처럼 그려진 캐릭터 화면으로 발표하기도 했다...ㅎㅎ
그래도 적당한 자유도내에서 직관적으로 알아보기엔 좋은 툴이라고 생각한다. 유료인 점만 빼면
Balsamiq Wirefames
개발환경
Flutter
앱은 Flutter를 이용했다. 앱 개발이 처음이라 React나 네이티브도 고민했었는데, 명색이 구글DSC 코어인지라 구글 기술을 선택했다. 처음 써보는 프레임워크인만큼 배우기 쉬운가가 중요한 포인트였는데, Flutter 초반보다는 강의영상이나 책들도 나오고 공식문서도 어느정도 한글화가 진행되고 있었다. 무엇보다 다른 프로젝트에서 프론트를 맡고있는 친구가 Flutter를 사용하고 있었기에 물어보기에도 좋다고 생각되었다. 그리고 무엇보다 크로스플랫폼이라니 섹시하지 않은가?
Arduino UNO WiFi Rev2
아두이노에 필요한 기능은 2가지였다. WIFI와 미세먼지 측정. 아두이노는 처음이라 사실 겁나는 부분이 많았다. 들리기로 모듈 연결을 잘못해서 보드가 타버렸다니 뭐니...무엇보다 회사돈으로 사는 것이다보니 고장났을때 다시 사달라고하기가 겁났다...ㅎㅎ
그래서 최대한 간단하게 구성할 수 있게 Wifi 기능이 포함된 보드(오히려 정보가 없어서 더 어려워질 줄 몰랐다)와 샤오미에서도 쓴다는 PM2008으로 구성했다.
Django REST framework
서버는 DRF를 이용했다. Django경험이 있어서 선택한 것도 있지만, Flask로 REST API 자료 찾기가 어려웠다;;; 아니 Flask 많이들 쓴다면서 한글 자료가 없다니...그렇다고 영어 자료들은 뭔가 잘 정리되어있는걸 보기가 힘든 것 같다.
PostgreSQL
원래 계획은 MySQL을 이용할 예정이였다. 특별히 이유가 있다기보단 미세먼지 측정값만 저장하면 됬기에 NoSQL은 고려대상이 아니였고, 프리티어에서 사용가능한 DB중에 MySQL이 제일 무난하다고 생각했다. 그런데 어쩜 무난히 지나가는게 없는지, Django mysqlclient가 문제였다. 자주 일어나는 문제라 금방 해결할 줄 알았는데, 내 구글링 실력이 부족한 것인지 대부분 Window환경에서 가능한 해결책들이였다. 그렇게 한창 스트레스를 받던 중 PostgreSQL도 무료로 사용이 가능했다. 무엇보다 update보다 insert가 압도적으로 많은 서비스이다보니 딱 들어맞는다고 생각됬다. 앞으로도 주로 애용하게 될 것 같다는 느낌이 든다.
AWS EC2 & RDS
2020 Solution Challenge때 GCP를 써봐서 GCP를 쓸 생각이였는데, 회사에서 만들어준 gsuite계정으로는 무료계정이 안만들어졌다;;;
게다가 여전히 GCP는 자료가 부족했다. 나만 그런지 모르겠는데 배포하고나면 편한게 장점인데, 배포하는게 안편해서 안장점.
공식문서에서는 배포가 정말 간단하게 써있는데, pyCharm에서 만든 django 프로젝트는 바로 올릴 수가 없었다. 몇가지 파일을 만들고 설정하면 되지만 관련 내용은 나중에 GCP를 따로 다루는게 필요할 것 같다.
Heroku도 후보에 있었는데, 인턴십에서 쓰기에는 좀 날로먹는다는 생각이 들었다. 나중에 학교 프로젝트에서 써야지ㅎ
AWS는 회사가 AWS 파트너이기도 하고 많이들 쓰는거니까 한번 해보자해서 쓰게됬는데, 저어엉말 잘한 선택이라고 생각한다.
무엇보다 자료가 많더라.
프로젝트 관리 및 문서들
사실 혼자하는 프로젝트라 프로젝트 관리니 문서작업이니 다 필요없지만, 막상 해놓고보니 도움이 많이 됬다. 그동안 프로젝트하면서 필요하겠는데?하는 것들을 나만의 양식으로 만들어서 관리하고 공유했었는데, 이미 다 있는 것들이더라. 프로젝트 진행하면서 중간중간 많이 바뀌게된 점들이 많아서 은근 귀찮으면서도 있으면 편하고 좋다. 이런 문서들을 하나로 모아서 볼 수 있으면 팀으로 작업할 때도 좀 편할 것 같은데...조사가 필요할 것 같다.
회고 🤔
잘한 점
프로젝트를 마무리하고서 잘한 점을 찾는다는건...참 어려운 일 같다. Django외에는 다 처음 써보는 것들이여서 시행착오도 많았고, 많고 적은 정보들 사이에서 허우적대는 시간이 많았다. 그럼에도 꼽아보자면 익숙한 것에 기대려고하지 않았다는 점인 것 같다. 프로젝트 계획 당시에도 여러 아이디어 중 한번도 해보지않은 것들만 쏙쏙 골라서 진행했고, 항상 서버만 개발해오던 입장에서 Front를 준비해야한다는 점에서 이미 도전이였다고 생각한다. 다음 프로젝트때는 또 어떤걸 새로 써보게될까 기대된다.
잘못한 점
참 많고 많은데 하나씩 짚어보자니 마음이 아프지만 그래도 해야겠지...
첫번째는 타이트한 일정 계획과 너무 심플한 Todo List였다. 전체적으로 규모가 큰 프로젝트는 아니여서 8주중 4주면 금방 끝내고 테스트를 진행할 거라 생각했다. 하지만 배우면서 진행하기엔 너무 타이트한 일정이였고, 디테일하게 작성되지 않아서 나중에 다시 일정을 잡고 지속적으로 Todo를 업데이트해야했다. 일정을 타이트하게 잡은 덕분에 쫄린 마음으로 늘어지지않게 진행할 수 있었던 것 같지만 내가 팀원이였으면 좀 스트레스 받았을 것 같다.
두번째는 그럼에도 불구하고 늘어진 점이다. 코시국으로인해 자택근무를 진행했는데, 작업용 책상과 노트북이 따로 있음에도 불구하고 참 많이 늘어졌다. 밤새는게 참 익숙해...
세번째는 UX를 고려하지 않은 점이다. 평소 프로젝트를 진행할 때 가장 중요하게 생각하는게 UX였는데, 정작 내 프로젝트에서는 소홀했다. 모든 통신 기능까지 마무리하고서 디자인이 전체적으로 너무 컴과 갬성이라는 피드백을 받고 한주동안 다 갈아엎어야했다. 디자인 감각이 부족해 지금도 별로지만...그래도 많이 좋아졌다고 생각한다.
디자인 변경전 App
배운 점
첫번째, 개인적으로 서버 배포는 귀찮아도 1부터 100까지 내가 다 하는게 편하다. 불편해도 경험해보자는 마인드로 EC2를 사용했는데, GCP로 Crontab을 사용하라 그랬으면 음...기능이 있긴하겠지...? 물론 처음에 ssh 접속도 제대로 안되고 그래서 Elastic Beanstalk을 쓸까도 고려했었지만, 결과적으로는 안쓰길 잘한 것 같다.
두번째, 상품으로서의 가치를 고려해야한다. 브리핑때마다 대표님이 얘기해주신 것이 상품으로서 가치가 있는지였다고 생각한다.(물론 이걸로 돈 못번다는 얘기를 하셨지만) 내가 아무리 코드를 기가막히게 짜고, 효율성이 어마어마해도 사용자가 안쓰고 싶으면 다 쓸모없는 것이 된다. 그래서 과연 나라면 이걸 내 폰에 설치해서 사용할까, 돈을 낼 수 있을까를 고민해볼 수 있었다.
세번째, 확장성을 고려해야한다. 처음에 아두이노와 서버통신을 고려할때는 단순하게 POST방식으로 쏘는 것만 생각했었다. 사실 프로젝트를 진행하는데는 상관없지만, 관련된 기능을 추가했을때 보안이슈가 생길 수 있었다. 애초에 POST도 주소만 알아내면 얼마든지 가짜데이터를 보낼 수 있었고, 나중에 미세먼지가 일정수준을 넘어갔을때 다른 IoT기기를 컨트롤하는 기능이 추가되면 더 큰 문제가 될 수 있었다. 이런 문제를 해결하기위해 AWS IoT를 사용하려고 했던 것이지만, 아두이노 코드에 Token값을 담아서 통신하는걸로 대체했다. 가끔 다른 사람이 코딩할때 옆에서 확장성을 고려하라는 훈수를 두곤했는데, 나한테도 좀 해야겠다.
아직 안풀린 궁금증
대체 AWS IoT는 어떻게 쓰는걸까;;; AWS 발표도 보고 했는데, 아무도 안쓸줄은 몰랐다. 라즈베리파이를 이용했으면 Python에서 돌렸을텐데, 아두이노Yun도 있었는데 Uno에서 정상작동할지도 확신이 안섰다. MQTT 통신도 배울 수 있는 기회였는데, 아쉽다.
향후 어떻게 다르게 할 것 인가?
프로젝트 관리가 가장 중요한 것 같다. 일정을 계획하고 ToDo를 작성하고 현재 상황을 검토하고 빠르게 피드백하는 것. 이번엔 혼자 진행해서 소통의 문제가 없었지만, 팀원이 한명이라도 있었으면 기능 하나 추가할때마다 싸워야했을지도 모른다. 그때그때 계획을 수정하고 문제를 해결하는게 애자일이긴 하지만 싸우면서까지 할 필요는 없으니까...
그리고 새로운 프레임워크는 미리미리 고려하자. 너무 대충 알아보면 나중에 분명 후회한다...계획단계에서부터 잘 알아보자.
