1. 기술 선택 배경
시스템 내 개인정보 데이터 보호 요구사항이 강화되면서 데이터 암호화 적용이 필수 과제가 되었습니다. 특히 이름, 전화번호, 이메일과 같은 개인정보는 저장 시 암호화가 필요했고, 운영 환경에서도 안전하게 관리되어야 했습니다.초기에는 데이터베이스 자체 암호화 기능만 적용하는 방안도 검토되었지만, 아래 이유들로 애플리케이션이 직접 암복호화를 수행하는 구조를 검토하게 되었습니다.
가. 데이터베이스 단에서만 암호화가 수행될 경우 애플리케이션 외부에서 데이터 접근 권한을 획득한 사용자가 평문 데이터를 조회할 가능성이 존재
나. 고객사 보안 가이드에서는 암호화 및 복호화를 데이터베이스 내부가 아닌 애플리케이션 레벨에서 처리하도록 권장
대상 시스템에서는 MongoDB Atlas를 사용하고 있었으며, MongoDB에서 공식적으로 제공하는 CSFLE(Client Side Field Level Encryption) 기능을 활용할 수 있습니다.
참고로CSFLE는 라이브러리를 통해 클라이언트 레벨에서 데이터를 암호화한 뒤 DB에 저장하고, 조회 시 자동으로 복호화하는 기능입니다.
특히 일부 필드에만 선택적으로 암호화를 적용할 수 있는데, 일반적으로 RDB를 사용하는 운영환경에서 필요한 컬럼에만 최소한으로 암호화하듯이 MongoDB에서도 동일하게 적용됩니다. 전체 데이터를 모두 암호화할 경우 검색 및 운영 효율성이 크게 저하될 수 있는데, CSFLE는 필요한 필드만 암호화할 수 있기 때문에 최적화가 가능합니다.
암호화 키 관리 방식도 보안 중요한 고려 사항이었습니다.
암호화키를 애플리케이션 내부 설정 파일에 저장할 경우 보안상 위험성이 존재하기 때문에 별도 KMS(Key Management Service)를 사용하는 방향으로 검토가 진행되었습니다.
해당 시스템은 AWS 환경에서 운영되고 있었기 때문에 AWS KMS를 사용하기로 결정하였습니다. AWS KMS는 키 생성, 접근 제어, 자동 갱신 기능 등을 제공하며 보안 관리 측면에서 안정성이 높습니다.
추가적으로 MongoDB에서 제공하는 Queryable Encryption 기능도 검토하였습니다.Queryable Encryption은 암호화된 데이터에 대해 일부 검색 기능을 제공하는 장점이 있었지만, 암호화 검색을 위해 추가적인 컬렉션이 생성되고 관리 구조가 복잡해지는 문제가 존재했습니다.
특히 운영 환경에서 DB 컬렉션 수 증가와 관리 복잡도가 예상되었고, 실제 프로젝트에서는 작업 편의성과 유지보수 효율성을 더욱 중요하게 판단하였습니다.
결과적으로 본 프로젝트에서는 CSFLE + AWS KMS 조합을 선택하게 되었습니다.
2. 로컬 환경 적용 과정
CSFLE 적용은 우선 로컬 개발 환경에서 검증하는 방식으로 진행되었습니다.
MongoDB에서는 Java용 CSFLE 샘플 프로젝트를 제공하고 있었으며, 이를 기반으로 기본 동작들을 먼저 확인하였습니다.
샘플 코드에서는 로컬 환경용 마스터키(CMK) 기능도 함께 제공하고 있었기 때문에 초기 테스트를 수행하기에 적합했습니다.초기 단계에서는 다음 항목들을 우선 검증하였습니다.
- 특정 필드 암호화 여부
- 저장 시 자동 암호화 동작
- 조회 시 자동 복호화 동작
- 암호화 대상 필드 지정 방식
- 데이터키(DEK) 생성 방식
- 마스터키(CMK) 연동 방식
CSFLE는 암호화 설정이 적용된 클라이언트를 통해 데이터를 저장할 경우 자동으로 암호화가 수행됩니다. 개발자는 별도의 암복호화 로직을 직접 작성하지 않아도 되기 때문에 개발 편의성이 높습니다.
예를 들어 이름(name) 필드에 암호화 설정을 적용한 뒤 데이터를 저장하면 실제 MongoDB 내부에는 바이너리 형태의 암호화 데이터가 저장됩니다. 반대로 동일한 클라이언트를 통해 데이터를 조회할 경우 자동으로 복호화가 수행되어 애플리케이션에서는 평문 데이터처럼 사용할 수 있습니다.
초기 테스트 과정에서는 Entity 구조와 암호화 스키마 정의 방식도 함께 검토했습니다.MongoDB CSFLE에서는 JSON Schema 기반으로 암호화 필드를 지정할 수 있는데, 특정 필드에 대해 deterministic 또는 random 암호화 방식을 선택할 수 있습니다.
Deterministic 암호화는 동일한 입력값이 항상 동일한 암호문으로 저장되기 때문에 equality 검색이 가능하다는 장점이 있지만 반면 random 암호화는 보안성이 높지만 동일 값 비교가 어렵습니다.
프로젝트에서는 개인정보 보호 수준과 검색 요구사항을 고려하여 검색이 필요한 일부 필드는 deterministic 암호화를 적용하고, 나머지 필드는 random 암호화를 적용하는 방식으로 설계하였습니다.
로컬 환경 테스트를 통해 기본적인 암복호화 동작과 데이터 저장 흐름을 안정적으로 검증할 수 있었습니다.
3. 클라우드 환경 및 AWS KMS 적용
로컬 환경 검증이 완료된 이후에는 MongoDB Atlas 기반 클라우드 환경에 실제 적용을 진행하였습니다.
클라우드 환경에서는 AWS KMS를 실제 운영계와 동일하게 개발계에 KMS로 사용하도록 구성되도록 했습니다. AWS KMS 적용을 위해서는 IAM 권한 설정, KMS Key 생성, 접근 정책 구성 등이 필요합니다.
특히 애플리케이션 서버가 KMS에 접근할 수 있도록 적절한 IAM Role 구성이 중요합니다. 권한 설정이 잘못될 경우 암호화키 조회 실패로 인해 애플리케이션 자체가 정상 동작하지 않을 수 있습니다.
로컬 환경에서는 로컬 마스터키(CMK)를 사용하고 있었기 때문에 운영 환경 전환 과정에서 키 변환 작업이 필요했었습니다.
이 과정에서 MongoDB CSFLE 라이브러리에서 제공하는 Rewrap 기능을 활용하였습니다. Rewrap은 기존 데이터키(DEK)를 새로운 마스터키(CMK)로 다시 암호화하는 기능입니다. 즉, 실제 데이터 자체를 다시 암호화하는 것이 아니라 데이터 암호화키(DEK)를 보호하는 상위 마스터키만 변경하는 구조입니다.
프로젝트에서는 로컬 마스터키 기반 DEK를 AWS KMS 기반 마스터키로 Rewrap하는 방식으로 운영 환경 전환을 수행했습니다.Rewrap 과정에서는 다음 사항들을 중점적으로 확인하였습니다.
- 기존 데이터 정상 복호화 여부
- 신규 저장 데이터 암호화 여부
- AWS KMS 접근 정상 여부
- 기존 DEK 재사용 가능 여부
- 장애 발생 시 롤백 가능 여부
다행히 Rewrap 이후에도 기존 데이터는 정상적으로 조회되었고, 신규 데이터 역시 AWS KMS 기반으로 안정적으로 암호화되는 것을 확인할 수 있었습니다.
운영 환경에서는 보안 정책상 KMS 키 자동 갱신 정책도 함께 적용하였습니다. AWS KMS는 일정 주기로 자동 회전(Rotation)을 지원하기 때문에 키 관리 효율성 측면에서도 큰 장점이 있었다. 해당 주기는 1년으로 설정하였습니다.
4. 운영 과정에서 확인한 주요 이슈
CSFLE를 실제 운영 환경에 적용하면서 다양한 시행착오와 운영 이슈를 경험할 수 있었습니다.첫 번째는 CSFLE 라이브러리 배포 방식 문제입니다.
MongoDB Enterprise용 CSFLE 라이브러리는 DB접속 클라이언트와 별개로 운영체제별 바이너리 파일 형태로 제공되는데, 파일 크기가 상당히 큰 편입니다. 리눅스 환경 기준 수십 MB 수준이었고, 윈도우 환경에서는 수백 MB 수준이었습니다.
초기에는 Git Repository 내부에 포함시키는 방안도 고려했지만, 바이너리 파일 관리 효율성과 Repository 크기 증가 문제 때문에 적절하지 않다고 판단하였습니다. 결과적으로 Nexus Repository를 통해 배포하거나 Docker 이미지 내부에 포함시키는 방식을 권장되었고 해당 프로젝트에서는 Docker 이미지 내부에 포함시키는 방향으로 진행했습니다.
두 번째는 Spring Boot 버전 호환성 문제입니다.
CSFLE 라이브러리는 MongoDB Enterprise 버전에 따라 내부 동작 방식이 조금씩 달랐고, 동일한 메이저 버전이라 하더라도 Spring Boot와의 호환성 문제가 발생할 수 있습니다.
특히 낮은 버전의 Spring Boot에서는 MongoDB Driver 충돌이나 Bean 초기화 오류가 발생하는 사례가 있었습니다. 별도 가이드 문서가 없으므로 현재 사용하는 Spring Boot 버전에 맞춰 비슷한 시기에 나온 CSFLE 라이브러리 버전들을 검증하였습니다.
결과적으로 너무 낮은 Spring Boot 버전 사용은 피하고, MongoDB Driver 및 CSFLE 라이브러리와 충분히 호환성이 검증된 버전을 사용하는 것이 중요하다는 점을 확인할 수 있었습니다.
세 번째는 KMS 마스터키(CMK) 갱신 이슈입니다.
AWS KMS는 기본적으로 자동 키 회전 기능을 제공합니다.
다만 기존 키 역시 일정 기간 유지될 수 있기 때문에 기존 DEK는 즉시 문제가 발생하지 않습니다. 그럼에도 불구하고 보안 관점에서는 새로 갱신된 CMK 기반으로 DEK를 다시 Rewrap하는 것이 권장됩니다.
프로젝트에서는 실제로 로컬 마스터키에서 AWS KMS 마스터키로 Rewrap하는 테스트를 수행하였고, 정상 동작을 확인할 수 있었습니다.
이를 통해 향후 키 교체 및 보안 정책 변경에도 안정적으로 대응할 수 있다는 확신을 얻을 수 있었습니다.
5. 데이터 마이그레이션과 LIKE 검색 대응
데이터 마이그레이션 과정에서도 예상하지 못한 문제가 발생하였습니다.
로컬 환경에서는 암복호화용 클라이언트를 통해 평문 데이터 조회가 정상 동작하였지만, MongoDB Atlas 환경에서는 일부 평문 데이터 조회 시 오류가 발생하였습니다.
결국 배포 환경인 클라우드 환경에서는 멀티 데이터소스 구조를 구성하게 되었습니다.하나는 평문 데이터를 조회하기 위한 일반 MongoDB 클라이언트였고, 다른 하나는 CSFLE가 적용된 암복호화 전용 클라이언트입니다.
마이그레이션 과정에서는 기존 평문 데이터를 일반 클라이언트로 조회한 뒤, 암복호화용 클라이언트로 다시 저장하는 방식으로 진행하였습니다.
이 과정에서 CSFLE가 자동으로 암호화를 수행하였기 때문에 별도의 암호화 로직을 직접 작성할 필요는 없었습니다.
또 다른 주요 이슈는 LIKE 검색 문제였습니다.
암호화 대상 데이터에는 이름과 같은 개인정보가 포함되어 있었는데, 사용자 검색 기능에서는 부분 검색 요구사항이 존재하였습니다.
참고로 금융권 시스템에서는 한국 이름 검색을 위해 키워드 기반 해시 검색 방식을 사용하는 경우가 많습니다. 예를 들어 이름을 초성 또는 일부 문자열 단위로 분리한 뒤 해시값으로 저장하고, 검색 시에도 동일한 방식으로 해시 변환 후 조회하는 구조입니다.
문제는 영문 이름이었습니다. 영문 이름은 부분 검색 경우의 수가 훨씬 많았기 때문에 원활한 검색을 위해 최소 16개 이상의 키워드 생성이 필요했습니다.
다행히 MongoDB는 배열 기반 검색 기능을 제공하고 있었기 때문에 키워드 해시 배열 필드를 추가하는 방식으로 해결할 수 있었습니다. 즉, 이름 필드 자체는 암호화하되, 검색용 키워드 해시 배열은 별도로 저장해 부분 검색 기능을 지원하도록 구성하였습니다.
만약 관계형 데이터베이스(RDB)를 사용하고 있었다면 별도의 키워드 참조용 해시 테이블을 두는 방식이 필요했을 것입니다.
이번 프로젝트를 통해 데이터 암호화는 단순히 저장 시 암호화만 고려하는 것이 아니라 검색, 운영, 마이그레이션, 키 관리까지 모두 포함한 종합적인 설계가 필요하다는 점을 다시 한번 확인할 수 있었습니다.
Daniel(K)