오픈클로(OpenClaw)란? 설치·채널 연결·모델·보안까지 보는 AI 에이전트 가이드

메신저에 질문을 보내고 답변을 받는 AI 서비스는 이미 익숙해요. 오픈클로(OpenClaw)는 여기서 한 단계 더 나아가, 사용자가 직접 관리하는 컴퓨터나 서버에 AI 에이전트를 두고 메신저·도구·파일·자동화 기능을 연결하는 오픈소스 프로젝트예요. 공식 문서는 OpenClaw를 여러 채팅 앱과 AI 에이전트를 연결하는 셀프 호스팅 게이트웨이로 설명해요.[1]

이 차이를 이해하지 못하면 오픈클로를 단순한 챗봇 앱으로 생각하기 쉬워요. 실제로는 게이트웨이 프로세스가 대화 세션과 라우팅, 채널 연결을 관리하고, 사용자가 선택한 모델과 도구가 그 위에서 동작하는 구조에 가까워요.[1][2]

이 글에서는 2026년 9월 6일 확인한 공식 문서와 저장소를 기준으로 오픈클로의 구조, 설치 흐름, 지원 채널, 모델 연결 방식, 보안 설정, 적합한 사용자와 주의할 점을 정리해요. 공식 문서에 없는 실제 성능이나 안정성은 확인된 사실처럼 쓰지 않았어요.

오픈클로는 어떤 프로그램일까?

오픈클로의 핵심은 내 장비에서 실행하는 AI 비서와 여러 대화창 사이의 중계기예요. 공식 문서에 따르면 하나의 Gateway가 채널 플러그인, WebChat, 모바일 노드와 연결되고, 세션·라우팅·채널 연결의 기준점 역할을 해요.[1]

따라서 구조를 단순화하면 다음과 같아요.

1. 사용자가 Telegram, Discord, WhatsApp, Slack 같은 채널에서 메시지를 보내요.[1][2]
2. OpenClaw Gateway가 메시지를 받아 어떤 에이전트와 세션으로 보낼지 판단해요.[1][2]
3. 선택한 모델이 답변을 만들고, 필요하면 브라우저·셸·파일·스킬 같은 도구를 호출해요.[1][2]
4. 결과가 원래 대화 채널로 돌아와요.[1][2]

공식 저장소는 OpenClaw를 사용자의 장치에서 실행되며 모델, 도구, 메시징 채널, 보조 앱을 하나의 Gateway로 연결하는 AI 비서라고 설명해요.[2] 이 구조 때문에 오픈클로의 장점은 모델 자체보다 연결성과 실행 권한을 한곳에서 관리한다는 점에 있어요.[1][2]

다만 셀프 호스팅이라고 해서 모든 데이터가 자동으로 컴퓨터 밖으로 나가지 않는다는 뜻은 아니에요.[1] 선택한 모델 제공자의 API를 사용하면 대화나 도구 실행에 필요한 정보가 해당 제공자에게 전달될 수 있어요.[6] 로컬 모델을 연결하면 이 경로를 줄일 수 있지만, 모델을 직접 운영해야 하는 부담이 생겨요.[6]

ChatGPT 같은 서비스와 무엇이 다를까?

일반적인 클라우드 AI 서비스는 계정으로 로그인한 뒤 웹이나 앱에서 바로 사용해요. 서버 운영, 채널 연결, 권한 경계를 직접 설계할 필요가 거의 없죠.

오픈클로는 반대쪽에 가까워요.

오픈클로의 자유도는 편리함과 같은 말이 아니에요. 채널 토큰, 모델 인증, 게이트웨이 접근 범위, 도구 권한을 직접 정해야 하므로 작은 개인 서버를 운영하는 경험이 필요해요.

핵심 구성 요소: Gateway, 에이전트, 채널

Gateway가 중심이에요

오픈클로 문서에서 Gateway는 세션, 라우팅, 이벤트, 채널 연결을 담당하는 로컬 제어 평면이에요.[1][2] Control UI와 CLI, TUI, 채널 플러그인은 Gateway에 연결되고, Gateway가 각 요청의 상태를 관리해요.[2]

기본 Control UI는 로컬 주소 http://127.0.0.1:18789/에서 열리도록 안내돼요.[1] 이 주소는 외부 공개용 웹사이트 주소가 아니라 같은 컴퓨터에서 관리 화면에 접근하기 위한 기본값이에요.[1] 원격 접속이 필요하다면 VPN·Tailnet·SSH 같은 별도 접근 경로와 인증을 함께 설계해야 해요.[1]

채널은 여러 개를 동시에 연결할 수 있어요

공식 채널 문서는 Discord, Feishu, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo 등을 비롯해 여러 메시징 서비스를 Gateway에 연결할 수 있다고 안내해요.[4] 채널은 동시에 사용할 수 있고, 오픈클로가 대화별로 라우팅해요.[4]

Telegram은 봇 토큰을 이용하는 방식이라 상대적으로 시작하기 쉬운 채널로 안내돼요.[4] WhatsApp은 QR 페어링과 로컬 상태 저장이 필요해 설정 방식이 달라요.[4] 채널 이름만 보고 설정 난이도가 같다고 생각하면 안 되는 이유예요.

에이전트와 세션은 분리해서 생각해야 해요

오픈클로는 한 명의 사용자와 하나의 대화만 처리하는 구조에 머물지 않아요.[1] 공식 개요는 에이전트별·워크스페이스별·발신자별 격리 세션과 다중 에이전트 라우팅을 주요 기능으로 소개해요.[1]

이 기능은 개인 업무와 팀 업무를 분리하거나, 서로 다른 프로젝트에 다른 파일·도구·모델 설정을 적용할 때 유용해요.[1] 하지만 팀원에게 채널을 열어 주는 순간에는 “같은 Gateway를 공유해도 되는가”를 먼저 판단해야 해요.[1] 팀 기능이 있다는 사실이 자동으로 안전한 멀티테넌트 환경을 보장하는 것은 아니에요.

모델은 어디에서 가져올까?

오픈클로는 특정 모델 하나에 묶인 제품이 아니에요. 공식 모델 제공자 문서는 OpenAI·Anthropic 같은 호스팅 제공자와 OpenAI 호환 인터페이스를 제공하는 로컬 서버를 함께 다뤄요.[6]

로컬 실행 경로로는 LM Studio, vLLM, LiteLLM, llama.cpp 계열처럼 OpenAI 호환 API를 제공하는 서버를 연결할 수 있어요.[6] 이때 오픈클로가 모델을 대신 실행하는 것이 아니라, 사용자가 실행해 둔 로컬 서버의 API 엔드포인트를 모델 제공자로 등록하는 방식으로 이해하면 쉬워요.[6]

선택지는 크게 세 가지예요.[6]

• 호스팅 API: 설치가 간단하고 강한 모델을 바로 사용할 수 있지만, API 비용과 외부 전송 범위를 확인해야 해요.[6]
• 로컬 모델 서버: 데이터 경로를 통제하기 쉽고 반복 사용 비용을 줄일 수 있지만, RAM·VRAM·설정·속도 문제를 직접 관리해야 해요.[6]
• 혼합 구성: 평소에는 로컬 모델을 쓰고, 긴 문맥이나 복잡한 도구 작업에는 호스팅 모델을 보조로 사용하는 방식이에요.[6]

오픈클로에서 로컬 모델을 쓴다고 해서 곧바로 ChatGPT급 도구 사용 품질이 보장되지는 않아요.[6] 모델의 함수 호출 지원, 긴 문맥 처리, 출력 형식 준수, 도구 선택 능력, 로컬 서버의 API 호환성을 따로 확인해야 해요.[6] 공식 문서가 “연결 가능”하다고 설명하는 것과 내 컴퓨터에서 원하는 작업이 안정적으로 끝난다는 것은 다른 주장입니다.[6]

설치 흐름과 필요한 환경

공식 설치 문서는 macOS, Linux, Windows를 지원하고, 설치 프로그램이 필요한 Node.js 런타임을 준비할 수 있다고 안내해요.[2][3] 2026년 9월 6일 확인 기준 공식 저장소의 최신 릴리스는 2026.9.2예요.[8]

공식 문서에 적힌 기본 흐름은 다음과 같아요.[3]

# macOS / Linux / WSL2
curl -fsSL https://openclaw.ai/install.sh | bash

Windows PowerShell에서는 공식 설치 스크립트를 사용해요.[2][3][8]

iwr -useb https://openclaw.ai/install.ps1 | iex

Node.js를 직접 관리하는 사용자는 npm 패키지 설치 경로도 사용할 수 있어요.[2] 저장소는 Node.js 22.22.3 이상, 24.15 이상 또는 25.9 이상을 지원 범위로 안내하고, npm 버전에 따라 lifecycle script 허용 옵션이 달라질 수 있다고 설명해요.[2][3]

설치 후에는 온보딩으로 모델 접근과 워크스페이스, Gateway 설정을 진행해요.[2][3][8]

openclaw onboard --install-daemon
openclaw gateway status
openclaw dashboard

온보딩이 끝났다고 바로 외부 채널부터 연결할 필요는 없어요.[3] 먼저 Control UI에서 짧은 메시지를 보내 모델 응답이 나오는지 확인하고, 그다음 Telegram 같은 채널 하나를 연결하는 순서가 안전해요.[3] 공식 시작 가이드도 설치·온보딩 이후 채널 연결과 pairing·보안 설정을 별도 단계로 안내해요.[3]

설치 전에 확인할 것

• Gateway를 계속 켜 둘 컴퓨터가 있는지 확인해요.
• 사용할 모델 제공자와 인증 방식을 정해요.
• 외부 메시지를 받을 채널 계정과 봇 계정을 분리할지 결정해요.
• 파일 읽기·쓰기, 셸 실행, 브라우저 사용이 정말 필요한지 정해요.
• 백업할 설정과 세션 데이터의 위치를 확인해요.
• 집 밖에서 접속할 경우 VPN이나 Tailnet 등 접근 경로를 먼저 설계해요.

보안: 설치보다 먼저 읽어야 하는 부분

오픈클로는 메시지에 답하는 프로그램을 넘어 호스트의 도구를 호출할 수 있기 때문에, 보안 설정을 나중에 미루면 안 돼요.[5][7] 공식 보안 문서는 외부에서 들어오는 메시지를 신뢰하지 않는 입력으로 취급하라고 안내해요.[5]

기본적으로 확인할 중요한 경계는 다음과 같아요.[5]

1. DM pairing과 허용 목록

알 수 없는 발신자가 DM을 보낼 수 있는 채널에서는 pairing과 허용 목록을 사용해 누가 에이전트에 접근할 수 있는지 제한해야 해요.[2][5] 공식 문서의 보안 기준 예시는 Gateway를 loopback에 묶고, 토큰 인증을 켜고, DM pairing을 사용하며, 그룹 대화에서는 멘션이 있어야 답하도록 설정해요.[5]

2. Gateway를 인터넷에 바로 공개하지 않기

127.0.0.1에 바인딩된 로컬 Gateway와 인터넷에 노출된 Gateway는 위험도가 전혀 달라요.[5] 외부 공개가 필요하다고 해서 포트를 그대로 열기보다 인증, 네트워크 접근 제어, 암호화된 원격 연결을 함께 구성해야 해요.[5] 공식 보안 문서도 노출을 줄이기 위해 loopback 바인딩과 토큰 인증을 권장하는 예시를 제공해요.[5]

3. 도구 권한은 모델 능력과 별개예요

모델이 똑똑하다고 해서 셸 명령이나 파일 삭제 권한을 줘도 안전하다는 뜻은 아니에요. 오픈클로 문서는 메인 세션의 도구가 호스트에서 실행될 수 있고, 샌드박싱을 별도로 구성해야 한다고 설명해요.[2][5]

실험 단계에서는 파일 쓰기·셸 실행·브라우저 자동화처럼 영향 범위가 큰 도구를 최소화하고, 개인 파일이 없는 별도 작업 디렉터리를 사용하는 편이 좋아요. 삭제·전송·구매·계정 변경처럼 되돌리기 어려운 동작은 사람의 승인을 거치는 정책이 필요해요.[2][5]

4. 샌드박스는 만능 방패가 아니에요

공식 샌드박싱 문서는 컨테이너 기반 실행에서 네트워크가 기본적으로 꺼질 수 있고, 환경 변수와 비밀값 전달에도 별도 주의가 필요하다고 안내해요.[7] 샌드박스를 켰다는 표시만으로 호스트 파일·네트워크·토큰 접근이 모두 차단됐다고 단정하면 안 돼요.[7]

샌드박스 이미지, 네트워크 정책, 마운트 경로, 환경 변수, 브라우저 프로필을 실제 설정과 함께 점검해야 해요.[7] 특히 API 키를 샌드박스에 넣으면 편리하지만, 컨테이너 메타데이터나 실행 로그에 노출되지 않는지도 확인해야 해요.[7]

오픈클로가 잘 맞는 사용자

오픈클로는 다음 조건에 가까울수록 잘 맞아요.

• Telegram이나 Discord에서 AI에게 반복 업무를 맡기고 싶은 사용자
• 집이나 사무실의 Mac·Linux 서버를 항상 켜 둘 수 있는 사용자
• 모델 API와 로컬 모델 서버의 차이를 이해하는 사용자
• 파일·브라우저·셸 도구에 필요한 권한만 좁혀서 줄 수 있는 사용자
• 여러 프로젝트나 팀원의 세션을 분리하고 싶은 사용자
• 클라우드 서비스보다 데이터 흐름과 배포 위치를 직접 통제하고 싶은 사용자

반대로 “설치 후 아무 설정 없이 안전하게 모든 일을 해 주는 비서”를 기대한다면 맞지 않을 수 있어요. 오픈클로는 강력한 자동화를 제공하는 만큼, 운영자가 권한과 실패 범위를 정해야 하는 도구예요.

실제로 쓸 때의 권장 시작 순서

처음부터 모든 채널과 도구를 켜는 방식은 권하지 않아요. 다음 순서가 현실적이에요.

1. 별도 사용자 계정이나 전용 컴퓨터에 OpenClaw를 설치해요.
2. 호스팅 모델 하나로 Control UI 응답만 확인해요.
3. Gateway를 loopback에 둔 채 pairing과 토큰 인증을 설정해요.
4. Telegram 또는 다른 채널 하나만 연결해요.
5. 읽기 전용 작업부터 시켜요. 예를 들면 일정 요약, 파일 목록 확인, 문서 검색처럼 되돌릴 필요가 없는 일부터 시작해요.
6. 도구 호출 로그와 세션 기록을 확인해요.
7. 필요할 때만 쓰기·셸·브라우저 권한을 단계적으로 추가해요.
8. 로컬 LLM을 연결할 경우 같은 작업을 호스팅 모델과 비교해요.

이 과정은 오픈클로가 공식적으로 보장하는 성능 순서가 아니라, 권한을 한 번에 넓히지 않기 위한 운영 권장안이에요. 실제 안정성과 속도는 장비, 모델, 채널, 네트워크, 작업 종류에 따라 달라져요.

결론: 오픈클로의 본질은 AI 모델보다 운영 구조에 있어요

오픈클로를 평가할 때 “어떤 모델을 쓰느냐”만 보면 핵심을 놓치기 쉬워요.[1] 이 프로젝트의 중심은 하나의 Gateway로 대화 채널, 세션, 모델, 도구, 스킬, 자동화를 연결하는 운영 구조예요.[1][2]

그래서 매력도 분명해요. 내 컴퓨터에 둔 AI를 Telegram이나 Discord에서 부를 수 있고, 호스팅 모델과 로컬 모델을 상황에 따라 바꿀 수 있으며, 여러 에이전트와 작업 공간을 분리할 수 있어요.[1][4][6]

동시에 책임도 커져요. 메시지 발신자 확인, Gateway 노출 범위, API 키, 파일 권한, 셸 실행, 샌드박스, 백업을 운영자가 챙겨야 해요.[5][7] 오픈클로는 설치 명령 하나로 끝나는 소비자용 앱이라기보다, 개인용 AI 자동화 서버에 가까워요.[1]

처음 시작한다면 채널 하나, 모델 하나, 읽기 중심 도구만 켜고 작은 작업부터 검증하는 편이 좋아요. 그 결과가 만족스러울 때 로컬 LLM이나 추가 채널, 자동화 권한을 넓히면 실패했을 때 원인을 찾기도 쉬워요.

시작 전 체크리스트

• □ 공식 설치 문서의 현재 Node.js와 설치 경로를 확인했나요?
• □ Gateway를 계속 실행할 장비와 백업 위치를 정했나요?
• □ 사용할 모델 제공자와 외부 전송 범위를 확인했나요?
• □ DM pairing과 허용 목록을 설정했나요?
• □ Gateway를 인터넷에 직접 공개하지 않았나요?
• □ 파일·셸·브라우저 도구에 필요한 최소 권한만 부여했나요?
• □ 샌드박스의 네트워크·마운트·환경 변수 설정을 확인했나요?
• □ 되돌릴 수 없는 작업에는 사람 승인 절차를 두었나요?

Sources

• [1] OpenClaw 공식 문서 개요
• [2] OpenClaw 공식 GitHub 저장소
• [3] OpenClaw 설치 문서
• [4] OpenClaw 채널 문서
• [5] OpenClaw 보안 문서
• [6] OpenClaw 모델 제공자 문서
• [7] OpenClaw 샌드박싱 문서
• [8] OpenClaw 최신 릴리스