PHP에서의 AI 에이전트 생태계 - 단순 OpenAI 호출부터 멀티 에이전트 플랫폼까지

지난 2년 동안 PHP 생태계 내에서 AI 개발을 중심으로 한 산업 전체가 부상했습니다.

한때 LLM(대규모 언어 모델)을 통합하는 것이 OpenAI API를 호출하는 몇 줄의 코드처럼 보였던 반면, 오늘날의 개발자들은 메모리, 도구(tools), 워크플로(workflows), 관찰 가능성(observability), 그리고 전문화된 에이전트 팀까지 갖춘 완전한 에이전트 시스템을 구축하고 있습니다.

보통 사람들이 AI 개발에 대해 이야기할 때, 가장 먼저 Python을 언급합니다. 그럴 만한 이유가 있습니다. LangChain, LangGraph, CrewAI, AutoGen 등 흥미로운 프로젝트들이 가득하며, 대부분의 열기는 꽤 오랫동안 그곳에 머물러 있었습니다.
하지만 이와 병행하여, PHP에서도 흥미로운 이야기가 펼쳐지고 있습니다.

그리고 그것은 저를 진심으로 기쁘게 합니다.

불과 몇 년 전만 해도 PHP 개발자들은 제공업체의 SDK(소프트웨어 개발 키트)를 기반으로 모든 것을 수동으로 조립해야 했습니다. 하지만 오늘날에는 모델 클라이언트부터 멀티 에이전트 시스템을 관리하는 플랫폼에 이르기까지, 다양한 추상화 수준을 가진 완전한 도구 생태계가 이미 구축되어 있습니다.

오늘날 이 지형이 어떤 모습인지 살펴보겠습니다.

단일 모델 요청에서 완전한 에이전트로

역사적으로 모든 것은 같은 방식으로 시작되었습니다.
거의 모든 AI 프로젝트는 다음과 같은 모습이었습니다:

$response = $client->chat()->create([
    'model' => 'gpt-5',
    'messages' => [
...

프로토타입(prototype) 단계에서는 이것으로 충분합니다.

하지만 시스템이 실제 비즈니스 가치를 제공하기 시작하면 다음과 같은 추가 요구사항이 나타납니다:

• 다중 모델 지원
• 제공업체를 빠르게 전환할 수 있는 능력
• 구조화된 출력 (Structured output)
• 외부 도구 호출 (External tool calling)
• 메모리 관리 (Memory management)
• 컨텍스트 관리 (Context management)
• 요청 추적 (Request tracing)
• 다단계 프로세스 오케스트레이션 (Multi-step processing orchestration)

어느 시점에 이르면, LLM을 둘러싼 코드가 비즈니스 로직 자체보다 더 많은 공간을 차지하고 있다는 사실을 깨닫게 됩니다.

이것이 바로 PHP에서 전문적인 AI 라이브러리들이 등장하기 시작한 정확한 이유입니다.
상황을 조금 단순화하자면, 현대의 생태계는 세 가지 계층으로 나눌 수 있습니다:

• AI SDKs
• Agent Frameworks
• Agent Platforms

계층이 올라갈수록 더 많은 인프라 작업을 책임지게 됩니다.

PHP의 현대적인 AI 개발 생태계는 대략 세 가지 수준으로 나눌 수 있습니다. SDK는 모델 상호작용 문제를 해결하고, 프레임워크는 에이전트 구축을 도우며, 플랫폼은 전체 에이전트 인프라를 관리합니다.

Level One: AI SDKs

이것이 기초입니다.

AI SDK는 한 가지 문제, 즉 모델과 상호작용하는 것을 편리하게 만드는 문제를 해결합니다.

이들은 에이전트를 관리하거나 워크플로우 (Workflows)를 오케스트레이션 (Orchestrate)하려고 시도하지 않습니다. 이들의 책임은 요청을 보내고 응답을 받는 것으로 끝납니다.

OpenAI PHP

Repository: https://github.com/openai-php/client
Status: Active

PHP를 위한 공식 OpenAI 클라이언트입니다.

본질적으로, 이는 추가적인 추상화 (Abstractions) 없이 OpenAI 플랫폼과 작업할 수 있는 가장 직접적인 방법, 즉 로우 레벨 (Low-level) SDK입니다.

다음 기능에 대한 액세스를 제공합니다:

• Responses API
• Chat Completions
• Embeddings
• Audio API
• Image Generation
• Fine-Tuning
• Files API

전형적인 예시는 매우 직관적입니다:

$response = $client->responses()->create([
    'model' => 'gpt-5',
    'input' => 'Create a short summary of the customer request'
...

이 접근 방식의 장점은 명확합니다: 완전한 제어권입니다.

단점 또한 명확합니다.

여러 모델이나 제공자 (Providers)를 지원해야 하는 즉시, 필요한 모든 추상화 계층을 직접 구축해야 합니다.

Prism

Repository: https://github.com/prism-php/prism
Status: Active

OpenAI PHP가 단일 플랫폼에 접근하는 데 집중하는 반면, Prism은 다른 목표를 가지고 만들어졌습니다. 바로 여러 제공자(provider)를 위한 통합 인터페이스를 제공하는 것입니다.
이것은 멀티 제공자 AI SDK (Software Development Kit)입니다.
아이디어는 간단합니다. 비즈니스 로직이 특정 모델에 의존해서는 안 된다는 것입니다.
오늘은 GPT를 사용하고, 내일은 Claude를 사용하며, 다음 달에는 Gemini를 사용하더라도 애플리케이션은 그 차이를 느끼지 못해야 합니다.

예시:
Prism::text()
->using('openai', 'gpt-5')
->withPrompt('Hello')
->generate();

모델을 전환하는 것은 말 그대로 한 줄의 변경일 뿐입니다:
Prism::text()
->using('anthropic', 'claude')
->withPrompt('Hello')
->generate();

Prism은 추가적인 기능들 덕분에 특히 유용해집니다.

구조화된 출력 (Structured Output)
자유 형식의 텍스트를 파싱하는 대신, 예상되는 출력 구조를 사전에 정의할 수 있습니다.
예를 들어:
class SentimentResult
{
public string $sentiment;
public int $score;
}

Laravel AI
Repository: https://github.com/laravel/ai
Status: Active
아마도 최근 몇 달 사이 등장한 가장 흥미로운 플레이어일 것입니다.
Laravel AI는 Laravel이 데이터베이스, 큐 (Queues), 그리고 인프라스트럭처 (Infrastructure)를 위해 했던 일을 인공지능 (AI)을 위해 수행하려고 노력하고 있습니다.
여기서 핵심 아이디어는 모델 지원이 아닙니다.
핵심 아이디어는 AI를 Laravel 애플리케이션의 자연스러운 일부로 만드는 것입니다.
코드가 즉시 익숙하게 느껴집니다:
$response = AI::chat()
→model('gpt-5')
→prompt('고객 요청에 대한 짧은 요약을 작성해줘')
→send();
하지만 진정한 가치는 더 깊은 곳에 있습니다.
AI는 다음과 같은 요소들과 자동으로 통합됩니다:
큐 (Queues)
이벤트 (Events)
서비스 컨테이너 (Service container)
로깅 (Logging)
설정 (Configuration)
스케줄러 (Scheduler)

그 결과, LLM (Large Language Model)은 마치 Redis나 PostgreSQL과 거의 동일한 수준의 또 다른 인프라스트럭처 의존성처럼 느껴지기 시작합니다.

2단계: 에이전트 프레임워크 (Agent Frameworks)
그리고 여기서부터 상황이 정말 흥미로워지기 시작합니다.
왜냐하면 모델 요청 (Model request)은 아직 에이전트 (Agent)가 아니기 때문입니다.
고객 지원 시스템을 상상해 보세요.
다음과 같은 메시지가 도착합니다:
환불 문제로 이미 세 번이나 연락했습니다. 아무도 응답이 없네요.
그다음에는 어떤 일이 일어날까요?
실제로 시스템은 보통 다음과 같은 작업이 필요합니다:
감정 (Sentiment) 판단
긴급도 (Urgency) 평가
고객 정보 조회
지원 이력 (Support history) 확인
응답 준비
결과 저장
모든 작업 로깅 (Log)

수십 개의 서비스를 수동으로 작성할 수도 있습니다.
또는 에이전트 프레임워크를 사용할 수도 있습니다.
실제 시스템에서 에이전트는 단독으로 작동하는 경우가 드뭅니다. 보통 전문화된 에이전트들 사이에 작업을 분배한 다음, 그들의 결과를 하나의 응답으로 결합하는 코디네이터 (Coordinator)가 등장합니다.

Neuron AI
Repository: https://github.com/neuron-core/neuron-ai
Status: Active
오늘날, 이것은 PHP에서 가장 성숙한 에이전트 프레임워크 (Agent Framework) 중 하나입니다.
접근 방식이 근본적으로 다릅니다.
개발자는 요청 (Request)을 기술하는 대신, 에이전트 (Agent)를 기술합니다:
$agent = Agent::make()
->name('SupportAgent')
->instructions('당신은 고객 지원 전문가입니다');
그 후 에이전트는 작업을 전달받습니다:
$result = $agent->run(
'고객 이메일을 분석하세요'
);
언뜻 보기에는 단순해 보입니다.
하지만 내부적으로는 전체 인프라 (Infrastructure)가 나타납니다:
메모리 (Memory)
워크플로우 (Workflows)
도구 (Tools)
RAG (검색 증강 생성)
멀티 에이전트 시스템 (Multi-agent systems)
관측 가능성 (Observability)
그리고 훨씬 더 많은 것들

철학적으로, 이 프로젝트는 Python 세계의 LangGraph와 놀라울 정도로 유사합니다.
메모리가 중요해진 이유
전통적인 LLM (대규모 언어 모델)은 다음과 같이 작동합니다:
요청 (Request) → 응답 (Response)
에이전트는 다르게 작동합니다:
요청 (Request)
↓
메모리 (Memory)
↓
도구 (Tools)
↓
LLM
↓
결과 (Result)
메모리는 에이전트가 이전의 행동과 축적된 컨텍스트 (Context)를 고려할 수 있게 해줍니다.
메모리가 없다면, 장기적으로 실행되는 비즈니스 프로세스는 불가능합니다.
멀티 에이전트 시스템 (Multi-Agent Systems)
최근 몇 달간의 또 다른 트렌드는 범용 에이전트 (Universal Agents)로부터 벗어나는 것입니다.
점점 더 많은 팀이 전문화된 역할 (Specialized Roles)을 채택하고 있습니다:
코디네이터 (Coordinator)
|
+-- CRM 에이전트 (CRM Agent)
|
+-- 감성 분석 에이전트 (Sentiment Agent)
|
+-- 회신 에이전트 (Reply Agent)
이 접근 방식은 실제 팀의 구조와 매우 유사합니다.
각 에이전트는 자신의 도메인 (Domain)을 책임집니다.

LarAgent
Repository: https://github.com/maestroerror/laragent
Status: Active
Neuron AI가 범용 에이전트 프레임워크를 지향한다면, LarAgent는 주로 Laravel 개발자들에게 초점을 맞추고 있습니다.
Laravel의 익숙한 철학을 즉시 느낄 수 있습니다:
class SupportAgent extends Agent
{
protected string $instructions =
'당신은 지원 전문가입니다';
}
최소한의 인프라 코드와 최대한의 Laravel 통합을 제공합니다.
많은 팀에게 이것은 에이전트 작업을 시작하는 가장 빠른 방법이 될 수 있습니다.

PapiAI
Repository: https://github.com/papi-ai/papi-core
Status: Active
강력한 타입 지정 (Strong typing)과 제공자 독립성 (Provider independence)을 강조하는 비교적 젊은 프로젝트입니다.
아키텍처 측면에서 PapiAI는 현대적인 PHP 개발 관행을 AI 세계로 가져오려는 시도로 느껴집니다.
주요 집중 분야는 다음과 같습니다:
타입 (Types)
계약 (Contracts)
미들웨어 (Middleware)
도구 (Tools)
구조화된 응답 (Structured responses)

AI 툴링이 전통적인 PHP 프레임워크의 아키텍처 원칙을 점진적으로 상속받는 모습을 지켜보는 것은 매우 흥미롭습니다.

Atlas
Repository: https://github.com/atlas-php/atlas
Status: Active
차세대 에이전트 솔루션의 또 다른 대표 주자입니다.
이 프로젝트는 다음과 같은 현대적인 요구사항을 염두에 두고 구축되고 있습니다:
음성 인터페이스 (Voice interfaces)
멀티모달리티 (Multimodality)
에이전트 (Agents)
도구 (Tools)
트레이싱 (Tracing)
모니터링 (Monitoring)

Atlas를 아직 성숙한 시장 참여자라고 부를 수는 없지만, 생태계가 나아가고 있는 방향을 명확하게 보여줍니다.

3단계: 에이전트 플랫폼 (Agent Platforms)
특정 규모에 도달하면 새로운 문제가 발생합니다.
과제는 더 이상 에이전트를 구축하는 것이 아닙니다.
과제는 수십 개의 에이전트를 관리하는 것이 됩니다.
다음과 같은 질문들이 생겨나기 시작합니다:
작업 라우팅 (Task routing)은 누가 처리하는가?
응답 품질을 어떻게 추적하는가?
변경 사항을 어떻게 테스트하는가?
메모리 (Memory)를 어떻게 관리하는가?
실패의 근본 원인을 어떻게 파악하는가?

이 지점에서 에이전트 플랫폼 (Agent Platforms)이 등장합니다.

PromptlyAgent
Repository: https://github.com/promptlyagentai/promptlyagent
Status: Active
이 프로젝트는 복잡한 에이전트 생태계를 구축하는 데 중점을 둡니다.
주요 강조 사항은 다음과 같습니다:
시각적 오케스트레이션 (Visual orchestration)
멀티 에이전트 워크플로우 (Multi-agent workflows)
도구 통합 (Tool integration)
에이전트 관리 (Agent management)

본질적으로, 이는 개별 구성 요소를 프로그래밍하는 것에서 전체 AI 인프라를 관리하는 것으로의 전환을 의미합니다.

Vizra ADK
Repository: https://github.com/vizra-ai/vizra-adk
Status: Active
Laravel 생태계의 또 다른 흥미로운 프로젝트입니다.
이 프로젝트는 에이전트 생명주기(agent lifecycle)의 거의 전 과정을 다룹니다:
개발 (Development)
테스트 (Testing)
메모리 (Memory)
워크플로 (Workflows)
관측 가능성 (Observability)
하위 에이전트 상호작용 (Sub-agent interaction)

업계 트렌드를 살펴보면, 이와 같은 솔루션들이 점진적으로 다음 단계의 추상화(abstraction) 수준으로 자리 잡고 있습니다.

시장이 향하는 방향
흥미롭게도, PHP는 현재 몇 년 전 Python이 걸었던 경로를 거의 똑같이 따르고 있습니다.
그 진화 과정은 다음과 같습니다:
사실상 거의 모든 AI 프로젝트는 유사한 진화 과정을 거칩니다. 단순한 모델 호출로 시작하여, 도구(tools)와 구조화된 출력(structured output)을 추가하고, 결국 상호작용하는 에이전트 네트워크로 성장합니다. 모든 사람은 단순한 모델 요청으로 시작합니다.
Prism::text()
->using('anthropic', 'claude')
->withPrompt('Привет')
->generate();
그다음 도구(tools)가 등장합니다.
그다음 메모리(memory)가 등장합니다.
그다음 워크플로(workflows)가 등장합니다.
그 이후에는 특화된 에이전트(specialized agents)가 필연적으로 등장하게 됩니다.
그리고 마침내, 이 모든 인프라를 어떻게든 관리해야 한다는 깨달음에 도달합니다.
이것이 바로 오케스트레이션(orchestration) 및 에이전트 관리 플랫폼이 현재 SDK 자체보다 더 빠르게 진화하고 있는 이유입니다.