항해플러스 3~5주차 회고

1. 이전 글 

 

- 항해플러스 백엔드 7기를 시작하며...

- 항해 플러스 백엔드 1주차 회고 - TDD

- 항해 플러스 백엔드 2주차 회고 - Clean Architecture 

 

2. 진행 내용

3~5주차에서는 새로운 기술, 성능 보다는 최대한 간단한 기술만을 이용하여 아래의 가치를 중점적으로 서버 애플리케이션을 개발 완료하는 것을 목표로 하였다.

• 기능의 동작: 성능보다는 주어진 요구사항에 맞게 기능이 올바르게 작동하도록 집중.
• 테스트 코드의 견고함: 유지보수성과 안정성을 고려한 테스트 코드 작성.
• 아키텍처 설계: 클린 아키텍처와 모듈화를 중점적으로 학습 및 적용.

 

• 3주차:
  • 프로젝트 초기 설계 진행
  • 마일스톤, 시퀀스 다이어그램, ERD 작성을 통해 요구사항을 명확히 정의.
• 4주차:
  • 요구사항에 맞게 설계대로 서버 애플리케이션 개발
• 5주차:
  • 필터와 인터셉터를 활용한 요청 처리 로직 추가

 

3. 고민했던 내용들

서버 스케일아웃 시 스케줄러의 동시성 문제

현재 서버 내부에 대기열 토큰 만료, 상태변경, 예약 만료 등의 기능들이 스프링 스케줄러로 구현되어 있는데 만일 서버를 스케일 아웃했을 경우 이 스케줄러끼리 동시성에 대한 문제가 생길 수 있겠다고 판단했다.

멘토링 시간에 해당 내용에 대하여 질문을 하여 멘토님이 실무에서 사용할 수 있을만한 여러 기법들에 대하여 답변을 해주셨지만, 과제에서는 최대한 간단하게 구현하기 위하여 로직 자체를 동시에 여러개의 스케줄러가 수행되어도 문제가 없도록 멱등하게 로직을 작성했다.

 

 

로깅 필터에서 MultipartRequest 또한 로깅을 해줘야 할까?

필터로 Request, Response에 대한 로깅 처리를 해주었고 로그에 요청 바디 데이터 또한 남도록 했다. 그러나 Multipart로 들어온 요청의 바디 값 또한 로그에 남겨야 할지 고민이 되었다.

결론적으로는 Multipart일 경우 로그로 남겨봤자 큰 의미가 없을 것 같다고 판단했고, Content-Type이 application/json으로 들어오지 않았다면 바디 값을 로그에 남기지 않도록 했다. 

 

 

4. 마무리

구체적으로 구현을 하면서 초기 설계단계에서 계획했던 것들이 많이 변경되었다. 대충 요구사항을 분석하고 키보드부터 두드리는 것에 익숙해져 과제를 하며 설계를 심도있게 하는 훈련이 잘 되어있지 않다는 게 느껴졌다.

또한 3주차의 경우 문서화 자체가 과제 사항이였는데, 문서화를 하는 작업 또한 익숙하지 않아서 시간이 많이 소요되었었다. 앞으로 연차가 쌓일 수록 코드를 짜는 시간보다 문서 작성을 하는 시간이 많아질 텐데 하드스킬에 대한 공부 이외에도 다이어그램 툴을 다루는 법이나, 문서 작성을 하는 스킬 또한 중요하게 관심을 갖고 훈련을 해야할 것 같다.

 

현재 개발한 서버 애플리케이션은 이후 남은 챕터들에서는 고도화 작업을 하게 될 것 같다. 현재까지는 익숙해서 구현하는 데 큰 어려움이 있었지만 앞으로의 과정들은 많이 경험해보지 못한 것들이라 새롭고 재미있을 것 같다.

남는 시간에 평소에 많이 써보지 못한 기술인 레디스나 카프카에 대하여 공부를 열심히 해야할 것 같다.