r/cursor•4개월 전•0•29

Composer 2.5 너무 별로인데 저만 그런가요?

Composer 2.5

핵심 요약

Cursor의 Composer 2.5 버전이 이전보다 문맥 파악 능력이 떨어지고 엉뚱한 파일을 참조하는 등 성능이 저하되었다는 불만 제기.

성능 저하 — Composer 2.5가 이전 버전보다 문맥 파악 능력이 떨어지고 엉뚱한 파일을 참조함.
프롬프트 논쟁 — 사용자의 프롬프트 작성 방식이 문제라는 의견과 도구 자체의 성능 문제라는 의견이 대립함.
복잡한 환경 — 여러 레포지토리를 동시에 다룰 때 Cursor의 동작이 불안정해지는 경향이 있음.

저만 그런 건가요, 아니면 Composer 2.5가 정말 최악인가요? 오늘 그냥 포기하고 코드베이스를 직접 훑어보면서 전부 제가 코딩했습니다...

저는 동시에 두 개의 레포지토리를 작업 중입니다:

React Native(Expo)와 Node 서버가 포함된 모노레포
Next.js와 Node 서버가 포함된 모노레포

문맥 파악 능력이 완전히 엉망인 느낌이었습니다. 아주 구체적인 작업을 도와달라고 요청했는데 엉뚱한 곳을 뒤지기 시작하더군요.

제 편향을 테스트하기 위해 파일을 첨부하고 이렇게 물어봤습니다:
"이 파일이 무슨 역할을 하는지 모르겠는데, 설명해줄 수 있어?"

그리고

[테스트를 위해 컴포넌트를 망가뜨림]
"이 파일(참조)에서 이 컴포넌트(참조)를 사용하려고 해. 속성 Y를 설정했을 때 왜 X 방식으로 동작하지 않는지 모르겠어. 분석해줄 수 있어?"

결과는 코드베이스 전체를 훑고, 관련 없는 파일들을 읽어대며 정말 형편없는 답변만 내놓았습니다.

원문

커뮤니티 목록

r/cursor•4개월 전•0•29

Composer 2.5 너무 별로인데 저만 그런가요?

Composer 2.5

핵심 요약

Cursor의 Composer 2.5 버전이 이전보다 문맥 파악 능력이 떨어지고 엉뚱한 파일을 참조하는 등 성능이 저하되었다는 불만 제기.

성능 저하 — Composer 2.5가 이전 버전보다 문맥 파악 능력이 떨어지고 엉뚱한 파일을 참조함.
프롬프트 논쟁 — 사용자의 프롬프트 작성 방식이 문제라는 의견과 도구 자체의 성능 문제라는 의견이 대립함.
복잡한 환경 — 여러 레포지토리를 동시에 다룰 때 Cursor의 동작이 불안정해지는 경향이 있음.

저만 그런 건가요, 아니면 Composer 2.5가 정말 최악인가요? 오늘 그냥 포기하고 코드베이스를 직접 훑어보면서 전부 제가 코딩했습니다...

저는 동시에 두 개의 레포지토리를 작업 중입니다:

React Native(Expo)와 Node 서버가 포함된 모노레포
Next.js와 Node 서버가 포함된 모노레포

문맥 파악 능력이 완전히 엉망인 느낌이었습니다. 아주 구체적인 작업을 도와달라고 요청했는데 엉뚱한 곳을 뒤지기 시작하더군요.

제 편향을 테스트하기 위해 파일을 첨부하고 이렇게 물어봤습니다:
"이 파일이 무슨 역할을 하는지 모르겠는데, 설명해줄 수 있어?"

그리고

결과는 코드베이스 전체를 훑고, 관련 없는 파일들을 읽어대며 정말 형편없는 답변만 내놓았습니다.

주요 댓글

r/cursor

Composer 2.5의 성능 저하를 두고 사용자의 프롬프트 실력 문제라는 의견과, 복잡한 레포지토리 환경에서 발생하는 도구의 한계라는 의견이 팽팽하게 맞서고 있습니다.

Skill issue네. 프롬프트 연습 좀 해. 네 글에서 바로 드러나는 예시: 코드 설명을 요청할 때 AI한테 뭘 모른다고 말할 필요가 전혀 없어. 어떤 변환을 수행해야 하는지, 결과물에 대해 뭘 기대하는지를 명확히 해야지. AI한테 뭘 모른다고 인정하는 건 아무런 도움이 안 돼.

-2

😅

그냥 실력 문제임. 프롬프트 짜는 법부터 연습하셈. 글만 봐도 딱 나오네. 코드 설명해달라고 할 때 굳이 AI한테 '이거 이해 안 돼요'라고 말할 필요가 전혀 없음. 어떤 변환을 원하는지, 결과물이 어땠으면 좋겠는지 명확하게 지시해야지. AI한테 이해 못 한다고 징징대봐야 아무 도움 안 됨.

-6

아니, 그건 내 실력 문제가 아님. 기대한 결과물은 컴포넌트가 어떻게 작동하는지에 대한 설명이었음. 내가 컴포넌트를 망가뜨렸을 때 'X 방식으로 작동해라'라고 기대했는데 말이지. 네가 무슨 말 하는지는 알겠고, 큰 작업이라면 네 말에 동의하겠지만, 위처럼 작은 작업에는 해당 안 됨. 더 잘 쓸 수 있다고 해서 지금 게 충분히 좋은 게 아니라는 법은 없잖아. 내 프롬프트는 훨씬 더 나은 결과를 기대할 수 있을 만큼 충분히 좋았음.

레포 두 개 동시에 돌리면 Cursor가 정신 못 차리더라. Composer가 빠르긴 한데, 범위가 정해진 수정이 아니라 탐색부터 시작해야 하는 작업에선 훨씬 구려짐. 그 컴포넌트 테스트는 이렇게 해보셈. 일단 해당 파일 하나만 찍어서 호출 그래프(call graph) 뽑아달라고 하고, 그다음에 '먼저 물어보기 전까진 이 경로 밖은 쳐다보지 마'라는 조건을 걸어서 왜 prop Y가 동작 안 하는지 물어보셈. 그래도 딴짓하면 그건 네 프롬프트 문제가 아님.

왜 그런 문제가 생기는지 알 수 있는 정보가 부족하네. 난 Composer 2.5(그전 버전인 2도 포함) 쓰면서 결과물 아주 만족스러웠음. 4개 리포지토리 연결된 워크스페이스에서 작업 중인데 코드베이스 꽤 크거든. Composer 진짜 최고임.

got 5.5는 opus나 sonnet 4.7이랑 비교하면 어때?

Opus랑 같은 수준임. Composer 2.5는 Sonnet 수준이고.

원문r/cursor