프로젝트 소개
"White Day"는 나만의 캔디를 커스텀하고, 달콤한 말을 담아 친구의 캔디머신에 캔디를 보내는 프로젝트입니다.
프로젝트 스크린샷
기간
제작 기간
2022년 1월 말 ~ 2022년 3월 13일 (약 50일)
서비스 기간
2022년 3월 14일 ~ 2022년 3월 20일
팀원
- FE : 김형록, 변찬우, 유시온
- BE : 양시준 (나), 조재영
- DevOps :김시훈, 노가성
- Design :안진형, 양세련
기술 스택
- FE
- BE
- 추가 예정...
- DevOps
- AWS
- Design
- Figma
프로젝트 계획
본래 계획하던 프로젝트가 여러 이유로 취소되어 새로운 프로젝트를 기획하게 되었다.
어떤 프로젝트를 할지 의논하던 중 5기 학생들끼리 처음 진행하는 프로젝트라서 협업에 좀 익숙해질 겸 가벼운 프로젝트로 진행하자는 의견과 모든 사람들이 즐길 수 있는 프로젝트를 하고 싶다는 의견이 팀원들의 공감을 받았다.
논의를 통해 저번 크리스마스에 유행했던 산타 파이브의 크리스마스 트리 꾸미기를 오마주한 회이트데이 프로젝트를 기획하게 되었다. (산타파이브 팀에게 오마주 허락을 받았다.)
차이점
크리스마스 트리 꾸미기를 오마주 했지만 그대로 따라하기 보다는 단점을 보완하거나 뭔가 특별한 기능을 가겼으면 좋겠다는 생각이 들었고, 팀원들 역시 동의해 주었다.
산타파이브 팀에서 작성한 회고록에서 자체적인 로그인을 이용하면서 계정을 분실하는 문제에 대책이 없었다는 식의 내용이 있어서 그걸 보완해서 화이트데이에선 OAuth2 로그인을 지원하기로 했다.
교내 배포 vs 국내 배포
기획 중 배포에 관해서 의견이 갈렸는데 국내 배포를 하자는 쪽과 교내 배포를 하자는 쪽으로 나뉘었다.
국내 배포를 희망하는 쪽은 이 프로젝트에 욕심이 있고, 이후 진행 할 프로젝트는 교내 대상으로 할 예정이기 때문에 지금 아니면 교내 배포를 할 수 없다는 쪽과 교내 배포를 희망하는 쪽은 아직 우리가 국내 대상으로 할 짬이 아니다, 서버 비용이랑 해킹같은 부분은 어떻게 할 거냐는 쪽이 있었다.
결국 현실적으로 서버 비용과 디도스, 해킹 같은 보안에 대한 대처가 부족하다는 결론이 나와서 교내 배포를 결정하게 되었다.
늦춰진 개발
하지만 중간에 겨울방학 기간에 하는 토익사관학교와 방과후 수업으로 인해서 3주간 진척이 없었고, 이후 개발을 들어가게 되었다.
개발 단계
가볍게 계획한 프로젝트인 만큼 개발 난이도는 솔직히 낮았고 분량도 적어서 초반까지는 순조로웠다.
나는 백엔드에서 유저 관련 로직을 담당했고, 개발하면서 있었던 여러 사건들을 정리해 보았다.
미뤄진 OAuth2 구현
같은 팀 4기 선배들이 OAuth2를 이용한 인증 서비스를 만들어 팀 프로젝트에 공유 사용하겠다는 말을 해서 임시로 로그인/회원가입 로직을 구현하게 되었다.
임시로 로그인/회원가입 을 구현할 때는 스프링 시큐리티에서 기본으로 지원하는 session방식을 사용했다. (그 때는 rest api 서버에서 session을 사용하는 건 권장되지 않는 방식이라는 것을 몰랐다.)
팀 프로젝트에서 방출?
화이트데이 프로젝트는 학생을 위한 프로젝트도 아니고, 어떤 특별한 목적보다는 가볍게 할 수 있는 프로젝트를 선택했기 때문에 우리 프로젝트가 팀 프로젝트의 방향과 맞지 않는다고 느낀 팀원들이 많아서 5기 팀원들이 진행한 자체적인 프로젝트로 변경되었다.
따라서 팀 프로젝트의 도메인과 화이트데이 프로젝트의 도메인이 다르게 되어 우리가 OAuth2 구현을 하게 되었다.
OAuth2 구현 중 문제 발생
내가 구현해본 적 있는 OAuth2 방식은 OAuth2-Client 프레임워크를 사용한 방식이였고, 이번 프로젝트에도 OAuth2-Client 방식을 사용하게 되었다.
하지만 여기서 문제가 발생했는데 나중에 API 연동 작업에 들어갔을 때 로그인이 끝난 후 리다이렉트 되는데 그 때 프론트 페이지에 세션 값이 담긴 쿠키가 전달되지 않는다는 문제였다.
원인을 찾아보니 rest api 서버를 사용해 도메인이 서로 달라서 쿠키를 전달해 줄 수 없었다.
하지만 시간이 없었던 우리는 결국 파라미터에 세션 값을 보내주면 프론트엔드에서 받아서 쿠키를 만드는 비효율적이고 문제가 많은 방식으로 진행하게 되었다.
❗ 지금 생각해보면 테스트 할 때만 도메인이 달랐고, 실제로 서비스 할 때는 같은 도메인을 사용했으니 굳이 저런 문제가 많은 방식을 사용하지 않아도 잘 동작했을 것이다.
😥 그때도 잘 생각했으면 알 수 있었을 텐데 정신이 없었는지 생각하지 못했던 것 같다...
문제를 대하는 자세
프로젝트를 진행하면서 크고 작은 문제가 있었는데 나는 매번 빨리 덮고 넘어가는데 급했던 것 같다.
한 선배가 OAuth2 구현에 문제가 있다는 사실을 알았을 때 문제의 근본적인 원인을 찾는 행동을 보고 내가 잘못 행동했구나 하는 생각이 들었고, 근본적인 원인을 찾는데 필요한 CS 지식도 없다는 것을 느꼈다.
지금도 그 때 문제를 침착하게 대응했으면 결과가 다르지 않았을까 하는 생각이 든다.
결국 늦춰진 런칭 날짜
여러 문제(방학으로 인한 소통 문제, 구현 문제 등)로 인해서 예상보다 개발 날짜가 길어졌고 결국 런칭 날짜를 일주일 늦추기로 결정했다.
배포는 어떻게?
교내 배포를 할 때 어떻게 배포하는 게 좋을지 관한 논의가 있었고, 학교에서 지원하는 웹 서버를 사용하기로 결정했다.
하지만 학기 초반이라서 학교 웹 서버를 옮기거나 건드리는 일이 많았고 그 때문에 마지막 연동 확인을 할 때도 자주 연결이 끊어지곤 했다. 결국 이런 상황에서는 배포가 힘들다고 판단했고, AWS를 사용해서 배포하는 방식으로 변경했다.
이 때가 배포 4~5일 전이었다. DevOps 쪽에서도 구현에 문제가 많이 발생했지만 주말까지 불태운 우리는 결국 런칭 하루 전날에 기숙사 저녁에 모여 서비스가 정상적으로 작동한다는 확인을 했고, 신난 우리들은 각자 못 잤던 잠을 자기 위해서 헤어졌다.
프로젝트 런칭
2022년 3월 14일 오전 8시 우리는 프로젝트를 런칭하고, 학교 학생들에게 홍보를 했다.
10분도 안돼서 몇십 여명 가까이 생긴 유저를 보고 나와 팀원들은 만족스러워했다. 하지만...
일어난 대 참사
런칭한지 약 2시간 이후 여러 문제를 도와주셨던 선배가 갑자기 DB에서 편지의 본문을 담당하는 컬럼에 다 NULL 값이 들어가 있다는 말을 했다.
원인을 찾아보니 프론트엔드에서 api key 값을 잘못 작성한 것이였다.
대응
예기치 못한 사태에 당황한 한 DevOps 팀원이 DB 테이블을 날려버리는 실수를 하고 말았다. 하지만 빠르게 프론트엔드에서 문제 대처를 하고 다시 배포를 했다.
결론
문제를 발생하고 해결하기까지 20분도 걸리지 않았지만 결국 서비스 런칭 이후 약 2시간 동안 저장된 데이터가 전부 날아가 버렸다. (약 40 여 명이 가입하고 편지을 작성했었다.)
서비스 런칭 초반에 관심이 컸었는데 수정을 위해서 서비스를 잠시 중지하고 다시 런칭하자 관심과 참여도가 이전에 비해 줄어들었다.
느낀 점
근본적인 문제는 프론트엔드에서 있었지만 백엔드에서 값 체크나 DB에서 도메인 설정 등 일어날 수 있는 실수를 대처하기 위한 처리를 하지 않았다는 것에서 벡엔드에도 문제가 있었다고 생각한다.
아무리 일정에 쫓기고 정신이 없더라고 테스트를 확실히 해야했다.
서비스 전날에 회원가입까지만 확인하고 신나서 더 테스트하지 않은 내 업보라고 생각한다... 😪
느낀 점
사실 중간에 여러 문제가 생겼을 때 프로젝트가 터질 수도 있겠다고 생각했지만 서비스까지 하게 돼서 좋았다. 다만 코드 구현을 깔끔하게 하지 못해서 아쉬운 건 어쩔 수 없는 것 같다...
서비스를 하기 위해서는 도메인, 서버, 보안, 테스트, ... 등 신경 써야 할 부분이 많고 복잡하고, 개인 프로젝트나 대회 준비를 위한 프로젝트와 실제로 서비스하기 위한 프로젝트는 정말 차이가 크다고 느꼈다.
마지막으로
처음에는 회고록을 작성하려고 했는데 쓰다 보니 회고라기보다는 정리나 후기라고 말하는 게 맞는 성격의 글이 되어버려서 제목도 WhiteDay 프로젝트 후기로 해버렸다.
수고했다 👍