그록 봇 활용 3회: 스킬과 루틴 — 한 번 시연하면 반복하는 자동화 만들기
이 시리즈에서 가장 실용적인 편입니다. 그록 봇에게 일을 시키는 방법은 두 가지인데, 지시문을 길게 쓰는 것과 한 번 해 보이는 것입니다. 후자가 훨씬 빠르고 정확합니다. 이번 3편은 스킬과 루틴이 무엇이 다른지, 그리고 시연 녹화로 자동화를 만드는 절차를 정리합니다.
지시문을 쓰지 않고 가르치는 방법
자동화 도구를 써 보신 분이라면 가장 지치는 부분을 아실 겁니다. 내가 아는 절차를 글로 옮기는 일입니다. 클릭 순서, 예외 상황, 판단 기준을 빠짐없이 적어야 하는데, 막상 적어 보면 내가 무의식적으로 하던 판단이 빠집니다.
그록 봇은 이 단계를 건너뛸 수 있게 합니다. 봇의 컴퓨터에서 내가 그 일을 한 번 하면, 그 과정이 재사용 가능한 스킬이 됩니다.
스킬과 루틴은 다른 것이다
공식 문서는 두 개념을 명확히 나눕니다. 이 구분을 놓치면 설정이 꼬입니다.
스킬(Skill)은 어떻게 하는가이고, 루틴(Routine)은 언제 하는가입니다. 스킬만 만들면 아무 일도 일어나지 않고, 루틴만 만들면 무엇을 할지 모릅니다.
스킬은 방법이고 루틴은 시점이다
비유하자면 스킬은 요리법이고 루틴은 식사 시간입니다. 요리법은 누가 언제 쓰든 같은 절차를 담고, 식사 시간은 그 요리법을 언제 꺼낼지 정합니다.
그래서 하나의 스킬을 여러 루틴이 부를 수 있고, 하나의 루틴이 여러 스킬을 이어 쓸 수도 있습니다.
스킬은 봇을 가리지 않는다
중요한 차이가 있습니다. 스킬은 접근 권한이 있는 어떤 봇이든 쓸 수 있습니다. 특정 봇에 묶이지 않습니다.
그래서 "보고서 정리하기" 같은 스킬을 한 번 만들어 두면, 나중에 만든 봇도 그대로 씁니다. 스킬은 계정 차원의 자산으로 쌓입니다.
루틴은 봇 하나에 붙는다
반대로 루틴은 특정 봇에 특정 워크플로를 배정하는 것입니다. "이 봇이, 이 작업을, 이 시점에" 하도록 묶는 설정입니다.
따라서 같은 스킬이라도 봇마다 다른 루틴으로 돌 수 있습니다. 아침에 도는 봇과 저녁에 도는 봇을 나누는 식입니다.
시연으로 스킬 만들기 절차
이제 실제 절차입니다. 전체 흐름은 다섯 단계입니다. 화면 보기 켜기 → 무엇을 할지 말하기 → 한 번 수행하기 → 녹화 멈추기 → 초안 검토하기.
각 단계에 걸린 제약이 있어서 순서를 지키는 편이 좋습니다. 하나씩 보겠습니다.
일대일 대화에서 화면 보기를 켠다
먼저 봇과 일대일 대화를 엽니다. 그룹 채팅이 아니라 단독 대화여야 합니다. 그 안에서 컴퓨터 화면 보기를 켜면 봇의 클라우드 컴퓨터 화면이 보입니다.
여기가 작업 무대입니다. 2편에서 처음 며칠은 화면 보기를 켜 두라고 권했는데, 스킬을 만들 때는 선택이 아니라 필수입니다.
무엇을 할 것인지 먼저 말한다
녹화를 시작하기 전에 봇에게 무엇을 보여줄 것인지 말해 둡니다. "지금부터 주간 보고서를 정리하는 방법을 보여줄게" 같은 한 문장이면 됩니다.
이 한 줄이 있고 없고의 차이가 큽니다. 봇은 화면 조작만 보고 의도를 추론해야 하는데, 목적을 미리 알면 무엇이 본질이고 무엇이 우연인지 구분하기 쉬워집니다.
한 번만 수행한다
그다음 작업을 한 번 수행합니다. 여러 번 반복해 보일 필요가 없습니다.
중간에 헤매거나 잘못 클릭했다면 다시 녹화하는 편이 낫습니다. 시행착오까지 절차의 일부로 학습될 수 있기 때문입니다.
녹화는 10분까지다
제약이 하나 있습니다. 녹화는 최대 10분입니다. 10분을 넘는 작업은 한 번에 담기지 않습니다.
이 제한은 설계 의도로 읽는 편이 맞습니다. 10분 안에 안 끝나는 절차는 애초에 여러 스킬로 쪼개는 것이 옳습니다. 하나의 거대한 스킬보다 작은 스킬 여럿이 고치기도 쉽습니다.
마이크는 녹음되지 않는다
공식 문서가 명시한 또 하나의 사실입니다. 녹화는 보이는 화면 조작만 담고 마이크 오디오는 녹음하지 않습니다.
따라서 말로 설명하면서 시연해도 그 설명은 남지 않습니다. 설명이 필요하면 녹화 전후에 채팅으로 적어야 합니다.
녹화 중 민감 정보를 보이지 말 것
2편에서도 짚었지만 여기서 다시 강조합니다. 공식 문서는 녹화 중 민감 정보를 화면에 노출하지 말라고 경고합니다.
비밀번호 입력 화면, 고객 개인정보가 뜬 목록, 계좌 정보가 보이는 페이지가 그렇습니다. 로그인은 녹화 시작 전에 끝내 두고, 민감한 목록은 필터를 걸어 가린 뒤 시연하는 편이 안전합니다.
멈추면 초안 스킬이 나온다
녹화를 멈추면 봇이 초안 스킬을 만들어 냅니다. 완성본이 아니라 초안이라는 점이 중요합니다.
봇이 화면에서 본 것을 자기 말로 정리한 결과이므로, 내 의도와 어긋난 부분이 반드시 있습니다. 그대로 쓰면 안 됩니다.
초안을 읽고 고치는 단계
공식 절차는 검토하고, 다듬고, 테스트하라입니다. 이 세 단계가 스킬 품질을 결정합니다.
읽을 때 볼 것은 두 가지입니다. 봇이 우연한 동작을 본질로 오해하지 않았는가(그날만 클릭한 항목을 매번 클릭하도록 적지 않았는가), 그리고 내가 무의식적으로 한 판단이 빠지지 않았는가입니다.
스킬에 담기는 네 가지
공식 문서가 정의하는 스킬의 구성 요소는 넷입니다. 단계(steps), 판단 규칙(judgment rules), 산출물(deliverables), 안전 경계(safety boundaries)입니다.
시연으로 자동으로 채워지는 것은 주로 단계입니다. 나머지 셋은 대개 사람이 직접 적어 넣어야 합니다. 여기가 초안을 고치는 작업의 실체입니다.
안전 경계를 스킬 안에 적는다
네 요소 중 실무에서 가장 중요한 것이 안전 경계입니다. "이 조건이면 진행하지 말고 나에게 물어라"를 스킬 안에 명시하는 것입니다.
예를 들어 "금액이 10만 원을 넘으면 중단하고 확인 요청", "목록에 없는 상대가 나오면 진행 금지" 같은 문장입니다. 2편에서 본 승인 경계가 계정 차원의 방어선이라면, 이건 작업 차원의 방어선입니다.
루틴으로 시점을 정한다
스킬이 준비되면 루틴을 붙일 차례입니다. 루틴은 스케줄 또는 이벤트로 실행됩니다.
스킬 없이 루틴만 만들면 매번 무엇을 할지 다시 설명해야 하므로, 스킬을 먼저 다듬고 루틴을 나중에 붙이는 순서를 권합니다.
매일 아침 여덟 시 같은 스케줄
가장 단순한 형태는 시간 기반입니다. "매일 아침 8시", "매주 월요일 오전"처럼 정해진 시각에 돕니다.
1편에서 본 성질이 여기서 살아납니다. 봇의 컴퓨터는 클라우드에 있으므로 내 기기가 꺼져 있어도 그 시각에 실행됩니다. 다만 로그인 세션이 만료돼 있으면 그 자리에서 사람을 기다리며 멈춥니다.
사건이 생겼을 때 도는 루틴
다른 형태는 이벤트 기반입니다. 특정 조건에 맞는 일이 생기면 실행되는 방식입니다. 새 메일이 오면, 특정 항목이 추가되면 같은 조건입니다.
스케줄 루틴보다 반응이 빠르지만, 그만큼 조건을 잘못 잡으면 예상보다 훨씬 자주 돕니다.
매칭 규칙을 좁게 잡아야 하는 이유
이벤트 루틴에서 가장 흔한 사고가 조건을 넓게 잡는 것입니다. "메일이 오면"으로 걸어 두면 하루에 수십 번 돕니다.
공식 문서도 매칭 규칙을 좁게 유지하라고 권합니다. 발신자, 제목 패턴, 라벨 같은 조건을 겹쳐서 정말 그 경우에만 걸리게 만드는 것이 정석입니다. 넓게 시작해서 좁히는 것보다, 좁게 시작해서 넓히는 편이 안전합니다.
활성화 전 테스트 실행
공식 문서가 명시적으로 권고하는 단계입니다. 루틴을 활성화하기 전에 테스트로 한 번 돌려 보라는 것입니다.
테스트 실행에서 볼 것은 결과물이 맞는가보다 봇이 거쳐 간 경로가 맞는가입니다. 결과가 우연히 맞았는데 경로가 틀린 경우가 있고, 그건 다음번에 반드시 어긋납니다.
봇이 스스로 스킬을 고친 사례
1편에서 짧게 언급한 사례를 여기서 자세히 보겠습니다. 어떤 사용자가 '게시물에 좋아요 누르기' 스킬을 만들어 실행했습니다.
실행 후 봇이 스스로 문제를 지적했습니다. 목록 화면만으로는 이미 좋아요를 누른 글인지 구분할 수 없다는 것이었습니다. 그리고 각 글을 먼저 열어 확인하도록 시키지도 않았는데 자기 지시문을 수정했습니다.
이 사례가 보여 주는 것은 두 가지입니다. 스킬은 고정된 스크립트가 아니라 고쳐 나가는 문서라는 점, 그리고 봇이 고친 내용도 사람이 읽어 봐야 한다는 점입니다. 이번엔 옳은 방향이었지만 항상 그러리라는 보장은 없습니다.
실제 사례: 반복 정리 작업을 스킬로
구체적으로 SVIL 연구소 같은 1인 작업 환경에 대입해 보겠습니다. 매주 하는 일 중 여러 화면을 오가며 같은 형식으로 정리하는 작업이 후보입니다.
흩어진 자료를 모아 한 문서로 만드는 일, 조건에 맞는 항목만 골라 목록을 갱신하는 일이 그렇습니다. 시연 10분 안에 들어가고, 판단 규칙이 단순하고, 결과를 눈으로 바로 확인할 수 있습니다.
실제 사례: 처음 만들 때 흔한 실패
처음 스킬을 만들 때 자주 나오는 실패 세 가지를 정리합니다.
첫째, 너무 큰 작업을 한 스킬에 담는 것입니다. 10분 제한에 걸리고, 걸리지 않더라도 어디서 틀렸는지 찾기 어렵습니다. 둘째, 판단 규칙을 안 적는 것입니다. 단계만 있고 "이럴 땐 이렇게"가 없으면 예외 상황에서 봇이 임의로 판단합니다. 셋째, 테스트 없이 활성화하는 것입니다. 이벤트 루틴이라면 잘못된 조건이 즉시 반복 실행으로 이어집니다.
핵심 정리
- 스킬 vs 루틴: 스킬은 어떻게(단계·판단 규칙·산출물·안전 경계), 루틴은 언제(스케줄 또는 이벤트). 스킬은 접근 권한이 있는 어떤 봇이든 쓰고, 루틴은 특정 봇에 배정됩니다.
- 시연 절차: 일대일 대화에서 화면 보기 켜기 → 무엇을 할지 말하기 → 한 번 수행 → 정지 → 초안 검토·수정·테스트.
- 녹화 제약: 최대 10분, 보이는 화면 조작만 기록, 마이크 오디오는 미녹음. 녹화 중 민감 정보 노출 금지.
- 초안은 초안이다: 자동으로 채워지는 것은 주로 단계이고, 판단 규칙·산출물·안전 경계는 대개 사람이 적어야 합니다.
- 루틴 운영: 매칭 규칙은 좁게. 활성화 전 테스트 실행은 공식 권고 사항이며, 결과보다 경로를 봅니다.
- 자기 수정: 봇이 실행 후 스스로 지시문을 고친 사례가 보고됐습니다. 다만 고친 내용도 사람이 읽어야 합니다.
참고하실 만한 것
스킬을 처음 만드실 때는 이번 주에 이미 두 번 이상 한 작업을 고르시길 권합니다. 앞으로 할 것 같은 일이 아니라 이미 반복된 일이어야 절차가 몸에 있고, 시연이 매끄럽습니다.
그리고 초안이 나오면 반드시 안전 경계 한 줄을 손으로 추가해 두세요. 자동으로는 거의 채워지지 않는 항목입니다.
다음 4편에서는 봇 여러 대를 팀으로 굴리는 방법과, 게임 에셋 74개를 두 시간에 만든 사례를 절차 단위로 분해해 보겠습니다.
출처
- xAI Docs — Skills, routines and automations (스킬·루틴 정의, 녹화 제한, 테스트 권고)
- xAI Docs — Grok Bot FAQ
- xAI — Introducing Grok Bot (시연 학습·자기 개선)
- explainX — Grok Bot Beta: 자기 수정 사례와 초기 베타 관찰
- eesel AI — Grok Bot review: what actually ships in the early beta
- MindStudio — How to Set Up Grok Bot and Build Your First AI Agents
- Unite.AI — xAI Launches Grok Bot, Always-On AI Teammates
- AIToolsReview — Grok Bot: xAI's Always-On AI Agents, Explained
협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/