오래된 SW 엔지니어의 평생 공부

들어가며

이 글은 Claude Code 자동화 실행 환경 & 설정 가이드의 후속 글이다. 전작이 Claude CLI를 Windows Task Scheduler 또는 로컬·클라우드 실행 환경과 결합해 Obsidian + OneDrive 기반 반복 작업을 자동화하는 방법을 다뤘다면, 이 글은 그 다음 단계에서 자동화 구조가 어떻게 에이전트 런타임 중심으로 확장됐는지를 기록한다.

처음에는 Linux의 crontab에 요일과 시간을 등록하고, 각 시점에 Claude Code를 실행하는 방식으로 AI 도구별 트렌드를 수집했다.

# OpenClaw: 목요일 03:00
0 3 * * 4 cd "/home/blcktgr/OneDrive/문서/Obsidian/Newbie" && /home/blcktgr/.nvm/versions/node/v24.18.0/bin/claude -p --permission-mode bypassPermissions /openclaw-collector >> /home/blcktgr/logs/openclaw_collector.log 2>&1

# Gemini: 금요일 02:30
30 2 * * 5 cd "/home/blcktgr/OneDrive/문서/Obsidian/Newbie" && /home/blcktgr/.nvm/versions/node/v24.18.0/bin/claude -p --permission-mode bypassPermissions /gemini-collector >> /home/blcktgr/logs/gemini_collector.log 2>&1

# Codex: 토요일 02:30
30 2 * * 6 cd "/home/blcktgr/OneDrive/문서/Obsidian/Newbie" && /home/blcktgr/.nvm/versions/node/v24.18.0/bin/claude -p --permission-mode bypassPermissions /codex-collector >> /home/blcktgr/logs/codex_collector.log 2>&1

# Cursor: 화요일 03:00
0 3 * * 2 cd "/home/blcktgr/OneDrive/문서/Obsidian/Newbie/" && /home/blcktgr/.nvm/versions/node/v24.18.0/bin/claude -p --permission-mode bypassPermissions /cursor-collector >> /home/blcktgr/logs/cursor_collector.log 2>&1

# Claude Code: 수요일 03:00
0 3 * * 3 cd "/home/blcktgr/OneDrive/문서/Obsidian/Newbie" && /home/blcktgr/.nvm/versions/node/v24.18.0/bin/claude -p --permission-mode bypassPermissions /claude-collector >> /home/blcktgr/logs/claude_collector.log 2>&1

현재는 이 역할을 OpenClaw의 내장 cron job으로 옮겼다. 이 변화는 실행 명령을 다른 곳으로 옮긴 정도가 아니다. 운영체제 중심의 명령 실행 자동화에서, 도구와 상태를 가진 에이전트 작업 자동화로 이동한 것에 가깝다.

전작과 이번 글의 관계

전작의 핵심 질문은 “Claude Code를 반복 실행하려면 어떤 실행 환경과 스케줄러가 필요한가?”였다. 실행 위치, CLI 경로, 시작 폴더, 권한 옵션, 로그 확인, 로컬 PC와 클라우드 VM의 비용·관리 trade-off를 설명했다.

이번 글의 질문은 한 단계 더 올라간다.

“반복 실행되는 Claude 작업을 수집·판단·보고까지 포함하는 운영 가능한 에이전트 파이프라인으로 만들려면 무엇이 달라지는가?”

따라서 두 글은 경쟁하는 대안이라기보다 발전 단계의 기록이다.

• 전작: Claude CLI를 안정적으로 실행하는 환경과 스케줄링
• 이번 글: 에이전트 작업의 상태·도구·보고·운영을 관리하는 런타임

전작에서 다룬 로컬 PC, OneDrive, Obsidian, CLI, 스케줄러라는 기반은 여전히 중요하다. 다만 현재 구조에서는 스케줄러가 단순히 명령을 실행하는 데 그치지 않고, 에이전트가 외부 소스를 읽고 결과를 판단하며 협업 채널에 전달하는 작업까지 호출한다. 전작 참고

기존 구조: Linux cron이 Claude Code를 실행한다

기존 파이프라인은 비교적 단순하다.

1. Linux cron이 정해진 요일과 시각에 실행된다.
2. 작업 디렉터리로 이동한다.
3. claude -p로 collector 명령을 호출한다.
4. Claude Code가 Obsidian 파일을 수집·작성한다.
5. 표준 출력과 오류를 별도 로그 파일에 추가한다.

이 구조의 장점은 명확하다. Linux에 익숙하다면 설정을 이해하기 쉽고, 실행 명령과 로그 파일이 눈에 보인다. Claude Code가 정상적으로 설치되어 있고 해당 경로와 권한이 유지되는 한, 외부 서비스에 덜 의존하면서 로컬 파일을 직접 처리할 수 있다.

반면 cron은 실행 시점만 알고 작업의 의미는 모른다. 수집 결과가 실제로 유효한지, 중복인지, 사람이 읽을 가치가 있는지, Discord에 보고해야 하는지까지는 collector 프롬프트와 별도 스크립트에 흩어지기 쉽다.

또한 다음과 같은 운영 정보가 기본적으로 분리되어 있다.

• 어떤 작업이 설치되어 있는가
• 마지막 실행이 성공했는가
• 중복 항목을 어떻게 판정했는가
• 실패가 일시적인가, 연속적인가
• 결과를 어디에 보고했는가
• 사람이 후속 판단을 해야 하는가

결국 “프로세스는 실행됐는가”와 “업무가 완료됐는가” 사이에 간극이 생긴다.

현재 구조: OpenClaw cron이 에이전트 작업을 호출한다

OpenClaw에서는 cron job이 에이전트 세션을 일정에 맞춰 호출한다. 작업의 실행 단위는 단순한 셸 명령이 아니라, 특정 목적과 출력 규칙을 가진 작업 지시문이다.

AI Trends RSS 작업을 예로 들면 대략 다음 흐름이다.

1. OpenClaw scheduler가 Asia/Seoul 기준으로 job을 실행한다.
2. 에이전트가 수집 스크립트를 실행한다.
3. RSS와 HTML 소스를 확인하고 신규 항목을 선별한다.
4. memory/ai-trends-rss-state.json을 이용해 이미 처리한 항목을 중복 제거한다.
5. 원본 결과와 후보를 마크다운으로 저장한다.
6. 의미 있는 신규 항목이 있을 때만 한국어 요약을 작성한다.
7. 새 Discord 스레드에 실행 결과를 보고한다.
8. 변화가 없으면 NO_REPLY로 조용히 종료한다.

즉, cron은 스케줄을 담당하고 실제 절차는 스크립트·스킬·운영 문서·에이전트 지시문이 담당한다. PALab 운영 문서에서도 이 원칙을 명시한다.

현재 AI Trends 관련 작업은 일일 RSS 수집뿐 아니라 주간 LLMWiki 컴파일, kanban 점검, cron 상태 점검처럼 서로 다른 목적의 job으로 분리되어 있다. 예전의 “도구별 주간 collector 5개”에서, “수집·정제·보고·운영 점검”이라는 업무 단위 중심 구조로 확장된 셈이다.

무엇이 달라졌나

1. 스케줄의 위치가 바뀌었다

기존에는 Linux 사용자의 crontab이 스케줄의 기준이었다. 현재는 OpenClaw gateway와 scheduler가 기준이다.

따라서 관리 대상도 다음처럼 달라진다.

• 기존: crontab -l, 셸 명령, 로그 파일
• 현재: OpenClaw cron job, job ID, timezone, timeout, delivery 설정, 실행 이력

기존 설정은 OS 계정에 강하게 묶여 있었고, 현재 설정은 에이전트 런타임에 묶여 있다.

2. 작업 단위가 명령에서 역할로 바뀌었다

기존 collector는 주로 “이 명령을 실행하라”는 형태였다. 현재 job은 “AI Trends를 수집하고, 신규성을 평가하고, 근거와 한계를 표시해 보고하라”는 역할 중심이다.

이 차이 때문에 현재 방식은 다음과 같은 판단을 작업 흐름에 포함할 수 있다.

• 신규 항목과 기존 항목 구분
• 출처별 신뢰도와 접근 제한 표시
• 본문 확인 여부와 metadata 기반 판단 구분
• 강한 신호와 단순 참고 신호 구분
• 의미 있는 변화가 없을 때 보고 생략

3. 결과 전달이 로그에서 협업 채널로 확장되었다

기존 결과의 기본 목적지는 로컬 파일과 로그였다. 사람이 나중에 로그를 열어 확인해야 했다.

현재는 파일을 원본·상태 저장소로 유지하면서, 의미 있는 요약을 Discord 스레드에 전달한다. 실행 결과가 작업 공간에 남고, 동시에 사람이 읽는 협업 공간에도 남는다.

특히 날짜별 새 스레드를 만들면 실행 단위와 보고 단위를 연결할 수 있다. 어떤 날짜에 어떤 소스가 성공·실패했는지, 어떤 후보가 선택됐는지, 제한사항이 무엇이었는지를 한 곳에서 추적할 수 있다.

4. 상태 관리가 명시적인 운영 요소가 되었다

기존 방식에서도 파일 덮어쓰기나 archive 규칙을 통해 상태를 관리할 수 있었지만, cron 자체가 이를 이해하지는 못했다.

현재는 memory/ai-trends-rss-state.json 같은 dedupe 상태를 작업의 계약으로 명시한다. 이 상태를 기준으로 신규 항목을 판단하므로, 매일 같은 기사를 다시 보고하는 일을 줄일 수 있다.

다만 상태 파일은 삭제하거나 초기화하면 안 된다. 초기화는 과거 항목을 모두 신규 항목으로 오인하게 만들 수 있기 때문이다.

5. “실행 성공”의 의미가 넓어졌다

Linux cron에서는 프로세스가 실행되고 종료 코드가 0이면 성공처럼 보이기 쉽다.

OpenClaw에서는 다음을 함께 봐야 한다.

• job이 실행됐는가
• 필요한 도구가 실제로 호출됐는가
• 소스 접근이 성공했는가
• 결과 파일이 생성됐는가
• 중복 제거 상태가 보존됐는가
• Discord 보고가 실제 스레드에 전달됐는가
• 사람이 조치해야 할 문제가 있는가

이 기준은 더 정확하지만, 운영 상태를 확인해야 할 항목도 많아진다는 뜻이다.

장점

작업과 판단을 하나의 흐름으로 묶을 수 있다

수집, 선별, 요약, 한계 표시, 보고를 한 작업 계약 안에 둘 수 있다. 별도의 셸 스크립트와 사람이 읽을 보고서를 서로 맞추는 비용이 줄어든다.

결과가 사람의 작업 공간으로 바로 들어온다

Discord 스레드, 마크다운 기록, 상태 파일을 함께 사용하면 실행 결과를 나중에 다시 찾기 쉽다. 단순 로그보다 “무엇이 중요했는가”를 빠르게 확인할 수 있다.

조건부 보고가 가능하다

신규 항목이 없을 때 매번 알림을 보내지 않고 조용히 종료할 수 있다. 반대로 강한 신호나 실패가 있을 때는 요약과 함께 노출할 수 있다.

출처와 불확실성을 함께 표현할 수 있다

본문을 확인하지 못한 항목을 metadata 기준으로 표시하거나 RSS 오류를 보고에 포함할 수 있다. 기존의 단순 수집보다 정보의 신뢰도와 한계를 전달하기 쉽다.

여러 종류의 반복 업무로 확장하기 쉽다

같은 런타임에서 RSS 수집, LLMWiki 컴파일, kanban 점검, cron 상태 점검을 각각 독립된 job으로 운영할 수 있다. 수집기만 늘리는 구조에서 운영 파이프라인 전체를 자동화하는 구조로 확장된다.

운영 규칙을 문서와 버전 관리로 끌어올릴 수 있다

cron은 스케줄만 담당하고 실제 절차는 skill/spec 문서가 담당하도록 하면, 작업 기준을 GitHub 문서로 검토·수정·추적할 수 있다. 긴 프롬프트를 여러 곳에 복사하는 문제도 줄어든다.

단점과 새로운 리스크

로컬 cron보다 의존하는 구성요소가 많다

현재 작업은 OpenClaw gateway, scheduler, 에이전트 런타임, 도구 권한, 외부 소스, Discord 전달 경로에 의존한다. 어느 한 계층이 멈추면 셸 명령 하나를 직접 실행하는 것보다 원인 파악이 복잡해질 수 있다.

실행 결과의 재현성이 낮아질 수 있다

같은 프롬프트라도 모델의 판단, 외부 페이지의 변화, 도구 응답에 따라 요약 결과가 달라질 수 있다. 따라서 raw archive, 상태 파일, 실행 날짜, source 제한을 함께 보존해야 한다.

관찰 가능성이 더 중요해진다

프로세스 로그만으로는 충분하지 않다. job ID, 최근 실행, 연속 실패, timeout, delivery 상태를 함께 확인해야 한다. 실제 운영에서도 web_search provider 미설정 경고나 delivery bookkeeping 불일치처럼, 실행과 전달 사이의 차이가 발견될 수 있다.

비용과 실행 시간이 늘어날 수 있다

단순 collector 명령보다 에이전트가 소스를 읽고 판단하고 보고하는 과정이 길다. 외부 검색과 모델 호출이 추가되므로 timeout, 모델 선택, 호출량을 관리해야 한다.

자동 판단의 오류가 보고서에 섞일 수 있다

RSS metadata만으로 본문 내용을 단정하거나, 마케팅 문구를 기술적 사실처럼 요약할 가능성이 있다. 그래서 현재 운영 규칙은 검증된 사실, 미확인 주장, 과도한 해석을 분리하도록 요구한다.

Discord 보고가 완료의 전부는 아니다

보고 메시지가 올라갔다고 작업이 완전히 끝난 것은 아니다. 원본 파일·상태·GitHub 문서 등 durable artifact가 먼저 남아야 하고, 필요한 경우 관련 프로젝트 카드도 갱신해야 한다.

비교 요약

결론: 자동화의 수준이 아니라 운영 모델의 변화다

Linux cron에서 OpenClaw cron으로의 전환은 “어디서 cron을 실행할 것인가”의 문제가 아니다. 더 정확히는 다음 세 가지가 바뀐 것이다.

1. 명령 실행 자동화 → 업무 단위 자동화
2. 로컬 로그 중심 → 상태·문서·협업 채널 중심
3. 성공/실패 판정 → 근거·불확실성·후속 조치까지 포함한 운영

이 방식은 AI Trends처럼 외부 정보 수집과 해석이 함께 필요한 작업에 특히 잘 맞는다. 다만 에이전트가 판단한다고 해서 운영 책임이 사라지는 것은 아니다. 소스의 최신성, 본문 확인 여부, dedupe 상태, 도구 권한, Discord 전달 여부를 계속 검증해야 한다.

따라서 가장 현실적인 운영 원칙은 다음과 같다.

• cron은 스케줄만 담당한다.
• 절차와 판단 기준은 문서·스킬·스크립트로 버전 관리한다.
• raw 결과와 상태를 먼저 보존한다.
• Discord는 요약과 협업을 위한 전달 계층으로 사용한다.
• 실행 성공과 업무 완료를 구분한다.
• 자동화가 만든 판단에는 출처와 불확실성을 함께 기록한다.

이 원칙을 지키면 OpenClaw cron은 Linux cron을 대체하는 도구가 아니라, 반복적인 리서치 업무를 운영 가능한 에이전트 파이프라인으로 끌어올리는 기반이 된다.

학부 2학년이었던 것 같다. 전자회로, Field Theory 였던가? 어떤 과목인지가 중요한 건 아니다. 내 동기들, 특히 같이 뭉쳐다니던 친한 친구들이 아니었다면, 지금도 그 엄창난 양의 숙제, 과제, 시험을 지나왔을 까 하는 생각이 든다. 보통 개강을 하면 4개월. 중간고사, 기말 고사 뿐 아니라 매달 시험이었다. 가뜩이나 고등학교 때 사지선다에 익숙해 있다가 커다란 갱지에 답을 채워 제출하는 주관식 문제들은 지금 생각해도 아득하다. 뿐만인가? 매시간 퀴즈에 숙제는 왜 이리 많은지. 다시 한번 친구들에게 감사한 마음이다. 가끔은 나도 내 숙제 혹은 추가 비용을 지불하고 구한 가뭄에 단비 같았던 'Solution' 책자를 같이 공유하곤 했다. 그럼에도 서슬퍼런 조교들의 'Copy' 평가는 무서웠다. 점수만 0점 처리가 아니고, 불려가 눈도장을 찍어야 했던 상황도 불편했다. 내가 조교를 할 때에도 이 부분은 눈에 불을 켜고 찾았던 기억도 있다.

컴퓨터가 거의 없던 시절의 쓰기 어려웠던 레포트가 워드프로세서가 도입되면서 이를 공유하는 것이 조금은 달라졌던 것 같다. 여전히 'Copy'를 면하기 위한 여러 노력도 기억이 난다. 이는 'Copy'를 넘는 조금은 더 나아간 부분이었다. 이 부분이 Academic Writing과 연결되는 것 같다. 아일랜드에서 박사 과정을 하면서 과정 중 영어 교육이 있어 반가워 감사하게 신청했었다. 기대와 다르면서, 신기하기도 했던 주제가 Pragarism(표절)이었다. 이는 과정 중에서 가장 먼저 이야기 하기도 하고 강조하기도 했던 부분이기 때문이다. 마치 'Copy'를 하면 안된다는 정신교육 같은 느낌이었다. 내 Supervisor의 연구지도는 다독이었다고 회상이 된다. 초기에 여러 논문을 추천하기도 하였고, 읽은 후에 '나의 문장'으로 요약하는 훈련을 지속해서 시켰었는데 이 부분도 Research 혹은 글쓰기와 연결되는 부분이었다.

AI 시대의 글씨기는 어떻게 변하고 있을까? Acamedic Writing을 떠나, SNS에에 올리는 글도 AI를 이용해서 생성한 내용들이 넘처 난다. 여러 질문들이 떠오른다. 한두줄의 Prompt로 나온 내용이 내가 쓴 글인가 아닌가? 처음부터 내가 한줄 한줄 모두 써내려 가면, 이 글은 표절이 아닌 온전한 내 글인가 아닌가? 친구의 숙제를 빌려서 내가 바꿔 낸 것은 내가 한 숙제인가 아닌가? 다른 저자의 글을 읽고 '나의 문장'으로 바꿔 쓴 것은 내글이 인가 아닌가? 이런 것들이 '테세우스의 배'의 역설처럼 들린다. 앞의 질문의 정오를 판단하기 앞서 어느 것이든 '나의 글'이라고 하는 것에는 무엇이 있어야 할까? AI로 쓰건 아니건 최소한은 '내'가 있지 않으면 안될 것 같다.

Y combinator가 발표한 QM은 단순한 코딩 에이전트가 아니라, 조직이 함께 쓰는 멀티플레이어 agent runtime을 제품으로 밀고 있다는 점에서 흥미롭다. 개인용 assistant를 팀 단위 협업 환경으로 확장할 때 가장 먼저 부딪히는 문제가 권한, 상태, 협업 표면, sandbox, 감사인데, QM은 이 다섯 가지를 한 코어 안에 묶어 풀려는 구조를 갖고 있다.

유사한 비교축은 OpenClaw와 Claude Cowork 같은 managed agent service다. 셋은 모두 "에이전트를 실제 업무 환경에 어떻게 올려놓을 것인가"를 다루지만, 문제를 푸는 계층과 경계가 다르다.

QM 소개

QM은 multiplayer agent harness for work를 표방하는 조직용 에이전트 코어다.

• 사람, 채널, 프로젝트마다 별도 scope를 두고 메모리, 파일, keychain view, permissions, cron, web app, durable sandbox를 나눈다.
• Slack과 웹 UI를 함께 제공하고, 같은 identity와 설정이 두 표면을 가로지른다.
• Codex, OpenCode, Claude Code 같은 실행기를 같은 코어 뒤에 연결할 수 있다.
• Postgres에 session, memory, queue 같은 지속 상태를 두고, 코어는 API, policy, scheduler, agent loop를 담당한다.
• 위험한 실행은 작은 고정 tool surface 뒤에 숨기고, 실제 명령은 scope별 sandbox 안의 execute 같은 경로로 몰아넣는다.

핵심적으로 QM은 "좋은 모델 하나"보다 "조직이 여러 사람과 여러 방에서 같이 쓰는 agent operating layer"를 만들려는 시도다.

비교 표

QM과 OpenClaw 비교

QM과 OpenClaw는 둘 다 agent runtime에 가깝지만 철학이 다르다.

• QM은 중앙집중형 shared runtime이다. 하나의 강한 코어가 조직 전체의 scope, memory, queue, policy, sandbox를 품는다.
• OpenClaw는 유연한 operator runtime이다. 에이전트 인스턴스와 workspace가 더 독립적이고, 협업은 채널 정책과 운영 방식으로 푸는 비중이 크다.
• QM은 멀티유저/멀티테넌시를 제품 내부 개념으로 다룬다.
• OpenClaw는 사람 또는 에이전트 단위 인스턴스를 먼저 세우고, 필요하면 여러 인스턴스를 엮는다.
• QM은 shared system consistency에 강하고, OpenClaw는 자가운영성과 실험 자유도에 강하다.

즉 QM은 조직용 agent OS에 가깝고, OpenClaw는 operator가 자기 환경에 맞게 휘게 만드는 agent runtime에 가깝다.

Managed agent service와의 비교

Claude Cowork 같은 managed agent service와 비교하면 차이는 더 뚜렷하다.

• managed service는 시작이 빠르다. 계정과 권한만 연결하면 곧바로 쓸 수 있다.
• 대신 데이터 위치, 실행 경계, 장기 상태, sandbox 구현, 보안 통제 상당 부분이 벤더 제품 설계 안에 묶인다.
• QM은 조직이 자기 클라우드와 자기 정책으로 runtime을 소유하려는 쪽이다.
• OpenClaw는 개인 또는 팀이 자기 워크스페이스와 도구 체계를 직접 운영하려는 쪽이다.

한 줄로 줄이면:

• managed service는 편의성
• QM은 조직용 통합 runtime
• OpenClaw는 자가운영형 agent operator layer

Sandbox 분리의 의미

QM에서 가장 중요한 설계 포인트 하나는 "agent가 돌아가는 코어"와 "실제 작업이 일어나는 컴퓨터"를 분리한다는 점이다.

• 코어는 정책, identity, scheduler, audit를 맡는다.
• 실제 파일 수정, 패키지 설치, 테스트 실행, 로그인된 서비스 접근은 scope별 sandbox 안에서 일어난다.
• 사람, 채널, 프로젝트마다 별도 sandbox를 가지면 한 작업의 오염이 다른 작업으로 번지는 범위를 줄일 수 있다.
• 조직 입장에서는 이것이 단순 보안 기능이 아니라, 책임 경계와 감사 경계를 만드는 방식이다.

기업 조직 관점에서 이 분리는 특히 중요하다.

1. 여러 팀이 같은 agent 시스템을 써도 작업 환경을 섞지 않을 수 있다.
2. 모델이 잘못된 판단을 하더라도 피해 범위를 scope 단위로 제한하기 쉽다.
3. 자격증명, 브라우저 세션, 설치된 도구, 임시 파일을 같은 보안 문맥으로 묶어 관리할 수 있다.
4. 사고가 났을 때 "어느 sandbox에서 무엇이 실행됐는가"를 추적하기 쉬워진다.
5. 장기적으로는 agent를 사람 한 명의 assistant가 아니라 조직의 업무 worker로 다루기 쉬워진다.

즉 sandbox 분리는 단순한 격리가 아니라, 조직형 agent를 위한 최소 운영 단위 정의에 가깝다.

구현은 어떻게 하나

QM은 sandbox backend를 aws, local, sprites 같은 substrate로 나누고, 코어는 설정에 따라 적절한 실행 환경을 붙인다.

• AWS 경로에서는 microVM 안에 작은 HTTP daemon을 두고, exec, read, write 같은 API로 명령 실행과 파일 I/O를 받는다.
• 코어는 모델에게 OS 전체를 직접 노출하지 않고, 정책이 붙은 tool surface만 노출한다.
• 모델이 실제로 하는 일은 "원격 작업 컴퓨터를 호출"하는 쪽에 가깝다.
• 이 구조 덕분에 runtime core와 execution substrate를 따로 교체하거나 강화할 수 있다.

물론 이 설계가 자동으로 안전해지는 것은 아니다. 실제 안전성은 microVM 격리, 네트워크 egress, token 수명, identity hygiene, 감사 로그 운영에 크게 의존한다.

조직 관점 판단

QM이 던지는 질문은 분명하다. 앞으로 조직은 agent를 SaaS 기능처럼 "접속해서 쓰는 것"으로 볼 것인가, 아니면 역할·권한·작업 컴퓨터를 가진 내부 runtime으로 볼 것인가.

• 후자에 가까울수록 QM류 구조의 설득력이 커진다.
• 전자에 가까울수록 managed service의 속도가 더 매력적이다.
• OpenClaw는 그 중간에서, 운영자가 자기 방식으로 runtime을 세우고 휘게 만드는 자유를 준다.

따라서 셋은 단순 경쟁 제품이라기보다, 조직이 agent를 어디까지 내부 운영체제로 받아들일지에 따라 선택지가 갈리는 구조다.

요약

• QM은 조직이 함께 쓰는 shared agent runtime이라는 점이 핵심이다.
• OpenClaw는 더 유연하고 자가운영적인 operator runtime에 가깝다.
• managed agent service는 가장 쉽게 시작할 수 있지만 내부 경계 통제는 제한적이다.
• QM의 가장 큰 차별점은 runtime core와 per-scope sandbox를 분리한다는 점이다.
• 기업 조직 관점에서 이 분리는 보안 기능이 아니라, 책임·감사·업무 격리 단위를 만드는 설계다.