팀 프로젝트 회고

Wednesday. November 25, 2020

9월 1일 시작했던 팀 프로젝트가 오늘(11/25) 끝이 났다.
프로그래밍은 11월이 되기 전에 완료 했으나, AWS 자동 배포를 하면서 여러 이슈를 만나 한 달 정도 헤맸다. (~~뻘짓, 삽질을 오지게 했다.~~)

하면서 느낀 점이 많이 있어서 회고를 해 보려 한다.

👀 시작 전에

왜 프로젝트를 시작 했나?

1년 정도 다른 직무로 일을 하다가 다시 개발 공부를 시작하는 거라, 학부생 때 배웠던 것을 상기 시킬 필요가 있었다.
그리고 개발을 쉰 기간 동안 새로운 기술들도 많이 나오고, 협업 트랜드도 바뀌어 있었기 때문에 ‘뭐부터 공부 해야 할까?’하고 막막했다.
그럴 때 가장 빠르게 답을 찾기 위해선 역시 경험을 해보는 수 밖에 없다고 생각했다.

따라서 프로젝트의 목표는?

두 가지 목표를 가지고 이번 프로젝트를 시작 했고, 다행히 목표를 이루고 프로젝트를 끝냈다.

클라이언트-서버 통신이 어떻게 진행 되는지 흐름을 익히자.
Github을 사용 해 협업 해보자.

🌦 프로젝트 소개

주제 (Subject)

`날씨에 맞춰 옷 추천하기`

매일 외출을 해야 했을 때(~~회사를 다닐 때~~), 분명 날씨를 보고 옷을 골라 입었는데 생각 했던 것보다 춥거나 더운 적이 많았다. 비가 온다는 예보를 분명 못 봤는데, 다른 사람들은 다 가지고 나온 우산을 안 가져 나온 적도 있었다.

날씨에 맞춰 옷과 아이템을 추천 해주는 서비스가 있으면 이런 실수가 줄어들 수 있을 거 같다 생각해 주제를 선정했다.

기능 (Features)

Open API 사용

openweathermap 날씨 API를 사용하여 현재 날씨와 오늘 전체 날씨 조회
네이버 뉴스 API를 사용하여 날씨 관련 뉴스 조회

MySQL DB 연결

옷 정보를 DB에 저장
현재 날씨에 맞는 옷을 가져와 랜덤으로 전달

구조 (Architecture)

Service

클라이언트가 서버로 요청(request)을 보냄
현재 날씨, 오늘 전체 날씨, 뉴스 기사를 해당 Open API에 요청
DB에서 (Open API로부터 받은)현재 날씨와 적합한 옷을 탐색
날씨 정보와 옷 정보, 뉴스 정보를 클라이언트에게 전달(response)

DevOps

로컬 레포지토리에서 개인 원격 레포지토리(Github)로 push
개인 원격 레포지토리에서 팀 원격 레포지토리로 pull request 하고, 팀원 확인 후 merge
Github webhook으로 인해 Jenkins에서 해당 이벤트를 감지
Jenkins에서 자동 빌드 및 AWS 배포

🤓 이런 걸 배웠다.

서버-클라이언트 관계를 받아들이게 됐다.

http 메소드에 대해 이론으로 아무리 빠삭 하게 공부 해도 실습 때 못 쓰면 말짱도루묵이다. 프로젝트를 처음 시작할 때는 get, post를 어떻게 적절하게 사용 해야 하는지도 몰랐다.
그리고 클라이언트에게 어떻게 response 해야 하는지도 몰랐다. 하지만 이젠 자연스러워졌다. 머리로만 이해하는 게 아니라 받아들이게 됐다.

서버에 대한 개념을 확장하게 됐다.

서버의 구조에 대해 깊게 고민 해보지 않았었고, 보안에 대해서도 가볍게 생각 했었다.(잘 모르니까 진지하게 생각해야 한다는 것 조차 몰랐다.)
서버를 켠다는 것의 의미와 포트 포워딩(port forwarding), 클라우드 서비스를 사용하는 이유를 이해하게 됐다.
더 나아가 로드 밸런싱, 오토 스케일링, 마이크로 서비스와 같은 것들의 개념도 알게 됐다. 언젠가 구축 해볼 기회를 만들어야겠다.

AWS를 맛봤다.

클라이언트를 맡은 팀원이 로컬에서 충분히 테스트를 해볼 수 있도록 하기 위해서 AWS를 사용했다.
AWS는 처음이라 굉장히 낯설었다. 하지만 필요하면 어떻게든 해낸다.
VPC, subnet, EC2, RDS 등 구조를 뜯어보고, 학부생 때 배웠던 네트워크 지식들도 총 동원 해서 이해 해 서버를 구축했다.
그러고 나니 매번 서버를 배포하기 번거로워 Jenkins로 자동 빌드 및 배포를 할 수 있도록 했다. (정말 여러 번의 실패 끝에 해냈다.)

git 사용이 자연스러워졌다.

clone이랑 fork의 차이점이 뭔지, remote라는 게 뭔지, 어떻게 이걸로 다른 팀원이랑 협업 해야 하는 건지 하나부터 열까지 몰랐다.
하지만 이제 브랜치를 나눠 사용하고, 레포지토리를 관리하고, pull request를 하는 등.. 구조에 대한 이해를 바탕으로 git 사용이 자연스러워졌다.
이렇게 되기까지 정말 팀원이랑 많은 삽질을 했었다.. 아직도 모르는 게 많이 나오지만, 새로운 걸 더 쉽게 받아들일 준비가 된 거 같다. (github으로 협업한 방식에 대해 조만간 글을 쓸 예정이다.)

😭 끝나고 보니, 아쉬운 것 투성이다.

프론트 파트에게 불친절 했었다.

백엔드-프론트를 나눠서 프로젝트를 한 게 처음이었다. (학부생때 한 적이 있었으나, 개발 협업을 하는 느낌보다는 과제를 팀원들과 하는 느낌이었다.)
그래서 어떻게 하면 프론트와 좀 더 원활하게 협업을 할 수 있는지 몰랐다. 예를 들어, response할 때 상태 코드와 에러 메시지를 보내야 한다거나, 라우터에 따라 어떤 http 메소드를 사용하고, body에 어떤 값을 줘야 하는지 정의 해줘야 한다는 것을 몰라 우왕좌왕 했다.
지금 생각하면 Swagger와 같은 문서를 작성해 공유 했으면 좋았을 거란 아쉬움이 남는다.

프로젝트 규모가 너무 작았다.

모르는 걸 공부하면서 하느라 오래 걸린 것도 있지만, 지금 보면 ‘이렇게 기능이 얼마 없는데 왜 2달이나 걸렸지?’ 싶을 만큼 규모가 작았다. (개구리 올챙이적 생각 못 하는 거일 수도 있지만..)
아이디어가 재밌었던 만큼 좀 더 다양한 기능을 생각 해 개발했으면.. 하는 아쉬움이 있다.

DB를 활용한 기능이 부족하다.

AWS RDS를 사용해 MySQL DB를 구축 했고, 사용하는 기능은 날씨에 맞는 옷을 탐색하는 것 뿐이다.
Read만 할 거면 MySQL 같은 관계형 데이터베이스가 아닌 MongoDB와 같은 NoSQL을 사용하는 게 더 좋았을 수도 있다. (물론 지금 데이터가 너무 적어 성능 비교도 안 된다.)
관계형 데이터베이스를 쓴 만큼 회원관리나 옷장 기능과 같은 CRUD를 넣었으면 더 좋았을 거 같다.

테스트 서버와 배포 서버를 구분하지 않았다.

AWS를 공부 하다 보니, 서버를 구축할 때 테스트용과 배포용을 구분해야 한다는 것을 알게 됐다. 하지만 그러지 않았다. AWS를 사용하기로 한 이유가 클라이언트가 쉽게 테스트를 해볼 수 있도록 하기 위해서였고(원격 서버를 사용해서), 처음부터 완벽할 수 없기에 일단 AWS에 서버를 구축해보는 것에 의의를 뒀기 때문이다.
기회가 된다면 제대로 해보고 싶다. 다음 프로젝트에서는 해볼 수 있길! (프리티어 안 쓰고 해볼 수 있음 좋겠다..ㅎㅎ)

무중단 배포를 하는 구조가 아니다.

Jenkins와 Github webhook을 사용해 원격 레포지토리에 변화가 생기면 AWS EC2에 있는 서버를 중단하고, 다시 clone 해서 서버를 실행하도록 했다. (pm2를 사용했다.)
실제 운영되는 서비스가 아니기에 이런 방법으로 자동 배포의 맛을 봤으나, 나중에는 NGINX나 Docker를 사용해 무중단 배포를 구현해보고 싶다.

☔️ 회고를 마치며

규모가 작은 프로젝트였지만, 약 3개월동안 참 알차게 배웠다. 프로젝트를 시작하기 전보다 발전한 내 자신이 느껴져서 뿌듯하고, 어떤 게 부족한지 알게 돼 앞으로 공부하고 싶은 것과 해보고 싶은 것이 생겼다.

프로젝트를 끝내고 나니 ‘아 이걸 왜 이렇게 했을까?’하는 아쉬움이 남듯, 몇 개월 뒤에 이 회고를 보면서 ‘이걸 왜 몰랐지?’라고 생각하겠지? 그러길 바라고, 그러기 위해 더 열심히 공부 해야겠다.

🌈 혹시 궁금하다면!

Joie-Kim

배운 것을 기록하는 습관! ✍️