멀티 에이전트에 LangGraph가 필수인가요?

아닙니다. 단순 순차 체인에 병렬·휴먼 interrupt가 없으면 OpenClaw 서브 에이전트나 단일 스크립트로 충분합니다. checkpoint·병렬·interrupt가 필요할 때 LangGraph를 고려하세요.

2026 Linux 클라우드 VPS 멀티 에이전트 배포 | LangGraph 오케스트레이션 vs OpenClaw Gateway 실행 계층 FAQ

Q: OpenClaw와 LangGraph를 같은 Linux VPS에?

가능합니다. LangGraph는 루프백에서 오케스트레이션, OpenClaw Gateway는 IM/Webhook 수신——흔한 PoC입니다. 메모리·FD 한도를 보고 무거운 Worker는 Cloud Mac으로 분리하세요.

지난주 한 팀이 멀티 에이전트 파이프라인 아키텍처 글을 따라 Supervisor + Worker 토폴로지를 Linux VPS에 올렸습니다. 데모는 잘 됐고 Slack 응답도 정상처럼 보였습니다. 하지만 주말 재부팅 이후 승인 대기 상태가 사라지고, 오래된 checkpoint 기준으로 Worker가 중복 실행되며, 채널 이벤트는 들어오는데 실제 작업 상태는 엇갈리는 장애가 발생했습니다. 핵심 원인은 모델이 아니라 운영 구조였습니다. LangGraph 오케스트레이션과 OpenClaw Gateway 실행 계층을 같은 임시 세션에 묶어 둔 설계가 문제였습니다.

프로덕션에서 중요한 건 에이전트 수가 아니라 책임 경계입니다. LangGraph는 그래프 라우팅, 상태 전이, checkpoint, human interrupt 복구를 담당하고, OpenClaw Gateway는 채널 유입, Cron 스케줄, 정책 경계, 24x7 운영 가시성을 담당해야 합니다. 이 문서는 이론보다 실전 운영에 맞춘 가이드입니다. VPS에서 실제로 재현 가능한 결정 매트릭스, 최소 토폴로지, handoff 계약, systemd 기본 설정, L0-L3 장애 분리 순서를 제공합니다. Gateway 상주 운영은 OpenClaw Linux 상주 FAQ, 비용/토큰 예산은 에이전트 비용 장부 글과 함께 보면 좋습니다.

2 계층

오케스트레이션 vs 실행면

L0-L3

계층형 장애 분리

24x7

systemd 상주 목표

왜 VPS에서 오케스트레이션과 실행 계층을 분리해야 하는가

로컬에서는 Planner -> Coder -> Reviewer를 단일 루프로 붙여도 동작합니다. 그러나 Linux VPS에서 실제 사용자 트래픽을 받기 시작하면 다음 문제가 동시에 나타납니다.

유입 경로가 다양함 - Slack 명령, DM, Webhook, 정시 보고 Cron 등 각기 다른 입력을 단일 그래프 노드에서 처리하기 어렵습니다.
상태가 오래 살아야 함 - 승인 대기가 몇 시간 지속될 수 있어, 재시작 후에도 checkpoint가 반드시 이어져야 합니다.
권한 분리 필요 - 외부 메시지를 받는 Gateway가 고권한 MCP 토큰을 직접 쥐면 위험합니다.
관측 영역 분리 필요 - TLS/403/채널 검증은 Gateway 이슈, 노드 루프/상태 충돌은 LangGraph 이슈입니다. 로그를 섞으면 MTTR이 급격히 늘어납니다.

그래서 기본 원칙은 명확합니다. LangGraph는 내부 포트에서 상태 중심으로 안정 실행, OpenClaw Gateway는 별도 서비스로 채널 유입과 정책 실행을 담당합니다. Gateway는 이벤트를 정규화해 thread_id 중심 요청으로 넘기고, LangGraph는 그 상태 계보를 책임집니다. 이 분리는 도구 취향 문제가 아니라 운영 책임 설계입니다.

한 줄 역할 정의

LangGraph는 topology, memory, checkpoint, 병렬 edge, human interrupt를 관리합니다. OpenClaw Gateway는 채널/Webhook ingress, Cron, MCP egress, openclaw logs 기반 운영 문맥을 관리합니다. Gateway에 Supervisor 논리를 억지로 넣으면 유지보수 불가능한 이중 제어면이 생깁니다.

토폴로지 결정 매트릭스: Linux VPS의 대표 3가지

현장에서 자주 쓰는 패턴은 아래 3개입니다. 선택 기준은 상시 채널 요구, interrupt 지속성, 무거운 작업의 실행 위치입니다.

패턴	LangGraph	OpenClaw	적합한 상황	주요 리스크
A - 단일 호스트, 이중 서비스	`127.0.0.1:8123`	공개 리버스 프록시 + 채널	PoC, 소규모 파일럿	메모리 경쟁, 동시 업그레이드 조율
B - VPS 오케스트레이션 + 외부 무거운 Worker	VPS 내부	VPS Gateway + 클라우드 Mac Worker	Xcode, 브라우저 자동화, 장시간 작업	MCP/SSH 지연, 자격 증명 회전 누락
C - OpenClaw 경량 다중 agent	미사용 또는 배치 전용	다중 Profile/하위 agent	순차 FAQ, 단순 지원 플로우	복잡한 병렬 검토 플로우 표현 한계

A 패턴은 시작이 빠르지만 checkpoint 내구성을 놓치면 재부팅에 매우 취약합니다. B 패턴은 무거운 실행을 cloud Mac으로 분산해 VPS 안정성을 크게 높입니다. C 패턴은 요구가 단순할 때 합리적입니다. 중요한 건 "그래프가 필요한 경계"와 "Gateway에서 끝내야 할 경계"를 명확히 정의하는 것입니다.

LangGraph의 다중 에이전트 모델링은 공식 multi-agent 개념 문서, OpenClaw 쪽 채널/게이트웨이 설정은 Gateway 설정 문서를 기준으로 삼으세요.

최소 재현 토폴로지 (패턴 A)

초기 도입 시 실패 확률이 낮았던 최소 구성입니다. Linux VPS, TLS, 기본 프록시가 준비되어 있다는 가정입니다.

LangGraph API 서비스 - FastAPI로 감싸고 127.0.0.1:8123에서 수신, checkpoint는 영속 스토리지로 보냅니다.
OpenClaw Gateway 서비스 - OpenClaw CLI 문서 기반 설치, 외부 노출은 프록시에서 통제합니다.
브리지 규칙 - 채널 이벤트를 Gateway에서 의도형 payload로 정규화해 graph run API를 호출합니다.
systemd 분리 - langgraph-api.service와 openclaw.service를 별도 단위로 관리해 장애 전파를 줄입니다.

systemd 스니펫 (LangGraph API 예시)

# /etc/systemd/system/langgraph-api.service
                [Unit]
                Description=LangGraph multi-agent API
                After=network-online.target

                [Service]
                User=deploy
                WorkingDirectory=/opt/langgraph-app
                Environment=CHECKPOINT_DIR=/var/lib/langgraph-checkpoints
                ExecStart=/opt/langgraph-app/.venv/bin/uvicorn main:app --host 127.0.0.1 --port 8123
                Restart=on-failure
                RestartSec=5

                [Install]
                WantedBy=multi-user.target

서비스 활성화 후에는 ss -lntp로 공개 포트를 확인하세요. 외부는 443 프록시만 열고, 그래프 API는 내부로 제한하는 것이 안전합니다. 이 기준을 지키면 배포/롤백/장애 대응에서 영향 범위를 예측하기 쉬워집니다.

handoff 계약: Gateway가 그래프에 넘겨야 할 데이터

분리 아키텍처에서 장애를 부르는 가장 흔한 원인은 계약 없는 payload입니다. 아래처럼 스키마를 고정하세요.

thread_id - 채널 스레드와 그래프 상태 계보를 고정 매핑하는 키.
intent - new_task, approve, cancel, status 같은 제한된 enum.
payload - repo URL, 대상 경로, 사용자 지시 등 구조화 정보. 대용량 파일은 객체 저장소 참조로 전달.
caller_scope - 채널/사용자 범위 정보. Gateway 검증 후에도 그래프에서 재검증.

LangGraph의 memory/checkpoint 모델은 장기 상태를 위해 설계되었습니다. Gateway가 별도 세션 상태기를 들고 있으면 결국 split-brain 현상이 생깁니다. 채널은 완료라고 말하지만 그래프는 여전히 실행 중인 상황이 대표적입니다.

human interrupt는 어디에 둬야 하나?

승인 대기/재개 상태는 LangGraph에 둬야 합니다. Gateway는 버튼 이벤트를 intent=approve 호출로 변환만 수행하세요. 승인 상태를 Gateway 임시 메모리에 두면 재시작 순간 플로우가 끊깁니다.

L0-L3 계층형 트러블슈팅

"봇이 조용하다"는 보고를 받으면, 두 계층을 동시에 수정하지 말고 아래 순서로 증거를 모으세요.

L0: systemd와 포트

systemctl status openclaw langgraph-api로 서비스 상태를 먼저 확정합니다. 그래프 API가 죽어 있어도 Gateway는 이벤트를 받기 때문에 오진이 흔합니다.

L1: OpenClaw 채널/브리지 로그

openclaw logs에서 Webhook 수신, 서명 검증, 브리지 URL을 확인합니다. 403/TLS/재시도 폭주는 L1 영역입니다.

L2: LangGraph trace와 checkpoint

같은 thread_id로 상태를 조회해 멈춘 노드를 찾습니다. checkpoint 권한/마운트 오류는 "매번 새 대화" 증상으로 나타납니다.

L3: 원격 Worker와 MCP

패턴 B에서는 원격 실행이 병목일 수 있습니다. NO_PROXY, 네트워크 경로, 토큰 만료, 원격 호스트 쿼터를 점검하세요.

배포 전 체크리스트 (30분)

LangGraph는 내부 인터페이스만 바인딩, 외부 진입점은 Gateway로 단일화.
checkpoint 저장소는 영속/백업 대상에 포함.
Gateway -> graph 타임아웃을 채널 재시도 창보다 짧게 설정.
노드별 도구 권한 화이트리스트를 명시하고 Reviewer 쓰기 권한 제거.
재부팅 리허설로 interrupt 복구와 Cron 중복 실행 여부 확인.
단일 trace id를 ingress부터 Worker 로그까지 관통.

자주 터지는 운영 실수

Supervisor 논리를 Gateway 전역 프롬프트에 넣고, checkpoint를 /tmp에 저장하고, ingress 계층과 고권한 도구가 같은 키를 쓰고, 무거운 브라우저 작업을 4GB VPS에 같이 올리는 조합입니다. 각각 단독으로도 사고를 만듭니다.

FAQ

멀티 에이전트면 반드시 LangGraph가 필요합니까?

아닙니다. 순차 작업, 단기 실행, 승인 대기 없음이라면 OpenClaw 경량 구성으로 충분할 수 있습니다. checkpoint/병렬 분기/interrupt 요구가 생길 때 도입하는 편이 안전합니다.

OpenClaw와 LangGraph를 같은 Linux VPS에 둘 수 있나요?

가능합니다. 다만 무거운 Worker는 cloud Mac으로 분리하고 VPS는 Gateway + 오케스트레이션 API 안정성에 집중하는 것이 좋습니다.

기존 OpenClaw 운영 환경에서 점진적으로 그래프를 붙이려면?

먼저 저위험 경로 한 개(Cron 한 종류 등)만 브리지로 연결하세요. 안정성 확인 후 Supervisor 의사결정 경로를 단계적으로 이전하면 됩니다.