인프런 커뮤니티 질문&답변
비회원 개념 추가 시 개선 방향
작성
·
37
·
수정됨
1
요즘 쇼핑몰 커머스등은 비회원 주문이 있는 경우가 거의 대부분인 것 같은데 비회원 주문,결제의 개념이 추가된다면 어떻게 개선될 수 있을까요?
api가 복제되는 느낌으로 가야하는지.. 주문, 장바구니, 결제 등등 유저아이디 대신 게스트아이디로 조회하는 등과 같이 작은 부분만 바뀌고 나머지 로직은 동일 반복될 것 같습니다.
주문조회시에도 회원 비회원.. 서비스는하나를 쓰고 OrderFinder에서 함수로 나누는 방식도 생각납니다.
어떤 방식이 더 있을까요?
답변 2
0
안녕하세요 질문 감사드립니다!
비회원에 대한 방식은 적어주신 것 처럼 여러가지 방식이 있을 것 같습니다
그럼 방식은 여러가지고 뭐로 해도 될 것 같은데요!
제가 의견을 드리기전에 wheon06님은 어떤 방식으로 처리하실 것 같으신가요?
그리고 왜 그 방식/전략을 써야한다고 생각하실지 궁금합니다!
먼저 제 의견을 한가지만 드리면 비회원의 주문,결제 까지 요구사항이 있다면 저는 비회원은 개념이 아니라고 볼 것 같습니다!
고민해보시고 의견 답글로 남겨주시면 저도 제 의견을 말씀드리겠습니다!
먼저 적어주신 전략도 유효하다고 보긴합니다, 다만 실제로 강의 예제에 해당 방식으로 구현을 직접 해보시면 아쉬운 부분을 충분히 느끼실 수 있을 것 같습니다 😃
우선 해당 방식으로 구현하면 구현체 자체에 분기문이 거의 대부분 기능에 들어가야합니다
주문, 결제 등등 거의 다 모든 도구들에 분기가 들어가게 되는거죠
또한 엔티티 저장 시 사용자/비회원에 대한 식별자가 Long, String 으로 분리되게 됩니다
그러면 OrderEntity에 저장을 할때 상당히 애매하겠죠 (이건 수정 한번 해보시면 바로 느껴지실 겁니다 😃 )
Long,Long 으로 만들어도 ID가 겹치는 문제가 있습니다 (물론 범위를 떨어트릴 수 있지만, 언젠가 만나겠죠)
그렇다고.... OrderEntity 와 나머지들을 비회원 용으로 GuestOrderEntity,, 처럼 다 만든다? 이건 이제 전체 비즈니스에 대한 구현의 중심 축이 분할 되버리는 문제가 생기죠
그래서 저라면 몇가지 선택이 있지만 대략 아래 같은 느낌의 결정을 할 것 같습니다
1안. User의 Type 추가 후 특정 시점에 User를 생성하여 비회원도 유사 회원 처리
분기문 필요 없음
2안. 모든 엔티티의 사용자에 대한 키를 String 으로 한개만 만들고 유저에 대한 ID체계를 "U1", "U15522", "G1" 과 같이 키에 타입을 넣도록 설계 후 단일화 된 로직으로 처리하게 할 것 같습니다
어떤 전략이건 제가 생각하는 핵심은 비즈니스와 도구들의 구현 로직에 특정 횡단의 핵심 개념이 아닌 요구사항 때문에 코드의 반복, 산개 되는 분기문이 생기고, 로직의 중심이 깨지는 것을 막을 것 같습니다
비회원은 일반적으로 서비스 성장에서 핵심이 될 수 없다고 생각합니다
만약 핵심으로 보더라도 상당히 낮은 급수의 중요도를 갖을 것 같습니다
단순히 주문의 주체가 된다로 개념으로 다루기에는 너무 구현 관점의 개념 정의 방법이라고 보여서 다소 아쉽게 느껴집니다
결국 개념 객체로 다루고 그 안에서 중요한 급수로 보려면 단순히 구현을 넘어서 비즈니스 적으로 얼마나 우리 서비스의 중심이고 가치가 있는지를 판단하면 좋을 것 같습니다!
(반대로 비회원이 메인인 서비스라면 타당하겠죠ㅎㅎ)
별개로 비회원 주문 자체의 기능은 저는 주문 시점 전에 가입을 유도 시켜서 회원 전환율을 올려한다고 생각해서, 이 부분은 기획과 타협을 해야한다고 보고 비회원 주문이 필요한 근거가 필요할 것 같습니다 🤔
장기적으로 비회원 주문은 회원을 유치하고 서비스를 성장시키는데에 도움이 안된다고 생각하거든요 (특정 유형의 상품에 대한 커머스라서 비회원이 가능해야한다면 타당하다고 보긴합니다, ex] 19금, 민감상품 등등)
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. wheon06님.
비회원 주문 및 결제를 추가하려고 할 때는 기존 시스템에 유연하게 통합할 수 있는 방식으로 접근해야 합니다. 주요 포인트는 비회원과 회원의 주문 프로세스 간 관계를 잘 조정하는 것입니다. 다음은 몇 가지 개선 방향입니다:
비회원 시스템 설계 방향:
유사한 엔터티 사용:
- 주문, 결제, 장바구니 등에서 공통으로 사용 가능한 엔터티를 정의합니다. 기존의
UserId대신GuestId를 추가하여 비회원과 회원 간의 차이를 줄일 수 있습니다. 이러한 엔터티 재사용으로 코드 중복을 최소화할 수 있습니다.
- 주문, 결제, 장바구니 등에서 공통으로 사용 가능한 엔터티를 정의합니다. 기존의
공통 로직 관리:
- 회원과 비회원의 주문 흐름에서 공통적인 비즈니스 로직은 별도의 서비스나 유틸리티 클래스로 관리하여, 중복 코드를 피하고 유지보수성을 높입니다. 이는 API가 복제되는 문제를 해결하는데 도움을 줄 수 있습니다.
- 회원과 비회원의 주문 흐름에서 공통적인 비즈니스 로직은 별도의 서비스나 유틸리티 클래스로 관리하여, 중복 코드를 피하고 유지보수성을 높입니다. 이는 API가 복제되는 문제를 해결하는데 도움을 줄 수 있습니다.
역할 기반 접근:
- API 레벨에서 접근 권한을 조정하여, 일부 API는
GuestId로도 접근 가능하도록 설정합니다. 이를 통해 비회원과 회원의 요청을 처리하는 로직을 크게 다르지 않게 유지합니다.
- API 레벨에서 접근 권한을 조정하여, 일부 API는
유연한 데이터 구조:
- 데이터 저장 시 회원과 비회원의 주문 및 결제를 구분하기 위해 추가적인 속성(예:
isGuest)을 활용하거나, 비회원 전용 테이블이나 필드를 통해 차이를 관리합니다.
- 데이터 저장 시 회원과 비회원의 주문 및 결제를 구분하기 위해 추가적인 속성(예:
추적성과 보안 유지:
- 비회원의 익명성과 관련된 문제를 해결하기 위해 추적 메커니즘을 강화해야 합니다. 비회원의 IP, 장치 정보 등을 활용하여 세션을 관리하고, 데이터 무결성을 보장합니다.
- 비회원의 익명성과 관련된 문제를 해결하기 위해 추적 메커니즘을 강화해야 합니다. 비회원의 IP, 장치 정보 등을 활용하여 세션을 관리하고, 데이터 무결성을 보장합니다.
비회원 기능 추가를 고려할 때, 기존 시스템의 구조를 최대한 활용하며, 공통 로직을 강화하여 시스템의 일관성과 유지보수성을 높이는 방향으로 진행하면 좋습니다.
관련된 질문으로는 Controller에서 비즈니스 로직 흐름이 나타나는 것에 대하여..을 참고하시면, 서비스 계층에서 어떻게 로직을 나누고 유지할지에 대한 유익한 논의가 포함되어 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.





안녕하세요! 저는 OrderOwner, CartOwner 등 별도의 개념객체를 반드는 방안을 생각했습니다. 비회원 또한 고객의 한 타입인 느낌이 들었습니다.
기존에는 User라는 하나의 개념만 있었다면 이제는 Member와 Guest를 User라는 상위 개념이 감싸지게 된 느낌이죠. 비회원 또한 주문의 주체이지 않나? 라는 생각이 들어서 개념객체로 표현하게 된 것 같습니다.
해당 클래스를 만들어 OrderService에서는 주문조회와 생성의 주체를 OrderOwner로 잡고.. OrderFinder등에서 분기처리를 하여 조회를 할 것 같습니다.
제미니님의 의견은 어떠신가요?? 답변 감사드립니다!