macOS 27 베타에서 Chrome과 Brave가 웹사이트를 불러오지 못하나요? 해결 방법

macOSTahoe ·
macOS 27 베타에서 Chrome과 Brave가 웹사이트를 불러오지 못하나요? 해결 방법

macOS 27 베타에서 Safari는 정상인데 Chrome이 웹사이트를 불러오지 못하나요? Chromium 브라우저가 작동하지 않는 이유와 단계별 해결 방법을 알아봅니다.

macOS 27 "Golden Gate" 퍼블릭 베타를 설치하고 Chrome을 열어 URL을 입력했는데... 아무 일도 일어나지 않습니다. 탭이 빙글빙글 돌아갑니다. 상태 표시줄에는 *연결 중...*이라는 문구가 뜬 채로 더 이상 진행되지 않습니다. 한참을 기다리면 ERR_CONNECTION_TIMED_OUT, ERR_NAME_NOT_RESOLVED 같은 무미건조한 오류나, Brave라면 다소 능청스러운 이 사이트에 연결할 수 없음 메시지를 받게 됩니다. 그래서 다른 사이트를 시도해 봅니다. 똑같습니다. 어떤 사이트를 열어도 마찬가지입니다. 그러다 습관적으로 Safari를 열어보면... 곧바로, 첫 시도에 아무 지체 없이 로드됩니다. 인터넷은 명백히 멀쩡합니다. Wi-Fi도 멀쩡합니다. 그런데도 macOS 27 베타에서 Chrome이 웹사이트를 불러오지 못하는 문제가 하루 오후를 통째로 잡아먹고 있고, 이 현상은 Brave, Edge, Arc, Vivaldi에서도 똑같이 나타납니다.

혹시 지금 이 상황이라면 일단 한숨 돌리세요. Mac이 고장 난 것도, 네트워크가 고장 난 것도 아닙니다. 이것은 현재 macOS 27 베타에서 널리 보고되고 있는 거친 부분(rough edge) 중 하나로, Chromium 기반 브라우저는 아무것도 불러오지 못하는데 Safari는 문제없이 통과하는 패턴입니다. Brave Community 포럼, Apple Discussions 스레드, MacRumors 베타 게시판 곳곳에서 이 현상이 보고되고 있으며, 공통점은 언제나 같습니다. WebKit 브라우저는 작동하고 Chromium 브라우저는 작동하지 않는다는 것입니다. 이 분리 현상이야말로 무엇이 잘못되었는지 알려주는 가장 큰 단서이며, 아래 해결책 대부분이 빠르고 되돌리기 쉬우며 무언가를 완전히 밀어버릴 필요가 없는 이유이기도 합니다.

이 가이드는 두 가지 역할을 합니다. 첫째, 베타에 걸맞은 유보적인 태도로 솔직하게 왜 Safari 이외의 브라우저만 문제를 일으키는지 설명합니다. 둘째, 순서대로 올라갈 수 있는 해결 사다리(fix ladder)를 제공합니다. 많은 사람에게 통하는 30초짜리 토글부터 시작해, 아무도 입 밖으로 꺼내고 싶어 하지 않는 솔직한 최후의 대안까지 다룹니다. 즉, 이것은 베타이며 Apple이 새 빌드를 내놓을 때까지 Safari에 의지하거나 안정된 Tahoe로 되돌아가는 것이 옳은 선택일 때도 있다는 것입니다. 그럼 브라우저를 되살려 보겠습니다.

핵심 요약

  • Safari는 정상 작동하는데 Chrome, Brave, Edge, Arc, Vivaldi가 모두 실패하는 것이 이 베타 문제의 특징입니다. 이는 특정 브라우저 하나의 문제라기보다, 현재 macOS 27 베타가 WebKit이 아닌 앱의 네트워크 트래픽을 처리하는 방식 — DNS, 네트워크 확장 프로그램, 앱별 네트워크 경로 — 을 가리킵니다.
  • 이는 베타 테스터들이 보고한 사례이며 Apple이 공식 확인한 버그는 아닙니다. Brave Community, Apple Discussions, MacRumors의 스레드에서 이 문제가 언급되고 있지만, Apple은 공식적으로 이를 인정한 적이 없습니다. 동작 방식은 베타 빌드마다 달라질 수 있으므로 업데이트할 때마다 다시 테스트해야 합니다.
  • 가장 성공률이 높은 해결책은 간단하고 되돌리기도 쉽습니다. 브라우저의 Secure DNS / DNS-over-HTTPS를 끄고, 네트워크 필터나 VPN 시스템 확장 프로그램(Little Snitch, LuLu, 회사 필터, 일부 백신 프로그램)을 비활성화하고, IPv6를 Link-local only로 설정하고, DNS 캐시를 비우는 것입니다.
  • Private Relay와 VPN을 먼저 확인하세요. iCloud Private Relay와 어중간하게 연결된 VPN 터널은 이 베타에서 Safari와 Chromium 앱에 서로 다르게 작동하며, 자주 원인으로 지목됩니다.
  • 솔직한 최후의 대안은 Safari를 쓰거나 되돌리는 것입니다. 베타에서는 일부 문제가 그저 Apple의 조치를 기다려야 할 때도 있습니다. 정상 작동하는 Chromium 브라우저가 반드시 필요하다면, 해당 빌드와 씨름하기보다 안정된 Tahoe로 롤백하는 방안을 저울질해 보세요.

먼저: 정말로 macOS 27 베타를 사용 중인가요?

설정을 하나라도 바꾸기 전에, 지금 사용 중인 것이 바로 이 글에서 다루는 베타가 맞는지부터 확인하세요. 여기 나오는 해결책은 베타 특유의 동작을 겨냥한 것이라, 안정 버전에서는 시간 낭비이거나 오히려 역효과를 낼 수 있습니다.

정확한 버전 확인하기

Apple 메뉴 > 이 Mac에 관하여를 열어 버전 줄을 확인합니다. 그런 다음 더 보기 > 소프트웨어 업데이트(또는 시스템 설정 > 일반 > 소프트웨어 업데이트)를 클릭해 베타 시드를 사용 중인지 확인하세요.

  • macOS 27.0 베타라고 표시되거나(또는 개발자용/퍼블릭 베타 배너가 보인다면), 제대로 찾아온 것입니다. 퍼블릭 베타는 2026년 7월 중순에 등장했습니다 — 7월 13일 퍼블릭 베타 1, 7월 22일 퍼블릭 베타 2 — 이 글을 쓰는 시점 기준 최신 개발자 시드는 베타 4, 빌드 26A5388g(7월 20일)입니다. Apple은 퍼블릭 시드에 대해 고정된 빌드 문자열을 공개하지 않았으므로 특정 번호에 지나치게 집착하지 마세요. "macOS 27 퍼블릭 베타"라고 부르는 정도가 정확한 표현입니다.
  • macOS 26.5.2(빌드 25F84) 또는 비슷한 버전이 표시된다면 베타가 아니라 안정된 Tahoe를 사용 중인 것입니다. 이 경우 Chromium 브라우저 전체가 먹통이 되는 현상은 알려진 베타 패턴이 아니므로, 일반적인 네트워킹 문제로 다루어야 합니다 — 아래의 베타 전용 단계 대신 Wi-Fi 끊김 완전 해결 가이드와 VPN 문제 해결 가이드부터 시작하세요.

Intel Mac 사용자를 위한 참고 사항

macOS 27 "Golden Gate"는 Apple 실리콘 전용입니다 — M1 이상만 지원합니다. 이번 주기에서 모든 Intel Mac이 지원 대상에서 제외되었습니다. Intel 기기를 사용 중이라면 애초에 macOS 27 베타를 실행할 수 없으므로, 브라우저 문제가 있다면 완전히 다른 원인입니다. 이 가이드는 베타를 실행 중인 M 시리즈 Mac을 전제로 합니다.

여기서 "베타"가 의미하는 것을 기억하세요

아래 내용은 모두 커뮤니티 포럼과 언론 보도를 종합한 베타 테스터들의 보고를 바탕으로 구성되어 있습니다. Apple이 공식적으로 인정하고 공식 수정을 내놓은 결함은 하나도 없습니다. 이는 두 가지 이유에서 중요합니다. 동작 방식이 빌드마다 바뀔 수 있다는 점(퍼블릭 베타 2에서 필요했던 조치가 다음 시드에서는 불필요해질 수 있습니다), 그리고 일부 테스터에게는 최종 해결책이 그저 Apple을 기다리는 것뿐이었다는 점입니다. 사전 출시 OS를 다루고 있다는 점에 맞춰 기대치를 조정하세요.

macOS 27 베타에서 Safari 이외의 브라우저만 문제를 일으키는 이유

여러분이 가진 가장 유용한 진단 단서는 Safari/Chromium 분리 현상입니다. 이 둘이 왜 다르게 동작하는지 이해하면 곧바로 해결책으로 이어집니다. 다만 이는 커뮤니티 보고를 바탕으로 한 근거 있는 추론이지 리버스 엔지니어링으로 확인된 확실한 사실은 아니라는 점을 전제로, 그 메커니즘을 살펴보겠습니다.

Safari와 Chromium은 서로 다른 네트워크 경로를 사용합니다

Safari는 WebKit 위에 구축되어 macOS와 긴밀하게 통합되어 있습니다. Apple 자체 프레임워크가 기대하는 방식대로 시스템의 네이티브 네트워킹 스택(NSURLSession, 시스템 리졸버, 시스템 신뢰 저장소)에 의존하며, iCloud Private Relay, 앱별 네트워크 정책, OS DNS 리졸버 같은 시스템 수준의 이점을 일급 시민(first-class citizen)으로서 물려받습니다.

반면 Chromium 브라우저(Chrome, Brave, Edge, Arc, Vivaldi는 모두 Chromium 엔진을 공유합니다)는 이 작업의 상당 부분을 직접 처리합니다. Chromium은 자체 네트워크 서비스, 종종 자체 DNS-over-HTTPS 리졸버, 자체 연결 풀링, 소켓을 여는 방식에 대한 자체적인 방침을 갖추고 있습니다. 이러한 독립성은 평소에는 강점입니다. 하지만 Apple이 앱별 네트워킹, DNS, 네트워크 확장 프로그램 필터링 방식을 바꾸고 있을지도 모르는 베타에서는 이것이 약점이 됩니다. Chromium의 가정과 베타의 새로운 동작 방식이 어긋나 버릴 수 있는데, Safari는 기본적으로 Apple 방식 그대로 동작하기 때문에 이런 문제를 애초에 겪지 않습니다.

네트워크 확장 프로그램과 DNS 관점 (유보적으로 본 설명)

최신 macOS는 앱 트래픽을 네트워크 확장 프로그램(network extension) 프레임워크를 통해 라우팅합니다. 콘텐츠 필터, VPN 클라이언트, DNS 프록시, 방화벽은 모두 시스템 네트워크 확장 프로그램으로 등록되어, 앱별로 트래픽을 검사·리디렉션·차단할 수 있습니다. Safari는 작동하는데 모든 Chromium 브라우저가 멈춘다는 베타 테스터들의 보고에 대해, 커뮤니티에서 유력하게 거론되는 이론은 다음 두 가지 모두 이 영역에 속합니다.

  1. Chromium 앱에서만 DNS 확인(resolution)이 실패하는 경우입니다. Chrome과 Brave가 자체 **Secure DNS(DNS-over-HTTPS)**를 사용하는 동안 베타가 DNS 처리 방식을 새롭게 바꾸었다면, 이름 조회가 영원히 멈춰버릴 수 있습니다 — 이는 끝없는 *연결 중...*이 보여주는 바로 그 모습입니다. 시스템 리졸버를 사용하는 Safari는 이 문제를 우회합니다. ERR_NAME_NOT_RESOLVED 같은 오류는 이 이론에 정확히 들어맞습니다.
  2. 네트워크 확장 프로그램 필터가 Safari 이외의 트래픽을 조용히 차단하는 경우입니다. Little Snitch, LuLu, 회사 콘텐츠 필터, 일부 백신 제품군처럼 네트워크 확장 프로그램으로 설치되는 도구들은 앱별 연결을 중재합니다. 베타에서 확장 프로그램을 평가하거나 승인하는 방식이 바뀌었다면, 필터가 Safari는 통과시키면서 Chromium 앱은 블랙홀로 보내버릴 수 있습니다. 이는 macOS Tahoe 26.5.1 네트워크 확장 프로그램 종료 문제 해결에서 다룬 네트워크 확장 프로그램 콘텐츠 필터 관련 베타 마찰과 같은 계열의 문제입니다 — 증상은 다르지만 부담을 받는 하위 시스템은 동일합니다.

둘 다 보고 내용과 부합하며, 솔직히 말해 하나의 보편적인 원인은 아닐 가능성이 큽니다. 서로 다른 테스터마다 "Chromium은 독자적인 네트워크 경로를 쓴다"는 동일한 토대 위에 서로 다른 트리거가 겹쳐 있을 가능성이 높습니다. 이는 문제 해결에 있어서는 좋은 소식입니다. 어느 쪽이 자신의 경우인지 알 필요가 없기 때문입니다. 그저 사다리를 순서대로 내려가다 보면 대개 한 단계에서 문제가 해결됩니다.

정확한 오류 메시지 해독하기

Chrome이 보여주는 오류 메시지는 원인을 상당히 좁혀 주므로, 클릭부터 하기 전에 메시지를 먼저 읽으세요. 흔히 나타나는 몇 가지 오류와 이 베타에서 그것이 보통 의미하는 바는 다음과 같습니다.

  • ERR_NAME_NOT_RESOLVED — 순수한 DNS 실패입니다. 브라우저가 도메인을 IP 주소로 전혀 변환하지 못한 것입니다. 이는 해결책 1(Secure DNS 끄기)과 해결책 4(캐시 비우기)를 강하게 가리킵니다. 이 베타 패턴에서 가장 흔한 특징입니다.
  • ERR_CONNECTION_TIMED_OUT — 이름은 확인되었지만 연결 자체가 끝내 완료되지 않았습니다. 네트워크 확장 프로그램 필터(해결책 2), IPv6 경합(해결책 3), 또는 어중간하게 살아있는 VPN(해결책 5)이 트래픽을 조용히 삼켜버렸을 가능성이 큽니다.
  • ERR_CONNECTION_REFUSED / ERR_CONNECTION_RESET — 무언가가 연결을 능동적으로 끊었습니다. 콘텐츠 필터나 방화벽 확장 프로그램이 설치된 Mac이라면 필터가 판정을 내리는 중일 가능성이 높습니다 — 곧바로 해결책 2로 가세요.
  • ERR_PROXY_CONNECTION_FAILED — 프록시가 설정되어 있는데(흔히 남아있는 구성 프로파일이나 VPN 앱에 의해) 그 프록시가 죽어 있는 상태입니다. 해결책 5의 프로파일 점검 항목을 참고하세요.
  • 오류 없이 계속 빙글빙글 도는 탭 — 대개 DNS 조회가 완전히 실패한 것이 아니라 멈춰 있는 상태이며, 이 역시 해결책 1과 4에 해당합니다.

베타에서는 이 중 어느 것도 확정적이지 않지만, 모든 단계를 하나하나 거치는 대신 어느 단계부터 시도해야 할지 알려줍니다.

"네트워크 확장 프로그램"이 실제로 무엇인지, 쉬운 말로 설명하면

네트워크 확장 프로그램이라는 용어가 낯설다면, 짧게 설명해 드리겠습니다 — 아래 해결책의 절반 정도가 이를 중심으로 돌아가기 때문에 알아둘 가치가 있습니다. 몇 년 전만 해도 트래픽을 검사하거나 필터링해야 하는 앱(VPN, 방화벽, 자녀 보호 기능, 백신의 웹 보호 기능)은 시스템 깊은 곳까지 권한을 갖는 커널 확장 프로그램으로 그 일을 처리했습니다. Apple은 여러 릴리스에 걸쳐 이러한 기능을 커널에서 빼내어 Network Extensions라는 샌드박스화된 사용자 공간 프레임워크로 옮겨 왔습니다. 오늘날 Little Snitch, 회사 필터, VPN을 설치하면 시스템 네트워크 확장 프로그램으로 등록되고, macOS는 여러분의 트래픽을 이 확장 프로그램을 거쳐 라우팅함으로써 해당 도구가 연결을 허용·차단·리디렉션할 수 있게 합니다 — 흔히 앱 단위로 이루어집니다.

이 앱별 처리 능력이 핵심입니다. 네트워크 확장 프로그램은 원칙적으로 Safari와 Chrome을 다르게 취급할 수 있으며, 연결이 어떻게 구성되는지는 OS가 알려주는 정보에 의존합니다. 베타가 그 아래에 있는 배관(plumbing) — 확장 프로그램이 승인되는 방식, 앱별 트래픽에 태그가 붙는 방식, 확장 프로그램에 각 연결이 전달되는 방식 — 을 바꾸면, Safari에서는 완벽하게 작동하던 확장 프로그램이 아무도 의도하지 않았는데도 Chromium 트래픽을 차단하거나 멈추게 만들 수 있습니다. 이것이 바로 "네트워크 확장 프로그램을 비활성화하고 다시 테스트하기"가 여기서 그토록 중요한 단계인 이유이며, 베타 업데이트 후마다 확장 프로그램을 다시 승인해야 하는 이유이기도 합니다.

이것이 "브라우저 고장"이 아니라 "베타"임을 알려주는 이유

만약 Chrome 자체가 고장 났다면 재설치로 해결되었을 것이고, Brave/Edge/Arc/Vivaldi가 한꺼번에 똑같이 실패하지도 않았을 것입니다. 네트워크가 고장 났다면 Safari도 실패했을 것입니다. "모든 Chromium 브라우저는 죽었는데 WebKit은 멀쩡하고, 기기도 같고 Wi-Fi도 같다"는 상황을 깔끔하게 설명하는 유일한 원인은 이 두 부류의 앱을 다르게 취급하는 OS-네트워크 계층의 무언가입니다 — 이는 정확히 사전 출시 OS가 잘못 처리하기 쉬운 종류의 것입니다. Golden Gate 베타 알려진 문제 정리를 읽어보면 이 빌드에 얼마나 많은 거친 부분이 있는지 맥락을 파악하는 데 도움이 됩니다.

60초 트리아지 체크리스트

전체 사다리를 시도하기 전에 다음 다섯 가지 빠른 확인을 먼저 해보세요. 거의 비용이 들지 않으면서도 종종 곧바로 효과적인 해결책을 가리켜 줍니다.

  1. Safari는 사이트를 불러오나요? 예라면 확인된 것입니다. 이는 Chromium 전용 패턴이며 아래 사다리가 적용됩니다. Safari마저 실패한다면 이는 베타 브라우저 버그가 아니라 일반적인 연결 문제입니다. Wi-Fi 끊김 가이드로 이동하세요.
  2. VPN이나 콘텐츠 필터가 실행 중인가요? 메뉴 막대와 시스템 설정 > 일반 > 로그인 항목 및 확장 프로그램 > 네트워크 확장 프로그램을 확인하세요. 무언가 있다면 그것이 첫 번째 용의자입니다.
  3. iCloud Private Relay가 켜져 있나요? 시스템 설정 > [사용자 이름] > iCloud > Private Relay에서 활성화 여부를 확인해 두세요.
  4. 도메인 이름은 안 되는데 IP 주소는 되나요? Chrome에서 http://1.1.1.1을 불러와 보세요. 순수 IP는 로드되는데 cloudflare.com은 안 된다면 문제는 DNS이며, 해결책 1과 4가 목표 지점입니다.
  5. 완전히 새로운 브라우저 프로필도 똑같이 동작하나요? Chrome에서 새 게스트 창을 열어보세요. 이것도 실패한다면 원인은 프로필이 아니라 시스템 전반에 있는 것이므로, 네트워크 관련 해결책으로 곧바로 넘어가세요.

이 다섯 가지 확인 결과가 무엇이든, 그냥 해결책 1부터 순서대로 시작해도 무방합니다. 각 변경 사항이 실제로 적용되도록 해결책 사이마다 Chrome을 완전히 재시작하세요(창을 닫는 것이 아니라 Cmd+Q로 종료).

정확히 어디서 문제가 발생하는지 확인하기 (선택 사항이지만 강력함)

설정을 바꾸기 전에 어느 계층에서 문제가 발생하는지 확실히 알고 싶다면, 안전한 Terminal 명령어 다섯 개가 답을 알려줍니다. 이 중 어느 것도 무언가를 변경하지 않고 상태만 읽으므로 위험 없이 모두 실행할 수 있습니다. 핵심은 다음 세 가지 질문을 구분하는 것입니다. 네트워크에 애초에 도달할 수 있는가? DNS는 작동하는가? Chrome은 안 되는데 시스템 수준의 HTTP 경로는 작동하는가?

1. 순수 IP로 인터넷에 도달할 수 있나요? 이는 DNS를 완전히 건너뜁니다.

ping -c 4 1.1.1.1

응답이 온다면 Mac의 연결 상태는 정상이며 문제는 더 상위 계층(DNS 또는 앱별 처리)에 있습니다. 이것마저 실패한다면 Safari도 실패하고 있을 것이며, 베타 브라우저 패턴이 아니라 일반적인 연결 문제를 보고 있는 것입니다.

2. DNS 확인(resolution)이 작동하나요?

ping -c 4 cloudflare.com

1단계는 성공했는데 이번 단계에서 확인할 수 없음이 나오거나 멈춘다면 DNS 문제임이 확인된 것입니다 — 바로 해결책 1과 4가 겨냥하는 문제입니다.

3. 리졸버에 직접 물어보기. dig와 nslookup은 모두 macOS에 기본 포함되어 있으며 시스템 리졸버가 반환하는 값을 보여줍니다.

dig cloudflare.com +short
nslookup cloudflare.com

여기서 응답이 온다면 시스템 리졸버는 정상이며 Chromium 자체의 DNS-over-HTTPS가 멈춰 있는 것입니다 — 브라우저의 Secure DNS를 꺼서 이 정상 작동하는 시스템 리졸버에 맡기는 해결책 1이 도움이 될 것이라는 강한 신호입니다.

4. Chrome은 안 되는데 시스템 HTTP 스택은 페이지를 불러오나요? curl은 macOS 자체 네트워킹을 사용하며, Safari가 사용하는 것과 같은 부류의 경로입니다.

curl -I https://www.cloudflare.com

Chrome은 멈춰 있는데 curl이 헤더(HTTP/2 200 등)를 반환한다면, 진단은 한 줄로 끝납니다. OS 경로는 작동하고 Chromium 경로는 작동하지 않는다는 것입니다. 이는 베타 패턴임이 확인된 것이며, 아래의 시스템 수준 해결책이 가장 유력한 선택지라는 뜻입니다.

5. 시스템이 실제로 사용하는 DNS는 무엇인가요?

scutil --dns | grep nameserver
networksetup -getdnsservers "Wi-Fi"

이는 VPN, 프로파일, 필터가 여러분이 선택하지 않은 DNS 서버로 조용히 가리키고 있는지 보여줍니다. 예상치 못한 주소가 보인다면 해결책 5의 프로파일 및 VPN 점검 항목을 다시 확인하세요.

이 다섯 가지를 실행해 보면 설정을 건드리기도 전에 DNS 문제인지, 필터 문제인지, 앱별 경로 문제인지 알 수 있습니다. Terminal이 익숙하지 않다면 이 섹션은 완전히 건너뛰어도 됩니다 — 해결 사다리는 이것 없이도 잘 작동합니다.

해결 사다리

위에서 아래로 순서대로 진행하세요. 각 단계 후에 다시 테스트하고, 사이트가 정상으로 돌아오면 멈추세요. 여기 나오는 모든 단계는 되돌릴 수 있습니다.

해결책 1: 브라우저의 Secure DNS / DNS-over-HTTPS 끄기

이는 이 베타 패턴에 대해 가장 효과가 큰 단일 해결책입니다. Chromium에 내장된 암호화 DNS야말로 베타 OS와 동기화가 어긋날 수 있는 자체 관리형 네트워킹의 전형적인 예이기 때문입니다. 브라우저에게 스스로 이름을 확인하는 것을 멈추고 시스템에 맡기라고 지시하는 것입니다.

Chrome, Brave, Edge, Vivaldi에서:

  1. 설정 > 개인 정보 보호 및 보안 > 보안을 엽니다.
  2. 보안 DNS 사용까지 스크롤한 다음 완전히 꺼짐으로 전환합니다. (제공업체만 바꾸지 말고 브라우저가 OS 리졸버를 사용하도록 아예 꺼야 합니다.)
  3. 브라우저를 완전히 종료한 다음(Cmd+Q) 다시 엽니다.

Arc의 경우: Arc > 설정을 열어 개인 정보 보호/보안 섹션을 찾은 다음 같은 방식으로 Secure DNS를 비활성화합니다. Arc는 Chromium의 설정을 자체 메뉴 안에 노출하고 있습니다.

트리아지 확인에서 순수 IP는 로드되었지만 도메인은 안 되었다면, 이 단계만으로도 해결되는 경우가 매우 많습니다.

브라우저에서 Secure DNS를 비활성화하는 macOS 화면

해결책 2: 네트워크 필터, VPN, 콘텐츠 필터 확장 프로그램 비활성화 또는 제거하기

Little Snitch, LuLu, 회사 콘텐츠 필터, DNS 필터링 앱, 웹 보호 기능이 있는 백신 제품군을 사용하고 있다면, 거의 확실히 시스템 네트워크 확장 프로그램으로 자체 설치되어 있을 것이며 — 이 베타에서 Safari는 통과시키고 Chromium은 차단하는 주요 용의자입니다.

  1. 시스템 설정 > 일반 > 로그인 항목 및 확장 프로그램으로 이동한 다음 네트워크 확장 프로그램 옆의 (i) 를 클릭합니다(예전 경로: 빌드에 따라 네트워크 확장 프로그램 또는 콘텐츠 및 개인정보 보호).
  2. 서드파티 네트워크 필터 / VPN / 방화벽 확장 프로그램을 하나씩 꺼짐으로 전환합니다.
  3. 전환할 때마다 Chrome을 완전히 종료했다가 다시 열어 재테스트합니다.

하나를 비활성화했더니 Chrome이 돌아온다면 범인을 찾은 것입니다. 그 시점부터는 Apple이 수정된 빌드를 낼 때까지 꺼둔 채로 두거나, 도구를 최신 버전으로 업데이트하거나(제조사들은 베타에 대응해 빠르게 패치를 냅니다), 제조사의 베타 호환성 안내를 확인할 수 있습니다. 관리형/회사 Mac을 사용 중이라면 회사 필터를 직접 비활성화하지 못할 수도 있습니다 — 이는 IT 팀에 문의할 사안이며, 베타 설치를 보류할 타당한 이유이기도 합니다. 네트워크 확장 프로그램 콘텐츠 필터 관련 글에서 OS가 그 아래에서 바뀔 때 이러한 확장 프로그램이 어떻게 동작하는지 더 깊이 다룹니다.

여러 테스터들이 IPv6가 오작동할 때 이 베타에서 Chromium의 듀얼 스택(IPv4 + IPv6) 연결 경합이 멈춰버리는 반면, Safari는 이를 견뎌낸다고 보고합니다. 네트워크 서비스에서 완전한 IPv6를 강제로 끄면 트래픽이 정상 작동하는 IPv4 경로로 밀려납니다.

시스템 설정을 통한 방법(권장, 완만한 방식):

  1. 시스템 설정 > 네트워크에서 사용 중인 서비스(Wi-Fi 또는 Ethernet)를 선택하고 **세부사항...**을 클릭합니다.
  2. TCP/IP 탭으로 이동합니다.
  3. IPv6 구성을 Link-local only로 설정합니다.
  4. 확인을 클릭한 다음 Chrome을 완전히 종료했다가 다시 엽니다.

Terminal을 통한 방법(명령줄을 선호한다면 동일한 효과): 먼저 서비스 이름 목록을 확인한 다음, 사용 중인 서비스의 IPv6를 끕니다. -setv6off는 GUI의 "Link-local only"보다 IPv6를 더 완전히 비활성화하지만, 이 문제를 분리해서 확인하는 용도로는 둘 다 효과가 있습니다.

# See the exact network service names
networksetup -listallnetworkservices

# Turn IPv6 off for Wi-Fi (use your exact service name)
sudo networksetup -setv6off "Wi-Fi"

나중에 IPv6를 정상으로 되돌리려면:

sudo networksetup -setv6automatic "Wi-Fi"

macOS 네트워크 설정 패널

해결책 4: DNS 캐시 비우기

DNS가 문제라면(그리고 이 베타에서는 흔히 그렇습니다), 오래되었거나 손상된 리졸버 캐시가 설정을 바꾼 후에도 실패한 조회 결과를 계속 고정시킬 수 있습니다. 캐시를 비우세요. 이는 캐시를 비우고 멀티캐스트 DNS 응답기를 재시작하는, 표준적이고 안전한 macOS 명령어 조합입니다.

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

관리자 비밀번호를 입력하라는 요청이 뜹니다. 성공해도 눈에 보이는 출력은 없습니다 — 이는 정상입니다. 이후 Chrome을 종료했다가 다시 열어 사이트를 시도해 보세요. 성공 확률을 높이려면 해결책 1(Secure DNS 끄기)과 함께 적용하세요. 두 가지를 함께 적용하면 이 베타에서 가장 흔하게 보고되는 DNS 실패 유형을 해결합니다.

해결책 5: Private Relay, VPN, 구성 프로파일 확인하기

iCloud Private Relay와 VPN은 둘 다 Mac에서 트래픽이 나가는 방식을 바꾸며, 둘 다 Safari와 Chromium 앱에 서로 다르게 처리됩니다 — 이는 이들을 전형적인 비대칭 실패 용의자로 만듭니다.

  • iCloud Private Relay: 시스템 설정 > [사용자 이름] > iCloud > Private Relay에서 일시적으로 꺼짐으로 전환한 다음 Chrome을 다시 테스트하세요. Private Relay는 Safari와 일부 시스템 트래픽만 라우팅하지만, 이를 토글하면 Chromium이 갇혀 있던 네트워크 상태를 초기화할 수 있습니다.
  • VPN: VPN이 연결되어 있다면 (앱을 최소화하는 것이 아니라) 완전히 연결을 해제한 다음 다시 테스트하세요. 어중간하게 연결되었거나 베타와 호환되지 않는 터널은 "브라우저가 영원히 멈춘다"는 현상의 매우 흔한 원인입니다. VPN이 문제로 확인되면 macOS VPN 문제 해결 가이드를 진행해 보세요 — 대부분의 VPN 클라이언트는 베타에 대응한 업데이트가 필요합니다.
  • 구성 프로파일: 시스템 설정 > 일반 > 기기 관리(또는 개인정보 보호 및 보안 > 프로파일)에서 알아보지 못하거나 더 이상 필요 없는 오래된 DNS나 프록시 프로파일을 제거하세요. 남아있는 프로파일이 잘못된 DNS 서버를 고정시킬 수 있습니다.

해결책 6: 일부 테스터들이 효과를 확신하는 FaceTime / "다른 기기의 전화 허용" 토글

이 방법은 다소 특이하고 확인되지 않았지만, 여러 포럼 게시자들이 이 방법으로 Chromium 브라우저가 다시 살아났다고 보고하고 있으므로 30초를 들일 가치는 있습니다. 이 Continuity 기능을 토글하면 네트워크 스택이 베타가 잘못된 상태로 남겨둔 앱별 경로를 다시 초기화하도록 자극한다는 것이 이론입니다.

  1. FaceTime > 설정을 엽니다(메뉴 막대: FaceTime > 설정).
  2. iPhone에서 걸려온 전화 / 다른 기기의 전화 허용을 찾아 껐다가 다시 켜세요.
  3. 또는 iPhone에서 설정 > 전화 > 다른 기기의 전화로 이동해 Mac을 껐다가 다시 켜세요.
  4. Chrome을 다시 테스트합니다.

이는 보장된 해결책이라기보다 일부 사람들에게 우연히 효과가 있는 민간요법 정도로 여기세요. 비용이 전혀 들지 않고 즉시 되돌릴 수 있으므로 사다리의 한 단계를 차지할 자격은 충분합니다.

해결책 7: 브라우저의 네트워크 설정 재설정 또는 새 프로필 시작하기

시스템 수준의 해결책으로도 안 된다면, 특정 브라우저 프로필이 손상된 네트워크 상태를 갖고 있는지 따로 분리해서 확인하세요.

  • Chrome/Brave/Edge: 설정 > 설정 초기화 > 설정을 기본값으로 복원을 엽니다. 이렇게 하면 북마크나 비밀번호는 그대로 두면서 사용자 지정 DNS, 프록시, 시작 설정을 지웁니다.
  • 새 프로필 테스트: 새 프로필을 만들거나(프로필 아이콘 > 추가) 게스트 창을 열어 사이트를 시도해 보세요. 새 프로필에서 작동한다면 문제는 기존 프로필 안에 있던 것이므로, 기존 프로필을 재설정하거나 새 프로필로 이전하세요.
  • 소켓/호스트 캐시 비우기: Chrome에서 chrome://net-internals/#sockets로 이동해 Flush socket pools를 클릭한 다음, chrome://net-internals/#dns에서 Clear host cache를 클릭하세요. (Brave와 Edge도 brave://net-internals처럼 자체 스킴 아래 동일한 페이지를 제공합니다.)

해결책 8: 브라우저를 깨끗하게 재설치하기

네트워크 관련 해결책을 모두 적용한 뒤에도 특정 브라우저 하나만 계속 문제라면, 그 브라우저를 완전히 재설치하세요. Chrome, Brave, Edge, Arc, Vivaldi는 모두 같은 엔진을 공유하므로, 다른 브라우저들에 비해 유독 한 브라우저만 뒤처질 때만 이 방법을 시도하세요 — 시스템 차원의 원인이라면 재설치로 해결되지 않습니다.

  1. 브라우저를 종료합니다(Cmd+Q).
  2. Applications에서 휴지통으로 끌어다 놓습니다.
  3. 제조사 사이트에서 최신 빌드를 직접 다운로드합니다 — 베타 호환성 수정은 브라우저 업데이트에 끊임없이 반영되므로, 현재 빌드가 이미 이 베타를 더 잘 처리할 수도 있습니다.
  4. 재설치한 다음 다시 테스트합니다. 다시 로그인하면 동기화된 데이터(북마크, 비밀번호)가 돌아옵니다.

해결책 9 (베타 현실을 인정하는 최후의 대안): Safari를 쓰거나 Tahoe로 되돌리기

여기서부터는 솔직한 이야기입니다. 이것은 베타이고, 브라우저 먹통 현상은 베타 테스터들이 보고한 것일 뿐 Apple이 인정한 것은 아니며, 일부 테스터들은 Apple이 새 빌드를 낼 때까지 위 사다리의 그 무엇도 완전히 통하지 않았다고 말합니다. 사다리를 끝까지 다 시도했는데도 Chromium이 여전히 먹통이라면, 합리적인 선택지는 두 가지입니다.

  • 지금은 Safari에 의지하세요. 잘 작동하고, 빠르고, 북마크도 가져올 수 있습니다. 베타가 성숙해지는 몇 주 동안 일상적인 브라우징을 Safari로 옮기는 것은 충분히 합리적인 임시방편이며, 새 시드가 나올 때마다 Chrome을 다시 테스트해 볼 수 있습니다(동작 방식은 빌드마다 실제로 바뀝니다).
  • 안정된 Tahoe로 되돌리세요. 정상 작동하는 Chromium 브라우저가 업무나 확장 프로그램, 다른 곳으로 옮길 수 없는 작업 흐름 때문에 반드시 필요하다면, 가장 깔끔한 해결책은 베타를 떠나는 것입니다. 데이터 손실 없이 macOS 27 베타에서 Tahoe로 다운그레이드하는 단계별 가이드를 따라 하세요. 아직 베타 설치를 고려하는 단계라면, 이번 문제 전체가 다음번에는 별도 볼륨에 안전하게 설치하는 것이 왜 중요한지 보여주는 강력한 근거입니다. 그래야 작업용 시스템이 절대 고장 나는 대상이 되지 않습니다.

이 중 어느 쪽을 선택하든 부끄러워할 일이 아닙니다. 베타는 여러분이 자발적으로 테스트하기로 한 미리보기이지, 고장 난 브라우저를 참고 견디겠다는 약속이 아닙니다.

흔한 문제 해결하기

문제: 이 베타에서 Chrome이 일부 사이트는 불러오지만 다른 사이트에서는 멈춥니다

해결책: 부분적으로 로드되는 것은 거의 항상 완전한 차단이 아니라 DNS 문제를 의미합니다. 일부 이름은 캐시에서 확인되는 반면 새로운 조회는 멈춥니다. 해결책 1(Secure DNS 끄기)과 해결책 4(DNS 캐시 비우기)를 함께 실행한 다음 Chrome을 완전히 종료했다가 다시 시도하세요. 그래도 계속되면 시스템 DNS를 일반 리졸버로 설정하세요 — 시스템 설정 > 네트워크 > 세부사항 > DNS에서 1.1.1.1과 8.8.8.8을 추가하면, OS가 이 베타에서 잘못 처리되는 리졸버에 의존하지 않게 됩니다.

문제: 모든 것이 정상이었는데 베타 업데이트 후 다시 문제가 생겼습니다

해결책: 예상된 일입니다. 새로운 시드마다 네트워크 확장 프로그램 승인 상태와 토글 동작이 초기화될 수 있습니다. macOS 27 베타를 업데이트할 때마다 시스템 설정 > 일반 > 로그인 항목 및 확장 프로그램 > 네트워크 확장 프로그램에서 네트워크 확장 프로그램을 다시 승인한 다음, 해결책 1과 해결책 4를 다시 실행하세요. 이는 Apple이 인정하지 않은 베타 동작이므로, 이전 해결책이 여전히 유효하다고 가정하기보다 매 빌드를 새로운 진단 대상으로 취급하세요.

문제: 회사나 학교 Mac이 필요한 해결책을 막고 있습니다

해결책: 관리형 Mac은 사용자가 직접 비활성화할 수 없는 회사 콘텐츠 필터와 구성 프로파일을 강제로 적용하며, 이러한 필터는 Safari는 작동하고 Chromium은 실패하는 분리 현상의 주요 용의자입니다. MDM과 씨름하지 마세요. IT 팀에 연락해 macOS 27 베타에서 Chromium 앱에서만 브라우저가 실패한다고 알리고, 필터 제조사에 베타 호환 빌드가 있는지 문의하세요. 없다면 이는 운영/관리형 Mac이 아직 베타에 올라가서는 안 된다는 명확한 신호입니다.

문제: 네트워크 확장 프로그램을 비활성화하니 Chrome이 고쳐졌지만 그 도구가 계속 실행되어야 합니다

해결책: 범인을 확인했으니 이제 올바른 방법으로 보호 기능을 되살리세요. 도구(Little Snitch, LuLu, 백신 등)를 최신 버전으로 업데이트하세요. 제조사들은 베타 호환성 패치를 빠르게 내놓습니다. 제조사의 릴리스 노트나 포럼에서 macOS 27 관련 안내를 확인하세요. 아직 호환 빌드가 없다면, 이 베타에서는 그 도구와 Chromium 중 하나를 선택해야 하는 상황입니다 — 제조사가 따라잡을 때까지 Tahoe로 되돌리는 것을 진지하게 고려할 만한 이유입니다.

FAQ

macOS 27 베타에서 왜 Safari는 되는데 Chrome과 Brave는 안 되나요?

Safari는 macOS의 네이티브 네트워킹과 DNS를 사용하므로, 베타가 무엇을 바꾸든 그대로 물려받습니다. Chromium 브라우저는 자체 DNS, 소켓, 연결 로직을 관리하는데, 이것이 베타의 새로운 앱별 네트워크 처리 방식과 어긋날 수 있습니다. 같은 기기, 같은 Wi-Fi인데도 네트워크 경로가 다르기 때문에 하나는 작동하고 다른 것들은 멈추는 것입니다.

이것은 Apple이 공식 인정한 버그이고 수정이 예정되어 있나요?

공식적으로는 아닙니다. 이 문제는 Brave Community, Apple Discussions, MacRumors에서 베타 테스터들이 보고했고 언론에서 종합해 다루었지만, Apple은 공식적으로 이를 인정한 적이 없습니다. 사전 출시 빌드에서 일어나는 일이므로 새 시드마다 동작이 바뀔 수 있어, macOS 27 베타를 업데이트할 때마다 다시 테스트해야 합니다.

Secure DNS를 끄면 브라우징 프라이버시가 낮아지나요?

약간, 그리고 일시적으로만 그렇습니다. 브라우저의 DNS-over-HTTPS를 비활성화하면 이름 조회가 암호화된 리졸버 대신 시스템 리졸버를 사용하게 됩니다. 베타를 위한 임시 해결책으로는 충분히 괜찮은 맞교환이며, Apple이 Chromium과 잘 맞물리는 빌드를 내놓으면 다시 Secure DNS를 켤 수 있습니다. HTTPS 페이지 트래픽은 어느 쪽이든 계속 암호화된 상태로 유지됩니다.

저는 베타가 아니라 macOS 26.5.2를 사용 중입니다. 이 해결책이 적용되나요?

아마 아닐 것입니다. Chromium 전체가 먹통이 되는 현상은 베타 패턴입니다. 안정된 Tahoe 26.5.2(빌드 25F84)에서 브라우저가 사이트를 불러오지 못한다면, 일반적인 연결 문제나 VPN, 필터일 가능성이 더 높습니다. 여기의 베타 전용 단계 대신 위에 링크된 Wi-Fi 및 VPN 가이드부터 시작하세요.

Chrome을 재설치하면 그것만으로 해결될까요?

이 문제에서는 좀처럼 그렇지 않습니다. Brave, Edge, Arc, Vivaldi가 Chrome과 함께 모두 실패한다면 원인은 시스템 수준에 있으며 브라우저 하나를 재설치해도 도움이 되지 않습니다. 다른 브라우저들과 달리 특정 Chromium 브라우저 하나만 뒤처질 때만 재설치하세요 — 그리고 항상 최신 빌드를 받으세요. 브라우저 업데이트에는 종종 베타 호환성이 추가되기 때문입니다.

이 문제 때문에 그냥 Tahoe로 되돌려야 할까요?

정상 작동하는 Chromium 브라우저가 일상에 필수적인데 해결 사다리가 통하지 않았다면, 그렇습니다 — 합리적인 결정입니다. 위에 링크된 다운그레이드 가이드를 따라 데이터 손실 없이 롤백하세요. 몇 주 동안 Safari로 지낼 수 있다면, 베타에 머물면서 새 시드가 나올 때마다 다시 테스트하는 쪽이 노력이 덜 드는 방법입니다.

결론

macOS 27 베타에서 Chrome이 웹사이트를 불러오지 못하는데 Safari는 완벽하게 작동한다면, 여러분이 보고 있는 것은 고장 난 Mac이나 고장 난 브라우저가 아닙니다 — WebKit을 다루는 방식과 다르게 Chromium의 독립적인 네트워크 경로를 처리하는 사전 출시 OS를 보고 있는 것입니다. 이 한 가지 통찰이 바로 해결책 대부분이 빠른 토글인 이유입니다. 브라우저의 Secure DNS 끄기, 네트워크 필터 확장 프로그램 비활성화, IPv6를 Link-local only로 설정하기, DNS 캐시 비우기, Private Relay와 VPN 확인하기. 이 단계들 중 하나가 대부분의 테스터에게 효과가 있으며, 그 어느 것도 몇 초 만에 되돌릴 수 있습니다.

하지만 솔직한 관점을 계속 염두에 두세요. 이는 베타 테스터들이 보고한 동작이지 Apple이 확인한 버그가 아니며, 베타에서 최종 해결책은 때로 그저 인내심입니다. 동작 방식은 빌드마다 바뀌므로 새 시드가 나올 때마다 다시 테스트하세요 — 그리고 정상 작동하는 Chromium 브라우저가 없어서는 안 되는 것이라면, Apple이 문제를 해결할 때까지 Safari에 의지하거나 안정된 Tahoe로 롤백하는 것을 부끄러워할 이유가 없습니다. 여러분은 자발적으로 미리보기를 테스트하기로 한 것이며, 고장 난 브라우저를 "다음 빌드를 기다리는" 상황으로 받아들이는 것이야말로 정확히 옳은 태도입니다.

마지막으로 실용적인 습관 하나를 덧붙이자면, 베타 배포 주기를 지켜보세요. Apple은 대략 1~2주마다 시드를 배포해 왔습니다 — 퍼블릭 베타 1은 7월 13일, 퍼블릭 베타 2는 7월 22일에 도착했고, 개발자 베타 4(빌드 26A5388g)는 7월 20일에 나왔습니다 — 그리고 네트워킹 동작은 시드마다 실제로 달라졌습니다. 그러므로 현명한 방법은 효과가 있는 해결책을 유지하면서 어느 단계가 문제를 해결했는지 기록해 두고, 새 빌드가 나올 때마다 그 우회 조치를 잠시 비활성화한 다음 Chrome을 다시 테스트하는 것입니다. 어떤 시드가 근본 문제를 조용히 해결했다면, Secure DNS와 IPv6를 영구히 바꾼 채로 두지 말고 정상 설정으로 되돌리는 것이 좋습니다. 베타는 계속 변화하니, 여러분의 우회 조치도 영구적이어서는 안 됩니다.

사다리는 맨 위부터 순서대로 시도하고, 사이트가 정상으로 돌아오는 첫 단계에서 멈추세요. Golden Gate에 계속 머물러야 할지 저울질하고 있다면, 알려진 문제 가이드와 안전한 설치 안내가 명확한 시각으로 결정을 내리는 데 도움이 될 것입니다.