자신의 정보만 업데이트 하는 로직 궁금한 점

토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1

해결된 질문

작성

38강 10분 13초에서 자신의 정보를 업데이트 하는 로직 만드는 부분에서 궁금한 점이 생겼습니다.

로그인된 사용자만 자기 정보를 업데이트 할 수 있는 기능을 웹 API 쪽의 어댑터에서 만든다고 하셨는데 왜 그런걸까요? 애플리케이션에서 검증을 하면 안되는걸까요?

java spring spring-boot jpa 리팩터링 ddd

답변 2

토비

지식공유자

좋은 질문을 해주셨네요.

회원은 자신의 정보만 업데이트 할 수 있다는 로직을 적용하는 방법은 크게 두 가지가 있을 것 같습니다.

하나는 제가 이번 강의에서 선택한 방법으로 헥사고날 애플리케이션 로직에선 업데이트를 할 수 있는 권한에 대한 로직을 넣지 않고, 이미 권한에 대한 체크가 완료된 상태에서 호출이 되면 업데이트를 수행하는 방식입니다. 이 경우 회원은 자신의 정보만 수정할 수 있다는 로직은 웹 어댑터 계층에서 먼저 검증을 마친 뒤에 이 기능을 사용하게 됩니다.

다른 방법은 현재 로그인한 회원 정보를 회원 정보 업데이트 인터페이스의 메소드에 추가하는 방법입니다. 이때는 애플리케이션 서비스 계층에서 먼저 로그인한 사용자가 이 정부를 수정할 권한이 있는지, 즉 자기 자신인지를 확인하는 권한 체크 로직이 나오게 되겠죠.

저는 이 두 가지가 다 가능한 방법이라고 생각합니다. 보통 후자의 방법을 많이 쓰긴했는데 이번엔 전자로 설계하면 어떨까 생각을 했습니다. 이유는 다음과 같습니다.

어떤 회원의 정보를 수정하는 것은 꼭 해당 회원 본인이 아닐 수 있습니다. 예를 들어 운영자가 회원의 요청을 받아서 어드민 기능을 통해서 회원 정보를 수정할 수 있습니다. 다른 이슈 때문에 강제로 수정을 해야할 경우도 있습니다. 이런 경우에는 회원 정보 업데이트 서비스 로직에서 업데이트가 가능한지 여부를 따지는 로직이 2가지(회원 자신인가 운영자인가)가 나와야 하죠. 그 중에서 운영자인 경우엔 또 회원 정보 수정에 대한 권한을 가졌는지도 체크가 필요할 겁니다. 또 운영자의 로그인 정보가 회원의 일종일 수도 있지만, 아닐 수도 있습니다. 이 경우 다른 종류의 로그인 정보로부터 현재 이 기능을 사용하는 사용자가 누구인지를 체크하는 로직도 회원 정보 업데이트 코드에 삽입되어야 합니다. 점점 복잡해질 수 있죠.

또 여러가지 이유로 마이그레이션을 한다거나 대량 업데이트가 필요해서 배치작업을 수행하는 경우에도 회원 정보 업데이트 기능을 호출할 수 있습니다. 이런 경우엔 파라미터로 전달 되는 로그인 유저는 null로 처리해야 할지, 배치 role을 가진 가상의 유저로 만들어야 할지도 고민을 하게 됩니다.

이런 이유로 어느 웹 계층 또는 다른 이벤트 리스너, 배치 프로그램이든 상관없이 거기서 해당 API에 대한 기능 사용 권한을 가졌는지를 먼저 검증하고, 그리고 이를 다 통과한 경우에 특정 회원의 정보를 수정하는 애플리케이션 서비스의 기능을 이용하게 하면 어떨까 생각을 해봤습니다.

물론 이 방식에는 단점도 있습니다. 자칫 권한 확인을 제대로 하지 않고 기능을 사용한다면 이를 보호해줄 방법이 없죠. 또, 누가 정보를 수정했는지에 대한 감사(audit) 정보를 남기는 부분은 어떻게 해야할지도 정책이 필요할 것이고요.

어떤 방법이든 장단점이 있고, 신경 쓸 부분이 있긴한데, 일단은 권한 체크를 마친 뒤에 특정 회원의 정보를 수정하는 기능을 호출하는 방법을 선택해봤습니다. 물론 이후 강의에서 개발을 진행하다가, 말씀하신 대로 애플리케이션 내부에서 검증하는 게 더 낫겠다는 판단이 들면 리팩터링 해야죠.

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 3831568님.

로그인된 사용자가 자신의 정보를 업데이트할 수 있는 기능을 웹 API 쪽에서 검증하는 이유에 대해 궁금하신 것 같습니다.

웹 API 계층에서의 검증 이유

보안 책임: 로그인된 사용자에 대한 검증은 주로 요청의 진위(Authorization)를 검증하는 것으로, 이는 보안과 관련된 기능입니다. 이러한 검증은 API 계층에서 처리하는 것이 일반적입니다. 웹 API 계층에서는 클라이언트로부터 들어오는 요청이 유효한지를 검증한 후, 비즈니스 로직을 수행할 수 있는지 판단합니다.
서버 부하 감소: 어플리케이션 내부의 작업까지 데이터가 넘어오지 않도록 API 계층에서 사전 차단을 통해 불필요한 처리를 방지할 수 있습니다. 즉, 애플리케이션 로직까지 요청이 전달되기 전에 인증 및 권한을 검증함으로써, 서버의 부하를 줄이는 효과가 있습니다.
단일 책임 원칙: API 계층은 요청을 받아들여 적절한 서비스 계층으로 전달할 수 있도록 하고, 서비스 계층은 실제 비즈니스 로직을 처리하도록 설계하는 것이 이상적입니다. 이에 따라, 인증과 권한 검사는 API 처리 단계에서 끝내는 것이 적합합니다.

유사한 논의

이와 관련된 추가적인 논의는 사용자 정보 업데이트와 API 계층의 역할에 대한 질문에서 확인하실 수 있습니다.

관련 강의에서 충분한 설명이 되었기를 바라며, 이러한 로직은 보안적 이유와 더불어 애플리케이션의 명확한 책임 분리를 위한 설계적 선택입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변