Back to all posts
Hermes

02 프로필과 조직 구성

02 프로필과 조직 구성의 핵심 흐름과 적용 방법을 정리한 글입니다.

2026년 07월 31일6분

📗 02 프로필과 조직 구성

목적

Hermes의 profile을 단순한 캐릭터 변경이 아니라 역할·권한·기억·세션·도구·메신저 연결이 분리된 회사 직원 단위로 사용하게 된 과정을 설명한다.

profile을 직원 단위로 선택한 이유

단테랩스 자료에서는 첫 직원의 SOUL.md를 만들고, 이후 profile을 복제해 여러 직원을 구성하는 흐름을 제시한다. 우리 서버도 이 개념을 출발점으로 삼았지만 직원 이름과 역할은 Littleducks's Company의 실제 AX 업무에 맞게 다시 설계했다.

profile 하나가 분리하는 대상은 다음과 같다.

profile
├─ config.yaml       모델·도구·실행 설정
├─ .env              profile별 비밀정보
├─ SOUL.md           역할·책임·말투·금지사항
├─ profile.yaml      description과 alias 정보
├─ skills/           profile 전용 절차
├─ memories/         장기 기억
├─ state.db          세션 상태
└─ gateway service   Slack 등 외부 채널 연결

다만 terminal backend가 local이므로 profile끼리 같은 Linux 사용자와 파일 시스템을 공유한다. 따라서 profile은 운영상 역할 분리에는 유효하지만 강한 보안 경계는 아니다.

구축 타임라인

시점 변화
2026-06-23 default Hermes 환경 설치
2026-06-27 개인 비서 성격의 lipa profile 생성
2026-07-23 회사 전략·조정 역할의 lisa profile 생성
2026-07-24 회사 채용 계획서에 따라 직원 profile 9개 생성
2026-07-31 Lisa–Frink 기술 delivery 경계와 콘텐츠 책임 구조 보강
2026-07-31 12개 profile 환경에 shared skills 단일 정본 연결 검증

2026-07-24에 거의 같은 시각으로 생성된 profile directory의 birth time과 회사 채용 기록을 대조하면 Martin부터 Smithers까지의 회사 profile이 한 작업 단위로 provisioning된 것을 확인할 수 있다.

현재 profile 구성

profile id 역할 기본 모델 현재 Gateway
default 시스템 기본 profile gpt-5.6-sol-pro stopped
lipa 개인 비서·운영 지원 gpt-5.5 running
lisa 전략기획·리서치·업무 배정 gpt-5.6-sol running
martin 데이터분석·수치 검증 gpt-5.6-sol running
marge 기획·운영·프로젝트 조정 gpt-5.6-sol running
bart 카피·대외 가독성 편집 gpt-5.6-sol running
maggie 디자인·브랜드 정보구조 gpt-5.6-sol running
frink 기술책임·AI 아키텍처·release gpt-5.6-sol running
comicbookguy 백엔드·플랫폼 개발 gpt-5.6-sol running
database 자동화·시스템 연동 gpt-5.6-sol running
milhouse 프론트엔드·QA gpt-5.6-sol stopped
smithers 총무·경영지원 gpt-5.6-sol stopped

Gateway 상태는 2026-07-31 hermes profile list의 실제 조회값이다. Milhouse와 Smithers는 내부 profile로 유지하되 Slack 상주 인력에서 제외했다.

profile 생성 방식

현재 CLI에서 재현 가능한 기본 형태는 다음과 같다.

hermes profile create <profile-id> --clone-from default
hermes profile describe <profile-id> --text "역할 설명"
hermes profile alias <profile-id>
hermes profile show <profile-id>

우리 구성에서는 profile을 만든 뒤 다음 항목을 별도로 확정했다.

  1. 회사 채용 계획서의 역할과 권한을 SOUL.md에 반영한다.
  2. Kanban과 업무 라우팅에 쓰일 간결한 description을 profile.yaml에 저장한다.
  3. 역할별 필수 도구는 켜고 승인되지 않은 특수 도구는 끈다.
  4. model과 provider를 검증한다.
  5. 공용 skill root를 연결한다.
  6. 외부 채널이 필요한 직원만 Gateway를 설치한다.
  7. 새 세션에서 역할·금지사항·책임 경계가 실제 답변에 반영되는지 검사한다.

SOUL.md에 들어간 내용

단테랩스의 Identity / Style / Avoid / Defaults 구분은 페르소나 설계의 기초로 참고했다. 회사 profile은 여기에 업무 책임, 협업 경계, 승인 조건, 보안 기준을 더했다.

Professor Frink를 예로 들면 다음 내용을 명시한다.

  • AI architecture, model selection, agent design, security와 비용 검토
  • Comic Book Guy·Database·Milhouse의 구현 결과 통합
  • 테스트, 보안, 회귀, 운영 준비 상태를 근거로 기술 완료 판단
  • commit, push, PR, review 대응과 release 기록 책임
  • 대표가 승인한 범위에서만 배포 실행
  • 운영 배포를 단독 승인하지 않음
  • blocker가 남아 있으면 완료로 보고하지 않음

Lisa는 반대로 사업 목적, 요구사항, 완료 조건, 우선순위와 사업 승인을 담당하고 개발 구현·Git delivery·직접 배포를 하지 않도록 경계를 뒀다. 이 구분으로 전략 승인과 기술 release 책임을 한 profile에 몰지 않았다.

profile description의 역할

SOUL.md는 해당 직원이 어떻게 행동할지를 정하고, profile description은 어떤 업무를 그 직원에게 배정할지 결정하는 짧은 라우팅 정보다.

예를 들면 현재 description은 다음처럼 역할을 구분한다.

  • Lisa: 기술 트렌드·시장 분석과 업무 분류, 기술 delivery는 Frink에게 위임
  • Frink: AI 기술·아키텍처 글과 기술 통합·release
  • Comic Book Guy: API·backend·DB·인증·권한·로그·복구
  • Database: 업무 자동화와 외부 시스템 연동
  • Milhouse: 사용자 화면·접근성·테스트·품질관리
  • Bart: 대외 글 구성과 가독성
  • Martin: 중요한 수치·계산·가격·성과 검증

profile을 만들기만 하고 description을 비워두면 멀티 에이전트 배정 시 역할을 안정적으로 구분하기 어렵다.

model과 공통 설정

현재 회사 profile의 공통 기반은 다음과 같다.

provider: openai-codex
terminal.backend: local
approvals.mode: manual
security.redact_secrets: true
memory.memory_enabled: true
skills.external_dirs:
  - /home/littleduck/.hermes/shared-skills

default는 고연산 gpt-5.6-sol-pro를 사용하지만 일반 직원은 gpt-5.6-sol로 맞췄다. 이는 모든 작업을 최고 연산 모델로 처리하기보다 일반 실행과 기준 profile을 구분한 구성이다.

skill 구조

공용 절차를 각 직원 폴더에 복사하면 버전이 갈라진다. 이를 피하기 위해 회사 공용 skill은 다음 단일 정본에 둔다.

/home/littleduck/.hermes/shared-skills/<skill-name>/

profile 전용 skill만 다음 위치에 둔다.

/home/littleduck/.hermes/profiles/<profile-id>/skills/

모든 profile이 공용 root를 추가 검색하지만 같은 이름의 local skill이 있으면 local copy가 우선한다. 따라서 공용 skill과 같은 이름의 profile-local copy를 만들지 않는 것이 원칙이다.

profile 선택과 실행

hermes -p frink
frink
hermes profile use frink
hermes profile show frink
  • -p <id>: 해당 호출에서 profile 지정
  • alias: frink, lisa처럼 profile별 wrapper 실행
  • profile use: 기본 profile을 고정
  • profile show: model, path, Gateway, SOUL과 alias 존재 확인

현재 Dashboard는 machine-level unified server이므로 named profile에서 실행해도 기본적으로 하나의 Dashboard에 연결되고 선택한 profile만 바뀐다. 별도 server가 필요할 때만 --isolated를 사용한다.

검증 방식

profile 구성 완료는 파일 존재만으로 판단하지 않았다.

1. profile show로 path·model·Gateway·SOUL 확인
2. profile describe로 routing description read-back
3. config get으로 provider·model·security·memory 확인
4. skills list 또는 skill_view로 공용 skill 로딩 확인
5. 새 profile session에서 역할 질문 실행
6. 금지된 업무나 역할 경계 질문으로 행동 검증
7. 외부 채널 대상 profile은 Gateway와 Slack 응답 확인

새 세션 검증이 중요한 이유는 이미 시작된 session에는 이전 SOUL.md가 주입되어 있을 수 있기 때문이다.

사실과 해석

사실

  • 현재 default 포함 12개 profile 환경이 존재한다.
  • 각 named profile에는 독립된 path, config, .env, SOUL, memory와 session DB가 있다.
  • 12개 환경 모두 shared skills root를 검색한다.
  • 회사 profile 대부분은 OpenAI Codex의 gpt-5.6-sol을 사용한다.
  • 9개 profile Gateway가 running이며 3개는 stopped다.

해석

역할별 profile은 한 명의 범용 agent에게 모든 책임을 주는 것보다 업무 배정과 결과 검증에 유리하다. 그러나 profile 수가 늘수록 credential, Gateway, skill version과 역할 중복을 관리해야 한다. 직원 수를 늘리는 것 자체가 성과가 아니며 실제 반복 업무와 완료 기준이 있는 역할만 상주시키는 편이 낫다.

결정사항

  • profile id는 영문 소문자를 사용한다.
  • 직원별 역할 정본은 SOUL.md, 업무 라우팅 요약은 description에 둔다.
  • 공용 skill은 shared root의 단일 정본으로 관리한다.
  • profile별 model·도구·Gateway는 역할과 실제 수요를 기준으로 설정한다.
  • 외부 작업과 비가역 변경에는 승인 경계를 명시한다.
  • profile 생성 후 새 session에서 역할과 금지사항을 검증한다.

미결정 사항

  • 고객별 profile을 같은 VM에 둘 수 있는 보안등급의 한계
  • profile별 예산·사용량 상한과 model fallback 정책
  • Milhouse와 Smithers의 Slack 상주 전환 조건
  • 정기 profile drift 점검 주기

다음 담당자

  • 조직·요구사항·채용 승인: Lisa·대표
  • 기술 profile 통합·검증: Professor Frink
  • role별 구현·운영: 각 전문 profile

출처