최종 산출물
제출 기한이 연장되어 보강 작업을 진행했다. 각자 작성한 자료를 취합한 발표 PPT를 제작했다.
발표 PPT 목차
- 프로젝트 인원 (+ 담당 기능)
- 서비스 소개
- 서비스 주요 기능
- 프로젝트 사용 기술
- 인프라 설계
- 데이터베이스 설계
- 프로젝트 이슈 - 구현 기능
- 프로젝트 이슈 - 어려웠던 점
- 프로젝트 이슈 - 협업
- 마치며 (+ 한줄 소감)
참고 자료
아쉬운 점
- 시간 부족: 작업 시간이 촉박해 최소한의 제출을 목표로 서둘러 작업했다. 완성도에 전혀 신경 쓰지 못한 점이 아쉬웠다.
- 코드적인 강조 부족: 발표 준비 시 코드와 기술적인 부분(API 명세서, ERD 등)을 충분히 다루지 못했다. 다른 팀의 발표를 보고 이것이 더 강조되었어야 했음을 느꼈다.
- 기술 어필 부재: 기술적으로 돋보일 수 있는 성능 테스트나 최적화 작업을 포함하지 못했다. 다른 팀의 발표에서 이런 부분이 두드러졌던 점이 아쉬웠다.
- 발표 내용의 다양성 부족: 발표가 다소 형식적으로 느껴질 수 있었던 구성으로, 팀의 기술적 강점이나 프로젝트의 차별성을 부각시키지 못했다.
발표 피드백
우리 팀 피드백
- 익숙한 Maven을 사용하신 것도 좋지만, Gradle을 사용해보는것도 추천합니다.
- 카카오 주소 API 연동 시 인프라 설계에서 누락된 부분을 점검할 필요가 있습니다.
- 도메인 설계는 프로젝트 크기나 개발자마다 다를 수 있지만, 다양한 기준이 있습니다. 유즈 케이스를 기준으로 설계하면 팀원 간 협업으로 인해 작업이 막히는 부분은 없을 것입니다.
- 비즈니스 영역을 기준으로 설계
- 유즈 케이스를 기준으로 설계
- 화면을 기준으로 설계
- 다른 방법으로도 구현할 수 있다는 열린 사고가 필요합니다.
다른 팀 피드백
- 삭제 작업보다는 데이터베이스 파티셔닝 방식을 고려하는 것이 효율적입니다.
- JPA로 생성된 ERD는 순서가 뒤죽박죽일 수 있으니 명확한 설계를 반영된 ERD를 작성하는 것이 좋습니다.
- 쿼리 스트링을 활용하여 엔드포인트를 줄이고 명확하게 만들 필요가 있습니다.
- 화면이 붙어있는 서비스는 세션 방식 인증이 적합하지만, 프론트와 백엔드가 완전히 분리된 경우에는 JWT를 사용하는 것이 더 유리합니다.
- 예기치 못한 상황을 많이 경험하며 다양한 대응 방법을 학습하셨으면 좋겠습니다.
- 고객 지원(CS)에서 로그 시스템을 우선 확인하므로, 로그 메시지가 직관적이고 명확해야 합니다.
- 통합 테스트는 데이터 반영을 검증하며, Mock 기반이나 상태 기반 테스트 전략을 적절히 활용해야 합니다.
- 자신이 작성한 코드에 대해 “왜 이렇게 했을까?”라는 궁금증을 가지는 태도가 개발 역량 향상에 도움이 됩니다.
- 개인정보 소프트 삭제 처리 이후의 작업에도 주의를 기울여야 합니다.
- Spring 6과 Boot 3는 기존 Security와 차이가 있으므로 자료를 찾는데 어려움이 있습니다.
AllBy를 사용하면 전체 데이터를 메모리에 올리게 되므로, JPA 그대로 활용할지 QueryDSL을 사용할지 신중히 선택해야 합니다.- RestTemplate 대신 RestClient를 사용하는 것이 최신 트렌드에 맞습니다. 참고 자료
- 컨벤션 정립에 시간을 투자하는 것이 장기적으로 프로젝트 품질 향상에 큰 도움이 됩니다.
- 납기가 가까워질수록 품질이 저하되는 것을 방지하려면, 지키기 쉬운 방식으로 규칙을 설정하는 것이 중요합니다.
- Stream은 외부 데이터 통합에는 적합하지 않으며, 내부 데이터 수정에만 사용하는 것이 바람직합니다.