현대 AI에는 또 다른 챗봇이 아닌, 더 나은 아키텍처가 필요합니다

flowchart TD
    U[User] --> UI[Interface]
    UI --> API[API Layer]
...

대부분의 AI 애플리케이션은 여전히 놀라울 정도로 유사해 보입니다.

사용자 (User)
↓
프롬프트 (Prompt)
↓
LLM
↓
응답 (Response)

이러한 형태는 단순하며, 그 단순함이 문제의 일부입니다. 이는 제품을 만드는 것을 쉽게 느껴지게 만듭니다. 또한 시스템을 피상적으로 느껴지게 만듭니다. 많은 경우, 애플리케이션의 지능은 언어 모델 (Language Model)에 대한 단 한 번의 호출로 축소되며, 나머지 런타임 (Runtime)은 프롬프트 엔지니어링 (Prompt Engineering), 몇 가지 검색 (Retrieval) 단계, 그리고 약간의 후처리 (Post-processing)로 위임됩니다.

이것은 언어 모델에 대한 비판이 아닙니다. 아키텍처 (Architecture)에 대한 관찰입니다.

현대의 LLM은 강력하지만, 구조 (Structure)를 대체할 수는 없습니다. 그 자체로 완전한 인지 시스템 (Cognitive System)은 아닙니다. 애플리케이션이 사소한 데모 수준을 넘어 성장하게 되면, 진짜 질문은 더 이상 "어떻게 하면 모델이 더 잘 대답하게 만들 것인가?"가 아닙니다. 그것은 "사용자의 요청과 최종 응답 사이에 어떤 일이 일어나는가?"가 됩니다.

그 질문이 바로 PAD+ AI가 시작되는 지점입니다.

PAD+ AI는 또 다른 LLM이 아닙니다. 또 다른 API 래퍼 (Wrapper)도 아닙니다. 더 멋진 껍데기를 가진 챗봇도 아닙니다. 이것은 기존 언어 모델을 중심으로 한 인지 아키텍처 (Cognitive Architectures)를 탐구하기 위한 오픈 연구 플랫폼입니다. 목표는 모델을 대체하는 것이 아닙니다. 단일 프롬프트 기반 상호작용으로는 할 수 없는 방식으로 추론하고, 기억하고, 검증하고, 적응하며, 자신의 행동을 설명할 수 있는 시스템을 구축하는 것이 목표입니다.

그것은 대부분의 제품 팀이 인정하는 것보다 더 흥미로운 문제입니다.

아키텍처 문제 (The Architectural Problem)

AI 애플리케이션에 대한 주류 접근 방식은 매우 좁은 정신 모델 (Mental Model)로 수렴되었습니다. 즉, 모델이 뇌이고 나머지는 모두 비계 (Scaffolding)라는 것입니다. 그 결과 많은 시스템이 연속성 (Continuity)보다는 유창성 (Fluency)에 최적화되어 있습니다.

사용자가 질문을 하면, 시스템은 이를 모델로 보내고, 모델은 답변을 반환합니다. 그것은 편리하지만, 몇 가지 중요한 문제들을 해결되지 않은 채로 남겨둡니다.

첫째, 지속 가능한 상태(state)의 개념이 없습니다. 시스템이 최근의 몇 차례 대화(turns)는 기억할 수 있지만, 정체성, 의도, 감정적 맥락 또는 장기적인 궤적(trajectory)에 대한 더 깊은 개념이 부족한 경우가 많습니다. 둘째, 시스템에 내부적인 규율(internal discipline)이 거의 없습니다. 명시적인 검증 루프(verification loop)가 존재하지 않습니다. 셋째, 아키텍처에 관찰 가능성(observability)이 결여된 경우가 많습니다. 무언가 잘못되었을 때, 그 이유를 설명하기 어렵습니다. 넷째, 시스템이 쉽게 진화할 수 없습니다. 대안적인 추론 전략을 테스트하거나, 메모리 메커니즘(memory mechanisms)을 비교하거나, 한 구성 요소가 다른 구성 요소에 어떻게 영향을 미치는지에 대해 추론하기가 어렵습니다.

이것이 바로 많은 AI 제품들이 개별적으로는 인상적으로 느껴지지만, 실제 적용 시에는 취약하게(brittle) 느껴지는 이유입니다. 이들은 텍스트를 잘 생성할 수는 있지만, 시간이 지남에 따라 일관된 내부 프로세스를 유지하는 데 어려움을 겪습니다.

더 깊은 문제는 모델이 불충분하다는 것이 아닙니다. 더 깊은 문제는 우리가 모델에게 너무 적은 구조를 가진 채 너무 많은 일을 하도록 계속 요구하고 있다는 점입니다.

흥미로운 질문은 더 이상 "어떻게 하면 모델을 더 똑똑하게 만들 것인가?"가 아닙니다. 그것은 "어떻게 하면 모델 주변의 시스템을 더 의도적(deliberate)으로 만들 것인가?"입니다.

내가 PAD+ AI를 시작한 이유

나는 대안을 탐구하고 싶었기에 PAD+ AI를 시작했습니다.

아이디어는 간단했습니다. LLM을 전체 인지 엔진(cognitive engine)으로 취급하는 대신, 더 큰 아키텍처의 한 구성 요소로 취급하는 것입니다. 시스템은 여전히 생성을 위해 언어 모델을 사용하겠지만, 의도, 메모리, 성격, 감정 상태, 검증 및 성찰(reflection)을 위한 레이어(layers)를 포함할 것입니다.

이러한 전환은 프로젝트의 성격을 변화시킵니다. 시스템을 단순한 기능(feature)에서 아키텍처 설계의 실험으로 탈바꿈시킵니다.

이것이 중요한 이유는 오늘날 많은 AI 작업이 여전히 단기적인 제품 목표를 중심으로 조직되어 있기 때문입니다. 특정 인터페이스를 구축하고, 프롬프트(prompt)를 튜닝하고, 검색 전략(retrieval strategy)을 추가한 뒤 시스템을 출시합니다. 이는 데모용으로는 효과적입니다. 하지만 연구를 위한 지속 가능한 토대를 반드시 만들어내는 것은 아닙니다.

PAD+ AI는 다른 기대를 가지고 구축되었습니다. 이 프로젝트는 아키텍처 자체를 관심 대상인 제품(product of interest)으로 취급합니다.

목표는 세련된 최종 사용자 경험(end-user experience)을 최우선으로 만드는 것이 아닙니다. 목표는 AI 시스템이 처리의 여러 단계에 걸쳐 인과적 연속성(causal continuity)을 어떻게 유지할 수 있는지 조사하는 것입니다. 다시 말해, 시스템이 단순히 프롬프트(prompt)에 반응하는 것이 아니라, 입력에서 출력까지 더 구조화된 내부 경로를 개발한다면 어떤 일이 벌어질까요?

인지 아키텍처(Cognitive Architecture) 구축

PAD+ AI의 핵심 아이디어는 생성이 파이프라인(pipeline)에서 첫 번째이자 유일한 단계가 되어서는 안 된다는 것입니다.

더 흥미로운 경로는 다음과 같습니다:

사용자 입력 (User Input)
  → 의도 및 문맥 분석 (Intent and context analysis)
  → 메모리 검색 및 통합 (Memory retrieval and consolidation)
...

이것은 비유가 아닙니다. 이것은 해당 리포지토리(repository)에서 탐구하고 있는 시스템의 형태입니다.

이 아키텍처는 의도적으로 모듈화(modular)되어 있습니다. 각 단계는 독립적으로 추론될 수 있습니다. 이는 매우 중요합니다. 시스템이 실험을 지원하려면 단일한 불투명한 프롬프트 로직 블록(opaque block of prompt logic)이어서는 안 됩니다. 경계가 필요합니다. 단계(phases)가 필요합니다. 전체 런타임(runtime)을 깨뜨리지 않고도 교체, 재정렬 또는 비활성화할 수 있는 인터페이스(interfaces)가 필요합니다.

이것이 이 프로젝트가 단일 구조의 실행 흐름(monolithic execution flow)보다는 모듈형 인지 파이프라인(modular cognitive pipeline)을 지향하는 이유입니다. 이 파이프라인은 보편적인 진리로 제시되는 것이 아닙니다. 이는 아키텍처 가설을 테스트 가능하게 만드는 하나의 방법입니다.

이는 책임(responsibility)에 대해 생각하는 방식 또한 변화시킵니다. 언어 모델(language model)은 여전히 텍스트를 생성할 수 있지만, 해석, 메모리, 판단 및 자기 수정(self-correction)의 모든 부담을 짊어질 필요는 없습니다. 이러한 관심사들은 검사하고 추론하기 더 쉬운 구성 요소들로 분산될 수 있습니다.

이것이 이러한 종류의 플랫폼에 관심을 가져야 하는 가장 강력한 이유 중 하나입니다. 이는 아키텍처를 가시화(visible)합니다.

flowchart TD
    A[사용자 입력 (User Input)] --> B[의도 및 문맥 분석 (Intent & Context Analysis)]
    B --> C[메모리 검색 (Memory Retrieval)]
...

벡터 데이터베이스를 넘어선 메모리

AI 애플리케이션 설계에서 가장 흔한 실수 중 하나는 메모리를 벡터 검색(vector search)과 동일시하는 것입니다.

그것은 유용하지만, 불완전합니다.

시간이 흐름에 따라 일관되게 동작해야 하는 시스템은 단일 검색 메커니즘 (retrieval mechanism)에 의존할 수 없습니다. 시스템에는 생태계로서의 메모리가 필요합니다. 이는 서로 다른 목적을 수행하는 다양한 형태의 메모리가 필요함을 의미합니다.

이전 상호작용에서 발생한 일을 위한 에피소드 메모리 (episodic memory)가 있습니다. 개념과 사실을 위한 의미론적 메모리 (semantic memory)가 있습니다. 원칙, 정체성, 그리고 지속적인 선호도를 위한 더 구조적인 계층들이 존재합니다. 이러한 종류의 아키텍처에서 검색 (retrieval)은 단순히 "유사한 청크 (chunks)를 찾는 것"이 아닙니다. 그것은 현재 작업에 적합한 형태의 컨텍스트 (context)를 선택하는 것에 관한 것입니다.

이것이 중요한 이유는 언어 모델 (language models)에게는 단순히 컨텍스트가 필요한 것이 아니라, 올바른 종류의 컨텍스트가 필요하기 때문입니다. 가공되지 않은 대화 기록에 접근할 수 있는 모델이, 안정적인 원칙과 관련 경험, 그리고 일관된 정체성 개념에 기반을 둔 모델보다 반드시 더 나은 위치에 있다고 할 수는 없습니다.

흥미로운 설계 과제는 더 많은 데이터를 저장하는 것이 아닙니다. 어떤 종류의 메모리가 관련이 있는지, 그것이 언제 활성화되어야 하는지, 그리고 모델을 노이즈 (noise)로 압도하지 않으면서 어떻게 생성 (generation)에 영향을 미쳐야 하는지를 결정하는 것입니다.

이것이 바로 PAD+ AI가 메모리를 단일 저장 추상화 (storage abstraction)가 아닌 계층화된 시스템으로 바라보는 이유입니다. 이 아키텍처는 즉각적인 회상 (immediate recall), 장기적 축적 (long-term accumulation), 개인적 일관성 (personal consistency), 그리고 사실적 근거 (factual grounding) 사이의 차이점을 탐구합니다. 이것들은 동일한 문제가 아니며, 이를 하나의 문제로 취급하는 것은 취약한 시스템으로 이어집니다.

관찰 가능성 (Observability)이 필수가 된 이유

아키텍처가 여러 인지 단계에 걸쳐 확장되기 시작하면, 디버깅 (debugging)은 완전히 다른 영역이 됩니다.

단일 프롬프트 기반 흐름 (prompt-based flow)에서는 "모델이 왜 이렇게 답변했을까?"라고 묻기가 쉽습니다. 하지만 시스템에 검사할 수 있는 명시적인 내부 상태 (internal state)가 없기 때문에 그 답변은 종종 만족스럽지 못합니다. 더 구조화된 아키텍처 (structured architecture)를 사용하면 질문은 더욱 풍부해지고 유용해집니다. 어떤 메모리 소스 (memory sources)가 응답에 영향을 주었는가? 어떤 전략 (strategy)이 선택되었는가? 어떤 가정 (assumptions)이 도전받았는가? 출력의 어느 부분이 검증되었고, 어느 부분이 검증되지 않은 채 남겨졌는가?

바로 이 지점에서 관찰 가능성 (observability)은 있으면 좋은 기능 (nice-to-have)을 넘어 아키텍처 그 자체의 일부가 됩니다.

시스템이 결국 로그 (logs)만으로는 내부에서 어떤 일이 일어나는지 더 이상 이해할 수 없을 정도로 복잡해졌습니다. 그 문제가 바로 X-Ray가 되었습니다.

이 문장은 관찰 가능성 계층 (observability layer) 뒤에 숨겨진 동기를 설명하기 때문에 중요합니다. X-Ray는 시스템을 더 정교해 보이게 만들기 위해 사후에 추가된 기능이 아닙니다. 그것은 대충 살펴보기에는 너무나 풍부해진 아키텍처의 결과물입니다. 이는 더 넓은 플랫폼에도 동일하게 적용됩니다. 일단 시스템이 여러 의사결정을 조정하기 시작하면, 내부 추적 가능성 (internal traceability)은 필수적이 됩니다.

대시보드 (dashboard)는 단순한 UI 계층이 아닙니다. 그것은 인지의 구조 (structure of cognition)를 검사하는 방법입니다. 이를 통해 우리는 파이프라인 (pipeline), 상태 전이 (state transitions), 메모리 검색 단계 (memory retrieval steps), 그리고 검증 결과 (verification outcomes)를 관찰할 수 있습니다. 이러한 종류의 투명성은 엔지니어링 (engineering)과 연구 (research) 모두에 중요합니다.

![[Pasted image 20260717233734.png]]
![[Pasted image 20260717234632.png]]

이것이 일반적인 LLM 오케스트레이션 (LLM Orchestration)과 다른 이유

이러한 시스템을 보고 단순히 모델 위에 구축된 또 다른 오케스트레이션 계층 (orchestration layer)이라고 가정하기 쉽습니다. 그것은 부분적으로만 사실입니다.

차이점은 PAD+ AI가 주로 도구 호출 (tool calls)을 체이닝하거나 워크플로 엔진 (workflow engine) 내에 몇 개의 프롬프트 (prompts)를 감싸는 것에 집중하지 않는다는 것입니다. 이 프로젝트는 인지 (cognition) 구조 그 자체에 집중합니다. 이 프로젝트는 LLM 애플리케이션이 보통 하나의 불투명한 프롬프트로 통합되어 버리는 관심사 (concerns)들을 분리함으로써, 더 일관된 내부 프로세스를 유지할 수 있는지 질문을 던집니다.

이러한 구분은 중요한데, 많은 오케스트레이션 프레임워크 (orchestration frameworks)가 실행 단계에서 멈추기 때문입니다. 그것들은 호출을 조정하고, 단계를 순차적으로 배치하며, 재시도 (retries)를 관리합니다. 기본적인 도구 사용 (tool use)을 제공하기도 합니다. 유용할 수는 있습니다. 하지만 그것들이 반드시 진화하는 인지 아키텍처 (cognitive architecture)로서 추론 가능한 시스템을 만들어내는 것은 아닙니다.

PAD+ AI는 한 단계 더 깊이 들어가려 노력하고 있습니다.

이 아키텍처는 더 단순한 시스템에서는 흔하지 않은 몇 가지 가정을 전제로 합니다. 첫째, 생성 (generation)은 단순히 가장 최근에 사용 가능한 정보가 아니라, 필터링되고 해석된 컨텍스트 (context)에 의해 제약되어야 한다고 가정합니다. 둘째, 메모리 (memory)는 단일 저장소가 아니라 서로 다른 책임을 가진 상호작용하는 메커니즘들의 집합이라고 가정합니다. 셋째, 검증 (verification)은 부수적인 추가 사항이 아니라 핵심 설계 기능이라고 가정합니다. 넷째, 여러 의사결정 단계가 있는 아키텍처는 추적 가능성 (traceability) 없이는 이해하기 어려워지기 때문에, 관찰 가능성 (observability)이 처음부터 내장되어야 한다고 가정합니다.

이것들은 사소한 문제가 아닙니다. 이는 초점을 "모델이 답할 수 있는가?"에서 "시스템이 인식 가능한 수준의 내부 규율을 가지고 동작할 수 있는가?"로 전환합니다.

이것이 바로 이 프로젝트가 진화 (evolution)에 강한 관심을 갖는 이유이기도 합니다. 오직 최신 입력에만 반응하는 시스템은 반응형 인터페이스 (reactive interface) 그 이상도 이하도 아닙니다. 시간이 지남에 따라 내부 상태 (internal state)를 업데이트하는 시스템은 더 지속 가능한 형태의 행동을 발전시키기 시작할 수 있습니다. 그것은 다른 차원의 엔지니어링 문제입니다. 상태 전이 (state transitions), 피드백 루프 (feedback loops), 메모리 공고화 (memory consolidation), 그리고 과거 결정의 장기적인 효과에 대해 고민할 것을 요구합니다.

실제로 이는 아키텍처가 단일 턴 (single turn)에서 모델이 똑똑해 보이게 만드는 것보다, 여러 턴에 걸쳐 시스템이 지능적으로 행동하게 만드는 것에 더 집중한다는 것을 의미합니다. 이 차이는 미묘하지만 중요합니다. 하나는 상호작용 패턴 (interaction pattern)이고, 다른 하나는 설계 철학 (design philosophy)입니다.

이러한 구분에 관심을 가져야 할 실질적인 이유도 있습니다. 많은 AI 제품들이 짧은 데모에서 인상을 남기도록 구축되지만, 시간이 지나면서 일관된 행동을 요구받을 때 유지보수가 어려워집니다. 시스템이 숨겨진 프롬프트 로직 (prompt logic)에 더 많이 의존할수록, 새로운 추론 전략 (reasoning strategies)을 도입하거나, 메모리 동작을 조정하거나, 좁은 성공 지표 (success metrics)를 넘어 성능을 평가하는 것이 점점 더 어려워집니다. 모듈형 아키텍처 (modular architecture)는 디버깅이 더 쉽고, 실험하기가 더 쉬우며, 발전시키기가 더 쉽습니다.

이것이 이 프로젝트의 실질적인 가치 중 하나입니다. 이 프로젝트는 AI 시스템을 편의성 계층 (convenience layers)으로 감싸인 고립된 모델 호출 (model calls)이 아니라, 소프트웨어 아키텍처 (software architectures)로 생각할 수 있는 방법을 제공합니다.

완성된 제품 대신 오픈 리서치 (Open Research)

이 프로젝트에서 가장 중요한 결정 중 하나는 이를 완성된 제품으로 제시하는 것을 피하는 것이었습니다.

PAD+ AI는 모든 사람을 위해 에이전틱 AI (agentic AI)를 해결해 주는 턴키 프레임워크 (turnkey framework)로 포지셔닝되지 않습니다. 이는 여전히 활발하게 개발 중인 아키텍처 아이디어들을 탐구하기 위한 오픈 리서치 플랫폼 (open research platform)입니다.