독핏 인프라 지도 — 내부용

정본 = 03_설계/인프라_통합_정책.md · 2026-09-19 밤(v2.8 — 배포 repo dogfit-ops · 리더/오퍼레이션 이름 · 엔진 v0.21.3 · 컨테이너 경로 /opt/data · 채널 9 체계)

① 업무 데이터 흐름

② 배포 흐름 (2026-09-19 R430 — 배포 repo dogfit-ops 미러 구조)

③ 스테이징·프로덕션 구성과 계정 권한

🔒 서버 1대 · 그 위 Docker가 컨테이너 2개. 컨테이너끼리는 격리 — 상대 환경에 손댈 수 없다(④). 서버를 또 가르는 것은 외부 고객용이 생길 때(⑦).

현재 STG 출처는 오픈 뒤에도 그대로 유지한다(Hana 2026-09-15). 후임이 오면 조직 repo 또는 개인 repo를 선택한다. PRD 배포 연결은 실제 운영 전에 결정하며, 개인 main의 모든 변경을 운영에 자동 배포하지 않는다. 웹 주소는 결정됐지만 확보·연결은 미검증이다.

이전 실측 기록 (2026-08-30 당시, 현재 상태 재확인 필요)

④ 컨테이너를 두 개로 가른다 — 스테이징과 프로덕션 (✅ Hana 확정 2026-08-29)

지금 (컨테이너 1개)                          바꾸면 (컨테이너 2개)
┌─ hermes ─────────────────┐            ┌─ hermes-stg ────┐  ┌─ hermes-prd ────┐
│  workspaces               │            │ workspaces      │  │ workspaces      │
│    ├ dogfit-stg  ←┐       │            │   └ dogfit(스테이징)│  │   └ dogfit(운영) │
│    └ dogfit-prd  ←┘ 서로   │            │ 데이터(STG)      │  │ 데이터(PRD)      │
│         보이고 써진다       │            └─────────────────┘  └─────────────────┘
└───────────────────────────┘                    상대 폴더는 아예 존재하지 않는다

그래서 「테스트 버전 스크립트」는 이렇게 간다

Hana 개인 dogfit-staging/main →(deploy_runtime.sh 미러)→ dogfit-ops main → hermes-stg /opt/data/workspaces/dogfit-ops/
검증 SHA · digest · 마이그레이션 → Hana 승인 태그 → hermes-prd /opt/data/workspaces/dogfit-ops/ (같은 배포 repo · 태그로 판을 가른다)
2026-09-19 R430 정정(구 /home/hermes/workspaces/dogfit/ — 이 이미지엔 /home/hermes가 없고 홈 = /opt/data). 태그 규칙은 운영 시작 전 확정. 상대 컨테이너 볼륨은 마운트하지 않는다.

실측  HERMES_WRITE_SAFE_ROOT=/opt/data:/home/hermes/workspaces      ← 쓰기 허용 = workspaces 전체
      이 값은 컨테이너 환경변수 하나 → 프로필별로 좁힐 수 없다

⑤ default = 리더(운영 총괄 역할) — 컨테이너마다 1명, 그래서 2명 (✅ Hana 확정 2026-08-30 · 이름 「리더」 = 2026-09-17 R396)

각 컨테이너의 default 프로필이 그 환경의 리더다(역할 = 운영 총괄 · 슬랙 앱 「리더」/「리더-TEST」 · handle leader · 폴더명 default 유지 · 2026-09-19 서버 반영). 아래는 이전 명칭의 근거다. 과거 Hana 원문: "프로덕션 총괄은 스테이징의 CTO, 프로덕션은 CTO가 있는 거야. AI CTO."

 🧪 스테이징(STG) 컨테이너                    🚀 프로덕션(PRD) 컨테이너
┌──────────────────────┐             ┌──────────────────────┐
│ default = STG 총괄    │             │ default = PRD 총괄    │
│  「STG 리더·총괄」    │             │  「PRD 리더·총괄」      │
│ ···················· │             │ ···················· │
│ hotel-stg            │             │ hotel-prd            │
│ daycare-stg          │             │ daycare-prd          │
│ class-stg            │             │ class-prd            │
│ operations-stg       │             │ operations-prd       │
└──────────────────────┘             └──────────────────────┘
       프로필 5명                          프로필 5명   = 합계 10명
           │                                   ▲
           └── 「정의」만 승격 (코드·스킬·설정) ──┘
               ⛔ 기억·자격증명은 어느 것도 안 넘어간다

총괄이 하는 일 — 네 가지

⚠️ 이건 2026-08-28 판의 변경이다

왜 갈렸나 — 위험이 무서워서가 아니다

순서를 헷갈리지 않는다. 먼저 정해진 것은 「컨테이너를 2개로 가른다」(④)이고, 총괄이 갈린 것은 그 귀결이다.

• 프로필은 컨테이너 안의 /opt/data/profiles/<이름>/에 산다(⑥). 컨테이너를 가르면 한 프로필이 두 컨테이너에 동시에 있을 수 없다.
• 억지로 유지하려면 총괄을 한쪽 컨테이너에 두고 반대편 워크스페이스 열쇠까지 들려야 하는데, 그건 방금 세운 담을 그 프로필 하나로 다시 뚫는 것이다.
• 남은 선택은 「어느 한쪽에만 둔다」와 「각 컨테이너에 하나씩」이었고, Hana가 후자를 골랐다 — 두 환경이 하는 일이 다르므로 역할도 다르다는 이유로.

⑥ 컨테이너에 「올라가는 것」은 층이 셋이다 (Hana 개인 VPS 실측 2026-08-28)

앞선 판은 "스테이징에 올린다"를 한 덩어리로 적어서 무엇이 어떻게 올라가는지 구분이 없었다. 이미 돌고 있는 Hana 개인 VPS에서 재서 확인했다.

실측한 것 (값은 안 봤다 — 경로·존재·개수만)

컨테이너      hermes | hermes-agent:v2026.6.19-hana2 | Up 5 weeks    ← 1개
엔진          /opt/hermes · Hermes Agent v0.17.0                     ← 1개, 전 프로필 공유

terminal.cwd  default → /home/hermes/workspaces/her                  ← ⭐ 프로필마다
              dot     → /home/hermes/workspaces/dot                     다른 폴더!
              kan     → /home/hermes/workspaces/kan

repo clone    workspaces/ 안에 hana-brain · hana-brain-cron
              · project-context                                       ← 같은 repo 2번 clone 실증

skills        /opt/data/skills(전역) + /opt/data/profiles/dot/skills   ← 프로필별로 따로
.env          /opt/data/.env 495줄 · dot 11줄 · kan 18줄              ← 프로필마다 다른 파일

⑦ 언제 컨테이너를 또 가르나 — 기준은 「누가 말을 거는가」

프로필은 담이 아니라 서랍이다. 진짜로 막아야 하면 프로필이 아니라 컨테이너를 가른다. 스테이징↔운영이 그 첫 적용(④)이었고, 다음 경계는 이것이다.

같은 기준이 민감 정보 전담 프로필(예: 인사·평가)에도 적용된다. 순서는 ① 대화 상대를 제한한다(직원 채널에 안 붙인다 — 1차 방어선) ② 필요하면 컨테이너를 가른다(2차). ⏳ 예약 앱은 미도입이라 이 절은 원칙이고 시점은 아직이다.

⑧ Slack 앱은 몇 개인가 — 앱 · 설치 · 봇은 서로 다른 것

Hana 질문이 여기 다 걸려 있어서 말 세 개부터 가른다.

그래서 몇 개인가

총괄 앱과 총괄 프로필은 「같은 결정」이다 — 고를 수 있는 게 아니다

Hermes 문서에 이 줄이 있다: "목록의 첫 번째 토큰이 primary이고, Socket Mode 연결에 쓰인다." → Slack과의 실시간 연결선은 「앱」 하나당 하나만 열린다. 그래서 앱 개수를 정하면 프로필 개수가 따라오고, 반대도 같다.

  총괄 앱 1장을 두 방에            총괄 앱 2장 (방마다 하나)
 ┌──────────────┐                ┌────────┐   ┌────────┐
 │  앱 1장       │                │ 앱 A    │   │ 앱 B    │
 └──┬────────┬──┘                └───┬────┘   └───┬────┘
    │        │                       │            │
  스테이징    운영                     스테이징        운영
  연결선 1개가 양쪽 말을 다 받음      각자 자기 연결선 · 게이트웨이 2개
  = 총괄 프로필 1명                  = 총괄 프로필 2명
  ~~2026-08-28까지 이쪽~~            ✅ 2026-08-30부터 이쪽

총괄을 「STG 리더 · PRD 리더」로 갈랐으니(⑤) 앱도 2장이 된다(STG 앱 이름 = 리더-TEST · 2026-09-19). 물리가 그렇게 묶여 있어서 따로 고를 여지가 없다.

⑨ 테스트는 세 겹이다 — 슬랙은 마지막 관문

앞선 판은 검증을 슬랙에서 사람이 해보는 것만 적었다. Hana 지적: "어떻게 다 슬랙에서 테스트하니? 슬랙에서 테스트는 최종으로 하는 거고." 맞다.

# 프로필을 지정해 한 번만 실행 (비대화형 · 슬랙 없이)
docker exec hermes-stg hermes -p hotel-stg chat -q "<케이스 문장>" --max-turns 3

⑩ 엔진 — 말풀이, 그리고 언제 새 판을 받나

git ls-remote --tags .../NousResearch/hermes-agent      (2026-08-28 조회)

v2026.6.19  v2026.7.1  v2026.7.7  v2026.7.7.2  v2026.7.20  v2026.7.30
v2026.8.3   v2026.8.13 v2026.8.16 v2026.8.16.2 v2026.8.18  v2026.8.19  v2026.8.27
                                                                        ↑ 어제

→ 69일간 13건 · 평균 5.8일에 1건 · 8월만 7건

그래서 진짜 질문은 「언제 받을 것인가」다

✅ 엔진에도 「스테이징 먼저」가 통한다 (2026-08-30 갱신 — 컨테이너 2개로 풀렸다)

새 엔진 판이 나옴
   │
   ▼
1. 컨테이너 hermes-stg에만 새 이미지 태그로 올린다   ← ⭐ 여기가 엔진의 「스테이징」이다
   프로덕션 컨테이너는 옛 지문 그대로 돈다                     (compose에서 서비스별로 태그를 달리 준다)
   │
   ▼
2. CLI 케이스 전수 + 테스트 슬랙 여정 재검증
   │
   ▼
3. 통과하면 같은 지문을 hermes-prd에 준다             ← 다시 build 하지 않는다
   │
   ▼
4. 이상하면 직전 설계도로 되돌린다                        ← 이전 이미지를 지우지 않고 남겨 둔다

⑪ 배포 사고는 사람이 아니라 기계가 막는다 (2026-08-28 · Hana 지시)

Hana는 개인 봇을 디스코드로, 독핏 봇을 슬랙으로 쓰기 때문에 사람 쪽에서 축을 헷갈릴 위험은 낮다. 틀릴 위험이 큰 쪽은 에이전트가 배포·마이그레이션을 실행할 때다. 그래서 확인을 사람 눈이 아니라 스크립트에 박는다.

⑫ 문제가 생기면 — 되짚는 순서

  1. 증거 고정        시각 · 채널/스레드 · 누가 · 입력 · 기대 · 실제 · 그때의「판」
        │            ⚠️ 바로 재시작부터 하지 않는다 — 재시작하면 증거가 사라진다
        ▼
  2. 어디가 고장인지   Slack 앱·토큰 / Hermes 프로필 / 도구 / Supabase /
        │            드라이브 / Cloudflare / 티피 / 지식 위키
        ▼
  3. 읽기만 하는 점검  게이트웨이 살아 있나 · 로그 · 지금 도는 판 · DB 환경 표시 · 외부 API
        │            ← 고치기 전에 본다
        ▼
  4. 스테이징에서 재현   가짜 데이터로 같은 일을 일으켜 본다
        │            ⚠️ 실고객 데이터를 스테이징로 복사하지 않는다
        │            재현 안 되면「원인 미확인」으로 둔다 — 그럴듯한 원인을 고르지 않는다
        ▼
  5. 자산별로 되돌림   아래 표
        ▼
  6. 같은 여정 재검증  고쳤으면 ⑨(테스트 3종)·②(배포 흐름)를 다시 밟는다

장애 알림은 어느 워크스페이스로 오나 (2026-08-28 Hana 결정)

⑬ 지식 위키(LLM 위키) — 코드와 같은 repo 안에 산다

⑭ GitHub·후임자 인계

⑮ 판 사이트 — 위와 별개 축

⑯ 아직 안 닫힌 것

이번 Claude 검토 요청