이번주 학습 내용

DTO 사용하는 이유

JPA를 이용해서 Entity를 조회 후 바로 클라이언트에 전달하는 것은 좋지 않다.

왜 좋지 않을까?

1. 클라이언트에 불필요한 정보 포함

   1. Entity에는 테이블의 정보를 모두 가지고 있기 때문에 클라이언트 화면에 필요한 정보보다 더 많은 정보를 넘겨주게 되면 클라이언트에서도 해당 화면에 필요한 정보가 명확하게 무엇인지 어려워 유지보수 및 트래픽 부분에서도 이슈가 있을 수 있다.

2. 보안성

   1. Entity에 있는 정보를 모두 클라이언트에게 전달하게 되면, 노출되면 안되는 개인정보가 네트워크 트래픽상에 노출될 수 있어 보안 부분에서 이슈가 발생할 수 있다.

3. Open-Session-In-View (OSIV) 문제

   1. 스프링 JPA에서 영속성 컨텍스트에서 Entity 조회시 Controller까지 해당 Entity를 전달하게 되면 해당 영속성 컨텍스트의 트랜잭션이 종료되지 않기 때문에 개발자가 의도하지 않은 데이터의 변경이 발생할 수 있음. 그러면 비즈니스에 크리티컬한 부분이 되기에 open-session-iv-view 옵션을 false로 설정하고 서비스 단에서 DTO로 변환하여 전달하는 것이 좋다.

레포지토리 성능 개선

1. 스프링 JPA를 이용한 조회의 문제점 (N+1)

   1. 단일 테이블 조회시에는 이슈가 없으나 연관된 Entity를 조회시에는 의도하지 않게 N+1의 쿼리를 실행하게 되는데, 데이터 개수가 적을때는 이슈가 없을 수 있으나 개수가 많아질 수록 N의 값이 커지기 때문에 성능 이슈가 발생할 수 있다.

       

2. 어떻게 해결할 수 있을까?

   1. JPQL의 fetch join 사용

       

   2. @Batchsize(size) 어노테이션 활용

      1. Lazy 로딩시 IN절로 조회되는 데이터의 사이즈를 지정할 수 있다.

테스트 코드

실무에서 테스트코드는 매우 중요하다.

내가 변경한 곳은 1개의 라인일지라도 해당 라인의 영향도는 알 수 없기 때문이다. ( 프로젝트 규모에 따라 다르지만 ㅎㅎ )

기존의 비즈니스 로직도 동일하게 동작하면서 내가 변경한 기능도 정확하게 동작하는지 확인하기 위해서는 배포하고 직접 화면을 확인하는 방법도 있지만 테스트 코드를 작성하면 코드 레벨에서 기능을 체크할 수 있다.

1. 테스트 코드 작성방법

   1. given - when - then

2. 테스트 코드 관련 어노테이션

   1. @DataJpaTest : 레포지토리 테스트

   2. Mockito 사용 : 단위 테스트에 사용

   3. @SpringbootTest 사용

      1. SpringbootTest는 스프링 컨테이너가 실행되어서 동작되므로 많은 테스트 코드 진행시 Mockito보다 속도가 느릴 수 있다.

이번주 미션 진행

[미션3] API 설계하기

이번 미션은 API 설계였는데 Restful하게 설계하려니 고민되는 부분이 있었고, 무엇보다 문서 작성이 힘들었다.

Github에서 관리하면 이력관리가 될 것 같아서 Github wiki에 정리하였는데 마크다운으로 작성하려니 직관적이지 않고, 반복되는 패턴들인데도 복사/붙여넣기 하는 과정이 있어 불필요하게 작성되는 느낌을 받았다.

추후에는 Spring docs로 코드레벨에서 API 명세를 관리할 수 있게 개선 해야할 것 같다.

회고

멘토님께서 이번주 중간 점검 미팅때 QnA를 진솔하게 해주셔서 감사했다.

JPA의 성능이슈에 대해서 고민하다가 이렇게 JPQL을 써야한다면 JPA만으로는 실무의 모든 쿼리를 대체할 수는 없을 것 같다. Mybatis + JPA의 구조를 택하는 이유도 네이티브 쿼리의 니즈가 있어서 아닐까 싶다.

요즘 회사에서 MSA 프로젝트 유지보수를 맡게되어서 코드 분석을 빡세게 하고 있고, 퇴근 후에는 운동, 플러터 스터디도 같이 진행하고 있어서 주변에서 일정을 들으면 놀라긴 하는데, 새로운 것을 배우는 재미가 있어서 그런지 아직까지는 버티면서 할만 한 것 같다.