내가 프로덕션 코드 작업에 Cursor 사용을 중단한 이유 (그리고 현재 사용 중인 도구)

• Cursor는 프로토타입 제작에는 빨랐지만, 실제 프로덕션 작업에서는 정체되었습니다.

• Claude Code 훅(hooks)을 통해 모든 커밋(commit) 전에 체크 과정을 자동화할 수 있었습니다.

• 기술(Skills)과 플러그인(plugins)을 통해 채팅 도구를 실제 파이프라인(pipeline)으로 변모시켰습니다.

• 새로운 설정으로 한 분기 동안 14개의 제품 출시를 완료했습니다.

저는 약 8개월 동안 스튜디오 전체를 Cursor로 운영했습니다. 그러다 Claude Code로 전환했고, 단 한 분기 만에 14개의 제품 출시를 완료했는데, 이는 이전 세 분기 동안 해낸 것보다 더 많은 양입니다. 이것은 제가 왜 떠났는지, 그리고 실제로 무엇이 변했는지에 대한 솔직한 버전의 이야기입니다.

Cursor가 잘했던 점과 한계가 드러난 지점

Cursor는 진정으로 좋은 에디터(editor)입니다. 이 점을 먼저 분명히 하고 싶습니다. 인터넷은 명확한 악당을 좋아하지만, Cursor는 그런 존재가 아닙니다. 프로토타이핑(prototyping) 용도로는 탁월합니다. 새 파일을 열고 작은 기능을 설명하면, 1분도 채 되지 않아 사용 가능한 구조를 만들어내는 것을 지켜볼 수 있었습니다. 탭 완성(tab completion) 기능은 매우 날카롭습니다. 블록을 하이라이트하고 변경을 요청하는 인라인 편집(inline edit) 기능은 작은 리팩터링(refactor) 작업에서 시간을 크게 절약해 주었습니다.

문제는 제 프로젝트가 연습용 단계를 넘어 성장하면서 시작되었습니다. 저의 주요 Shopify 백엔드(backend)는 서로 연결된 약 40개의 파일을 가지고 있습니다. 제품 동기화, 이미지 파이프라인(pipelines), 스케줄링 로직(scheduling logic), 블로그 게시자 등이 포함됩니다. 코드베이스(codebase)가 그 정도 규모에 도달하면, 에디터는 단순히 눈앞의 파일뿐만 아니라 관계를 이해해야 합니다. Cursor는 한 파일을 자신 있게 수정하면서도, 조용히 다른 두 개의 파일을 망가뜨리곤 했습니다. Cursor는 저의 컨벤션(conventions)을 알지 못했습니다. 저의 테스트(tests)를 실행하지도 않았습니다. Cursor는 모든 요청을 전날 설정해 둔 규칙에 대한 기억이 없는, 완전히 새로운 대화로 취급했습니다.

저는 저만의 규칙을 담은 텍스트 파일을 열어두고, 매 세션마다 채팅창에 붙여넣기 시작했습니다. 명명 규칙 (Naming conventions), 출력물에 em dash(—)를 절대 사용하지 않는다는 사실, 제가 요구하는 통화 형식 (Currency formatting), 그리고 제 발행 스크립트가 차단하는 단어 목록까지 말이죠. 매 세션마다 이 내용을 붙여넣었습니다. 같은 600단어를 두 달 동안 계속 붙여넣으면서, 저는 수동 작업을 없애주기로 되어 있는 도구를 중심으로 오히려 수동 워크플로우 (Manual workflow)를 구축했다는 사실을 깨달았습니다.

임계점은 3월의 어느 금요일이었습니다. 저는 Cursor에게 제품 스키마 (Product schema)에 필드를 추가해 달라고 요청했습니다. Cursor는 스키마를 업데이트했지만, 세 곳의 호출 지점 (Call sites)을 놓쳤고, 저는 결국 깨진 코드를 푸시하여 라이브 페이지를 20분 동안 다운시켰습니다. 재앙적인 수준은 아니었습니다. 하지만 그달에만 벌써 세 번째였습니다. 이 도구는 쓰는 속도는 빨랐지만 정확함에 있어서는 느렸고, 프로덕션 작업 (Production work)에서는 정확함만이 유일하게 의미 있는 속도입니다. 저는 배포할 계획이 있는 그 어떤 작업에 대해서도 이 도구를 신뢰하는 것을 멈췄습니다.

Claude Code의 훅 (Hooks)이 나의 일상 업무를 어떻게 바꾸었나

저의 마음을 돌린 단 하나의 기능은 바로 훅 (Hooks)이었습니다. Claude Code를 사용하면 특정 시점에 자동으로 실행되는 명령어를 정의할 수 있습니다. 도구가 실행되기 전, 파일을 편집한 후, 혹은 커밋 (Commit) 하기 전과 같은 시점 말이죠. 사소하게 들릴지 모르지만, 이것이 게임의 판도를 바꿉니다.

저는 파일이 작성될 때마다 린터 (Linter)와 단어 검사를 실행하는 훅을 설정했습니다. 이제 모델이 제 블로그 발행기를 편집하면, 훅이 즉시 금지 단어 스캔을 실행하여 제가 결과물을 확인하기도 전에 em dash나 차단된 용어를 찾아냅니다. 오류는 다시 대화창으로 전달되고, Claude는 그 자리에서 즉시 이를 수정합니다. 수동으로 붙여넣을 필요도 없고, 금요일 오후의 서비스 중단도 없습니다. 규칙은 제 기억이 아니라 프로젝트 안에 살아 있습니다.

저는 스키마 파일에 변경이 생길 때마다 테스트 스위트 (Test suite)를 실행하는 두 번째 훅도 설정했습니다. 만약 필드가 추가되어 세 곳의 호출 지점이 깨지면, 테스트가 실패하고, 그 실패 결과가 다시 세션으로 전달되며, 동일한 루프 안에서 수정이 이루어집니다. 지난 3월에 제 사이트를 다운시켰던 문제는 이제 매번 약 4초 만에 자동으로 포착됩니다.

이것이 바로 에디터(editor)와 시스템(system)의 차이입니다. Cursor는 제 파일에 코드를 작성했습니다. 반면 Claude Code는 저의 실제 프로세스에 참여합니다: 작성, 확인, 수정, 검증, 그리고 다음 단계로 이동하는 과정 말입니다. 저는 세션마다 600단어에 달하는 규칙을 붙여넣던 방식에서, 설정(config) 파일에 한 번 정의해두고 잊어버리는 방식으로 전환했습니다.

전체 설정에 대한 더 깊은 맥락을 알고 싶다면, Claude Code Desktop Full IDE Rebuild에서 제가 이 모든 것을 어떻게 하나로 연결했는지 자세히 다루고 있습니다. 요약하자면, 저의 규칙들은 인프라(infrastructure)가 되었습니다. 새로운 프로젝트를 시작할 때 제 템플릿을 클론(clone)하는 순간, 동일한 훅(hooks)을 상속받습니다. 금지어, 통화 형식, 테스트 게이트(test gates) 등 모든 것이 자동으로 로드됩니다.

솔직한 트레이드오프(tradeoff)는 설정 비용입니다. 훅을 처음부터 제대로 구성하려면 오후 시간 하나를 통째로 써야 합니다. Cursor는 설정이 전혀 필요 없습니다. 하지만 저는 제 스튜디오를 단 하루가 아니라 수년간 운영할 것이며, 계산기를 두드려보면 첫 오후의 시간을 투자한 후 매일매일 보상을 돌려주는 도구가 훨씬 유리합니다.

스킬(Skills)과 플러그인(Plugins)이 이를 파이프라인(Pipeline)으로 만들었습니다

훅(Hooks)이 정확성을 해결했다면, 스킬(Skills)과 플러그인(Plugins)은 범위를 해결했습니다. Claude Code에서의 스킬이란 한 번 가르치면 영원히 재사용할 수 있는 패키지화된 능력입니다. 저는 지금 여러분이 읽고 있는 바로 이 구조, 즉 제 블로그 형식을 위한 스킬을 구축했습니다. 첫 줄의 TLDR div, 4개의 H2 섹션, 하단 라인, 내부 링크, 제휴 링크 배치 등 말이죠. 저는 더 이상 형식을 설명하지 않습니다. 그저 "X에 대한 lab 아티클을 작성해줘"라고 말하면, 스킬이 모든 규칙을 수행합니다.

저는 제품 출시 체크리스트를 위한 또 다른 스킬도 만들었습니다. 새로운 디자인을 시스템에 넣으면, 스킬은 다음 순서를 알고 있습니다: 목업(mockups) 생성, 히어로 이미지 업스케일링(upscale), 리스팅 작성, 소셜 포스트 예약, 인덱스 업데이트. 예전에는 각각 별도의 도구로 처리해야 했던 단계들이 이제는 하나의 재사용 가능한 능력 안에 담겨 있습니다.

이미지 단계는 Magnific을 통해 업스케일링 (upscaling)을 수행합니다. 제 원본 아트워크는 저해상도로 생성되어 인쇄 가능한 수준이 되어야 하기 때문입니다. 소셜 예약 단계는 Buffer로 전달되어, 제가 다섯 개의 탭을 열지 않고도 출시가 여러 플랫폼에 동시에 퍼져나갈 수 있게 합니다. Claude Code가 이 전체 체인을 오케스트레이션 (orchestration)합니다. Cursor는 결코 이런 것을 시도하지 않았습니다. Cursor는 에디터 (editor)이며 자신의 영역을 지키는데, 그것 자체로 문제는 없지만 제 업무는 편집이 아닙니다. 제 업무는 완성된 제품을 엔드 투 엔드 (end-to-end)로 출시하는 것입니다.

플러그인 (Plugins)은 이를 더욱 확장합니다. 저는 모델이 제품 데이터를 직접 읽고 쓸 수 있게 해주는 플러그인을 통해 Shopify 스토어 운영을 수행합니다. 이는 테스트 게이트 (test gates)와 단어 검사가 전 과정에서 작동하며, 아이디어에서 실제 리스팅 (listing)까지 단 하나의 세션 안에서 출시가 이루어짐을 의미합니다. 제가 언급했던 14번의 출시는 바로 이 파이프라인 (pipeline)에서 나왔습니다. 예전 설정이었다면 각각 반나절 동안 수동으로 조립해야 했을 작업들이었습니다. 이제는 대부분 제 실제 집중 시간이 한 시간도 채 걸리지 않습니다.

제가 계속해서 다시 배우고 있는 교훈은 이것입니다: 승리하는 도구는 가장 매끄러운 자동 완성 (autocomplete)을 가진 도구가 아닙니다. 제가 반복적인 작업을 멈출 수 있도록 제 프로세스 (process)를 인코딩 (encode)할 수 있게 해주는 도구입니다. Cursor는 키스트로크 (keystroke)에 최적화되었습니다. Claude Code는 워크플로 (workflow)에 최적화되었으며, 워크플로는 1인 스튜디오가 생존하느냐 사느냐가 결정되는 지점입니다.

여전히 Cursor를 찾는 경우

Claude Code가 모든 면에서 승리한다고 거짓말하지는 않겠습니다. 그런 종류의 글은 시간이 지나면 가치가 떨어지고 누구에게도 도움이 되지 않기 때문입니다. 오늘날에도 제가 여전히 Cursor를 열 상황이 있습니다.

새로운 프레임워크 (framework)를 배우고 있고 이를 대화형으로 탐색하고 싶을 때, Cursor의 인라인 편집 (inline editing)과 즉각적인 완성 기능은 매우 훌륭합니다. 피드백 루프 (feedback loop)가 매우 타이트합니다. 생각의 절반만 입력해도 완성되는 것을 볼 수 있습니다. 정확성이 아직 중요하지 않은 순수한 탐색 단계에서는, 구조화된 루프보다 빠른 루프가 더 유리합니다. 저는 정확히 이 용도로 Cursor를 계속 설치해 두고 있습니다.

만약 여러분이 이미 확립된 에디터 문화(editor culture)를 가진 대규모 팀에서 일한다면, 계산 방식은 달라집니다. 제 논거 전체는 혼자 작업한다는 전제하에 성립합니다. 제가 규칙을 정의하고, 제가 훅(hooks)을 소유하며, 다른 다섯 명의 개발자와 컨벤션(conventions)을 협상할 필요가 없습니다. 팀은 다른 종류의 마찰(friction)이 존재하며, 모두가 이미 익숙한 에디터는 단일 작업자 워크플로우(single-operator workflow)가 포착할 수 없는 실질적인 가치를 지닙니다. 저는 제가 내리는 결론이 보편적인 판결이 아니라, 스튜디오 전체를 운영하는 한 개인에게 효과적인 방식을 설명하고 있는 것입니다.

그리고 만약 여러분의 프로젝트가 진정으로 작은 규모를 유지한다면, Cursor의 설정이 필요 없는(zero setup) 점은 결함이 아니라 기능입니다. 제가 사랑하는 훅(hook) 시스템은 코드베이스가 서로를 깨뜨릴 일이 없는 세 개의 파일 정도라면 필요 없는 오버헤드(overhead)일 뿐입니다. 솔직히 말하면, 8개월 전의 저에게는 Cursor를 조금 더 계속 사용하라고 말했을 것입니다. 전환의 이점은 여러분의 작업이 단일 파일 사고방식(single-file mindset)을 넘어설 때 비로소 나타납니다.

저를 움직이게 만든 것은 조합이었습니다: 프로덕션의 중요성(production stakes), 단독 소유권(solo ownership), 그리고 인코딩할 가치가 있을 만큼 충분히 복잡한 프로세스입니다. 이 세 가지가 모두 충족될 때, 훅(hooks)과 기술(skills)은 더 이상 있으면 좋은 부가 기능이 아니라 스튜디오가 돌아가게 만드는 이유가 됩니다. 배경 설명: Claude Code Desktop Full IDE Rebuild에서는 이 세 가지가 저에게 일치했던 순간과 제가 내린 설정 결정들에 대해 다룹니다.

그래서 저는 두 도구를 모두 유지합니다. 단지 각 도구가 실제로 잘하는 일에 맞춰 사용할 뿐이며, 이제 모든 무거운 프로덕션 작업은 구조화된 도구를 통해 흐릅니다.

핵심 요약 (Bottom Line)

제가 Cursor를 떠난 이유는 도구가 나빠졌기 때문이 아니라, 제 작업 방식이 변했기 때문입니다. 프로토타이핑(Prototyping)은 속도와 긴밀한 피드백 루프(feedback loop)를 보상하며, Cursor는 그 점에서 탁월합니다. 프로덕션(Production)은 정확성, 반복 가능한 프로세스, 그리고 제가 직접 신경 쓰지 않아도 제 규칙을 기억해 주는 시스템을 보상합니다. 훅(Hooks)은 제 사이트를 다운시켰던 버그들을 잡아냈습니다. 기술(Skills)은 제 포맷을 패키징하여 제가 더 이상 이를 설명할 필요가 없게 만들었습니다. 플러그인(Plugins)은 모델을 실제 스토어에 연결했고, 그 결과 한 분기 동안 14번의 런칭을 성공적으로 마칠 수 있었습니다.

만약 당신이 1인 운영(solo operation)을 하고 있고, 매일 아침 채팅창에 똑같은 규칙들을 계속해서 붙여넣고 있다면, 그것이 바로 신호입니다. 그것을 한 번만 인코딩(Encode)하세요. 도구가 스스로를 점검하게 만드세요. 설정을 위해 보내는 오후 시간은 그 이후의 매일매일로 보상받게 될 것입니다.

제가 이 방식을 중심으로 스튜디오를 어떻게 구성했는지 전체적인 그림을 보고 싶다면, Claude Blueprint에서 제가 엔드 투 엔드(end to end)로 사용하는 훅(hooks), 기술(skills), 그리고 프로젝트 구조를 설명하고 있습니다. 작게 시작하세요. 당신을 계속 괴롭히는 점검 과정을 자동화하고, 거기서부터 구축해 나가세요.

이 기사에는 제휴 링크가 포함되어 있습니다. 이 링크를 통해 가입하시면, 귀하에게 추가 비용 부담 없이 저에게 소정의 수수료가 지급될 수 있습니다. (광고)