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