사람이 보던 운영 표면을 AI도 보게 만들기

1. AI 에이전트에서 먼저 필요한 것은 더 똑똑한 모델이 아닙니다

AI 에이전트를 운영하면서 가장 강하게 느낀 점은 단순합니다. 모델이 얼마나 똑똑한가보다 먼저, 모델이 무엇을 볼 수 있는가가 중요합니다.

사람은 운영할 때 여러 화면을 동시에 봅니다. 슬랙 대화, GitHub PR과 CI, Grafana 대시보드, Sentry 오류, 서버 로그와 systemd 상태, 광고 계정과 GA4, 고객 메일과 통화 녹취를 오갑니다. 그 표면들을 오가면서 “지금 무슨 일이 벌어지고 있는지”를 판단합니다.

AI 에이전트에게 같은 화면과 기록이 없으면, 아무리 좋은 모델을 붙여도 결국 추측하는 비서가 됩니다. “아마 됐을 것이다”, “문제가 없을 것이다”, “이런 방향이면 좋을 것이다” 같은 말은 할 수 있지만, 실제 운영자가 기대하는 수준의 판단은 하기 어렵습니다.

Hermes 주변에 만든 수많은 루프의 공통점은 여기에 있습니다. 서버, 코드, 실행 에이전트, 로그, 웹훅, 오류 추적, 비밀값, 음성 기록, 광고 신호, 기억 관리, 레포 운영이 모두 하나의 질문으로 정리됩니다. 사람이 보던 것을 AI도 보게 만들 수 있는가, 그리고 AI가 한 일을 사람이 다시 확인할 수 있는가입니다.

2. 함께 보는 운영 표면이라는 기준

이 구조를 설명하는 말은 “사람과 AI가 함께 보는 운영 표면”입니다. 사람과 AI가 같은 현장을 본다는 뜻입니다. 여기서 “같다”는 말은 모든 비밀값과 원본 데이터를 모델에게 그대로 넣는다는 뜻이 아닙니다. 오히려 반대입니다.

같은 표면이란 다음 조건을 만족하는 표면입니다.

• 사람이 보는 상태가 AI에게도 API, 파일, 로그, 대시보드, 슬랙 스레드, 작업 기록, 결과물 형태로 노출되어 있습니다.
• AI가 한 행동이 사람이 다시 읽을 수 있는 결과물로 남습니다.
• 이벤트의 원인, 판단, 다음 행동이 한 표면에서 추적됩니다.
• 비밀값, 개인정보 원본, 운영 환경 변경 권한은 숨기되 상태와 근거는 드러납니다.
• 정상 상태는 조용하고, 실패·위험·결정이 필요한 상태만 사람에게 올라옵니다.

이 기준은 자동화를 더 공격적으로 만들기 위한 것이 아닙니다. 오히려 자동화를 안전하게 만들기 위한 기준입니다. AI가 무엇을 봤는지, 무엇을 근거로 판단했는지, 어디까지 실행했고 어디서 멈췄는지를 사람이 추적할 수 있어야 하기 때문입니다.

3. 처음 보는 사람에게 설명하면

패스트캠퍼스에서 AI 에이전트를 설명할 때도 결국 같은 방식이 가장 잘 통했습니다. “AI가 알아서 다 한다”로 시작하면 듣는 사람은 바로 막힙니다. 대신 이렇게 설명하는 편이 쉽습니다.

그래서 이 글은 “우리도 AI 에이전트를 붙일 수 있을까?”라는 질문에 대한 답이기도 합니다. 먼저 모델을 고르는 것이 아니라, 우리 조직의 운영 표면이 얼마나 정리되어 있는지를 봐야 합니다. 에이전트는 그 다음입니다.

4. 운영 표면 평가 계약

진단 브리프는 조직의 운영 표면을 평가하기 위한 최소 계약이다. 모델 추천보다 먼저 사람이 실제로 보는 표면, 에이전트가 안전하게 읽을 수 있는 근거, 깨우는 사건, 완료 증거, 멈춤 조건을 대조한다.

Agent task:
1. List the human operational surfaces:
   - chat/thread surface
   - source code and pull request surface
   - CI/deployment surface
   - logs, metrics, dashboards, alerts
   - error tracking
   - secrets and configuration
   - customer/support/email/voice evidence
   - task/project tracking
   - business/growth dashboards

2. For each surface, answer:
   - What does a human see?
   - What can an AI agent read without exposing secrets?
   - What event should wake the agent?
   - What artifact proves the agent acted correctly?
   - When must the agent stop and ask a human?

3. Score maturity:
   0 = human-only, no agent-readable surface
   1 = agent can read screenshots or copied text only
   2 = agent can read logs/files/API manually when asked
   3 = important events wake the agent automatically
   4 = agent acts, records evidence, and respects approval gates

4. Produce a setup plan:
   - first surface to expose
   - safest webhook to add
   - smallest evidence artifact
   - approval gates
   - monitoring and rollback plan

Rules:
- Never ask for raw secrets.
- Do not recommend autonomous production changes before observability exists.
- Treat worker self-reports as untrusted until verified by primary evidence.
- Prefer event-driven triggers over polling.
- Keep normal states silent; surface blockers and decisions.

5. 전체 아키텍처

현재 구조를 크게 보면 슬랙이 운영 표면이고, Hermes Joe가 판단 계층이며, Codex·Happy·Kanban이 실행 계층입니다. Grafana·Loki·Sentry·Webhook은 외부 상태를 AI가 볼 수 있는 사건과 로그로 바꿉니다. Infisical은 비밀값을 숨긴 채 실행 권한만 주는 계층입니다. Voice Memory와 Hindsight는 사람이 말하고 들었던 것을 나중에 다시 찾을 수 있는 근거 포인터로 바꾸는 기억 계층입니다.

flowchart TB
  Joon[Joon / 운영자] --> Slack[슬랙
대화·결정·결과 보고]
  Slack --> Hermes[Hermes Joe
맥락 파악·판단·조율]

  Hermes --> Memory[Hermes Memory
작고 안정적인 진입점]
  Hermes --> Hindsight[Hindsight
의미 기반 기억 검색]
  Hermes --> Sessions[Session Search
과거 대화와 결정]
  Hermes --> Skills[Skills / Runbooks
반복 가능한 절차]

  Hermes --> Kanban[Hermes Kanban
작업 상태와 실행 기록]
  Kanban --> Pieter[Pieter
개발 판단]
  Kanban --> Tim[Tim
운영 판단]
  Kanban --> Workers[Worker Profiles
분리된 작업자]

  Hermes --> Codex[Codex CLI
코드 수정 lane]
  Hermes --> Happy[Happy
원격 코딩 lane]

  Codex --> Git[Git / GitHub / CI]
  Happy --> Git
  Git --> Webhooks[웹훅 / CI 사건]
  Webhooks --> Hermes

  Sentry[Sentry 오류] --> EventHub[이벤트 허브
서명 검증·중복 제거]
  EventHub --> Kanban
  EventHub --> Slack

  Servers[PVE / 서버 / Docker / systemd] --> Promtail[Promtail]
  Promtail --> Loki[DSM Loki]
  Loki --> Grafana[DSM Grafana]
  Grafana --> Alerts[Grafana 알림]
  Alerts --> Hermes

  Secrets[Infisical
비밀값 이름·범위·주입] --> Hermes
  Secrets --> Codex

  Voice[Voice Memory
녹음·전사·작업 문서] --> Hermes
  Voice --> Hindsight

  Ads[Meta 광고 / GA4 / Gmail 알림] --> Hermes
  Hermes --> Slack
  Slack --> Joon

모든 것이 Hermes로 들어오지만, Hermes가 모든 것을 혼자 처리하지는 않습니다. Hermes는 맥락과 판단을 맡습니다. 코드 실행은 Codex와 Happy 작업 lane으로 넘깁니다. 지속 상태는 Kanban에 남깁니다. 운영 상태는 Grafana, Loki, Sentry에서 봅니다. 비밀값은 Infisical에서 필요한 순간에만 주입합니다. 과거 맥락은 Memory, Skills, Session Search, Hindsight 같은 기억 계층으로 나눕니다.

6. 슬랙은 채팅창이 아니라 운영 표면입니다

슬랙은 이 시스템의 가장 바깥쪽 표면입니다. 일반적인 챗봇처럼 “질문하면 답하는 곳”이 아니라, 작업 요청, 의사결정, 결과 보고, 실패 알림, 근거 전달이 모두 모이는 운영 표면입니다.

여기서 중요한 원칙은 모든 것을 슬랙에 보내지 않는다는 점입니다. 정상 상태는 보낼 필요가 없습니다. “정상입니다”만 반복하는 감시 알림은 사람의 주의를 갉아먹습니다. 반대로 실패했는데 조용하면 사고가 됩니다. 그래서 슬랙으로 올라오는 메시지는 가능한 한 행동 필요, 결정 필요, 위험 확인 필요 상태여야 합니다.

슬랙 스레드는 단순한 댓글 묶음이 아니라 작업의 작은 맥락 단위입니다. CI가 실패한 뒤 Hermes가 회복 작업을 한다면 최종 결과는 초기 알림 스레드 아래로 들어가야 합니다. Voice Memory 요약에 Joon이 코멘트를 달면, 그 스레드는 녹음 후처리 루프의 진입점이 됩니다. 고객 메일 알림 스레드에서 “진행해봐”라고 하면 그 스레드가 고객 요청의 실행 표면이 됩니다.

7. Hermes Joe는 실행자가 아니라 판단 계층입니다

Hermes Joe는 “도구가 많은 챗봇”이 아닙니다. 역할은 맥락 파악, 판단, 조율입니다. 필요한 skill을 불러오고, 과거 대화를 찾고, Hindsight를 조회하고, 레포와 서버를 확인하고, Codex·Happy·Kanban 작업자에게 실행을 넘긴 뒤, 원천 증거로 결과를 검증합니다.

• 요구사항을 실행 가능한 완료 기준으로 바꿉니다.
• 어떤 작업은 Codex lane, 어떤 작업은 Kanban 작업자, 어떤 작업은 직접 터미널 검증이 맞는지 판단합니다.
• 작업자 자기 보고를 그대로 믿지 않고 변경점, 테스트, 빌드, E2E, PR, CI, 실제 서비스 동작을 확인합니다.
• 운영 배포, DB 변경, 비밀값 출력, 실제 광고 변경 같은 위험한 경계는 명시 승인 없이는 넘지 않습니다.
• 최종적으로 Joon에게 “다 했다”가 아니라 “무엇으로 증명되는가”라는 형태로 보고합니다.

작업자가 “완료”라고 했는데 실제로는 PR이 merge되지 않았거나, Sentry 후속 조치를 말로만 써놓고 실행하지 않았거나, 배포 검증이 빠진 경우가 있었습니다. 그 뒤로 완료의 기준은 작업자의 문장이 아니라 원천 증거가 되었습니다.

8. 계속 확인하기보다, 사건이 생길 때 깨웁니다

AI 에이전트를 운영할 때 가장 쉬운 설계는 계속 확인하게 만드는 것입니다. “5분마다 확인해라”, “계속 기다려라”, “완료됐는지 봐라” 같은 구조입니다. 그러나 이 방식은 금방 한계에 닿습니다. 토큰을 태우고, 정상 상태 보고가 소음이 되고, 정작 중요한 실패가 묻힙니다.

그래서 가능한 루프는 웹훅과 사건 기반 구조로 바꿉니다. 외부 시스템이 변화를 감지하고 작은 payload를 보냅니다. Hermes는 그때만 깨어납니다. 단순 전달로 충분한 알림은 LLM을 쓰지 않고, 판단이 필요한 경우에만 Hermes가 실행됩니다.

sequenceDiagram
  participant External as 외부 시스템
(CI/Sentry/Gmail/Grafana/Voice)
  participant Webhook as 웹훅 / 이벤트 허브
  participant Hermes as Hermes Joe
  participant Surface as 운영 표면
(Slack/Kanban/Grafana/Hindsight)
  participant Human as Joon

  External->>Webhook: 사건 발생
  Webhook->>Webhook: 서명 검증 / 중복 제거 / 분류
  alt 정상 또는 조치 불필요
    Webhook->>Surface: 상태만 조용히 갱신
  else 중요 / 위험 / 실패
    Webhook->>Hermes: 작은 payload로 에이전트 깨우기
    Hermes->>Surface: 로그, 상태, 결과물 확인
    Hermes->>Surface: 행동, 결과, 근거 기록
    Hermes->>Human: 결정 또는 행동 필요 시에만 슬랙 보고
  end

이 설계의 핵심은 AI를 덜 일하게 만드는 것이 아닙니다. AI가 가치 없는 관찰에 토큰을 쓰지 않게 하고, 판단이 필요한 순간에만 집중하게 만드는 것입니다. 정상은 조용해야 하고, 실패와 위험은 드러나야 하며, 결정이 필요하면 사람에게 올라옵니다.

웹훅에도 함정은 많았습니다. route test가 200 ignored를 반환했는데 실제 에이전트는 깨어나지 않는 경우가 있었습니다. Sentry Internal Integration은 서명을 보내지만 Alert Rule plain webhook은 보내지 않는 식의 차이도 있었습니다. 그래서 웹훅의 성공 기준은 단순 200이 아닙니다. 서명 검증, 중복 제거, 사건 종류 확인, 정상 수신, 작업 생성, 최종 결과물까지 봐야 합니다.

9. Kanban, Codex, Happy: 실행은 나누고 검증은 남깁니다

코드 작업과 긴 실행은 Hermes 본 대화 턴 안에 두기 어렵습니다. 그래서 실행 lane을 나눕니다. Codex는 분리된 작업 디렉터리에서 코드 작업을 수행합니다. Happy는 원격 코딩 lane으로 쓰되 완료 웹훅 중심으로 정리했습니다. Kanban은 작업자와 profile 사이의 지속적인 제어판입니다.

flowchart TB
  Joe[Joe / Hermes
조율자 + 검증자] --> Plan[명세 / 완료 기준 / 프롬프트]
  Plan --> Kanban[Kanban 작업
지속 상태]
  Plan --> Codex[Codex CLI Lane
분리된 작업 디렉터리]
  Plan --> Happy[Happy Lane
완료 웹훅]

  Codex --> Diff[Git 변경점 / Commit]
  Happy --> Diff
  Diff --> Tests[테스트 / E2E / 빌드]
  Tests --> Review[Joe 검증
변경점 + 테스트 + 원래 완료 기준]
  Review --> PR[GitHub PR / Merge 후보]
  PR --> CI[CI / Webhook]
  CI --> Joe
  Review --> Slack[슬랙 근거 보고]

이 구조의 핵심은 실행자와 검증자를 분리하는 것입니다. Codex가 파일을 고칠 수 있고, Happy가 PRD를 구현할 수 있고, Kanban 작업자가 작업을 완료로 표시할 수 있습니다. 그러나 최종적으로 그 작업이 Joon의 원래 완료 기준을 만족하는지 판단하는 것은 Joe의 일입니다.

Codex lane은 특히 실행 환경 표면이 중요합니다. 슬랙이나 Hermes 안에서 실행되는 subprocess는 HOME이 다른 곳으로 잡힐 수 있고, 이 경우 Codex 인증 정보를 못 찾아 인증 오류처럼 보일 수 있습니다. 그래서 Codex lane은 실제 사용자 HOME과 경로를 명시적으로 맞추고, 수정 작업은 공유 checkout이 아니라 분리된 작업 디렉터리에서 돌립니다. Codex 자기 보고는 참고하되, 변경점과 테스트는 Hermes가 다시 확인합니다.

Happy도 비슷합니다. 예전에는 기다리고 반복 확인하는 루프가 많았습니다. 지금은 완료 웹훅이 Hermes를 깨우고, Joe가 lane 결과, 작업 디렉터리, git log, 테스트 출력을 확인합니다. Happy가 “success”라고 말하는 것은 merge 권한이 아니라 검토 시작 신호에 가깝습니다.

Kanban은 지속 상태를 제공하지만 Kanban 자체도 완전한 신뢰 대상은 아닙니다. DB 손상, 작업자 heartbeat 정체, profile별 skill 가용성 문제를 겪었습니다. 그래서 제어판도 관찰되어야 합니다. 작업 상태, 실행 로그, 작업자 heartbeat, 담당 profile 준비 상태까지 확인합니다.

10. 로그와 대시보드: Loki, Grafana, Sentry는 AI가 보는 운영 눈입니다

운영에서 사람은 Grafana와 Sentry를 봅니다. 그러면 AI도 같은 것을 볼 수 있어야 합니다. Promtail은 서버 로그를 중앙 Loki로 보내고, Grafana는 사람이 보는 대시보드를 제공하고, Sentry는 운영 오류와 crash를 issue 표면으로 만듭니다. Hermes는 이 표면들을 통해 지금이 장애인지, 사용자 영향이 있는지, 오래된 소음인지, 즉시 작업이 필요한지를 판단합니다.

여기서 중요한 시행착오가 있었습니다. 한때 앱 서버에서 localhost Loki endpoint가 실패하는 것을 보고 local Loki/Grafana stack을 운영 서버에 올린 적이 있습니다. 나중에 확인하니 기준이 되는 구조는 DSM의 중앙 Loki/Grafana였고, 앱 서버에는 Promtail이 중앙 Loki로 보내는 구조가 맞았습니다.

Sentry도 단순히 슬랙으로 전달하는 것만으로는 부족합니다. 운영 오류가 있으면 issue id, release, environment, stack trace 같은 디버깅 단서와 재발 여부, 사용자 영향 가능성을 함께 봐야 합니다. 채팅 알림만 있는 구조는 쉽게 흘러갑니다. 그래서 중요한 Sentry 신호는 Kanban 작업으로 남기고, 슬랙에는 무엇이 생겼고 누가 처리하며 어디서 추적하는지를 남기는 방향이 더 안정적이었습니다.

Grafana 알림도 비슷합니다. 모든 알림이 즉시 조치 대상은 아닙니다. 예를 들어 예상 VM 구성과 실제 상태가 어긋나서 어떤 VM이 켜져 있는 것을 발견했을 때, AI가 마음대로 종료하면 사람의 작업을 날릴 수 있습니다. 이 경우 AI의 역할은 상태를 확인하고, 위험을 설명하고, 종료할지 예상 상태를 바꿀지를 사람에게 결정으로 올리는 것입니다.

11. 비밀값 관리: AI가 비밀을 아는 것이 목표가 아닙니다

AI 에이전트에게 권한을 주는 문제는 단순히 API key를 넣는 문제가 아닙니다. 목표는 AI가 비밀값을 아는 것이 아니라, 비밀값을 보지 않고도 필요한 실행 맥락을 얻는 것입니다.

Infisical은 이 목적의 중심에 있습니다. 사람이 보는 표면은 프로젝트, 환경, 경로, 비밀값 이름입니다. AI가 볼 수 있는 것도 주로 이 수준이어야 하고, 값 자체는 출력하지 않습니다. Codex나 Hermes가 실행할 때는 범위를 제한한 주입을 씁니다. 로컬 신뢰 개발 환경에서는 넓은 범위를 쓸 수 있지만, 서비스 실행 환경에는 더 좁은 project/env/path를 씁니다.

이 계층에서도 시행착오가 있었습니다. 실행 환경의 HOME이 사람의 HOME과 다르게 잡히면 인증 정보를 찾는 방식이 달라집니다. 어떤 점검 스크립트는 한쪽 .env만 보고 token이 없다고 오탐을 냈지만, 실제 runtime은 다른 경로에서 인증 정보를 찾고 있었습니다. 그래서 비밀값 점검은 실행 환경이 인증 정보를 해석하는 방식을 그대로 반영해야 합니다.

12. 기억은 저장소가 아닙니다

처음 에이전트 기억을 만들 때 가장 쉬운 실수는 모든 것을 기억시키는 것입니다. 작업 결과, PR 번호, issue 번호, commit SHA, 완료 로그, 일회성 알림을 Memory에 넣고 싶어집니다. 그러나 이것은 장기적으로 에이전트를 나쁘게 만듭니다. 맥락이 낡고, 미래 판단을 오염시키고, 정말 중요한 선호와 경계를 밀어내기 때문입니다.

그래서 기억 계층을 나눴습니다.

flowchart LR
  Current[현재 Hermes 대화] --> Memory[Hermes Memory
작고 안정적인 포인터]
  Current --> Skills[Skills
절차 / runbook]
  Current --> Sessions[Session Search
과거 대화]
  Current --> Hindsight[Hindsight
의미 기반 근거 색인]
  Current --> Voice[Voice Memory
녹음 / 전사 / 작업 문서]

  Hindsight --> Voice
  Hindsight --> Sessions
  Memory --> Skills

Hermes Memory는 작고 신호가 높아야 합니다. Joon의 선호, 안정적인 환경 진입점, 반복적으로 틀리면 비용이 큰 안전 경계만 들어갑니다. Skills에는 절차가 들어갑니다. 관찰 운영, 비밀값 관리, 웹훅 구독, 음성 기억, Codex lane 운영 같은 재사용 가능한 절차를 담습니다.

Session Search는 과거 대화와 결정을 찾는 계층입니다. “그때 왜 이렇게 했는가”, “어디까지 했는가”, “누가 무엇을 승인했는가”는 Memory에 박는 것이 아니라 여기서 회수합니다. Hindsight는 의미 기반 검색 계층이지만 원본 전사문이나 긴 작업 로그를 넣는 장소가 아니라 근거를 찾아가는 색인입니다.

13. 음성 흐름: 사람이 들은 것을 AI도 근거로 보게 만들기

Voice Memory와 Voice Flow는 이 철학이 가장 잘 드러나는 부분입니다. 사람은 통화, 미팅, 음성 메모에서 맥락을 얻습니다. 그렇다면 AI도 그 근거를 볼 수 있어야 합니다. 단, 원본 음성과 전사문을 무작정 Memory에 넣는 방식은 아닙니다.

flowchart TB
  Audio[음성 녹음] --> STT[STT / 화자 분리 / 정렬]
  STT --> Package[전사 패키지]
  Package --> Workdoc[작업 문서
할 일 / 인사이트 / 질문]
  Package --> Graph[Neo4j 근거 투영]
  Workdoc --> Hermes[Hermes 해석]
  Graph --> Hermes

  Hermes --> Slack[슬랙 요약 스레드]
  Slack --> Comment[Joon 코멘트]
  Comment --> VoiceAPI[Voice Memory 코멘트 API]
  VoiceAPI --> Hermes
  Hermes --> Hindsight[Hindsight 색인
원천 포인터만 저장]

Voice Memory는 근거를 생산합니다. 녹음, STT, 화자 분리, 전사 패키지, 작업 문서, 그래프 투영을 만듭니다. Hermes는 해석합니다. 이 녹음이 어떤 프로젝트와 연결되는지, 어떤 행동이 실제인지, 어떤 인사이트가 오래 남을 만한지를 판단합니다. Hindsight는 원천 포인터를 남깁니다. 미래의 에이전트는 Hindsight에서 찾고, 필요하면 Voice Memory API로 전사문과 작업 문서를 다시 가져옵니다.

여기서도 경계가 중요합니다. Neo4j 그래프 투영은 절대 진실이 아니라 다시 만들 수 있는 근거 투영입니다. 화자 분리 라벨은 사람 identity의 증거가 아닙니다. 누가 말했는지가 중요한 답이라면 전사문과 알려진 맥락을 다시 확인해야 합니다. 품질이 낮은 녹음은 성공처럼 처리하지 않습니다.

슬랙 요약 스레드는 이 루프에서 사람이 교정하는 표면입니다. 새 녹음이 후처리되면 슬랙에 요약이 올라오고, Joon이 스레드에 코멘트를 달면 그 코멘트가 Voice Memory 코멘트 API로 들어가 후처리를 다시 트리거합니다. 사람이 듣고 교정한 내용이 다시 AI 근거 루프로 들어오는 구조입니다.

14. Meta 광고와 성장 신호도 운영 표면입니다

이 구조는 개발·인프라에만 적용되지 않습니다. Meta 광고, GA4, Gmail 성장 알림, 캠페인 성과 스냅샷도 같은 철학으로 다룹니다. 사람이 광고 계정과 분석 화면을 보며 판단한다면, AI도 같은 신호를 볼 수 있어야 합니다.

다만 광고 표면에는 특유의 위험이 있습니다. Meta 노출·집행 데이터와 GA4 기여 추정을 섞으면 안 되고, GA4의 넓은 이벤트를 전환의 정답으로 보면 안 됩니다. 광고 소재 검토도 작은 thumbnail이 아니라 원본 광고 이미지로 봐야 합니다. 실제 예산 변경, 캠페인 시작, 전환 매핑 변경은 운영 변경과 같은 계열이므로 명시 승인이 필요합니다.

그래서 성장 루프도 같은 명세를 따릅니다. 사람이 보는 표면은 Meta 대시보드와 GA4이고, AI가 보는 표면은 Graph API 스냅샷, GA4 리포트, Gmail 본문입니다. 정상적인 정보성 업데이트는 조용히 넘어가고, 예산·리드 품질·추적 단절·승인 이슈·캠페인 리스크처럼 행동이 필요한 신호만 슬랙 성장 표면으로 올라옵니다.

15. 실제 운영 표면 스크린샷

아래 이미지는 이 글을 위해 직접 찍은 현재 운영 표면의 스크린샷입니다. 인증 정보나 비밀값은 포함하지 않았습니다. 로그인 화면도 단순한 장식이 아니라 중요한 표면입니다. 사람이 “여기서 확인한다”고 느끼는 곳을 AI도 상태·API·로그·사건 형태로 볼 수 있게 만드는 것이 이 구조의 출발점이기 때문입니다.

스크린샷을 넣는 이유는 단순한 비주얼 강화가 아닙니다. “표면”이라는 개념은 실제 화면, 실제 대시보드, 실제 로그인 경계, 실제 결과물이 있을 때 더 분명해집니다. AI 운영 체계는 추상적인 조율 그래프만으로 완성되지 않습니다. 사람이 실제로 돌아와 확인할 수 있는 장소가 있어야 합니다.

16. 표면별 명세

17. 기술별 링크와 외부 레퍼런스

이 구조는 특정 제품 하나를 그대로 따라 만든 것이 아닙니다. 다만 각 층마다 참고할 만한 공개 프로젝트와 공식 문서가 있습니다. 이 글을 자기 회사 에이전트에게 읽힌다면, 아래 링크들이 실제 판단 기준이 됩니다.

중요한 것은 링크의 수가 아닙니다. 각 도구가 사람용 화면, AI용 입력, 사건 발생 조건, 결과 증거, 승인 경계 중 어디를 맡는지를 정리하는 것입니다. 이 다섯 가지가 정리되지 않으면 도구를 아무리 많이 붙여도 운영이 좋아지지 않습니다.

18. 시행착오: 이 구조는 한 번에 나온 것이 아닙니다

지금의 구조는 처음부터 명확했던 것이 아닙니다. 여러 실패를 겪으면서 원칙이 생겼습니다.

1. 관찰 표면의 위치를 착각했습니다

local Loki/Grafana를 잘못 올린 경험은 큰 교훈이었습니다. 관찰 가능성은 대시보드를 하나 더 만든다고 생기지 않습니다. 로그가 어디에서 어디로 흐르는지, 어떤 데이터 소스가 기준인지, 어떤 라벨 규칙을 쓰는지를 먼저 증명해야 합니다.

2. 반복 확인은 에이전트를 지치게 합니다

대기 루프, 반복 상태 확인, 정상 보고만 반복하는 cron은 에이전트 토큰과 사람의 주의를 동시에 낭비했습니다. 지금은 가능한 한 사건 기반으로 바꾸고, 정상은 조용히 두며, 실패와 결정만 드러나게 만듭니다.

3. 작업자 자기 보고는 완료 증거가 아닙니다

Codex, Happy, Kanban 작업자가 “완료”라고 말해도 실제로는 변경점이 불완전하거나, 테스트가 빠졌거나, PR이 merge되지 않았거나, 배포 검증이 빠질 수 있습니다. 최종 증거는 Git, 테스트 출력, E2E 근거, CI, 실제 서비스 동작입니다.

4. Memory를 많이 넣는다고 똑똑해지지 않습니다

작업 로그와 일회성 결과를 Memory에 넣으면 미래의 에이전트 맥락이 오염됩니다. Memory는 진입점이고, 절차는 skill이며, 근거는 원천 시스템에 남깁니다. Hindsight는 source를 찾는 색인입니다.

5. 비밀값과 인증 경로도 운영 표면의 일부입니다

AI가 실행되는 shell의 HOME이 사람의 HOME과 다르면 인증 정보를 찾는 방식이 달라집니다. 한쪽 .env만 보는 점검은 오탐을 만들 수 있습니다. 비밀값 자체가 아니라 비밀값을 어떻게 찾아 주입하는지를 명세해야 합니다.

6. 웹훅은 연결됐다는 말만으로는 부족합니다

event 종류가 달라 route가 무시되거나, 서명 방식이 달라 인증이 막히거나, tunnel 경로가 달라 외부 수신이 죽는 일이 있었습니다. 웹훅은 서명된 요청, 정상 수신, agent 실행, 작업 생성, 최종 결과물까지 검증해야 합니다.

7. 음성 근거는 해석이 필요합니다

STT, 화자 분리, 그래프 투영, 작업 문서 요약은 근거 표면이지 절대 진실이 아닙니다. 누가 말했는지, 어떤 행동이 실제인지, 어떤 해석이 가능한지는 전사문 근거를 확인해야 합니다. 그래서 Voice Memory는 근거를 만들고 Hermes가 해석합니다.

8. 제어판도 깨집니다

Kanban은 지속 상태지만 DB 손상, skill 충돌, heartbeat 정체 같은 문제가 있었습니다. source of truth라고 부르는 시스템에도 관찰과 복구 표면이 필요합니다.

19. 현재 따르는 설계 규칙

1. 먼저 구조를 증명합니다. 무언가 안 보이면 새 도구를 만들기 전에 현재 흐름부터 확인합니다.
2. 계속 확인하지 말고 사건으로 깨웁니다. 정상은 조용히, 막힘은 크게 드러냅니다.
3. 말보다 결과물입니다. 완료 주장은 변경점, 테스트, 로그, 대시보드, 작업 기록, 스크린샷, API 응답으로 증명합니다.
4. 원본을 복사하지 말고 찾는 길을 남깁니다. Memory와 Hindsight에는 원천 근거를 찾는 포인터를 둡니다.
5. 비밀값이 아니라 이름과 범위입니다. AI가 비밀값을 읽지 않아도 실행 가능한 주입 표면을 만듭니다.
6. 되돌리기 어려운 일은 사람 승인입니다. 운영 배포, DB 변경, 실제 광고 변경, 파괴적 인프라 작업은 명시 승인이 필요합니다.
7. 스레드는 감사 단위입니다. 슬랙 스레드는 작업 단위의 근거 흐름입니다.
8. 작업자는 실행하고 Joe는 검증합니다. 실행과 판단을 분리합니다.
9. 기억은 희소 자원입니다. 오래 남을 방향타만 Memory에 둡니다.

20. 결론: 에이전트 인프라의 다음 단계는 더 긴 프롬프트가 아닙니다

많은 에이전트 실험은 프롬프트를 길게 만들거나 더 좋은 모델을 붙이는 방향으로 갑니다. 물론 모델은 중요합니다. 그러나 운영하는 입장에서 더 본질적인 질문은 따로 있습니다.

이 에이전트는 사람이 보는 현장을 볼 수 있는가. 그리고 사람이 이 에이전트의 판단을 다시 검증할 수 있는가.

Hermes 주변에 만든 인프라는 이 질문에 대한 답입니다. Slack, Webhook, Kanban, Grafana, Loki, Sentry, Infisical, Codex, Happy, Voice Memory, Hindsight는 각각 다른 시스템처럼 보이지만, 실제로는 하나의 방향으로 수렴합니다.

AI 에이전트의 다음 단계는 “알아서 다 하는 마법”이 아닙니다. 더 명확한 관찰 표면, 더 작은 권한 경계, 더 좋은 근거 흐름, 더 조용한 정상 상태, 더 빠른 실패 노출입니다. 그 위에서만 자율성이 의미를 가집니다.