makgol's note – SREhttps://docs.makgol.com/sre/Recent content in SRE on makgol's noteHugo -- gohugo.ioko-KR© 2026 MontSun, 01 Nov 2026 00:00:00 +090001 SRE는 운영 문제를 어떻게 엔지니어링으로 푸는가https://docs.makgol.com/sre/01-what-is-sre/Sun, 01 Nov 2026 00:00:00 +0900https://docs.makgol.com/sre/01-what-is-sre/ <h1>01 · SRE는 운영 문제를 어떻게 엔지니어링으로 푸는가</h1><blockquote> <p>영어 위키백과 <a href="https://en.wikipedia.org/wiki/Site_reliability_engineering"target="_blank" rel="noopener">Site reliability engineering</a> 항목의 2026-10-04 판을 바탕으로 구성했습니다. 용어와 실무 설명은 <a href="https://sre.google/sre-book/table-of-contents/"target="_blank" rel="noopener">Google SRE 책</a>을 참고해 보충했습니다.</p> </blockquote> <p>SRE도 서비스를 운영합니다. 사이트 신뢰성 엔지니어링(SRE)은 그 운영을 소프트웨어 공학의 문제로 다루는 방식입니다. 배포가 이어지고 장비가 고장 나며 예상하지 못한 트래픽이 몰리는 환경에서 변경 관리, 모니터링, 장애 대응, 용량 계획을 맡습니다. 서비스의 가용성·지연 시간·성능·효율을 살피면서, 장애 복구에 같은 수작업이 반복된다면 코드와 설계를 바꿔 사람의 개입을 줄입니다.</p>02 AI가 장애를 해결할 때 SRE는 어디서 경험을 쌓나https://docs.makgol.com/sre/02-ai-deskilling-sres/Sun, 01 Nov 2026 00:00:00 +0900https://docs.makgol.com/sre/02-ai-deskilling-sres/ <h1>02 · AI가 장애를 해결할 때 SRE는 어디서 경험을 쌓나</h1><p>AI가 복구를 앞당겼다면, 사람이 그 원인과 조치를 이해했는지도 따로 확인해야 합니다. 속도만으로는 알 수 없습니다. 이 글은 AI가 제시한 근거를 직접 확인하고, 해결 과정을 자신의 말로 설명하는 연습을 업무에 남기자고 제안합니다.</p>03 USE Method로 느린 서비스의 자원 병목 좁히기https://docs.makgol.com/sre/03-use-method/Sun, 01 Nov 2026 00:00:00 +0900https://docs.makgol.com/sre/03-use-method/ <h1>03 · USE Method로 느린 서비스의 자원 병목 좁히기</h1><p>CPU 사용률이 낮다는 이유로 서버의 자원 조사를 끝내기는 어렵습니다. 한 CPU에 작업이 몰렸거나, 짧은 대기가 긴 평균에 가려졌을 수 있습니다. 물리 자원에 여유가 있어도 애플리케이션의 연결 풀이 먼저 한도에 닿는 경우가 있습니다.</p>04 RED Method로 요청량·실패·지연을 함께 읽는 기준https://docs.makgol.com/sre/04-red-method/Sun, 01 Nov 2026 00:00:00 +0900https://docs.makgol.com/sre/04-red-method/ <h1>04 · RED Method로 요청량·실패·지연을 함께 읽는 기준</h1><p>서버에 여유가 있어도 요청은 실패하거나 늦게 끝날 수 있습니다. CPU와 메모리 사용률만으로는 사용자가 겪는 문제가 드러나지 않을 수 있습니다. 서비스가 받은 요청이 얼마나 많았는지, 그중 얼마나 실패했는지, 처리에 얼마나 걸렸는지를 함께 살펴봅니다.</p>05 Four Golden Signals로 사용자 영향과 한계 읽기https://docs.makgol.com/sre/05-four-golden-signals/Sun, 01 Nov 2026 00:00:00 +0900https://docs.makgol.com/sre/05-four-golden-signals/ <h1>05 · Four Golden Signals로 사용자 영향과 한계 읽기</h1><p>주문이 느리다는 신고를 받았다면 요청의 지연과 실패부터 확인합니다. CPU 그래프만으로는 사용자가 겪는 지연과 실패를 놓칠 수 있기 때문입니다. 들어오는 요청량과 자원의 여유를 함께 살피면 어느 구간을 조사할지 좁히기 쉬워집니다.</p>