냉비서: 냉장고 관리 앱 개발 일기 - 개발편

우선 1편인 냉비서 기획편!

냉비서: 냉장고 관리 앱 개발 일기 - 기획편

 

다음은 프로젝트의 github link이다.

GitHub - TeamC00K/FridgePlease: Image Detection/Classification model을 이용한 냉장고 관리 앱 "냉비서"

 

종강한 후, 어느정도 숨통이 트일 정도로 쉬고 나서 이제서야 개발편 일기를 써보려고 한다. 기획편에서 본 것과 같이 백엔드 개발을 맡게 되었는데, 나름대로 프로젝트 경험이 팀에서 가장 많았던지라 다른 쪽을 개발하는 것이나 기획에도 어느정도 관여하게 되었다. 그래서 이번 프로젝트가 이전보다 더욱 능동적으로 무언가를 결정할 일이 참 많았던 것 같다. 일단 창업 아이템을 선정한 다음, 해야 할 task를 정한 다음, 우선순위대로 일을 처리하는 것이 중요했다. 그래서 우리는 먼저 mockup screen을 만들어서 프로그램의 전체적인 틀을 먼저 만들어보려고 했다. 

아이패드로 가볍게 설계를 한 다음, 각 페이지마다 어떤 데이터들이 필요한지에 대해서 생각을 하였다. 가장 중점적으로 생각한 것은 바로 사용자 편의성이다. 대표적인 예시로는 식료품을 인식하는 과정에서 예측오차로 인한 불가피한 직접 입력을 하는 경우에 기존 앱보다 훨씬 더 간편하게 만들고 싶어서 많은 이야기들이 오갔다. 적어도 우리는 자연스럽게 이걸 입력하도록 설계하고자 했고, 결과적으로 간편한 사용자 경험을 제공하기 위해 인식된 식재료들을 확인하는 과정을 슬라이드를 통해 자연스럽게 할 수 있도록 설계하였다. 

 

그리고 알림을 통해서 유통기한이 임박한 식료품들을 유저들에게 알려주는 기능을 설계했다. 아무래도 실제 사용을 할 때 이러한 것들을 알려주지 않는다면 앱을 이용하더라도 시간날때마다 앱을 켜서 "얘는 유통기한이 언제까지지?" 라고 직접 확인을 해야하는 일이 발생하기 때문에 반드시 필요한 기능이라고 생각했다.

 

여기서 시간이 부족해서 결국 완전하게 구현하지 못한 기능이 있는데, 바로 알림이 왔을 때, 그 알림을 클릭하면 해당 음식으로 할 수 있는 레시피들을 소개를 같이 해주었는데, 마지막에 마감에 치여서 결국 완성하지 못한 기능이다. 구현 난이도는 어렵지 않지만 우선순위에서 밀리는 기능이라서 미루다가 보니 아쉽게도 개발하지는 못했다.

또한 마찬가지로 식료품의 소모 상태 또한 간편하게 변경을 하고자 하였는데, 해당 식료품의 소모상태를 슬라이드하여 어느 정도로 소모되었는지 확인을 할 수 있도록 하였다. 이렇게 해서 앱의 기본적인 틀에 대해서는 방향을 잡을 수 있었다.

 

다음으로는 전체적인 프로그램의 로직을 설계해야 했다. 아이디어가 pivot되는 과정을 거치면서 중간중간 변경 사항이 있었다.(자세한 내용은 냉비서 기획일기 참고) 여튼 최종적으로 냉비서는 아래의 플로우차트대로 동작하도록 설계하였다.

 

그렇게 flowchart까지 완성한 이후, 각각의 task에 우선순위를 할당하고, 각자에게 task를 주면서 개발이 진행되었다. 

가장 먼저 각각의 화면에서 필요한 요구사항들을 정리하고 구현을 시작했다. 그런데 이 때 다른 팀원들 대부분이 협업해서 프로젝트를 진행한 경험이 거의 없었기에  front, back, 분류 모델 등의 컴포넌트들을 연결하는 과정에서 상대방의 코드를 배경지식 없이 읽으면서 개발을 진행하였기에 개발 속도가 지연될 뿐만 아니라 서로 의도와는 다르게 API를 설계하거나 데이터 양식이나 변수명 등이 통일되지 않는다는 문제점이 있었다. 이를 해결하기 위해서 각각의 화면에서 필요한 데이터들을 정리한 다음,  front-back-모델을 연결하는 API를 설계하였다.

이를 통해서 주고받을 데이터의 양식과 변수명을 통일하고, API의 의도를 명시하며 문서화를 진행하고 이를 팀원들과 공유하는 방식으로 개발 업무를 정리했다.  API를 문서화하면 무엇보다도 자신이 작성하지 않은 코드를 분석하지 않더라도 어떤 값을 API를 통해 전송해야 하는지 명확하게 알 수 있다는 점에서 각각의 컴포넌트를 연결하는 과정을 기존보다 훨씬 편리하고 기능의 의도에 맞게 개발을 진행하는 것에 있어서 큰 도움이 되었다. 역시나 다른 사람들과 함께 협업을 할 때에는 이런 정보를 공유하는 것에 대한 중요성을 느꼈던 일이었다. 그 후 trello를 이용하여 각자의 ToDo, Doing, Done에 대한 일정을 공유하면서 일의 우선순위를 설정하여 겹치는 일이 발생하지 않도록 하였다.

 

그리고 두번째로는 데이터를 처리하는 방식에 대해서 생각을 했다. DB는 파이썬에서 주로 사용하는 DB인 SQLite를,  ORM은 인턴을 하면서 사용한 적이 있는 SQLAlchemy를 사용하였다. 아래 문서를 참고하여 설계를 진행하였다.

Flask에서 SQLAlchemy 사용하기 — Flask 0.11-dev documentation

 

DB table은 다음과 같은 방식으로 구현하고자 설계하였다. 사실 너무 간소화된 감이 없지 않다. 아무래도 실제 서비스를 염두하고 개발을 한다기보다는 창업을 위한 MVP를 빠르게 설계하는 것이 목적이다 보니 간단하게 설계를 하였다. 만약 실제 서비스를 하게 된다면 유저 각각의 정보를 훨씬 구체적으로 입력을 받아야 할것이며, table간의 관계도 훨씬 복잡해질 것이다. 그렇지만 우선은 빠르게 개발하는 것이 목적이다 보니 다음과 같이 설계를 하였다.

 

다음으로 고민한 부분은 사용자가 실시간으로 이미지 데이터를 생성하는데 이를 어떤 방식으로 수집하는지에 대한 프로세스에 대한 것이다. 가장 기본적으로는 ETL 프로세스를 거쳐서 데이터를 처리한 다음, 처리된 데이터는 S3로 저장하는 방식으로 설계하였다. 조금 더 구체적으로 이야기하자면 다음과 같은 과정을 거친다.

 

1. Extract : 냉장고 내부 카메라를 통해서 냉장고 내부를 촬영한 후, 해당 사진에서 object detection model을 통해서 어떤 식재료들이 냉장고에 있는지 찾는다.

 

2. Transform : object classification model을 통해 추출한 이미지에 해당하는 object들이 어떤 식재료인지 분류한다. 다만 이 때 classification의 기준이 되는 score를 정하는 것이 꽤나 중요한 이슈였다. 기준점이 너무 낮을 경우에는 모든 식재료를 전부 unknown인 식재료로 인식하고, 기준점이 너무 높을 경우에는 아무렇게나 분류를 해버린다. 대표적으로 비닐에 싸여있는 식재료의 경우가 대표적인데 이런 경우에는 사실 classification을 통해서 찾는 것이 거의 불가능하기에 수동으로 입력을 했어야 했다.

 

3. Load :  아까의 과정을 통해서 data labeling을 한 이후, 해당 데이터를 DB에 업로드를 하여 유저가 냉장고 관리를 할 수 있도록 한다. 이 과정에서 유통기한 등의 정보들도 새롭게 update한다.

사진을 올려서 모델을 작동시키는 기능

 

이렇게 로직과 설계를 마치고 난 후에 실제 구현을 했는데, 사실 이 부분은 그렇게 어렵지는 않았다. 다만 파이썬을 꽤 오래 써봤는데 backend를 python으로 짜본 경험을 하고 싶어서 flask로 backend를 설계하였다. 처음 배우는 거라서 약간의 러닝 커브가 있는 것 빼고는 크게 어려운 것은 없었다. 작성해야 할 API는 크게 유저의 로그인/회원가입 절차 부분과 식재료들을 인식/분류하여 db에 추가하고 화면에 식재료의 상태를 rendering하는 정도였다. 사실 이전에 다른 프로젝트를 할 때 이미 어느정도 경험을 했었던 부분이 많았기에 빠르게 코드를 작성할 수 있었다.

 

무사히 프로젝트가 끝나긴 했지만 단기간에 개발한 프로젝트이다 보니 아직 아쉬운 점들이 많다고 생각한다. 첫번째로는 데이터 파이프라인에 관련된 것이다. 아무래도 이런 AI 기반의 스타트업을 하려고 하면 데이터를 잘 관리하는 파이프라인이 있어야 한다. 다만 수업에서 한 프로젝트이다 보니 그정도의 유저 데이터를 수집하는 것이 불가능하기도 했고, ETL 프로세스 정도는 구현했으나, 그 이상의 것은 이번 프로젝트에서는 필수적이지는 않다고 생각한다. MVP를 빠르게 만들고 검증하는 것을 목적으로 하다 보니 우선순위가 조금 떨어진 감이 없지 않은데, 나중에 대규모 트래픽이 발생하는 것에 대해서도 한번 대응해보고 싶다는 생각이 들었다. 두번째로는 아무래도 완벽한 프로그램을 작성하는 것이 아니다보니 빠르게 짜는 것에 초점을 맞추게 되었고, 따라서 다른 기능들을 많이 구현한 것은 아니다보니 지식적인 측면에서는 새롭게 배우는 것이 적었다.

 

다만 이번 프로젝트는 다른 부분에서 많은 성장이 있었다고 생각한다. 대표적으로 1편에서와 같이 창업이라는 것에 대한 insight를 얻을 수 있었고, 4명이서 협업을 하면서 각자 맡은 일을 하다보니 커뮤니케이션을 하는 방식에 대해서 많은 것을 느꼈던 프로젝트였다. 내 개인적인 생각으로는 이제 엔지니어가 정말 자신의 일만 잘해도 되는 시대는 이미 끝났다고 생각하기에 조금 더 폭넓게 보는 시각을 기르고 싶었는데 이번 프로젝트를 하면서 어느정도 그 목적을 달성한 것 같아 뿌듯하다. 1등이라는 결과는 부수적으로 따라온 것이고 말이다.