Gitae를 만든 이유는 계속 같은 실무적 질문을 마주했기 때문입니다. 웹사이트가 정말 다운된 것인가, 아니면 문제는 내 쪽에만 있는가?
브라우저 탭 하나만으로는 제대로 진단하기 어렵습니다. 페이지가 열리지 않는 이유가 origin server 장애일 수도 있지만, DNS, HTTPS 인증서, routing, firewall 규칙, 닫히거나 필터링된 포트, ISP, VPN 경로, 브라우저 상태, 로컬 cache 때문일 수도 있습니다. 눈에 보이는 증상은 같지만 필요한 조치는 완전히 다릅니다.
제가 Gitae로 해결하고 싶었던 것은 바로 이것입니다. 단순히 초록색이나 빨간색 상태를 보여주는 대신, 다음에 어느 layer를 조사해야 하는지 좁혀 주는 도구를 만들고 싶었습니다.
“사이트가 다운됐다” 뒤에 있는 실제 문제
많은 간단한 website checker는 아주 좁은 질문에 답합니다. 특정 URL이 특정 시점에 특정 위치에서 응답했는가? 유용한 정보지만, 그것만으로 outage 원인을 진단한 것은 아닙니다.
DNS가 잘못되었으면 application을 재시작해도 고쳐지지 않습니다. HTTPS가 certificate 문제로 실패한다면 page content를 바꾸는 것은 의미가 없습니다. TCP port에 접근할 수 없어도 server 자체는 살아 있을 수 있습니다. 외부 server에서는 열리는데 제 연결에서만 열리지 않는다면, 문제는 application server가 아니라 제 network와 목적지 사이 경로에 있을 수도 있습니다.
그래서 Gitae는 다음과 같은 모델을 중심으로 만들었습니다. 웹사이트는 여러 dependency가 이어진 chain이고, 각 check는 그 chain의 일부에 대한 증거만 제공한다.
외부 시점은 유용하지만 절대적인 답은 아니다
Gitae의 검사는 제 VDS server가 있는 모스크바와 헬싱키에서 실행됩니다. 처음 문제가 보였던 컴퓨터와 network 밖에서 추가 관측 지점을 얻을 수 있다는 점이 중요합니다.
로컬에서는 실패하지만 두 VDS에서 모두 응답한다면, origin이 최소한 모든 곳에서 완전히 unreachable한 것은 아니라는 중요한 신호입니다. 그 경우 local DNS, ISP routing, VPN, browser, firewall 또는 특정 network path에 의존하는 문제를 더 먼저 봅니다. remote probe에서도 실패한다면 server, DNS, certificate, routing 또는 더 넓은 network 장애를 조사할 근거가 커집니다.
하지만 remote check가 local check보다 자동으로 “더 정확한” 것은 아닙니다. 두 VDS 위치가 인터넷 전체를 대표하지 않습니다. 모스크바와 헬싱키에서는 정상이어도 다른 국가, ISP, CDN edge 또는 network에서는 실패할 수 있습니다. 저는 remote result를 추가 관측 지점으로 보지, 전 세계 상태에 대한 판정으로 보지 않습니다.
현재 Gitae가 확인하는 것
- Website check — 외부 server에서 URL이 응답하는지 확인합니다.
- SSL check — HTTPS/TLS 인증서 상태와 인증서 관련 문제를 확인합니다.
- DNS check, nslookup, dig — domain이 어떻게 resolve되고 어떤 DNS record가 반환되는지 봅니다.
- Reverse DNS와 IP check — IP 정보와 PTR/reverse-DNS 데이터를 보여 줍니다.
- Domain info와 domain age — domain의 기본 metadata를 제공합니다.
- Port check — probe 위치에서 대상 port에 도달할 수 있는지 확인합니다.
- Find your IP — service에서 보이는 public IP를 표시합니다.
- Ping과 traceroute — latency, packet loss, host까지의 경로에 대한 network signal을 제공합니다.
- Hosting check와 CMS detection — infrastructure와 technology를 식별하는 데 도움이 되는 신호를 보여 줍니다.
저는 이 결과들을 의도적으로 “신호”로 취급합니다. PTR record만으로 server 소유자를 증명할 수 없습니다. 공개 fingerprint 기반 CMS detection도 정확한 software stack을 증명하지 않습니다. 한 probe에서 port에 접근할 수 없다고 해서 그 port가 모든 곳에서 닫혀 있다는 뜻도 아닙니다. 중간 경로에서 필터링될 수 있습니다.
결과를 어떻게 해석하는가
가치는 각 결과를 따로 볼 때보다 여러 check를 함께 비교할 때 생깁니다.
DNS가 예상한 address를 반환하고 HTTPS certificate가 valid이며 두 VDS에서 website가 정상 응답하지만 로컬에서만 열리지 않는다면, server를 변경하기 전에 local path를 더 깊게 조사합니다. 반대로 DNS 결과가 일관되지 않거나 remote website check도 실패한다면 infrastructure 쪽을 살펴볼 이유가 더 커집니다.
Ping과 traceroute도 신중하게 해석해야 합니다. ICMP는 filter되거나 rate-limit될 수 있습니다. traceroute에서 한 hop이 보이지 않는다고 그 node가 고장났다고 단정할 수 없고, ping에 응답하지 않는 host가 HTTPS는 정상 제공할 수도 있습니다. 이 도구들은 context를 추가하지, 최종 진단을 내려 주지는 않습니다.
제 핵심 원칙은 이것입니다. 하나의 성공한 check가 전체 system의 건강을 증명하지 않고, 하나의 실패한 check가 혼자서 원인을 설명하지도 않는다.
Availability와 SEO는 같은 개념이 아니다
Availability는 SEO에도 중요하지만 technical outage와 ranking problem은 같은 것이 아닙니다. Crawling은 indexing이 아니고, indexing은 traffic이 아닙니다.
Crawler가 DNS, network 또는 server error 때문에 site에 도달하지 못하면 그 시점에는 해당 content를 정상적으로 가져올 수 없습니다. Google은 crawling 중 network와 DNS error를 server-side 5xx error와 비슷하게 처리하며, 장기간의 unavailability가 crawl과 이미 index된 URL에 영향을 줄 수 있다고 문서화하고 있습니다. 그렇다고 모든 짧은 outage가 자동으로 SEO 손실을 만든다는 뜻은 아닙니다. Diagnostic tool만으로 이후 traffic 변화의 원인이 정확히 그 outage였다고 증명할 수도 없습니다.
사용자 입장에서는 더 단순합니다. site에 접근하지 못하면 사용할 수 없습니다. 프로젝트에 따라 session, lead, conversion 또는 revenue 손실로 이어질 수 있지만, 기술적 진단 결과 자체가 business impact를 계산해 주는 것은 아닙니다.
“사이트가 다운됐다”면 이렇게 확인하고 싶다
- 다른 network에서 증상을 확인합니다. local browser 결과가 인터넷 전체를 대표한다고 가정하지 않습니다.
- DNS를 확인합니다. domain resolve와 예상 record를 확인합니다.
- HTTPS/TLS를 확인합니다. certificate validity와 connection error를 봅니다.
- 필요한 port를 확인합니다. probe 위치에서 접근 가능한지 검사합니다.
- Network signal을 비교합니다. ping과 traceroute는 보조 정보로 사용합니다.
- IP, reverse DNS, hosting, CMS signal을 봅니다. 예상한 infrastructure에 도달하고 있는지 확인하는 데 도움이 됩니다.
- 그 후에 조사 범위를 좁힙니다. evidence가 application, server, DNS, network path, local environment 중 어디를 더 강하게 가리키는지 판단합니다.
이것은 모든 incident에 적용되는 표준 protocol이 아닙니다. 제가 피하고 싶었던 실수를 줄이기 위한 순서입니다. “사이트가 안 열린다”는 정보 하나만 보고 전혀 다른 layer를 바꾸는 실수입니다.
먼저 실제 사용 가치, monetization은 그다음
현재 Gitae는 monetized되지 않았습니다. 처음에는 제 자신을 위해 만들었습니다. 제 컴퓨터 바깥에서 site를 빠르게 확인한 뒤 DNS, certificate, port, network 진단으로 바로 넘어가고 싶었기 때문입니다.
현재 목표는 diagnostics를 더 유용하게 만들고, SEO와 실제 수요를 통해 organic traffic을 얻을 수 있는지 확인하는 것입니다. 적당한 수준의 traffic이라도 생기면 instant messenger alert가 포함된 automated website monitoring을 추가하고 싶습니다. 같은 아이디어를 manual diagnosis에서 detection으로 확장하는 것입니다. 무언가 unavailable해졌다는 사실을 먼저 알고, owner가 빠르게 조사를 시작할 수 있는 정보를 제공하는 방식입니다.
핵심은 계속 단순하게 유지하고 싶다
“Up”과 “down”은 증상이지 설명이 아닙니다.
DNS, HTTPS/TLS, routing, port, hosting, application, 그리고 사용자 자신의 network까지 모두 단순해 보이는 availability problem에 영향을 줄 수 있습니다. Gitae가 모든 root cause를 마법처럼 찾는 것은 아니며, 그 외부 VDS 지점만으로 인터넷 전체가 무엇을 보는지 알 수도 없습니다. 하지만 여러 독립적인 signal을 한곳에서 볼 수는 있습니다.
제가 원했던 도구는 바로 그것입니다. “사이트가 안 열린다”에서 멈추지 않고, “다음에는 어느 layer를 조사해야 할까?”라는 더 유용한 질문으로 넘어가게 해 주는 도구입니다.