단순한 대화형 AI를 넘어, 실제 컴퓨터를 직접 제어하는 AI가 등장했다면 믿으시겠습니까? openclaw가 바로 그 혁신을 이끌고 있습니다. 이 프로젝트는 “말을 잘하는 AI”가 아니라 진짜로 업무를 실행하는 AI 에이전트를 지향하며, 사용자의 PC에서 브라우저를 조작하고 파일을 다루는 등 시스템 수준의 작업을 자동화합니다. 슬로건도 과감합니다. “THE AI THAT ACTUALLY DOES THINGS(실제로 행동하는 AI)”.
주말 프로젝트에서 시작된 openclaw의 폭발적 성장
openclaw는 2025년 말, 피터 슈타인베르거가 개인 생산성과 디지털 업무 자동화를 위해 만든 주말 프로젝트에서 출발했습니다. 흥미로운 점은 이름이 고정되지 않고 진화해 왔다는 사실입니다.
- 초기 명칭: Clawdbot
- 상표권 이슈로 변경: MoltBot
- 2026년 1월 말 최종 안착: OpenClaw
이 과정은 단순한 리브랜딩이 아니라, 특정 기업에 종속되지 않는 오픈소스 에이전트로서의 정체성을 명확히 하는 흐름이었습니다. 결과는 인상적입니다. GitHub에서 단기간에 10만 개 이상의 스타를 얻으며, 역사상 가장 빠르게 성장하는 오픈소스 프로젝트 중 하나로 기록되었습니다.
“대화”가 아니라 “실행”을 목표로 한 openclaw의 문제의식
기존 챗봇은 많은 경우 “설명”과 “추천”에 머뭅니다. 하지만 실제 업무는 다릅니다. 업무는 보통 다음을 요구합니다.
- 여러 단계로 쪼개진 절차(로그인 → 검색 → 다운로드 → 정리 → 보고)
- 예외 처리(페이지 구조 변경, 권한 오류, 파일 누락)
- 다양한 도구의 연동(브라우저, 로컬 파일, 셸 명령, 메시징)
openclaw는 이 간극을 정면으로 겨냥합니다. 즉, AI가 사용자의 환경에서 직접 클릭하고 입력하고 저장하는 것을 기본 철학으로 삼습니다. 여기서 ‘손이 달린 AI’라는 표현이 설득력을 얻습니다. AI가 단지 안내하는 존재가 아니라, 사용자를 대신해 행동의 마지막 단계까지 수행하기 때문입니다.
openclaw 프로젝트의 흥미로운 여정과 이름의 변천사
하나의 주말 프로젝트에서 출발해, 상표권 문제와 오픈소스 정신 사이에서 이름을 바꿔가며 성장한 openclaw의 숨은 이야기는 “기술은 어떻게 커뮤니티가 되는가”를 보여주는 사례입니다. 이 프로젝트의 변화는 단순한 리브랜딩이 아니라, 정체성(누구를 위한 도구인가)을 정교하게 다듬어 온 과정에 가깝습니다.
주말 프로젝트에서 시작된 실전형 자동화
openclaw의 시작점은 거창한 회사의 로드맵이 아니라, 개발자의 개인적인 생산성 문제였습니다. 2025년 말, 피터 슈타인베르거가 “내 컴퓨터에서 실제로 일을 처리해주는 에이전트”를 만들기 위해 주말에 손댄 것이 출발이었죠. 여기서 중요한 건 목표가 처음부터 명확했다는 점입니다.
대화만 하는 챗봇이 아니라 파일을 읽고, 브라우저를 조작하고, 반복 업무를 끝까지 실행하는 시스템 수준의 에이전트를 지향했습니다. 이 방향성이 이후 폭발적 성장의 기반이 됩니다.
이름이 바뀐 이유: ‘멋’이 아니라 ‘생존’과 ‘철학’
프로젝트는 초기에는 Clawdbot이라는 이름으로 알려졌습니다. 하지만 곧 상표권 이슈가 불거졌고, 이는 오픈소스 프로젝트가 현실 세계의 제약과 마주하는 전형적인 장면입니다.
이후 이름은 MoltBot으로 변경되었지만, 최종적으로 2026년 1월 말 OpenClaw로 정착합니다.
이 마지막 선택이 특히 의미 있는 이유는, 단순히 “새 이름이 필요해서”가 아니라 특정 기업이나 제품 생태계에 종속되지 않는 오픈소스 에이전트라는 정체성을 이름 자체에 새겼기 때문입니다. ‘Open’이라는 단어는 기술적 개방성(연동/확장)뿐 아니라 운영 철학(커뮤니티 중심)까지 함축합니다.
리브랜딩 이후의 폭발적 성장: 오픈소스 신뢰의 증명
이름이 정리되자 프로젝트는 더 빠르게 확산됐습니다. GitHub에서 단기간에 10만 개 이상의 스타를 얻으며, 역사상 가장 빠르게 성장하는 오픈소스 프로젝트 중 하나로 기록됐죠.
이 수치가 의미하는 바는 단순한 인기 이상의 것입니다.
- “실제로 일을 하는 AI”에 대한 수요가 이미 폭발 직전이었다는 점
- 상표권 같은 외부 변수에도 불구하고, 프로젝트가 투명하게 방향을 정리하고 커뮤니티 신뢰를 확보했다는 점
- openclaw가 단지 데모가 아니라, 다양한 환경에서 “업무 자동화”에 바로 투입할 수 있는 실전형 에이전트로 인식되었다는 점
결국 openclaw의 이름 변천사는 우여곡절이 아니라, 프로젝트가 개인 도구 → 공개 프로젝트 → 커뮤니티 기반 인프라로 진화하는 과정에서 필연적으로 거쳐야 했던 성장통입니다.
penclaw 3계층 아키텍처가 구현하는 완벽한 자율성
WhatsApp에서 “이번 주 경쟁사 가격표 모아서 요약해줘”라고 한 줄 던졌는데, AI가 알아서 웹을 돌아다니고(브라우저), 파일을 정리하고(로컬 폴더), 필요하면 모델까지 바꿔가며(Claude→GPT-4→Llama) 끝까지 결과물을 만들어낸다면 어떨까요? openclaw의 3계층 아키텍처는 바로 이 “메시지 입력 → 실제 실행”의 간극을 구조적으로 지워, 완결된 자율 작업 수행을 가능하게 합니다.
openclaw의 1계층: 인터페이스(Interface) — “어디서 말하든, 즉시 연결되는 입구”
openclaw의 첫 번째 계층은 사용자가 명령을 내리는 채널을 표준화합니다. WhatsApp, Telegram, Discord, Slack 같은 메시징 플랫폼은 물론 WebSocket 기반의 실시간 연결까지 포괄해, 사용자는 가장 익숙한 곳에서 일을 지시할 수 있습니다.
기술적으로 중요한 포인트는 다음입니다.
- 채널 독립성: 메시지 앱이 달라도 “요청 → 작업”으로 이어지는 내부 흐름이 동일하게 유지됩니다.
- 실시간성: WebSocket 같은 양방향 프로토콜을 통해 작업 진행 상황(예: “로그인 화면 진입”, “스크린샷 캡처 완료”)을 즉시 피드백할 수 있어, 자동화가 “블랙박스”가 되지 않습니다.
- 보안의 시작점: 이 계층에서부터 “누가 보냈는지”가 판별되고, 승인되지 않은 발신자는 기본적으로 배제되는 페어링 정책이 적용됩니다. 즉, 자율성은 여기서부터 ‘통제된 자율성’으로 설계됩니다.
openclaw의 2계층: 추론 및 제어(Gateway) — “대화가 아니라 ‘작업’을 운영하는 엔진”
두 번째 계층인 Gateway는 openclaw의 핵심 두뇌이자 관제탑입니다. Node.js 환경에서 TypeScript로 작성되어 로컬 머신에서 실행되며, 단순 응답 생성이 아니라 “일을 끝내는 과정”을 통제합니다.
1) 상태를 기억하는 실행 중심 설계
Gateway는 대화 기록, 세션 정보, 사용자 선호도를 파일 시스템에 저장해 지속성을 확보합니다. 이 구조의 의미는 명확합니다.
- 작업이 길어져도(예: 20단계의 웹 수집+정리) 맥락이 끊기지 않음
- 중간 실패가 있어도 어디까지 했는지를 바탕으로 재시도/복구 가능
- 사용자마다 다른 규칙(저장 위치, 파일 네이밍, 보고서 포맷)을 누적 학습처럼 반영 가능
즉, “대화형 AI”가 아니라 운영형 에이전트로 동작하게 만드는 기반이 이 계층에 있습니다.
2) 모델 불가지론 + 페일오버: “모델은 도구일 뿐, 업무는 멈추지 않는다”
openclaw가 돋보이는 지점은 모델 불가지론(model-agnostic) 설계입니다. Claude, GPT-4, Gemini 같은 상용 모델뿐 아니라 Llama 같은 오픈소스 모델도 연결할 수 있고, 더 중요한 건 모델 오류 시 자동 전환(페일오버)입니다.
- 특정 모델이 장애/쿼터 제한/응답 품질 저하를 겪으면
- Gateway가 다른 모델로 전환해 작업을 계속 진행
- 사용자 입장에서는 “작업이 끝나는 것”이 우선이며, 어떤 모델이 답했는지는 부차적이 됩니다.
이 설계는 에이전트의 본질을 정확히 짚습니다. 대화 품질이 아니라, 작업 완료율이 핵심 KPI인 구조입니다.
3) 계획 수립과 도구 호출의 분리
Gateway는 요청을 받으면 곧바로 실행하지 않고, 보통 다음과 같은 운영 루프를 만듭니다.
- 목표 해석(요청을 작업 단위로 쪼개기)
- 단계별 계획 수립(필요 도구/권한/리스크 판단)
- 스킬 호출(브라우저, 셸, 파일 등)
- 결과 검증 및 다음 단계 결정(재시도, 대안 경로, 요약 생성)
이 “계획 → 실행 → 검증”의 반복이 openclaw를 단순 자동화 스크립트가 아니라 자율적 워크플로우 엔진으로 만듭니다.
openclaw의 3계층: 실행 및 도구(Skills) — “마우스와 키보드를 가진 AI”
세 번째 계층인 Skills는 openclaw가 ‘말’이 아니라 행동을 하게 만드는 실제 실행부입니다. 여기에는 대표적으로 다음 능력이 포함됩니다.
- 브라우저 제어: 헤드리스 브라우저로 페이지 이동, 검색, 폼 입력, 버튼 클릭, 데이터 수집
- 파일 시스템 접근: 파일 읽기/쓰기/정리, 폴더 구조 생성, 결과물 저장
- 셸 실행: 스크립트 실행, 변환 작업(PDF 생성 등), 개발/운영 자동화
- 증거 생성: 스크린샷 캡처, PDF 출력 등 작업 결과의 “감사 가능한 산출물” 확보
기술적으로 중요한 점은, Skills가 단순히 “API 호출” 수준이 아니라 사용자 컴퓨터 상에서 작업을 재현한다는 것입니다. 웹사이트가 API를 제공하지 않아도 브라우저로 들어가 사람처럼 처리할 수 있고, 로컬 파일 정리까지 한 번에 이어집니다. 이 때문에 openclaw는 비정형 업무(웹 기반 반복 작업, 수기성 운영 업무)에서도 강합니다.
openclaw 3계층이 만드는 핵심 효과: “플랫폼-모델-실행의 삼각형을 닫는다”
많은 자동화 도구는 “입력 채널” 또는 “실행 도구” 중 하나에만 강하고, AI 모델은 그 사이를 메우는 형태로 붙습니다. 반면 openclaw는 처음부터 다음을 하나의 파이프라인으로 설계합니다.
- 어디서 지시하든(Interface)
- 무슨 모델을 쓰든(Gateway의 모델 불가지론)
- 로컬에서 실제로 실행되도록(Skills)
결과적으로 사용자는 “메시지 하나”로 시작해도, 시스템은 작업을 쪼개고 실행하고 검증하고 산출물까지 남기는 완결된 자율 업무 루프를 돌릴 수 있습니다. 이것이 openclaw 3계층 아키텍처가 말하는 ‘완벽한 자율성’의 기술적 정체입니다.
openclaw의 실제 능력: 내 손처럼 내 컴퓨터를 움직이는 AI
브라우저 제어부터 파일 시스템 접근, 이메일 확인까지. openclaw는 “대답하는 AI”가 아니라 “실제로 실행하는 AI”에 가깝습니다. 핵심은 단순합니다. 사용자가 자연어로 지시하면, openclaw가 (1) 해야 할 일을 계획하고 (2) 필요한 도구를 고르고 (3) 컴퓨터에서 실제 액션을 수행한 뒤 (4) 결과를 증거(로그/스크린샷/파일)로 남기는 흐름으로 움직인다는 점입니다. 이 구조는 Claude의 Cowork(폴더 파일을 읽고 수정하는 컴퓨터 제어권 제공)가 보여준 “AI에게 제어권을 주면 업무가 실제로 굴러간다”는 가치와 정확히 맞닿아 있습니다.
openclaw는 명령을 어떻게 “계획”으로 바꾸나: 에이전트 실행 루프
openclaw는 요청을 받으면 즉시 실행부터 하지 않고, 보통 아래 순서로 작업을 쪼갭니다.
- 의도 파악(Goal 정리): 사용자가 원하는 최종 산출물이 무엇인지 확정
- 작업 분해(Task decomposition): “웹에서 정보 수집 → 문서 정리 → 파일 저장 → 공유”처럼 단계화
- 도구 선택(Skills 호출): 브라우저/셸/파일 시스템/이메일 등 필요한 실행 수단을 선택
- 실행(Act) + 검증(Check): 중간 결과를 확인하고 다음 단계로 진행(실패 시 재시도 또는 경로 변경)
- 산출물 생성(Output): PDF, 텍스트 파일, 스크린샷, 요약 보고서 등 형태로 결과를 남김
여기서 중요한 건 openclaw가 “답변”을 만드는 게 아니라, 계획-실행-검증 루프를 계속 돌려 실제 상태를 바꾼다는 점입니다. 즉, 사용자의 컴퓨터가 곧 작업 현장이 됩니다.
openclaw 브라우저 제어: 클릭·검색·폼 작성까지 “사람처럼” 진행
openclaw의 브라우저 제어는 단순 크롤링을 넘어 실제 사용자 행동(탭 열기, 검색, 페이지 이동, 폼 입력, 다운로드)에 가깝게 동작합니다. 헤드리스 브라우저를 띄우고 단계별로 진행하며, 필요하면 스크린샷으로 현재 화면 상태를 남겨 “지금 무엇을 했는지”를 증명할 수도 있습니다.
실전 예시
- “경쟁사 5곳의 가격 페이지를 찾아 표로 정리해줘”
- 검색 → 각 사이트 이동 → 가격 정보 추출 → 표 작성 → 로컬 파일로 저장
- “이 사이트에서 지난달 결제 내역 PDF로 내려받아 폴더에 저장해줘”
- 로그인(권한이 주어진 경우) → 결제 내역 페이지 이동 → PDF 다운로드 → 지정 폴더 정리
이 과정에서 openclaw는 페이지 구조가 바뀌거나 버튼 위치가 달라져도, 실행 중 관찰한 화면/DOM 정보를 바탕으로 경로를 수정하며 목표를 계속 추적합니다.
openclaw 파일 시스템 접근: 읽기·수정·정리까지 자동화의 중심
브라우저에서 정보를 가져오는 것만으로 끝나지 않습니다. 업무 자동화는 대개 “파일로 정리하고, 축적하고, 재사용”하는 순간부터 가치가 커집니다. openclaw는 로컬 파일 시스템에 접근해 다음을 수행할 수 있습니다.
- 폴더 내 파일 탐색, 내용 읽기
- 문서 수정 및 신규 파일 생성(예: 보고서 초안 작성)
- 파일 이동/정리(예: 다운로드 폴더 자동 분류)
- 필요 시 셸 스크립트 실행로 변환/압축/배포 같은 후처리까지 연결
실전 예시
- “이번 주 회의록 폴더에서 지난주 액션 아이템만 모아 ‘TODO.md’로 만들어줘”
- 파일 검색 → 텍스트 추출 → 항목만 필터링 → 마크다운 생성 → 저장
- “고객사별로 흩어진 계약서 파일명을 규칙에 맞게 일괄 변경해줘”
- 파일 목록 스캔 → 규칙 적용 → 리네이밍 실행 → 변경 로그 저장
이 지점이 Cowork와 닮아 있는 이유는 명확합니다. AI에게 ‘문서가 있는 폴더’를 쥐여주는 순간, AI는 대화를 넘어 실제 업무 산출물을 만들기 시작하기 때문입니다.
openclaw 이메일 확인: “알림”이 아니라 “처리”로 이어지는 자동화
이메일은 업무의 병목이 되기 쉽습니다. openclaw는 이메일 확인을 단순 요약으로 끝내지 않고, 조건에 따라 후속 조치까지 이어지게 만들 수 있습니다.
- 특정 발신자/키워드 메일만 필터링
- 첨부파일 다운로드 후 폴더에 저장 및 파일명 정규화
- 요청 사항을 추출해 체크리스트 생성
- 필요한 경우 브라우저 작업(폼 제출, 시스템 등록)으로 연결
실전 예시
- “세금계산서 메일만 찾아 첨부파일을 ‘/2026/세금/’에 저장하고 월별로 정리해줘”
- 메일 검색 → 첨부 다운로드 → 폴더 생성/정리 → 누락 여부 리포트 작성
openclaw가 Cowork와 만나는 지점: ‘대화형 도우미’에서 ‘업무 실행자’로
Cowork가 보여준 핵심은 “AI가 폴더를 읽고 수정할 수 있으면, 요약이나 조언이 아니라 실제 결과물을 만든다”는 것입니다. openclaw도 같은 흐름 위에 있습니다.
다만 openclaw는 한 단계 더 나아가 브라우저·셸·파일 시스템·메시징 인터페이스를 묶어 하나의 실행 체계(에이전트)로 동작합니다. 그래서 사용자는 “이걸 해줘”라고 말하면 되고, openclaw는 필요한 도구를 선택해 일을 끝내는 방향으로 움직입니다.
openclaw를 쓸 때 현실적으로 체감되는 장점
- 반복 업무의 종결: “다운로드→정리→요약→공유” 같은 루틴을 통째로 자동화
- 다단계 작업 연결: 브라우저에서 찾은 정보를 파일로 정리하고, 그 결과를 다시 후속 액션으로 연결
- 증거 기반 진행: 스크린샷/파일/로그로 “무엇을 했는지”가 남아 검증이 쉬움
결국 openclaw의 진짜 매력은 기능 목록이 아니라, 사용자의 컴퓨터에서 ‘행동’을 만들어낸다는 데 있습니다. 이 지점에서 우리는 “손이 달린 AI”가 왜 업무 자동화의 다음 단계로 불리는지, 실감하게 됩니다.
보안과 미래: openclaw가 여는 ‘컴퓨터를 맡기는 시대’의 선택과 도전
강력한 페어링 정책, 샌드박스, 감사 도구, 그리고 모델 페일오버까지 갖췄는데도 한 가지 질문은 남습니다. AI에게 내 컴퓨터 제어권을 주는 순간, 우리는 무엇을 얻고 무엇을 잃을까? openclaw는 “실제로 행동하는 AI”를 표방하는 만큼, 보안과 책임의 기준도 챗봇 시대와는 다른 레벨로 끌어올립니다.
openclaw 보안 철학: “더 똑똑하게”보다 “더 안전하게”
openclaw의 핵심은 모델 성능이 아니라 접근 제어입니다. 즉, 에이전트가 무엇을 “할 수 있는지”를 먼저 가두고, 그 안에서만 자동화를 허용합니다.
- 페어링(신뢰 기반 연결): 모르는 발신자는 무시하고, 사용자의 명시적 승인으로만 상호작용을 시작합니다. 이는 메시징 플랫폼 연동에서 특히 중요합니다.
- 샌드박스(격리 실행): 고위험 작업은 격리된 환경에서 실행해, 실수나 악성 명령이 시스템 전체로 번지는 것을 줄입니다.
- 실시간 감시/감사 도구: 취약점을 지속적으로 점검하고, 에이전트의 행동을 추적 가능한 형태로 남기는 접근이 포함됩니다.
하지만 여기서 중요한 전제가 있습니다. “통제된 자동화”는 “무위험”과 다릅니다. AI가 파일 시스템과 브라우저를 만질 수 있다는 것은, 권한이 넓을수록 사고 반경도 커진다는 뜻입니다.
openclaw에 컴퓨터를 맡길 때 현실적으로 커지는 위험
에이전트가 실제로 일을 처리한다는 것은, 동시에 실제로 “사고”도 낼 수 있다는 의미입니다. 특히 다음 영역이 리스크의 중심입니다.
데이터 노출 위험
파일 읽기/쓰기/삭제가 가능해지면, 민감한 문서가 의도치 않게 외부 전송되거나(혹은 로그/캐시로 남거나) 접근 경로가 확대될 수 있습니다.
→ 따라서 민감 정보가 있는 폴더는 처음부터 연결하지 않는 설계가 사실상 필수 운영 수칙입니다.권한 남용 및 계정 탈취의 파급력
브라우저 자동화가 강력하다는 것은, 세션 쿠키·자동 로그인·비밀번호 관리자 등과 결합될 때 파급력이 커진다는 뜻입니다. 에이전트가 ‘로그인 가능한 존재’가 되면, 그 순간부터 공격자는 “AI”가 아니라 “내 PC에 접근 가능한 사용자”를 노립니다.비결정성(Non-determinism)과 업무 리스크
LLM 기반 에이전트는 같은 지시에도 다른 행동을 선택할 수 있습니다. 폼 입력, 이메일 발송, 파일 삭제 같은 작업에서 이 비결정성은 치명적일 수 있습니다.
→ 자동화의 ROI가 큰 만큼, 검증 단계(승인/드라이런/리플레이)를 어디에 둘지가 안전성의 핵심이 됩니다.
페일오버는 만능이 아니다: openclaw의 ‘연속성’과 ‘일관성’ 트레이드오프
openclaw의 매력 중 하나는 모델 불가지론과 페일오버입니다. 특정 모델이 실패하면 다른 모델로 전환해 작업을 이어갈 수 있죠. 이는 운영 측면에서 가용성(Availability)을 높입니다.
하지만 보안·품질 관점에서는 새로운 질문이 생깁니다.
- 모델이 바뀌면 추론 스타일도 바뀐다: 계획 수립 방식, 도구 호출 패턴, 오류 처리 방식이 달라져 결과가 흔들릴 수 있습니다.
- 정책 준수의 일관성: 어떤 모델은 보수적으로 행동하고, 어떤 모델은 공격적으로 실행할 수 있습니다. 페일오버가 “성공률”은 높여도 “행동의 일관성”을 낮출 수 있습니다.
- 감사(Audit) 난이도 증가: 사고가 났을 때 “어떤 모델이 어떤 이유로 전환되었고, 그 뒤 어떤 결정이 이어졌는지”를 재구성해야 합니다.
즉, 페일오버는 업타임을 위한 장치이지, 자동으로 보안을 올려주는 장치는 아닙니다. 운영자는 “전환 기준”과 “전환 후 승인 규칙”을 별도로 설계해야 합니다.
openclaw가 여는 미래: 자동화는 ‘툴’에서 ‘대리 실행자’로
그럼에도 불구하고, openclaw 같은 에이전트가 여는 미래는 분명합니다. 자동화의 단위가 스크립트/매크로를 넘어, 비정형 업무 전체를 묶는 워크플로우 실행으로 이동합니다.
- 사람이 하던 ‘클릭 기반 업무’가 표준화된다: 브라우저 조작, 자료 수집, 문서 생성, 후속 보고까지 한 흐름으로 연결됩니다.
- 기업 자동화의 중심이 API에서 UI로 확장된다: API가 없는 레거시 시스템도 에이전트가 다룰 수 있어, 자동화 범위가 넓어집니다.
- ‘업무 설계’가 경쟁력이 된다: 모델 선택보다 중요한 것은 권한 설계, 검증 단계, 실패 시 롤백, 로그/감사 체계입니다.
결국 “AI에게 컴퓨터를 맡기는 시대”의 승자는, 가장 큰 모델을 쓰는 팀이 아니라 가장 안전하게 맡기는 방법을 표준화한 팀이 될 가능성이 큽니다. openclaw는 그 변화를 현실로 끌어당기는 촉매입니다.
