오픈클로(OpenClaw)가 어떻게 작동하는지, 과장 없이 자세히 살펴보겠습니다.00:00

순수하고 우아한 기술이 적용되었고, 그 핵심에는 모든 것을 연결하는 게이트웨이가 있습니다. 게이트웨이는 기본적으로 트래픽 라우터 역할을 하며, 다양한 종류의 입력을 받습니다.00:04

이녀석의 유일한 임무는 이러한 입력을 받아서, 태그를 달고, 에이전트를 위한 큐에 넣어주는 것입니다. 이 아키텍처에서 게이트웨이는 가장 단순한 부분이지만, 항상 켜져 있습니다.00:16

모든 작업은 에이전트 내부에서 이루어집니다. 아마 이미 알고 계시겠지만, 이것은 능동적이고 살아있는 느낌을 줍니다. 모든 것은 입력에 달려있습니다. 다섯 가지 다른 유형의 입력이 있어서 시스템이 살아있게 됩니다.00:28

각각의 입력은 게이트웨이에서 이벤트를 발생시키고, 그 과정에서 에이전트가 응답합니다.00:41

하지만 가장 흥미로운 점은 이 모든 입력이 사람이 시작한 것이 아니라는 겁니다. 슬랙, 와츠앱, 텔레그램 메시지와 같은 메시지도 있고, 또 다른 것들이 있습니다.00:48

시스템 자체에서 발생하는 다른 유형의 메시지들이 있습니다. 예를 들어, 30분마다 시작되는 하트비트(heartbeat)와, 사용자가 정의한 시간에 실행되는 크론 작업(cron jobs)이 있습니다. 이러한 것들이 있습니다.01:00

그리고 예외적인 경우도 있을 수 있습니다. 또, 특정 동작을 시작하는 외부 API 엔드포인트도 있습니다. 그런 다음 내부 훅이 있는데, 이는 내부 상태 변화를 일으켜 트리거됩니다.01:13

게이트웨이에서 발생하는 사건들이 에이전트를 시작하거나 활성화시키는 반응을 불러일으킵니다.01:26

그리고 이 모든 것을 합치면 키보드를 만지지 않아도 24시간 내내 운영되는 에이전트가 되죠. 아마 이 개발자에게 전화한 영상이 바이럴로 퍼진 것을 보셨을 겁니다. 자, 그럼 왜 그런 일이 발생했는지 자세히 살펴보겠습니다.01:32

자, 여기서 무슨 일이 있었는지 설명드리겠습니다. 세 시에 실행되도록 설정된 크론 작업이 있었던 거죠. 이건 기본적으로 시스템 클럭 트리거였어요. 게이트웨이가 그걸 감지하고 긴급 작업 검사 요청을 큐에 보냈습니다.01:47

이제, 이에 대한 응답으로 에이전트가 깨어났어요. 왜냐하면 그것이 해야 할 일이니까요. instruction.md 파일을 읽었고, 서버 충돌이 발생하면 전화하라는 지시사항이 명시되어 있었어요.02:02

이에 대한 응답으로, 이메일 서버 로그를 확인했고, 서버에 문제가 발생했다는 것을 발견했습니다. 그리고 이미 트웰로 API에 접근 권한이 있었습니다.02:16

지시받은 대로, 그냥 전화했습니다. 보시면 아시겠지만, 두려워서 결정한 게 아니에요. 트리거, 지시, 도구 실행과 같이 논리적인 흐름에 따라 코드가 실행된 결과입니다.02:25

하지만 이건 아주 깔끔하게 설계된 시스템이에요. 에이전트는 인간이 시작했든 시스템이 시작했든 트리거에 반응하고 있습니다.02:37

자, 이제부터 정말 흥미로운 부분이 시작됩니다. 여러 입력이 동시에 게이트웨이를 시작하거나 작동시키려고 시도할 수도 있습니다.02:46

그렇다면 질문은 에이전트에 과도하게 요청을 보내거나, 웹훅과 하트비트가 정확히 동시에 발생할 경우에 어떤 일이 발생하느냐가 되겠네요.02:54

게이트웨이는 모든 것을 큐에 넣고, 에이전트는 한 번에 하나의 작업을 선택합니다. 따라서 여러 에이전트를 설정한 경우, 큐에서 작업을 동시에 가져갈 수 있습니다.03:03

단일 에이전트로는 충분하지 않은 상황들이 발생할 수 있습니다. 멀티 에이전트 시스템이 필요하며, OpenClaw는 멀티 에이전트 설정을 기본적으로 지원합니다.03:16

하지만 여기서 더 흥미로운 점이 나타납니다. 그들은 텔레파시 경로를 사용하는 대신, 내부 소통을 위해 게이트웨이를 활용합니다. 에이전트가 트리거를 시작하면, 큐에 추가되는 방식과 동일하게 처리될 것입니다.03:27

다른 어떤 요인으로도 발생할 수 있습니다. 예를 들어, 두 개의 다른 에이전트가 있다고 가정해 보겠습니다.03:41

하나는 연구 에이전트이고, 다른 하나는 작가 에이전트입니다.03:44

이제 연구 에이전트가 작업을 완료하면, 게이트웨이로 메시지를 보내서 작가 에이전트에게 이 내용을 초안 작성하라고 지시합니다. 게이트웨이에서 내부 메시지는 사용자 메시지와 똑같이 보입니다.03:49

작성 에이전트의 큐로 라우팅되고, 응답을 기다릴 거예요. 이렇게 하면 모든 에이전트가 분리된 상태로 복잡한 동작을 변경할 수 있습니다.04:03

자체적인 작업 공간 내에서 이루어지기 때문에, 이 전체 설정은 이벤트 기반 개발의 매우 우아한 예시라고 할 수 있습니다.04:16

기본적으로는, 계속해서 실행되는 루프로, 사건들을 추적하고, 큐에 넣고, 에이전트가 행동을 취하며, 상태를 업데이트하는 방식이죠. 하지만 지금까지의 모든 행동 기록을 보존하면서 진행됩니다.04:23

지금까지 어떤 행동들이 취해졌는지, 정확히 어떻게 기억하는 걸까요? 사실상 놀랍도록 단순한 기술을 사용합니다. 오픈 클라우드는 모든 것에 대해 복잡하고 비싼 벡터 데이터베이스에 의존하지 않고, 단순히 사용합니다.04:35

에이전트가 게이트웨이에서 발생하는 이벤트에 의해 활성화될 때마다, 시스템의 기록이나 기억을 담고 있는 마크다운 파일을 읽습니다. 따라서 매번 해당 마크다운 파일을 참조하게 됩니다.04:46

본질적으로, 말 한마디 하기 전에 자신의 일기를 읽는 셈입니다.04:59

이것이 시스템의 상태를 지속 가능하고, 사람이 읽을 수 있으며, 엄청나게 빠르게 로드할 수 있게 만드는 이유입니다. 이제 마지막 조각은 시스템이 액세스할 수 있는 도구들입니다.05:04

어떤 것들은 내장된 도구들이 있고, 로컬 시스템의 파일을 읽을 수 있으며, bash 명령어를 사용하거나 터미널을 사용할 수도 있습니다.05:15

그리고 API 엔드포인트와 같이 연결할 수 있는 외부 도구들도 있습니다. 스킬을 통해 연결하는 거죠.05:22

새로운 기술이나 새로운 API 사용법에 대해 학습하는 모든 내용은 단순히 Markdown 파일에 기록됩니다.05:26

이론적으로는 매우 간단한 시스템이고, 바로 그 점이 인상적인 이유이기도 합니다.05:34

솔직히 말씀드리면, 에이전트 시스템이나 클라우드 코드, 에이전트 SDK, 심지어는 에이전트 SDK에서 제공하는 것들을 이용해서 이와 비슷한 걸 만들 수 있습니다. 그런데 대부분 영구적이지 않아요.05:42

그러니 입력이나 시스템 이벤트를 이 큐로 전달하는 것뿐만 아니라, 이벤트나 에이전트를 활성화하거나 깨우는 게이트웨이 구현 방안을 마련해야 할 것입니다.05:54

저, 제가 말씀드린 것처럼, 모든 것이 게이트웨이로 향합니다. 두 에이전트 간의 통신이라도 마찬가지입니다. 모든 것이 트리거로 인식되는 것처럼 보입니다.06:09

그리고 모든 내용을 마크다운 파일 형태로 저장하고 있기 때문에, 프롬프트 인젝션과 관련된 몇 가지 문제가 발생할 수 있습니다.06:18

이벤트 트리거는 모든 것을 큐에 넣고, 에이전트나 LLM의 컨텍스트를 통과하여 프롬프트 주입이 발생할 수 있습니다.06:27

오픈클로가 접근하고 사용하는 스킬과 관련된 큰 문제가 있습니다. 다행히도, 그 문제에 대해 적극적으로 해결하고 있습니다.06:37

클로 허브에 일부 악성 코드가 있었던 것으로 보이나, 개발팀에서 현재 해당 문제들을 적극적으로 해결하고 있습니다.06:48

샌드박스 환경에서 먼저 확인해 보는 것이 좋습니다. 왜냐하면 이것을 통해 개인 맞춤형 AI 어시스턴트의 미래가 어떻게 보일지 엿볼 수 있기 때문입니다.06:56

이것이 바로 OpenClaw 내부에서 더 높은 수준에서 일어나는 모든 마법입니다. 사용자와 시스템, 그리고 외부 후크에 의해 생성된 트리거를 사용한 이벤트 기반 개발 방식이죠.07:04

에이전트들이 그것에 반응하고 있습니다. 정말 아름다운 엔지니어링 기술이 적용되어 있어서 매우 특별하다고 할 수 있습니다. 하여튼, 이 영상이 도움이 되셨기를 바라며, 시청해주셔서 감사합니다. 늘 그렇듯, 다음 영상에서 만나요.07:18