결제 뒷고기

[GIVEN53]

.

[GIVEN53]

reviewer:
스웨거는 다른 개발자에게 해당 API 사용하는 방법을 설명해주는 용도로 쓰이는데요~
기본으로 적용되는 것 만으로는 스웨거가 문서의 용도로 쓰이기 아쉬운 부분이 많은 것 같아요.

@Tag 을 활용해서 도메인 별 API 나눠주기
어떤 도메인에 쓰이는 API 인지 명확하게 구분해주고, 도메인에 대한 설명을 추가함으로써 사용하는 개발자에게
가이드를 제공해줄 수 있게 되어요.

Request 에 @Description, @Example 를 활용해서 데이터의 설명과 더불어서 어떤 형태로 데이터가 들어오면 좋은지를
구체적으로 명시해보기.

요청에 필요한 값들이 어떤 형태로 들어와야하는지 구체적으로 가이드 해줄 수 있습니다.

(참고사항) controller 에 적용할 수도 있는데 controller 에 사용하게되면 가독성이 떨어질 수 있어
보통 requestDto 로 매핑해서 해당 오브젝트 내에서 선언해두곤 하는 것 같습니다.

link: woowacourse/spring-roomescape-payment#111 (comment)

[Kimprodp]

e-commerce에서 사용자가 육안으로 확인할 수 있는 결제 내역은 최종값(승인, 예약 등)밖에 없습니다.
하지만 결제 내역의 상태를 변경한 내용을 history 등으로 나타내어 저장하고 있을거예요.
사용자 문의 혹은 정산, 버그 추적 등에서 사용하기 때문입니다.
도메인 용어와 개발 용어를 최대한 분리하여 사용해야합니다. 커뮤니케이션을 진행할 때 헷갈릴 수 있기 때문입니다.

woowacourse/spring-roomescape-payment#84 (comment)

---

@primary를 작성한 이유가 있을까요?

woowacourse/spring-roomescape-payment#39 (comment)

---

RestDoc을 작성하며 불편했던 점이 있을까요?
그렇다면 이를 해결하기 위해 어떤 방안을 고민해보셨을까요?

불편한 점을 알고 이를 개선하려는 태도가 훌륭하네요 :D
4.adoc 결합 답변 : API 문서를 작성할 때, 필요한 내용을 정한 후 build.gradle에서 자동으로 문서를 만들었습니다.

woowacourse/spring-roomescape-payment#144 (comment)

[nayonsoso]

🏃‍♂️🦆

🔸 @Value 보다는 @ConfigurationProperties를 사용하기

리뷰어 :

@value를 사용하는 경우에 설정값에 하드코딩된 문자열로 접근하기 때문에, 
해당 설정값에 접근하는 곳이 여러 군데 생기면 관리하기가 어려워진다는 단점이 있어요.
@ConfigurationProperties를 대신 사용해보는 것은 어떤가요?

리뷰이 :
너무 좋습니다!
이젠 record 로도 사용이 가능하며 스프링 2.6 버전 부터 @ConstructorBinding 을 붙여 줄 필요도 없어서 간단한 코드로 빈 등록과 설정 값을 객체로써 가져올 수 있었습니다!

🔸 timeout 테스트 방법

이 부분은 테스트해보고싶다면 테스트코드 실행시에 가상의 웹 서버를 띄워야할거에요.
자동화된 환경을 구축하려면 시간이 좀 걸릴 수도 있겠어요. 까다로울수 있으니 너무 많이 시간을 쓰지 않는 선에서만 시도해보시는게 좋을것같네요.
자동화된 테스트가 어렵다면 가상의 Mock 서버를 실제로 띄워보고 (spring 서버를 쓸수도 있겠죠) 임의로 delay를 주어 응답하는 방식으로 인수테스트를 진행하여 확인해볼수도 있을것같네요.

woowacourse/spring-roomescape-payment#75 (comment)

🔸 로그를 어디에 저장해야 할까?

로그는 아주 중요한 문제죠. 
회사 규모가 커지면 로그 관리만 도맡아 하는 팀이 따로 생기기도 해요.
일반적으로 서버로그를 서버에 쌓으면 매번 로그를 확인해야 할 때마다 서버에 직접 들어가봐야하니 불편하죠.
실제 서비스되는 데이터가 아니라 로그와 같이 운영 과정에서 나오는 부가적인 데이터들은 DB로 관리하기에 약간 과하기도 해요.
이럴 때에 사용하기 적합한 것이 검색엔진이에요.
시간을 너무 많이 쓰시지 않는 선에서 ELK, datadog, grafana loki 와 같은 키워드들로 한번 학습해보시면 좋을것같네요.

또한 로그를 남길 때는 '기록해뒀다가 나중에 보게 될 것인가? 진짜로?' 를 질문해봐야해요.
로깅 비용이 생각보다 비싸요.
RestClient 요청 부분을 모두 로깅해서 보고싶은가요? 
헤더에 대해서 세세하게 볼 필요가 있나요? 
진짜로?

🔸 API 문서에 동작에 대한 것을 꼼꼼히 적는게 오히려 안좋을 수 있다.

문서를 정말 꼼꼼히 작성해주셨는데, 전반적으로 설명이 약간 과한것같네요.
주석과 마찬가지로 문서에도 동작과 관련된 내용은 되도록 들어가지 않는 것이 좋아요.
나중에 해당 API의 동작이 바뀔 수도 있고, 다른 목적으로 다른 곳에서 API가 사용될 수도 있죠.
API 스펙 자체만 보고도 용도와 동작을 대강 알 수 있도록 설계해야하고, 잘 만들면 보통은 스펙만 보고도 대강 추측할 수 있어요.

woowacourse/spring-roomescape-payment#147 (comment)

[alstn113]

리뷰어: 외부 연동 클라이언트와 관련된 부분은 docs를 주석으로 첨부하면 유용하다.

woowacourse/spring-roomescape-payment#62 (comment)

---

리뷰어: 외부 클라이언트 테스트는 수행해본 후 disabled 처리한다.

woowacourse/spring-roomescape-payment#62 (comment)

[le2sky]

리뷰어 : Exception이 어떤 http status를 반환해야할 지 web 계층의 정보를 판단해도 되나요? 예외는 controller layer인가요?

리뷰이 : Service에서 발생시킨 예외가 web 계층의 정보를 판단해 자신이 스스로 반환할 HTTP 상태코드를 정하고 있네요. 확실히 잘못된 부분이라 생각됩니다. 상태코드를 정하는 것은 GlobalExceptionHandler 같은 controller layer에서 처리하도록 해보겠습니다.

링크 : woowacourse/spring-roomescape-payment#72 (comment)

---

리뷰어 : 하나의 @transactional로 묶여있을 때 paymentClient.requestPaymentApproval이 지연된다면 어떤 문제가 발생할까요?
@transactional이라는 것은 데이터베이스의 커넥션을 관리하는 범위가 되는 것이고, 이 범위가 데이터베이스가 아닌 요청에 의해 지연이 되는건 생각보다 큰일이에요. 트랜잭션이 아닌 호출이 트랜잭션을 물고 있고, 이로인해 커넥션을 물고있으니 다른 호출이 써야할 커넥션을 점유하고 있는 상황인거죠.

해결을 바라고 드렸던 코멘트는 아니었고 @Transcational을 외부호출과 함께 두었을때의 문제에 대해서 짚고 넘어가셨으면 해서 남긴 이야기여서 이정도로 넘어가도 좋을 것 같아요.

링크 : woowacourse/spring-roomescape-payment#72 (comment)

---

상황 : spring data jpa repository를 한번 래핑함 (repository -> repositoryImpl)

리뷰어 : (개인적으로는) jpa를 사용했을 때 현재와 같이 의존성을 빼는 행위가 불필요하다고 생각해요. 확장가능한 구조를 바라보았을 때 이미 jpaRepository를 상속받은 Repository 인터페이스이기 때문에 확장이 불가능한건 아니거든요. 물론 이상적인 구조에서는 jpa에 종속적인 entity와 순수 도메인 클래스를 분리한다라는 이야기도 있는데 저는 이또한 불필요하다고 생각합니다. "이상"과 "현실"은 다르기 때문에 공수가 많이 드는 작업은 굳이하지 않는것이 맞다고 생각해요. 특수한 케이스가 아닌 이상 분리한다고 하더라도 jpa entity와 도메인 클래스의 정보들이 완전히 동일할텐데 그럼 하는 이유가 없는 것 아닐까싶어요.

링크 : woowacourse/spring-roomescape-payment#78 (comment)

---

리뷰어 : 로그는 굳이 줄바꿈을 하지는 않아요. 콘솔에 출력을 보기 위함이 아니기 때문에 줄바꿈을 통해서 얻는 이득은 거의 없습니다. 수많은 로그들이 줄바꿈이 되어 정렬되어있으면 오히려 보기 힘들어요.

링크 : woowacourse/spring-roomescape-payment#78 (comment)

---

리뷰어 : openapi란 무엇인가요?

리뷰이 : openapi는 restful api를 정의하기 위한 표준이에요. openapi로 API의 엔드포인트, 메서드, 매개변수, 응답 형식 등을 명확하고 일관되게 기술할 수 있어요. 과거에 swagger로 불렸지만 팀이 smartbear에 합류하면서 v3부터 openapi로 이름을 변경했다는 히스토리가 있어요.

링크 : woowacourse/spring-roomescape-payment#120 (comment)

---

상황 : Member의 equals hashcode

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Member member = (Member) o;
        if (id == null || member.id == null) {
            return Objects.equals(email, member.email);
        }
        return Objects.equals(id, member.id);
    }

    @Override
    public int hashCode() {
        if (id == null) {
            return Objects.hash(email);
        }
        return Objects.hash(id);
    }

리뷰어 :

1. java의 equals와 database를 동일선상에서 보는 것이 맞나요?

equals의 목적은 무엇이라고 생각하시나요? 두 객체의 동등성을 비교하는 것이 그 목적이라면 unique한 email로만 equals를 사용해도 도메인 코드를 어플리케이션에서 사용할 때 문제가 없는 것 아닌가요?
일반적으로 id만으로 equals의 대상으로 잡는 이유는 database entity와 domain를 동일선상에서 보는 것으로 어느정도 합의를 했기 때문이에요. 그 상황이라면 id가 null이면 null인대로 database entity가 아니기 때문에 동등성 대상으로 바라보지 않는거죠.
다만 equals의 목적이 domain 객체의 순수성 그자체라면 id로의 비교없이 email로만 비교해도 될 것이고요.

3. jpa는 equals를 작업하지 않아도 동일성비교가 가능합니다.

이미 영속성 컨텍스트에 들어간 상태라는 것을 생각한다면 jpa에 종속된 현재 어플리케이션에서는 equals 동등성이 아니더라도 jpa persistence context에 들어갔다 나온 이후이기 때문에 동일성비교가 가능합니다. id로만 비교하는 것이 목적이라면 오히려 equals 동등성을 재정의하지 않아도 jpa가 알아서 동일성을 보장해주는 것 아닐까요?

5. equals hashcode에는 if 등과 같은 로직을 태우지 않습니다.

객체의 상태를 보장하는 일반적인 Object메소드들은 로직을 태우게 된다면 다른 사람들이 봤을때 이해의 영역으로 넘어가기 때문에 가능하면 인텔리제이에서 자동으로 생성해주는 것 이상의 추가 분기 로직은 태우지 않는 편이에요.
예를들면 Object의 toString()는 통념상 "디버깅"의 용도이기 때문에 마찬가지로 이를 비즈니스적 의미를 가진 출력물은 전부 배제하고 디버깅을 위한 필드에 대한 정보만 정리되어 담아둡니다.

링크 : woowacourse/spring-roomescape-payment#134 (comment)

---

리뷰어 :

팀프로젝트로 넘어가시다보면 지금과 같이 특정 요청 혹은 로직에 대해서 시작과 끝을 로깅하고 둘을 함께 트래킹해야할 때가 생길 수 있어요. 만들어주신 형태로 메소드단에서는 scope이 다른 곳으로 넘어가지 않기 때문에 이정도로 충분할 수 있는데 하나의 api요청에 대해서 모든 요청을 비슷하게 트래킹해야하는 상황이 발생할 수 있는거죠.

보통 이에 해결하는 방법으로는 MDC(Mapped Diagnostic Context)을 사용하기도 해요. 키워드만 기억해두시고 나중에 비슷한 상황이 발생했을 때 한번 고민해보시면 좋을 것 같아요.

링크 : woowacourse/spring-roomescape-payment#156 (comment)

[J-I-H-O]

DB 트랜잭션과 외부 통신은 분리하여 수행하는 것이 좋다

Reviewer :

DB transaction 내에서 외부 통신은 지양하시는 것이 좋은데요,
이유에 대해 알고계실까요? 모르신다면 한번 추측해서 답변을 해주시면 좋을것 같습니다.

Reviewee :

1. 트랜잭션이 외부 API 호출을 롤백하지는 않는다.
   결제 이후 애플리케이션 로직에서 예외가 발생하더라도, 결제가 취소되지는 않습니다. 하나의 트랜잭션 관리되고 있지만, 외부 API와의 작용은 데이터베이스 트랜잭션이 아니므로 별도로 관리해야합니다.
2. 외부 API와의 통신 시간이 트랜잭션 시간에 영향을준다.
   데이터베이스와 통신하기 위해 커넥션을 사용하는데, 하나의 트랜잭션에서 외부 API 호출까지 수행하게 되면 호출 시간동안 해당 커넥션을 잡고있게 됩니다. 커넥션 풀은 제한적이므로 여러개의 요청이 발생하면 커넥션을 획득하지 못한 요청은 대기해야하고, 애플리케이션 성능이 저하됩니다.

추가로, 지금은 결제 로직을 예약 서비스에서 분리해서 결제 부분은 트랜잭션에서 제외되도록 했습니다. 그런데 상황에 따라 DB 저장은 완료되었으나 이후에 결제에 실패하면 DB 저장을 rollback하거나, 반대로 결제 이후 DB 관련 로직에서 예외가 생기면 결제를 취소하는 로직이 필요할 수도 있을 것 같은데요, 이런 처리들은 어떤 방식으로 하시는지 궁금합니다!

Reviewer :

찾아주신 이유가 맞습니다. 👍
어떠한 전략을 취할 것이냐에 따라 여러가지 방법이 있을것 같은데요,
보편적인 방법으로는 타 시스템과 대사(compare, reconsiliation)를 통하여 데이터 불일치 상태에 대한 처리를 하곤 합니다.
여기서는 결제사와의 대사 작업이 되겠네요.
이러한 작업을 위해 결제 전후로 데이터를 남기곤 합니다.

woowacourse/spring-roomescape-payment#31 (comment)
woowacourse/spring-roomescape-payment#40 (comment)
woowacourse/spring-roomescape-payment#92 (comment)

---

write-ahead

Reviewee :

payment의 경우 승인된 결제에 대해서만 저장하고 있어 실패 데이터를 모두 저장해야할지 의문이 생겼습니다. 그래서 우선 실패 결과를 DB에 저장은 하지 않고 예외 처리를 하고 로그를 남기고 있는데요, 혹시 의도하지 않은 결과가 왔을 때 일반적으로 어떤 처리를 하시는지 궁금합니다.

Reviewer :

보통의 경우 write-ahead 테이블을 이용한 정보를 먼저 남깁니다. 보통 xxxRequest 라는 이름의 테이블을 많이 사용한 것 같네요.

가령 PaymentRequest 테이블을 만들어 pay 요청을 결제사에 전송하기 전에 먼저 생성하고 이후 상태를 변경하도록 전략을 취합니다.

위 테이블에 요청상태인지, 성공인지, 실패인지를 남기고 각 사유를 남겨두어 pay의 상태를 추적합니다.
(모든 정보를 남기지는 않고 핵심정보만 저장합니다. 단, 필요에 따라 모든 정보를 저장할 수 도 있습니다.)

pay호출 전에 남기는 이유는 실제 호출까지 이루어졌는지 확인을 가장 확실하게 할 수 있는 방법이 db에 기록하는 것이기 때문입니다.

보통의 경우 결제를 한 이후 대사(reconciliation, 데이터 정합성을 맞추는 등의 행위)를 하는데 이를 위해서도 중요하게 사용되는 정보이기도 합니다. 또한 고객의 클레임이 들어왔을때 로그를 확인하는 것보다 admin등에 거래 요청을 확인할 수 있는 기능을 추가하여 대응할 수 있는 장점도 생기곤 합니다.

woowacourse/spring-roomescape-payment#99 (comment)
woowacourse/spring-roomescape-payment#126 (comment)

---

Reviewer :

보통 api를 제공하는 측에서 공유한 readtimeout보다는, 정확히 요청에 대한 처리가 완료되는 경우를 감안해서 1초의 여유를 두시는 것이 안정적입니다.

api를 제공하는 측에서 10초의 readtimeout 시간을 가지고 있다면 11초로 fit하게 설정하는 것이 좋습니다.

woowacourse/spring-roomescape-payment#31 (comment)
woowacourse/spring-roomescape-payment#40 (comment)

---

Reviewer :

소소한 팁인데요. property로 이러한 시간과 관련된 값은 int로 주입받지 않고 처음부터 Duration으로 주입받을 수 있습니다.

properties에 int가 아닌 Duration으로 변수형을 선언하시고 application.yml에 시간 단위를 적어주면 가능합니다. ex. 3s

참고 : https://docs.spring.io/spring-boot/reference/features/external-config.html#features.external-config.typesafe-configuration-properties.conversion

woowacourse/spring-roomescape-payment#40 (comment)

[jimi567]

리뷰어 : 22억 이상을 결제하면 어떻게 되나요? (결제 금액을 나타내는 필드의 타입이 Integer 임)

리뷰이 :
결제에 실패합니다. 더 많은 금액까지 가능하도록
결제 가능 금액을 long 타입까지 늘려주었습니다.

리뷰어 :
방탈출 서버에는 22억 넘는게 없는데요? 라고 묻는다면,

만약 bad request로 22억이 들어온다면, 오버플로우 에러를 내는게 맞을지? validation error를 내는게 맞을지? 로 생각해볼수도 있겠네요.

ref : woowacourse/spring-roomescape-payment#48 (comment)

---

리뷰어 :
PaymentException도 ExceptionType으로 표현하면 어떤가요?

만약 토스페이먼츠가 에러메시지를 변경했다면 방탈출 시스템도 같이 영향을 받겠네요. 토스페이먼츠의 변경이 방탈출 시스템에 영향을 주는건, 객체로 생각해보면 어떤가요?

리뷰이 :

특정 객체의 변경이 외부에 영향을 주는 것을 경계하라는 말씀으로 받아들였습니다. 객체지향에서의 OCP 가 떠오르는데, 잘 접근을 한 것인지 모르겠네요 ㅎㅎ
제가 이미 토스 페이먼츠 라는 "외부"의 무언가를 인터페이스로 추상화 하였으니, 이 인터페이스가 예외에서도 외부와의 충분히 끊어줄 수 있을 것 같아요.

그런데, 여기서 어떤 메시지를 클라이언트에게 내려줄까? 에 대한 고민이 생겼습니다.
선택지는 아래와 같이 존재하는데요.

1. 토스 페이먼츠의 예외 메시지를 그대로 사용한다. -> 외부 api 변경이 서비스에 영향을 줄 가능성이 높다.
2. 400번대 / 500번대 로 구분해 일정한 메시지를 사용한다. -> 클라이언트에게 보안과 관련된 정보를 숨길 수 있고, 토스의 변경에도 영향을 받지 않지만, "잔액 부족" 과 같은 문제에 대해 빠르게 피드백을 받고 해결할 수 있는 부분에 대한 대처가 미흡해질 수 있다.
3. 토스의 에러 코드들을 모두 관리하고, 각각 우리의 메시지로 변경해 사용한다. -> 코드 자체가 새로운 에러 코드 추가와 같은 토스의 변경에 영향을 받게 될 가능성이 높다.

리뷰어 :

만약 저라면, 현재 프로젝트 수준에서는 "잔액부족 / 카드정보가 잘못되었어요" 빼고는 다 "결제실패했어요" 정도로 처리할것 같아요

ref : woowacourse/spring-roomescape-payment#22 (comment)

(외부 API를 사용할 때 에러 핸들링 관련해서 중요한 고민 점이라 생각해서 추가해봤어요)

---

리뷰어 : 타임아웃을 잘 설정해 주셨네요. 왜 5 / 30 이어야 하는지 이유를 생각해볼까요?

리뷰이 :

"connect / read 에서 이루어 지는 작업의 부하 정도가 다르기 때문" 일 것 같습니다.
connect 라는 것은 단순히 클라이언트와 서버 사이의 TCP 연결이 맺는 과정이기 때문에 간단한 네트워크 패킷의 교환 과정입니다.
(3 way handshake 이지만, 마지막 패킷은 클라이언트의 응답이기 때문에 네트워크 패킷 통신 두번이 필요한 작업의 전부일 것 같아요)

반면 read 라는 것은 우리가 원하는 결과값을 받아오는 과정이고, 연결에 비해 더 무거운 작업에 해당할 것 같습니다.
또한, 안돌이 이야기 하셨던 것 처럼 토스 역시 다시 은행사의 API 를 호출하는 과정이 필요하다 보니 시간이 훨씬 많이 필요할 것 같아요

키워드 : 타임아웃, tcp 3 way handshake

ref : woowacourse/spring-roomescape-payment#22 (comment)

---

리뷰어 :
스프링이 사용하는 ObjectMapper는 기본 ObjectMapper와 조금은 다릅니다.
타임 포맷이 달라지거나... 정의되지 않는 필드가 있거나 하면 문제가 될 수 있어요.
(기본 ObjectMapper를 통해, 결제 서비스를 테스트 하는 코드에 대해..)

해당 테스트는 기본 ObjectMapper를 스프링 ObjectMapper라고 생각하고 사용하고 있는것 같은데, 그렇다면 스프링 ObjectMapper를 사용하든 스프링이 쓰는것과 똑같은 설정을 사용하자.

유의 사항 
API 응답이나 웹훅 이벤트 본문에 새로운 필드가 추가와 같이 [하위 호환을 지원하는 변경 사항](https://docs.tosspayments.com/reference/versioning#%ED%95%98%EC%9C%84-%ED%98%B8%ED%99%98%EC%9D%84-%EC%A7%80%EC%9B%90%ED%95%98%EB%8A%94-%EB%B3%80%EA%B2%BD-%EC%82%AC%ED%95%AD)은 버전 릴리즈 없이 기존 API에 반영됩니다. 클라이언트 코드는 이러한 변경에 유연하게 대응할 수 있도록 작성해 주세요. 추가된 새로운 필드를 무시하거나 기본값을 설정하는 방식으로 JSON 파싱 로직을 구성해 주세요.

예를 들어 Java에서는 ObjectMapper를 사용해서 JSON 응답을 처리할 때 .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false) 옵션을 설정하면 새로운 필드가 추가되어도 오류가 발생하지 않을 수 있습니다.

(출처 : https://docs.tosspayments.com/reference/using-api/req-res#유의사항

ref : woowacourse/spring-roomescape-payment#12 (comment)

---

리뷰어 :
트랜잭션과 외부 api를 묶는것부터 질문을 드리고 싶네요.

사실, 현업에서도 이것 때문에 많은 문제가 발생하긴 해요. 다른 회사의 api를 사용하기도 하지만, 요즘 대부분의 회사들은 MSA 구조로 되어 있는 경우가 많아요. 멤버를 조회하려면 멤버 팀이 제공하는 api를 사용해야 한다든지...

외부 api는 네트워크를 이용해야 합니다. 네트워크와 local 코드 수행의 시간차이가 얼마나 나는지 아시나요??

트랜잭션이, 매~~~~~~우 느린 task와 묶인다면 어떤 문제가 있을까요??

알아볼 것 :
외부 API를 연동할 때 고려하면 좋은 점들
카카오 페이 결제 트랜잭션 관리 부분

---

리뷰어 :

결제 도메인에서 String paymentKey를 Id로 가질 경우, 이런 문제가 발생할 수 있어요. INDEX 테코톡

15분이라는 시간에 비해 배우는게 많아서 보는게 좋긴한데..
3줄 요약:
1, mysql innodb 기준 Id는 클러스터링 인덱스로 형성됨,
2. 클러스터링 인덱스에서 새롭게 데이터가 삽입되고, 정렬 규칙으로 중간에 값이 삽입되면, 그 뒤에 있는 값들이 밀려나야돼서, b tree 재구축이 생김
3. 유니크 제약 조건을 걸어라(유니크는 비클러스터링 인덱스로 중복 검사를 위한 인덱스가 생성됨 클러스터링 인덱스와는 독립적으로 관리)

리뷰이 :

위처럼 구성하는 경우, 새로운 paymentKey가 추가되었을 때 많은 엔티티들이 이동하게 되어 추가 비용이 커질 수 있겠네요.
단순히 paymentKey로 결제를 검색하는 경우가 클거라고 생각하여 id로 두었는데, 이는 id가 아닌 unique index로 설정하는 것이 제가 원하는 바에 가깝다는 것을 배우게 되었습니다.

ref : woowacourse/spring-roomescape-payment#2 (comment)

---

리뷰어 :

@Component
public class RoomeescapeExceptionOperationCustomizer implements OperationCustomizer {...}

spring docs 의 open api spec generator에서 필요한 부분을 잘 찾아 원하는 기능을 구현한것 같아요.

Spring Doc 에도 개발자가 문서화를 위해 생성되는 여러 객체를 생성하는 방법을 커스텀할 수 있다. -> OperationCustomizer
이를 통해, 문서화를 위해 필요한 어노테이션의 개수를 현저히 줄일 수 있다.