HTTPS 인증서 경고가 뜰 때 접속해도 될까?

‘연결이 비공개로 설정되어 있지 않습니다.’ 익숙한 사이트 앞에서 이런 문구가 나오면 멈칫하게 됩니다. HTTPS 인증서 오류는 원인에 따라 할 일이 달라집니다. 만료된 인증서, 맞지 않는 도메인, 틀어진 기기 시간은 겉으로 비슷한 경고를 만들지만 다음에 할 일은 다릅니다. 먼저 접속을 멈춘 뒤 바꿔도 되는 것과 기다려야 하는 것을 나눠 보세요.

HTTPS 인증서 오류가 남아 있다면 접속을 이어가지 마세요

물건을 주문하려고 결제창을 열었는데 ‘연결이 비공개로 설정되어 있지 않습니다’라는 화면이 나왔다면, 지금 할 일은 결제 버튼을 다시 찾는 것이 아닙니다. 주소와 오류 코드를 남기고 돌아가는 쪽이 먼저입니다. 평소 쓰던 상점이라도 결제창은 별도 회사의 호스트에서 열릴 수 있고, 그 연결의 인증서가 정상인지 다시 확인해야 합니다.

인증서 경고는 브라우저가 현재 접속 상대를 기대한 방식으로 검증하지 못했다는 신호입니다. 사이트 운영자의 갱신 실수도, 기기 시간이 틀린 경우도, 통신을 중간에서 검사하는 환경도 원인이 될 수 있습니다. 경고만 보고 공격이라고 확정할 수는 없지만, 사용자가 원인을 모르는데 예외를 허용할 이유도 없습니다.

다른 환경에서 경고가 사라졌다는 사실은 비교 단서입니다. 처음 사용하던 회선이나 기기의 문제가 해결됐다는 뜻은 아닙니다. ‘다른 곳에서는 된다’와 ‘지금 이 연결도 괜찮다’를 같은 결론으로 묶지 않는 것이 이 글의 출발점입니다.

인증서 경고와 다른 보안 화면부터 구분하세요

‘주의 요함’이라는 짧은 표시만으로는 종류를 알 수 없습니다

브라우저 주소창의 일반 HTTP 경고, 화면 전체를 가리는 인증서 오류, 위험 사이트 차단은 서로 다릅니다. 암호화되지 않은 HTTP 페이지라는 표시와 HTTPS 인증서를 검증하지 못했다는 경고에 같은 해결법을 적용하면 엉뚱한 설정을 바꾸게 됩니다. 주소의 시작 부분, 경고 제목, 상세 오류 코드를 함께 읽으세요.

서버에 연결되지 않는 증상 전반은 사이트에 연결할 수 없을 때 확인할 순서에서 다룹니다. 보안 경고가 아니라 페이지 없음이나 접근 거부 화면이면 404와 403 오류의 차이로 구분할 수 있습니다.

자물쇠나 정상 인증서가 판매자 신뢰까지 확인해 주지는 않습니다

HTTPS는 연결의 인증과 암호화에 관한 장치이지, 판매자가 주문을 이행한다는 보증이 아닙니다. 비슷하게 만든 다른 도메인도 자기 이름에 맞는 인증서를 발급받을 수 있습니다. 인증서가 정상으로 보이더라도 로그인 화면과 결제 목적지가 낯설다면 피싱 사이트 구별 기준을 함께 적용하세요.

오류 코드는 다음에 볼 항목을 고르는 단서입니다

브라우저와 운영체제에 따라 문구가 다릅니다. 아래는 Chrome 계열에서 볼 수 있는 대표 코드이며, Firefox나 Safari의 메시지가 문자 그대로 같을 필요는 없습니다. 상세 보기에 오류 원인이 표시된다면 읽거나 기록하는 것까지는 진단에 도움이 됩니다. 그것과 ‘계속 진행’을 누르는 것은 다른 행동입니다.

같은 코드에 여러 원인이 들어갈 수 있습니다. 예를 들어 신뢰 기관 오류는 사설 인증서뿐 아니라 중간 인증서 구성이나 로컬 신뢰 저장소의 문제와도 관련될 수 있습니다. 코드 하나로 ‘백신 때문’이라고 결론 내리고 보호 기능을 끄면, 문제를 해결한 것이 아니라 검사를 없앤 상태가 될 수 있습니다.

여러 오류가 함께 있거나 한 오류를 고친 뒤 다른 오류가 나타날 수도 있습니다. 인증서 날짜가 맞아졌다고 해서 이름과 신뢰 경로까지 검증됐다고 가정하지 마세요. 최종 판단은 정상적인 브라우저 검증을 거쳐 경고 없이 정확한 주소에 연결되는지입니다.

만료와 기기 시간 오류는 날짜를 대조하면 갈립니다

기기가 인식하는 현재 시각부터 확인하세요

노트북을 오래 꺼 두었거나 기기 전원이 완전히 방전된 뒤에는 날짜가 과거로 돌아가 있을 수 있습니다. 이때는 여러 정상 사이트의 인증서가 아직 시작되지 않았거나 이미 끝난 것으로 판단될 수 있습니다. 화면 오른쪽 아래의 월일만 보지 말고 연도와 현재 시간까지 확인하는 편이 빠릅니다.

Windows는 설정의 ‘시간 및 언어 → 날짜 및 시간’, Mac은 시스템 설정의 ‘일반 → 날짜 및 시간’에서 자동 설정과 시간대를 살펴볼 수 있습니다. iPhone은 ‘일반 → 날짜 및 시간’, Android는 설정 검색에서 ‘날짜 및 시간’을 찾으면 됩니다. 기기 버전·제조사·회사 관리 정책에 따라 이름이나 변경 가능 여부는 달라집니다.

기간 검증의 기준은 기기가 인식하는 실제 현재 시각입니다. 표시 시간대만 다르더라도 같은 순간을 올바르게 가리키면 반드시 인증서 오류가 생기는 것은 아닙니다. 현지 시각을 잘못 입력해 시스템 시계 자체가 어긋났는지 구분하세요.

메뉴가 다르거나 자동 설정이 비활성화되어 있다면 Microsoft의 Windows 날짜·시간 설정, Apple의 Mac 자동 시간 설정, iPhone 등 Apple 기기의 시간 문제 안내에서 사용 중인 기기의 절차를 확인할 수 있습니다. 회사가 관리하는 설정은 담당 부서에 문의하세요.

인증서의 시각이 UTC로 표시되면 한국 시각과 9시간 차이가 있으므로 같은 기준으로 바꿔 비교해야 합니다. 시계를 인증서에 억지로 맞추는 것이 아니라 실제 현재 시각에 맞추세요. 고의로 과거 날짜를 넣어 만료된 인증서를 통과시키는 방법은 기간 검사의 목적을 무너뜨립니다.

내 시계가 맞는데 특정 사이트만 만료라면 운영자 차례입니다

기기 시간이 정상이고 특정 사이트의 인증서 종료 시각이 지났다면 방문자가 새 인증서를 설치해 줄 수는 없습니다. 운영자가 갱신하고 실제 서비스 지점에 적용해야 합니다. 인증서가 발급됐다는 공지만으로 모든 서버에 배포됐다고 볼 수도 없습니다. 접속 지역이나 서비스 호스트에 따라 다른 인증서를 내보내는 상황이 있기 때문입니다.

‘갱신 중이니 무시하고 들어오라’는 메시지 대신, 경고가 없는 공식 앱이나 알려진 고객센터에서 일정과 대체 절차를 확인하세요. 공개 글을 읽는 일도 경고가 사라진 뒤로 미루는 것이 기본입니다. 민감한 정보를 입력하지 않는다고 페이지의 스크립트와 다운로드가 무해해지는 것은 아닙니다.

도메인 불일치는 회사 이름이 아니라 주소의 이름을 대조합니다

브랜드가 같아도 서로 다른 호스트일 수 있습니다

인증서 검증은 화면 로고와 상호가 닮았는지를 보는 과정이 아닙니다. 브라우저가 연결하는 호스트명과 인증서에 허용된 이름을 비교합니다. 예를 들어 안내용 가상 주소인 https://pay.example.com/checkout에서는 pay.example.com이 호스트명입니다. 뒤의 /checkout 경로나 주문번호는 인증서 이름 비교의 대상이 아닙니다.

example.com, www.example.com, pay.example.com은 서로 다른 이름입니다. 하나의 인증서가 여러 이름을 포함할 수도 있지만 자동으로 전부 포함되는 것은 아닙니다. 일반적인 와일드카드 *.example.com은 pay.example.com에는 맞아도 example.com 자체나 a.pay.example.com까지 한꺼번에 덮지는 않습니다. 따라서 www를 붙이거나 빼는 일을 만능 해결책으로 쓰지 마세요.

코드에 COMMON_NAME이 있어도 이름 목록을 함께 봅니다

현대의 서비스 이름 검증은 인증서의 Subject Alternative Name, 즉 SAN 이름 목록이 중요합니다. 상세 정보에 보이는 대표 이름이나 회사명 한 줄만으로 일치 여부를 판단하면 놓치는 부분이 생깁니다. 브라우저가 보여주는 인증서 정보의 접근 방법은 버전마다 다르므로, 상세 정보가 열리지 않으면 코드와 주소만 기록해도 문의에 충분한 출발점이 됩니다.

한글 주소가 영문 xn-- 표기로 보이는 것만으로 불일치인 것은 아닙니다. 같은 국제화 도메인의 다른 표기일 수 있습니다. 철자와 변환 관계는 한글 도메인과 퓨니코드 확인 방법으로 대조하세요. 인증서에 적힌 낯선 주소를 새 목적지로 삼지 말고, 원래 알고 있던 공식 경로에서 다시 출발합니다.

사이트가 https://old.example.com에서 새 주소로 이동시키려 해도, 예전 주소의 HTTPS 연결부터 검증에 실패하면 브라우저가 이동 응답을 받기 전에 멈출 수 있습니다. ‘새 주소로 보내는 링크니까 옛 인증서는 상관없다’는 설명은 맞지 않습니다. 공식 공지에 있는 새 주소를 별도 경로로 확인하는 것은 가능하지만, 경고 화면에서 추측한 주소로 이동하지는 않습니다.

신뢰 기관 오류가 여러 사이트에서 나면 공통 환경을 살펴봅니다

운영자는 인증서 자체뿐 아니라 신뢰할 수 있는 발급 기관까지 이어지는 연결 정보를 제대로 제공해야 합니다. 방문자의 기기에도 현재 검증에 필요한 신뢰 정보가 있어야 합니다. 오래된 운영체제나 잘못된 서버 구성 때문에 검증이 실패할 수 있으며, 경고가 떴다는 이유만으로 사이트가 해킹됐다고 말할 수는 없습니다.

최신 상태 확인과 검증 끄기는 반대입니다

개인 기기는 운영체제와 브라우저의 공식 업데이트를 먼저 확인하세요. 업데이트가 오래 밀렸다면 다른 TLS 관련 문제도 함께 있을 수 있습니다. 반대로 ‘루트 인증서를 설치하면 해결된다’는 팝업이나 게시글의 파일을 받는 것은 전혀 다른 조치입니다. 새로운 발급 주체를 신뢰하도록 만드는 행위라, 한 사이트만이 아니라 이후의 연결 검증에도 영향을 줄 수 있습니다.

회사 보안 장비는 승인된 관리 경로에서 확인하세요

일부 회사·학교 네트워크는 보안 검사를 위해 조직이 관리하는 인증서를 사용합니다. 승인된 기기에 필요한 구성이 빠지면 경고가 생길 수 있습니다. 그렇다고 웹페이지가 주는 인증서를 직원이 직접 설치하는 것이 정답은 아닙니다. 담당 부서에 서비스 주소와 발급자 표시를 전달하고 조직의 배포 절차를 따르세요.

외부 모바일 회선에서 회사 문서를 열어 보는 행동도 조직 정책을 먼저 따라야 합니다. 사내 전용 서비스는 밖에서 접속되지 않는 것이 정상일 수 있습니다. 비교 점검은 허용된 공개 사이트와 기기에서만 진행하며, 회사 VPN이나 보안 에이전트를 임의로 해제하지 않습니다.

같은 주소에서 조건을 하나씩 바꿔 보세요

휴대폰은 되고 PC는 안 된다는 말만으로 PC 고장을 판단할 수 없습니다. 휴대폰이 모바일 데이터에 연결돼 있고 PC는 회사 Wi-Fi를 쓴다면 기기와 회선이 동시에 달라진 것입니다. 먼저 어느 조건을 바꿨는지 한 줄로 적으면 원인을 좁히기 훨씬 쉽습니다.

비교할 때는 북마크와 검색결과가 같은 호스트로 가는지도 보세요. 한쪽은 www가 있고 다른 쪽은 없는 주소라면 같은 대상을 비교한 것이 아닙니다. 브라우저의 시크릿 모드는 사이트 저장 정보 차이를 살피는 데는 도움이 되지만 인증서 검증을 특별히 더 정확하게 만드는 기능은 아닙니다.

전체 쿠키 삭제나 네트워크 초기화는 첫 단계로 권하지 않습니다. 만료된 서버 인증서를 쿠키를 지워 갱신할 수는 없고, 로그인 상태와 저장한 네트워크만 잃을 수 있습니다. 한 번에 여러 설정을 바꾸면 무엇이 달라졌는지도 남기기 어렵습니다.

공공 Wi-Fi 로그인 문제를 인증서 예외로 풀지 마세요

호텔·카페·역의 Wi-Fi는 인터넷을 쓰기 전에 이용약관이나 인증 화면을 거치기도 합니다. 아직 이 절차를 끝내지 않았을 때 브라우저가 원하는 HTTPS 사이트 대신 다른 응답을 받으면 연결이 막힐 수 있습니다. 시설 네트워크라는 사실과 로그인 화면이 진짜라는 사실은 따로 확인해야 합니다.

운영체제의 네트워크 로그인 알림부터 확인합니다

기기의 Wi-Fi 로그인 알림이나 시설이 안내한 접속 절차를 이용하고, 네트워크 이름이 맞는지 직원에게 확인하세요. 은행이나 메일의 HTTPS 경고를 무시해 로그인 포털로 들어가려고 하지 않습니다. 시설이 안내한 포털 자체에 인증서 경고가 남거나 개인정보 요구가 납득되지 않으면 그 회선 사용을 중단합니다.

이미 알려진 시설 포털에 필요한 최소 정보와 평소 쓰는 계정 비밀번호를 구분해야 합니다. Wi-Fi 이용을 위해 은행 비밀번호, 메일 비밀번호, 결제 인증번호를 요구한다면 입력할 이유가 없습니다. 신뢰할 수 있는 개인 회선으로 전환한 뒤 원래 목적지를 정확히 다시 열어 보세요.

Google은 연결 오류 안내에서 공용 Wi-Fi 포털을 별도 상황으로 다룹니다. 브라우저별 문제 분류는 Chrome 공식 오류 해결 안내에서 확인할 수 있습니다. 포털 문제라는 추측이 경고를 우회할 근거가 되지는 않습니다.

HSTS 때문에 진행 버튼이 없어도 차단을 풀 필요는 없습니다

어떤 경고에는 계속 접속하는 버튼이 보이지 않습니다. 사이트가 HSTS 정책을 사용하고 브라우저가 그 정책을 알고 있다면, 인증서 오류를 사용자의 예외 선택으로 넘기지 않도록 처리할 수 있습니다. 이는 버튼이 고장 난 상황과 다릅니다.

HTTP로 낮추면 같은 서비스를 안전하게 여는 것이 아닙니다

주소의 https를 http로 바꾸면 암호화와 인증의 보호를 내려놓게 됩니다. HSTS가 적용된 경우에는 브라우저가 다시 HTTPS로 바꾸기도 합니다. 정책 기록을 지우거나 숨겨진 진행 명령을 찾는 대신 운영자가 인증서 문제를 해결하도록 기다리는 편이 맞습니다.

다른 브라우저에 진행 버튼이 있다고 해서 위험이 줄어드는 것도 아닙니다. 오류 종류와 정책 상태에 따라 화면 선택지가 달라질 뿐입니다. 특히 결제·전자서명·행정 신청처럼 마감이 있는 작업은 예외 접속보다 공식 앱, 전화 접수, 기한 안내 등 대체 수단을 먼저 확인하세요. 대체 경로 역시 기관이 실제 제공하는 방식이어야 합니다.

세 가지 상황에서 접속 판단을 해보면 기준이 분명해집니다

다음 세 사례는 설명용으로 구성했습니다. 실제 고객 사고나 복구 기록이 아닙니다. 각 상황에서 관찰한 사실과 다시 접속할 조건을 구분해 보세요.

오래 보관한 노트북에 날짜 오류가 납니다

• 관찰: 은행과 메일 모두 날짜 오류가 나고, 노트북의 연도가 수년 전으로 표시됩니다.
• 할 일: 실제 현재 시각으로 동기화하고 브라우저를 다시 엽니다. 시간을 고쳐도 경고가 남으면 인증서 기간·업데이트 상태를 더 살펴봅니다.
• 재개 조건: 시계가 맞고 정확한 은행·메일 주소에 경고 없이 연결됩니다. 과거 날짜로 인증서에 맞춘 것은 해결이 아닙니다.

쇼핑몰은 열리지만 결제창에 이름 불일치가 뜹니다

• 관찰: shop.example.com은 열리지만 pay.example.com에서 경고가 납니다. 두 주소는 가상입니다.
• 할 일: 입력을 멈추고 기존 고객센터에 결제 호스트와 오류를 전달합니다. 제출 직후였다면 주문·승인 상태부터 확인해 같은 결제를 반복하지 않습니다.
• 재개 조건: 확인된 결제 목적지에 경고 없이 연결되고, 이전 거래 상태까지 확인한 뒤 진행합니다.

호텔 Wi-Fi에서 여러 사이트에 인증서 신뢰 오류가 보입니다

• 관찰: 같은 기기의 개인 모바일 회선에서는 열리지만 호텔 Wi-Fi에서만 오류가 납니다. 발급자가 낯설다는 이유만으로 신뢰 오류가 발생하는 것은 아닙니다.
• 할 일: 네트워크 이름과 로그인 절차를 직원에게 확인합니다. 포털에도 경고가 남거나 인증서 설치를 요구하면 사용을 멈추고 문의합니다.
• 재개 조건: 이용이 허용된 신뢰할 수 있는 회선에서 원래 목적지가 경고 없이 열립니다. 모바일 접속 성공이 호텔 망의 복구를 뜻하지는 않습니다.

이미 경고를 넘기고 정보를 입력했다면 무엇부터 할까요

경고 화면을 본 것만으로 비밀번호가 유출됐다고 볼 수는 없습니다. 브라우저가 연결을 막은 상태인지, 예외를 허용해 페이지를 열었는지, 무엇을 입력하거나 내려받았는지를 나눠야 합니다. 기억을 정리한다고 같은 경고 페이지에 다시 들어갈 필요는 없습니다.

비밀번호를 입력했다면 정상 경로에서 계정을 보호합니다

신뢰할 수 있는 기기와 회선에서 공식 앱이나 확인된 주소를 이용해 비밀번호를 바꾸고, 제공되는 경우 활성 세션과 로그인 기록을 확인하세요. 다른 서비스에 같은 비밀번호를 썼다면 그 계정도 따로 변경합니다. 다중 인증 설정과 보안 알림도 살펴볼 수 있습니다. 여기서도 인증서 경고가 계속되면 다른 검증된 경로부터 확보합니다.

Google 계정을 사용하는 경우 Google의 계정 보호 안내에서 최근 보안 활동·접속 기기 검토와 2단계 인증 절차를 확인할 수 있습니다. 다른 서비스도 해당 제공자의 보안 설정과 복구 안내를 이용하세요. 이는 정보 입력 이후의 보호 조치이며, 인증서 경고 자체가 계정 탈취의 증거라는 뜻은 아닙니다.

결제정보·파일·인증서 설치는 대응 대상을 달리합니다

카드정보나 결제 인증 내용을 제출했다면 발급사와 서비스의 공식 고객센터에 연락해 거래 확인과 필요한 보호 조치를 안내받으세요. 파일만 다운로드하고 열지 않은 상황과, 실행파일을 실행하거나 인증서·프로파일을 설치한 상황은 다릅니다. 후자는 기기 보안 설정까지 영향을 받았을 수 있으므로 조직 기기라면 IT 담당자에게 알리고 개인 기기라면 신뢰할 수 있는 지원을 받는 것이 좋습니다.

회사 문서나 개인정보가 포함된 파일을 업로드했다면 계정 비밀번호 변경만으로 끝나지 않을 수 있습니다. 어떤 파일을 어느 주소로 전송했는지 내부 대응 담당자에게 전달하되, 신고 게시판에 원본 파일과 개인 정보를 공개하지는 않습니다.

문의에는 인증서 화면보다 비교 조건을 함께 남기세요

‘보안 오류가 납니다’만 보내면 담당자는 어느 서버와 기기를 살펴봐야 할지 알기 어렵습니다. 정확한 호스트명, 발생 시각과 시간대, 오류 코드, 기기·브라우저 버전, 비교 결과를 한 묶음으로 적어 보세요. 로그인·결제 직전인지도 중요합니다.

스크린샷을 첨부할 때는 이름·메일·주문번호·로그인 토큰이 보이는지 먼저 살피세요. 전체 URL의 쿼리에는 임시 인증 정보가 들어갈 수 있으므로 공개 문의에는 호스트와 필요한 경로만 남기는 편이 좋습니다. 발급자와 기간 정보가 보이면 도움이 되지만, 인증서 상세를 볼 수 없다는 이유로 경고를 넘기지는 않습니다.

주소나와에 실린 안내 링크가 문제라면 주소 수정·오류 제보로 알려주세요. 대상 사이트의 인증서를 고칠 권한은 그 운영자에게 있으므로, 안내 링크 수정과 서비스 복구는 별개입니다. 다른 주소 가이드는 주소모음 안내에서 찾을 수 있습니다.

운영자는 발급 완료보다 실제 접속 지점의 인증서를 확인합니다

방문자라면 앞의 문의 단계까지면 충분합니다. 자신이 관리하는 사이트의 문제라면 발급 시스템에서 새 인증서가 보이는 것만으로 작업을 끝내지 마세요. 브라우저가 실제로 만나는 웹 서버·CDN·로드밸런서·결제 호스트에 올바른 인증서가 적용됐는지 확인해야 합니다.

기간·이름·체인을 따로 점검합니다

인증서의 유효기간, SAN 이름 목록, 필요한 중간 인증서, 서버가 선택하는 인증서와 호스트 라우팅을 점검합니다. 여러 호스트나 접속 지점이 있다면 일부만 갱신됐는지도 봅니다. 갱신 자동화가 있어도 갱신 후 배포·재로드 단계가 실패할 수 있으므로 외부에서 실제 연결을 검증하는 절차가 필요합니다.

방문자에게 보안 기능을 끄라고 안내하면 잠깐 페이지를 열 수 있어도 문제의 원인은 남습니다. 점검 중이라면 별도의 정상적인 공지 채널에 영향 범위와 대체 이용 방법을 올리고, 정상 검증을 확인한 뒤 복구를 안내하세요. 검증되지 않은 복구 시간을 약속하기보다는 다음 안내 시점을 정하는 편이 낫습니다.

HTTPS 인증서 경고에 자주 묻는 질문

공식 출처와 작성·검토 기준

주소나와 편집팀이 일반 이용자의 접속 판단을 위해 정리한 안내입니다. 자료 확인일은 2026년 9월 11일입니다. 특정 사고를 해결한 후기나 모든 운영체제에서 오류를 재현한 실험 보고서가 아닙니다. 본문의 세 사례와 문의 메모는 가상이며, example.com 하위 주소는 설명용입니다.

• Google Chrome — 일반적인 오류 메시지 도움말: 인증서 오류 코드, 잘못된 기기 시간, 공용 Wi-Fi와 조직 프록시 관련 안내.
• RFC 5280, 4.1.2.5절 — 인증서 유효기간: notBefore와 notAfter 및 시각 표현의 기준.
• RFC 9525, 6절 — 서비스 이름 검증: 인증서의 서비스 식별자와 호스트명 대조, 와일드카드 범위. 단순 회사명·대표 이름 확인과 구분하는 근거.
• RFC 6797, 8.4절 — HSTS의 보안 연결 오류 처리: 정책이 알려진 호스트의 보안 연결 오류에서 사용자 예외를 허용하지 않는 기준.

RFC 원문과 Chrome 공식 안내를 대조하고, 기기 시간 설정은 Microsoft·Apple 도움말, 계정 보호는 Google 계정 도움말을 확인했습니다. 설정 위치는 일반적인 메뉴 구성으로 안내하며 버전·언어·관리 정책에 따라 달라질 수 있습니다. 공식 도움말의 모든 진단 조치를 그대로 나열하기보다, 이 글에서는 방문자가 직접 할 확인과 운영자·IT 담당자가 처리할 변경을 나눴습니다. 실제 원인이 확인되기 전까지 특정 업체의 장애나 공격으로 단정하지 않습니다.