Open Agent Platform: LangGraph 에이전트를 “앱처럼” 만들고 운영하게 만든 실험

AI 에이전트 시대가 오면서, 이제 문제는 “에이전트를 만들 수 있느냐”가 아닙니다.
진짜 어려운 문제는 그 다음입니다. 누가 설정을 바꾸고, 어떤 도구를 붙이고, 여러 에이전트를 어떻게 운영하느냐죠.

LangChain이 공개했던 Open Agent Platform은 바로 이 지점을 겨냥했습니다. 에이전트를 코드 덩어리가 아니라 운영 가능한 제품 단위로 다루게 만든 플랫폼입니다. 다만 지금 이 프로젝트를 볼 때 꼭 알아야 할 점이 하나 있습니다. 이 저장소는 2026년 2월 25일에 아카이브되었고, README에서도 deprecated 상태라고 명시하며 현재는 LangSmith의 Agent Builder 사용을 권장하고 있습니다. 즉, OAP는 “지금 당장 도입할 최신 메인 제품”이라기보다, LangChain이 한때 어떤 방향으로 에이전트 플랫폼을 설계했는지 보여주는 매우 좋은 레퍼런스에 가깝습니다. (GitHub)

프로젝트 소개

Open Agent Platform은 LangGraph 기반 에이전트를 웹 UI에서 생성, 관리, 설정, 대화할 수 있게 만든 오픈소스 플랫폼입니다. 저장소 설명과 문서에 따르면 이 플랫폼의 핵심 목적은 비개발자도 에이전트를 다룰 수 있게 하면서, 동시에 개발자는 LangGraph 그래프와 설정 스키마를 통해 확장 가능하게 만드는 것입니다. 문서에서는 이를 “citizen developer platform”이라고 표현하며, 에이전트를 도구, RAG 서버, 심지어 다른 에이전트와도 연결할 수 있다고 설명합니다. (GitHub)

누가 만들었는지도 분명합니다. 루트 package.json의 author는 LangChain으로 표기되어 있고, 저장소 역시 langchain-ai 조직 아래 공개됐습니다. 또한 레포 구조를 보면 모노레포 형태로 운영되며, 루트는 Yarn workspaces와 Turborepo를 사용하고, 실제 웹 앱은 apps/web에 들어 있습니다. 웹 앱 의존성을 보면 Next.js 15, React 19, TypeScript, Supabase, LangGraph SDK, MCP SDK, Zod, Zustand, Radix UI 등을 사용합니다. 한마디로 말해, 이 프로젝트는 “에이전트 런타임”이라기보다 LangGraph 위에 얹힌 운영 UI + 관리 레이어입니다. (GitHub)

왜 이런 프로젝트가 등장했을까

기존의 에이전트 개발 방식은 대부분 개발자 중심이었습니다. LangGraph로 그래프를 만들고, 코드에서 프롬프트를 수정하고, 툴 연결을 바꾸고, 배포 환경을 바꾸려면 결국 엔지니어가 개입해야 했습니다. OAP는 이 문제를 “그래프 자체를 노코드화”해서 풀지 않았습니다. 대신 그래프는 개발자가 만들고, 그래프 위 설정 계층을 UI로 노출하는 방식을 택했습니다. 문서에서 에이전트를 “기존 LangGraph graph 위에 올라간 custom configuration”이라고 설명하는 이유가 여기에 있습니다. (GitHub)

이 접근이 꽤 영리한 이유는, 에이전트의 핵심 로직은 여전히 코드로 관리하면서도, 실제 운영에 필요한 변수들—예를 들면 모델, 시스템 프롬프트, temperature, MCP 툴 목록, RAG 컬렉션—은 UI에서 바꿀 수 있기 때문입니다. 즉 OAP는 “노코드로 에이전트를 만든다”기보다, 더 정확히 말하면 개발자가 준비한 LangGraph 에이전트를 노코드로 조립하고 운영하게 만든다에 가깝습니다. (GitHub)

핵심 아이디어: 에이전트를 앱처럼 관리한다

이 프로젝트를 이해하는 가장 좋은 문장은 README의 이 설명입니다.
Agent는 LangGraph deployment 안의 특정 graph에 연결된 custom assistant입니다. 그리고 그 assistant는 이름, 설명, configurable fields를 가집니다. 즉 OAP의 에이전트는 단순한 프롬프트 템플릿이 아니라, 배포된 그래프에 사용자 설정을 덧씌운 실행 단위입니다. (GitHub)

이 개념을 개발자 관점으로 바꾸면 이렇게 볼 수 있습니다.

• LangGraph graph = 실행 엔진
• OAP agent = 운영 가능한 제품 인스턴스
• configurable fields = 제품의 설정 화면
• OAP UI = 설정/대화/관리 콘솔

그래서 OAP는 “에이전트 빌더”이면서 동시에 “에이전트 어드민”입니다. 단순히 생성만 하는 도구가 아니라, 배포된 여러 그래프를 불러와서 하나의 제품군처럼 관리하는 레이어입니다. 실제로 배포 목록은 NEXT_PUBLIC_DEPLOYMENTS 환경변수로 주입되고, 이 중 하나는 기본 배포로 지정되어야 합니다. 코드에서도 기본 배포가 반드시 하나 있어야 하며, 기본 배포에는 defaultGraphId가 필요하다고 검증합니다. (GitHub)

OAP의 핵심 기능

1) 에이전트 관리 UI

문서와 README는 OAP의 첫 번째 강점으로 Agent Management를 내세웁니다. 사용자는 웹 인터페이스에서 에이전트를 만들고, 설정하고, 상호작용할 수 있습니다. 이때 중요한 건 OAP가 LangGraph deployment를 직접 실행하는 시스템이 아니라, 이미 존재하는 LangGraph deployment들을 불러와서 UI에서 관리하는 시스템이라는 점입니다. 퀵스타트에서도 먼저 별도의 agent repository를 배포한 뒤, 그 deployment 정보를 OAP에 연결하도록 안내합니다. (GitHub)

2) MCP 툴 연결

OAP는 MCP 서버를 통해 외부 도구를 연결할 수 있게 설계됐습니다. README와 문서는 MCP Tools를 핵심 기능으로 소개하고 있고, 설정 문서에서는 configurable field 중 하나를 type: "mcp"로 선언하면 OAP가 이를 도구 선택 UI로 해석한다고 설명합니다. 또한 웹 앱 코드는 MCP 서버 URL과 인증 필요 여부를 환경변수로 받아 기본값을 주입합니다. 즉 개발자는 에이전트에 “MCP 설정 필드”만 정의하면, OAP는 그 필드를 사람이 고를 수 있는 도구 설정 화면으로 바꿔 줍니다. (GitHub)

3) RAG 통합

RAG도 같은 방식입니다. 문서는 LangConnect를 1급 통합 대상으로 소개하고, 퀵스타트에서는 별도 LangConnect 서버를 띄운 뒤 NEXT_PUBLIC_RAG_API_URL을 설정하라고 안내합니다. FAQ에서는 웹 앱 자체는 별도 백엔드가 꼭 필요하지 않지만, RAG 기능을 쓰려면 LangConnect 서버는 독립적으로 운영해야 한다고 명시합니다. 즉 OAP는 자체적으로 벡터 인덱싱을 수행하는 시스템이 아니라, RAG 백엔드에 대한 UI 게이트웨이입니다. (GitHub)

4) 다중 에이전트 오케스트레이션

OAP 문서에는 Supervisor Agent가 별도 예제로 제공됩니다. 즉 하나의 에이전트가 다른 에이전트를 하위 단위처럼 조정하는 구조를 상정하고 있습니다. README에서도 “other agents through an Agent Supervisor”를 강조합니다. 이 점은 OAP가 단일 챗봇 빌더라기보다, 멀티 에이전트 운영 UI를 지향했다는 뜻입니다. 실제 타입 정의와 UI 설정 코드에는 type: "agents" 설정도 존재해, 다른 에이전트 목록을 구성값으로 받는 시나리오를 염두에 둔 흔적이 보입니다. (GitHub)

5) 인증과 접근 제어

기본 인증은 Supabase입니다. 퀵스타트와 .env.example 모두 Supabase URL과 anon key를 요구하고, 구글 로그인 노출 여부도 환경변수로 제어합니다. 동시에 웹 앱 클라이언트 코드를 보면, 사용자 액세스 토큰이 없거나 NEXT_PUBLIC_USE_LANGSMITH_AUTH가 true일 때는 /api/langgraph/proxy/{deploymentId} 경로를 사용하고 x-auth-scheme: langsmith 헤더를 보냅니다. 반대로 사용자 토큰이 있으면 각 deployment URL로 직접 Authorization 헤더와 Supabase 토큰을 붙여 접근합니다. 즉 OAP는 인증 계층도 꽤 유연하게 설계돼 있습니다. (GitHub)

이 플랫폼이 강력한 이유: “그래프를 UI로 번역한다”

OAP의 진짜 묘미는 단순한 대시보드가 아니라, LangGraph의 config schema를 UI로 자동 해석하는 계층에 있습니다.

설정 문서를 보면, 개발자는 LangGraph의 configurable schema에 x_oap_ui_config 메타데이터를 추가해 필드 타입을 선언할 수 있습니다. 예를 들어 text, textarea, number, boolean, slider, select, json 같은 UI 타입을 붙일 수 있고, 설명, 기본값, 검증 함수, 옵션 목록도 제공할 수 있습니다. 웹 앱의 ui-config.ts는 실제로 schema의 각 property를 순회하면서 x_oap_ui_config를 읽고, 이를 UI 필드 배열로 변환합니다. metadata가 없으면 기본적으로 text input으로 렌더링합니다. (GitHub)

이건 개발자 입장에서 엄청 중요한 포인트입니다.
왜냐하면 OAP는 프론트엔드에서 별도 폼을 하드코딩하지 않아도, 그래프 스키마만 잘 정의하면 운영 UI가 자동 생성되기 때문입니다.

예를 들어 이런 식입니다.

import "@langchain/langgraph/zod";
import { z } from "zod";

export const GraphConfiguration = z.object({
  modelName: z.string().optional().langgraph.metadata({
    x_oap_ui_config: {
      type: "select",
      default: "openai/gpt-4.1",
      description: "응답 생성에 사용할 모델",
      options: [
        { label: "GPT-4.1", value: "openai/gpt-4.1" },
        { label: "Claude 3.7 Sonnet", value: "anthropic/claude-3-7-sonnet-latest" }
      ]
    }
  }),

  temperature: z.number().optional().langgraph.metadata({
    x_oap_ui_config: {
      type: "slider",
      default: 0.7,
      min: 0,
      max: 2,
      step: 0.1,
      description: "창의성 조절"
    }
  }),

  systemPrompt: z.string().optional().langgraph.metadata({
    x_oap_ui_config: {
      type: "textarea",
      description: "에이전트의 시스템 프롬프트"
    }
  })
});

이 패턴의 의미는 명확합니다.
백엔드 그래프 스키마가 곧 어드민 UI 계약서가 된다는 겁니다. OAP는 이 계약을 읽어 UI를 만들고, 사용자는 웹에서 조정하고, 실행은 여전히 LangGraph가 담당합니다. (GitHub)

프로젝트 아키텍처 분석

OAP를 아키텍처적으로 보면 이렇게 정리할 수 있습니다.

이 그림에서 핵심은 OAP가 “중앙 실행 엔진”이 아니라는 점입니다. 실행의 중심은 LangGraph deployment이고, OAP는 그 위에 다음 세 가지를 얹습니다.

1. 사용자용 관리 UI
2. 설정 스키마를 UI로 바꾸는 해석기
3. 인증/프록시/도구 연결을 위한 접착 레이어

실제 코드도 이 구조를 뒷받침합니다. createClient는 조건에 따라 LangGraph deployment로 직접 붙거나, OAP의 API 프록시를 통해 붙습니다. ui-config.ts는 LangGraph schema를 읽어 일반 설정 필드, MCP 필드, RAG 필드, agents 필드를 분리합니다. 그리고 deployments 설정은 환경변수에서 읽어 기본 graph를 강제합니다. 즉 OAP는 runtime orchestrator라기보다 control plane에 가까운 웹 플랫폼입니다. (GitHub)

실제 동작 흐름을 개발자 관점에서 보면

개발자가 OAP용 에이전트를 붙이는 흐름은 대략 이렇습니다.

퀵스타트 문서도 거의 이 흐름을 따릅니다. 먼저 OAP 저장소를 실행하고, 그다음 사전 제공된 에이전트들(Tools Agent, Supervisor Agent, Deep Research Agent)을 별도 repository에서 배포한 뒤, 각 deployment의 id, tenantId, deploymentUrl, defaultGraphId 등을 NEXT_PUBLIC_DEPLOYMENTS에 넣으라고 안내합니다. 다시 말해 OAP는 자체적으로 agent logic를 생산하는 시스템이 아니라, 배포된 agent를 등록하고 운영하는 시스템입니다. (GitHub)

예제로 보면 더 쉽다

예를 들어 팀 내부 문서 검색용 에이전트를 만든다고 해봅시다.

개발자는 LangGraph로 아래 같은 그래프를 만듭니다.

• 기본 응답 노드
• RAG 검색 노드
• 필요 시 MCP 기반 외부 툴 호출 노드

그리고 설정 스키마에는 다음만 노출합니다.

• 모델 선택
• 시스템 프롬프트
• temperature
• 사용할 RAG 컬렉션
• 허용할 MCP 툴

그러면 운영자는 OAP UI에서 이렇게 일하게 됩니다.

• 고객지원 팀용 에이전트 하나 생성
• 시스템 프롬프트를 “정확하고 보수적으로 답하라”로 설정
• HR 컬렉션만 연결
• 캘린더 툴은 끄고 사내 검색 툴만 켬

이 과정에서 개발자는 그래프 코드를 다시 수정할 필요가 없습니다. OAP가 필요한 변경을 설정 계층으로 흡수해 주기 때문입니다. 이게 바로 OAP의 가장 실용적인 가치입니다. (GitHub)

언제 쓰면 좋은가

OAP는 특히 이런 팀에 잘 맞습니다.

1) LangGraph는 이미 쓰고 있는데 운영 UI가 없는 팀

이 경우 OAP는 꽤 매력적입니다. 에이전트별 설정 화면, 인증, 도구 연결, 대화 UI를 처음부터 만들지 않아도 되기 때문입니다. OAP는 LangGraph agents가 전제지만, 바로 그 제약 덕분에 LangGraph 팀에게는 도입 포인트가 분명합니다. (GitHub)

2) 비개발자에게 프롬프트/모델/툴 선택권을 넘기고 싶은 팀

OAP 문서는 처음부터 비기술 사용자 접근성을 강조합니다. 운영팀, PM, 도메인 전문가가 직접 에이전트를 조정해야 한다면 이 구조가 잘 맞습니다. (GitHub)

3) 멀티 에이전트 실험을 빠르게 해보고 싶은 팀

Supervisor Agent나 agent-to-agent 구성처럼, 하나의 챗봇이 아니라 여러 에이전트 조합을 실험하고 싶을 때 OAP의 모델은 꽤 자연스럽습니다. (GitHub)

아쉬운 점도 분명하다

하지만 한계도 명확합니다.

첫째, LangGraph 종속성이 큽니다. FAQ에 따르면 OAP에서 쓰려는 에이전트는 LangGraph Platform에 배포된 LangGraph agent여야 합니다. 범용 에이전트 관리 플랫폼이라기보다 LangGraph 전용 운영 레이어입니다. (GitHub)

둘째, 완전한 노코드라고 보긴 어렵습니다. 사용자가 UI에서 에이전트를 조립할 수는 있지만, 그 전에 개발자가 compatible한 LangGraph graph와 config schema를 만들어야 합니다. 즉 노코드의 범위는 “운영과 설정”이지 “핵심 에이전트 로직 생성”까지는 아닙니다. (GitHub)

셋째, 지금 시점에서는 아카이브된 프로젝트라는 점을 무시하면 안 됩니다. LangChain도 현재는 LangSmith의 Agent Builder를 권장하고 있습니다. 그래서 프로덕션 신규 도입 관점이라면 OAP 자체보다, OAP가 보여준 설계 아이디어를 배우는 쪽이 더 중요합니다. (GitHub)

그래서 이 프로젝트를 어떻게 봐야 할까

Open Agent Platform은 결과적으로 하나의 중요한 메시지를 남겼습니다.

에이전트는 프롬프트 묶음이 아니라 운영 대상이다.

모델을 고르고, 도구를 붙이고, 권한을 나누고, 여러 에이전트를 조합하고, 사용자가 바꿔도 되는 범위를 UI로 노출해야 합니다. OAP는 이 문제를 LangGraph의 configurable schema와 메타데이터 기반 UI 생성으로 풀려고 했습니다. 그리고 이 발상은 지금 봐도 꽤 선명합니다. (GitHub)

정리하면 OAP는 이렇게 기억하면 됩니다.

• LangGraph 기반 에이전트를 웹에서 운영 가능하게 만든 control plane
• config schema를 UI로 번역해 비개발자 운영을 가능하게 한 플랫폼
• MCP, RAG, Supervisor까지 포함한 멀티 에이전트 운영 실험
• 다만 현재는 deprecated 및 archived 상태

그래서 이 프로젝트의 진짜 가치는 “이걸 지금 바로 써라”보다,
에이전트 플랫폼을 만들 때 어떤 레이어가 필요한지 보여주는 설계 참고서라는 데 있습니다.
LangGraph를 쓰는 팀이라면 특히 더 많이 배울 수 있는 저장소입니다. (GitHub)