원인

Hibernete에서는 @OneToOne 매핑 시 Lazy Loading을 적용하려면 몇 가지 제약사항이 따릅니다.
하지만 User 엔티티에 매핑되어 있는 UnGraduatedApplication, GraduatedApplication, GEDApplication은 각각 양방향 관계로 매핑되어 있어, 지연 로딩 방식을 적용해도 실제 쿼리 동작 시 지연 로딩이 아닌 즉시 로딩을 수행하게 됩니다.
이에 따라 단순 User 테이블 조회의 경우(예: 사용자 로그인) 불필요한 원서 정보까지 불러오게 되므로 1번이면 될 조회 쿼리를 4회씩 전송하게 되어 응답 지연 시간을 증가시켜 서비스의 쾌적한 이용이 어렵습니다.
이는 명백한 성능 이슈로, 런칭 전 까지 필히 수정되어야 할 사항이라고 사료되어 known-issue로 게시하게 되었습니다.

참고 링크

• How can I make a JPA OneToOne relation lazy

문제사항

액세스/리프레시 토큰 재발급 API에 만료된 리프레시 토큰으로 요청하면 401 혹은 403이 아닌 500 서버 에러를 반환합니다.

해결방법

입력된 리프레시 토큰이 만료되었을 경우 500이 아닌 403을 반환하도록 수정합니다.

Husky 코드에서 기존 이미지를 삭제하는 로직에 문제가 있습니다.
Main Frontend에서는 자동저장 기능을 수시로 유저 정보 수정 요청을 보내는데, 이 때 API에서는 body에 사진이 있을 경우 해당 사진을 삭제합니다. 하지만 이미지 변경사항이 없음에도 해당 이미지를 삭제하기 때문에 리사이징 된 이미지가 계속해서 삭제되는 문제가 발생했습니다.

문제사항

지원자가 지원자 사진을 새로 등록할 때, 기존 이미지를 삭제하는 로직이 누락되어 있습니다. 기존 이미지를 삭제하지 않는다면 이미지가 계속 쌓일 것이고, 이는 비용 증가로 이어져 재정 상 부담이 됩니다.

해결방법

• 지원자 이미지 등록 시 기존에 등록된 이미지를 삭제하는 로직을 추가합니다.

기존 isFilledStudentInfo 메서드는 null 체크만 했지만 빈 문자열 검증도 해야 한다.

문제사항

• 자기소개서 및 학업계획서에 개행이 가능하게끔 변경해 달라는 선생님의 요구가 있었습니다.
• 허나 입력 칸의 크기를 넘을 경우 PDF가 깨져 다음 페이지를 점유하는 문제가 발생합니다.

해결방법

1. PDF 출력 로직에서 개행 처리를 비활성화합니다.
2. 개행 시 글자 수를 추가해 칸을 넘으면 개행을 더 이상 진행하지 않습니다.

문제사항

• 이메일 검증을 위해 서버로 이메일을 전달할 때 현재 상태로는 이를 파라미터로 전달하고 있습니다.
• 이는 보안적 측면에서 문제가 발생할 가능성이 높다고 사료됩니다.

해결방법

• 이메일을 Body로 수신합니다.
  • 전송 정보의 SSL(TLS)를 이용한 암호화를 정상적으로 진행하기 위함

문제사항

토큰 재발급 API에서 헤더에 리프레시 토큰이 없는 경우 Internal Server Error 발생

해결방법

헤더에 리프레시 토큰이 없는 경우 400을 반환하도록 예외처리

코드 가독성 개선을 위해 만들었던 ApplicationAdapter 이지만 오히려 가독성을 떨어뜨리고 있습니다. 치명적인 이슈는 아니지만 코드 퀄리티 개선을 위해 ApplicationAdapter를 없애고 다른 방식을 사용해야 합니다.

문제사항

• 미리보기용/최종제출용 원서출력 기능이 매우 느립니다.

해결방법

• Docx4J & Apache FOP 대신 iText를 이용하도록 변경해야 합니다.
• 기존 docx -> Apache FO -> PDF 플로우 대신 native PDF를 직접 수정하는 등의 low-level 처리가 필요합니다.

문제사항

이메일 전송 요청을 연속으로 요청하면 그대로 AWS SES를 호출해 메일 큐가 비대해지는 문제가 있습니다. 이에 redis ttl을 활용하여 특정 이메일로 너무 많은 요청을 보낸 경우 TOO_MANY_REQUEST를 반환하는 로직을 추가해야 합니다.

해결방법

1. 앞서 말한 redis를 이용해 한꺼번에 너무 많은 요청을 보낼 경우 예외를 발생시키는 방법
2. Nginx에서 TOO_MANY_REQUEST를 반환하는 방법

3학년 1학기 점수가 없을 경우 최종제출 할 수 없도록 Validation을 강화해야 한다.

기존 get status API에서는 마이페이지에서 필요한 status 정보와 1차합격/최종합격에 이용되는 status 정보가 함께 제공되었다. 하지만 이렇게 될 경우 합격 발표일 이전에 마이페이지에서 개발자도구를 이용하여 합격 여부를 알 수 있다는 결함이 발견되었다. 따라서 마이페이지 상태 정보 API와 합격 여부 API로 분리해야 한다.

통합 테스트의 경우 SpringApplicationContext를 공유할 수 있도록 변경하고
단위 테스트의 경우 불필요하게 어플리케이션을 구동시키는 @SpringBootTest가 아닌 @WebMvcTest로 변경한다.

Csrf 공격을 방지해야 합니다.

문제사항

• 현재 학교 코드를 검색하는 API에서는 검색하고자 하는 중학교가 속한 지역의 관할교육청 정보를 선택해야 합니다.
• '경기도 광주' 지역 관할교육청과 '광주광역시' 지역 관할교육청의 정보를 구분할 명확한 방법이 없습니다.
• DB 스키마 구조 상으로는 관할교육청 구분을 같이 받아야 할 이유 및 근거가 전혀 없으며, 불필요한 추가 쿼리를 발생시켜 성능에 악영향을 끼칩니다.

해결방법

• 학교 코드 검색 API에서 지역 관할 교육청 구분을 수신하지 않도록 변경합니다.
  • 디자인 수정
  • 프론트엔드 팀(Poodle) 측에 전달
  • Husky 코드 수정