ArgumentResolve에서 ID 반환에 대해

[Choi-JJunho]

안녕하세요? 친애하는 코마 여러분
제가 첫 페어프로그래밍하면서 정말 생각없이 도입했던 ArgumentResolver에 대해 변경하고자하는 내용이 생겨 이렇게 말씀 올려봅니다.

정말 부끄럽지만 OSIV 설정 및 인증 방식에 관련하여 한가지 수정하는것을 제안드리고자 discussion 올려봅니다.

OSIV(Open Session In View) : 영속성 관리가 Controller Layer까지 전파되는 설정 default는 true

쉽게말해 OSIV는 Entity의 생명주기를 Controller Layer까지 관리하게 두는 설정으로 이 설정이 켜져있는 경우 Controller Layer의 로직이 수행될 때 까지 Database Connection을 물고있게 되는 문제점이 발생하게됩니다.

다시말해 최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때 까지 DB Connection을 물고있게 되는거죠.
이 설정은 불필요하게 DB Connection을 길게 물고있기 때문에 보통은 OSIV 설정을 끄는 편입니다. (default는 true)

이에 로직에 작성되어있는 내용 중 다음과 같은 부분이 신경쓰였습니다.

Service에서 받는 저 엔티티는 영속화와는 관계없이 신뢰할 수 없는 객체가 됩니다. ArgumentResolver로부터 조회되고 Service에 도착했지만 안에 무슨 무시무시한 값이 있을지 알 수 없습니다.

이에 ArgumentResolver에서 인증된 값을 반환할때 studentId (혹은 userId)와 같이 ID를 반환하고 service에서 Repository로 조합해서 사용하는 방식으로 수정하는 건에 대해 제안드려봅니다.

항상 감사합니다 😊

[songsunkook]

OSIV를 처음 학습한 제가 이해한 것이 맞는지 잘 모르겠어서 정리해보겠습니다. 🤯

1. OSIV(Open Session In View) 기능은 요청 단위로(≈서비스단을 넘어 컨트롤러, 뷰까지) 영속성 컨텍스트를 유지하여 트랜잭션 외부에서도 지연 로딩을 원활하게 할 수 있도록 합니다.
   1. 덕분에 지연로딩에 의해 아직 로딩되지 않았던 연관관계 객체에 대해 컨트롤러단에서도 DB를 통해 정보를 불러올 수 있습니다.
      -> 컨트롤러에서도 자유로운 객체 그래프 활용이 가능해집니다.
2. OSIV는 요청이 시작될 때부터 끝날 때까지 DB 커넥션을 물고있기 때문에 성능상 이슈가 큽니다.
   1. 이 점 때문에 호불호가 크게 갈리고, admin 페이지 등 비교적 요청이 적은 기능에 대해서만 사용하길 추천하고 있습니다.
3. 스프링 OSIV에서 컨트롤러단은 트랜잭션 외부에 위치하기 때문에 기본적으로 DB에 변경사항이 반영되지 않지만, 영속성 엔티티를 수정한 후 서비스단(트랜잭션 내부)을 호출 시 변경감지가 동작하여 DB에 컨트롤러에서의 변경사항이 반영됩니다.

말씀해주신 고민은 3번에 관한 내용으로 생각됩니다. 현재 코마 프로젝트는 스프링 기본 설정에 의해 OSIV 설정이 켜져있는 상태입니다. ArgumentResolver에서 Student를 검증한 상황이지만 그 과정에서 Student 객체는 영속화되었고(studentRepository.findById(userId) 호출), 서비스단이 전달받은 영속성 엔티티의 내용이 검증 과정(또는 컨트롤러 등)에서 변경되었다면 의도치 않게 DB에 변경사항이 반영됩니다.

여기까지가 제가 이해한 내용입니다. 틀린 부분이 있다면 지적해주시면 감사하겠습니다.
위 정보를 기반으로 제 의견을 말씀드리겠습니다.

1. 현재 ArgumentResolver를 사용하여 사용자를 검증하는 형태가 위험하다는 점에 동의합니다. 트랜잭션 외부의 변경사항이 DB에 반영될 수 있는 가능성이 있어서는 안된다고 생각합니다.
2. ArgumentResolver에서 검증을 마친 후 영속성 엔티티를 그대로 반환하는 것이 아니라 userId를 반환하고 service에서 다시 find하는 것은 ArgumentResolver와 Service 사이에서의 변경 위험을 없앨 수 있어 좋은 아이디어라고 생각합니다.
   1. 다만 완전히 안전하다고 보기는 힘들 것 같습니다. 제가 이해한 것이 맞다면 ArgumentResolver에서 변경되는 사항에 대해서는 영속성 컨텍스트에 저장되어 Service에서 새로 find하더라도 변경된 엔티티가 반환되고 DB에 저장될 것으로 보입니다.
3. 코마 프로젝트는 현재 엔티티와 별개인 DTO를 작성하여 반환하는 구조를 지니고 있습니다. 여기에 OSIV를 활성화시켜야 하는 메리트가 있는지 잘 모르겠습니다. 현재로써는 OSIV 기능을 끄는 것이 성능 상 이점과 보안 상 이점을 모두 잡을 수 있는 가장 좋은 방법이라고 생각합니다.

최종적으로 제 결론은 아래와 같습니다.

1. OSIV 기능을 off한다.
2. 위 방법이 힘들다면 제안해주신 바와 같이 ID를 반환하는 형태로 ArgumentResolver를 수정한다.

제 이해가 부족하여 글이 너무 길어진 것 같습니다. 긴 글 읽어주셔서 감사합니다! 😊

[Choi-JJunho]

학습하고 정리해주신 덕분에 제시한 내용에 대한 근거가 풍족해진것 같군요 👍
저는 Connection을 길게 물고있다. 라는 부분이 핵심되는 초점이였는데 제시해주신 다양한 근거들도 만족스럽습니다

ArgumentResolver에서 변경되는 사항에 대해서 걱정하시는 부분 또한 공감했으나 ArgumentResolver에서는 엔티티의 상태를 최대한 변경하지 않는 방향으로 코드를 작성하는게 맞다고 생각합니다~

결론까지 함께 정리해주셔서 감사합니다~!

[xhdtn8070]

OSIV를 끄는 것은 성능 이슈, 트랜잭션 관리 문제, 그리고 리소스 사용 최적화 측면에서 좋은 선택입니다.
특히, 대규모 애플리케이션에서는 이런 결정이 성능 향상에 큰 영향을 미칠 수 있습니다.

추가적으로 유저의 로그인 여부와 권한을 체크하는 로직을 서비스 로직과 분리하는 것은 좋은 접근 방식입니다.
기존 ArgumentResolver 또한 로직의 분리를 위해 작성되었고 좋은 방법인 것 같습니다.

다만 OSIV를 끄고 ID를 받아오는게 좋은 것 같습니다. 이유는 다음과 같습니다.
트랜잭션 관리의 명확성: OSIV를 끄면, 트랜잭션의 범위가 서비스 레이어 내로 명확하게 제한됩니다. 이로 인해 트랜잭션 관리가 더 명확해지고, 데이터 일관성을 보장하는 데 도움이 됩니다.
데이터 전달의 명확성: ArgumentResolver를 사용하여 유저 ID와 같은 필요한 정보만을 컨트롤러에 전달함으로써, 데이터의 전달이 명확해지고, 영속성 컨텍스트와 관련된 복잡성이 감소합니다.
서비스 레이어의 책임 강화: 유저의 실제 데이터는 서비스 레이어에서 필요에 따라 조회되므로, 이를 통해 서비스 레이어의 책임이 강화되고, 애플리케이션의 구조가 더욱 견고해집니다.

제 의견을 다음과 같습니다.
OSIV를 OFF한다.
ArgumentResolver가 ID를 반환한다.

[Choi-JJunho]

Tx 관리, 데이터 전달, 레이어 등 설계의 관점에서 생각해볼 수도 있겠군요!
풍족한 의견 감사합니다 😊
근거가 상당히 설득력 있다고 생각합니다 👍