2025년 1월 정보들

링크 : https://pomb.us/build-your-own-react/

예전에 보았던 블로그를 다시한번 읽어보게되었다. 리액트를 실무에서 사용한 적 없지만 재미있게 읽었다. 프론트엔드 시장에서 한 획을 그은 리액트의 코어로직에 대해서 많이 알게 되었다.

링크 : https://xtdb.com/blog/challenge-of-data-compliance

개인정보 데이터 관리와 규정 준수에 관한 내용을 간단히 설명드리겠습니다:

1. 규정 준수 현황
2. 개인정보 보호 법률이 매년 강화됨
3. 국가/지역별 상이한 규정으로 관리가 복잡
4. 데이터 유출 시 재정적 손실과 평판 하락 발생
5. 기존 데이터베이스의 문제점
6. 전통적 데이터베이스는 업데이트 시 이전 데이터 삭제
7. 과거 높은 저장비용으로 인한 제한적 설계
8. 시계열 데이터 추적 어려움
9. 다양한 데이터베이스 솔루션
10. MVCC: 임시 버전 관리
11. RDF: 이전 데이터 보존
12. 시계열 DB: 실시간 데이터 특화
13. 데이터 웨어하우스: 제한적 이력 조회
14. Bi-temporal 데이터베이스 장점
15. 전체 데이터 버전 날짜별 저장
16. 특정 시점 데이터 확인 가능
17. 감사/분쟁 해결에 효과적

링크 : https://xtdb.com/blog/retire-crud

CRUD의 Update와 Delete 작업은 데이터를 영구히 삭제하거나 변경하여 과거 데이터 추적이 불가능한 문제가 있다. 이를 해결하기 위해 업계는 타임스탬프와 삭제 플래그 방식을 도입했으나, 시스템 복잡도가 증가하고 JOIN 작업에서 어려움이 발생했다. 이후 데이터베이스 엔진 차원에서 이력을 자동 관리하는 Temporal Tables가 등장했지만, 이는 데이터의 유효 시점만 추적할 수 있었다. 최근에는 데이터의 유효 시점과 변경 시점을 모두 추적할 수 있는 Bitemporal 데이터베이스가 등장하여 운영 쿼리는 물론 과거 데이터 조회, 규정 준수까지 효과적으로 지원하고 있다.

CRUD의 한계와 대안

1. CRUD의 문제점
2. Update와 Delete로 인한 데이터 영구 삭제/변경
3. 규정 준수와 감사 요건 충족 어려움
4. 과거 시점의 데이터 조회 불가능
   • 예: 특정 시점의 주식 가격
   • 예: 계정 해지 전 고객의 서비스 이용 내역

## 2. 초기 해결방안 ### 2.1 타임스탬프 방식

• 업데이트 시 새로운 레코드 삽입
• 시간 정보 컬럼 추가
• 최신값 확인을 위한 추가 로직 필요

### 2.2 삭제 플래그 방식

• 실제 DELETE 대신 플래그 사용
• 별도의 테이블로 삭제 기록 관리
• JOIN 작업 시 복잡도 증가

## 3. 진보된 해결방안 ### 3.1 Temporal Tables

• 데이터베이스 엔진 차원의 지원
• 자동 이력 관리
• 히스토리 테이블 자동 관리
• 유효 시간만 추적 가능

### 3.2 Bitemporal 데이터베이스

• 두 가지 시간 추적
  • Valid Time: 데이터 유효 시점
  • Transaction Time: 데이터 변경 시점
• 운영 쿼리 정상 수행
• 과거 데이터 조회 용이
• 비즈니스/규정준수/감사 요구사항 충족

이러한 계층적 발전을 통해 데이터 관리는 더욱 정교해지고 있다.

Clojure 로 간단하게 Redis 를 만들어보는 프로젝트. core.async , atom 을 사용한다. 점진적으로 개선해 가는 것으로 길을 잃지 않게 만들었다.