[우테코] 피움(pium) 팀 프로젝트 회고 - 8주차

8주차 회고에 앞서

마지막 8주 차에서는 로그인, 로깅 전략 수립, 모니터링 환경 구축을 진행했고 첫 배포인 1.0 버전을 출시했다.

 

마지막으로 4차 데모데이를 진행했다.

 

훌륭한 팀원들 덕분에 무사히 레벨 3 프로젝트를 마칠 수 있었다.

---

로그인

마지막 4차 스프린트에서 구현하기로 했던 로그인 기능을 구현했다.

서비스 특성 상 일반 로그인은 불필요하다고 생각했고, 소셜 로그인 방식을 선택했다. 네이버, 구글, 카카오, 깃허브 등 많은 소셜 로그인을 활용할 수 있지만, 서비스 주 타켓층인 30대 ~ 50대를 고려해 가장 범용성이 높은 카카오 로그인을 사용하기로 했다.

 

인증을 구현할 방식으로 토큰을 이용한 인증과 세션을 이용한 인증 방식 중 세션 인증 방식을 선택했다.

 

우선 현재 프로젝트 규모에서 토큰 방식과 세션 방식 중 어느 것을 사용하더라도 크게 차이점이 없다는 의견이 모였다. 더불어 최종 데모데이까지 개발에 쏟을 수 있는 시간이 5일 정도 남은 점, 단일 서버를 사용하고 있기 때문에 세션 동기화에 신경 쓸 필요가 없다는 점, JWT 토큰 인증에 대한 학습 소요 시간 모두 고려해 세션 인증 방식을 선택했다.

 

조이가 조금 고생해준 덕분에 무사히 로그인을 마쳤다 !

 

운영 환경에 올렸을 때 약간의 트러블 슈팅이 있었지만 그 과정에서 몰랐던 점(CORS 설정, 쿠키가 담기지 않는)을 많이 배울 수 있었다. 

 

로그인과 관련한 내용은 아래에서 확인할 수 있다.

 

https://blog.pium.life/OAuth2.0-backend/

OAuth 2.0 로그인 구현하기 (카카오)

 

---

로깅 전략 수립

4차 데모데이 요구사항 중 하나 인 로깅 프레임워크 적용을 완료했다.

 

스프링 부트의 기본 로그 프레임워크인 Logback을 활용해서 개발 환경, 운영 환경의 로깅 전략을 분리했고, 기존의 애플리케이션에서 발생하는 모든 출력을 담고 있는 nohup.out에서 각 환경마다의 로그 파일을 만들도록 했다.

 

개발 환경은 말 그대로 개발자가 직접 사용하고 디버깅하는 용도이기 때문에 INFO 레벨부터 모든 로그를 출력시키도록 했고, SQL과 SQL에 바인딩되는 파라미터까지 확인할 수 있도록 로그 레벨을 설정했다.

 

운영 환경은 무수히 많은 요청이 발생하기 때문에 ERROR 레벨 로그를 출력시키도록 했다. 또한 운영 환경에서 ERROR 레벨 로그가 발생하는 경우 팀 슬랙으로 알림이 가도록 구성했다.

 

슬랙 알림의 경우에는 요구 사항에는 존재하지 않았지만, 개발을 진행하면서 팀원들이 로그를 확인해야 되는 상황이 종종 발생했다. 현재 우테코에서 제공하는 서버는 캠퍼스 내에서만 접속할 수 있기 때문에 외부에서는 확인할 수 없다. 그래서 추가적으로 개발 서버의 INFO 레벨도 슬랙으로 확인할 수 있도록 설정했다. INFO 레벨부터 로깅하기 때문에 꽤 많은 알람이 발생하지만 개발 서버는 운영 서버에 비해 비교적 자주 사용하지 않고, 팀원들만 사용하기 때문에 큰 무리는 없었다. 

 

로깅과 관련한 자세한 내용은 아래에서 확인할 수 있다.

 

https://blog.pium.life/server-logging/

Logback을 이용해 운영 환경 별 로그 남기기

---

모니터링 환경 구축

AWS CloudWatch를 이용해 모니터링 환경을 구축했다.

모니터링 환경을 구축할 때 선택할 수 있는 선택지가 3개 있었다.

 

1. 현재 가용 중인 빌드 서버 내에 구축하기

2. EC2 인스턴스를 요청해 별도의 서버에 구축하기

3. AWS CloudWatch를 이용해 모니터링 환경 구축하기

 

빌드 서버 내에 구축하는 방법은 2가지의 문제점이 있었는데, 첫 번째로 빌드 서버의 메모리가 부족하다는 점이었다. 모니터링 환경을 구축하지 않는 상황에서 빌드를 위한 스왑 메모리까지 할당하고 있는데 추가의 메모리를 할당하기에는 부족했다. 두 번째로 가용 중인 빌드 서버가 문제가 발생한 경우에는 모니터링 환경까지 영향을 받는다. 그러므로 첫 번째 방법은 제한된다고 판단했다.

 

그러므로 독립적인 모니터링 환경이 필요했고 EC2 인스턴스를 추가로 요청해 사용하는 방법을 생각했다.

새로운 EC2(t3g.small)는 한 달에 약 15달러의 비용이 발생한다.

 

그에 비해 AWS CloudWatch는 기본적인 지표와 하나의 대시보드를 사용한다고 했을 때 약 5달러 내외의 비용이 발생한다.

 

비용적인 측면에서 CloudWatch를 사용하는 것이 훨씬 합리적이었고, AWS 인스턴스를 사용하고 있는 만큼 AWS에서 제공하는 모니터링 도구를 이용하는 것이 더 신뢰성 있다고 판단했다.

 

그래서 위 3가지의 선택지 중 AWS CloudWatch를 이용하기로 결정했다.

 

모니터링 환경 구축과 관련한 자세한 내용은 아래에서 확인할 수 있다.

 

https://blog.pium.life/server-monitoring/

CloudWatch를 이용한 모니터링 환경 구성

---

런칭 페스티벌

4차 데모데이는 이전 데모데이와는 다르게 런칭 페스티벌로 진행했다.

당일에 캠퍼스에 등교하니 예쁘게 꾸며져 있었다.

 

팀마다 5분간 발표를 진행했고 이후에는 각자 부스에서 서비스를 소개하는 시간을 가졌다.

 

이번 발표는 주노가 맡아서 잘해줬다 👍

 

우리 팀은 부스에서 뽑기 이벤트를 진행했고 피움 스티커, 노트북 스티커, 식물 등 다양한 상품을 준비했다 !

캠퍼스에 계시는 코치님들께서 피드백과 소중한 말씀을 많이 해주셨는데, 그중에서 브라운이 해주신 피드백이 정말 뜻깊었다.

캠퍼스에 있는 다른 조들의 부스도 전부 체험했다.

우테코 크루들 답게 완성도가 너무너무 좋았고, 재미있는 서비스들이 너무 많았다.

정말 정말 대단하고 멋있었다.

 

런칭 페스티벌을 마치고, 마지막으로 팀 회식을 했다.

 

선릉에 유명한 뼈 찜을 먹고

간단하게 2차도 하고 잘 마무리했다.

멋진 우리 팀원들 🌱

---

8주차를 마치며

훌륭한 팀원들 덕분에 레벨 3 팀 프로젝트를 잘 마칠 수 있었다.

 

우리 서비스를 함께 만들어갈 수 있는 소중한 팀원들과 함께해서 영광이었고 팀원들 간의 케미가 좋아서 협업을 하는 내내 행복하게 임할 수 있었다. 기획 단계부터 회의에 많은 시간을 투자했는데 그런 만큼 뾰족한 서비스를 만들 수 있었고, 시간 배분도 적절히 해 주어진 기간 내에 목표치를 모두 달성하며 무사히 마칠 수 있었습니다.

 

모두 정말 고생 많으셨습니다!

 

다가오는 레벨 4도 화이팅입니다 😀