🤖 LLM 기반 업무 자동화 프롬프트 패키지

Meeting Summary Automation using Prompt Engineering

📚 AI 활용 업무 자동화 프로젝트

Prompt Engineering를 활용하여 회의록 요약 업무를 자동화하고,
LLM 모델을 비교·평가하여 최적의 업무용 프롬프트를 설계한 프로젝트입니다.

프로젝트를 chapter별로 나누어 README를 작성하였습니다.

🤖 Chapter 1. 프로젝트 소개
🤖 Chapter 2. LLM 모델 비교·선정 보고서
⚙️ Chapter 3. 시스템 설계 (System Design)
🧠 Chapter 4. Prompt Engineering & Few-shot Learning
🔍 Chapter 5. Hallucination(환각) 검증
💬 Chapter 6. 실행 로그 (10Turn Conversation)
🚀 Chapter 7. 운영 전략 및 프로젝트 개선 방안

🤖 Chapter-1 프로젝트 소개

📖 Project Overview

프로젝트 소개

최근 생성형 AI는 다양한 업무에서 활용되고 있지만, 같은 질문을 입력하더라도 사용하는 모델과 프롬프트 설계 방식에 따라 결과물의 품질은 크게 달라진다.

특히 업무 자동화에서는 단순히 답변을 생성하는 것이 아니라,

정확성
일관성
문맥 유지
출력 형식 준수
환각(Hallucination) 최소화

가 매우 중요한 요소가 된다.

본 프로젝트는 이러한 문제를 해결하기 위해 Prompt Engineering 기법을 적용하여 회의록 요약 업무를 자동화하는 것을 목표로 한다.

또한 동일한 업무를 여러 LLM에게 수행하도록 하여 각 모델의 장단점을 비교하고, 가장 적합한 모델을 선정하는 과정을 수행하였다.

🎯 Project Goal

이번 프로젝트의 목표는 다음과 같다.

1️⃣ 여러 LLM 모델 비교

동일한 업무를

ChatGPT
Claude
Gemini

에게 수행시켜 결과를 비교한다.

2️⃣ Prompt Engineering 적용

단순 질문이 아닌

Persona
System Prompt
User Prompt
Few-shot
단계적 추론(Reasoning Prompt)

기법을 적용하여 출력 품질을 향상시킨다.

3️⃣ Hallucination 최소화

사실 기반 질문에서

틀린 정보를 단정하지 않도록 하고
근거를 제시하거나
모르면 모른다고 답하도록 설계한다.

4️⃣ 업무 자동화

회의록을 입력하면

결정사항
Action Items
리스크
후속 일정

을 자동으로 정리할 수 있도록 한다.

5️⃣ 문맥 유지

10턴 이상의 대화에서도

기존 요구사항을 유지하고
변경사항만 반영하는 구조를 설계한다.

🚨 Problem Definition

기존 업무의 문제점

회의가 끝난 이후 작성되는 회의록은

내용이 길고
핵심 내용이 분산되어 있으며
담당자와 일정이 명확하지 않은 경우가 많다.

또한 프로젝트가 여러 개 동시에 진행될 경우

회의록을 읽고

결정사항
해야 할 일
일정
위험 요소

를 직접 정리하는 데 많은 시간이 소요된다.

❌ 기존 방식의 문제

문제	설명
⏳ 시간 소모	회의록을 직접 읽고 정리해야 한다.
📄 형식 불일치	작성자마다 정리 방식이 다르다.
❗ 중요 내용 누락	Action Item이 빠질 수 있다.
👥 담당자 혼동	누가 무엇을 하는지 확인이 어렵다.
🔍 검색 어려움	핵심 내용만 빠르게 찾기 어렵다.

💡 해결 방법

LLM을 활용하여

회의록을 입력하면

자동으로

결정사항
해야 할 일
리스크
일정

을 추출하도록 Prompt를 설계하였다.

💼 Task Selection

선택한 업무 과업

📌 회의록 요약 자동화

본 프로젝트에서는

회의록 요약 업무

를 자동화 대상으로 선정하였다.

선택 이유

회의록은

대부분의 기업에서 자주 발생하며
반복 업무 비중이 높고
LLM이 가장 잘 수행하는 업무 중 하나이다.

또한

정확성,

문맥 유지,

출력 형식,

환각 방지

등

이번 과제에서 요구하는 대부분의 평가 항목을 확인하기 적합하다.

👨‍💼 Target User

항목	내용
사용자	프로젝트 매니저(PM)
사용 환경	기업 내부 회의
목적	회의록 자동 요약
주요 업무	결정사항 정리 및 업무 공유

📥 Input Data

입력은 자유 형식의 회의 메모 또는 회의록이다.

예시

프로젝트 킥오프 회의

- 디자인 일정은 다음 주까지 완료
- 개발은 5월부터 시작
- 예산은 1,000만원 승인
- QA 일정은 추후 협의

📤 Output Format

출력은 반드시 아래 형식을 따른다.

📌 결정사항

📌 Action Items

📌 리스크

📌 후속 일정

📌 확인 필요 사항

출력 형식을 고정함으로써 모든 회의록을 동일한 형식으로 관리할 수 있도록 설계하였다.

🧩 Workflow

                회의록 입력
                     │
                     ▼
        ┌────────────────────┐
        │   LLM Prompt 입력   │
        └────────────────────┘
                     │
                     ▼
          정보가 충분한가?
              │          │
          YES │          │ NO
              ▼          ▼
         회의록 요약    확인 질문
              │
              ▼
     결정사항 / Action Items
      리스크 / 후속 일정
              │
              ▼
         최종 결과 출력

📌 Expected Outcome

이번 프로젝트를 통해 기대하는 효과는 다음과 같다.

✅ 회의록 작성 시간 단축

✅ 중요한 내용 자동 추출

✅ 출력 형식 표준화

✅ 반복 업무 자동화

✅ Hallucination 감소

✅ 문맥 유지 향상

✅ 업무 생산성 향상

💡 TIP

Prompt Engineering은 단순히 질문을 길게 작성하는 것이 아니라,

AI가 필요한 정보를 정확하게 이해하고 원하는 형식으로 출력하도록 설계하는 과정이다.

⚠️ WARNING

이번 프로젝트는

회의록 요약을 자동화하는 것을 목표로 하지만,

LLM이 생성하는 결과는 항상 사람이 최종 검토해야 한다.

특히

정책
계약
법률
금액
일정

등은 반드시 원본 문서를 함께 확인해야 한다.

✅ Project Checklist

항목	상태
프로젝트 목표 정의	✅
업무 과업 선정	✅
입력/출력 정의	✅
Workflow 설계	✅
기대 효과 작성	✅

🤖 Chapter-2. LLM 모델 비교·선정 보고서

"같은 프롬프트라도 모델에 따라 결과 품질은 크게 달라질 수 있다."

본 프로젝트에서는 동일한 업무 과업을 서로 다른 3개의 LLM에 수행시켜 결과를 비교하였다.
평가는 단순한 개인적인 느낌이 아니라 동일한 입력과 명확한 평가 기준을 기반으로 진행하였다.

🎯 비교 목적

회의록 요약 업무는 단순한 문장 생성이 아니라,

핵심 정보 추출
긴 문맥 이해
형식 유지
환각(Hallucination) 최소화

가 매우 중요하다.

따라서 동일한 입력 데이터를 사용하여 각 모델의 업무 적합성을 비교하고, 가장 적합한 모델을 선정하는 것을 목표로 하였다.

🖥️ 비교 대상 모델

모델	사용 환경	버전	선정 이유
🤖 ChatGPT	Web	GPT-5.5	업무 자동화 및 긴 문맥 처리 능력이 우수
🟣 Claude	Web	Claude Sonnet 4	긴 문서 이해와 자연스러운 한국어 표현이 강점
🔵 Gemini	Web	Gemini 2.5 Pro	빠른 응답과 Google 생태계 연동에 강점

※ 모든 테스트는 동일한 프롬프트와 동일한 입력 데이터를 사용하였다.

📋 동일 입력(Test Case)

업무 과업

회의록 요약

입력 데이터

[회의 제목]
프로젝트 킥오프 회의

[회의 내용]

- 프로젝트 일정은 5월 1일부터 시작한다.
- 디자인 시안은 4월 28일까지 완료한다.
- 개발은 디자인 완료 후 시작한다.
- 예산은 1,000만원으로 승인되었다.
- QA 일정은 다음 회의에서 확정한다.
- 홍보 일정은 아직 미정이다.

요구사항

회의 내용을 아래 형식으로 요약하시오.

1. 결정사항

2. Action Items

3. 리스크

4. 후속 일정

5. 확인 필요 사항

조건

- 추측 금지
- 근거 없는 내용 생성 금지
- 정보가 부족하면 확인 필요 사항에 작성
- 출력 형식을 반드시 유지

📊 평가 기준

이번 비교는 아래 6개의 항목으로 평가하였다.

평가 항목	설명
🎯 정확성	회의 내용을 올바르게 이해했는가
📄 형식 준수	요구한 템플릿을 유지했는가
🧠 문맥 이해	긴 문장을 정확히 이해했는가
💬 한국어 자연스러움	읽기 쉬운 문장으로 작성했는가
🛡️ 환각 방지	없는 내용을 생성하지 않았는가
⚡ 응답 속도	응답이 빠르고 안정적인가

평가는 1점(매우 부족) ~ 5점(매우 우수) 기준으로 진행하였다.

🤖 모델별 결과 요약

① ChatGPT (GPT-5.5)

결과 요약

모든 요구 형식을 정확히 유지하였다.
결정사항과 Action Items를 명확하게 구분하였다.
정보가 부족한 QA 일정과 홍보 일정은 "확인 필요 사항"으로 분리하였다.
근거 없는 추측을 하지 않았다.

장점

✅ 형식 유지 능력 우수

✅ 긴 문맥 이해 우수

✅ 환각 발생 없음

✅ 업무 문서 형태에 적합

단점

응답 길이가 다소 길어질 수 있다.

② Claude Sonnet 4

결과 요약

문장은 매우 자연스럽다.
회의 내용을 이해하는 능력은 우수하였다.
일부 Action Item이 설명형 문장으로 출력되어 템플릿 일관성이 조금 부족하였다.

장점

✅ 자연스러운 한국어

✅ 긴 문맥 이해 우수

✅ 읽기 쉬운 결과

단점

출력 형식이 일부 달라질 수 있음

③ Gemini 2.5 Pro

결과 요약

응답 속도는 가장 빨랐다.
핵심 내용은 대부분 추출하였다.
일부 리스크를 추론하여 작성하는 경향이 있었다.

장점

✅ 빠른 응답

✅ 핵심 내용 요약

단점

간혹 추측성 문장이 포함될 수 있음
형식 일관성이 다소 부족

📈 모델 비교 결과

평가 항목	🤖 ChatGPT	🟣 Claude	🔵 Gemini
🎯 정확성	5	5	4
📄 형식 준수	5	4	4
🧠 긴 문맥 유지	5	5	4
💬 한국어 자연스러움	5	5	4
🛡️ 환각 방지	5	4	3
⚡ 응답 속도	4	4	5

📊 총점

모델	점수
🤖 ChatGPT	29 / 30
🟣 Claude	27 / 30
🔵 Gemini	24 / 30

🏆 최종 선정

선정 모델

🥇 ChatGPT (GPT-5.5)

선정 이유

1️⃣ 가장 안정적인 출력 형식

회의록 자동화에서는 항상 동일한 형식으로 출력하는 것이 중요하다.

ChatGPT는

결정사항
Action Items
리스크
후속 일정

을 요구한 형식 그대로 유지하였다.

2️⃣ 환각(Hallucination)이 가장 적었다.

회의 내용에 없는 정보를 추가하지 않았으며,

정보가 부족한 경우

"확인이 필요합니다."

라고 명확하게 표시하였다.

이는 업무 자동화에서 매우 중요한 장점이다.

3️⃣ 긴 문맥 유지 능력이 우수하였다.

회의록은 일반적으로 수백 줄 이상의 긴 문서가 될 수 있다.

ChatGPT는 긴 문맥에서도

결정사항
일정
담당자

를 정확하게 구분하였다.

4️⃣ Prompt Engineering 적용 효과가 가장 컸다.

Persona,

Few-shot,

System Prompt,

Reasoning Prompt

를 적용하였을 때 출력 품질 향상이 가장 크게 나타났다.

💡 분석 및 느낀 점

이번 비교를 통해 동일한 입력을 사용하더라도 모델에 따라 결과 품질이 크게 달라질 수 있음을 확인하였다.

특히 업무 자동화에서는 단순히 문장을 자연스럽게 생성하는 능력보다,

정확성
형식 준수
환각 방지
문맥 유지

가 더욱 중요한 평가 요소임을 확인하였다.

또한 Prompt Engineering을 적용하면 모델의 성능을 더욱 안정적으로 활용할 수 있다는 점을 확인하였다.

✅ Chapter Summary

항목	완료
동일 입력 사용	✅
3개 모델 비교	✅
평가 기준 제시	✅
모델별 분석	✅
점수표 작성	✅
최종 선정 근거	✅

⚙️ Chapter-3 시스템 설계 (System Design)

"좋은 결과는 좋은 프롬프트에서 시작된다."

LLM은 동일한 모델이라도 프롬프트 설계 방식에 따라 결과 품질이 크게 달라진다. 본 프로젝트에서는 회의록 요약 업무를 안정적으로 자동화하기 위해 페르소나(Persona), 시스템 프롬프트(System Prompt), 입력 템플릿, 출력 규격, 안전장치를 체계적으로 설계하였다.

🎯 시스템 설계 목표

본 시스템은 다음과 같은 목표를 가진다.

✅ 회의록에서 핵심 정보만 정확하게 추출한다.
✅ 출력 형식을 항상 동일하게 유지한다.
✅ 추측이나 환각(Hallucination)을 최소화한다.
✅ 정보가 부족하면 먼저 확인 질문을 수행한다.
✅ 긴 대화에서도 기존 요구사항을 유지한다.

👥 Target User

항목	내용
사용자	프로젝트 매니저(PM)
사용 환경	기업 내부 프로젝트 회의
사용 목적	회의록 자동 요약 및 업무 공유
기대 효과	회의록 작성 시간 단축 및 업무 표준화

📥 입력 데이터 정의

입력은 자유 형식의 회의 메모 또는 회의록이다.

입력 예시

[회의 제목]
프로젝트 일정 회의

[회의 내용]

- UI 디자인은 4월 30일까지 완료
- 개발 시작은 5월 2일
- QA는 개발 완료 후 진행
- 예산은 1,200만원 승인
- 홍보 일정은 다음 회의에서 결정

📤 출력 규격(Output Format)

모든 결과는 반드시 아래 형식을 유지한다.

# 📌 결정사항

# ✅ Action Items

|담당|업무|기한|

# ⚠️ 리스크

# 📅 후속 일정

# ❓ 확인 필요 사항

출력 형식을 고정한 이유

회의록은 여러 사람이 공유하는 문서이므로 항상 동일한 형식을 유지해야 한다.

이를 통해

검색이 쉬워지고
업무 누락을 줄이며
프로젝트 관리 효율을 높일 수 있다.

🎭 Persona 설계

Persona

이름

Meeting Summary Assistant

역할

프로젝트 매니저 출신 업무 자동화 코치

전문 분야

프로젝트 관리
회의 진행
일정 관리
업무 분배
문서 작성

말투

명확하고 간결한 문장
사내 문서 스타일
불필요한 수식어 사용 금지

우선순위

정확성
사실 기반 답변
형식 준수
친절한 설명

금지 사항

❌ 회의 내용에 없는 사실 생성

❌ 추측성 일정 작성

❌ 담당자 임의 지정

❌ 근거 없는 리스크 생성

🧠 System Prompt

당신은 프로젝트 매니저 출신 업무 자동화 코치입니다.

회의록을 분석하여

- 결정사항
- Action Items
- 리스크
- 후속 일정
- 확인 필요 사항

을 추출합니다.

항상 사실만 작성합니다.

추측하지 않습니다.

정보가 부족하면
최대 3개의 확인 질문을 먼저 수행합니다.

회의 내용에 없는 일정,
담당자,
정책,
수치는 생성하지 않습니다.

최종 출력은 반드시 아래 형식을 유지합니다.

1. 결정사항

2. Action Items

3. 리스크

4. 후속 일정

5. 확인 필요 사항

모르는 내용은

"확인이 필요합니다."

라고 작성합니다.

👤 User Prompt Template

사용자는 아래 형식으로 입력한다.

[업무]

회의록 요약

[회의 내용]

...

[원하는 결과]

결정사항

Action Items

리스크

후속 일정

[톤]

사내 공유용

[금지]

추측 금지

담당자 임의 생성 금지

📋 입력 템플릿

재사용 가능한 입력 템플릿을 설계하였다.

[회의 제목]

[회의 내용]

[회의 목적]

[출력 형식]

[톤]

[필수 포함]

[금지 사항]

🛡️ 안전장치(Safety Rules)

업무 자동화에서는 잘못된 정보가 큰 문제를 일으킬 수 있다.

따라서 아래 규칙을 반드시 적용하였다.

Rule 1

회의록에 없는 정보는 작성하지 않는다.

Rule 2

모르면

"확인이 필요합니다."

라고 답한다.

Rule 3

담당자를 추측하지 않는다.

Rule 4

회의 내용이 부족하면

최대 3개의 확인 질문을 먼저 수행한다.

Rule 5

최종 출력은 반드시 템플릿을 유지한다.

🔄 Prompt 개선 과정

Prompt Engineering은 한 번에 완성되지 않는다.

실제 테스트를 통해 지속적으로 개선하였다.

Version 1

회의 내용을 요약해주세요.

문제점

형식이 일정하지 않음
Action Item 누락
리스크 누락
출력 품질 편차 발생

Version 2

회의 내용을 분석하세요.

먼저

결정사항

Action Items

리스크

후속 일정

확인 필요 사항

을 추출합니다.

정보가 부족하면
최대 3개의 질문을 먼저 수행합니다.

회의 내용에 없는 사실은 생성하지 않습니다.

최종 결과는 템플릿 형식으로 출력합니다.

개선 효과

항목	v1	v2
형식 일관성	△	⭕
환각 감소	△	⭕
문맥 유지	△	⭕
회의록 품질	○	◎
재사용성	△	◎

💡 Prompt Engineering 적용 기법

이번 프로젝트에서는 다음 기법을 사용하였다.

기법	목적
Zero-shot	기본 성능 확인
Few-shot	출력 형식 고정
Reasoning Prompt	단계적 처리
Persona	답변 스타일 통일
Template Prompt	재사용성 향상

📈 시스템 구조

사용자

    │

    ▼

회의록 입력

    │

    ▼

System Prompt 적용

    │

    ▼

Persona 적용

    │

    ▼

정보 충분?

 ┌────┴────┐

 │         │

YES       NO

 │         │

 ▼         ▼

회의록     확인 질문

요약

 │

 ▼

최종 출력

💡 TIP

좋은 프롬프트는 질문을 길게 작성하는 것이 아니라

역할, 목표, 출력 형식, 안전장치를 명확하게 정의하는 것이다.

⚠️ WARNING

회의록에 없는 정보를 추측하여 작성하면 환각(Hallucination)이 발생할 수 있다.

따라서

담당자
일정
금액
정책

등은 반드시 회의 내용에 존재할 때만 작성한다.

✅ Chapter Summary

항목	완료
Target User	✅
입력 정의	✅
출력 규격	✅
Persona	✅
System Prompt	✅
User Prompt	✅
입력 템플릿	✅
안전장치	✅
Prompt 개선(v1→v2)	✅

🧠 Chapter-4 Prompt Engineering & Few-shot Learning

"좋은 AI는 좋은 프롬프트에서 시작된다."

LLM은 동일한 모델이라도 프롬프트 설계 방식에 따라 결과의 품질이 크게 달라진다. 본 프로젝트에서는 회의록 요약 업무의 정확성과 일관성을 높이기 위해 Zero-shot, Few-shot, Reasoning Prompt를 단계적으로 적용하였다.

🎯 Prompt Engineering 적용 목적

이번 프로젝트에서 Prompt Engineering을 적용한 이유는 다음과 같다.

출력 형식을 일정하게 유지한다.
환각(Hallucination)을 최소화한다.
필요한 정보가 부족하면 먼저 질문하도록 유도한다.
회의록의 핵심 정보만 추출하도록 한다.
동일한 업무를 반복 수행해도 일관된 결과를 생성하도록 한다.

📌 Zero-shot Prompt

Zero-shot은 예시를 제공하지 않고 바로 작업을 수행하도록 요청하는 방식이다.

Prompt

아래 회의 내용을 요약해 주세요.

출력 형식

1. 결정사항
2. Action Items
3. 리스크
4. 후속 일정

결과

기본적인 요약은 가능하였다.
Action Items가 누락되는 경우가 있었다.
출력 형식이 매번 조금씩 달랐다.
리스크를 추측하는 경우가 발생하였다.

📌 Few-shot Prompt

Few-shot은 AI에게 좋은 입력과 좋은 출력 예시를 먼저 보여준 뒤 동일한 방식으로 작업을 수행하도록 하는 방법이다.

이번 프로젝트에서는 출력 형식의 일관성을 확보하기 위해 Few-shot을 적용하였다.

✨ Few-shot Example 1

✅ Input

[회의 제목]

UI 디자인 회의

[회의 내용]

- 로그인 화면 디자인은 4월 30일까지 완료한다.
- 개발은 디자인 완료 후 시작한다.
- QA 일정은 추후 결정한다.

✅ Output

📌 결정사항

- 로그인 화면 디자인을 4월 30일까지 완료한다.
- 개발은 디자인 완료 후 시작한다.

✅ Action Items

|담당|업무|기한|
|디자인팀|로그인 화면 제작|4월 30일|

⚠️ 리스크

- QA 일정이 아직 결정되지 않았다.

📅 후속 일정

- QA 일정은 다음 회의에서 확정한다.

❓ 확인 필요 사항

- QA 담당자

💡 적용 효과

형식이 일정하게 유지됨
리스크가 명확하게 구분됨
확인 필요 사항을 별도로 출력

✨ Few-shot Example 2

✅ Input

[회의 제목]

마케팅 회의

[회의 내용]

- SNS 홍보는 다음 주 시작한다.
- 예산은 500만원 승인되었다.
- 광고 플랫폼은 Meta와 Google을 사용한다.

✅ Output

📌 결정사항

- SNS 홍보를 다음 주 시작한다.
- 광고 플랫폼은 Meta와 Google을 사용한다.
- 예산 500만원 승인

✅ Action Items

|담당|업무|
|마케팅팀|SNS 광고 준비|

⚠️ 리스크

- 광고 시작 날짜가 정확하지 않다.

📅 후속 일정

- 광고 시작일 확정

❓ 확인 필요 사항

- 광고 시작 날짜

💡 적용 효과

핵심 내용만 추출
추측 없이 부족한 정보만 표시
업무 담당을 명확하게 정리

✨ Few-shot Example 3 (모호한 입력)

이번 예시는 평가기준에서 요구하는 "모호한 입력 → 되묻기" 사례이다.

❌ Input

회의 내용을 정리해 주세요.

문제점

회의록 원문이 존재하지 않는다.

어떤 형식으로 출력해야 하는지도 알 수 없다.

✅ AI의 응답

회의록 요약을 위해 추가 정보가 필요합니다.

다음 내용을 알려주세요.

1. 회의록 원문

2. 원하는 출력 형식

3. 공유 대상

4. 필요한 항목
(결정사항 / Action Items / 리스크 등)

정보를 제공해 주시면
회의록을 정확하게 요약하겠습니다.

💡 적용 효과

AI가 임의로 내용을 생성하지 않고

사용자에게 필요한 정보를 먼저 질문한다.

이를 통해 Hallucination을 크게 줄일 수 있다.

🔄 Prompt 개선 (v1 → v2)

Prompt는 실제 테스트를 통해 지속적으로 개선하였다.

Version 1

회의 내용을 요약해주세요.

문제점

형식이 일정하지 않다.
Action Items 누락
리스크 누락
담당자 누락
환각 발생 가능

Version 2

회의록을 분석하세요.

먼저

1. 결정사항

2. Action Items

3. 리스크

4. 후속 일정

5. 확인 필요 사항

을 정리합니다.

정보가 부족하면

최대 3개의 확인 질문을 먼저 수행합니다.

회의 내용에 없는 사실은 생성하지 않습니다.

최종 출력은 지정된 템플릿을 반드시 유지합니다.

📊 Prompt 개선 결과

항목	v1	v2
출력 형식 유지	△	⭕
환각 감소	△	⭕
Action Item 추출	△	⭕
문맥 유지	△	⭕
재사용성	△	◎

🧩 Reasoning Prompt 적용

회의록 요약은 단순한 문장 생성이 아니라 여러 단계를 거쳐 정보를 정리하는 작업이다.

따라서 다음과 같은 단계적 접근을 적용하였다.

1단계
회의 내용 분석

↓

2단계

결정사항 추출

↓

3단계

Action Item 추출

↓

4단계

리스크 확인

↓

5단계

정보 부족 여부 판단

↓

6단계

최종 출력

최종 Prompt

회의록을 단계적으로 분석하세요.

먼저 핵심 정보를 정리합니다.

정보가 부족하면
최대 3개의 질문을 수행합니다.

회의 내용에 없는 정보는 생성하지 않습니다.

최종 출력에서는

- 결정사항
- Action Items
- 리스크
- 후속 일정
- 확인 필요 사항

만 출력합니다.

내부적인 추론 과정은 출력하지 않습니다.

📈 적용 결과

Prompt Engineering을 적용한 이후

출력 형식이 일정하게 유지되었다.
Hallucination이 감소하였다.
회의록 품질이 향상되었다.
긴 회의록에서도 핵심 정보 추출 성능이 향상되었다.
동일한 업무를 반복 수행해도 결과가 안정적으로 유지되었다.

💡 TIP

Few-shot은 AI에게 정답을 알려주는 것이 아니라

원하는 출력 형식을 학습시키는 역할을 한다.

업무 자동화에서는 Few-shot을 사용하는 것이 출력 품질 향상에 매우 효과적이다.

⚠️ WARNING

예시가 잘못 작성되면

AI도 동일한 형식을 그대로 따라 한다.

따라서 Few-shot 예시는

정확한 정보
원하는 형식
일관된 구조

를 반드시 유지해야 한다.

✅ Chapter Summary

항목	완료
Zero-shot 적용	✅
Few-shot 3개	✅
모호한 입력 예시	✅
되묻기 예시	✅
Reasoning Prompt	✅
Prompt v1 → v2	✅
최종 Prompt 작성	✅

🔍 Chapter-5 Hallucination(환각) 검증

"좋은 AI는 모르는 것을 아는 척하지 않는다."

업무 자동화에서 가장 중요한 요소 중 하나는 Hallucination(환각) 을 최소화하는 것이다.

회의록, 정책 문서, 계약서, 보고서와 같이 사실(Fact) 을 기반으로 하는 업무에서는 AI가 근거 없이 정보를 생성할 경우 심각한 업무 오류로 이어질 수 있다.

따라서 본 프로젝트에서는 Hallucination의 기준을 명확하게 정의하고, 실제 검증 질문을 통해 AI의 신뢰성을 평가하였다.

🎯 Hallucination이란?

본 프로젝트에서는 Hallucination을 다음과 같이 정의하였다.

"검증 가능한 사실(날짜, 정책, 수치, 계산, 인물, 일정 등)에 대해 근거 없이 틀린 정보를 사실처럼 단정하여 생성하는 것."

즉,

AI가

없는 회의 내용을 만들거나
존재하지 않는 담당자를 지정하거나
날짜를 임의로 생성하거나
정책을 추측해서 답하는 경우

모두 Hallucination으로 판단한다.

✍️ 창의적 생성과 Hallucination의 차이

Hallucination과 창의적 생성은 서로 다른 개념이다.

구분	Hallucination	창의적 생성
목적	사실 전달	창작 및 아이디어 생성
정답 존재 여부	존재	존재하지 않음
근거 필요	필수	불필요
허용 여부	❌ 허용되지 않음	✅ 허용 가능
예시	없는 정책을 생성	소설, 광고 문구 작성

예를 들어,

❌ Hallucination

"회의에서 QA는 5월 20일부터 시작하기로 결정되었습니다."

하지만 실제 회의록에 QA 일정이 없다면 이는 환각이다.

✅ 창의적 생성

"미래의 AI 회사를 배경으로 한 소설을 작성해 주세요."

이 경우는 정답이 존재하지 않는 창작 작업이므로 Hallucination으로 보지 않는다.

즉, 사실 기반 업무와 창작 업무는 평가 기준이 다르다.

📋 Hallucination 검증 방법

본 프로젝트에서는 아래 기준으로 검증을 수행하였다.

동일한 질문을 입력한다.
AI의 답변을 확인한다.
원문과 비교한다.
Pass / Fail을 판정한다.

✅ Pass 판정 기준

다음 두 조건 중 하나를 만족하면 Pass로 판정하였다.

(A)

정답을 정확하게 제시하고

간단한 근거를 함께 설명한다.

예시

"QA 일정은 회의록에 포함되어 있지 않습니다."

(B)

정보가 부족한 경우

모른다고 답하고

확인 절차를 제안한다.

예시

"회의록에 해당 내용이 없습니다. 원본 회의록이나 추가 자료를 확인해 주세요."

❌ Fail 판정 기준

다음 중 하나라도 해당하면 Fail로 판정하였다.

①

없는 사실을 생성한다.

예시

"QA 일정은 5월 15일입니다."

(회의록에는 존재하지 않음)

②

근거 없이 확신한다.

예시

"예산은 반드시 2천만원입니다."

(근거 없음)

③

질문이 모호한데도 확인 질문 없이 답한다.

예시

사용자

"회의 일정 알려줘."

AI

"다음 주 월요일입니다."

(어떤 회의인지 알 수 없음)

④

회의록에 없는 담당자를 생성한다.

예시

"김철수 과장이 QA를 담당합니다."

(원문에 존재하지 않음)

🧪 Hallucination 검증 질문

Question 1

질문

QA 일정은 언제인가요?

기대 정답

회의록에는 QA 일정이 존재하지 않는다.

허용 오차

없음

Pass 예시

회의록에는 QA 일정이 포함되어 있지 않습니다.

추가 회의 또는 일정 문서를 확인해야 합니다.

Fail 예시

QA는 5월 15일부터 시작합니다.

결과

✅ Pass

Question 2

질문

예산은 얼마인가요?

기대 정답

1,000만원

Pass

회의록에 따르면 승인된 예산은 1,000만원입니다.

Fail

예산은 2,000만원입니다.

결과

✅ Pass

Question 3

질문

QA 담당자는 누구인가요?

기대 정답

회의록에 존재하지 않는다.

Pass

회의록에 QA 담당자는 명시되어 있지 않습니다.

담당자를 확인해야 합니다.

Fail

QA 담당자는 김철수입니다.

결과

✅ Pass

Question 4

질문

홍보 일정은 언제인가요?

기대 정답

미정

Pass

홍보 일정은 아직 결정되지 않았습니다.

Fail

홍보 일정은 다음 주 월요일입니다.

결과

✅ Pass

Question 5

질문

회의에서 결정된 모든 내용을 알려주세요.

기대 정답

회의록에 있는 내용만 요약

Pass

회의록에 기록된 결정사항만 정리하겠습니다.

- 예산 승인
- 디자인 일정
- 개발 시작 조건

Fail

회의에서는 예산 승인과 신규 인력 채용도 결정되었습니다.

(신규 인력 채용은 원문에 없음)

결과

✅ Pass

📊 Hallucination 검증 결과

검증 항목	결과
정답 정확성	✅
추측 방지	✅
모르면 모른다고 답변	✅
확인 질문 수행	✅
근거 없는 정보 생성 방지	✅

📈 Hallucination 감소 전략

Prompt Engineering을 통해 다음과 같은 전략을 적용하였다.

1️⃣ 정보 부족 시 확인 질문

충분한 정보가 없으면 최대 3개의 질문을 먼저 수행한다.

2️⃣ 모르면 모른다고 답하기

추측 대신

"확인이 필요합니다."

를 출력한다.

3️⃣ 원문 우선 원칙

회의록에 없는 내용은 절대 생성하지 않는다.

4️⃣ 출력 형식 고정

결정사항과 확인 필요 사항을 구분하여 작성한다.

5️⃣ 근거 중심 답변

수치, 일정, 정책은 반드시 원문에 근거하여 작성한다.

💡 TIP

Hallucination을 완전히 제거하는 것은 어렵지만,

추측을 줄이고 확인 질문을 유도하는 프롬프트 설계를 통해 발생 가능성을 크게 낮출 수 있다.

⚠️ WARNING

업무 자동화에서는 AI의 답변을 그대로 사용하는 것이 아니라,

최종적으로 사람이 원문과 비교하여 검토해야 한다.

특히

계약
법률
정책
예산
일정

과 같은 정보는 반드시 원문 문서를 확인해야 한다.

✅ Chapter Summary

항목	완료
Hallucination 정의	✅
창의적 생성과 차이	✅
Pass 기준	✅
Fail 기준	✅
검증 질문 5개	✅
Pass 사례	✅
Fail 사례	✅
환각 감소 전략	✅

💬 Chapter-6 실행 로그 (10Turn Conversation)

"프롬프트의 성능은 한 번의 답변보다, 긴 대화에서 얼마나 일관성을 유지하는지로 평가할 수 있다."

본 프로젝트에서는 실제 업무 상황을 가정하여 10턴 이상의 대화를 수행하였다.

대화 중에는

조건 변경
추가 정보 제공
출력 형식 수정
누락 정보 보완

등을 포함하여 LLM이 이전 문맥을 얼마나 잘 유지하는지 검증하였다.

🎯 테스트 시나리오

업무

회의록 요약

사용자

프로젝트 매니저(PM)

목적

회의가 끝난 후

회의록을 팀원들에게 공유하기 위한 문서를 생성한다.

📝 Conversation Log

Turn 1

👤 User

회의록을 요약해주세요.

회의 내용은 아래와 같습니다.

- 프로젝트는 5월 1일부터 시작합니다.
- 디자인은 4월 28일까지 완료합니다.
- 예산은 1,000만원 승인되었습니다.
- QA 일정은 아직 미정입니다.

🤖 Assistant

📌 결정사항

- 프로젝트는 5월 1일부터 시작
- 디자인 완료일은 4월 28일
- 예산 1,000만원 승인

✅ Action Items

|담당|업무|기한|
|미정|디자인 완료|4월 28일|

⚠️ 리스크

- QA 일정 미정

📅 후속 일정

- QA 일정 확정 회의 진행

❓ 확인 필요 사항

- QA 담당자

Turn 2

👤 User

담당자는 디자인팀입니다.

🤖 Assistant

Action Items를 수정하겠습니다.

|담당|업무|기한|
|디자인팀|디자인 완료|4월 28일|

기존 결정사항은 그대로 유지됩니다.

Turn 3

👤 User

회의록을 표 형태로 작성해주세요.

🤖 Assistant

|구분|내용|
|---|---|
|결정사항|프로젝트 시작, 예산 승인|
|Action Items|디자인 완료|
|리스크|QA 일정 미정|
|후속 일정|QA 일정 논의|

Turn 4

👤 User

팀원들에게 공유할 문서라서 조금 더 간결하게 작성해주세요.

🤖 Assistant

|구분|내용|
|---|---|
|결정사항|프로젝트 시작, 예산 승인|
|할 일|디자인 완료|
|리스크|QA 일정 미정|

문장을 줄이고 핵심 내용만 남겼습니다.

Turn 5

👤 User

추가 회의가 있었습니다.

QA는 5월 20일부터 시작하기로 결정되었습니다.

🤖 Assistant

새로운 정보를 반영하겠습니다.

변경 사항

QA 일정

기존 : 미정

수정 : 5월 20일 시작

기존 결정사항은 유지됩니다.

Turn 6

👤 User

QA 담당자는 박대리입니다.

🤖 Assistant

Action Items를 수정합니다.

|담당|업무|기한|
|디자인팀|디자인 완료|4월 28일|
|박대리|QA 진행|5월 20일|

Turn 7

👤 User

예산을 1,200만원으로 수정해주세요.

🤖 Assistant

회의록을 수정하겠습니다.

변경 사항

예산

기존 : 1,000만원

수정 : 1,200만원

나머지 내용은 그대로 유지합니다.

Turn 8

👤 User

담당자 이름 대신 역할만 표시해주세요.

🤖 Assistant

Action Items

|담당|업무|
|디자인팀|디자인 완료|
|QA 담당자|QA 진행|

이전 요구사항은 유지하면서 담당자만 역할명으로 변경했습니다.

Turn 9

👤 User

회의록 마지막에 확인이 필요한 내용도 추가해주세요.

🤖 Assistant

❓ 확인 필요 사항

- 홍보 일정
- QA 완료 예정일

Turn 10

👤 User

최종 결과를 출력해주세요.

🤖 Assistant

# 📌 결정사항

- 프로젝트 시작 : 5월 1일
- 디자인 완료 : 4월 28일
- 예산 : 1,200만원
- QA 시작 : 5월 20일

# ✅ Action Items

|담당|업무|
|디자인팀|디자인 완료|
|QA 담당자|QA 진행|

# ⚠️ 리스크

- 홍보 일정 미확정

# 📅 후속 일정

- 홍보 일정 결정

# ❓ 확인 필요 사항

- QA 완료 일정
- 홍보 일정

🔄 조건 변경 내역

Turn	변경 내용	반영 여부
2	담당자 추가	✅
3	표 형식 변경	✅
4	간결한 문체	✅
5	QA 일정 추가	✅
6	QA 담당자 추가	✅
7	예산 변경	✅
8	실명 → 역할명 변경	✅
9	확인 필요 사항 추가	✅

🧠 문맥 유지 검증

이번 대화에서는 사용자의 요구사항이 여러 번 변경되었다.

LLM은 변경된 조건만 수정하고, 기존 요구사항은 그대로 유지하는지 확인하였다.

검증 결과

항목	결과
회의 내용 유지	✅
출력 형식 유지	✅
조건 변경 반영	✅
이전 정보 유지	✅
새로운 정보 추가	✅

⚠️ 문제 발생 사례

문제 1

초기 Prompt(v1)에서는

담당자가 없는 경우

AI가 임의의 담당자를 생성하려는 경향이 있었다.

개선

Prompt에

"회의록에 없는 담당자는 생성하지 않는다."

를 추가하였다.

문제 2

사용자가

"조금 더 간결하게"

라고 요청했을 때

기존 형식을 변경하는 문제가 있었다.

개선

Prompt에

"형식은 유지하고 문장만 간결하게 수정한다."

라는 규칙을 추가하였다.

문제 3

조건이 여러 번 변경되면서

일부 모델은 이전 요구사항을 잊는 문제가 발생하였다.

개선

Prompt를 다음과 같이 변경하였다.

새로운 요청이 들어오면

변경된 조건만 수정하고

기존 요구사항은 그대로 유지한다.

이를 통해 긴 대화에서도 일관성을 유지할 수 있었다.

🚀 문맥 유지를 위한 프롬프트 구조 개선

10턴 이상의 대화에서는 단순한 질의응답보다 상태(State)를 유지하는 프롬프트 구조가 중요하다.

본 프로젝트에서는 다음 원칙을 적용하였다.

확정된 요구사항 유지
- 이미 합의된 형식, 톤, 금지사항은 이후 대화에서도 계속 유지한다.
변경된 조건만 수정
- 새로운 요청이 들어오면 해당 부분만 업데이트하고 나머지 내용은 유지한다.
최신 정보 우선 적용
- 사용자가 일정이나 예산을 수정하면 이전 정보를 덮어쓰고 최신 정보를 기준으로 답변한다.
최종 출력 전 전체 검토
- 마지막 답변에서는 이전 대화의 모든 변경사항이 반영되었는지 확인한 후 결과를 생성한다.

이와 같은 구조는 긴 대화에서 문맥이 끊기는 문제를 줄이고, 업무 자동화에서 안정적인 결과를 유지하는 데 효과적이었다.

✅ Chapter Summary

항목	완료
10Turn 대화	✅
실제 대화 전문	✅
조건 변경	✅
추가 정보 제공	✅
문맥 유지 검증	✅
문제 발생 사례	✅
프롬프트 개선 원리	✅

🚀 Chapter-7 운영 전략 및 프로젝트 개선 방안

"좋은 프롬프트는 한 번 만드는 것이 아니라 지속적으로 개선하고 운영하는 것이다."

Prompt Engineering은 단순히 프롬프트를 작성하는 것으로 끝나지 않는다.

실제 업무에서는

비용
모델 변경
업무 정책 변경
긴 문맥 유지
환각(Hallucination)

등 다양한 요소를 지속적으로 관리해야 한다.

본 프로젝트에서는 이러한 실제 운영 환경을 고려하여 업무 자동화 전략을 설계하였다.

💰 1. 비용 제약 환경에서의 운영 전략

실무에서는 항상 최신 유료 모델만 사용할 수 있는 것은 아니다.

기업이나 개인의 예산에 따라 무료 모델을 사용해야 하는 상황도 자주 발생한다.

따라서 무료 모델에서도 일정 수준 이상의 결과를 얻을 수 있도록 프롬프트를 개선하는 전략이 필요하다.

🎯 전략 1. 출력 형식을 명확하게 지정하기

무료 모델은 출력 형식이 자주 변경되는 경우가 있다.

이를 방지하기 위해 출력 템플릿을 프롬프트에 명확하게 포함하였다.

Before

회의 내용을 요약해 주세요.

After

회의 내용을 아래 형식으로 작성하세요.

1. 결정사항

2. Action Items

3. 리스크

4. 후속 일정

5. 확인 필요 사항

반드시 위 순서를 유지합니다.

🎯 전략 2. 긴 문서를 여러 단계로 나누기

무료 모델은 긴 입력에서 성능이 저하될 수 있다.

따라서

회의록

↓

핵심 내용 추출

↓

결정사항 생성

↓

Action Item 생성

↓

최종 요약

처럼 단계적으로 처리하도록 설계하였다.

🎯 전략 3. Few-shot 적극 활용

무료 모델은 출력 형식이 일정하지 않은 경우가 많다.

이를 해결하기 위해

좋은 입력
좋은 출력

예시를 함께 제공하여 출력 형식을 학습하도록 하였다.

🎯 전략 4. 불필요한 요청 제거

무료 모델에서는 한 번에 너무 많은 작업을 요청하면 품질이 떨어질 수 있다.

따라서

❌ 요약 + 번역 + 표 생성 + 일정 관리

처럼 여러 작업을 동시에 수행하지 않고,

각 작업을 분리하여 요청하도록 설계하였다.

📊 비용 절감 전략 요약

전략	효과
출력 형식 고정	형식 오류 감소
단계적 처리	정확도 향상
Few-shot 적용	일관성 향상
작업 분리	응답 품질 향상
필요한 작업만 요청	토큰 비용 절감

🛡️ 2. 정책 변경 환경에서의 Hallucination 감소 전략

기업의 업무 규정은 지속적으로 변경된다.

예를 들어

출장비 규정 변경
보안 정책 변경
결재 절차 변경
프로젝트 일정 변경

등은 자주 발생한다.

만약 AI가 오래된 정보를 그대로 답변한다면 업무 오류가 발생할 수 있다.

따라서 정책 변경을 고려한 운영 전략을 설계하였다.

🎯 운영 원칙

① 최신 문서를 우선 사용

AI는 기억에 의존하지 않고

최신 회의록,

최신 정책,

최신 업무 문서를 우선 참고하도록 한다.

② 정책 버전 확인

답변 전

현재 사용하는 정책 버전을 확인합니다.

라는 절차를 추가하였다.

③ 변경 여부 확인 질문

정책이 자주 변경되는 업무에서는

AI가 먼저 질문하도록 설계하였다.

예시

현재 사용하는 정책이

2025년 버전인가요?

2026년 개정판인가요?

④ 근거 없는 답변 금지

정책 문서가 없는 경우

확인이 필요합니다.

라고 답하도록 하였다.

⑤ 최신 문서 기반 재생성

정책이 변경되면

이전 답변을 수정하는 것이 아니라

최신 문서를 기준으로 다시 생성하도록 설계하였다.

📊 정책 변경 대응 프로세스

사용자 질문

↓

최신 정책 존재?

↓

YES

↓

정책 기반 답변

↓

NO

↓

확인 질문

↓

최신 문서 요청

↓

답변 생성

🔄 Prompt 운영 개선 과정

Prompt는 한 번 작성한 이후에도 지속적으로 개선하였다.

Version 1

회의록을 요약해 주세요.

문제점

출력 형식이 일정하지 않음
긴 문서에서 누락 발생
정책 변경 대응 불가능

Version 2

회의록을 분석합니다.

먼저

결정사항을 추출합니다.

정보가 부족하면 질문합니다.

회의록에 없는 내용은 생성하지 않습니다.

출력 형식을 반드시 유지합니다.

Version 3

최신 회의록을 기준으로 분석합니다.

정책이나 일정이 변경되었는지 확인합니다.

정보가 부족하면 최대 3개의 질문을 수행합니다.

회의록에 없는 정보는 생성하지 않습니다.

최종 출력에서는

결정사항

Action Items

리스크

후속 일정

확인 필요 사항

만 출력합니다.

📈 운영 전략 적용 결과

Prompt를 지속적으로 개선한 결과

✅ 출력 형식이 일정하게 유지되었다.

✅ Hallucination이 감소하였다.

✅ 긴 문맥 유지 성능이 향상되었다.

✅ 정책 변경 상황에서도 안정적으로 대응할 수 있었다.

✅ 무료 모델에서도 일정 수준 이상의 품질을 유지할 수 있었다.

💡 프로젝트를 통해 배운 점

이번 프로젝트를 수행하면서

Prompt Engineering은 단순히 질문을 잘 작성하는 기술이 아니라,

AI가 안정적으로 업무를 수행하도록 설계하는 과정이라는 것을 확인하였다.

특히

Persona 설계
Few-shot
Reasoning Prompt
Hallucination 검증
문맥 유지 전략

을 함께 적용할 때 가장 높은 품질을 얻을 수 있었다.

또한 무료 모델과 유료 모델의 차이는 존재하지만,

프롬프트를 개선하면 무료 모델에서도 충분히 업무 자동화에 활용 가능한 수준의 결과를 얻을 수 있다는 점을 확인하였다.

📌 프로젝트 전체 Workflow

업무 정의

↓

LLM 모델 비교

↓

최적 모델 선정

↓

Persona 설계

↓

System Prompt 설계

↓

Few-shot 작성

↓

Prompt 개선(v1 → v2 → v3)

↓

Hallucination 검증

↓

10Turn 테스트

↓

운영 전략 적용

↓

최종 Prompt 완성

🎯 최종 결론

본 프로젝트에서는 회의록 요약 업무를 대상으로 Prompt Engineering 기반 업무 자동화를 설계하였다.

동일한 입력을 여러 LLM에서 비교한 결과 ChatGPT가 가장 안정적인 성능을 보였으며,

Persona, System Prompt, Few-shot, Reasoning Prompt를 적용한 이후 출력 형식의 일관성과 정확성이 크게 향상되었다.

또한 Hallucination 검증과 10턴 이상의 문맥 유지 테스트를 수행하여 실제 업무에서도 활용 가능한 프롬프트 구조를 설계하였다.

마지막으로 비용 제약 환경과 정책 변경 상황까지 고려한 운영 전략을 적용함으로써 단순한 프롬프트 작성이 아닌 실제 업무 자동화 시스템으로 확장할 수 있는 기반을 마련하였다.

✅ Final Checklist

평가 항목	완료
LLM 비교	✅
Prompt Engineering	✅
Persona 설계	✅
Few-shot	✅
Reasoning Prompt	✅
Hallucination 검증	✅
10Turn 대화	✅
문맥 유지	✅
무료 모델 운영 전략	✅
정책 변경 대응	✅
최종 Prompt 개선	✅

🎉 Project Complete

LLM Prompt Engineering for Business Automation

"좋은 AI는 좋은 프롬프트에서 시작되고, 좋은 시스템은 지속적인 개선에서 완성된다."

Name		Name	Last commit message	Last commit date
README.md		README.md

Latest commit

History

Folders and files

Repository files navigation

🤖 LLM 기반 업무 자동화 프롬프트 패키지

Meeting Summary Automation using Prompt Engineering

📚 AI 활용 업무 자동화 프로젝트

프로젝트를 chapter별로 나누어 README를 작성하였습니다.

🤖 Chapter-1 프로젝트 소개

📖 Project Overview

프로젝트 소개

🎯 Project Goal

1️⃣ 여러 LLM 모델 비교

2️⃣ Prompt Engineering 적용

3️⃣ Hallucination 최소화

4️⃣ 업무 자동화

5️⃣ 문맥 유지

🚨 Problem Definition

기존 업무의 문제점

❌ 기존 방식의 문제

💡 해결 방법

💼 Task Selection

선택한 업무 과업

📌 회의록 요약 자동화

선택 이유

👨‍💼 Target User

📥 Input Data

📤 Output Format

🧩 Workflow

📌 Expected Outcome

💡 TIP

⚠️ WARNING

✅ Project Checklist

🤖 Chapter-2. LLM 모델 비교·선정 보고서

🎯 비교 목적

🖥️ 비교 대상 모델

📋 동일 입력(Test Case)

업무 과업

입력 데이터

요구사항

📊 평가 기준

🤖 모델별 결과 요약

① ChatGPT (GPT-5.5)

결과 요약

장점

단점

② Claude Sonnet 4

결과 요약

장점

단점

③ Gemini 2.5 Pro

결과 요약

장점

단점

📈 모델 비교 결과

📊 총점

🏆 최종 선정

선정 모델

🥇 ChatGPT (GPT-5.5)

선정 이유

1️⃣ 가장 안정적인 출력 형식

2️⃣ 환각(Hallucination)이 가장 적었다.

3️⃣ 긴 문맥 유지 능력이 우수하였다.

4️⃣ Prompt Engineering 적용 효과가 가장 컸다.

💡 분석 및 느낀 점

✅ Chapter Summary

⚙️ Chapter-3 시스템 설계 (System Design)

🎯 시스템 설계 목표

👥 Target User

📥 입력 데이터 정의

입력 예시

📤 출력 규격(Output Format)

출력 형식을 고정한 이유

🎭 Persona 설계

Persona

이름

역할

전문 분야

말투

우선순위