관찰 가능성 구축 가이드: 모니터링을 ‘그래프’에서 ‘설명’으로 전환하기

# IT 시스템 모니터링과 관찰 가능성 구축 가이드  모니터링은 그래프를 그리는 일이 아니라, 실패를 예측 가능한 사건으로 바꾸는 일이다. 그러나 많은 팀은 “보인다”는 상태와 “설명할 수 있다”는 상태를 혼동한다. 이 혼동이 알람 폭격, 조용한 장애, 대시보드 관광을 낳는다. 운영의 목적은 장애를 없애는 데 있지 않다. 장애는 형태를 바꾸며 되돌아온다. 운영의 목적은 장애를 **설명 가능하고 재현 가능한 사건**으로 낮추는 데 있다. --- ## 1) 정의를 먼저 세운다: 모니터링과 관찰 가능성의 분리 모니터링과 관찰 가능성은 겹치지만 동일하지 않다. 정의를 분리하면, 이후의 모든 선택이 정렬된다. 정렬은 운영에서 사치가 아니라 비용 절감의 다른 이름이다. ### 모니터링: 알려진 실패를 감지하는 장치 모니터링은 “무엇이 정상인지”를 전제로 한다. CPU 사용률, 오류율, 지연 시간 같은 지표는 기준선을 갖는다. 기준선을 벗어나면 경보를 울린다. 이 방식의 강점은 단순함이다. 약점도 단순하다. **모르는 실패**에는 무력하다. ### 관찰 가능성: 모르는 실패를 설명할 수 있는 능력 관찰 가능성은 결과에서 원인을 복원하는 능력이다. 장애가 발생했을 때, “어디서부터 무너졌는가”를 추적한다. 여기서 핵심은 데이터의 양이 아니라 **구조적 연결성**이다.  관찰 가능성은 도구로 시작하지만, 도구로 끝나지 않는다. 식별자, 시간, 샘플링, 카디널리티, 보관 정책 같은 설계가 필요하다. 결국 이는 팀의 질문 방식, 즉 진단 문화의 형식화다. > 모니터링이 “알려진 경고등”이라면, 관찰 가능성은 “원인 규명 장치”다. --- ## 2) 현장에서 먼저 무너지는 것들: 붕괴 지점부터 역순으로 운영 시스템은 보통 “구축”에서 무너지지 않는다. “운영”에서 무너진다. 따라서 실패 패턴부터 역순으로 다루는 편이 실용적이다. ### 알람이 너무 많아 결국 무시된다: 알람 피로의 구조 알람을 늘리면 마음은 편해지지만, 팀은 둔해진다. 알람은 주의력을 소비한다. 주의력은 운영에서 가장 희소한 자원이다. 알람 피로는 단순히 “알람이 많다”의 문제가 아니다. **알람이 행동으로 이어지지 않는다는 사실**이 문제다. 울려도 아무도 움직이지 않는 알람은, 시스템이 아니라 사람을 학습시킨다. 무시하도록. 알람을 줄이는 기준은 기술이 아니라 약속이다. “울리면 누가 무엇을 언제까지 한다”가 없는 알람은 삭제 대상이다. 그 알람은 신호가 아니라 소음이다. **알람 점검 체크리스트** - 이 알람은 사용자의 피해와 직접 연결되는가 - 울렸을 때 15분 내 첫 조치가 가능한가 - 동일 원인으로 연쇄 울림이 발생하지 않는가(중복/폭주) - 임계치가 ‘감’이 아니라 근거(최근 분포, SLO) 위에 있는가 - 조치가 런북으로 연결되는가(링크 하나라도) ### 장애 때 로그가 없거나, 시간이 맞지 않는다: 상관관계 단절 장애가 났는데 로그가 없다는 말은 종종 정확하지 않다. 보통은 “로그는 있는데 연결이 없다”가 더 정확하다. 서비스 A의 로그와 서비스 B의 로그가 같은 사건을 말하지 못한다. 상관관계는 두 가지 축에서 끊긴다. 첫째는 **시간**이다. 시스템 시간이 어긋나면 사건의 순서가 무너진다. 둘째는 **식별자**다. 요청 ID, 트레이스 ID가 없으면 경로를 복원할 수 없다. 관찰 가능성의 최소 조건은 화려한 대시보드가 아니다. **동일 사건을 동일 식별자로, 동일 시간 축에서** 볼 수 있어야 한다. 여기서부터 “왜”가 가능해진다. **구조를 만드는 최소 합의** - 모든 진입 요청에 correlation id를 부여하고 하위 호출로 전파 - 로그에 trace_id / span_id 또는 동등한 식별자를 포함 - 타임스탬프는 표준 형식으로 기록하고, 시간 동기화 정책을 명시 - 장애 시점의 샘플 로그가 아니라, 재현 가능한 조건(파라미터/버전)을 남김 ### 대시보드는 예쁜데 “행동”이 없다: 대시보드 관광의 함정 대시보드는 종종 결과물로 취급된다. 그러나 운영에서 대시보드는 결과물이 아니라 **작전 지도**다. 작전 지도에는 경로와 규칙이 있어야 한다. 대시보드가 실패하는 전형은 이렇다. 그래프는 많고, 질문은 없다. 누구도 “이 수치가 변하면 무엇을 한다”를 말하지 못한다. 대시보드는 두 종류로 나뉘어야 한다. 첫째는 온콜이 보는 **즉시 진단 대시보드**다. 둘째는 개선을 위한 **추세/용량 대시보드**다. 이 둘을 섞으면, 둘 다 실패한다. 온콜 화면에 장기 추세를 넣으면 판단이 느려진다. 추세 화면에 즉시 진단을 넣으면 개선이 피상화된다. ### 비용이 폭발하거나, 반대로 데이터가 비어 있다: 관측의 경제학 관측 데이터는 “더 많이”가 곧 “더 좋게”가 아니다. 특히 로그와 트레이스는 비용이 선형으로 늘지 않는다. 카디널리티가 폭발하면, 비용은 예측 불가능해진다. 반대로 비용이 두려워 데이터를 비우면, 장애는 설명 불가능해진다. 이때 팀은 두 번 비용을 낸다. 첫째는 관측 비용을 아꼈고, 둘째는 장애 비용으로 더 크게 지불한다. 따라서 관측은 기술이 아니라 **예산과 위험의 교환**이다. 무엇을 포기했는지 기록하는 팀이 오래 간다. 샘플링, 보관 기간, 해상도, 태그 정책은 “기술 설정”이 아니라 “운영 합의”다. --- ## 3) Logs / Metrics / Traces를 ‘수집’이 아니라 ‘질문’으로 엮기 3대 신호는 목록이 아니다. 장애 순간의 질문을 끝까지 밀어붙이기 위한 언어다. 따라서 설계의 출발점은 “도구”가 아니라 “질문 흐름”이어야 한다. ### 질문 흐름의 표준 형태 현장에서 가장 자주 쓰이는 흐름은 대체로 다음 순서를 가진다. 1) 사용자가 느리다고 말한다 2) 어디가 느린가(경로) 3) 어떤 조건에서 느린가(재현) 4) 언제부터 느렸나(변화점) 5) 무엇이 바뀌었나(배포/설정/트래픽) 이 흐름을 3대 신호에 대응시키면 구조가 생긴다. - Traces: “어디가 느린가”를 경로로 보여준다 - Logs: “어떤 조건에서”를 문맥으로 남긴다 - Metrics: “언제부터”를 변화점으로 찍는다 ### 트레이스: 경로를 얻되, 읽을 수 있어야 한다 분산 트레이싱은 이제 검토 대상이라기보다 표준에 가깝다. 특히 OpenTelemetry는 수집과 전파의 공통 언어로 자리 잡았다. 하지만 표준이 도입을 보장하지는 않는다. 트레이스의 함정은 “데이터는 있는데 팀이 읽지 않는다”는 데 있다. 스팬이 많아도, 서비스 경계가 불명확하면 진단이 느리다. 따라서 처음에는 넓게가 아니라 **핵심 경로에 깊게**가 낫다. 실무적 권장 순서가 있다. - 외부 요청 진입점 1~2개를 정한다(핵심 사용자 여정) - 해당 경로의 주요 의존성(DB, 캐시, 외부 API)만 스팬으로 묶는다 - 지연의 상위 원인(대기, 재시도, 큐잉)이 구분되도록 속성을 설계한다 ### 로그: 포렌식이 아니라 재현을 위한 기록 로그는 사건의 흔적이지만, 흔적만으로는 부족하다. 장애 분석에서 로그의 가치는 “증거”보다 “재현 조건”에 있다. 재현이 가능하면, 문제는 기술 문제로 환원된다. 따라서 로그 설계의 핵심은 형식과 식별자다. - 구조화 로그(JSON 등)를 기본으로 한다 - trace_id, request_id, user_impact(가능한 범위) 같은 연결 고리를 넣는다 - 오류 로그에는 원인 분류를 위한 코드(에러 타입, 의존성 이름)를 남긴다 다만 로그는 가장 쉽게 비용을 폭발시킨다. 특히 고카디널리티 필드를 무분별하게 태그로 올리면, 검색과 저장이 함께 무너진다. “검색 편의”와 “비용/성능”은 늘 교환 관계다. ### 지표: 요약의 언어, 알람의 기반 지표는 세부를 버리고, 추세를 얻는다. 그래서 알람의 기반이 된다. 그러나 지표가 현실을 대체할 수는 없다. 지표 설계에서 자주 발생하는 오류는 두 가지다. 첫째, 모든 것을 지표로 만들려는 욕심이다. 둘째, 지표가 “행동 임계치”가 아니라 “관찰용 숫자”로 남는 것이다. 지표는 다음 두 층으로 나누는 편이 안전하다. - 서비스 건강 지표: 오류율, 지연 시간, 트래픽, 포화도 - 원인 후보 지표: GC, 큐 길이, DB 커넥션, 캐시 히트율 등 첫 층은 알람과 연결되고, 둘째 층은 진단과 연결된다. 이 분리가 없으면 알람이 원인 후보로 과적재된다. 그 순간 알람은 늘어나고, 책임은 흐려진다. --- ## 4) 알람 설계의 중심축: SLO, 그리고 현장 타협 SLO 중심 설계는 원칙으로는 탁월하다. 그러나 많은 팀이 “완벽한 SLO”를 기다리다 아무것도 못 한다. 운영에서 완벽주의는 종종 방치의 다른 이름이 된다. 핵심은 단계적 접근이다. SLO는 문서가 아니라 운영 체계에 붙어야 한다. 붙는 순간부터, 알람은 신호가 아니라 **약속**이 된다. ### 1단계: 핵심 사용자 여정 1~2개만 SLO화 처음부터 모든 엔드포인트를 SLO로 만들 필요가 없다. 핵심은 사용자 피해를 대표하는 경로를 잡는 것이다. 대표적인 시작점은 다음과 같다. - 로그인, 결제, 검색 같은 핵심 트랜잭션 - 외부 고객이 직접 체감하는 API 상위 1~2개 - 내부 서비스라면 상위 소비자(consumer)가 의존하는 핵심 기능 여기서 SLI는 대개 지연 시간과 오류율로 충분하다. 정교함보다 지속성이 낫다. ### 2단계: 에러버짓을 변경 관리와 연결 SLO가 “좋은 지표”로만 남으면, 알람은 줄지 않는다. 에러버짓을 배포와 연결해야 한다. - 에러버짓이 빠르게 소진되면 변경을 보수적으로 - 에러버짓이 충분하면 실험을 허용 이 연결이 생기면, 운영은 사후 대응에서 사전 조율로 이동한다. 모니터링이 “사건 감지”를 넘어 “조직 의사결정”이 된다. ### 3단계: 성숙도에 따라 알람은 줄이고, 디버깅 신호를 늘린다 성숙한 서비스는 알람이 많지 않다. 대신 디버깅 신호가 풍부하다. 알람은 적지만, 울리면 빠르게 원인을 좁힐 수 있다. 이 단계에서는 다음의 교환을 의식해야 한다. - 알람 수 감소 ↔ 런북 품질 상승 - 임계치 단순화 ↔ 트레이스/로그의 연결성 강화 - 즉시 대응 자동화 ↔ 자동화 실패 시 안전장치 알람이 줄어드는 만큼, “조용한 장애”의 위험은 늘 수 있다. 따라서 알람 감소는 관찰 가능성의 성숙을 전제로 한다. 줄이는 것 자체가 목표가 되면, 팀은 더 어두워진다. --- ## 5) 짧은 장애 서사: OOM이 남긴 교훈(증상→진단→개선) 장애는 대개 단순한 형태로 시작한다. 예컨대 프로세스가 OOM으로 강제 종료되고, 재기동을 반복한다. 처음 보이는 증상은 “간헐적 5xx 증가” 정도다. ### 당시 보였던 것: 지표의 경고는 있었으나, 원인이 흐렸다 지표는 메모리 사용량 상승과 재기동 횟수 증가를 보여줬다. 오류율도 함께 올랐다. 따라서 “무언가가 터졌다”는 사실은 빨리 알 수 있었다. 하지만 무엇이 메모리를 먹는지, 어느 요청이 촉발하는지 알기 어려웠다. 알람은 있었지만 행동이 느렸다. 알람은 증상을 말했고, 원인을 말하지 못했다. ### 당시 안 보였던 것: 상관관계가 끊긴 로그와 트레이스 로그는 남아 있었으나 요청 단위로 묶이지 않았다. 트레이스는 부분적으로만 있었고, 문제 구간이 비어 있었다. 결국 재현을 위해 운영자가 임시 로그를 추가하고 재배포를 했다. 이 순간 팀은 비용을 두 번 낸다. 첫째는 장애 비용, 둘째는 긴급 변경 비용이다. 관찰 가능성이 부족할 때 반복되는 장면이다. ### 이후 바꾼 것: “알람 기준”이 아니라 “설명 구조”를 바꾼다 개선의 중심은 임계치 조정이 아니었다. 구조를 바꿨다. - 핵심 요청에 trace_id 전파를 강제하고, 로그에 포함 - 메모리 급증 시점의 상위 경로를 트레이스로 확인 가능하게 구성 - OOM 위험을 ‘메모리 사용률’ 하나로 알리지 않고, 포화도와 재기동 패턴을 함께 보게 구성 - 알람에는 런북 링크와 첫 조치(덤프 수집, 최근 배포 확인)를 명시 알람은 여전히 울린다. 그러나 이후에는 “무슨 일이냐”가 아니라 “왜 그러냐”로 곧장 들어갈 수 있었다. 이 차이가 복구 시간을 결정한다. --- ## 6) 2026년의 선택지: 표준, 저수준 관측, 그리고 LLM의 유혹 도구의 진화는 빠르다. 그러나 운영의 본질은 느리게 바뀐다. 따라서 최신 트렌드는 “도입”이 아니라 “질문을 더 잘 만들었는가”로 평가해야 한다. ### OpenTelemetry: 사실상의 공통 언어, 그러나 운영 설계는 별개다 OpenTelemetry는 수집 표준을 제공한다. 표준화의 가치는 크다. 벤더 종속을 줄이고, 이식성을 높인다. 하지만 표준이 곧 품질은 아니다. - 어떤 스팬이 의미 있는가 - 어떤 속성이 진단에 필요한가 - 샘플링을 어디서 할 것인가 이 질문은 여전히 팀의 몫이다. 표준은 “가능성”을 주고, 설계는 “질서”를 만든다. ### eBPF 기반 관측: 강력하지만, 데이터만 많아지는 함정 eBPF 기반 관측은 시스템/네트워크 레벨에서 많은 것을 드러낸다. 특히 커널 수준의 병목이나 네트워크 지연을 잡는 데 유리하다. 다만 팀 역량과 디버깅 문화가 없으면 결과는 단순하다. 데이터만 늘어난다. 저수준 관측은 “정확한 질문”이 있을 때 가치가 커진다. 예컨대 애플리케이션 지표로는 설명되지 않는 지연이 있을 때, 커널/네트워크 관측이 빛난다. 반대로 늘 켜두고 “언젠가 쓰겠지”로 접근하면 비용과 복잡성만 남는다. ### LLM을 운영에 붙일 때의 원칙: 요약은 돕되, 결론은 훔치지 말 것 알람 요약, 런북 추천, 로그 클러스터링은 분명 유용하다. 운영자는 텍스트의 홍수 속에서 시간을 잃는다. 요약은 시간을 되돌려준다. 그러나 LLM의 자동 결론은 위험하다. 근거가 빈약한 확신은, 운영에서 사고를 확장한다. 따라서 역할을 제한하는 편이 안전하다. - 요약: 사건의 타임라인 정리, 관련 지표/로그 링크 묶기 - 추천: 런북 후보 제시, 과거 유사 장애 티켓 연결 - 금지에 가까운 영역: 원인 단정, 자동 조치의 무검증 실행 운영은 책임의 기술이다. 책임이 흐려지는 자동화는, 결국 팀을 약하게 만든다. --- ## 7) 추천 스택이 아니라, 결정 기준표 제품 나열은 오래 못 간다. 팀의 조건이 다르기 때문이다. 따라서 “무엇을 쓰는가”보다 “무엇을 감당하는가”가 먼저다. ### 결정 기준표(간단 버전) | 결정 항목 | 선택 기준 | 포기하는 것 | |---|---|---| | 로그 수집/검색 | 구조화 로그, 인덱싱 정책, 접근 권한 | 디버깅 편의 vs 비용/성능 | | 지표 저장 | 카디널리티 제한, 보관 기간, 다운샘플링 | 해상도 vs 비용 | | 트레이싱 | 핵심 경로 우선, 샘플링 전략 | 전체 가시성 vs 오버헤드 | | 알람 라우팅 | 온콜 체계, 소유권 명확화 | 즉시성 vs 팀 부담 | | eBPF 관측 | 명확한 저수준 질문이 있을 때 | 단순성 vs 깊이 | | LLM 보조 | 요약/연결 중심, 근거 링크 필수 | 속도 vs 책임 | 이 표의 목적은 답을 주는 데 있지 않다. 팀이 무엇을 포기하는지 자각하게 하는 데 있다. 자각은 운영에서 재발 방지의 출발점이다. --- ## 8) 내일 바로 할 수 있는 7가지(작업 티켓 형태) 1. 알람 목록을 펼치고, “울리면 누가 무엇을 하는가”가 없는 항목을 표시한다. 2. 핵심 사용자 여정 1개를 정하고, 오류율/지연 시간 SLI를 하나씩 만든다. 3. 모든 서비스 로그에 공통 필드(trace_id 또는 동등 식별자, 버전, 환경)를 합의한다. 4. 대시보드를 “온콜 진단용”과 “추세/용량용”으로 분리한다. 5. 트레이싱은 넓게가 아니라, 핵심 경로에 깊게 심는다(의존성 3개부터). 6. 로그/트레이스/지표의 보관 기간과 샘플링을 문서화하고, 무엇을 포기했는지 한 줄로 남긴다. 7. 알람 메시지에 런북 링크를 붙이고, 첫 조치 3줄을 적는다. --- ## 결론: 관찰 가능성은 ‘설명 가능한 사건’으로 만드는 질서 관찰 가능성은 도구의 문제가 아니라, 장애를 설명할 수 있는 구조를 설계하는 일이다. 알람은 많을수록 안전한 것이 아니라, 울렸을 때 반드시 행동으로 이어질 만큼만 존재해야 한다. Logs/Metrics/Traces는 각각의 수집이 목적이 아니라, “왜”를 끝까지 밀어붙이기 위한 언어다. 관찰 가능성이란, 장애를 없애는 기술이 아니라 장애를 설명 가능한 사건으로 만드는 질서다.