DynamoDB 속성 이름 불일치와 KMS 설정 확인
카카오페이 v2를 구성하면서 공통 트랜잭션 모델을 여러 서비스에 적용하려 했습니다. 그런데 실제 테이블과 모델의 속성 이름이 달라 조회 과정에서 오류가 발생했습니다.
Java 필드는 camelCase였지만 벤더별 transaction 테이블은 PascalCase를 사용했습니다. 이 작업에서는 전체 테이블의 이름 규칙을 바꾸기보다 모델에 실제 속성 이름을 명시해 맞췄습니다.
코드와 저장된 속성 이름
DynamoDB는 transactionId와 TransactionId를 서로 다른 속성으로 봅니다. 키 이름이 맞지 않으면 요청이 실패할 수 있고, 일반 속성이라면 매핑되지 않아 값이 비어 보이거나 다른 이름으로 저장될 수 있습니다.
기존 테이블에는 이미 데이터가 있었습니다. 속성 이름을 바꿀 수는 있지만, 데이터를 변환하고 그 이름을 사용하는 코드를 함께 전환해야 합니다. 당시에는 모델을 테이블에 맞추는 쪽을 선택했습니다.
실제 속성 이름 지정
AWS SDK v2 Enhanced Client의 @DynamoDbAttribute로 실제 속성 이름을 지정했습니다. 아래는 매핑을 보여주기 위한 단순한 getter 예시입니다. 전체 엔티티와 테이블 정의는 생략했습니다.
@DynamoDbPartitionKey
@DynamoDbAttribute("TransactionId")
public String getTransactionId() {
return transactionId;
}annotation은 getter에 적용합니다. Java 필드는 transactionId로 유지하면서 DynamoDB의 TransactionId와 연결할 수 있습니다. 실제 모델에서는 파티션 키와 정렬 키, 인덱스에 쓰는 속성도 함께 맞춰야 했습니다.
공통 라이브러리의 모델도 수정하고, 이를 사용하는 서비스에 반영했습니다. 기존 common 테이블의 camelCase는 유지했습니다. 모든 테이블을 PascalCase로 통일한 작업은 아니었습니다.
저장과 조회 양쪽의 확인
조회 결과만 보면 저장할 때 다른 이름의 속성을 만드는 문제를 놓칠 수 있습니다. 기존 항목을 읽는 경우와 새 항목을 저장하고 다시 읽는 경우를 함께 봐야 합니다.
키 이름과 타입, 정렬 키, 인덱스에서 반환하는 필드도 확인할 항목입니다. 공통 모델을 사용하는 서비스라도 테이블과 인덱스가 다르면 같은 조회를 보장할 수는 없습니다.
KMS 키와 환경 설정
같은 구축 기간에 KMS 키와 CloudFormation 설정도 정리했습니다. 키 식별자를 코드에 직접 고정하기보다 환경 설정을 통해 전달하도록 관리했습니다.
DynamoDB의 저장 시 암호화와 애플리케이션에서 값을 암·복호화하는 처리는 구분해야 합니다. DynamoDB는 기본적으로 저장 시 암호화를 제공하며, 고객 관리 키를 사용하는 경우에는 해당 테이블·리전에 맞는 키와 접근 정책이 필요합니다. Global Table의 복제본에서도 각 리전의 키 구성을 확인해야 합니다.
앱이 직접 KMS를 호출하는 경우에는 사용하는 클라이언트의 리전, 키 식별자와 권한, 기존 암호문을 복호화할 수 있는지를 따로 확인해야 합니다. 설정 저장소에서 키를 읽는다고 키 교체와 기존 데이터 처리가 자동으로 해결되는 것은 아닙니다.
이 작업에서는 저장 모델과 키 설정을 맞춘 뒤 테스트를 보강했습니다. 공통 모델 수정과 라이브러리 반영, 서비스의 실제 배포 상태를 구분해서 확인할 필요가 있었습니다.