Fission으로 에이전트 추론을 보존하는 공유 위키 동시성 제어

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Chroma의 Foundation은 코딩 에이전트 trace와 회사 데이터를 여러 에이전트가 공동 편집하는 위키로 축적하는 memory layer이며, 핵심 난제는 자연어 지식을 동시에 갱신할 때 추론 비용을 버리지 않는 동시성 제어입니다. 일반적인 OCC 트랜잭션은 수분 동안 검색과 추론을 수행한 뒤 커밋 충돌이 나면 전체 작업을 다시 실행해야 하므로 토큰과 지연 시간이 낭비됩니다. Fission은 첫 페이지 읽기부터 배타적 잠금을 잡고 wound-wait로 충돌을 막되, 중단을 롤백하지 않고 이미 완료한 페이지 변경을 조기 커밋합니다. 페이지별 원자성과 Chroma Cloud의 내구성은 유지하면서 에이전트가 남은 상태를 읽고 재시도하게 하는 구조이며, 약 39.7%의 재시도가 이전 충돌 페이지를 다시 방문하고 28.2%의 수정이 해당 페이지와 내용을 공유했습니다.

빠른 이해

새로운 점

에이전트의 장시간 추론을 보존하기 위해 트랜잭션 중단을 롤백이 아닌 조기 커밋으로 처리하는 동시성 제어 방식입니다.

핵심 메커니즘

입력 배치를 여러 작업으로 나눈 뒤 각 에이전트가 관련 위키 페이지를 검색하고 첫 페이지 읽기 시 배타적 잠금을 획득합니다. 배치 도착 시각이 오래된 작업은 wound-wait 규칙으로 젊은 작업을 중단시키며, 중단된 작업은 이미 기록한 변경을 남긴 채 잠금을 해제하고 원래 시각으로 재시도합니다. Chroma Cloud의 OCC는 개별 페이지 쓰기의 원자성과 내구성을 맡고, reasoning model은 남아 있는 페이지 상태를 읽어 중복 기록이나 추가 갱신 여부를 판단합니다.

핵심 수치

배치 처리 시간: 여러 분- OCC 검증이 커밋 시점에 수행되면 장시간 실행 뒤 재시도 비용이 커집니다.
읽기·쓰기 재방문 비율: 약 39.7%- wounded transaction이 이전 시도를 중단시킨 페이지를 다시 읽거나 쓴 비율입니다.
페이지 수정의 내용 중첩: 28.2%- wounded transaction의 재시도 중 수정이 중단 원인 페이지와 prefix 또는 suffix를 공유한 비율입니다.
Git 기반 초기 구현의 포기 사례: 3/8은 반복 충돌 뒤 포기, 4/8은 오래된 read 또는 재독 필요로 포기- 파일시스템과 Git 병합을 사용한 초기 Foundation 호출 결과입니다.

섹션별 상세

에이전트 협업의 공유 상태 문제

코딩 에이전트 여러 개를 동시에 실행하면 각 작업을 격리하기 위해 Git worktree를 사용할 수 있지만, 충돌은 병합 시점까지 미뤄질 뿐 사라지지 않습니다. 코드에서는 줄 단위 차이가 대체로 문법 단위와 맞고 수정 범위가 국소적이어서 Git 병합이 작동하지만, 에이전트가 작성하는 위키와 지식 베이스는 자연어라서 요약·재구성·재작성·철회가 일어납니다. 따라서 Foundation의 핵심 문제는 여러 에이전트가 하나의 공유 지식을 동시에 갱신할 때 충돌을 어떻게 다룰지이며, 단순한 파일 병합으로는 유효한 추론 결과까지 버려질 수 있습니다.

Foundation의 데이터 처리 흐름

Foundation은 코딩 에이전트의 trace와 회사 데이터를 받아 오래 유지되는 기록과 검색 인덱스를 만드는 Chroma의 memory layer입니다. 입력 데이터는 여러 배치로 나뉘고, 각 에이전트는 배치에 포함된 trace를 바탕으로 위키에서 관련 페이지를 검색한 뒤 해당 페이지를 읽고 필요한 내용을 갱신합니다. 이 과정은 lightweight reasoning model이 수행하며, 위키 페이지는 Chroma에 청크 단위로 저장되고 Chroma Cloud의 Optimistic Concurrency Control이 한 페이지가 부분적으로 기록된 상태로 노출되지 않도록 보호합니다.

기존 트랜잭션이 추론 비용을 버리는 이유

Foundation의 한 배치 처리는 여러 분이 걸릴 수 있고, 에이전트의 read set은 미리 주어지지 않은 채 검색과 추론을 거쳐 발견됩니다. Chroma Cloud의 OCC는 커밋 시점에 읽은 데이터의 변경 여부를 검증하므로, 수분 동안 실행된 작업이 마지막에 충돌하면 전체 트랜잭션을 중단하고 처음부터 다시 추론해야 합니다. 데이터베이스 트랜잭션은 같은 코드를 밀리초 안에 재실행할 수 있지만, 에이전트는 페이지 탐색과 판단을 다시 수행하면서 토큰과 지연 시간을 다시 지불하므로 원자성보다 살아남은 추론의 비율인 Goodput을 보존하는 편이 중요합니다.

Fission의 잠금과 조기 커밋

Fission은 위키 전체의 원자성을 목표에서 제외하고 페이지별 원자성만 유지하는 Foundation의 동시성 제어 프로토콜입니다. 에이전트가 검색 결과를 받는 순간이 아니라 첫 페이지를 읽는 순간 배타적 잠금을 획득하고, 배치 도착 시각을 기준으로 wound-wait를 적용해 오래된 작업이 젊은 작업을 중단시키며, 중단된 작업은 원래 시각을 유지한 채 잠금을 풀고 재시도합니다. 핵심 차이는 중단을 롤백으로 처리하지 않는다는 점으로, 잠금이 해제될 때까지 완료된 페이지 변경은 그대로 커밋되고 Chroma Cloud가 그 내구성을 담당합니다.

부분 결과를 이어가는 에이전트의 역할

Fission은 중단된 작업의 일부 변경을 남기므로, 재시도하는 에이전트가 현재 위키 상태를 읽고 이미 처리된 내용을 판별할 수 있어야 합니다. Foundation은 TODO 도구를 사용해 작업 순서를 구성하며, 에이전트가 일반적으로 링크보다 본문을 먼저 작성하는 prefix-safe 패턴을 만들기 때문에 중간 상태가 대체로 유효하게 남습니다. 테스트에서는 Haiku 4.5와 Context-1을 검색 sub-agent로 사용한 구성이 위키 생성에 충분했으며, 한 trace는 source_ids를 대조해 이전 시도에서 이미 기록한 내용을 다시 쓰지 않는 판단을 내렸습니다.

충돌 빈도와 잠금 설계의 관찰

Fission에서도 잠금 충돌로 작업이 중단되는 상황은 발생하며, 충돌이 읽기 대기에서 생겼는지 쓰기 대기에서 생겼는지에 따라 후속 행동이 달라집니다. 약 39.7%의 wounded transaction은 이전 시도를 중단시킨 페이지를 읽거나 쓰는 과정에서 다시 방문했고, 재시도 중 기록된 페이지 수정의 28.2%는 중단 원인이 된 페이지와 prefix 또는 suffix를 공유했습니다. 이 결과는 일부 재시도가 충돌을 유발한 작업을 실제로 이어받는다는 뜻이며, reader-writer lock으로 바꾼 초기 실험에서는 wounding 비율이 더 높고 잠금 승격만으로 진행을 보장하기 어려웠습니다.

Git 기반 충돌 해결의 실패 사례

Foundation의 초기 구현은 파일시스템 추상화 위에 Git을 올려 위키 충돌을 해결했지만, 자연어 페이지를 다시 읽고 병합하는 과정에서 에이전트가 작업을 포기하는 문제가 컸습니다. 8번의 호출 중 3번은 반복 충돌 뒤 명시적으로 포기했고, 4번은 읽은 내용이 오래됐거나 다른 작업이 내용을 바꿔 재독이 필요하다는 이유로 포기했으며, 나머지 1번만 쓰기가 불필요하다고 올바르게 판단했습니다. 에이전트가

용어 해설

낙관적 동시성 제어(Optimistic Concurrency Control): — 여러 작업이 충돌 없이 진행된다고 가정한 뒤 커밋 시점에 읽은 데이터가 바뀌었는지 검증하는 방식입니다. 충돌이 확인되면 작업을 중단하고 다시 실행하지만, Foundation처럼 에이전트가 검색과 추론에 수분을 쓰는 환경에서는 이미 지불한 토큰과 추론 시간을 잃는 문제가 커집니다.
2단계 잠금(Two-Phase Locking): — 트랜잭션이 데이터를 읽거나 쓰기 전에 잠금을 획득하고, 작업이 끝날 때까지 잠금을 유지하는 동시성 제어 방식입니다. Fission은 페이지 단위 잠금과 wound-wait를 사용하지만, 충돌 시 전체 작업을 되돌리는 전통적 규칙 대신 이미 완료한 변경을 그대로 남깁니다.
Wound-Wait: — 잠금 요청 사이에 순서를 부여해 교착 상태를 막는 방식입니다. 오래된 트랜잭션이 젊은 트랜잭션이 보유한 잠금을 필요로 하면 젊은 작업을 중단시키고, 젊은 작업은 오래된 작업이 끝날 때까지 기다립니다. Fission에서는 중단된 작업의 변경을 롤백하지 않습니다.
선형화 가능 이력(Linearizable History): — 동시 요청이 실제로는 하나의 순서대로 처리된 것처럼 보이도록 각 연산의 결과를 정렬하는 일관성 모델입니다. Fission은 위키 전체를 하나의 원자적 트랜잭션으로 묶지 않지만, Chroma Cloud의 저장 계층을 통해 페이지 쓰기와 전체 이력의 순서를 안정적으로 유지합니다.
CRDT: — 여러 복제본이 독립적으로 갱신된 뒤 충돌 없이 하나의 상태로 수렴하도록 자료 구조에 특별한 결합 규칙을 넣는 방식입니다. Fission은 상태가 단조롭게만 증가해야 한다는 제약을 두지 않고, 모델이 기존 내용을 덮어쓰거나 철회할 수 있으므로 CRDT에 해당하지 않습니다.
Saga 패턴(Saga Pattern): — 긴 작업을 여러 단계로 나누고 각 단계가 완료될 때마다 커밋한 뒤, 실패하면 보상 작업으로 이전 효과를 되돌리는 분산 트랜잭션 방식입니다. Fission도 단계별 커밋을 활용하지만 보상 작업을 실행하지 않으며, 중단 시 이미 남은 변경을 후속 에이전트가 이어서 처리합니다.
Goodput: — 전체 처리량이 아니라 비용을 지불한 작업 중 최종 결과로 살아남은 작업의 비율을 뜻합니다. Foundation은 에이전트가 검색하고 추론하는 데 수분과 토큰을 소비하므로, 충돌 때마다 처음부터 다시 계산하는 대신 유효한 중간 변경을 보존해 Goodput을 높이는 데 초점을 둡니다.

기술

Foundation
Chroma Cloud
Fission
FoundationDB
Git
Haiku 4.5
Context-1
Optimistic Concurrency Control
wound-wait

언급된 리소스

문서원문 링크