Microsoft Teams: "We couldn't connect" 연결·로그인 오류
안녕하세요, BlueByte입니다. Microsoft Teams를 열면 창이 스피너에서 로딩되다가 We couldn't connect. Try again.에서 멈추거나, 로딩 스플래시에 계속 머물거나, 로그인 화면에 0xCAA70007·0xCAA20003 같은 코드가 뜨는 경우가 있습니다. 여러분 PC가 고장 난 게 아니라, Teams가 로그인에 필요한 핸드셰이크를 끝내지 못하는 상황입니다. 오늘은 이 메시지들이 뜻하는 것, 원인을 구분하는 법, 원인별 실행 가능한 해결, 그리고 재발 방지까지 하나씩 짚어보겠습니다.
"We couldn't connect"와 CAA 코드가 알려주는 것
Teams는 같은 이야기를 몇 가지 형태로 보여 줍니다:
We couldn't connect. Try again.
We ran into a problem. Reconnecting…
Status code: 0xCAA70007
Status code: 0xCAA20003각 메시지는 클라이언트가 로그인의 어느 지점 — 로컬 상태를 불러온 뒤 Microsoft 인증 서비스에 토큰을 요청하는 단계 — 에 도달했지만 이를 끝내지 못했다는 뜻입니다. 순수한 We couldn't connect는 보통 오래된 로컬 상태를 가리키고, 0xCAA 코드는 토큰 교환 자체를 가리키며 끝 네 자리 16진수가 원인을 좁혀 줍니다. 어느 쪽도 계정이 사라졌다는 뜻은 아닙니다.
Teams 로그인을 막는 다섯 가지
Teams가 연결에 실패하는 원인은 다음 중 하나입니다:
- 손상된 로컬 캐시 — 클라이언트가 조율하지 못하는 오래된 토큰과 설정 때문에 재연결을 반복합니다.
- 잘못된 시스템 시계 — 날짜나 시간이 틀리면 보안 엔드포인트로의 TLS가 실패하고, Teams는
0xCAA20003을 보고합니다. - 네트워크나 방화벽이 인증 엔드포인트를 막음 — Teams가
login.microsoftonline.com에 닿지 못해0xCAA70007이나0xCAA82EE2로 나타납니다. - 잘못된 자격 증명 — 이메일이나 비밀번호가 틀린 경우로
0xCAA90018로 보고됩니다. - 테넌트나 라이선스 문제 — 관리자가 앱을 비활성화했거나 구독이 만료되어 애초에 토큰이 발급되지 않는 경우입니다.
앞의 두 가지는 여러분이 1분 안에 직접 고칩니다. 나머지 셋은 빠르게 확인한 뒤 직접 고치거나 IT 관리자에게 넘깁니다.
먼저 어떤 Teams를 쓰는지 확인하기
캐시 경로는 classic Teams와 new Teams가 다르므로, 무엇이든 지우기 전에 어느 쪽인지 확인하세요:
Get-AppxPackage -Name MSTeams | Select-Object Name, VersionName Version
---- -------
MSTeams <build number, varies by update>MSTeams를 가리키는 줄이 나오면 new Teams입니다. 명령이 아무것도 반환하지 않으면 classic Teams입니다. 로그인 화면 왼쪽 아래에 표시되는 코드도 적어 두세요 — 아래에서 씁니다.
캐시를 지워 오래된 로컬 상태 고치기
이것이 순수한 We couldn't connect 반복의 해결책입니다. 먼저 Teams를 완전히 종료하세요 — 실행 중인 프로세스가 파일을 다시 잠급니다. classic Teams에서는:
Get-Process -Name Teams -ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item -Path "$env:APPDATA\Microsoft\Teams\*" -Recurse -Forcenew Teams에서는:
Get-Process -Name ms-teams -ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item -Path "$env:LOCALAPPDATA\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\*" -Recurse -ForcemacOS에서는 Teams를 종료(⌘-Q)하고 Terminal에서 지웁니다 — classic은 rm -r ~/Library/Application\ Support/Microsoft/Teams, new Teams는 rm -rf ~/Library/Group\ Containers/UBF8T346G9.com.microsoft.teams와 rm -rf ~/Library/Containers/com.microsoft.teams2를 씁니다. 여기서 지우는 것은 메시지나 파일이 아닙니다 — 그것들은 클라우드에 있고, 여러분은 Teams가 다음 실행 때 다시 만드는 로컬 사본만 지우는 것입니다. 겁먹지 않아도 됩니다. Teams를 다시 실행해 로그인하면 캐시를 새로 만드느라 첫 실행이 조금 느립니다.
보안 연결을 깨뜨리는 시계 고치기
코드가 0xCAA20003이면 컴퓨터 시계가 틀려 Microsoft 엔드포인트로의 TLS가 실패하는 것입니다. 시간을 다시 맞추세요:
w32tm /resyncSending resync command to local computer...
The command completed successfully.그런 다음 설정에서 날짜·시간·시간대가 맞는지 확인하세요. macOS나 Linux에서는 자동 시간을 켜세요(Linux는 sudo timedatectl set-ntp true). 몇 분만 어긋나도 핸드셰이크가 깨지기에 충분합니다.
네트워크·자격 증명·테넌트가 문제일 때
0xCAA70007이나 0xCAA82EE2이면 Teams가 인증 서비스에 닿지 못하는 것입니다. 엔드포인트가 닿는지 확인하세요:
Test-NetConnection login.microsoftonline.com -Port 443TcpTestSucceeded : TrueFalse로 나오면 방화벽·프록시·VPN이 가로막고 있는 것입니다 — IT 관리자와 함께 Microsoft 365 엔드포인트를 허용하세요. 0xCAA90018이면 올바른 이메일과 비밀번호로 다시 로그인하세요. 그리고 조직의 누구도 로그인하지 못하거나 코드가 비활성화된 앱을 가리키면, 이는 관리자만 풀 수 있는 테넌트나 라이선스 문제입니다 — 정확한 상태 코드를 적어 전달하세요.
실제 사례: 스피너에 멈춘 classic Teams
한 사용자의 classic Teams가 로딩 스피너로 열려 We couldn't connect. Try again.에 도달합니다. 시계는 맞고 다른 앱은 인터넷에 닿으므로 로컬 상태 문제입니다. Get-AppxPackage -Name MSTeams가 아무것도 반환하지 않아 classic Teams임이 확인됩니다. 종료한 뒤 위의 classic Teams 명령 두 줄로 %APPDATA%\Microsoft\Teams를 지우고 다시 실행합니다. 캐시가 새로 만들어지는 20초쯤 뒤 로그인이 끝나고 Teams가 연결을 유지합니다. 계정과 데이터는 처음부터 멀쩡했고, 로컬 캐시만 걸려 있었던 것입니다.
Teams가 로그인해 연결을 유지하는지 확인하기
고친 뒤 Teams는 채팅 목록에 도달해 그대로 있어야 하며 Reconnecting…으로 되돌아가지 않아야 합니다. 자신에게 메시지를 보내고 새로고침해 보세요 — 메시지가 남아 있고 상태가 온라인으로 보이면 로그인이 건강한 것입니다. 그래도 연결되지 않으면 상태 코드를 다시 읽으세요 — 다른 코드는 캐시 정리 실패가 아니라 이 목록의 다른 원인을 뜻합니다.
재발 방지, 그리고 Outlook이 시작되지 않는 것과의 차이
new Teams가 오래된 빌드에 묶이지 않고 스스로 업데이트하게 두고, 시스템 시계를 자동 시간으로 유지하고, Teams를 쓰기 도중에 강제 종료하지 말고 깔끔하게 종료해 캐시가 반쯤 쓰인 채 남지 않게 하세요. 이것은 Outlook의 Cannot start Microsoft Outlook과는 다른 실패입니다 — 그쪽은 손상된 로컬 프로필이나 OST가 원인이고, Teams 캐시가 아니라 프로필을 복구해 고칩니다. 둘 다 로컬 상태 문제지만 서로 다른 앱, 다른 폴더에 있습니다. 다음에 Teams가 연결되지 않으면 상태 코드부터 읽고, 캐시에서 시계, 네트워크 순으로 이 목록을 따라가 보세요.
관련 질문
캐시를 지우면 채팅이나 파일이 사라지나요?
아니요. 메시지·파일·채널은 캐시가 아니라 Microsoft 365에 있습니다. 지우는 것은 Teams가 다음 로그인 때 다시 만드는 로컬 사본이며, 비용은 첫 실행이 느려지는 것뿐입니다.
new Teams인데 classic %APPDATA% 경로가 비어 있습니다.
정상입니다 — new Teams는 캐시를 %APPDATA%\Microsoft\Teams가 아니라 %LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache 아래에 둡니다. Get-AppxPackage -Name MSTeams로 어느 쪽인지 확인한 뒤 해당 경로를 지우세요.
코드가 0xCAA20003입니다.
시계가 틀려 TLS가 실패하는 것입니다. w32tm /resync를 실행한 뒤 날짜·시간·시간대를 고치세요. 몇 분만 어긋나도 로그인이 깨지기에 충분합니다.
회사의 모두가 동시에 겪습니다.
그것은 여러분 PC가 아니라 테넌트를 가리킵니다 — 만료된 구독이나 관리자가 비활성화한 앱입니다. 캐시 정리는 도움이 되지 않으니 상태 코드를 IT 관리자에게 전달하세요.
연결됐다가 "Reconnecting…"으로 되돌아갑니다.
보통 네트워크가 오래 유지되는 연결을 끊는 경우입니다 — 불안정한 VPN이나 프록시. Test-NetConnection login.microsoftonline.com -Port 443으로 확인하고, 간헐적으로 실패하면 Teams가 아니라 엔드포인트로 가는 경로가 문제입니다.
참고 자료
Haneul Seo
Infrastructure engineer · 10+ years running Linux fleets
같은 카테고리 다른 글
Gmail이 550-5.7.26으로 거부: 도메인의 DMARC 정책 때문에 인증되지 않은 메일이 수신 거부됨
Gmail이 우리 도메인이 직접 게시한 DMARC 정책을 집행한 결과입니다. 메시지가 header From: 도메인 기준으로 SPF·DKIM 정렬을 모두 통과하지 못했고, p=quarantine이나 p=reject 정책이 이를 하드 바운스로 바꿉니다. Authentication-Results 헤더가 어느 검사가 실패했는지 알려주고, SPF·DMARC·DKIM 레코드를 향한 dig 세 번이 원인을 지목합니다. SPF나 DKIM으로 인증하라는 비슷한 문구의 바운스는 정책이 아니라 Gmail의 기본 발신자 요구사항에 걸린 다른 문제입니다.
Microsoft Entra ID: AADSTS50011, 요청에 지정된 redirect URI 가 앱에 등록된 redirect URI 와 일치하지 않음
로그인은 끝까지 성공했는데 마지막 한 단계에서 Entra ID 가 거부합니다. 앱이 보낸 redirect_uri 가 등록된 URI 중 어느 것과도 문자 단위로 같지 않기 때문입니다. 비교는 대소문자를 구분하고 끝의 슬래시를 세며, localhost 를 제외하면 https 를 요구하고 포트도 일치해야 합니다. 목록도 web·spa·publicClient 세 개로 나뉘어 있고, application 객체가 아닌 service principal 에 넣은 URI 는 동기화 과정에서 사라질 수 있습니다. 오류 메시지에서 URI 와 앱 ID 를 꺼내 az ad app show 로 대조하고, az ad app update 나 Graph PATCH 로 정확한 문자열을 넣은 뒤 3~5분 기다리면 됩니다.
Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled
smtp.office365.com 으로 메일을 보내던 스캐너·스크립트·앱이 535 5.7.139 로 멈추는 이유는 SMTP AUTH 프로토콜이 테넌트 전체, 해당 메일박스, 또는 Basic 인증을 막는 인증 정책·보안 기본값 중 어딘가에서 꺼져 있기 때문입니다. 문구(Tenant, Mailbox, 'did not meet the criteria')를 읽고 Get-TransportConfig·Get-CASMailbox·Get-AuthenticationPolicy 로 확인한 뒤, 테넌트 전체가 아니라 필요한 메일박스 하나만 엽니다. Basic SMTP AUTH 는 다리일 뿐입니다. Microsoft 는 2026년 12월 말 기존 테넌트에서 기본 비활성화하므로 발신자를 OAuth·High Volume Email·릴레이 커넥터로 옮겨야 합니다.
Zoom: "Unable to connect" 오류 코드 5003 — 브라우저는 되는데 데스크톱 앱만 Zoom 에 못 붙을 때
오류 5003 은 같은 PC 의 웹 클라이언트는 정상 입장하는데 Zoom 데스크톱 앱이 Zoom 서버와의 연결을 끝내지 못하는 상태입니다. 앱은 브라우저보다 더 많은 것을 필요로 합니다. Zoom 방화벽 문서는 미팅용 TCP 443/8801/8802 와 UDP 3478/3479/8801–8810, 인증서 검증용 CA 호스트 목록을 들고, zoom.us 와 *.zoom.us 를 프록시·SSL 검사에서 제외하라고 권고합니다. 포트 테스트, curl issuer 확인, 앱 내장 Network Connectivity Tool(Ctrl+Alt+Shift+D / Cmd+Option+Shift+D)로 어느 계층이 끊겼는지 보고 그 계층을 고치며, 재설치는 옆자리는 되는데 한 대만 실패할 때 씁니다.
Slack: 회사 프록시 뒤에서 뜨는 "Slack cannot connect"와 회색 "Last updated…" 띠
Slack은 채널을 평범한 HTTPS로 불러오지만 새 메시지는 443 포트로 Slack이 이름을 밝힌 wss-*.slack.com 호스트 셋(primary·backup·mobile)에 붙는 지속 WebSocket으로 받습니다. 프록시나 방화벽이 HTTP 쪽은 통과시키고 upgrade는 막으면 — 대개 wss 호스트에 SSL 복호화가 켜져 있거나 허용 목록이 slack.com에서 끝나기 때문에 — 브라우저는 멀쩡해 보이는데 앱은 회색 "Last updated…" 띠나 "Slack cannot connect."를 띄웁니다. 문제의 PC에서 curl 프로브 두 개로 어느 계층이 막혔는지 보고, wss 호스트 세 개를 복호화에서 예외 처리하고, my.slack.com/help/urls의 도메인을 전부 허용한 뒤 my.slack.com/help/test로 확인합니다.
Word: 문서가 "locked for editing by another user"라며 열리지 않음
Word가 문서의 잠금(owner file)을 발견해 다른 누군가가 열어 두었다고 판단하고 읽기 전용 사본만 제안합니다. 대개는 아무도 열지 않았습니다: 크래시가 잠금을 남겼거나, 숨은 Word 프로세스가 여전히 파일을 쥐고 있는 것입니다. 어느 쪽인지 확인하고 Word 인스턴스를 모두 닫은 뒤 남겨진 ~$ owner file을 삭제하면 문서가 다시 편집 가능하게 열립니다.