아무도 지켜보지 않을 때 돌아가는 동기화를 위한 여섯 가지 규칙

2026년 10월 8일, Lance Martin과 CJ Avilla는 매일 아침 Slack과 GitHub를 읽고 Slack에 요약을 올리는 에이전트에 대한 안내 글을 발표했습니다. 그것이 돌아가는 모습을 지켜보는 사람은 없습니다. 가장 쓸모 있는 단락은 성공처럼 보이는 실패에 관한 것입니다. 소스의 서버가 다운되었거나 토큰이 만료되면 “에이전트는 그 소스에서 아무것도 보지 못하고 ‘새로운 것 없음’이라고 보고합니다.”

Shopify에서 Brevo로 가는 연락처 동기화에도 같은 실패가 있습니다. 두 SaaS 도구 사이의 모든 예약 동기화도 마찬가지입니다. 조용히 실패한 읽기는 오늘 아무도 가입하지 않은 스토어와 똑같아 보입니다.

그들의 글은 지켜보는 사람 없이 돌아가는 에이전트를 위한 여섯 가지 규칙으로 끝납니다. 동기화를 운영하는 사람의 눈으로 읽으면 하나하나가 reverse ETL의 규칙입니다. 워커는 죽었지만, 동기화는 죽지 않았습니다는 충돌 속에서 연락처 하나를 따라갔습니다. 이 페이지는 그 위의 체크리스트입니다. 자동 데이터 동기화를 위한 여섯 가지 규칙, 각 규칙에 대해 Tajo의 러너가 오늘 하는 일, 그리고 부족한 부분입니다. 러너 쪽 내용은 멈추거나 실패한 동기화 복구하기에 정리되어 있습니다.

1. 책갈피에서 읽고, 배치가 도착했을 때만 옮기기

그들의 첫 번째 규칙은 “각 소스를 고정된 시간 범위가 아니라 책갈피에서 읽으라”는 것입니다. “최근 24시간”이라는 시간 범위는 실행이 늦게 시작하면 빈틈을 남기고, 일찍 시작하면 레코드를 반복합니다.

Tajo 동기화는 저장된 커서에서 소스를 배치 단위로 읽습니다. 커서는 배치가 끝날 때 움직이며, 그 배치의 모든 레코드가 도착했을 때만 움직입니다. 실패한 실행은 마지막으로 깔끔했던 위치를 유지하므로, 다음 실행은 중단된 배치를 건너뛰지 않고 다시 읽습니다.

주문에는 별도의 책갈피가 있습니다. Shopify 주문 예약 동기화는 첫 예약 실행에서 시작해 이전 실행 이후 바뀐 내용을 보냅니다. 지난 주문은 사람이 동기화를 실행할 때만 갑니다. 예약 실행과 사람이 시작한 실행은 서로 다른 커서를 유지하므로, 과거 데이터 백필이나 테스트 배치가 예약 커서를 되돌릴 수 없습니다.

대가는 중단된 배치를 두 번 읽는다는 것입니다. 그것을 안전하게 만드는 것이 규칙 2입니다.

2. 모든 쓰기에 충돌을 견디는 키를 붙이기

그들의 네 번째 규칙은 게시물을 “Slack이 확인했을 때만” 보낸 것으로 치고, 그때서야 책갈피와 원장을 갱신합니다. 등기 우편이 이렇게 동작합니다. 창구를 떠날 때가 아니라 서명된 수령증이 돌아올 때 배달된 것입니다.

Tajo가 레코드를 쓰기 전에, 레코드는 전송 키를 받습니다. 키는 동기화, 소스, 페이지 커서, 페이지 안의 위치, 레코드 자체의 해시이므로 개인 데이터를 담지 않습니다. 대상 시스템을 호출하기 전에 확보되고, 쓰기가 성공하면 완료로 표시됩니다. 완료된 키는 7일 동안 보관됩니다. 재시도나 이후의 예약 실행은 같은 레코드에 대해 같은 키를 도출하고, 그것이 완료된 것을 확인하면 대상 시스템을 다시 호출하지 않습니다.

여기에는 두 가지 대가가 따릅니다. 7일이 지나면 원장은 잊어버리고, 더 오래된 커서에서 다시 실행하면 다시 쓸 수 있습니다. 그리고 시간 초과된 쓰기는 정당한 의심을 남깁니다. 상대 시스템이 응답 없이 저장했을 수도 있습니다. Tajo는 그 쓰기를 7일 동안 실패로 기록하는 대신 이후 시도에서 다시 시도합니다. 대상 시스템에 자체 멱등성 키를 넘기는 커넥터는 그 의심을 없앱니다. 그럴 수 없는 커넥터에는 중복 한 건의 가능성이 남습니다.

3. 하나의 실행이 동기화를 소유하고, 쓰기마다 그것을 증명하기

그들의 세 번째 규칙은 “게시하기 직전에 모든 항목을 다시 확인하라”입니다. 동기화에서 읽기와 쓰기 사이에 가장 바뀌기 쉬운 것은 누가 쓸 수 있느냐입니다.

Tajo의 각 동기화에는 리스가 하나 있고, 자체 토큰과 15분의 수명을 가지며 5분마다 갱신됩니다. 실행은 대상 시스템을 호출하기 전에 리스를 아직 가지고 있는지 확인하고, 커서를 옮기기 전에 한 번 더 확인합니다. 리스를 잃은 실행은 멈추고, 그 페이지에는 “실행이 도중에 자리를 잃어 두 번 쓰지 않도록 멈췄습니다.”라고 표시됩니다. 진행 중인 실행과 부딪힌 두 번째 실행은 그 뒤에 줄을 서지 않고 종료됩니다.

레코드도 확인합니다. 읽기와 쓰기 사이에서 레코드는 동의 필터를 거칩니다. 입증할 수 있는 동의 없이 마케팅 오디언스에 기록되려는 연락처는 추측하지 않고 거부합니다. 도움말 페이지의 표현대로라면, 실패의 방향은 “지나치게 신중한” 쪽이지, “과잉 발송” 쪽이 아닙니다.

4. 지나가는 것은 재시도하고, 그렇지 않은 것은 멈추기

그들의 여섯 가지 규칙은 얼마나 자주 다시 시도할지에 대해 아무 말도 하지 않습니다. 동기화에는 그 규칙이 필요합니다. 가장 흔한 실패가 속도 제한과 공급업체 쪽의 잠깐의 장애이기 때문입니다.

대기열에 들어간 Tajo 실행이 실패하면 다섯 번의 시도를 받습니다. 그 사이 대기 시간은 60, 120, 240, 480초로, 모두 합쳐 약 15분입니다. 어떤 실패는 다시 시도해도 고칠 수 없기 때문에 절대 재시도하지 않습니다. 이미 진행 중인 실행과 부딪힌 실행은 재시도하지 않으며, 게시된 버전이나 연결이 더 이상 유효하지 않은 실행도 재시도하지 않습니다.

연속된 실패는 한 번의 삐끗함과 다릅니다. 동기화가 마지막으로 변경된 이후 완료된 최근 다섯 번의 실행이 모두 실패하면, Tajo는 동기화를 일시 중지하고 마지막 오류를 그 페이지에 보여 줍니다. 한 번 성공하면 횟수는 초기화됩니다. 일시 중지된 동기화를 저절로 다시 시작하는 것은 없습니다. 사람이 원인을 고치고 다시 게시합니다. 워커 글이 이 규칙을 낳은 사건을 이야기합니다.

5. 침묵을 발견으로 다루기

“실패한 읽기는 조용한 하루가 아니라 읽을 수 없었다고 보고하라.” 여섯 가지 중 가장 어렵고, 우리가 일부만 지키는 유일한 규칙입니다.

지켜지는 부분. 오류가 난 읽기는 실행을 실패시킵니다. 거부된 토큰이나 응답하지 않는 서버는 대상 시스템에 아무것도 보내지 않고, 커서를 있던 자리에 두며, 다섯 번 실패 후의 일시 중지에 포함됩니다. 그리고 매시 13분에 Tajo는 활성 동기화가 있는 모든 워크스페이스를 확인합니다. 최근 24시간 동안 성공한 실행이 없으면 자체 팀에 알림을 보내며, 실행이 하나도 기록되지 않은 워크스페이스도 포함합니다. 이것이 매시간 검사입니다.

지켜지지 않는 부분. 저자들이 말하는 조용한 읽기는 레코드 없이 “OK”라고 답하는 읽기입니다. 우리 러너는 그것을 성공으로 셉니다. Shopify 고객 같은 소스의 경우, 이전에 레코드를 만들어 낸 적이 있는 동기화가 0건으로 연속 열 번 성공하면 별도의 검사가 Tajo 팀에 경고합니다. Shopify 주문은 업데이트 시각 기준으로 읽기 때문에 빈 실행이 흔한 일이고, 그 검사는 실행되지 않습니다. 레코드를 일부 돌려주지만 마땅히 돌려줘야 할 것보다 적은 소스는 전혀 잡아내지 못합니다.

반론은 이렇습니다. “15분 일정이라면 빈 실행 열 번은 두 시간 반이다. 왜 첫 번째에 알리지 않는가?” 연락처 동기화는 실제로 기본값으로 15분마다 실행됩니다. 그리고 15분 동안 새 고객이 없는 스토어는 흔합니다. 첫 번째 빈 실행에 알림을 보내면 매일 밤 울릴 것이고, 늘 울리는 알림은 아무도 읽지 않습니다. 그 기준선은 속도를 믿음과 맞바꿉니다. 그래도 침묵에 대한 추측일 뿐, 저자들의 규칙은 아닙니다.

6. 동기화가 쓸 수 있는 것을 한 번 정하고, 모든 실행이 그것을 증명하게 하기

그들의 다섯 번째 규칙은 에이전트의 설정을 “에이전트가 편집할 수 없는 저장소”에 둡니다. 여섯 번째 규칙은 읽기만 하는 곳에서는 에이전트에 읽기 전용 접근만 주고, 실행마다 쓸 수 있는 비용에 상한을 둡니다. 둘 다 에이전트가 다른 사람이 쓴 텍스트를 읽고, 그 텍스트가 에이전트에게 명령하려 할 수 있기 때문에 존재합니다.

동기화에서 설정 파일에 해당하는 것은 게시된 규칙입니다. Tajo 동기화를 게시하면 미리보기한 바로 그 규칙의 다이제스트에 묶입니다. 편집하면 초안으로 돌아가고, 다시 실행되기 전에 미리보기를 다시 거칩니다. 모든 실행은 무엇이든 바꾸기 전에, 자신이 그 게시된 버전을 게시 당시의 연결로 실행하고 있는지 확인합니다. 이 확인에 실패한 실행은 재시도하지 않습니다. 방향도 고정되어 있습니다. 동기화 규칙은 한 방향으로 쓰며 Shopify로 되돌려 쓰지 않습니다.

비용 상한에 해당하는 것은 없습니다. 우리 동기화 실행에는 실행당 비용 상한이 없습니다. 재시도 한도와 일시 중지가 제한하는 것은 실패가 얼마나 오래 이어질 수 있는지이지, 실행 한 번의 비용이 아닙니다.

만들어진 것과 아직 만들어지지 않은 것

이 글을 쓰는 시점에 만들어진 것:

• 모든 레코드가 도착한 배치 뒤에만 움직이는 커서와, 사람이 시작한 실행이 되돌릴 수 없는 예약 주문 커서.
• 7일 동안 보관되는 완료된 쓰기의 원장과 대조되는 레코드마다의 전송 키.
• 쓰기 전과 커서가 움직이기 전에 확인되는 동기화마다 하나의 리스.
• 60초, 이어서 120, 240, 480초를 기다리는 실행마다 다섯 번의 시도. 충돌이나 유효하지 않은 게시는 재시도하지 않습니다.
• 동기화 페이지에 표시되는 연속 다섯 번 실행 실패 후의 일시 중지.
• 최근 24시간 동안 성공한 실행이 없을 때의 매시간 알림.
• 마케팅 오디언스에 기록되는 연락처에 대한 실행 시점의 동의 필터와, 모든 실행에서 게시된 버전인지 확인하는 검사.

아직 만들어지지 않은 것, 의지하기 전에 알아 두면 좋은 것:

• 레코드 0건으로 성공한 읽기는 읽을 수 없었다고 보고되지 않습니다. 열 번 경고가 그 일부를 다룹니다. Shopify 주문이나 레코드를 너무 적게 돌려주는 소스는 다루지 않습니다.
• 24시간 알림이 가는 곳은 Tajo이지 여러분이 아니며, 열 번 경고도 마찬가지입니다. 일시 중지는 동기화 페이지에 표시됩니다.
• 매시간 검사는 워크스페이스를 봅니다. 개별 동기화를 보지 않습니다. 건강한 동기화 하나가 옆의 조용한 동기화를 가립니다.
• 실행당 비용 상한이 없습니다.
• 일시 중지된 동기화를 다시 시작하는 것은 없습니다. 사람이 합니다.
• 다섯 번 실패 후 일시 중지와 24시간 검사는 동기화마다가 아니라 Tajo 배포 전체에 설정됩니다.

이 중 하나가 여러분의 동기화에 나타나면 멈추거나 실패한 동기화 복구하기가 무엇이 보이고 무엇을 해야 하는지 알려 줍니다.

저자들은 사람이 매일 아침 읽는 요약을 위해 여섯 가지 규칙을 썼습니다. 동기화에는 아침 독자가 아예 없고, 그래서 이 규칙들이 더 필요합니다. 규칙 1부터 4까지와 규칙 6은 오늘 우리 러너 안의 코드입니다. 규칙 5는 절반만 쓰였습니다. 소스를 읽지 못하는 동기화는 그렇다고 말해야 합니다.