Windows 11에서 NAS나 사내 공유폴더를 열 때 사용자 이름과 암호를 정확히 입력했는데도 “네트워크 자격 증명 입력” 창이 반복해서 나타날 수 있습니다. ‘자격 증명 기억’을 선택해도 재부팅하면 다시 묻거나, 다른 계정으로 바꾸려는데 이전 계정이 계속 자동 입력되기도 합니다.
이 증상은 암호 하나만의 문제가 아닙니다. Windows에 저장된 자격 증명, 이미 연결된 SMB 세션, 서버가 요구하는 계정 형식, NAS의 사용자 권한, Windows 11의 강화된 SMB 보안 정책 중 어느 단계에서 인증이 어긋나는지 분리해야 합니다.
이번 글에서는 다음 순서로 문제를 좁힙니다.
- 서버 이름과 사용자 계정의 소속을 정확히 구분합니다.
- 자격 증명 관리자에서 해당 서버의 오래된 항목만 제거합니다.
cmdkey와net use로 저장 정보와 현재 SMB 세션을 따로 확인합니다.- 이전 연결을 종료한 뒤 올바른 계정 형식으로 다시 연결합니다.
- TCP 445와 실제 SMB 연결의 사용자·Dialect·서명 상태를 확인합니다.
- 게스트 허용이나 SMB1 활성화 같은 위험한 우회 설정을 피합니다.
핵심 결론
Windows는 같은 로그인 세션에서 동일한 서버에 서로 다른 계정으로 동시에 연결하려 할 때 충돌할 수 있습니다. 암호를 계속 다시 입력하기보다 저장 자격 증명과 현재 연결 세션을 각각 확인한 뒤, 한 계정으로 다시 연결해야 합니다.
먼저 증상을 네 가지로 나누세요
| 증상 | 우선 의심할 원인 |
|---|---|
| 암호 입력창이 닫혔다가 곧바로 다시 나타남 | 사용자 이름 형식·암호·계정 잠금·권한 오류 |
| 올바른 새 계정을 입력해도 이전 계정으로 접속됨 | 저장된 Windows 자격 증명 또는 기존 SMB 세션 |
| PC 이름으로는 실패하지만 IP 주소로는 접속됨 | 이름 확인·DNS·서버 별칭과 자격 증명 대상 불일치 |
| 다른 PC에서는 되지만 내 PC만 실패 | 로컬 저장 자격 증명·세션·정책 문제 |
| 모든 PC에서 같은 계정만 실패 | NAS/서버 계정 상태·공유 권한·암호 만료 |
| Windows 11 업데이트 후 게스트 공유만 실패 | SMB 서명·비보안 게스트 차단 등 보안 정책 변화 |
로그인 창이 나타난다는 것은 서버에 전혀 도달하지 못한 상황과는 다릅니다. 하지만 접속 경로가 IP인지 서버 이름인지, TCP 445가 열려 있는지는 뒤에서 별도로 확인해야 합니다.
먼저 하면 안 되는 행동
- Windows 자격 증명을 전부 삭제하지 않습니다.
- NAS 계정 암호를 여러 번 무작정 바꾸지 않습니다.
- SMB1을 설치해 인증 문제를 우회하지 않습니다.
- “비보안 게스트 로그온 허용”을 전체 PC에 켜지 않습니다.
- 방화벽을 완전히 끈 상태로 계속 사용하지 않습니다.
- 명령줄에 실제 암호를 그대로 넣어 화면 기록이나 명령 기록에 남기지 않습니다.
- 회사 PC에서 NTLM·SMB 서명 정책을 임의로 해제하지 않습니다.
1단계: 사용자 이름을 ‘어느 장치의 계정인지’ 표시합니다

공유폴더 로그인 창에서 평소 Windows 로그인 이메일만 넣으면 서버가 그 계정을 알지 못할 수 있습니다. 접속 계정은 대개 공유를 제공하는 NAS 또는 파일 서버에 만들어진 계정입니다.
사용자 이름은 환경에 따라 다음처럼 입력합니다.
| 계정 위치 | 입력 예시 |
|---|---|
| NAS의 로컬 계정 | NAS-OFFICE\backupuser |
| Windows 파일 서버의 로컬 계정 | FILESERVER\seo |
| Active Directory 도메인 계정 | COMPANY\seo 또는 seo@company.local |
| Microsoft Entra·조직 환경 | 조직이 지정한 UPN 형식 |
서버 이름 앞부분을 붙이는 이유는 같은 backupuser라는 이름이 내 PC와 NAS 양쪽에 존재할 때 어느 장치의 계정인지 명확히 지정하기 위해서입니다.
여기서 확인할 것
- NAS 또는 서버 관리 화면에 해당 사용자가 실제로 존재하는지 확인합니다.
- 계정이 비활성화·잠김·암호 만료 상태가 아닌지 확인합니다.
- 공유폴더 권한과 파일 시스템 권한을 모두 확인합니다.
- 암호에 한글 입력기·Caps Lock·Num Lock 영향이 없는지 확인합니다.
- 서버 이름으로 접속할지 IP 주소로 접속할지 한 가지 방식으로 테스트합니다.
\\NAS-OFFICE\Team과 \\192.168.0.20\Team은 같은 장치를 가리키더라도 Windows의 자격 증명 대상에서는 별개로 저장될 수 있습니다. 이름과 IP를 번갈아 사용하면 오래된 항목이 남아 원인 파악이 어려워집니다.
2단계: 자격 증명 관리자에서 해당 서버 항목만 제거합니다

시작 메뉴에서 자격 증명 관리자를 검색해 실행합니다.
- Windows 자격 증명을 선택합니다.
- NAS 이름, 파일 서버 이름 또는 IP 주소와 관련된 항목을 찾습니다.
- 항목을 펼쳐 저장된 사용자 이름을 확인합니다.
- 현재 접속하려는 서버의 오래된 항목만 제거합니다.
- 관련 없는 Microsoft 계정·웹 자격 증명은 삭제하지 않습니다.
서버 이름과 IP 주소를 모두 사용했다면 다음처럼 항목이 여러 개일 수 있습니다.
NAS-OFFICE192.168.0.20Domain:target=NAS-OFFICEMicrosoftAccount:...와 무관한 일반 자격 증명
삭제 후 바로 로그인창에 새 계정을 넣었는데도 예전 계정이 사용된다면, 저장 자격 증명뿐 아니라 현재 메모리에 열린 SMB 연결 세션이 남아 있는지 확인해야 합니다.
3단계: cmdkey와 net use로 ‘저장’과 ‘연결’을 따로 봅니다

관리자 권한이 없어도 목록 확인은 가능하지만, 연결 정리와 진단을 한 창에서 진행하려면 **터미널(관리자)**을 사용하는 편이 편리합니다.
저장된 자격 증명 목록은 다음 명령으로 확인합니다.
cmdkey /list
Microsoft 공식 문서에서 cmdkey는 저장된 사용자 이름·암호·자격 증명을 만들고, 나열하고, 삭제하는 명령으로 설명됩니다.
현재 네트워크 연결은 다음으로 확인합니다.
net use
두 명령의 차이는 중요합니다.
| 명령 | 확인 대상 | 대표적인 문제 |
|---|---|---|
cmdkey /list | 디스크에 저장된 자격 증명 | 오래된 사용자 이름·암호 자동 사용 |
net use | 현재 로그인 세션의 네트워크 연결 | 다른 계정으로 이미 연결되어 새 계정 충돌 |
결과를 읽는 방법
cmdkey /list에 NAS-OFFICE 관련 항목이 있고 사용자가 예전 계정이라면 해당 대상만 삭제합니다. net use에 같은 서버의 공유가 이미 연결돼 있다면 그 연결을 먼저 끊어야 다른 계정을 안정적으로 시험할 수 있습니다.
서버 이름과 IP 주소가 각각 등장한다면 어떤 경로로 연결했는지 통일합니다. DNS 별칭으로 연결한 세션과 실제 서버명 세션이 별개로 보일 수도 있습니다.
4단계: 기존 SMB 세션과 저장 항목을 정확히 종료합니다
특정 공유 연결만 끊으려면 다음 형식을 사용합니다.
net use \\NAS-OFFICE\Team /delete
드라이브 문자로 연결했다면 다음처럼 지울 수 있습니다.
net use Z: /delete
저장 자격 증명은 cmdkey /list에 표시된 대상 이름을 확인한 뒤 삭제합니다.
cmdkey /delete:NAS-OFFICE
표시 대상이 Domain:target=NAS-OFFICE처럼 다르게 나온다면 목록에 나온 실제 대상과 맞춰야 합니다. 무관한 항목까지 한꺼번에 삭제하지 않습니다.
새 계정으로 다시 연결할 때는 명령줄에 암호를 직접 쓰지 않고 *를 사용해 암호 입력을 요청받는 방식이 안전합니다.
net use Z: \\NAS-OFFICE\Team /user:NAS-OFFICE\backupuser *
net use * /delete는 언제 사용하나요?
이 명령은 현재 사용자의 모든 네트워크 연결을 끊을 수 있습니다. 열어 둔 네트워크 파일이나 업무 프로그램 연결도 함께 종료될 수 있으므로, 특정 서버만 정리할 수 없고 영향 범위를 이해할 때 마지막으로 사용합니다.
net use * /delete

업무 중인 회사 PC에서는 먼저 열린 문서를 저장하고 연결된 업무 시스템을 확인해야 합니다.
5단계: 암호 문제인지 네트워크 문제인지 TCP 445로 분리합니다
PowerShell에서 서버의 SMB 포트가 열리는지 확인합니다.
Test-NetConnection NAS-OFFICE -Port 445
중요한 결과는 TcpTestSucceeded입니다.

- True: 서버의 SMB 포트까지 네트워크 연결이 가능하므로 인증·권한·정책을 집중 확인합니다.
- False: 암호 입력 이전에 방화벽·네트워크 위치·서버 서비스·라우팅 문제를 확인해야 합니다.
연결이 성공한 뒤 실제 SMB 세션은 다음 명령으로 확인할 수 있습니다.
Get-SmbConnection
확인할 주요 열은 다음과 같습니다.
| 항목 | 의미 |
|---|---|
| ServerName | 실제 연결한 서버 이름 |
| ShareName | 연결한 공유 이름 |
| UserName | 현재 SMB 세션에 사용된 계정 |
| Dialect | 협상된 SMB 프로토콜 버전 |
| Signed | SMB 서명 사용 여부 |
로그인 창에서 새 계정을 넣었는데 Get-SmbConnection의 UserName이 이전 사용자라면 세션 정리가 완전히 되지 않은 것입니다.
6단계: NAS·서버의 계정과 권한을 확인합니다
Windows 쪽 자격 증명을 초기화해도 계속 거부되면 공유를 제공하는 장치에서 확인합니다.
NAS에서 확인할 항목
- 사용자가 활성 상태인지
- 암호가 만료됐거나 로그인 실패로 잠기지 않았는지
- 해당 공유폴더에 읽기 또는 읽기/쓰기 권한이 있는지
- 그룹 권한과 사용자별 거부 권한이 충돌하지 않는지
- SMB 서비스가 활성화돼 있는지
- 접속 차단 목록에 내 PC의 IP가 들어가지 않았는지
- 2단계 인증과 SMB 앱 암호 같은 별도 정책이 있는지
공유폴더가 열리지만 파일 수정·삭제만 실패한다면 인증 자체는 성공했을 수 있습니다. 이 경우 공유 권한과 파일 시스템 권한을 별도 글로 진단해야 합니다.
7단계: Windows 11의 강화된 SMB 보안을 우회하지 마세요

Windows 11 24H2와 최신 Windows Server 환경은 SMB 서명과 인증 보안을 강화했습니다. Microsoft 문서에 따르면 Windows 11 24H2와 Windows Server 2025에서는 SMB 서명이 기본적으로 요구되는 범위가 확대됐으며, 게스트 사용자는 서명을 사용할 수 없어 거부될 수 있습니다.
또한 비보안 게스트 로그인은 암호를 요구하지 않고 표준 서명·암호화를 지원하지 않기 때문에 중간자 공격이나 악성 서버 위험을 높입니다.
피해야 할 임시 우회
| 우회 방법 | 위험 또는 한계 |
|---|---|
| SMB1 설치 | 오래된 프로토콜이며 최신 환경에서 기본 제거·비활성화 |
| 비보안 게스트 로그온 허용 | 인증 없이 접속하고 서명·암호화 보호가 약함 |
| SMB 서명 요구 해제 | 변조·자격 증명 릴레이 공격 방어 약화 |
| NTLM 제한 전면 해제 | 관리 환경의 인증 보안 정책 약화 |
| 방화벽 완전 비활성화 | 불필요한 포트와 서비스까지 노출 |
오래된 NAS가 게스트 접속만 지원한다면 Windows 보안을 낮추기보다 NAS에 암호가 있는 사용자 계정을 만들고 SMB2/3 및 서명을 지원하도록 펌웨어와 설정을 점검하는 편이 우선입니다.
상황별 진단표
| 확인 결과 | 다음 조치 |
|---|---|
cmdkey에 예전 계정 존재 | 해당 서버 대상만 삭제 |
net use에 같은 서버 연결 존재 | 해당 공유 세션 종료 후 재연결 |
| TCP 445 False | 서버 SMB 서비스·방화벽·네트워크 경로 확인 |
| TCP 445 True, 암호 계속 거부 | 계정 형식·암호·잠금·공유 권한 확인 |
| IP로 되고 서버명으로 실패 | DNS·이름 확인·별칭·자격 증명 대상 점검 |
| 새 계정 입력 후에도 이전 UserName 표시 | 기존 SMB 세션 완전 종료 |
| 게스트 공유만 업데이트 후 실패 | NAS에 인증 계정 생성 및 SMB 보안 호환성 확인 |
| 회사 도메인에서 NTLM 관련 실패 | 관리자에게 Kerberos·SPN·정책 확인 요청 |
최종 체크리스트
- 서버 이름·IP·공유 이름을 정확히 구분했습니다.
- NAS 또는 서버에 실제 존재하는 계정을 사용했습니다.
- 사용자 이름을
서버명\사용자또는도메인\사용자형식으로 시험했습니다. - 자격 증명 관리자에서 해당 서버의 오래된 항목만 제거했습니다.
cmdkey /list와net use를 모두 확인했습니다.- 기존 SMB 세션을 종료하고 새 계정으로 다시 연결했습니다.
Test-NetConnection -Port 445결과를 확인했습니다.Get-SmbConnection에서 실제 사용 계정을 확인했습니다.- NAS 계정 잠금과 공유 권한을 확인했습니다.
- SMB1·비보안 게스트·서명 해제 같은 위험한 우회를 사용하지 않았습니다.
자주 묻는 질문
‘자격 증명 기억’을 선택했는데 왜 다시 묻나요?
저장한 대상 이름과 실제 접속 주소가 다르거나, 기존 SMB 세션이 다른 계정을 사용하거나, 서버가 그 계정을 거부하면 다시 나타날 수 있습니다. 서버명과 IP를 번갈아 사용했는지도 확인합니다.
Windows 로그인 PIN을 NAS 암호로 넣으면 되나요?
대부분 아닙니다. PIN은 해당 Windows 장치의 로그인 수단이고, 네트워크 공유는 NAS나 서버에 등록된 계정 암호를 요구합니다.
자격 증명 관리자를 모두 지워도 되나요?
권장하지 않습니다. 다른 서버·원격 데스크톱·앱 로그인에도 영향을 줄 수 있으므로 문제 서버와 일치하는 항목만 제거합니다.
IP 주소로 접속하면 되는데 서버 이름으로는 안 됩니다
이름 확인 문제일 가능성이 있습니다. 그러나 IP와 이름에 서로 다른 자격 증명이 저장됐을 수도 있으므로 cmdkey /list와 net use 결과를 함께 비교합니다.
시스템 오류 1219가 나타납니다
같은 서버에 서로 다른 사용자 이름으로 여러 연결을 시도했을 때 자주 나타납니다. 열린 파일을 저장한 뒤 기존 서버 연결을 종료하고 한 계정으로 다시 연결합니다.
Windows 11 업데이트 후 게스트 NAS가 갑자기 안 됩니다
최신 Windows는 SMB 서명과 게스트 인증 보안을 강화했습니다. 비보안 게스트를 전역 허용하기보다 NAS에 암호가 있는 사용자를 만들고 SMB2/3 호환성을 확인하는 것이 안전합니다.
공유폴더는 열리지만 파일을 삭제할 수 없습니다
로그인은 성공한 상태일 수 있습니다. 공유 권한과 NAS 또는 NTFS 파일 권한, 읽기 전용 설정을 별도로 확인해야 합니다.
마무리: 저장된 암호와 현재 연결 계정은 서로 다릅니다
네트워크 자격 증명 창이 반복될 때 가장 많이 놓치는 부분은 자격 증명 관리자에 저장된 계정과 현재 SMB 연결에 실제 사용 중인 계정이 별개라는 점입니다.
따라서 저장 자격 증명 확인 → 현재 세션 확인 → 기존 연결 종료 → 계정 소속을 명시해 재연결 → TCP 445와 실제 SMB 사용자 확인 순서로 처리해야 합니다. 이 방식이면 무작정 암호를 변경하거나 SMB 보안을 낮추지 않고 문제 지점을 찾을 수 있습니다.
현재 증상이 서버 이름으로 접속할 때만 나타나는지, IP 주소에서도 동일한지 먼저 비교해 보세요. 그 한 가지 결과만으로도 이름 확인 문제와 계정·권한 문제를 크게 나눌 수 있습니다.

댓글 남기기