Thesis 에이전트 실패의 첫 원인은 모델 성능 부족이 아니라 운영 표면 부재다.
1. 에이전트는 세계를 직접 보지 않는다
AI 에이전트가 실패하면 가장 먼저 의심받는 건 모델이다. 더 큰 모델을 써야 한다, 프롬프트를 더 길게 써야 한다, reasoning effort를 올려야 한다. 처방은 늘 그쪽으로 향한다. 물론 모델 성능은 중요하다. 그러나 내가 Hermes를 굴리면서 반복해서 본 실패의 첫 원인은 다른 데 있었다. 에이전트가 사람이 보는 운영 세계를 보지 못한 것이다.
사람은 운영할 때 화면 하나만 보지 않는다. Slack 스레드에서 요청의 맥락을 읽고, GitHub PR에서 변경점을 보고, CI에서 어디가 깨졌는지 짚고, Grafana 대시보드에서 그래프의 모양을 보고, Loki에서 로그 흐름을 따라가고, Sentry에서 issue가 재발하는지 확인한다. 서버에서는 systemd 상태와 Docker 로그를 보고, 광고는 Meta와 GA4를 나눠서 보고, 고객 맥락은 Gmail과 음성 기록에서 끌어온다. 이 조각들이 합쳐져 "지금 무슨 일이 벌어지고 있는가"라는 한 줄의 판단이 된다.
에이전트에게 이 조각들이 없으면, 에이전트는 운영자가 아니라 추측하는 비서가 된다. "아마 됐을 거예요" 같은 말은 할 수 있다. 하지만 어떤 로그를 봤는지, 어떤 테스트가 통과했는지, 어떤 알림이 진짜 사건인지, 어떤 결정은 사람에게 올려야 하는지는 판단하지 못한다. 자율성은 관찰 가능성 다음에 온다. 순서를 바꿀 수 없다.
2. 사람이 보는 운영 표면 목록부터 적는다
에이전트를 붙이는 첫 단계는 모델 후보를 고르는 일이 아니다. 사람이 이미 보고 있는 운영 표면을 적는 일이다. 이 목록은 조직마다 다르다. Hermes/pjy.pizza의 지금 구조에서는 대략 이렇게 나뉜다.
| 표면 | 사람이 보는 것 | 에이전트가 읽어야 하는 것 | 남아야 하는 증거 |
|---|---|---|---|
| Slack | 지시, 결정, 결과 보고, 실패 알림 | 스레드 맥락, 채널 성격, 후속 코멘트 | 원인·행동·결과가 이어진 스레드 |
| Git/GitHub/CI | diff, PR, check 결과 | 변경 파일, 테스트 출력, CI 상태 | commit, PR, check run, 리뷰 기록 |
| Grafana/Loki | 대시보드와 로그 패널 | LogQL 결과, 라벨, 데이터 소스 | 로그 근거와 대시보드 위치 |
| Sentry | issue, stack trace, release/environment | issue id, 재발 여부, 사용자 영향 단서 | 작업 링크와 처리 결과 |
| Infisical | 프로젝트, 환경, 경로, secret 이름 | 값이 아닌 이름·범위·주입 상태 | 값 노출 없는 가용성 판단 |
| Voice Memory | 녹음, 전사, 작업 문서 | 원천 포인터, 요약, 교정 코멘트 | 작업 문서와 Hindsight 포인터 |
| Meta/GA4/Gmail | 성장 신호와 고객 반응 | API 스냅샷, 리포트, 메일 본문 | 승인 경계가 남은 실행 기록 |
이 표는 도구 목록이 아니다. 에이전트에게 열어줄 세계의 지도다. "우리도 AI를 붙일 수 있을까"라는 질문은 "우리 운영 표면 중 무엇이 에이전트에게 안전하게 읽히는가"라는 질문으로 바뀌어야 한다. 후자에 답할 수 없으면 전자는 아직 이르다.
3. 함께 보는 운영 표면의 정의
함께 보는 운영 표면은 사람이 보는 모든 것을 AI에게 원본 그대로 들이붓는다는 뜻이 아니다. 오히려 반대에 가깝다. 비밀값, 개인정보, 원본 고객 데이터, 되돌리기 어려운 운영 권한은 좁게 다뤄야 한다. 핵심은 같은 판단에 필요한 근거를, 사람과 AI가 서로 다른 안전한 형태로 공유하는 것이다.
이 기준에서 좋은 표면은 다섯 조건을 만족한다.
- 사람이 보는 상태가 API, 파일, 로그, 대시보드, 스레드, 작업 기록 형태로 에이전트에게도 드러난다.
- 에이전트가 한 행동이 사람이 다시 읽을 수 있는 결과물로 남는다.
- 사건의 원인, 판단, 다음 행동이 한 흐름에서 추적된다.
- 비밀값과 위험 권한은 숨기되, 상태와 근거는 드러난다.
- 정상은 조용하고, 실패·위험·결정만 사람의 주의로 올라온다.
이 정의가 없으면 "AI가 볼 수 있다"는 말은 너무 쉽게 부풀려진다. 스크린샷 한 장 보고 추측하는 것도 본다고 부를 수 있고, production shell 권한을 통째로 넘기는 것도 본다고 부를 수 있다. 둘 다 운영 표면이 아니다. 전자는 근거가 약하고, 후자는 권한이 과하다. 함께 보는 표면은 근거와 권한을 분리한다.
4. 처음 듣는 사람에게 설명하는 방식
AI 에이전트 운영을 처음 설명할 때 "AI가 알아서 다 한다"고 말하면 거의 항상 오해가 생긴다. 더 나은 설명은 다음 순서다.
첫째, 장애가 나면 사람이 어디를 보는지 적는다. Slack, Sentry, Grafana, 서버 로그, GitHub, 고객 메일 중 무엇이 가장 먼저 열리는지 본다. 둘째, 그 표면을 AI가 읽을 수 있는 형태로 바꾼다. 화면을 그대로 던지는 게 아니라 webhook, 로그 질의, 파일, API, 스레드, 작업 기록으로 바꾼다. 셋째, 모든 상태를 다 올리지 않는다. 정상은 조용히 둔다. 넷째, AI가 한 일을 사람이 다시 확인할 수 있게 한다.
이 설명은 "프롬프트를 잘 쓰자"보다 느리게 들릴 수 있다. 그러나 운영에서는 이쪽이 빠르다. 프롬프트만 긴 에이전트는 첫 번째 장애에서 곧장 추측을 시작한다. 표면을 가진 에이전트는 어떤 시스템이 말하고 있는지, 어떤 근거가 부족한지, 어디서 멈춰야 하는지를 말할 수 있다.
5. 운영 성숙도 사다리
다음 사다리는 조직의 에이전트 준비도를 빠르게 가늠하는 데 쓸 수 있다. 핵심은 모델 이름이 아니라 표면의 형태다.
| 단계 | 상태 | 전형적 증상 | 다음 개선 |
|---|---|---|---|
| 0 | 사람 전용 운영 | 사람만 대시보드를 보고 AI는 추측한다 | 사람이 보는 표면 목록화 |
| 1 | 복사/스크린샷 기반 | 에이전트가 붙여넣은 텍스트에만 반응한다 | 안전한 읽기 API 또는 로그 파일 제공 |
| 2 | 수동 조회 가능 | 사람이 시키면 로그나 파일을 읽는다 | 사건 발생 시 자동으로 깨우는 경로 추가 |
| 3 | 사건 기반 표면 | 중요한 이벤트가 에이전트를 깨운다 | 증거 기록과 승인 경계 정리 |
| 4 | 검증 가능한 운영 파트너 | 에이전트가 행동하고, 근거를 남기고, 멈출 곳을 안다 | 표면별 runbook과 회귀 검증 강화 |
Hermes의 목표는 4단계의 환상을 만드는 게 아니다. 모든 표면을 한 번에 자동화하지도 않는다. 중요한 표면부터 2단계에서 3단계로 올리고, 위험한 경계에는 명시 승인을 남기고, 작업자의 자기 보고가 아니라 원천 증거를 본다. 사다리는 한 칸씩만 올라간다.
6. 운영 세계가 표면으로 바뀌는 흐름
flowchart TB Human["Joon / 운영자"] --> HumanSurfaces["사람이 보는 표면<br/>Slack · GitHub · Grafana · Sentry · 서버 · 광고 · 음성"] HumanSurfaces --> Translation["안전한 변환<br/>API · 로그 · 웹훅 · 파일 · 스레드 · 작업 기록"] Translation --> Agent["Hermes / 에이전트"] Agent --> Evidence["남는 증거<br/>diff · test · log · screenshot · thread · task"] Evidence --> Human Translation --> Guardrails["권한 경계<br/>secret 값 숨김 · 파괴적 변경 승인 · 정상은 조용히"] Guardrails --> Agent
이 그림에서 중요한 건 가운데의 변환 계층이다. 사람 화면을 그대로 AI에게 복사하는 게 아니라, AI가 읽어도 안전하고 사람이 다시 검증할 수 있는 운영 표면으로 바꾼다. 변환 계층이 부실하면 위쪽 화살표가 아무리 많아도 에이전트는 여전히 추측한다.
7. 실패 사례: 자기 보고를 완료 증거로 착각할 때
가장 흔한 실패는, 작업자가 "완료"라고 말하는 순간 운영자가 안심하는 것이다. Codex lane, Happy lane, Kanban worker 모두 어떤 형태로든 완료 보고를 한다. 그러나 완료 보고는 증거가 아니다. PR이 실제로는 merge되지 않았을 수 있고, 테스트가 빠졌을 수 있고, Sentry 후속 조치가 말로만 남았을 수 있고, 배포 검증이 통째로 누락됐을 수 있다.
이 실패는 모델이 약해서 생기지 않는다. 완료의 운영 표면이 없어서 생긴다. 어떤 diff가 남았는지, 어떤 테스트가 통과했는지, 어떤 CI가 실패했는지, 실제 서비스가 어떻게 응답하는지, Slack 스레드에 어떤 결론이 남았는지를 볼 수 없으면, 에이전트는 자기 보고를 사실처럼 취급한다.
그래서 Hermes 주변의 원칙은 "말보다 결과물"이다. 작업자의 문장은 신호이고, Git·테스트·로그·대시보드·스크린샷·API 응답이 증거다. 에이전트 운영의 첫 번째 안전장치는 더 엄격한 말투가 아니라 더 읽기 쉬운 증거 표면이다.
8. 운영 규칙
- 모델을 고르기 전에 사람이 보는 운영 표면 목록을 만든다.
- AI에게 raw secret이나 원본 민감 데이터를 넘기는 일을 운영 표면이라고 부르지 않는다.
- 정상 상태를 계속 보고하는 자동화는 줄이고, 실패·위험·결정이 필요한 사건만 올린다.
- 작업자의 완료 보고는 검토를 시작하라는 신호로 취급한다.
- 완료 증거는 변경점, 테스트, 로그, 대시보드, 스레드, API 응답처럼 사람이 다시 읽을 수 있는 것에서 찾는다.
- 비밀값은 값이 아니라 프로젝트·환경·경로·이름·주입 상태로 다룬다.
- 운영 표면은 사람만 보는 화면도, AI만 아는 내부 상태도 아니다. 둘이 같은 근거를 서로 검증 가능한 형태로 보는 장소다.
다음 글
다음 글은 /writing/observable-surface/agent-readable-diagnostic-brief/로 이어진다. 운영 표면이라는 개념을 조직 평가에 바로 적용할 수 있도록, 글의 주장과 에이전트의 평가 절차를 어떻게 연결할지 다룬다.