3 pillars 그 후 — 4 추가 신호의 *6개월 후* 운영 노트
3 pillars 가 더 이상 충분하지 않은 이유 발행 후 6개월. 4 추가 신호 (events / user journeys / deploy correlation / similarity) 가 운영에서 어떻게 작동했는지의 후속.
3 pillars 가 더 이상 충분하지 않은 이유 후 6개월. 4 추가 신호의 운영 평가.
6개월 데이터
신호 | MTTR 기여 (이전 vs 이후) | 운영 부담
─────────────────────────┼──────────────────────────┼─────────────
1. Events | 53 → 31 분 (-22) | 낮음
2. User journeys | 31 → 24 분 (-7) | 중
3. Deploy correlation | 24 → 17 분 (-7) | 중간
4. Similarity matching | 17 → 23 분 (+6) *후퇴* | 높음Similarity matching 이 역효과. 이유는 다음 섹션.
4 신호의 진짜 가치 vs 운영 부담
Events — 가장 높은 ROI
이벤트 stream 박는 데 2주. MTTR -22 분. ROI 가장 큼. 모든 조직이 제일 먼저 박아야 할 신호.
User journeys — 좋지만 비싸다
journey 추적에 데이터 수집 + 저장 비용 큼. MTTR -7 분. 여전히 양수 ROI 지만 Events 의 1/3.
Deploy correlation — 의외로 복잡
각 deploy 와 영향 받은 metric / segment 자동 매핑이 예상보다 어려움. 수동 라벨링 으로 보완 필요. MTTR -7 분.
Similarity matching — 후퇴
가장 큰 발견. 과거 인시던트 vector matching 이 false positive 가 너무 많음. 첫 알람과 함께 5개의 비슷한 과거 사례 가 떴는데, 5개 중 1개만 진짜 관련. 나머지 4개를 검토 / 기각 하는 데 시간 추가.
해결 시도 — vector similarity 임계 0.7 → 0.95 로 올림. false positive 줄음. 하지만 진짜 비슷한 케이스 도 놓침. 재현율 -50%.
결론 — similarity matching 은 현재 상태로는 net negative. 별도 명시적 검색 (사람이 trigger) 으로 후퇴.
6개월의 누적 효과
시작 MTTR: 53 분 (3 pillars 만)
종료 MTTR: 23 분 (3 pillars + 3 신호, similarity 제외)
순 개선: -30 분 (-57%)원래 4 신호로 23분 예상했지만 similarity 제거 후 23분. similarity 가 net negative 인 발견이 6개월의 가장 큰 학습.
다음 6개월의 시도
similarity matching 의 net positive 패턴 — 우리 가설:
- 수동 trigger 시 만 vector search 활성화
- 2 단계 검색 — 첫 단계 1차 매칭, 두 번째 단계 사람이 어느 게 비슷한지 선택
- 과거 사례를 자동 표시 가 아니라 사람이 검색 하면 보여줌
이 패턴으로 Q3 측정 예정.
3 pillars 위에 4번째 신호를 얹으려는 SRE / 플랫폼 리드라면 이 6개월 MTTR 데이터 (53 → 23 분) 가 출발점. 우리 숫자는 우리 워크로드 한정 이지만, similarity matching 의 false positive 문제는 공통 함정 일 가능성. 도입 전 에 명시적 trigger 모드부터.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백