AI에게 규칙을 세워야 하는 이유
Vibe Coding은 자연어로 AI에게 코드를 직접 생성하게 하는 개발 방식입니다. 문제는 품질에 있습니다. 규칙 없는 AI는 재작업을 하고, 수정을 빠뜨리고, 몰래 코드를 삭제하며, 영구적인 기술 부채를 남깁니다. 이 강에서는 먼저 어떤 사고가 발생하는지 살펴보고, 그 다음 가장 안정적인 제약 주입 방법을 알아봅니다.
다음 네 가지 사고 유형은 AI 협업에서 반복적으로 발생하며, 원인은 모두 같습니다: 제약이 컨텍스트에 들어가지 않은 것입니다.
오해로 인한 재작업
AI는 요구사항을 받자마자 바로 작성을 시작하고, 200줄을 작성한 후에야 오해가 있었음을 발견하고 롤백합니다. 더 심한 경우 7개 파일을 수정한 후에야 접근 방식이 틀렸다는 것을 발견하여 각각 revert하는 비용이 매우 높습니다.
기술 스택 드리프트
다른 대화에서 AI는 다른 프레임워크를 선택합니다: 오늘은 Express, 내일은 Fastify. 데이터베이스는 MongoDB와 PostgreSQL 사이를 오갑니다. 기술 스택이 고정되지 않으면 프로젝트는 드리프트 속에서 일관성을 잃습니다.
선의의 파괴
AI는 리팩토링 시 불필요하다고 판단한 코드를 정리하는데, 나중에서야 그 코드가 유용했다는 것을 발견합니다. 선의의 정리가 파괴적인 작업이 됩니다.
영구적인 기술 부채
완전한 인증 시스템을 요청하면 AI는 「먼저 간단한 로그인을 만들고 나중에 OAuth를 추가하자」고 합니다. 결과적으로 그 나중은 영원히 오지 않고, 간단한 코드가 영구적인 기술 부채가 됩니다.
「로그인 기능 만들어 줘」라는 같은 요청이 규칙 없는 모드와 규칙 있는 모드에서 완전히 다른 결과로 이어집니다. 「다음 단계」를 클릭하면 두 타임라인이 동시에 진행됩니다.
AI에게 제약을 전달하는 세 가지 일반적인 방법이 있습니다. 클릭하여 전환하면서 같은 제약(「데이터베이스는 PostgreSQL 사용」)이 세 시점에서 여전히 유효한지 확인하세요.
frontmatter로 적용 방식 제어
---
alwaysApply: true # 모든 대화에 자동 적용
---
# 개발 제약 및 구성 표준
다음은 사용자의 중요한 제약 사항입니다. 반드시 엄격히 준수해 주세요.true는 전역 코딩 표준에, false는 글쓰기 스타일 가이드 같이 필요 시 참조하는 파일에 사용하여 코딩 대화의 컨텍스트를 오염시키지 않습니다.
xs_vibe_rules의 세 가지 파일
rule-opensource.mdc: 주요 개발 표준, 전체 워크플로우를 커버하는 14개 챕터writing-style.mdc: 글쓰기 스타일 가이드, 필요 시 수동으로 참조secrets.mdc: API 키 및 자격증명 템플릿, 플레이스홀더 형식
사용 시 프로젝트의 .cursor/rules/ 디렉토리에 넣으면 됩니다.
itshen/xs_vibe_rules · 이 시리즈의 오픈소스 저장소
전체 규칙 세트가 오픈소스로 공개되어 있습니다(MIT License). Fork하여 프로젝트의 .cursor/rules/ 디렉토리에 넣고 자신의 기술 스택에 맞게 수정하면 첫 번째 AI 협업 표준이 됩니다.
규칙의 가치는 많은 것이 아니라 각각이 실제 문제를 해결하는 것에 있습니다. AI가 같은 실수를 반복할 때마다 그것을 규칙으로 만드세요 - 이것이 이 시리즈 전체의 기본 방법입니다. 제약이 효과가 있는지는 주입 메커니즘에 달려 있습니다. 「반드시」를 열 번 써도 매 턴 자동 로드되는 Rule 파일 하나만 못합니다.
출처: 이 시리즈는 저자의 오픈소스 저장소 itshen/xs_vibe_rules를 기반으로 하며, 여러 실제 프로젝트에서 축적된 Cursor Rules와 설계 사고를 담고 있습니다.