14조 코드리뷰 5회차

[rbm0524]

📌 관련 이슈

• [FEAT] CORS 설정 #60
• [REFACTOR] 회원 API리팩토링 #62
• [FEAT] GeoHash 적용 #59
• [FEAT] 결제 승인 구현 #36

✨ PR 내용

9주차 개발사항 적용했습니다.

궁금한점

---

1. 트랜잭션 분리

@Service
@Slf4j
@RequiredArgsConstructor
/** 결제 승인 서비스 */
public class PaymentConfirmService {

	private final TossPaymentsClient tossPaymentsClient;

	private final PaymentValidationService paymentValidationService;
	private final PaymentStatusUpdateService paymentStatusUpdateService;
	private final PointUpdateService pointUpdateService;

	@Transactional
	public PaymentConfirmationResponse confirm(PaymentConfirmRequest request) {
		// 1. 결제 상태 변경 (준비 -> 실행 중)
		paymentStatusUpdateService.updatePaymentStatusToExecuting(request.orderId(), request.paymentKey());
		// 2. 결제 유효성 검사
		paymentValidationService.validate(request.orderId(), BigDecimal.valueOf(request.amount()));
		// 3. 결제 승인 요청
		PaymentConfirmationResponse response = tossPaymentsClient.confirmPayment(request);
		// 4. 승인 결과에 따른 결제 상태 업데이트
		paymentStatusUpdateService.updatePaymentStatus(new PaymentStatusUpdateCommand(request.paymentKey(), request.orderId(), response.paymentStatus()));
		// 5. 포인트 충전
		pointUpdateService.increasePoint(request.orderId());
		return response;
	}

}

confirm 메소드에서 하나의 트랜잭션으로 5개의 로직이 수행될 때 “결제 상태 변경”과 같은 부가기능의 실패로 결제 승인에 성공하였음에도 DB에 올바르게 기록되지 못하는 상황을 방지하기 위해 트랜잭션을 분리할 수 있나요?

현재 결제 승인 내부 로직 전체를 한 트랜잭션으로 수행 중인데 여기서 수행되는 몇몇의 기능은 별도의 트랜잭션에서 수행되도록 구현하고 싶은데 어떤 방법이 좋을지 궁금합니다!

2. 카카오 로그아웃

카카오 로그아웃 방식

1. 서비스 토큰만 만료

• 장점: 간편하다
• 단점: 로그아웃하고 다시 로그인할 때 바로 로그인되버려서 계정을 못 바꾼다

2. 카카오 로그아웃

• 요청: 액세스토큰(카카오의)
• 응답: 사용자 카카오 아이디
• 카카오 액세스토큰을 만료시킨다
• 서비스토큰 만료는 별도로 구현

3. 카카오 계정과 함께 로그아웃
   -요청: 앱 키, 리다이렉트 url (서비스로그아웃할)
   -응답: 별도로 없음

• 여기서 카카오 계정과 함께 로그아웃은 요청으로 보내는 거에 사용자 관련 내용이 없는데 어떻게 사용자를 식별에서 로그아웃을 시키는지 알기 어려웠습니다. 이에 대한 멘토님의 도움이 필요합니다,,,
• 저의 추측: 카카오와 관련된 사용자 정보가 쿠키로써 브라우저에 저장되어 있어서 그걸 활용

구현에 어려움이 있는 것은 아니나 3번 카카오 계정과 함께 로그아웃 방식에 대해서 완벽히 이해하지 못 해 멘토님께 도움을 얻고 싶어 질문드립니다!

[leaf-upper]

안녕하세요~ 시험이 마무리 되신지 별로 안되셨을텐데요, 5주차 프로젝트 진행하시느라 고생많으셨습니다~!
몇가지 질문주신부분에 대해서 제가 생각하는 부분을 답변을 드릴게요.

1. 트랜잭션 분리

결제 과정이 웹페이지에서는 굉장히 쉽게 이뤄지는것 같지만 백엔드 서비스 개발 구현 관점에서는 복잡한 부분이 많은것 같아요
질문 주신 부분도 어려운 부분중 하나인데요~
결제 승인이 되었더라도, 서비스 DB에 올바르게 기록되지 않는 상황이 간혹가다 발생할수 있습니다. 대부분의 케이스는 네트워크 오류로 인해서 그런 상황이 종종 발생해요.
일단 질문 주신 부분의 "부가기능에 대한 트랜잭션 분리"는 여러가지 방법이 있을 수 있습니다. 가장 쉬운 방법은 트랜잭션 전파수준 (Propagation)을 변경하여, 부가기능이 실패해서 롤백되더라도, 주요기능은 커밋하실 수 있습니다.
두번째는 메세징 큐 혹은 비동기 이벤트를 이용한 처리 방식인데요, 결제 Event 혹은 메세지를 발행하고, 이 메세지를 처리하는 Handler 혹은 Consumer 애플리케이션을 둬서, 로직을 분리시킬 수 있습니다.

질문 주신 부분에 대한 답변은 위처럼 드릴 수 있겠지만, 트랜잭션을 분리한다고 하더라도 결제 상태가 불일치하는 케이스가 생기기 마련입니다.
그래서 결제 시스템에서는 배치 애플리케이션을 통해 결제 상태의 정합성을 맞춰가는 과정이 필요합니다.

토스 페이먼츠의 결제 시스템을 연동하신다면, 토스페이먼츠에서 제공하는 결제 조회 API (일단위, 시간단위 혹은 분단위로까지 가능합니다.)
를 통해서 토스에서 결제한 내역과 우리가 결제한 내역의 상태가 서로 일치하는지 체크하고, 불일치한다면 이를 어떻게 처리해야할지도 고민이 필요합니다.

결제는 데이터 정합성이 100% 맞아야하는 서비스의 중요한 시스템인만큼 위 답변에 대해서도 좋은 참고가 되셨으면 좋겠습니다.

2. 카카오 로그아웃

여기서 말하는 로그아웃은 결국 사용자의 액세스토큰을 만료시키는 작업을 말하는것 같아요. 질문 주신 부분은 카카오 로그아웃이 아닌,
"카카오 계정과 함께 로그아웃" 기능으로 이해했습니다. 카카오 디벨로퍼스에서의 문서를 읽어봤을때 "카카오 계정과 함께 로그아웃은" 사용자가 카카오 소유의 페이지로 이동하여, 카카오 서비스 자체에서 로그아웃을 하는 기능을 말하는것 같은데요,
모든 서비스의 로그인과정이 그러하듯, 카카오 또한 마찬가지로 관련된 사용자를 식별하기 위해 필요한 정보가 (쿠키 혹은 세션) 브라우저에 남아있기 때문에 이를 이용해 카카오에서 로그아웃 시킬 수 있을것 같습니다.
결론적으로는 추측해주신게 맞는것 같아요.

추가적으로 궁금하신 사항있으시면 말씀부탁드려요~

[leaf-upper]

Frontend와 Backend서버간 Origin이 서로 달라서 CORS 설정을 해주신것 같아요.
서로 같은 Origin이 되도록 웹 서버 (NGINX) 를 하나 두고, 이를 통해 FE의 파일들과, BE의 API를 제공하면 CORS 헤더 없이도 문제를 해결할 수 있을까요?

[westzeroright]

오호.. nginx를 활용해서 해결할 수도 있는거였군요,, 좋은 방법 알려주셔서 감사합니다! nginx통해서 https 통신을 해보려고 했는데 이 과정 중에서 적용해보겠습니다..!

[leaf-upper]

PointManagementService, PointUpdateService는 완전히 같은 코드 인것 같아서 중복제거를 위해서 한가지만 사용하면 좋을것 같습니다.

[nove1080]

PoinUpdateService -> PointManagementService 로 이름을 변경했는데 두 파일이 모두 들어간것 같네요 ㅜㅜ

[leaf-upper]

👍 👍

[leaf-upper]

최신기술이네요~

[leaf-upper]

👍 👍
이전보다 코드의 가독성이 좋아진것 같은기분이 드네요~
너무 고생많으셨습니다!
마지막 1주차 남았는데요! 항상 마지막에 잘 마무리하는게 중요하더라구요~
남은 1주차 화이팅입니다.

[westzeroright]

멘토님 답변감사드립니다! 남은 1주차 화이팅해보겠습니다!!

[nove1080]

안녕하세요~ 시험이 마무리 되신지 별로 안되셨을텐데요, 5주차 프로젝트 진행하시느라 고생많으셨습니다~! 몇가지 질문주신부분에 대해서 제가 생각하는 부분을 답변을 드릴게요.

1. 트랜잭션 분리

결제 과정이 웹페이지에서는 굉장히 쉽게 이뤄지는것 같지만 백엔드 서비스 개발 구현 관점에서는 복잡한 부분이 많은것 같아요 질문 주신 부분도 어려운 부분중 하나인데요~ 결제 승인이 되었더라도, 서비스 DB에 올바르게 기록되지 않는 상황이 간혹가다 발생할수 있습니다. 대부분의 케이스는 네트워크 오류로 인해서 그런 상황이 종종 발생해요. 일단 질문 주신 부분의 "부가기능에 대한 트랜잭션 분리"는 여러가지 방법이 있을 수 있습니다. 가장 쉬운 방법은 트랜잭션 전파수준 (Propagation)을 변경하여, 부가기능이 실패해서 롤백되더라도, 주요기능은 커밋하실 수 있습니다. 두번째는 메세징 큐 혹은 비동기 이벤트를 이용한 처리 방식인데요, 결제 Event 혹은 메세지를 발행하고, 이 메세지를 처리하는 Handler 혹은 Consumer 애플리케이션을 둬서, 로직을 분리시킬 수 있습니다.

질문 주신 부분에 대한 답변은 위처럼 드릴 수 있겠지만, 트랜잭션을 분리한다고 하더라도 결제 상태가 불일치하는 케이스가 생기기 마련입니다. 그래서 결제 시스템에서는 배치 애플리케이션을 통해 결제 상태의 정합성을 맞춰가는 과정이 필요합니다.

토스 페이먼츠의 결제 시스템을 연동하신다면, 토스페이먼츠에서 제공하는 결제 조회 API (일단위, 시간단위 혹은 분단위로까지 가능합니다.) 를 통해서 토스에서 결제한 내역과 우리가 결제한 내역의 상태가 서로 일치하는지 체크하고, 불일치한다면 이를 어떻게 처리해야할지도 고민이 필요합니다.

결제는 데이터 정합성이 100% 맞아야하는 서비스의 중요한 시스템인만큼 위 답변에 대해서도 좋은 참고가 되셨으면 좋겠습니다.

오 배치 애플리케이션을 통해 정합성을 맞추는 부분은 생각하지 못했는데 말씀 감사합니다!
이번 프로젝트에 배치 서버를 구축하긴 힘들겠지만 프로젝트가 종료된 후에 보다 완성도 높은 결제 시스템을 위해 만들어보겠습니다~