오픈클로(OpenClaw) 구조 분석 — 게이트웨이·채널 어댑터·메모리로 만드는 개인 AI 에이전트

핵심 메시지

• 오픈클로의 중심에는 게이트웨이가 있다. 메신저에서 들어온 메시지를 받아 적절한 에이전트에 나눠 주고 시스템 전체의 생명 주기를 관리하는 중앙 제어 지점이다.
• 텔레그램·디스코드 같은 메신저는 채널 어댑터로 추상화돼 있어, 카카오톡처럼 새 메신저를 붙이고 싶으면 어댑터만 새로 만들면 된다.
• 메시지가 들어오면 개인 전용 에이전트를 가장 먼저 찾고, 없으면 팀·계정·채널 순으로 넓혀 가며 담당 에이전트를 배정한다.
• 설정 파일을 감시하다가 바뀌면 재시작 없이 전체에 반영한다. 편리하지만 검증이 형식 위주라 잘못된 설정도 그대로 퍼진다.
• 발표자는 API 종량 과금으로 비용이 급격히 줄어드는 것을 겪고, 구독 계정의 인증 쿼터를 쓰는 방식으로 바꿔 비용을 잡았다.

쉽게 이해하기

이 영상은 한 스터디 모임에서 오픈소스 AI 에이전트를 화면에 띄워 놓고 함께 뜯어본 기록이다. 발표자조차 "나도 지금 같이 보는 중"이라고 말할 만큼 따끈한 프로젝트인데, 실제로 발표 도중에 프로젝트 이름이 또 한 번 바뀌는 장면이 그대로 담겼다. 처음엔 클로드봇, 그다음 몰트봇, 발표 시점엔 오픈클로였다.

구조는 크게 세 덩어리다. 게이트웨이와 라우팅, 설정을 담당하는 코어 시스템, 외부 API 제공자와 메신저를 잇는 통합 시스템, 그리고 명령줄 도구·훅·플러그인으로 기능을 늘리는 확장 시스템이다. 이를 다시 클라이언트, 게이트웨이, 비즈니스 로직, 통합, 인프라 계층으로 나눠 볼 수 있는데, 발표자는 이 정리 문서 자체를 AI에게 만들게 했다고 밝혔다.

가장 눈여겨볼 부분은 에이전트를 고르는 규칙이다. 사용자 한 명에게 전용으로 묶인 에이전트가 있으면 그 에이전트가 무조건 먼저 대답을 가져간다. 없을 때에야 팀, 계정, 채널 단위로 범위를 넓힌다. 콜센터처럼 일반 상담원이 먼저 받고 전문 부서로 넘기는 방식과는 정반대로, 좁은 범위에서 시작해 넓혀 가는 셈이다.

에이전트 내부는 익숙한 형태다. 판단을 맡는 러너, 시스템 프롬프트와 대화 기록을 담는 컨텍스트, 그리고 도구로 구성되고, 생각하고 도구를 부르고 결과를 관찰하는 과정을 여러 번 반복한다. 발표자는 웹 검색과 브라우저, 파일 읽기·쓰기를 붙여 놨다고 했다. 다만 텔레그램에서는 답이 한 글자씩 흘러나오지 않고 완성된 뒤에야 통째로 도착해 답답하다는 점도 함께 지적했다.

발표자가 이 도구를 붙잡고 있는 이유는 따로 있다. 지금은 회사에서, 집에서, 노트북을 들고 나가서 쓰는 대화가 전부 따로 놀며 파편화돼 있는데, 메신저를 창구로 삼아 하나로 모으고 싶다는 것이다. 나아가 업무가 사람에게 바로 떨어지는 대신 자신의 AI 대리인에게 먼저 떨어지고, 처리할 수 있는 건 걸러 낸 뒤 결정이 필요한 것만 올라오는 방식을 그려 보고 있다고 말했다.

주요 인사이트

• 이름이 두 번이나 바뀌고 문서를 갱신하는 사이 또 바뀔 만큼 빠르게 움직이는 프로젝트다. 이런 도구를 실무에 얹을 때는 기능보다 갱신을 따라가는 운영 방식을 먼저 정해 두는 편이 안전하다.
• 발표자는 원본 저장소와 자기 저장소를 따로 두고, 핵심 코드는 원본에서 당겨 온 뒤 자기 코드를 그 위에 얹는 방식으로 관리했다. 명령 한 줄이면 최신 코드로 갱신하고 설명 문서까지 함께 고치도록 스킬을 만들어 뒀다.
• 문서에 코드 조각을 붙여 둔 이유가 인상적이다. 코드를 읽으려는 게 아니라, AI가 설명을 지어내지 못하도록 해당 부분의 실제 코드를 증거로 가져오게 시킨 것이다.
• 메모리를 디스크에 저장하는 구조라 용량만 넉넉하면 대화 기록을 길게 쌓아 둘 수 있다. 단기 기억은 메모리에, 장기 기억은 데이터베이스에 두고 검색해 꺼내 쓰는 형태다.
• 개발용 PC에 그대로 설치하면 에이전트가 파일을 마음대로 바꿔 버릴 위험이 있다. 발표자는 중요한 자료를 여러 곳에 백업해 뒀다며, 걱정된다면 가상 머신에서 돌리라고 권했다.

자주 묻는 질문

관련 AI 소식