핀테크 핸드북, 실무 적용 가능성은?
핀테크 엔지니어링 핸드북의 금전 데이터 처리 방식에 대한 비판이 제기됨
정수형 저장(Integer Storage)과 문자열 기반 API(String-based API)의 장단점 및 데이터 격리 아키텍처(Data Isolation Architecture) 적용 논쟁
이벤트 소싱(Event Sourcing)의 핵심 로직 적용 범위와 데이터 불변성(Data Immutability) 확보 방안에 대한 토론
핸드북 내용의 LLM 작성 의혹과 함께 실제 법규 및 컴플라이언스 준수 중요성이 강조됨
금전 데이터 정밀도 문제: 정수형 vs 문자열
커뮤니티에서는 금전 데이터를 JSON float으로 저장하는 것에 대한 강한 비판이 제기되었습니다. 특히 Rust의 `Decimal` 타입이 내부적으로 float으로 표현될 경우 발생하는 정밀도 손실 문제를 지적하며, 정수형(Integer) 기반 저장을 강력히 권고합니다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 핵심 금융 데이터를 안전하게 관리하는 것과 맥락을 같이 합니다. 다만, 문자열(String) 타입을 API 교환 형식으로 사용하는 것이 정밀도 손실 문제를 근본적으로 해결할 수 있다는 대안도 제시되었습니다.
이벤트 소싱(Event Sourcing) 적용 범위와 불변성
금전 데이터의 불변성(Immutability) 확보를 위해 이벤트 소싱이 언급되었으나, 모든 서비스에 적용하는 것은 과도하다는 의견이 지배적입니다. 핵심 로직(원장, 결제, 주문 등)에만 적용하고, 데이터 불변성(Data Immutability)은 이벤트 기반 기록(Event-based Records)이나 변경 불가능한 감사 추적(Immutable Audit Trail)으로도 달성 가능하다고 설명합니다. 또한, 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 개인 식별 정보(PII)와 금융 데이터를 분리하여 규제 준수와 데이터 보존 의무를 동시에 만족시키는 방안도 논의되었습니다.
JSON 숫자 파싱 및 API 설계의 함정
JSON API에서 숫자를 다룰 때, 언어나 파서가 내부적으로 float으로 변환하면서 발생하는 정밀도 손실 위험이 지적되었습니다. 이를 방지하기 위해 문자열(String) 타입 사용을 제안하며, 이는 데이터 미저장 정책(Zero-Retention Policy)과는 별개로 API 교환 형식에서의 데이터 무결성을 보장하는 방법으로 설명됩니다. 일부에서는 이를 안티패턴으로 간주하지만, 실제 서비스에서는 사용자나 주주를 위해 실용적인 접근이 필요하다는 의견이 나왔습니다.
핸드북 신뢰성 및 규제 준수 문제
핸드북 내용이 LLM에 의해 작성되었을 가능성이 제기되며, 특히 PII와 금융 데이터를 분리하여 보관하는 내용이 KYC/AML 규정에 위배될 수 있다는 비판이 있었습니다. 금융 기관은 반드시 해당 운영 지역의 법률 및 규제를 준수해야 하며, 내부 핸드북과 법률/컴플라이언스 팀의 검토를 거친 가이드라인을 따라야 함을 강조합니다. 이는 GDPR 규제 준수(GDPR Compliance)와 같은 국제적 규제 환경에서도 중요한 고려사항입니다.
