배치 기반 계정 동기화 구조 설계 사례: 실시간 연동 없는 환경에서 정합성 유지하기

📌 개요

실시간 API 연동이 불가능하고, DB 접근 권한도 제한된 환경에서
어떻게 계정 데이터를 정확성 있게 동기화할 수 있을까?

이 글은 실제 현역에서 경험한 사례를 바탕으로,
플래그 기반 매핑 테이블 + 주기적 배치 + 긴급 대응 루틴을 통해
문제를 해결한 구조를 정리한 글이다.

---

🔍 문제 상황

• 고객 시스템과 자사 시스템 간 계정 정보 동기화 필요
• 실시간 API 미제공, 고객 DB에 직접 접근도 불가능
• 변경 데이터만 안전하게 반영하는 구조 필요

---

🧩 설계 구조 요약

📁 고객 시스템(트리거)

• 계정 변경 발생 시, 매핑 테이블에 변경된 데이터 + 상태 플래그 기록

🖥 자사 시스템(폴링)

• 일일 주기로 매핑 테이블 폴링
• 플래그가 활성화된 데이터만 반영
• 반영 완료 후, 상태 플래그 초기화

---

⚙️ 주요 설계 고려사항

✅ 1. 중복/누락 방지를 위한 상태 전이 로직

• 상태값: 플래그
• 동기화 시점 기준으로 처리 시점 기록
• 처리 완료 시 상태값 변경

✅ 2. 단일 프로세스 환경 + 업무 시간 분리

• 동기화는 새벽 시간대에만 실행
• 업무 시간 내 계정 변경 작업과 물리적으로 분리 → Race Condition 방지

✅ 3. 장애 대응 구조

• 긴급 동기화가 필요한 경우 → 고객 측에서 GUI 실행 툴로 수동 실행
• 실패 시 이력 기록 + 자동 재시도 (5분)

---

🤔 왜 실시간 메시지 구조가 아닌가?

• 고객 시스템에는 모니터링 체계도 없고, 메시지 브로커 등 인프라 비용이 크며
• 최소 인프라 환경에서 가장 안정적인 방식을 추구

---

💬 Q&A

Q. Race Condition은 어떻게 방지하나요?

A. 계정 ID + 상태값 기반 상태 전이 전이 로직(상태가 다른 상태로 바뀌는 과정을 제어하는 로직)으로 동시 처리 방지.

새벽 시간대에만 동기화 처리되고 시간상 충돌 가능성도 없음.

Q. 긴급 상황에는 어떻게 처리하나요?

A. 스크립트 실행 도구를 고객에 제공, 고객사 GUI 툴로 단일 배치를 수동 트리거함.

실패 시 자동 리트라이 루틴으로 복원됨.

Q. 메시지 구조가 아니라 배치를 선택한 이유가 무엇인가요?

A. 고객 시스템 인프라 한계로 MQ나 webhook 방식 적용 불가.

대신 플래그 기반 동기화 + 배치 주기 조절로 충분히 안정적인 구조 구성.

 

---

🧐 기술 포인트 요약

기술 요소	적용 전략
데이터 정확성	상태 플래그 + 매핑 테이블 기반 처리
동시성 문제	업무시간/처리시간 분리, 단일 프로세스
장애 복원	수동 실행 + 자동 리트라이(5분)
성능 고려	DB 랩/로그 누적 방지, 최소 I/O 구조
확장성 대안	메시지 큐 미적용 → 인프라 간소화 유지

 

---

🚀 마무리

기술적 제약이 많은 환경에서도
폴링 기반 구조 + 상태 기반 동기화 설계만 잘해도
충돌 없고 신뢰성 있는 계정 통합이 가능하다.

언젠가는 메시지 기반 구조로 전환할 수도 있겠지만,
지금은 "할 수 있는 자원으로 최적의 안정성"을 만드는 것이 핵심

---

🧩 적용 이후 발견된 문제점 및 개선 방향

⚠️ 리트라이 주기 개선

• 고정 주기 리트라이는 반복 부하를 유발함
• 지수적 증가 간격(5→10→20분)을 적용하여 서버 부하를 점진적으로 줄이는 방향으로 전환

⚠️ 롤백 시 DB 부하에 대한 대안 검토

• 롱런 트랜잭션에서 발생하는 DB 락/Undo 로그 누적 등의 부하 문제
• 대안 1: Savepoint 기반 복원, 단점은 I/O 병목 및 DBMS 의존도
• 대안 2: 청킹(Chunking) + 실패 청크만 리트라이 방식으로 장애 범위 최소화
  • 다음번에 적용한다면 의존도를 줄이고 앱 내에서 처리하기 위해 대안2를 선택할 것이다.