온콜 장애 대응, AI가 런북을 자동으로 실행해준다면? — Relvy 소개

새벽 3시 알림, 그리고 런북 찾기

개발자라면 한 번쯤은 겪어봤을 거예요. 새벽에 PagerDuty나 Slack 알림이 울리고, 잠결에 노트북을 열어서 뭐가 문제인지 파악하려고 하는데, 머리가 안 돌아가서 런북(runbook)을 찾아 헤매는 그 상황. 런북이 뭐냐면, 특정 장애 상황에서 어떤 순서로 뭘 확인하고 어떻게 조치해야 하는지 정리해놓은 매뉴얼이에요. "CPU 사용량이 90% 넘으면 → 이 대시보드 확인 → 이 서비스 재시작 → 이 로그 확인" 이런 식으로요.

문제는, 런북이 있어도 잘 관리 안 되는 경우가 많다는 거예요. 작성된 지 1년이 넘어서 현재 인프라랑 안 맞거나, Confluence 어딘가에 묻혀 있어서 급할 때 못 찾거나, 아예 특정 시니어 개발자의 머릿속에만 존재하는 "암묵지"인 경우도 흔하죠. Y Combinator F24 배치에서 나온 Relvy라는 스타트업이 바로 이 문제를 풀려고 해요.

Relvy가 하는 일

Relvy는 한마디로 온콜 런북을 AI로 자동화하는 서비스예요. 기존의 온콜 대응 흐름을 생각해보면 이래요: 알림 발생 → 사람이 알림 확인 → 런북 찾기 → 런북에 따라 수동으로 진단 → 조치. Relvy는 이 과정에서 "런북 찾기"부터 "진단"까지를 AI 에이전트가 자동으로 수행하도록 만들어요.

구체적으로 어떻게 동작하는지 살펴볼게요. 먼저, 모니터링 시스템(Datadog, PagerDuty 등)에서 알림이 발생하면 Relvy가 이를 감지해요. 그러면 Relvy의 AI 에이전트가 해당 알림의 맥락을 분석하고, 관련된 런북을 자동으로 찾아서 실행해요. 여기서 "실행"이란 단순히 문서를 보여주는 게 아니라, 런북에 적힌 진단 단계를 실제로 수행하는 거예요. 로그를 확인하고, 메트릭을 조회하고, 관련 서비스의 상태를 체크하는 작업을 AI가 대신 하는 거죠.

그리고 이 결과를 온콜 담당자에게 요약해서 전달해요. "이 알림은 이런 원인일 가능성이 높고, 런북에 따라 확인해보니 이런 상태입니다. 이런 조치가 필요해 보입니다" 같은 식으로요. 온콜 담당자는 새벽에 머리 싸매고 여러 대시보드를 돌아다닐 필요 없이, Relvy가 정리해준 컨텍스트를 보고 판단만 하면 되는 거예요.

왜 지금 이런 도구가 필요한가

최근 몇 년간 인프라가 점점 복잡해지면서 온콜 부담이 크게 늘었어요. 마이크로서비스 아키텍처가 보편화되면서 서비스 간 의존성이 복잡해졌고, 하나의 장애가 여러 서비스에 연쇄적으로 영향을 미치는 경우가 많아졌거든요. 이런 환경에서 사람이 직접 모든 맥락을 파악하고 진단하는 건 점점 어려워지고 있어요.

또한 온콜 피로(on-call fatigue)는 개발자 이직의 주요 원인 중 하나예요. 특히 스타트업이나 작은 팀에서는 온콜 로테이션이 빡빡해서, 한 달에 일주일 이상 새벽 알림에 시달리는 경우도 있잖아요. 런북 자동화가 이 부담을 줄여줄 수 있다면, 개발자 경험(DX) 측면에서 큰 의미가 있어요.

비슷한 도구들과의 비교

사실 온콜 자동화 영역에는 이미 여러 플레이어가 있어요. PagerDuty는 인시던트 관리 플랫폼의 대표주자이고, 최근에는 AI 기반 분석 기능을 추가하고 있어요. Shoreline.io(현재 Elastic에 인수됨)는 자동 복구(auto-remediation) 도구로, 특정 조건에서 자동으로 스크립트를 실행해주는 기능을 제공했어요. Rootly나 Firehydrant 같은 도구들도 인시던트 관리를 자동화하는 데 집중하고 있고요.

Relvy가 차별화하려는 지점은 런북을 중심으로 한 진단 자동화에요. 기존 도구들이 알림 라우팅이나 인시던트 관리에 초점을 맞추고 있다면, Relvy는 "알림이 왔을 때 실제로 뭘 확인해야 하는지"를 자동화하는 데 집중해요. 즉, 인시던트 관리의 "두뇌" 역할을 하겠다는 거죠.

다만, 아직 초기 단계의 스타트업이라 몇 가지 우려 사항도 있어요. AI가 진단을 자동으로 수행한다는 건 프로덕션 환경에 대한 읽기 권한을 AI에게 준다는 뜻이거든요. 보안과 권한 관리가 어떻게 되는지, 잘못된 진단이나 조치를 했을 때 어떤 안전장치가 있는지 같은 부분은 도입 전에 꼼꼼히 확인해야 해요.

한국 개발자에게 주는 시사점

한국의 많은 스타트업과 테크 기업에서도 온콜 문화가 자리잡아가고 있어요. 카카오, 토스, 배민 같은 곳에서는 이미 체계적인 온콜 시스템을 운영하고 있고, 중소 규모의 팀에서도 PagerDuty나 Opsgenie를 도입하는 경우가 늘고 있어요.

Relvy를 당장 도입하지 않더라도, 이 서비스가 제시하는 방향성은 참고할 만해요. 런북을 코드처럼 관리하자는 개념인데요. 런북을 Confluence 같은 위키에 자유 형식으로 적는 대신, 구조화된 형태(예: YAML이나 마크다운 템플릿)로 관리하면, 나중에 AI 도구를 연동하기도 쉽고, 런북 자체의 품질도 올라가요.

실무에서 바로 해볼 수 있는 것: 기존 런북을 점검하면서 "이 런북의 각 단계를 스크립트로 바꿀 수 있을까?"라고 자문해보세요. 자동화할 수 있는 부분이 의외로 많을 거예요. 간단한 셸 스크립트나 Python 스크립트로 진단 단계를 자동화하는 것부터 시작하면, Relvy 같은 도구 없이도 온콜 부담을 줄일 수 있어요.