JYP Garden Internal

5인 회사 운영하며 직접 헤르메스 에이전트 720시간 돌려본 후기 (feat. Slack, Hostinger)

Properties1
tagsyoutube, ai, ax, agentic-ai, company-operations

9 min read

5인 회사 운영하며 직접 헤르메스 에이전트 720시간 돌려본 후기 (feat. Slack, Hostinger)

YouTube 관심 채널 번들로 수집된 자료를 OMW 지식화 문서로 재정리한 노트. 전사 원문은 Raw 문서에 보존하고, 이 문서는 JYP Labs 적용 관점의 요약·판단·후속 액션만 남긴다.

핵심 메타데이터

한 줄 요약

소규모 AX 조직이 Hermes Agent를 Slack 중심 업무 OS로 붙여 한 달 운영하며, 회의록·메일·데일리 태스크·SOP·사내 도구 개발까지 “AI를 팀원으로 쓰는 방식”을 실험한 사례다.

핵심 주장

  1. 공용 AI 에이전트는 ChatGPT형 질의응답 도구가 아니라 조직 운영 레이어다.
    영상은 Hermes Agent를 단순 챗봇이 아니라 Slack 안에 상주하는 팀원으로 배치하고, 매일의 업무·회의·메일·문서 흐름을 읽게 만드는 방식에 초점을 둔다.

  2. AI Native Company의 출발점은 모델 성능보다 맥락 수집 구조다.
    회의록, 이메일, Slack 대화, 스탠드업, Notion/Obsidian 문서, GitHub 기록을 한곳에 적재해야 에이전트가 조직의 현재 상태를 이해할 수 있다고 본다.

  3. Raw 데이터만 쌓으면 부족하고, 압축된 SOP/LLM Wiki가 필요하다.
    발표자는 안드레 카파시의 LLM Wiki 개념을 빌려, 원본 소스 → 압축 문서 → SOP/위키 → 질의·판단·실행의 구조가 토큰 효율성과 거버넌스에 중요하다고 설명한다.

  4. 업무 자동화는 승인 루프와 함께 설계해야 한다.
    메일 답장, 견적서, 세금계산서, 외부 커뮤니케이션, 계약성 판단은 초안·제안까지는 AI가 하되 최종 승인과 책임은 사람이 가져야 한다는 한계도 함께 언급한다.

  5. 팀원별 AI 리터러시 편차는 공개 사용 문화와 반복 피드백으로 줄인다.
    에이전트와의 대화를 공개 채널에 남기고, 매일 피드백을 주며, 에이전트가 할 일과 사람이 할 일을 계속 구분하는 것이 조직 적응의 핵심으로 제시된다.

사례 구조

1. 설치·운영 환경

  • Mac mini 로컬 설치는 개인 실험에는 적합하지만, 공용 운영 환경으로는 업데이트·전원·보안·관리 이슈가 있다고 평가한다.
  • VPS/서버형 운영은 24시간 가동, 중앙 관리, 공용 Slack 연동 측면에서 더 적합하다고 주장한다.
  • 단, 영상에는 Hostinger 할인 링크가 포함되어 있어 인프라 추천 부분은 상업적 맥락을 감안해야 한다.

2. 맥락 수집 레이어

  • 회의록 서비스/녹음 장치/Zapier/Slack/Obsidian/GitHub를 연결해 조직 활동을 Markdown과 서버 저장소에 적재한다.
  • 데일리 스탠드업, 출퇴근 기록, 이메일 문의, 팀 대화가 에이전트의 읽기 대상이 된다.
  • 핵심은 “AI가 읽을 수 있는 형식으로 조직의 흔적을 남기는 문화”다.

3. 조직의 뇌: SOP와 LLM Wiki

  • 매일 SOP를 갱신하고, 회의록·문서·프로젝트 정보를 압축된 문서로 관리한다.
  • 원본 전체를 매번 읽히는 방식이 아니라, AI가 먼저 참조할 수 있는 요약·색인·업무 기준을 만든다.
  • 이는 JYP Labs의 jyp-garden/OMW 운영 철학과 거의 같은 방향이다.

4. 실행 업무

  • 데일리 태스크 제안과 리스크 브리핑
  • 메일 분류와 답장 초안 작성
  • 회사 소개서·PPT·HTML 페이지 등 산출물 생성
  • 사내 ERP/견적서/세금계산서 등 내부 도구 개발 보조
  • 팀원별 업무 아이디어 리뷰, 프로젝트 관리 기능 추가, 개발자 스탠드업 기록

5. 한계와 리스크

  • 계약, 견적, 외부 커뮤니케이션, 고객 정보 처리에는 사람 검수가 필요하다.
  • 토큰 사용량은 예측하기 어렵다.
  • 팀원별 AI 활용 역량 차이가 존재한다.
  • 데이터 거버넌스·보안 담당자 또는 담당 에이전트가 필요하다.
  • 고객사 정보와 민감 정보를 무분별하게 적재하지 않는 가드레일이 중요하다.

JYP Labs 적용점

유지할 방향

  • Sophie/Hermes를 Slack 안의 공용 운영 레이어로 두는 방향은 유효하다.
  • OMW jyp-garden을 Raw 보관소가 아니라 압축 지식·SOP·프로젝트 판단 기준으로 쓰는 방향이 맞다.
  • 아침 브리핑, 메일 라우팅, Google Tasks 승인 루프, 회의록 액션 추출은 이 영상의 성공 사례와 일치한다.

보완할 점

  • YouTube/LinkedIn/메일 수집 결과가 지금처럼 전사 원문만 wiki/sources/에 남으면 LLM Wiki의 가치가 떨어진다.
  • Raw는 raw/에 두고, wiki/sources/에는 반드시 다음이 있어야 한다.
    • 핵심 주장
    • JYP Labs 적용점
    • 리스크와 확인 필요 사항
    • 후속 액션 후보
    • 기존 개념/프로젝트 문서 연결
  • 반복 수집 시 wiki/log.md 중복 기록을 방지해야 한다.
  • AppleDouble ._*.md 사이드카 파일은 OMW lint를 깨뜨리므로 vault 동기화/백업 단계에서 제외해야 한다.

후속 액션 후보

  1. OMW ingest 품질 기준 강화
    YouTube 관심 채널 수집 파이프라인에서 wiki/sources/ 저장 시 전사 전문을 붙이지 않고, Raw 링크 + 요약/적용점/액션 구조를 강제한다.

  2. Sophie cron 산출물 검증 루프 추가
    수집 후 omw fields <relpath>와 touched-file lint를 돌려 type, date, tags, visibility, confidence 누락을 잡는다.

  3. AI Work OS 운영표준 문서에 반영
    이 영상의 “맥락 수집 → 압축 위키 → 실행 에이전트 → 승인 루프” 구조를 JYP Labs 운영표준의 참고 사례로 연결한다.

  4. 보안·거버넌스 체크리스트 별도화
    고객사 정보, 계약/견적, 외부 발송, 개인 정보는 에이전트가 초안까지만 처리하고 승인권은 사람에게 남기는 원칙을 문서화한다.

관련 문서 연결

확인 필요

  • 영상 발화에는 자동 전사 오류가 일부 있다. 예: 헤르메스/해르메스/헬멧스, 적재/적제, G스텍/G브레인 등은 맥락상 해석해 정리했다.
  • Hostinger 관련 내용은 영상 내 광고/제휴 맥락이 있으므로 JYP Labs 인프라 의사결정 근거로 직접 쓰지는 않는다.
  • 발표자의 실제 내부 구현 상세는 화면·발화 기준이며, 재현 가능성은 별도 검증이 필요하다.

그래프 뷰

백링크