New · Step 1

2부 · 지침 (Instructions)

항상 로드되는 상위 규칙 — 6원칙·단일 출처·확인 게이트.

1. 지침 (Instructions) — 에이전트의 헌법

▶ 포인트 — 지침은 항상 컨텍스트에 로드되는 상위 규칙이다. 그래서 짧고·명확하고·”무엇을”에 집중해야 한다. 가장 흔한 실수는 (1) 과설계, (2) 세부를 지침에 박아 스킬을 우회하게 만드는 것이다.

1.1 개념 — 지침은 무엇인가

  • 에이전트가 모든 대화에서 항상 참조하는 최상위 규칙. 회사로 치면 헌법·취업규칙.
  • 스킬(필요할 때 로드)과 달리 지침은 늘 켜져 있으므로, 길수록 모든 응답이 무거워지고 핵심이 묽어집니다(1부 3.2 attention budget).
  • 따라서 지침에는 항상 지켜야 할 소수의 원칙만 담고, 상황별 디테일은 스킬로 내립니다.

1.2 어떻게 작성하나 — 6원칙

이번 데모를 만들며 검증한 작성 원칙입니다.

① “무엇을”만, “어떻게”는 맡긴다. 메이커는 목표·규칙만 쉬운 말로 적고, 코드·라이브러리·경로 같은 구현은 에이전트에 맡깁니다(1부 1.4 황금률).

❌ "pandas로 /app/uploads의 xlsx를 read_excel 후 groupby로 집계하고 print"
✅ "엑셀 숫자는 눈대중 말고 실제로 계산해서 정확한 값을 알려주세요"

② 일반 사용자가 읽을 수 있게. 대부분의 메이커는 개발자가 아닙니다. 디렉토리·함수명·전문용어를 빼고 업무 언어로 적습니다.

③ 단일 출처(Single Source of Truth) — 지침에 세부를 박지 마라. 세부 규칙(예: 브랜드 색상)을 지침과 스킬 양쪽에 적으면 에이전트가 “지침에 이미 있네” 하고 스킬을 건너뜁니다. 디자인·절차는 스킬에만 두고, 지침은 스킬을 가리키게합니다.

❌ 지침: "배경은 아이보리(#FBF6EC), 포인트는 마젠타(#C2185B)"
   → 에이전트가 색만 알고 템플릿·단색 폴백 규칙이 든 스킬을 안 봄

✅ 지침: "메일·보고서는 회사 디자인 규칙(메일·보고서 스킬)을 그대로 따르세요"
   → 색을 알려면 반드시 스킬을 열어야 함 → 템플릿·규칙까지 함께 따라옴

흔한 사고다. 색을 지침에 박아두면 에이전트가 색만 보고 스킬(템플릿·예외 처리 규칙)을 건너뛰어, 디자인이 부분적으로 깨지는 일이 생긴다(1.5 사례).

④ 비가역 행동에는 확인 게이트(HITL). 메일 발송·외부 전송처럼 되돌리기 어려운 작업은 반드시 사용자 확인 후 실행으로 못 박습니다(1부 10.2).

⑤ 가드레일은 부정형으로 명확히. “데이터에 없는 숫자를 만들지 않는다”, “승인 전 발송하지 않는다” 처럼 금지선을 분명히 적습니다.

⑥ 구조: 역할 → 작업별 규칙 → 가드레일. 짧은 섹션으로 끊어 스캔하기 쉽게 만듭니다.

1.3 좋은 지침 구조 (템플릿)

# [에이전트 이름] — 지침

[한 문단: 역할과 무엇을 도와주는지]

## [작업 A]를 할 때
- 규칙 (무엇을, 쉬운 말로)
- 세부는 스킬을 가리키기

## [작업 B]를 할 때 (비가역이면 "중요" 표시)
- 확인 게이트, 금지선

## 지킬 점 (가드레일)
- 항상/절대 규칙 3~5개

1.4 지침에 넣을 것 vs 스킬로 내릴 것

가장 자주 막히는 결정입니다. 기준은 “항상 필요한가, 가끔 필요한가”입니다.

구분 지침(항상 로드) 스킬(필요할 때 로드)
성격 모든 대화에 적용되는 원칙 특정 작업의 방법·형식
길이 짧게(스캔 가능) 길어도 됨(그때만 로드)
예 역할, 톤, 가드레일, HITL 규칙 분석 방법, 보고서 형식, 디자인 규칙, 특수 절차
변경 빈도 드묾 자주(형식·규칙 진화)

지침에 넣을 것 (소수):

  • 에이전트의 역할과 무엇을 도와주는지
  • 항상 지켜야 할 가드레일(없는 숫자 만들지 않기 등)
  • 비가역 행동의 확인 게이트(발송 전 승인)
  • 세부가 필요한 작업은 “그 스킬을 따르라”는 포인터

지침에서 빼야 할 것 (→ 스킬로):

  • 구체적 출력 형식·템플릿
  • 색·폰트 같은 디자인 값
  • 단계별 절차·도구 사용법
  • 코드·라이브러리·경로 같은 구현

짚고 가기: 지침이 길어진다고 느끼면 십중팔구 어떻게(구현·형식)가 섞인 것이다. 그 부분을 스킬로 내리면 지침은 다시 가벼워지고, 에이전트는 작업할 때 해당 스킬을 펼쳐 더 정확히 따른다.

1.5 왜 단일 출처가 중요한가 — 디자인 깨짐 사례

세부를 지침에 중복으로 박으면 에이전트가 스킬을 건너뛰어 품질이 깨지는 일이 생깁니다. 대표적인 예가 HTML 메일 디자인입니다.

  • 증상: 메일 헤더 글씨(흰색)가 안 보임.
  • 표면 원인: 헤더 배경을 그라데이션(linear-gradient)만으로 칠해, 그라데이션 미지원 메일앱(Outlook 등)에서 배경이 사라지고 흰 글씨만 남음.
  • 근본 원인: 색 값이 지침에 박혀 있어 에이전트가 스킬의 안전 규칙(“흰 글씨엔 단색 배경을 깐다”)을 펼쳐보지 않음.
  • 교훈: 디자인을 스킬에만 두고 지침은 “스킬을 따르라”고만 했다면, 에이전트가 스킬을 열어 안전 규칙(bgcolor 단색)을 함께 적용했을 것.

반론 대응(FAQ): “지침에 다 적으면 더 확실하지 않나?” → 아니다. 다 적을수록 지침이 비대해져 핵심이 묽어지고(attention budget), 스킬을 우회해 오히려 품질이 떨어진다. 지침은 가리키고, 디테일은 스킬에.