프롬프트를 코드처럼 다루기: Cursor 슬래시 명령어를 위한 기술, 평가(Evals), 그리고 배포 게이트 CI
요약
Cursor의 슬래시 명령어를 단순한 마크다운 스니펫이 아닌, 엄격한 평가(Evals)와 CI 배포 게이트를 갖춘 제품 수준의 워크플로우로 관리하는 방법론을 소개합니다.
핵심 포인트
- 프롬프트를 단순 텍스트가 아닌 구조화된 기술(Skill) 계약으로 관리
- 행동 평가(Behavioral evals)를 통한 PASS/FAIL 점수 체계 도입
- CI 단계에서 안전 가드 유무를 검증하는 배포 게이트(Ship-gate) 구축
- 에이전트의 결과물을 검증하기 위한 독립적인 비판자(Critic) 프로세스 활용
대부분의 Cursor 커맨드 팩(command packs)은 마크다운 스니펫(markdown snippets)입니다. 프롬프트를 붙여넣고, 에이전트(agent)가 잘 작동하기를 바라며, 성능이 퇴보하면 어깨를 으쓱하며 문단을 다시 작성하곤 합니다. 개인적인 메모로는 괜찮습니다. 하지만 다른 사람들이 설치하여 사용하는 워크플로우(workflows)를 배포하는 방식으로는 좋지 않습니다.
저는 그 반대를 원했습니다. 마치 작은 제품처럼 작동하는 슬래시 명령어(/slash commands) 말입니다. 각 /command는 얇은 엔트리(entry)입니다. 실제 계약(contract)은 쌍을 이루는 기술(skill)에 존재합니다. 행동 평가(Behavioral evals)는 PASS / PARTIAL / FAIL 점수를 매깁니다. CI의 배포 게이트(Ship-gate) 고정 요소(fixtures)는 기술 텍스트에서 안전 가드(safety guard)가 사라지면 빌드를 실패 처리합니다. 모든 PR(Pull Request)에 LLM 판사(judge)를 두지 않습니다. 구조적 앵커(Structural anchors)만 사용합니다. 저렴하고, 지루하며, 강제할 수 있습니다.
/gauntlet-loop 살펴보기
/gauntlet-loop를 예로 들어보겠습니다. 아이디어는 단순하고 냉혹합니다. "더 좋게 만들어줘"라고 말하는 것을 멈추는 것입니다. 실제 예시를 이겨내야 합니다.
-
명령어 파일(Command file). 얇은 YAML 프론트매터(frontmatter)와 개요(Overview), 기본값(Defaults), 단계(Steps), 안티 패턴(Anti-patterns), 예시(Examples)로 구성됩니다. 1단계는 항상 기술 계약(skill contract)을 해결합니다(워크스페이스 경로, 그 다음 사용자 설치 폴백(fallback)). 안티 패턴은 트리거(Trigger) / 잘못된 사례(Wrong) / 올바른 사례(Correct) / 이유(Reason)라는 고정된 형태를 사용합니다. 올바른(Correct) 동작은 기술 내의 긍정적 가드(positive guard)로도 존재해야 합니다.
-
기술 계약(Skill contract). 입력값으로는 목표(GOAL)와 실제 세계의 상응물(REAL-WORLD EQUIVALENT)이 필요하며, 검사 가능한 참조 팩(reference pack)(파일, 스크린샷, 클립, 빌드 또는 리포지토리(repo) 경로)이 추가로 필요합니다. 유명한 이름 하나만으로는 팩이 될 수 없습니다. 에이전트는 독립적인 부분들로 분해되고, 부분별 상태 머신(state machine)(빌드 → 비판 → 통과 | 반복 | 종료)을 실행하며, 제작자가 자신의 작업물을 직접 채점하게 두지 않습니다. 비판자(Critics)는 새로운 컨텍스트(context)를 사용합니다. 참조보다 더 나은 경우에만 통과(Pass)하며, 동일한 경우는 실패(fail)로 간주합니다. 모든 부분이 통과하면, 통합 비판자(integration critic)가 전체를 채점합니다. 선택 사항으로 예산(budget), 취향 영역의 자부심 게이트(taste-domain pride gate), 그리고 이력서를 위한 격차 장부(gap ledger)가 있습니다.
-
평가 루브릭(Eval rubric). 사례는 참조 누락, 팩 누락, 동일 시 실패(equal-is-fail), 비판 건너뛰기, 조작된 맹점(fabricated blind), 예산 소진, 중단된 격차를 재시도 없이 이력서에 기재하는 경우 등을 다룹니다. PARTIAL은 배포 게이트(ship gate)에서 실패로 간주됩니다.
CI에서의 Fixtures (Fixtures in CI). eval/fixtures.yaml은 SKILL.md에 반드시 그대로 나타나야 하는 skill_required 문구들을 나열합니다. "Do not let builders evaluate their own work"를 삭제하면 run-eval-fixtures.py --strict가 빨간색(실패)으로 변합니다. 이것이 핵심입니다. 부정적 지식(negative knowledge)은 암묵적 지식(tribal knowledge)이 아닌, 고정된 상태로 유지됩니다.
이것이 설치 사용자에게 중요한 이유
사용자가 이 저장소를 Cursor 사용자 플러그인(user plugin)으로 추가할 때, 단순히 느낌(vibes)에 의존하는 메뉴가 아니라 계약(contracts)과 CI 스토리(CI story)를 함께 받게 됩니다. 카탈로그는 이식성을 유지합니다(일반적인 예시 사용, 고용주 이름 미포함). 플러그인 설치는 데스크톱, 웹, CLI 및 모바일에 걸쳐 사용자의 계정과 동기화됩니다.
설치: Customize → Plugins를 통해 https://github.com/emaraschio/cursor-commands를 설치하세요. 공식 Cursor 제품이 아닙니다. MIT 라이선스입니다.
만약 본인만의 슬래시 명령어(slash commands)를 유지 관리한다면, 재사용 가능한 아이디어는 전체 카탈로그보다 더 작고 구체적입니다. 모든 명령어에 기술(skill)을 쌍으로 지정하고, 몇 가지 배포 게이트(ship-gate) 케이스를 작성한 뒤, 가드 텍스트(guard text)가 사라지면 CI가 실패하도록 만드세요. 그것만으로도 모델이 지난달의 프롬프트를 기억하기를 바라는 것보다 훨씬 낫습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기