AI Operators / Product Systems

코드가 아니라 마크다운이 기능이 되는 순간

Cursor가 WorkTrees 기능을 수천 줄의 코드에서 Skill과 서브에이전트 프롬프트로 옮긴 사례는, 제품 기능의 일부가 “소프트웨어”에서 “운영 가능한 지시문”으로 이동하고 있음을 보여준다.

이 발표의 표면적인 이야기는 자극적입니다. Cursor가 WorkTrees 기능을 1만 줄이 넘는 코드에서 약 200줄짜리 Skill과 명령 프롬프트로 옮겼다는 이야기입니다. 하지만 더 중요한 지점은 “코드를 줄였다”가 아닙니다. 제품 기능의 일부가 컴파일된 코드에서, 읽고 고치고 평가할 수 있는 마크다운 운영 규칙으로 이동했다는 점입니다.

이 변화는 단순한 리팩터링이 아니라 제품을 만드는 방식의 이동입니다. 예전에는 기능이 UI, 상태관리, IPC, 테스트, cleanup 로직으로 구현됐습니다. 이제 일부 기능은 “에이전트에게 어떤 절차를 맡길 것인가”라는 Skill 문서와 서브에이전트 조합으로 구현됩니다.

WorkTrees는 원래 ‘격리된 병렬 작업 환경’이었다

발표자는 먼저 Git worktree를 설명합니다. 하나의 저장소를 여러 checkout으로 나눠, 여러 에이전트가 같은 프로젝트에서 동시에 작업해도 서로의 변경을 침범하지 않게 만드는 방식입니다. Cursor에서는 여기에 에이전트를 붙여 “같은 작업을 여러 모델에게 동시에 시켜보고 결과를 비교하는” Best-of-N 같은 워크플로우까지 만들었습니다.

이 기능은 파워유저에게 강력합니다. 같은 프롬프트를 Kimi, Grok, GPT, Opus 같은 모델에 동시에 던지고, 각 구현을 프리뷰한 뒤 좋은 조각을 골라 합칠 수 있기 때문입니다. 문제는 구현 비용이었습니다.

삭제된 것은 코드가 아니라 ‘고정된 제품 표면’이었다

기존 구현은 worktree 생성과 관리, 에이전트가 해당 디렉터리 안에 머물도록 강제하는 로직, 수많은 cleanup과 테스트를 포함했습니다. 발표자는 새 구현에서 이 대부분을 제거했고, WorkTrees 기능을 Cursor의 기존 primitive인 Skills, commands, subagents 위에 다시 얹었다고 말합니다.

여기서 핵심은 Skill이 “문서”처럼 보이지만 사실상 제품 동작을 정의하는 실행 가능한 운영 규칙이 된다는 점입니다. 예를 들어 worktree Skill은 에이전트에게 checkout을 만들고, setup script를 실행하고, 이후 작업을 그 경로 안에서 유지하라고 지시합니다. Best-of-N Skill은 부모 에이전트에게 여러 모델별 서브에이전트를 만들고, 각자 worktree에서 작업하게 한 뒤, 결과를 표로 비교해 사용자에게 설명하라고 지시합니다.

마크다운이 코드가 되는 조건

“Markdown is the new code”라는 말은 마크다운이 Python이나 TypeScript를 대체한다는 뜻이 아닙니다. 더 정확히는 반복적인 에이전트 작업 흐름을 제품 코드 바깥으로 빼낼 수 있다는 뜻입니다.

전통적인 소프트웨어에서 기능은 결정론적이어야 했습니다. 버튼을 누르면 항상 같은 경로로 실행되고, 가능한 예외를 코드가 처리해야 했습니다. 하지만 에이전트 제품에서는 일부 기능이 확률적이고 해석적인 작업입니다. 여러 모델을 비교하고, 결과를 요약하고, 장단점을 평가하는 일은 애초에 코드보다 에이전트가 잘하는 영역입니다.

그래서 Cursor의 선택은 “모든 것을 마크다운으로 만들자”가 아닙니다. 코드가 잘하는 부분과 에이전트가 잘하는 부분의 경계를 다시 그은 것입니다.

좋아진 점: 기능이 가벼워지고 조합 가능해진다

발표에서 나온 장점은 명확합니다. 유지해야 할 코드가 크게 줄어듭니다. 특히 WorkTrees처럼 전체 사용자보다 파워유저가 많이 쓰는 고급 기능은, 애플리케이션 코어에 무거운 유지보수 부담으로 남아 있기보다 Skill로 얇게 유지하는 편이 합리적일 수 있습니다.

또 하나의 장점은 사용자가 대화 중간에 worktree로 전환할 수 있다는 점입니다. 예전에는 기능이 UI에 고정돼 있었기 때문에 시작 시점의 선택이 중요했습니다. 이제는 slash command처럼 필요할 때 불러올 수 있습니다. 기능이 버튼에서 대화 중 호출 가능한 운영 루틴으로 바뀐 겁니다.

Best-of-N도 더 유연해집니다. 예전에는 하나의 결과를 선택해야 했다면, 새 방식에서는 여러 서브에이전트 결과를 parent agent가 비교하고, 일부 구현을 조합하거나 비판적으로 정리할 수 있습니다. 이건 단순히 “멀티 에이전트”라는 말보다 더 중요합니다. 작업 결과를 고르는 사람이 아니라, 결과를 종합하는 에이전트 계층이 생기는 구조입니다.

나빠진 점: 하드 가드레일이 프롬프트 신뢰로 바뀐다

하지만 이 전환에는 비용이 있습니다. 기존 구현에서는 에이전트가 primary checkout을 건드리지 못하게 물리적으로 막을 수 있었습니다. 새 구현에서는 “이 디렉터리 안에서 작업하라”는 지시를 모델이 계속 기억해야 합니다. 발표자는 이 부분을 거의 가장 큰 문제로 봅니다.

이 차이는 작지 않습니다. 소프트웨어 가드레일은 실패를 원천 차단합니다. 프롬프트 가드레일은 실패를 줄이지만 완전히 막지는 못합니다. 특히 긴 세션에서는 모델이 작업 위치를 잊거나, primary checkout에서 작업을 시작할 수 있습니다.

그래서 다음 병목은 eval과 RL이다

발표 후반부가 흥미로운 이유는 여기 있습니다. Cursor는 이 문제를 단순히 “프롬프트를 더 잘 쓰자”로 끝내지 않습니다. worktree 안에서만 작업했는지, primary checkout을 오염시키지 않았는지 평가하는 eval을 만들고, Composer 같은 자체 모델의 RL 학습 과제에도 이런 환경을 넣으려 한다고 설명합니다.

이 말은 Skill 기반 제품의 다음 단계가 보입니다. 앞으로 기능은 코드, 프롬프트, eval, 모델 학습 데이터가 함께 움직이는 묶음이 됩니다. Skill이 제품 동작을 정의하고, eval이 실패를 측정하고, RL이 그 실패 패턴을 줄입니다. 즉 마크다운은 혼자 코드가 되는 것이 아니라 평가 가능한 운영 단위가 될 때 제품 기능이 됩니다.

NerdMakr 관점의 정리

이 영상은 Cursor의 특정 기능 리팩터링 사례지만, 더 크게 보면 에이전트 제품의 방향을 보여줍니다. 앞으로 좋은 제품 팀은 모든 기능을 무겁게 코드로 박아 넣지 않을 겁니다. 대신 아래 질문을 계속 던질 가능성이 큽니다.

• 이 기능은 결정론적 코드로 강제해야 하는가?
• 아니면 에이전트가 절차를 읽고 수행하는 Skill로 충분한가?
• 실패했을 때 위험한 부분은 무엇이며, 어디까지는 하드 가드레일이 필요한가?
• 프롬프트로 옮긴 부분은 어떤 eval로 측정할 것인가?
• 반복 실패 패턴은 모델 학습이나 시스템 reminder로 어떻게 줄일 것인가?

결론은 단순합니다. 마크다운은 코드보다 약합니다. 하지만 어떤 기능에서는 그 약함이 오히려 장점입니다. 더 빨리 바꾸고, 더 쉽게 읽고, 더 유연하게 조합할 수 있기 때문입니다. 단, 그 대가로 평가와 가드레일이 필요합니다.

Sources: YouTube video “Replacing 12K LoC with a 200 LoC Skill — David Gomes, Cursor” by AI Engineer, transcript extracted on 2026.05.07. Thumbnail from YouTube public thumbnail. This article is a Korean learning-purpose editorial reconstruction, not an official transcript.