🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개) · 출처: Jira/Confluence 수집물 2026-04
0한눈에
- 대상: 운영 DB binlog → 고객사 환경 전송 경로(Binlog shipping service), 다운로드 모니터링 사이트.
- 버전:
Binlog shipping service v3 → v4.0.0 (2026-04 릴리스), 모니터링 사이트 v1 → v2(구축 완료).
- 핵심 변경: 2024년 적용한 스크램블링(난독화)을 정식 암호화로 전환.
1왜 했나
기존 binlog 전송은 2024년에 적용한 스크램블링(난독화) 방식으로만 보호되고 있었다. 난독화는 평문 노출을 막아주긴 하지만 정식 암호화에 비해 보안 보장이 약하다. 고객사 환경으로 데이터가 나가는 경로이므로, 전송 구간을 정식 암호화로 전환해 보안을 강화하는 것이 목표였다.
난독화는 "읽기 어렵게"이고, 정식 암호화는 "키 없이는 못 읽음"이다. v4의 핵심은 이 보호 등급을 한 단계 올린 것.
2전송 경로
운영 DB(lab-master)에서 추출한 binlog가 분산(dist)을 거쳐 고객사 환경(gath)으로 전달된다. v4에서는 이 전송 구간의 페이로드가 정식 암호화 상태로 이동한다.
- 운영 DB(
lab-master)에서 binlog 추출
- 전송 데이터 정식 암호화 — AES-256-GCM(기밀성 + 무결성 Tag 검증). 키는 빌드 시 임베딩. (기존 스크램블링 대체)
- 분산 노드(
dist) → 고객사 환경(gath)으로 전송
- 고객사 측에서 binlog → SQL 변환(Custom Parser) 후 upsert로 적용해 중복 적용 에러를 제거하고, 실패 시 트랜잭션 재시도. DB 접속 계정 정보도 암호화.
- 고객사 다운로드 상태를 모니터링 사이트 v2에서 가시화
3모니터링 v2
- 고객사 binlog 다운로드 상태를 보는 모니터링 사이트 v2 구축 완료.
- 산출물: 설계 문서 · 아키텍처 · 런북(runbook) · 배포 시나리오를 모두 문서화.
- 온보딩 시 런북·배포 시나리오 문서를 먼저 확인하면 운영/장애 대응 흐름을 빠르게 파악 가능.
4온보딩 포인트
- Binlog shipping service는 운영 DB → 배포 노드 → 고객사 환경 경로. binlog 전송 구간은 v4부터 정식 암호화 상태.
- "스크램블링 = 난독화(2024)", "정식 암호화 = v4(2026)" — 두 용어를 혼동하지 말 것.
- 역할: 본 작업은 2026-01 데이터파트 파트리더 취임 후 파트리더로서 주도. (2026 이전 binlog 난독화 작업은 데이터 엔지니어 시절 작업)
5공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/binlog-shipping-encryption.html)은 내부 서비스명·호스트명·내부 컴포넌트명·고객사명을 일반 용어("바이너리 로그 쉬핑 서비스", "고객사 환경", "분산 노드")로 치환하고, 문제·접근·임팩트 중심으로 일반화했다. 이 내부 문서는 본인 참고/온보딩용으로 내부 식별자를 유지한다.
🔄 바이너리 로그 동기화 시리즈 ③ — ① 스크램블링 · ② 모니터링·로그 수집기 · ③ 암호화 전환 · ④ 모니터링 v2