Cursor Agent 일반 문제 해결

Cursor의 agent 모드는 강력하지만, 문제가 발생하면 증상이 혼란스러울 수 있습니다. 무기한 중단되는 agent, 설명 없이 저하되는 성능, 또는 예상보다 훨씬 적은 토큰으로 사용량 미터가 100%에 도달하는 것, 이 모두는 포럼 사용자들이 정기적으로 보고하는 문제입니다. 이 가이드는 Cursor에서 가장 일반적인 agent 문제에 대한 구체적이고 테스트된 해결책을 제공합니다.

Agent가 "Taking Longer Than Expected"에서 중단됨

가장 많이 보고된 agent 문제입니다. agent가 작업을 시작하고, 작업을 시작한 후 "Taking longer than expected" 메시지로 정체됩니다. 때로는 결국 완료되고, 때로는 영원히 완료되지 않습니다.

메시지 이해

"Taking longer than expected"는 오류가 아닙니다. agent의 현재 작업이 시간 임계값을 초과했다는 알림입니다. agent는 무언가를 기다리고 있을 가능성이 있습니다:

대기 원인	가능성	수정 난이도
AI 제공자에 대한 네트워크 요청	높음	쉬움
도구 실행 시간 초과	중간	중간
대용량 파일 읽기/인덱싱	중간	쉬움
터미널 명령 중단	중간	중간
MCP 서버 응답 없음	낮음	중간
Cursor 내부 버그	낮음	어려움

진단 단계 1: 네트워크 연결 확인

agent는 Cursor의 클라우드에 의존하여 AI 모델을 실행합니다. 네트워크가 불안정하거나 프록시 뒤에 있으면 agent가 중단됩니다.

# Cursor API 연결 테스트
curl -w "Time: %{time_total}s\n" -o /dev/null -s https://api2.cursor.sh/health

# 프록시 뒤에 있는지 확인
echo $HTTP_PROXY
echo $HTTPS_PROXY

팁

회사 VPN이나 프록시 뒤에 있는 경우 agent가 간헐적으로 중단될 수 있습니다. Cursor의 Settings > General > HTTP Proxy에서 프록시 설정을 구성하세요. 프록시가 WebSocket 연결을 허용하는지 확인하세요. Cursor는 agent 응답 스트리밍에 WebSocket을 사용합니다.

진단 단계 2: 도구가 멈춰 있는지 확인

agent가 도구 실행(예: 터미널 명령, 파일 검색, MCP 도구 호출)을 기다리고 있을 수 있습니다. agent의 활동 표시기를 확인하세요. "Running command..." 또는 "Searching files..."와 같이 표시되면, 중단은 AI 모던이 아닌 도구 실행에 있습니다.

해결: 현재 agent 실행을 취소(Cmd/Ctrl + .)하고 다시 시도하세요. 동일한 도구에서 지속적으로 중단되면 해당 도구에 문제가 있는 것입니다. 아래의 터미널 중단 및 MCP 섹션을 참조하세요.

진단 단계 3: 컨텍스트 크기 줄이기

큰 컨텍스트 창은 단계당 처리해야 할 데이터가 많아지므로 agent를 느리게 합니다. 프로젝트가 크거나 많은 파일이 열려 있는 경우:

1. 현재 작업에 필요하지 않은 파일 닫기
2. @ 멘션을 사용하여 관련 파일만 참조
3. 대규모 프로젝트에서는 필요하지 않는 한 @codebase 피하기
4. 채팅 기록이 너무 길어지면 삭제

경고

@codebase 멘션은 agent에게 인덱싱된 전체 코드베이스를 검색하도록 지시합니다. 10,000개 이상의 파일이 있는 프로젝트에서는 상당한 시간이 걸릴 수 있으며 "Taking longer than expected" 메시지를 트리거할 수 있습니다. 더 나은 성능을 위해 대상을 지정한 @file 또는 @folder 멘션을 대신 사용하세요.

진단 단계 4: agent 프로세스 재시작

위의 방법들이 도움이 되지 않으면, agent 프로세스 자체가 나쁜 상태일 수 있습니다:

1. 명령 팔레트 열기(Cmd/Ctrl + Shift + P)
2. Developer: Reload Window 입력
3. 재로드 후 새 agent 세션 시작

이것은 프로젝트를 닫지 않고 메모리 내 상태를 지웁니다.

느린 agent 성능

agent가 느리지만 완전히 멈추지 않은 경우, 경험은 좌절스럽게 느려질 수 있습니다. 포럼 사용자는 각 단계에 30초 이상 걸리는 "초느림" 성능을 설명합니다.

일반적인 성능 문제 원인

1. 대규모 코드베이스 인덱싱

agent를 사용하는 동안 Cursor가 코드베이스를 인덱싱 중이면 성능이 크게 저하됩니다. 상태 표시줄에서 인덱싱 표시기를 확인하세요.

해결:

• 무거운 agent 작업을 시작하기 전에 인덱싱이 완료될 때까지 대기
• 불필요한 인덱싱을 건너뛰기 위해 대규모 디렉터리를 files.exclude에 추가:

{
  "files.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true,
    "**/.next": true,
    "**/coverage": true,
    "**/.git/objects": true
  }
}

2. 너무 많은 열린 탭

열린 각 파일은 메모리와 컨텍스트를 소비합니다. Cursor는 agent의 컨텍스트 인식을 위해 열린 파일을 추적합니다.

해결: 적극적으로 작업하지 않는 파일을 닫으세요. Cmd/Ctrl + W로 현재 탭을 닫으세요. 언제든 다시 열 수 있습니다.

3. 백그라운드 agent 충돌

포어그라운드 agent를 사용하는 동안 백그라운드 agent가 실행 중이면, 리소스를 놓고 경쟁합니다.

해결: 상태 표시줄에서 실행 중인 백그라운드 agent를 확인하세요. 포어그라운드 작업을 하는 동안 일시 중지하거나 취소하세요.

4. 구식 Cursor 버전

성능 개선은 각 Cursor 업데이트와 함께 제공됩니다. 구형 버전을 실행하면 최적화를 놓치는 것입니다.

해결:

# Cursor 버전 확인
# Help > About (macOS에서는 Cursor > About)

2버전 이상 뒤처진 경우 즉시 업데이트하세요.

성능 최적화 체크리스트

• 코드베이스 인덱싱 완료
• 대규모 디렉터리가 인덱싱에서 제외됨
• 열린 파일이 10-15개 이하
• 백그라운드 agent가 일시 중지되거나 완료됨
• Cursor가 최신 버전으로 업데이트됨
• VPN/프록시 문제 없음 (curl로 테스트)
• 충분한 시스템 RAM (최소 8GB, 권장 16GB)
• 디스크에 최소 20% 여유 공간

Windows에서의 whois.exe 충돌

Windows에서 놀라울 정도로 일반적이고 구체적인 문제: whois.exe 프로세스가 관련될 때 agent가 중단되거나 충돌합니다. 포럼 사용자는 agent 불안정성을 이 Windows 시스템 유틸리티로 추적했습니다.

whois.exe란?

whois.exe는 도메인 이름 조회를 수행하는 Windows Sysinternals 도구입니다. 표준 Windows의 일부는 아니지만 개발자가 일반적으로 설치합니다. 일부 Cursor 확장이나 MCP 서버가 네트워크 작업 중에 호출할 수 있습니다.

충돌

다음과 같은 경우 문제가 발생합니다:

1. MCP 서버 또는 확장이 whois.exe를 자식 프로세스로 생성
2. whois.exe가 중단되는 네트워크 요청 수행 (예: 방화벽 뒤의 도메인 쿼리)
3. 자식 프로세스가 시간 초과되지 않음
4. agent가 자식 프로세스 완료를 무기한 대기
5. agent가 중단된 것으로 보임

해결 1: PATH에서 whois.exe 제거

개발에 whois.exe가 필요하지 않은 경우:

# whois.exe가 PATH에 있는지 확인
where.exe whois

# 발견된 경우, PATH에서 제거 (필요에 따라 경로 조정)
$path = [System.Environment]::GetEnvironmentVariable("PATH", "User")
$newPath = ($path -split ";" | Where-Object { $_ -notlike "*Sysinternals*" }) -join ";"
[System.Environment]::SetEnvironmentVariable("PATH", $newPath, "User")

이 변경 후 Cursor를 재시작하세요.

해결 2: whois.exe를 호출하는 것 식별

Process Monitor를 사용하여 어떤 프로세스가 whois.exe를 생성하는지 찾습니다:

1. Sysinternals에서 Process Monitor 다운로드
2. Process Monitor 시작
3. 필터 설정: Process Name contains whois.exe
4. Cursor에서 agent 작업 시작
5. 어떤 프로세스가 whois.exe를 생성하는지 관찰

식별한 후, 해당 MCP 서버 또는 확장을 구성하여 whois.exe를 트리거하는 네트워크 조회를 비활성화합니다.

팁

MCP 서버가 도메인을 검증하기 위해 whois.exe를 생성하는 경우, 서버 구성에서 verifyDomains 또는 dnsLookup 설정을 확인하세요. 보안을 위해 도메인 검증이 필요하지 않은 MCP 서버에서 이를 비활성화하면 중단을 방지할 수 있습니다.

해결 3: 프로세스 시간 초과 설정

자식 프로세스를 생성하는 MCP 서버의 경우, 시간 초과를 구성합니다:

{
  "mcpServers": {
    "problematic-server": {
      "command": "npx",
      "args": ["-y", "@org/server"],
      "env": {
        "CHILD_PROCESS_TIMEOUT_MS": "10000",
        "DISABLE_WHOIS": "true"
      }
    }
  }
}

터미널 선택 중단

관련되었지만 다른 문제: agent가 통합 터미널에서 텍스트를 선택하려고 할 때 중단됩니다. agent가 텍스트를 선택하는 것처럼 보이는 상태에 들어가지만 작업을 완료하지 못합니다.

원인

일반적으로 다음과 같은 경우 발생:

1. 터미널에 큰 스크롤백 버퍼가 있음
2. 터미널에서 실행 중인 애플리케이션이 대체 화면 모드에 있음 (예: vim, less, top)
3. agent가 화면 경계에 걸쳐 있는 텍스트를 선택하려고 시도

해결 1: 터미널 스크롤백 지우기

터미널을 포함하는 agent 작업을 시작하기 전에:

1. 현재 터미널 종료 (Cmd/Ctrl + Shift + )
2. 새 터미널 열기
3. agent 작업 시작

해결 2: 대체 화면 프로그램 피하기

agent는 전체 화면 터미널 애플리케이션과 안정적으로 상호 작용할 수 없습니다. 워크플로에 agent가 터미널 명령을 실행하는 것이 포함된 경우:

• agent의 터미널에서 vim, nano, less, top, htop 실행 피하기
• 비대화형 대안 사용: less 대신 cat, less 대신 head

해결 3: 터미널 설정 구성

{
  "terminal.integrated.scrollback": 1000,
  "terminal.integrated.enablePersistentSessions": false
}

스크롤백을 줄이면 agent가 선택 시 처리해야 하는 텍스트 양을 제한하여 중단을 방지합니다.

경고

agent가 터미널과 상호 작용할 때 지속적으로 중단되는 경우, 작업이 실제로 터미널 상호 작용을 필요로 하는지 고려하세요. 많은 터미널 작업(테스트 실행, 출력 확인)은 Cursor의 내장 패널을 통해 수행할 수 있으며, 이는 agent 상호 작용에 더 안정적입니다.

더 적은 토큰으로 사용량 100% 도달

많은 포럼 사용자가 보고하는 좌절스러운 문제: 사용량 대시보드가 100% 사용량을 표시하지만, 사용자는 그렇게 많은 토큰을 사용하지 않은 것을 알고 있습니다. 이는 조기에 제한되거나 속도 제한을 받는 인상을 줍니다.

사용량 계산 이해

Cursor의 사용량 미터는 단순한 원시 토큰 수가 아닌 여러 항목을 추적합니다:

구성 요소	계산하는 것	대략적 가중치
입력 토큰	모델에 전송된 토큰	높음
출력 토큰	모델이 생성한 토큰	높음
컨텍스트 검색	코드베이스 인덱싱 및 검색	중간
도구 호출	각 도구 실행	호출당 낮음, 누적
파일 읽기	agent가 읽는 각 파일	읽기당 낮음, 누적
MCP 작업	각 MCP 서버 상호 작용	중간

팁

50개 파일을 읽고, 10번의 도구 호출을 수행하고, 5000개의 출력 토큰을 생성하는 단일 agent 작업은 15000개의 출력 토큰을 생성하는 작업과 동일한 "사용량"을 소비할 수 있습니다. 사용량 미터는 순수한 토큰 카운터가 아닙니다. agent가 소비한 모든 계산 리소스의 가중 조합입니다.

사용량이 예상보다 빨리 100%에 도달하는 이유

이유 1: 컨텍스트 팽창

agent 작업의 각 단계는 전체 대화 컨텍스트와 참조된 파일을 모델로 전송합니다. 대화에 20턴이 있고 10개 파일을 참조하는 경우, 21단계는 그 모든 것에 새 내용을 추가하여 전송합니다. 토큰 수는 선형이 아닌 이차적으로 증가합니다.

해결:

• 각 고유 작업에 새 채팅 시작
• 관련 없는 작업 사이에 /clear 사용
• 전체 코드베이스 참조 피하기; 특정 파일 사용

이유 2: 반복된 파일 읽기

agent는 다른 단계에서 동일한 파일을 여러 번 읽을 수 있습니다. 각 읽기는 사용량에 계산됩니다.

해결:

• agent가 파일을 반복해서 읽는 것을 발견하면, 명시적으로 말하세요: "파일 X의 내용은 이미 있습니다. 다시 읽지 마세요."
• @file 멘션을 사용하여 파일을 컨텍스트에 한 번 로드

이유 3: Plan 모드 오버헤드

Plan 모드를 사용하면 agent는 실행 전에 계획을 생성합니다. 이 계획 생성은 코드가 변경되지 않았음에도 불구하고 사용량에 계산되는 토큰을 소비합니다.

해결: 모든 작업이 아닌 선택적으로 Plan 모드를 사용하세요.

실제 사용량 모니터링

실제 토큰 분석을 보려면:

1. 상태 표시줄의 사용량 표시기 클릭
2. 상세 분석 보기
3. "Context tokens"와 "Generated tokens" 확인

컨텍스트 토큰이 생성된 토큰을 크게 초과하는 경우, 사용량은 실제 코드 생성이 아닌 컨텍스트 팽창에 의해 소비되고 있는 것입니다.

경고

사용량이 겉보기에 최소한의 활동으로 지속적으로 100%에 도달하는 경우, 통제 불능 백그라운드 agent를 확인하세요. 루프에 빠진 백그라운드 agent는 사용량을 빠르게 소비합니다. Background Agents 패널에서 결과를 생성하지 않고 지속적인 활동을 보이는 agent가 있는지 확인하고 취소하세요.

대시보드 비용 가시성

포럼 사용자들은 Cursor 대시보드가 비용 분석을 명확하게 표시하지 않아, 돈이 어디에 사용되는지 이해하기 어렵다고 보고합니다.

대시보드가 표시하는 것

Cursor 대시보드(Settings > Usage에서 접근)는 다음을 표시합니다:

1. 총 사용량 - 플랜 한도의 백분율
2. 모델 분석 - 어떤 모델이 가장 많이 소비했는지
3. 타임라인 - 청구 기간 동안의 사용량

대시보드가 표시하지 않는 것

• 작업별 토큰 수 (개별 채팅을 확인해야 함)
• 달러 비용 (Pro/Business 플랜의 경우, 사용량은 백분율로 표시되며 달러 금액이 아님)
• 컨텍스트 vs 생성 토큰 분할 (채팅별로만 가능, 집계 불가)
• MCP 서버 사용량 (MCP 호출에 의한 토큰 사용량은 분리되지 않음)

더 나은 가시성을 위한 해결 방법

작업별 사용량 추적

각 중요한 agent 작업 후, 사용량 백분율을 기록하세요. 이것은 어떤 작업 유형이 가장 비용이 많이 드는지에 대한 정신 모델을 구축합니다:

Task: Refactor auth module - 15% usage
Task: Write unit tests - 8% usage
Task: Debug API endpoint - 5% usage

API를 사용한 상세 지표

Business 플랜을 사용하는 경우, API를 쿼리하여 상세 사용량을 얻을 수 있습니다:

# 사용량 상세 정보 가져오기 (Business 플랜 API)
curl -H "Authorization: Bearer $CURSOR_API_KEY" \
  https://api2.cursor.sh/usage/details?period=current

이것은 모델, 작업 유형 및 날짜별로 토큰 사용량의 JSON 분석을 반환합니다.

고정된 프롬프트 헤더 수정

agent 사용성에 영향을 미치는 UI 문제: 프롬프트 입력 헤더가 창 상단에 고정되어 스크롤되지 않으며, 화면 공간을 차지하고 내용을 가립니다.

문제

agent 응답이 긴 경우, 프롬프트 입력 바가 상단에 고정된 상태로 유지됩니다. 작은 화면에서는 이것이 표시 영역의 20-30%를 소비할 수 있어, 실제 응답을 위한 공간이 거의 남지 않습니다.

해결 1: 전체 화면 채팅 전환

Cmd/Ctrl + Shift + L을 눌러 채팅 패널을 전체 화면 모드로 전환합니다. 이것은 응답에 더 많은 공간을 제공하고 고정 헤더를 비례적으로 작게 만듭니다.

해결 2: 채팅 레이아웃 조정

{
  "cursor.chat.stickyHeader": false,
  "cursor.chat.compactMode": true
}

stickyHeader를 false로 설정하면 프롬프트 헤더가 나머지 내용과 함께 스크롤됩니다.

팁

stickyHeader 설정이 Cursor 버전에서 사용할 수 없는 경우, cursor.chat.inputBehavior라고 불릴 수 있습니다. Settings > Features > Chat에서 입력 바 동작을 구성하기 위한 옵션을 확인하세요. 정확한 설정 이름은 버전에 따라 변경되었습니다.

해결 3: 더 넓은 창 사용

고정 헤더가 문제가 아니지만 화면 공간이 부족한 경우, Cursor 창 너비를 늘리세요. 채팅 패널은 800px+ 너비에서 더 사용하기 쉽습니다. 13인치 랩톱에서는 agent 집약적 작업을 위해 외장 모니터를 고려하세요.

일반 문제 해결 워크플로

agent가 오작동하고 있고 구체적으로 어떤 문제가 적용되는지 확신할 수 없는 경우, 이 체계적인 접근 방식을 따르세요.

단계 1: 격리된 재현

1. 새 채팅 시작
2. 간단한 작업 부여: "내용이 'hello'인 test.txt라는 파일을 만드세요"
3. 이것이 실패하면, 문제는 환경적입니다 (네트워크, Cursor 설치, 시스템 리소스)
4. 이것이 성공하면, 문제는 작업 특정입니다 (큰 컨텍스트, 특정 도구, MCP)

단계 2: 로그 확인

1. 출력 패널 열기 (Cmd/Ctrl + Shift + U)
2. 드롭다운에서 Cursor Agent 선택
3. 오류 메시지, 시간 초과 또는 예외 찾기

단계 3: 안전 모드

모든 확장과 MCP 서버 비활성화:

1. Cmd/Ctrl + Shift + P > Extensions: Disable All Installed Extensions
2. MCP 서버 구성 임시 제거
3. Cursor 재시작
4. agent 테스트

안전 모드에서 agent가 작동하면, 문제는 확장이나 MCP 서버로 인한 것입니다. 원인을 격리하기 위해 하나씩 다시 활성화합니다.

단계 4: 진단 정보 수집

문제를 Cursor 지원에 보고해야 하는 경우:

# Cursor 버전
cursor --version

# 시스템 정보
# macOS: system_profiler SPHardwareDataType
# Windows: systeminfo | findstr /B /C:"OS Name" /C:"Total Physical Memory"
# Linux: uname -a && free -h

# Cursor 로그 위치
# macOS: ~/Library/Application Support/Cursor/logs/
# Windows: %APPDATA%/Cursor/logs/
# Linux: ~/.config/Cursor/logs/

요약

Cursor의 agent 문제는 몇 가지 범주로 나뉩니다: 중단을 일으키는 네트워크 및 연결 문제, 느림을 일으키는 리소스 경합, whois.exe와 같은 Windows 특정 충돌, 터미널 상호 작용 제한, 그리고 예상보다 빨리 할당량을 소비하는 것처럼 느끼게 만드는 사용량 계산 특성. 이 가이드의 진단 단계를 따르면, 대부분의 agent 문제의 근본 원인을 식별하고 맹목적으로 재시작하고 최선을 바라는 대신, 대상을 지정한 해결책을 적용할 수 있습니다.