Cursor는 내가 20년 넘게 써온 서비스 중 유일하게, 고객 지원이 전혀 되지 않아 구독을 취소한 제품임
여러 주에 걸쳐 결제 관련 질문을 여러 번 메일로 보냈지만, 단 한 번도 답장을 받지 못함
단순 VS Code 관련 문의가 아니라 Cursor의 팀원 개입이 꼭 필요한 이슈였음
하지만 홍보 메일은 잘만 잘 옴
Cursor의 ‘가치’가 빨리 다른 서비스에도 확산되길 바람
다음 팀은 메일에 답장해주길 기대
이 프롬프트에는 빠진 내용이 많음
가장 두드러지는 건 tool call descriptors의 부재
1년 전 jailbreaking 프롬프트와 직접 비교해봐도 됨
그래도 cursor rules 등 다른 부분의 설정은 아이디어가 좋음
참고로, 관련 프롬프트 자료는 여기서 볼 수 있음
Cursor에서는 사용자가 취하는 액션에 따라 다른 프롬프트를 사용함
지금은 샘플만 제공했는데, 근본적인 목표는 다양한 모델을 A/B 테스트하고 프롬프트와 모델을 최적화하는 것임
재현할 수 있도록 코드도 제공했고, 거기서 다른 프롬프트들도 참고할 수 있음
네가 공유한 Gist 자료도 꽤 유용함
혹시 어떤 최적화 로직이 있어서, 유저의 쿼리에서 꼭 필요한 도구 정보만 프롬프트에 포함시키는 것 아닐까 하는 생각이 듦
아마도 토큰 절약을 위해 불필요한 tool descriptor는 과감히 빼는 전략을 쓰고 있을 듯
기사 마지막에 어떻게 쓸지 결정하기 전에 훑어보는 첫 게시물일 뿐이라고 명시돼 있음
참고로, 요즘은 단순히 패킷을 보는 용도로 mitmproxy가 꽤 훌륭해짐 mitmproxy docs
wireshark는 데스크탑 앱에서 Cursor 서버로 가는 요청(실질적으로 LLM에 보내는 요청)을 보는 데에는 쓸 수 있음
하지만 Cursor의 서버에서 LLM으로 실제 요청이 어떻게 가는지 보고 싶으면, 별도 설정이 필요
이런 설정이면 우리가 요청을 바꿔가며 A/B 테스트도 해볼 수 있음
Cursor 및 다양한 IDE 모달리티 솔루션은 흥미롭지만, 이들이 컨텍스트를 대충 다루는 습관을 기르게끔 만든다는 점이 아쉬움
Cursor 프롬프트에서 발췌한 문구를 보면,
"사용자가 메시지를 보낼 때마다 현재 상태, 세션 내 편집 히스토리, 린터 에러 등 추가 정보를 우리가 자동으로 붙일 수 있고, 이 정보는 코딩 작업에 연관될 수도 있고 안 될 수도 있음. 적절성은 니가 결정하라"는 식임
이런 ‘컨텍스트 블로트’는 LLM이 진짜 어려운 문제를 해결할 때 성능을 크게 제한함
예시로 든 .env 문제는 간단한 유형이라 Cursor가 잘 다루지만, 이 정도 복잡성으론 소프트웨어 엔지니어를 계속 고용할 수 없음
개인적으론 AI와 작업할 때 먼저 채팅 인터페이스에서 대화 맥락을 깔끔하게 관리하는 방법부터 고민하길 제안
복잡한 문제에서는 미팅, 슬랙 대화, 내부 문서, 외부 컨텐츠, 코드 등이 맥락에 얽혀 있기 때문
난 FileKitty(링크)와 최근엔 slackprep(링크) 같은 툴을 만들어서, 문제 해결과 관련 있는 정보만 추려내 더 의도적으로 쓸 수 있도록 함
나도 이 부분에 동의하며, 내 에이전트 앱을 개발할 땐 맥락을 훨씬 신중하게 큐레이션해야 했음
"자동으로 첨부할 수 있다"가 아니라 실제 첨부한 것만 포함해 지시문 작성이 필요했음
"연관될 수도 있고 아닐 수도 있으니 네가 알아서 결정해라" 대신, 연관성이 있을 때와 없을 때 각각 어떻게 해야 할지 명확한 지시가 있어야 효과적임
맥락이 짧은 경우엔 별 문제 없지만, 길고 복잡한 이슈에선 이러한 세밀한 인스트럭션이 큰 차이를 만듦
아마 Cursor는 캐시된 토큰 가격의 장점을 위해 지시를 최대한 일반적으로 해두는 것 같음
아직 많은 부분이 실험 단계이고, 앞으로 프롬프트와 모델 개선이 많이 이뤄질 걸로 봄
Hacker News 의견
Cursor는 내가 20년 넘게 써온 서비스 중 유일하게, 고객 지원이 전혀 되지 않아 구독을 취소한 제품임
여러 주에 걸쳐 결제 관련 질문을 여러 번 메일로 보냈지만, 단 한 번도 답장을 받지 못함
단순 VS Code 관련 문의가 아니라 Cursor의 팀원 개입이 꼭 필요한 이슈였음
하지만 홍보 메일은 잘만 잘 옴
Cursor의 ‘가치’가 빨리 다른 서비스에도 확산되길 바람
다음 팀은 메일에 답장해주길 기대
이 프롬프트에는 빠진 내용이 많음
가장 두드러지는 건 tool call descriptors의 부재
1년 전 jailbreaking 프롬프트와 직접 비교해봐도 됨
그래도 cursor rules 등 다른 부분의 설정은 아이디어가 좋음
참고로, 관련 프롬프트 자료는 여기서 볼 수 있음
Cursor에서는 사용자가 취하는 액션에 따라 다른 프롬프트를 사용함
지금은 샘플만 제공했는데, 근본적인 목표는 다양한 모델을 A/B 테스트하고 프롬프트와 모델을 최적화하는 것임
재현할 수 있도록 코드도 제공했고, 거기서 다른 프롬프트들도 참고할 수 있음
네가 공유한 Gist 자료도 꽤 유용함
혹시 어떤 최적화 로직이 있어서, 유저의 쿼리에서 꼭 필요한 도구 정보만 프롬프트에 포함시키는 것 아닐까 하는 생각이 듦
아마도 토큰 절약을 위해 불필요한 tool descriptor는 과감히 빼는 전략을 쓰고 있을 듯
관련 참고자료는 여기에 있음
그럼... wireshark는 이제 쓸 수 없는 것임?
기사 마지막에 어떻게 쓸지 결정하기 전에 훑어보는 첫 게시물일 뿐이라고 명시돼 있음
참고로, 요즘은 단순히 패킷을 보는 용도로 mitmproxy가 꽤 훌륭해짐 mitmproxy docs
wireshark는 데스크탑 앱에서 Cursor 서버로 가는 요청(실질적으로 LLM에 보내는 요청)을 보는 데에는 쓸 수 있음
하지만 Cursor의 서버에서 LLM으로 실제 요청이 어떻게 가는지 보고 싶으면, 별도 설정이 필요
이런 설정이면 우리가 요청을 바꿔가며 A/B 테스트도 해볼 수 있음
Cursor 및 다양한 IDE 모달리티 솔루션은 흥미롭지만, 이들이 컨텍스트를 대충 다루는 습관을 기르게끔 만든다는 점이 아쉬움
Cursor 프롬프트에서 발췌한 문구를 보면,
"사용자가 메시지를 보낼 때마다 현재 상태, 세션 내 편집 히스토리, 린터 에러 등 추가 정보를 우리가 자동으로 붙일 수 있고, 이 정보는 코딩 작업에 연관될 수도 있고 안 될 수도 있음. 적절성은 니가 결정하라"는 식임
이런 ‘컨텍스트 블로트’는 LLM이 진짜 어려운 문제를 해결할 때 성능을 크게 제한함
예시로 든 .env 문제는 간단한 유형이라 Cursor가 잘 다루지만, 이 정도 복잡성으론 소프트웨어 엔지니어를 계속 고용할 수 없음
개인적으론 AI와 작업할 때 먼저 채팅 인터페이스에서 대화 맥락을 깔끔하게 관리하는 방법부터 고민하길 제안
복잡한 문제에서는 미팅, 슬랙 대화, 내부 문서, 외부 컨텐츠, 코드 등이 맥락에 얽혀 있기 때문
난 FileKitty(링크)와 최근엔 slackprep(링크) 같은 툴을 만들어서, 문제 해결과 관련 있는 정보만 추려내 더 의도적으로 쓸 수 있도록 함
"자동으로 첨부할 수 있다"가 아니라 실제 첨부한 것만 포함해 지시문 작성이 필요했음
"연관될 수도 있고 아닐 수도 있으니 네가 알아서 결정해라" 대신, 연관성이 있을 때와 없을 때 각각 어떻게 해야 할지 명확한 지시가 있어야 효과적임
맥락이 짧은 경우엔 별 문제 없지만, 길고 복잡한 이슈에선 이러한 세밀한 인스트럭션이 큰 차이를 만듦
아마 Cursor는 캐시된 토큰 가격의 장점을 위해 지시를 최대한 일반적으로 해두는 것 같음
아직 많은 부분이 실험 단계이고, 앞으로 프롬프트와 모델 개선이 많이 이뤄질 걸로 봄
Cursor의 프롬프트에 대한 다른 분석은 여기서 볼 수 있음
긴 대화에서 관련 맥락을 선별하는 과정이 항상 궁금했음
실제로 그 로직을 리버스 엔지니어링해서 어떻게 변환 기록을 잘라내고, 파일의 최신 상태를 어떻게 표현하는지 알아낸 사람이 있는지 궁금함
앞으로도 이 부분을 계속 조사하며, TensorZero를 활용해 모델과 프롬프트 최적화 실험을 계속할 예정
mitmproxy를 이용해서 같은 방식으로 분석 중임 관련 토론
이제 프롬프트 정보를 알게 되었으니 Cursor 서버를 재구현해서 완전 로컬(혹은 일종의 크랙된) 버전을 만드는 게 가능할지 궁금함
아니면 애초에 Cline, Roo Code 같은 오픈소스, 에이전트 코딩 특화 프로젝트가 있으니 그걸 쓰는 게 더 나음
프롬프트 나오기만을 기다려 이 시도를 했다는 건 좀 의외
Cursor의 apply 모델은 서버에서 돌아가는 구조로 보임
로컬 apply 모델을 직접 구현하는 게 얼마나 어려울지 궁금함
맥북에서 돌리면 훨씬 빠를 수도 있을 듯
확실히 가능함