AI 에이전트에게 왜 불가능한 목표가 아닌 적절한 목표가 필요한가

작가의 노트:

이 글은 버티컬 AI 솔루션(Vertical AI Solutions)을 구축하는 분들, 과학을 믿는 분들, 특히 이러한 생성 능력을 갖춘 LLM(대규모 언어 모델)이 여전히 과학적 발명품이며 수학과 과학의 법칙을 따른다고 믿는 분들을 위한 글입니다.

AI 하이프 사이클(Hype Cycle)의 환상
현재 거의 모든 AI 스타트업은 신뢰할 수 있고 프로덕션에 즉시 투입 가능한 에이전트의 어떤 버전을 약속하고 있습니다.

최근 몇 차례의 YC(Y Combinator) 배치(batch)를 살펴보면, 기업의 거의 90%가 AI 중심이며, 그들 중 대부분은 버티컬 AI(Vertical AI) 기업입니다. 이들은 기반 모델(underlying model)을 직접 구축하는 것이 아니라, 모델 위에 레이어를 구축하여 특정 산업이나 워크플로(workflow)에 적용합니다.

마케팅 예산은 막대하고, 시드 라운드(seed rounds) 규모는 엄청나며, 내러티브(narrative)는 주로 수천억 달러의 기업 가치를 유지하기 위해 하이프(hype)를 지속시켜야 하는 프런티어 LLM(frontier LLM) 제공업체들에 의해 작성되고 있습니다.

저는 바로 이 시장에서 인프라를 구축하고 있는 창업자이며, 이 글은 우리가 내린 베팅, 그리고 왜 우리가 다른 모든 이들이 판매하고 있는 더 시장성 있는 약속을 쫓는 대신 이 길을 선택했는지에 관한 것입니다.

이 시장에서 아무도 직접적으로 대답하고 싶어 하지 않는 질문이 있습니다. 전통적인 API(Application Programming Interface)가 항상 작동해 온 방식처럼, 동일한 입력에 대해 매번 동일한 출력을 내놓는, 실제로 결정론적(deterministic)인 핵심 AI 프리미티브(primitive)를 구축한 사람이 있습니까?

없습니다. 그리고 모델 위에 RAG(검색 증강 생성), 추가된 컨텍스트(context), 또는 에이전트 최적화(agentic optimization)를 아무리 더한다 해도 그것은 변하지 않습니다.

근본적인 결함을 패치해 온 역사
ChatGPT가 출시되었을 때, 그것은 놀라운 생성 능력을 해방시켰습니다.

저는 결코 그 점을 폄하하지 않을 것입니다. 그것은 우리 시대의 가장 놀라운 기술적 돌파구 중 하나로 남아 있습니다.

하지만 업계가 인상적인 소비자 데모에서 미션 크리티컬(mission-critical)한 기업용 워크플로로 이동하려고 시도함에 따라, LLM의 핵심적인 약점인 내재된 예측 불가능성(unpredictability)이 극명하게 드러났습니다.

이를 해결하기 위해 업계는 급격하게 여러 층의 임시방편(band-aids)을 거쳐왔습니다:

벡터 데이터베이스 (Vector Databases): Pinecone 및 Chroma와 같은 도구들이 시맨틱 검색 (semantic search)을 주목받게 했습니다.

유용하기는 하지만, 벡터 데이터베이스는 근본적으로 전통적인 데이터베이스의 논리적 진화 형태입니다. 즉, 단순히 수학적 임베딩 (embeddings)을 저장하고 유사도 쿼리 (similarity queries)를 가능하게 할 뿐입니다.

검색 증강 생성 (Retrieval-Augmented Generation, RAG): RAG는 LLM의 환각 (hallucinations) 및 메모리 제한에 대한 궁극적인 해결책으로 칭송받았습니다. 그 약속은 간단했습니다: LLM을 사용자의 맞춤형 데이터 경계 내로 제한하는 것입니다.

실제로 기업들은 RAG가 단지 환각을 줄여줄 뿐, 이를 완전히 제거하지는 못한다는 사실을 빠르게 깨달았습니다.

에이전트 최적화 (Agentic Optimizations): 추론 단계의 체이닝 (chaining), 도구 호출 (tool calls) 추가, 멀티 에이전트 워크플로 (multi-agent workflows) 오케스트레이션 등은 에이전트의 능력을 향상시키지만, 추가되는 모든 단계는 예측 가능성 (predictability)을 향한 단계가 아니라 또 다른 확률적 결정 (probabilistic decision)일 뿐입니다.

관측 가능성 (Observability) 및 오픈 지식 프레임워크 (Open Knowledge Frameworks): 오늘날 시장의 관심은 관측 가능성 프레임워크, 지식 그래프 (knowledge graphs), 그리고 Google의 Knowledge Graph 솔루션과 같은 이니셔티브로 이동했습니다.

이러한 최상위 계층 솔루션들은 모두 정확히 똑같은 불가능한 과제에 도전하고 있습니다: 확률적 시스템 (probabilistic system)이 결정론적 (deterministically)으로 동작하도록 강제하는 것입니다.

수직적 AI (Vertical AI) 기업들은 이러한 패턴이 대규모로 나타나는 가장 명확한 사례입니다. 이들은 파운데이션 모델 (foundation model) 위에 RAG, 컨텍스트 (context), 에이전트 워크플로를 쌓아 올려, 이 조합이 고객들이 신뢰할 수 있을 만큼 충분히 결정론적으로 느껴지기를 희망합니다.

하지만 결코 그 지점에 도달하지 못하는데, 그 이유는 계층 (layer)이 문제가 아니기 때문입니다. 그 아래에 있는 모델이 문제입니다.

[ 전통적 소프트웨어 (Traditional Software) ] → 입력 (Input) + 결정론적 코드 (Deterministic Code) → 100% 예측 가능한 출력 (Predictable Output)

[ 생성형 AI 에이전트 (Generative AI Agent) ] → 입력 (Input) + 확률적 LLM (Probabilistic LLM) → 가변적 / 진화하는 출력 (Variable / Evolving Output)

LLM에 결정론을 강제할 수 없는 이유
래퍼 (wrapper), 관측 가능성 도구, 또는 RAG 파이프라인이 LLM의 근본적인 본질을 근본적으로 바꿀 수 있을까요? 아니요. 수학적으로 불가능합니다.

1. LLM은 수학이며, 그 수학은 확률적입니다. 핵심적으로, LLM이 수천억 개의 파라미터(parameter)를 가지고 있더라도, LLM은 다음 토큰 예측(next-token prediction)을 수행합니다. LLM은 프롬프트(prompt)가 주어졌을 때 통계적으로 가장 확률이 높은 답변을 선택합니다. 확률은 정의상 비결정론적(non-deterministic)입니다.

2. 모델은 지속적으로 진화합니다. 프론티어 모델(Frontier models)은 끊임없이 업데이트되고, 미세 조정(fine-tuning)되며, 재학습(retraining)됩니다. 만약 모델의 기저 파라미터나 정렬 가중치(alignment weights)가 시간이 지남에 따라 변한다면, 동일한 입력이 주어지더라도 출력은 필연적으로 드리프트(drift)할 것입니다. 여기에 도구 호출(tool calls)과 누적되는 컨텍스트(context)가 포함된 다단계 에이전트 체인(multi-step agent chain)을 쌓는다면, 드리프트는 상쇄되는 대신 추가되는 레이어마다 복리로 쌓이게 됩니다.

만약 시스템이 확률에 의존하고 지속적인 학습을 거친다면, 해당 시스템이 경직되고 100% 결정론적인(deterministic) 결과를 생성할 것이라고 기대하는 것은 수학적 모순입니다.

그 위에 어떤 도구 스택을 쌓더라도 이를 바꿀 수는 없으며, 오직 그 결과로 발생하는 현상들을 관리할 수 있을 뿐입니다.

나아갈 길: 결정론에서 감사 가능성(Auditability)으로
이것이 우리가 AI 에이전트를 포기해야 한다는 의미일까요? 절대 아닙니다.

AI는 근본적으로 시장 역학을 재편하고 있으며, 그 영향력은 부정할 수 없습니다.

하지만 우리는 접근 방식을 바꿔야 합니다. 비결정론적 모델을 경직된 틀에 억지로 맞추려고 자원을 낭비하는 대신, 모델의 확률적 본질을 받아들이고 감사 가능성(Auditability)을 통한 제약된 신뢰성(Constrained Reliability)에 집중해야 합니다.

블랙박스(black box) 내부에서 추적할 수 없는 것은 통제할 수 없습니다.

AI 에이전트가 드리프트하고, 진화하며, 때때로 예상치 못한 결정을 내릴 것이라는 점을 수용한다면, 기업의 요구사항은 예측 가능성(predictability)에서 엄격한 감사 가능성(auditability) 및 거버넌스(governance)로 전환됩니다.

그리고 감사 가능성은 일회성 해결책이 아닌 지속적인 프로세스로서만 작동합니다. 오늘 드리프트하는 모델은 다음 미세 조정(fine-tune) 이후에, 컨텍스트 창(context windows)이 커진 이후에, 그리고 에이전트 체인이 더 길어진 이후에 내일은 또 다르게 드리프트할 것입니다.

일회성 감사(audit)는 어제 무슨 일이 일어났는지를 알려줄 뿐입니다. 실제로 필요한 것은 모든 실행을 무기한으로 감시하는 상시 프로세스입니다. 즉, 예상치 못한 결정이 프로덕션(production)에 도달하기 전에 개입할 수 있는 인간의 감독(human oversight) 및 시스템이 진화함에 따라 지속적으로 개선하는 피드백 루프(feedback loop)와 결합된 지속적인 감사 가능성(continuous auditability)이 필요합니다.

이를 일관되게 실행한다면, 에이전트는 결정론적(deterministic)이 되지 않더라도 기업에 실제로 중요한 방식, 즉 에이전트가 무엇을 했는지, 왜 했는지를 항상 알 수 있고, 잘못된 순간을 피해를 입히기 전에 포착함으로써 건전하고 신뢰할 수 있는 상태를 유지하게 됩니다.

이것이 바로 우리가 구축한 것을 형성한 정확한 깨달음입니다.

ZizkaDB가 AI 신뢰성 문제를 해결하는 방법
이러한 깨달음이 바로 우리가 ZizkaDB를 구축한 이유입니다.

출처 (Github , Cloud)

LLM을 100% 결정론적(deterministic)으로 만들겠다고 주장하는 불가능한 마법 같은 해결책을 약속하는 대신, ZizkaDB는 AI 에이전트를 위해 특별히 구축된 오픈 소스 운영 데이터베이스(operational database)입니다. 이는 일회성 점검이 아니라 상시 프로세스로서, 자율 에이전트를 프로덕션에서 안전하게 실행하는 데 필요한 지속적인 상태 관리(state management), 행동 추적(behavioral tracing) 및 감사 인프라를 제공합니다.

ZizkaDB가 기업용 에이전트의 핵심 문제를 해결하는 방식은 다음과 같습니다:

1. 인과적 계보 및 컨텍스트 메모리 (why() 및 at() 함수)
   표준 로거(logger)는 원시 입력과 출력만을 캡처하므로, 에이전트가 잘못된 결정을 내렸을 때 추측에 의존할 수밖에 없습니다. ZizkaDB는 인과적 계보(causal lineage)를 네이티브로 추적합니다 (db.why()와 같은 함수 사용).

이를 통해 개발자는 에이전트의 실행 트리(execution tree)를 역추적하여 특정 시점의 정확한 근본 원인(root cause), 부모 이벤트(parent event) 및 시스템 상태를 밝혀낼 수 있습니다.

2. 파라미터 스냅샷 및 드리프트 추적 (Parameter Snapshots & Drift Tracking)
   AI 에이전트는 프롬프트 컨텍스트(prompt context)가 확장되고 데이터가 축적됨에 따라 시간이 지남에 따라 행동이 변합니다. ZizkaDB는 실행 시점의 파라미터 스냅샷(parameter snapshots), 컨텍스트 창(context windows) 및 환경 파라미터를 기록합니다.

에이전트의 출력이 드리프트(drift)될 때, 편차를 유발한 정확한 시점의 컨텍스트(temporal context)를 격리하여 조사할 수 있습니다.

1. 심층 내부 감사(Deep Internal Auditing) 및 인간의 감독(Human Oversight): 에이전트 실행 파이프라인(execution pipeline)을 블랙박스(black box)로 취급하는 대신, ZizkaDB는 모든 도구 호출(tool call), 컨텍스트 주입(context injection), 그리고 추론 단계(reasoning step)를 기록합니다. 이는 Python, TypeScript, LangChain, CrewAI, 그리고 MCP를 위한 네이티브 SDK를 통해 프로덕션 루프(production loops)에 원활하게 통합됩니다.

이러한 가시성(visibility)을 통해 팀은 의도하지 않은 결정이 프로덕션 환경에 도달하기 전에 실시간 인간 감독을 트리거할 수 있으며, 기반 모델(underlying model)이 계속 변화함에 따라 시스템을 지속적으로 개선할 수 있습니다.

결론
우리는 100% 자율적이고 결함 없는 AI 에이전트에 대한 과장된 약속을 더 이상 필요로 하지 않습니다.

우리에게 필요한 것은 AI의 본질을 인식하는 실용적이고 견고한 인프라입니다. 즉, AI는 일회성 해결책이 아니라 능동적이고 지속적인 거버넌스(governance)가 필요한 강력한 확률론적 엔진(probabilistic engine)이라는 점을 인정하는 인프라입니다.

AI 에이전트 위에 아무리 많은 레이어(layer)를 쌓더라도, 에이전트를 엄격하게 결정론적(deterministic)으로 만들 수는 없습니다.

하지만 ZizkaDB와 함께라면, 에이전트를 감사 가능(auditable)하고 관리 가능하며, 기업 환경에서 신뢰할 수 있는 수준으로 만들 수 있습니다.