파일 탐색기에서 \\사무실PC\공유자료 또는 \\NAS이름\폴더를 열었는데 “네트워크 경로를 찾지 못했습니다”라는 메시지와 오류 코드 0x80070035가 나타날 수 있습니다. 검색 결과를 따라 네트워크 검색을 켜거나 방화벽을 껐는데도 해결되지 않는 경우도 많습니다.

그 이유는 네트워크 공유 폴더 접속이 하나의 기능이 아니기 때문입니다. 대상 장치의 이름을 IP 주소로 바꾸는 단계, TCP 445번 포트로 연결하는 단계, SMB 프로토콜을 협상하는 단계, 사용자 계정을 인증하는 단계, 공유 권한과 NTFS 권한을 적용하는 단계가 차례로 통과해야 합니다.

따라서 0x80070035를 해결하려면 설정을 무작정 켜고 끄는 대신 어느 계층에서 연결이 끊겼는지 먼저 찾아야 합니다. 이 글은 Windows 11 클라이언트가 다른 PC나 NAS의 공유 폴더에 접속하지 못할 때 사용할 수 있는 실무 진단 순서를 설명합니다.

핵심 결론: 이름·포트·인증·권한을 따로 검사해야 합니다

다음 두 주소는 같은 공유 폴더를 가리킬 수 있지만 진단상 의미가 다릅니다.

\\NAS-NAME\Share
\\192.168.0.20\Share

IP 주소로는 열리지만 이름으로는 열리지 않는다면 SMB 서비스 자체보다 DNS·LLMNR·NetBIOS 같은 이름 해석 계층을 먼저 봐야 합니다. 이름과 IP 주소 모두 실패하고 TCP 445 테스트도 실패한다면 자격 증명보다 방화벽·라우팅·서버 대기 상태를 먼저 확인해야 합니다. TCP 445는 통과하지만 “액세스가 거부되었습니다”가 나오면 인증과 권한 단계로 이동합니다.

먼저 하면 안 되는 조치

• 오류가 났다고 Windows 방화벽을 장기간 전체 해제하지 않습니다.
• 인터넷에서 받은 레지스트리 파일을 바로 실행하지 않습니다.
• SMB 1.0을 첫 해결책으로 설치하지 않습니다.
• Enable insecure guest logons를 이유 없이 활성화하지 않습니다.
• 공유 폴더의 권한을 무조건 Everyone: 모든 권한으로 바꾸지 않습니다.
• 저장된 연결을 확인하지 않고 net use * /delete를 실행하지 않습니다.
• 회사 PC의 로컬·도메인 보안 정책을 관리자 승인 없이 변경하지 않습니다.

Microsoft는 SMB1에 중대한 보안 취약점이 있어 사용하지 말 것을 강하게 권고하며, Windows 11에는 SMB1 클라이언트와 서버가 기본 설치되지 않습니다. 또한 익명 게스트 접속은 표준 SMB 서명과 암호화를 지원하지 않아 자격 증명 탈취와 릴레이 공격 위험을 높일 수 있습니다.

네트워크 공유가 열리는 기술 순서

공유 폴더 접속은 대략 다음 순서로 진행됩니다.

1. 입력한 서버 이름을 IP 주소로 해석합니다.
2. 해당 IP까지 네트워크 경로가 존재하는지 확인합니다.
3. TCP 445번 포트로 SMB 세션을 시작합니다.
4. 클라이언트와 서버가 SMB 버전·서명·암호화 조건을 협상합니다.
5. 사용자 계정과 암호를 인증합니다.
6. 공유 수준 권한을 적용합니다.
7. 파일시스템의 NTFS 권한을 적용합니다.

뒤 단계의 설정을 바꿔도 앞 단계가 막혀 있으면 효과가 없습니다. 예를 들어 포트 445가 차단된 상태에서 자격 증명을 다시 저장해도 서버와 인증 패킷을 주고받을 수 없습니다.

1단계: 정확한 UNC 경로와 실패 범위를 기록합니다

공유 경로는 역슬래시 두 개로 시작하는 UNC 형식을 사용합니다.

\\서버이름\공유이름

서버 이름만 입력한 \\서버이름과 공유 이름까지 포함한 \\서버이름\자료실을 각각 시험합니다. 서버 루트는 보이지만 특정 공유만 실패하면 네트워크보다는 공유 이름 또는 권한 문제일 가능성이 큽니다.

다음 조건도 기록합니다.

• 모든 PC에서 실패하는지 한 PC에서만 실패하는지
• 특정 공유만 실패하는지 서버의 모든 공유가 실패하는지
• 이름과 IP 주소의 결과가 다른지
• 오류가 0x80070035, 자격 증명 오류, 액세스 거부 중 무엇인지
• Windows 업데이트·NAS 펌웨어·공유 계정 변경 직후인지

2단계: 서버 이름이 올바른 IP로 해석되는지 확인합니다

PowerShell에서 다음 명령을 실행합니다.

Resolve-DnsName NAS-NAME

명령의 목적

NAS-NAME이 어떤 IP 주소로 해석되는지 확인합니다. 결과 IP가 현재 NAS의 주소와 다르거나 응답이 없다면 공유 권한을 건드리기 전에 이름 해석을 수정해야 합니다.

결과 해석

• 올바른 IPv4 주소가 출력됨: 이름 해석의 기본 단계는 통과했습니다.
• 오래된 IP가 출력됨: DHCP 주소 변경이나 DNS 캐시를 의심합니다.
• 이름이 존재하지 않는다는 오류: DNS에 등록되지 않았거나 로컬 이름 검색이 실패했습니다.
• 여러 주소가 출력됨: 실제 SMB 서버가 어느 주소에서 응답하는지 각각 확인합니다.

DNS 캐시를 확인하고 비우려면 다음 명령을 사용할 수 있습니다.

ipconfig /displaydns
ipconfig /flushdns

flushdns는 로컬 DNS 해석 캐시를 비울 뿐, 공유 파일이나 저장된 암호를 삭제하지 않습니다. 다만 근본적으로 DNS 서버에 잘못된 레코드가 있으면 다시 같은 주소를 받아오므로 임시 해결에 그칠 수 있습니다.

3단계: 이름과 IP 주소를 분리 시험합니다

파일 탐색기 주소창에서 다음을 각각 입력합니다.

\\NAS-NAME\Share
\\192.168.0.20\Share

IP 주소 접속은 진단용으로 유용하지만 장기 해결책으로 고정하면 DHCP 변경 때 다시 끊길 수 있습니다. NAS에 DHCP 예약을 적용하거나 정상적인 이름 해석 체계를 복구하는 편이 안정적입니다.

4단계: TCP 445가 실제로 열리는지 검사합니다

SMB2와 SMB3의 직접 호스팅 연결은 일반적으로 TCP 445를 사용합니다. PowerShell에서 다음을 실행합니다.

Test-NetConnection NAS-NAME -Port 445 -InformationLevel Detailed

핵심 결과는 RemoteAddress와 TcpTestSucceeded입니다.

TcpTestSucceeded : True

클라이언트에서 대상의 445번 포트까지 TCP 연결이 성립했다는 뜻입니다. SMB 인증 성공을 의미하지는 않습니다. 다음 단계에서 SMB 협상과 자격 증명을 확인합니다.

TcpTestSucceeded : False

다음 후보가 남습니다.

• NAS 또는 공유 PC가 꺼져 있거나 절전 상태
• 잘못된 IP 주소
• Windows 방화벽 또는 보안 제품에서 파일 공유 차단
• 공유기·VLAN·게스트 Wi-Fi의 클라이언트 격리
• NAS의 SMB 서비스 중지
• 회사망에서 TCP 445 제한

이 결과에서 바로 Windows 방화벽을 전체 해제하지 않습니다. 대상 PC의 네트워크 프로필과 파일 및 프린터 공유 규칙이 필요한 범위에서 허용되는지 확인해야 합니다.

5단계: 네트워크 프로필과 검색 기능을 구분합니다

Windows 11에서 설정 → 네트워크 및 인터넷 → 현재 연결 속성으로 들어가 네트워크 프로필을 확인합니다. 신뢰하는 집이나 사무실 내부망에서 공유 기능을 사용할 때는 일반적으로 개인 네트워크가 적합합니다. 공용 네트워크에서는 PC 검색과 파일 공유 노출이 제한될 수 있습니다.

그다음 고급 네트워크 설정 → 고급 공유 설정에서 다음 항목을 확인합니다.

• 네트워크 검색
• 파일 및 프린터 공유

하지만 탐색기의 네트워크 목록에 장치가 안 보이는 것과 \\IP주소\공유 직접 접속이 안 되는 것은 같은 문제가 아닙니다. 검색 기능이 꺼져도 정확한 UNC 경로로는 접속될 수 있습니다. 반대로 장치 아이콘이 보여도 TCP 445나 인증에서 실패할 수 있습니다.

6단계: 기존 SMB 연결과 자격 증명 충돌을 확인합니다

Windows는 같은 서버에 이미 다른 계정으로 연결한 상태에서 또 다른 계정을 사용하려 할 때 충돌할 수 있습니다. 명령 프롬프트에서 먼저 현재 연결을 조회합니다.

net use

연결된 서버와 드라이브 문자를 확인한 뒤, 문제가 되는 연결만 정확히 끊습니다.

net use \\NAS-NAME\Share /delete

주의

net use * /delete는 현재 사용자 세션의 모든 네트워크 연결을 끊을 수 있습니다. 업무 중인 매핑 드라이브나 프로그램 연결도 중단될 수 있으므로 목록을 확인한 후 특정 대상만 삭제하는 편이 안전합니다.

저장된 자격 증명은 제어판 → 사용자 계정 → 자격 증명 관리자 → Windows 자격 증명에서 확인합니다. 같은 NAS의 이전 IP·이름·계정이 여러 개 저장되어 있다면 실제 사용 중인 계정을 확인한 뒤 오래된 항목만 제거합니다.

새 연결을 명시적으로 시험하려면 다음처럼 사용할 수 있습니다.

net use \\NAS-NAME\Share /user:NAS-NAME\username *

마지막 *는 암호를 화면에 직접 명령문으로 노출하지 않고 입력 프롬프트를 표시하게 합니다. 암호를 명령줄에 그대로 적으면 콘솔 기록과 작업 내역에 남을 수 있으므로 피합니다.

7단계: SMB 세션이 성립한 뒤 협상 결과를 확인합니다

연결에 성공한 상태라면 PowerShell에서 다음 명령으로 SMB 세션 정보를 볼 수 있습니다.

Get-SmbConnection | Select-Object ServerName, ShareName, UserName, Dialect, Signed, Encrypted

이 명령은 이미 성립한 연결을 조회합니다. 실패한 연결이 목록에 없다고 SMB 기능이 설치되지 않았다는 뜻은 아닙니다. 연결이 인증 전에 끊겼다면 세션 자체가 만들어지지 않을 수 있습니다.

클라이언트의 SMB 설정을 읽기만 하려면 다음을 사용합니다.

Get-SmbClientConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature, EnableInsecureGuestLogons

설정을 조회한 뒤 곧바로 Set-SmbClientConfiguration으로 보안을 낮추지 않습니다. 서버가 계정 인증과 SMB2/3을 지원하도록 수정하는 것이 우선입니다.

8단계: 공유 권한과 NTFS 권한을 따로 확인합니다

공유 PC에서 대상 폴더를 우클릭한 뒤 두 위치를 확인합니다.

1. 속성 → 공유 → 고급 공유 → 권한
2. 속성 → 보안

첫 번째는 네트워크 공유 수준의 권한이고 두 번째는 NTFS 파일시스템 권한입니다. 네트워크 접속 시 두 권한이 함께 적용되며, 실제 가능한 작업은 더 제한적인 결과를 따릅니다.

예를 들어 공유 권한에서 Everyone: 변경을 허용해도 보안 탭에서 해당 사용자가 읽기만 가진다면 파일 수정은 실패합니다. 반대로 NTFS에서 수정 권한이 있어도 공유 권한이 읽기 전용이면 네트워크에서는 수정할 수 없습니다.

권한을 해결할 때 전체 사용자에게 모든 권한을 주는 방식은 개인정보와 랜섬웨어 피해 범위를 넓힐 수 있습니다. 실제 필요한 사용자 또는 그룹에 최소 권한을 부여합니다.

9단계: 게스트 로그인 차단 메시지는 ‘우회’보다 서버 수정을 우선합니다

“조직의 보안 정책에서 인증되지 않은 게스트 액세스를 차단합니다”라는 메시지는 이름 해석이나 공유 권한 오류와 다릅니다. 구형 NAS나 Samba 장치가 사용자 인증 없이 guest 세션을 요구할 때 나타날 수 있습니다.

Microsoft 문서에 따르면 Windows 11 Pro는 기본적으로 SMB 클라이언트의 게스트 연결과 잘못된 자격 증명 뒤의 게스트 전환을 허용하지 않습니다. 게스트 로그온은 암호가 없고 SMB 서명·암호화 같은 표준 보안 기능도 지원하지 않습니다.

안전한 해결 우선순위는 다음과 같습니다.

1. NAS 펌웨어를 업데이트합니다.
2. NAS에서 SMB2 또는 SMB3을 활성화합니다.
3. 공유 전용 사용자 계정과 강한 암호를 만듭니다.
4. 공유 폴더에 해당 계정의 최소 권한을 부여합니다.
5. Windows 자격 증명 관리자에 정확한 계정을 저장합니다.

게스트 로그인 허용이나 SMB 서명 요구 해제는 보안 수준을 낮추므로, 격리된 레거시 환경에서 위험을 평가한 관리자만 최후의 호환성 조치로 검토해야 합니다.

10단계: SMB1 설치 요구가 나오면 장치의 수명과 위험을 확인합니다

오래된 NAS나 복합기 설명서에서 SMB1 활성화를 요구할 수 있습니다. 그러나 SMB1은 폐기된 레거시 프로토콜이며 Microsoft는 사용하지 말 것을 권고합니다.

다음 순서로 대응합니다.

• 장치 제조사의 최신 펌웨어에서 SMB2/3 지원 여부 확인
• 공유 방식 변경 또는 지원되는 새 장치로 교체 검토
• 중요한 업무망과 레거시 장치를 분리
• 불가피한 경우 보안 담당자가 제한된 기간·범위·방화벽 정책을 설계

인터넷 검색 글을 따라 Windows 기능에서 SMB1을 켜는 것은 접속을 일시적으로 살릴 수 있어도 공격 표면을 넓힐 수 있습니다. 애드센스용 정보 글에서도 “체크하면 해결”이라고 단순 안내해서는 안 되는 이유입니다.

11단계: SMB 클라이언트 이벤트 로그로 협상 실패를 확인합니다

이벤트 뷰어에서 다음 경로를 확인합니다.

응용 프로그램 및 서비스 로그
→ Microsoft
→ Windows
→ SMBClient
→ Connectivity / Security

Connectivity에는 서버 연결과 전송 계층 문제, Security에는 인증·서명·게스트 정책과 관련된 단서가 남을 수 있습니다. 발생 시각과 UNC 경로를 맞춰 보고, 이벤트 메시지에 표시된 서버 이름·상태 코드·정책 조건을 기록합니다.

로그가 없다고 문제가 없다는 뜻은 아닙니다. 로그 채널이 비활성화되어 있거나 실패가 SMB 단계에 도달하기 전에 발생했을 수 있습니다. 이때는 Resolve-DnsName과 Test-NetConnection 결과가 더 우선입니다.

증상별 최종 판단표

전문 점검이 필요한 경우

• 업무 서버·도메인·Microsoft Entra ID·그룹 정책이 연결된 환경입니다.
• 여러 VLAN과 방화벽 구간을 지나야 합니다.
• SMB 서명 또는 암호화 정책을 변경해야 합니다.
• 랜섬웨어 대응을 위해 공유 권한 감사가 필요합니다.
• 패킷 캡처에서 SMB 협상·NTLM·Kerberos 분석이 필요합니다.
• 오래된 NAS 때문에 SMB1 또는 게스트 로그인을 요구받고 있습니다.
• 서버 로그에 반복적인 인증 실패나 계정 잠금이 기록됩니다.

관리자에게 문의할 때는 오류 화면만 보내지 말고 UNC 경로, 발생 시각, 클라이언트 IP, Resolve-DnsName 결과, Test-NetConnection 결과, SMBClient 이벤트 ID를 함께 전달합니다. 암호와 인증 토큰은 전달하지 않습니다.

네트워크 공유 진단 체크리스트

• 정확한 \\서버\공유 경로를 확인했다.
• 이름 접속과 IP 접속을 각각 시험했다.
• Resolve-DnsName 결과 IP를 확인했다.
• TCP 445 연결 성공 여부를 확인했다.
• 신뢰하는 내부망이 개인 네트워크인지 확인했다.
• 네트워크 검색과 직접 UNC 접속을 구분했다.
• net use에서 기존 연결 계정을 확인했다.
• 자격 증명 관리자에서 오래된 항목만 정리했다.
• 공유 권한과 NTFS 권한을 따로 확인했다.
• 익명 게스트 대신 전용 계정 사용을 검토했다.
• SMB1을 설치하지 않고 펌웨어·SMB2/3부터 확인했다.
• SMBClient Connectivity·Security 로그를 확인했다.

자주 묻는 질문

Q1. 0x80070035는 무조건 방화벽 오류인가요?

아닙니다. 이름 해석, 네트워크 경로, TCP 445, SMB 서비스 등 여러 계층에서 발생할 수 있습니다. 포트 검사 전에 방화벽을 끄지 않습니다.

Q2. ping이 성공하면 공유 폴더도 열려야 하나요?

아닙니다. ping은 ICMP 응답을 확인할 뿐 TCP 445와 SMB 인증 성공을 보장하지 않습니다.

Q3. TCP 445가 성공하면 무엇이 확인된 건가요?

대상 IP의 445번 포트까지 TCP 연결이 성립한 것입니다. 계정 인증, SMB 서명, 공유 권한은 별도로 확인해야 합니다.

Q4. IP로는 되는데 컴퓨터 이름으로 안 됩니다.

이름 해석 문제 가능성이 큽니다. Resolve-DnsName 결과와 실제 서버 IP를 비교하고 DNS·DHCP 구성을 확인합니다.

Q5. 자격 증명 창에 올바른 암호를 넣어도 계속 반복됩니다.

이미 다른 계정으로 같은 서버에 연결되어 있거나 사용자 이름 형식이 잘못됐을 수 있습니다. net use와 Windows 자격 증명 관리자를 확인합니다.

Q6. 공유 권한과 보안 탭 권한 중 무엇이 우선인가요?

네트워크 접속에서는 공유 권한과 NTFS 권한이 함께 적용되며 실제 허용 범위는 더 제한적인 쪽을 따릅니다.

Q7. Everyone 권한을 주면 해결되지 않나요?

접속이 될 수는 있지만 불필요한 사용자에게 데이터가 노출되고 랜섬웨어 피해 범위가 커질 수 있습니다. 필요한 사용자·그룹에 최소 권한을 부여해야 합니다.

Q8. SMB1을 설치하면 구형 NAS가 열릴까요?

일부 레거시 장치는 연결될 수 있지만 SMB1은 심각한 보안 위험이 있어 권장되지 않습니다. 펌웨어 업데이트와 SMB2/3 전환을 우선합니다.

Q9. 게스트 로그인을 켜도 되나요?

게스트 로그인은 서명·암호화 같은 표준 보안 기능을 지원하지 않습니다. 인증 계정 사용이 우선이며 정책 변경은 위험을 평가한 관리자가 제한적으로 결정해야 합니다.

Q10. 네트워크 목록에 NAS가 안 보여도 직접 접속할 수 있나요?

가능합니다. 검색 기능과 UNC 직접 접속은 다른 경로입니다. \\IP주소\공유이름을 진단용으로 시험합니다.

Q11. net use * /delete를 실행해도 되나요?

모든 네트워크 연결이 끊길 수 있어 업무 프로그램에 영향을 줄 수 있습니다. 먼저 net use로 확인하고 특정 연결만 삭제합니다.

Q12. Windows 초기화가 도움이 되나요?

DNS·방화벽·NAS 계정·공유 권한·구형 프로토콜 문제는 초기화로 해결되지 않을 수 있습니다. 계층별 결과를 수집한 뒤 원인에 맞는 조치를 해야 합니다.

마무리: 공유 폴더 오류는 ‘어디까지 연결됐는지’가 핵심입니다

네트워크 공유 폴더가 열리지 않을 때 가장 빠른 진단법은 설정을 많이 바꾸는 것이 아니라 연결이 도달한 마지막 단계를 찾는 것입니다. 이름과 IP를 비교하고, TCP 445를 검사한 뒤, 세션·자격 증명·공유 권한·NTFS 권한 순서로 이동하면 불필요한 초기화와 보안 저하를 피할 수 있습니다.

특히 구형 NAS 접속을 위해 SMB1이나 익명 게스트 인증부터 활성화하는 방식은 단기적으로 편해 보여도 장기적인 보안 위험을 만들 수 있습니다. 서버에 인증 계정을 만들고 SMB2/3과 서명·암호화를 지원하도록 업데이트하는 것이 원칙입니다.

현재 겪는 증상이 이름 접속 실패인지, TCP 445 실패인지, 로그인 반복인지 먼저 확인해 보셨나요? 개인정보와 암호를 제외하고 세 결과를 기록해 두면 서비스센터나 네트워크 관리자도 훨씬 정확하게 원인을 좁힐 수 있습니다.

공식 참고 자료

• Microsoft 지원: Windows 네트워크 파일 공유 방법
• Microsoft 지원: Windows의 핵심 네트워크 설정과 네트워크 프로필
• Microsoft Learn: SMB2·SMB3의 안전하지 않은 게스트 로그온
• Microsoft Learn: SMB1·SMB2·SMB3 감지 및 관리
• Microsoft Learn: Windows와 Windows Server의 SMB 보안 강화
• Microsoft Learn: SMB 서명 동작 제어
• Microsoft Learn: Get-SmbConnection 명령
• Microsoft Learn: 다른 사용자 자격 증명으로 네트워크 공유 연결 시 제한