Conversation
- AccountVerification 엔티티 bankName → bankCode 필드명 변경 - 계좌번호 양방향 암호화 유틸리티(AesEncryptionUtil) 추가 - 암호화 관련 에러코드 추가 (ENCRYPTION_FAILED, DECRYPTION_FAILED) - Flyway 마이그레이션 V32 추가 (bank_name → bank_code) - 환경변수 설정 추가 (encryption.aes.secret-key) - 도메인 단위 테스트 추가
- AccountVerificationClient 인터페이스 정의 (String 반환) - TossAccountVerificationClient 구현체 추가 (현재 Fake 데이터 반환) - AccountVerificationService에 verifyAccount 메서드 추가 - VerifyAccountCommand, AccountVerificationInfo DTO 추가 - 서비스 단위 테스트 및 통합 테스트 추가
- POST /api/v1/seller/sellers/account-verifications 엔드포인트 추가 - AccountVerificationRequest DTO 추가 - Controller에서 Info 객체 직접 반환 (Response DTO 미사용) - Swagger 문서 작성 (@operation, @apiresponse)
Walkthrough판매자 계좌 인증 흐름(엔드포인트·서비스·외부 클라이언트), 계좌번호 AES-GCM 암호화 유틸리티, 관련 에러 코드(ENCRYPTION_FAILED/DECRYPTION_FAILED), DB 마이그레이션 및 관련 단위·통합 테스트를 추가/수정했습니다. Changes
Sequence DiagramsequenceDiagram
participant Client as Client
participant Controller as SellerController
participant Service as AccountVerificationService
participant ExtClient as AccountVerificationClient
participant Crypto as AesEncryptionUtil
participant Repo as AccountVerificationRepository
participant DB as Database
Client->>Controller: POST /account-verifications (bankCode, accountNumber)
Controller->>Service: verifyAccount(VerifyAccountCommand)
Service->>Repo: findSellerById(sellerId)
Repo-->>Service: Seller
Service->>ExtClient: verifyAccount(bankCode, accountNumber)
ExtClient-->>Service: accountHolder (nullable)
Service->>Crypto: encrypt(accountNumber)
Crypto-->>Service: encryptedAccountNumber
Service->>Repo: save(AccountVerification(bankCode, encryptedAccountNumber, accountHolder, verified, seller))
Repo->>DB: INSERT
DB-->>Repo: OK
Repo-->>Service: AccountVerification
Service-->>Controller: AccountVerificationInfo
Controller-->>Client: CommonResult<AccountVerificationInfo>
Estimated code review effort🎯 4 (Complex) | ⏱️ ~65 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In
`@src/main/java/com/bbangle/bbangle/seller/seller/service/client/TossAccountVerificationClient.java`:
- Around line 5-13: TossAccountVerificationClient.verifyAccount currently always
returns a fixed success value ("테스트예금주"), which is unsafe for production; update
it so the fake behavior is only used in non-production environments (e.g., check
active Spring profile or a feature flag) and otherwise fail-fast or delegate to
the real Toss API client; additionally add a warning log when the fake path is
taken so it's obvious in logs. Reference TossAccountVerificationClient and its
verifyAccount method and implement an environment/profile check (or annotate the
bean with `@Profile` for dev/test) and a clear logger message when returning the
fake value.
In `@src/main/java/com/bbangle/bbangle/util/AesEncryptionUtil.java`:
- Around line 16-56: AesEncryptionUtil currently derives a fixed IV from the key
(ivParameterSpec) which breaks security; change to authenticated AES-GCM with a
per-encryption random IV: update ALGORITHM to "AES/GCM/NoPadding", remove the
ivParameterSpec field and any use of new IvParameterSpec(keyBytes,..) in the
constructor (keep secretKeySpec creation but validate key length is 16/24/32
bytes), then in encrypt(String plainText) generate a fresh 12-byte IV with
SecureRandom for each call, create a GCMParameterSpec(128, iv) and init the
Cipher with secretKeySpec and that spec, encrypt and prepend (or otherwise
include) the IV to the ciphertext before Base64-encoding the combined bytes; in
decrypt(String encryptedText) Base64-decode, split out the IV (first 12 bytes),
create a GCMParameterSpec from it, init Cipher for DECRYPT_MODE with
secretKeySpec and that spec, and decrypt the remaining bytes; remove any code
that derives IVs from the key and ensure exceptions still map to
BbangleException as before.
In `@src/main/resources/flyway/V32__app.sql`:
- Around line 1-2: The current ALTER TABLE CHANGE COLUMN bank_name bank_code
risks data corruption and truncation; instead implement a safe multi-step
migration for account_verifications: add a new column bank_code VARCHAR(10),
populate it from bank_name using a deterministic mapping function/table or CASE
expressions (and explicitly handle/trim/validate values longer than 10 chars and
log unmapped names), verify row counts and integrity, then drop bank_name and
finally rename bank_code if desired; target the migration SQL that modifies
account_verifications and reference the bank_name → bank_code mapping logic so
the update uses that mapping before removing the old column.
🧹 Nitpick comments (3)
src/test/java/com/bbangle/bbangle/seller/domain/AccountVerificationUnitTest.java (1)
55-58: 두 번째 테스트의 assertion 보강을 권장합니다.미인증 상태 테스트에서
isNotNull()과isVerified()외에 다른 필드 검증이 누락되어 있습니다. 첫 번째 테스트와의 일관성을 위해bankCode,accountNumber,accountHolder,seller필드도 검증하면 회귀 버그를 더 잘 감지할 수 있습니다.♻️ 추가 assertion 제안
// assert assertThat(accountVerification).isNotNull(); assertThat(accountVerification.isVerified()).isFalse(); + assertThat(accountVerification.getBankCode()).isEqualTo(bankCode); + assertThat(accountVerification.getAccountNumber()).isEqualTo(encryptedAccountNumber); + assertThat(accountVerification.getAccountHolder()).isEqualTo(accountHolder); + assertThat(accountVerification.getSeller()).isEqualTo(seller); }src/main/java/com/bbangle/bbangle/seller/seller/controller/dto/SellerRequest.java (1)
26-28: 계좌번호 형식 유효성 검사 추가를 권장합니다.현재
@NotBlank만 적용되어 있어 임의의 문자열이 허용됩니다. 계좌번호는 일반적으로 숫자로만 구성되고 길이 제한이 있으므로, 패턴 검증을 추가하면 잘못된 입력을 조기에 차단할 수 있습니다.♻️ 패턴 유효성 검사 추가 제안
`@Schema`(description = "계좌번호", example = "123412341234") `@NotBlank`(message = "계좌번호는 필수입니다.") + `@Pattern`(regexp = "^[0-9]{8,14}$", message = "계좌번호는 8~14자리 숫자만 입력 가능합니다.") String accountNumbersrc/test/java/com/bbangle/bbangle/seller/seller/service/AccountVerificationServiceIntegrationTest.java (1)
121-140: 테스트 프로파일이 이미 적용되어 있지만, 실제 API 구현 시 테스트 격리 보장이 필요합니다.현재
TossAccountVerificationClient는 스텁 구현(@Component로 등록된 실제 빈 사용)을 반환하고 있으며, 테스트는 이미@ActiveProfiles("test")로 테스트 프로파일을 사용 중입니다. 다만 코드의 TODO 주석("토스페이먼츠 API 연동 후 실제 구현 예정")에서 보듯이, 실제 API 호출로 변경되면 테스트가 불안정해질 수 있습니다.테스트 프로파일 전용
AccountVerificationClient구현 또는@MockBean을 통해 외부 의존성을 명시적으로 분리하는 것이 권장됩니다.
Comment on lines
+5
to
+13
| @Component | ||
| public class TossAccountVerificationClient implements AccountVerificationClient { | ||
|
|
||
| @Override | ||
| public String verifyAccount(String bankCode, String accountNumber) { | ||
| // TODO: 토스페이먼츠 API 연동 후 실제 구현 예정 | ||
| // 현재는 Fake 예금주명 반환 | ||
| return "테스트예금주"; | ||
| } |
There was a problem hiding this comment.
프로덕션 배포 시 위험: Fake 구현체가 항상 성공을 반환합니다.
현재 구현은 실제 계좌 검증 없이 항상 고정된 예금주명을 반환합니다. 이 상태로 프로덕션에 배포되면 모든 계좌가 유효한 것으로 처리되어 보안 및 데이터 무결성 문제가 발생할 수 있습니다.
실제 API 연동 전까지 다음 중 하나를 고려해 주세요:
🛡️ 권장 조치 방안
방안 1: 프로파일 기반 제한
+import org.springframework.context.annotation.Profile;
+
+@Profile("!prod")
`@Component`
public class TossAccountVerificationClient implements AccountVerificationClient {방안 2: 경고 로깅 추가
+import lombok.extern.slf4j.Slf4j;
+
+@Slf4j
`@Component`
public class TossAccountVerificationClient implements AccountVerificationClient {
`@Override`
public String verifyAccount(String bankCode, String accountNumber) {
+ log.warn("[FAKE] 계좌 인증 요청 - bankCode: {}, 실제 API 연동 필요", bankCode);
// TODO: 토스페이먼츠 API 연동 후 실제 구현 예정
return "테스트예금주";
}🤖 Prompt for AI Agents
In
`@src/main/java/com/bbangle/bbangle/seller/seller/service/client/TossAccountVerificationClient.java`
around lines 5 - 13, TossAccountVerificationClient.verifyAccount currently
always returns a fixed success value ("테스트예금주"), which is unsafe for production;
update it so the fake behavior is only used in non-production environments
(e.g., check active Spring profile or a feature flag) and otherwise fail-fast or
delegate to the real Toss API client; additionally add a warning log when the
fake path is taken so it's obvious in logs. Reference
TossAccountVerificationClient and its verifyAccount method and implement an
environment/profile check (or annotate the bean with `@Profile` for dev/test) and
a clear logger message when returning the fake value.
Comment on lines
+1
to
+2
| -- account_verifications 테이블의 bank_name 컬럼을 bank_code로 변경 | ||
| ALTER TABLE account_verifications CHANGE COLUMN bank_name bank_code VARCHAR(10); |
There was a problem hiding this comment.
은행명→은행코드 전환 시 데이터 백필/변환 누락 위험
컬럼 이름만 변경하면 기존 bank_name 값이 그대로 bank_code로 해석되어 데이터 정합성이 깨질 수 있습니다. 또한 기존 값 길이가 10자를 초과하면 절단 위험이 있습니다. 매핑 백필 또는 안전한 단계적 마이그레이션을 고려해 주세요.
🔧 안전한 마이그레이션 방향 예시
-ALTER TABLE account_verifications CHANGE COLUMN bank_name bank_code VARCHAR(10);
+ALTER TABLE account_verifications ADD COLUMN bank_code VARCHAR(10);
+-- TODO: bank_name → bank_code 매핑으로 백필
+-- UPDATE account_verifications SET bank_code = CASE bank_name ... END;
+-- ALTER TABLE account_verifications DROP COLUMN bank_name;🤖 Prompt for AI Agents
In `@src/main/resources/flyway/V32__app.sql` around lines 1 - 2, The current ALTER
TABLE CHANGE COLUMN bank_name bank_code risks data corruption and truncation;
instead implement a safe multi-step migration for account_verifications: add a
new column bank_code VARCHAR(10), populate it from bank_name using a
deterministic mapping function/table or CASE expressions (and explicitly
handle/trim/validate values longer than 10 chars and log unmapped names), verify
row counts and integrity, then drop bank_name and finally rename bank_code if
desired; target the migration SQL that modifies account_verifications and
reference the bank_name → bank_code mapping logic so the update uses that
mapping before removing the old column.
|
Note Docstrings generation - SUCCESS |
coderabbitai bot
added a commit
that referenced
this pull request
Feb 1, 2026
Docstrings generation was requested by @kimbro97. * #579 (comment) The following files were modified: * `src/main/java/com/bbangle/bbangle/seller/domain/AccountVerification.java` * `src/main/java/com/bbangle/bbangle/seller/seller/controller/SellerController.java` * `src/main/java/com/bbangle/bbangle/seller/seller/controller/dto/SellerRequest.java` * `src/main/java/com/bbangle/bbangle/seller/seller/controller/swagger/SellerApi.java` * `src/main/java/com/bbangle/bbangle/seller/seller/service/AccountVerificationService.java` * `src/main/java/com/bbangle/bbangle/seller/seller/service/client/AccountVerificationClient.java` * `src/main/java/com/bbangle/bbangle/seller/seller/service/client/TossAccountVerificationClient.java` * `src/main/java/com/bbangle/bbangle/seller/seller/service/info/AccountVerificationInfo.java` * `src/main/java/com/bbangle/bbangle/util/AesEncryptionUtil.java`
kmindev
approved these changes
Feb 1, 2026
This was referenced Feb 4, 2026
This was referenced Feb 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reviewer
1팀
History
🚀 Major Changes & Explanations
(판매자) 계좌정보 인증
기존 은행 이름 방식에서 은행 코드 방식으로 변경 (API 연동 표준화 및 정확성 향상)
계좌번호는 AES-256 양방향 암호화하여 DB에 저장 (정산 등 필요 시 복호화하여 사용)
Summary by CodeRabbit
새로운 기능
개선사항
테스트
DB 마이그레이션
✏️ Tip: You can customize this high-level summary in your review settings.