Foowinkle MVP앱 개발 기록: 개발(1)

기획 단계에서의 요구사항, 디자인 미션 등을 바탕으로 본격적인 개발에 착수하게 되었습니다. 이번 프로젝트에서는 Kotlin 프론트엔드 개발이 가능한 팀원분과 저 2명이서 MVP 개발을 진행하였고, 저는 백엔드 개발을 담당하게 되었습니다. 시장 가설을 검증할 수 있는 MVP를 어떻게든 만들어 내는 것을 목적으로 난생 처음 JavaScript 문법, AWS 클라우드 서비스도 배워가면서 진행했기 때문에 부족한 부분과 시행착오가 많았습니다. 읽어주시는 분들께서는 "아 저렇게 할 수도 있구나~" 정도로 가볍게 읽어주시면 감사하겠습니다.

 

개발 과정은 문과생인 저에게 모든 것이 난관이었기 때문에.. 어떤 난관들이 있었는지 설명해보면서 회고해보겠습니다.

프로젝트 관리

사실 두명이서 진행하는 프로젝트였기때문에, 그냥 좋은 게 좋은거지~ 카톡으로, 전화로 이야기하면 될 것 같다고 생각했었습니다. 하지만 실제로 프로젝트를 진행해보니, 바로 지난 주 회의에서 이야기했던 것도 가물가물해지고, 요구사항들도 따로 문서화 해놓지 않으면 서로 말이 달라 문제가 발생했습니다. 이러한 문제가 발생하자, 더 이상 기술부채가 생기지 않도록 하기위해 빠르게 노션으로 문서화하여 협업을 진행하기로 했습니다. 

노션 협업 페이지

API 명세

프론트엔드는 안드로이드 Kotlin, 백엔드는 Node.js로 진행했고, 서로 각자의 영역만 각자 담당했기 때문에 사실상 대부분의 협업은 API문서를 통해 진행되었습니다. API 문서를 작성하고 활용하면서 느낀 점은 

 

1. 들여쓰기, 제목(h1,h2,h3) 깊이 설정을 잘 해야 가독성이 높고 오해의 소지가 생기지 않는다.

2. 변수 타입, 설명만 보고는 이해하기 어려우니 샘플코드를 작성하는 것이 좋다.

3. API 수가 많아질 수록 찾기 어려우니 잘 분류를 해놓아야 한다.

 

라는 점입니다.

 

API 명세문서의 일부

전국 식당 데이터 확보

시장 가설을 효과적으로 검증하기 위해서는 갤러리에 있는 음식 사진들을 손쉽게 앱 내에 아카이빙 할 수 있도록, 사진만 올리면 식당 이름을 알려주는 기능이 필수적이었습니다. 뿐만 아니라 이 부분이 사용자들에게 다른 서비스가 제공하지 않는 "WOW moment" 가 될 것으로 생각했기 때문입니다.

 

사업계획서에는 공공 데이터 포털에 있는 식당 데이터를 확보할 것이라고 했지만, 공공데이터를 다운로드 받아서 확인해보니 여러 문제를 발견하였습니다.

 

문제 1: 공공데이터의 좌표계가 중부원점 좌표계(..난생처음 들었던 좌표계)였다. 사진에서 추출한 위치 좌표계(위경도)와 달랐다. 좌표계 종류가 이렇게나 복잡하고 많다는 사실을 처음 알았다.

문제 2: 전국 식당 DB를 받았더니 너무 크기가 커서 엑셀로 열리지도 않았다.

문제 3: 위치 좌표 정보가 없는 식당도 꽤 많이 있었다. 

문제 4: 동일한 Row가 많았고 폐업한 식당도 상당 수 존재했다.

문제 5: DB는 다운로드 받은 그 당시의 정보라 시간이 지나면 다음에 같은 작업을 반복해야만 했었다.

 

초반부부터 예상치 못한 문제들이 닥쳐서 당황하기도 했지만, 곧 해결책을 찾고 DB를 구축했습니다.

 

문제 1 해결방법)

문제 1 ) 공공데이터의 좌표계가 중부원점 좌표계(..난생처음 들었던 좌표계)였다.  사진에서 추출한 위치 좌표계(위경도)와 달랐다.

구글에서 중부원점 좌표계 -> 위경도 로 변환하는 엑셀 수식 파일을 받아서 모든 Row에 적용했습니다.

자동 변환해주는 사이트도 있었지만, 속도가 너무 느리고, 횟수제한이 있어 활용하지 않았습니다.

하지만 엑셀 파일로 변환 결과를 구글 맵에 찍어보니 정확한 좌표가 나오지 않았습니다. 그래서 결과 좌표값을 몇개 더 구글 맵에 찍어보니 모두 오차가 비슷하게 나타나서, 변환 수식에 오차를 적용한 새로운 수식을 작성하고 새로운 수식으로 변환했습니다.

 

문제 2 해결방법

  문제 2) 전국 식당 DB를 받았더니 너무 크기가 커서 엑셀로 열리지도 않았다.

터미널에서 "split -l 1000000" 으로 csv 파일을 분할해서 엑셀로 연 후 작업했습니다. 

 

문제 3 해결방법

  문제 3) 위치 좌표 정보가 없는 식당도 꽤 많이 있었다. 

위치좌표는 없었지만 도로명주소와 지번주소는 가지고 있었습니다. 이를 위경도 좌표로 변환해주는 구글 스프레드시트 API인 지오코딩 을 활용하여 하루 무료 API 제한량 10000개씩을 매일 변환했습니다.

 

문제 4 해결방법

  문제 4) 동일한 Row가 많았고 폐업한 식당도 상당 수 존재했다.

엑셀에서 필터를 적용하여 폐업한 식당의 Row를 삭제했고, 동일한 Row의 경우는 DB에 삽입하는 과정에서 삭제되도록 했습니다.

 

문제 5 해결방법

  문제 5) DB는 다운로드 받은 그 당시의 정보라 시간이 지나면 다음에 같은 작업을 반복해야만 했었다.

공공데이터를 Foowinkle의 DB로 변환하는 과정을 문서화했습니다. 또한 최종 수정일자 컬럼을 추가하여 다시 공공 데이터를 다운로드 받으면 최종 수정일자가 마지막 DB 갱신일자 이후인 식당만을 추가하도록 했습니다.

DB 가공 프로세스 중 일부

DB 설계

draw.io

이 데이터베이스 명세는 기획 단계에서 설계했던 기능들이 추가되면서 변경된 최신 버전입니다.

DB 를 설계하면서 가장 어려웠던 부분들은 

 

1. DB 테이블간의 외래키, 관계 설정

2. 어느정도의 종속을 허용할 것인지 결정하는 것

 

처음에는 마냥 외래키를 많이 걸어서 테이블끼리 관계가 견고해지면 좋은 DB인줄 알았습니다. 하지만 외래키가 걸려있다는 것은 삭제와 수정에 제한이 걸린다는 뜻이라 마냥 많이 엮어놓는 것만이 능사는 아니었습니다. 꼭 필요하지 않은 관계는 굳이 연결시키지 않는 것이 빠른 개발 프로세스에는 도움이 되기도 했습니다. 물론 나중에 서비스가 견고해지면 테이블 간의 관계를 엮고 견고하게 만드는 것이 중요한 일이 될 수 있겠지만요.

 

그리고 식당테이블의 갯수가 몇십만개가 되다보니, DB 탐색에서의 속도를 고려할 수 밖에 없었습니다. 따라서 각 INDEX를 설정해놓아 탐색 속도를 높였습니다. INDEX를 설정하면 삽입과 삭제, 수정하는 속도는 늘지만 탐색하는 속도는 빨라지기 때문에 수정과 삭제가 수시로 일어나는 것이 아닌 식당 정보 테이블에서는 INDEX를 설정하는 것이 여러모로 옳은 결정이었습니다.

 

 

다음 글에서는 난생처음 AWS로 서비스를 구축했던 방법과 겪었던 시행착오들을 회고해보겠습니다.