침묵의 실패, 파트 2: 코드는 괜찮지만 기반이 부패했을 때

내부 아키텍처(Internal architecture)는 건전하지만, 실행 환경(Execution environment)이 에이전트(Agent)를 조용히 저하시킬 때

요약 (TL;DR)

파트 1에서는 에이전트 메모리 아키텍처 내부의 다섯 가지 침묵의 실패 — 즉, 내부적 저하(Internal degradation)를 다루었습니다. 이번 파트에서는 그 아래에 존재하는 것들, 즉 실행 환경(Execution environment), 컨텍스트 윈도우(Context window) 내 메모리의 위치, 그리고 에이전트가 실제로 보는 것을 왜곡하는 구조적 불균형(Structural imbalances)을 다룹니다. 코드는 정확할 수 있습니다. 하지만 그 코드가 실행되는 기반(Ground)은 여전히 부패할 수 있습니다.

서론

당신은 파트 1의 해결책들을 적용했습니다. 삭제 대신 가중치 감쇠 (Weight decay)를 사용했습니다. 절단 (Truncation) 대신 요약 (Summarization)을 사용했습니다. 매 요청마다 새로운 프롬프트 (Prompt)를 사용했습니다. 배포 전 엔드 투 엔드 테스트 (End-to-end tests)를 수행했습니다.

시스템은 깨끗해 보입니다.

하지만 — 여전히 무언가가 표류합니다. 천천히. 일관성 없이. 재현하기 어렵게.

문제는 더 이상 코드에 있지 않습니다. 코드가 실행되는 기반에 있습니다.

실패 6: 런타임 환경의 부패 (Runtime Environment Decay)

재시작 없이 몇 주 동안 지속적으로 실행되는 시스템은 축적되도록 설계되지 않은 상태(State)를 축적하게 됩니다.

실제 사례: 우리가 배포한 어시스턴트 중 하나가 컨텍스트(Context) 내에서 중복 메시지를 보고하기 시작했습니다. 진단 결과는 아무것도 나타내지 않았습니다 — 데이터베이스에는 중복이 없었고, 검색 로직 (Retrieval logic)은 정확했으며, 코드는 변경되지 않았습니다. 시스템을 재시작하자 문제가 완전히 해결되었습니다. 그리고 몇 주가 지나기 전까지는 다시 발생하지 않았습니다.

원인은 에이전트의 코드에 있지 않았습니다. 실행 환경 (Execution environment)에 있었습니다. 프로세스 수준의 캐시 (Process-level caches), 오래된 런타임 상태 (Stale runtime state), 몇 주간의 연속 운영으로 인한 부산물(Artifacts) — 이 모든 것들은 애플리케이션 수준의 진단으로는 보이지 않았습니다.

패턴 이름: 런타임 부패 (Runtime decay). 실행 환경은 조용히 노화됩니다. 결정론적 (Deterministic)이었던 동작이 확률론적 (Probabilistic)으로 변합니다 — 이는 버그 때문이 아니라, 축적된 런타임 상태 때문입니다.

증상:

→ 재시작 시 사라지는 오류들
→ 깨끗한 환경에서는 재현할 수 없는 동작
→ "어제까지는 잘 됐는데"
...

이것이 생각보다 중요한 이유:

정기적인 시스템 유지보수 과정에서 운영 체제(Operating Systems), 의존성(Dependencies), 그리고 런타임 환경(Runtime Environments)은 업데이트를 통해 진화합니다. 커널 패치(Kernel patches)는 시스템 호출(System call) 동작을 변경합니다. 패키지 업데이트는 공유 라이브러리(Shared libraries)를 수정합니다. Python 환경은 이전 버전으로부터 축적된 캐시된 바이트코드(Cached bytecode)를 쌓아둡니다. 각각의 변화는 미미합니다. 하지만 수주에 걸쳐 축적된 변화는 그렇지 않습니다.

환경 자체가 버그입니다.

올바른 접근 방식:

먼저 문제가 재현 가능한 동안 진단 데이터(Diagnostics)를 수집하십시오. 로그(Logs), 프로세스 상태(Process state), 캐시 크기(Cache sizes), 메모리 사용량(Memory usage) 등이 해당됩니다. 재시작은 런타임 상태(Runtime state)를 정리하지만, 증거 또한 파괴합니다. 먼저 진단하고, 그 다음에 재시작하십시오.

1. 코드 변경 없이 동작이 변하는가?
   → 진단 데이터 수집 (로그, 프로세스 상태, 캐시)
   → 코드 디버깅 전 재시작 수행
...

중요한 주의사항: 재시작은 축적된 런타임 상태를 정리합니다. 하지만 이미 영구 저장소(Persistent storage)에 기록된 손상된 데이터베이스(Corrupted databases), 오염된 임베딩(Poisoned embeddings), 깨진 요약(Broken summaries), 또는 유효하지 않은 레코드(Invalid records)를 복구하지는 못합니다. 재시작 후에도 문제가 지속된다면, 그것은 환경의 문제가 아니라 데이터의 문제입니다.

실패 7: 주입 위치 맹목성 (Injection Position Blindness)

에이전트(Agent)는 컨텍스트(Context)를 전달받습니다. 적절한 가중치가 부여되고, 중복이 제거되었으며, 최신 상태인 모든 올바른 메모리들이 그곳에 있습니다.

하지만 그것들이 프롬프트(Prompt) 내의 어디에 위치해 있습니까?

트랜스포머 어텐션(Transformer attention)에 관한 연구 — 특히 Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (2023) — 에 따르면 모델은 컨텍스트를 불균등하게 처리한다는 것이 입증되었습니다. 컨텍스트 창(Context window)의 시작 부분과 끝 부분은 중간 부분보다 더 많은 어텐션(Attention)을 받습니다. 긴 컨텍스트에서는 데드 존(Dead zone) — 존재하지만 감소된 집중도로 처리되는 콘텐츠 — 이 발생합니다.

컨텍스트 창 (Context window):
[시작 부분]    ← 높은 어텐션 ✅
[...중간...] ← 어텐션 감소 🟡
...

만약 가장 중요한 메모리가 긴 프롬프트의 중간에 위치한다면 — 그 메모리는 존재하지만, 에이전트는 이를 낮은 집중도로 처리합니다. 이것은 검색(Retrieval)의 실패가 아닙니다. 위치 선정(Positioning)의 실패입니다.

패턴 명칭: 위치 맹목성 (Position blindness). 잘못된 위치에 있는 올바른 콘텐츠는 영향력을 상실합니다.

올바른 해결책: 위치 인식 주입 (position-aware injection).

def inject_memories(memories: list, system_prompt: str) -> str:
    # 중요도에 따라 정렬
    critical = [m for m in memories if m["importance"] >= 0.8]
...

원칙: 중요한 것을 주의 (attention)가 머무는 곳에 배치하십시오. 이는 복잡한 엔지니어링을 요구하지 않습니다. 단지 컨텍스트 창 (context window)이 어떻게 구조화되어 있는지에 대한 인식만 있으면 됩니다.

참고: 이 효과의 심각성은 모델, 컨텍스트 길이 (context length), 그리고 콘텐츠 유형에 따라 달라집니다. 짧은 컨텍스트 (4K 토큰 미만)의 경우 위치의 중요성이 덜합니다. 더 긴 컨텍스트 (16K 이상)의 경우, 그 효과가 점점 더 눈에 띄게 나타납니다. 사용 중인 특정 모델과 컨텍스트 크기로 테스트해 보십시오.

실패 8: 레코드 크기 불균형 (Record Size Imbalance)

메모리 데이터베이스에 200개의 레코드가 포함되어 있습니다. 검색 (Retrieval) 과정에서 가중치에 따라 상위 10개를 선택합니다.

그 10개 중 하나가 1800 토큰 길이에 달합니다.

전체 컨텍스트 예산:    4000 토큰
하나의 대형 레코드:    1800 토큰  (45%)
나머지 9개 레코드:     2200 토큰  (55%)

단 하나의 장황한 메모리가 컨텍스트 예산의 거의 절반을 소비하여, 잠재적으로 관련이 있을 수 있는 다른 9개의 레코드를 밀어냅니다. 이 대형 레코드가 반드시 더 중요하지 않을 수도 있습니다. 단지 크기가 클 뿐입니다.

패턴 명칭: 크기 치환 (size displacement). 레코드의 중요도가 아닌 레코드의 크기가 컨텍스트 점유율을 결정합니다.

이는 시간이 흐름에 따라 자연스럽게 발생합니다. 에이전트가 긴 분석적 응답을 생성합니다. 이것이 메모리로 저장됩니다. 몇 달 후, 그 하나의 장황한 레코드는 단순히 크다는 이유만으로, 더 짧지만 더 관련성이 높은 수십 개의 메모리보다 지속적으로 컨텍스트 공간을 차지하게 됩니다.

올바른 해결책: 검색 시 토큰 인식 예산 책정 (token-aware budgeting). 여기 간단한 탐욕 알고리즘 (greedy approach) 방식이 있습니다:

def retrieve_within_budget(memories, token_budget=2000):
    """토큰 예산을 준수하면서 중요도에 따라 메모리를 선택합니다.

...

모든 레코드는 크기에 의해 제약받으면서 중요도를 바탕으로 경쟁합니다. 1800 토큰짜리 레코드도 여전히 선택될 수 있지만, 다른 레코드들로부터 뺏어오는 공간을 정당화할 만큼 충분히 중요할 때만 가능합니다.

또한, 쓰기 시점(write time)에 레코드 길이를 정규화(normalizing)하는 것을 고려하십시오. 메모리가 합리적인 길이를 초과할 경우(구체적인 임계값은 아키텍처와 컨텍스트 예산에 따라 다름), 저장하기 전에 요약(summarize)해야 하며, 절대 잘라내기(truncate)해서는 안 됩니다. 이는 크기 치환(size displacement)이 애초에 누적되는 것을 방지합니다.

종합하기: 쓰기 품질 (Write Quality)

파트 1과 파트 2는 명시적으로 언급할 가치가 있는 공통된 맥락을 공유합니다: 메모리에 무엇을 쓰느냐는 그것을 어떻게 읽느냐만큼 중요합니다.

파트 1에서는 컨텍스트 중요도 점수(contextual importance scoring)를 소개했습니다. 이는 메시지 길이가 아닌 콘텐츠 유형을 기반으로 중요도를 계산하는 방식입니다. 파트 2에서는 쓰기 시점에 고려해야 할 두 가지 사항을 추가합니다:

크기 정규화 (Size normalization): 요약 없이 저장된 긴 레코드는 검색 시 크기 치환(size displacement)을 유발합니다 (실패 사례 8).

환경 인지 (Environmental awareness): 코드가 정확하더라도 누적된 런타임 상태(runtime state)가 기록되는 내용을 오염시킬 수 있습니다 (실패 사례 6).

요약 품질 (Summarization quality): 핵심 사실을 놓치거나, 이름을 누락하거나, 감정적 맥락을 평탄화하는 등의 부실한 요약은 그 자체로 장기적인 오염의 원인이 됩니다. 요약본은 향후 검색 시 원본을 대체하게 됩니다. 만약 요약이 부정확하다면, 이를 기반으로 구축되는 모든 미래의 상호작용은 그 부정확함을 상속받게 됩니다. 요약은 단순히 길이를 줄이는 것이 아니라 의미를 보존해야 합니다.

쓰기 계층(write layer)은 첫 번째 방어선입니다. 낮은 품질의 데이터가 부실한 점수 산정, 정규화 누락, 또는 망가진 요약을 통해 데이터베이스에 유입된다면, 그 어떤 다운스트림 최적화(downstream optimization)로도 이를 보상할 수 없습니다. 소스(source) 단계에서 깨끗하게 유지하십시오.

재시작 시 컨텍스트 보호하기

재시작은 필요합니다. 하지만 보호되지 않은 재시작은 그 자체로 침묵의 실패(silent failure)의 원인이 됩니다. 상태(state)를 저장하지 않고 에이전트 프로세스가 종료되면, 현재의 대화 컨텍스트(conversation context)가 손실됩니다. 에이전트는 마지막 대화에 대한 기억 없이 재개됩니다. 사용자는 이를 알아차리고, 신뢰는 무너집니다.

패턴: 모든 재시작 주기를 감싸는 두 개의 스크립트.

**우아한 종료 (Graceful shutdown)**는 중단하기 전에 마지막 상태를 저장합니다:

중단 스크립트 (Stop script):
1. SIGTERM 전송 (SIGKILL 아님) → 에이전트가 신호를 포착함
2. 에이전트가 마지막 메시지들을 데이터베이스에 기록함
...

핵심적인 세부 사항은 종료 기록 자체가 메모리의 일부가 된다는 점입니다. 에이전트가 재시작될 때, 자신이 언제 중단되었는지를 알게 됩니다. 이는 에이전트가 소실된 시간에 대해 아무런 설명도 할 수 없는 혼란스러운 공백을 방지합니다.

**진단적 시작 (Diagnostic startup)**은 첫 번째 메시지를 보내기 전에 모든 것을 검증합니다:

시작 스크립트 (Start script):
1. 실행 환경 확인 (conda, 의존성 (dependencies))
2. 설정 확인 (API 키, 경로)
...

시작 스크립트는 절대 충돌(crash)하지 않습니다. 만약 데이터베이스가 누락되었다면, 어떤 것이 누락되었는지와 어떻게 재생성해야 하는지를 알려줍니다. 만약 의존성 (dependency)이 깨졌다면, 어떤 패키지를 설치해야 하는지 알려줍니다. 이 스크립트는 반쯤 기능하는 에이전트를 시작하지 않습니다. 완전히 검증된 시스템을 시작하거나, 무엇이 잘못되었는지 설명할 뿐입니다.

이것이 컨텍스트 보호 (context protection)에 중요한 이유:

우아한 종료 (graceful shutdown)가 없다면, 모든 재시작은 대화의 흐름을 중간에 끊어버립니다. 진단적 시작 (diagnostic startup)이 없다면, 에이전트는 메모리 계층이 누락된 상태로 실행될 수 있으며, 무엇을 잃었는지도 모른 채 조용히 그 상태로 작동하게 됩니다.

이 두 스크립트가 결합되어 재시작을 컨텍스트를 손상시키는 사건에서 컨텍스트를 보존하는 사건으로 변화시킵니다. 에이전트는 다시 재개할 것임을 인지한 상태로 종료하며, 모든 것이 온전함을 인지한 상태로 시작합니다.

전체 진단 체크리스트

두 기사 전체를 관통하는 전체 보호 세트:

메모리 아키텍처 (Memory Architecture) (파트 1 — 내부적):

□ 삭제가 아닌 주입 (injection) 시 가중치 감쇠 (Weight decay)
□ 절단 (truncation)이 아닌 요약 (Summarization)
□ 매 요청마다 새로운 프롬프트 (Fresh prompt)
...

실행 환경 (Execution Environment) (파트 2 — 외부적):

□ 재시작 전 진단 정보 수집
□ 시스템 업데이트 후 에이전트 재시작
□ 코드 변경 없이 동작이 드리프트 (drift)할 때 — 환경을 먼저 확인
...

쓰기 계층 (Write Layer) (두 파트 공통):

□ 쓰기 시점에 문맥적 중요도 점수 산정 (Contextual importance scoring)
□ 쓰기 시점에 크기 정규화 (Size normalization)
□ 요약 품질이 핵심 사실을 보존하는지 검증

**컨텍스트 구조 (Context Structure) (파트 2):

□ 위치 인식 주입 (Position-aware injection) (상단 및 하단에 핵심 콘텐츠 배치)
□ 레코드 수 기준 예산 책정이 아닌, 토큰 기반 예산 책정 (Token-based budgeting)
□ 긴 컨텍스트 (Long contexts)를 위한 데드 존 (Dead zone) 인지

결론 (Conclusion)

파트 1에서는 문제가 발생했을 때 메모리 아키텍처 내부에서 어떤 일이 일어나는지 — 즉, 시스템 자체의 로직 내에서 조용히 축적되는 내부적 저하 (Internal degradation)에 대해 살펴보았습니다.

파트 2에서는 아키텍처는 올바르지만 그 주변의 실행 환경이 올바르지 않을 때 어떤 일이 일어나는지 — 즉, 런타임 상태 (Runtime state), 컨텍스트 위치 선정 (Context positioning), 그리고 구조적 불균형 (Structural imbalances)으로 인한 외부적 저하 (External degradation)에 대해 살펴보았습니다.

두 경우 모두 답은 같습니다: 침묵의 저하 (Silent degradation)입니다. 에이전트는 계속 작동합니다. 단지 아주 조금 더 나빠질 뿐입니다. 그리고 당신이 묻지 않는 한, 에이전트는 이를 말해주지 않을 것입니다.

실행 환경의 무결성 (Integrity)은 부차적인 관심사가 아닙니다. 그것은 아키텍처의 일부입니다. 둘 다 유지하십시오.

시리즈 구성:

1. Memory-Safe AI Development — 메모리 시스템을 설계하는 방법
2. Silent Failures, Part 1 — 내부적 저하 (Internal degradation)
3. Silent Failures, Part 2 — 외부 및 환경적 저하 (External and environmental degradation)

저자: Aleksandr Kossarev, Jõgeva, Estonia

태그: #ai #architecture #programming #softwareengineering