✨ Update 02. Prompts with the latest refined prompts from D:\_Geulbeot
This commit is contained in:
109
02. Prompts/최종본/01-1. 단일 AI 활용 보고서 작성 _ (개요) 내용 요약 (1).md
Normal file
109
02. Prompts/최종본/01-1. 단일 AI 활용 보고서 작성 _ (개요) 내용 요약 (1).md
Normal file
@@ -0,0 +1,109 @@
|
||||
# 프롬프트 구조 및 내용 해설 — 단일 AI 보고서 작성
|
||||
|
||||
---
|
||||
|
||||
## 1. 이 프롬프트는 무엇인가
|
||||
|
||||
단일 AI를 활용하여 내부 자료 기반의 분석 보고서를 작성하는 프롬프트이다.
|
||||
작성자가 AI와 대화하며 단계별로 확인·수정을 거쳐 A4 HTML 보고서를 완성한다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 어떻게 실행하는가
|
||||
|
||||
작성자는 아래 세 가지를 AI에게 함께 제공한다.
|
||||
|
||||
| 제공물 | 설명 |
|
||||
|--------|------|
|
||||
| **(사전) 작성자 기재사항.md** | 보고서 제목, 목적, 대상 독자, 성격, 키워드, 흐름 등 작성자의 요구사항 |
|
||||
| **프롬프트 본문.md** | AI가 따를 규칙과 절차. 문체, 형식, 출처 원칙, HTML 출력 규격 포함 |
|
||||
| **관련 자료** | 보고서의 근거가 되는 첨부 파일들 |
|
||||
|
||||
프롬프트 본문은 한 번 설계하면 거의 수정하지 않는 고정 규칙이고, 기재사항은 매 보고서마다 작성자가 채워 넣는 변동 입력값이다. 두 파일을 분리한 이유는 프롬프트를 범용 템플릿으로 유지하면서, 작성자가 기재사항만 바꿔 다양한 보고서에 재사용할 수 있도록 하기 위함이다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 특징
|
||||
|
||||
이 프롬프트의 핵심 특징은 **(사전) 기재사항에 기반하여 프롬프트 각 항목이 재정리된다**는 점이다.
|
||||
|
||||
- 페르소나 설정 → 기재사항의 분야·전문성 힌트를 반영하여 AI가 스스로 전문가 역할을 선언
|
||||
- 보고서 성격 → 기재사항의 목적·대상·성격에 따라 보고서 방향이 결정됨
|
||||
- 목차 설계 → 기재사항의 키워드·보고서 흐름에 따라 구조가 설계됨
|
||||
- 최종 출력 → 기재사항의 제목이 표지와 헤더에 반영됨
|
||||
|
||||
기재사항을 많이 채울수록 정밀해지고, 적게 채워도 프롬프트의 기본값으로 동작한다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 프롬프트 순서 — 왜 이 위치에 있는가
|
||||
|
||||
프롬프트 본문은 **사전 규칙**과 **작업 절차** 두 영역으로 나뉜다.
|
||||
사전 규칙은 AI가 작업을 시작하기 전에 숙지해야 할 것이고, 작업 절차는 순서대로 실행하는 것이다.
|
||||
|
||||
### 사전 규칙의 순서
|
||||
|
||||
| 순서 | 항목 | 이 위치에 있는 이유 |
|
||||
|------|------|-------------------|
|
||||
| ① | 페르소나 설정 | "나는 누구인가"가 정해져야 이후 모든 판단의 관점이 생긴다 |
|
||||
| ② | 보고서 성격 | 페르소나가 정해진 후 "무엇을 위한 보고서인가"를 확인한다 |
|
||||
| ③ | 출처 및 자료 활용 원칙 | 목적이 정해진 후 "자료를 어떻게 다룰 것인가"의 규칙이 필요하다. 이것이 없으면 AI가 자료에 없는 내용을 추론으로 채운다 |
|
||||
| ④ | 문체 기준 | 무엇을 쓸지, 어떤 자료로 쓸지가 정해진 후 "어떤 말투로 쓸지"를 지정한다 |
|
||||
| ⑤ | 보고서 형식 | 문체까지 정해진 후 "물리적으로 어떤 모양인가"를 지정한다. 계층 구조, 문단 길이, 표 처리 등 |
|
||||
|
||||
**요약 : 정체성 → 목적 → 재료 규칙 → 말투 → 외형** 순서이다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 각 단계 요약
|
||||
|
||||
### STEP 1. 자료 분석 및 페르소나 선언
|
||||
|
||||
자료를 읽고 분야·성격을 파악하여 페르소나를 선언한다. 자료별 핵심 내용, 문제점·쟁점, 상충 사항을 정리하여 작성자에게 보고한다. 이 단계에서만 `[자료-001]`, `[상충]` 같은 내부 태그를 사용하여 근거를 명확히 보여준다.
|
||||
|
||||
→ **자료를 읽지 않은 상태에서 목차를 설계하면 자료에 없는 내용으로 채우게 되므로, 분석이 반드시 선행되어야 한다.**
|
||||
|
||||
### STEP 2. 목차 설계
|
||||
|
||||
STEP 1의 분석 결과와 기재사항의 키워드·흐름을 바탕으로 장-절 구조의 목차를 설계한다. 자료에서 충분히 뒷받침되는 항목만 포함한다.
|
||||
|
||||
→ **목차 없이 본문을 쓰면 AI가 중간에 구조를 바꾸거나 내용을 반복한다. 목차를 먼저 확정해야 절의 범위가 명확해진다.**
|
||||
|
||||
### STEP 3. 절 단위 본문 작성
|
||||
|
||||
확정된 목차 순서대로 1개 절씩 작성하고, 작성자 확인 후 다음 절로 이동한다. 본문에는 내부 태그를 표시하지 않고, 출처는 본문 흐름에 자연스럽게 녹인다.
|
||||
|
||||
→ **한 번에 전체를 쓰면 특정 절만 수정할 때 다른 절까지 함께 바뀌는 문제가 발생한다. 절 단위로 나누면 수정 범위가 격리된다.**
|
||||
|
||||
### STEP 4. 전체 검토 및 마무리
|
||||
|
||||
맥락 흐름, 중복, 문체 통일, 수치 일관성, 키워드 반영 여부를 체크리스트로 검토한다.
|
||||
|
||||
→ **절 단위로 쓰면 개별 절의 품질은 확보되지만, 절 간 연결과 일관성은 전체를 놓고 봐야 한다.**
|
||||
|
||||
### STEP 5. 최종 출력 — A4 HTML 보고서
|
||||
|
||||
확정된 본문을 A4 규격 HTML로 변환하여 출력한다. HTML 구조(5-B), CSS(5-C), 변환 규칙(5-D), JS 렌더링 엔진(5-E)이 프롬프트 안에 포함되어 있다.
|
||||
|
||||
→ **Markdown은 A4 용지 규격, 페이지 분할, 인쇄 레이아웃을 제어할 수 없다. HTML + CSS + JS가 A4 보고서를 브라우저에서 렌더링하고 인쇄/PDF 저장까지 가능하게 한다.**
|
||||
|
||||
---
|
||||
|
||||
## 6. 출처 태그의 이중 처리
|
||||
|
||||
| 단계 | 태그 | 이유 |
|
||||
|------|------|------|
|
||||
| STEP 1 | 표시 | 작성자가 AI의 분석 근거를 확인해야 한다 |
|
||||
| STEP 3~5 | 제거, 본문에 녹임 | 최종 보고서에 태그가 보이면 가독성이 떨어진다 |
|
||||
|
||||
태그 없이 쓰라고만 하면 AI가 출처 구분 자체를 하지 않아 추론으로 채우는 문제가 생긴다. "내부적으로는 구분하되 최종 출력에서만 제거하라"는 이중 규칙이 이를 해결한다.
|
||||
|
||||
---
|
||||
|
||||
## 7. 한계
|
||||
|
||||
- 자료가 많으면 AI의 컨텍스트 윈도우를 초과하여 전체를 한 번에 읽지 못할 수 있음
|
||||
- 절 단위 수정을 지시해도 AI가 다른 절을 함께 바꾸는 경우가 있음
|
||||
- 시각화(차트, 그래프) 생성 절차가 없어 텍스트 보고서만 출력됨
|
||||
- CSS/JS를 정확히 포함하는지, box-content 구조를 올바르게 만드는지는 AI 역량에 의존
|
||||
- 대화가 길어지면 초반에 선언한 문체나 형식을 잊는 경우가 있음
|
||||
727
02. Prompts/최종본/01-2. 단일 AI 활용 보고서 작성 프롬프트.md
Normal file
727
02. Prompts/최종본/01-2. 단일 AI 활용 보고서 작성 프롬프트.md
Normal file
@@ -0,0 +1,727 @@
|
||||
# 내부 자료 기반 분석 보고서 작성 가이드
|
||||
|
||||
> 이 프롬프트는 **(사전) 요청사항.md** 파일 및 첨부된 관련 자료와 함께 제공됩니다.
|
||||
> 프롬프트의 모든 지시는 해당 파일과 자료를 기반으로 수행하십시오.
|
||||
|
||||
---
|
||||
|
||||
## 페르소나 설정
|
||||
|
||||
**(사전) 요청사항.md**의 분야·전문성 힌트와 첨부된 자료를 읽고, 아래를 수행하십시오.
|
||||
|
||||
1. 자료의 분야를 파악하십시오.
|
||||
2. 자료의 성격을 파악하십시오.
|
||||
3. 파악된 분야와 성격에 맞는 전문가 페르소나를 선언하십시오.
|
||||
4. (사전) 요청사항에 힌트가 있으면 이를 반영하고, 없으면 자료에서 자동 파악하십시오.
|
||||
|
||||
---
|
||||
|
||||
## 보고서 성격
|
||||
|
||||
**(사전) 요청사항.md**에 기재된 목적·대상 독자·성격을 기준으로 보고서의 방향을 설정하십시오.
|
||||
|
||||
기재가 없는 경우 아래를 기본값으로 적용하십시오.
|
||||
|
||||
- 대상 : 사내 임직원
|
||||
- 성격 : 현황 문제점 분석, 주제 학습과 이해, 실무 인사이트 도출
|
||||
- 이 보고서는 특정 방향을 제시하기보다, 향후 전략 수립을 위한 전단계적 관찰과 다각적 검토의 성격을 지닙니다.
|
||||
|
||||
---
|
||||
|
||||
## 출처 및 자료 활용 원칙
|
||||
|
||||
제공된 자료의 내용을 **우선적으로** 활용하십시오.
|
||||
|
||||
**작성 과정에서의 내부 규칙 (작성자에게는 보이지 않는 처리):**
|
||||
|
||||
- 자료에 근거한 내용과 AI 자체 판단을 내부적으로 구분하며 작성하십시오.
|
||||
- 자료 간 내용이 상충할 경우 임의로 한쪽을 선택하지 말고, 양쪽 입장을 모두 정리하십시오.
|
||||
- 자료에 없는 내용을 사실인 것처럼 작성하지 마십시오.
|
||||
|
||||
**최종 보고서의 출력 규칙:**
|
||||
|
||||
- 최종 보고서 본문에는 `[자료-001]`, `[AI 판단]`, `[상충]` 같은 내부 태그를 표시하지 마십시오.
|
||||
- 출처가 필요한 경우, 본문 흐름 안에서 자연스럽게 녹이십시오.
|
||||
(예: "국토교통부 통계에 따르면 ~", "실무 현장에서는 ~로 알려져 있음")
|
||||
- 단, **STEP 1 자료 분석 보고** 단계에서는 작성자에게 출처와 쟁점을 명확히 보여주기 위해 태그를 사용하십시오.
|
||||
|
||||
**비정형 출처 기준:**
|
||||
|
||||
- SNS, 블로그, 언론자료 등은 사례 참고용으로만 사용하십시오.
|
||||
- 분석과 인사이트 도출은 신뢰할 수 있는 자료나 실무 기반 내용에서 하십시오.
|
||||
|
||||
---
|
||||
|
||||
## 문체 기준
|
||||
|
||||
기본 문체는 **보고체(간결체)**입니다. 전체 보고서에 일관 적용하십시오.
|
||||
|
||||
| 항목 | 기준 | 예시 |
|
||||
|------|------|------|
|
||||
| 문장 종결 | 명사형 또는 동사 원형 종결 | ~으로 나타남, ~임, ~필요 |
|
||||
| 문장 길이 | 1문장 2줄 이내 | 길면 두 문장으로 분리 |
|
||||
| 주어 생략 | 주어 반복 시 생략 | "분석 결과, ~로 확인됨" |
|
||||
| 수동태 | 적극 사용 | ~로 분석됨, ~으로 판단됨 |
|
||||
| 경어·구어 | **절대 사용 금지** | ~합니다, ~입니다, ~것 같다 금지 |
|
||||
| 숫자 표기 | 아라비아 숫자 | 3개, 15% |
|
||||
|
||||
---
|
||||
|
||||
## 보고서 형식
|
||||
|
||||
**계층 구조**
|
||||
|
||||
| 계층 | 표기 |
|
||||
|------|------|
|
||||
| 장 (Chapter) | 1, 2, 3 ... |
|
||||
| 절 (Section) | 1.1, 1.2, 2.1 ... |
|
||||
| 항 (Clause) | 가, 나, 다 ... |
|
||||
| 항 하위 | ▢ → ㅇ → - |
|
||||
|
||||
**문단 및 표 처리**
|
||||
|
||||
- 1개 문단은 3~5문장으로 구성하십시오.
|
||||
- 수치가 3개 이상 나열될 경우 반드시 표로 정리하십시오.
|
||||
- 표에는 출처를 본문 흐름 안에서 자연스럽게 명기하십시오.
|
||||
|
||||
---
|
||||
|
||||
## 작업 절차
|
||||
|
||||
아래 단계를 순서대로 수행하십시오.
|
||||
각 단계는 작성자의 확인 후 다음 단계로 진행합니다.
|
||||
|
||||
---
|
||||
|
||||
### [STEP 1] 자료 분석 및 페르소나 선언
|
||||
|
||||
제공된 자료와 (사전) 요청사항을 읽고 아래 형식으로 보고하십시오.
|
||||
|
||||
> 이 단계에서만 내부 태그([자료-001], [상충] 등)를 사용하여 작성자에게 명확히 보여주십시오.
|
||||
|
||||
```
|
||||
[자료 분석 완료]
|
||||
|
||||
▣ 페르소나 선언
|
||||
- 분야 :
|
||||
- 선언 : "나는 ~~ 분야의 ~~ 전문가입니다."
|
||||
|
||||
▣ 자료별 핵심 내용
|
||||
- [자료-001] : 핵심 내용
|
||||
- [자료-002] : 핵심 내용
|
||||
|
||||
▣ 식별된 문제점·쟁점
|
||||
- 문제점 1 : 내용 / 근거 자료
|
||||
- 문제점 2 : 내용 / 근거 자료
|
||||
|
||||
▣ 자료 간 상충 사항 (있는 경우만)
|
||||
- [상충] : [자료-001]의 입장 vs [자료-002]의 입장
|
||||
|
||||
▣ 보고서에 활용 가능한 수치·사례
|
||||
- 수치/사례 : 근거 자료
|
||||
```
|
||||
|
||||
보고 후 작성자의 확인을 기다리십시오.
|
||||
|
||||
---
|
||||
|
||||
### [STEP 2] 목차 설계
|
||||
|
||||
STEP 1의 분석 결과와 (사전) 요청사항의 포함 키워드·보고서 흐름을 바탕으로 목차를 설계하십시오.
|
||||
|
||||
```
|
||||
[목차 설계 기준]
|
||||
- 장(Chapter) → 절(Section) 구조로 구성하십시오.
|
||||
- 자료에서 충분히 뒷받침되는 항목만 목차에 포함하십시오.
|
||||
- (사전) 요청사항에 보고서 흐름이 지정되어 있으면 이를 반영하십시오.
|
||||
- 지정되어 있지 않으면 논리적 흐름(배경 → 현황 → 분석 → 시사점)을 기본으로 하되, 자료 성격에 따라 조정하십시오.
|
||||
```
|
||||
|
||||
목차를 제시하고 작성자의 확인을 기다리십시오.
|
||||
수정 요청 시 반영 후 재제시하십시오.
|
||||
|
||||
---
|
||||
|
||||
### [STEP 3] 절 단위 본문 작성
|
||||
|
||||
확정된 목차의 첫 번째 절부터 순서대로 본문을 작성하십시오.
|
||||
|
||||
```
|
||||
[작성 규칙]
|
||||
- 한 번에 1개 절씩만 작성하십시오.
|
||||
- 최종 보고서 본문에는 내부 태그를 표시하지 마십시오.
|
||||
- 출처는 본문 흐름 안에서 자연스럽게 녹이십시오.
|
||||
- 작성한 절을 제시하고 작성자의 확인을 기다리십시오.
|
||||
- 수정 요청 시 해당 절만 수정하십시오. 다른 절을 건드리지 마십시오.
|
||||
- 확인 완료 시 다음 절로 이동하십시오.
|
||||
```
|
||||
|
||||
모든 절 작성이 완료되면 완료를 보고하십시오.
|
||||
|
||||
---
|
||||
|
||||
### [STEP 4] 전체 검토 및 마무리
|
||||
|
||||
모든 절 작성이 완료되면 아래 항목을 검토하십시오.
|
||||
|
||||
```
|
||||
[전체 검토]
|
||||
|
||||
✅ 맥락 흐름 : 장 간 연결 자연스러움 / 어색한 부분 X건
|
||||
✅ 중복 내용 : 절 간 중복 없음 / 중복 X건
|
||||
✅ 문체 통일 : 보고체 준수 / 위반 X건
|
||||
✅ 수치 일관성 : 수치·용어 통일 / 불일치 X건
|
||||
✅ 자료 반영 : (사전) 요청사항의 키워드 전부 반영 / 미반영 X건
|
||||
|
||||
⚠️ 수정 필요 항목 (있는 경우만)
|
||||
- 해당 절 : 사유 및 수정 제안
|
||||
```
|
||||
|
||||
검토 결과를 보고하고, 작성자의 최종 확인을 기다리십시오.
|
||||
|
||||
---
|
||||
|
||||
### [STEP 5] 최종 출력 — A4 HTML 보고서
|
||||
|
||||
작성자의 최종 확인이 완료되면, 아래 HTML/CSS/JS 규격에 따라 A4 보고서 HTML 파일을 출력하십시오.
|
||||
|
||||
---
|
||||
|
||||
#### 5-A. A4 렌더링 엔진 핵심 원칙
|
||||
|
||||
출력 HTML에 포함된 JS 렌더링 엔진은 아래 원칙으로 동작합니다.
|
||||
본문 HTML은 이 원칙에 맞는 구조여야 합니다.
|
||||
|
||||
| 원칙 | 설명 |
|
||||
|------|------|
|
||||
| **Deep Sanitization** | 모든 class, style을 삭제하고 표준 스타일로 재적용. SVG 내부는 제외 |
|
||||
| **H1 Only Break** | 대목차(H1) 태그에서만 무조건 페이지를 나눔 |
|
||||
| **Orphan Control** | H2, H3가 페이지 하단에 홀로 남으면 다음 페이지로 넘김 |
|
||||
| **Smart Fit** | 표·그림이 15% 이내로 넘치면 85%까지 축소하여 현재 페이지에 배치 |
|
||||
| **Gap Filling** | 그림이 넘어가 빈 공간이 생기면 뒤 텍스트 문단을 당겨와 채움 |
|
||||
| **Visual Standard** | 여백 상하좌우 20mm, 모든 그림·표 캡션은 하단 중앙 정렬 |
|
||||
|
||||
---
|
||||
|
||||
#### 5-B. HTML 전체 구조
|
||||
|
||||
출력 HTML은 아래 구조를 정확히 따르십시오.
|
||||
`raw-container` 안의 4개 박스에 콘텐츠를 주입하면, JS가 이를 읽어 A4 페이지로 조립합니다.
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html lang="ko">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>보고서 제목</title>
|
||||
<style>
|
||||
/* === 5-C의 CSS 전문을 여기에 삽입 === */
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<!-- ① 원본 데이터 컨테이너 (화면에 표시되지 않음, JS가 읽는 원본) -->
|
||||
<div id="raw-container">
|
||||
<div id="box-cover">
|
||||
<h1>보고서 제목</h1>
|
||||
<h2>부제 (선택)</h2>
|
||||
<p>작성자 / 소속 / 작성일</p>
|
||||
</div>
|
||||
<div id="box-toc">
|
||||
<!-- 본문의 H1, H2, H3를 그대로 나열 → JS가 목차로 자동 변환 -->
|
||||
</div>
|
||||
<div id="box-summary">
|
||||
<!-- 요약 내용 (없으면 비워둠) -->
|
||||
</div>
|
||||
<div id="box-content">
|
||||
<!-- 본문 전체 (H1~H3, p, table, ul, ol 등) -->
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- ② 페이지 템플릿 (JS가 복제하여 사용) -->
|
||||
<template id="page-template">
|
||||
<div class="sheet">
|
||||
<div class="page-header"></div>
|
||||
<div class="body-content"></div>
|
||||
<div class="page-footer">
|
||||
<span class="rpt-title"></span>
|
||||
<span class="pg-num"></span>
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<!-- ③ 렌더링 엔진 JS -->
|
||||
<script>
|
||||
/* === 5-E의 JS 전문을 여기에 삽입 === */
|
||||
</script>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 5-C. CSS 전문 — A4 렌더링 스타일시트
|
||||
|
||||
아래 CSS를 `<style>` 태그 안에 그대로 포함하십시오.
|
||||
|
||||
```css
|
||||
@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@300;400;500;700;900&display=swap');
|
||||
|
||||
:root {
|
||||
--primary: #006400;
|
||||
--accent: #228B22;
|
||||
--light-green: #E8F5E9;
|
||||
--bg: #525659;
|
||||
}
|
||||
body { margin: 0; background: var(--bg); font-family: 'Noto Sans KR', sans-serif; }
|
||||
|
||||
.sheet {
|
||||
width: 210mm; height: 297mm;
|
||||
background: white; margin: 20px auto;
|
||||
position: relative; overflow: hidden; box-sizing: border-box;
|
||||
box-shadow: 0 0 15px rgba(0,0,0,0.1);
|
||||
}
|
||||
@media print {
|
||||
.sheet { margin: 0; break-after: page; box-shadow: none; }
|
||||
body { background: white; }
|
||||
}
|
||||
|
||||
.page-header {
|
||||
position: absolute; top: 10mm; left: 20mm; right: 20mm;
|
||||
font-size: 9pt; color: #000000; font-weight: bold;
|
||||
text-align: right; border-bottom: none !important; padding-bottom: 5px;
|
||||
}
|
||||
.page-footer {
|
||||
position: absolute; bottom: 10mm; left: 20mm; right: 20mm;
|
||||
display: flex; justify-content: space-between; align-items: flex-end;
|
||||
font-size: 9pt; color: #555; border-top: 1px solid #eee; padding-top: 5px;
|
||||
}
|
||||
|
||||
.body-content {
|
||||
position: absolute;
|
||||
top: 20mm; left: 20mm; right: 20mm;
|
||||
bottom: auto;
|
||||
}
|
||||
|
||||
h1, h2, h3 {
|
||||
white-space: nowrap; overflow: hidden; word-break: keep-all; color: var(--primary);
|
||||
margin: 0; padding: 0;
|
||||
}
|
||||
h1 {
|
||||
font-size: 20pt; font-weight: 900; color: var(--primary);
|
||||
border-bottom: 2px solid var(--primary); margin-bottom: 20px; margin-top: 0;
|
||||
}
|
||||
h2 {
|
||||
font-size: 18pt; border-left: 5px solid var(--accent); padding-left: 10px;
|
||||
margin-top: 30px; margin-bottom: 10px; color: #03581dff;
|
||||
}
|
||||
h3 { font-size: 14pt; margin-top: 20px; margin-bottom: 5px; color: var(--accent); font-weight: 700; }
|
||||
p, li { font-size: 12pt !important; line-height: 1.6 !important; text-align: justify; word-break: keep-all; margin-bottom: 5px; }
|
||||
|
||||
.toc-group { margin-bottom: 12px; break-inside: avoid; page-break-inside: avoid; }
|
||||
.toc-lvl-1, .toc-lvl-2, .toc-lvl-3 { list-style: none !important; }
|
||||
.toc-item { line-height: 1.8; list-style: none; border-bottom: 1px dotted #eee; }
|
||||
.toc-lvl-1 { color: #006400; font-weight: 900; font-size: 13.5pt; margin-top: 15px; margin-bottom: 5px; border-bottom: 2px solid #ccc; }
|
||||
.toc-lvl-2 { font-size: 10.5pt; color: #333; margin-left: 20px; font-weight: normal; }
|
||||
.toc-lvl-3 { font-size: 10.5pt; color: #666; margin-left: 40px; }
|
||||
.toc-lvl-1 .toc-number, .toc-lvl-1 .toc-text { font-weight: 900; font-size: 1.2em; color: #006400; }
|
||||
.toc-lvl-1 .toc-number { float: left; margin-right: 14px; }
|
||||
.toc-lvl-1 .toc-text { display: block; overflow: hidden; }
|
||||
.toc-lvl-2 .toc-number, .toc-lvl-3 .toc-number { font-weight: bold; color: #2c5282; margin-right: 11px; }
|
||||
.toc-lvl-2 .toc-text, .toc-lvl-3 .toc-text { color: #4a5568; font-size: 1em; }
|
||||
|
||||
table {
|
||||
width: 100%; border-collapse: collapse; margin: 15px 0; font-size: 9.5pt;
|
||||
table-layout: auto; border-top: 2px solid var(--primary);
|
||||
}
|
||||
th, td {
|
||||
border: 1px solid #ddd; padding: 6px 5px; text-align: center;
|
||||
vertical-align: middle; word-break: keep-all; word-wrap: break-word;
|
||||
}
|
||||
th {
|
||||
background: var(--light-green); color: var(--primary); font-weight: 900;
|
||||
white-space: nowrap; letter-spacing: -0.05em; font-size: 9pt;
|
||||
}
|
||||
|
||||
figure { display: block; margin: 20px auto; text-align: center; width: 100%; }
|
||||
img, svg { max-width: 95% !important; height: auto !important; display: block; margin: 0 auto; border: 1px solid #eee; }
|
||||
figcaption { display: block; text-align: center; margin-top: 10px; font-size: 9.5pt; color: #666; font-weight: 600; }
|
||||
|
||||
.atomic-block { break-inside: avoid; page-break-inside: avoid; }
|
||||
#raw-container { display: none; }
|
||||
|
||||
.highlight-box {
|
||||
background-color: rgb(226, 236, 226); border: 1px solid #2a2c2aff;
|
||||
padding: 5px; margin: 1.5px 1.5px 2px 0px; border-radius: 3px; color: #333;
|
||||
}
|
||||
.highlight-box li, .highlight-box p { font-size: 11pt !important; line-height: 1.2; letter-spacing: -0.6px; margin-bottom: 3px; color: #1a1919ff; }
|
||||
.highlight-box h3, .highlight-box strong, .highlight-box b { font-size: 12pt !important; color: rgba(2, 37, 2, 1) !important; font-weight: bold; margin: 0; display: block; margin-bottom: 5px; }
|
||||
|
||||
.squeeze { line-height: 1.35 !important; letter-spacing: -0.5px !important; margin-bottom: 2px !important; }
|
||||
.squeeze-title { margin-bottom: 5px !important; padding-bottom: 2px !important; }
|
||||
#box-summary p, #box-summary li { font-size: 10pt !important; line-height: 1.45 !important; letter-spacing: -0.04em !important; margin-bottom: 3px !important; text-align: justify; }
|
||||
#box-summary h1 { margin-bottom: 10px !important; padding-bottom: 5px !important; }
|
||||
|
||||
.toc-squeeze .toc-group { margin-bottom: 5px !important; }
|
||||
.toc-squeeze .toc-lvl-1 { margin-top: 8px !important; margin-bottom: 3px !important; }
|
||||
.toc-squeeze .toc-item { line-height: 1.4 !important; padding: 1px 0 !important; }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 5-D. 본문 변환 규칙
|
||||
|
||||
STEP 3에서 작성한 본문을 `box-content`에 넣을 때 아래 규칙으로 변환하십시오.
|
||||
|
||||
| 보고서 요소 | HTML 변환 |
|
||||
|------------|-----------|
|
||||
| 장 제목 (1, 2, 3...) | `<h1>1. 제목</h1>` |
|
||||
| 절 제목 (1.1, 1.2...) | `<h2>1.1 제목</h2>` |
|
||||
| 항 제목 | `<h3>제목</h3>` |
|
||||
| 본문 문단 | `<p>내용</p>` |
|
||||
| 항목 나열 | `<ul><li>항목</li></ul>` |
|
||||
| 순서 나열 | `<ol><li>항목</li></ol>` |
|
||||
| 수치 정리 | `<table>` 구조로 변환 |
|
||||
|
||||
> **주의** : `box-content` 안에는 class, style 속성을 붙이지 마십시오.
|
||||
> JS의 `detox()` 함수가 모든 class/style을 제거하고 표준 스타일로 재적용합니다.
|
||||
> 단, `highlight-box` 클래스가 필요한 강조 박스는 예외입니다.
|
||||
|
||||
---
|
||||
|
||||
#### 5-E. JS 렌더링 엔진 전문 — A4 페이지네이션
|
||||
|
||||
아래 JavaScript를 `<script>` 태그 안에 그대로 포함하십시오.
|
||||
|
||||
```javascript
|
||||
window.addEventListener("load", async () => {
|
||||
await document.fonts.ready;
|
||||
const CONFIG = { maxHeight: 970 };
|
||||
|
||||
const rawContainer = document.getElementById('raw-container');
|
||||
if (rawContainer) {
|
||||
rawContainer.innerHTML = rawContainer.innerHTML.replace(
|
||||
/(<rect[^>]*?)\s+y="[^"]*"\s+([^>]*?y="[^"]*")/gi, "$1 $2"
|
||||
);
|
||||
}
|
||||
const raw = {
|
||||
cover: document.getElementById('box-cover'),
|
||||
toc: document.getElementById('box-toc'),
|
||||
summary: document.getElementById('box-summary'),
|
||||
content: document.getElementById('box-content')
|
||||
};
|
||||
|
||||
let globalPage = 1;
|
||||
let reportTitle = raw.cover.querySelector('h1')?.innerText || "Report";
|
||||
|
||||
function detox(node) {
|
||||
if (node.nodeType !== 1) return;
|
||||
if (node.closest('svg')) return;
|
||||
let cls = "";
|
||||
if (node.hasAttribute('class')) cls = node.getAttribute('class');
|
||||
if ( (cls.includes('bg-') || cls.includes('border-') || cls.includes('box')) &&
|
||||
!cls.includes('title-box') && !cls.includes('toc-') &&
|
||||
!cls.includes('cover-') && !cls.includes('highlight-box') ) {
|
||||
node.setAttribute('class', 'highlight-box atomic-block');
|
||||
node.querySelectorAll('h3, h4, strong, b').forEach(head => { head.removeAttribute('style'); head.removeAttribute('class'); });
|
||||
node.removeAttribute('style');
|
||||
cls = 'highlight-box atomic-block';
|
||||
}
|
||||
if (node.hasAttribute('class')) {
|
||||
if (!cls.includes('toc-') && !cls.includes('cover-') && !cls.includes('highlight-') &&
|
||||
!cls.includes('title-box') && !cls.includes('atomic-block')) {
|
||||
node.removeAttribute('class');
|
||||
}
|
||||
}
|
||||
node.removeAttribute('style');
|
||||
if (node.tagName === 'TABLE') node.border = "1";
|
||||
if (node.tagName === 'FIGURE') {
|
||||
node.querySelectorAll('h3, h4, .chart-title').forEach(t => t.style.display = 'none');
|
||||
}
|
||||
}
|
||||
|
||||
function formatTOC(container) {
|
||||
const nodes = container.querySelectorAll("h1, h2, h3");
|
||||
if(nodes.length === 0) return;
|
||||
let tocHTML = "<ul style='padding-left:0; margin:0;'>";
|
||||
nodes.forEach(node => {
|
||||
let text = node.innerText.trim();
|
||||
let lvlClass = node.tagName === "H1" ? "toc-lvl-1" : (node.tagName === "H2" ? "toc-lvl-2" : "toc-lvl-3");
|
||||
let num = "", title = text;
|
||||
const match = text.match(/^(\d+(\.\d+)*)\s+(.*)/);
|
||||
if (match) { num = match[1]; title = match[3]; }
|
||||
tocHTML += `<li class='toc-item ${lvlClass}'><span class='toc-number'>${num}</span><span class='toc-text'>${title}</span></li>`;
|
||||
});
|
||||
tocHTML += "</ul>";
|
||||
container.innerHTML = tocHTML;
|
||||
}
|
||||
|
||||
function getFlatNodes(element) {
|
||||
if(element.id === 'box-toc') {
|
||||
element.querySelectorAll('*').forEach(el => detox(el));
|
||||
formatTOC(element);
|
||||
const tocNodes = [];
|
||||
let title = element.querySelector('h1');
|
||||
if (!title) { title = document.createElement('h1'); title.innerText = "목차"; }
|
||||
tocNodes.push(title.cloneNode(true));
|
||||
const allLis = element.querySelectorAll('li');
|
||||
let currentGroup = null;
|
||||
allLis.forEach(li => {
|
||||
if (li.classList.contains('toc-lvl-1')) {
|
||||
if (currentGroup) tocNodes.push(currentGroup);
|
||||
currentGroup = document.createElement('div');
|
||||
currentGroup.className = 'toc-group atomic-block';
|
||||
const ul = document.createElement('ul');
|
||||
ul.style.margin = "0"; ul.style.padding = "0";
|
||||
currentGroup.appendChild(ul);
|
||||
}
|
||||
if (!currentGroup) {
|
||||
currentGroup = document.createElement('div');
|
||||
currentGroup.className = 'toc-group atomic-block';
|
||||
const ul = document.createElement('ul');
|
||||
ul.style.margin = "0"; ul.style.padding = "0";
|
||||
currentGroup.appendChild(ul);
|
||||
}
|
||||
currentGroup.querySelector('ul').appendChild(li.cloneNode(true));
|
||||
});
|
||||
if (currentGroup) tocNodes.push(currentGroup);
|
||||
return tocNodes;
|
||||
}
|
||||
let nodes = [];
|
||||
Array.from(element.children).forEach(child => {
|
||||
detox(child);
|
||||
if (child.classList.contains('highlight-box')) {
|
||||
child.querySelectorAll('h3, h4, strong, b').forEach(head => { head.removeAttribute('style'); head.removeAttribute('class'); });
|
||||
nodes.push(child.cloneNode(true));
|
||||
}
|
||||
else if(['DIV','SECTION','ARTICLE','MAIN'].includes(child.tagName)) { nodes = nodes.concat(getFlatNodes(child)); }
|
||||
else if (['UL','OL'].includes(child.tagName)) {
|
||||
Array.from(child.children).forEach((li, idx) => {
|
||||
detox(li);
|
||||
const w = document.createElement(child.tagName);
|
||||
w.style.margin="0"; w.style.paddingLeft="20px";
|
||||
if(child.tagName==='OL') w.start=idx+1;
|
||||
const cloneLi = li.cloneNode(true);
|
||||
cloneLi.querySelectorAll('*').forEach(el => detox(el));
|
||||
w.appendChild(cloneLi);
|
||||
nodes.push(w);
|
||||
});
|
||||
} else {
|
||||
const clone = child.cloneNode(true);
|
||||
detox(clone);
|
||||
clone.querySelectorAll('*').forEach(el => detox(el));
|
||||
nodes.push(clone);
|
||||
}
|
||||
});
|
||||
return nodes;
|
||||
}
|
||||
|
||||
function renderFlow(sectionType, sourceNodes) {
|
||||
if (!sourceNodes.length) return;
|
||||
let currentHeaderTitle = sectionType === 'toc' ? "목차" : (sectionType === 'summary' ? "요약" : reportTitle);
|
||||
let page = createPage(sectionType, currentHeaderTitle);
|
||||
let body = page.querySelector('.body-content');
|
||||
let queue = [...sourceNodes];
|
||||
while (queue.length > 0) {
|
||||
let node = queue.shift();
|
||||
let clone = node.cloneNode(true);
|
||||
let isH1 = clone.tagName === 'H1';
|
||||
let isHeading = ['H2', 'H3'].includes(clone.tagName);
|
||||
let isText = ['P', 'LI'].includes(clone.tagName) && !clone.classList.contains('atomic-block');
|
||||
let isAtomic = ['TABLE', 'FIGURE', 'IMG', 'SVG'].includes(clone.tagName) ||
|
||||
clone.querySelector('table, img, svg') || clone.classList.contains('atomic-block');
|
||||
if (isH1 && clone.innerText.includes('-')) { clone.innerText = clone.innerText.split('-')[0].trim(); }
|
||||
if (isH1 && (sectionType === 'body' || sectionType === 'summary')) {
|
||||
currentHeaderTitle = clone.innerText;
|
||||
if (body.children.length > 0) { page = createPage(sectionType, currentHeaderTitle); body = page.querySelector('.body-content'); }
|
||||
else { page.querySelector('.page-header').innerText = currentHeaderTitle; }
|
||||
}
|
||||
if (isHeading) {
|
||||
const spaceLeft = CONFIG.maxHeight - body.scrollHeight;
|
||||
if (spaceLeft < 160) { page = createPage(sectionType, currentHeaderTitle); body = page.querySelector('.body-content'); }
|
||||
}
|
||||
body.appendChild(clone);
|
||||
if (isText && clone.innerText.length > 10) {
|
||||
const originalHeight = clone.offsetHeight;
|
||||
clone.style.letterSpacing = "-1.0px";
|
||||
if (clone.offsetHeight < originalHeight) { clone.style.letterSpacing = "-0.8px"; }
|
||||
else { clone.style.letterSpacing = ""; }
|
||||
}
|
||||
if (body.scrollHeight > CONFIG.maxHeight) {
|
||||
if (sectionType === 'toc' && !body.classList.contains('toc-squeeze') && body.children.length > 0) {
|
||||
body.classList.add('toc-squeeze');
|
||||
if (body.scrollHeight <= CONFIG.maxHeight) continue;
|
||||
else { body.classList.remove('toc-squeeze'); body.removeChild(clone); }
|
||||
}
|
||||
if (isText) {
|
||||
body.removeChild(clone);
|
||||
let textContent = node.innerText;
|
||||
let tempP = node.cloneNode(false); tempP.innerText = "";
|
||||
if (clone.style.letterSpacing) tempP.style.letterSpacing = clone.style.letterSpacing;
|
||||
body.appendChild(tempP);
|
||||
const words = textContent.split(' ');
|
||||
let currentText = "";
|
||||
for (let i = 0; i < words.length; i++) {
|
||||
let prevText = currentText;
|
||||
currentText += (currentText ? " " : "") + words[i];
|
||||
tempP.innerText = currentText;
|
||||
if (body.scrollHeight > CONFIG.maxHeight) {
|
||||
tempP.innerText = prevText;
|
||||
tempP.style.textAlign = "justify"; tempP.style.textAlignLast = "justify";
|
||||
let remainingNode = node.cloneNode(false);
|
||||
remainingNode.innerText = words.slice(i).join(' ');
|
||||
queue.unshift(remainingNode);
|
||||
page = createPage(sectionType, currentHeaderTitle);
|
||||
body = page.querySelector('.body-content');
|
||||
break;
|
||||
}
|
||||
}
|
||||
} else {
|
||||
body.removeChild(clone);
|
||||
let spaceLeft = CONFIG.maxHeight - body.scrollHeight;
|
||||
if (body.children.length > 0 && spaceLeft > 50 && queue.length > 0) {
|
||||
while(queue.length > 0) {
|
||||
let candidate = queue[0];
|
||||
if (['H1','H2','H3'].includes(candidate.tagName) ||
|
||||
candidate.classList.contains('atomic-block') || candidate.querySelector('img, table')) break;
|
||||
let filler = candidate.cloneNode(true);
|
||||
if(['P','LI'].includes(filler.tagName) && filler.innerText.length > 10) filler.style.letterSpacing = "-1.0px";
|
||||
body.appendChild(filler);
|
||||
if (body.scrollHeight <= CONFIG.maxHeight) {
|
||||
if(filler.style.letterSpacing === "-1.0px") filler.style.letterSpacing = "-0.8px";
|
||||
queue.shift();
|
||||
} else { body.removeChild(filler); break; }
|
||||
}
|
||||
}
|
||||
if (body.children.length > 0) { page = createPage(sectionType, currentHeaderTitle); body = page.querySelector('.body-content'); }
|
||||
body.appendChild(clone);
|
||||
if (isAtomic && body.scrollHeight > CONFIG.maxHeight) {
|
||||
const currentH = clone.offsetHeight;
|
||||
const overflow = body.scrollHeight - CONFIG.maxHeight;
|
||||
body.removeChild(clone);
|
||||
if (overflow > 0 && overflow < (currentH * 0.15)) {
|
||||
clone.style.transform = "scale(0.85)"; clone.style.transformOrigin = "top center";
|
||||
clone.style.marginBottom = `-${currentH * 0.15}px`;
|
||||
body.appendChild(clone);
|
||||
} else { body.appendChild(clone); }
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function createPage(type, headerTitle) {
|
||||
const tpl = document.getElementById('page-template');
|
||||
const clone = tpl.content.cloneNode(true);
|
||||
const sheet = clone.querySelector('.sheet');
|
||||
if (type === 'cover') {
|
||||
sheet.innerHTML = "";
|
||||
const title = raw.cover.querySelector('h1')?.innerText || "Report";
|
||||
const sub = raw.cover.querySelector('h2')?.innerText || "";
|
||||
const pTags = raw.cover.querySelectorAll('p');
|
||||
const infos = pTags.length > 0 ? Array.from(pTags).map(p => p.innerText).join(" / ") : "";
|
||||
sheet.innerHTML = `
|
||||
<div style="position:absolute; top:20mm; right:20mm; text-align:right; font-size:11pt; color:#666;">${infos}</div>
|
||||
<div style="display:flex; flex-direction:column; justify-content:center; align-items:center; height:100%; text-align:center; width:100%;">
|
||||
<div style="width:85%;">
|
||||
<div style="font-size:32pt; font-weight:900; color:var(--primary); line-height:1.2; margin-bottom:30px; word-break:keep-all;">${title}</div>
|
||||
<div style="font-size:20pt; font-weight:300; color:#444; word-break:keep-all;">${sub}</div>
|
||||
</div>
|
||||
</div>`;
|
||||
} else {
|
||||
clone.querySelector('.page-header').innerText = headerTitle;
|
||||
clone.querySelector('.rpt-title').innerText = reportTitle;
|
||||
if (type !== 'toc') clone.querySelector('.pg-num').innerText = `- ${globalPage++} -`;
|
||||
else clone.querySelector('.pg-num').innerText = "";
|
||||
}
|
||||
document.body.appendChild(sheet);
|
||||
return sheet;
|
||||
}
|
||||
|
||||
createPage('cover');
|
||||
if(raw.toc) renderFlow('toc', getFlatNodes(raw.toc));
|
||||
|
||||
const summaryNodes = getFlatNodes(raw.summary);
|
||||
const tempBox = document.createElement('div');
|
||||
tempBox.style.width = "210mm"; tempBox.style.position = "absolute"; tempBox.style.visibility = "hidden";
|
||||
tempBox.id = 'box-summary';
|
||||
document.body.appendChild(tempBox);
|
||||
summaryNodes.forEach(node => tempBox.appendChild(node.cloneNode(true)));
|
||||
const totalHeight = tempBox.scrollHeight;
|
||||
const pageHeight = CONFIG.maxHeight;
|
||||
const lastPart = totalHeight % pageHeight;
|
||||
if (totalHeight > pageHeight && lastPart > 0 && lastPart < 180) {
|
||||
summaryNodes.forEach(node => {
|
||||
if(node.nodeType === 1) {
|
||||
node.classList.add('squeeze');
|
||||
if(node.tagName === 'H1') node.classList.add('squeeze-title');
|
||||
if(node.tagName === 'P' || node.tagName === 'LI') {
|
||||
node.style.fontSize = "9.5pt"; node.style.lineHeight = "1.4"; node.style.letterSpacing = "-0.8px";
|
||||
}
|
||||
}
|
||||
});
|
||||
}
|
||||
document.body.removeChild(tempBox);
|
||||
renderFlow('summary', summaryNodes);
|
||||
renderFlow('body', getFlatNodes(raw.content));
|
||||
|
||||
document.querySelectorAll('.sheet h1, .sheet h2').forEach(el => {
|
||||
let fs = 100;
|
||||
while(el.scrollWidth > el.clientWidth && fs > 50) { el.style.fontSize = (--fs)+"%"; }
|
||||
});
|
||||
|
||||
const allTextNodes = document.querySelectorAll('.sheet .body-content p, .sheet .body-content li');
|
||||
allTextNodes.forEach(el => {
|
||||
if (el.closest('table') || el.closest('figure') || el.closest('.chart')) return;
|
||||
if (el.innerText.trim().length < 10) return;
|
||||
const originH = el.offsetHeight;
|
||||
const originSpacing = el.style.letterSpacing;
|
||||
el.style.fontSize = "12pt"; el.style.letterSpacing = "-1.4px";
|
||||
const newH = el.offsetHeight;
|
||||
if (newH < originH) { el.style.letterSpacing = "-1.0px"; }
|
||||
else { el.style.letterSpacing = originSpacing; }
|
||||
});
|
||||
|
||||
document.querySelectorAll('.sheet h1, .sheet h2').forEach(el => {
|
||||
let fs = 100;
|
||||
while(el.scrollWidth > el.clientWidth && fs > 50) { el.style.fontSize = (--fs)+"%"; }
|
||||
});
|
||||
|
||||
const pages = document.querySelectorAll('.sheet');
|
||||
if (pages.length >= 2) {
|
||||
const lastSheet = pages[pages.length - 1];
|
||||
const prevSheet = pages[pages.length - 2];
|
||||
if(lastSheet.querySelector('.rpt-title')) {
|
||||
const lastBody = lastSheet.querySelector('.body-content');
|
||||
const prevBody = prevSheet.querySelector('.body-content');
|
||||
if (lastBody.scrollHeight < 150 && lastBody.innerText.trim().length > 0) {
|
||||
prevBody.style.lineHeight = "1.3"; prevBody.style.paddingBottom = "0px";
|
||||
const contentToMove = Array.from(lastBody.children);
|
||||
contentToMove.forEach(child => prevBody.appendChild(child.cloneNode(true)));
|
||||
if (prevBody.scrollHeight <= CONFIG.maxHeight + 5) { lastSheet.remove(); }
|
||||
else { for(let i=0; i<contentToMove.length; i++) prevBody.lastElementChild.remove(); prevBody.style.lineHeight = ""; }
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
const rawToRemove = document.getElementById('raw-container');
|
||||
if(rawToRemove) rawToRemove.remove();
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 5-F. 출력 규칙 요약
|
||||
|
||||
```
|
||||
[출력 규칙]
|
||||
- STEP 3에서 확정된 절들을 5-D 변환 규칙에 따라 HTML로 변환하여 box-content에 넣으십시오.
|
||||
- 수정 확인 과정에서 변경된 내용이 있으면 최종본을 반영하십시오.
|
||||
- 내부 태그([자료-001], [AI 판단], [상충])는 본문에 포함하지 마십시오.
|
||||
- 출처는 본문 흐름 안에서 자연스럽게 녹이십시오.
|
||||
- 보고서 말미에 "참고 자료" 절을 두어, 활용한 자료 목록을 정리하십시오.
|
||||
- CSS(5-C)와 JS(5-E)를 그대로 포함하십시오. 수정하지 마십시오.
|
||||
- box-content 안에는 class, style 속성을 붙이지 마십시오. (highlight-box 예외)
|
||||
- 이 HTML을 브라우저에서 열면 A4 보고서가 자동 렌더링됩니다.
|
||||
```
|
||||
97
02. Prompts/최종본/01. (사전) 작성자 기재사항.md
Normal file
97
02. Prompts/최종본/01. (사전) 작성자 기재사항.md
Normal file
@@ -0,0 +1,97 @@
|
||||
# (사전) 요청사항
|
||||
|
||||
> 이 파일을 작성하여 프롬프트 및 관련 자료와 함께 AI에게 제공하십시오.
|
||||
|
||||
---
|
||||
|
||||
## 보고서 제목
|
||||
|
||||
```
|
||||
(예: 한국 토목 인프라 산업에서의 AutoCAD 독점 구조와 시사점)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 보고서 목적
|
||||
|
||||
```
|
||||
(예: AutoCAD 독점 현황의 문제점을 파악하고, 토목 S/W 시장의 구조적 개선 방향에 대한 인사이트를 도출)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 대상 독자
|
||||
|
||||
```
|
||||
(예: 사내 임직원 / 경영진 / 기술팀 등)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 보고서 성격
|
||||
|
||||
```
|
||||
아래 중 해당하는 항목을 선택하거나, 직접 기재하십시오.
|
||||
|
||||
- [ ] 현황에 대한 문제점 분석
|
||||
- [ ] 주제에 대한 학습과 이해
|
||||
- [ ] 실무 관점의 인사이트 도출
|
||||
- [ ] 의사결정을 위한 검토 자료
|
||||
- [ ] 기타 :
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 분야 및 페르소나 힌트
|
||||
|
||||
```
|
||||
AI가 자료를 읽고 페르소나를 스스로 파악하되, 아래에 힌트를 제공할 수 있습니다.
|
||||
비워두면 AI가 자료에서 자동 파악합니다.
|
||||
|
||||
- 분야 : (예: 토목공학, 건설 IT, 환경 정책 등)
|
||||
- 전문성 : (예: 산업 분석, 기술 검토, 정책 비교 등)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 포함 키워드
|
||||
|
||||
```
|
||||
보고서에 반드시 포함되어야 할 키워드나 주제를 나열하십시오.
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 보고서 흐름 (선택)
|
||||
|
||||
```
|
||||
보고서의 흐름을 직접 지정하고 싶은 경우 기재하십시오.
|
||||
비워두면 AI가 자료 분석 결과를 바탕으로 설계합니다.
|
||||
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
4.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 제공 자료 목록
|
||||
|
||||
```
|
||||
- [자료-001] 파일명 : 내용 설명
|
||||
- [자료-002] 파일명 : 내용 설명
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 추가 지시 (선택)
|
||||
|
||||
```
|
||||
AI에게 별도로 전달할 사항이 있으면 기재하십시오.
|
||||
(예: "3장은 해외 사례 중심으로", "표는 최소화해줘" 등)
|
||||
```
|
||||
12
02. Prompts/최종본/02-1. 내부 자료 정리_NotebookLM (1).md
Normal file
12
02. Prompts/최종본/02-1. 내부 자료 정리_NotebookLM (1).md
Normal file
@@ -0,0 +1,12 @@
|
||||
# (사전) 관련 내부 자료들의 업로드
|
||||
|
||||
```
|
||||
업로드 내용을 바탕으로 주요 핵심 내용들과 키워드를 중심으로 정리해주세요.
|
||||
|
||||
정리시에 꼭 포함되어야 하는 사항은 다음과 같습니다.
|
||||
- AutoCAD의 토목 엔지니어링 독점 현황
|
||||
- 이로 인한 국내 토목시장의 문제
|
||||
- 발생하는 문제점
|
||||
- 대안
|
||||
- 시사점
|
||||
```
|
||||
86
02. Prompts/최종본/02-2. 보고서 내용 생성_Skywork (1).md
Normal file
86
02. Prompts/최종본/02-2. 보고서 내용 생성_Skywork (1).md
Normal file
@@ -0,0 +1,86 @@
|
||||
# (사전) NotebookLM 요약 결과 업로드 후 아래 프롬프트 실행
|
||||
|
||||
## 역할 정의
|
||||
|
||||
```
|
||||
당신은 토목공학 및 인프라 기술 응용 분야에 전문성을 지닌 산업 분석가입니다.
|
||||
당신의 임무는 한국 인프라 건설 산업, 특히 토목 분야에서 AutoCAD의 사용 실태와
|
||||
구조적 문제에 대해 포괄적이고 통찰력 있는 분석을 제공하는 것입니다.
|
||||
이 분석은 기업 임원들을 위한 것이므로, 실질적이며 사례 기반의 인사이트에 중점을 두어야 합니다.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 지시 사항
|
||||
|
||||
```
|
||||
먼저, 한국 인프라 산업(특히 토목 분야) 내 AutoCAD 사용의 현황을 개괄하십시오.
|
||||
|
||||
AutoCAD의 시장 지배력의 원인을 분석하되, 기술적 우수성과 관행적 의존을 모두 고려하십시오.
|
||||
|
||||
한국의 토목 기술자들이 직면한 문제, 특히 AutoCAD 사용과 관련된 어려움을 조사하십시오.
|
||||
|
||||
3D BIM 기술로의 전환 상황과 Civil 3D, Revit 등 Autodesk 제품들의 역할을 평가하십시오.
|
||||
|
||||
AutoCAD 및 기타 Autodesk 제품에 대한 사용자 경험과 실질적인 불편함을 수집하십시오.
|
||||
|
||||
최근 데이터와 신뢰할 수 있는 자료를 활용하여 분석을 뒷받침하십시오.
|
||||
|
||||
사례 연구를 포함하여 실질적인 인사이트를 제공하십시오.
|
||||
|
||||
그래프나 도표 등의 시각 자료를 활용하여 명확성과 이해도를 높이십시오.
|
||||
|
||||
분석의 전반적인 어조는 전문적이고 포괄적이어야 하며, 다각적인 시각에서 접근하십시오.
|
||||
|
||||
특정 제품 개발 방향은 제시하지 마십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 보고서 구조 지정
|
||||
|
||||
```
|
||||
보고서는 단순 연구보고서가 아니므로 일반적인 연구 개요 사항은 포함하지 마십시오.
|
||||
|
||||
보고서의 흐름은 아래 순서를 따르십시오.
|
||||
|
||||
1. 토목 S/W 시장에 대한 구조를 바탕으로 AutoCAD 독점의 배경과 문제
|
||||
2. 이러한 독점이 과연 관행인지, 아니면 기능적 수요에 의한 것인지
|
||||
3. 그렇다면 AutoCAD는 토목 인프라건설 산업 분야에서 적합한 것인지
|
||||
4. 적합하지 않다면 어떠한 기능들과 요구사항들이 포함되어야 하는 것인지
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 출처 및 성격 기준
|
||||
|
||||
```
|
||||
사례와 수치를 기반으로 하십시오.
|
||||
|
||||
SNS, 블로그, 언론자료 등 비정형 출처는 사례 참고용으로만 사용하되,
|
||||
분석과 인사이트 도출은 반드시 신뢰할 수 있는 자료나 실무 기반의 내용을 바탕으로 구성하십시오.
|
||||
|
||||
이 보고서는 특정 방향을 제시하기보다는,
|
||||
향후 전략 수립을 위한 전단계적 관찰과 다각적 검토의 성격을 지닙니다.
|
||||
정형화되지 않은 의견도 구조적으로 정리하십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 응답 스타일
|
||||
|
||||
```
|
||||
귀하의 응답은 전문적이고 포괄적이며 분석적이어야 하며, 기업 임원들이 읽기에 적합해야 합니다.
|
||||
특정 제품 개발 방향은 제시하지 않고, 균형 잡힌 관점을 제시하십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 리마인더
|
||||
|
||||
```
|
||||
실질적이고 사례 기반의 인사이트에 집중하십시오.
|
||||
최근 1~2년 이내의 데이터와 신뢰할 수 있는 출처를 활용하십시오.
|
||||
전문적인 어조를 유지하고, 다각적 분석을 제공하십시오.
|
||||
특정 제품 개발 방향은 제시하지 마십시오.
|
||||
```
|
||||
36
02. Prompts/최종본/02-3. 문체 보완 및 구조화_Gemini (1).md
Normal file
36
02. Prompts/최종본/02-3. 문체 보완 및 구조화_Gemini (1).md
Normal file
@@ -0,0 +1,36 @@
|
||||
# (사전) skywork 보고서 결과물 업로드
|
||||
|
||||
|
||||
## 역할 정의
|
||||
|
||||
```
|
||||
당신은 보고서 편집 전문가입니다.
|
||||
제공된 보고서의 내용을 수정하지 않고, 문체를 다듬고 구조적 마무리를 수행하는 것이 임무입니다.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 절대 원칙
|
||||
|
||||
```
|
||||
본문의 내용, 수치, 사례, 출처를 변경하지 마십시오.
|
||||
문장을 삭제하거나 새로운 내용을 추가하지 마십시오.
|
||||
문체와 구조 정리만 수행하십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 지시 사항
|
||||
|
||||
```
|
||||
제공된 보고서 내용을 그대로 유지한 상태에서 아래 두 가지를 수행하십시오.
|
||||
|
||||
1. 문체 보완
|
||||
- 전체 문체를 부드럽게 다듬으십시오.
|
||||
- 딱딱하거나 나열식인 문장을 자연스러운 흐름으로 연결하십시오.
|
||||
- 내용 자체는 바꾸지 마십시오.
|
||||
|
||||
2. 구조화 마무리
|
||||
- 각 문단의 마지막에 해당 문단의 핵심 사항을 구조화하여 정리하십시오.
|
||||
- 본문 흐름을 해치지 않는 범위에서 요약·정리 항목을 추가하십시오.
|
||||
```
|
||||
78
02. Prompts/최종본/02. AI 활용 보고서 작성(3step) _ (개요) 내용 요약.md
Normal file
78
02. Prompts/최종본/02. AI 활용 보고서 작성(3step) _ (개요) 내용 요약.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# AI 기반 문서 생성 — 프롬프트 모음
|
||||
|
||||
## 개요
|
||||
|
||||
내부 자료를 바탕으로 주제에 대한 분석 보고서를 생성하기 위한 AI 프롬프트 모음입니다.
|
||||
NotebookLM으로 자료를 정리하고, Skywork으로 보고서를 생성하고, Gemini로 문체를 다듬는 3단계 흐름입니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 프로세스
|
||||
|
||||
```
|
||||
내부 자료 (PDF, PPT, DOCX 등)
|
||||
↓
|
||||
[00-1] NotebookLM → 내부 자료 핵심 내용 정리
|
||||
↓
|
||||
[00-2] Skywork → 산업 분석 보고서 생성
|
||||
↓
|
||||
[00-3] Gemini → 문체 보완 및 구조화 마무리
|
||||
↓
|
||||
최종 보고서 완성
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 단계별 프롬프트
|
||||
|
||||
---
|
||||
|
||||
### 00-1. 내부 자료 핵심 내용 정리
|
||||
`사용 AI : NotebookLM`
|
||||
|
||||
내부 자료를 NotebookLM에 업로드하고, 주제와 관련된 핵심 내용을 정리합니다.
|
||||
NotebookLM은 업로드된 소스에서만 답변하므로, 정리 범위(독점 현황, 문제점, 대안, 시사점)만 지정합니다.
|
||||
|
||||
---
|
||||
|
||||
### 00-2. 주제 기반 산업 분석 보고서 생성
|
||||
`사용 AI : Skywork`
|
||||
|
||||
산업 분석가 역할을 부여하고, 주제에 대한 분석 보고서를 생성합니다.
|
||||
보고서 흐름(독점 배경 → 관행 vs 수요 → 적합성 → 요구사항)을 직접 지정하며,
|
||||
출처 신뢰도 기준과 보고서 성격(전단계적 관찰, 다각적 검토)을 명시합니다.
|
||||
|
||||
---
|
||||
|
||||
### 00-3. 문체 보완 및 구조화 마무리
|
||||
`사용 AI : Gemini`
|
||||
|
||||
Skywork이 생성한 보고서의 내용을 그대로 유지한 채, 문체를 부드럽게 다듬고
|
||||
각 문단 말미에 핵심 사항을 구조화하여 정리합니다.
|
||||
|
||||
---
|
||||
|
||||
## 한계 및 아쉬운 점
|
||||
|
||||
**Skywork의 자율성이 너무 크다** : 보고서를 잘 쓰지만 프롬프트의 지시를 넘어서 자체적으로 구조를 재편하거나 내용을 확장하는 경향이 있습니다. 작성자가 의도한 범위를 벗어나는 결과물이 자주 나옵니다.
|
||||
|
||||
**Skywork의 부분 수정이 어렵다** : 특정 문단만 수정을 요청하면 해당 부분만 고치는 것이 아니라 전체 보고서를 재생성합니다. 이미 확정한 다른 부분까지 변경되어 수정 작업이 반복됩니다.
|
||||
|
||||
**NotebookLM의 정리 내용이 Skywork에 제대로 반영되지 않는다** : NotebookLM에서 정리한 핵심 내용을 Skywork에 전달해도, Skywork이 자체 지식을 우선하여 정리 사항이 누락되거나 희석됩니다.
|
||||
|
||||
**Gemini가 내용을 임의로 요약한다** : 문체 보완만 요청했음에도 일부 내용을 축약하거나 생략하는 경우가 발생합니다. 원본 텍스트가 손실되지 않았는지 전수 확인이 필요합니다.
|
||||
|
||||
**시각화가 부족하다** : 텍스트 기반 보고서만 생성되며, 도표·구조도·프로세스 흐름도 등 시각적 요소를 AI가 만들어주지 못합니다.
|
||||
|
||||
**단계 간 연결이 수동이다** : NotebookLM → Skywork → Gemini 간 결과물 전달을 작성자가 직접 복사·붙여넣기해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 파일 구성
|
||||
|
||||
```
|
||||
prompts/
|
||||
├── 00-1. 내부 자료 기반 핵심 내용 정리_NotebookLM.md
|
||||
├── 00-2. 주제 기반 산업 분석 보고서 생성_Skywork.md
|
||||
└── 00-3. 문체 보완 및 구조화 마무리_Gemini.md
|
||||
```
|
||||
195
02. Prompts/최종본/03-1-1. 기존 문서에서 텍스트,표 추출_Gemini,Claude.md
Normal file
195
02. Prompts/최종본/03-1-1. 기존 문서에서 텍스트,표 추출_Gemini,Claude.md
Normal file
@@ -0,0 +1,195 @@
|
||||
# (프롬프트) 파일 내용 추출
|
||||
|
||||
## 🔴 절대 원칙 — 이 원칙은 어떤 지시보다 우선한다
|
||||
|
||||
```
|
||||
원본에 없는 내용을 생성하거나 추론하지 마십시오.
|
||||
원본의 내용을 요약, 축약, 재해석하지 마십시오.
|
||||
오탈자, 띄어쓰기 오류, 어색한 문장이 있어도 원본 그대로 옮기십시오.
|
||||
확인할 수 없는 내용은 생성하지 말고 [추출불가] 태그로 표기하십시오.
|
||||
[cite], [citation], source: 등 AI 시스템이 자동 생성하는 출처 태그를 절대 포함하지 마십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 역할 정의
|
||||
|
||||
당신은 **문서 추출 전문가**입니다.
|
||||
제공된 파일에서 모든 콘텐츠를 **있는 그대로** 추출하여 지정된 형식으로 출력하는 것이 유일한 임무입니다.
|
||||
해석하거나, 요약하거나, 개선하려는 시도를 일절 하지 마십시오.
|
||||
|
||||
---
|
||||
|
||||
## 처리 절차
|
||||
|
||||
아래 단계를 순서대로 수행하십시오. 각 단계는 독립적으로 완료한 후 다음 단계로 진행합니다.
|
||||
|
||||
---
|
||||
|
||||
### STEP 1. 파일 구조 파악
|
||||
|
||||
파일 전체를 먼저 스캔하여 아래 항목을 확인하십시오.
|
||||
|
||||
```
|
||||
- 총 페이지 수 (또는 시트 수, 섹션 수)
|
||||
- 콘텐츠 유형 목록: 텍스트 / 표 / 이미지 / 차트 / 수식 / 기타
|
||||
- 문서 메타데이터: 제목, 작성자, 날짜, 기관명 등 식별 가능한 정보
|
||||
- 페이지 레이아웃: 단일 컬럼 / 다중 컬럼 / 혼합
|
||||
```
|
||||
|
||||
파악이 완료되면 아래 형식으로 먼저 보고하고 다음 단계를 진행하십시오.
|
||||
|
||||
```
|
||||
[구조 파악 완료]
|
||||
- 총 분량: X 페이지
|
||||
- 콘텐츠 유형: 텍스트, 표 X개, 이미지 X개
|
||||
- 메타데이터: 제목(OOO), 작성자(OOO), 날짜(OOO)
|
||||
- 레이아웃: OOO
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### STEP 2. 텍스트 추출 → MD 파일 출력
|
||||
|
||||
**문서의 맨 첫 줄부터 맨 마지막 줄까지 위에서 아래로(Top-to-Bottom) 순서대로 읽으십시오.**
|
||||
표만 찾거나, 이미지만 찾거나, 특정 요소만 선별 추출하지 마십시오.
|
||||
제목 → 개요 → 본문 → 표 → 캡션 → 결론의 원본 흐름을 그대로 유지하십시오.
|
||||
|
||||
아래 규칙에 따라 전체 텍스트를 추출하여 마크다운(.md) 형식으로 출력하십시오.
|
||||
|
||||
#### 2-1. 계층 구조 변환 규칙
|
||||
|
||||
| 원본 요소 | MD 변환 |
|
||||
|---------|--------|
|
||||
| 문서 제목 | `# 제목` |
|
||||
| 대목차 / 장 | `## 제목` |
|
||||
| 중목차 / 절 | `### 제목` |
|
||||
| 소목차 / 항 | `#### 제목` |
|
||||
| 본문 단락 | 빈 줄로 구분된 일반 텍스트 |
|
||||
| 번호 목록 | `1. 항목` |
|
||||
| 기호 목록 | `- 항목` |
|
||||
| 강조 (볼드) | `**텍스트**` |
|
||||
| 페이지 구분 | `---` + `<!-- page X -->` 주석 |
|
||||
|
||||
#### 2-2. 표 추출 규칙 — Visual Grid Rule
|
||||
|
||||
**"선(Line)이 법이다"**: 표의 내용이나 논리를 판단하지 말고, 오직 선이 막혀있는지 뚫려있는지만 보고 셀 병합을 결정하십시오.
|
||||
|
||||
**가로 병합 (colspan)**
|
||||
같은 행 내에서 인접한 셀 사이에 세로줄이 없다면 무조건 하나로 합치십시오.
|
||||
상위 셀 아래에 N개의 하위 열이 있다면 반드시 `colspan="N"`을 적용하십시오.
|
||||
|
||||
**세로 병합 (rowspan)**
|
||||
좌측 열에서 아래 행 사이에 가로줄이 없다면, 데이터가 달라도 무조건 하나로 합치십시오.
|
||||
특정 그룹이 시각적으로 N개 행을 포함하고 그 사이에 가로선이 없다면 `rowspan="N"`으로 묶으십시오.
|
||||
|
||||
MD는 colspan/rowspan을 직접 표현할 수 없으므로, 병합이 있는 표는 아래와 같이 처리하십시오.
|
||||
- 표 앞에 `[병합표]` 태그를 표기하십시오.
|
||||
- 병합된 셀 위치에 `[↑병합]` (세로) 또는 `[←병합]` (가로) 태그로 명시하십시오.
|
||||
- 표 뒤 JSON에서 정확한 colspan/rowspan 값을 기록하십시오.
|
||||
|
||||
표 앞에는 반드시 `[표 X] p.페이지 — 표 제목`을 기재하십시오.
|
||||
|
||||
```
|
||||
[표 1] p.1 — 샘플링 제어 설정 비교
|
||||
|
||||
| 설정 항목 | 설명 | 특징/효과 |
|
||||
|---------|-----|---------|
|
||||
| 온도 | 내용 | 내용 |
|
||||
```
|
||||
|
||||
#### 2-3. 헤더/푸터 처리
|
||||
|
||||
- 반복되는 헤더/푸터(기관명, 페이지 번호 등)는 본문에 삽입하지 않고 별도로 처리하십시오.
|
||||
- MD 파일 최상단 메타데이터 블록에 한 번만 기재하십시오.
|
||||
|
||||
```markdown
|
||||
---
|
||||
title: "문서 제목"
|
||||
author: "작성자"
|
||||
date: "날짜"
|
||||
organization: "기관명"
|
||||
total_pages: X
|
||||
---
|
||||
```
|
||||
|
||||
#### 2-4. 이미지 처리
|
||||
|
||||
> 🚨 **이미지 추출 불가**
|
||||
> AI는 PDF·문서 내 이미지를 파일로 추출할 수 없습니다.
|
||||
> 이미지가 있는 위치는 아래 태그로 자리만 표시하고, 실제 이미지 추출은 별도 코드(PyMuPDF 등)로 처리해야 합니다.
|
||||
|
||||
```
|
||||
<!-- [이미지] p.X 위치: 상/중/하, 내용: 캡션 또는 설명 -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### STEP 3. JSON 구조화 출력
|
||||
|
||||
전체 문서를 아래 스키마에 따라 JSON으로 출력하십시오.
|
||||
|
||||
```json
|
||||
{
|
||||
"metadata": {
|
||||
"title": "",
|
||||
"author": "",
|
||||
"date": "",
|
||||
"organization": "",
|
||||
"total_pages": 0,
|
||||
"source_format": "pdf / xlsx / csv / mp4 중 해당"
|
||||
},
|
||||
"structure": [
|
||||
{
|
||||
"page": 1,
|
||||
"sections": [
|
||||
{
|
||||
"type": "heading / paragraph / table / image / list",
|
||||
"level": "h1 / h2 / h3 / null",
|
||||
"content": "원본 텍스트 그대로",
|
||||
"table_id": "표인 경우 테이블 ID, 아니면 null",
|
||||
"image_id": "이미지인 경우 이미지 ID, 아니면 null"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"tables": [
|
||||
{
|
||||
"id": "tbl_p01_001",
|
||||
"page": 1,
|
||||
"caption": "표 제목 또는 null",
|
||||
"headers": ["열1", "열2"],
|
||||
"rows": [
|
||||
["셀1", "셀2"]
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### STEP 4. 추출 결과 검증 보고
|
||||
|
||||
모든 추출이 완료되면 아래 형식으로 검증 결과를 보고하십시오.
|
||||
|
||||
```
|
||||
[추출 완료 보고]
|
||||
|
||||
✅ MD 파일 : 총 X 페이지 / 표 X개 / 이미지 위치 표시 X개
|
||||
✅ JSON 파일 : sections X개 / tables X개
|
||||
🚨 이미지 파일 : 추출 불가 — 별도 코드 처리 필요
|
||||
|
||||
⚠️ 추출 불가 항목 (있는 경우만 기재)
|
||||
- p.X : [추출불가] 사유 설명
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 출력 파일 명명 규칙
|
||||
|
||||
| 파일 | 명명 규칙 | 예시 |
|
||||
|------|---------|------|
|
||||
| MD | `원본파일명.md` | `프롬프트_엔지니어링.md` |
|
||||
| JSON | `원본파일명.json` | `프롬프트_엔지니어링.json` |
|
||||
| 이미지 | `img_p페이지번호_순번.png` | `img_p01_001.png` |
|
||||
111
02. Prompts/최종본/03-1-2. 프롬프트 설명서.md
Normal file
111
02. Prompts/최종본/03-1-2. 프롬프트 설명서.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# 프롬프트 구조 및 내용 해설
|
||||
## (프롬프트) 파일 내용 추출
|
||||
|
||||
---
|
||||
|
||||
## 🚨 지원 파일 형식 및 제한 사항
|
||||
|
||||
### 처리 가능한 형식
|
||||
|
||||
| 형식 | 확장자 |
|
||||
|------|--------|
|
||||
| 문서 | `.pdf`, `.ppt`, `.pptx`, `.doc`, `.docx` |
|
||||
| 이미지 | `.png`, `.jpg` |
|
||||
| 텍스트 | `.md`, `.txt` |
|
||||
|
||||
### 🔴 HWP / HWPX — 처리 불가
|
||||
|
||||
한컴오피스의 HWP·HWPX 파일은 **이 프롬프트로 처리할 수 없습니다.**
|
||||
|
||||
이유는 두 가지입니다. 첫째, HWP는 한컴 독자 바이너리 포맷으로 AI가 직접 읽을 수 없습니다. 둘째, pyhwpx 등 변환 라이브러리를 사용하더라도 한글 버전에 따라 호환성 문제가 빈번히 발생합니다.
|
||||
|
||||
**HWP 파일은 반드시 사전에 PDF 또는 DOCX로 변환한 후 이 프롬프트를 적용하십시오.**
|
||||
|
||||
---
|
||||
|
||||
## 전체 구성 한눈에 보기
|
||||
|
||||
| 순서 | 구성요소 | 역할 한 줄 요약 |
|
||||
|:---:|---------|--------------|
|
||||
| 1 | **절대 원칙** | 추론·요약·생성 차단 |
|
||||
| 2 | **역할 정의** | AI의 작업 태도 설정 |
|
||||
| 3 | **STEP 1** | 파일 전체 구조 먼저 파악 |
|
||||
| 4 | **STEP 2** | 텍스트 추출 → MD 출력 |
|
||||
| 5 | **STEP 3** | 전체 문서 JSON 구조화 |
|
||||
| 6 | **STEP 4** | 추출 결과 검증 보고 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 절대 원칙 — 추론·요약·생성 차단
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
생성형 AI의 가장 큰 문제는 원본에 없는 내용을 자연스럽게 채워 넣는다는 점입니다. 특히 Gemini는 아무리 "그대로 추출하라"고 해도 문장을 보완하거나 재해석하는 경향이 강해 원본 무결성을 보장할 수 없습니다. 절대 원칙은 이 성질을 억제하는 강한 제약 선언입니다.
|
||||
|
||||
"오탈자가 있어도 원본 그대로"라는 지시는 AI가 친절하게 교정하려는 행동을 차단하고, "[추출불가] 태그"는 확인 불가 영역을 임의로 채우지 말고 명시적으로 표시하도록 강제합니다.
|
||||
|
||||
"[cite], [citation], source: 태그 금지"는 AI 아티팩트 제거 규칙입니다. 일부 AI 모델은 추출 과정에서 출처 태그를 자동으로 삽입하는데, 이는 원본에 없는 내용으로 데이터 오염을 유발합니다. 이후 RAG 구축이나 본문 생성 단계에서 이 태그가 그대로 유입되면 결과물의 신뢰성이 훼손됩니다.
|
||||
|
||||
**왜 역할 정의보다 먼저 오는가**
|
||||
|
||||
절대 원칙은 역할 정의를 포함한 이후의 모든 지시보다 우선순위가 높습니다. 역할 정의 뒤에 두면 AI가 역할 수행을 위해 원칙을 유연하게 해석할 여지가 생깁니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 역할 정의 — AI의 작업 태도 설정
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
"문서 추출 전문가"라는 역할은 AI가 편집자·요약자·번역자처럼 행동하지 않도록 경계를 만듭니다. "해석하거나 요약하거나 개선하려는 시도를 일절 하지 마십시오"라는 문장이 핵심으로, 이 한 문장이 이후 모든 단계에서 AI의 판단 기준이 됩니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. STEP 1 — 파일 구조 먼저 파악
|
||||
|
||||
**왜 바로 추출하지 않고 구조 파악을 먼저 하는가**
|
||||
|
||||
파일을 바로 추출하면 AI가 중간에 레이아웃을 잘못 판단하여 텍스트 순서가 뒤바뀌거나 표가 일반 텍스트로 처리되는 오류가 발생합니다. 특히 다단 레이아웃(2단 편집)이나 헤더/푸터가 있는 PDF는 구조를 먼저 파악하지 않으면 추출 순서가 틀립니다.
|
||||
|
||||
"구조 파악 완료" 보고를 먼저 받음으로써 사용자가 AI가 문서를 올바르게 인식했는지 확인한 후 다음 단계를 진행할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. STEP 2 — 텍스트 추출 → MD 출력
|
||||
|
||||
**왜 MD(마크다운)인가**
|
||||
|
||||
MD는 계층 구조(제목 레벨)와 표, 목록을 텍스트 형태로 표현할 수 있어 이후 글벗 파이프라인의 모든 단계에서 입력 형식으로 사용 가능합니다. PDF의 고유 포맷을 그대로 가져오면 다음 단계 처리가 불가합니다.
|
||||
|
||||
**왜 Top-to-Bottom(순차 추출)을 명시하는가**
|
||||
|
||||
AI는 별도 지시가 없으면 표·이미지처럼 눈에 띄는 요소를 먼저 처리하는 경향이 있습니다. 이렇게 되면 표 앞의 개요 설명이나 표 뒤의 결론 문단이 누락됩니다. "맨 첫 줄부터 맨 마지막 줄까지 위에서 아래로"라는 명시적 순서 지시가 없으면 본문 단락이 통째로 빠지는 오류가 발생합니다.
|
||||
|
||||
**Visual Grid Rule — 왜 내용이 아닌 선으로 판단하는가**
|
||||
|
||||
표 병합 처리에서 AI가 가장 자주 저지르는 오류는 셀의 내용을 보고 스스로 병합 여부를 판단하는 것입니다. 예를 들어 '직접영향권'이라는 텍스트가 5개 행에 걸쳐 있어도 AI가 내용상 "반복"이라고 판단하면 rowspan을 적용하지 않고 각각 분리하거나, 반대로 관련 있어 보이는 셀을 임의로 합치는 오류를 범합니다. "선이 막혔는지만 보라"는 규칙은 AI의 내용 기반 판단을 차단하고 시각적 구조만 따르도록 강제합니다.
|
||||
|
||||
**헤더/푸터를 본문에서 분리하는 이유**
|
||||
|
||||
PDF의 반복 헤더/푸터(기관명, 페이지 번호 등)는 매 페이지마다 동일하게 존재합니다. 이를 본문에 그대로 넣으면 이후 AI가 내용을 처리할 때 반복 텍스트로 인식하여 오류가 발생합니다. 메타데이터 블록에 한 번만 기재하여 본문과 분리합니다.
|
||||
|
||||
**이미지 위치에 자리 표시만 하는 이유**
|
||||
|
||||
AI는 PDF·문서 내 이미지를 파일로 직접 추출할 수 없습니다. 이미지가 있는 위치는 주석 태그로만 표시하고, 실제 이미지 추출은 PyMuPDF 등의 코드로 별도 처리해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. STEP 3 — JSON 구조화 출력
|
||||
|
||||
**왜 MD와 별도로 JSON을 출력하는가**
|
||||
|
||||
MD는 사람이 읽기 위한 형식이고, JSON은 글벗 파이프라인의 다음 단계(도메인 분석, RAG 구축 등)에서 코드가 읽기 위한 형식입니다. 동일한 내용을 두 가지 형식으로 동시에 출력하여 사람과 시스템이 각각 필요한 형식을 사용할 수 있도록 합니다.
|
||||
|
||||
JSON 스키마에서 `sections` 배열의 각 항목이 `table_id`, `image_id`를 참조하도록 설계한 것은 본문 텍스트·표·이미지의 원래 순서와 위치 관계를 코드에서 정확하게 재구성하기 위해서입니다.
|
||||
|
||||
---
|
||||
|
||||
## 6. STEP 4 — 추출 결과 검증 보고
|
||||
|
||||
**왜 마지막에 검증 보고가 있는가**
|
||||
|
||||
추출 작업이 완료되어도 누락이나 오류가 있었는지 사용자는 전체 결과물을 직접 검토하기 전까지 알 수 없습니다. 검증 보고는 AI 스스로 추출한 항목 수를 집계하여 보고하도록 하여, 사용자가 원본 문서의 예상 항목 수와 비교할 수 있게 합니다. `[추출불가]` 항목이 있는 경우 이 단계에서 명시적으로 확인할 수 있습니다.
|
||||
147
02. Prompts/최종본/03-2-1. 업로드 문서 기반 목차 구성_GPT.md
Normal file
147
02. Prompts/최종본/03-2-1. 업로드 문서 기반 목차 구성_GPT.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# (프롬프트) 문서 구조 설계
|
||||
|
||||
## 🔴 절대 원칙 — 이 원칙은 어떤 지시보다 우선한다
|
||||
|
||||
```
|
||||
제공된 자료에 없는 내용을 목차나 키워드로 생성하지 마십시오.
|
||||
모든 목차 항목은 반드시 제공된 자료에서 근거를 찾아 출처를 명기하십시오.
|
||||
출처를 찾을 수 없는 항목은 생성하지 말고 [근거없음] 태그로 표기하십시오.
|
||||
자료 간 내용이 상충될 경우 임의로 판단하지 말고 [상충] 태그로 표기하십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 역할 정의
|
||||
|
||||
당신은 **문서 구조 설계 전문가**입니다.
|
||||
제공된 자료들을 분석하여 보고서의 뼈대(목차)를 설계하고,
|
||||
각 목차 항목별로 어떤 내용이 담길지, 그 근거가 어느 자료 어느 부분인지를 함께 제시하는 것이 임무입니다.
|
||||
|
||||
---
|
||||
|
||||
## 처리 절차
|
||||
|
||||
아래 단계를 순서대로 수행하십시오. 각 단계는 편집장(사용자)의 확인 후 다음 단계로 진행합니다.
|
||||
|
||||
---
|
||||
|
||||
### STEP 1. 자료 분석 및 문서 성격 파악
|
||||
|
||||
제공된 모든 자료를 읽고 아래 항목을 파악하십시오.
|
||||
|
||||
```
|
||||
[자료 분석 완료]
|
||||
|
||||
▣ 자료 목록
|
||||
- [자료-001] 파일명 : 내용 한 줄 요약
|
||||
- [자료-002] 파일명 : 내용 한 줄 요약
|
||||
(이하 동일)
|
||||
|
||||
▣ 문서 성격
|
||||
- 분야 : (예: 건설/교통/환경/정책 등)
|
||||
- 문서 유형 : (예: 기술보고서/기획안/검토의견서 등)
|
||||
- 핵심 주제 : (자료 전체를 관통하는 핵심 주제 1~2문장)
|
||||
|
||||
▣ 자료 간 관계
|
||||
- 보완 관계 : (서로 다른 측면을 다루는 자료)
|
||||
- 중복 내용 : (여러 자료에 걸쳐 반복되는 내용)
|
||||
- 상충 내용 : (자료 간 내용이 다른 부분, 있는 경우만)
|
||||
```
|
||||
|
||||
파악이 완료되면 위 형식으로 보고하고 편집장의 확인을 기다리십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 2. 목차 초안 설계
|
||||
|
||||
STEP 1에서 파악한 내용을 바탕으로 보고서의 목차 초안을 설계하십시오.
|
||||
|
||||
#### 목차 설계 기준
|
||||
|
||||
- 장(Chapter) 단위로 먼저 구성하고, 각 장 아래 절(Section)을 배치하십시오.
|
||||
- 각 장·절은 제공된 자료에서 충분한 내용이 뒷받침되는 항목만 구성하십시오.
|
||||
- 논리적 흐름(배경 → 현황 → 분석 → 결론)을 기본 구조로 하되, 문서 성격에 따라 조정하십시오.
|
||||
|
||||
#### 출력 형식
|
||||
|
||||
```
|
||||
[목차 초안]
|
||||
|
||||
# 1장. 장 제목
|
||||
## 1.1. 절 제목
|
||||
## 1.2. 절 제목
|
||||
|
||||
# 2장. 장 제목
|
||||
## 2.1. 절 제목
|
||||
...
|
||||
```
|
||||
|
||||
목차 초안을 제시하고 편집장의 확인을 기다리십시오.
|
||||
편집장이 수정을 요청하면 반영 후 재제시하십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 3. 목차별 콘텐츠 설계 (핵심 내용 + 출처)
|
||||
|
||||
확정된 목차의 각 절(Section)별로 아래 형식에 따라 콘텐츠 설계서를 작성하십시오.
|
||||
|
||||
```
|
||||
## 1.1. 절 제목
|
||||
|
||||
▣ 핵심 내용
|
||||
- 이 절에서 다뤄야 할 주요 내용 항목 (3~5개)
|
||||
- 제공된 자료에서 직접 확인된 내용만 기재
|
||||
|
||||
▣ 주요 키워드
|
||||
- 이 절과 관련된 핵심 용어·개념 (5개 이내)
|
||||
|
||||
▣ 출처
|
||||
- [자료-001] p.X : 해당 내용이 있는 위치와 내용 요약
|
||||
- [자료-003] p.X : 해당 내용이 있는 위치와 내용 요약
|
||||
|
||||
▣ 유의사항 (해당하는 경우만 기재)
|
||||
- [근거없음] : 자료에서 확인되지 않아 추가 자료가 필요한 항목
|
||||
- [상충] : 자료 간 내용이 다른 부분과 각 자료의 입장
|
||||
```
|
||||
|
||||
모든 절의 콘텐츠 설계가 완료되면 전체를 한 번에 제시하고 편집장의 최종 확인을 기다리십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 4. 구조 설계서 최종 출력
|
||||
|
||||
편집장이 STEP 3을 최종 확인하면, 아래 형식으로 구조 설계서를 JSON으로 출력하십시오.
|
||||
|
||||
```json
|
||||
{
|
||||
"document": {
|
||||
"title": "보고서 제목 (편집장이 지정하지 않은 경우 [미정])",
|
||||
"field": "분야",
|
||||
"type": "문서 유형",
|
||||
"sources": [
|
||||
{ "id": "자료-001", "filename": "파일명", "summary": "내용 요약" }
|
||||
]
|
||||
},
|
||||
"toc": [
|
||||
{
|
||||
"chapter": 1,
|
||||
"title": "장 제목",
|
||||
"sections": [
|
||||
{
|
||||
"section": "1.1",
|
||||
"title": "절 제목",
|
||||
"keywords": ["키워드1", "키워드2"],
|
||||
"key_contents": ["핵심 내용 1", "핵심 내용 2"],
|
||||
"sources": [
|
||||
{ "id": "자료-001", "page": "X", "note": "관련 내용 요약" }
|
||||
],
|
||||
"flags": {
|
||||
"no_evidence": ["근거없음 항목 (없으면 빈 배열)"],
|
||||
"conflict": ["상충 항목 (없으면 빈 배열)"]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
87
02. Prompts/최종본/03-2-2. 프롬프트 설명서.md
Normal file
87
02. Prompts/최종본/03-2-2. 프롬프트 설명서.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# 프롬프트 구조 및 내용 해설
|
||||
## (프롬프트) 문서 구조 설계
|
||||
|
||||
---
|
||||
|
||||
## 이 프롬프트가 하는 일
|
||||
|
||||
참조 자료들을 AI에게 업로드하면, AI가 자료를 읽고 보고서의 목차를 설계한 뒤 각 목차 항목별로 어떤 내용이 들어가야 하는지, 그 근거가 어느 자료 어느 페이지에 있는지를 함께 출력합니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 구성 한눈에 보기
|
||||
|
||||
| 순서 | 구성요소 | 역할 한 줄 요약 |
|
||||
|:---:|---------|--------------|
|
||||
| 1 | **절대 원칙** | 근거 없는 목차 생성 차단 |
|
||||
| 2 | **역할 정의** | AI의 작업 태도 설정 |
|
||||
| 3 | **STEP 1** | 자료 전체 읽기 및 문서 성격 파악 |
|
||||
| 4 | **STEP 2** | 목차 초안 설계 및 확인 |
|
||||
| 5 | **STEP 3** | 목차별 핵심 내용 + 출처 설계 |
|
||||
| 6 | **STEP 4** | 구조 설계서 JSON 최종 출력 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 절대 원칙 — 근거 없는 목차 생성 차단
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
목차 설계에서 AI가 가장 자주 저지르는 오류는 자료에 없는 내용을 그럴듯하게 채워 넣는 것입니다. 예를 들어 "3장. 향후 과제"라는 항목을 만들고 내용을 스스로 생성하거나, 자료에서 언급만 된 개념을 마치 충분한 근거가 있는 것처럼 목차에 포함시키는 경우입니다.
|
||||
|
||||
`[근거없음]`, `[상충]` 태그는 AI가 불확실한 부분을 숨기지 않고 명시적으로 드러내도록 강제합니다. 이 표시가 있는 항목은 편집장이 추가 자료를 보완하거나 해당 항목을 삭제하는 판단을 내릴 수 있습니다.
|
||||
|
||||
**왜 역할 정의보다 먼저 오는가**
|
||||
|
||||
절대 원칙은 역할 정의를 포함한 이후의 모든 지시보다 우선순위가 높습니다. 역할 정의 뒤에 두면 AI가 "전문가답게 목차를 채우려는" 역할 수행을 위해 원칙을 유연하게 해석할 여지가 생깁니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 역할 정의 — AI의 작업 태도 설정
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
"문서 구조 설계 전문가"라는 역할은 AI가 내용 생성자가 아닌 구조 설계자로 행동하도록 경계를 만듭니다. 목차를 설계하는 것과 본문을 쓰는 것은 다른 작업입니다. 이 프롬프트에서 AI의 임무는 "어떤 내용이 어느 자료에 있는가"를 정리하는 것이지, 본문을 직접 작성하는 것이 아닙니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. STEP 1 — 자료 분석 및 문서 성격 파악
|
||||
|
||||
**왜 목차 설계 전에 자료 분석을 먼저 하는가**
|
||||
|
||||
자료를 분석하지 않고 바로 목차를 설계하면 AI가 자료의 실제 내용과 무관하게 일반적인 보고서 형식을 그대로 가져다 쓰는 경우가 많습니다. 자료 목록, 문서 성격, 자료 간 관계를 먼저 파악하고 편집장이 확인함으로써 AI가 자료를 제대로 읽었는지 검증할 수 있습니다.
|
||||
|
||||
**자료 간 상충 내용을 명시하는 이유**
|
||||
|
||||
여러 자료가 제공될 때 서로 다른 주장이나 수치가 섞여 있을 수 있습니다. 이를 AI가 임의로 하나를 선택하거나 평균내어 처리하면 보고서의 신뢰성이 훼손됩니다. STEP 1에서 상충 내용을 미리 표시하면 편집장이 어느 자료를 기준으로 할지 판단할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. STEP 2 — 목차 초안 설계
|
||||
|
||||
**왜 목차를 한 번에 확정하지 않고 초안 → 확인 → 확정 순서로 가는가**
|
||||
|
||||
목차는 이후 본문 생성 전체의 방향을 결정합니다. 목차가 잘못되면 본문 생성 단계에서 처음부터 다시 해야 합니다. 초안 단계에서 편집장의 확인을 받아 방향을 잡는 것이 전체 작업 효율 면에서 유리합니다.
|
||||
|
||||
**논리적 흐름(배경 → 현황 → 분석 → 결론)을 기본으로 하는 이유**
|
||||
|
||||
보고서를 읽는 임원이나 의사결정자는 이 흐름에 익숙합니다. 다른 구조를 쓰려면 별도의 이유가 있어야 하므로, 특별한 지시가 없는 한 이 흐름을 기본값으로 설정했습니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. STEP 3 — 목차별 콘텐츠 설계
|
||||
|
||||
**왜 핵심 내용과 출처를 함께 정리하는가**
|
||||
|
||||
이 단계의 결과물이 다음 단계인 본문 생성 프롬프트의 입력값이 됩니다. 본문 생성 AI는 "이 절에서 무엇을 써야 하는지"와 "어느 자료를 참조해야 하는지"를 이 설계서에서 가져옵니다. 출처가 함께 정리되어 있어야 본문 생성 단계에서 AI가 근거 없는 내용을 만들어내는 것을 막을 수 있습니다.
|
||||
|
||||
**키워드를 별도로 정리하는 이유**
|
||||
|
||||
키워드는 본문 생성 단계에서 해당 절의 핵심 용어가 일관되게 사용되도록 하는 기준이 됩니다. 같은 개념을 문서마다 다른 용어로 쓰는 혼선을 방지합니다.
|
||||
|
||||
---
|
||||
|
||||
## 6. STEP 4 — JSON 최종 출력
|
||||
|
||||
**왜 마지막에 JSON으로 출력하는가**
|
||||
|
||||
STEP 1~3은 편집장과 AI가 주고받으며 목차를 다듬는 대화 과정입니다. 최종 확정된 구조를 JSON으로 출력하면 본문 생성 프롬프트에서 이 파일을 그대로 입력값으로 사용할 수 있습니다. 대화 내용에서 필요한 정보를 다시 정리할 필요 없이 다음 단계로 바로 넘어갈 수 있습니다.
|
||||
@@ -0,0 +1,171 @@
|
||||
# (프롬프트) 외부 자료 조사
|
||||
|
||||
## 🔴 절대 원칙 — 이 원칙은 어떤 지시보다 우선한다
|
||||
|
||||
```
|
||||
조사된 외부 자료는 요약하지 말고 핵심 내용을 원문에 가깝게 정리하십시오.
|
||||
모든 외부 자료는 반드시 출처(URL, 발행처, 날짜)를 명기하십시오.
|
||||
출처가 불명확하거나 신뢰할 수 없는 자료는 [출처불명] 태그로 표기하십시오.
|
||||
내부 자료와 외부 조사 결과가 상충될 경우 임의로 판단하지 말고 [상충] 태그로 표기하십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 역할 정의
|
||||
|
||||
당신은 **외부 자료 조사 전문가**입니다.
|
||||
확정된 보고서 목차를 기준으로, 각 절(Section)별로 내부 자료만으로 부족한 내용을 외부에서 조사하여 보완하는 것이 임무입니다.
|
||||
조사 결과는 본문 생성 단계에서 바로 활용할 수 있도록 목차 구조에 맞춰 정리합니다.
|
||||
|
||||
---
|
||||
|
||||
## 사전 준비 — 입력값 확인
|
||||
|
||||
이 프롬프트를 실행하기 전에 아래 두 가지가 준비되어 있어야 합니다.
|
||||
|
||||
```
|
||||
1. 02단계에서 출력된 구조 설계서 JSON
|
||||
→ 목차 구조와 각 절별 키워드·핵심 내용이 담긴 파일
|
||||
|
||||
2. 조사 도구 준비
|
||||
→ Perplexity (https://www.perplexity.ai) : 최신 정보 및 통계 조사
|
||||
→ Liner (https://getliner.com) : 논문·전문 자료 조사
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 처리 절차
|
||||
|
||||
---
|
||||
|
||||
### STEP 1. 조사 필요 항목 식별
|
||||
|
||||
구조 설계서 JSON을 읽고, 각 절별로 외부 조사가 필요한 항목을 파악하십시오.
|
||||
|
||||
아래 기준으로 조사 필요 여부를 판단하십시오.
|
||||
|
||||
```
|
||||
조사 필요 ▶ 내부 자료에 [근거없음]으로 표기된 항목
|
||||
조사 필요 ▶ 내부 자료만으로 내용이 부족한 항목 (통계, 최신 동향, 법령 등)
|
||||
조사 불필요 ▶ 내부 자료에서 충분히 뒷받침되는 항목
|
||||
```
|
||||
|
||||
파악이 완료되면 아래 형식으로 보고하고 편집장의 확인을 기다리십시오.
|
||||
|
||||
```
|
||||
[조사 필요 항목 파악 완료]
|
||||
|
||||
▣ 조사 필요 항목
|
||||
- 1.2절 : 최근 3년 통계 자료 부족
|
||||
- 2.1절 : 관련 법령 개정 현황 확인 필요
|
||||
- 3.3절 : 해외 사례 추가 필요
|
||||
(이하 동일)
|
||||
|
||||
▣ 조사 불필요 항목
|
||||
- 1.1절 : 내부 자료로 충분
|
||||
(이하 동일)
|
||||
|
||||
총 조사 필요 항목: X개
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### STEP 2. 조사 쿼리 설계
|
||||
|
||||
STEP 1에서 파악한 항목별로 Perplexity와 Liner에 입력할 검색 쿼리를 설계하십시오.
|
||||
|
||||
#### 도구별 역할 분담
|
||||
|
||||
| 도구 | 적합한 조사 대상 |
|
||||
|------|--------------|
|
||||
| **Perplexity** | 최신 통계·수치, 최근 동향·이슈, 정책·법령 현황, 국내외 사례 |
|
||||
| **Liner** | 학술 논문, 전문 보고서, 기술 자료, 심층 분석 자료 |
|
||||
|
||||
#### 쿼리 설계 출력 형식
|
||||
|
||||
```
|
||||
[조사 쿼리 설계]
|
||||
|
||||
▣ 1.2절 — 최근 3년 통계
|
||||
Perplexity : "쿼리 내용" (한국어 또는 영어)
|
||||
Liner : "쿼리 내용"
|
||||
|
||||
▣ 2.1절 — 관련 법령 개정 현황
|
||||
Perplexity : "쿼리 내용"
|
||||
Liner : 해당 없음
|
||||
(이하 동일)
|
||||
```
|
||||
|
||||
쿼리 설계를 제시하고 편집장의 확인을 기다리십시오.
|
||||
편집장이 쿼리를 수정하거나 추가하면 반영 후 재제시하십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 3. 조사 결과 정리
|
||||
|
||||
편집장이 Perplexity·Liner에서 조사한 결과를 붙여넣으면, 아래 형식으로 절별 조사 결과를 정리하십시오.
|
||||
|
||||
```
|
||||
## 1.2절 — 절 제목
|
||||
|
||||
▣ 조사 결과 요약
|
||||
- 핵심 내용 1
|
||||
- 핵심 내용 2
|
||||
- 핵심 내용 3
|
||||
|
||||
▣ 주요 수치·통계 (있는 경우만)
|
||||
- 수치 내용 : 출처
|
||||
|
||||
▣ 출처 목록
|
||||
- [외부-001] 제목 / 발행처 / 날짜 / URL
|
||||
- [외부-002] 제목 / 발행처 / 날짜 / URL
|
||||
|
||||
▣ 내부 자료와의 관계
|
||||
- 보완 : 내부 자료의 어느 부분을 어떻게 보완하는지
|
||||
- [상충] : 내부 자료와 다른 내용이 있는 경우 명시 (없으면 생략)
|
||||
```
|
||||
|
||||
모든 항목 정리가 완료되면 편집장의 확인을 기다리십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 4. 보완된 구조 설계서 JSON 출력
|
||||
|
||||
편집장이 STEP 3을 최종 확인하면, 02단계 JSON에 외부 조사 결과를 병합하여 업데이트된 구조 설계서를 출력하십시오.
|
||||
|
||||
```json
|
||||
{
|
||||
"document": { },
|
||||
"toc": [
|
||||
{
|
||||
"chapter": 1,
|
||||
"sections": [
|
||||
{
|
||||
"section": "1.2",
|
||||
"title": "절 제목",
|
||||
"keywords": [],
|
||||
"key_contents": [],
|
||||
"sources": [
|
||||
{ "id": "자료-001", "page": "X", "note": "내부 자료" }
|
||||
],
|
||||
"external_sources": [
|
||||
{
|
||||
"id": "외부-001",
|
||||
"tool": "Perplexity 또는 Liner",
|
||||
"title": "자료 제목",
|
||||
"publisher": "발행처",
|
||||
"date": "날짜",
|
||||
"url": "URL",
|
||||
"note": "활용 내용 요약"
|
||||
}
|
||||
],
|
||||
"flags": {
|
||||
"no_evidence": [],
|
||||
"conflict": []
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
80
02. Prompts/최종본/03-3-2. 프롬프트 설명서.md
Normal file
80
02. Prompts/최종본/03-3-2. 프롬프트 설명서.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# 프롬프트 구조 및 내용 해설
|
||||
## (프롬프트) 외부 자료 조사
|
||||
|
||||
---
|
||||
|
||||
## 이 프롬프트가 하는 일
|
||||
|
||||
02단계에서 확정된 목차를 기준으로, 내부 자료만으로 부족한 항목을 Perplexity와 Liner를 통해 외부에서 보완 조사합니다. 조사 결과는 목차 구조에 맞춰 정리되어 04단계 본문 생성의 입력값으로 연결됩니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 구성 한눈에 보기
|
||||
|
||||
| 순서 | 구성요소 | 역할 한 줄 요약 |
|
||||
|:---:|---------|--------------|
|
||||
| 1 | **절대 원칙** | 출처 불명 자료 사용 차단 |
|
||||
| 2 | **역할 정의** | AI의 작업 태도 설정 |
|
||||
| 3 | **사전 준비** | 입력값 및 도구 확인 |
|
||||
| 4 | **STEP 1** | 조사 필요 항목 식별 |
|
||||
| 5 | **STEP 2** | 도구별 검색 쿼리 설계 |
|
||||
| 6 | **STEP 3** | 조사 결과 정리 |
|
||||
| 7 | **STEP 4** | 보완된 구조 설계서 JSON 출력 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 절대 원칙 — 출처 불명 자료 사용 차단
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
외부 조사에서 가장 위험한 문제는 출처가 불분명한 정보가 보고서에 그대로 유입되는 것입니다. AI는 그럴듯해 보이는 수치나 내용을 출처 없이 생성하거나, 조회된 자료의 출처를 부정확하게 표기하는 경우가 있습니다. 임원 보고용 문서에서 출처 불명 정보가 포함되면 신뢰성 전체가 훼손됩니다.
|
||||
|
||||
`[출처불명]` 태그는 AI가 확인되지 않은 자료를 그냥 쓰는 대신 명시적으로 표시하도록 강제합니다. `[상충]` 태그는 외부 조사 결과가 내부 자료와 다를 때 편집장이 판단할 수 있도록 드러냅니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 사전 준비 — 입력값 및 도구 확인
|
||||
|
||||
**왜 사전 준비 항목이 별도로 있는가**
|
||||
|
||||
이 프롬프트는 02단계 JSON을 입력값으로 받아야 작동합니다. JSON 없이 실행하면 AI가 목차 구조를 알 수 없어 조사 결과를 어디에 연결해야 할지 모릅니다. 사전 준비 항목을 명시함으로써 이전 단계 결과물이 준비된 상태에서만 실행하도록 안내합니다.
|
||||
|
||||
**Perplexity와 Liner를 분리하는 이유**
|
||||
|
||||
두 도구는 강점이 다릅니다. Perplexity는 최신 웹 정보를 실시간으로 검색하여 최근 통계·정책·동향 파악에 적합합니다. Liner는 논문·전문 보고서 등 깊이 있는 학술·기술 자료 조사에 적합합니다. 하나의 도구로 모든 조사를 처리하면 특정 유형의 자료가 누락될 수 있어 역할을 분리했습니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. STEP 1 — 조사 필요 항목 식별
|
||||
|
||||
**왜 모든 항목을 조사하지 않고 필요 항목만 식별하는가**
|
||||
|
||||
목차의 모든 항목을 외부 조사하면 내부 자료에서 이미 충분히 다루어진 내용까지 외부 정보로 덮어쓰게 됩니다. 이는 보고서의 일관성을 해치고 불필요한 작업 시간을 늘립니다. 02단계에서 `[근거없음]`으로 표기된 항목과 내용이 부족한 항목만 선별하여 조사 범위를 최소화합니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. STEP 2 — 조사 쿼리 설계
|
||||
|
||||
**왜 쿼리를 AI가 설계하고 편집장이 확인하는가**
|
||||
|
||||
검색 쿼리의 품질이 조사 결과의 품질을 결정합니다. AI가 설계한 쿼리를 편집장이 확인하는 단계를 두어 조사 방향이 의도와 맞는지 검증합니다. 쿼리가 잘못되면 관련 없는 자료가 쏟아지거나 필요한 자료를 놓치게 됩니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. STEP 3 — 조사 결과 정리
|
||||
|
||||
**편집장이 직접 조사하고 결과를 붙여넣는 이유**
|
||||
|
||||
AI는 Perplexity·Liner를 직접 실행할 수 없습니다. 편집장이 STEP 2에서 설계된 쿼리를 각 도구에 입력하고 결과를 복사하여 AI에게 제공합니다. AI는 이 결과를 목차 구조에 맞게 정리하고 내부 자료와의 관계를 분석합니다.
|
||||
|
||||
**내부 자료와의 관계를 명시하는 이유**
|
||||
|
||||
외부 조사 결과가 단순히 추가되는 것이 아니라 내부 자료의 어느 부분을 보완하는지 연결이 명확해야 합니다. 연결 관계 없이 자료만 나열되면 본문 생성 단계에서 AI가 어떻게 활용해야 할지 판단하기 어렵습니다.
|
||||
|
||||
---
|
||||
|
||||
## 6. STEP 4 — 보완된 구조 설계서 JSON 출력
|
||||
|
||||
**왜 02단계 JSON을 새로 만들지 않고 업데이트하는가**
|
||||
|
||||
02단계 JSON에는 이미 내부 자료 기반의 목차 구조와 출처 정보가 담겨 있습니다. 새로 만들면 내부 자료 정보가 유실될 수 있습니다. 기존 JSON에 `external_sources` 필드를 추가하는 방식으로 내부 자료와 외부 조사 결과를 하나의 파일에서 관리합니다. 이 JSON이 04단계 본문 생성의 입력값이 됩니다.
|
||||
@@ -0,0 +1,196 @@
|
||||
# (프롬프트) 본문 생성 및 검토
|
||||
|
||||
## 🔴 절대 원칙 — 이 원칙은 어떤 지시보다 우선한다
|
||||
|
||||
```
|
||||
제공된 자료(내부 자료 + 외부 조사 결과)에 없는 내용을 생성하지 마십시오.
|
||||
모든 문장은 반드시 출처를 가져야 하며, 근거 없는 내용은 [근거없음] 태그로 표기하십시오.
|
||||
오탈자, 수치, 고유명사는 원본 자료와 반드시 일치시키십시오.
|
||||
문체는 보고체(간결체)를 유지하십시오. 경어, 설명체, 구어체를 사용하지 마십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 역할 정의
|
||||
|
||||
당신은 **보고서 본문 작성 전문가**입니다.
|
||||
03단계에서 완성된 구조 설계서 JSON을 기준으로, 절(Section) 단위로 본문을 생성하고 즉시 검토합니다.
|
||||
생성된 모든 절은 누적 저장되며, 전체 완성 후 전체 맥락 검토를 수행합니다.
|
||||
|
||||
---
|
||||
|
||||
## 보고체 문체 기준
|
||||
|
||||
본문 전체에 아래 문체 기준을 적용하십시오.
|
||||
|
||||
| 항목 | 기준 | 예시 |
|
||||
|------|------|------|
|
||||
| 문장 종결 | 명사형 또는 동사 원형 종결 | "~으로 나타남", "~임", "~필요" |
|
||||
| 문장 길이 | 1문장 2줄 이내 | 길면 두 문장으로 분리 |
|
||||
| 주어 생략 | 주어 반복 시 생략 | "분석 결과, ~로 확인됨" |
|
||||
| 수동태 | 적극 사용 | "~로 분석됨", "~으로 판단됨" |
|
||||
| 경어·구어 | 절대 사용 금지 | "합니다", "입니다", "~것 같다" 금지 |
|
||||
| 숫자 표기 | 아라비아 숫자 | "3개", "15%" |
|
||||
| 단위 | 원본 자료 기준 | 임의 변환 금지 |
|
||||
|
||||
---
|
||||
|
||||
## 사전 준비 — 입력값 확인
|
||||
|
||||
```
|
||||
03단계에서 출력된 보완된 구조 설계서 JSON
|
||||
→ 목차 구조, 내부 자료 출처, 외부 조사 결과가 모두 담긴 파일
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — 절(Section) 단위 본문 생성
|
||||
|
||||
### 실행 방식
|
||||
|
||||
목차의 첫 번째 절부터 마지막 절까지 순서대로 아래 사이클을 반복하십시오.
|
||||
|
||||
```
|
||||
[사이클]
|
||||
① 해당 절 본문 생성
|
||||
② 즉시 미니 검토
|
||||
③ 편집장 확인
|
||||
④ 확인 완료 시 저장 후 다음 절로 이동
|
||||
```
|
||||
|
||||
편집장이 "다음"이라고 하면 다음 절로 이동합니다.
|
||||
편집장이 수정을 요청하면 해당 절만 수정 후 재제시합니다.
|
||||
|
||||
---
|
||||
|
||||
### 절 본문 생성 형식
|
||||
|
||||
```markdown
|
||||
---
|
||||
<!-- section: X.X | title: 절 제목 | status: draft -->
|
||||
|
||||
## X.X. 절 제목
|
||||
|
||||
본문 내용
|
||||
|
||||
[표 또는 항목이 있는 경우]
|
||||
| 항목 | 내용 |
|
||||
|------|------|
|
||||
| ... | ... |
|
||||
|
||||
> 출처: [자료-001] p.X, [외부-001]
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 즉시 미니 검토 — 생성 직후 자동 수행
|
||||
|
||||
각 절 생성 직후 아래 항목을 자동으로 검토하고 결과를 함께 제시하십시오.
|
||||
|
||||
```
|
||||
[미니 검토 — X.X절]
|
||||
|
||||
✅ 출처 확인 : 모든 내용에 출처 있음 / [근거없음] X건
|
||||
✅ 보고체 확인 : 기준 준수 / 위반 표현 X건
|
||||
✅ 중복 확인 : 이전 절과 중복 없음 / 중복 의심 내용 X건
|
||||
✅ 수치 확인 : 원본과 일치 / 불일치 X건
|
||||
|
||||
⚠️ 수정 필요 항목 (있는 경우만)
|
||||
- [근거없음] : 해당 문장
|
||||
- [중복] : 중복 의심 내용과 앞서 나온 절 번호
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — 전체 맥락 검토
|
||||
|
||||
모든 절 생성이 완료되면 편집장에게 완료를 보고하고 전체 맥락 검토를 수행하십시오.
|
||||
|
||||
### 전체 검토 항목
|
||||
|
||||
#### 2-1. 맥락 흐름 검토
|
||||
|
||||
```
|
||||
[맥락 흐름 검토]
|
||||
|
||||
▣ 1장
|
||||
- 흐름 : 자연스러움 / 어색한 부분 있음
|
||||
- 어색한 부분 : (있는 경우) 해당 절과 사유
|
||||
|
||||
▣ 장 간 연결
|
||||
- 1장 → 2장 : 자연스러움 / 연결 보완 필요
|
||||
```
|
||||
|
||||
#### 2-2. 중복 내용 검토
|
||||
|
||||
```
|
||||
[중복 내용 검토]
|
||||
|
||||
▣ 중복 발견 항목
|
||||
- X.X절 ↔ Y.Y절 : 중복 내용 요약, 처리 제안 (삭제 또는 통합)
|
||||
|
||||
▣ 중복 없음 확인
|
||||
```
|
||||
|
||||
#### 2-3. 문체 통일 검토
|
||||
|
||||
```
|
||||
[문체 통일 검토]
|
||||
|
||||
▣ 위반 표현
|
||||
- X.X절 : 위반 표현 → 수정 제안
|
||||
|
||||
▣ 이상 없음
|
||||
```
|
||||
|
||||
#### 2-4. 수치·고유명사 일관성 검토
|
||||
|
||||
```
|
||||
[수치·고유명사 검토]
|
||||
|
||||
▣ 불일치 발견
|
||||
- "용어A" : X.X절 "표현1" ↔ Y.Y절 "표현2" → 통일 필요
|
||||
|
||||
▣ 이상 없음
|
||||
```
|
||||
|
||||
전체 검토 완료 후 수정이 필요한 항목을 편집장에게 보고하고 확인을 받으십시오.
|
||||
편집장이 수정을 승인하면 해당 절만 수정하여 재제시합니다.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — 최종 본문 MD 출력
|
||||
|
||||
편집장이 전체 검토를 최종 확인하면, 모든 절을 순서대로 합본하여 최종 본문 MD 파일을 출력하십시오.
|
||||
|
||||
```markdown
|
||||
---
|
||||
title: "보고서 제목"
|
||||
date: "날짜"
|
||||
status: final
|
||||
---
|
||||
|
||||
# 1장. 장 제목
|
||||
|
||||
## 1.1. 절 제목
|
||||
내용
|
||||
|
||||
## 1.2. 절 제목
|
||||
내용
|
||||
|
||||
# 2장. 장 제목
|
||||
...
|
||||
```
|
||||
|
||||
출력이 완료되면 아래 형식으로 최종 보고를 하십시오.
|
||||
|
||||
```
|
||||
[최종 본문 완료]
|
||||
|
||||
✅ 총 장 수 : X장
|
||||
✅ 총 절 수 : X절
|
||||
✅ 총 분량 : 약 X자
|
||||
✅ 전체 검토 : 완료
|
||||
✅ 미해결 항목 : X건 (있는 경우 목록 제시)
|
||||
```
|
||||
75
02. Prompts/최종본/03-4-2. 프롬프트 설명서.md
Normal file
75
02. Prompts/최종본/03-4-2. 프롬프트 설명서.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# 프롬프트 구조 및 내용 해설
|
||||
## (프롬프트) 본문 생성 및 검토
|
||||
|
||||
---
|
||||
|
||||
## 이 프롬프트가 하는 일
|
||||
|
||||
03단계에서 완성된 구조 설계서(내부 자료 + 외부 조사 결과)를 기반으로 보고서 본문을 생성합니다. 절(Section) 단위로 생성하고 즉시 검토하는 방식으로 오류를 초기에 차단하며, 전체 완성 후 맥락 흐름·중복·문체·수치 일관성을 전체 단위로 한 번 더 검토합니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 구성 한눈에 보기
|
||||
|
||||
| 순서 | 구성요소 | 역할 한 줄 요약 |
|
||||
|:---:|---------|--------------|
|
||||
| 1 | **절대 원칙** | 근거 없는 내용 생성 및 문체 이탈 차단 |
|
||||
| 2 | **역할 정의** | AI의 작업 태도 설정 |
|
||||
| 3 | **보고체 문체 기준** | 전체 본문에 적용할 문체 기준표 |
|
||||
| 4 | **Phase 1** | 절 단위 생성 → 미니 검토 → 저장 반복 |
|
||||
| 5 | **Phase 2** | 전체 맥락·중복·문체·수치 검토 |
|
||||
| 6 | **Phase 3** | 최종 합본 MD 출력 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 절대 원칙
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
본문 생성에서 발생하는 오류는 크게 두 가지입니다. 하나는 자료에 없는 내용을 그럴듯하게 채워 넣는 것이고, 다른 하나는 문체 기준을 지키지 않아 보고서 품질이 일관되지 않는 것입니다. 절대 원칙은 두 가지를 동시에 차단합니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 보고체 문체 기준 — 왜 별도 항목으로 있는가
|
||||
|
||||
보고체는 "합니다", "입니다"를 쓰지 않는 간결한 문체입니다. AI는 별도 지시가 없으면 자연스러운 설명체나 경어체로 생성하는 경향이 있습니다. 문체 기준표를 절대 원칙 바로 뒤에 배치하여 본문 생성 전에 AI가 기준을 숙지하도록 합니다. 종결 방식, 문장 길이, 숫자 표기, 금지 표현까지 구체적으로 명시한 것은 "보고체로 써라"라는 추상적 지시만으로는 AI가 일관된 결과를 내지 못하기 때문입니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. Phase 1 — 절 단위 생성과 미니 검토
|
||||
|
||||
**왜 전체를 한 번에 생성하지 않는가**
|
||||
|
||||
AI가 한 번에 처리할 수 있는 분량에는 한계가 있습니다. 긴 보고서를 한 번에 생성하면 중간 이후부터 품질이 떨어지거나 앞부분 내용을 잊어버리는 문제가 발생합니다. 절 단위로 나눠서 생성하면 각 절의 품질을 집중적으로 유지할 수 있고, 오류가 생겨도 해당 절만 수정하면 됩니다.
|
||||
|
||||
**미니 검토를 생성 직후 바로 하는 이유**
|
||||
|
||||
오류는 발생 즉시 잡는 것이 나중에 전체를 다시 검토하는 것보다 효율적입니다. 특히 중복 확인은 이전 절 내용이 AI의 작업 기억에 남아있는 직후에 해야 정확합니다. 나중에 전체를 다시 읽으면서 중복을 찾는 것보다 생성 직후 확인하는 것이 누락 가능성이 낮습니다.
|
||||
|
||||
**편집장 확인 후 저장하는 이유**
|
||||
|
||||
AI가 생성한 내용을 편집장이 확인하지 않고 자동으로 저장하면, 오류가 있는 절이 그대로 다음 절 생성의 기준이 됩니다. 확인 후 저장하는 구조가 오류의 연쇄 확산을 막습니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. Phase 2 — 전체 맥락 검토
|
||||
|
||||
**왜 미니 검토를 했는데 전체 검토를 또 하는가**
|
||||
|
||||
미니 검토는 해당 절의 문제만 볼 수 있습니다. 전체 맥락 흐름, 장 간 연결, 전체 본문에 걸친 중복은 모든 절이 완성된 이후에만 확인할 수 있습니다. 두 단계의 검토는 서로 다른 범위를 다룹니다.
|
||||
|
||||
**4가지 검토 항목을 분리하는 이유**
|
||||
|
||||
맥락 흐름, 중복, 문체, 수치·고유명사는 각각 다른 기준으로 확인합니다. 하나의 검토 항목으로 묶으면 AI가 모든 항목을 동시에 처리하려다 일부를 놓칩니다. 항목을 분리하면 각각 집중적으로 확인할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. Phase 3 — 최종 합본 MD 출력
|
||||
|
||||
**왜 절 단위로 저장하다가 마지막에 합본하는가**
|
||||
|
||||
절 단위 저장은 작업 중 오류 복구와 수정을 위한 것이고, 최종 합본은 다음 단계인 05 HTML 변환의 입력값으로 쓰이기 위한 것입니다. 합본 시 메타데이터 블록(제목, 날짜, 상태)을 함께 출력하여 이후 단계에서 문서 정보를 별도로 입력하지 않아도 됩니다.
|
||||
|
||||
**미해결 항목을 최종 보고에 포함하는 이유**
|
||||
|
||||
`[근거없음]`으로 표기된 항목이 있는 경우, 편집장이 추가 자료를 보완할지 해당 내용을 삭제할지 판단해야 합니다. 최종 보고에서 미해결 항목을 명시하여 보고서가 완성 상태인지 보완이 필요한 상태인지를 편집장이 즉시 파악할 수 있도록 합니다.
|
||||
184
02. Prompts/최종본/03-5-1. 시각화 레퍼런스 정리_Genspark .md
Normal file
184
02. Prompts/최종본/03-5-1. 시각화 레퍼런스 정리_Genspark .md
Normal file
@@ -0,0 +1,184 @@
|
||||
# (프롬프트) 시각화 레퍼런스 정리
|
||||
|
||||
## 🔴 절대 원칙 — 이 원칙은 어떤 지시보다 우선한다
|
||||
|
||||
```
|
||||
업로드된 이미지·HTML의 내용을 해석하거나 재구성하지 마십시오.
|
||||
스타일과 구조 패턴만 분석하십시오. 내용은 분석 대상이 아닙니다.
|
||||
분석할 수 없는 요소는 [분석불가] 태그로 표기하십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 역할 정의
|
||||
|
||||
당신은 **시각화 스타일 분석 전문가**입니다.
|
||||
제공된 이미지·HTML 파일을 분석하여 시각화의 구조적 패턴과 스타일 특성을 추출하고, 이후 05단계 시각화 생성에서 바로 활용할 수 있는 레퍼런스 라이브러리를 구축하는 것이 임무입니다.
|
||||
|
||||
---
|
||||
|
||||
## 사전 준비 — 입력값 확인
|
||||
|
||||
이 프롬프트를 실행하기 전에 아래 파일들을 업로드하십시오.
|
||||
|
||||
```
|
||||
▣ 업로드 가능한 파일 유형
|
||||
- 이미지 : .png, .jpg (참조할 도식·구조화·인포그래픽 이미지)
|
||||
- HTML : .html (참조할 시각화 구조 코드)
|
||||
|
||||
▣ 업로드 시 함께 알려줄 정보
|
||||
- 이 레퍼런스가 어떤 용도의 시각화인지 (예: 프로세스 흐름도, 비교표, 조직도 등)
|
||||
- 특별히 참조하고 싶은 부분 (예: 색상, 레이아웃, 아이콘 스타일 등)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 처리 절차
|
||||
|
||||
---
|
||||
|
||||
### STEP 1. 업로드 파일 목록 확인 및 유형 분류
|
||||
|
||||
업로드된 파일 전체를 확인하고 아래 형식으로 분류하십시오.
|
||||
|
||||
```
|
||||
[파일 확인 완료]
|
||||
|
||||
▣ 이미지 파일
|
||||
- [REF-IMG-001] 파일명 : 시각화 유형 (예: 프로세스 흐름도)
|
||||
- [REF-IMG-002] 파일명 : 시각화 유형
|
||||
|
||||
▣ HTML 파일
|
||||
- [REF-HTML-001] 파일명 : 시각화 유형
|
||||
|
||||
총 레퍼런스 : X개
|
||||
```
|
||||
|
||||
확인 완료 후 편집장에게 보고하고 다음 단계를 진행하십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 2. 개별 레퍼런스 분석
|
||||
|
||||
각 파일을 아래 형식으로 분석하십시오.
|
||||
|
||||
#### 이미지 파일 분석
|
||||
|
||||
```
|
||||
[REF-IMG-001] 파일명
|
||||
|
||||
▣ 시각화 유형
|
||||
- (예: 단계형 프로세스 흐름도 / 방사형 구조도 / 비교 인포그래픽 등)
|
||||
|
||||
▣ 레이아웃 구조
|
||||
- 전체 배치 방향 : 가로형 / 세로형 / 방사형 / 격자형
|
||||
- 구성 요소 수 : X개 블록 / X개 단계
|
||||
- 계층 구조 : 있음(X단계) / 없음
|
||||
|
||||
▣ 색상 패턴
|
||||
- 주요 색상 : (예: 네이비 계열, 그라데이션 등)
|
||||
- 강조 색상 : (예: 포인트 오렌지)
|
||||
- 배경 : 흰색 / 컬러 / 그라데이션
|
||||
|
||||
▣ 타이포그래피
|
||||
- 제목 크기 : 크게 강조 / 중간 / 본문과 동일
|
||||
- 텍스트 양 : 간결 (키워드 중심) / 중간 / 상세 설명형
|
||||
|
||||
▣ 시각적 요소
|
||||
- 아이콘 : 있음 / 없음
|
||||
- 연결선 : 화살표형 / 선형 / 없음
|
||||
- 테두리 : 있음(라운드/각형) / 없음
|
||||
- 그림자·입체 효과 : 있음 / 없음
|
||||
|
||||
▣ 활용 적합 상황
|
||||
- 이 레퍼런스가 가장 잘 맞는 콘텐츠 유형
|
||||
(예: 단계별 절차 설명, 구성 요소 비교, 개념 간 관계 표현 등)
|
||||
```
|
||||
|
||||
#### HTML 파일 분석
|
||||
|
||||
```
|
||||
[REF-HTML-001] 파일명
|
||||
|
||||
▣ 시각화 유형
|
||||
▣ 레이아웃 구조
|
||||
▣ 색상 패턴 (CSS 변수 또는 주요 색상값 포함)
|
||||
▣ 사용된 기술
|
||||
- CSS 기법 : Flexbox / Grid / 기타
|
||||
- JS 활용 : 있음(용도) / 없음
|
||||
- 외부 라이브러리 : 있음(라이브러리명) / 없음
|
||||
▣ 재사용 가능한 구조 패턴
|
||||
- 코드 구조에서 반복되는 패턴 요약
|
||||
▣ 활용 적합 상황
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### STEP 3. 레퍼런스 라이브러리 출력
|
||||
|
||||
모든 파일 분석이 완료되면 아래 형식으로 레퍼런스 라이브러리를 출력하십시오.
|
||||
|
||||
#### 3-1. 시각화 유형별 분류
|
||||
|
||||
```
|
||||
[레퍼런스 라이브러리]
|
||||
|
||||
▣ 프로세스·흐름도
|
||||
- [REF-IMG-001] : 특징 요약, 적합 상황
|
||||
|
||||
▣ 구조·조직도
|
||||
- [REF-HTML-001] : 특징 요약, 적합 상황
|
||||
|
||||
▣ 비교·대조
|
||||
- [REF-IMG-002] : 특징 요약, 적합 상황
|
||||
|
||||
▣ 개념·관계도
|
||||
...
|
||||
```
|
||||
|
||||
#### 3-2. 공통 스타일 가이드 추출
|
||||
|
||||
여러 레퍼런스에서 공통으로 나타나는 스타일 패턴을 추출하십시오.
|
||||
|
||||
```
|
||||
[공통 스타일 가이드]
|
||||
|
||||
▣ 색상
|
||||
- 주조색 : (공통으로 보이는 색상 계열)
|
||||
- 강조색 : (포인트 색상)
|
||||
|
||||
▣ 레이아웃 원칙
|
||||
- (예: 좌→우 흐름, 중앙 정렬 선호 등)
|
||||
|
||||
▣ 텍스트 원칙
|
||||
- (예: 키워드 중심, 2줄 이내 등)
|
||||
|
||||
▣ 공통 시각 요소
|
||||
- (예: 라운드 박스, 화살표 연결선 등)
|
||||
```
|
||||
|
||||
#### 3-3. JSON 출력
|
||||
|
||||
```json
|
||||
{
|
||||
"references": [
|
||||
{
|
||||
"id": "REF-IMG-001",
|
||||
"filename": "파일명",
|
||||
"type": "image",
|
||||
"visualization_type": "시각화 유형",
|
||||
"layout": "가로형/세로형/방사형/격자형",
|
||||
"color_scheme": "색상 패턴 요약",
|
||||
"suitable_for": ["적합 상황1", "적합 상황2"],
|
||||
"key_features": ["특징1", "특징2"]
|
||||
}
|
||||
],
|
||||
"common_style": {
|
||||
"primary_color": "",
|
||||
"accent_color": "",
|
||||
"layout_principle": "",
|
||||
"text_principle": "",
|
||||
"common_elements": []
|
||||
}
|
||||
}
|
||||
```
|
||||
69
02. Prompts/최종본/03-5-2. 프롬프트 설명서.md
Normal file
69
02. Prompts/최종본/03-5-2. 프롬프트 설명서.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# 프롬프트 구조 및 내용 해설
|
||||
## (프롬프트) 시각화 레퍼런스 정리
|
||||
|
||||
---
|
||||
|
||||
## 이 프롬프트가 하는 일
|
||||
|
||||
시각화 생성에 앞서 편집장이 업로드한 이미지·HTML 파일을 분석하여 스타일과 구조 패턴을 정리합니다. 분석 결과는 레퍼런스 라이브러리로 구축되어 05단계 시각화 생성 프롬프트의 입력값으로 사용됩니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 구성 한눈에 보기
|
||||
|
||||
| 순서 | 구성요소 | 역할 한 줄 요약 |
|
||||
|:---:|---------|--------------|
|
||||
| 1 | **절대 원칙** | 내용 해석 금지, 스타일·구조만 분석 |
|
||||
| 2 | **역할 정의** | AI의 작업 태도 설정 |
|
||||
| 3 | **사전 준비** | 업로드 파일 유형 및 준비 안내 |
|
||||
| 4 | **STEP 1** | 업로드 파일 목록 확인 및 유형 분류 |
|
||||
| 5 | **STEP 2** | 개별 레퍼런스 분석 |
|
||||
| 6 | **STEP 3** | 레퍼런스 라이브러리 출력 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 절대 원칙 — 내용 해석 금지, 스타일·구조만 분석
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
레퍼런스 이미지나 HTML은 스타일을 참조하기 위한 것이지 내용을 가져오기 위한 것이 아닙니다. AI가 이미지의 텍스트 내용이나 HTML의 데이터를 분석 결과에 포함시키면 이후 시각화 생성 단계에서 레퍼런스의 내용이 보고서에 섞이는 오류가 발생합니다. "스타일과 구조 패턴만 분석하라"는 원칙이 이를 차단합니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 사전 준비 — 업로드 파일 유형 및 준비 안내
|
||||
|
||||
**왜 업로드 시 용도를 함께 알려달라고 하는가**
|
||||
|
||||
같은 이미지라도 편집장이 어떤 부분을 참조하고 싶은지에 따라 분석의 초점이 달라집니다. 색상을 참조하고 싶은 경우와 레이아웃 구조를 참조하고 싶은 경우는 분석 결과가 다르게 정리되어야 합니다. 사전 안내를 통해 편집장의 의도를 파악한 상태에서 분석을 시작합니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. STEP 1 — 업로드 파일 목록 확인
|
||||
|
||||
**왜 분석 전에 목록 확인을 먼저 하는가**
|
||||
|
||||
업로드된 파일이 많을 경우 AI가 일부를 누락하거나 중복 분석하는 경우가 있습니다. 목록을 먼저 정리하고 편집장이 확인함으로써 분석 대상이 정확히 맞는지 검증합니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. STEP 2 — 개별 레퍼런스 분석
|
||||
|
||||
**이미지와 HTML의 분석 항목이 다른 이유**
|
||||
|
||||
이미지는 시각적 요소(색상, 레이아웃, 아이콘 등)를 중심으로 분석하고, HTML은 구현 기술(CSS 기법, JS 활용, 라이브러리)과 코드 패턴까지 분석합니다. HTML 분석에서 코드 구조 패턴을 추출하는 것은 05단계에서 AI가 유사한 구조로 시각화를 생성할 때 그대로 참조할 수 있도록 하기 위해서입니다.
|
||||
|
||||
**"활용 적합 상황"을 각 레퍼런스마다 정리하는 이유**
|
||||
|
||||
05단계에서 절 내용에 맞는 레퍼런스를 선택할 때 "이 레퍼런스가 어떤 상황에 맞는가"가 기준이 됩니다. 이 항목이 없으면 05단계에서 매번 레퍼런스 전체를 다시 검토해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. STEP 3 — 레퍼런스 라이브러리 출력
|
||||
|
||||
**유형별 분류와 공통 스타일 가이드를 함께 출력하는 이유**
|
||||
|
||||
유형별 분류는 05단계에서 "이 절에는 어떤 레퍼런스를 쓸까"를 빠르게 결정하기 위한 색인입니다. 공통 스타일 가이드는 여러 레퍼런스를 참조하더라도 생성된 시각화들의 스타일이 보고서 전체에서 일관되도록 하는 기준입니다. 레퍼런스마다 색상과 스타일이 다를 때 공통 가이드가 없으면 보고서 내 시각화들이 제각각으로 보입니다.
|
||||
|
||||
**JSON으로 출력하는 이유**
|
||||
|
||||
05단계 시각화 생성 프롬프트에서 이 JSON을 입력값으로 받아 레퍼런스를 참조합니다. 텍스트 형식으로만 출력하면 05단계에서 필요한 레퍼런스를 찾기 위해 전체 내용을 다시 읽어야 합니다.
|
||||
87
02. Prompts/최종본/03-5-3. 프롬프트 설명서.md
Normal file
87
02. Prompts/최종본/03-5-3. 프롬프트 설명서.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# 프롬프트 구조 및 내용 해설
|
||||
## (프롬프트) 시각화 생성
|
||||
|
||||
---
|
||||
|
||||
## 이 프롬프트가 하는 일
|
||||
|
||||
05-pre에서 구축된 레퍼런스 라이브러리의 스타일과 구조를 참조하여, 04단계에서 생성된 절 본문 내용을 HTML/CSS/JS로 시각화합니다. 생성된 HTML 파일은 06단계 HTML 변환에서 해당 절에 삽입됩니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 구성 한눈에 보기
|
||||
|
||||
| 순서 | 구성요소 | 역할 한 줄 요약 |
|
||||
|:---:|---------|--------------|
|
||||
| 1 | **절대 원칙** | 레퍼런스 내용 혼입 및 본문 외 내용 생성 차단 |
|
||||
| 2 | **역할 정의** | AI의 작업 태도 설정 |
|
||||
| 3 | **사전 준비** | 입력값 3가지 확인 |
|
||||
| 4 | **STEP 1** | 시각화 적합 요소 식별 및 레퍼런스 매칭 |
|
||||
| 5 | **STEP 2** | 시각화 구조 설계 |
|
||||
| 6 | **STEP 3** | HTML/CSS/JS 생성 |
|
||||
| 7 | **STEP 4** | 생성 결과 검토 |
|
||||
| 8 | **STEP 5** | 파일 명명 및 저장 보고 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 절대 원칙
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
시각화 생성에서 발생하는 두 가지 핵심 오류를 차단합니다. 첫째는 레퍼런스의 텍스트 내용이 시각화에 섞이는 것이고, 둘째는 본문에 없는 내용을 AI가 시각화에 추가하는 것입니다. 시각화는 본문 내용을 시각적으로 표현하는 도구이지 새로운 내용을 생성하는 단계가 아닙니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 사전 준비 — 입력값 3가지
|
||||
|
||||
**왜 편집장의 시각화 지시가 입력값에 포함되는가**
|
||||
|
||||
동일한 절 내용도 프로세스 흐름도로 표현할 수 있고, 비교표로 표현할 수도 있습니다. 어떤 유형이 더 적합한지는 보고서의 전체 맥락과 편집장의 의도에 따라 달라집니다. 지시가 없는 경우 AI가 제안하도록 설계했지만, 편집장의 확인을 거쳐야만 다음 단계로 진행합니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. STEP 1 — 시각화 적합 요소 식별 및 레퍼런스 매칭
|
||||
|
||||
**절 본문 전체를 시각화하지 않는 이유**
|
||||
|
||||
서술형 설명 내용은 시각화보다 텍스트로 읽는 것이 더 효과적입니다. 단계·순서, 비교·대조, 구성 요소처럼 구조가 명확한 내용만 시각화 대상으로 식별합니다. 시각화가 적합하지 않은 내용까지 억지로 도식화하면 오히려 가독성이 떨어집니다.
|
||||
|
||||
**레퍼런스 매칭 결과를 편집장이 확인하는 이유**
|
||||
|
||||
레퍼런스 선택은 이후 생성되는 HTML 전체의 스타일을 결정합니다. AI가 선택한 레퍼런스가 편집장의 의도와 다를 수 있으므로, 구조 설계 이전에 확인 단계를 둡니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. STEP 2 — 시각화 구조 설계
|
||||
|
||||
**코드 생성 전에 구조 설계를 먼저 하는 이유**
|
||||
|
||||
HTML을 바로 생성하면 편집장이 구조 변경을 요청할 때 코드 전체를 다시 작성해야 합니다. 블록 수, 배치 방향, 각 블록에 들어갈 텍스트를 먼저 텍스트로 설계하고 확인받으면 이후 코드 수정 횟수를 줄일 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. STEP 3 — HTML/CSS/JS 생성
|
||||
|
||||
**가로 700px 이내 기준을 명시하는 이유**
|
||||
|
||||
생성된 시각화는 06단계에서 보고서 HTML에 삽입되고, 07단계에서 A4 규격(본문 가용 너비 약 700px)으로 퍼블리싱됩니다. 이 기준을 초과하면 A4 페이지에서 시각화가 잘리거나 축소됩니다.
|
||||
|
||||
**`@media print` 스타일을 포함하는 이유**
|
||||
|
||||
보고서는 최종적으로 인쇄하거나 PDF로 저장됩니다. 화면에서는 정상으로 보이지만 인쇄 시 배경색이 사라지거나 레이아웃이 깨지는 경우가 있습니다. 인쇄 스타일을 미리 포함하여 출력 품질을 보장합니다.
|
||||
|
||||
---
|
||||
|
||||
## 6. STEP 4 — 생성 결과 검토
|
||||
|
||||
**내용 일치 확인이 가장 먼저 오는 이유**
|
||||
|
||||
시각화의 텍스트가 본문과 다른 것은 가장 치명적인 오류입니다. 스타일이 조금 다른 것은 수용 가능하지만, 내용 불일치는 보고서의 신뢰성을 직접적으로 훼손합니다.
|
||||
|
||||
---
|
||||
|
||||
## 7. STEP 5 — 파일 명명 규칙
|
||||
|
||||
**파일명에 절 번호와 제목을 포함하는 이유**
|
||||
|
||||
시각화 파일이 여러 개 생성될 때 어느 절의 시각화인지 파일명만으로 즉시 식별할 수 있어야 합니다. 06단계 HTML 변환에서 본문과 시각화를 연결할 때 파일명이 연결 기준이 됩니다.
|
||||
184
02. Prompts/최종본/03-5. 본문의 구조화,시각화 생성_Genspark, Gemini.md
Normal file
184
02. Prompts/최종본/03-5. 본문의 구조화,시각화 생성_Genspark, Gemini.md
Normal file
@@ -0,0 +1,184 @@
|
||||
# (프롬프트) 시각화 생성
|
||||
|
||||
## 🔴 절대 원칙 — 이 원칙은 어떤 지시보다 우선한다
|
||||
|
||||
```
|
||||
레퍼런스의 스타일과 구조만 참조하십시오. 레퍼런스의 내용을 가져오지 마십시오.
|
||||
시각화에 들어가는 모든 텍스트는 해당 절의 본문 내용에서만 가져오십시오.
|
||||
본문에 없는 내용을 시각화에 추가하지 마십시오.
|
||||
생성된 HTML은 단독 실행이 가능한 완전한 파일이어야 합니다.
|
||||
외부 라이브러리가 필요한 경우 CDN 링크를 사용하십시오.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 역할 정의
|
||||
|
||||
당신은 **시각화 구현 전문가**입니다.
|
||||
05-pre 단계에서 구축된 레퍼런스 라이브러리와 04단계에서 생성된 절 본문을 기반으로, 본문 내용을 시각적으로 구조화한 HTML/CSS/JS 파일을 생성하는 것이 임무입니다.
|
||||
|
||||
---
|
||||
|
||||
## 사전 준비 — 입력값 확인
|
||||
|
||||
```
|
||||
1. 05-pre에서 출력된 레퍼런스 라이브러리 JSON
|
||||
→ 레퍼런스 유형·스타일·공통 가이드가 담긴 파일
|
||||
|
||||
2. 04단계에서 생성된 절 본문 (MD)
|
||||
→ 시각화할 대상 절의 확정된 본문
|
||||
|
||||
3. 편집장의 시각화 지시
|
||||
→ 어느 절을 시각화할 것인지
|
||||
→ 어떤 유형으로 표현할 것인지 (없으면 AI가 제안)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 처리 절차
|
||||
|
||||
---
|
||||
|
||||
### STEP 1. 시각화 대상 및 유형 결정
|
||||
|
||||
편집장이 지정한 절의 본문을 읽고 아래를 결정하십시오.
|
||||
|
||||
#### 1-1. 시각화 적합 요소 식별
|
||||
|
||||
```
|
||||
[시각화 적합 요소 분석 — X.X절]
|
||||
|
||||
▣ 시각화 적합 요소
|
||||
- 단계·순서가 있는 내용 : (해당 문장 또는 항목)
|
||||
- 비교·대조 내용 : (해당 문장 또는 항목)
|
||||
- 구성 요소·분류 내용 : (해당 문장 또는 항목)
|
||||
- 관계·연결 내용 : (해당 문장 또는 항목)
|
||||
|
||||
▣ 시각화 불필요 요소
|
||||
- 서술형 설명 내용 : 텍스트 본문 유지 권장
|
||||
```
|
||||
|
||||
#### 1-2. 레퍼런스 매칭
|
||||
|
||||
05-pre 라이브러리에서 가장 적합한 레퍼런스를 선택하십시오.
|
||||
|
||||
```
|
||||
[레퍼런스 매칭]
|
||||
|
||||
▣ 추천 레퍼런스 : [REF-XXX-00X]
|
||||
- 선택 이유 : 해당 레퍼런스의 어떤 특성이 이 절 내용과 맞는지
|
||||
- 참조할 요소 : 색상 / 레이아웃 / 연결 구조 / 타이포그래피 등
|
||||
|
||||
▣ 시각화 유형 : (예: 4단계 프로세스 흐름도)
|
||||
▣ 예상 구성 요소 수 : X개 블록
|
||||
```
|
||||
|
||||
편집장의 확인을 받고 다음 단계로 진행하십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 2. 시각화 구조 설계
|
||||
|
||||
확정된 유형과 레퍼런스를 기반으로 시각화의 구조를 설계하십시오.
|
||||
|
||||
```
|
||||
[시각화 구조 설계 — X.X절]
|
||||
|
||||
▣ 전체 레이아웃
|
||||
- 방향 : 가로형 / 세로형 / 방사형
|
||||
- 구성 : X개 블록, 연결 방식
|
||||
|
||||
▣ 블록별 내용 (본문에서 추출)
|
||||
- 블록 1 : 제목 텍스트 / 설명 텍스트
|
||||
- 블록 2 : 제목 텍스트 / 설명 텍스트
|
||||
(이하 동일)
|
||||
|
||||
▣ 적용 스타일
|
||||
- 색상 : 공통 스타일 가이드 기준
|
||||
- 폰트 : Noto Sans KR
|
||||
- 크기 : A4 삽입 기준 (가로 700px 이내)
|
||||
```
|
||||
|
||||
편집장의 확인을 받고 다음 단계로 진행하십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 3. HTML/CSS/JS 생성
|
||||
|
||||
확정된 구조 설계를 기반으로 완전한 HTML 파일을 생성하십시오.
|
||||
|
||||
#### 생성 기준
|
||||
|
||||
```
|
||||
- 단독 실행 가능한 완전한 HTML 파일
|
||||
- 외부 폰트 : Noto Sans KR (Google Fonts CDN)
|
||||
- 외부 라이브러리 : CDN 사용 (필요한 경우만)
|
||||
- 크기 : 가로 700px 이내 (A4 본문 삽입 기준)
|
||||
- 배경 : 흰색 (#ffffff)
|
||||
- 인쇄 대응 : @media print 스타일 포함
|
||||
```
|
||||
|
||||
#### 출력 형식
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html lang="ko">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>X.X절 시각화 — 제목</title>
|
||||
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@400;500;700&display=swap" rel="stylesheet">
|
||||
<style>
|
||||
/* 레퍼런스 기반 스타일 */
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<!-- 시각화 구조 -->
|
||||
<script>
|
||||
/* 필요한 경우만 */
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### STEP 4. 생성 결과 검토
|
||||
|
||||
HTML 생성 직후 아래 항목을 자동으로 검토하고 결과를 함께 제시하십시오.
|
||||
|
||||
```
|
||||
[시각화 검토 — X.X절]
|
||||
|
||||
✅ 내용 일치 : 본문 내용과 시각화 텍스트 일치 / 불일치 X건
|
||||
✅ 레퍼런스 반영 : 스타일 반영 완료 / 미반영 항목 X건
|
||||
✅ 공통 스타일 : 가이드 준수 / 위반 항목 X건
|
||||
✅ 기술 검토 : 단독 실행 가능 / 오류 X건
|
||||
✅ 크기 기준 : 700px 이내 준수 / 초과
|
||||
|
||||
⚠️ 수정 필요 항목 (있는 경우만)
|
||||
- 항목 : 사유 및 수정 제안
|
||||
```
|
||||
|
||||
편집장의 확인을 받고 최종 파일로 저장하십시오.
|
||||
|
||||
---
|
||||
|
||||
### STEP 5. 시각화 파일 명명 및 저장 보고
|
||||
|
||||
```
|
||||
[저장 완료]
|
||||
|
||||
▣ 파일명 : viz_X-X_절제목.html
|
||||
(예: viz_2-3_추진단계별역할.html)
|
||||
|
||||
▣ 삽입 위치 : X.X절 본문 [표 또는 항목] 다음
|
||||
▣ 크기 : 가로 Xpx × 세로 Xpx
|
||||
▣ 참조 레퍼런스 : [REF-XXX-00X]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 반복 실행
|
||||
|
||||
하나의 절 시각화가 완료되면 편집장의 지시에 따라 다음 절의 시각화를 동일한 STEP 1~5 순서로 진행하십시오. 공통 스타일 가이드는 모든 시각화에 일관되게 적용합니다.
|
||||
1000
02. Prompts/최종본/03-6-1. 내용 취합(본문,시각화) 및 전체 HTML 변환_Gemini (1).md
Normal file
1000
02. Prompts/최종본/03-6-1. 내용 취합(본문,시각화) 및 전체 HTML 변환_Gemini (1).md
Normal file
File diff suppressed because it is too large
Load Diff
259
02. Prompts/최종본/03-6-2. 프롬프트 설명서.md
Normal file
259
02. Prompts/최종본/03-6-2. 프롬프트 설명서.md
Normal file
@@ -0,0 +1,259 @@
|
||||
# 프롬프트 구조 및 내용 해설
|
||||
## (프롬프트) HTML 변환
|
||||
|
||||
---
|
||||
|
||||
## 이 프롬프트가 하는 일
|
||||
|
||||
04단계에서 완성된 본문 MD와 05단계에서 생성된 시각화 HTML 파일들을 하나의 보고서 HTML로 통합합니다. 이 HTML은 07단계 A4 보고서 퍼블리싱 렌더링 엔진(v82)의 직접 입력값이 됩니다.
|
||||
|
||||
단, 이 단계는 단순히 콘텐츠를 합치는 것이 아닙니다. 07단계 렌더링 엔진이 올바르게 동작하려면 특정 HTML 구조, CSS 스타일시트, JS 페이지네이션 엔진이 모두 포함되어야 합니다. 따라서 이 단계의 출력물은 **콘텐츠 통합 + 렌더링 인프라 탑재**를 동시에 수행한 완성형 HTML입니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 구성 한눈에 보기
|
||||
|
||||
| 순서 | 구성요소 | 역할 한 줄 요약 |
|
||||
|:---:|---------|--------------|
|
||||
| 1 | **절대 원칙** | 본문·시각화 내용 수정 금지 |
|
||||
| 2 | **역할 정의** | AI의 작업 태도 설정 + 07단계 엔진과의 관계 명시 |
|
||||
| 3 | **사전 준비** | 입력 파일 3가지 확인 |
|
||||
| 4 | **STEP 1** | 본문 목차와 시각화 파일 매핑 |
|
||||
| 5 | **STEP 2** | 표지·요약 내용 확인 |
|
||||
| 6 | **STEP 3-A** | 07단계 렌더링 엔진 6대 원칙 |
|
||||
| 7 | **STEP 3-B** | HTML 전체 구조 (raw-container + template + script) |
|
||||
| 8 | **STEP 3-C** | CSS 전문 — A4 렌더링 스타일시트 |
|
||||
| 9 | **STEP 3-D** | 본문 변환 규칙 — MD → HTML 매핑 |
|
||||
| 10 | **STEP 3-E** | 시각화 삽입 규칙 |
|
||||
| 11 | **STEP 3-F** | JS 렌더링 엔진 전문 — 페이지네이션 |
|
||||
| 12 | **STEP 3-G** | JS 엔진 동작 요약 표 |
|
||||
| 13 | **STEP 4** | 통합 결과 검토 (CSS/JS 포함 확인 추가) |
|
||||
| 14 | **STEP 5** | 최종 파일 출력 보고 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 절대 원칙
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
이 단계는 생성이 아닌 통합 단계입니다. 그런데 MD를 HTML로 변환하는 과정에서 AI가 가장 자주 저지르는 오류가 있습니다. 문장이 어색해 보이면 자연스럽게 다듬고, 긴 단락을 보기 좋게 요약하고, 중복처럼 보이는 문장을 슬쩍 삭제하는 것입니다. 이것은 모두 04단계에서 편집장이 확인하고 확정한 내용을 AI가 임의로 훼손하는 행위입니다.
|
||||
|
||||
"토씨 하나 바꾸지 않고"라는 표현은 이 원칙의 강도를 명확히 전달합니다. 오탈자가 있어도, 문장이 어색해도, 원본 그대로 옮기는 것이 이 단계의 유일한 임무입니다. 내용에 문제가 있다면 편집장이 판단하고 04단계로 돌아가서 수정해야 합니다. AI가 변환 과정에서 임의로 처리하면 안 됩니다.
|
||||
|
||||
시각화 HTML 코드를 수정하지 않는다는 원칙은 05단계에서 설계된 스타일과 구조가 삽입 과정에서 변형되는 것을 막습니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 역할 정의 — 07단계 엔진과의 관계를 명시하는 이유
|
||||
|
||||
**기존 해설에서 달라진 점**
|
||||
|
||||
기존 프롬프트는 "보고서 HTML 편집 전문가"라는 역할만 부여했습니다. 변경된 프롬프트는 여기에 07단계 렌더링 엔진(v82)이 어떤 구조를 요구하는지까지 미리 설명합니다.
|
||||
|
||||
**왜 이렇게 바뀌었는가**
|
||||
|
||||
06단계의 출력물은 사람이 읽는 문서가 아니라 07단계 JS 엔진이 처리하는 입력 데이터입니다. AI가 07단계 엔진의 요구사항을 모른 채 "보기 좋은 HTML"을 만들면, 정작 엔진이 파싱할 수 없는 구조가 나옵니다. 역할 정의에서 "이 HTML은 렌더링 엔진의 입력값"이라는 관계를 먼저 설정해야 이후 STEP 3의 구체적 지시들이 왜 그 형태여야 하는지 AI가 이해합니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. STEP 1 — 본문 목차와 시각화 파일 매핑
|
||||
|
||||
**왜 매핑 테이블을 먼저 만드는가**
|
||||
|
||||
시각화 파일이 여러 개일 때 어느 파일이 어느 절에 들어가는지 먼저 정리하지 않으면 삽입 누락이나 위치 오류가 발생합니다. 매핑 테이블을 편집장이 확인함으로써 삽입 위치가 의도와 맞는지 검증합니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. STEP 2 — 표지·요약 내용 확인
|
||||
|
||||
**표지와 요약을 이 단계에서 입력하는 이유**
|
||||
|
||||
표지의 작성자·날짜·소속은 문서 내용과 무관한 정보로 편집장이 직접 지정해야 합니다. 요약(Executive Summary)은 전체 본문이 완성된 이후에야 작성 가능한 내용입니다. 04단계에서 본문을 생성할 때는 전체가 완성되지 않은 상태이므로 이 단계에서 처음 입력합니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. STEP 3 — 통합 HTML 생성
|
||||
|
||||
STEP 3은 이 프롬프트의 핵심 단계이며, 7개 하위 절(3-A ~ 3-G)로 구성됩니다. 각 절이 존재하는 이유를 순서대로 해설합니다.
|
||||
|
||||
---
|
||||
|
||||
### 5-A. 렌더링 엔진 6대 원칙 (3-A)
|
||||
|
||||
**왜 06단계 프롬프트에 07단계 엔진의 동작 원칙을 미리 명시하는가**
|
||||
|
||||
06단계 AI가 HTML을 만들 때, 07단계 엔진이 어떤 규칙으로 페이지를 나누는지 모르면 엔진과 충돌하는 구조를 만들 수 있습니다. 예를 들어 엔진은 H1 태그에서만 페이지를 나누는데(H1 Only Break), AI가 H2에서도 `page-break-before`를 삽입하면 중복 분할이 발생합니다. AI가 표를 `<div>`로 감싸면 엔진의 Smart Fit(표 축소)이 해당 표를 감지하지 못합니다.
|
||||
|
||||
6대 원칙을 미리 보여주는 이유는 "이 규칙을 AI가 직접 구현하라"는 것이 아닙니다. "이 규칙이 이미 엔진에 구현되어 있으니, 당신은 엔진이 처리할 수 있는 깨끗한 구조만 만들라"는 뜻입니다. AI의 역할 경계를 명확히 하는 것입니다.
|
||||
|
||||
| 원칙 | 06단계 AI가 지켜야 할 사항 |
|
||||
|------|------------------------|
|
||||
| Deep Sanitization | box-content 안에 불필요한 class/style을 넣지 말 것 (엔진이 제거함) |
|
||||
| H1 Only Break | 페이지 나눔 관련 CSS를 삽입하지 말 것 (엔진이 처리함) |
|
||||
| Orphan Control | 제목 뒤에 빈 태그를 넣지 말 것 (엔진이 제목 위치를 자동 조정함) |
|
||||
| Smart Fit | 표/그림을 원본 크기 그대로 넣을 것 (엔진이 축소 판단함) |
|
||||
| Gap Filling | 빈 공간 채우기를 시도하지 말 것 (엔진이 자동 처리함) |
|
||||
| Visual Standard | 여백·캡션 위치를 직접 지정하지 말 것 (CSS가 처리함) |
|
||||
|
||||
---
|
||||
|
||||
### 5-B. HTML 전체 구조 (3-B)
|
||||
|
||||
**HTML이 3개 영역으로 나뉘는 이유**
|
||||
|
||||
변경된 프롬프트는 출력 HTML의 구조를 ① raw-container, ② page-template, ③ script 세 영역으로 명시합니다.
|
||||
|
||||
**① raw-container가 `display: none`인 이유**
|
||||
|
||||
raw-container는 화면에 직접 표시되는 영역이 아닙니다. JS 렌더링 엔진이 이 안의 콘텐츠를 읽어서 A4 페이지(.sheet)로 재조립한 뒤 body에 추가합니다. 렌더링이 완료되면 raw-container는 JS에 의해 삭제됩니다. 즉, 원본 데이터의 임시 저장소 역할입니다.
|
||||
|
||||
**② page-template이 `<template>` 태그인 이유**
|
||||
|
||||
HTML5의 `<template>` 태그는 브라우저가 렌더링하지 않지만 JS에서 `content.cloneNode(true)`로 복제할 수 있는 특수 태그입니다. 엔진이 A4 페이지를 하나 만들 때마다 이 템플릿을 복제하여 헤더·본문·푸터 구조를 가진 sheet를 생성합니다. 이 구조 덕분에 모든 페이지가 동일한 레이아웃을 유지합니다.
|
||||
|
||||
**box-cover / box-toc / box-summary / box-content 4개 박스로 나누는 이유**
|
||||
|
||||
07단계 엔진은 각 박스를 다른 방식으로 처리합니다. cover는 별도 레이아웃으로 표지를 생성하고, toc는 목차를 자동 그룹화하며, summary는 넘침 시 자간을 자동 압축하고, content는 H1 기준으로 페이지를 분할합니다. 4개 박스를 구분하지 않으면 엔진이 표지에 페이지 번호를 넣거나, 본문에 목차 압축 로직을 적용하는 등의 오동작이 발생합니다.
|
||||
|
||||
---
|
||||
|
||||
### 5-C. CSS 전문 (3-C)
|
||||
|
||||
**왜 CSS를 "수정하지 마십시오"로 고정하는가**
|
||||
|
||||
이 CSS는 단순한 스타일이 아니라 JS 렌더링 엔진과 밀접하게 연동된 설정값들을 포함합니다.
|
||||
|
||||
예를 들어 `.sheet`의 `width: 210mm; height: 297mm`는 A4 물리 규격이고, JS의 `CONFIG.maxHeight: 970`은 이 높이에서 상하 여백 20mm를 뺀 본문 가용 높이입니다. CSS에서 여백을 25mm로 바꾸면 JS의 maxHeight와 불일치하여 콘텐츠가 넘치거나 빈 공간이 생깁니다.
|
||||
|
||||
`.atomic-block`의 `break-inside: avoid`는 엔진의 Smart Fit 로직과 연동됩니다. `.highlight-box`의 스타일은 `detox()` 함수의 하이라이트 박스 감지 조건과 맞물립니다. 하나를 바꾸면 다른 쪽이 깨지는 구조이므로 CSS를 고정하는 것입니다.
|
||||
|
||||
**색상 체계(CSS Custom Properties)의 설계 의도**
|
||||
|
||||
`--primary: #006400`(짙은 녹색), `--accent: #228B22`(포레스트 그린), `--light-green: #E8F5E9`(연한 녹색)의 3단계 색상 체계는 보고서 전체의 시각적 통일성을 유지합니다. H1의 border-bottom, H2의 border-left, 표 헤더의 배경색이 모두 이 변수를 참조합니다. 색상을 바꾸고 싶다면 CSS 변수 값만 수정하면 전체 문서에 일괄 적용되도록 설계되어 있습니다.
|
||||
|
||||
**주요 CSS 구성 요소와 역할**
|
||||
|
||||
| CSS 영역 | 역할 | JS와의 연동 |
|
||||
|----------|------|-----------|
|
||||
| `.sheet` | A4 용지 규격 정의 | `CONFIG.maxHeight`와 연동 |
|
||||
| `.page-header`, `.page-footer` | 여백 20mm 내 헤더/푸터 배치 | `createPage()`가 텍스트 주입 |
|
||||
| `.body-content` | 본문 영역 위치 고정 | `renderFlow()`가 높이 측정 기준으로 사용 |
|
||||
| `h1, h2, h3` | 제목 스타일 + `white-space: nowrap` | 엔진의 제목 자동 축소 로직과 연동 |
|
||||
| `p, li` | 본문 텍스트 기본 스타일 | 엔진의 자간 최적화(Squeeze) 대상 |
|
||||
| `.toc-*` | 목차 레벨별 스타일 | `formatTOC()`가 클래스를 자동 부여 |
|
||||
| `.highlight-box` | 강조 박스 표준 스타일 | `detox()`의 박스 감지·변환 대상 |
|
||||
| `.atomic-block` | 분할 불가 블록 | 엔진이 통째로 다음 페이지로 이동 |
|
||||
| `.squeeze`, `.toc-squeeze` | 압축 모드 스타일 | 엔진이 넘침 감지 시 동적 적용 |
|
||||
| `#box-summary` 전용 스타일 | 요약 페이지 자간/행간 축소 | Smart Squeeze 로직과 연동 |
|
||||
| `@media print` | 인쇄 시 그림자 제거, 여백 초기화 | 브라우저 인쇄 → PDF 변환 대응 |
|
||||
|
||||
---
|
||||
|
||||
### 5-D. 본문 변환 규칙 (3-D)
|
||||
|
||||
**왜 box-content 안에 class/style을 붙이지 말라고 하는가**
|
||||
|
||||
JS 렌더링 엔진의 `detox()` 함수는 SVG, 목차, 표지, 하이라이트 박스를 제외한 모든 요소의 class와 style을 제거합니다. 06단계 AI가 열심히 `class="paragraph"` `style="color:blue"`를 붙여도 엔진이 전부 지워버립니다. 불필요한 작업을 지시하지 않기 위해 "붙이지 마십시오"로 명시합니다.
|
||||
|
||||
단, `highlight-box` 클래스는 예외입니다. `detox()`의 화이트리스트에 `highlight-`가 포함되어 있어 이 클래스는 보존됩니다. 04단계 본문에서 강조 박스로 지정된 영역이 있다면 `<div class="highlight-box">` 로 감싸야 합니다.
|
||||
|
||||
**`<!-- page X -->` 주석을 제거하는 이유**
|
||||
|
||||
04단계에서 절 단위로 생성할 때 AI가 페이지 구분 주석을 삽입하는 경우가 있습니다. 페이지 분할은 07단계 JS 엔진이 콘텐츠 높이를 측정하여 자동으로 수행하므로, 수동 페이지 마커는 불필요합니다. 남겨두면 엔진 동작에 영향을 주지는 않지만 raw-container에 불필요한 노드가 생겨 `getFlatNodes()`의 처리 효율이 떨어집니다.
|
||||
|
||||
---
|
||||
|
||||
### 5-E. 시각화 삽입 규칙 (3-E)
|
||||
|
||||
**`<figure class="atomic-block">`으로 감싸는 이유**
|
||||
|
||||
렌더링 엔진의 `renderFlow()` 함수는 노드 유형을 판별할 때 `FIGURE` 태그이거나 `atomic-block` 클래스를 가진 요소를 "분할 불가 블록"으로 인식합니다. 이 블록은 페이지를 넘어갈 경우 통째로 다음 페이지로 이동하며, Smart Fit 로직에 의해 15% 이내 넘침이면 85%로 축소됩니다.
|
||||
|
||||
시각화를 `<figure class="atomic-block">`으로 감싸지 않으면 엔진이 이를 일반 텍스트로 취급하여 중간에서 잘라버릴 수 있습니다. 차트나 다이어그램이 반으로 잘리는 것을 방지하기 위해 이 래핑이 필수입니다.
|
||||
|
||||
**`<figcaption>`으로 캡션을 배치하는 이유**
|
||||
|
||||
CSS에서 `figcaption`에 `text-align: center`와 `font-size: 9.5pt`가 지정되어 있습니다. 또한 `detox()` 함수는 `FIGURE` 태그 내부의 `h3, h4, .chart-title`을 `display: none`으로 숨깁니다. 이는 시각화 내부에 이미 제목이 있을 때 캡션과 중복되는 것을 방지하기 위한 로직입니다. 따라서 캡션은 시각화 내부 제목이 아닌 `<figcaption>` 태그로 통일해야 합니다.
|
||||
|
||||
**시각화의 `<style>`과 `<script>`를 이동하는 이유**
|
||||
|
||||
시각화 HTML 파일은 단독 실행을 위해 자체 `<style>`과 `<script>`를 포함합니다. 여러 시각화를 하나의 HTML에 합칠 때 이를 그대로 두면 스타일이 충돌하거나 스크립트가 중복 실행됩니다. `<style>`은 `<head>`로, `<script>`는 렌더링 엔진 `<script>` 앞으로 모아서 충돌을 방지합니다.
|
||||
|
||||
**클래스명에 절 번호 prefix를 붙이는 이유**
|
||||
|
||||
각 시각화가 `.container`, `.box` 같은 일반적인 클래스명을 사용할 경우, 여러 시각화를 합치면 서로의 스타일이 덮어씌워집니다. `.viz-1-2-container`처럼 절 번호를 prefix로 붙이면 각 시각화의 스타일이 독립적으로 유지됩니다.
|
||||
|
||||
---
|
||||
|
||||
### 5-F. JS 렌더링 엔진 전문 (3-F)
|
||||
|
||||
**왜 JS도 "수정하지 마십시오"로 고정하는가**
|
||||
|
||||
이 JS는 CSS의 수치, HTML의 id/class 명, 그리고 4개 박스 구조와 정밀하게 맞물려 동작합니다. 대표적인 의존 관계는 아래와 같습니다.
|
||||
|
||||
| JS 코드 | 의존 대상 |
|
||||
|---------|---------|
|
||||
| `CONFIG.maxHeight: 970` | CSS `.sheet` height 297mm - 상하 여백 40mm |
|
||||
| `document.getElementById('box-cover')` | HTML `<div id="box-cover">` |
|
||||
| `document.getElementById('page-template')` | HTML `<template id="page-template">` |
|
||||
| `node.classList.contains('highlight-box')` | CSS `.highlight-box` 스타일 |
|
||||
| `node.classList.contains('atomic-block')` | CSS `.atomic-block` break-inside 규칙 |
|
||||
| `body.classList.add('toc-squeeze')` | CSS `.toc-squeeze` 압축 스타일 |
|
||||
|
||||
JS를 수정하면 이 의존 관계가 깨져 페이지 분할 오류, 표지 누락, 목차 깨짐 등이 발생합니다. 06단계 AI의 역할은 엔진을 개선하는 것이 아니라, 엔진이 처리할 수 있는 콘텐츠를 만드는 것입니다.
|
||||
|
||||
**엔진의 핵심 함수별 역할**
|
||||
|
||||
| 함수 | 역할 | 실행 시점 |
|
||||
|------|------|---------|
|
||||
| `detox()` | 모든 요소의 class/style 제거 + 표준 스타일 재적용. SVG 내부 제외. 하이라이트 박스 자동 변환 | 노드 평탄화 시 각 요소에 적용 |
|
||||
| `formatTOC()` | box-toc 내 H1/H2/H3 분석 → toc-lvl-1/2/3 클래스 리스트 자동 생성 | getFlatNodes()에서 toc 처리 시 |
|
||||
| `getFlatNodes()` | 중첩된 div/section 구조를 평탄화하여 1차원 노드 배열로 변환 | renderFlow() 호출 전 |
|
||||
| `renderFlow()` | Place→Squeeze→Check→Split 4단계로 노드를 A4 페이지에 순차 배치 | 각 섹션(toc, summary, body) 렌더링 시 |
|
||||
| `createPage()` | page-template을 복제하여 새 A4 sheet 생성. cover는 별도 레이아웃 적용 | renderFlow()에서 페이지 넘침 시 |
|
||||
|
||||
---
|
||||
|
||||
### 5-G. JS 동작 요약 표 (3-G)
|
||||
|
||||
**왜 프롬프트 사용자에게 엔진 내부 동작을 설명하는가**
|
||||
|
||||
3-F의 JS 코드는 약 300줄이며, 프롬프트를 사용하는 사람(편집장)이 코드를 직접 읽을 것을 기대할 수 없습니다. 그러나 엔진이 어떤 순서로 무엇을 하는지 모르면 문제가 생겼을 때 원인을 파악할 수 없습니다.
|
||||
|
||||
예를 들어 "요약 페이지 글자가 너무 작다"는 문제가 발생했을 때, 동작 요약 표가 없으면 300줄 코드를 읽어야 합니다. 표가 있으면 "5번: summary에 Smart Squeeze 적용" → "CSS의 `.squeeze` 스타일 확인"으로 즉시 추적이 가능합니다.
|
||||
|
||||
이 표는 코드를 읽지 않아도 "무엇이 어떤 순서로 일어나는지"를 파악할 수 있게 해주는 디버깅 지도입니다.
|
||||
|
||||
---
|
||||
|
||||
## 6. STEP 4 — 통합 결과 검토
|
||||
|
||||
**기존 해설에서 달라진 점**
|
||||
|
||||
기존 검토 항목은 본문 누락, 시각화 삽입, 구조 태그, 목차 구조, 출처 태그의 5가지였습니다. 변경된 프롬프트에서는 3가지 항목이 추가되었습니다.
|
||||
|
||||
| 추가된 검토 항목 | 검증 대상 | 누락 시 발생하는 문제 |
|
||||
|---------------|---------|------------------|
|
||||
| **CSS 포함** | 3-C절의 A4 렌더링 스타일시트 전문 | 브라우저에서 열면 서식 없는 텍스트만 표시됨. JS 엔진이 높이 계산을 잘못하여 페이지 분할 오류 발생 |
|
||||
| **JS 포함** | 3-F절의 페이지네이션 렌더링 엔진 전문 | raw-container가 `display: none`인 채로 남아 화면에 아무것도 표시되지 않음 |
|
||||
| **폰트 임포트** | `@import url('...Noto+Sans+KR...')` | 시스템 기본 폰트로 렌더링되어 한글 자간·행간이 틀어지고, JS의 높이 측정값이 달라져 페이지 분할 위치가 어긋남 |
|
||||
|
||||
**`[근거없음]` 항목을 수정하지 않고 그대로 포함하는 이유**
|
||||
|
||||
`[근거없음]`으로 표기된 항목은 편집장이 추가 자료로 보완할지, 해당 내용을 삭제할지 판단해야 하는 항목입니다. AI가 임의로 처리하지 않고 편집장에게 알려서 최종 판단을 받습니다.
|
||||
|
||||
---
|
||||
|
||||
## 7. STEP 5 — 최종 파일 출력 보고
|
||||
|
||||
**기존 해설에서 달라진 점**
|
||||
|
||||
기존 출력 보고에는 장·절 수, 시각화 수, 표지·목차·요약 포함 여부만 있었습니다. 변경된 프롬프트에서는 CSS 포함 여부와 JS 포함 여부가 추가되었습니다.
|
||||
|
||||
**CSS/JS 포함을 출력 보고에 명시하는 이유**
|
||||
|
||||
이전 프롬프트에서 06단계 출력물은 콘텐츠만 담긴 HTML이었고, CSS와 JS는 07단계에서 별도로 적용하는 구조였습니다. 변경된 프롬프트에서는 06단계 출력물 자체가 완성형 HTML(콘텐츠 + CSS + JS)입니다. 따라서 출력 보고에 "이 파일을 브라우저에서 열면 A4 보고서가 자동 렌더링됩니다"라는 안내와 함께 CSS/JS 탑재 여부를 확인 항목으로 포함합니다.
|
||||
|
||||
**다음 단계 안내가 달라진 이유**
|
||||
|
||||
기존에는 "07 A4 보고서 퍼블리싱 프롬프트에 이 HTML을 입력하십시오"였습니다. 변경된 프롬프트에서는 렌더링 엔진이 이미 HTML에 포함되어 있으므로, "이 HTML을 브라우저에서 열면 A4 보고서가 자동 렌더링됩니다. Chrome 인쇄(Ctrl+P)로 PDF 저장이 가능합니다"로 안내가 바뀌었습니다. 즉, 07단계가 별도의 AI 작업이 아니라 브라우저 실행으로 대체되는 구조입니다.
|
||||
1021
02. Prompts/최종본/03-7-1. 보고서 형식(A4 규격)으로 변환_Gemini.md
Normal file
1021
02. Prompts/최종본/03-7-1. 보고서 형식(A4 규격)으로 변환_Gemini.md
Normal file
File diff suppressed because it is too large
Load Diff
187
02. Prompts/최종본/03-7-2. 프롬프트 설명서.md
Normal file
187
02. Prompts/최종본/03-7-2. 프롬프트 설명서.md
Normal file
@@ -0,0 +1,187 @@
|
||||
# (프롬프트) A4 규격 보고서 형식으로 변환 (HTML)
|
||||
|
||||
Gemini 등 생성형 AI가 문서를 분석하면, 결과물은 페이지 구분 없이 내용이 쭉 이어지는 HTML 파일로 나옵니다.
|
||||
이 프롬프트는 그 HTML을 받아 **표지 → 목차 → 요약 → 본문** 순서의 A4 규격 보고서 형태로 재조립하는 변환 도구입니다.
|
||||
출력물은 브라우저에서 바로 인쇄하거나 PDF로 저장할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 구성 한눈에 보기
|
||||
|
||||
| 순서 | 구성요소 | 역할 한 줄 요약 |
|
||||
|:---:|---------|--------------|
|
||||
| 1 | **페르소나** | AI의 작업 태도와 판단 기준 설정 |
|
||||
| 2 | **원칙 0** | 내용 손실 방지 — 절대 규칙 |
|
||||
| 3 | **원칙 1** | 레이아웃 품질 기준 — 6가지 규칙 |
|
||||
| 4 | **제작가이드 가** | 보고서 외형 설계 (CSS) |
|
||||
| 5 | **제작가이드 나** | 콘텐츠 입력 공간 정의 (Body 구조) |
|
||||
| 6 | **제작가이드 다** | 실제 변환 처리 로직 (JS 엔진) |
|
||||
| 7 | **실행 순서** | 전체 처리 흐름 제어 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 페르소나 — AI의 작업 태도 설정
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
'지능형 퍼블리싱 아키텍트'라는 역할을 AI에게 부여합니다.
|
||||
구체적으로는 두 가지 행동 방식을 강제합니다.
|
||||
"스타일 독소 제거" 지시는 원본 HTML의 디자인을 무시하고 A4 기준으로 새로 입히도록 유도하고,
|
||||
"복사기처럼 보존 / 강박증 수준으로 맞춤"이라는 표현은 내용은 절대 건드리지 말고 레이아웃만 정밀하게 처리하라는 이중 명령입니다.
|
||||
|
||||
**왜 가장 먼저 오는가**
|
||||
|
||||
AI는 프롬프트를 위에서부터 순서대로 읽고 이후 내용을 해석합니다.
|
||||
페르소나가 먼저 정의되어야 그 뒤에 나오는 원칙과 코드를 "어떤 태도로" 수행해야 하는지 기준이 생깁니다.
|
||||
페르소나를 뒤에 두면 AI가 앞의 원칙들을 해석할 때 기준이 없어 느슨하게 적용할 가능성이 높아집니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 원칙 0 — 내용 손실 방지
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
AI가 HTML을 처리하는 과정에서 자주 발생하는 문제인 "내용 요약, 생략, 임의 수정"을 차단합니다.
|
||||
"복사기 모드"라는 단어는 AI에게 편집자가 아닌 복사 도구로 동작하도록 행동 방식을 제한하고,
|
||||
"토씨 하나 바꾸지 않는다"는 표현은 표의 수치나 문장이 변경되는 것을 명시적으로 금지합니다.
|
||||
|
||||
**왜 원칙 1과 분리되어 있는가**
|
||||
|
||||
원칙 0은 이 프롬프트 전체에서 어떤 경우에도 예외 없이 지켜야 하는 절대 규칙이고,
|
||||
원칙 1은 레이아웃 품질에 관한 기술적 규칙으로 상황에 따라 판단이 개입될 수 있습니다.
|
||||
두 가지를 같은 레벨에 두면 AI가 레이아웃 최적화를 위해 내용을 임의로 조정하는 판단 오류가 생길 수 있어, 우선순위를 명확히 분리한 것입니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 원칙 1 — 레이아웃 품질 기준 (6가지)
|
||||
|
||||
**렌더링이란**
|
||||
|
||||
HTML 코드를 사람이 볼 수 있는 화면으로 표시하는 과정을 렌더링이라 합니다.
|
||||
이 프롬프트에서는 HTML 코드를 A4 용지 형태의 보고서로 표시하는 것이 렌더링에 해당합니다.
|
||||
|
||||
**왜 6가지인가**
|
||||
|
||||
6개는 임의로 정한 숫자가 아닙니다. 실제 변환 작업 과정에서 반복적으로 발생한 레이아웃 문제들을 해결하며 버전을 거듭하는 과정에서 수렴된 규칙들입니다. 각각이 실제로 발생하는 특정 문제에 대응합니다.
|
||||
|
||||
**각 규칙이 해결하는 실제 문제**
|
||||
|
||||
| 규칙 | 없으면 발생하는 문제 |
|
||||
|------|-----------------|
|
||||
| Deep Sanitization | Gemini 출력 HTML의 색상·글자크기가 A4 디자인을 덮어씌워 보고서 외형이 망가짐 |
|
||||
| H1 Only Break | 모든 소제목에서 페이지가 나뉘어 페이지 수가 과도하게 늘거나, 아무데서도 안 나뉘어 내용이 뭉침 |
|
||||
| Orphan Control | 소제목만 페이지 맨 아래에 홀로 남고 내용은 다음 페이지에 있는 어색한 구성 발생 |
|
||||
| Smart Fit | 표·그림이 페이지를 조금만 넘어도 다음 페이지로 밀려나 현재 페이지 하단이 텅 빔 |
|
||||
| Gap Filling | 그림이 다음 페이지로 넘어가면서 현재 페이지 하단에 불필요한 공백 발생 |
|
||||
| Visual Standard | 여백과 캡션 위치 기준이 없어 페이지마다 정렬이 제각각 |
|
||||
|
||||
**왜 원칙 0 다음에 오는가**
|
||||
|
||||
내용 보존(원칙 0)이 확보된 이후에 레이아웃 품질(원칙 1)을 논의하는 것이 논리적 순서입니다.
|
||||
레이아웃 규칙을 먼저 두면 AI가 레이아웃 최적화를 위해 원칙 0을 희생하는 판단을 할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 제작가이드 가 — 보고서 외형 설계 (CSS)
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
보고서의 시각적 외형 전체를 코드로 정의합니다. 글자 크기, 색상, 여백, 제목 스타일, 표 디자인 등이 여기서 결정됩니다. AI는 앞서 배운 원칙들을 이 CSS 설계도를 기반으로 구현합니다.
|
||||
|
||||
**주요 항목과 영향**
|
||||
|
||||
| CSS 항목 | 보고서에서의 영향 |
|
||||
|---------|---------------|
|
||||
| `:root` 색상 변수 | `--primary: #006400` 한 줄을 바꾸면 보고서 전체 색상 테마가 변경됨 |
|
||||
| `.sheet` | A4 용지 1장의 물리적 크기(210mm × 297mm) 고정 |
|
||||
| `.body-content` | 본문 작업 영역을 상하좌우 20mm 여백 안쪽으로 제한 |
|
||||
| `h1, h2, h3` | 제목 계층별 글자 크기와 색상을 차별화하여 가독성 확보 |
|
||||
| `.highlight-box` | 강조 박스의 배경색·테두리·글자 크기 통일 |
|
||||
| `.squeeze` | 요약 페이지가 약간 넘칠 때 자동 압축 적용 (행간·자간 축소) |
|
||||
|
||||
**왜 Body 구조(나) 보다 먼저 오는가**
|
||||
|
||||
CSS가 먼저 선언되어야 그 다음에 나오는 HTML 구조와 JS 엔진이 스타일을 참조할 수 있습니다.
|
||||
HTML → JS 순서로 실행되는 웹 브라우저의 기술적 특성 때문에 이 순서는 변경이 불가합니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 제작가이드 나 — 콘텐츠 입력 공간 (Body 구조)
|
||||
|
||||
**이 프롬프트에서 하는 역할**
|
||||
|
||||
원본 HTML을 역할별로 분리하여 주입할 수 있는 4개의 전용 공간을 정의합니다.
|
||||
AI에게 "원본 내용을 이 4개 박스에 나눠 담아라"는 입력 인터페이스 역할을 합니다.
|
||||
|
||||
**4개 박스의 역할**
|
||||
|
||||
| 박스 | 담기는 내용 | 처리 방식 |
|
||||
|-----|----------|---------|
|
||||
| `#box-cover` | 문서 제목, 부제, 작성 정보 | 중앙 정렬 표지로 생성 |
|
||||
| `#box-toc` | 목차 | 3계층 목차로 자동 포맷 |
|
||||
| `#box-summary` | 요약 내용 | 1페이지 압축 우선 적용 |
|
||||
| `#box-content` | 본문 전체 | 페이지 분할 렌더링 |
|
||||
|
||||
**`<template>`의 역할**
|
||||
|
||||
JS 엔진이 새 페이지가 필요할 때마다 이 템플릿을 복제하여 A4 용지를 찍어냅니다. 머리말·본문 영역·꼬리말 구조가 매 페이지에 동일하게 적용되는 것이 이 구조 덕분입니다.
|
||||
|
||||
---
|
||||
|
||||
## 6. 제작가이드 다 — 실제 변환 처리 로직 (JS 엔진)
|
||||
|
||||
**왜 세분화되어 있는가**
|
||||
|
||||
변환 처리는 하나의 거대한 코드 덩어리가 아니라 역할이 분리된 함수들의 조합입니다.
|
||||
각 함수가 독립된 하나의 임무만 수행하도록 설계되어 있어 오류 발생 시 해당 함수만 수정할 수 있습니다.
|
||||
|
||||
**다-1. 초기화 및 설정**
|
||||
|
||||
렌더링을 시작하기 전에 기준값을 먼저 세팅합니다.
|
||||
`maxHeight: 970`은 A4 용지(297mm)에서 상하 여백(각 20mm)을 뺀 본문 가용 높이를 픽셀로 환산한 값으로, 이후 모든 페이지 분할 판단의 기준이 됩니다.
|
||||
`await document.fonts.ready`는 웹폰트가 완전히 로드된 후 실행을 시작하도록 대기시킵니다. 폰트가 로드되기 전 실행하면 글자 너비 계산이 틀려 페이지 분할 위치가 어긋납니다.
|
||||
|
||||
**다-2. Sanitizer (detox 함수)**
|
||||
|
||||
Gemini 출력 HTML에 포함된 Tailwind CSS·인라인 스타일을 제거하고 A4 CSS 엔진과 충돌하지 않는 상태로 세탁합니다. 이 처리가 없으면 원본의 색상·글자크기·여백이 A4 디자인을 덮어씌웁니다. SVG(차트·그래프) 내부는 구조가 복잡하여 건드리면 깨지므로 예외 처리합니다.
|
||||
|
||||
**다-3. 목차 포매터 (formatTOC 함수)**
|
||||
|
||||
원본 HTML의 제목 태그(H1/H2/H3)를 읽어 3계층 목차를 자동 생성합니다. 원본 목차 구조의 품질과 무관하게 항상 일정한 형태의 목차 페이지가 출력됩니다.
|
||||
|
||||
**다-4. 노드 평탄화 처리 (getFlatNodes 함수)**
|
||||
|
||||
HTML은 div 안에 section 안에 article처럼 중첩 구조로 되어 있습니다. 이를 렌더링 엔진이 하나씩 배치할 수 있는 단위 블록들의 목록으로 풀어냅니다. 이 처리 없이는 중첩 구조 때문에 페이지 분할 위치를 계산할 수 없습니다.
|
||||
|
||||
**다-5. 핵심 렌더링 엔진 (renderFlow 함수)**
|
||||
|
||||
콘텐츠를 A4 용지에 실제로 배치하는 핵심 처리입니다. **배치 → 자간 최적화 → 넘침 감지 → 분할 또는 이동**의 4단계로 동작하며, 원칙 1의 6가지 규칙이 코드로 구현되는 곳입니다.
|
||||
|
||||
**다-6. 페이지 생성기 (createPage 함수)**
|
||||
|
||||
렌더링 엔진이 "새 페이지 필요"를 판단하면, 이 함수가 실제 A4 용지 한 장을 생성합니다. 표지·목차·본문에 따라 레이아웃이 다르게 적용됩니다.
|
||||
|
||||
---
|
||||
|
||||
## 7. 실행 순서 — 전체 처리 흐름 제어
|
||||
|
||||
**왜 마지막에 오는가**
|
||||
|
||||
실행 순서는 앞서 정의된 CSS·HTML 구조·JS 함수들을 모두 호출하는 총괄 지휘 역할입니다. 구성 요소들이 모두 정의된 이후에 실행되어야 하기 때문에 가장 마지막에 위치합니다.
|
||||
|
||||
**처리 순서와 각 단계의 이유**
|
||||
|
||||
```
|
||||
① 표지 생성 → 항상 첫 페이지. 순서 변경 불가
|
||||
② 목차 렌더링 → 페이지 번호 제외. 본문보다 반드시 앞에 위치
|
||||
③ 요약 압축 사전 측정 → 렌더링 전에 미리 1페이지 초과 여부를 계산.
|
||||
렌더링 이후에는 수정 불가하여 이 순서가 필수
|
||||
④ 요약 렌더링 → 압축 처리 결과를 적용하여 출력
|
||||
⑤ 본문 렌더링 → 페이지 번호 시작. 가장 많은 처리 시간 소요
|
||||
⑥ 긴 제목 자동 축소 → 렌더링 완료 후 가로로 넘치는 제목을 축소
|
||||
⑦ 자간 통합 조정 → 전체 페이지를 대상으로 자간 최적화 1회 추가 적용
|
||||
⑧ 마지막 페이지 병합 → 마지막 페이지 내용이 3줄 이하이면 앞 페이지에 합쳐 페이지 낭비 방지
|
||||
⑨ 원본 데이터 삭제 → raw-container를 화면에서 제거하여 최종 출력물만 표시
|
||||
```
|
||||
|
||||
③번 "요약 압축 사전 측정"이 별도 단계로 존재하는 이유는, 요약 페이지가 1페이지를 소폭 초과할 때 강제로 2페이지로 넘기지 않고 글자 크기·행간을 미리 조정하여 1페이지 안에 맞추기 위해서입니다. 렌더링이 완료된 이후에는 이 조정이 불가능하여 반드시 렌더링 전에 처리합니다.
|
||||
227
02. Prompts/최종본/03. AI 활용 보고서 작성(7step) _ (개요) 내용 요약 (1).md
Normal file
227
02. Prompts/최종본/03. AI 활용 보고서 작성(7step) _ (개요) 내용 요약 (1).md
Normal file
@@ -0,0 +1,227 @@
|
||||
# AI 기반 문서 생성 프로세스 — 프롬프트 모음
|
||||
|
||||
## 개요
|
||||
|
||||
기존 자료를 바탕으로 보고서·기획서·기술문서를 생성하기 위한 단계별 AI 프롬프트 모음입니다.
|
||||
각 단계는 독립적인 AI 작업 단위로 구성되며, 이전 단계의 출력물이 다음 단계의 입력값으로 연결되는 파이프라인 구조입니다.
|
||||
각 프롬프트 파일에는 실제 AI에게 전달하는 지시문과, 해당 지시문의 구조와 이유를 설명하는 해설 파일이 쌍으로 구성되어 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 전체 프로세스
|
||||
|
||||
```
|
||||
내부 자료 (PDF, PPT, DOCX 등)
|
||||
↓
|
||||
[01] 파일 내용 추출 → MD + JSON
|
||||
↓
|
||||
[02] 문서 구조 설계 → 목차 + 출처 설계서 JSON
|
||||
↓
|
||||
[03] 외부 자료 조사 → 보완된 설계서 JSON
|
||||
↓
|
||||
[04] 본문 생성 및 검토 → 최종 본문 MD
|
||||
↓
|
||||
[05-pre] 시각화 레퍼런스 정리 → 레퍼런스 라이브러리 JSON
|
||||
↓
|
||||
[05] 시각화 생성 → 절별 시각화 HTML 파일
|
||||
↓
|
||||
[06] 내용 취합 및 HTML 변환 → 통합 보고서 HTML
|
||||
↓
|
||||
[07] A4 보고서 퍼블리싱 → A4 규격 보고서 HTML (인쇄·PDF 저장 가능)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 단계별 프롬프트
|
||||
|
||||
---
|
||||
|
||||
### 01. 파일 내용 추출
|
||||
`사용 AI : Gemini, Claude`
|
||||
|
||||
기존 문서에서 텍스트와 표를 있는 그대로 추출합니다.
|
||||
추론·요약·수정 없이 원본 그대로를 MD와 JSON으로 출력하는 것이 핵심입니다.
|
||||
Top-to-Bottom 순차 추출, Visual Grid Rule(선 기반 표 병합)이 핵심 원칙입니다.
|
||||
|
||||
**지원 형식** : `.pdf` `.ppt/x` `.doc/x` `.png` `.jpg` `.md` `.txt`
|
||||
|
||||
> 🚨 **HWP/HWPX 처리 불가** : 한컴 독자 포맷으로 AI가 직접 읽을 수 없음. 사전에 PDF 또는 DOCX로 변환 필요.
|
||||
> 🚨 **이미지 추출 불가** : AI는 문서 내 이미지를 파일로 저장할 수 없음. 위치 표시(주석 태그)만 가능하며 실제 추출은 코드로 별도 처리 필요.
|
||||
|
||||
---
|
||||
|
||||
### 02. 문서 구조 설계
|
||||
`사용 AI : GPT`
|
||||
|
||||
업로드된 자료를 분석하여 보고서의 목차를 설계하고, 각 목차 항목별 핵심 내용과 출처를 함께 정리합니다.
|
||||
자료에 근거가 없는 항목은 `[근거없음]`, 자료 간 내용이 다를 경우 `[상충]` 태그로 명시합니다.
|
||||
확정된 구조는 JSON으로 출력되어 이후 단계의 공통 입력값이 됩니다.
|
||||
|
||||
---
|
||||
|
||||
### 03. 외부 자료 조사
|
||||
`사용 AI : Perplexity, Liner`
|
||||
|
||||
확정된 목차를 기준으로 내부 자료만으로 부족한 항목을 외부에서 보완 조사합니다.
|
||||
AI가 검색 쿼리를 설계하면 작성자가 직접 검색 후 결과를 붙여넣는 방식으로 운용합니다.
|
||||
|
||||
- Perplexity : 최신 통계·동향·정책 조사
|
||||
- Liner : 논문·전문 보고서·기술 자료 조사
|
||||
|
||||
> ⚠️ AI가 Perplexity·Liner를 직접 실행할 수 없어 수동 운용이 필요합니다.
|
||||
|
||||
---
|
||||
|
||||
### 04. 본문 생성 및 검토
|
||||
`사용 AI : Skywork, Gemini, Genspark`
|
||||
|
||||
구조 설계서(내부 자료 + 외부 조사 결과)를 기반으로 절(Section) 단위로 본문을 생성합니다.
|
||||
생성 직후 미니 검토(출처·문체·중복·수치), 전체 완성 후 전체 맥락 검토(흐름·중복·문체통일)의 2단계 검토를 수행합니다.
|
||||
문체는 보고체(간결체) 고정입니다.
|
||||
|
||||
---
|
||||
|
||||
### 05-pre. 시각화 레퍼런스 정리
|
||||
`사용 AI : Genspark`
|
||||
|
||||
시각화 생성에 앞서 작성자가 업로드한 이미지·HTML 파일을 분석하여 스타일·구조 패턴을 정리합니다.
|
||||
레퍼런스의 내용이 아닌 스타일과 레이아웃 구조만 추출하며, 공통 스타일 가이드를 함께 구축합니다.
|
||||
분석 결과는 JSON으로 출력되어 05단계의 입력값이 됩니다.
|
||||
|
||||
---
|
||||
|
||||
### 05. 시각화 생성
|
||||
`사용 AI : Genspark, Gemini`
|
||||
|
||||
05-pre에서 구축된 레퍼런스 라이브러리의 스타일을 참조하여, 절 본문 내용을 HTML/CSS/JS로 시각화합니다.
|
||||
텍스트는 100% 본문에서만 가져오며 레퍼런스의 내용을 유입시키지 않습니다.
|
||||
A4 삽입 기준(가로 700px 이내)과 인쇄 대응(`@media print`)을 포함합니다.
|
||||
|
||||
---
|
||||
|
||||
### 06. 내용 취합(본문·시각화) 및 전체 HTML 변환
|
||||
`사용 AI : Claude, GPT`
|
||||
|
||||
04단계 본문 MD와 05단계 시각화 HTML 파일들을 하나의 보고서 HTML로 통합합니다.
|
||||
표지·목차·요약이 이 단계에서 추가됩니다.
|
||||
|
||||
> **핵심 원칙** : 본문 텍스트를 추론·생성·삭제·요약·수정하지 않습니다. 변환이지 편집이 아닙니다. 오탈자가 있어도 원본 그대로 옮깁니다.
|
||||
|
||||
출력물은 07단계 A4 퍼블리싱 엔진이 처리할 수 있는 4개 박스 구조(box-cover / box-toc / box-summary / box-content)로 구성됩니다.
|
||||
|
||||
---
|
||||
|
||||
### 07. A4 보고서 퍼블리싱
|
||||
`사용 AI : Gemini`
|
||||
|
||||
06단계 통합 HTML을 A4 규격(210×297mm) 보고서 형태로 재조립합니다.
|
||||
표지 → 목차 → 요약 → 본문 순서로 렌더링하며, 페이지 분할·표 배치·자간 최적화를 자동 처리합니다.
|
||||
브라우저에서 인쇄하거나 PDF로 저장할 수 있는 최종 출력물을 생성합니다.
|
||||
|
||||
---
|
||||
|
||||
## 한계 및 제약 사항
|
||||
|
||||
### 출력 형식의 한계
|
||||
|
||||
AI 프롬프트만으로 생성 가능한 최종 파일 형식은 HTML에 한정됩니다.
|
||||
|
||||
| 형식 | 가능 여부 | 현재 대안 |
|
||||
|------|---------|---------|
|
||||
| PDF | ✅ 브라우저 인쇄 → PDF 저장 (Chrome 권장) | — |
|
||||
| HWP | ❌ AI 직접 생성 불가 | 수동 복사 또는 LibreOffice 변환 |
|
||||
| PPTX | ❌ AI 직접 생성 불가 | python-pptx 별도 코드 필요 |
|
||||
| XLSX | ❌ AI 직접 생성 불가 | openpyxl 별도 코드 필요 |
|
||||
| 이미지 추출 | ❌ AI 직접 추출 불가 | PyMuPDF 별도 코드 필요 |
|
||||
|
||||
### 운용상의 한계
|
||||
|
||||
**단계 간 연결이 수동이다** : 각 단계의 출력물을 작성자가 직접 복사하여 다음 단계 AI에 붙여넣어야 합니다.
|
||||
|
||||
**외부 검색이 수동이다** : Perplexity·Liner 검색은 AI가 직접 실행할 수 없어 작성자가 수행 후 결과를 붙여넣어야 합니다.
|
||||
|
||||
**HWP 입력 불가** : 내부 자료가 HWP 형식인 경우 PDF 또는 DOCX로 사전 변환이 필요합니다.
|
||||
|
||||
**컨텍스트 한계** : 분량이 긴 문서를 한 번에 생성하면 AI의 처리 품질이 저하됩니다. 이것이 04단계에서 절 단위 생성이 필수인 이유입니다.
|
||||
|
||||
**문서 유형 고정** : 현재 프롬프트는 보고서 형식과 보고체 문체에 최적화되어 있습니다. 제안서·기획안 등 다른 유형을 처리하려면 프롬프트 구조를 수동으로 수정해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 추가로 필요한 기능과 그 이유
|
||||
|
||||
현재 프로세스는 AI 프롬프트 단위의 수작업 파이프라인입니다. 반복 사용과 품질 안정화를 위해 아래 기능들이 보완되어야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 1. HWP 전처리 모듈
|
||||
|
||||
**왜 필요한가** : 국내 공공기관·건설업계의 내부 자료 대부분은 HWP 형식입니다. 현재는 01단계 실행 전에 작성자가 수동으로 PDF 변환을 해야 하며, 변환 과정에서 표 구조나 레이아웃이 손상되는 경우가 빈번합니다. pyhwpx 또는 LibreOffice CLI를 활용한 자동 변환 모듈이 없으면 이 프로세스의 입력 범위가 실무 환경과 괴리됩니다.
|
||||
|
||||
---
|
||||
|
||||
### 2. 이미지 추출 전처리 모듈
|
||||
|
||||
**왜 필요한가** : 01단계에서 AI는 이미지의 위치만 주석으로 표시할 뿐 파일 추출은 불가합니다. 도면·그래프·사진이 포함된 기술 문서는 이미지 없이는 보고서가 불완전합니다. PyMuPDF 기반의 이미지 추출 모듈이 별도로 존재해야 01단계 결과물이 완결성을 가집니다.
|
||||
|
||||
---
|
||||
|
||||
### 3. 단계 간 파이프라인 자동 연결
|
||||
|
||||
**왜 필요한가** : 현재는 각 단계 AI의 출력물(MD, JSON, HTML)을 작성자가 수동으로 복사하여 다음 단계 AI에 붙여넣어야 합니다. 이 반복 작업은 실수와 피로를 유발하며, 대량 문서 처리 시 병목이 됩니다. n8n 등의 워크플로우 도구를 통해 단계별 출력물이 자동으로 다음 단계 입력으로 전달되는 오케스트레이션이 필요합니다.
|
||||
|
||||
---
|
||||
|
||||
### 4. 외부 조사 도구 자동 연동
|
||||
|
||||
**왜 필요한가** : 03단계에서 AI가 설계한 검색 쿼리를 Perplexity·Liner에서 실행하는 것은 작성자의 수동 작업입니다. 이 단계가 수동인 한 프로세스 자동화는 이 지점에서 반드시 끊깁니다. Perplexity API 또는 웹 검색 기능을 AI가 직접 호출하여 결과를 구조 설계서 JSON에 자동 병합하는 기능이 필요합니다.
|
||||
|
||||
---
|
||||
|
||||
### 5. 파일 형식 변환 모듈 (HWP·PPTX·XLSX 출력)
|
||||
|
||||
**왜 필요한가** : 최종 출력물이 HTML과 PDF에 한정되어 실무 제출 형식과 불일치하는 경우가 많습니다. HWP 제출이 요구되는 공공기관 보고서, PPTX 형식의 발표 자료, XLSX 형식의 실적 정리표 등은 현재 프로세스로 생성이 불가합니다. python-pptx, openpyxl, LibreOffice 변환 등 코드 기반 후처리 모듈이 없으면 최종 납품물 생성 단계에서 다시 수작업이 개입됩니다.
|
||||
|
||||
---
|
||||
|
||||
### 6. 문서 유형별 프롬프트 세트 분리
|
||||
|
||||
**왜 필요한가** : 현재 02~04단계 프롬프트는 보고서 형식과 보고체 문체에 고정되어 있습니다. 기획안은 목차 구조가 다르고, 제안서는 설득형 문체가 필요하며, 기술보고서는 수식·도면 참조 방식이 다릅니다. 문서 유형이 달라질 때마다 프롬프트 전체를 수정해야 한다면 반복 활용성이 크게 떨어집니다. 유형별로 특화된 프롬프트 세트가 별도로 구성되어야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 7. 시각화 템플릿 라이브러리
|
||||
|
||||
**왜 필요한가** : 05-pre 단계에서 매번 레퍼런스 이미지나 HTML을 새로 업로드하고 분석하는 과정은 반복 작업입니다. 프로세스 흐름도, 단계별 구조도, 비교표, 개념 관계도 등 자주 사용되는 시각화 유형을 사전에 HTML 템플릿으로 제작하여 라이브러리로 관리하면, 05단계에서 레퍼런스 분석 없이 바로 템플릿을 참조할 수 있습니다. 현재의 05-pre 단계를 생략하거나 간소화할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
### 8. 프롬프트 버전 관리
|
||||
|
||||
**왜 필요한가** : 각 단계의 프롬프트는 실제 사용 결과에 따라 지속적으로 개선됩니다. 어떤 버전의 프롬프트로 어떤 결과물이 만들어졌는지 추적이 되지 않으면, 개선이 퇴행인지 진보인지 판단할 수 없습니다. 프롬프트 파일의 버전 번호 관리와 변경 이력 기록이 필요합니다.
|
||||
|
||||
---
|
||||
|
||||
## 파일 구성
|
||||
|
||||
```
|
||||
prompts/
|
||||
├── 01. 기존 문서에서 텍스트,표 추출_Gemini,Claude.md
|
||||
├── 02. 업로드 문서 기반 목차 구성_GPT.md
|
||||
├── 03. 목차에 해당하는 외부 자료 조사_perplexity,liner.md
|
||||
├── 04. 본문 생성 및 검토_skywork,gemini,genspark.md
|
||||
├── 05-pre. 시각화 레퍼런스 정리_Genspark.md
|
||||
├── 05. 본문의 구조화,시각화 생성_Genspark,Gemini.md
|
||||
├── 06. 내용 취합(본문,시각화) 및 전체 HTML 변환.md
|
||||
└── 07. A4 규격 보고서 형식으로 변환_Gemini.md
|
||||
|
||||
explanations/
|
||||
├── 프롬프트 구조 및 내용 해설 (1).md ← 07단계 해설
|
||||
├── 프롬프트 구조 및 내용 해설 (2).md ← 01단계 해설 (파일 형식 제한 포함)
|
||||
├── 프롬프트 구조 및 내용 해설 (3).md ← 02단계 해설
|
||||
├── 프롬프트 구조 및 내용 해설 (4).md ← 03단계 해설
|
||||
├── 프롬프트 구조 및 내용 해설 (5).md ← 04단계 해설
|
||||
├── 프롬프트 구조 및 내용 해설 (6).md ← 05-pre 단계 해설
|
||||
├── 프롬프트 구조 및 내용 해설 (7).md ← 05단계 해설
|
||||
└── 프롬프트 구조 및 내용 해설 (8).md ← 06단계 해설
|
||||
```
|
||||
Reference in New Issue
Block a user