[InIT] 개선점과 코드컨벤션

InIT 프로젝트를 시작한지 벌써 6개월이 지났다. MVP는 진작에 4월에 나온 상태이지만 기획 수정과 QA, 마케팅의 영역때문에 홍보는 아직 하지 않고 있었다. 이 기회에 백엔드를 개선해볼만한 점들을 모으고, 예전에 정한 컨벤션에 좀 더 클린한 코드를 만들기 위해 다른 팀원들에게 회의를 요청하였다.

회의 요약

1. 코드스타일
   1. Type 안정성 - Wapper Class 쓰면 null check 필수
   2. ResponseEntity 통일
   3. Docs의 편리성을 위해 @ApiOperation랑 @ApiTag 사용
   4. 변수의 네이밍 - 영문법 기준으로 맞추기
2. NoSQL 검색 기능과 서버 성능 개선을 위한 검토
   1. 유저 수가 3000명 이상 되면 검토 시작한다.
   2. 유저 수가 5000명 이상 되면 진짜 서버 분리한다.
3. Infra 설정
   1. Rolling version일 경우 프로덕트 환경을 위해 Version 안정성이 있는 Linux로 변경
   2. 서버 환경을 위한 도커라이징
   3. Dev와 Prod가 같은 환경인지 확인
4. 버저닝
   1. 지금 메인 기준 1.0.0
   2. 버그 픽스 또는 핫픽스, 중요하지 않은 코드 변경의 경우 마지막 숫자 상승
   3. PR올릴 때 버저닝 명시하고, 중요한 기능 올리는 경우에는 모두 확인(가운데 버전)
   4. 핫 픽스나 기능적인 부분이 아닌 코드 변경은 임의로 올리기(끝에 버전)
5. 정리
   1. 브랜치 각자 정리하기
   2. 도커관련 파일 정리하기 (v1.0.1)
   3. 서버 마이그레이션은 브랜치만 남겨놓고, 필요한 경우 재진행
6. 테스트 중요
   1. 기본적으로 Mock 객체를 쓰되, Stub, Spy도 사용
   2. 서비스 테스트같은 경우는 BDDMockito를 사용
   3. @ExtendWith(SpringExtention.class)쓰고, SAME_THREAD 설정은 삭제
   4. 컨트롤러 테스트는 @MvcTest로 만들기
7. 슬랙에서 프로젝트 로드맵 논의
   1. 프로젝트 모두 같이 회의해서 미리 로드맵이 나올 수 있도록 논의

회고

요약에서 몇 가지에 대해서 좀 더 써보려고 한다.

1-2
현재 코드를 보면 각 도메인 별로 코드가 다름을 한 눈에 볼 수 있다. 처음 컨벤션을 정하고 들어갔고, 그 컨벤션을 다 지키면서 작성하는데도 다르다. 그렇기 때문에 조금 더 코드 스타일의 정형화가 필요했다.

ResponseEntity 관련 어노테이션은 삭제하고 ResponseEntity 자체로 통일하기로 했다. 왜냐하면 @ResponseBody, @ResponseStatus(HttpStatus.OK) 해당 어노테이션을 쓰면 좀 더 편한 코드가 작성될 수 있지만, 하나의 컨트롤러에서 exception 처리로 HttpStatus를 보내지 않으면서 StatusCode가 다르게 전달해야 하는 경우도 있기 때문이다.

1-3
그리고 Swagger를 쓰면서 프론트 엔드에게 좀 더 편리한 Api Docs를 제공하기 위해 @ApiOperation랑 @ApiTag를 쓰기로 했다. 우리도 Swagger 쓰면서 더 헷갈리지 않기 때문에 좋은 선택인 것 같다.

2
NoSQL은 서로 조사해온 부분들이 있었지만, 살짝 공유하고 현재의 서버에는 적용할 필요가 있을까라는 생각을 했다. 우리의 서비스가 잘 되었으면 좋겠지만, 아직 MAU도 제대로 측정도 못 할 정도의 상태이기 때문이다. 홍보도 안 했고,,, 유저의 트래픽이 생긴다면 검토들어가고 더 생기면 개발들어갈 예정이다.

3-1
나는 이때까지 사이드 프로젝트를 하면서 Centos와 Ubuntu만 써왔었다. 그렇기 때문에 인프라쪽을 맡은 팀원이 Amazon Linux를 사용하는 것에 신기했고, 궁금해서 찾아보았다. 그런데 Rolling Version이라고 한다. 해당 버전은 계속해서 Version이 업데이트되는 것이기 때문에 이전 버전을 찾을 수 없다. 그냥 버전이 하나의 버전인 것이다.

도커라이징을 하면 개발환경을 같을 테지만, AMI 자체로 만들어서 마이그래이션을 진행한다고 했을 때, 도커까지 같은 환경에 올라갈까 라는 의문이 생긴다. 그렇기 때문에 인프라를 맡고 있는 팀원에게 변경 요청을 했고, Amazon Linux가 아닌 Amazon Linux2라서 한 번 더 확인 해봐야한다고 한다. 2가 붙어서 달라졌을지도 모르기 때문에 한 번 검토해보기로 했다. 하지만 한 가지 더 안좋은 점은 해당 환경이면 AWS에서 밖에 못 쓴다.. 이것도 고려해서 검토한다고 한다.

5-3
마이그래이션이 나온 이유는 현재 AWS에 한 명 밖에 접속할 수 없기 때문이다. 우리 사이드 프로젝트는 현재 비영리이다. 그렇기 때문에 팀원분의 회사에서 사이드 프로젝트 지원 AWS 크레딧이 나온다고 하여 해당 크레딧을 쓰고 있다. 그렇기 때문에 계정을 공유할 수 없는 문제가 생겼고, 한 명만 들어가고 있다. 그리고 인프라를 맡으신 분이 AWS 인프라에 대해서는 처음 경험하시는 것이라 프로젝트의 진행에 까지 영향을 끼쳤다. 그래서 여러 마이그래이션 환경을 조사했고, 비용과 가성비가 뛰어난 Vultr에 마이그래이션을 하려고 했다. 하지만 시간이 지날수록 인프라 환경설정이나 구성에 익숙해지시고 경험치가 늘어나는게 보여서 현재 인프라를 그대로 쓰기로 했다.

그래도 migration branch를 남겨놓는 이유는 migration branch에는 이미 CI/CD부터 설정 변경, 도커라이징(현재 서버는 도커라이징 되어있지 않다. 해놓고 싶은데, code deploy까지 들달아 놓으셔서 내가 CI/CD에 관여하기가 어렵다 ㅠㅠ)까지 모두 migration되어 있긴하다. 일단 진행하면서 프로젝트에 더 병목현상이 생긴다면 해당 브랜치 설정에 main을 머지해서 마이그래이션 해버리기로 같이 결정하였다.

6
MVP 개발을 하면서 테스트 코드 작성을 우선순위에서 배제했었고, 현재 테스트 커버리지는 12.5%이다. 6월까지 30%를 채우기로 했고, 계속해서 늘려갈 예정이다. 그리고 테스트코드에 대해서도 서로 알고 있는 테스트 방법들을 공유했고, BDDMockito와 Extension, Annotation을 적절히 사용하기로 하였다. @SpringBootTest은 단위 테스트의 커버리지가 많이 상승하면 도입해 볼 예정이다.

느낀 점

이렇게 한 번 만나서 개선점과 서로의 코드스타일 등 다양한 점에 대해서 논의하고 나니 조금 더 백엔드 개발 방향을 다시 한번 똑바로 잡은 느낌이었다.

슬랙과 노션 등을 통해서 정보를 공유하지만 그 부분의 한계도 자주 일어난다. 사이드 프로젝트이다 보니 일처럼 코어타임이 있는 것도 아니고 각자의 일정이 더 우선적이다. 그렇기 때문에 일과는 다른 방식이 필요하다. 요즘 언택트 회사들이 늘어나고 있는데, 그것은 코어타임도 있고, 일에 대한 자발적인 의무가 있어서 가능하다고 본다. 사이드 프로젝트는 그것을 강요하지도 않고, 사이드 프로젝트의 목적이 각 프로젝트원들끼리 다 다르다 보니 일처럼 할 수 없다. 이런 이유로 이런 모임을 자주는 아니더라도 한 번씩 모여서 서로 프로젝트에 관해 정보를 공유하는 일이 있었으면 좋을 것 같다.