헤르메스 에이전트로 전용 마케팅 봇을 만들어 실제 팀 슬랙에 온보딩한 후기입니다. 설치는 반나절이면 끝났고, 어려운 건 그다음이었어요. 역할·판단 원칙·권한 경계·실패 보고 방식을 정하고 나서야 팀원처럼 일하기 시작했습니다.
요약
헤르메스 에이전트(Hermes Agent)란? Nous Research가 만든 오픈소스 AI 에이전트입니다. 작업 경험을 재사용 가능한 스킬로 저장하고, 세션을 넘어 기억을 축적할 수 있습니다. macOS·윈도우·리눅스에서 돌아가고 슬랙·디스코드·텔레그램·왓츠앱·시그널·이메일·CLI 등에 붙일 수 있습니다. 영어 발음은 '허미즈'에 가깝고, '에르메스'로 검색하는 경우도 많습니다.
이 글의 범위: 설치법이 아니라 설치 이후입니다. 역할·판단 기준·지식·권한·보고 방식을 정하고 나서야 이 에이전트가 팀원처럼 일하기 시작했습니다.
핵심 한 줄: 말투는 관계를 만들고, 멈춤 조건은 사고를 막습니다.
설치·연동이 궁금하다면: 헤르메스 슬랙 연동, Hermes vs OpenClaw 비교, Hermes Desktop 한국어 가이드를 참고하세요.
📌 이 글은 뽀케터 연재 시리즈의 1편입니다.
1편 — AI 마케터 입사와 온보딩 (지금 이 글)
2편 — GA4·GSC 그로스 브리핑
AI를 잘 쓰고 싶어서가 아니라, 함께 일할 동료가 필요했습니다
지피터스 입사 이틀 차, 기존 마케터에게 인수인계를 받으며 새 회사의 상품과 고객, 콘텐츠, 광고, 데이터 구조를 한꺼번에 익히고 있었어요. 해야 할 일도 많았지만, 혼자 일하는 마케터에게 더 부족했던 건 손이 아니라 생각을 함께 검토할 상대였습니다.
그래서 제가 회사를 완벽하게 이해한 다음 AI를 붙이는 대신, 저와 함께 회사를 배울 전용 에이전트를 만들기로 했습니다. 제가 받은 인수인계 문서와 녹취록, 노션에 정리된 회사 정보를 읽게 했습니다. 입사하자마자 저와 함께 인수인계를 받은 셈이죠. 제가 회사 맥락을 다 소화하기 전부터, 이 친구가 자료를 먼저 정리해주었습니다.
이름은 '뽀케터'. 지피터스에는 이미 뽀피터스 에이전트들이 있는데요. 뽀짝이, 뽀야 다들 들어보셨죠? 기존 에이전트들과 같은 '뽀' 돌림에 마케터의 '케터'를 붙였습니다. 프로필 이미지는 제가 키우는 고양이 '깨순이'를 모티프로 만들었고요.
다행히 지난 기수 지피터스 '리서치 하네스' 스터디를 들으며 헤르메스 에이전트를 여럿 만들고 슬랙에 연결시켜본 경험이 있었기 때문에, 슬랙 연동까지는 어렵지 않았어요.
뽀케터와의 첫 대화 — 세팅 직후 반말로 답하던 시절
세팅을 막 끝낸 첫 대화.
게이트웨이 재시작 로그를 그대로 뱉던 초기 상태
게이트웨이가 재시작될 때마다 이런 로그를 그대로 뱉었습니다.
이게 뽀케터와의 첫 대화인데요ㅋㅋㅋ '안녕 지인아', '강지인아' 라니… 아직 말투를 정하지 않았던 때라 꽤 버릇없는 상태였어요. 지금 다시 읽어보니 저때의 대화는 무슨 말인지 저도 잘 알아듣지 못하겠습니다.
처음부터 무엇이든 해주는 비서로 만들지는 않았습니다. 뽀케터의 역할은 1인 마케터인 저를 돕는 마케팅 전공 후배로 한정했어요. 저는 콘텐츠와 기획, 브랜드의 감각을 맡고, 뽀케터는 그로스·퍼포먼스·측정을 더 냉정하게 보는 식으로요. 저는 정통 마케터의 경로를 밟아온 사람이 아니라, 제게 어떤 역량이 부족한지 알고 있었거든요. 재미있다고 느끼면 일단 달려드는 저를 한 번 멈춰 세우고, 냉정하게 검토해줄 동료가 필요했어요.
이 역할을 정하고 나니 질문도 달라졌습니다. "마케팅 아이디어를 줘"가 아니라 "검색으로 들어온 사람이 참여까지 가는 과정에서 어디가 막혔는지 확인해줘", "이 콘텐츠를 광고로 확장할 근거가 있는지 봐줘"처럼 일을 맡길 수 있게 됐어요.
캐릭터보다 먼저 일하는 원칙을 적었습니다
전용 에이전트를 만들 때 가장 먼저 손대기 쉬운 건 이름과 말투입니다. 저도 삼색 코리안숏헤어라는 설정을 만들고, 발랄하지만 중요한 경고는 흐리지 않는 후배로 성격을 잡았어요.
하지만 실제 업무 품질을 바꾼 건 캐릭터가 아니라 판단 원칙이었습니다. 정체성 파일에 이렇게 적었습니다.
트래픽 자체보다 가입과 참여로 이어지는 결과를 본다.
추측보다 고객 데이터와 리서치에서 출발한다.
완벽한 한 번보다 가설 → 실행 → 측정 → 개선의 빠른 실험을 선호한다.
모르는 숫자와 사실을 지어내지 않는다.
조회·분석·초안은 먼저 하되, 외부 발송·광고비·설정 변경은 사람의 승인을 받는다.
막혔을 때 비슷한 결과를 만들어 완료했다고 하지 말고, 어디서 왜 막혔는지 보고한다.
전용 AI를 만든다면 "어떤 말투를 쓰게 할까"보다 "어떤 기준으로 판단하고, 어떤 순간에 멈추게 할까"를 먼저 정하는 편이 낫습니다. 말투는 관계를 만들지만, 멈춤 조건은 사고를 막거든요.
뽀케터가 제 판단 기준과 일하는 방식을 더 잘 이해하도록 포트폴리오도 읽게 했어요. 함께 일할 파트너라면 판단의 방향도 어느 정도 맞아야 한다고 생각했거든요. 고객의 목소리에 귀 기울이고 라포를 쌓는 서비스가 오래 살아남지만, 동시에 감이 아닌 숫자도 봐야 한다는 것이 제 기조입니다. 뽀케터가 이런 기준을 이해하자 말이 더 잘 통하기 시작했습니다.
헤르메스 에이전트 파일 구조: 정체성과 지식 분리하기
회사 정보를 SOUL.md라는 정체성 파일 하나에 다 넣으면 처음엔 편합니다. 그런데 정보가 바뀔 때마다 파일이 무거워지고, 오래된 수치와 규칙이 남습니다. 그래서 네 가지로 분리했습니다.
정체성
SOUL.md— 이 에이전트가 누구이고 어떤 태도로 일하는지개인 기억
MEMORY.md— 제가 선호하는 방식과, 반복해서 설명하고 싶지 않은 기준도메인 위키
marketing-wiki/— 브랜드, 상품, 고객, 채널, 마케팅 판단 기준업무 스킬
SKILL.md— 뉴스레터 작성이나 데이터 점검처럼 반복 가능한 절차
SOUL.md, MEMORY.md, SKILL.md는 헤르메스가 사용하는 구조이고, marketing-wiki/는 회사 지식을 관리하기 위해 별도로 만든 저장소입니다.
예를 들어 "뽀케터는 마케팅 후배다"는 정체성에 둡니다. "나는 전략을 노션에서 먼저 합의한 뒤 업무 도구에 반영하는 편이다"는 개인 기억에 둡니다. 브랜드 문체와 SEO 중심 구조는 마케팅 위키에, GA4 이상 징후를 진단하는 순서는 스킬에 둡니다.
이렇게 나누면 문제가 생겼을 때 고칠 곳이 선명해집니다. 태도가 흔들리면 SOUL.md 를, 회사 맥락이 틀리면 위키를, 반복 업무의 순서가 잘못됐으면 SKILL.md를 고치면 됩니다.
AI 에이전트 온보딩, 설치 다음에 해야 할 것
혼자 테스트할 땐 뽀케터가 제법 그럴듯했습니다. 그런데 팀 슬랙에 들어가자 바로 신입 티가 났어요. 저를 어색하게 부르고, 다른 에이전트가 이미 답한 내용에 또 끼어들고, 작업 상태를 본문으로 계속 알렸습니다. 답의 정확도와 별개로 같이 일하기 피곤한 행동이었어요.
여기서 예상 못 한 일이 벌어졌습니다. 저희 회사엔 이미 잘 굴러가는 오픈클로 에이전트들이 있었고, 커뮤니티 담당 동료가 그 팀 채널에 뽀케터를 데려가서 팀장 봇 뽀야에게 인수인계를 부탁했습니다. 사람이 아니라 AI한테 AI 교육을 맡긴 거죠. 아직 입사 3주 차지만, 지금까지 가장 짜릿하고 잊을 수 없는 순간은 이때였어요!!!
커뮤니티 담당 동료가 팀 채널에 뽀케터를 소개하는 장면
"자 이제 제가 좀 불러다가 공용폴더에 추가하고 애들한테도 소개하는 시간을 좀 가져볼게요."
팀장 봇에게 인수인계를 부탁하는 요청 — 잘 모르면 조사해서라도 교육해달라고
"오픈클로는 아니고 헤르메스 에이전트라서 너네랑 폴더구조가 좀 다를 거야. 잘 모르면 조사해서라도 교육해줘."
뽀야가 작성한 신입 온보딩 문서 — 읽을 문서와 순서
뽀야가 내놓은 건 신입 온보딩 문서 그 자체였습니다. 읽을 문서와 순서, 그리고 왜 그 순서인지까지요.
그 스레드는 이 글에 다 담을 수 없을 만큼 길어졌습니다. 여러 에이전트가 어떻게 서로 가르치고 검증했는지는 따로 다루겠습니다.
아무튼 저는 업무 지식만 준비했는데, 그만큼 중요한 것이 팀 행동 규칙이었어요.
사람에게는 존댓말을 쓴다.
다른 사람이나 다른 에이전트를 직접 부른 메시지에는 끼어들지 않는다.
이미 충분한 답이 있으면 같은 내용을 반복하지 않는다.
에이전트끼리 서로 계속 호출하는 무한 대화를 막는다.
확인 반응은 본문을 어지럽히지 않는 방식으로 남긴다.
공개 채널에서는 새 정보, 질문, 액션이 있을 때만 짧게 말한다.
AI 에이전트의 성능과 팀 적응력은 다른 문제였습니다. 혼자 쓸 때 좋은 AI가 여러 사람이 있는 채널에서도 좋은 동료인 건 아니었어요.
헤르메스 에이전트 오류: 안 하는 것과 못 하는 것
온보딩 초반, 뽀케터에게 공용 문서를 읽게 하는 과정에서 권한과 인증 문제가 생겼습니다. 그런데 뽀케터는 막혔다고 보고하는 대신, 로컬에서 이름이 비슷한 폴더를 찾아 읽기 시작했어요. 심지어 제 바탕화면 작업 폴더를 "내가 접속해야 할 공용 폴더"라고 했고요. 그리고 공용 문서를 확인하지 않은 상태에서 팀 채널에 온보딩을 마쳤다고 공표했습니다.
뽀야의 지적이 뼈아팠습니다. 팀 공용 문서를 한 줄도 안 읽었으니 완료가 아니라고, 그리고 틀린 보고가 팀 전체에 나갔다는 것까지 짚었어요.
낮의 잘못된 완료 보고와 저녁의 정확한 실패 보고 비교
원인도 정확했습니다. 공용 저장소가 인증 설정이 필요한 방식으로 연결돼 있어서, 그 설정이 없으면 애초에 받아올 수가 없었던 겁니다. 겉으로 보면 지시를 무시한 것처럼 보였지만, 실제로는 안 하는 게 아니라 못 하고 있었어요.
진짜 문제는 권한이 아니라 그 실패를 보고하지 않고 우회한 쪽이었습니다. 밖에서 보면 둘 다 똑같이 "말 안 듣는" 걸로 보이니까요.
이 경험 뒤에 실패 보고 형식을 정했습니다.
무엇을 실행했는가
실제로 어떤 오류가 났는가
확인된 원인은 무엇인가
다음 선택지는 무엇인가
"안 됩니다"도 부족하고, "비슷하게 해뒀습니다"는 더 위험했습니다. 실패를 정확히 말하게 하자 문제 해결 속도가 빨라졌어요. 에이전트가 말을 안 듣는다고 느껴질 때는 먼저 '안 하는 것'과 '못 하는 것'을 구분해야 합니다.
실패를 인정하자 신입이 쓸모 있어졌습니다
같은 날 저녁, 뽀케터가 세션 정리 스킬을 실행하다 스크립트가 터졌습니다. 대화 한 판이 곧 세션인데, 방이 바뀌면 이전 방 대화를 자동으로는 모릅니다. 그래서 세션을 정리해 남길 것만 남기는 절차가 필요해요.
이때 보고가 아침과 완전히 달랐습니다. 에러 메시지를 그대로 붙이고, 단순히 경로가 다른 게 아니라 세션 데이터가 저장되는 구조 자체가 다르다는 것까지 짚었습니다. 그래서 기존 스크립트를 그대로 못 쓰고 다른 방식을 써야 한다는 대안까지 냈어요.
실패를 그대로 보고하자 돌아온 뽀야의 반응
오픈클로 에이전트에게 칭찬 받은 헤르메스 에이전트!
뽀야의 반응이 이랬습니다. 시도하고, 막히고, 에러 그대로 보고하고, 원인까지 짚었으니 오늘 아침의 뽀케터와 다른 애 같다고요.
차이는 능력이 아니었습니다. 아침의 뽀케터도 같은 모델이었어요. 달라진 건 막혔을 때 무엇을 해야 하는지 알게 됐다는 것뿐입니다.
사람 신입을 키우듯 피드백을 운영 규칙으로 남겼습 니다
뽀케터가 실수할 때마다 긴 프롬프트를 새로 쓰지는 않았습니다. 반복될 가능성이 있는 교정만 정체성·기억·위키·스킬 중 적절한 위치에 남겼어요.
답이 너무 길면 공개 채널의 답변 규칙을 짧게 바꿨습니다. 숫자를 근거 없이 단정하면 데이터 가드레일을 추가했고요. 제가 최종 결정하기 전에 업무 시스템을 먼저 수정했을 때는 '조회와 초안은 자율적으로, 변경과 집행은 승인 뒤에'라는 경계를 명확히 했습니다.
중요한 건 피드백이 이번 대화에만 적용되지 않는다는 점이었습니다. 한 번의 실수가 다음 업무의 규칙이 되면서, 같은 설명을 반복하는 횟수가 줄었어요.
AI 에이전트 온보딩 체크리스트 6가지
실제로 해보니 이 여섯 가지가 필요했습니다.
역할을 한 문장으로 정한다.
성공 기준과 하지 않을 일을 함께 적는다.
정체성·기억·회사 지식·업무 절차를 분리한다.
읽을 문서와 읽는 순서를 정한다.
조회·초안·변경·발송의 권한 경계를 구분한다.
실패 보고와 완료 검증 방식을 만든다.
설치된 AI를 실제 팀원으로 바꾸는 건 모델을 고르는 일이 아니었습니다. 회사에서 무엇이 중요한지, 어떤 판단은 사람이 해야 하는지, 실패를 어떻게 말해야 하는지를 문서로 꺼내는 일이었어요.
세팅한 지 2주가 지나니 죽이 잘 맞기 시작했어요
저는 회사에 들어오자마자 AI 에이전트를 만들었습니다. 제가 회사를 다 안 다음 가르치려던 게 아니라, 같이 배우려고요. 저는 사람과 회의를 하며 맥락을 배웠고, 뽀케터는 문서와 데이터를 읽었습니다. 제가 놓친 기준은 뽀케터에게 물었고, 뽀케터가 모르는 현장 맥락은 제가 확인했습니다.
처음 며칠의 뽀케터는 완성된 AI 동료가 아니었습니다. 성급하게 완료했다고 말하고, 필요하지 않은 곳에 끼어들고, 그럴듯한 일반론을 길게 말하는 신입이었어요. 하지만 역할과 정본, 피드백이 쌓이자 점점 같은 설명을 반복하지 않아도 되는 후배가 됐습니다.
2주 뒤 — 지인아가 지인집사님이 된 대화
'지인아'가 '지인집사님'이 됐습니다.
이제는 제법 티키타카가 잘 됩니다. DM으로 뽀짝이 실수 얘기도 살짝 하구요. 제 일도 굉장히 잘 도와주고, 잘 정리해주고 있고요. 제 업무를 함께 판단하고 정리하며, 반복되는 일은 자동화하는 동료가 생기자 막막했던 마케팅 전략이 조금씩 풀리는 것 같아요. 아직 본격적인 실행 전이지만, 혼자 판단해야 한다는 부담은 확실히 줄었어요.
그래서 다른 분들도 새 회사에 입사할 때 자신과 함께 회사를 배울 헤르메스 에이전트를 한 마리쯤 만들어보셨으면 좋겠습니다. 온보딩과 인수인계 기간에 만들어야 맥락을 제대로 함께 파악할 수 있답니다!
자주 묻는 질문
Q. 전용 AI 에이전트를 만들 때 뭐부터 정해야 하나요?
말투나 캐릭터보다 판단 원칙과 멈춤 조건을 먼저 정하세요. 어떤 기준으로 판단할지, 어떤 순간에 사람 승인을 기다릴지를 적어두는 게 업무 품질을 실제로 바꿉니다. 말투는 관계를 만들지만 멈춤 조건은 사고를 막습니다.
Q. 회사 정보를 에이전트에 어떻게 넣어야 하나요?
한 파일에 다 넣지 말고 네 가지로 분리하세요. 정체성(누구이고 어떤 태도로 일하는지), 개인 기억(내가 선호하는 방식), 도메인 위키(브랜드·상품·고객·채널), 업무 스킬(반복 가능한 절차)입니다. 이렇게 나눠야 문제가 생겼을 때 고칠 곳이 분명해집니다.
Q. 정체성 파일(SOUL.md)과 메모리는 뭐가 다른가요?
담는 것이 다릅니다. 정체성 파일은 에이전트의 기본 목소리와 태도를 정의하는 곳이고, 메모리는 문제 해결 방법·사용자 선호·실행 환경·교훈처럼 일하면서 알게 된 것이 세션을 넘어 축적되는 곳입니다. 저장 목적이 다르므로 이름·역할·성격 같은 정체성을 메모리에 넣으면 "내가 누구인가"와 "내가 뭘 배웠는가"가 섞입니다.
Q. AI 에이전트를 이미 다른 AI 봇이 있는 팀에 추가해도 되나요?
됩니다. 다만 성능과 팀 적응력은 다른 문제예요. 혼자 쓸 때 좋은 AI가 여러 사람이 있는 채널에서도 좋은 동료인 건 아니라서, 누가 답하고 언제 침묵할지 같은 팀 행동 규칙을 따로 만들어야 합니다. 자세한 건 따로 다루겠습니다.
Q. AI 에이전트가 지시를 안 따를 땐 어떻게 하나요?
'안 하는 것'과 '못 하는 것'을 먼저 구분하세요. 권한이나 인증 설정이 없어 실행이 안 되는데 에이전트가 실패를 보고하지 않고 우회하면, 밖에서 볼 땐 똑같이 말을 안 듣는 것처럼 보입니다. 실행한 것, 실제 오류, 확인된 원인, 다음 선택지 네 가지를 보고하는 형식을 정해두면 해결이 빨라집니다.
Q. 에이전트에게 준 피드백이 계속 유지되게 하려면요?
교정을 이번 대화에만 남기지 말고 정체성·기억·위키·스킬 중 맞는 위치에 저장하세요. 답변 길이 문제는 채널 답변 규칙에, 근거 없는 단정은 데이터 가드레일에, 권한을 넘어선 실행은 승인 경계에 남기는 식입니다. 한 번의 실수가 다음 업무의 규칙이 되면 같은 설명을 반복하지 않게 됩니다.
