Dayner에서 구매 이력을 관리하는 방법 [1] (feat: 개인정보보호법, 원장 데이터)

 

개요

Dayner에서는 기프트카드와 쿠폰, 앞으로 추가될 포장 주문과 관련된 결제 데이터를 관리하기 위해 구매 이력 관리 방식을 철저히 설계하고 있다.

 

이러한 설계는 기능적으로는 사용자의 데이터 보호와 개인정보보호법 내부의

전자상거래 등에서의 소비자보호에 관한 법률 시행령 ( 약칭: 전자상거래법 시행령 )에 부합하도록 설계를 진행하였다.

 

비기능적으로는 결제 내역의 보관과 관리 방식은 '원장 테이블'의 개념을 적용하여 데이터의 무결성과 신뢰성을 확보해보고자 하였는데

국가법령정보센터 | 연계정보

 

 

이번 포스팅에서는 기능적 요구와 원장/거래 데이터를 따로 관리하는 전략을 왜 선정하게 되었는지 알아보자!

---

개인정보처리방침 관점의 기능적 설계 분석

 

 

 

클라이언트(Dayner 사업주)의 법률대리인에 의해 요청 받은 기능에 의하면 제 6조에 의거하여 모든 회원이 웹사이트 내에 존재하는 서비스를 통해 거래한 유/무형의 대금 결제에 대해서는 빠짐없이 기록을 해야한다고 한다.

 

또한 추가적으로 대부분의 웹서비스에서는 원장 데이터라고 따로 두어 관리를 하기에 가능하다면 그렇게 구현하는게 좋을것 같다고 추천받았다.

 

또한 열람-보존 방법을 확인해보면

6조 세부조항 1항

따라서

 1. 결제 내역을 거래발생일과 함께 데이터베이스에 저장/보존 해야한다.

 

앗,, 그리고 당사자(소비자)가 요청하면 데이터를 제공해줘야한다.

따로 저작물이 없기 때문에 따로 문서화도 할수 있어야한다.

6조 세부조항 2항

 

2. 결제 내역을 회원 별로 조회 할수도 있어야한다.

 

 

 개인정보 이용동의 철회 시에는 별도 보존을 해줘야한다.

 

3. 회원의 회원 가입 여부(개인정보 동의 기준) 에 따라서 데이터를 분리하여 관리하여야 한다. 

 

 

포장주문의 경우에는 상관이 없지만 기프트카드, 쿠폰은 선물에 의해 비회원도 사용이 가능하기에 따로 타입을 만들어서 분리 해줘야한다. 

 

 

 

---

 

Dayner의 데이터 관리 전략: 원장 테이블 개념의 적용

 

발생되는 데이터를 관리/저장하는 전략으로 전통적인 금융 원장 테이블의 개념을 차용하였는데 자문에 따르면 원장 테이블은 중요한 정보를 신뢰성 있게 보관하고, 필요 시 언제든지 참고할 수 있는 기준이 되는 테이블이라고 한다.

• 효율성
  PaymentArchive로 데이터를 이동함으로써, 결제 내역 테이블의 크기를 관리하고 성능을 최적화할 수 있다.
  특히 결제수단-결제 내역 형태의 테이블의 경우에는 join이 발생하여 조회시 성능 이슈가 발생 하는데, join 연산이 어느정도 비정규화로 인해 해소 되기 때문에 효율적이다.
  
  
• 안정성
  어느정도의 중복을 허용하는 방식으로 인해서 저장비용이 조금 늘게 되겠지만 데이터 보관은 안정적으로 수행할 수 있다고 한다.
  
  
• 법적 요구사항 준수
  개인정보보호법과 금융상거래법에 따라 필요한 기간 동안 데이터를 보관하며, 데이터의 무결성을 유지하도록 설계되었다.
  결제 관련 데이터는 최소 5년간 저장되게 하였다.

---

 

Dayner의 데이터 관리 방식:  원장 데이터인 PaymentArchive와 결제 내역 테이블

따라서 위의 기능적 요청과 비기능적 특성에 의해서 결제 이력을 두 개의 테이블로 나누어 관리한다.

 

• 결제 내역 테이블 (Transaction Table)
  • 이 테이블은 실시간으로 사용자가 결제 내역을 확인할 수 있도록 최신 데이터를 유지한다.
  • 사용자가 결제를 진행하면, 해당 데이터는 이 테이블에 기록되고, 사용자는 언제든지 자신의 결제 내역을 조회할 수 있다.
    
    
• 결제 데이터 보관 테이블 (PaymentArchive)
  • 일정 기간이 지나거나 발생된 데이터는 결제 내역 테이블에서 PaymentArchive로 이동하여 장기 보관된다(즉시 저장되지 않아도된다. 딜레이가 존재).
  • 과거 결제 내역을 안전하게 보관하며, 분쟁 발생 시 증거로 사용할 수 있다.
  • 접근 빈도가 낮은 데이터를 저장하는 효율성을 최적화하는 방식으로 설계되었으며, 중복된 데이터의 일부도 허용하여 보관한다. 

 

---

 

인프라: 보안적 측면

화살표의 방향을 보면 이해가 쉽다!

 

• 암호화
  결제 관련 데이터는 접근이 제한된 상황에서만 사용되며, 데이터베이스 서버는 Spring 애플리케이션이 실행되는 서버와 독립적으로 구성되어 있어 직접 조회가 불가능하다.
  
  
• 접근 통제
  PaymentArchive 테이블은 AWS IAM 최상위 권한을 가진 계정만이 접근할 수 있으며, 일반 개발자나 애플리케이션 어드민 계정도 접근이 불가능하도록 설정되어 있다.
  최소한의 권한으로만 접근할 수 있는 정책을 통해 데이터 보안을 강화해두었다.
  
  
• 데이터 파기
  보관 기간이 지난 결제 데이터는 매월 진행되는 정산 과정에서 삭제하거나 비식별화 처리하여, 개인정보보호법의 요구사항을 충족시키고 있다. 

 

---

 

마무리

결론적으로는 결제 데이터를 안전하게 관리하기 위해,

  기능적으로는 개인정보보호법과 금융상거래법을 준수하는 데이터 관리 전략을 채택하고 있고

  비기능적으로는 원장/거래 데이터의 별도 관리를 통해 사용자는 자신의 결제 내역을 신속하게 확인할 수 있고, 관리자는 결제 데이터를 효율적으로 관리할수 있다.

 

 

현재의 결제 데이터는 약 5,000건에서 10,000건 정도가 존재하지만, 향후 결제 내역이 증가할 경우 적절한 인덱싱을 통해 추가적인 성능 향상을 기대할 수 있을것 같다.

 

 

다음 포스팅으로는 그래서 여러 결제 관련 엔티티에서 하나의 원장 데이터(PaymentArchive)로 어떻게 변환해서 저장을 하게 되었는지 코드와 함께 알아보자!