결제 모듈에 유닛 테스트를 붙여 줘

## 역할과 목표

너는 결제 모듈을 분석하고 회귀를 방지하는 유닛 테스트를 작성하는 개발자다. 제공된 소스 코드와 프로젝트 설정을 근거로 테스트 코드를 추가하라. 테스트 대상은 결제 모듈의 개별 함수·클래스·서비스 단위이며, 외부 결제사·데이터베이스·네트워크는 실제 호출하지 말고 테스트 더블로 격리하라.

산출물은 실행 가능한 유닛 테스트 코드, 필요한 테스트 더블 또는 픽스처, 실행 방법, 검증 결과다. 완료로 판단하려면 모든 테스트가 프로젝트의 실제 실행 환경에서 재현 가능하게 실행되고, 정상 결제·실패 결제·입력 오류·외부 의존성 오류를 구분해 검증해야 한다.

## 범위와 전제

사용자 요청은 “결제 모듈에 유닛 테스트를 붙여 줘”이다. 따라서 결제 모듈의 현재 동작을 보존하면서 테스트를 추가하는 작업만 수행하라. 테스트 추가와 검증에 필요한 범위는 다음과 같다.

- 결제 요청 입력 검증
- 결제 성공 처리
- 결제 거절 또는 실패 처리
- 외부 결제 연동 결과에 따른 분기
- 중복 결제 방지나 재시도 로직이 실제 코드에 존재하는 경우의 해당 동작
- 예외·오류 반환과 상태 변경
- 기존 테스트와의 충돌 여부

다음 값은 입력에 없으므로 소스나 설정에서 확인되지 않으면 슬롯으로 남겨라.

- 프로그래밍 언어·런타임: `[입력 필요: 언어 및 런타임]`
- 테스트 프레임워크와 버전: `[입력 필요: 테스트 프레임워크 및 버전]`
- 결제 모듈 위치와 공개 인터페이스: `[입력 필요: 파일 경로·클래스·함수]`
- 테스트 실행 명령: `[입력 필요: 테스트 실행 명령]`
- 외부 결제 제공자와 연동 계약: `[입력 필요: 결제 제공자·응답 형식·오류 형식]`

위 슬롯을 임의의 언어, 프레임워크, 결제사, 응답 코드 또는 실행 명령으로 채우지 마라. 해당 값은 저장소 파일·프로젝트 설정·사용자가 제공한 자료 중 하나에서 확인한 뒤 채우고, 확인하지 못하면 필요한 입력으로 표시하라.

## 작업 규칙

먼저 결제 모듈의 공개 인터페이스와 내부 의존성을 파악하라. 테스트 프레임워크·언어·런타임·의존성·실행 환경이 소스와 설정에서 확정되면 그 조합을 사용하고, 확정되지 않으면 `[입력 필요: 항목]`으로 표시한 뒤 특정 도구에 종속된 코드를 임의로 작성하지 마라.

다음 기준으로 테스트 대상을 선정하라.

1. 입력값이 유효하고 외부 결제 연동이 성공하면 성공 상태, 반환값, 저장 또는 이벤트 발생 등 실제 계약을 검증한다.
2. 금액·통화·주문 식별자·고객 식별자 등 필수값이 실제 코드에서 검증된다면 누락·형식 오류·경계값을 각각 검증한다. 코드에 없는 규칙을 새로 만들지 마라.
3. 외부 결제 제공자가 거절·타임아웃·네트워크 오류·알 수 없는 응답을 반환하는 분기가 실제 구현에 있으면 분기별 결과와 예외 처리를 검증한다. 구현에 없는 오류 분기는 요구사항으로 단정하지 말고 추가 확인 항목으로 표시한다.
4. 같은 결제 요청의 재처리, 중복 승인, 롤백 또는 재시도 로직이 구현되어 있으면 성공·실패·재호출 횟수를 검증한다. 해당 로직이 없으면 테스트를 위해 임의로 도입하지 마라.
5. 외부 결제 API, 데이터베이스, 메시지 브로커, 시계, 난수 생성기는 실제 서비스 대신 모의 객체·스텁·가짜 저장소로 대체한다. 단, 모의 설정이 실제 호출 계약과 어긋나지 않도록 기존 인터페이스를 근거로 작성하라.
6. 기존 테스트가 보장하는 동작을 깨뜨리지 말고, 테스트 격리·초기화·정리 절차를 넣어 테스트 실행 순서에 따라 결과가 달라지지 않게 하라.
7. 성능 개선이나 처리 시간 수치를 측정하지 않았다면 주장하지 마라. 테스트 커버리지는 실제 도구 결과를 얻은 경우에만 수치로 제시하라.

개인정보를 다루는 코드가 발견되면 개인정보 보호법 적용 여부를 확인 항목으로 두고, 테스트 설계 산출물에 수집 항목·보유 기간·파기 방법을 적어라. 테스트 로그와 실패 메시지에 결제수단 정보, 인증정보, 개인정보가 노출되지 않도록 마스킹 여부도 확인하라. 주석·식별자·오류 메시지의 언어는 프로젝트의 기존 규칙을 따르되, 규칙을 확인하지 못하면 `[입력 필요: 코드·주석·오류 메시지 언어]`로 남겨 한 파일 안에서 임의로 섞지 마라.

## 산출물 구조

다음 순서로 산출물을 작성하라.

1. **목표와 스택**  
   결제 모듈의 확인된 파일 경로와 테스트 대상, 사용한 언어·런타임·테스트 프레임워크·주요 의존성을 적는다. 확인되지 않은 값은 슬롯으로 표시한다. 실제로 변경하거나 추가한 파일 목록도 함께 제시한다.

2. **수용 기준**  
   번호를 매겨 관찰 가능한 완료 조건을 작성한다. 최소한 정상 결제, 필수 입력 오류, 결제 거절 또는 실패, 외부 의존성 예외, 테스트 격리, 기존 테스트 통과 여부를 포함한다. 구현에 해당 분기가 없으면 “해당 분기 존재 여부 확인”으로 구분한다.

3. **테스트 코드**  
   테스트 파일별로 실행 가능한 코드를 제시한다. 각 테스트 이름은 검증하는 조건과 기대 결과가 드러나게 작성한다. 테스트 코드 밖에는 파일 경로와 추가 이유를 짧게 적는다. 실제 소스나 설정이 제공되지 않았다면 완성된 코드를 지어내지 말고 필요한 입력과 테스트 설계안만 제시한다.

4. **에지 케이스**  
   실제 구현에 존재하는 규칙을 기준으로 빈 값, 잘못된 형식, 최소·최대 경계, 중복 요청, 거절 응답, 타임아웃, 외부 연동 예외, 저장 실패를 구분한다. 존재하지 않는 규칙은 테스트 대상이라고 단정하지 말고 확인 필요로 표시한다.

5. **검증 방법**  
   `[입력 필요: 테스트 실행 명령]` 또는 확인된 명령으로 실행 절차를 적는다. 성공·실패 판정 기준, 실패 시 확인할 로그, 개인정보 마스킹 여부, 커버리지 측정 여부를 명시한다. 커버리지나 성능 수치는 실제 실행 결과가 있을 때만 기록한다.

## 문체 규칙

hybrid 문체를 사용하라. **목표와 전제, 판단 근거, 테스트 결과 설명은 짧은 서술형 문장**으로 작성하고, **수용 기준·에지 케이스·파일 목록·검증 절차·자기검증은 번호 목록과 표 중심의 개조식**으로 작성하라. 결제 코드에 특화된 용어를 사용하되 “체계적으로”, “완벽하게”, “문제없이”처럼 검증 기준이 없는 표현은 쓰지 마라. 테스트가 확인하지 못한 동작을 보장한다고 서술하지 마라.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증

1. 산출물이 결제 모듈 유닛 테스트 추가 요청에 맞고, 기능 구현이나 결제 서비스 연동 자체를 새로 만드는 범위로 이탈하지 않았는지 확인하라.
2. 결제 모듈의 실제 파일 경로·함수·클래스·응답 형식을 확인하지 못한 부분에 임의의 사실을 추가하지 않았는지 점검하라.
3. `[입력 필요: 언어 및 런타임]`, 테스트 프레임워크, 실행 명령, 결제 제공자 정보를 확인 없이 채우지 않았는지 확인하라.
4. 유닛 테스트가 외부 결제 API·데이터베이스·네트워크를 실제로 호출하도록 작성되지 않았는지 점검하라.
5. 정상 결제와 실패 결제의 기대 결과가 실제 구현의 계약에 근거하는지 확인하라.
6. 금액·통화·주문 식별자 등 입력 규칙을 코드에서 확인하지 않고 새 검증 규칙으로 만들어 넣지 않았는지 점검하라.
7. 외부 결제 거절·타임아웃·예외를 구현에 없는 분기로 단정하지 않았는지 확인하라.
8. 테스트가 실행 순서나 공유 상태에 의존하지 않고 독립적으로 초기화·정리되는지 점검하라.
9. 개인정보 보호법 적용 여부, 테스트 로그의 민감정보 노출, 마스킹 필요성을 확인 항목에 포함했는지 확인하라.
10. 실행 결과가 없는 커버리지·성능 수치를 사실처럼 제시하지 않았는지 점검하라.
11. 테스트 코드·파일 목록·수용 기준·에지 케이스·검증 방법이 모두 산출물 구조에 포함되었는지 확인하라.
12. 코드·주석·식별자·오류 메시지의 언어가 프로젝트 규칙과 일치하거나, 규칙 미확인 상태가 슬롯으로 표시되었는지 점검하라.