한마디 털어놓을 게 있습니다. @cursor_ai 면접 보기 전까지, 저는 Cursor를 실제로 써본 적이 없었습니다.
Meta에서는 Claude Code가 폭발적으로 인기를 끌고 있었습니다. 저는 개인 사이드 프로젝트를 위해 월 200달러 플랜까지 결제했을 정도였죠. 단순하면서도 빠르게 생산성을 느낄 수 있다는 점이 정말 마음에 들었습니다. 하지만 제게 중요한 포인트는 cc를 거의 원하는 대로 바꿀 수 있는 나만의 기술 세트를 개발하는 것이었습니다. 심지어 그 위에 자체 에이전트 오케스트레이터 툴까지 만들기 시작했습니다.
오프사이트 면접 기간 동안 이틀에 걸쳐 Cursor를 사용하며 면접 프로젝트를 구축했습니다. Cursor 3 출시 전이라 Editor Window를 사용하고 있었죠. 저는 수년간 vscode를 사용해와서 대부분의 키보드 단축키가 여전히 제 컨텍스트 윈도우에 남아 있었기 때문에 IDE로 돌아가는 게 그리 어렵지 않았습니다. 하지만 솔직히 말하면, 처음 한두 시간 동안은 확실히 CLI가 그리웠어요. 무언가를 클릭하는 게 거의 야만적으로 느껴졌달까요. 하지만 몇 가지 정말 인상 깊었던 점들이 있었습니다.
첫째, 당시 제가 사용하던 모델인 Opus와 Codex가 왠지 더 똑똑하게 느껴졌습니다. 그리고 프로젝트의 다른 부분(프론트엔드는 Opus, 시스템은 Codex)에서 두 모델을 동시에 사용하며 자유롭게 전환할 수 있다는 점이 놀라웠습니다. 면접 전부터 저는 이미 다중 모델 적대적 리뷰에 대해 열광하고 있었기 때문에, UI에서 이 기능을 기본적으로 사용할 수 있다는 것은 매우 자연스럽게 느껴졌습니다. 더 좋았던 점은 서로 다른 모델의 하위 에이전트를 생성하여 하나의 대화에서 두 모델의 장점을 모두 활용할 수 있다는 것이었습니다.
둘째, 압축(compaction)이 엄청나게 빨랐습니다. cc 사용자로서 저는 압축에 몇 분이 걸리는 것에 익숙했고, 그래서 항상 컨텍스트와 계획 사용량을 예의주시해야 했습니다. 그래서 Cursor에서 압축이 얼마나 빠른지 보고 완전히 충격을 받았습니다. 거의 컨텍스트 사용량을 신경 쓸 필요가 없을 정도였죠. 그냥 잘 작동했고, 반면 cc에서는 압축 후 모델이 갑자기 엄청 멍청해지는 경우가 자주 느껴졌습니다.
그리고 세 번째로 눈에 띈 것은 GUI가 TUI보다 얼마나 많은 것을 제공할 수 있는지였습니다. Cursor 브라우저에서 앱을 직접 열고 Design Mode로 디자인을 변경하는 것이 직관적으로 느껴졌고, 목적에 맞게 설계된 UI가 에이전트 코딩을 얼마나 더 효과적으로 만들 수 있을지 고민하게 되었습니다.
Cursor로 Cursor 만들기
3월 말에 합류한 이후로 저는 주로 Cursor 3의 Agent Window를 개발하고 있으며, 이를 일상적으로 사용하고 있습니다. 저는 여전히 cc가 훌륭한 팀이 만든 멋진 제품이라고 생각하지만, 그 단순함 때문에 사람들이 이를 감싸는 자체 추상화를 만들고 싶어하는 경향이 있다는 것을 알게 되었습니다. 마지막 직장에서는 매주 cc 위에 구축된 새로운 내부 오케스트레이터 툴이 발표되는 것 같았습니다.
@bcherny는 이 "잠재 수요(latent demand)" 개념에 대해 자주 이야기합니다:
"제품에는 '잠재 수요'라는 아주 오래된 개념이 있습니다... 제품을 해킹 가능하고, 사람들이 다른 용도로 남용할 수 있을 만큼 개방적인 방식으로 만드는 것입니다. 그러면 사람들이 어떻게 남용하는지 보고 그에 맞춰 제품을 구축하는 거죠."
바로 이거였습니다! 사람들이 오케스트레이션 툴로 모여드는 것은 CLI를 사용하면 인간인 당신이 오케스트레이터가 된다는 잠재 수요를 드러내는 것이었습니다.
하지만 제가 사용해본 모든 에이전트 워크플로우는 잘못된 것에 집중하고 있었습니다. GUI에서 여러 CLI를 실행하는 것은 요점을 완전히 놓치고 있었습니다. 제가 관심을 가진 접근 방식은 에이전트에 대한 신뢰를 구축하는 것이었습니다.
이전 엔지니어링 매니저로서 저는 에이전트를 관리하는 것이 인간 엔지니어 팀을 구축하는 것과 비슷하다는 것을 금방 깨달았습니다. 신입 사원은 코드베이스를 이해하고 업무 방식을 파악하기 위해 온보딩이 필요합니다. 그들은 과거 경험에서 습득한 기술(디버깅, 고품질 코드 및 테스트 작성, 커뮤니케이션 등)을 이미 갖춘 상태로 합류합니다.
에이전트는 끊임없이 건망증과 어리석음에 빠진 신입 사원과 같습니다. 그들은 당신이 말한 것을 기억하지 못하고, 새로운 것을 제대로 배우지도 못합니다. 하지만 우리는 규칙, 기술, 도구, 장기 기억을 통해 이를 근사하게 만들 수 있습니다. 그들은 유능하지만 어리석고, 매우 가르치기 쉽습니다. 그리고 저는 그들의 실패 패턴을 깊고 엄격한 엔지니어링에 대해 제가 아는 모든 것을 가르칠 기회로 보았습니다.
왜냐하면 엄격함이 없으면 에이전트는 당신이 요청한 코드를 작성하기 위해 아첨하듯 무슨 짓이든 할 것이기 때문입니다. 그리고 그들은 정말 많은 코드를 작성할 수 있고 또 작성할 것입니다. 순진한 병렬화는 그들이 더 빨리 형편없는 코드를 쓰게 만들 뿐입니다.
빨리 가고 싶다면, 먼저 깊이 들어가라
저는 에이전트 오케스트레이션이 생산적으로 이루어질 수 있다고 생각합니다. 하지만 깊이 우선 접근이 필요합니다.
저는 @cursor_ai를 구축하는 데 매일 사용하는 개인 기술 및 엔지니어링 원칙 세트인 pstack을 오픈소스로 공개합니다. 저는 사이드 프로젝트에서 이 기술들의 초기 버전을 개발하기 시작했고, 그 이후로 계속 개선해 왔습니다.
여기서 받으세요: https://cursor.com/marketplace/cursor/pstack
이 기술들은 Cursor 팀에서 가장 많이 사용되는 기술 중 하나가 되었습니다. 여러분 모두와 공유하게 되어 정말 기쁩니다.
pstack은 여러 모델을 사용하여 에이전트가 더 엄격해지도록 가르칩니다. 제가 관찰한 모든 실패 패턴을 기술로 전환했습니다. 이 플러그인의 핵심은 /poteto-mode로, 주어진 작업에 대해 에이전트가 따라야 할 올바른 플레이북을 제공하는 고차 기술입니다. 목표는 최대 LOC가 아니라 그 반대입니다: 최소한의 코드로 최대의 영향을 내는 것입니다.
엄격함은 숙련된 엔지니어와 동일한 방식으로 문제에 접근함으로써 적용됩니다. 예를 들어, 디버깅에 접근하는 좋은 방법은 문제 공간을 이진 탐색하는 것입니다. 무슨 일이 일어나고 있는지에 대한 몇 가지 가설을 세우고, 실제 근본 원인에 가까워질 때까지 체계적으로 가설을 배제해 나가는 것입니다. 재현이 어렵다면 버그를 인위적으로 강제로 발생시키려고 시도할 수도 있습니다. 또는 프로그램이 실행될 때 프로그램 상태를 확인하기 위해 계측(instrumentation)이나 콘솔 로깅을 추가할 수도 있습니다.
이러한 단계들은 에이전트가 추측 대신 철저하게 문제를 디버깅하는 데 사용할 수 있는 플레이북을 형성합니다. 에이전트는 당신이 허락한다면 기꺼이 추측하려 들 것입니다. pstack은 동일한 수준의 엄격함으로 소프트웨어 엔지니어링에 접근할 수 있게 해주는 많은 기술과 플레이북을 제공합니다. 현재 저는 다음과 같은 플레이북을 가지고 있습니다:
- 기술 작성 및 평가
- 자율적으로 작업하기
- 버그 수정 및 런타임 포렌식
- 기능 개발
- 시각적 일치 및 프로토타이핑
- 그 외 다수
엄격함이 필요할 때마다 프롬프트 앞에 /poteto-mode를 붙이세요. 예를 들어:
다른 기술을 필요에 따라 호출할 수도 있습니다:
- /how: 하위 시스템이 실제로 어떻게 작동하는지에 대한 설명을 원할 때.
- /why: 무언가가 왜 이런 방식으로 구축되었는지 알고 싶을 때. 사용 가능한 MCP를 사용하여 각 증거 카테고리(소스 제어, 이슈 트래커, 장문 문서, 실시간 채팅, 인프라 관찰 가능성, 오류 추적, 분석 웨어하우스)를 병렬로 쿼리합니다.
- /architect: 함수 경계를 넘는 코드를 작성하려고 할 때, 먼저 타입과 데이터 구조를 확정하고 싶을 때.
- /arena: 동일한 작업에 대해 N개의 병렬 시도를 한 다음 각각의 최고 부분을 가져오고 싶을 때.
- /interrogate: 다른 모델이 어떤 것을 적대적으로 리뷰하게 하고 싶을 때.
- /tdd: 버그를 수정 중입니다. 먼저 실패하는 테스트를 작성하고, 그 다음 수정하세요.
- /unslop: 모든 종류의 AI 작성을 정리할 때. 평이하게 말하도록 만듭니다.
- /reflect: 긴 대화 후에 지속적으로 기술을 개선하고 싶을 때.
- /figure-it-out: 특이한 작업을 하고 있나요? 작업을 위한 엄격하고 감사 가능한 플레이북을 설계합니다.
- /show-me-your-work: 검토 가능한 결정 과정을 원할 때. 결정 사항을 tsv 파일에 기록합니다.
마지막으로, /automate-me로 나만의 모드 기술을 만들 수 있습니다. 최근 대화 기록을 분석하고, 당신이 작업한 방식을 바탕으로 your-mode 기술 초안을 작성한 후, 내부적으로 pstack을 통해 라우팅합니다.
pstack은 모든 에이전트 코딩 툴과 함께 작동하지만, Cursor와 같은 다중 모델 툴에서 특히 잘 작동합니다. 많은 기술이 각 모델의 고유한 강점과 약점을 활용하기 위해 다중 모델 워크플로우를 사용합니다. 에이전트 오케스트레이션이지만, 폭 우선이 아닌 깊이 우선으로 적용됩니다.
에이전트의 병목 현상은 검증입니다. 에이전트는 많은 양의 코드를 빠르게 작성할 수 있습니다. 모든 코드가 올바른지 확인하는 것은 매우 어렵습니다. 거기에 도달할 수 있다면, 소프트웨어를 위한 다크 팩토리와 같은 진정한 에이전트 병렬 처리가 가능할지도 모릅니다.
하지만 먼저, 우리는 깊이 들어가고 엄격해져야 합니다. 저는 신뢰를 높임으로써 거기에 도달할 수 있다고 생각합니다.
pstack을 사용해보시고 의견을 알려주세요.
소프트웨어 유지보수의 선(禪)과 기술
이러한 기술들은 코드를 작성할 때 더 자신감 있게 움직일 수 있게 도와줍니다. 하지만 이제 에이전트가 모든 코드를 작성하면서 유지보수는 악몽이 되었습니다. 버그, 성능 문제, 기능 요청은 여전히 해결하는 데 시간이 걸립니다. 그리고 이제 코드가 훨씬 더 많아졌습니다!
저는 Cursor에서 Cursor 자동화를 광범위하게 사용합니다. 이는 예약하거나 Slack 채널의 새 메시지와 같은 이벤트에 응답하여 실행할 수 있는 클라우드 에이전트입니다. 한 가지 예로 제 봇 Benny가 있습니다. 저는 그에게 pstack과 동일한 기술을 부여했습니다.
Benny는 아직 진행 중인 작업이지만, 제 비전은 소프트웨어 유지보수 프로세스를 가능한 한 많이 자동화하는 것입니다. 아이디어는 이렇습니다: 이제 pstack을 사용하여 PR 품질이 높을 것이라는 상당한 확신을 가지고 문제를 대부분 "원샷"할 수 있다면, 피드백도 확실히 자동화할 수 있을 것입니다.
이 팩토리는 트라이지(triage)로 시작합니다: 직원들로부터 버그 리포트에 대한 정보를 수집합니다. 우리는 Cursor를 많이 사용(dogfood)하기 때문에 릴리스 후보에 대한 직원들의 피드백을 많이 받습니다. Benny는 이미지와 비디오 첨부 파일을 이해하고, pstack 기술을 사용하여 코드베이스를 탐색하며, 재현 단계가 명확하지 않은 경우 리포터와 채팅하여 정보를 얻습니다.
이것은 버그 리포팅 프로세스의 중요한 부분입니다. 명확한 재현 단계와 무엇이 고장 났는지에 대한 이해 없이는 에이전트는 해결책을 추측할 수밖에 없습니다. 우리는 에이전트에게 정확히 어디서, 어떻게 고장이 나는지에 대한 명확한 이해를 제공해야 합니다.
트라이지가 완료되면 Benny는 코드 검토, 최근 버그 회귀에 대한 git 히스토리, 동일한 버그에 대한 다른 메시지가 있는 Slack, 그리고 기능이 어떻게 작동해야 하는지에 대한 디자인 및 제품 결정이 있는 Notion까지 조사한 결과를 바탕으로 티켓을 생성합니다: 버그인지, 아니면 의도적으로 이렇게 설계된 것인지.
티켓이 접수된 후, 다른 Benny 봇이 제가 만든 /orchestrate라는 또 다른 기술을 사용하여 이를 처리합니다.
먼저, 컴퓨터 사용을 통해 문제를 재현하려고 시도합니다. Cursor Cloud Agents는 클라우드에서 Cursor 자체를 실행할 수 있으며, 데스크톱과 상호 작용하고, 항목을 클릭하고, 키보드 입력을 보냅니다. 내부적으로는 CDP 또는 이와 동등한 프로토콜을 사용하여 제품을 프로그래밍 방식으로 제어하기 위해 제가 만든 더 많은 기술을 사용합니다.
이를 통해 버그 리포트를 재현할 수 있는지 여부를 입증할 수 있습니다. 버그를 일관되게 재현한다면, 수정을 시도합니다. 성능 문제라면, Benny는 수정 전후의 CPU 트레이스와 힙 스냅샷을 가져올 수 있습니다. 하위 플래너는 더 많은 워커를 생성하여 pstack 기술을 사용해 수정 사항을 검증하고, 수정되었다면 티켓과 대조하여 확인합니다.
이 실행에서는 수정 전후의 비디오를 촬영하기 위해 추가 워커가 생성되고, 마지막으로 워커가 설명에 비디오와 함께 PR을 검토용으로 엽니다.
이 모든 것은 아직 진행 중이며 해야 할 일이 훨씬 더 많지만, 제가 자거나 다른 일을 하는 동안 자신 있게 버그를 수정해 줄 에이전트 팀을 갖게 되어 기쁩니다. 코드 리뷰를 확장 가능하게 만드는 것도 또 다른 큰 영역이며, Cursor가 이를 돕기 위한 멋진 새로운 기능을 곧 선보일 것이라고 생각합니다.
하지만 자신만의 소프트웨어 팩토리를 구축하는 핵심은 신뢰입니다. 검증을 포함하여 에이전트가 문제를 처음부터 끝까지 책임질 수 있다고 신뢰하지 않으면, 프로세스를 자동화할 수 없습니다. pstack과 같은 플러그인을 사용하여 에이전트에 더 많은 엔지니어링 깊이를 부여함으로써 신뢰를 높이면, 더 야심 찬 문제에 도전할 수 있습니다. 아직 신뢰하지 않는 에이전트를 병렬화하려는 것은 엄청난 토큰 낭비이며 코드베이스에 더 많은 형편없는 코드를 도입할 뿐입니다.
읽어주셔서 감사합니다!
