https://github.com/kanggeonnim/PerspectiView?tab=readme-ov-file
이전까지 개인 토이프로젝트, 2인 프로젝트는 경험해봤지만 6인 팀프로젝트와 팀장은 특히 더 무거웠습니다..
자세한 기획과 기능 데모는 깃허브를 통해 확인하실 수 있습니다.
프로젝트에서 제가 맡았던 부분 위주로 회고 시작하겠습니다.
저는 평소에 웹툰, 웹소설을 즐겨보는 독자지만 작품 설정 관리가 안되는 작품들은 재미가 없어 손이 잘 안가게 되고, 이런 부분에서 작가분들에게 시각적으로 작품설정을 관리하는 서비스가 있으면 도움이 될 것 같다고 생각해 프로젝트 기획 및 구현을 진행했습니다.
사전 인터뷰
기획은 했지만 실제 웹툰, 웹소설 스토리 작가분들에게 도움이 될만한 서비스인지 네이버 웹툰 작가분과 대면 인터뷰, 레진 코믹스와 카카오페이지의 작가 분과 이메일 인터뷰를 진행했습니다.
기존에 스토리를 작성하며 독자가 있는 서비스를 생각했지만 작가분들과 인터뷰를 통해 아이디어를 남에게 노출하는 것을 꺼리고 차라리 작가 팀과의 협업이 가능한 팀 단위 서비스의 방향성 피드백과 부가적으로 있으면 좋을 기능들의 디테일한 피드백을 통해 기획을 마무리 했습니다.
쉬는 주말에 혼자 대전에서 포항까지 인터뷰를 하느라 힘들었지만 피드백을 통해 더 나은 방향성과 디테일들을 챙길 수 있어 보람을 느꼈습니다.
6명이 1팀?
사공이 많으면 배가 산으로 간다.
진짜였습니다. 매일 9시와 5시 30분에 스크럼을 진행했지만 모든 팀원이 한 방향을 향해 달려가는지 체크하는 것이 생각보다 힘이 들었습니다. 팀장으로서 임무 분배를 한 것이 잘 진행되고 있는지, 오늘이나 이번주에 완료될 진행상황들을 잘 보고해주는 팀원이 고맙고, 한주 한주 지나갈 수록 모든 팀원과 소통이 잘되어 초반보다 원활한 임무분할을 할 수 있었습니다.
JIRA
JIRA를 통해 1주 단위 스프린트를 위한 에픽(목표)과 에픽 달성을 위한 세분화된 스토리 포인트 분배 및 스토리 관리 덕에 성공적으로 프로젝트를 완료할 수 있었습니다.
팀마다 지라를 관리하는 방법이 다르지만 저희 팀 내에서 목표 설정과 일정 관리는 성공적이였으니 앞으로 새롭게 만난 팀에서 지라 관리 파악과 사용에서 조금 더 빠르게 적응 할 수 있을 거라는 자신감을 얻을 수 있었습니다.
자동배포
젠킨스
1. 파이프라인에 다양한 빌드전, 빌드후 라이브러리를 제공
2. docker mount를 통해 쉬운 이식 기반의 확장성 제공
3. 백엔드, 프론트엔드, db와 같은 도커 네트워크로 EC2 외부 포트 개방하지 않고 통신 가능
위와 같은 이유로 젠킨스를 사용했습니다.
프론트, 백 모두 제가 배포를 맡아 진행했고 아래와 같은 순서로 진행됩니다.
- 젠킨스 빌드
- 빌드한 파일 publish over SSH로 EC2로 전송
- EC2 내의 쉘 스크립트를 실행해 이전 이미지 제거 및 생성 후 실행
큰 도커 이미지(예: node나 nginx를 포함한 것)를 젠킨스에서 EC2로 전송하는 것을 최소화하기 위해 빌드 파일을 전송하고 배포하는 환경에서 이미지화를 진행했습니다.
Application 설정파일, JASYPT 암호화
백엔드는 application 설정파일은 로컬, 운영, db분리 등으로 나눠 jar 파일을 실행했습니다.
모든 설정파일은 jasypt를 통해 암호화 한 후 git에 올려 배포환경에서 환경주입 시 jasypt 암호만 주입할 수 있었습니다.
테스트 코드
백엔드는 테스트 코드를 지속적으로 작성해 새로운 서비스가 추가되거나 기존 서비스가 변경될 경우 테스트를 통해 문제를 확인해가며 자동배포를 진행했습니다.
CORS
백엔드 개발도 했지만 인프라의 모든 부분을 혼자맡으면서 가장 머리털 빠지는 이슈였습니다. 배포환경의 백과 프론트 연결을 처음하는데 nginx를 활용해 백과 프론트의 주소를 외부로 노출하지 않고 리버스 프록시를 적용하면서 더욱 복잡했습니다.
1. 리버스 프록시 적용할 때 Origin 추가하기
2. 스프링 시큐리티 Origin 허용 추가하기
스프링 시큐리티 설정 파일 내 CorsConfiguration 빈 등록시에 프론트의 Origin을 추가해줍니다.
3. 스프링 시큐리티 PreFlight 허용 추가하기
이전 문제를 다 해결해도 브라우저를 통해 요청을 할 때 GET 요청만 가능하고 나머지 요청은 다 막혔습니다. OPTION http method를 활용해 해당 요청을 처리가능한지 확인하는 로직을 실행되어 해당 프로젝트 내의 모든 OPTION 요청을 허용해줘야 preFilght를 무사히 마치고 본 요청을 처리할 수 있습니다.
4. 프론트 Credentials 설정
쿠키를 사용한다면 프론트에서 추가로 해줘야할 설정입니다.
// 1. axios 전역 설정
axios.defaults.withCredentials = true; // withCredentials 전역 설정
후기
전반적인 백엔드 개발과 인프라 구축, 팀장의 역할을 맡으면서 진행한 팀 프로젝트는
팀장으로서
생각보다 팀장역할이 힘들었지만 일정관리 부분에서 팀원의 역량을 파악하고 업무 분배하는법과 지속적으로 팀원들의 진행도를 파악하고 더딘 부분에 도움을 주고 받는 것의 중요성을 알 수 있었습니다.
백엔드 엔지니어로서
통합 컨트롤러 테스트 or 포스트맨을 통한 테스트의 중요성과 환경마다 설정파일을 분리하는 법, 자신이 수정하는 부분에서 파생되어 팀원들의 로직에 변동이 있을 때 사전 협의 및 변화를 잘 알리는 것의 중요성을 배웠습니다.
인프라 엔지니어로서
배포환경의 백과 프론트 연결, TLS 인증서 발급을 통한 HTTPS 적용, S3 정적 웹 호스팅 HTTPS 적용 , CORS 문제해결, 보다 가벼운 배포 파일의 중요성과 개발자가 편한 자동배포까지는 진행해봤지만, 사용자가 편한 무중단 배포까지는 적용해보지 못해 해당 부분 공부중에 있습니다.
약 4주간 정말 열심히 진행했고 천천히 백엔드 리팩토링과 인프라 변경을 거칠 예정입니다.
읽어주셔서 감사합니다.