[엘리스] 데이터 분석 웹 서비스 프로젝트를 하며 느낀 점, 앞으로 공부할 것

안녕하세요, AI트랙 2기의 레이서 블로거로 활동중인 송성곤이라고 합니다. 이번 포스팅에서는 엘리스에서 수행한 두번째 프로젝트의 마지막 주차를 정리하면서 어떤 것들을 느꼈는지, 앞으로 어떤 공부를 해야할지에 대한 것들을 적어보려고 합니다.

3주차에 했던 일들

3주차에 한 일들과 느낀점을 정리해보면 다음과 같았습니다.

1. api 버그 수정

버그의 원인은 정말 다양했습니다.

1. 예외처리를 하지 않아서
2. 더미데이터를 넣어놔서 or 데이터가 없어서
3. 데이터 간의 스케일이 달라서 (왓챠는 5점, 다른 포털사이트는 10점이 만점)
4. 허겁지겁 코드를 짜느라 로직이 이상해져서
5. api 설계를 할 때 구체적인 고려를 하지 않아서

5점이냐 10점이냐 그것이 문제로다

다른 건 그렇다 쳐도 4번으로 버그가 났을 때는 조금....마음이 그랬습니다.

5번은 api 명세서 최초 작성시나 수정하면서도 다른 백엔드 팀원분과 정말 열심히 고려를 했는데, 어쩔 수 없이 부족한 부분들이 있었습니다. 각자 머릿속으로 생각한 구현방법 간에 차이가 있어서 그랬습니다.

예를 들어 저는 몇개가 들어올지 모르는 태그들을 요청시에 받기 위해서 ?tags=태그1-태그2-태그3,,, 이렇게 url 쿼리스트링으로 받는 걸 생각했는데, 다른 분은 json으로 생각하셨더라구요. 그 와중에 프론트 엔드에서 생각한 건 또 달라서 여러 방법이 있다는 점이 신기했습니다.

2. api, utils(데이터 삽입, 갱신 프로그램) 마무리

이 당시에도 아직 완성되지 못한 api들이 몇몇 있었고, 데이터를 삽입하거나 갱신하는 코드들은 아직 데이터가 없다는 이유로 만들지 않았기 때문에 이 작업들도 필요했습니다. 일단 데이터만 넣어두면 api작성은 빨리 할 수 있었는데, utils 파일들이 생각보다 까다로웠습니다. 그리고 그 안에서 함수들을 어떻게 모듈화하고, 어떻게 하면 이쁘게 짤 수 있을 지 생각하는 게 참 어려웠습니다. 물론 이쁘게 짜는 것도 함수들을 그럴싸하게 모듈화하여 묶는 것도 하지 못했습니다(...)

3. 배포

처음에는 VM에 깃랩 repo를 클론해서 flask run하는 방법을 할까 했었습니다. 하지만... 이왕 하는 거 멋있고 그럴싸하게 도커로 빌드하고 배포해보고 싶어서

1. 로컬에서 빌드
2. docker hub에 push (실제 현업에서는 클라우드에 docker를 관리하는 곳이 따로 있어서 이렇게는 안 한다고 합니다)
3. vm에서 pull

하는 방법으로 배포를 했습니다. 처음에 dockerfile 작성하는 것부터 참 힘들었습니다. CMD랑 ENTRYPOINT는 뭐고,,, 로컬에선 잘 되는데 빌드해서 하면 안 되고,,, 왜 이미지를 새로 빌드했는데 이전 이미지 삭제는 안 되고,,, 컨테이너에 환경변수는 어떻게 넘겨주고,,,,

어떤 날은 10시~10시30분 스크럼 이후 제가 학교를 가야해서 최종 버전을 배포하려고 했는데, 갑자기 새로 배포한 녀석이 잘 안 되는 겁니다. 진짜 너무 급해서 손발이 달달 떨렸습니다. 자칫하면 프론트분들이 api연동해서 개발하시던 작업들을 정말 하루종일 스탑하게 되기 때문에,,, 남에게 피해를 주고 싶지 않은 저로서는 정말 손이 달달 떨렸습니다... 어찌저찌 지난 버전으로 git checkout하고 다시 빌드해서 이전 버전으로 하긴 했는데, 다시는 겪고 싶지 않은 경험이었습니다. (파일 하나 수정할 때 마다 커밋을 하자)

 

 

다음으로는 프로젝트를 하면서 아쉬웠던 점과 잘한 점입니다.

아쉬웠던 점

1. 코드를 싸버림

말 그대로 코드를 쓰는 게 아니라 싸버려서, 다른 팀원분께서 이거로 피드백을 주셨을 정도입니다. 일단 급하기도 하고 나름 의미를 알 수 있다고 생각해서 몽고디비 요청 후 나온 결과물이 cursor니까 강의에서 나왔던 것 처럼 cur라고 쓰곤 했었는데 어떤 쿼리의 결과인지 명확히 알 수 있게 객체명이든 콜렉션 명으로든 변수명을 짓고, 리팩토링 하는 시간을 가질 수 있게 마감기한을 빡빡하게 잡았다면 좋았을 것 같습니다.

2. 웹서버 사용을 하지 못한 점

flask run을 하면 알 수 있듯이 실제 배포에서는 uwsgi나 nginx등을 사용했어야 됐는데, 그냥 flask 내의 서버로 배포한 점이 아쉽습니다. nginx랑 uwsgi를 연동해서 배포하고 싶었는데, 뭔지도 모르고 그냥 복붙해서 배포하는 것도 이상한 거 같고 컨테이너로 배포하려면 docker-compose도 써야해서 너무 어렵게 느껴졌습니다. 다음에는 웹서버를 미리 공부해서 배포 시점을 빠르게 잡아야겠습니다다.

3. git을 제대로 활용하지 못한 점

저는 처음에 로컬에서의 work 브랜치랑 clone했을 때 딸려온 remote의 work브랜치가 연결이 안 되는 건 줄 알고 브랜치를 엄청 이상하고 복잡하게 사용했었는데, upstream하면서 알아서 잘 되더라구요 하하

그리고 협업하거나 브랜치 생성하는 부분에서도 저때문에 괜히 이상해졌던 것 같습니다. 다음에 한다면 꼭 work브랜치를 만들고 feature브랜치를 자주 병합하면서 코드리뷰하는 그림이 나오면 좋겠습니다.

잘한 점

미리미리 배포를 자주 함

최종발표 안내 노션 페이지

발표 안내에 나와있듯이, 라이브 데모 시에는 VM에 배포가 완료되어있어야 하는데, 몇몇 팀들은 배포가 안 되어있거나이슈가 발생하여 라이브데모를 localhost에서 진행하는 모습들을 보여줬습니다. 그에 반해 우리팀은 미리미리 빌드를 테스트하고, 배포를 자주해왔고 백엔드 최종 배포는 전날에 올리고 특별히 수정할 부분이 없었기 때문에 라이브 데모를 안정적으로 진행할 수 있었습니다.

공부할 것, 해보고 싶은 것

docker

• CMD, ENTRYPOINT의 차이점
• TARGET? NAME? 

docker-compose

• docker-compose를 쓰면 포트나 환경변수 등 이런저런 것들을 편하게 설정할 수 있는 것 같았다.

쿠버네티스

• 아직 급하진 않은데, 언젠가 필요할 것이라 생각한다.

nginx, uwsgi

• 다음 프로젝트에서는 nginx와 flask를 docker 혹은 docker-compose로 엮어 깔쌈하게 배포하고 싶다.

네트워크, CS

• 80, 443 포트가 각각 http, https를 의미한다는 것을 알고 충격적이었다...
• 백엔드 로드맵의 Internet, OS and General Knowledge 부분에 대해 공부해야 될 것 같다.

기억해두고 싶은 정보들)

코치님께서 알려주신 필요 없는 이미지, 컨테이너 제거하는 명령어

docker system prune -af --volumes

# ORM에서 편하게 to_dict 정의하는 방법 for 직렬화(serealize)
def to_dict(self):
    return {x.name: getattr(self, x.name) for x in self.__table__.columns}