에이전트가 스스로 만든 능력을 그냥 켜도 될까 — OpenClaw가 Skill Workshop으로 푼 방법

오픈소스 개인 AI 어시스턴트 OpenClaw를 들여다보면서 흥미로웠던 화면 중 하나가 Skill Workshop(스킬 워크숍)이다. AI 에이전트한테 "월요일 아침에 메일함 정리하는 루틴을 스킬로 만들어 줘"라고 말하면, 에이전트가 그 자리에서 새 능력을 글로 적어 만들어 낸다. 강력하다. 그런데 에이전트가 적은 그 글이 곧장 살아 있는 능력이 된다면? 검증 안 된 자동 동작이 다음 대화부터 바로 실행된다는 뜻이다. 이 글은 "에이전트가 스스로 능력을 늘리되, 사람이 한 번 보고 켠다"는 문제를 OpenClaw가 초안→검토→승인 파이프라인으로 어떻게 풀었는지를 따라간다.

배경 — 스킬은 "에이전트의 행동 매뉴얼"이다

OpenClaw에서 스킬(skill)이란 에이전트가 특정 상황에서 따라야 할 절차를 적어 둔 문서다. 평범한 마크다운 파일 하나(SKILL.md)에 "이런 요청이 오면 이렇게 처리하라"는 매뉴얼을 적어 두면, 에이전트가 대화 중 그 상황을 만났을 때 자동으로 그 매뉴얼을 꺼내 읽고 행동한다. 사람이 신입에게 주는 업무 매뉴얼과 같은 발상이다 — 다만 그 매뉴얼을 읽고 실제로 손을 움직이는 게 AI라는 점이 다르다.

매뉴얼을 사람이 직접 손으로 써 둘 수도 있지만, OpenClaw는 한 걸음 더 나간다. 에이전트가 채팅 대화에서 스킬을 직접 만들어 내게 한 것이다. "이런 루틴 자주 하니까 스킬로 만들어 둬"라고 말하면 에이전트가 절차를 정리해 새 매뉴얼을 작성한다. 자기 능력을 스스로 늘리는 셈이다.

다이어그램 설명. 이 그림은 에이전트가 자기 능력을 스스로 늘리는 가장 단순한 흐름을 보여준다. 사용자가 말로 요청하면 에이전트가 절차를 정리해 새 매뉴얼을 만들고, 그 매뉴얼이 곧장 다음 대화부터 자동 실행으로 이어진다. 핵심은 맨 아래 화살표다 — 매뉴얼이 만들어지자마자 살아 있는 행동 지침이 된다는 점. 이게 강력한 만큼 위험하기도 하다는 걸 다음 섹션에서 본다. 흔한 오해는 "스킬은 그냥 텍스트 파일이니 무해하다"는 가정인데, 그 텍스트가 곧 AI의 자동 행동을 결정하므로 텍스트 한 줄이 곧 동작 한 가지다. 그래서 이 자기 확장이 사람에게 주는 가치는 "반복 작업을 말 한마디로 자동화"하는 데 있다.

핵심 문제 — 검증 없이 라이브에 올리면 벌어지는 일

방금 본 단순 흐름에는 빠진 단계가 있다. 사람이 그 매뉴얼을 한 번도 보지 않았다는 것이다. 에이전트가 작성한 글이 곧바로 살아 있는 SKILL.md가 되면, 검증되지 않은 자동 행동이 그 즉시 활성화된다. 구체적으로 어떤 사고가 날 수 있는지 보자.

다이어그램 설명. 이 그림은 사람의 검토 없이 에이전트가 매뉴얼을 직접 살아 있는 파일로 쓸 때 갈라지는 세 가지 실패를 보여준다. 맨 위 "검증 없음"에서 세 갈래로 나뉜다. 첫째, 이미 있는 trip-planning 같은 스킬과 같은 이름으로 만들면 멀쩡히 돌던 능력을 통째로 갈아엎는다. 둘째, 작성된 매뉴얼 안에 위험한 명령(파일을 지우거나 외부로 데이터를 보내는 식)이 섞여 있어도 검증 단계가 없으니 그대로 활성화된다. 셋째, 에이전트가 사용자의 의도를 오해한 채 절차를 적어도 그 잘못된 절차가 즉시 자동 실행된다. 가장 고약한 건 두 번째다 — 일반 텍스트 파일처럼 보이지만 그 내용이 곧 AI의 자동 행동이라, "그냥 메모 한 장"이 실제로는 검증 안 된 실행 권한이 된다. 그래서 이 단계에 사람의 눈을 한 번 끼워 넣는 것이 사람·시스템 양쪽의 안전을 지키는 전제가 된다.

여기서 트레이드오프가 분명해진다. 에이전트의 자기 확장을 막아 버리면 안전하지만 편의를 잃고, 그대로 풀어 주면 편하지만 위험하다. OpenClaw가 고른 답은 둘 사이 — 에이전트가 만들되, 살아 있는 능력으로 켜는 순간에만 사람이 개입하는 방식이다.

해결 방법 — 초안(proposal)과 적용(apply)을 분리한다

OpenClaw의 핵심 결정은 단순하다. 에이전트와 운영자는 살아 있는 SKILL.md를 직접 쓰지 못한다. 대신 제안(proposal)을 먼저 만든다. 제안이란 곧바로 실행되지 않는 보류 상태의 초안으로, 제안된 스킬 내용·적용 대상·스캐너 검사 상태·해시·되돌리기 정보를 담은 묶음이다. 파일 이름부터 다르다 — 살아 있는 SKILL.md가 아니라 PROPOSAL.md로 저장된다. 이 초안이 살아 있는 스킬이 되는 건 오직 적용(apply)이라는 단 하나의 동작을 거칠 때뿐이다.

비유하자면 출판 전 원고와 같다. 작가(에이전트)가 원고를 쓰지만, 그게 곧 출간된 책은 아니다. 편집자(사람)가 검토하고 "출간 승인"을 눌러야 비로소 서점에 깔린다. 원고를 고치는 동안에는 독자(다음 대화의 에이전트)에게 아무 영향이 없다.

다이어그램 설명. 이 그림은 제안 하나가 거치는 생애 주기를 보여준다. 만들기·수정하기 요청은 곧장 라이브가 되지 않고 모두 "보류 중" 상태로 들어간다. 보류 중인 제안은 다듬기를 거쳐 다시 보류 상태로 돌아올 수 있고(원고 수정), "적용" 경로를 탈 때만 비로소 살아 있는 매뉴얼이 된다. 거부하거나 보안 검토를 위해 격리하는 갈래도 있는데, 둘 다 살아 있는 파일을 건드리지 않는다. 핵심 설계는 "적용"이 유일하게 라이브로 쓰는 동작이라는 점이다 — 만들기·수정하기·다듬기는 전부 살아 있는 스킬을 바꾸지 않는다. 놓치기 쉬운 함정은 "수정하기(revise)"가 라이브를 바꾼다고 오해하는 것인데, 다듬기는 어디까지나 보류 중인 원고를 손볼 뿐이고, 보류 상태를 벗어나는 길은 적용·거부·격리 셋뿐이다. 다듬을 수 있는 것도 오직 "보류 중" 상태의 제안에 한한다.

적용(apply) 한 번에 묶인 안전장치들

"적용이 유일한 라이브 쓰기"라는 규칙이 힘을 가지려면, 그 적용 한 번에 안전장치가 몰려 있어야 한다. OpenClaw는 적용 동작 전후로 여러 검사를 끼워 넣었다.

다이어그램 설명. 이 그림은 "적용"을 눌렀을 때 통과해야 하는 관문들을 위에서 아래로 보여준다. 적용을 누르면 먼저 스캐너(보안·형식 검사기)를 한 번 더 돌려 내용을 재검사한다 — 통과하지 못하면 그 자리에서 격리된다. 스캔을 통과하면, 새로 만드는 경우엔 같은 이름의 스킬이 이미 있는지 본다 — 있으면 그 자리에서 실패시켜 기존 능력을 갈아엎는 사고(no clobber, 덮어쓰기 금지)를 막는다. 기존 스킬을 고치는 경우엔 제안을 만든 뒤 살아 있는 스킬이 그새 바뀌었는지 본다. 제안은 만들 때 대상의 해시(파일 내용을 짧은 지문으로 압축한 값)에 묶여 있어서, 라이브가 바뀌면 지문이 어긋나 "오래됨(stale)" 상태가 되고 다시 다듬어야 한다 — 내가 검토한 그 원고가 실제로 적용되도록 보장하는 장치다. 이 관문들을 지나면 살아 있는 파일을 건드리기 직전에 되돌리기 정보를 먼저 저장한 뒤에야 비로소 라이브 파일을 쓴다. 핵심 패턴은 "라이브를 바꾸기 직전에 검사·기록을 몰아넣는다"는 것이다. 함정은 "검토할 때 이미 스캔했으니 적용 때 또 안 해도 된다"는 생각인데, 검토와 적용 사이에 내용이 바뀔 수 있으므로 적용 시점에 스캐너를 다시 돌리는 게 핵심이다.

승인 게이트 — 사람이 끼어드는 정확한 지점

그렇다면 "사람의 승인"은 정확히 어디에 들어갈까? OpenClaw는 에이전트가 스스로 적용·거부·격리를 호출할 때 기본적으로 승인 프롬프트(사용자에게 "이대로 진행할까요?"를 묻는 확인 단계)를 띄운다. 이게 human-in-the-loop(사람이 자동 흐름의 한 단계로 끼어드는 설계)의 실제 구현 지점이다.

다이어그램 설명. 이 그림은 에이전트가 스스로 적용·거부·격리를 시도할 때 사람이 끼어드는 분기를 보여준다. 가운데 승인 정책에서 두 갈래로 갈린다. 기본값일 때는 사람에게 확인을 묻고, 사람이 승인해야만 동작이 실행되며 거절하면 멈춘다. 신뢰할 수 있는 환경으로 정책을 바꾸면 이 확인 단계를 건너뛴다. 여기서 중요한 설계는 "auto로 바꿔도 에이전트가 여전히 그 동작을 직접 호출해야 한다"는 점이다 — 자동 모드는 사람의 확인을 생략할 뿐, 에이전트가 마음대로 라이브 파일을 직접 쓰는 우회로를 열어 주는 게 아니다. 놓치기 쉬운 함정은 자동 모드를 "검증 없이 다 통과"로 오해하는 것인데, 앞 섹션의 덮어쓰기 차단·해시 검사·스캐너 재실행 같은 관문은 승인 프롬프트와 무관하게 그대로 작동한다. 사람의 클릭만 생략될 뿐 기술적 관문은 유지된다.

에이전트는 우회할 수 없다 — 단일 통로 강제

이 모든 게이트가 의미를 가지려면, 에이전트가 게이트를 우회해 파일을 직접 만지는 길이 막혀 있어야 한다. OpenClaw는 에이전트가 스킬 작업을 할 때 오직 skill_workshop이라는 전용 도구만 쓰게 강제한다. 일반 파일 쓰기·편집·셸 명령으로 제안 파일을 만들거나 바꾸는 것을 금지한다.

다이어그램 설명. 이 그림은 스킬 작업이 거쳐야 하는 단일 통로를 보여준다. 에이전트는 전용 도구 한 곳으로만 들어갈 수 있고, 점선으로 끊긴 일반 파일 쓰기·편집·셸 명령 경로는 막혀 있다. 그 아래를 보면 채팅·명령줄(CLI)·게이트웨이라는 세 가지 입구가 모두 같은 하나의 Skill Workshop 서비스로 모인다. 이게 중요한 이유는 입구가 여러 개라도 검사 로직이 한 곳에 모여 있어야, 어느 입구로 들어와도 같은 안전장치(덮어쓰기 차단·해시 검사·스캐너)를 똑같이 통과하기 때문이다 — 입구마다 검사 규칙이 제각각이면 한 입구의 허점이 전체 구멍이 된다. 놓치기 쉬운 함정은 격리된 환경(sandboxed run)에서다. 그런 환경에서는 이 전용 도구가 아예 만들어지지 않으므로, 제안을 검토·적용하려면 평범한 호스트 세션이나 명령줄에서 해야 한다.

지원 파일도 검사 대상 — 매뉴얼에 딸린 스크립트까지

스킬은 매뉴얼 한 장으로 끝나지 않을 때가 많다. 매뉴얼이 참조하는 스크립트·예시·템플릿 같은 지원 파일(support files)이 딸려 온다. 에이전트가 작성한 매뉴얼에 실행 스크립트가 함께 묻어 들어오면 이것도 검증 대상이다. OpenClaw는 지원 파일이 들어갈 수 있는 폴더를 다섯 곳(assets/·examples/·references/·scripts/·templates/)으로 제한하고, 위험한 경로 패턴을 거부한다.

다이어그램 설명. 이 그림은 매뉴얼에 딸린 지원 파일이 통과해야 하는 검사를 보여준다. 가운데 "안전한 파일인가?" 판단에서, 시스템 어디든 가리킬 수 있는 절대경로, 점으로 시작하는 숨김 경로, 상위 폴더로 빠져나가는 경로 탈출(..), 허용된 폴더 밖의 위치, 제안 디렉터리에서 실행 권한(+x) 비트가 켜진 채로 들어온 파일, 정상 텍스트가 아닌 비UTF-8·널바이트 파일은 모두 거부된다. 통과한 파일만 스캔·해시 후 제안과 함께 보관되고, 살아 있는 매뉴얼 옆에 실제로 놓이는 건 오직 적용 시점이다. 여기서 한 가지 짚어 둘 점은, 거부 대상이 "스크립트 파일"이 아니라 "실행 권한 비트가 켜진 파일"이라는 것이다. scripts/는 애초에 허용된 폴더 중 하나이고, 스킬에 딸린 스크립트(run.sh·foo.py 등)의 내용 자체는 거부되지 않는다 — 실행 권한만 떼면 그대로 보관·적용된다. 스킬이 그 스크립트를 돌릴 때는 매뉴얼에서 인터프리터를 명시해 호출하므로(bash scripts/run.sh 식) 실행 비트가 필요 없다. 즉 막는 것은 "미리 무장된 채로 들어온 파일"이지 스크립트라는 종류 자체가 아니다. 이 패턴이 중요한 이유는 경로 탈출 같은 고전적 공격(허용된 폴더 안에 있는 척하면서 ..로 시스템 파일을 덮어쓰려는 시도)을 처음부터 차단하기 때문이다. 놓치기 쉬운 점은 "에이전트가 만든 거니까 안전하겠지"라는 가정인데, 에이전트가 오해했거나 외부 입력에 영향받았을 수 있으므로 출처와 무관하게 같은 검사를 적용한다.

결과 — 무엇이 좋아졌나

이 구조가 들어오면서, 에이전트의 자기 확장이라는 강력하지만 위험한 능력이 안전한 파이프라인으로 정리된다. 앞서 본 사고들이 이렇게 막힌다.

검증 없이 직접 라이브	초안 → 검토 → 승인 파이프라인
에이전트가 곧장 살아 있는 SKILL.md를 씀	먼저 PROPOSAL.md(보류 초안)로만 저장, 적용 때만 라이브
같은 이름 스킬을 무심코 덮어씀	덮어쓰기 차단 — 이미 있으면 적용 실패
검토한 내용과 실제 적용이 어긋날 수 있음	해시로 대상에 묶어, 라이브가 바뀌면 stale 처리
위험한 내용·스크립트가 그대로 활성화	적용 시 스캐너 재실행 + 지원 파일 경로 검사
사람이 개입할 지점이 없음	적용·거부·격리에 승인 프롬프트 (기본값)
잘못 적용해도 되돌릴 수 없음	라이브 변경 전 되돌리기 정보 먼저 기록

정리하면, Skill Workshop은 "에이전트가 스스로 능력을 늘리되, 라이브로 켜는 단 한 순간에만 사람이 문지기로 선다"는 설계다. 자기 확장의 강력함은 그대로 누리면서 — 말 한마디로 반복 작업을 자동화 — 그 능력이 검증 없이 시스템에 스며드는 위험만 골라 막는다. AI 에이전트가 점점 더 스스로 도구를 만들어 쓰는 방향으로 가는 지금, 이런 "만들기는 자유, 켜기는 승인"의 분리는 자율성과 안전을 동시에 쥐는 현실적인 타협점이다 — 사람이 모든 절차를 손으로 쓰지 않아도 되고, 동시에 사람이 보지 않은 능력이 멋대로 돌아가지도 않기 때문이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.