Elice AI Track 2기에서 진행한 2차 팀 프로젝트가 끝이났다.
저번주 토요일날 발표를 하고 마무리를 지었는데 아쉬운 점이 많지만 그래도 배포까지 완료하고 정상적인 웹서비스를 만들었다는 것에 만족한다.

나는 백엔드를 담당하였고, 어떤 일을 하였는지 회고해보는 시간을 가지려고한다.

인프라 구축

AWS RDS

VM에다가 DB를 냅다 구축해도 상관이 없을 것이다. 첫 프로젝트때에는 그랬으니 말이다. 하지만, 이번 프로젝트는 OTT서비스(Netflix, Tving, Coupang, Watcha, wavve)의 모든 데이터가 개발 도중에 필요한 상황이였다..

그래서 AWS RDS를 구축하여 각자 DB URL만 가지고 있다면 접속할 수 있게 만들어 개발에 차질이 없도록 진행했다.

전에 Spring을 공부하면서 한 번 구축해본 경험이 있어 수월하게 만들 수 있었다.

AWS S3

우리는 각 컨텐츠의 포스터 이미지들이 필요했다. 이 이미지들을 Client가 띄우기 위해서는 Cloud Storage가 필요했고 AWS RDS도 쓰는데 AWS S3도 써보자! 해서 만들어봤다.

이건 처음하는 것이라 많이 어려울 줄 알았는데 의외로 쉬웠다.
처음에 구축하고, 이미지 URL을 불러오는게 힘들었는데 이것도 AWS S3는 권한이 있었다.. Azure CloudStorage쓸때에는 이런적이 없었던 것 같은데 여기서 권한 설정을 부여하는 게 조금 애먹었다.

해당 내용은 Python과 AWS S3연동하기 에 적어놨다.

그리고 IAM에 대해 이해했다. AWS에서는 root사용자는 모든 리소스에 접근이 가능하지만, root사용자로 개발을 진행하다가 멋모르고 코드에 key값이 노출이 된다면? 그러면 모든 aws 리소스에 접근이 가능해져 큰일이 날 것이다.

이런 일을 방지하기 위해서 AWS S3에만 접근이 가능한 IAM 사용자를 만들어 key값을 만들어야 한다. 그러면 유출이 되더라도, AWS S3의 리소스만 털릴 것이고, IAM 사용자를 삭제하고, 다시 만들어 key값을 새로 부여하면 된다.

마지막으로 연동에서 많이 애먹을 줄 알았다. 하지만 python에 boto3라는 라이브러리가 정말 나이스했다. 해당 라이브러리로 쉽게 진행할 수 있었다.

개발

API서버

Flask를 이용하여 MVC구조로 만들었다.
첫 프로젝트에서도 해당 구조로 만들었기에 어렵지 않게 잘 만들 수 있었던 것 같다.

그리고 Migration을 사용하여 DB 테이블을 만들었는데 정말 아무리봐도 이건 신세계였다. 너무너무 편했고 앞으로도 애용할 것 같다.

추천 로직 연동

프론트, 백, 데이터분석 이렇게 3가지로 역할을 분담하고 진행했는데 이제 API서버에 대한 전체적인 틀을 완성하고 데이터분석 코드와 연동하려고 하는데 정말.. 힘들었다.

왜냐하면 데이터분석은 jupyter를 이용해 진행했기 때문이다. 그래서 쉘단위로 실행한 코드들은 메모리에 남아있고 이를 사용하는 로직으로 구성되어있다보니 많은 수정작업이 이루어져야 했다.

남이 짠 코드를 연동하는것은 결코 쉬운 일이 아니였다. 로직을 이해하고 이에 맞게 수정하려고 하다가 너무 많은 시간을 사용하는 것 같고, 그냥 라이브러리를 가져다가 쓴다는 느낌으로 input, output값만 알면 되지 않을까? 하는 생각으로 연동을 시작했다.

해당 로직들은 객체로 관리해서 구현했다. 이 때, 왜 객체지향, 객체지향하는지 알 것 같았다. 팀원들과 협업을 하고 연동할 시에 객체지향적으로 개발을 하면 정말정말 편하게 작업할 수 있었다. 수정작업이 이루어져도 input값으로 뭘 주면 되죠? output은 어떤 값이 나오나요? 이것만 팀원한테 물어보고 이에 맞게 내 코드를 수정하면 되는 것이였다. 객체내부의 로직은 알 필요가 없었다.

아쉬웠던 점

기획

API명세서 작성

이거는 협업할 때 필수인 것을 깨달았다. 중간중간 개발하다가 API가 수정이 될 때가 많았는데 이 때 프론트팀원분들과 소통을 하는 것으로 API명세서로 진행했다. 이 명세서대로 작성하다보니 개발에만 집중할 수 있었다.

ER Diagram

전에 "파워오브 데이터베이스"라는 책을 읽어서 DB설계를 해보고 싶어 진행했다.
여기서 PK를 다중 값을 이용하여 ("title", "director")처럼 묶어서 진행했었는데 이런식으로 하면 FK로 진행할 때 테이블이 더 복잡해진다는 코치님의 말씀을 들었다.
현업에서도 PK는 Autoincrement로 누가봐도 unique한 값으로 사용한다고 하여 바꾸면서 많은 지식을 얻었다.

아쉬웠던 점

SQL대신에 NoSQL

아직 프로젝트를 진행해보면서 NoSQL이라는 것이 있다. 정도만 알았지 SQL로만 진행을 했다. 많이 편해서 그랬던 것 같은데 이번에 NoSQL에 대해 공부를 해보면서 우리 프로젝트를 NoSQL로 하는게 맞다고 생각이 들었다.
1. 수많은 OTT서비스의 컨텐츠 데이터들이 DB에 저장이 되는데 이는 수정이 안 일어나는 데이터들이다.
=> NoSQL은 수정/삭제가 어려운 대신 읽기가 빠르다. 이러한 점을 잘 알았으면 NoSQL을 썼을 것이다.
2. OTT서비스의 컨텐츠들의 컬럼수가 엄청 많다.
=> 필요한 컬럼도 있지만 아닌 컬럼들은 일일이 하나씩 제거하느라 힘들었는데 NoSQL로 쓴다면.. 이러한 전처리과정없이 그냥 넣어도 되었을 것이다.
3. Doc2Vec파일 저장
=> Doc2Vec모델의 파일이 있는데 이 파일의 크기가 70MB정도로 꽤 컸다. 이러한 것을 깃허브에 올리게 된다면 레포의 크기가 너무 커져 비효율적이다. 라고 생각해서 DB에 파일을 올리는 방법은 없을까? 했는데 NoSQL을 썼으면 해결되었을 문제였다.

이러한 점을 비추어볼 때 우리 프로젝트에서는 NoSQL이 맞지 않을까 싶었다.

API서버를 늦게 구축한 점

API서버는 모든 infra(AWS RDS, AWS S3)를 구축해놓고 진행했다. 하지만 이렇게 하니 프론트팀원분들이 api에 대해서 테스트를 해보지 못해서 각자 로컬에서 간단하게 api서버를 만들고 테스트를 하는 것을 알았다.
아마 내가 개발하면서 우선순위를 잘못 선택했던 것 같다. API의 요청을 받고 응답을 주는건 쉬우니 후순위로 생각했는데 협업적인 부분에서는 1순위로 잡았어야 하는게 맞았던 것 같다.

기획 문서의 부재

학교에서 "소프트웨어 공학"이라는 과목을 들었었다. 여기에서는 소프트웨어 개발기획에 대해서 다루었고 이에 대해 공부를 많이 했었다.
하지만, 막상 프로젝트에 적용하려다 보니 시간적인 여유가 부족했다. 3주라는 짧은 시간과 팀원들의 역량을 모르는 채로 진행하다보니 기획은 뒷전에 두고 먼저 개발부터! 라는 생각으로 진행했다.
그러다 보니 개발 도중에 무엇인가 수정이 되야 할 것 같은데.. 하면 어디서부터 건드려야 하고 누구한테 이 얘기를 해야하지? 라는 생각에 회의를 자주 열게되고 오히려 개발이 더디게 진행되는 상황이 연출되었다.
아직 프로젝트를 많이 진행해보지 못해서 그런 것일수도 있겠다 생각했지만 그래도 기획문서같은게 잘 정리가 되어있었다면 편하지 않았을까? 하는 생각이 든다.
Diagram등 문서를 좀 만들어두고 개발을 진행했다면.. 하는 아쉬움이 든다.