병렬 실행 시스템에서의 상태 드리프트(State Drift) - 정의와 해결 방법

크래시(Crash)보다 더 나쁜 버그 카테고리가 있습니다. 크래시는 소란스럽습니다. 실행을 중단시키고, 에러를 발생시키며, 무언가 잘못되었고 대략 어디인지 알려줍니다. 이를 찾아 수정하고 다음 단계로 넘어갈 수 있습니다. 하지만 상태 드리프트(State Drift)는 조용합니다. 실행은 계속됩니다. 로그는 깨끗해 보입니다. 개별 노드(Node)들은 성공합니다. 페이로드(Payload)도 유효합니다. 그럼에도 불구하고 시스템은 점진적이고 미묘하게, 의미론적으로(Semantically) 틀어지며, 구조적으로는 올바르지만 의미상으로는 망가진 출력을 생성합니다. 이것이 바로 병렬 실행 시스템(Parallel Execution Systems)이 공유 상태(Shared State)에 대한 제어력을 상실했을 때 발생하는 현상입니다. 그리고 일단 대규모 환경에서 이를 경험하고 나면, 분산 시스템(Distributed Systems)을 구축하는 방식에 대한 사고방식 자체가 완전히 바뀌게 됩니다.

상태 드리프트(State Drift)의 실체
대부분의 개발자는 상태 관리(State Management)를 로컬 문제로 접합니다. 단일 스레드(Single Thread), 단일 프로세스(Single Process), 단일 진실 공급원(Single Source of Truth). 상태는 가변적(Mutable)이지만, 변경(Mutation)은 순차적입니다. 항상 하나의 결정적인 현실 버전이 존재합니다. 병렬성(Parallelism)은 이러한 가정을 완전히 깨뜨립니다. 여러 실행 분기(Execution Branches)가 동시에 실행되면서 공유 컨텍스트(Shared Context)를 읽고, 변환하고, 쓰는 과정에서 "상태(State)"는 더 이상 단일한 진실이 아니며 파편화된 타임라인처럼 작동하기 시작합니다. 서로 다른 분기들이 동일한 객체의 서로 다른 버전을 보유하게 됩니다. 각 분기는 자신이 최신 상태에서 작업하고 있다고 믿습니다. 어느 것도 정확히 틀린 것은 아닙니다. 하지만 어느 것도 완전히 옳은 것도 아닙니다. 그 결과가 바로 상태 드리프트(State Drift)입니다. 즉, 시스템의 내부 세계 모델이 일관되고 응집력 있는 현실로부터 점진적으로 발산(Divergence)하는 현상입니다. 소규모에서는 드리프트가 관리 가능한 수준입니다. 개별적인 불일치는 사소한 이상 징후로 나타납니다. 하지만 수백 개의 병렬 분기, 장기 실행 워크플로우(Long-running Workflows), 복잡한 에이전트 시스템(Agent Systems)에 걸친 대규모 환경에서는 드리프트가 기하급수적으로 누적됩니다. 한 분기에서의 미묘한 불일치로 시작된 문제는 하류(Downstream)의 결정으로 전파되고, 집계(Aggregation)를 오염시키며, 결국 기술적으로는 올바르게 실행되고 있지만 의미론적으로는 망가진 시스템을 만들어냅니다.

발현 방식 (How It Manifests)

상태 드리프트 (State Drift)의 가장 교활한 특성은 그것이 마치 정상적인 동작처럼 보인다는 점입니다. 제가 600개 이상의 노드로 구성된 AI 오케스트레이션 (Orchestration) 인프라를 구축했을 때, 상태 드리프트는 에러를 통해 자신을 드러내지 않았습니다. 대신 다음과 같은 기이한 현상들로 자신을 알렸습니다:

• 중복된 추론 체인 (Duplicated reasoning chains): 에이전트들이 이미 완료된 하위 작업 (Subtasks)을 다시 해결함. 이는 그들이 가진 컨텍스트 (Context) 버전에 이전 해결 결과가 포함되어 있지 않았기 때문입니다.
• 오래된 요약본이 풍부한 컨텍스트를 덮어씀 (Stale summaries overriding richer context): 압축 분기 (Compression branch)가 늦게 종료되면서, 병렬 분기 (Parallel branch)가 이미 생성해 놓은 더 풍부한 요약본 위에 더 오래되고 충실도가 낮은 요약본을 작성함.
• 더 이상 존재하지 않는 엔티티 (Entities)에 대한 하위 참조: 분기들이 자신들이 인지하지 못하는 사이에 다른 동시 실행 분기에 의해 재구조화된 컨텍스트 그래프 (Context graphs)를 기반으로 의사결정을 내림.
• 병합 노드 (Merge nodes)가 의미론적으로 오래된 상태를 조용히 수락함: 모든 스키마 (Schema) 검사를 통과하여 구조적으로는 유효하지만, 이전 실행 윈도우 (Execution window)의 컨텍스트를 담고 있는 페이로드 (Payloads)가 올바른 상태를 오래된 상태로 조용히 덮어씀.

실행 로그 (Execution logs)는 기술적으로는 정확했습니다. 모든 노드가 성공했고, 모든 페이로드가 검증되었습니다. 시스템은 충돌 (Crashing)하고 있지 않았습니다. 다만 드리프트 (Drifting)하고 있었을 뿐입니다.

그리고 이 모든 증상 아래에 깔린 진짜 문제는 동일했습니다. 바로 병렬 실행 분기들 사이의 통제되지 않는 가변성 (Uncontrolled mutability)이었습니다. 병렬성 (Parallelism) 자체가 문제는 아니었습니다. 문제는 여러 동시 분기들이 규율 없이 공유 상태 (Shared state)를 변경하도록 허용했다는 점이었습니다.

미숙한 해결책들과 그것이 실패하는 이유 (The Naive Fixes and Why They Fall Short)

상태 드리프트에 직면했을 때 가장 먼저 드는 생각은 동기화 (Synchronization)를 추가하는 것입니다:

• 지연된 병합 (Delayed merges)
• 대기 노드 (Wait nodes)
• 실행 장벽 (Execution barriers)
• 실행 의존성 체인 (Execution dependency chains)
• 임계 경로에 대한 강제 순차 실행 (Forced sequencing for critical paths)

이러한 방법들은 도움이 됩니다. 충돌 빈도를 줄여주고, 가장 명백한 레이스 컨디션 (Race conditions)을 방지해 줍니다. 하지만 드리프트를 완전히 제거하지는 못합니다. 왜냐하면 각 분기들은 여전히, 시작 시점에는 유효했지만 이후 동시 실행에 의해 수정되어 버린 상태에 대해 '오래된 로컬 가정 (Stale local assumptions)'을 품고 있기 때문입니다.

브랜치(Branch)가 병합될 때 동기화(Synchronization)를 수행할 수는 있지만, 이는 각 브랜치가 실행되는 동안 어떤 상태에서 작동하고 있었는지에 대한 문제를 해결하지는 못합니다. 동기화는 타이밍(Timing)을 제어할 뿐, 일관성(Consistency)을 제어하는 것이 아닙니다. 진정한 해결책은 더 근본적인 것, 즉 분산 상태 규율(Distributed-state discipline)을 필요로 합니다.

실제로 효과가 있는 다섯 가지 전략

버전 관리된 컨텍스트 객체 (Versioned context objects)
첫 번째 의미 있는 해결책은 상태 버전 관리(State versioning)를 암시적(Implicit)인 방식이 아닌 명시적(Explicit)인 방식으로 만드는 것이었습니다. 모든 주요 상태 객체는 계보 메타데이터(Lineage metadata)를 포함하기 시작했습니다: 버전 ID(Version ID), 부모 실행 참조(Parent execution reference), 변이 깊이 카운터(Mutation depth counter), 그리고 타임스탬프(Timestamp)가 그것입니다. 브랜치들은 자신이 상태를 소유하고 있다고 가정하는 것을 중단했습니다. 대신, 명시적으로 식별된 상태의 버전을 기반으로 작동했습니다. 그 즉각적인 효과는 가시화였습니다. 모든 상태 객체가 버전을 가지게 된 순간, 숨겨져 있던 엄청난 양의 드리프트(Drift)가 눈에 보이게 되었습니다.

명시적 화해 계층 (Explicit reconciliation layers)
여러 브랜치(Branch)가 동일한 상태 객체(State object)에 대해 서로 상충하는 풍부화(Enrichment)를 생성하게 되면, 이를 병합할 원칙적인 방법이 필요합니다. "마지막에 쓴 데이터가 승리한다(Last write wins)"는 화해 전략이 아니라, 전략을 포기하는 것입니다. 명시적 화해 단계(Explicit reconciliation passes)는 다음과 같은 작업을 수행합니다:

• 브랜치 출력물을 필드별로 비교
• 명시적인 우선순위 규칙 또는 신뢰도 점수(Confidence scores)를 사용하여 충돌 해결
• 구조화된 필드를 통째로 병합하는 대신 선택적으로 병합
• 신뢰도가 낮은 변이(Mutation)가 신뢰도가 높은 상태를 오염시키도록 허용하는 대신 폐기

이는 성능 측면에서 비용이 많이 드는 작업입니다. 실행 그래프(Execution graph)에 지연 시간(Latency)과 복잡성을 추가합니다. 하지만 브랜치들이 서로의 출력물을 조용히 덮어쓰도록 방치하는 대안은, 빠르지만 틀린 시스템을 만들어낼 뿐입니다. 화해의 성능 비용은 정확성을 위한 비용입니다.

승격 전 상태 유효성 검사 (State validity checks before promotion)
상당한 양의 불안정성은 특정 실패 모드, 즉 유효한 컨텍스트(Context)로 위장한 불완전한 부분 쓰기(Incomplete partial writes)에서 발생했습니다. 브랜치가 상태 객체 쓰기를 시작했다가 중간에 실패하면, 스키마 검증(Schema validation)은 통과하지만 의미론적으로는 불완전한 부분적 구조를 남기게 됩니다. 하위 브랜치들은 이 부분적인 상태를 읽고, 이를 바탕으로 결론을 도출하며, 오염을 앞으로 전파합니다.

해결책은 승격 게이트(Promotion gate)였습니다. 어떤 상태 객체라도 공유 컨텍스트에 진입하기 전에, 다음과 같은 사항을 확인하는 구조적 검증을 거쳐야 했습니다:

• 스키마 무결성 (Schema integrity)
• 의존성 참조 유효성 (Dependency reference validity): 참조된 모든 엔티티가 현재 컨텍스트 그래프에 실제로 존재하는지 확인
• 고립된 링크 탐지 (Orphaned link detection): 삭제된 엔티티에 대한 참조
• 부분 쓰기 탐지 (Partial write detection): 구조적으로는 존재하지만 의미론적으로 불완전한 객체

부분적인 컨텍스트 객체는 병합되는 대신 격리(Quarantined)되었습니다. 유효한 상태를 생성하는 데 실패한 브랜치는 유효한 상태 업데이트가 아닌, 브랜치 실패로 처리되었습니다.

실행 단계의 시간적 격리 (Temporal isolation of execution phases)

마지막이자 아마도 가장 중요한 전략은 특정 유형의 작업들이 동일한 활성 변이 윈도우(active mutation window) 내에 공존해서는 안 된다는 점을 인식하는 것이었습니다. 추론(Reasoning), 보강(Enrichment), 메모리 압축(Memory compression), 그리고 오케스트레이션(Orchestration) 결정은 각각 근본적으로 다른 방식으로 상태(state)를 조작합니다. 이들을 공유 가능한 가변 상태(shared mutable state)에 대해 동시에 실행하도록 허용하는 것은 불일치를 초래하는 지름길입니다.

해결책은 이들을 엄격한 승격 순서(promotion order)를 가진 격리된 실행 단계로 분리하는 것이었습니다:

1. 추론(Reasoning) 단계가 완료되어 버전이 지정된 출력물을 생성합니다.
2. 보강(Enrichment) 단계가 추론 출력물을 읽어 보강된 스냅샷(enriched snapshots)을 생성합니다.
3. 메모리 압축(Memory compression)은 라이브 상태(live state)가 아닌, 확정된 보강 상태(finalized enriched state) 위에서 실행됩니다.
4. 오케스트레이션(Orchestration) 결정은 완전히 조정되고 승격된 상태(fully reconciled, promoted state)를 바탕으로 내려집니다.

단계 간 오염(Cross-phase contamination)이 급격히 감소했습니다. 시스템은 이전과는 다른 방식으로 예측 가능해졌습니다. 이는 개별 구성 요소가 변했기 때문이 아니라, 구성 요소들 사이의 시간적 경계(temporal boundaries)가 명시적이고 강제되었기 때문입니다.

가장 어려운 부분: 관찰 가능성 (Observability)

위의 모든 내용은 드리프트(drift)를 줄이는 방법에 대해 설명합니다. 하지만 드리프트를 수정하기 전에, 먼저 그것을 볼 수 있어야 합니다. 이것이 진정으로 어려운 부분입니다. 대규모 환경에서 상태 드리프트를 디버깅하는 것은 분산된 인지(distributed cognition)를 디버깅하는 것처럼 느껴집니다. 당신은 단일 실패를 추적하는 것이 아닙니다. 시간의 흐름에 따라 비동기 추론 계층(asynchronous reasoning layers)을 통해 전파되는 아주 미세한 불일치들을 추적하는 것입니다.

가장 까다로운 버그는 모든 개별 노드가 성공했고, 모든 페이로드(payload)가 검증되었음에도 불구하고, 전체 시스템이 의미론적으로 잘못된(semantically wrong) 상태가 되는 경우입니다. 표준 로깅(Standard logging)만으로는 충분하지 않습니다. 다음과 같은 질문에 답할 수 있어야 합니다:

• 이 브랜치는 이 상태 객체의 어떤 버전 위에서 작동했는가?
• 이 객체의 이 필드는 마지막으로 언제 변경되었으며, 어떤 브랜치가 이를 변경했는가?
• 이 출력물의 전체 계보(lineage)는 무엇인가? 즉, 여기에 도달하기까지 거친 모든 변환 과정은 무엇인가?

이 정도 수준의 관찰 가능성(observability) 없이는 직관에 의존하여 디버깅을 해야 합니다. 하지만 관찰 가능성이 확보되면 드리프트는 추적 가능해지며, 추적 가능한 문제는 해결 가능한 문제가 됩니다.

이러한 문제들을 통해 구축된 사고 모델의 전환(Mental Model Shift)은 병렬 시스템(Parallel Systems)에 대한 저의 근본적인 생각을 바꾸어 놓았습니다. 대부분의 개발자가 처음 갖는 직관은 '병렬성은 속도에 관한 것이다'라는 점입니다. 더 빨리 끝내기 위해 작업들을 동시에 실행한다는 것이죠. 이는 어느 정도 사실입니다. 하지만 상태 드리프트(State Drift)가 실질적인 문제가 되는 복잡성 단계에 이르면, 병렬성은 인식론(Epistemology), 즉 시스템의 각 분기(Branch)가 무엇을 알고 있는지, 그것을 언제 알게 되었는지, 그리고 자신의 지식이 최신 상태라고 얼마나 확신할 수 있는지에 관한 것이 됩니다. 상태 드리프트는 시스템의 서로 다른 부분들이 이러한 질문들에 대해 일관되지 않은 답변을 가질 때 발생합니다. 해결책은 주로 동기화 프리미티브(Synchronization Primitives)나 잠금 메커니즘(Locking Mechanisms)에 관한 것이 아닙니다. 그것은 모든 구성 요소가 "나는 어떤 버전의 현실 위에서 작동하고 있는가, 그리고 그것을 어떻게 아는가?"라는 질문에 대해 명확하고, 명시적이며, 신뢰할 수 있는 답변을 가질 수 있도록 시스템을 설계하는 것에 관한 것입니다. 이것을 제대로 해낸다면 병렬 시스템은 예측 가능해집니다. 이를 잘못 처리한다면, 기술적으로는 정확하지만 의미론적으로는 망가진(Semantically Broken) 시스템을 디버깅하는 데 아주 긴 시간을 소비하게 될 것입니다.

저자: Nidhish Akolkar. 저는 인도 푸네(Pune)에 기반을 둔 컴퓨터 공학도이자 AI 시스템 엔지니어입니다. 저는 자율형 멀티 에이전트 AI 인프라를 구축하며, 투자를 받은 기관 AI 및 ML 연구소를 운영하고 있습니다.
GitHub: github.com/nidhishakolkar01-lgtm
LinkedIn: linkedin.com/in/nidhish-a-akolkar-30a33238b