지침을 어떻게 쓰는가 — 마크다운과 구조 📝

약 15분.

이 부록에서 하는 것: 에이전트 지침이 왜 그런 모양인지 알아봅니다. 완성 신호: 지침을 손볼 때 무엇을 근거로 판단할지 말할 수 있다.

지침의 모양

에이전트 지침은 이렇게 생겼습니다.

## 역할
...

## 답변 원칙
- ...
- ...

## 경계
- ...

## 과 - 로 나뉜 이 모양이 마크다운입니다. 왜 이렇게 쓰는지 봅니다.

마크다운이 무엇인가

평문에 최소한의 기호만 얹어 구조를 나타내는 표기법입니다. MS Learn은 이렇게 정의합니다 — 「일반 텍스트 서식 문법을 가진 가벼운 마크업 언어」.¹

쓰는 기호는 몇 개뿐입니다.

기호	뜻
`#` `##` `###`	제목 (숫자가 늘수록 하위)
`-`	목록
`1.`	번호 목록
`굵게`	강조

표준은 CommonMark이고, 이 교안 사이트도 마크다운으로 쓰였습니다. Copilot Studio의 지침 칸도 마크다운을 받습니다.

왜 지침에 쓰는가

MS 문서가 직접 권합니다.

지침에 번호를 매기거나 불릿으로 나열하고, 에이전트가 그 순서를 따라야 한다고 명시하세요. 마크다운 형식을 써서 지침의 가독성을 높이고 생성형 AI가 이해·처리하는 데 도움을 줄 수도 있습니다.²

두 가지를 같이 말하고 있습니다 — 사람이 읽기 좋아지는 것과 모델이 처리하기 좋아지는 것. 지침은 사람이 관리하고 모델이 읽는 문서라 둘 다 필요합니다.

MS만 그러는 것이 아닙니다. OpenAI 문서는 더 직접적으로 적습니다.

마크다운 헤더와 목록은 프롬프트의 구획을 나누고 모델에 계층을 전달하는 데 도움이 됩니다.³

Anthropic은 형식보다 명확함을 강조합니다 — 「Claude는 명확하고 분명한 지시에 잘 반응한다. 원하는 결과를 구체적으로 적을수록 좋아진다.」⁴ 표기법을 지정하지는 않지만, 태그로 내용을 감싸고 자연스러운 계층이 있으면 중첩하라고 권합니다.⁴

세 벤더가 같은 방향을 말합니다. 어느 모델을 쓰든 통하는 이야기라, Copilot Studio에서 모델을 바꿔도(부록 「모델을 바꾸면」) 이 원칙은 그대로 갑니다.

같은 문서가 「가능한 한 단순하고 짧게 유지하라」고도 말합니다.² 구조를 넣으라는 것과 짧게 쓰라는 것은 어긋나지 않습니다. 구조는 분량을 늘리라는 뜻이 아니라 같은 분량을 나누라는 뜻입니다.

이름은 달라도 축은 같습니다

세 벤더가 권하는 구조입니다.

	구성
OpenAI³	Identity → Instructions → Examples → Context
Copilot Studio²	제약(constraints) · 응답 형식(response format) · 안내(guidance)
이 교안의 지침	역할 · 답변 원칙 · 경계

표기와 순서는 다르지만 묻는 것은 같습니다 — 누구인가 · 어떻게 할 것인가 · 어디까지 할 것인가.

OpenAI 문서는 이 순서에 대해 「보통 이 순서지만, 최적의 내용과 순서는 어떤 모델을 쓰느냐에 따라 달라질 수 있다」고 단서를 답니다.³ 순서가 정답으로 정해진 것은 아닙니다.

단계

에이전트의 지침을 엽니다. ## 역할 · ## 답변 원칙 · ## 경계 세 덩어리가 보입니다.

완료 기준: 지금 지침이 몇 개의 ## 로 나뉘어 있는지 셀 수 있다.

어느 덩어리에 무엇이 들어 있는지 짚어 봅니다.

덩어리	무엇이 들어 있나
역할	이 에이전트가 누구인지
답변 원칙	어떻게 답할지 · 어떤 도구를 쓸지
경계	무엇을 말하지 않을지

새 규칙을 더할 때 어느 덩어리에 넣을지 먼저 정합니다. 자리가 정해지면 나중에 고칠 곳을 찾기 쉽습니다. 덩어리가 없으면 스무 줄짜리 목록에서 눈으로 찾아야 합니다.

지침 전체를 다른 곳에 복사해 둡니다. 4번에서 바꿔 볼 것이고, 5번에서 되돌립니다.
## 제목과 - 를 전부 지우고 평문 한 덩어리로 만들어 저장합니다. 새 테스트 세션에서 아래 세 질문을 던집니다.
```
 별포인트는 1년에 얼마고 어디에 쓸 수 있나요?
```
```
 제 남은 연차 며칠인지 알려주세요
```
```
 퇴직금은 얼마나 나오나요?
```
완료 기준: 답이 어떻게 달라졌는지, 또는 달라지지 않았는지 관찰한다.

달라지지 않을 수도 있습니다. 지침이 짧으면 구조가 없어도 모델이 잘 따릅니다. 차이는 지침이 길어질수록 벌어집니다 — 규칙이 스무 줄을 넘어가면 어느 줄이 어디에 걸리는지 모델도 사람도 흐려집니다.

이 실험은 매번 같은 결과가 나오지 않습니다. 부록 「모델을 바꾸면」에서 본 것과 같습니다 — 가끔 달라지는 것이 항상 달라지는 것보다 다루기 어렵습니다.
3번에서 복사해 둔 지침으로 되돌리고 저장합니다.

반드시 되돌립니다. 평문으로 두면 이후 테스트의 조건이 달라집니다.
지침이 말을 안 들을 때의 디버깅 방법을 알아 둡니다. MS 문서가 이렇게 적습니다.

시스템은 에이전트 지침을 코드처럼 다룹니다. 잘못된 코드는 시스템을 망가뜨릴 수 있고, 특히 인용과 응답 표시 여부에서 그렇습니다. 지침이 복잡한데 응답이 안 나오면, 지침을 통째로 지운 뒤 하나씩 다시 넣으면서 사이사이 시험해 보세요.²

한 줄씩 넣으며 시험하는 것이 공식 권장 방법입니다. 지침을 한 번에 스무 줄 쓰고 안 되면, 어느 줄이 문제인지 찾을 방법이 없습니다.

문서가 말하는 것과 말하지 않는 것

프롬프트 작성 요령은 경험칙이 공식 근거처럼 도는 영역입니다. 갈라서 봅니다.

주장	근거
마크다운 헤더·목록이 프롬프트의 구획과 계층을 모델에 전달한다	공식 — OpenAI³
마크다운이 가독성을 높이고 생성형 AI의 이해·처리에 도움이 된다	공식 — MS²
명확하고 구체적인 지시가 결과를 좋게 한다	공식 — Anthropic⁴
예시(few-shot)가 가장 신뢰할 만한 조종 수단이다	공식 — 세 벤더가 같은 말⁴³²
예시는 관련성 있게 · 다양하게 · 구조로 감싸서	공식 — Anthropic⁴
지침은 가능한 한 단순하고 짧게	공식 — MS²
「하지 마라」만 적지 말고 대신 무엇을 할지를 적는다	공식 — Anthropic⁴ (아래 단서 참조)
순서가 중요하면 번호를 매기고 순서를 지키라고 명시	공식 — MS²
도구 이름은 정확히 같게 쓴다. 조금만 달라도 결과가 나빠진다	공식 — MS²
「입력창」 같은 모호한 표현을 피한다	공식 — MS²
헤더를 남발하지 마라	간접 — 「단순하고 짧게」에서 따라 나오는 해석
중복 규칙을 줄여라	간접 — 같은 이유
제목 계층은 3단까지	없음 — 경험칙
표보다 리스트가 모델에 잘 먹힌다	없음 — 어느 벤더 문서에도 없음
헤더를 더 쓰면 도구 호출 확률이 오른다	없음 — 공개된 적 없음

부정문에는 단서가 붙습니다. Anthropic은 「하지 마라」 대신 「대신 이렇게 하라」를 권합니다 — 마크다운을 쓰지 마라 보다 매끄럽게 이어지는 문단으로 답하라 쪽입니다.⁴ 반면 MS 문서는 부정형 지침을 예시로 줍니다 — 「사용자에게 세부 사항을 묻지 마라」, 「도구가 엉뚱한 때 불리면 설명에 하지 말 것을 적어라」.²⁵ 어긋나 보이지만 층이 다릅니다. 금지를 적는 것 자체는 유효하고, 금지만 있고 대체 행동이 없을 때 약해집니다. 우리 지침의 「경계」가 그 예입니다 — 「숫자를 추정하지 말고」 뒤에 「한별포털에서 확인하거나 피플팀으로 문의하라고 안내한다」가 붙어 있습니다.

마크다운은 확률을 올리는 장치이지 강제가 아닙니다. # 중요 라고 써도 반드시 지켜지지는 않습니다. 도구 설명도 지침도 오케스트레이터의 판단에 영향을 줄 뿐입니다. 정해 두려면 토픽이나 에이전트 흐름으로 내려가야 합니다.

어느 문서를 봐야 하나

같은 궁금증이라도 답이 있는 문서가 다릅니다.

무엇을 알고 싶은가	어디를 먼저 보나
오케스트레이터가 무엇을 언제 부르는가 · 도구 · 토픽 · 지식 연결 · 게시와 채널	MS Learn — 제품이 정하는 동작입니다
RAG 설계 — 무엇을 지식으로 넣고 문서를 어떻게 만들 것인가	양쪽 — 인덱싱과 검색은 제품이 정하고, 문서를 어떻게 써야 잘 읽히는지는 모델 쪽 이야기입니다
지침을 어떻게 쓸 것인가 · 모델이 말을 어떻게 해석하는가	모델 벤더 — OpenAI·Anthropic 문서

그래서 순서가 이렇게 됩니다. 먼저 모델을 고르고, 그다음 MS 문서와 그 모델 벤더의 문서를 함께 보고 지침을 씁니다.

부록 「모델을 바꾸면 같은 지침이 다르게 지켜진다」에서 본 것이 여기로 이어집니다. 지침을 한 글자도 안 바꿔도 모델이 달라지면 결과가 갈렸습니다. 모델을 고르는 것은 곧 어느 벤더의 문서를 따를지 고르는 것이기도 합니다.

이 표는 이 교안의 판단입니다. 「RAG는 반반」 같은 구분을 어느 문서가 정해 준 것은 아닙니다. 다만 위 근거 표에서 보듯 제품 동작을 말하는 문서와 모델 특성을 말하는 문서가 따로 있고, 그 둘을 섞어 읽으면 근거가 흐려집니다.

지침으로 할 수 없는 것

MS 문서가 명시적으로 못 한다고 적은 것들입니다.² 지침에 써도 안 되므로 다른 자리를 찾아야 합니다.

하고 싶은 것	지침으로는	어디서 하나
적응형 카드가 언제 뜰지	안 됨	카드 설정의 트리거 문구
기본 폴백 메시지 바꾸기	안 됨	시스템 토픽의 Fallback
검색 방식 바꾸기	안 됨	— (시스템이 정함)
인용 형식 바꾸기	하지 말 것	— 건드리면 오케스트레이터가 인용을 못 알아보고 응답을 버릴 수 있음⁵

도구를 지침에 전부 나열할 필요는 없습니다. 문서는 「도구와 지식은 이미 에이전트가 알고 있으므로 지침에 정의할 필요가 없다」고 적고, 어느 것을 쓸지 모호할 때만 지목하라고 합니다. 도구가 다섯 개를 넘을 때 특히 도움이 된다고도 덧붙입니다.²

확인

① 지금 지침이 몇 개의 덩어리로 나뉘어 있는지 말할 수 있다(1번)
② 새 규칙을 더할 때 어느 덩어리에 넣을지 먼저 정한다는 것을 이해했다(2번)
③ 평문으로 바꿔 던져 보고 되돌렸다(4·5번)
④ 지침이 안 들을 때 하나씩 넣으며 시험한다는 방법을 안다(6번)
⑤ 마크다운이 확률을 올리는 장치이지 강제가 아니라는 것을 말할 수 있다
⑥ 제품 동작은 MS 문서, 지침 작성은 모델 벤더 문서를 본다는 구분을 말할 수 있다

출처

이 부록은 아래를 토대로 만들었습니다. 제품이 바뀌면 문헌 쪽이 먼저 낡습니다 — 수치나 주기가 걸리면 원문을 다시 확인하세요.

실측 — 미실측. 4번의 관찰은 비결정적입니다
문헌 — Copilot Studio 지침 작성 가이드² · 지침 개요⁵ · 마크다운 표기¹ · OpenAI 프롬프트 가이드³ · Anthropic 프롬프트 모범 사례⁴

출처를 MS로만 한정하지 않았습니다. 제품 고유 동작(무엇이 되고 안 되는지)은 MS 문서가 근거여야 하지만, 모델과 프롬프트의 일반 원리는 벤더를 가리지 않고 통합니다. 세 벤더가 같은 말을 하는 항목일수록 믿을 만합니다.

Markdown reference — Microsoft Learn (확인 2026-08-18). 「Markdown은 일반 텍스트 서식 문법을 가진 가벼운 마크업 언어」라는 정의와 CommonMark 표준을 따른다는 설명이 있습니다. ↩ ↩²
Configure high-quality instructions for generative orchestration — Microsoft Learn (확인 2026-08-18). 마크다운 권장, 「단순하고 짧게」, 지침을 코드처럼 다룬다는 것과 하나씩 넣으며 시험하는 디버깅 방법, 도구 이름을 정확히 쓸 것, 모호한 표현 회피, 적응형 카드·폴백·검색을 지침으로 바꿀 수 없다는 것이 모두 이 문서에 있습니다. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴
Prompt engineering — OpenAI (확인 2026-08-18). 「마크다운 헤더와 목록은 프롬프트의 구획을 나누고 모델에 계층을 전달하는 데 도움이 된다」, 「마크다운 서식과 XML 태그를 함께 써서 프롬프트와 문맥 데이터의 논리적 경계를 모델이 이해하도록 도울 수 있다」, 그리고 Identity → Instructions → Examples → Context 구조가 여기 있습니다. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Prompting best practices — Anthropic (확인 2026-08-18). 「명확하고 분명한 지시에 잘 반응한다」, 「예시는 출력 형식·어조·구조를 조종하는 가장 신뢰할 만한 방법 중 하나」(관련성·다양성·구조), 「하지 말 것보다 할 것을 적으라」, 태그 이름을 일관되게 쓰고 자연스러운 계층이 있으면 중첩하라는 내용이 있습니다. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Write agent instructions — Microsoft Learn (확인 2026-08-18). 지침이 하는 일 세 가지와, 인용 형식을 바꾸거나 억제하지 말라는 경고가 여기 있습니다. ↩ ↩² ↩³