새벽에 Sentry 알림이 하나 울린다. 사람이라면 그 한 줄만 보고 판단하지 않는다. Grafana 패널을 열고, Loki에서 로그를 뒤지고, 마지막 배포 시점을 떠올리고, Slack 스레드에서 "이거 누가 보고 있나"를 확인한다. 운영 판단은 한 화면이 아니라 이 표면들의 교차점에서 나온다. AI가 같은 판단을 하려면 같은 현장을 읽어야 한다.
Thesis 관찰 가능성은 대시보드를 하나 더 만드는 일이 아니다. 기준이 되는 로그 흐름과 사건 해석을, 다음에도 똑같이 재현할 수 있게 증명하는 일이다.
1. AI가 운영을 보려면 사람과 같은 근거를 가져야 한다
"같은 현장을 읽는다"는 말을 오해하기 쉽다. 모든 화면을 캡처해 모델에게 통째로 밀어 넣는다는 뜻이 아니다. 스크린샷 한 장은 그 순간을 보여줄 뿐, 다음에 같은 사건이 터졌을 때 다시 꺼내 볼 근거가 되지 못한다. AI가 운영을 보려면 네 가지가 있어야 한다. 기준 로그 흐름, 질의 가능성, 사건 분류, 그리고 사건이 지나간 뒤에도 남는 증거.
Hermes에게 Loki, Grafana, Sentry는 "운영 눈"이다. 역할은 또렷하게 나뉜다. Promtail이 서버 로그를 중앙 Loki로 흘려보낸다. Grafana는 사람이 보는 대시보드와 알림 규칙을 쥔다. Sentry는 애플리케이션 오류를 issue와 stack trace라는 구조로 만든다. Hermes는 이 표면들을 읽고 지금 필요한 게 무엇인지 고른다. 조용한 기록인지, Slack 보고인지, Kanban 작업 생성인지, 아니면 사람을 깨워 승인을 받아야 하는 일인지.
핵심은 마지막 분기다. 같은 신호라도 어디로 보내느냐가 운영의 질을 가른다. 그리고 그 분기를 제대로 하려면, 먼저 신호가 들어오는 길이 진짜 기준 경로인지부터 의심해야 한다.
2. local Loki 실수에서 나온 기준
한때 앱 서버에서 localhost Loki endpoint가 자꾸 실패하는 걸 보고, 운영 서버에 local Loki/Grafana stack을 통째로 올린 적이 있다. 표면적으로는 빠른 해결처럼 보였다. 로그가 안 보이니 가까운 데 저장소를 하나 세우면 되겠지 싶었다.
문제는 기준 구조가 따로 있었다는 점이다. 진짜 중앙 Loki/Grafana는 DSM에 있었다. 앱 서버가 할 일은 새 stack을 세우는 게 아니라 Promtail로 중앙 Loki에 로그를 보내는 것이었고, Grafana 데이터 소스도 그 중앙 흐름을 보고 있어야 했다. 내가 올린 local stack은 로그를 보이게 만든 게 아니라, "어느 Loki가 진짜냐"라는 혼란을 하나 더 만들었을 뿐이다.
이 실패가 규칙 하나를 남겼다. 로그가 안 보인다고 새 대시보드를 만들지 않는다. 먼저 흐름을 증명한다. Promtail이 어떤 파일을 tail하는지, 어떤 label을 붙이는지, 중앙 Loki가 그걸 받고 있는지, Grafana 데이터 소스가 어느 Loki를 보는지, 대시보드의 LogQL이 그 label 규칙과 맞물리는지 — 이 경로를 끝까지 따라가 본다. 관찰 가능성은 도구를 설치하는 일이 아니라 기준 경로를 증명하는 일이다.
flowchart LR App[앱 서버 로그] --> Promtail[Promtail] Promtail --> Loki[DSM 중앙 Loki] Loki --> Grafana[DSM Grafana] Grafana --> Alert[Grafana 알림] Alert --> Hermes[Hermes 판단] App -.잘못된 우회.-> Local[운영 서버 local stack] Local -.기준 혼란.-> Hermes
3. Sentry issue는 Slack 소음과 다르다
Sentry를 Slack으로 연결만 하면 관찰 가능성이 생긴다고 착각하기 쉽다. 하지만 채팅 알림은 흘러간다. 스크롤을 한 번 올리면 사라지고, 같은 오류가 열 번 와도 열 개의 똑같은 메시지가 될 뿐이다.
Sentry issue는 다르다. 사건의 구조를 가진다. issue id, environment, release, stack trace, 처음 발생 시점, 재발 여부, 사용자 영향 가능성, 그리고 연결된 담당 작업까지. Hermes가 봐야 하는 건 "오류가 있었다"가 아니다. "이게 새 사건인가, 이미 처리 중인가, 방금 그 배포와 엮여 있나, 지금 사람을 깨울 일인가"이다. 이 질문들은 채팅 한 줄로는 답할 수 없고, issue 구조 위에서만 답이 나온다.
그래서 Sentry 신호는 두 단계로 다룬다. 첫 단계는 사건 정규화다. issue와 environment를 읽어 중복을 접고, 같은 오류가 몇 번째인지를 센다. 두 번째는 운영 해석이다. 오래된 소음이면 조용히 기록하고 끝낸다. 새 오류이거나, 재발이거나, 사용자 영향 가능성이 보이면 Slack이나 Kanban으로 올린다. 이때 사람이 읽는 Slack 메시지는 단순 전달이 아니라 추적 가능한 요약이어야 한다. issue 링크 없이 "에러 났어요"만 던지면, 받은 사람이 결국 처음부터 다시 뒤져야 한다.
4. 알림은 많을수록 안전하지 않다
Grafana 알림도 같은 함정에 빠진다. 모든 경고를 즉시 사람에게 던지면, 운영 표면은 금세 무시된다. 정상 상태 보고와 낮은 우선순위 경고가 반복되면 사람은 알림 채널 자체를 안 읽게 된다. 그러면 정작 중요한 한 건도 같이 묻힌다. Hermes의 역할은 알림을 증폭하는 게 아니라 분류하는 것이다.
예를 들어 문서에 적힌 예상 VM 상태와 실제 상태가 어긋날 수 있다. 어떤 VM이 켜져 있다고 해서 AI가 곧바로 종료하면 안 된다. 그 위에서 사람이 작업 중일 수도 있고, 문서의 예상 상태가 낡았을 수도 있다. 이 경우 알림의 의미는 "자동 조치"가 아니라 "결정 필요"다. Hermes는 상태를 확인하고, 위험을 설명하고, 종료할지 예상 상태 문서를 고칠지를 사람에게 올린다. 끄는 건 사람의 몫으로 남긴다.
이 분류를 매번 즉흥으로 하지 않으려면, 신호별로 "어디까지가 조용히 둘 일이고 어디부터가 사람 승인 경계인지"를 미리 그어 두는 게 낫다.
| 신호 | 조용히 둘 상태 | Slack으로 올릴 상태 | 사람 승인 경계 |
|---|---|---|---|
| Loki 로그 | 예상된 반복 로그, 디버그 수준 소음 | 오류 급증, 특정 서비스 반복 실패, 원인 질의 필요 | 로그 삭제, 보존 정책 변경 |
| Grafana 알림 | 자동 회복된 낮은 우선순위 경고 | 지속되는 장애, 용량 위험, 예상 상태 불일치 | VM 종료, 인프라 변경 |
| Sentry issue | 오래된 소음, 이미 추적 중인 issue | 새 오류, 재발, 사용자 영향 가능성 | 배포, rollback, 데이터 변경 |
| Slack 보고 | 단순 상태 갱신 | 행동 필요, 결정 필요, 위험 설명 | 운영 변경 승인 |
이 표는 Hermes를 위한 것이기도 하지만, 조직에 그대로 옮겨 써도 된다. 칸의 내용은 각자 다르겠지만, "조용히 / 보고 / 승인"이라는 세 칸의 골격은 어디서나 작동한다.
5. 기준 질의가 있어야 AI가 다시 볼 수 있다
스크린샷 한 장으로도 한 번은 본다. 문제는 운영이 반복된다는 데 있다. 같은 사건이 다음 주에 또 터졌을 때, AI는 같은 기준으로 다시 질의할 수 있어야 한다. 그러려면 Loki와 Grafana에 기준 질의가 있어야 한다.
구체적으로는 이런 것들이다. 결제 흐름을 볼 때 어떤 service label로 좁히는가. 사건을 볼 때 기본 시간 범위는 최근 15분인가 1시간인가. 어떤 문자열은 무시해도 되는 소음이고, 어떤 문자열이 보이면 멈춰야 하는 사건인가. 처음엔 이 기준이 거칠어도 된다. 완벽할 필요는 없다. 다만 머릿속이 아니라 문서에 있어야 한다.
"Hermes가 장애를 의심할 때 먼저 던지는 LogQL은 무엇인가", "Grafana에서 어떤 대시보드가 기준판인가", "Sentry issue를 Slack으로 올릴 때 절대 빠지면 안 되는 필드는 무엇인가" — 이 답들이 글로 남아 있어야 다음 에이전트가, 혹은 한 달 뒤의 나 자신이, 운영 표면을 추측하지 않고 그대로 재현한다. 관찰 가능성의 진짜 산출물은 대시보드가 아니라 이 재현 가능한 기준이다.
6. 운영 규칙
- 로그가 안 보이면 새 스택을 올리기 전에 Promtail, 중앙 Loki, Grafana 데이터 소스, label 규칙을 먼저 따라간다.
- local Loki는 임시 진단 도구로는 쓸 수 있지만 기준 운영 표면이 되어서는 안 된다.
- Sentry는 Slack 알림이 아니라 issue 구조 중심으로 해석한다.
- Slack에는 모든 오류를 보내지 않는다. 행동 필요, 결정 필요, 위험 설명만 올린다.
- AI의 로그 해석과 자동 조치는 다른 일이다. VM 종료, rollback, 데이터 변경은 사람 승인 경계다.
- 기준 LogQL과 대시보드 위치를 운영 문서에 남긴다.
- 관찰 가능성의 성공 기준은 "보인다"가 아니라 "같은 사건을 다시 같은 근거로 해석할 수 있다"이다.
7. 다음 글
운영 눈이 생기고 나면 곧장 다음 질문이 따라온다. 에이전트에게 무엇을 보여주고, 무엇은 절대 보여주지 않을 것인가. 로그와 대시보드를 읽힌다는 건 그 안에 섞인 토큰과 고객 데이터에도 손이 닿을 수 있다는 뜻이기 때문이다. 다음 글 /writing/observable-surface/secrets-without-secret-leakage에서는 그 권한 표면을 다룬다.