추적 대상 11개 도구 전체의 구조 감사를 2026년 10월 23일 직접 HTTP 검사로 진행했다. 노출 수치는 DevTune의 공개 표에서 가져왔다. 90일 보고서와 30일 실시간 페이지는 서로 다른 기간을 사용하며 절대 혼합하지 않는다.

AI 답변은 구매자를 소수의 인시던트 관리 도구로 안내한다. incident.io, Rootly, PagerDuty가 대부분의 자리를 차지한다. 이 범주에서 추적하는 11개 도구가 실제로 유지하는 인용 가능한 자산을 확인하자 불편한 패턴이 드러났다. 구매자가 들어본 적 없는 도구라고 해서 모두 기본 요소가 없는 것은 아니며, 기본 요소를 갖췄다고 인용되는 것도 아니다. 기계가 읽을 수 있는 구성이 가장 완전한 도구들의 노출도는 거의 0이거나 0이다.

간단히 답하면 이렇다. 이 노트의 나머지 부분에서는 근거 데이터를 살펴본다. AI가 현재 인시던트 관리와 온콜에 무엇을 추천하는지, 11개 도구 각각이 어떤 기계 판독 가능 자산과 비교 페이지를 유지하는지, 그리고 도구가 목록에서 빠졌다면 그 차이가 무엇을 뜻하는지 다룬다.

이 글은 진단이지 순위표가 아니다. 다른 매체는 이미 이 도구들의 순위를 매겼다. 여기서는 다른 질문을 던진다. 인용되지 않는 도구는 왜 밀리는가?

현재 AI가 인시던트 관리에 추천하는 것

ChatGPT Search, Perplexity, Gemini Search, Google AI Mode, Bing Copilot은 주로 incident.io, Rootly, PagerDuty 세 브랜드를 구매자에게 안내한다. DevTune의 공개AI 검색 현황 보고서는 2026년 4월 2일부터 6월 30일까지 이 범주의 답변 1,255개를 측정했으며 incident.io는 47.9%, Rootly는 32.7%, PagerDuty는 26.8%에 등장했다. 추적된 모든 브랜드의 범주 중앙값은 12.4%였다.

DevTune은 이 범주의공개 실시간 페이지롤링 30일 기간의 공개 실시간 페이지를 운영한다. 2026년 10월 말 현재도 incident.io가 42.7%, Rootly가 36.7%, PagerDuty가 34.0%로 같은 세 이름이 선두를 유지한다. 해당 페이지에서 주목할 점은 두 가지다.

  • 나머지 도구들은 거의 사라졌다. 30일 기간에서 ilert의 존재율은 2.0%, OneUptime은 0.7%이며 Spike.sh와 Squadcast는 모두 0%다.
  • 인용되는 것과 이름이 언급되는 것은 다르다다. DevTune은 존재(페이지가 출처로 인용됨)와 브랜드 언급(답변에서 선택지로 이름이 나옴)을 구분한다. PagerDuty는 답변의 34%에 존재했지만 이름이 언급된 비율은 0%였다. incident.io는 42.7%에 존재했고 66%에서 이름이 언급됐다.

30일간의 전체 현황은 DevTune의공개 브랜드 표:

순위 브랜드 등장률 브랜드 언급 인용된 쌍
1 incident.io 42.7% 66.0% 64
2 Rootly 36.7% 0% 55
3 PagerDuty 34.0% 0% 51
4 Opsgenie 14.7% 0% 22
5 FireHydrant 11.3% 27.3% 17
6 Better Stack 4.7% 20.0% 7
7 Grafana (IRM) 4.0% 1.3% 6
8 ilert 2.0% 0% 3
9 OneUptime 0.7% 0.7% 1
10 Spike.sh 0% 0.7% 0
11 Squadcast 0% 0% 0

이 표에서 4위는 Opsgenie로, Atlassian 제품이며판매를 중단했으며— 판매는 2025년 6월 4일에 종료됐고 지원은 2027년 4월 5일에 종료될 예정이다. 이는 Atlassian 자체 마이그레이션 페이지에 따른 것이다. 30일 기간에도 해당 페이지는 답변 약 7개 중 1개에서 계속 인용된다. AI 답변은 출처가 작성될 당시 존재했던 근거를 바탕으로 하므로, 문서가 많은 제품은 시장이 바뀐 뒤에도 오랫동안 인용된다.

(이 섹션의 DevTune 수치는 모두 끝에 링크된 두 공개 페이지에서 가져왔으며, 각각 해당 기간을 기준으로 합니다. 90일 보고서와 30일 실시간 페이지는 표본 크기가 다르므로 둘 사이의 작은 차이는 측정 노이즈로 간주하세요.)

확인한 항목과 방법

이 카테고리에서 추적하는 각 브랜드에 대해 답변 엔진이 실제로 활용할 수 있는 인용 가능한 자산을 확인했습니다. 도구 11개를 각각 6개 항목씩 점검했으며, 모두 2026년 10월 23일 직접 HTTP 요청으로 수행했습니다:

  1. llms.txt 도메인 루트에 있는, 기계 판독용 신흥 인덱스 파일
  2. llms-full.txt 단일 파일 버전
  3. robots.txt AI 크롤러 규칙(GPTBot, ClaudeBot, PerplexityBot 등)
  4. 경쟁사 비교 또는 대안 페이지 사이트맵에서
  5. 공개 벤치마크 또는 독창적 연구 콘텐츠
  6. 문서 포털 접근성 (HTTP 상태 및 페이지 제목)

이는 모델 샘플링이 아니라 구조적 사실이다. 각 검사에서 상태 코드와 확인할 수 있는 콘텐츠가 반환되었거나 반환되지 않았다. 서버가 상태 200인 HTML 오류 페이지를 반환한 경우에는 누락으로 계산했다.

감사 결과

11개 도구 중 7개가 유효한 llms.txt를 게시한다. 4개는 llms-full.txt를 게시한다. 2개는 robots.txt에서 AI 봇을 이름으로 명시해 환영하며, 나머지 대부분은 기본적으로 허용한다. 한 도구의 문서는 로그인 장벽 뒤에 있다.

항목 해당 항목이 있는 도구(11개 중) 대상
유효한 llms.txt 7 incident.io, Rootly, FireHydrant, Grafana, ilert, OneUptime, Spike.sh
llms-full.txt 4 Rootly, Grafana, OneUptime, Spike.sh
robots.txt에서 AI 봇을 명시적으로 환영 2 Rootly, OneUptime
비교 또는 대안 페이지 6 incident.io(7페이지), ilert(25), OneUptime(30), Rootly(4), Spike.sh(2), Better Stack(1)
로그인 없이 접근 가능한 문서 10 Squadcast를 제외한 모두
공개 벤치마크 콘텐츠 5 Rootly(게시물 6개), PagerDuty(보고서 1개), incident.io(게시물 1개), Grafana(대시보드 13개), OneUptime(게시물 56개, 인프라 벤치마크)

PagerDuty, Opsgenie, FireHydrant, Grafana는 비교 페이지를 전혀 게시하지 않는다. Squadcast의 sitemap은 SolarWinds 전체 사이트 sitemap으로 리디렉션되어 감사할 수 없었다.

이 표를 존재율 수치와 대조하면 두 가지 발견이 두드러진다.

첫 번째 발견: 기본 요소의 부재는 최하위권을 설명하지만 중위권은 설명하지 못한다.Squadcast가 가장 명확한 사례다. 도메인에 유효한 robots.txt와 llms.txt가 없고, sitemap은 SolarWinds 전체 사이트의 sitemap으로 리디렉션되며, 문서 도메인은 Google 로그인 페이지로 리디렉션된다. 이런 구성은 기계가 콘텐츠를 읽도록 유도하지 않는다. 존재율은 0%다. 진단은 간단하다. 크롤러가 로그인 없이 문서에 접근할 수 없다면 경쟁에 참여하지 못한 것이다.

두 번째 발견: 이러한 자산만으로는 인용이 발생하지 않는다.Spike.sh는 llms.txt, llms-full.txt, 비교 페이지 2개, 완전히 개방된 robots.txt를 관리한다. 30일 기간의 존재율은 0%다. OneUptime은 누구보다 많은 것을 갖췄다. robots.txt에 "AI / LLM crawlers are welcome"이라고 표시하고, 두 llms 파일과 문서용 별도 llms.txt를 게시하며, 비교 페이지 30개를 관리한다. 존재율은 0.7%다. 체크리스트는 전제 조건처럼 작동하고, 인용은 다른 곳에서 나온다.

인용 데이터는 승자가 실제로 무엇에 의존하는지 보여줄까? 30일 기간 동안 DevTune은 이 카테고리의 인용 2,487건을 만든 콘텐츠 구성을 기록했다. 블로그 게시물 31.6%, 문서 24.8%, 비교 페이지 19.1%, 베스트 목록 10.0%, 제품 페이지 8.1%다. 인용된 콘텐츠 중 기업 소유 및 상업 출처가 85.5%, 편집 보도가 9.1%, 커뮤니티 스레드가 1.3%를 차지한다. 90일 보고서에서 incident.io의 선두에 대한 DevTune 자체의 설명은 다음과 같다. "카테고리 교육 콘텐츠가 선두 업체 인용의 대부분을 이끈다." 선두 업체가 받는 인용의 거의 88%는 문서나 제품 페이지가 아니라 블로그 게시물을 가리킨다.

이것이 진짜 격차다. 뒤처지는 도구에 부족한 것은 설정 파일이 아니라 구매자가 질문할 때 답변이 참고하는 전체 증거 자료다. 카테고리 설명, 구체적인 비교, 제3자 목록, 방법론을 담은 벤치마크 게시물이 여기에 해당한다. incident.io는 블로그로 이긴다. Rootly는 Gemini Search가 인용하는 비교 페이지로 이긴다. PagerDuty는 문서만으로 우위를 차지하므로 출처로 인용되지만 선택지로 언급되지는 않는다. 답변에 등장하는 경로는 하나가 아니며, 모든 경로는 게시되고 찾을 수 있는 증거를 거친다.

인용되지 않는 도구는 왜 뒤처지는가

두 데이터 세트를 함께 보면 이 카테고리에서 뒤처지는 도구의 패턴은 다음과 같다:

  • 존재율이 0인 도구는 기껏해야 빈약한 사이트를 기계가 읽을 수 있게 유지한다. 답변 엔진이 "최고의 인시던트 관리 도구"를 정리할 때 카테고리 교육 콘텐츠와 비교 자료를 참고한다. 순위에 오르는 콘텐츠를 하나도 게시하지 않았다면 후보군에 들지 못한다.
  • 문이 있어야 할 곳에 벽이 있다. 로그인으로 막힌 문서(Squadcast), 누락된 robots.txt 파일, 모회사 브랜드에 통합된 도메인(Opsgenie는 Atlassian에, Squadcast는 SolarWinds에)이 콘텐츠에서 답변으로 이어지는 경로를 끊는다.
  • 기계는 Spike.sh와 OneUptime을 읽을 수 있지만 인용할 이유는 없다. 주변 증거가 없으면 llms 파일은 아직 누구도 제시하지 않은 주장을 색인화할 뿐이다.
  • 오래된 선택지는 계속 남는다. 판매 종료일로부터 18개월이 지난 뒤에도 Opsgenie가 계속 등장한다는 점은 답변이 저절로 갱신되지 않음을 보여준다. 이는 양방향으로 작용한다. 누군가 더 나은 증거를 게시할 때까지 AI 답변에서 오늘 차지하는 도구의 위치가 유지된다.

기록해 두고 싶은 단서가 하나 있다. 이번 감사는 구조를 측정했으며 콘텐츠 범위를 측정한 것은 아니다. 제3자 언급, 리뷰 사이트, 커뮤니티 스레드는 집계하지 않았지만 DevTune 데이터에 따르면 이들도 역할을 한다. 구조적 조사 결과는 도구 자체 도메인에서 부족한 점을 설명한다. 특정 브랜드의 수치를 어떤 방법이 움직이는지 입증할 수는 없으며, 고정된 체크리스트가 인용을 보장한다고 주장하는 사람도 믿지 않는다.

도구가 추천 대상에서 빠졌다면 해야 할 일

이 카테고리의 데이터에 맞는 순서는 다음과 같다:

  1. 먼저 접근 경로를 열어라. 유효한 robots.txt, 주요 페이지를 나열한 llms.txt, 크롤러가 로그인 없이 접근할 수 있는 문서를 갖춰라. 11개 도구 중 대부분은 이미 이 기준을 충족한다. 도구가 이 기준을 충족하지 않는다면 목록의 다른 항목은 별 의미가 없다.
  2. 인용 구성에 필요한 페이지를 만들어라. 이 카테고리에서는 카테고리 교육 콘텐츠(인시던트 대응이 무엇인지, 어떻게 선택하는지)와 정직한 비교 페이지를 뜻한다. 선두 업체들의 인용 프로필은 바로 이런 형식이 주를 이룬다.
  3. 제3자 목록에 등장하라. 이 카테고리 인용 10건 중 1건은 다음을 가리킨다:베스트 목록과 리뷰 페이지. 그 페이지들이 똑같은 세 브랜드만 알고 있다면 계속 그 세 브랜드를 추천할 것이다.
  4. 콘텐츠를 최신 상태로 유지하라. Opsgenie가 계속 등장하는 것은 답변이 오랫동안 오래된 증거에 의존한다는 점을 보여준다. 게시 날짜, 현재 가격, 관리되는 비교 자료는 답변 엔진이 설명을 갱신할 이유를 제공한다.

자신의 도구에도 같은 검사를 하고 싶다면, 바로 이것이 제공하는 서비스다:CiteGap의 무료 감사은 다음을 수행한다. 도메인에서 인용 가능한 자산을 점검하고 카테고리에서 실제로 인용되는 콘텐츠와 비교해 부족한 점을 쉬운 말로 알려준다.

무료 라이트 감사 실행

자주 묻는 질문

AI가 가장 자주 추천하는 인시던트 관리 도구는 무엇인가?

DevTune의 90일 보고 기간과 현재 30일 라이브 테이블에서 상위 세 도구는 동일하다. incident.io, Rootly, PagerDuty다. incident.io는 두 기간 모두 선두이며, PagerDuty는 추천 도구로 언급되는 것보다 출처로 인용되는 경우가 더 많다.

AI는 왜 내 인시던트 관리 도구를 한 번도 언급하지 않을까?

이 카테고리에서 가장 흔한 구조적 원인은 근거가 되는 정보망의 부재(카테고리 설명 페이지나 비교 페이지가 없음), 기술적 장벽(로그인이 필요한 문서, llms.txt 부재, 제한적인 robots.txt), 또는 AI 답변이 확립된 출처에 의존하는 분야에서 브랜드가 신생이라는 점이다. 추적 대상인 11개 도구를 모두 감사한 결과, 11개 중 7개에 유효한 llms.txt가 있었고 11개 중 6개에 비교 페이지가 있었다. 존재감이 0인 도구에는 구조나 근거, 또는 둘 다 부족했다.

llms.txt를 게시하면 AI 인용이 보장될까?

아니다. Spike.sh와 OneUptime은 모두 탄탄한 llms 자산을 갖추고 있지만 존재감은 거의 없거나 0이다. llms.txt와 공개된 robots.txt는 기본 요건에 불과해 보인다. 이 카테고리의 인용 데이터는 답변에서 인용할 수 있는 카테고리 안내 콘텐츠와 비교 콘텐츠를 높이 평가한다.

내 개발자 도구가 인용될 수 있는지 어떻게 확인할 수 있을까?

직접구조 점검을 직접 재현할 수 있다 (llms.txt, robots.txt, 문서 접근성, 사이트 sitemap의 비교 페이지 확인), 또는 실행CiteGap의 무료 감사. 이 도구는 점검을 수행하고 카테고리 수준의 비교를 추가한다. 브랜드별 존재감 수치는 DevTune이라이브 테이블을 게시한다이 카테고리의 라이브 테이블을 공개하며, 이 글은 그 데이터를 바탕으로 한다.

출처

  • DevTune, State of AI Search for Dev Tools (데이터 기간 2026년 4월 2일부터 6월 30일까지; 43개 카테고리, 이 카테고리에서 측정한 답변 1,255개):devtune.ai/dev-tools-state-of-ai-search
  • DevTune, Incident Management & On-Call 라이브 브랜드 테이블(최근 30일 기준, 2026년 10월 23일 열람):devtune.ai/verticals/incident-management-and-on-call
  • Atlassian, Opsgenie 마이그레이션 페이지(판매 종료 2025년 6월 4일, 지원 종료 2027년 4월 5일):atlassian.com/software/opsgenie/migration
  • 11개 인시던트 관리 도구의 구조 감사: CiteGap이 2026년 10월 23일에 실시한 직접 HTTP 점검(llms.txt, llms-full.txt, robots.txt, 사이트맵, 문서 접근성)