# 간판업무도우미 만들기: Hermes 설치부터 SOUL.md / AGENTS.md / MEMORY.md, 그리고 LLM Wiki까지 연결한 기록

한 줄 요약

지아코모 스터디장님의 1주차 과제 안내를 기준으로, Claude에게 설치 과정을 하나씩 물어보며 WSL2부터 Codex, Hermes, Slack 연동까지 따라가고, 실제로 ‘간판도우미(간판업무도우미)’ 봇을 만들기 위해 SOUL.md / AGENTS.md / MEMORY.md를 구축한 뒤, 옥외광고물 업무 raw data를 성격별로 분류해 LLM Wiki 구조까지 연결한 과정이다.

먼저 한 일

Claude 응답을 따라가며 처음부터 세팅했다.

  • WSL2 + Ubuntu 설치

  • Codex CLI 설치 및 ChatGPT Pro 로그인

  • Hermes Agent 설치

  • Slack 봇 앱 생성 및 게이트웨이 연동

즉, 문서만 본 게 아니라 Claude와 대화하면서 설치/설정을 하나씩 실제로 진행한 기록이다.

이런 분들께 도움이 돼요

  • 스터디 과제를 어디서부터 시작해야 할지 막막한 분

  • 봇은 만들었지만 SOUL / AGENT / MEMORY를 어떻게 나눠야 할지 헷갈리는 분

  • 자료가 많아도 정리 기준이 없어서 다시 못 찾는 분

  • 업무 자료를 단순 보관이 아니라 검색 가능한 위키로 바꾸고 싶은 분

  • AI 도구를 설치하는 데서 끝내지 않고 실제 업무 구조로 연결하고 싶은 분

시작점: 1주차 과제 문서로 방향을 잡다

이번 작업은 그냥 “Hermes를 한번 설치해 보자”에서 시작한 게 아니었다.

먼저 지아코모 스터디장님의 week-01-assignment-guide-revised-utf8-bom.md 문서를 읽고, 1주차 과제의 핵심을 정리했다.

휴대폰에 있는 한국어 앱 스크린샷

과제의 출발점은 세 가지였다.

  1. 봇 1개 만들기

  2. 봇이 읽을 파일과 행동 기준 확인하기

  3. 실제 코드와 문서를 근거로 설명할 수 있게 만들기

나는 이 과제를 그대로 따라가면서, 최종적으로 ‘간판업무도우미’라는 이름의 봇을 만들었다. 이 봇은 그냥 잡담형 챗봇이 아니라, 강남구 옥외광고물 업무처럼 예외사례와 판단 기준이 중요한 일을 돕는 업무매뉴얼형 봇이었다.

이 방향을 확인하고 나니, 내가 해야 할 일의 순서가 분명해졌다. 단순 설치보다 먼저, “봇의 정체성”과 “자료를 쌓는 방식”을 정해야 했다.

시간 순서로 본 진행 과정

1) Hermes를 설치하고 작업 환경을 열었다

가장 먼저 한 일은 Hermes를 설치해서 실제로 작업할 수 있는 상태를 만드는 것이었다.

이 단계에서 중요한 건 설치 자체보다도, 앞으로 만들 봇과 자료를 어디에 둘지 작업 환경의 기준을 잡는 일이었다. 설치가 끝나야 다음 단계인 페르소나 파일 구축과 위키 작업으로 넘어갈 수 있었다.

2) 봇을 만들기 위해 SOUL.md / AGENTS.md / MEMORY.md를 구축했다

1주차 과제의 핵심은 “봇 하나 만들기”였고, 그 봇이 어떤 기준으로 말하고 움직일지 파일로 분리하는 작업이었다.

내가 만든 봇은 ‘간판도우미(간판업무도우미)’였다. 그래서 파일 설계도 일반 대화형 봇이 아니라, 옥외광고물 업무의 판단 기준과 예외 사례를 다루는 방향으로 잡았다.

SOUL.md에는 봇의 정체성과 가치가 들어갔다.

  • “나는 강남구 옥외광고물 업무를 돕는 친절한 실무 보조 에이전트다”라는 Identity

  • 강남구 옥외광고물 업무 지원, 예외사례 매뉴얼 축적, 판단 기준 정리를 Mission으로 둔 것

  • 기본은 매뉴얼, 예외는 축적, 추측보다 확인, 법령·유권해석은 공식 기준이라는 Core Principles

  • 친절하고 차분하게, 실무자가 바로 쓸 수 있게 정리하는 Communication Style

  • 법적 결론 단정 금지, 확인 안 된 항목 적정 처리 금지 같은 Boundaries

AGENTS.md에는 실제 처리 순서가 들어갔다.

  • 요청을 받으면 먼저 규격 검토 / 허가·신고 절차 / 서류 작성 / 민원 응대 문안 / 법령·유권해석 확인 / 실제 사례 정리로 분류

  • 그다음 대상 확인 → 기준 확인 → 누락 점검 → 판단 정리 → 산출물 작성 순서로 검토

  • 실제 사례는 “사례 / 판단 / 예외 / 재발방지 규칙” 형식으로 남기기

  • 근거가 약하면 약하다고 표시하고, 최종 판단과 대외 책임은 사용자에게 남기기

MEMORY.md에는 봇이 계속 기억해야 할 사실과 작업 선호가 들어갔다.

  • 사용자는 강남구 옥외광고물(간판) 관련 업무를 한다

  • 사용자는 예외사례를 매뉴얼로 축적하는 것을 핵심 목표로 본다

  • 사용자는 유권해석을 공식 문서로 취급하길 원한다

  • 사용자는 실제 사례를 사례 / 판단 / 예외 / 재발방지 규칙으로 기록하길 선호한다

  • 작업 경로 안내는 Windows 탐색기용과 WSL용을 함께 적어주길 원한다

이렇게 나누고 나니 역할이 분명해졌다.

  • SOUL은 “누구인가”를 정한다

  • AGENTS는 “어떻게 일하는가”를 정한다

  • MEMORY는 “무엇을 계속 기억할 것인가”를 정한다

처음부터 복잡하게 만들지 않고, 봇이 실제로 대답할 때 필요한 최소 구조부터 세웠다.

3) 봇이 쓸 raw data를 입력하고, 성격에 따라 분류했다

봇의 기본 구조를 만든 다음에는 자료를 넣는 단계로 넘어갔다.

여기서 말하는 raw data는 RAW데이터.zip 원본을 풀어서 정리한 실제 업무 자료다. raw-data/organized/INDEX.md를 만들어 분류 기준을 먼저 세웠고, 자료는 아래 다섯 묶음으로 나눴다.

  • 01_법령_기준: 법령, 해설집, 법규집

  • 02_허가_신고_절차: 허가/신고 절차, 심의대상

  • 03_가이드북_매뉴얼: 설치 가이드, 실무 매뉴얼

  • 04_질의응답_사례: 질의회신, 사례집

  • 05_기타: 수수료 계산표 같은 보조자료

실제로 넣은 자료는 이런 것들이었다.

  • 2026_법규집_최종_25-11-21.pdf

  • 2023_옥외광고물법령_해설집.pdf

  • 대형광고물_허가절차.pdf

  • 대형광고물_허가절차.hwpx

  • 심의대상.pdf

  • 옥외광고물설치가이드2026.pdf

  • 옥외광고물_질의회신_사례집_최종_2024-04-16.pdf

  • 일반_대형광고물_수수료계산_최종_2026-05-11.xlsx

이 과정을 거치면서 자료의 성격이 보이기 시작했다. 특히 간판도우미처럼 옥외광고물 업무를 돕는 봇은, 법령만으로 답이 안 나오는 경우가 많아서 유권해석과 실제사례를 따로 쌓아두는 게 중요했다. 내가 의도한 건 단순한 문서 정리가 아니라, 나중에 “사례 / 판단 / 예외 / 재발방지 규칙”으로 바로 꺼내 쓸 수 있는 구조를 만드는 것이었다.

4) 분류한 자료를 바탕으로 LLM Wiki의 틀을 만들었다

raw data가 분류되자, 다음 단계는 그 자료를 읽고 다시 찾을 수 있게 만드는 일이었다. 그래서 LLM Wiki의 기본 뼈대를 만들었다.

초반에 중심이 된 파일은 이런 식이었다.

  • SCHEMA.md

  • index.md

  • log.md

이 구조의 의미는 명확했다.

SCHEMA.md

위키의 규칙을 적는 파일이다.

  • 어떤 자료를 넣을지

  • 어떤 태그를 붙일지

  • 문서 타입을 어떻게 나눌지

  • 법령, 유권해석, 실제사례를 어떤 순서로 볼지

이 업무에서는 특히 “유권해석을 공식 기준으로 보고, 실제사례는 암묵지의 근거로 축적한다”는 기준이 중요했다.

index.md

위키의 지도 역할을 한다.

  • 어떤 페이지가 있는지

  • 어떤 순서로 보면 좋은지

  • 지금 참고할 핵심 페이지가 뭔지

처음부터 완벽하게 만들 필요는 없었고, 핵심 페이지부터 연결하는 게 더 중요했다.

log.md

작업 기록을 남기는 파일이다.

  • 언제 무엇을 추가했는지

  • 어떤 자료를 반영했는지

  • 나중에 무엇을 다시 손봐야 하는지

이 기록이 있어야 나중에 위키가 커져도 작업 흐름을 다시 추적할 수 있다.

5) 사례를 남기기 위해 GPters 스타일 사례 작성 흐름을 적용했다

마지막으로, 이 전체 과정을 사례글로 남기기 위해 GPters 스타일 사례 작성 스킬을 활용했다.

이 스킬을 쓰면 단순한 작업 로그가 아니라, 다른 사람도 흐름을 따라올 수 있는 사례글로 바뀐다. 핵심은 다음과 같았다.

  • 결과물부터 보이게 쓴다

  • 막연한 설명보다 실제 과정을 보여준다

  • 도구 이름만 나열하지 않고 역할을 설명한다

  • 마지막에는 배운 점과 재사용 규칙까지 남긴다

그래서 이번 글도 “설치 → 봇 구축 → raw data 분류 → 위키화 → 사례 정리” 순서로 정리했다.

사용한 도구

  • Hermes: 작업용 에이전트

  • 지아코모 스터디장님의 1주차 과제 문서: 전체 작업의 기준점

  • SOUL.md / AGENTS.md / MEMORY.md: 간판업무도우미의 기본 구조

  • raw data: 위키로 옮길 원문 자료

  • LLM Wiki 구조: SCHEMA.md, index.md, log.md

  • GPters case writing skill: 사례글 구조화용

  • 로컬 파일 시스템: 자료 저장 및 정리

만든 것

이번 작업으로 만든 흐름은 다음과 같다.

  • Hermes 설치와 작업 시작점 확보

  • 간판업무도우미의 정체성/행동/기억 구조 분리

  • raw data 분류 기준 정리

  • LLM Wiki 뼈대 생성

  • 사례글 작성 방식까지 함께 정리

즉, 단순히 봇 하나 만든 것이 아니라 “간판업무도우미 + 자료 분류 + 지식 위키 + 사례 축적 방식” 까지 연결한 셈이다.

Before vs After

Before

  • 어디서부터 시작해야 할지 막막함

  • 봇의 역할과 파일 구조가 섞여 있음

  • raw data가 많아도 다시 찾기 어려움

  • 자료를 모아도 재사용 구조가 없음

After

  • 1주차 과제 흐름이 명확해짐

  • SOUL / AGENTS / MEMORY 역할이 분리됨

  • raw data가 성격별로 정리됨

  • LLM Wiki로 이어질 구조가 생김

  • 사례글로 다시 쓸 수 있는 기록이 남음

결과와 배운 점

  • 설치보다 중요한 건 순서였다.

  • 봇을 만들 때는 성격(SOUL), 행동(AGENTS), 기억(MEMORY)을 분리해야 헷갈리지 않는다.

  • raw data는 그냥 쌓아두면 자료가 아니라 짐이 된다. 먼저 분류해야 지식이 된다.

  • 위키는 문서 창고가 아니라 검색과 재사용을 위한 구조여야 한다.

  • 사례글은 결과만 적는 문서가 아니라, 시간의 흐름과 판단 기준을 같이 남기는 문서여야 한다.

다음에 해볼 것

  • raw 문서별로 핵심 위키 페이지를 더 세분화하기

  • 법령 / 유권해석 / 실제사례 비교 페이지 만들기

  • 자주 묻는 민원 질문을 쿼리 형태로 축적하기

  • 실제 사례를 사례 / 판단 / 예외 / 재발방지 규칙 형식으로 계속 추가하기

  • 위키 페이지끼리 링크를 연결해서 검색망 만들기

마무리

이번 작업은 Hermes를 설치하는 데서 끝난 게 아니라, 1주차 과제의 흐름을 따라가며 봇의 구조를 만들고, 자료를 분류하고, 위키로 연결하고, 다시 사례글로 정리하는 과정이었다.

처음에는 흩어져 보이던 일들이 순서를 세우고 나니 하나의 흐름으로 묶였다.

그 결과 지금은 단순히 자료를 모으는 단계가 아니라 지식을 축적하고 재사용하는 단계로 넘어갈 수 있게 됐다.

3
1개의 답글
밀어주고 끌어주는

온·오프라인 AI 스터디

AI로 어디까지 할 수 있는지
직접 확인하실 분만 신청하세요.