논리적 복제 vs 배치 ETL: 동기화 방식 선택하기

우리가 “데이터를 동기화”할 때 해결하려는 문제는 무엇인가요?

팀들은 작업이 한 곳에서만 일어나지 않기 때문에 데이터를 시스템 간 복사합니다. 영업은 CRM에, 결제는 청구 시스템에, 운영은 내부 대시보드에 있을 수 있습니다. 지원팀은 도구를 오가며 확인하지 않고 전체 상황을 알아야 하고, 리더들은 실제 발생한 일과 일치하는 리포트를 원합니다.

“신뢰할 수 있는 동기화”는 설명은 쉽지만 유지하긴 어렵습니다: 올바른 레코드가 도착하고, 중요한 항목이 빠지지 않으며, 업데이트는 유용할 만큼 충분히 빠르게 반영됩니다. ‘충분히 빠름’은 경우에 따라 다릅니다. 사기 검증은 몇 분 내가 필요할 수 있고, 월간 재무 보고서는 몇 시간이 허용될 수 있습니다.

동기화가 잘못되면 보통 누락된 레코드, 중복, 오래된 필드, 부분적 업데이트(예: 주문 헤더만 있고 라인 아이템이 없는 경우)처럼 보입니다.

유용한 사고 모델은 이벤트 vs 스냅샷입니다.

이벤트는 개별 변경입니다: “주문 #1842가 생성됨”, “상태가 배송으로 변경됨”, “환불 발생”. 변경-데이터 접근 방식은 이벤트를 옮기는 경향이 있어 준실시간 동작을 지원할 수 있습니다.

스냅샷은 예약된 복사입니다: “매일 밤 어제 주문을 복사”. 배치 ETL은 보통 이런 식으로 작동합니다. 더 단순할 수 있지만 데이터는 덜 최신입니다.

논리적 복제 대 배치 ETL에 관한 대부분의 논쟁은 사실상 이 선택에 관한 것입니다: 지속적인 이벤트가 필요한가, 아니면 주기적 스냅샷으로 사람들이 보는 것을 신뢰시킬 수 있는가?

논리적 복제와 배치 ETL, 간단히 설명

논리적 복제는 원본 데이터베이스가 변경이 발생할 때 스트림으로 전송한다는 뜻입니다. 전체 테이블을 복사하는 대신 “행이 추가됨”, “행이 업데이트됨”, “행이 삭제됨” 같은 변화를 발행합니다. 대상은 그 변경을 순서대로 적용해 원본과 밀접하게 정렬됩니다.

배치 ETL은 스케줄에 따라 스냅샷을 가져옵니다. 작업은 데이터를 추출(종종 “마지막 실행 이후의 모든 것”)하고 필요하면 변환한 뒤 대상에 로드합니다. 복제는 실시간 업데이트 같은 느낌이고, 배치 ETL은 매시간(또는 매일 밤) 체크인해서 따라잡는 느낌입니다.

보통 둘은 다른 위치에서 실행됩니다. 복제는 데이터베이스 변경 로그에 가깝게 지속적으로 실행됩니다. 배치 ETL은 정해진 시간에 실행되고 멈췄다가 다시 실행되는 잡입니다.

어떤 방식이든 동일한 신뢰 질문에 답해야 합니다:

• 삭제는 어떻게 표현되어 대상에 ‘유령’ 행이 남지 않게 하는가?
• 같은 변경이 두 번 도착하면 어떻게 처리하는가(멱등성)?
• 많은 행이 빠르게 변경될 때 순서를 어떻게 유지하는가?
• 재시작이나 재배포 중에 변경이 누락되지 않게 하려면?
• 단순히 “작업이 성공했다”가 아니라 간극을 어떻게 감지하는가?

예: 주문이 생성되고 상태가 ‘대기’에서 ‘결제됨’으로 바뀌고 나중에 환불되는 경우, 복제는 세 개의 변경 이벤트를 보냅니다. 일일 스냅샷은 중간 상태를 보존하도록 배치 프로세스를 설계하지 않으면 최종 상태만 캡처할 수 있습니다.

최신성과 지연: 실시간에 얼마나 가까워야 하나?

복제와 배치 ETL을 비교하기 전에 비즈니스 관점에서 ‘충분히 최신’이 무엇인지 정의하세요. 숫자로 시작하세요: “지원팀은 최대 5분 전 데이터로 작업할 수 있다” 또는 “재무팀은 어제 집계로 충분하다”.

최신성은 누군가가 데이터를 사용할 때의 데이터 연령입니다. 지연은 원본의 변경이 대상에 반영될 때까지의 지연입니다. 동기화가 자주 멈추면 평균 지연이 낮아도 여전히 ‘오래된’ 데이터가 될 수 있습니다.

지연은 어디서 오나

간단한 동기화도 캡처(변경을 감지하는 시점), 전송(데이터 이동), 처리(변환 및 중복 제거), 적용(대상에 쓰고 인덱싱) 등 여러 지연을 쌓습니다.

지속적인 소량 흐름(복제나 빈번한 마이크로배치)은 더 부드러운 최신성을 제공하지만 하루 종일 동기화를 운영해야 합니다. 예약된 배치는 이해하기 쉽지만 스파이크를 만듭니다: 예를 들어 새벽 2시에 큰 부하가 몰리고 다음 실행 전까지 데이터는 오래됩니다.

준실시간은 사람들이 빠르게 결정을 내리거나 고객이 결과를 바로 보는 경우에 도움이 됩니다. 지원 대시보드는 새 주문을 빠르게 보여줘서 상담원이 품절인 상품을 약속하지 않도록 해야 합니다. 반면 주요 사용이 주간 보고서나 월별 청구라면 모든 작은 업데이트를 즉시 반영하는 것은 복잡성만 늘릴 뿐 결과를 개선하지 못합니다.

실용적인 판단 기준:

• 동기화된 데이터를 누가 사용하며 어떤 결정을 내리는가?
• 데이터가 15분 오래되면 무엇이 깨지는가?
• 지속적으로 운영하는데 드는 비용(인프라와 온콜 시간)은 얼마인가?
• 대상이 가장 한가한 시간은 언제인가?
• 어떤 최신성을 약속하고(그리고 커뮤니케이션할 것인가)?

실패 복구: 무언가 고장났을 때 올바른 상태로 되돌리는 방법

동기화는 드물게 극적인 방식으로 실패합니다. 보통 작은 일상적 문제로 실패합니다: 서버 재시작, 네트워크 문제로 연결 끊김, 또는 로드 중 작업이 크래시. 목표는 ‘절대 실패하지 않음’이 아니라 ‘올바른 최종 상태로 복구함’입니다.

일반적 실패 모드에는 원본 장애, 대상 장애, 처리 중 작업 충돌, 제약 조건을 위반하는 나쁜 데이터 등이 있습니다.

논리적 복제에서는 보통 저장된 위치(대개 로그 오프셋)부터 변경을 재생함으로써 복구합니다. 대상이 다운되면 변경은 쌓였다가 복구 시 순서대로 적용됩니다. 긴 장애 동안 복제 슬롯(또는 동등한 것)이 무한히 커지지 않도록 관리하는 것이 중요합니다.

배치 ETL에서는 보통 시간 창을 다시 실행하는 방식으로 복구합니다(예: “어제 재적재” 또는 “지난 2시간 재적재”). 운영적으로는 간단한 경우가 많지만 로직이 두 번 실행되어도 안전해야 합니다.

가장 큰 신뢰 깨짐은 부분 쓰기입니다. 배치가 70% 쓰여진 뒤 크래시가 나면 중복이나 누락이 생길 수 있으니 계획이 필요합니다. 두 스타일 모두에 도움이 되는 패턴:

• 동일 입력을 두 번 적용해도 같은 상태가 되도록 멱등성을 구현하세요.
• 안정적 기본 키로 업서트(upsert)를 선호하세요.
• 성공 커밋 후에만 ‘마지막 처리’ 마커를 옮기세요.
• 거부된 행은 검사하고 재실행할 수 있도록 보관하세요.

백필(backfill)은 고통이 드러나는 곳입니다. 대량의 과거 데이터를 다시 처리해야 할 때 배치 ETL가 유리한 경우가 많습니다. 복제도 백필이 가능하지만 보통 별도의 경로(먼저 스냅샷 복사 후 변경 적용)를 사용하므로 미리 테스트하는 것이 좋습니다.

예: 주문 동기화가 라인 아이템은 썼지만 헤더를 쓰기 전에 충돌했다면, 주문 단위(또는 배치 단위)로 원자적 트랜잭션을 적용하거나 업서트 기반 로드를 사용하면 반쪽짜리 주문이 남지 않습니다.

스키마 진화: 데이터 모델이 바뀌면 어떻게 되나?

스키마 변경은 많은 동기화가 조용히 신뢰를 잃는 지점입니다. 파이프라인은 계속 실행되지만 데이터의 의미가 아래에서 바뀔 수 있습니다. 복제는 데이터베이스 수준에서 깨질 수 있고, ETL은 변환이나 리포트에서 더 늦게 깨지는 경향이 있습니다.

추가적 변경(새 컬럼, 새 테이블, 선택적 필드)은 가장 쉬운 편입니다. 소비자가 이를 ‘추가 항목’으로 취급하고 기본값이 합리적이면 대개 문제없습니다. 함정은 모든 다운스트림 소비자가 새 필드를 인식하거나 어떻게 백필할지 알 거라 가정하는 것입니다.

파괴적 변경(이름 변경, 타입 변경, 컬럼 삭제, 값의 의미 변경)은 위험합니다. 즉시 실패(잡 오류)하거나 서서히 실패(데이터가 들어오지만 잘못됨)할 수 있습니다.

안전하게 진화하는 방법

마이그레이션할 충분한 시간을 두고 변경을 호환 가능하게 유지하세요:

• 스키마나 페이로드에 버전을 붙여(예: v1, v2) 구버전과 신버전이 공존하도록 하세요.
• 구형과 신형 필드가 공존하는 호환 기간을 운영하세요.
• 새로운 형태에 의존하는 로직을 전환하기 전에 백필하세요.
• 아무도 읽지 않는 것을 확인한 뒤에만 필드를 제거하세요.

매핑이 깨지는 곳

실제 고장 대부분은 시스템들 사이의 접착부에서 발생합니다. 예: ETL이 orders와 customers를 customer_id로 조인하는데 이게 client_id로 바뀌면 조인이 모두 널 매치로 바뀌고 여전히 행을 생성할 수 있습니다.

취약한 지점을 주의하세요: 타입 캐스트, 키가 절대 바뀌지 않는다고 가정한 조인, 그리고 “status는 이 값 중 하나” 같은 다운스트림 규칙 등입니다.

보안과 소유권: 누가 무엇을 동기화할 권한이 있나?

보안 질문은 두 접근법에서 비슷하지만 위험은 다른 곳에 드러납니다. 복제는 보통 광범위한 읽기 접근으로 지속적으로 실행됩니다. 배치 ETL은 스케줄에 따라 더 큰 데이터 슬라이스를 한 번에 가져올 수 있습니다. 어떤 경우든 동기화가 할 일을 하기에 충분한 최소 권한을 부여하세요.

사람 계정 대신 전용 서비스 계정을 사용하세요. 필요한 테이블, 컬럼, 뷰에만 읽기 권한을 주고 연결 가능한 위치를 제한하세요. 가능하면 대상이 절대 봐서는 안 되는 데이터를 필터링한 ‘동기화 전용 뷰’를 노출하세요.

민감한 필드는 팀이 깜짝 놀라는 곳입니다. 대상이 레코드 자체는 필요하더라도 모든 필드를 필요로 하진 않을 수 있습니다. 개인 연락처, 결제 정보, 내부 메모 같은 필드를 제외할지, 마스킹할지, 토큰화할지 초기에 결정하세요. 전송 중 암호화하고 비밀은 파이프라인 설정에 두지 말고 적절한 시크릿 스토어에 보관하세요.

소유권은 나중에 끝없는 논쟁을 막습니다:

• 각 필드의 진실 소스를 정하세요(테이블 단위가 아니라 필드 단위로).
• 대상이 쓰기 권한이 있는지(양방향인지 단방향인지)를 정의하세요.
• 충돌을 어떻게 처리할지 결정하세요(최종 쓰기 우선, 대상 편집 무시, 수동 검토 등).
• 대상에 복사된 데이터의 보존 규칙을 정하세요.

감사는 신뢰의 마지막 조각입니다. 누가 데이터를 접근했고, 무엇이 변경되었고, 언제 반영되었는지 답할 수 있어야 합니다. 간단한 관행은 추적 가능한 동기화 실행 ID와 타임스탬프를 함께 전달해 업데이트를 종단간 추적할 수 있게 하는 것입니다.

동기화를 신뢰할 수 있게 유지하려면 무엇을 모니터링해야 하나?

동기화는 평범한 화요일에 무작위로 신뢰할 수 있어야만 유용합니다. 어떤 접근법이든 모니터링은 얼마나 뒤처져 있는지, 얼마나 자주 실패하는지, 숫자가 여전히 말이 되는지 알려줘야 합니다.

일별로 봐야 할 세 가지 건강 신호:

• 지연/래그: 대상이 원본보다 얼마나 뒤처져 있는가
• 오류율: 실패, 재시도, 버려진 행(dead-letter)에 보낸 건수
• 처리량: 분당 처리된 행이나 이벤트 수와 갑작스런 거의 제로로의 하락

그다음 조용한 문제를 잡을 소규모 데이터 품질 체크를 추가하세요. 중요 테이블(주문, 송장, 티켓)을 몇 개 고르고 반복 가능한 방식으로 검증하세요. 예: 어제 원본에 주문이 1,240건 있었다면 대상에 1,180건만 있어서는 안 됩니다.

보통 많은 것을 커버하는 체크:

• 일별(또는 중요한 피드의 경우 시간별) 행 수
• 일치해야 하는 합계(금액 합계, 결제된 주문 수)
• 필수 필드의 널 비율(이메일, 상태, 타임스탬프)
• 키의 고유성(중복 order_id 없음)
• “삭제의 진실”: 취소되거나 삭제된 레코드가 다운스트림에서도 사라지거나 표시되는지

일관성 문제는 종종 간극 속에 숨어 있습니다: 늦게 도착하는 업데이트, 누락된 삭제, 순서가 뒤바뀐 이벤트 등. 가장 오래된 미처리 타임스탬프를 추적하고 주기적으로 레코드를 샘플링해 최신 버전이 존재하는지 확인하세요.

알림은 지루하고 실행 가능하게 유지하세요. 임계값을 설정하고(예: 랙 15분 초과, 오류율 1% 초과, 처리량이 기준보다 10분 이상 낮음) 런북에: 먼저 무엇을 확인할지, 어떻게 안전하게 재생할지, 올바른 상태로 복구했는지 어떻게 확인할지 적어 두세요.

단계별: 올바른 동기화 접근법을 선택하는 방법

데이터를 누가 사용할지 명확히 하세요. 재무 보고서, 지원 대시보드, 자동 가격 규칙은 같은 테이블을 서로 다른 방식으로 사용합니다. 결정이 시간이 중요한 경우 늦은 데이터는 단순히 짜증나는 수준을 넘어 잘못된 결과를 낳습니다.

간단한 의사결정 절차:

1. 명확히 소비자와 그들이 내리는 결정을 이름 붙이세요. 동기화에 의존하는 화면, 리포트, 프로세스를 목록으로 만들고 영향 범위를 적으세요.
2. 감이 아닌 목표를 설정하세요. 최신성(초, 분, 시간), 정확성(허용 가능한 오류 수준), 비용(인프라, 엔지니어링 시간, 운영 부담)을 합의하세요.
3. 목표를 만족하는 가장 단순한 패턴을 선택하세요. 실시간에 가깝고 예측 가능한 변경 캡처가 필요하면 복제를 사용하세요. 몇 분 단위면 마이크로배치를, 보고와 히스토리 재처리가 중요하면 야간 배치를 사용하세요. 하이브리드도 흔합니다.
4. 복구를 계획하세요. 얼마나 과거까지 재생할 수 있는지, 백필을 어떻게 실행할지, 로드가 어떻게 멱등성을 유지하는지 결정하세요.
5. 신뢰 체크와 소유권을 정의하세요. 상태를 증명하는 검증(건수, 합계, 최종 업데이트 시간, 샘플 검사)을 선택하고 누가 알림을 받고 누가 데이터를 고칠지 지정하세요.

구체적 예: 지원팀이 고객과 통화 중 주문 상태가 필요하면 분 단위가 중요하므로 복제나 마이크로배치가 적합합니다. 재무팀이 일일 매출을 필요로 하면 야간 배치로 충분한 경우가 많습니다.

동기화된 데이터를 신뢰할 수 없게 만드는 흔한 실수들

가장 큰 함정은 ‘최신성=정확성’이라고 가정하는 것입니다. 파이프라인이 초 단위로 최신이어도 조인이 바뀌었거나 필터가 추가되었거나 행이 중복되면 잘못될 수 있습니다. 검증 없이 대시보드가 이상해지거나 고객이 불만을 제기할 때까지 모를 수 있습니다.

삭제는 또 흔한 실수입니다. 복제와 ETL 모두 ‘제거’가 무엇을 의미하는지 명확히 해야 합니다. 시스템 A가 하드 삭제를 하면 시스템 B가 단순히 삽입·업데이트만 하는 경우 리포트는 시간에 따라 어긋납니다. 소프트 삭제도 동기화가 삭제 플래그와 타임스탬프를 전달하지 않으면 똑같이 까다롭습니다.

반복적으로 보이는 실수들:

• 최신성만 목표로 삼고 기본 건수, 합계, 스폿체크를 무시함
• 삽입과 업데이트는 동기화하지만 삭제, 병합, 비활성화 상태는 처리하지 않음
• 컬럼 이름 변경, 분할, 타입 변경 시 조용히 깨지는 하드코딩된 필드 매핑
• 히스토리 데이터 수정이 필요할 때 백필 계획이 없음
• 잡 실패에만 알림을 걸고 랙, 누락 데이터, 느린 드리프트에는 알리지 않음

예: CRM이 고객을 삭제하는 대신 ‘inactive’로 표시하고 ETL은 status = active인 고객만 복사한다고 합시다. 한 달 뒤 유지율 지표는 과대평가됩니다. 비활성 고객이 대상에 전혀 넘어오지 않았거나 제거되지 않았기 때문입니다. 모든 것이 최신해 보여도 정확성은 이미 틀릴 수 있습니다.

동기화를 “완료”라고 부르기 전 빠른 체크리스트

숫자로 명확히 합의하고 소유권과 검증된 복구가 있어야 합니다. 처음에는 괜찮아 보이던 동기화도 실제 변경과 실패가 누적되면 흐트러집니다.

• 최신성 약속이 문서화되어 있다. 목표 지연, 측정 시점, 누락 시 대처를 정의하세요.
• 핵심 필드(상태, 가격, 고객 이메일)의 진실 소스를 명확히 하라. 어느 시스템이 우선인지, 업데이트가 일방향인지 쌍방향인지 문서화하세요.
• 복구를 종단간 테스트했다. 실패를 시뮬레이션하고 중복이나 누락 없이 재생/재실행할 수 있음을 확인하세요.
• 스키마 변경 규칙이 존재한다. 누가 변경을 승인하고 어떻게 롤아웃하며 이름 변경, 타입 변경, 컬럼 삭제를 어떻게 처리할지 정하세요.
• 모니터링이 실행 가능하다. 랙, 오류율, 핵심 데이터 체크를 추적하고 알림이 온콜 담당자에게 무엇을 할지 알려주게 하세요.

현실 점검: delivery_instructions가 주문에 추가되면 이 필드가 자동으로 동기화되는지, 심하게 실패하는지, 아니면 안전하게 무시되는지 과정상 명확해야 합니다.

현실적인 예: 두 시스템 간 주문 동기화

PostgreSQL에 주문을 저장하는 회사가 있다고 합시다. 두 팀이 이 데이터를 필요로 합니다: 지원팀은 “내 주문이 어디 있나?”에 답할 실시간 대시보드가 필요하고, 재무팀은 안정적인 일일 수치가 필요합니다.

이들은 한쪽 접근법만 억지로 적용하지 않고 혼합 접근법을 사용합니다.

지원용으로는 논리적 복제를 사용해 새 주문과 상태 업데이트가 읽기 최적화된 데이터베이스에 빠르게 반영되도록 합니다. 재무용으로는 영업시간 이후 하루에 한 번 배치 ETL을 돌려 정제된 주문을 리포팅 웨어하우스에 적재하고 세금, 할인, 환불 같은 비즈니스 규칙을 적용해 변하지 않는 일일 스냅샷을 만듭니다.

그런데 어느 날 스키마 변경으로 refund_reason이 추가됩니다. 지원팀은 즉시 이 필드를 원합니다. 복제는 새 컬럼을 빠르게 통과시킬 수 있지만 배치 잡은 초기에 이를 선택적 필드(기본값 “unknown”)로 처리해 리포팅 로직이 준비될 때까지 안전하게 둡니다.

어느 날 지원 대상이 3시간 동안 다운되었습니다. 복구 후 복제는 저장된 위치부터 따라잡습니다. 중요한 단계는 단순히 ‘다시 실행됐다’가 아니라 ‘정확하다’는 것을 검증하는 것입니다: 장애 창 동안의 주문 건수를 확인하고 몇 건을 끝에서 끝으로 샘플 점검합니다.

매일 아침 그들은 숫자를 신뢰하기 전에 짧은 신호 집합을 확인합니다: 복제 랙, 지난 24시간 원본 대 대상 주문 건수, 재무 테이블의 중복, 배치 성공 여부 및 실행당 적재된 행 수, 그리고 높은 가치 주문 몇 건을 두 시스템에서 샘플로 검증합니다.

다음 단계: 동기화를 보이게 만들고 운영하기 쉽게 하기

접근법(또는 하이브리드)을 선택한 뒤 실제 작업은 동기화를 사람들이 매일 신뢰할 수 있게 만드는 것입니다. 하나의 측정 가능한 목표를 정하고 제품 지표처럼 다루세요. 대부분 팀에게 첫 번째 목표는 최신성(데이터가 얼마나 새로운가) 또는 정확성(얼마나 자주 틀리는가) 중 하나입니다.

작게 시작하세요: 한 테이블, 한 이벤트 스트림, 혹은 주문이나 티켓 같은 한 워크플로에 집중하세요. 그 경로가 안정되면 패턴을 복제하세요. 문제를 빠르게 감지하고 고칠 수 있는 능력 없이 확장하면 더 큰 혼란을 더 빨리 만들 뿐입니다.

비기술 팀을 위한 실용적 “동기화 상태” 뷰는 보통 현재 랙 대 목표, 마지막 성공 동기화 시간, 마지막 실패 시도, 오늘 처리량 대 예상 범위, 상태가 빨간색일 때 해야 할 짧은 지침을 포함합니다.

이런 내부 관리자 화면을 빠르게 만들고 싶다면 AppMaster 같은 노코드 플랫폼이 모니터링 뷰를 신속히 제공하고 스키마나 워크플로가 진화할 때 모든 것을 다시 쓰지 않고도 조정할 수 있게 도와줄 수 있습니다.