중앙 운영 DB의 변경분(바이너리 로그)이 복제·고객사 on-premise로 전달되는 동기화 경로에서, 로그를 스크램블링(난독화)해 전송 중 데이터가 그대로 노출되지 않도록 보호
스크램블링은 완성된 보안 설계라기보다, 고객사로 나가는 변경 로그가 그대로 노출되는 위험을 먼저 줄인 단계였습니다. 운영 중인 동기화 경로를 한 번에 크게 바꾸기 어려울 때 선택한 현실적인 개선이었습니다.
이후 암호화 전환 작업으로 이어졌기 때문에, 이 페이지는 최종 형태보다 보안 수준을 단계적으로 끌어올린 흐름 안에서 보는 편이 맞습니다.
제품 데이터는 primary → replica(분산) → 고객사 on-premise 로 바이너리 로그 기반 동기화로 전파됩니다. 바이너리 로그는 모든 데이터 변경을 담는 매개체라, 전송 중 내용이 그대로 노출되는 것을 막을 필요가 있었습니다.
데이터 엔지니어로서 스크램블링 적용과 동기화 경로 복원 검증을 단독으로 수행했습니다. 운영·고객사 환경 모두에 영향을 주는 변경이라 호환성과 무중단 적용을 우선했습니다.
같은 해 MySQL 8.0→8.4 LTS 업그레이드, DB 아키텍처 인스턴스 분리와 함께 진행한 DB 플랫폼 개선 작업의 일부. 전송 데이터의 정식 암호화는 후속 데이터 동기화 개선에서 별도로 도입.
🔄 바이너리 로그 동기화 시리즈 ① — 이어지는 작업: ② 모니터링·로그 수집기 · ③ 암호화 전환 · ④ 고객사 동기화 모니터링 v2