AI 컨텍스트 효율성 실험: 왜 아키텍처가 컨텍스트 크기를 이겼는가

그림 1: 실험의 핵심 전환점: 컨텍스트 (context), 압축 (compaction), 지역성 (locality), 거버넌스 (governance), 복구 (recovery), 그리고 결론.

질문은 컨텍스트에 관한 것이었다

나는 내가 컨텍스트 (context) 실험을 수행하고 있다고 생각했다.

하지만 아니었다.

단지 그때까지는 그것을 알지 못했을 뿐이다.

실험은 매우 간단해 보이는 질문과 함께 시작되었다.

결과적으로 그것은 불완전한 질문이었다.

AI 보조 소프트웨어 개발 효율성을 실제로 구동하는 것은 무엇인가?

이것은 대부분의 엔지니어들이 AI 코딩 도구를 본격적인 업무에 사용한 후 결국 던지게 되는 질문이다. 처음에는 명백한 변수들이 모두 세션 (session) 내부에 존재한다. 얼마나 많은 컨텍스트 (context)를 사용할 수 있는가? 얼마나 빨리 소모되는가? 압축 (compaction) 이후에는 어떤 일이 발생하는가? 에이전트 (agent)가 작업을 계속할 수 있을 만큼 충분히 기억하는가? 장기 실행 세션 (long-running session)이 인수인계 (handoffs), 요약 (summaries), 그리고 중단 (interruptions)을 견뎌낼 수 있는가?

그것들이 처음에 관찰할 가치가 있었던 것들이었다. 작업은 합성 벤치마크 (synthetic benchmark)가 아닌 두 개의 실제 리포지토리 (repository)에서 진행되었다. Financial Portfolio Agent (FPA)와 Market Intelligence Lab (MIL)은 서로 다른 책임, 실제 검증 요구 사항, 그리고 확립된 리포지토리 경계 (repository boundaries)를 가지고 있었다. FPA는 가계 실행 현실성 (household execution realism), 포트폴리오 인텔리전스 (portfolio intelligence), 생존 가능성 포지셔닝 (survivability positioning), 그리고 결정론적 금융 의사 결정 지원 (deterministic financial decision support)을 처리했다. MIL은 시스템적 컨텍스트 (systemic context), 매크로 인텔리전스 (macro intelligence), 증거 품질 (evidence quality), 그리고 소스 계보 거버넌스 (source lineage governance)를 처리했다.

초기 멘탈 모델 (mental model)은 단순했다: 컨텍스트 (context)는 연료다. 만약 세션이 연료를 너무 많이 태워버리면 효율성이 떨어진다. 만약 압축 (compaction)이 충분한 상태 (state)를 보존한다면 효율성은 유지된다.

그 모델이 틀린 것은 아니었다. 단지 불완전했을 뿐이다.

실험은 결과적으로 47개의 마스터 관찰 결과가 포함된 복구된 데이터셋을 생성했다: 14개의 컨텍스트 (context) 관찰, 13개의 압축 (compaction) 이벤트, 6개의 기능 배치 (feature batch) 관찰, 7개의 모델 (model) 관찰, 그리고 12개의 복구 (recovery) 관찰이다. 덕분에 이야기는 초기에 증거를 확보할 수 있었다. 작업의 형태가 변했다는 것은 단순한 느낌이 아니었다. 설명이 어디서부터 움직이기 시작했는지 추적할 수 있는 충분한 텔레메트리 (telemetry)가 있었다.

그림 2: 컨텍스트 (context), 압축 (compaction), 피처 배치 (feature batch), 모델 (model) 및 복구 로그 (recovery logs) 전반에 걸쳐 복구된 관측 횟수.

실험이 끝날 무렵, 가장 강력하게 보존된 신호는 컨텍스트 크기가 아니었습니다. 그것은 아키텍처 국소성 (architectural locality)이었습니다. 놀라운 결과는 압축 (compaction)이 작동했다는 것이 아니었습니다. 놀라운 결과는 작업이 명확한 아키텍처적 거처 (architectural home)를 가질 때 AI가 작업하기 더 쉬운 시스템이 되었다는 점이었습니다.

이 실험은 컨텍스트 연구로 시작되었습니다. 그러나 아키텍처 연구로 끝났습니다.

첫 번째 단서는 연소 패턴 (Burn Pattern)이었다

첫 번째 유용한 증거는 수치적이었습니다. 컨텍스트 값들은 실험 전반에 걸쳐 보존되었으며, 이후 데이터셋으로 재구성되었습니다.

FPA는 26K, 66K, 100K, 133K, 161K, 194K, 219K를 포함한 컨텍스트 관측값을 복구했습니다. MIL은 38K, 50K, 125K, 153K, 166K, 179K, 192K, 205K, 217K, 228K, 240K를 포함한 관측값을 복구했습니다. 또한 MIL은 42.0K부터 205.0K까지 실행된 더 깔끔한 2세대 재구축 (Generation 2 rebuild) 시퀀스를 보존했습니다.

언뜻 보기에 이 숫자들은 이야기의 전부처럼 보입니다. 컨텍스트가 성장합니다. 세션이 무거워집니다. 압축 (compaction)이 이를 초기화합니다. 작업이 계속됩니다.

하지만 데이터는 신중하게 다뤄져야 했습니다. 복구된 FPA 값들은 관측된 마커 (observed markers)였으며, 완전한 시계열 (time series)이 아니었습니다. 일부 MIL 값들은 순서가 정해져 있었지만, 모든 값이 그런 것은 아니었습니다. 모든 지점에 대해 정확한 타임스탬프 (timestamp)가 보존되지는 않았습니다. 데이터셋은 부분적인 기록이 완전한 측정 시스템인 것처럼 가장하는 대신, 알 수 없는 값을 UNKNOWN으로 올바르게 유지합니다.

그 차이가 중요합니다. 소스 데이터가 불완전할 때 깔끔한 차트는 거짓말을 할 수 있습니다. 올바른 조치는 관측치를 관측치로서 보존하는 것이었습니다. 즉, 기술적인 이야기를 전달하기에는 충분하지만, 완전한 벤치마크 (benchmark)라고 주장하기에는 부족한 수준으로 유지하는 것이었습니다.

그림 3: 복구된 컨텍스트 (context) 관찰 결과. MIL Generation 2 시퀀스는 정렬되어 있으며, FPA 값은 관찰된 마커로서 보존되었습니다.

기간 (duration) 데이터도 마찬가지였습니다. 트랜스크립트 (transcript)는 1m 00s부터 6m 27s까지의 관찰된 작업 시간을 보존했지만, 모든 기능 (feature)에 대한 완전한 모델 대 기간 (model-to-duration) 매핑을 제공하지는 않았습니다. 다시 말하지만, 이로 인해 데이터는 유용한 텔레메트리 (telemetry)가 되었을 뿐, 통제된 비교 (controlled comparison) 대상은 아니었습니다.

그 후 데이터셋을 재구축해야 했습니다

가장 중요한 편집상의 발견 중 하나는 주요 기술적 발견 이전에 이루어졌습니다. 아카이브 (archive)는 결과물은 보존하고 있었지만, 그 결과물 뒤에 숨겨진 모든 관찰 값들을 보존하고 있지는 않았습니다.

이로 인해 재구성 (reconstruction) 과정을 거쳐야만 했습니다. 트랜스크립트 (transcript)가 1차 자료 (primary source)가 되었습니다. 목표는 이를 요약하는 것이 아니었습니다. 목표는 텔레메트리 (telemetry), 즉 컨텍스트 값 (context values), 압축 이벤트 (compaction events), 모델 관찰 (model observations), 기능 배치 관찰 (feature batch observations), 기간 관찰 (duration observations), 그리고 복구 이벤트 (recovery events)를 복구하는 것이었습니다.

위의 스코어카드 (scorecard)는 해당 과정의 결과물입니다. 이를 통해 작업은 기억 속에서 방어 가능한 데이터셋 (dataset)으로 옮겨졌습니다.

이것들은 복구된 관찰 값들이며, 완전한 실험 총계는 아닙니다. 이 경계가 바로 데이터셋이 유용한 이유입니다. 무엇이 보존되었고 무엇이 보존되지 않았는지를 명시하기 때문입니다.

가장 가치 있는 값 중 일부는 트랜스크립트 (transcript)에만 존재했습니다. FPA는 219K에서 26.7K로의 압축 전환 (compaction transition)을 보존했습니다. MIL은 240K에서 38K로의 전환을 보존했습니다. 또한 MIL은 42.0K부터 205.0K까지의 Generation 2 재구축 테이블 (rebuild table)을 보존했습니다. 아카이브는 압축 (compaction)이 연속성 (continuity)을 지원한다는 더 넓은 발견을 보존했지만, 트랜스크립트 (transcript)는 그 이야기에 구체적인 수치를 부여했습니다.

이 재구성을 통해 실험의 어조가 바뀌었습니다. 이는 다음 단계의 논의를 무시하기 어렵게 만들었습니다.

압축 (Compaction)은 작동했습니다

압축 (Compaction)은 중요한 테스트를 통과했습니다.

FPA는 219K에서 26.7K로 이동했습니다. MIL은 240K에서 38K로 이동했습니다. MIL은 또한 239K -> 42K로 축소된 압축 (Compaction) 관찰 결과와, 이어서 발생한 42K -> 205K의 재구축 범위 (rebuild span)를 유지했습니다.

이것은 진정한 연속성의 이야기입니다. 충분한 운영 상태 (operational state)가 채팅 외부에 존재한다면, 장기간 실행되는 AI 개발 프로세스는 방대한 양의 컨텍스트 (context)를 덜어내고도 계속 진행될 수 있습니다. 저장소 아티팩트 (Repository artifacts), 부트스트랩 노트 (bootstrap notes), 거버넌스 기록 (governance records), 검증 명령 (validation commands), 그리고 지속적인 문서화 (durable documentation)가 모두 중요합니다.

그림 5: 압축 (Compaction)은 두 저장소 모두에서 컨텍스트 크기를 눈에 띄게 초기화했지만, 정확한 압축 횟수는 알 수 없습니다.

하지만 바로 이 지점에서 실험의 흐름이 바뀌기 시작했습니다.

만약 압축 (Compaction)이 전체 설명이었다면, 주요 교훈은 운영적인 측면이었을 것입니다: 더 잘 요약하고, 깔끔하게 압축하며, 주의 깊게 재시작하라. 이것들은 좋은 관행이지만, 아카이브에서 나타난 가장 강력한 처리량 (throughput) 신호를 설명하지는 못했습니다.

압축 (Compaction)은 작업이 지속될 수 있도록 도왔습니다. 하지만 그것이 지배적인 처리량 동인 (throughput driver)으로 유지되지는 않았습니다.

이러한 차이점 덕분에 잘못된 교훈을 얻는 것을 방지할 수 있었습니다. 이 실험은 “컨텍스트 윈도우 (context window)가 클수록 작업이 빨라진다”라고 말하는 것이 아니었습니다. 또한 “압축 (Compaction)이 정답이다”라고 말하는 것도 아니었습니다. 압축 (Compaction)은 계속할 수 있는 공간을 만들어 주었지만, 왜 어떤 작업들은 이해하는 데 드는 비용이 계속 저렴하게 느껴지는지는 설명하지 못했습니다.

작업은 로컬 (local) 상태를 유지할 때 효율성을 유지했습니다.

전환점: 국소성 (Locality)이 신호가 되다

국소성 (locality)이라는 단어가 실험의 중심이 된 이유는, 이것이 컨텍스트 크기만으로는 설명할 수 없는 부분을 설명해주었기 때문입니다.

전환점은 미묘했습니다. 실험이 갑자기 새로운 이론을 발표하게 만든 단 하나의 특징은 없었습니다. 대신, 작업 과정에서 동일한 패턴이 계속해서 나타났습니다. 인접한 기능(feature)들은 이전 기능들 근처에 머물 때 완료하기가 더 쉬웠습니다. 파일, 테스트, 그리고 개념들이 이미 활성 작업 세트(active working set)의 일부일 때 검토(review)가 더 쉬웠습니다. 기능이 포트폴리오 로직(portfolio logic), 보고서 계약(report contracts), 또는 런타임 동작(runtime behavior)으로 넘어가지 않을 때 검증(validation) 범위가 더 좁게 유지되었습니다.

그 패턴은 단순한 컨텍스트(context) 수치보다 더 흥미로웠습니다. 컨텍스트 수치가 높은 세션이라도 다음 작업이 동일한 아키텍처적 이웃(architectural neighborhood)에 속해 있다면 여전히 원활하게 진행될 수 있었습니다. 반면, 새로 압축된 세션이라도 다음 작업이 너무 많은 관련 없는 도메인(domain)을 다시 불러와야 한다면 여전히 어려움을 겪을 수 있었습니다. 사용 가능한 컨텍스트의 양도 중요했지만, 작업의 형태(shape)가 더 중요했습니다.

작업이 일관된 아키텍처 영역 내에 머물 때, AI 에이전트(AI agent)가 새로 발견해야 할 요소는 줄어들었습니다. 관련 파일들이 서로 가까이 있었고, 개념들은 재사용되었으며, 테스트는 예측 가능했습니다. 위험 표면(risk surface)은 제한되었습니다. 검토자(reviewer)는 변경 사항이 적절한지 이해하기 위해 시스템 전체를 다시 불러올 필요가 없었습니다.

FPA에서 가장 명확한 사례는 파이프라인 메타데이터(Pipeline Metadata)였습니다. 반복되는 작업은 다음과 같은 소수의 파일 주위에 클러스터링(clustering)되었습니다:

app/pipeline/registry.py
app/pipeline/planner.py
app/pipeline/runner.py
tests/test_pipeline_registry.py
tests/test_pipeline_planner.py
tests/test_pipeline_runner.py

해당 클러스터는 발견 가능성(discoverability), 소유권 가시성(ownership visibility), 의존성 가시성(dependency visibility), 출력 가시성(output visibility), 계보 가시성(lineage visibility), 카테고리 조사(category inspection), 그리고 경계 조사(boundary inspection)와 관련된 기능들을 지원했습니다. 이러한 기능들은 유용했지만, 보고서 재설계(report redesign), CSV 스키마 변경(CSV schema changes), 포트폴리오 로직 변경(portfolio logic changes), 또는 런타임 실행 재설계(runtime execution redesign)를 요구하지 않았습니다.

이것이 아키텍처가 주는 교훈입니다. AI 에이전트는 코드에만 컨텍스트를 소비하는 것이 아닙니다. 불확실성(uncertainty)에 컨텍스트를 소비하고 있는 것입니다.

소유권(ownership)이 불분명할 때, 컨텍스트 소모(context burn)는 증가합니다. 검증 경로(validation path)를 알 수 없을 때, 컨텍스트 소모는 증가합니다. 기능(feature)이 여러 개념적 경계(conceptual boundaries)를 가로지를 때, 컨텍스트 소모는 증가합니다. 반면, 작업이 성숙한 지역성 클러스터(locality cluster) 내에 위치할 때, 에이전트는 동일한 정신적 지도(mental map)를 재사용할 수 있습니다.

아카이브(archive)가 수치적인 지역성 승수(locality multiplier)를 증명하는 것은 아닙니다. 지역성이 토큰 소모를 특정 퍼센트만큼 줄였다는 것을 보여주는 것도 아닙니다. 이 주장은 더 신중합니다. 보존된 실험 기록 내에서, 아키텍처적 지역성(architectural locality)이 지배적인 효율성 승수(efficiency multiplier)로 나타났다는 것입니다.

그림 6: 컨텍스트에 관한 질문이 아키텍처적 지역성에 대한 발견으로 전환되었습니다.

그 지점이 바로 실험이 주로 컨텍스트 창(context windows)에 관한 것이기를 멈춘 지점이었습니다.

그것은 코드베이스의 형태(codebase shape)에 관한 것이 되었습니다.

경계가 있는 컨텍스트(Bounded Contexts)가 사고 비용을 낮추었다

지역성(locality)이 가시화되자, 다음 질문은 명확했습니다. 무엇이 일부 영역을 지속적으로 레버리지(leverage)를 창출할 수 있을 만큼 충분히 지역적으로 만들었는가?

그 답은 경계가 있는 컨텍스트(bounded contexts)였습니다.

파이프라인 메타데이터(Pipeline Metadata)는 가장 명확한 FPA 사례였습니다. 이는 일관된 소유권(ownership), 결정론적인 읽기 전용 쿼리 동작(deterministic read-only query behavior), 기능 배치 전반에 걸친 안정적인 인접성(adjacency), 그리고 파이프라인 실행으로부터의 명확한 분리를 갖추고 있었습니다. 이는 시스템의 실행 방식을 재설계하지 않고도 시스템을 더 쉽게 조사(inspect)할 수 있게 만들었습니다.

그 차이는 미묘하지만 중요합니다. 경계가 있는 컨텍스트(bounded context)는 단순한 디렉터리가 아닙니다. 그것은 전체 시스템을 시야에 끌어들이지 않고도 관련된 질문에 답할 수 있는 장소입니다.

파이프라인 메타데이터는 다음과 같은 질문에 답했습니다:

이 출력물의 소유권은 누구에게 있는가?
이 카테고리에 의존하는 것은 무엇인가?
어떤 모듈이 이 파이프라인 영역에 참여하는가?
어떤 출력물이 공유되는가?
어떤 다운스트림(downstream) 카테고리가 영향을 받는가?

각각의 새로운 조사(inspection) 기능은 이후의 조사 기능들을 더 쉽게 만들었습니다. 작업이 자신의 이전 작업 근처에 머물렀기 때문에 작업의 효과가 복리로 작용했습니다.

실험 기록은 또한 Export Quality Hardening을 MIL의 경계 컨텍스트 (bounded context)로 식별합니다. FPA 아카이브에는 해당 워크스트림 (workstream)을 동일한 수준의 상세도로 분석할 수 있는 충분한 MIL 내부 증거가 포함되어 있지 않으므로, 해당 경계는 명시적으로 유지될 필요가 있습니다. 실험 기록은 Export Quality Hardening이 경계 컨텍스트 (bounded context)로 나타났다고 명시할 수 있습니다. FPA 로컬 증거로는 MIL의 내부 구조를 증명할 수 없습니다.