에이전트 인터페이스의 변화

최근 오픈소스 생태계에서 AI 에이전트와 사용자를 연결하는 인터페이스에 대한 고민이 깊어지고 있다. 대부분의 AI 도구가 전용 웹 콘솔이나 복잡한 대시보드를 제공하는 방향으로 발전해 온 것과 달리, 일상적으로 사용하는 메신저를 에이전트의 직접적인 실행 환경으로 탈바꿈시키려는 시도가 늘고 있다.

오늘 소개할 오픈클로(OpenClaw)는 내 컴퓨터에서 직접 돌아가는 오픈소스 AI 에이전트 게이트웨이다. 단순한 챗봇 묶음이 아니라, 텔레그램이나 디스코드 같은 메신저와 언어 모델 사이에 위치하여 세션과 권한을 통제하는 로컬 런타임 역할을 한다. 사용자가 자신의 데이터와 에이전트의 실행 경로를 완전히 통제할 수 있다는 점이 이 프로젝트의 핵심이다.

업데이트 (2026. 02. 23)

프로젝트의 영향력이 급속도로 커지면서, 2026년 2월 23일 오픈클로의 창립자 피터 스타인버거와 코어 팀이 오픈AI(OpenAI)로 합류했다는 소식이 전해졌다. 다행히 오픈클로 자체는 독립적인 오픈소스 재단 아래에서 지속적으로 유지보수될 예정이다.

메신저가 곧 실행 런타임이 될 때

오픈클로가 짧은 시간에 개발자들의 시선을 끈 이유는 직관적인 사용성에 있다. 전용 웹사이트에 접속하거나 별도의 앱을 설치할 필요 없이, 매일 쓰는 메신저 대화창에서 에이전트에게 바로 명령을 내릴 수 있다. 텍스트뿐만 아니라 이미지, 오디오, 문서 등 다양한 포맷의 입출력을 메신저의 네이티브 UI로 처리한다.

출처: OpenClaw 공식 문서

메신저 인터페이스를 채택함으로써 사용자는 새로운 도구의 사용법을 학습할 필요가 사라진다. 또한 플러그인 아키텍처를 통해 슬랙(Slack), 왓츠앱(WhatsApp) 등 새로운 메신저 채널을 쉽게 연동할 수 있어 확장성이 뛰어나다. 이는 에이전트와의 상호작용이 일상적인 대화의 흐름 속에 자연스럽게 녹아들게 만든다.

이름 변천사와 성장 배경

이 프로젝트는 흥미로운 탄생 배경을 가지고 있다. PSPDFKit의 창업자인 베테랑 엔지니어 피터 스타인버거(Peter Steinberger)가 평소 쓰던 메신저로 컴퓨터에 명령을 내리고 싶어 주말 프로젝트로 시작한 것이 출발점이다.

초기에는 WhatsApp 게이트웨이라는 의미의 Warelay로 시작했다. 이후 Claude 모델 활용을 강조한 Clawdbot(Clawd)으로 변경했으나, 상표권 문제로 급하게 가재의 탈피를 뜻하는 Moltbot으로 이름을 바꿨다. 최종적으로 2026년 1월 말, 불과 몇 시간 만에 현재의 OpenClaw로 프로젝트 이름과 저장소를 완전히 옮기며 안착했다.

출처: GitHub: OpenClaw

위와 같이 짧은 기간 동안 GitHub 스타가 급상승한 흐름은, 개인의 불편함을 해소하기 위해 만든 도구가 얼마나 빠르고 강렬하게 오픈소스 커뮤니티의 요구와 맞아떨어졌는지를 보여준다.

에이전트 전용 커뮤니티가 주는 놀라움, 몰트북

주위에서 오픈클로 얘기가 나올 때 특히 자주 언급되며 사람들을 놀라게 한 부분은 몰트북(Moltbook)의 존재다. 이곳은 인간이 아닌 AI 에이전트들이 모여 상호작용하는 별도의 커뮤니티 공간이다.

출처: Moltbook.com

실제로 몰트북에 들어가 보면 여러 에이전트가 사용자의 개입 없이 서로 지식을 교환하고 있다. 단순히 질문에 답하는 봇을 넘어, 다른 에이전트와 자율적으로 소통하는 모습은 오픈클로가 단순한 메신저 도구 이상이라는 느낌을 준다. 궁금하면 한 번 들어가서 확인해 보자. 참 신기하다.

보안 우려에 대한 오픈클로의 대응 전략

강력한 자율성은 필연적으로 보안에 대한 우려를 낳는다. 질문과 답변을 주고받는 수준을 넘어, 에이전트가 로컬 파일 시스템을 읽고 쓰거나 쉘 명령어를 실행할 수 있는 권한을 얻는 순간 보안 리스크는 급격히 커진다. 실제로 강력한 도구 실행 권한이 악용될 여지가 있어, 일부 기업에서는 사내망 내 오픈클로 사용을 선제적으로 제한하기도 했다.

따라서 오픈클로를 무작정 설치해서 사용하기 전에 관련 내용을 인지하고 가는 것이 중요하다. 물론 오픈클로는 커뮤니티에서 끊임없이 거론되는 이러한 보안 문제를 인지하고 있으며, 시스템 설계 단계부터 위험을 통제할 수 있는 다양한 대응 장치들을 마련해 두고 있다.

3계층 게이트웨이 구조를 통한 통제

오픈클로는 권한 통제를 위해 3계층 아키텍처를 채택했다. 시스템의 중심에는 세션 관리와 메시지 라우팅을 담당하는 게이트웨이가 위치한다. 이 게이트웨이를 기준으로 위로는 외부 통신을 담당하는 채널(메신저)이 붙고, 아래로는 실제 작업을 수행하는 에이전트가 연결된다.

이러한 계층 분리는 직접적인 접근을 차단하는 역할을 한다. 다양한 메신저 플랫폼의 서로 다른 권한 모델을 게이트웨이 단일 지점에서 일관되게 정책화하고 통제할 수 있게 해준다.

세밀한 도구 접근 권한 제어

에이전트가 사용할 수 있는 도구의 범위를 사용자가 직접 제어할 수 있다. 접근 가능한 파일 시스템 경로나 네트워크 리소스를 화이트리스트 방식으로 세밀하게 설정하여, 에이전트의 무분별한 권한 남용을 원천적으로 막는다.

로컬 런타임의 물리적/논리적 격리

에이전트에게 캘린더나 메일 접근 같은 유용한 권한을 부여하고 싶지만, 메인 PC의 전체 제어권을 넘기는 것은 여전히 위험할 수 있다.

이 때문에 실무 환경에서는 오픈클로 런타임을 맥 미니(Mac Mini)나 별도의 가상 머신(VM) 같은 철저히 격리된 환경에 배포하는 전략이 자주 권장된다. 물리적 혹은 논리적으로 샌드박싱된 장비에서 게이트웨이를 구동하고 제한된 권한의 컨테이너 내부에서만 에이전트가 스크립트를 실행하도록 구성하여, 최악의 경우에도 피해 범위를 격리된 공간 안으로 한정 짓는다.

어떻게 사용할까?

이 글에서는 2026년 2월 1일 시점의 공개 릴리스인 v2026.1.30 버전을 기준으로 한다.

오픈클로를 로컬에 구축하고 테스트 환경을 구성하는 흐름은 꽤 직관적이다. 터미널에서 명령어 몇 번만 입력하면 곧바로 나만의 에이전트 런타임을 띄워볼 수 있다.

빠른 설치와 대시보드 접근

설치 스크립트를 통해 CLI를 준비하고, 온보딩 명령어로 초기 설정을 마치는 것이 가장 일반적인 시작 경로다.

# 1. 오픈클로 CLI 전역 설치 및 데몬 설치
npm install -g openclaw@latest
openclaw onboard --install-daemon

온보딩 과정에서 인증과 게이트웨이 설정이 차례로 진행된다. 특히 사내망에 구축된 로컬 LLM이나 프라이빗 모델을 커스텀 엔드포인트로 지정하여, 외부로의 데이터 유출 없이 에이전트를 테스트해 볼 수도 있다.

다만 앞서 언급한 것처럼 오픈클로 사용을 제한한 기업이 많으니, 꼭 사내 보안 부서의 확인을 받자.

# 2. 메시징 채널(WhatsApp 등) 로그인
openclaw channels login

# 3. 게이트웨이 상태 확인 및 대시보드 접속
openclaw gateway status
openclaw dashboard

설정 후 dashboard 명령을 통해 Control UI에 접속하면, 메신저 채널을 연동하기 전이라도 에이전트의 기본 동작과 도구 호출(Tool calling) 로그를 브라우저에서 직접 디버깅할 수 있다.

채널 보안과 그룹 채팅 설정

실제로 메신저와 연동할 때 유용한 기능 중 하나는 세밀한 채널 통제다. ~/.openclaw/openclaw.json 설정 파일을 수정하면 특정 사용자의 접근만 허용하거나, 그룹 채팅에서의 에이전트 동작 방식을 조정할 수 있다.

{
  "channels": {
    "whatsapp": {
      "allowFrom": [
        "+15555550123"
      ],
      "groups": {
        "*": {
          "requireMention": true
        }
      }
    }
  },
  "messages": {
    "groupChat": {
      "mentionPatterns": [
        "@openclaw"
      ]
    }
  }
}

위와 같이 설정하면 지정된 연락처의 요청에만 응답하며, 그룹 채팅에서는 @openclaw처럼 명시적으로 멘션했을 때만 에이전트가 개입하게 된다. 채널 내 무분별한 봇의 응답을 막고 사용자가 원할 때만 에이전트를 호출할 수 있는 실용적인 기능이다.

권한 및 연결 문제 해결

실제 운영 환경에서는 몇 가지 흔한 문제에 부딪힐 수 있다. 가장 빈번한 이슈는 로컬 파일 시스템 접근 권한이다. 에이전트가 스크립트를 실행하거나 파일을 생성하려 할 때 권한 거부(Permission Denied) 에러가 발생한다면, 게이트웨이를 실행하는 시스템 사용자의 권한 범위를 점검해야 한다.

또한, 커스텀 프로바이더 연결 시 타임아웃이 발생한다면 LLM 엔드포인트의 Base URL 설정 끝에 후행 슬래시(/)가 올바르게 포함되었는지, 혹은 방화벽이 특정 포트 통신을 차단하고 있지 않은지 확인하는 과정이 필요하다.

정리하며

오픈클로가 이토록 빠르게 커뮤니티의 관심을 모은 이유는, 에이전트의 사용처를 일상적인 메신저라는 가장 친숙한 공간으로 끌어내렸기 때문이다. 복잡한 전용 UI 대신 메신저 대화창을 실행 런타임으로 삼고, 에이전트 간의 자율적인 소통을 실험하는 모습은 다가올 AI 인프라의 새로운 인터페이스 모델을 제시한다.

하지만 도구가 강력해질수록 권한 관리와 보안 격리는 더욱 중요해진다. 오픈클로를 도입할 때는 단순히 기술적 호기심을 넘어, 스스로 동작하는 에이전트를 어떤 안전한 경계(Boundary) 안에서 통제할 것인지에 대한 고민이 반드시 선행되어야 한다.

업데이트 (2026. 02. 23)

2026년 2월 23일, 오픈클로의 창립자 피터 스타인버거와 코어 팀이 오픈AI(OpenAI)로 합류했다는 기사가 나왔다.

언젠가는 보안 문제가 해결된, 모두에게 범용적인 오픈클로가 등장하지 않을까…!?