• "밥타" 서비스는 에브리타임 시간표를 통해 사용자간의 빠른 약속 시간을 잡을 수 있도록 도와주는 서비스다.
• 에브리타임 시간표 이미지를 넣으면, 함께 약속을 잡을 사용자들끼리의 시간표 정보로 언제 만나면 되는지 알려준다.
• 서강대학교 수업시간을 기준으로 만들었고, 서강대학교의 수업 시간은 1시간 15분, 쉬는 시간은 15분이기 때문에 단위를 가정하고 데이터 처리를 진행한다.
  

시작하게 된 계기

처음 서비스에 대한 아이디어를 떠올리게 된 건 18년도 여름, 1학년 때였다. 개발에 대한 지식도 전무했을 때였고, 아는 것이라고는 학교에서 배운 c언어가 전부였기에 아이디어로만 남아있었는데, 인턴으로 Object detection 모델을 개발하는 일을 하게 되면서 예전에 내가 하고 싶었던 아이디어를 구현할 수 있겠다는 생각을 하게 되었다.

그러나 시험기간 때도 그러하듯, 오늘 할 일은 내일의 내가 하기 때문에 미루고만 있다가, 동기 중 한 명이 "그것 참 흥미롭네" 하고 프론트 개발을 하겠다고 했다. (아마 혼자 하려 했다면 아직도 완성 못 하지 않았을까...?)

그렇게 퇴근 후 틈틈히 개발을 시작하게 되었다.

개발 기간, 협업 방식

원래 예상한 개발 기간은 1달이었다. 규모가 큰 서비스도 아니고, 나도 그렇고 동기도 그렇고 프로젝트 경험이 있어서 개발에 어려움을 겪을 것 같지도 않았기 때문이다. 또한, 개발 전 기획 회의에서 미리 개발에 필요한 api들과, req, res 형식까지 확정지었기 때문에 정말 개발만 하면 됐다.

그래서 실질적으로 하루에 개발할 수 있는 시간은 퇴근한 후였음에도, 일주일에 2~3일? 정도 하루 1시간 정도 투자해서 여유롭게 개발했던 것 같다.

프로젝트를 진행하면서 기획 단계에서 딱 1번 만났고, 모든 회의나 진행 상황 공유는 notion 으로 진행했다.

앞에서도 언급했듯 기획 단계에서 거의 모든 것을 정하고 들어갔기 때문에 개발하는데 어려움이 크게 없었고, notion에 이슈들을 모아 관리했기 때문에 좋았던 것 같다.

notion을 사용하면서 좋았던 점은 한 문서를 누구나 편집할 수 있다는 점인데, 이번 프로젝트에서는 핸들링 해야 하는 에러나, 구현해야 하는 기능들을 모아 놓고 관리해서 우선순위를 쉽게 알 수 있었던 것이 좋았던 것 같다.

사소한 것 하나 놓치지 않는 꼼꼼한 팀원... 그저 감사하다...

사용한 스택

사용한 스택은 다음과 같다.

• FastAPI
• Docker
• OpenCV
• Notion API

Fast API

우선 FastAPI는 회사에서 다른 팀원분께서 가볍고 빠르게 프로토타입 만드는데 좋다고 추천하셔서 사용했고, Docker 는 이제는 오히려 안 쓰는게 더 불편해졌다.

사용해본 결과 역시 FastAPI 가 괜히 핫한게 아니라는 걸 알게 되었다. 개인적으로 마음에 들었던 점은, "docs 가 자동으로 생성된다" 랑 "공식 도큐멘트 페이지가 너무 잘 되어있다" 였다.

아마 다들 도큐멘트 보고 개발하다가, 오류가 생기면 거의 무조건 stack overflow 로 넘어갈 텐데, 이번 개발을 하면서 거의 그런 점이 없을 정도로 자세하고 여러 상황에 맞게 설명이 아주 잘 되어있다. (심지어 FastAPI docker image 만드는 것도 공식 문서에 튜토리얼로 있다)

급하면 바로 아래로 내려가라는 친절한 말까지...

Notion API

보통 노션은 기록용으로 사용하거나, 잘 사용한다 해도 협업 툴로 사용하는데, 이번 프로젝트에서 나는 노션을 DB로 사용했다. 이 점이 이 프로젝트에서 재미있는 점이라고 생각한다.

우선 Notion API 를 사용한 이유는 다음과 같다.

• 빠르게 프로토타입을 만들고 싶었다.
• 테이블을 설계해보니 관계형 db를 사용할 이유가 없었다. (table이 1개 내지 2개)
• 그냥 내가 써 보고 싶었다.

좋은 점은 우선 매우 쉽게 사용할 수 있다는 점이다.
sql이나 다른 db 구축을 전혀 할 줄 모르고, 단순히 python이나 js만 할 줄 아는 사람도 공식 문서 보고 코드 몇 줄만 치면 구현이 가능하다는 점이 강력한 점인 것 같다.

또, 노션 자체가 시각화를 잘 해줘서 노션 페이지 자체가 디비가 되기 때문에 보기 편하다는 점이다. 따라서 개발을 전혀 모르는 팀원이 디비에 접근하여 원하는 인사이트를 볼 수도 있고, 노션 페이지 자체에서 필터링이나 카운팅 등을 할 수 있다.

실제로 개발할 때 프론트에서 db를 노션으로 볼 수 있으니까 테스트를 할 때 어디서 오류가 있는지 빠르게 찾을 수 있는 장점도 있었다.

하지만 뭐든 처음 하는 건 러닝커브가 있을 수 밖에 없다. 따라서 그냥 rds같은 전통적인 db가 익숙한 개발자라면 그냥 rds 쓰는 것도 좋을 듯 하다. 그리고 api에 의존적이다 보니 할 수 있는 것들이 제한적이다.

결론을 말하자면 "가벼운 사이드프로젝트를 할 계획이며, 한 번 써 보고 싶다면" 시도해보는 것을 추천한다.

OpenCV

이번 프로젝트는 "시간표 이미지에서 시간을 추출하는 것"이 핵심이었기 때문에 이 부분에 가장 많은 시간을 투자했다. 처음부터 backend app단에서 테스트하지 않았고, jupyter notebook 에서 먼저 시간표 이미지에서 강의 시간을 추출하는 프로그램을 만들고 난 후 그 로직을 그대로 백엔드 앱에서 사용하는 방식을 택했다.

이미지 처리하는 로직은 다음과 같은 순서로 진행되었다.

input img size 통일하기 - ROI 설정

사용자는 에브리타임 시간표를 input 으로 넣는데, 이 사진이 화면 캡처일 수도 있고, 앱 상에서 "이미지로 저장하기" 를 통해 저장한 사진일 수도 있다. 무엇보다 가장 큰 문제는 이미지의 width, height 가 전부 다를 수 밖에 없다는 점인데, 이를 해결하기 위해 정말 많은 고민을 했다.

아래 보이는 두 시간표는 동일한 시간표이지만, 이미지 사이즈도 다르고 시간표 영역도 다르다. 먼저 어떤 이미지가 들어오든 동일하게 처리하기 위해 전처리를 해 주어야 했다.

수행한 방법으로는 contour를 통해 시간표 박스만 잘라서 동일한 로직으로 데이터가 추출될 수 있도록 전처리를 해 주었다.

강의 시간 추출하기 - otsu, contour

앞에서 ROI에 맞게 input data의 전처리를 진행하였다. 이제 필요한 정보는 "사람이 눈으로 시간표를 보듯이, 수업 시간이 어디에 있느냐"였다.
사람의 경우 색상으로 다른 시간표임을 알지만, 컴퓨터에서 이러한 예외 처리를 다 해주기 어렵기 때문에 gray scale로 바꾼 후, otsu 알고리즘을 이용하여 수업 시간의 영역만 볼 수 있도록 처리를 해 주었다. 마지막으로 contour를 통해 수업 시간의 이미지 상에서의 좌표 정보를 저장할 수 있었다.

왼쪽부터 순서대로 원본 이미지, gray scale로 변환한 이미지, contour로 box를 친 이미지, otsu 알고리즘으로 수업 시간만 남긴 이미지이다.

해당 강의 시간의 시간, 요일 추출하기

이 부분이 가장 어려웠는데, 그 이유는 역시 input의 이미지 사이즈가 전부 다 다르기 때문이었다. 결국 이 문제는 input 이미지의 비율 로 해결했다.
해당 좌표가 전체 이미지 상에서 가로, 세로 기준 어느 위치에 있는지 비율 계산을 통해 약간의 오차가 존재하지만 어떤 시간인지, 무슨 요일인지 알아낼 수 있게 되었다.

데이터 추출을 완료한 후

만들어진 코드를 필요한 부분만 남기고 정리한 후, FastAPI 앱에서 모듈로 import하여 사용했다.

코드 리팩토링까지 한 후의 전체 코드는 150줄 정도로 매우 간결한 코드가 완성되었다.

마치며

우선 예전에 만들고 싶었지만, 실력이 없어서 아이디어로만 남겨놓았던 프로젝트를 이후에 혼자 힘으로 만들 수 있다는 점이 매우 좋았고 (이게 낭만이지), 기획부터 개발, 배포까지 전부 내가 하고 싶은 대로 진행할 수 있었던 점에서 애착이 남는 프로젝트였다.

또, 믿음직스러운 동기와 함께 개발할 수 있어서 어려움도 없었고, 디자인적 안목도 있는 친구라 완성된 페이지가 내가 구상했던 것보다 좋아서 200% 만족한다. (프젝의 퀄리티는 역시 디자인이 좌우한다....)

이번 프로젝트를 통해 앞으로 만들고 싶은 것이 있다면, 주저하지 않고 바로 실행으로 옮길 수 있는 실력을 항상 가지고 있어야겠다는 것을 느꼈다. 아마 어떤 분야든 계속 공부해 나가지 않을까...

이제 한동안은 밀린 블로그 정리도 하면서, 머신러닝 공부를 이어나갈 것 같다.

---

여담으로, 서비스 이름 짓는 게 제일 힘들었다.

밥타 구경하러 가기
github 레포