내 시스템 중 하나는 두 가지 방식의 규칙(manners)을 가지고 매일 밤 작업을 수행합니다. 154개의 행(row)에 대해서는 무엇을 발견하든 묻지 않고 덮어씁니다. 15개의 행에 대해서는 단 하나의 필드도 변경할 수 없습니다. 할 수 있는 최선은 요청을 접수하고 기다리는 것뿐입니다. 동일한 작업, 동일한 피드(feed), 동일한 테이블(table)입니다. 유일한 차이점은 사람이 해당 행을 만진 적이 있는지 여부입니다.

두 개의 문

이 시스템은 인력 개발 운영을 위한 명령 센터입니다. 일리노이(State of Illinois) 주는 인력 센터 디렉토리를 발행하며, 매일 밤 나의 동기화(sync) 작업은 해당 피드를 가져와 내가 가진 데이터와 비교합니다. 현재 154개에 달하는 대부분의 사이트는 익명의 디렉토리 항목입니다. 우리 측의 그 누구도 이를 열어본 적이 없습니다. 이러한 항목의 경우, 피드가 직접 데이터를 작성합니다. 새로운 주소, 새로운 전화번호, 새로운 운영 시간, 완료되었습니다. 아무도 보지 않는 행을 두고 주 정부와 논쟁하는 것은 어리석은 일일 것입니다. 피드가 해당 행에 대해 무엇인가를 알고 있는 유일한 당사자이므로, 피드가 결정합니다.

15개의 사이트는 다릅니다. 이들은 파트너 센터로, 우리 측 사람들이 직원 메모와 방문 기록을 채워 넣은 행들입니다. 누군가 그곳에 직접 운전해서 갔습니다. 누군가 어느 문을 사용해야 하는지, 누구를 찾아야 하는지를 적어 두었습니다. 피드가 이러한 행 중 하나와 내용이 다를 경우, 동기화는 데이터를 작성하지 않습니다. 대신 변경 사항을 WorkNetPendingChange라고 불리는 테이블에 대기열(queue)로 쌓아두고, 사람이 이를 승인하거나 거부할 때까지 기다립니다.

그리고 그 어떤 것도 절대 삭제되지 않습니다. 주 정부의 내보내기(export)에서 사라진 사이트는 단지 missingSince 날짜가 부여될 뿐입니다. 피드는 오작동할 수 있습니다. 내보내기 데이터가 잘릴 수도 있습니다. 날짜는 되돌릴 수 있습니다. 방문 기록을 통해 연쇄적으로 발생하는 삭제(cascade delete)는 되돌릴 수 없습니다.

• 154개: 피드가 자유롭게 덮어쓰는 디렉토리 사이트
• 15개: 변경 사항이 검토를 위해 대기하는 파트너 센터
• 0개: 동기화 작업이 삭제할 수 있도록 허용된 행

피드가 아닌 행

동기화를 설계하는 일반적인 방식은 피드가 신뢰할 수 있는 원천(source of truth)인지 묻는 것입니다. 그 질문은 하나의 가정을 숨기고 있습니다. 바로 권한이 피드에 속해 있다는 가정입니다. 그렇지 않습니다. 권한은 행(row)에 속해 있습니다.

각 측이 실제로 무엇을 알고 있는지 생각해 보십시오. 상태(state)는 자신이 게시한 내용을 알고 있습니다. 지난 화요일의 방문이나, 기재된 전화번호가 팩스 기기로 연결된다는 메모에 대해서는 전혀 모릅니다. 이곳의 누구도 건드리지 않은 행(row)에 대해서는 피드(feed)의 지식이 존재하는 지식의 전부이므로, 피드가 모든 충돌에서 승리해야 합니다. 사람들이 작업해 온 행에 대해서는 피드가 더 적은 정보를 가지고 있으며, 피드가 이를 덮어쓰게 두는 것은 더 큰 정보를 파괴하는 것을 의미합니다.

권한은 피드(feed)의 속성이 아닙니다. 그것은 행(row)의 속성입니다.

핵심 통찰 (Key insight): 동기화 쓰기(sync write) 권한을 행(row) 단위로 부여하십시오. 사람이 아무런 작업도 하지 않은 곳에서는 자유롭게 덮어쓰고, 누군가 작업을 수행한 곳에서만 변경을 제안할 수 있게 됩니다.

무엇이 망가졌는가: 내가 후회했던 모든 동기화는 동일한 방식으로 실패했습니다. 상류(upstream)의 내보내기(export) 작업이 잘못되었고, 해당 작업은 수개월간의 인간의 작업을 덮어쓰며 그 잘못된 내용을 충실히 복사했습니다. 덮어쓰기는 밀리초(milliseconds) 만에 이루어졌습니다. 코디네이터(coordinator)가 사이트에 대해 알고 있던 정보를 되찾는 데는 몇 주가 걸렸으며, 아예 불가능한 경우도 있었습니다.

동일한 규칙이 계속해서 나타납니다

이 규칙을 깨닫고 나니, 내 스택(stack) 전체에서 이 규칙이 보이기 시작했습니다. 동일한 커맨드 센터(command center)가 공유 편지함을 분류하는 인박스 에이전트(inbox agent)를 운영합니다. 일상적인 메시지는 에이전트가 스스로 처리합니다. 실제 관계에 영향을 미치는 모든 것은 검토 대기열(review queue)로 넘어갑니다. 다시 한번 두 개의 문(two doors)이 존재하는 셈입니다.

나의 퍼블리싱 파이프라인(publishing pipeline)도 같은 방식으로 작동합니다. 작업 로그(work-log) 항목들은 엔터프라이즈 타임라인(enterprise timeline)에 스스로 게시됩니다. 변경 로그(changelog) 한 줄에 그 누구의 판단도 달려 있지 않기 때문입니다. 내 이름이 걸린 공개 에세이들은 승인을 기다립니다. 그리고 완전히 다른 산업 분야인 의료 청구(medical billing)에서 내가 운영하는 거부 평가 엔진(denial-assessment engine)은 기계적인 케이스들에 직접 작용하며, 실제 판단이 필요한 소수의 케이스에 대해서는 escalate_to_human을 호출합니다.

내 업무의 세 가지 영역이 하나의 규칙을 따릅니다. 자동화는 사람이 건드리지 않은 작업에 대해 완전한 권한을 갖습니다. 사람이 그것을 건드리는 순간, 자동화는 작성자(writer)에서 제안자(proposer)로 격하됩니다.

결과: 이 동기화(sync)는 인간의 노력 없이도 154개의 행(row)을 최신 상태로 유지하며, 15개의 파트너 센터와 발생하는 모든 드리프트(drift)는 데이터가 반영되기 전에 반드시 사람의 검토를 거칩니다. 어느 하나를 희생하지 않고도 신선함과 안전함을 동시에 확보합니다.

무엇을 구축할 것인가

이 모든 것은 생소한 것이 아닙니다. 이는 WHERE 절과 대기 중인 변경 사항 테이블(pending-changes table)에 불과합니다. 어려운 점은 이것을 구축하기로 결정하는 것입니다. 왜냐하면 "피드(feed)가 진실의 원천(source of truth)이다"라는 말이 너무나 깔끔하게 들리기 때문입니다. 만약 여러분이 외부 피드를 사람들이 실제로 작업하는 시스템에 연결하고 있다면, 저는 다음과 같이 하겠습니다:

1. 피드 단위가 아닌 행(row) 단위로 쓰기 권한(write authority)을 부여하십시오. 진실의 원천은 행 수준(row-level)의 문제입니다.
2. 인간의 작업이 피드의 권한을 격하시키도록 하십시오. 행에 대한 첫 번째 스태프 노트(staff note)가 작성되는 순간, 피드는 작성자(writer)에서 조언자(advisor)로 전환됩니다.
3. 동기화(sync)가 삭제를 수행하게 두지 마십시오. 부재(absence)를 기록하고 그것이 무엇을 의미하는지는 사람이 결정하게 하십시오.
4. 모든 변경 사항이 하나의 경로를 선택하게 만드십시오: 직접 쓰기(direct write) 또는 검토 대기열(review queue). 제3의 경로는 없습니다.
5. 사람들이 실제로 읽을 수 있을 만큼 대기열을 짧게 유지하십시오. 아무도 읽지 않는 검토 대기열은 불필요한 단계가 추가된 삭제(delete)일 뿐입니다.

기계는 아무도 신경 쓰지 않는 것을 소유해야 하며, 그래야 사람이 자신이 신경 쓰는 것을 소유할 수 있습니다. 여러분의 데이터베이스에서 어떤 행(row)에 지문(fingerprints)이 남아 있는지 확인해 보십시오. 바로 그 행들이 피드가 반드시 문의를 거쳐야 하는 대상들입니다.

원문은 nabbilkhan.com에 게시되었습니다.