오늘날 대부분의 AI 프레임워크는 언어 모델을 시스템의 중심에 두며, 모든 것이 LLM을 중심으로 회전합니다.

지식이 필요한가요? RAG (Retrieval-Augmented Generation)를 추가하세요.
외부 동작이 필요한가요? 도구 (tools)를 추가하세요.
메모리가 필요한가요? 메모리 계층 (memory layer)을 추가하세요.
자율성이 필요한가요? 에이전트 (agents)를 추가하세요.

그 결과는 종종 다음과 같은 모습입니다:

모델은 오케스트레이터 (orchestrator), 플래너 (planner), 라우터 (router), 그리고 실행 엔진 (execution engine)의 역할을 동시에 수행하게 됩니다.

지난 몇 년간 AI 애플리케이션을 구축하면서, 저는 이것이 문제를 생각하는 올바른 방법인지 의문이 생기기 시작했습니다.

만약 LLM이 시스템의 중심이 아니라면 어떨까?
만약 그것이 단순히 여러 핵심 구성 요소 중 하나라면 어떨까?

CPU 비유 (The CPU Analogy)

전통적인 컴퓨터 시스템에서 CPU는 연산을 수행합니다. 하지만 CPU가 컴퓨터의 전부는 아닙니다.
완전한 시스템에는 다음과 같은 것들도 필요합니다:

• 메모리 (Memory)
• 저장 장치 (Storage)
• 입출력 (Input and Output)
• 장치 드라이버 (Device Drivers)
• 실행 중인 프로그램 (Running Programs)
• 운영 체제 (Operating System)

운영 체제는 모든 것을 조정하며 프로그램이 이러한 리소스를 사용하여 실행될 수 있도록 합니다.

이는 저에게 단순한 생각으로 이어졌습니다:

만약 LLM이 컴퓨터의 CPU가 하나의 구성 요소인 것처럼, AI 시스템의 단지 하나의 구성 요소라면 어떨까?

모델은 **추론 (reasoning)**과 **생성 (generation)**을 수행합니다.
하지만 AI 시스템에는 다음과 같은 것들도 필요합니다:

• 지식 검색 (Knowledge retrieval)
• 상태 관리 (State management)
• 도구 실행 (Tool execution)
• 외부 통합 (External integrations)
• 워크플로우 오케스트레이션 (Workflow orchestration)

이러한 것들이 모델 자체의 책임이 되어서는 안 됩니다. 이를 담당하는 **런타임 (runtime)**이 존재해야 합니다.

AI 시스템을 컴퓨터 시스템에 매핑하기 (Mapping AI Systems to Computer Systems)

이 비유는 놀라울 정도로 유용해지기 시작했습니다.

이러한 관점에서 바라볼 때, AI 애플리케이션은 **프롬프트 체인 (prompt chain)**이라기보다 시스템 리소스 (system resources) 위에서 실행되는 **프로그램 (program)**에 더 가깝게 보이기 시작합니다.

프로그램 중심의 관점

간단한 **헬프 봇 (Help Bot)**을 생각해 봅시다.
대부분의 구현 방식은 다음과 같이 설명됩니다:

하지만 동일한 것을 설명하는 또 다른 방법은 다음과 같습니다:

프로그램 (program) 자체가 주요 실행 단위가 되는 반면, **모델 (model)**은 **런타임 (runtime)**에서 사용할 수 있는 여러 리소스 중 하나가 됩니다. 또한 지식 검색 (knowledge retrieval), 도구 실행 (tool execution), 또는 상태 관리 (state management)와 같은 다른 리소스를 사용할 필요가 있을 수도 있습니다.

이러한 관점의 작은 변화는 놀라울 정도로 큰 결과를 초래합니다.

런타임이 필요한 이유

AI 애플리케이션이 단일 프롬프트를 넘어 성장하면, 다음과 같은 추가 기능들이 빠르게 필요해집니다:

• 다중 모델 (Multiple models)
• 지식 소스 (Knowledge sources)
• 상태 (State)
• 분기 로직 (Branching logic)
• 외부 도구 (External tools)
• 검증 (Validation)
• 재사용 가능한 워크플로우 (Reusable workflows)

그 시점에서 과제는 더 이상 프롬프팅이 아닙니다.

과제는 **오케스트레이션 (orchestration)**입니다.

시스템에는 다음과 같은 사항을 책임지는 무언가가 필요합니다:

• 실행 상태 관리 (Managing execution state)
• 리소스 로딩 (Loading resources)
• 워크플로우 단계 실행 (Executing workflow steps)
• 입출력 처리 (Handling inputs and outputs)
• 도구 및 모델 조정 (Coordinating tools and models)

다시 말해, **런타임 (Runtime)**이 필요합니다.

GenOS의 이면에 담긴 아이디어

이러한 깨달음은 결국 제가 GenOS를 구축하는 계기가 되었습니다.

GenOS는 AI 시스템을 위한 로컬 우선 (local-first) 런타임입니다.

GenOS의 목표는 또 다른 프롬프트 래퍼 (prompt wrapper)나 에이전트 프레임워크 (agent framework)가 되는 것이 아닙니다. 대신, 모든 것을 언어 모델 (language model) 중심으로 두는 것이 아니라, AI 시스템이 일련의 리소스 (resources) 위에서 실행되는 **실행 가능한 프로그램 (executable programs)**으로 취급될 때 어떤 모습일지를 탐구합니다.

GenOS에서 이러한 실행 가능한 프로그램은 **프로젝트 (Projects)**로 표현됩니다.

GenOS **프로젝트 (Project)**는 다음을 정의합니다:

• 입력 (Inputs)
• 출력 (Outputs)
• 워크플로 그래프 (Workflow Graph)
• 엔트리 노드 (Entry Node)

**프로젝트 (Project)**는 다음과 같은 **리소스 (resources)**를 사용할 수 있습니다:

• 추론/연산을 위한 모델 (Models)
• 저장을 위한 지식 (Knowledge)
• 메모리를 위한 상태 (State)
• 외부 기능을 위한 도구 (Tools)

**런타임 커널 (Runtime Kernel)**은 이러한 리소스들을 조정하고 **프로젝트 (Projects)**를 실행합니다.

이 모델에서 **프로젝트 (Project)**는 주요 실행 단위가 되며, 모델, 지식, 도구, 상태는 프로젝트가 실행되는 동안 사용하는 리소스가 됩니다.

모듈로서의 프로젝트 (Projects as Modules)

개발 과정에서 나타난 더 흥미로운 아이디어 중 하나는 **프로젝트 (Projects)**를 **재사용 가능한 실행 단위 (reusable execution units)**로 취급하는 것이었습니다.

**프로젝트 (Project)**는 **입력 및 출력 (Inputs & Outputs)**을 정의할 수 있으며, 다른 **프로젝트 (Projects)**가 **모듈 (Module)**로서 호출할 수 있는 워크플로 그래프를 노출할 수 있습니다.

이를 통해 더 큰 시스템을 더 작고 재사용 가능한 **프로젝트 (projects)**들로부터 구축할 수 있습니다.

예를 들어:

각 GenOS **프로젝트 (Project)**는 **입력 (inputs)**과 **출력 (outputs)**에 의해 정의된 잘 설계된 인터페이스를 가진 프로그램처럼 동작하며, 이를 통해 복잡한 시스템을 작고 집중된 프로젝트들로부터 구성할 수 있습니다.

에이전트의 재사고 (Rethinking Agents)

이 설계의 예상치 못한 결과 중 하나는 에이전트 (agents)에 대한 색다른 관점이었습니다.

많은 AI 프레임워크는 에이전트를 특별한 개념으로 도입합니다.

하지만 만약 **프로젝트 (Projects)**가 다른 **프로젝트 (Projects)**를 호출할 수 있다면, 정교한 에이전트 (agent)는 단순히 다른 **프로젝트 (Projects)**들을 조정하는 **상위 수준의 프로젝트 (higher-level project)**가 될 수 있습니다.

이 모델에서는:

별도의 런타임 추상화 (runtime abstraction)라기보다는 (상위 수준의 프로젝트가 됩니다).
이는 복잡한 동작을 지원하면서도 아키텍처 (architecture)를 단순하게 유지해 줍니다.

이것이 중요한 이유

현재 AI 생태계는 모델 (models)에 크게 집중하고 있습니다.
모델은 중요합니다. 하지만 모델은 완전한 AI 시스템 (AI system)의 일부분일 뿐입니다.

애플리케이션 (applications)이 더 커지고 더 유능해짐에 따라, 다음과 같은 요소들이 점점 더 중요해집니다:

• 상태 (State)
• 지식 (Knowledge)
• 도구 (Tools)
• 재사용성 (Reusability)
• 오케스트레이션 (Orchestration)

제가 탐구하고 싶었던 질문은 이것이었습니다:

우리가 **소프트웨어 시스템 (software systems)**을 설계하는 방식과 동일한 방식으로 **AI 시스템 (AI systems)**을 설계한다면 어떤 일이 벌어질까?
단일 컴포넌트 (component)를 중심으로 하는 것이 아니라, 런타임 (runtime)에 의해 조정되는 많은 컴포넌트들의 상호작용을 중심으로 설계한다면 말이다.

향후 전망

GenOS는 아직 초기 단계에 있지만, 이 아이디어는 계속해서 진화하고 있습니다.

목표는 언어 모델 (language models)이 시스템의 중심이 되는 것이 아니라, 지식 (knowledge), 도구 (tools), 상태 (state), 그리고 재사용 가능한 워크플로우 (reusable workflows)와 함께 작동할 수 있는 **구조화된 환경 (structured environment)**을 제공하는 것입니다.

아마도 GenOS를 구축하며 얻은 가장 흥미로운 깨달음은 이것일 것입니다:

AI 애플리케이션 (AI applications)의 미래는 모델에게 모든 것을 책임지게 만드는 것이 아닐지도 모른다.
모델을 중심으로 더 나은 런타임 (runtimes)을 구축하는 것에 관한 것일지도 모른다.

CPU 하나만으로는 컴퓨터가 아니기 때문입니다.
그리고 LLM 하나만으로는 AI 시스템 (AI system)이 아니기 때문입니다.

아이디어 탐구

GenOS는 오픈 소스 (open source)이며 아직 초기 단계에 있지만, 이 글에서 논의된 아이디어들을 탐구하기 위한 실질적인 수단 역할을 합니다.

AI 시스템에 대한 런타임 중심적 (runtime-oriented) 접근 방식에 관심이 있으시다면, 여러분의 생각과 비판, 그리고 대안적인 관점을 듣고 싶습니다.

Repository: https://github.com/sagenticlab/genos
npm: https://www.npmjs.com/package/@sagentic/genos