리포트가 도착하는 것만으로는 아무것도 나아지지 않는다 — 끊긴 고리는 'measure'가 아니라 'route'였다

2026-06-04 · Ascendy Engineering

TL;DR

주기적으로 도착하는 리포트·알림은 그 자체로 가치가 0이다. 가치는 그게 닫힌 루프(측정→분석→개선→재측정)를 굴릴 때만 생긴다.
모니터링을 개선하자면 보통 “지표를 더 모으자”로 가는데, 우리 루프를 단계로 쪼개 보니 **끊긴 고리는 ‘measure’가 아니라 ‘capture→route’**였다 — 떠오른 개선점이 사람이 기억해서 다시 옮겨 넣어야 행동으로 이어졌다. 사람이 manual relay 병목.
해법: ① durable backlog(기억 대신 파일이 들고 있음) ② agent가 핸드오프·PR 초안을 직접 작성(사람은 승인만). 사람을 transport에서 빼되 approver로 남긴다.
두 번의 삽질: “자동 스케줄러로 영구히” 추천했다가 그게 세션 스코프 + 7일 만료라 영구 엔진이 아님을 확인하고 정정 — 만료되는 자동화는 자동화가 아니다. 그리고 backlog가 다음 dead queue가 되지 않게 anti-rot lifecycle을 박았다.

소스 노트. 이 글은 상위 인프라 팀의 인테이크(docs/intake/from-infra/2026-06-04-monitoring-closed-loop.md)를 정제한 것이다. 첫 사이클이 포착한 현재 열린 운영 항목은 본문에서 제외했고(미해결 gap 신호 방지), backlog 경로·내부 식별자는 일반화했다. 멀티 AI를 붙였더니 느려졌다, 두 번째 AI를 어떻게 부르고 언제 멈추나와 같은 “프로세스/AI 협업” 결의 글이다.

리포트가 도착하는 것만으로는

주기적으로 도착하는 리포트를 손보다가 한 가지를 분명히 했다. 그 리포트는 그 자체로는 가치가 0이다. 가치는 그게 닫힌 루프를 굴릴 때만 생긴다.

측정(measure) → 분석(analyze) → 개선(improve) → 재측정(re-measure)

리포트가 매주 와도, 보고 → 고치고 → 다시 재는 데까지 이어지지 않으면 그건 그냥 주기적으로 도착하는 숫자일 뿐이다. 이 원칙을 우리 운영 모니터링에도 대보니, 루프가 어디서 끊겼는지가 선명해졌다.

끊긴 고리는 ‘measure’가 아니라 ‘route’였다

모니터링을 개선하자고 하면 보통 “지표를 더 모으자 / 대시보드를 더 만들자”로 간다. 그런데 우리 루프를 단계로 쪼개 보니 그쪽이 아니었다.

[1 surface] → [2 capture] → [3 route to actor] → [4 act] → [5 re-measure]
 알림·리포트·추세      (사람의 기억 + 재전달에 의존)       PR / 핸드오프
                     ^^^^^^^ 여기가 끊김 ^^^^^^^

1단계(surface) — 알림·리포트·추세는 이미 개선점을 내보내고 있었다.
4–5단계(act, re-measure) — PR·핸드오프·재측정 메커니즘도 이미 있었다.
끊긴 곳은 2–3단계 — 떠오른 개선점이 사람이 그걸 기억해서 올바른 자리에 다시 옮겨 넣어야 비로소 행동으로 이어졌다.

즉 사람이 manual relay 병목이었다. 모니터링은 개선점을 내보내는데, 사람이 다시 전달하지 않으면 신호는 거기서 죽는다. 사람의 기억은 휘발성이고, 신호 수는 사람보다 많다. 진짜 gap은 “측정이 부족”이 아니라 **“측정된 게 행동하는 쪽으로 라우팅되지 않고 증발”**이었다. — 지표를 더 모았어도 이 gap은 그대로였을 것이다.

사람을 transport에서 빼되, approver로는 남긴다

고친 방식은 두 가지를 사람의 머리 밖으로 빼는 것이었다.

Durable capture — 떠오른 개선점을 추적 가능한 backlog 한 장에 행으로 적는다. 사람의 기억 대신 파일이 들고 있는다.
Agent-driven routing — 주간 리뷰에서 agent가 backlog와 추세를 읽고, 각 항목에 대해 PR이나 핸드오프 초안을 직접 작성한다.

여기 결정적인 분리가 하나 있다.

병목을 없애는 것은 “무엇이 리뷰를 트리거하느냐”가 아니라 “리뷰가 무엇을 하느냐”다.

트리거는 여전히 사람이 주간에 한 번 당겨도 된다. 하지만 그 한 번의 트리거 뒤에 agent가 핸드오프를 이미 초안해 두면, “사람이 신호를 하나하나 기억해 재전달하거나 아니면 죽는다”가 “사람이 주간에 한 번 트리거하고, agent가 초안한 걸 승인한다”로 바뀐다. per-signal relay가 사라진다. 사람은 transport가 아니라 approver로 남는다.

삽질 ① — “자동 스케줄러로 돌리자”가 틀렸다

처음 떠올린 답은 “주간 자동 리뷰를 스케줄러 잡으로 영구히 돌리자”였다. 그런데 실제 스케줄 기능을 확인해보니 — 그 잡은 세션 스코프이고 약 7일 뒤 자동 만료됐다. “영구 자동 엔진”이 아니었다.

그 추천을 그대로 뒀으면, “매주 자동으로 돈다”고 적어 놓고 일주일 뒤 조용히 멈추는 — 정확히 우리가 고치려던 그 “조용한 증발”을 재현할 뻔했다. 그래서 정정했다. 트리거는 사람이 주간에 한 줄로 시작하고(필요하면 가벼운 리마인더가 찌르는 정도), 병목 제거의 본질은 위에서 말한 agent의 초안 작성에 있다고 명시했다.

교훈: “자동화로 해결”이라고 적기 전에, 그 자동화 수단의 수명·스코프를 먼저 확인하라. 만료되는 자동화는 자동화가 아니다.

삽질 ② — backlog가 다음 ‘dead queue’가 되지 않게

durable list를 만드는 것엔 또 함정이 있다. lifecycle이 없는 list는 병목을 “사람의 기억”에서 “stale TODO 더미”로 옮길 뿐이다. 적어 놓고 아무도 안 보면 똑같이 증발한다.

그래서 backlog를 free-form 메모가 아니라 상태 기계로 만들었다.

각 항목은 필드를 갖는다: 언제 떠올랐나 / 무엇이 surface 했나 / owner는 누구 / 다음 행동 / 상태(open→routed→acting→done/dropped) / 우선순위 / 마지막 리뷰일.
매 사이클의 hard rule: 모든 open 항목을 반드시 touch — 진전시키거나, 재우선순위화하거나, 이유를 적고 닫거나. 손 안 댄 항목을 남기지 못한다.
2사이클 동안 손 안 댄 항목은 STALE로 자동 escalate → 조용히 썩지 않는다.
WIP cap(사이클당 최대 N건만 라우팅) → 전부 쏟아내지 않고 우선순위로 triage.

이 hygiene 규칙이 없으면 backlog는 그냥 더 큰 무덤이 된다.

가져갈 것

주기적 리포트·알림은 그 자체로 가치 0. 닫힌 루프(측정→분석→개선→재측정)를 굴릴 때만 의미가 생긴다.
루프를 단계로 쪼개 끊긴 고리를 찾아라. “measure가 부족”이 아니라 “측정된 게 route되지 않고 증발”인 경우가 많다.
사람이 relay 병목이면, 사람을 transport에서 빼되 approver로 남겨라 — durable backlog가 기억을 대신하고, agent가 초안을 작성하고, 사람은 승인한다.
trigger 자동화 ≠ 병목 제거. 그리고 만료되는 자동화 수단을 영구 엔진으로 착각하지 마라.
durable list엔 anti-rot lifecycle을 박아라 — 매 사이클 전 항목 touch / N사이클 미접촉 escalate / WIP cap. 안 그러면 list가 다음 무덤이 된다.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: monitoring, observability, feedback-loop, process-design, automation, agent-ops