PID를 넘어: 로컬 우선 AI 및 자율 시스템 시대의 에이전트 생존성 재정의

Originally published on tamiz.pro.

클라우드 네이티브 개발 시대에 생존성(liveness)은 단순한 불리언 값(boolean)이었습니다. 프로세스가 실행 중인가? PID 1이 존재하면 서비스는 살아있는 것으로 간주했습니다. 이 모델은 상태 비저장(stateless) 마이크로서비스와 선형적인 요청-응답 파이프라인에는 충분했습니다. 그러나 로컬 우선 AI(Local-First AI), 엣지 컴퓨팅, 자율 에이전트 프레임워크의 수렴은 이 가정을 근본적으로 무너뜨렸습니다.

현대 AI 에이전트는 단순한 프로세스가 아닙니다. 외부 도구와 상호 작용하고, 벡터 메모리를 유지하며, 복잡한 논리 체인을 실행하는 상태 저장(stateful), 멀티 스레드 인지 엔진입니다. 에이전트는 CPU를 소비하고, 메모리를 보유하며, 핑에 응답하는 '프로세스적' 의미에서는 '살아있을' 수 있지만, 근본적인 모델 가중치(model weights)가 손상되었거나, 로컬 벡터 데이터베이스가 잠겼거나, 자율 루프가 환각으로 유발된 재시도 폭풍(hallucination-induced retry storm)에 빠진 경우 기능적으로는 '죽어있을' 수 있습니다.

본 글에서는 왜 전통적인 생존성 프로브(liveness probes)가 AI 시스템에는 구식이 되었는지 탐구하고, '상태 저장 생존성(Stateful Liveness)'의 청사진을 제공합니다. 우리는 로컬 우선 AI의 아키텍처를 해부하고, HTTP 200 OK 뒤에 숨겨진 특정 실패 모드를 식별하며, 분산되고 로컬인 자율 시스템의 현실과 일치하는 강력한 상태 확인 전략을 설계할 것입니다.

목차

• 1. 프로세스만으로 판단하는 생존성의 환상
• 2. 로컬 우선 AI 에이전트의 해부학
• 3. 실패 모드: '살아있음'이 '고장남'을 의미할 때
• 4. 상태 저장 헬스 프로브 설계하기
• 5. 구현: 생존성 오케스트레이터
• 6. 에이전트 건강 운영화하기
• 7. 자주 묻는 질문

표준 Java 또는 Go 마이크로서비스의 경우, 프로세스가 실행 중이고 포트가 열려 있다면 핵심 불변성(invariants)은 보통 유지됩니다. 상태는 외부적이며(데이터베이스, 캐시), 코드는 결정론적입니다.

로컬 우선 AI 에이전트의 경우, 상태는 내부적이고 휘발적입니다. '상태'에는 다음이 포함됩니다:

• 모델 가중치 (Model Weights): VRAM/RAM에 로드된 부동소수점 배열(Floating-point arrays).
• 컨텍스트 창 (Context Window): 최근 대화의 슬라이딩 윈도우.
• 메모리 그래프 (Memory Graph): 로컬 디스크 기반 DB(SQLite, LanceDB, Faiss)에 저장된 벡터.
• 자율 상태 (Autonomous State): ReAct(Reason + Act) 루프의 현재 단계를 추적하는 내부 변수.

에이전트는 모델이 손상된 가중치 파일로 인해 NaN(Not a Number, 숫자가 아님) 전파 오류를 겪고 있거나, 로컬 벡터 DB가 이전의 불안정한 종료(unclean shutdown)로 인해 더티 트랜잭션 상태에 있을 때도 TCP 헬스 체크를 통과할 수 있습니다. PID에만 의존한다면 프로세스를 재시작할 뿐이며, 결국 손상된 상태를 로드하여 다시 실패하고, 표준 라이브니스 체크가 정확하게 해석하기 어려운 충돌 루프(crash loop)를 만듭니다.

2. 로컬 우선 AI 에이전트의 해부학 (Anatomy of a Local-First AI Agent)

라이브니스가 왜 복잡한지 이해하려면, 현대적인 로컬 우선 에이전트 스택의 구성 요소들을 살펴봐야 합니다. Ollama 또는 LLM.intel을 사용하여 추론(inference)을 수행하는 엣지 장치(Jetson Orin이나 고급 노트북 같은)에서 실행되는 에이전트를 고려해 보세요.

구성 요소 분석 (The Component Breakdown)

1. 추론 엔진 (Inference Engine): 양자화된 모델(GGUF, ONNX)을 로드하는 런타임입니다. VRAM과 양자화 스케일을 관리합니다.
2. 벡터 저장소 (Vector Store): 로컬 임베딩 데이터베이스입니다. UPSERT 및 QUERY 작업을 처리합니다. 이는 전형적인 동시성 병목 지점(concurrency bottleneck)입니다.
3. 오케스트레이터 (The Orchestrator): 에이전트의 사고 과정을 관리하는 LangChain/LlamaIndex 계층 또는 사용자 정의 Python/Go 루프입니다.
4. 도구 계층 (The Tool Layer): 에이전트가 호출할 수 있는 외부 API, 파일 시스템 접근 또는 셸 명령어입니다.

'생명'의 데이터 흐름 (The Data Flow of 'Life')

[사용자 입력] -> [오케스트레이터] -> [LLM 추론] -> [컨텍스트 창 업데이트]
                     |	                  ^                 |
                     v                  |                 v
...

이 흐름에서 '활성 상태(liveness)'는 LLM 프로세스의 정적인 속성이 아닙니다. 이는 전체 루프의 동적 속성입니다. 만약 벡터 메모리 업데이트가 실패한다면 (로컬 SSD의 디스크 I/O 문제로 인해), LLM은 텍스트 생성을 계속할 수 있지만, 에이전트는 일관되고 상태를 유지하는 페르소나라는 의미에서 더 이상 '살아있지' 않습니다. 즉, 기억을 잃어버린 것입니다.

3. 실패 모드: '활성'하다는 것이 '고장났다'는 의미일 때

traditional health checks가 놓치는 특정 실패 상태들을 분류해야 합니다. 이것들이 바로 로컬 우선 AI의 '조용한 살인자(silent killers)'들입니다.

3.1. NaN 전파 (모델 손상)

로컬 모델을 파인튜닝하거나 검증되지 않은 소스에서 불러올 때, 부동소수점 오류가 축적될 수 있습니다. 만약 어떤 레이어(layer)가 NaN을 출력하면, 후속 레이어도 쓰레기 값이나 NaN을 출력할 수 있습니다. 프로세스가 충돌하지는 않지만, 헛소리를 하거나 토큰을 반복하기 시작합니다.

• 증상: 에이전트가 모든 프롬프트에 동일한 단어 하나 또는 특수 토큰의 루프 응답을 보냅니다.
• 활성 상태 격차(Liveness Gap): 프로세스는 작동하고 포트는 열려 있지만, 인지적 출력은 유효하지 않습니다.

3.2. 벡터 DB 교착 상태 (Deadlock)

로컬 벡터 데이터베이스(예: LanceDB 또는 Chroma)는 종종 싱글 스레드이거나 파일 잠금(file locks)을 사용합니다. 만약 에이전트가 대규모 배치 쓰기(새 문서 인덱싱)를 진행하는 도중에 읽기 요청이 들어오면, 타임아웃으로 설정되지 않았다면 무한정 블록될 수 있습니다.

• 증상: 에이전트가 `

장시간 자율 세션이 진행되면, 컨텍스트 창(context window)이 가득 차게 됩니다. 요약(summarization) 또는 잘라내기(truncation) 전략에 실패할 경우, LLM은 '시스템 프롬프트(system prompt)'나 사용자 정체성을 잃을 수 있습니다. 에이전트는 계속 실행되지만, 그 행동 양식이 급격하게 변합니다. 안전 가드레일(safety guardrails)을 무시하거나 지침을 잊어버리기 시작할 수 있습니다.

• 증상: 역할극 이탈(Role-play drift), 지침 무시(instruction ignoring).
• 활성도 격차(Liveness Gap): 에이전트는 '살아있지만' 행동 상태가 '손상된' 상태입니다.

3.4. 도구 루프 정지(Tool Loop Stall)

ReAct 패턴에서, 에이전트가 도구를 호출합니다. 만약 해당 도구가 멈춘다면 (예: 타임아웃 없이 입력을 기다리는 로컬 셸 명령어), 에이전트도 블록됩니다. LLM 추론(inference)은 일시 중지되지만, 오케스트레이터 스레드(orchestrator thread)는 갇히게 됩니다.

• 증상: 도구에서 높은 CPU 사용량 발생, LLM에서는 0% 사용량, 응답 없음.
• 활성도 격차(Liveness Gap): 상태 확인(health check)이 LLM 서버를 주기적으로 호출하지만, 이 경우 기술적으로 '유휴(idle)' 상태이며, 프로브가 단순히 TCP 연결인지라 200 OK를 반환하여 갇힌 도구 스레드를 가립니다.

4. 상태 기반 활성도 프로브 설계하기 (Designing Stateful Health Probes)

이를 해결하려면, 우리는 **프로세스 활성도(Process Liveness)**에서 **상태 활성도(State Liveness)**로 전환해야 합니다. 이를 위해서는 세 가지 유형의 프로브가 필요합니다:

4.1. 인지적 핑 (Cognitive Ping) (정상 작동 확인)

단순히 포트만 확인할 수는 없습니다. 일관된 출력을 생성하는지 검증하기 위해 모델에 사소하고 결정론적인 프롬프트를 보내야 합니다.

• 방법: temperature=0과 낮은 max_tokens를 사용하여 `

• 방법: 프로브 벡터(벡터 공간에 내장된 알려진 UUID)를 삽입하고 유사도 임계값 1.0으로 이를 조회합니다.

• 성공 기준: 해당 프로브 벡터가 최상위 검색 결과로 반환됩니다.

• 이유: 이는 디스크 I/O, 임베딩 모델, 그리고 검색 로직이 모두 정상적으로 작동함을 확인시켜 줍니다.

4.3. 루프 지연 시간 예산 (The Loop Latency Budget)

자율 루프가 막히지 않도록 보장해야 합니다.

• 방법: 마지막 '생각(thought)' 또는 '행동(action)' 단계 이후 경과 시간을 모니터링합니다. 에이전트가 X초 이상('Thinking' 상태에 머무는 시간, 모델 크기에 따라 설정 가능) '사고 중(Thinking)' 상태라면, 이를 '정지(Stalled)'로 플래그 지정합니다.
• 성공 기준: 마지막 상태 전환의 타임스탬프가 예산 범위 내에 있습니다.

5. 구현: 생존성 오케스트레이터 (The Liveness Orchestrator)

Python에서 StatefulLivenessChecker를 구현해 보겠습니다. 이 클래스는 에이전트 주변의 사이드카(sidecar) 또는 래퍼(wrapper) 역할을 하며, 구성 요소를 능동적으로 테스트합니다.

데모 목적으로 로컬 Ollama 인스턴스와 간단한 인메모리 벡터 스토어를 가정할 것이며 (프로덕션에서는 LanceDB/Chroma로 교체하세요), 실제 환경을 전제로 합니다.

5.1. 프로브 정의 (The Probe Definitions)

import time
import requests
imhashlib
...

5.2. 오케스트레이터 루프 (The Orchestrator Loop)

실제 시스템에서는 메인 에이전트 루프를 차단할 수 없습니다. 생존성 체크는 별도의 스레드나 프로세스에서 실행되어야 합니다. 여기에 에이전트를 래핑하는 FastAPI 서비스에 통합하는 방법이 나와 있습니다.

import threading
import time
from fastapi import FastAPI, HTTPException
...

5.3. 생존성을 위한 '회로 차단기' (The 'Circuit Breaker' for Liveness)

단순히 '저하(degraded)' 상태라고 보고하는 것만으로는 충분하지 않습니다. 만약 에이전트가 NaN 루프에 빠진다면, 이를 종료해야 합니다. LLM 클라이언트를 회로 차단기(circuit breaker)로 래핑하여, liveness_probe가 연속으로 세 번 실패하면 작동을 중지하도록 할 수 있습니다.

class LivenessCircuitBreaker:
    def __init__(self, probe: LivenessProbe, failure_threshold: int = 3):
        self.probe = probe
...

6. 에이전트 상태 운영화 (Operationalizing Agent Health)

실제 로컬 우선 환경에서 이를 어떻게 배포할까요?

6.1. 사이드카 패턴 (The Sidecar Pattern)

실제 로컬 우선 환경에서 이를 어떻게 배포할까요?

6.1. 사이드카 패턴 (The Sidecar Pattern)

Agent와 Ollama를 같은 기기(예: Raspberry Pi 또는 Mac Studio)에서 실행하는 경우, LivenessProbe 서비스를 별도의 경량 컨테이너나 systemd 서비스로 실행하세요.

• Ollama: 모델을 실행합니다.
• Agent App: 로직을 실행합니다.
• Liveness Service: 위의 프로브 코드를 실행합니다. /health를 노출합니다.
• Monitor: Grafana 또는 간단한 스크립트가 Liveness Service를 주기적으로 확인(poll)합니다. 만약 2분 이상 degraded 상태를 보고하면, Agent App을 재시작합니다 (Ollama 자체에 문제가 없는 한 Ollama는 제외).

6.2. AI를 위한 SLI 정의하기

전통적인 SLI(Service Level Indicators)는 지연 시간(latency)과 가용성(availability)입니다. AI의 경우, **일관성(Coherence)**과 **관련성(Relevance)**을 추가해야 합니다.

6.3. LLM의 '블랙박스' 처리하기

가장 어려운 부분은 전체 추론(inference)을 실행하지 않고는 LLM이 '일관성 있는지(coherent)' 알 수 없다는 것입니다. 2+2 프로브는 휴리스틱(heuristic)입니다. 이 모델이 산술을 잘 처리하지 못하는 특정 아키텍처를 가지고 있거나, 양자화(quantization)가 너무 낮아서 기본적인 논리까지 잃어버린 경우 실패할 수 있습니다.

모범 사례: '골든 테스트(Golden Test)' 세트를 사용하세요. 간단한 Q&A 쌍으로 구성된 JSON 파일을 유지합니다 (예: `

No. Cognitive Ping은 작은 추론(few tokens, temp=0)입니다. 로컬 하드웨어에서는 이 작업이 50ms 미만으로 소요됩니다. Vector DB 확인은 디스크 I/O 읽기이며, 이는 무시할 수 있는 수준입니다. 그 비용은 사용자나 외부 API로 잘못된 데이터를 전파하는 침묵하는 에이전트 실패 비용보다 훨씬 낮습니다.

7.2. 메인 에이전트 프로세스에 의해 Vector DB가 잠긴 경우 어떻게 처리하나요?

메인 에이전트는 벡터 쓰기 작업에 Write-Ahead Logging (WAL) 또는 Optimistic Concurrency를 사용해야 합니다. Liveness Probe는 가능하다면 읽기 전용(Read-Only) 확인을 수행하거나 별도의 연결 풀을 사용해야 합니다. 만약 SQLite 기반의 벡터 저장소(예: sqlcipher 또는 sqlite-vec)를 사용한다면, 프로브와 에이전트 간의 교착 상태(deadlock)를 방지하기 위해 busy_timeout을 설정하는지 확인하세요.

7.3. 이것을 클라우드 기반 LLM에도 사용할 수 있나요?

네, 하지만 'Coherence' 확인은 중요도가 낮아집니다 (클라우드 제공업체가 모델 무결성을 처리하기 때문입니다). 그러나 네트워크 불안정성 때문에 지연 시간(Latency) 및 가용성(Availability) 확인이 더 중요해집니다. 클라우드의 경우, 모델이 제공업체의 API 뒤에 있기 때문에 NaN 확인보다는 **재시도 예산(Retry Budgets)**에 초점을 맞추는 것이 좋습니다.

7.4. 에이전트가 '사고 중(Thinking)' 상태이고 응답하는 데 30초가 걸리면 어떻게 하나요?