바이너리 로그 기반 데이터 동기화 암호화 전환
외부에서 제공되는 replica 연결을 허용하기 어려운 고객사 환경에 바이너리 로그 변경분을 전달하는 데이터 동기화 체계를 개선했습니다. 난독화 수준이던 보호 방식을 정식 암호화로 전환해 전송 구간 보안을 강화했습니다.
0작업자의 메모
난독화는 “눈에 안 보이게” 만드는 수준이고 고객사 동기화 경로에서 필요한 것은 기밀성과 무결성을 설명할 수 있는 암호화였습니다. 그래서 AES-256-GCM 전환은 기능 개선보다 책임 경계를 분명히 하는 작업에 가까웠습니다.
전송 방식만 바꾸면 운영자는 여전히 답답합니다. 다운로드 상태와 실패 지점을 같이 볼 수 있게 만든 이유는 장애가 생겼을 때 보안과 운영을 따로 보지 않기 위해서였습니다.
1배경
제품 데이터는 고객사 내부 DB가 초기 백업본을 보유하고, 운영 DB의 바이너리 로그 변경분을 받아 반영하는 경로로 동기화됩니다. 이 구조는 외부 replica 연결을 두기 어려운 보안 제약 때문에 필요했고 이전 버전에서는 전송 데이터를 스크램블링(난독화) 방식으로만 보호하고 있어 전송 구간 보안 수준을 더 끌어올릴 필요가 있었습니다.
- 난독화는 가독성을 낮출 뿐 정식 암호화에 비해 보안 보장이 약함
- 고객사 환경으로 데이터가 나가는 경로이므로 전송 구간 보안이 핵심 요구사항
- 전송과 함께 고객사 측 다운로드 상태의 가시성도 부족했음
A아키텍처 (전체 시스템)
운영망의 바이너리 로그를 버전 라우팅 프록시로 제공하고 암호화 전송 후 고객사에서 복호화·SQL 변환해 반영. 배포 모드(직접/프록시/파일검수/폐쇄망)는 고객사 환경에 맞춰 선택.
2접근
바이너리 로그 기반 데이터 동기화 체계를 개선하면서 보호 방식을 난독화 → 정식 암호화로 전환했습니다. 동시에 고객사 측 다운로드 상태 모니터링을 새로 구축하고 설계·아키텍처·런북·배포 시나리오를 문서화해 운영 가능한 형태로 마무리했습니다.
- 전송 암호화는 표준 알고리즘 AES-256-GCM을 채택해 기밀성과 무결성(Tag 검증)을 동시에 보장
- 암·복호화 키는 코드에 두지 않고 빌드 시 임베딩하며, DB 접속 계정 정보도 암호화해 자격 증명 노출을 차단
- 단순히 binlog 전체를 그대로 적용하던 방식에서, binlog→SQL 변환(Custom Parser) + upsert 변환으로 바꿔 중복 적용 에러를 제거
- 적용 실패 시 트랜잭션 재시도 메커니즘으로 일시적 오류에 견디도록 보강
3결과
4역할
데이터 엔지니어로서 바이너리 로그 기반 데이터 동기화 체계의 암호화 전환과 모니터링을 기획·설계·구현하고 배포 시나리오 리뷰를 마친 뒤 기술지원팀에 이관했습니다. 이후 운영에서 접수된 이슈를 재현·개선하며 고객사 환경으로 나가는 데이터의 보안과 가시성을 지원했습니다.
이전 단계의 난독화 적용은 별도 항목으로 정리.
🔄 바이너리 로그 동기화 시리즈 ③ — ① 스크램블링 · ② 모니터링·로그 수집기 · ④ 고객사 동기화 모니터링 v2