cursor와 일하기...
on
최근 두 달간 유료 구독을 통해 노후화된 대규모 프로젝트에 Cursor를 도입하여 다양한 작업을 시도해 보았다. 대상은 파일 약 600개 규모의 프로젝트로, 여러 작업자의 중구난방식 기여로 인해 불필요한 중복과 비효율이 만연한 상태다. 특히 과거의 잘못된 관행(불필요한 다형성, 상속 구조, 남용된 Stream 등)으로 인해 가독성과 성능이 모두 저하된 코드들이 산재해 있다.
실제 적용 과정에서 느낀 핵심적인 판단은 다음과 같다.
- LLM 활용이 효과적인 경우 사용자의 숙련도가 낮을 때: 프로젝트 전체를 리드할 역량이 부족한 사용자에게 Cursor는 강력한 보조 도구가 된다.
표준적인 패턴의 작업: 전형적이고 보편적인 로직은 LLM의 학습량이 많아 매우 우수한 결과물을 도출한다.
소규모 프로젝트: 규모가 작을수록 결과 확인이 빠르고, 오류 발생 시 사용자가 즉각 개입하여 수습하기 용이하다.
- 한계점 및 주의사항 복잡도 증가와 수습 비용: 단순 작업은 능숙하나, 구조적인 개선을 시도할 때 검증 과정에서 문제가 생기면 이를 해결하려다 오히려 일을 더 키우는 경향이 있다. 결국 사람이 개입해 마무리해야 하며, 이 과정에서 투입되는 공수가 산출물보다 커지는 ‘배보다 배꼽이 큰’ 상황이 발생한다.
잘못된 최적화: 성능 최적화를 시도하다가 코드를 더 복잡하게 꼬아버려 안 하느니만 못한 결과를 내놓기도 한다.
- 종합 평 및 향후 전망 모델 성능의 한계: LLM은 학습 데이터의 패턴에 의존한다. 최신 모델조차 투입되는 토큰과 시간 대비 만족스러운 결과(특히 레거시 코드 대응)를 보여주지 못했다.
개인화된 학습의 필요성: 현재로서는 특히 ‘옛날 스타일’의 코드를 다룰 때 인간의 개입이 필수적이다. 향후 개인이 자신의 프로젝트 환경에 맞게 LLM을 미세 조정(Fine-tuning)할 수 있는 인프라가 갖춰진다면 비로소 실질적인 도약이 가능할 것으로 보인다.
내가 프롬프팅을 잘 했다라거나 인내심이 남들보다 더 있었다면 다른 결과가 나왔지 싶지만 어쩄든 내가 보는 관점에선 그러하다. 내가 봤을 때 엄청난 장점은 내용을 이해하기 쉬운 표현으로 요약하거나 작업 내용을 정리하는 기능에 있다고 본다. 성능 최적화는 생각보다 기대 이하였던 경우가 많고 맘에 안드는 type handling을 개선하라고 했을 때 연관 함수가 많거나 하면 굉장히 많은 토큰과 시간을 소모해도 일을 제때에 끝내지 못해서 결국 작업자가 어쩔 수 없이 중단해야 하는 경우가 허다 했다.
결론: 나중엔 좋아지겠지만 한동안 별로 안쓰게 될 것 같다. 나는. 단순한 잔심부름을 시켜냐 할 때나 부르면 좀 도움이 되려나. 그것도 이렇게나 큰 프로젝트, 특히나 코딩 습관이 안좋은 인간들이 많은 부분 기여(?)를 한 경우에나 이득을 볼 것 같다고 해야할 것 같다.