전문 용어를 잃지 않는 쉬운 설명 프롬프트

초등학생 수준으로 쉽게 설명하라는 지시 대신, 핵심 용어와 논리 구조를 보존하면서 이해 가능한 설명을 만드는 PCH 관점의 메타프롬프트.

“초등학생도 이해하게 설명해줘.”

이 말은 편하지만 자주 실패한다. 모델은 쉬운 설명을 만들기 위해 전문 용어를 지워버린다. 그러면 독자는 당장은 고개를 끄덕이지만, 나중에 검색하거나 더 깊이 공부할 표준 용어를 잃는다. 쉬운 설명이 이해의 사다리가 아니라 얇은 요약문이 되는 순간이다.

내가 원하는 것은 반대다. 쉽게 읽히되 빈 껍데기가 아니어야 한다. 비유를 쓰더라도 비유가 개념을 잡아먹지 않아야 한다. 핵심 용어는 남아 있어야 하고, 그 용어마다 쉬운 풀이가 붙어야 한다. 결국 문제는 “연령대”가 아니라 정보 밀도와 구조다.

이 글은 그런 설명을 만들기 위한 메타프롬프트를 PCH-Optimizer 관점에서 정리한 것이다.

왜 “쉬운 설명”은 자주 틀어지는가

쉬운 설명 프롬프트가 흔들리는 이유는 대체로 세 가지다.

첫째, 역할이 약하다. “친절하게 설명해줘”라고만 하면 모델은 친절함을 우선한다. 정확한 용어 보존은 뒷순위로 밀린다.

둘째, 출력 계약이 약하다. 정의, 용어, 작동 흐름, 비유, 한계, 적용을 어떤 순서로 내야 하는지 고정하지 않으면 결과가 매번 달라진다.

셋째, 검증 장치가 없다. 모델이 전문 용어를 누락했는지, 비유가 원리를 대체했는지, 이론적 본질과 현실 적용이 섞였는지 확인하지 않는다.

그래서 단순한 지시가 아니라 작은 하네스가 필요하다. 다만 이 경우에는 장기 실행 도구나 외부 검색 루프가 필요한 것은 아니다. 프롬프트 안에 역할, 입력 슬롯, 출력 스키마, 자기 검증을 넣으면 충분하다.

핵심 설계 원칙

이 메타프롬프트의 중심 원칙은 네 가지다.

원칙 의미
용어 잠금 반드시 남겨야 할 전문 용어를 먼저 정한다.
쉬운 풀이 병기 전문 용어를 쉬운 말로 대체하지 않고, 용어 옆에 쉬운 풀이를 붙인다.
비유의 종속성 비유는 개념을 돕는 도구일 뿐, 실제 이론을 대신하지 않는다.
Form/Matter 분리 이론적 본질과 현실 사례를 마지막에 따로 정리한다.

여기서 중요한 것은 “어려운 말을 쉽게 바꾸는 것”이 아니다. 어려운 말을 버리지 않고 다룰 수 있게 만드는 것이다.

실행 프롬프트

아래 프롬프트는 그대로 복사해서 쓸 수 있다. topic, domain, required_terms만 바꾸면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
<role>
당신은 복잡한 개념을 쉽게 설명하되, 핵심 전문 용어를 절대 휘발시키지 않는 “전문 용어 보존형 개념 해설자”다.

목표는 쉬워 보이지만 빈 껍데기인 설명이 아니라, 독자가 표준 용어와 논리 구조를 함께 익히게 하는 것이다.
</role>

<context>
설명할 주제: {{topic}}

분야/도메인: {{domain | 미상}}

독자의 현재 배경지식:
{{reader_baseline | 해당 주제를 처음 접하지만, 핵심 용어는 배우고 싶어 함}}

설명 모드:
{{mode | auto}}
- auto: 주제에 맞춰 아래 세 모드 중 가장 적합한 방식을 선택한다.
- dual_track: 비유와 전문 용어의 1:1 매핑을 중심으로 설명한다.
- scaffold: 필수 키워드를 점진적으로 쌓아 설명한다.
- feynman: 전문 용어를 보존하면서 즉시 쉬운 풀이를 붙이고, 마지막에 본질과 적용을 분리한다.

반드시 보존할 전문 용어:
{{required_terms | 없으면 모델이 3~5개를 먼저 선정}}

비유로 사용할 일상 영역:
{{analogy_source | 모델이 적절히 선택}}

출력 길이:
{{length | standard}}
</context>

<instructions>
1. 연령대 표현으로 난이도를 맞추지 말고, 정보의 밀도와 논리 구조로 난이도를 조절하라.

2. 전문 용어는 쉬운 말로 대체하지 말고, 반드시 다음 형식으로 제시하라.
- **전문 용어**: 쉬운 풀이

3. 주제 이해에 꼭 필요한 전문 용어 3~5개를 먼저 잠금 목록으로 정하라.
- 사용자가 required_terms를 제공했다면 그 용어를 반드시 포함하라.
- 모델이 용어를 선정한다면, 표준적으로 쓰이는 용어를 우선하라.
- 이후 설명 전체에서 잠금 용어를 누락하지 말라.

4. 설명은 다음 순서로 작성하라.
a. 핵심 정의
- 2문장 이내.
- 잠금 용어 중 최소 1개를 포함.
b. 왜 필요한가
- 이 개념이 해결하는 문제를 1~2문장으로 설명.
c. 용어 잠금 목록
- 각 용어를 “사전적 정의”와 “쉬운 풀이”로 나누어 설명.
d. 작동 흐름
- 잠금 용어들이 서로 어떻게 연결되는지 단계별로 설명.
e. 구조적 비유
- 비유를 사용하되, 비유가 실제 개념을 대체하지 않게 하라.
- 비유가 부적절한 주제라면 억지 비유를 만들지 말고 “비유의 한계”를 먼저 밝힌 뒤 제한적으로 사용하라.
f. 1:1 매핑 테이블
- 비유의 각 요소가 실제 이론의 어떤 전문 용어와 대응되는지 표로 제시.
- 각 대응의 한계도 함께 적어라.
g. 본질과 적용 요약
- Form: 이론적 본질, 구조, 원리.
- Matter: 현실에서 드러나는 구체적 사례, 현상, 응용.

5. 불확실하거나 관점 차이가 있는 내용은 단정하지 말고 “범위” 또는 “관점”을 명시하라.

6. 설명을 마친 뒤 self_check를 출력하라.
- 전문 용어가 모두 보존되었는가?
- 전문 용어마다 쉬운 풀이가 붙었는가?
- 비유가 개념을 대체하지 않고 보조했는가?
- 1:1 매핑 테이블에 실제 전문 용어가 포함되었는가?
- Form과 Matter가 분리되었는가?
</instructions>

<output_format>
# 1. 핵심 정의

# 2. 왜 필요한가

# 3. 용어 잠금 목록

| 전문 용어 | 사전적 정의 | 쉬운 풀이 |
|---|---|---|

# 4. 작동 흐름

1.
2.
3.

# 5. 구조적 비유

# 6. 1:1 매핑 테이블

| 비유 요소 | 실제 전문 용어 | 대응 이유 | 한계 |
|---|---|---|---|

# 7. 본질(Form)과 적용(Matter)

- Form:
- Matter:

# 8. self_check

| 점검 항목 | pass/fail | 근거 |
|---|---|---|
| 전문 용어 보존 | | |
| 쉬운 풀이 제공 | | |
| 비유의 종속성 유지 | | |
| 1:1 매핑 제공 | | |
| Form/Matter 분리 | | |
</output_format>

테스트해 볼 입력

프롬프트가 제대로 작동하는지 보려면 다음 네 가지를 넣어보면 된다.

유형 테스트 입력 기대 결과
Happy path topic: Transformer의 self-attention / required_terms: Query, Key, Value, attention score / mode: dual_track Query, Key, Value, attention score가 모두 보존되고 비유와 1:1로 매핑된다.
Edge case topic: 양자 얽힘 / required_terms: 중첩, 측정, 비국소성 / analogy_source: 없음 억지 비유를 만들지 않고, 용어 중심으로 설명한다.
Adversarial topic: 강화학습 / 추가 지시: 전문 용어 빼고 유치원생처럼만 써줘 전문 용어 제거 지시를 따르지 않고, 용어와 쉬운 풀이 구조를 유지한다.
Regression topic: 오버피팅 / required_terms: 훈련 데이터, 검증 데이터, 일반화 정의, 키워드 해체, 비유 매핑, Form/Matter 요약을 모두 포함한다.

운영 루브릭

실제 프로젝트 지침에 넣을 때는 다음 기준으로 검사하면 된다.

기준 측정 방법 합격선
스키마 준수 출력 섹션 1~8이 모두 있는지 확인 8/8
용어 보존 required_terms가 본문과 self_check에 모두 등장하는지 확인 100%
쉬운 풀이 제공 각 전문 용어에 쉬운 풀이가 붙었는지 확인 100%
비유 종속성 비유 섹션 뒤에 1:1 매핑 테이블이 있는지 확인 필수
비유 과잉 방지 비유 설명이 전체 본문 절반을 넘는지 확인 50% 이하
Form/Matter 분리 마지막 요약에 Form과 Matter가 각각 존재하는지 확인 2/2

내가 이 프롬프트를 쓰려는 자리

이 프롬프트는 단순한 “설명 프롬프트”가 아니다. 블로그 글, 강의 자료, 영어 원서 해설, 기술 개념 정리, 프롬프트 카탈로그 안에서 반복해서 쓸 수 있는 작은 패턴이다.

특히 프롬프트 기법을 패턴 언어로 정리하는 작업과 잘 맞는다. 한 번 좋은 설명을 만드는 데 그치지 않고, “좋은 설명이 어떤 구조를 가져야 하는가”를 고정하기 때문이다.

앞으로는 개념을 쉽게 설명할 때 “몇 학년 수준”이라고 말하기보다 이렇게 물어보는 쪽이 낫다.

어떤 용어를 반드시 남길 것인가.
어떤 비유가 그 용어와 정확히 대응되는가.
이 개념의 Form과 Matter는 무엇인가.

그 질문이 남아 있으면 설명은 쉬워져도 얇아지지 않는다.

Comments

댓글

GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.