Windows용 AdGuard 10월 이슈 리포트: 사후 분석

최근 일부 Windows용 AdGuard 사용자분들이 앱 사용 중 문제를 겪었습니다. 7.22 버전 출시 이후, 브라우저에서 간헐적으로 웹페이지가 로드되지 않는 현상이 발견되었습니다. Chrome에서는 비교적 빠르게 조치할 수 있었지만, Firefox에서는 문제를 재현하기 어려웠고 여러 요인이 복합적으로 작용해 더 오래 지속되었습니다.

본 게시물 시점 기준으로, 해당 문제를 완전히 해결하는 핫픽스인 Windows용 AdGuard v7.22.1을 출시했습니다. 원활한 사용을 위해 앱을 최신 버전으로 업데이트해 주시기 바랍니다. 다른 플랫폼에서 AdGuard를 사용 중이시라면 별도의 조치가 필요하지 않으며, 모든 기능이 정상적으로 작동할 것입니다.

불편을 끼쳐드린 점 진심으로 사과드립니다. 이번 이슈가 AdGuard에 대한 전반적인 경험에 영향을 미치지 않기를 바랍니다. 이번 문제는 일회성으로 발생한 것이며, 같은 일이 다시 발생하지 않도록 내부 프로세스를 점검하고 개선 조치를 이미 시행했습니다.

아래에서는 해당 이슈가 어떻게 발생했는지 시간순으로 설명하고, 이어서 기술적인 세부 사항과 재발 방지를 위한 조치들을 안내해 드리겠습니다.

타임라인

10월 2일

AdGuard for Windows v7.22를 출시했습니다.

October 4 10월 4일

사용자로부터 v7.22 업데이트 이후 웹페이지가 로드되지 않고 Timed out 오류가 발생한다는 GitHub 이슈가 접수되었습니다.

10월 6일

QA 팀이 조사를 시작했으나 문제를 재현할 수 없었습니다. 같은 날 개발팀으로 이슈를 전달했고, 내부 논의가 시작되었습니다.

10월 16일

더 많은 사용자가 GitHub 토론에 참여하면서 보고와 추천이 누적되었습니다. 안타깝게도 이 단계에서 QA 팀은 해당 수준의 이슈에 대한 내부 에스컬레이션 지침을 따르지 않았습니다. 버그 재현 시 심각한 어려움을 겪었는데, 이는 부분적으로 사용자 보고의 일관성 부족 때문이었습니다. 이로 인해 팀은 해당 버그가 몇 버전 전에 도입된 것으로 추정하여 긴급 패치가 필요하지 않다고 판단했습니다. 결국 다음 예정된 버전으로 연기되었고, 해당 작업이 P1: Critical으로 표시되었음에도 제대로 에스컬레이션되지 않아 소중한 시간이 낭비되었습니다.

10월 30일

24일 후, 해당 문제가 내부적으로 재발하며 사용자에게 미친 실제 영향의 규모가 드러났습니다. 문제를 성공적으로 재현한 후, 우리는 전체적인 피해 규모를 보다 정확하게 추정할 수 있었습니다. 핫픽스(v7.22.1) 작업이 즉시 시작되었습니다. 그러나 대부분의 시간과 노력은 문제를 안정적으로 재현하고 주요 원인을 파악하는 데 투입되었습니다. 이 과정에서 여러 가설이 테스트되고 배제되었습니다.

조사 과정에서 QUIC 연결과 관련된 Firefox 버그도 발견되었는데, 이는 페이지 로딩 속도를 더욱 저하시키고 디버깅을 복잡하게 만들었습니다. 또한, 윈튠(Wintun)이 비활성화된 상태에서 호환 모드로 AdGuard VPN과 AdGuard가 동시에 실행될 때 QUIC 연결 필터링이 적용되지 않는 문제도 확인되었습니다.

11월 1일

문제의 원인을 부분적으로 파악하고 재현 방법을 확인했습니다. DNS 필터링 엔진인 DnsLibs에 수정 사항을 적용했으며, 테스트를 위해 야간 빌드를 배포했습니다.

11월 5일

저희는 핵심 원인을 AdGuard의 필터링 엔진인 CoreLibs의 라우팅 루프 감지 구성 요소 내 버그로 정확히 규명했습니다. 해당 문제는 즉시 수정되었으며, 두 번째 야간 빌드가 출시되었습니다.

11월 6일

Nightly 빌드 테스트 결과 초기 수정 사항으로 TCP 연결 관련 문제 대부분이 해결되었으나 일부 UDP 관련 문제는 남아 있었습니다. 사용자 영향 최소화를 위해 수정 사항을 두 단계로 배포하기로 결정했습니다. 먼저 세 번째 Nightly 빌드에서 최종 라이브러리 수정 및 드라이버 지침 업데이트를 포함한 추가 문제를 해결했습니다. 이후 v7.22.1 패치를 준비하여 철저히 테스트한 후 당일 출시했습니다.

기술적 세부 사항

버그

Windows용 AdGuard v7.22 버그로 인해 Firefox에서 특정 페이지를 로드할 때 가끔씩 예측 불가능한 동결 현상이 발생했습니다. Chrome 사용자에게는 그다지 영향을 미치지 않았습니다. 이 문제는 CoreLibs v1.19가 라우팅 루프 방지 기능을 도입한 이후 시작되었으며, 이 메커니즘은 트래픽이 스스로로 다시 순환하는 것을 방지하기 위해 설계되었습니다.

이 버그 자체에는 두 가지 주요 원인이 있었습니다. 첫째, 프로그래밍 오류로 인해 라우팅 루프 검사에서 특정 포트가 제외되어 브라우저 요청과 같은 일부 정상적인 필터링 연결이 차단될 수 있었습니다. 이는 AdGuard에서 발생하는 OCSP 요청과 같은 일부 서비스 요청에 의해 유발되었습니다. 이러한 요청 이후 다음 브라우저 연결이 중단되었습니다.

둘째, 이미 설정된 연결에 대해 검사가 잘못된 위치에서 적용되어 불필요한 연결 차단이 발생했습니다.

라우팅 루프로부터 보호가 필요한 이유는 무엇인가요?

라우팅 루프는 트래픽이 원본 앱으로 되돌아갈 때 발생합니다. 이러한 루프는 연결 속도 저하와 높은 CPU 사용량을 유발할 수 있습니다. 일반적으로 이런 상황은 발생하지 않지만, 다른 소프트웨어와의 상호작용으로 인해 라우팅 루프가 여전히 발생할 수 있습니다. 이를 방지하기 위해 AdGuard는 발신 연결을 소스 주소로 추적하고 동일한 주소로 되돌아오는 연결을 종료합니다.

왜 Chrome에는 약간만 영향을 미쳤을까요?

서비스 요청 직후의 연결만 끊어졌기 때문에 크롬 사용자들은 이 문제를 훨씬 덜 인지했습니다. 이는 크롬이 연결이 재설정된 후 동일한 네트워크 요청을 자동으로 다시 시도하기 때문입니다.

반면 파이어폭스 사용자들은 보다 직접적인 영향을 받았습니다. 해당 브라우저의 설계에는 어떠한 네트워크 오류 발생 후에도 자동 재시도 기능이 포함되어 있지 않아, 이 문제가 그들에게 더 뚜렷하게 드러났기 때문입니다.

Linux와 Android용 AdGuard는 어떻게 되나요?

해당 문제는 버전 1.19의 CLI 단계에서는 발견되지 않았습니다. 비록 최신 기능은 항상 AdGuard CLI에 먼저 도입되어 UI 기반 애플리케이션에 통합되기 전에 주요 문제를 찾아 수정할 수 있도록 하지만 말입니다. 이 경우 문제는 Linux 자동 모드에서만 발생했으며, 주로 Firefox에서 나타났습니다. 결과적으로 이러한 조건을 충족하는 사용자는 극소수였기에 사용자 보고도 접수되지 않았습니다.

동일한 CoreLibs 1.19를 사용하는 Android용 AdGuard v4.12에서는 문제가 나타나지 않았습니다. 이는 수신 및 발신 연결 주소가 달라 다른 환경에서 버그를 유발한 동일한 조건이 발생하지 않았기 때문입니다.

문제 진단

문제 진단은 특히 어려웠습니다. AdGuard는 상대적으로 적은 수의 서비스 연결을 열고, 문제를 재현하려는 반복적인 시도에서는 캐시된 OCSP 요청이 사용되는 경우가 많아 버그가 나타나지 않았습니다. 또한 이 문제는 한 번에 단일 다운스트림 연결에만 영향을 미쳤습니다. Chrome 사용자는 대부분 영향을 받지 않았는데, 이는 브라우저가 실패한 연결을 자동으로 재시도하기 때문입니다. 반면 Firefox 사용자는 네트워크 오류 발생 시 재연결을 시도하지 않기 때문에 직접적인 영향을 받았습니다.

Firefox 버그 발견 과정

이 찾기 어려운 버그를 추적하던 중, 절반 가량의 보고서에 다른 증상이 동반되었으며, 해당 문제가 과거 버전의 AdGuard에서도 재발하기 시작한다는 사실을 발견했습니다. 이를 통해 우리는 별도의 Windows용 Firefox의 HTTP/3 연결 관련 버그도 함께 발견하게 되었습니다.

간단히 말해, Firefox는 사이트가 HTTP/3 지원을 광고하는 즉시 해당 연결이 아직 사용 가능하지 않더라도 즉시 HTTP/3 연결을 시도합니다. AdGuard는 현재 기본적으로 HTTP/3를 필터링하지 않으므로, HTTPS 필터링이 활성화된 애플리케이션에서는 HTTP/3가 차단됩니다.

일반적으로 브라우저는 '해피 아이볼(Happy Eyeballs)'과 같은 알고리즘을 포함하여 최적의 프로토콜을 선택할 수 있게 하지만, Windows용 Firefox는 사이트가 HTTP/3를 지원한다는 정보(예: HTTPS와 같은 DNS 레코드)를 수신하면 즉시 HTTP/3 연결을 시도합니다. 그리고 활성 HTTP/2 연결이 존재함에도 불구하고 아직 설정되지 않은 HTTP/3 연결에 요청을 할당합니다. HTTP/3를 사용할 수 없는 경우, 사이트 로딩이 20~30초 동안 일시 중단된 후 요청이 활성 HTTP/2 연결로 재할당됩니다.

해당 동작에 대한 버그 보고서가 제출되었습니다. 예방 조치로 AdGuard는 HTTP/3 필터링이 비활성화된 경우 h3 ALPN 매개변수를 제외하도록 HTTPS 유형 DNS 레코드를 수정했습니다. 이는 AdGuard에 의해 차단될 경우에도 브라우저에서 HTTP/3 사용 가능 여부를 숨깁니다.

수정 사항

수정은 두 단계로 진행되었습니다. 첫 번째 단계에서는 연결 매칭 로직을 수정하여 포트를 적절히 포함시켰습니다. 이로 인해 대부분의 문제가 해결되었으나, Windows가 최근 종료된 연결의 포트를 재사용하는 문제로 인해 일부 오탐이 지속되었습니다. 11월 5일 저녁에 배포된 야간 빌드가 대부분의 사용자에게 도움이 되었습니다.

그러나 AdGuard 로그에는 여전히 문제의 흔적이 남아 있었습니다. 결국 문제는 부분적으로만 해결된 것으로 드러났습니다. 연결 매칭 알고리즘만 수정하는 것은 충분하지 않았는데, 소켓이 해제된 후 1초 이내에 Windows가 아웃바운드 연결의 포트를 재사용할 수 있기 때문입니다. 이로 인해 동일한 주소와 포트를 가진 무관한 연결들이 루프로 오인되는 또 다른 유형의 오탐이 발생했습니다.

명백한 새로운 사고는 발생하지 않았지만(모두 정상 작동 중이라고 보고함), 잠재적으로 많은 사용자가 여전히 영향을 받을 수 있었습니다. 이에 따라 두 번째 단계로 넘어갔습니다. 이 단계에서는 해당 사례들을 해결하여 최종 핫픽스인 v7.22.1을 출시했으며, 이로써 문제가 완전히 해결되었습니다.

예방 조치

이 문제는 정상적인 테스트 환경에서 재현하기 어려웠고, 사용자 피드백에 대한 충분한 주의가 기울여지지 않았기 때문에 조기에 발견되지 못했습니다.

현재 QA 및 개발 프로세스를 업데이트 중이며, 특히 더 엄격한 프로세스 모니터링, 강화된 자동화, 팀 내 더 철저한 테스트 및 커뮤니케이션의 결합에 중점을 두고 있습니다. 이를 통해 향후 유사한 사고를 방지하고 모든 사용자에게 AdGuard의 신뢰성을 보장하고자 합니다.

QA 팀 워크플로 변경

QA 팀은 GitHub 이슈의 댓글 수와 추천 수에 더 많은 주의를 기울일 예정입니다. 인적 요소를 최소화하기 위해, 이 모니터링은 수동 검토에만 의존하지 않을 것입니다 — 공개 이슈의 활동 및 추천 수 추적을 위한 자동화 시스템이 도입됩니다. 이 접근 방식이 효과적임이 입증되면, 모든 AdGuard 프로젝트의 모든 QA 팀으로 확장 적용될 수 있습니다.
트라이아지 가이드라인을 기반으로 추가 브리핑을 실시하고, Jira 내부의 이슈 평가를 위한 필수 절차를 도입할 예정입니다. 이 프로세스에서는 구조화된 내부 트라이아지 가이드라인에 기반한 근거 제시가 요구되며, 이를 통해 우선순위 결정의 일관성과 투명성을 보장할 수 있습니다.

팀은 또한 사용자를 위한 진단 질문 목록을 준비할 예정이며, 이를 통해 사용자 피드백을 기반으로 필터링 관련 문제를 식별하고 분석하는 것이 더 쉬워질 것입니다.

마지막으로, 향후 유사한 문제 발생을 방지하기 위해 여러 새로운 자동화 테스트가 구현될 예정입니다. 다양한 브라우저에서 페이지 필터링 속도를 평가하기 위한 벤치마크 테스트 스크립트가 개발 중입니다. 성능 기준선이 정의되면 이후 모든 릴리스는 이를 기준으로 측정될 것입니다. 현재 자동화 테스트는 Google Chrome에서만 사용되지만, Firefox로도 확대할 계획입니다. 또한 해당 브라우저에서 정의된 ‘문제 페이지’ 집합의 로딩 속도를 측정하는 테스트를 작성할 예정입니다. 이 목록은 알려진 문제 웹사이트를 기반으로 하며, 본 이슈 조사 범위에서 확인된 사이트(예: discord.com)를 시작으로 지속적으로 확장될 것입니다.

개발 팀의 워크플로 변경

개발 팀은 향후 릴리스에서 오류 발생 가능성을 줄이기 위해 가능한 경우 새로운 기능에 대한 통합 테스트를 포함한 새로운 테스트 추가에 더 많은 주의를 기울일 것입니다. 또한 새로운 기능에 대한 상세한 기술 문서 제공과 모든 관련 팀이 잠재적 문제 및 경계 사례에 대한 새로운 기능 테스트 필요성을 제대로 인지하도록 하는 데 더 중점을 둘 것입니다.

CoreLibs의 새 버전을 제품에 통합할 때는 이제 CoreLibs 팀의 명시적 승인을 받은 후 진행합니다. 현재 이 통합 프로세스는 어느 정도 분리되어 진행되므로 문제 발생 가능성을 놓칠 위험이 있습니다.

결론

이번 사건으로 피해를 입으신 모든 사용자분들께 다시 한번 사과드리며, 피드백을 제공해 주시고 어려운 상황을 헤쳐나가는 데 도움을 주신 모든 분들께 진심으로 감사드립니다. 앞으로는 중대한 영향을 미칠 수 있는 중요한 문제에 대해 사용자분들과의 소통을 더욱 신속하고 투명하게 진행하겠습니다.