on-premise 데이터 동기화 배포 시나리오·최종 기술지원

배경

제품 데이터는 중앙 운영 DB에서 만들어지고 고객사는 이 데이터를 자사 인프라 안에서 직접 운영해야 합니다. 운영 DB의 replica를 직접 제공·연결하는 방식은 고객사 보안 정책상 허용되기 어려워 고객사 내부에 DB를 두고 초기 백업본 + 바이너리 로그 변경분으로 동기화하는 별도 구조가 필요했습니다.

• 고객사마다 네트워크·보안·운영 정책이 달라 설치 형상과 구성 시나리오가 환경별로 상이
• 외부 replica 연결 대신 고객사 내부에서 운영되는 구조라, 문제가 생기면 원격 진단·재현 분석이 필요

한 일

• 환경별 배포 시나리오 설계·리뷰 — 고객사 환경 제약에 맞춰 기본·파일 검수·시간 제한·폐쇄망·중계 경로 구성을 나누고 기술지원팀의 배포 기준으로 이관
• 배포 형상 기준 정리 — 고객사별 DB 백업본 버전 · 동기화 모듈/프록시 버전 · 설치일을 비교할 수 있도록 관리 기준을 정리
• 기술지원팀 이관 이슈 대응 — 기술지원팀이나 외주가 1차로 해결하지 못하는 DB · 바이너리 로그 기반 동기화 · 동기화/정합성 · 네트워크 이슈를 시스템 담당자로서 직접 진단·해결
• 고객사 현안 대응 — 업로드/반영 실패, 동기화 지연, TLS·네트워크 오류, 분석 결과 오탐처럼 제품 데이터와 고객사 환경이 만나는 지점의 문제를 로그·DB 상태·배포 형상까지 연결해 추적
• 지원 표준화 — 설치 가이드 · 배포 시나리오 · 신규 고객사 등록 절차를 문서화해 지원을 표준화하고 신규 담당자 온보딩을 지원
• 파일 검수 구성 수정 (2026-09) — 증권사 고객사가 중간 서버에서 파일을 검사한 뒤 내부 서버로 넘기는 구성에서, 중간 다운로드 서버가 저장된 암호화 파일을 인식하지 못해 전달이 실패했습니다. 고객사 서버에 암호화 도구를 설치하는 대신 다운로드 서버와 동기화 모듈에 전송 구간 암·복호화를 끄는 설정을 짝으로 두어 저장 파일을 그대로 서빙하게 했습니다. 한쪽만 바꾸면 무결성 검사에서 바로 실패하도록 두었고, 기본값은 둘 다 켜짐이라 기존 고객사에는 영향이 없습니다.
• 4.2.0: MySQL을 배포 이미지에서 분리 (2026-09-18) — 공공기관 취약점 점검에서 동봉된 MySQL 8.4.0이 미패치로 지적됐습니다. MySQL 버전업은 운영 업무라는 방향에 맞춰 이미지를 다운로드 서버와 동기화 모듈 전용으로 줄이고 MySQL은 별도 이미지로 두어, 이후 MySQL 패치를 릴리스와 무관하게 올릴 수 있게 했습니다. 이미지는 669MB → 162MB로 줄었습니다. 다운로드 서버 단위 테스트 14개와 이미지 스모크 테스트 26개를 추가했고, 모든 다운로드가 실패해도 종료 코드 0으로 끝나던 문제를 함께 고쳤습니다.

역할

데이터 동기화 체계의 설계·구현과 배포 시나리오 리뷰까지 맡아 기술지원팀에 이관했습니다. 고객사 배포와 상시 운영은 기술지원팀이 담당하고, 저는 운영 중 전달받은 DB·동기화·정합성·네트워크 이슈를 재현하고 코드를 개선하는 최종 기술지원 역할을 맡았습니다. 2026년부터는 전환 작업과 지원 기준 정리를 함께 이끌었고, 9월의 파일 검수 구성 수정과 MySQL 분리 릴리스도 직접 만들어 전달했습니다.

관련: 이슈 트래킹 & 장애 추적 체계