Executive Summary

주요 수치

출처: Gou 외, Git4Data: Database-Native Version Control for AI Agents, arXiv:2609.02106(2026) 표 1·표 4·4.2절

논문이 첫 그림으로 든 상황은 데이터 정제다. 중복된 개체와 깨진 필드가 섞인 원본 테이블이 있고, 어느 정제 전략이 맞는지 미리 알 수 없다. 그래서 에이전트는 전략 하나에 걸지 않고 원본을 세 갈래로 가른다. 한쪽은 범주 값을 규칙으로 정규화하고, 다른 쪽은 비슷한 이름을 묶어 중복을 지우고, 나머지 하나는 문맥을 읽어 의미를 바로잡는다.

세 갈래를 다 돌리고 나면 어느 하나가 압승하지 않는다. 각 전략이 손대는 레코드의 집합이 서로 다르다. 그래서 마지막 작업은 승자를 고르는 일이 아니라 갈래마다 쓸 만한 행만 골라 하나의 상태로 되돌리는 일이 되고, 그 과정에서 무엇을 시도했고 무엇을 받아들였고 무엇을 버렸는지가 기록으로 남아야 한다.

논문이 요구 조건으로 적은 네 가지가 여기서 나온다. 투기적 수정 전에 데이터를 포크할 것, 행 단위 차이를 들여다볼 것, 검증된 변경만 병합할 것, 실패한 경로는 원본을 복사하지 않고 되돌릴 것. 이것들이 외부 도구가 아니라 데이터베이스가 직접 제공하는 일급 연산이어야 한다는 것이 이 글이 다루는 제안의 출발점이다.

이런 요구를 처음 짚은 쪽이 이 논문은 아니다. 에이전트가 관계형 데이터를 읽고 변환을 제안하고 SQL을 평가하며 다시 고친다는 관찰은 데이터 관리 학계에서 몇 해째 쌓여 왔고, 에이전트를 앞에 놓고 데이터 시스템을 다시 설계하자는 2026년 CIDR 논문은 이 패턴에 투기적 탐색이라는 이름까지 붙였다. 4절에서 쓰는 벤치마크도 같은 흐름에서 나왔다. 이 논문이 새로 밀어 넣는 것은 문제 인식이 아니라 그 인식에 대응하는 SQL 연산이다.

데이터를 버전으로 다루려는 시도가 없었던 것은 아니다. 문제는 각각이 다른 자리에서 막힌다는 점이다. 논문은 다섯 갈래의 선행 작업을 훑으면서 어디까지 되고 어디서 멈추는지를 하나씩 짚는다.

표를 세로로 읽으면 진단이 하나로 모인다. 데이터베이스에 없는 것은 변경을 붙잡거나 포크하는 능력이 아니다. 그렇게 만들어진 버전들을 다루는 SQL 연산, 즉 비교와 충돌을 아는 재통합이 없다는 것이 논문의 문장이다.

Git4Data가 빌려 온 어휘는 네 개다. 스냅숏이 커밋이나 태그를 맡고, 브랜치는 스냅숏에서 복제한 새 테이블이며, diff는 두 버전이 어긋나는 행을 보고하고, 병합은 받아들인 변경을 명시된 충돌 정책 아래 되돌린다.

네 연산 모두 SQL 문장이라 기존 트랜잭션과 인증, 접근 제어를 그대로 물려받는다. 사람 엔지니어와 에이전트가 같은 인터페이스를 쓴다는 뜻이기도 하고, 여러 테이블에 걸친 변경이 한 트랜잭션으로 함께 발행된다는 뜻이기도 하다. 스냅숏은 데이터베이스 단위로도 뜰 수 있지만, 논문은 설명을 단순하게 하려고 테이블 하나를 기준으로 문법을 편다.

논문의 예제에서는 테이블 T가 스냅숏 sn1을 남기고, 거기서 갈라져 나온 TClone이 따로 발전해 sn3에 이른다. 그동안 T도 멈춰 있지 않아 sn2로 나아간다. 마지막에 두 갈래가 sn4에서 합쳐진다.

가장 가벼운 형태의 스냅숏은 아예 선언하지 않는다. 다중 버전 저장 엔진은 최근 24시간쯤의 시점 이력을 이미 들고 있어서, 지나간 상태를 타임스탬프로 바로 질의할 수 있다. 오래 남겨야 하는 상태만 이름을 붙여 승격한다.

이름 붙은 스냅숏은 복제의 출발점이 된다. 복제된 TClone은 T의 스키마와 데이터를 물려받지만 그 순간부터 둘은 서로에게 영향을 주지 않는다. 에이전트가 운영 상태를 건드리지 않고 투기적 변경을 시험할 수 있는 격리가 여기서 생긴다.

비교의 의미는 정렬과 무관하다. 테이블 버전을 순서 없는 행의 다중집합으로 놓고, 양쪽에서 상쇄되지 않는 행만 골라내기 때문이다. 물리적 배치가 어떻든 결과가 같다는 뜻이고, 기본키가 있으면 그 키가 버전을 가로지르는 행의 신원 노릇을 한다.

병합에서 원본을 통째로 덮어쓰지 않는 이유는 예제 흐름에 이미 들어 있다. TClone을 탐색하는 동안 T도 sn2로 나아갔으므로, T를 브랜치로 갈아 끼우면 그 사이의 진척이 소리 없이 사라진다. 그래서 Git4Data는 공통 조상 sn1을 스스로 찾아내 3-way 병합을 한다. 사용자가 베이스를 지목할 필요는 없고, 스냅숏과 복제의 계보를 시스템이 따라간다. 베이스를 끝내 찾지 못하면 빈 베이스로 처리하되, 두 복제본이 공유하는 오브젝트는 건너뛰므로 손으로 짠 SQL보다는 여전히 빠르다.

3.1무엇을 진짜 충돌로 볼 것인가

기본키가 있으면 판정이 단순하다. 베이스와 대상, 원본 세 스냅숏에서 같은 키의 행을 견주어, 두 브랜치가 각자 같은 키를 고쳤을 때만 진짜 충돌로 잡는다. 두 브랜치가 같은 새 키를 넣은 경우도 여기 들어간다. 한쪽만 건드렸거나 양쪽이 똑같이 고쳤다면 결과가 갈리지 않으므로 시스템이 알아서 정리한다.

기본키가 없으면 행을 이어 줄 신원이 없어 다중집합 논리로 내려간다. 넣은 행은 전체 값으로 묶고 지운 행은 저장 엔진의 물리적 행 식별자로 좇는다. 양쪽 델타에 같은 변경이 나타나되 서로 상쇄되지 않을 때만 충돌을 의심하고, 한쪽에만 있는 변경은 그냥 적용한다.

설계에서 공들인 대목은 따로 있다. 컴팩션이나 가비지 컬렉션이 유효한 행을 새 오브젝트로 옮겨 적으면 값은 그대로인데 위치가 바뀐다. 이때 옮겨진 행을 변경으로 읽으면 저장소 정리가 다른 브랜치의 멀쩡한 수정을 가려 버린다. Git4Data는 값이 같으면 이동으로 인식해 허위 충돌을 만들지 않는다. 다만 저자들은 이 경우가 자주 오지는 않는다고 덧붙인다. 브랜치는 대개 잘 정리된 스냅숏에서 갈라져 나오므로 공통 베이스 구간에서 컴팩션이 도는 일 자체가 드물고, 지워진 원본 행의 값을 통째로 다시 읽어야 하는 것도 이 경우뿐이다.

연산의 뜻 자체는 어느 OLTP 데이터베이스에 올려도 같다. 저장 설계에 따라 달라지는 것은 비용이다. 이 문법이 감당할 만한 값에 돌아가려면 저장 엔진이 세 가지를 이미 갖고 있어야 한다. 데이터를 제자리에서 고치지 않고 불변 단위로 덧붙일 것, 삭제를 표시로 남길 것, 버전 관리 연산이 트랜잭션으로 실행될 것.

두 번째 조건이 왜 필요한지는 비교와 병합을 떠올리면 바로 보인다. 삭제가 표시로 남아야 비교가 테이블 전체를 훑지 않고도 지워진 행을 보고하고, 병합이 한쪽에서만 지운 행과 양쪽이 함께 지운 행을 갈라 볼 수 있다. 논문이 강조하는 대목은 이 셋을 갖춘 엔진이라면 Git4Data가 그 위에 얹히는 얇은 해석 층으로 충분하다는 점이다. 실제로 MatrixOne 구현은 저장 계층을 고치지 않았다.

MatrixOne은 테이블 데이터를 클라우드 오브젝트 스토리지에 불변 오브젝트로 쌓는다. 삭제는 키와 물리적 행 번호를 적은 툼스톤 오브젝트로 표현하고, 스냅숏은 그 오브젝트들을 가리키는 디렉터리에 지나지 않는다. 가비지 컬렉션이 스냅숏을 알아보고 참조된 오브젝트를 남기기 때문에, 브랜치와 태그를 유지하는 데 데이터 복사가 끼어들지 않는다.

복제 비용을 실제로 재면 차이가 이렇게 벌어진다. TPC-H의 lineitem 테이블을 스케일 팩터 100, 그러니까 100GB로 놓고 잰 값이다.

비교와 병합에서도 같은 원리가 작동한다. 두 버전이 갈라진 뒤에 쓰인 오브젝트만 읽으면 된다. 무작위로 100만 행을 고친 조건에서 비교가 3.27초, 병합이 16.13초였고, 같은 일을 손으로 짠 SQL로 하면 각각 431.50초와 471.16초가 걸렸다. 기본키가 없으면 지운 행을 찾느라 조회가 더 붙어 이득이 줄어든다. 같은 조건의 비교가 60.19초, 병합이 68.75초다.

여기까지는 갈래 하나를 놓고 잰 값이다. 논문은 갈래가 여럿일 때도 같은지 따로 확인했다. 네 사람이 각자 같은 테이블을 포크해 대체로 겹치지 않는 수정을 병합하되, 그중 두 갈래는 기본키의 10퍼센트 구간에서 서로 부딪치게 두고 ACCEPT로 해소한 조건이다. 100만 행을 고친 규모에서도 내장 비교와 병합은 손으로 짠 SQL보다 자릿수가 달라지는 수준으로 빨랐다. 앞의 표들은 원본이 가만히 있는 동안 브랜치만 고친 경우라 충돌이 날 일이 없었으니, 충돌을 일부러 만들어 놓고 잰 자리는 논문에서 여기뿐이다.

저자들이 여기서 끌어낸 교훈은 성능표 바깥에 있다. Git은 순서가 있는 텍스트 줄을 어림짐작으로 맞추는 반면, 관계형 엔진은 기본키가 행에 신원을 주므로 깔끔한 의미론을 따로 만들지 않고도 얻는다. 논문은 기본키 인덱스에 기댄 재통합이 값으로 맞추는 전통적 방식을 자릿수가 달라질 만큼 앞선다고 적었는데, 바로 앞에서 본 기본키 있고 없는 두 줄이 그 자리다.

끝에서 끝까지 도는 워크로드로 옮기면 비교 상대가 DoltDB가 된다. BranchBench는 브랜치 생애주기와 브랜치 내부 SQL, 브랜치 간 비교, 가지치기를 워크로드 축으로 놓은 벤치마크다. 약 4,700만 행 위에서 에이전트 다섯 기가 20스텝씩 돌며 각자 포크하고 질의하고 병합하거나 버린다.

네 워크로드에서 벌어진 차이는 8.4배에서 18.5배 사이다. DoltDB가 브랜치 연산마다 테이블 내용을 실체화해 견주는 반면 Git4Data는 변경된 델타만 읽기 때문이라는 것이 저자들의 설명이다. 그래서 실행 시간이 테이블 크기가 아니라 변경 크기를 따라간다.

이 성질이 가장 뚜렷하게 보이는 실험은 에이전트를 1,000기까지 늘린 시뮬레이션이다. 각 에이전트가 데이터베이스를 포크하고 브랜치 안에서 한 스텝씩 돌리는 부하인데, Git4Data는 400초에 끝냈고 DoltDB는 두 시간 안에 끝내지 못했다. 데이터를 열 배로 키워도 이 시뮬레이션은 600초로 크게 밀리지 않았다. 포크 비용이 데이터 크기와 무관하게 메타데이터에만 매여 있다는 뜻이다.

예외도 논문에 적혀 있다. 데이터를 열 배로 키웠을 때 소프트웨어 개발과 데이터 정제는 3.2배 안쪽으로만 느려졌고 MCTS 탐색은 웜 40초 아래에 머물러 사실상 그대로였다. 장애 재현 워크로드만 13.5배 느려졌다. 이 워크로드의 수정이 테이블 전체를 훑고 다시 쓰는 방식이라 비용이 변경 크기가 아니라 데이터 크기를 따라가기 때문이다. 델타 기반 설계의 이점이 어디까지인지를 저자들이 스스로 그어 둔 셈이다.

포크가 메타데이터 연산이 되고 병합이 원자적으로 커밋되자 브랜치 생성은 더 이상 동시성을 제약하지 않게 됐다. 대신 브랜치 안에서 도는 작업들이 같은 컴퓨트와 입출력을 나눠 쓰는 문제가 전면에 올라왔다. 저자들이 스스로 적은 표현으로는 열린 문제가 저장 효율에서 자원 거버넌스로 옮겨 갔다.

남은 숙제로 논문이 꼽은 것은 네 가지다. 앞의 둘은 지금 당장 걸린다. 수천 개의 투기적 브랜치를 두고 스케줄링과 진입 제어, 브랜치별 할당량을 어떻게 정할 것인가. 그리고 지금은 충돌 해소가 행 단위여서 같은 행의 다른 컬럼을 고친 두 브랜치도 충돌로 잡히는데, 셀 단위로 내려가는 것이 자연스러운 다음 걸음이다. 다만 더 어려운 문제는 의미론 쪽에 있다. 각자로는 제약을 어기지 않는 두 변경이 합쳐지면 제약을 깨는 경우가 그렇다.

나머지 둘은 브랜치가 오래 살아남을 때 생긴다. 스키마가 바뀌면 비교와 병합의 전제가 무너지고, 이름 붙은 스냅숏이 오브젝트를 붙들고 있어 브랜치가 쌓일수록 저장이 늘어난다. 둘 다 정책 없이 남아 있다. 충돌 정책 자체도 세 가지에서 멈춰 있는데, 저자들이 미탐구 영역으로 남긴 것 가운데 하나가 비교 결과를 읽은 에이전트에게 병합을 몰고 가는 역할을 맡기는 방식이다.

논문이 열린 문제라 적은 것들이 코드에서는 어디까지 와 있는지 궁금해 저장소를 열어 봤다. MatrixOne이 실제로 갖춘 문장은 논문이 서술한 네 연산보다 많다. 파서의 구문 트리에는 테이블과 데이터베이스 단위의 브랜치 생성·삭제, 비교, 병합에 더해 논문에 나오지 않는 문장이 하나 더 있다.

Git의 cherry-pick에 해당하는 연산이고, 2026년 4월 9일에 병합됐다. 기본키 값을 리터럴로 적거나 서브쿼리로 넘겨 특정 행만 대상 테이블로 옮기며, 두 스냅숏 사이의 변경으로 범위를 좁힐 수도 있다. 충돌 정책 세 가지는 병합과 같고, 기본키가 없는 테이블은 아예 거부된다. 1절의 정제 워크플로가 말한 받아들인 델타만 골라 되돌리기에 대응하는 문장인데, 논문은 이 문장을 다루지 않으므로 둘을 잇는 것은 이 글의 해석이다. 승인 목록을 서브쿼리로 넣을 수 있다는 점은 검토 절차를 SQL 안에 두려는 팀에게 특히 실무적이다.

자원 거버넌스 쪽도 움직이고 있다. 8월 29일에 병합된 변경은 스냅숏 생성과 브랜치 생성에 계정별 할당량을 걸고, 관리자가 한도를 바꾼 직후 다른 노드에서 들어온 요청이 낡은 카탈로그를 보고 통과하는 일이 없도록 순서를 강제한다. 한도가 없으면 그냥 통과시키고, 한도가 유한하면 할당량 행을 잠근 채 사용량을 세어 메타데이터 발행까지 한 트랜잭션으로 묶는다. 논문이 말한 브랜치별 할당량, 그러니까 에이전트의 진척도를 반영하는 스케줄링과는 아직 거리가 있다. 그래도 자원 통제가 운영 문서에서 엔진 안으로 옮겨 오고 있다는 신호로는 읽힌다.

여기까지 읽어 주신 데 감사드린다. 논문 전문은 arXiv:2609.02106에서 볼 수 있고, 이 글의 문법과 수치는 논문 2절·3절·4절에서, 저장소의 코드 상태는 MatrixOne 저장소에서 2026년 9월 6일에 직접 확인했다. 에이전트에게 데이터 쓰기 권한을 이미 열어 둔 팀이 있다면 되돌리기와 기록을 어느 계층에서 감당하고 있는지 나눠 주시면 좋겠다.

학술 논문

• 1.Gou, H., Zhang, Z., Sun, Y., Xu, P., Tian, F., Wang, L., Wang, J. (2026). "Git4Data: Database-Native Version Control for AI Agents." arXiv:2609.02106.
• 2.Ang et al. (2026). "Supporting Our AI Overlords: Reimagining Data Practices for AI Agents." CAIS'26 워크숍. — BranchBench 비교 벤치마크 출처, Git4Data 저자와 별개 팀.

구현·비교 대상

• 3.MatrixOrigin. (2026). "matrixorigin/matrixone." GitHub. — Git4Data가 구현된 저장소.
• 4.DoltHub. (2026). "dolthub/dolt." GitHub. — BranchBench 비교 대상, 가장 근접한 선행 구현.
• 5.Neon. (2026). "Branching." Neon Docs. — 인스턴스 단위 copy-on-write 포크, 테이블 단위 브랜치·행 단위 병합 불가.