Cursor의 AI 에이전트(AI agent)로 코딩을 하던 중, 아무런 반응 없이 작은 “Thinking...”(생각 중...) 표시가 영원히 회전하는 것을 목격했다면, 당신만 겪는 문제가 아닙니다. Cursor Composer 2.5 프리징(freezing) 현상은 현재 Cursor 커뮤니티 포럼에서 가장 많이 보고되는 문제 중 하나이며, 특히 여러 파일이 열려 있는 긴 에이전트 세션(agent session) 중간에 발생하는 경향이 있습니다.

이 가이드는 이 문제가 왜 발생하는지, 지금 당장 어떻게 해결할 수 있는지, 그리고 문제가 계속 반복될 경우 어떻게 해야 하는지를 정확히 안내합니다. 불필요한 미사여구 없이, 동일한 문제를 겪고 있는 개발자들의 실제 보고를 바탕으로 실제로 작동하는 단계만을 제공합니다.

빠른 해결 요약 박스
시간이 촉박하다면, 전체 가이드를 읽기 전에 다음 단계들을 순서대로 시도해 보세요:

1. 30~60초 동안 기다리기 — 과부하 상태에서는 일부 “멈춤(stuck)” 상태가 스스로 해결되기도 합니다.
2. 채팅창에 “continue” 또는 “go on”을 입력하고 Enter를 누르기 — 이는 많은 무음 정지(silent hangs) 상태를 해제합니다.
3. 창 다시 로드(Reload the window) — Cmd+Shift+P (Mac) 또는 Ctrl+Shift+P (Windows/Linux) → “Developer: Reload Window” 입력 → Enter.
4. 멈춘 채팅을 계속하는 대신 새로운 Composer 채팅 시작하기.
5. 모델을 Composer 2.5에서 다른 모델(예: Opus 또는 GPT)로 일시적으로 전환한 후 다시 전환하기.
6. Cursor를 최신 버전으로 업데이트하기 — 많은 프리징 버그들이 몇 주 내에 패치됩니다.
7. 다시 로드가 도움이 되지 않는다면 Cursor를 완전히 재시작하기 (창을 닫는 것이 아니라 종료(quit)해야 함).
8. status.cursor.com 확인하기 — 일부 프리징은 로컬 버그가 아니라 일시적인 백엔드(backend) 장애일 수 있습니다.

이 중 어떤 방법도 작동하지 않는다면, 아래의 전체 단계별 가이드를 계속 읽어주세요.

Cursor Composer 2.5 프리징이란 무엇인가?
Cursor Composer 2.5 프리징은 Cursor IDE 내부의 AI 에이전트가 작업 중간에 멈추는 현상을 말합니다. 보통 “Thinking…”(생각 중...), “Taking longer than expected…”(예상보다 오래 걸리는 중...) 메시지가 표시되거나, 응답도 없고 에러도 없으며 깔끔하게 취소할 방법도 없이 회전하는 인디케이터만 나타납니다. 에이전트가 실행 중인 것처럼 보이지만, 턴(turn)을 완료하지 못하고, 파일을 편집하지 못하며, 답변도 하지 못하는 상태입니다.

이는 느린 응답(slow response)과는 다릅니다. 느린 응답은 결국 완료됩니다.

프리징(freeze)은 세션이 스스로 복구할 수 없는 상태에 갇혔음을 의미합니다. Cursor 커뮤니티에서는 사용자가 "continue"와 같은 짧은 후속 메시지를 보내 차단을 해제하지 않으면, 이러한 멈춤 현상 중 일부는 결코 해결되지 않는다고 보고했습니다.

또한, 이 현상이 특정 버전에만 국한된 것이 아니라는 점을 알아둘 필요가 있습니다. 개발자들은 Composer 1, Composer 2, 그리고 현재의 Composer 2.5에 이르기까지 유사한 'Thinking' 상태에서의 멈춤 동작을 보고해 왔습니다. 특히 여러 에이전트(agent)와 서브 에이전트(subagent)를 동시에 실행할 때, Composer 에이전트가 오류 메시지나 복구 방법 없이 무한히 "Thinking..." 상태에 빠지는 현상이 발생합니다.

왜 이런 문제가 발생할까요?

Composer 2.5는 복잡한 에이전트 모델(agentic model)입니다. 단순히 텍스트를 생성하는 것에 그치지 않고, 계획을 세우고, 도구(tool)를 호출하며, 파일을 편집하고, 터미널 명령어를 실행하며, 로컬 환경의 응답을 기다립니다. 이 과정 중 어느 한 고리라도 약해지면 프리징이 발생할 수 있습니다. 상세 원인은 다음과 같습니다:

• 장시간 실행되는 에이전트 루프(Long-running agent loops): Composer 2.5는 지속적이고 다단계적인 작업을 수행하도록 설계되었습니다. 작업이 길어지면 모델의 도구 호출(tool calls)과 Cursor의 로컬 실행 간의 동기화가 어긋날 수 있으며, 이로 인해 UI에는 "Thinking"이라고 표시되지만 실제로는 아무런 작업도 일어나지 않는 상태가 됩니다.
• 서브 에이전트의 복잡성(Subagent complexity): Composer가 작업의 일부를 처리하기 위해 서브 에이전트를 생성할 때, 단 하나의 서브 에이전트 실패만으로도 오류를 표시하지 못한 채 전체 부모 세션(parent session)이 중단될 수 있습니다.
• 파일 동기화 문제(File sync issues): 일부 멈춤 현상은 백그라운드에서 로컬 파일 동기화 기능이 조용히 실패하는 것과 관련이 있습니다.
• 과도한 로컬 리소스 사용(Heavy local resource usage): Cursor IDE는 코드 에디터 위에 AI 런타임(runtime)과 프로젝트 파일을 얹어 놓은 구조입니다. 사양이 낮은 기기이거나, 많은 확장 프로그램(extension) 및 대규모 리포지토리(repo)가 열려 있는 경우 리소스가 빠르게 부족해질 수 있습니다.
• 네트워크/API 지연(Network/API latency): Composer 2.5는 완전한 로컬 모델이 아니라 Cursor의 백엔드를 통해 실행됩니다. API와의 연결이 끊기거나 느려지면 UI가 불확실한 상태(limbo)에 빠질 수 있습니다.
• 속도 제한 또는 사용량 제한(Rate limiting or usage caps): 사용 중인 플랜의 요청 제한(request limits)에 도달하면, 응답 시간이 급격히 늘어나 마치 프리징된 것처럼 보일 수 있습니다.

손상된 채팅/세션 상태 (Corrupted chat/session state): 때때로 대화 스레드 자체가 많은 턴(turn)을 거친 후 잘못된 상태에 빠지게 되며, 모델이 해당 스레드 내에서 복구되지 못할 수 있습니다.

일반적인 원인 (Common Causes)
다음은 사용자들이 보고한 가장 빈번한 근본 원인과 일반적인 증상을 매칭한 빠른 참조 테이블입니다:

| 원인 | 일반적인 증상 | 빠른 테스트 |
| :--- | :--- | : |
| 멀티 에이전트 / 서브 에이전트 과부하 (Multi-agent / subagent overload) | 오류 없이 무한히 “Thinking…” 상태에 머무름 | 여러 에이전트가 실행 중일 때만 발생하는지 확인 |
| 긴 대화 스레드 (Long conversation thread) | 많은 턴 이후 프리징 발생 (“5턴까지는 잘 작동하다가 멈춤”) | 새로운 채팅을 시작하여 동일한 속도로 프리징이 발생하는지 확인 |
| 오래된 Cursor 빌드 (Outdated Cursor build) | 업데이트 후 무작위 중단, “generating 중 멈춤” | Help > About에서 버전을 확인하고 최신 버전과 비교 |
| 낮은 시스템 메모리/CPU (Low system memory/CPU) | 프리징 전 IDE 전체가 느려짐 | 프리징 발생 시 작업 관리자(Task Manager) / 활성 상태 보기(Activity Monitor) 확인 |
| 네트워크 불안정 (Network instability) | 사라지지 않는 “Taking longer than expected” 메시지 | 다른 네트워크에서 테스트하거나 연결 상태 확인 |
| 계정 사용 제한 도달 (Account usage limits hit) | 극도로 느린 응답, 수 시간의 지연 | Cursor 설정의 사용량 대시보드(usage dashboard) 확인 |
| 파일 동기화 오류 (File sync errors) | 콘솔에 동기화 관련 오류 태그와 함께 멈춤 발생 | 개발자 도구(Developer Tools) 콘솔을 열어 동기화 오류 확인 |
| 특정 모델의 특이 사항 (Specific model quirk) | 특정 모델에서만 발생하며 다른 모델은 정상임 | 모델을 전환한 후 동일한 프롬프트로 재테스트 |

단계별 해결 방법 (Step-by-Step Solutions)
다음은 가장 쉽고 빠른 방법부터 더 복잡한 방법 순으로 나열되었습니다. 순서대로 시도해 보세요.

1. 후속 메시지 보내기 (Send a Follow-Up Message) 너무 간단해 보일 수 있지만, 가장 일관되게 보고되는 해결 방법 중 하나입니다. 만약 Composer 2.5가 “Thinking…”(생각 중...) 또는 “Taking longer than expected…”(예상보다 오래 걸리는 중...) 상태에서 멈춰 있다면, 다음과 같이 짧은 메시지를 입력하세요: continue(계속해), go on(계속해), finish the task(작업을 완료해). 이렇게 하면 세션에 자극을 주어 컨텍스트(Context)를 잃지 않고도 멈춤 현상을 빈번하게 해제할 수 있습니다.

2. Cursor 개발자 창 재로드 사용 (Use Cursor Developer Reload Window) 이는 응답하지 않는 Cursor Composer 2.5를 위한 가장 효과적인 내장 해결 방법입니다. 단계: Cmd+Shift+P (Mac) 또는 Ctrl+Shift+P (Windows/Linux)를 눌러 명령 팔레트(Command Palette)를 엽니다. “Developer: Reload Window”를 입력합니다. Enter를 누릅니다. 이 방법은 프로젝트를 닫지 않고 Cursor 창을 재로드하여, 열려 있는 파일은 유지하면서 에디터의 내부 상태를 재시작합니다. 저장되지 않은 작업(저장되지 않은 파일 변경 사항은 유지되지만, 진행 중인 에이전트 실행은 취소됨)을 잃지 않으면서 AI 패널의 대부분의 일시적인 오류를 해결합니다.

3. 멈춘 채팅을 종료하고 새 채팅 시작하기 (Kill the Stuck Chat and Start a New One) 재로드로 해결되지 않는 경우: 멈춰버린 Composer 탭/채팅을 닫습니다. 새로운 Composer 세션을 엽니다 (Cmd+I / Ctrl+I). 관련 컨텍스트를 짧게 다시 붙여넣습니다 (닫기 전 접근이 가능하다면 멈춘 채팅에서 마지막 몇 개의 메시지를 복사할 수 있습니다). 이는 현재 개발자들이 채팅을 마비시키는 무한 “Thinking” 버그로부터 복구하기 위해 사용하는 수동 해결책입니다. 시간과 토큰(Tokens)이 다소 소모되더라도, 새로운 에이전트를 시작하고 이전 대화 컨텍스트를 수동으로 입력하는 방식입니다.

4. 모델 일시적 전환 (Switch the Model Temporarily) 채팅 패널에서 모델 선택기(Model Picker)를 열고 Composer 2.5에서 다른 모델(Opus, GPT 또는 사용 가능한 다른 옵션)로 전환한 뒤, 간단한 테스트 프롬프트를 실행하고 다시 Composer 2.5로 전환합니다. 이 방법은 해당 채팅 세션의 기본 연결 상태를 재설정하는 데 자주 도움이 됩니다.

5. Cursor 완전히 재시작하기 (Restart Cursor Completely) 단순한 재로드(Reload)가 아닌 전체 재시작은 창 재로드보다 더 많은 것을 정리합니다. Mac: Cmd+Q를 눌러 완전히 종료한 다음 다시 엽니다.

Windows/Linux: 작업 표시줄에서 모든 Cursor 창을 닫고, 작업 관리자(Task Manager)를 통해 Cursor.exe 프로세스가 남아 있지 않은지 확인한 후 다시 엽니다.
6. 시스템 리소스 확인 및 확보: 시스템 부하와 관련된 Cursor IDE 프리징(Freeze) 문제를 해결하는 방법: 사용하지 않는 브라우저 탭, Docker 컨테이너 또는 기타 메모리 점유율이 높은 앱을 종료합니다. Cursor가 열려 있는 동안 Activity Monitor (Mac) 또는 작업 관리자 (Windows)에서 CPU/RAM 사용량을 확인합니다. 크거나 관련 없는 워크스페이스(Workspace)를 닫으세요. 여러 개의 거대한 리포지토리(Repo)를 별도의 창에 열어두면 리소스 소모가 빠르게 누적됩니다.
7. Cursor를 최신 버전으로 업데이트: Cursor 메뉴 > 업데이트 확인(Check for Updates)으로 이동하거나 (cursor.com에서 최신 설치 프로그램을 다운로드합니다). 특정 빌드와 관련된 프리징 버그는 보고된 후 며칠에서 몇 주 이내에 흔히 패치되므로, 오래된 빌드는 흔하면서도 쉽게 해결 가능한 원인입니다.
8. 네트워크 연결 확인: Composer 2.5는 사용자의 기기에서 완전히 실행되는 것이 아니라 Cursor의 백엔드(Backend)를 통해 실행되므로, 불안정한 연결은 실제 프리징과 동일해 보이는 멈춤 현상을 유발할 수 있습니다. 유선 연결이나 다른 Wi-Fi 네트워크를 시도해 보세요. 간섭 가능성을 배제하기 위해 VPN을 일시적으로 비활성화합니다. Cursor의 상태 페이지(Status page)를 확인하여 진행 중인 장애가 있는지 점검합니다.
9. 사용량 제한(Usage Limits) 도달 여부 확인: Cursor 내부의 설정(Settings) > 사용량(Usage)으로 이동하여 남은 할당량(Quota)을 확인합니다. 제한이 있는 플랜을 사용 중이고 빠른 요청(Fast-request) 허용량을 모두 소진했다면, 응답 속도가 급격히 느려져 완전히 실패하는 대신 마치 프리징된 것처럼 느껴질 수 있습니다.
10. Cursor 상태 페이지 확인 및 요청 ID(Request ID) 공유: 때때로 프리징은 로컬 문제가 아니라 Cursor 측의 일시적인 백엔드 장애일 수 있습니다. 문제가 사용자 기기에 있다고 가정하기 전에: status.cursor.com을 방문하여 Composer에 영향을 미치는 활성 또는 최근 해결된 장애가 있는지 확인합니다. 문제를 보고해야 하는 경우, 문제가 발생한 대화에서 요청 ID(Request ID)를 찾아(Cursor의 공식 문제 해결 문서에 위치가 설명되어 있습니다) 포럼 게시물이나 지원 티켓(Support ticket)에 포함하세요.

Cursor 커뮤니티 포럼에서 확인된 사례에 따르면, 이 단계는 Cursor 지원 팀이 가장 먼저 요청하는 사항입니다. 이를 통해 지원 팀은 추측하는 대신, 멈춰버린 특정 백엔드 실행(backend run)을 추적할 수 있습니다.

고급 문제 해결 방법 (Advanced Troubleshooting Methods)

기본적인 단계로 문제가 해결되지 않거나 프리징(freeze) 현상이 계속 반복된다면, 다음 방법들을 시도해 보세요:

개발자 콘솔 검사 (Inspect the Developer Console)
커맨드 팔레트(Command Palette)를 열고 “Developer: Toggle Developer Tools”를 실행하세요. 프리징이 발생하는 순간의 Console 탭에서 오류를 확인하세요. 특히 동기화 관련 오류(sync-related errors)를 주의 깊게 살펴보시기 바랍니다. 일부 사용자들은 Composer가 생성 중에 멈출 때 로그에 나타나는 파일 동기화 오류(file-sync error)와 프리징 현상 사이의 연관성을 보고했습니다.

충돌하는 확장 프로그램 비활성화 (Disable Conflicting Extensions)
일부 서드파티(third-party) 확장 프로그램이 Cursor의 AI 패널 렌더링이나 백그라운드 프로세스를 방해할 수 있습니다. 필수적이지 않은 확장 프로그램을 하나씩 비활성화하며 다시 테스트해 보세요.

Cursor 로컬 캐시/설정 삭제 (Clear Cursor's Local Cache/Settings) — 최후의 수단
로컬 상태(local state)의 손상이 의심되는 경우:

1. 먼저 사용자 정의 설정(custom settings)이나 스니펫(snippets)을 백업하세요.
2. Cursor를 완전히 종료하세요.
3. 사용 중인 OS의 Cursor 애플리케이션 지원/설정(support/config) 폴더를 찾아 캐시(cache) 디렉토리의 이름을 변경하세요(삭제하지 마세요).
4. Cursor를 다시 열면 새로운 캐시가 다시 구축됩니다.

서브에이전트(Subagents) 과부하 방지
멀티 에이전트(multi-agent) 또는 서브에이전트(subagent) 워크플로우를 실행 중이라면, 프리징이 발생하는 작업에 대해서는 단일 에이전트로 규모를 축소하세요. 이는 현재 Cursor 팀이 추적 중인 서브에이전트 관련 '생각 중 멈춤(stuck-thinking)' 버그를 직접적으로 해결하는 방법입니다. 사용자들은 멈춘 멀티 에이전트 세션을 위해 복구 로직을 자동으로 생성하는 “Repair” 버튼이나 /repair 명령어를 제안했으나, 이 글을 쓰는 시점 기준으로 해당 수정 사항은 아직 배포되지 않았습니다.

최소한의 프로젝트에서 재현 (Reproduce in a Minimal Project)
작은 테스트 프로젝트를 열고 간단한 Composer 2.5 프롬프트를 실행해 보세요. 만약 거기서도 프리징이 발생한다면, 해당 문제는 특정 대규모 코드베이스와 관련된 것이 아니라 환경적 요인(Cursor 빌드, 네트워크, 시스템)에 의한 것입니다.

실제 사례

예시 1: "5회 대화 후 프리징"
한 개발자는 Composer를 사용할 때, 새로운 창에서 약 5회 정도 대화가 오간 후 Cursor가 완전히 멈추는 현상을 보고했습니다. 반면 Claude Code는 긴 작업들을 문제없이 완료했습니다. 해결 방법: 하나의 스레드를 길게 유지하는 대신 몇 번의 대화마다 새로운 채팅을 시작하고, 세션 사이에 앱을 완전히 재시작하는 것이 효과적이었습니다.

예시 2: 조용한 "Thought briefly" 중단
또 다른 사용자는 에이전트가 정상적으로 작동하다가, 갑자기 "Thought briefly"라는 메시지를 표시한 뒤 오류 메시지나 작업 완료 여부에 대한 표시 없이 멈춰버린다고 설명했습니다. 대부분의 경우 "continue"를 입력하면 해결되었으며, 나머지는 창을 새로고침하여 해결했습니다.

예시 3: Composer 사용 후 충돌
한 보고에 따르면, Composer가 몇 초간 작동하다가 프리징이 발생한 후 "window terminated unexpectedly" 오류와 함께 충돌이 발생했습니다. 이는 전체 재설치 후에도 지속되었습니다. 이 경우 문제는 특정하여 Composer 패널에서만 발생했습니다(일반 채팅은 정상 작동). 이는 시스템 전체의 문제라기보다 패널 특정적인 렌더링 버그임을 시사하며, 대부분의 영향을 받은 사용자들은 "Developer Reload Window"를 실행하고 확장 프로그램(extensions)을 비활성화함으로써 문제를 해결했습니다.

예시 4: 프리징으로 오해한 사용량 제한에 따른 속도 저하
Pro 플랜 사용자가 500회 프리미엄 요청 제한에 도달한 후, 요청 하나당 거의 하루가 걸리는 것처럼 느껴질 정도로 속도가 거의 멈추는 현상을 보고했습니다. 이는 실제 프리징은 아니었지만, 사용량 대시보드(usage dashboard)를 먼저 확인하지 않으면 프리징과 구별할 수 없었습니다.

예시 5: Cursor 팀 자체의 서버 측 장애 확인
잘 기록된 한 포럼 스레드에서, 한 사용자가...