소개
이번 에이전트 하네스 스터디는 Hermes를 활용해 나만의 봇을 만들고, 단순한 프롬프트가 아니라 반복해서 사용할 수 있는 하네스로 발전시키는 과정이었어요.
저도 스터디 초기에 ‘데비’라는 반려 에이전트를 만들었습니다. Hermes를 설치하고 텔레그램을 연결한 뒤 이름, 역할, 말투와 기본적인 안전 경계를 설정했어요. 앞으로 데비를 제 일상을 함께 운영 하는 개인 비서로 키우고, 여러 영역을 담당하는 팀원 에이전트도 연결하겠다는 계획까지 세웠습니다.
그런데 계획은 그럴듯했지만 실제 데비는 초기 설정에서 크게 나아가지 못했어요.
이름과 캐릭터는 있었지만 무엇을 언제 챙겨야 하는지, 어떤 정보를 기억해야 하는지, 어디까지 스스로 행동할 수 있는지, 반복 업무를 어떤 순서로 처리해야 하는지는 정해져 있지 않았습니다. 한마디로 **봇의 모습은 있었지만 하네스는 없는 상태**였어요.
스터디 마지막을 앞두고 보니 그동안 Context, Memory, Tool, Skill, 승인 경계와 검증에 대해 배운 내용을 정작 제 봇에는 충분히 적용하지 못했다는 생각이 들었어요. 그래서 새로운 계획을 하나 더 세우는 대신, 배운 것을 실제 데비의 구조로 옮겨보기로 했습니다.
이번에 시도하고자 했던 것은 데비가 개인 비서로 움직이기 위해 필요한 최소 하네스를 실제 파일과 절차로 만드는 것이었어요.
구체적인 목표는 다음과 같았습니다.
- 데비의 말투뿐 아니라 판단과 보고 원칙까지 정의하기
- 사용자 정보와 반복 업무 절차를 서로 다른 맥락으로 분리하기
- 먼저 알려야 하는 상황과 침묵해야 하는 상황 정하기
- 추측과 할루시네이션을 줄이기 위한 사실 확인 원칙 만들기
- 파일 작업과 외부 행동의 승인 경계 구체화하기
- 자동화 전에 수동으로 검증할 수 있는 반복 업무 Skill 만들기
개인 비서에는 구체적인 사용자 맥락이 필요하지만, 공개 사례글에는 개인 일정, 생활시간, 건강 수치, 재무정보처럼 개인을 유추할 수 있는 내용은 제외하고 구조와 판단 과정만 남겼습니다.
## 진행 방법
### 사용한 도구
- **Hermes** — 데비가 실제로 동작할 에이전트 환경이자 기존 SOUL.md, 사용자 맥락, Skill을 적용할 대상
- **텔레그램** — 기존에 연결해둔 데비와 대화하기 위한 채널
- **Codex** — 질문을 통해 필요한 맥락을 정리하고, 하네스 구조와 문서 초안을 만드는 데 활용
- **Markdown** — SOUL, 사용자 맥락, Skill, 운영계획을 각각 독립된 파일로 작성
이번 단계에서는 Codex와 함께 실제 하네스 문서를 만들었고, Hermes 환경 반영과 외부 서비스 연결은 다음 검증 단계로 남겨두었습니다.
### 1. 먼저 데비에게 필요한 역할을 질문으로 좁혔어요
처음부터 기능 목록을 길게 만들지 않고 다음 세 가지를 기준으로 정리했어요.
1. 데비가 반복해서 챙겨야 하는 것은 무엇인가?
2. 데비가 먼저 알려도 되는 순간과 침묵해야 하는 순간은 언제인가?
3. 데비가 절대로 임의로 실행하면 안 되는 행동은 무엇인가?
처음 사용한 프롬프트 전문은 다음과 같습니다.
```text
맞아. 지금 데비는 완전 기본적인 세팅이 되어 있는 상태야.
내 개인 비서로 만들어 나가기 위해서는 어떤 과정을 거치면 좋을지
상세하게 가이드해주고, 필요하다면 질문해줘.
```
Codex가 일정관리, 사용하는 도구, 원하는 능동성, 방해받고 싶지 않은 상황, 우선 목표, 서비스 권한과 개인정보 경계 등을 질문했고, 저는 그 질문에 답하면서 데비가 알아야 할 맥락을 정리했어요.
공개 글에는 답변의 세부 내용 대신, 질문을 통해 다음 항목이 정리되었다는 결과만 남깁니다.
- 데비의 핵심 역할
- 정보의 기준 장소
- 먼저 알려도 되는 조건
- 침 묵해야 하는 조건
- 서비스별 승인 원칙
- 저장하면 안 되는 민감정보
### 2. SOUL, USER, Skill, 운영계획의 책임을 분리했어요
초기에는 데비에 관한 내용을 SOUL.md 하나에 모두 넣으려고 했어요. 하지만 스터디에서 배운 하네스 구조를 적용해보니 성격, 사용자 정보, 업무 절차는 서로 다른 종류의 맥락이었습니다.
| 문서 | 책임 |
|---|---|
| DEBBY_SOUL.md | 데비는 누구이며 어떻게 판단하고 말하는가 |
| DEBBY_USER.md | 데비가 알아야 할 안정적인 사용자 맥락 |
| DEBBY_DAILY_BRIEFING_SKILL.md | 반복 업무를 언제, 어떤 입력과 절차로 처리하는가 |
| DEBBY_OPERATIONS_PLAN.md | 도구별 역할, 권한 단계, 도입 순서와 검증 기준 |
이렇게 나누니 데비의 말투를 바꾸다가 업무 절차까지 흔들리거나, 사용자 프로필에 임시 작업 지시가 계속 쌓이는 문제를 줄일 수 있었어요.
### 3. SOUL.md를 캐릭터 설정에서 판단 계약으로 확장했어요
기존 SOUL.md에는 이름, 역할, 싹싹한 말투와 기본 경계 정도만 있었어요. 이번에는 다음 내용을 추가했습니다.
- 결론과 다음 행동을 먼저 제시하는 보고 방식
- 사실·추정·의견 을 구분하는 기준
- 할루시네이션과 편향을 경계하는 규칙
- 정보가 부족할 때 확인 방법을 제시하는 방식
- 불필요한 간섭을 줄이는 능동성 원칙
- 외부 행동과 파일 작업의 승인 경계
- 영구 삭제 금지와 복구 가능성 우선 원칙
사실 기반 조언 규칙을 보강할 때 사용한 프롬프트 전문은 다음과 같습니다.
```text
데비 SOUL.md에 다음 내용을 추가해줘.
추측성 말을 하지 말고, 할루시네이션이나 바이어스가 있는 조언은
극도로 경계하니까 항상 팩트에 근거한 조언을 해줘.
그리고 혹시나 컴퓨터 파일을 다룰 때는 절대 파일 삭제나 이동 등은
반드시 나의 허락을 받고서 진행을 해주고,
절대 영구 삭제는 하지 말아야 할 1순위로 체크해줘.
```
이 요청을 바탕으로 SOUL.md에는 다음과 같은 실행 가능한 규칙이 들어갔어요.
```text
- 모든 조언과 판단은 확인 가능한 사실과 근거를 우선한다.
- 사실, 추정, 의견을 명확히 구분한다.
- 정보가 부족하면 부족하다고 밝히고 필요한 확인 방법을 제시한다.
- 중요한 판단에서는 근거의 출처, 최신성, 반대 가능성과 불확실성을 확인한다.
- 파일이나 폴더를 삭제·이동하기 전 대상과 범위를 보여주고 승인을 받는다.
- 파일과 폴더를 영구 삭제하지 않는다.
- 덮어쓰기·이름 변경·대량 수정도 영향과 복구 방법을 먼저 설명한다.
```
### 4. 반복 업무를 Daily Briefing Skill로 만들었어요
데비에게 “일정을 잘 챙겨줘”라고 말하는 대신, 입력과 처리 순서, 출력 형식, 실패 조건이 있는 반복 업무로 바꿨어요.
Daily Briefing의 처리 흐름은 다음과 같습니다.
```text
오늘 일정과 마감 확인
→ 실제 가용 시간 확인
→ 반드시 처리할 일 선택
→ 계속 밀리는 중요한 영역 확인
→ 과도한 계획 축소
→ 주의사항과 다음 행동 제안
```
Skill에는 다음 항목을 포함했습니다.
- 사용하는 조건
- 필요한 입력
- 입력을 조회하지 못했을 때의 행동
- 처리 순서
- 결과 출력 형식
- 일정 중 알림을 보내지 않는 침묵 조건
- 승인 없이 수정하지 않는 경계
- 실행 후 확인할 검수 체크리스트
특히 “먼저 챙겨주는 비서”를 만들면서도 다음과 같은 제한을 함께 넣었어요.
```text
- 일정이 진행 중일 때는 방해하지 않는다.
- 방해 금지 시간에는 메시지를 보내지 않는다.
- 이미 완료한 일을 다시 묻지 않는다.
- 핵심 업무만 제한적으로 점검한다.
- 할 일을 계속 추가하기보다 완료·축소·재배치·보류 중 하나를 선택하도록 돕는다.
- 일정이나 문서의 수정이 필요하면 실행하지 않고 먼저 제안한다.
```
### 5. 자동화 전에 권한 단계와 검증 순서를 만들었어요
처음에는 캘린더와 문서 도구를 연결해 바로 자동화하고 싶었어요. 하지만 이번에는 기능을 빨리 여는 것보다, 잘못 실행했을 때의 영향을 줄이는 것이 먼저라고 판단했습니다.
권한은 다음 순서로 확대하도록 정했어요.
```text
조회 전용
→ 실행안 제시
→ 사용자 승인
→ 제한적 실행
→ 반복 검증을 통과한 저위험 업무만 자동화
```
도입 순서도 다음처럼 나눴습니다.
```text
1단계 맥락과 안전 경계 정리
2단계 브리핑 수동 테스트
3단계 반복 업무 Skill 보강
4단계 필요한 서비스의 조회 전용 연결
5단계 검증된 업무만 제한적으로 자동화
6단계 필요한 경우 팀원 에이전트 분리
```
## 결과와 배운 점
### 결과
스터디 초기에 계획으로만 남아 있던 데비를 다음 네 개의 실제 하네스 문서로 구체화했습니다.
1. DEBBY_SOUL.md — 정체성, 판단, 보고, 사실 확인과 안전 경계
2. DEBBY_USER.md — 개인화를 위한 사용자 맥락과 민감정보 제외 기준
3. DEBBY_DAILY_BRIEFING_SKILL.md — 반복 업무의 입력, 절차, 출력과 검수 기준
4. DEBBY_OPERATIONS_PLAN.md — 도구별 역할, 권한 단계, 도입 순서와 평가 기준
Before와 After를 비교하면 다음과 같아요.
| 구분 | Before | After |
|---|---|---|
| 정체성 | 이름과 말투 중심 | 판단·보고·불확실성 처리 원칙 포함 |
| 사용자 이해 | 간단한 프로필 | 안정적인 사용자 맥락을 별도 관리 |
| 일정관리 | “일정을 챙겨줘” | 입력·절차·출력·침묵 조건을 가진 Skill |
| 안전 | 위험한 행동은 승인 | 파일 이동·덮어쓰기까지 포함한 구체적 승인 경계 |
| 자동화 | 하고 싶은 일 목록 | 조회와 수동 검증부터 시작하는 도입계획 |
| 확장 | 팀원 에이전트 구상 | 총괄 하네스 검증 후 분리하는 순서 |
이번 단계에서 실제 문서와 운영 구 조는 만들었지만, 다음 항목은 아직 확인하지 않았습니다.
- 개정한 문서를 실제 Hermes 환경에 반영한 뒤의 동작
- Calendar와 문서 도구의 실제 연결
- 브리핑 예약 실행
- 일정 중 알림 차단이 의도대로 작동하는지
- 장기간 사용했을 때 실제 누락과 미루기가 줄어드는지
따라서 이번 결과는 자동화까지 완료한 사례라기보다, **초기 설정에 머물던 봇을 실제로 검증할 수 있는 하네스 구조까지 만든 사례**입니다.
### 배운 점과 나만의 꿀팁
첫 번째로, **봇에게 이름을 붙이는 것과 하네스를 만드는 것은 다른 일**이었어요. 페르소나는 출발점이지만 반복해서 사용하려면 입력, 판단, 절차, 출력, 실패 조건과 승인 경계가 필요했습니다.
두 번째로, SOUL, 사용자 맥락, Skill의 역할을 나눠야 수정하기 쉬웠어요. 성격과 업무 절차를 한 문서에 섞으면 한 부분을 고칠 때 다른 부분까지 흔들릴 수 있었습니다.
세 번째로, 능동적인 에이전트에는 행동 조건뿐 아니라 **침묵 조건**도 필요했어요. 먼저 알려주는 것만큼 언제 방해하지 않을지를 정하는 것이 중요했습니다.
네 번째로, 자동화는 서비스 연결부터 시작하는 것이 아니라 **운영계약과 검증 기준부터 시작해야 한다**는 걸 배웠어요. 완료 기준이 없으면 결과가 그럴듯해도 실제로 잘 작동하는지 판단하기 어렵습니다.
### 과정 중 겪은 시행착오
**1. 계획을 많이 세운 것이 실제로 만든 것은 아니었어요.**
초기에는 여러 팀원 에이전트를 붙이는 그림까지 그렸지만, 총괄인 데비 한 명의 업무 방식도 충분히 정해져 있지 않았습니다. 그래서 범위를 넓히는 대신 기본 하네 스를 실제 문서로 만드는 데 집중했어요.
**2. “현실적으로 조언해줘”는 판정 기준이 아니었어요.**
무엇이 현실적이고 사실 기반인지 확인할 수 없었기 때문에, 사실·추정·의견 구분, 출처와 최신성 확인, 불확실성 표시처럼 관찰 가능한 기준으로 바꿨습니다.
**3. “파일 삭제는 조심해줘”만으로는 부족했어요.**
삭제뿐 아니라 이동, 덮어쓰기, 이름 변경도 복구 비용을 만들 수 있었습니다. 승인 대상, 실행 전 설명, 복구 가능성과 영구 삭제 금지까지 하나의 규칙으로 보강했어요.
### 도움이 필요한 부분
- Hermes에서 사용자 맥락과 Skill을 장기간 운영할 때, 정보가 오래되거나 충돌하는 문제를 어떻게 관리하면 좋은지 궁금해요.
- 캘린더 조회를 기반으로 하되 방해 금지 상황을 안정적으로 판정하는 운영 경험이 있으신 분들의 팁을 듣고 싶어요.
- 수동 테스트를 몇 회 정도 통과했을 때 자동 실행으로 전환하는 것이 적절한지도 다른 분들의 기준이 궁금합니다.
### 앞으로의 계획
다음에는 자동화를 바로 켜지 않고 한 가지 반복 업무부터 검증할 계획입니다.
1. 개정한 SOUL.md와 USER.md를 Hermes에 반영
2. 필요한 서비스는 조회 전용으로 연결
3. Daily Briefing을 수동으로 여러 차례 실행
4. 정보 누락, 과한 제안, 불필요한 알림과 승인 위반 여부 기록
5. 기준을 통과한 뒤에만 예약 실행으로 전환
검증 기준도 미리 정했습니다.
- 중요한 일정 누락 없음
- 방해 금지 상황의 불필요한 알림 없음
- 승인 없는 수정·발송·이동·삭제 없음
- 확인되지 않은 내용을 사실처럼 말하지 않음
- 사용자가 실제로 실행할 수 있는 분량만 제안
스터디 초반에는 “언젠가 이런 개인 비서를 만들고 싶다”는 계획이었다면, 마지막에는 그 계획을 실제 파일과 규칙으로 옮겼어요. 이제부터는 데비가 작은 업무 하나를 안정적으로 수행할 수 있는지 직접 테스트하면서, 계획 속 반려 에이전트를 믿고 맡길 수 있는 개인 비서로 만들어가려고 합니다.
## 도움 받은 글 (옵션)
- 지피터스 23기 사례글 작성 템플릿 — 소개, 진행 방법, 프롬프트, 결과와 배운 점을 구성하는 데 참고
- 에이전트 하네스 스터디 자료 — Context, Memory, Tool, Skill, 승인 경계와 검증 구조를 설계하는 데 참고
- 이전 데비 사례글 — 초기 Hermes·텔레그램 설정과 이번 하네스 구조를 비교하는 기준으로 활용
- Codex와 진행한 설계 대화 — 질문을 통해 역할, 경계, 반복 업무와 검증 기준을 구체화하는 데 활용
