AI 코딩 도구를 사용하다 보면 Rule, Skill, Prompt 같은 개념을 접하게 된다.
처음 보면 전부 AI에게 자연어로 지시하는 기능처럼 보인다.
실제로도 비슷하다.
하지만 역할을 구분해서 보면 구조가 명확해진다.
Rule = AI가 지켜야 하는 규칙
Skill = 특정 작업을 수행하는 방법과 절차
Prompt = 현재 AI에게 요청하는 작업
Context = 프로젝트에 대한 정보
Tools = 실제 작업을 수행하기 위한 수단
Harness = 이 요소들을 조합한 AI Agent 작업 환경
이 글에서는 이 구조를 기준으로 Cursor를 사용하는 방식을 정리한다.
Rule
Rule은 AI가 프로젝트에서 작업할 때 따라야 하는 개발 규칙과 제약사항이다.
예를 들어 Unity 프로젝트라면 다음과 같은 규칙을 정의할 수 있다.
- 핵심 게임 로직은 MonoBehaviour에서 분리한다.
- Update에서 반복적인 GetComponent 호출을 사용하지 않는다.
- 반복 생성되는 객체는 Object Pooling을 우선 고려한다.
- 의존성은 명시적으로 관리한다.
이 규칙은 특정 작업 하나를 위한 것이 아니다.
플레이어 이동 시스템을 만들 때도 적용되고,
플레이어 이동 시스템 생성
인벤토리 시스템을 만들 때도 적용된다.
인벤토리 시스템 생성
네트워크 기능을 만들 때도 프로젝트의 관련 Rule이 적용될 수 있다.
따라서 Rule은 다음과 같이 이해하는 것이 가장 간단하다.
Rule
-> "이 프로젝트에서는 이렇게 개발한다."
프로젝트마다 Rule을 다르게 설정할 수 있다
Rule의 중요한 특징 중 하나는 프로젝트에 맞춰 다르게 구성할 수 있다는 것이다.
예를 들어 세 개의 프로젝트가 있다고 하자.
Project A
-> Unity 게임
Project B
-> Node.js 서버
Project C
-> React 웹
프로젝트마다 기술 스택과 아키텍처가 다르기 때문에 같은 개발 규칙을 적용할 이유가 없다.
Unity 프로젝트에서는:
Unity Lifecycle
MonoBehaviour
ScriptableObject
Object Pooling
게임 아키텍처
와 관련된 규칙이 중요하다.
Node.js 서버에서는:
TypeScript
REST API
Error Handling
Database
Logging
같은 규칙이 중요하다.
React 프로젝트에서는:
React Component
State Management
TypeScript
UI Architecture
같은 규칙이 필요하다.
결국 프로젝트별로 AI에게 다른 개발 환경을 제공할 수 있다.
Unity Project
-> Unity Rule
-> C# Rule
-> Architecture Rule
Node.js Project
-> Node.js Rule
-> API Rule
-> Database Rule
React Project
-> React Rule
-> TypeScript Rule
-> UI Rule
이게 Rule을 사용하는 가장 중요한 이유 중 하나다.
Global Rule과 Project Rule
모든 프로젝트에서 공통으로 사용할 규칙과 특정 프로젝트에서만 필요한 규칙을 분리할 수도 있다.
예를 들어:
Global Rule
-> 기본 코드 스타일
-> 주석 작성 원칙
-> 보안 원칙
그리고 프로젝트에서는:
Project Rule
-> 프로젝트 아키텍처
-> 기술 스택
-> 네이밍 규칙
-> 프로젝트별 개발 방식
을 정의할 수 있다.
개념적으로 보면 다음과 같다.
Global Rule
+
Project Rule
+
Scoped Rule
이런 식으로 규칙을 계층적으로 구성할 수 있다.
중요한 것은 모든 프로젝트에 동일한 규칙을 강제로 적용하는 것이 아니라 프로젝트의 특성에 맞춰 AI의 행동 범위를 설계하는 것이다.
Skill
Skill은 Rule과 목적이 다르다.
Skill은 특정 작업을 수행하기 위한 방법과 절차를 정의한다.
예를 들어 Git Commit 작업을 생각해보자.
매번 다음 작업을 반복한다고 가정한다.
Git 변경사항 확인
-> 변경된 파일 분석
-> 변경 목적 파악
-> Commit Type 결정
-> Commit Message 작성
-> Commit 실행
이 작업을 매번 Prompt로 작성하는 것은 비효율적이다.
이런 반복 작업을 Skill로 정의하면 하나의 작업 절차로 재사용할 수 있다.
예를 들어:
/commit-gen
같은 형태로 호출한다고 생각할 수 있다.
Skill 내부에서는 다음과 같은 절차를 정의할 수 있다.
1. Git diff 확인
2. 변경 파일 분석
3. 변경 목적 판단
4. Commit Type 결정
5. Commit Message 생성
6. 사용자 요청에 따라 Commit 수행
따라서 Skill은 다음과 같이 이해하는 것이 좋다.
Skill
-> "이 작업은 이런 방법과 순서로 처리한다."
Skill은 단순한 Prompt인가
여기서 헷갈리기 쉬운 부분이 있다.
Skill을 단순히 미리 만들어둔 Prompt라고 생각할 수도 있다.
어느 정도는 맞다.
반복적으로 사용하는 Prompt를 Skill로 만들어 재사용할 수 있기 때문이다.
하지만 이것만으로 설명하기에는 부족하다.
Skill에는 단순한 명령뿐만 아니라 다음과 같은 내용도 포함할 수 있다.
작업 순서
-> 분석 방법
-> 판단 기준
-> 사용할 도구
-> 결과 검증
-> 오류 처리
따라서 Skill은 단순한 Prompt 단축키라기보다:
특정 작업을 수행하기 위한 재사용 가능한 Agent Workflow
에 가깝게 이해하는 것이 좋다.
Skill에 추가 입력을 전달할 수 있다
Skill을 실행할 때 추가적인 입력을 전달하는 방식도 생각할 수 있다.
예를 들어:
/pr-create develop
이라고 요청하면 develop을 기준 브랜치로 사용하는 식이다.
또는:
/pr-create develop 로그인 기능과 회원가입 기능을 기준으로 MR 생성
처럼 추가적인 자연어 요구사항을 함께 전달할 수도 있다.
개념적으로는:
/skill-name
+
추가 입력
이다.
Skill은 이 입력을 작업에 활용한다.
Rule과 Skill의 차이
둘의 차이를 하나의 표로 정리하면 명확하다.
| 구분 | 역할 |
|---|---|
| Rule | 작업할 때 지켜야 하는 규칙 |
| Skill | 특정 작업을 수행하는 방법과 절차 |
| Prompt | 현재 수행할 작업에 대한 요청 |
| Context | 작업 대상 프로젝트에 대한 정보 |
| Tools | 실제 작업을 수행하기 위한 수단 |
예를 들어 다음과 같은 요청이 있다고 하자.
Prompt
-> 플레이어 이동 시스템을 만들어줘.
프로젝트에는 다음 Rule이 존재한다.
Rule
-> 핵심 로직은 MonoBehaviour에서 분리한다.
-> 불필요한 GetComponent 호출을 피한다.
-> 의존성은 명시적으로 관리한다.
그리고 이동 시스템 개발 Skill이 존재한다.
Skill
-> 기존 이동 시스템 탐색
-> 관련 인터페이스 확인
-> 필요한 클래스 생성
-> 기존 코드와 연결
-> 컴파일 오류 확인
-> 테스트
그러면 AI는 개념적으로:
Prompt
+
Skill
+
관련 Rule
+
Project Context
+
Tools
-> Agent 작업
형태로 작업하게 된다.
Rule과 Skill은 함께 사용된다
둘은 경쟁 관계가 아니다.
오히려 함께 사용할 때 의미가 커진다.
예를 들어 멀티플레이 게임 서버 프로젝트에 다음 Rule이 있다고 하자.
Rule
-> 서버 권위 구조를 따른다.
-> 클라이언트의 입력을 서버에서 검증한다.
-> 게임 상태는 서버를 기준으로 관리한다.
그리고 네트워크 기능을 생성하는 Skill이 있다.
Skill
-> 기존 네트워크 코드 탐색
-> Client Message 생성
-> Server Handler 생성
-> 입력 검증 로직 추가
-> 상태 변경
-> 테스트
사용자가:
/create-network-feature PlayerMove
라고 요청하면 AI는 Skill의 작업 절차를 따라가면서 프로젝트 Rule도 고려할 수 있다.
결과적으로:
Prompt
-> PlayerMove 네트워크 기능 생성
Skill
-> 네트워크 기능을 생성하는 작업 절차
Rule
-> 서버 권위
-> 입력 검증
-> 프로젝트 아키텍처
Context
-> 기존 네트워크 코드
-> 관련 클래스
-> 프로젝트 구조
Tools
-> 파일 검색
-> 파일 수정
-> 빌드
-> 테스트
-> Agent 작업
이라는 구조가 만들어진다.
AI Agent Harness
여기서 한 단계 더 나아가면 Harness라는 개념으로 연결할 수 있다.
AI에게 단순히:
이 코드 수정해줘.
라고 요청하는 것과,
프로젝트에 필요한 규칙과 작업 절차, 도구와 컨텍스트를 제공한 뒤 작업시키는 것은 차이가 크다.
AI Agent가 실제 개발 작업을 수행할 수 있도록 다음 요소들을 구성할 수 있다.
Rule
-> 무엇을 지켜야 하는가
Skill
-> 어떻게 작업할 것인가
Prompt
-> 지금 무엇을 할 것인가
Context
-> 어떤 프로젝트에서 작업하는가
Tools
-> 무엇을 사용해서 작업할 것인가
이런 요소를 조합해 AI Agent가 프로젝트에서 작업할 수 있는 환경을 구성하는 개념을 Harness라고 볼 수 있다.
개념적으로 표현하면:
Rule + Skill + Prompt + Context + Tools
-> Agent Harness
-> AI Agent
-> 실제 개발 작업
여기서 Harness는 반드시 특정 제품의 하나의 기능을 의미한다고 볼 필요는 없다.
핵심은 AI Agent를 그냥 코드 생성기로 사용하는 것이 아니라, 프로젝트의 개발 방식에 맞게 작업 환경 자체를 설계한다는 것이다.
기존의 AI 사용 방식과 다른 점
일반적인 AI 사용 방식은 다음과 비슷하다.
개발자
-> Prompt 작성
-> AI 응답
-> 코드 복사
-> 수정
-> 다시 Prompt
AI가 매번 새로운 작업을 수행할 때마다 개발자가 필요한 맥락과 규칙을 다시 설명해야 한다.
Harness를 구성하면 구조가 달라진다.
Project
-> Rule
-> Skill
-> Context
-> Tools
Developer
-> Prompt
Prompt + Project Environment
-> Agent
-> 작업 수행
개발자는 매번 프로젝트의 모든 규칙을 설명할 필요가 없다.
프로젝트에 필요한 규칙과 작업 방법을 미리 정의해두고, 현재 필요한 작업만 요청하면 된다.
프로젝트마다 다른 AI를 만드는 것
여기서 중요한 관점이 하나 나온다.
AI 모델 자체가 달라지는 것은 아니다.
같은 AI를 사용하더라도 프로젝트 환경을 다르게 구성하면 AI의 작업 방식은 달라질 수 있다.
예를 들어:
Unity Project
-> Unity Rule
-> C# Rule
-> Game Architecture
-> Unity 관련 Skill
Server Project
-> Node.js Rule
-> API Architecture
-> Database Rule
-> Server 관련 Skill
같은 AI라도 프로젝트에 따라 다른 규칙과 작업 절차를 적용할 수 있다.
따라서 AI Agent를 사용할 때 중요한 것은 단순히 어떤 모델을 사용하는가만이 아니다.
Model
+
Context
+
Rules
+
Skills
+
Tools
+
Workflow
를 어떻게 구성하느냐도 중요하다.
정리
Rule과 Skill의 차이는 간단하다.
Rule
-> 개발 원칙
Skill
-> 작업 절차
Prompt
-> 현재 요청
Context
-> 프로젝트 정보
Tools
-> 작업 수단
그리고 이것들을 프로젝트에 맞게 조합하면:
Rule + Skill + Prompt + Context + Tools
-> Agent Harness
라는 구조를 만들 수 있다.
결국 핵심은 AI에게 코드를 잘 만들어달라고 요청하는 것에서 끝나는 것이 아니다.
AI가 어떤 규칙을 지키고,
어떤 방식으로 작업하며,
어떤 프로젝트 정보를 참고하고,
어떤 도구를 사용하고,
어떤 절차로 결과를 검증할 것인지까지 설계하는 것이다.
이렇게 보면 Cursor의 Rule과 Skill은 단순한 편의 기능이 아니다.
AI Agent를 프로젝트의 개발 방식에 맞게 구성하기 위한 기본적인 제어 수단으로 볼 수 있다.