홈으로 돌아가기

OpenClaw 아키텍처: 노드와 게이트웨이

OpenClaw는 주변 기기를 위한 노드와 UI를 위한 Canvas와 함께 중앙 허브인 Gateway를 중심으로 구축되었습니다. 이 기사는 액터, 상호작용, 5가지 실제 사례(CRM, 브리핑, 카트, 오케스트레이션, 3D 프린터)를 분석합니다.

OpenClaw: 노드, 게이트웨이, 캔버스 작동 방식
Advertisement 728x90

OpenClaw 아키텍처: 핵심 구성 요소와 상호작용

OpenClaw는 중앙 게이트웨이(Gateway)를 제어 평면으로 하는 허브-스포크 아키텍처를 사용합니다. 이 구조는 에이전트가 주변 기기와 I/O 채널과 상호작용할 수 있게 합니다. 노드(node), 세션(session), 채널(channel), 오퍼레이터(operator)의 역할을 이해하면 중급 이상 개발자들이 시스템 설정과 활용을 더 쉽게 할 수 있습니다.

노드(Node)는 동반 기기로 작동하며, role: "node"로 WebSocket을 통해 게이트웨이에 연결됩니다. node.invoke를 통해 canvas., camera., device., notifications., system.*, system.run 등의 명령 인터페이스를 제공합니다.

역할과 액터 간 상호작용

게이트웨이는 노드와 오퍼레이터의 연결을 관리하고, 채널과 세션을 조정하며, 기기 페어링을 처리합니다. 채널은 WhatsApp, Telegram, Discord, Slack, Signal 같은 메신저와 통합되어 메시지를 세션 → 에이전트로 라우팅하고 역방향으로 전달합니다.

Google AdInline article slot

| 액터 | 책임 | 상호작용 |

|---------------|-------------------------------|-------------------------------------|

| 게이트웨이 | 제어 평면 | 노드/오퍼레이터 연결, 세션/채널 관리 |

Google AdInline article slot

| 채널 | 메신저 통합 | 메시지 → 게이트웨이 → 세션 → 에이전트 |

| 노드 | 주변 기기 | role: node로 연결, node.invoke |

| 오퍼레이터| 관리 | 페어링, 승인, 설정 |

Google AdInline article slot

| 세션 | 에이전트 컨텍스트 | 히스토리와 상태 저장 |

| 에이전트 | AI 런타임 | 세션 내 도구/노드 호출 |

| 사용자 | 최종 사용자 | 채널/오퍼레이터를 통해 |

| 기기 | 연결된 기기 | 게이트웨이를 통한 페어링 |

흐름: 사용자 → 채널 → 게이트웨이 → 세션 → 에이전트 → 노드/채널. 오퍼레이터가 페어링과 작업을 승인합니다.

노드 유형:

  • macOS 메뉴바 앱
  • iOS/Android (카메라, GPS, 화면용)
  • 서버용 헤드리스 (openclaw node run)
  • VS Code 확장

생태계 내 Canvas와 A2UI

Canvas는 에이전트가 제어하는 시각적 작업 공간입니다. A2UI는 인터페이스를 동적으로 생성하는 프로토콜입니다. 에이전트가 canvas.present 또는 canvas.a2ui.push를 호출해 JSON UI 설명을 생성하면, 노드(macOS, iOS, Android, 웹)에서 렌더링됩니다.

사용 사례:

  • 동적 대시보드
  • 인터랙티브 폼
  • 데이터 시각화
  • AI 네이티브 앱 (CRM, 모니터링)
  • 게임, 갤러리

사용자 작업은 WebSocket을 통해 에이전트로 실시간 업데이트됩니다.

실제 사례: 개인 CRM

문제: Gmail, WhatsApp, 캘린더, Notion에 흩어진 데이터.

사용자 흐름: Telegram 메시지: "이반 이바노프 프로필." 에이전트가 탭, 필드, 히스토리가 있는 Canvas를 엽니다.

결과: 실시간 업데이트되는 통합 AI 기반 CRM.

아키텍처: 채널 → 게이트웨이 → 세션 → 에이전트 (canvas 스킬 + A2UI) → 노드 (UI). 오퍼레이터가 승인 처리; 데이터는 세션에 저장.

실제 사례: 아침 브리핑

문제: 캘린더, 이메일, 날씨 수집에 10~15분 소요.

사용자 흐름: "브리핑" → "모스크바 날씨" 등의 후속 질문.

결과: Canvas에 차트가 포함된 요약.

아키텍처: 게이트웨이 스케줄 작업 → 세션 → 에이전트 (스킬: 캘린더/이메일/날씨) → 채널/Canvas. 헤드리스 노드 선택적.

실제 사례: 가족 쇼핑 리스트

문제: 그룹 채팅의 혼란.

사용자 흐름: Telegram 그룹 메시지 → "장바구니 보기" → 리스트와 버튼이 있는 Canvas.

결과: 모바일 노드에서 최신 리스트.

아키텍처: 채널 (그룹) → 게이트웨이 → 세션 → 에이전트 (파싱, canvas) → 모바일 노드. 작업은 WebSocket.

실제 사례: 다중 에이전트 오케스트레이션

문제: 단일 에이전트의 집중력 상실.

사용자 흐름: "점呼" → 작업 위임.

결과: 에이전트 팀의 최종 보고서.

아키텍처: 게이트웨이 (다중 세션) → 리드 에이전트 (위임) → 에이전트별 노드 → 채널.

실제 사례: 3D 프린터 팜

문제: Bambu Lab 프린터 수동 모니터링.

사용자 흐름: "X1C 상태", "Benchy 출력", "카메라 보기".

결과: 카메라 피드와 원격 제어.

아키텍처: 채널 → 게이트웨이 → 세션 → 에이전트 → 물리적 노드 (Bambu 통합) → 프린터.

주요 요점

  • 게이트웨이는 중앙 허브—이 없이는 아무것도 작동하지 않습니다.
  • 노드는 에이전트를 서버(헤드리스)나 센서(모바일) 기기로 확장합니다.
  • Canvas/A2UI는 채팅을 완전한 UI로 변환합니다.
  • 세션은 컨텍스트를 격리하고 메모리를 저장합니다.
  • 오퍼레이터는 보안 페어링과 승인을 보장합니다.

— Editorial Team

Advertisement 728x90

다음 읽기