🧑🏻💻 Ep.20 | 관측 가능성과 AI, 장애를 읽는 법
그 주는 처음부터 끝까지 결제 서비스가 말썽이었습니다. 화요일엔 잡힐 듯 안 잡히던 버그, 수요일엔 하마터면 넘어갈 뻔한 평문 비밀번호. 그리고 금요일 새벽, 기어이 알림이 울렸습니다.
노트북을 열었더니 대시보드엔 그래프 수십 개가 동시에 출렁이고, 로그는 분당 수천 줄씩 쌓이고 있었어요. 데이터는 차고 넘치는데, 정작 "왜 터졌나"는 안 보였습니다. 한참을 헤매다 깨달았죠. 제 문제는 데이터가 부족한 게 아니라, 너무 많아서 못 읽는 거였습니다.
관측 가능성의 어려움은 데이터가 없어서가 아니라, 그걸 하나의 이야기로 엮기 어려워서입니다.
1. 데이터가 많다고 보이는 게 아니다
로그, 메트릭, 트레이스. 요즘은 다 찍습니다. 그런데 장애가 나면 여전히 헤매요. 진짜 어려운 건 연결이거든요.
에러율이 올라간 것과 응답 시간이 늘어난 게 같은 원인인지, 이 서비스의 지연이 저 서비스 때문인지 아니면 그 반대인지, 30분 전 배포와 지금 이 증상이 관련 있는지. 흩어진 신호를 하나의 이야기로 엮어야 원인이 보입니다. 데이터를 모으는 건 시스템이 하지만, 그걸 이야기로 읽는 건 여전히 사람의 일입니다.
2. AI가 잘하는 건 패턴과 연결
이 지점에서 AI가 쓸모 있습니다. 사람보다 많은 신호를 동시에 훑는 데 강하거든요.
"이 시간대에 평소와 다른 패턴을 보인 메트릭을 전부 찾아줘", "이 에러 로그들을 비슷한 것끼리 묶고 많은 순으로 정리해줘", "응답 시간이 튄 시점과 겹치는 다른 이벤트가 있어?" 이런 요청에 AI는 지치지 않고 답합니다.
☑️ 수천 줄 로그에서 "튀는 것"을 골라내는 일은, 사람보다 AI가 빠르고 꾸준합니다.
디버깅에서와 같아요. AI는 단서를 모으고 가설을 펼치는 단계에서 힘을 냅니다.
3. 그래도 인과는 사람이 판단한다
여기에 함정이 있습니다. AI는 같이 움직인 것을 잘 찾습니다. 그런데 같이 움직였다고 원인은 아니에요.
에러율과 트래픽이 같이 올랐다면, 트래픽이 원인일 수도 있고 둘 다 다른 것의 결과일 수도 있습니다. 배포 직후 지연이 생겼다면, 그 배포 탓일 수도 있고 마침 겹친 다른 일 탓일 수도 있고요.
☑️ 상관관계와 인과관계는 다릅니다. AI는 상관을 보여주고, 인과는 시스템을 아는 사람이 판단합니다.
AI가 "이 둘이 같이 움직였습니다"라고 하면, 사람은 "그럼 왜 그럴까"를 물어야 합니다. 디버깅 때와 똑같이, 첫 가설에 묶이지 말고 반증할 근거도 같이 찾아야 하고요.
4. 좋은 신호를 미리 심어둔다
AI가 잘 읽으려면, 애초에 읽을 만한 데이터가 있어야 합니다. 쓰레기를 넣으면 쓰레기가 나오니까요.
평소에 신경 쓸 것들이 있습니다.
✔️ 로그에 맥락 담기: 요청 ID, 사용자 단위, 어느 단계인지
✔️ 의미 있는 메트릭 고르기: 다 찍는 게 아니라 장애를 설명할 수 있는 것
✔️ 트레이스로 흐름 잇기: 요청이 어느 서비스를 거쳤는지
관측 가능성은 장애가 났을 때 시작하는 게 아니라 평소에 심어두는 겁니다. AI든 사람이든, 없는 데이터는 못 읽으니까요. 말하자면 "왜를 기록하는 습관"의 운영 버전인 셈입니다.
5. 장애 한복판에서 쓰는 법
실제 장애 상황에서 AI를 어떻게 쓰면 좋을까요. 앞서 말한 도구 이야기와 이어집니다.
모니터링·로그 시스템을 도구로 연결해두면, AI가 직접 조회해서 1차 요약을 해줍니다. "지금 상황을 타임라인으로 정리해줘"라고 하면 흩어진 이벤트를 시간순으로 묶어주고, "지금까지 확인한 것과 남은 가설을 정리해줘"라고 하면 대응 중 헝클어진 머릿속을 정리해줍니다.
☑️ 단, 롤백·트래픽 차단 같은 조치 결정은 사람이 합니다. 자동화 이야기에서와 같이, 판단이 큰 일은 넘기지 않습니다.
AI는 상황을 빠르게 정리해서 사람의 판단을 돕는 자리에 둡니다.
6. 사후에 더 빛난다
장애가 끝난 뒤가 오히려 AI를 쓰기 좋은 시점입니다. 급하지 않고 데이터는 다 쌓여 있으니까요.
"이 시간 동안 무슨 일이 있었는지 순서대로 정리해줘"로 타임라인을 재구성하고, 디버깅 회고에서처럼 사람이 깨달은 걸 포스트모템 초안으로 만들고, "이 장애를 미리 잡으려면 어떤 알림이 있었어야 할까"로 재발 방지를 챙깁니다.
사람이 "무엇을 배웠는지"를 말하면, AI가 그걸 다음 사람이 읽을 기록으로 만들어줍니다. 같은 장애를 두 번 겪지 않는 것, 그게 관측 가능성의 최종 목적이고요.
7. 결국 시스템을 나는 사람이 읽는다
AI는 신호를 빠르게 모으고, 패턴을 찾고, 타임라인을 정리합니다. 그런데 "이 그래프가 왜 이상하지" 하는 위화감을 느끼는 건, 이 시스템을 직접 운영해본 사람입니다.
AI는 장애를 읽는 속도를 올려줍니다. 다만 어디를 봐야 할지, 무엇이 정상이 아닌지 아는 건 시스템을 아는 사람의 몫입니다. 설계 감각이 그렇듯, 이 감각도 운영의 경험에서 옵니다.
데이터는 시스템이 주고, 의미는 사람이 읽습니다. 화요일부터 새벽을 넘긴 그 한 주도, 결국 누군가 로그를 끝까지 읽어내고서야 끝이 났습니다.
🌱 운영과 장애 대응을 실전으로 나누는 곳, 루퍼스
쏟아지는 데이터에서 의미를 읽는 일은 경험에서 나옵니다. 루퍼스에서는 관측 가능성, 장애 대응, 대규모 트래픽 운영 같은 주제를 현업의 경험으로 나눕니다 🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article