인프런 커뮤니티 질문&답변
작성한 질문수
로그인 비즈니스 로직을 원 쿼리로 하지 않는 이유
해결된 질문
작성
·
615
·
수정됨
3
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예
3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예
[질문 내용]
안녕하세요.
스프링 MVC 2편 - 섹션6. 로그인 처리1 중 로그인 기능 강의를 수강하다가 구현 방법에 대해 궁금한 점이 생겨 질문 드립니다.
강의 3:49초 부분에서 로그인 핵심 비즈니스 로직을 2단계의 과정으로 나누고 이를 코드로 작성하는 것을 학습했습니다.
입력 받은 loginId와 일치하는 회원 정보가 있는 지 DB에서 조회한다
loginId로 DB에서 조회한 회원 정보의 password와 입력 받은 password를 비교하여, 일치하는 회원 정보를 찾는다
public Member login(String loginId, String password) {
return memberRepository.findByLoginId(loginId)
.filter(m -> m.getPassword().equals(password))
.orElse(null);
}강의의 로직은 잘 이해하였지만,
일종의 원 쿼리라고 부르는 방식으로, 한 번에 해결할 수 있을텐데, 왜 2단계로 나누어 해결하는 지 이유가 궁금합니다.
강의에서는 메모리를 DB로 사용했지만 일반적인 DB를 사용한다고 가정했을 때,
제가 생각한 방법은
MemberRepository에
public Optional findByLoginIdAndPassword(String loginId, String password)메서드를 정의하고loginId와 password가 모두 일치하는 (AND 조건) 회원 정보가 있으면, 그 회원 정보(Member)를 반환
일치하는 회원 정보가 없으면 null 반환
LoginService에서 리포지토리의
findByLoginIdAndPassword를 호출하기만 하면 되지않을까 생각했습니다.
public Member login(String loginId, String password){
return memberRepository.findByLoginIdAndPassword(loginId, password);
}이렇게 생각한 이유는
입력한 정보와 일치하는 데이터가 DB에 있는 지 확인하기 위해 어차피 DB에 접근이 필요한 상황이고,
그렇다면 자바에서 루프를 돌면서 비교하는 것보다 DB에서 WHERE 절을 통해 조건을 비교하는 것이 빠르지 않을까 싶어서 입니다.
정답이 있는 건 아니겠지만, 영한님께서 로직을 2단계로 나누어 작성하신 데에는 이유가 있을 것이라 생각해서, 그 이유가 궁금합니다.
저는 SI에서 근무를 했었는데, 비즈니스 로직을 모두 쿼리에 녹여내고, 대부분을 원 쿼리로 해결하는 방식의 개발 방법을 익혔었습니다.
영한님 강의를 들으면서 이게 좋지 않은 방법이란 것을 알게 되었고, 보다 객체지향적으로 설계하고 개발할 수 있도록 노력하고 있습니다.
그래서 로그인 로직에서도 원 쿼리보다는, 강의에서와 같이 2단계로 작성하는 것이 더 좋은 방법인 건지 궁금합니다.
긴 질문 읽어주셔서 감사합니다. ^^
답변 2
4
안녕하세요. catveloper365님
이 부분에 특별한 이유가 있어서 이렇게 작성한 것은 아닙니다 :)
단순한 예제여서 최대한 쉽게 설명하기 위해서 이렇게 코드를 작성해두었습니다.
제가 작성한 것 처럼 회원ID로 회원을 찾은 다음에 비밀번호를 검색해도 되고, 또는 작성하신 것 처럼 조건을 최적화해서 조회해도 됩니다.
다만 여기에는 성능과 코드 재사용이라는 점에서 트레이드 오프가 있습니다.
제가 작성한 것 처럼 하면 별도의 리포지토리 메서드를 만들지 않고 기존 리포지토리 코드를 재사용할 수 있습니다. 그리고 비밀번호를 검사하는 로직을 서비스 계층으로 올릴 수 있습니다. 이렇게 하면 비밀번호를 검사하는 것 자체가 서비스 로직으로 올라오게 되면서 리포지토리에 의존하지 않게 되는 것이지요. 예를 들어서 리포지토리가 DB가 아닌 다른 기술로 변경하게 되더라도 비밀번호 검사 로직을 그대로 유지할 수 있습니다.
이 방법은 생각하신 것 처럼 성능에서 트레이드 오프가 있습니다.
성능 최적화 관점에서 보면 하나의 쿼리로 처리하는 것이 더 나은 선택입니다.
다만 성능 최적화를 하려면 그곳에 맞는 리포지토리 전용 기능이 보통 필요하게 되고, 리포지토리가 점점 더 많은 비즈니스 로직을 가져가게 됩니다. 이것을 애플리케이션 유지보수를 조금 더 어렵게 만들 수 있습니다.
하지만 실무에서 개발을 하려면 유지보수를 위한 코드의 재사용과 성능 관점에서 최적화라는 두가지 균형을 잘 이루는 것이 중요합니다.
예를 들어서 성능이 중요한 사용자가 많은 서비스 대상이라면 로그인 부분에 성능 최적화가 필수입니다. 물론 여기서 최적화가 꼭 DB만 사용한다는 뜻은 아니고 캐시 등도 고려할 수 있습니다. 만약 일부 사용자만 사용하는 어드민 이라면 로그인 부분에 성능 최적화 보다는 코드 유지보수를 더 잘 하는 방법이 더 좋은 방법이라 생각합니다.
좋은 개발자는 결국 본인의 환경에 맞는 적절한 트레이드 오프 판단을 할 수 있는 개발자이겠지요.
도움이 되셨길 바래요 :)
0
안녕하세요, 인프런 AI 인턴이에요.
로그인 비즈니스 로직을 원 쿼리로 하지 않는 이유에 대해서 설명해 드릴게요. 일반적으로 로그인은 사용자가 입력한 아이디와 비밀번호를 이용해서 데이터베이스에서 회원 정보를 조회하고, 일치하는 회원 정보를 찾아야 합니다. 원 쿼리 방식으로 한 번에 해결하는 것은 가능하지만, 여러 가지 이유로 인해 2단계로 나누어 해결하는 것이 더 효율적입니다.
첫 번째로, 입력 받은 loginId와 일치하는 회원 정보를 DB에서 조회하는 단계입니다. 이 단계에서는 사용자가 입력한 정보와 DB에 저장된 정보를 비교하여 일치하는 회원 정보를 찾습니다. 만약 비밀번호가 틀리거나 일치하는 회원 정보가 없다면 추가적인 비교 작업 없이 바로 null을 반환하면 됩니다. 이렇게 첫 번째 단계에서 일치하는 회원 정보를 찾지 못하면 불필요한 비교 작업을 줄일 수 있습니다.
두 번째로, 첫 번째 단계에서 일치하는 회원 정보를 찾았다면 입력 받은 password와 회원 정보의 password를 비교하여 일치하는지 확인하는 단계입니다. 이 단계에서는 비밀번호를 일치 여부를 확인하여 로그인 결과를 반환할 수 있습니다. 일치하지 않는 경우 null을 반환하거나, 일치하는 경우 해당 회원 정보를 반환하면 됩니다.
이렇게 2단계로 나누어서 로그인 비즈니스 로직을 처리하는 이유는, 첫 번째 단계에서 불필요한 비교 작업을 최소화하고, 두 번째 단계에서는 실제로 비밀번호 일치 여부를 확인하여 로그인을 처리하기 때문입니다.
이런 구조로 로그인 비즈니스 로직을 설계하면, 입력된 데이터가 많을 경우 비교 작업을 최소화하여 성능상의 이점을 가질 수 있습니다.
원 쿼리 방식으로 한 번에 처리하는 것도 가능하지만, 위에 설명한 이유로 인해 2단계로 나누어서 처리하는 것이 일반적으로 더 효율적이에요.
추가적인 질문이 있으시면 언제든지 물어보세요. 좋은 하루 되세요!
답변 너무 감사합니다 😭
코드의 재사용 관점은 전혀 생각하지 못했던 부분이어서 답변을 통해 많은 깨달음을 얻었습니다.
오로지 한 가지 방법만 알고 있었는데, 이런 방법도 있구나 하고 훨씬 시야가 넓어진 느낌이에요.
답변 내용을 항상 떠올리면서, 적절한 선택을 할 수 있는 개발자가 되도록 노력하겠습니다.
감사합니다