이미지 로딩 중...
AI Generated
2025. 11. 11. · 5 Views
바닥부터 만드는 ChatGPT 10편 대화형 데이터 적응 전략
ChatGPT와 같은 대화형 AI 시스템을 구축할 때 필수적인 데이터 적응 전략을 실무 중심으로 다룹니다. 실시간 대화 컨텍스트 관리부터 사용자 맞춤형 응답 생성까지, 실제 프로덕션 환경에서 바로 적용할 수 있는 핵심 기법들을 배웁니다.
목차
- 대화_컨텍스트_윈도우_관리
- 동적_프롬프트_템플릿_시스템
- Few-Shot_Learning_적응
- 토큰_예산_관리_전략
- 대화_상태_머신_구현
- 사용자_프로파일_기반_적응
- 컨텍스트_압축_기법
- 동적_Temperature_조절
1. 대화_컨텍스트_윈도우_관리
시작하며
여러분이 ChatGPT와 긴 대화를 나누다 보면 갑자기 이전 내용을 까먹는 경험을 해보셨나요? 사용자가 "아까 말한 그 방법으로 해줘"라고 했는데 AI가 "무슨 방법을 말씀하시는 건가요?"라고 되묻는 상황 말이죠.
이런 문제는 LLM의 컨텍스트 윈도우 제한 때문에 발생합니다. GPT-3.5는 4K 토큰, GPT-4는 8K~32K 토큰의 제한이 있어서, 대화가 길어지면 초반 내용이 잘려나가게 됩니다.
실제 서비스에서는 사용자 경험을 크게 해치는 치명적인 문제입니다. 바로 이럴 때 필요한 것이 대화 컨텍스트 윈도우 관리입니다.
중요한 정보는 유지하면서도 토큰 제한 내에서 효율적으로 대화 히스토리를 관리하는 전략이죠.
개요
간단히 말해서, 이 기법은 제한된 컨텍스트 윈도우 안에서 가장 중요한 대화 내용만 선별하여 유지하는 시스템입니다. 실무에서 이 기법이 필요한 이유는 명확합니다.
API 비용은 토큰 수에 비례하고, 응답 속도도 컨텍스트 길이에 영향을 받습니다. 예를 들어, 고객 상담 챗봇에서 20턴 이상의 긴 대화를 처리할 때, 모든 내용을 그대로 유지하면 비용이 급증하고 응답이 느려집니다.
기존에는 단순히 최근 N개 메시지만 유지하는 방식을 사용했다면, 이제는 중요도를 판단하여 선택적으로 유지할 수 있습니다. 이 기법의 핵심은 슬라이딩 윈도우 방식과 중요도 기반 선택, 그리고 요약 기법을 결합하는 것입니다.
이러한 특징들이 실시간 대화 시스템에서 안정적인 성능을 보장합니다.
코드 예제
# 대화 컨텍스트 윈도우 매니저
class ConversationWindowManager:
def __init__(self, max_tokens=3000, keep_system_prompt=True):
# max_tokens: 유지할 최대 토큰 수
self.max_tokens = max_tokens
self.keep_system_prompt = keep_system_prompt
self.messages = []
def add_message(self, role, content):
# 새 메시지 추가
self.messages.append({"role": role, "content": content})
self._trim_messages()
def _trim_messages(self):
# 토큰 수를 계산하여 초과 시 오래된 메시지 제거
total_tokens = sum(len(m["content"]) // 4 for m in self.messages)
while total_tokens > self.max_tokens and len(self.messages) > 1:
# 시스템 프롬프트는 유지, 가장 오래된 사용자/AI 메시지 제거
if self.keep_system_prompt and self.messages[0]["role"] == "system":
self.messages.pop(1)
else:
self.messages.pop(0)
total_tokens = sum(len(m["content"]) // 4 for m in self.messages)
설명
이것이 하는 일: 대화가 길어질수록 자동으로 오래된 메시지를 제거하면서도, 핵심 컨텍스트(시스템 프롬프트)는 유지하여 AI가 일관된 페르소나를 유지하도록 합니다. 첫 번째로, __init__ 메서드에서 최대 토큰 수와 시스템 프롬프트 유지 여부를 설정합니다.
max_tokens는 API 제한과 비용을 고려하여 설정하는 값으로, GPT-3.5의 경우 전체 4K 중 응답을 위해 1K를 남기고 3K 정도로 설정하는 것이 일반적입니다. 그 다음으로, add_message가 호출되면 새 메시지를 리스트에 추가하고 즉시 _trim_messages를 실행합니다.
이 방식은 매 메시지마다 윈도우 크기를 체크하므로 토큰 제한을 절대 초과하지 않습니다. _trim_messages는 간단한 토큰 추정(문자 수 / 4)을 사용하여 빠르게 계산합니다.
정확한 토큰 계산을 위해서는 tiktoken 라이브러리를 사용할 수 있지만, 실시간 처리에서는 이 정도 근사치로도 충분합니다. 시스템 프롬프트를 제외한 가장 오래된 메시지부터 제거하는 FIFO 방식을 사용합니다.
여러분이 이 코드를 사용하면 API 요청마다 일정한 토큰 수를 유지할 수 있어 비용을 예측 가능하게 관리할 수 있습니다. 또한 응답 속도가 안정적으로 유지되고, 메모리 사용량도 제어됩니다.
실전 팁
💡 실제 프로덕션에서는 tiktoken 라이브러리로 정확한 토큰 수를 계산하세요. len(content) // 4는 근사치일 뿐이며, 특수문자나 한글이 많으면 오차가 커집니다.
💡 중요한 메시지(시스템 프롬프트, 사용자의 첫 요청 등)는 별도로 표시하여 절대 제거되지 않도록 하세요. importance 플래그를 추가하는 방식이 효과적입니다.
💡 메시지 페어(사용자 질문 + AI 응답)를 함께 제거하세요. 한쪽만 남으면 대화 맥락이 깨집니다.
💡 대화가 특정 길이(예: 10턴)를 넘어가면 자동으로 이전 대화를 요약하여 하나의 컨텍스트 메시지로 압축하는 전략을 병행하세요.
2. 동적_프롬프트_템플릿_시스템
시작하며
여러분이 다양한 유형의 사용자 요청을 처리하는 AI를 만들 때, 매번 프롬프트를 수작업으로 작성하면 얼마나 비효율적일까요? "코드 리뷰 해줘", "번역해줘", "요약해줘" 같은 요청마다 다른 프롬프트가 필요합니다.
이 문제는 실제 서비스에서 매우 흔합니다. 하드코딩된 프롬프트는 유지보수가 어렵고, 새로운 기능 추가 시 코드 전체를 수정해야 합니다.
A/B 테스트로 프롬프트 효과를 비교하는 것도 불가능하죠. 바로 이럴 때 필요한 것이 동적 프롬프트 템플릿 시스템입니다.
사용자 의도를 분석하여 자동으로 최적의 프롬프트를 생성하고 주입합니다.
개요
간단히 말해서, 이 시스템은 사용자 입력을 분석하여 적절한 프롬프트 템플릿을 선택하고, 변수를 채워서 완성된 프롬프트를 생성하는 엔진입니다. 왜 이것이 필요한지 실무 관점에서 보면, 하나의 AI 시스템이 여러 역할을 수행해야 하는 경우가 많습니다.
예를 들어, 기업용 AI 어시스턴트는 문서 작성, 데이터 분석, 코드 생성, 회의 요약 등 다양한 작업을 처리해야 합니다. 기존에는 각 기능마다 별도의 하드코딩된 프롬프트를 사용했다면, 이제는 템플릿 기반으로 동적 생성하여 확장성과 유지보수성을 확보할 수 있습니다.
핵심 특징은 의도 분류기와 템플릿 저장소, 그리고 변수 바인딩 엔진을 결합한 것입니다. 이러한 구조가 프롬프트 엔지니어링을 코드가 아닌 데이터로 관리할 수 있게 해줍니다.
코드 예제
# 동적 프롬프트 템플릿 엔진
class PromptTemplateEngine:
def __init__(self):
# 의도별 프롬프트 템플릿 저장소
self.templates = {
"code_review": "You are an expert code reviewer. Review the following {language} code and provide feedback on:\n1. Code quality\n2. Potential bugs\n3. Performance\n\nCode:\n{code}",
"translation": "Translate the following text from {source_lang} to {target_lang}. Maintain the tone and context:\n\n{text}",
"summarization": "Summarize the following text in {style} style, focusing on {focus_points}:\n\n{text}"
}
def detect_intent(self, user_input):
# 간단한 키워드 기반 의도 분류 (실무에서는 ML 모델 사용)
if "리뷰" in user_input or "review" in user_input.lower():
return "code_review"
elif "번역" in user_input or "translate" in user_input.lower():
return "translation"
elif "요약" in user_input or "summarize" in user_input.lower():
return "summarization"
return "general"
def generate_prompt(self, intent, **variables):
# 의도에 맞는 템플릿을 선택하고 변수를 바인딩
template = self.templates.get(intent, "Answer the following question: {query}")
return template.format(**variables)
설명
이것이 하는 일: 사용자의 요청을 분석하여 어떤 작업인지 판단하고, 미리 정의된 템플릿에 실제 데이터를 채워넣어 최적화된 프롬프트를 자동 생성합니다. 첫 번째로, __init__에서 다양한 작업 유형별 프롬프트 템플릿을 딕셔너리로 관리합니다.
각 템플릿은 중괄호 {}로 표시된 변수 플레이스홀더를 포함하며, 이는 Python의 str.format()과 호환됩니다. 실무에서는 이 템플릿들을 JSON 파일이나 데이터베이스에 저장하여 코드 수정 없이 업데이트할 수 있습니다.
그 다음으로, detect_intent가 사용자 입력을 분석합니다. 여기서는 간단한 키워드 매칭을 사용했지만, 실제 프로덕션에서는 BERT 기반 의도 분류 모델이나 few-shot learning을 활용한 GPT 기반 분류기를 사용합니다.
의도 분류의 정확도가 전체 시스템 품질을 좌우하므로 충분한 학습 데이터를 확보해야 합니다. generate_prompt는 분류된 의도에 해당하는 템플릿을 찾아서, 전달받은 변수들로 플레이스홀더를 채웁니다.
**variables를 사용하여 어떤 변수든 유연하게 받을 수 있으며, 템플릿에 없는 변수는 무시됩니다. 템플릿에 필요한 변수가 누락되면 KeyError가 발생하므로, 실무에서는 기본값을 설정하거나 검증 로직을 추가해야 합니다.
여러분이 이 시스템을 사용하면 새로운 작업 유형을 추가할 때 코드 수정 없이 템플릿만 추가하면 됩니다. 또한 A/B 테스트로 프롬프트 효과를 쉽게 비교할 수 있고, 버전 관리를 통해 프롬프트 변경 이력을 추적할 수 있습니다.
실전 팁
💡 템플릿을 외부 파일(JSON, YAML)로 분리하여 프롬프트 엔지니어가 코드 지식 없이도 수정할 수 있게 만드세요. 이는 팀 협업 효율을 크게 높입니다.
💡 템플릿 버전 관리를 구축하세요. 각 템플릿에 버전 번호와 성능 메트릭을 기록하면 어떤 프롬프트가 효과적인지 데이터 기반으로 판단할 수 있습니다.
💡 의도 분류에 confidence score를 도입하세요. 확신도가 낮으면 사용자에게 의도를 명확히 하도록 되묻는 것이 잘못된 작업을 수행하는 것보다 낫습니다.
💡 프롬프트 템플릿에 few-shot 예제를 포함시키세요. 예제를 동적으로 선택하여 주입하면 응답 품질이 크게 향상됩니다.
💡 다국어 지원을 고려한다면 템플릿을 언어별로 관리하고, 사용자 언어를 감지하여 자동으로 선택하는 로직을 추가하세요.
3. Few-Shot_Learning_적응
시작하며
여러분이 AI에게 새로운 작업을 시킬 때마다 긴 설명을 해야 한다면 얼마나 답답할까요? "이렇게 하면 안 되고, 저렇게 해야 해"라고 매번 설명하는 것은 비효율적입니다.
이런 문제는 특히 도메인 특화 작업에서 두드러집니다. 법률 문서 작성, 의료 기록 요약, 금융 리포트 생성 등은 일반적인 프롬프트만으로는 원하는 결과를 얻기 어렵습니다.
포맷, 톤, 전문 용어 사용 등 세밀한 가이드가 필요하죠. 바로 이럴 때 필요한 것이 Few-Shot Learning 적응입니다.
몇 개의 예제만 보여주면 AI가 패턴을 파악하여 유사한 작업을 수행합니다.
개요
간단히 말해서, 이 기법은 작업의 입력-출력 예제를 프롬프트에 포함시켜 AI가 원하는 스타일과 포맷을 학습하도록 만드는 방법입니다. 실무에서 이 기법이 중요한 이유는 fine-tuning 없이도 특정 도메인에 AI를 적응시킬 수 있기 때문입니다.
Fine-tuning은 비용이 높고 시간이 오래 걸리지만, few-shot learning은 즉시 적용 가능합니다. 예를 들어, 회사의 특정 보고서 형식을 따르도록 AI를 조정할 때 몇 개의 샘플 보고서만 제공하면 됩니다.
기존에는 긴 instruction을 작성하여 원하는 출력 형식을 설명했다면, 이제는 예제를 보여주는 것만으로 더 정확한 결과를 얻을 수 있습니다. 핵심은 관련성 높은 예제를 선택하고, 입력-출력 쌍을 명확히 구조화하여 제시하는 것입니다.
예제의 품질과 다양성이 few-shot learning의 성공을 좌우합니다.
코드 예제
# Few-Shot 예제 선택 및 주입 시스템
import numpy as np
from sklearn.metrics.pairwise import cosine_similarity
class FewShotAdapter:
def __init__(self, example_pool):
# 예제 풀: [{"input": "...", "output": "...", "embedding": [...]}]
self.example_pool = example_pool
def select_examples(self, query, query_embedding, n_examples=3):
# 쿼리와 가장 유사한 예제를 선택
similarities = []
for example in self.example_pool:
sim = cosine_similarity([query_embedding], [example["embedding"]])[0][0]
similarities.append((sim, example))
# 유사도가 높은 상위 N개 선택
similarities.sort(reverse=True, key=lambda x: x[0])
return [ex for _, ex in similarities[:n_examples]]
def build_few_shot_prompt(self, query, query_embedding, instruction):
# 선택된 예제로 few-shot 프롬프트 구성
selected = self.select_examples(query, query_embedding)
prompt = f"{instruction}\n\nExamples:\n"
for i, ex in enumerate(selected, 1):
prompt += f"\nExample {i}:\nInput: {ex['input']}\nOutput: {ex['output']}\n"
prompt += f"\nNow, process this:\nInput: {query}\nOutput:"
return prompt
설명
이것이 하는 일: 사용자의 새로운 요청이 들어오면, 과거의 비슷한 예제들을 찾아내서 "이런 식으로 해줘"라고 보여주는 방식으로 AI의 출력을 유도합니다. 첫 번째로, __init__에서 예제 풀을 초기화합니다.
각 예제는 입력, 출력, 그리고 임베딩 벡터를 포함합니다. 임베딩은 미리 OpenAI의 embedding API나 sentence-transformers로 생성해둡니다.
예제 풀은 실무에서 수백 개에서 수천 개까지 확장될 수 있으므로, 효율적인 검색을 위해 FAISS 같은 벡터 데이터베이스를 사용하는 것이 좋습니다. 그 다음으로, select_examples가 쿼리 임베딩과 예제들의 임베딩을 비교하여 코사인 유사도를 계산합니다.
유사도가 높다는 것은 의미적으로 비슷한 작업이라는 뜻이므로, 해당 예제가 AI에게 좋은 가이드가 됩니다. 상위 N개를 선택하는데, N은 보통 3~5개가 적당합니다.
너무 많으면 토큰을 낭비하고, 너무 적으면 패턴 학습이 불충분합니다. build_few_shot_prompt는 선택된 예제들을 구조화된 형식으로 배열합니다.
"Example 1: Input... Output..." 형태로 명확히 구분하여 AI가 입력-출력 관계를 쉽게 파악하도록 합니다.
마지막에 실제 쿼리를 같은 포맷으로 제시하여, AI가 자연스럽게 패턴을 따라하도록 유도합니다. 여러분이 이 시스템을 사용하면 도메인 특화 작업의 정확도가 크게 향상됩니다.
새로운 유형의 작업이 추가되어도 예제만 추가하면 되므로 확장이 용이하고, 예제를 업데이트하여 지속적으로 품질을 개선할 수 있습니다.
실전 팁
💡 예제의 다양성을 확보하세요. 비슷한 예제만 모으면 AI가 특정 패턴에만 과적합됩니다. edge case를 포함한 다양한 시나리오를 커버해야 합니다.
💡 예제 선택 시 다양성과 유사성의 균형을 맞추세요. 가장 유사한 것만 선택하는 대신, 상위 10개 중에서 다양성을 고려하여 3개를 선택하는 MMR(Maximal Marginal Relevance) 알고리즘을 사용하세요.
💡 부정 예제(bad examples)도 포함시킬 수 있습니다. "이렇게 하지 마세요"라고 명시하면 AI가 피해야 할 패턴을 학습합니다.
💡 예제의 품질이 결과를 좌우합니다. 자동 생성된 예제보다는 사람이 검증한 고품질 예제를 사용하세요. 주기적으로 예제 풀을 리뷰하고 저품질 예제를 제거하세요.
4. 토큰_예산_관리_전략
시작하며
여러분이 ChatGPT 기반 서비스를 운영하다가 월말에 청구서를 받고 깜짝 놀란 경험이 있나요? API 비용이 예상보다 10배 높게 나오는 경우가 실제로 자주 발생합니다.
이 문제는 토큰 사용을 제어하지 않고 무분별하게 긴 프롬프트를 보내거나, 응답 길이를 제한하지 않아서 생깁니다. 특히 사용자가 긴 문서를 첨부하거나 여러 번 재질문하는 경우, 토큰 소비가 폭발적으로 증가합니다.
B2C 서비스라면 수천 명의 사용자가 동시에 사용하므로 통제가 필수입니다. 바로 이럴 때 필요한 것이 토큰 예산 관리 전략입니다.
품질을 유지하면서도 비용을 최적화하는 균형점을 찾는 시스템이죠.
개요
간단히 말해서, 이 전략은 각 요청과 응답에 토큰 제한을 설정하고, 실시간으로 사용량을 추적하여 예산을 초과하지 않도록 관리하는 시스템입니다. 실무에서 이것이 중요한 이유는 예측 가능한 비용 구조가 비즈니스 지속 가능성의 핵심이기 때문입니다.
사용자별, 기능별로 토큰 할당량을 설정하면 프리미엄 사용자는 더 많은 기능을 쓰게 하고, 무료 사용자는 제한된 범위 내에서 사용하게 할 수 있습니다. 예를 들어, 무료 플랜은 하루 10K 토큰, 프로 플랜은 100K 토큰으로 차등화하는 방식입니다.
기존에는 사후적으로 비용을 확인하고 놀라는 방식이었다면, 이제는 사전에 예산을 설정하고 실시간으로 모니터링하여 통제할 수 있습니다. 핵심은 토큰 카운팅, 우선순위 기반 할당, 그리고 동적 조절 메커니즘을 결합하는 것입니다.
이러한 요소들이 비용 효율성과 사용자 경험의 균형을 만듭니다.
코드 예제
# 토큰 예산 관리 시스템
import tiktoken
class TokenBudgetManager:
def __init__(self, daily_budget=100000, user_tier_limits=None):
# daily_budget: 일일 전체 토큰 한도
self.daily_budget = daily_budget
self.daily_used = 0
self.user_tier_limits = user_tier_limits or {"free": 10000, "pro": 50000, "enterprise": 200000}
self.user_usage = {} # {user_id: used_tokens}
self.encoder = tiktoken.encoding_for_model("gpt-3.5-turbo")
def count_tokens(self, text):
# 정확한 토큰 수 계산
return len(self.encoder.encode(text))
def can_process_request(self, user_id, user_tier, prompt, max_response_tokens=500):
# 요청 처리 가능 여부 판단
prompt_tokens = self.count_tokens(prompt)
estimated_total = prompt_tokens + max_response_tokens
# 전체 일일 예산 체크
if self.daily_used + estimated_total > self.daily_budget:
return False, "Daily system budget exceeded"
# 사용자별 예산 체크
user_used = self.user_usage.get(user_id, 0)
user_limit = self.user_tier_limits[user_tier]
if user_used + estimated_total > user_limit:
return False, f"User daily limit exceeded ({user_used}/{user_limit})"
return True, "OK"
def record_usage(self, user_id, tokens_used):
# 사용량 기록
self.daily_used += tokens_used
self.user_usage[user_id] = self.user_usage.get(user_id, 0) + tokens_used
설명
이것이 하는 일: API를 호출하기 전에 토큰 소비량을 미리 계산하여 예산 내에서 처리 가능한지 확인하고, 초과 시 요청을 거부하여 비용 폭발을 방지합니다. 첫 번째로, __init__에서 일일 전체 예산과 사용자 등급별 한도를 설정합니다.
tiktoken 라이브러리의 인코더를 초기화하는데, 이는 OpenAI가 실제 사용하는 토큰 계산 방식과 동일하므로 정확한 예측이 가능합니다. 사용자 등급별 차등화는 비즈니스 모델에 따라 조정할 수 있으며, 실무에서는 더 세밀한 등급 체계를 사용합니다.
그 다음으로, count_tokens가 텍스트를 실제 토큰으로 인코딩하여 정확한 개수를 반환합니다. 이전에 사용한 "문자 수 / 4" 방식보다 훨씬 정확하며, 청구되는 실제 토큰 수와 일치합니다.
한글, 특수문자, 이모지 등이 섞여 있어도 정확히 계산됩니다. can_process_request는 요청을 처리하기 전에 두 가지를 체크합니다.
먼저 시스템 전체의 일일 예산을 확인하고, 다음으로 해당 사용자의 개인 한도를 확인합니다. max_response_tokens는 예상 응답 길이로, 실제 응답이 이보다 짧을 수 있지만 안전하게 높게 잡습니다.
예산 초과 시 명확한 에러 메시지를 반환하여 사용자에게 알립니다. record_usage는 API 호출 후 실제 사용된 토큰을 기록합니다.
OpenAI API 응답의 usage 필드에서 정확한 토큰 수를 가져와서 기록해야 합니다. 이 데이터는 실시간 대시보드나 알림 시스템에 연동하여 비정상적인 사용 패턴을 감지할 수 있습니다.
여러분이 이 시스템을 사용하면 예상치 못한 비용 폭탄을 방지할 수 있습니다. 사용자 등급별 차등 서비스로 수익 모델을 구축할 수 있고, 실시간 모니터링으로 이상 징후를 빠르게 포착하여 대응할 수 있습니다.
실전 팁
💡 일일 예산을 한 번에 소진하는 것을 막기 위해 시간대별 쿼터를 설정하세요. 예를 들어, 일일 100K 토큰이라면 시간당 4K 토큰으로 제한하여 특정 시간에 몰리는 것을 방지합니다.
💡 프롬프트 압축 기법을 병행하세요. 불필요한 반복, 장황한 설명을 제거하고 핵심만 전달하면 토큰을 30~50% 절약할 수 있습니다.
💡 캐싱 전략을 도입하세요. 동일하거나 유사한 요청은 이전 응답을 재사용하여 API 호출 자체를 줄입니다.
💡 사용자에게 토큰 사용량을 투명하게 공개하세요. "오늘 3,500/10,000 토큰 사용" 같은 정보를 제공하면 사용자가 스스로 조절합니다.
💡 긴급 상황을 위한 버퍼를 남겨두세요. 일일 예산의 90%를 일반 사용자에게 할당하고 10%는 프리미엄 사용자나 중요 작업을 위해 예약합니다.
5. 대화_상태_머신_구현
시작하며
여러분이 복잡한 멀티턴 대화를 처리하는 AI를 만들 때, "이전 단계를 완료해야 다음으로 넘어갈 수 있는" 흐름을 어떻게 관리하시나요? 예를 들어 호텔 예약 챗봇에서 날짜 → 인원 → 객실 타입 → 결제 순서를 강제해야 합니다.
이 문제는 무상태(stateless) AI 모델의 본질적인 한계입니다. GPT는 각 요청을 독립적으로 처리하므로, 대화가 어느 단계에 있는지, 다음에 무엇을 물어봐야 하는지 자동으로 알지 못합니다.
사용자가 갑자기 순서를 뛰어넘거나 이전 단계로 돌아가면 혼란이 생깁니다. 바로 이럴 때 필요한 것이 대화 상태 머신입니다.
대화를 명확한 상태들로 나누고, 각 상태에서 가능한 전환을 정의하여 체계적으로 흐름을 제어합니다.
개요
간단히 말해서, 이 시스템은 대화를 여러 상태(state)로 모델링하고, 사용자 입력에 따라 상태를 전환하면서 각 상태에 맞는 프롬프트와 검증을 적용하는 구조입니다. 실무에서 이것이 필수인 이유는 트랜잭션이나 민감한 정보를 다루는 대화에서 순서와 완결성이 중요하기 때문입니다.
예를 들어, 의료 상담 챗봇에서 증상 → 병력 → 알레르기 → 처방 순으로 진행해야 하는데, 사용자가 중간을 건너뛰면 위험합니다. 기존에는 대화 히스토리를 보고 AI가 "추측"하는 방식이었다면, 이제는 명확한 상태 전환 규칙으로 확실하게 제어할 수 있습니다.
핵심은 상태 정의, 전환 조건, 그리고 각 상태별 프롬프트 전략을 결합하는 것입니다. 이러한 구조가 복잡한 비즈니스 로직을 안정적으로 구현하게 해줍니다.
코드 예제
# 대화 상태 머신 구현
from enum import Enum
class ConversationState(Enum):
INIT = "init"
COLLECTING_DATE = "collecting_date"
COLLECTING_GUESTS = "collecting_guests"
COLLECTING_ROOM_TYPE = "collecting_room_type"
CONFIRMING = "confirming"
COMPLETED = "completed"
class ConversationStateMachine:
def __init__(self):
self.state = ConversationState.INIT
self.data = {} # 수집된 정보 저장
# 각 상태별 프롬프트 정의
self.state_prompts = {
ConversationState.INIT: "안녕하세요! 호텔 예약을 도와드리겠습니다. 체크인 날짜를 알려주세요.",
ConversationState.COLLECTING_DATE: "날짜를 입력해주세요 (예: 2025-12-25):",
ConversationState.COLLECTING_GUESTS: "투숙 인원을 알려주세요:",
ConversationState.COLLECTING_ROOM_TYPE: "객실 타입을 선택하세요 (스탠다드/디럭스/스위트):",
ConversationState.CONFIRMING: "예약 정보를 확인해주세요:\n{data}\n확인하시겠습니까? (예/아니오)"
}
def get_prompt(self):
# 현재 상태에 맞는 프롬프트 반환
prompt = self.state_prompts[self.state]
if self.state == ConversationState.CONFIRMING:
return prompt.format(data=self.data)
return prompt
def process_input(self, user_input):
# 사용자 입력을 처리하고 상태 전환
if self.state == ConversationState.INIT:
self.state = ConversationState.COLLECTING_DATE
elif self.state == ConversationState.COLLECTING_DATE:
self.data["date"] = user_input
self.state = ConversationState.COLLECTING_GUESTS
elif self.state == ConversationState.COLLECTING_GUESTS:
self.data["guests"] = user_input
self.state = ConversationState.COLLECTING_ROOM_TYPE
elif self.state == ConversationState.COLLECTING_ROOM_TYPE:
self.data["room_type"] = user_input
self.state = ConversationState.CONFIRMING
elif self.state == ConversationState.CONFIRMING:
if "예" in user_input:
self.state = ConversationState.COMPLETED
return "예약이 완료되었습니다!"
return self.get_prompt()
설명
이것이 하는 일: 대화를 여러 단계로 쪼개서, 한 단계가 완료되어야 다음으로 넘어가도록 강제합니다. 마치 양식을 순서대로 채우듯이 대화를 진행시킵니다.
첫 번째로, Enum으로 가능한 모든 상태를 정의합니다. 이는 오타나 잘못된 상태 참조를 컴파일 타임에 잡을 수 있게 해줍니다.
상태 이름은 명확하게 "무엇을 하는 단계인지" 표현해야 하며, 실무에서는 10~20개의 상태를 가질 수 있습니다. 예를 들어 결제 흐름은 카드정보입력 → 주소확인 → OTP인증 → 결제실행 → 영수증발급 같은 세밀한 단계로 나뉩니다.
그 다음으로, __init__에서 초기 상태와 데이터 저장소를 준비합니다. data 딕셔너리는 대화 진행 중 수집된 모든 정보를 담으며, 이는 세션 관리 시스템(Redis 등)에 영구 저장되어야 합니다.
state_prompts는 각 상태에서 사용자에게 보여줄 메시지를 정의합니다. process_input은 현재 상태에 따라 다르게 동작하는 핵심 로직입니다.
간단한 if-elif 체인으로 구현했지만, 실무에서는 state pattern이나 strategy pattern을 사용하여 각 상태를 별도 클래스로 분리하는 것이 유지보수에 좋습니다. 입력 검증 로직(날짜 형식 확인, 인원 수 범위 체크 등)을 추가하면 더욱 견고해집니다.
상태 전환은 명시적으로 self.state = ...로 수행되며, 이는 추적과 디버깅이 쉽습니다. 로그에 "COLLECTING_DATE → COLLECTING_GUESTS 전환됨"을 기록하면 대화 흐름을 정확히 재현할 수 있습니다.
여러분이 이 패턴을 사용하면 복잡한 대화 시나리오를 예측 가능하게 관리할 수 있습니다. 각 단계에서 필요한 검증을 강제하여 데이터 품질을 보장하고, 사용자가 어디서 이탈하는지 분석하여 UX를 개선할 수 있습니다.
실전 팁
💡 상태 전환 다이어그램을 먼저 그려보세요. 모든 가능한 전환 경로를 시각화하면 빠뜨린 엣지 케이스를 발견할 수 있습니다.
💡 뒤로 가기 기능을 지원하세요. 사용자가 "이전 단계로"라고 하면 상태 스택을 유지하여 돌아갈 수 있게 만들면 UX가 크게 향상됩니다.
💡 타임아웃을 구현하세요. 사용자가 10분 동안 응답하지 않으면 상태를 초기화하거나 저장하여 나중에 재개할 수 있게 합니다.
💡 각 상태마다 허용되는 명령어를 정의하세요. "취소", "도움말", "처음부터" 같은 메타 명령어는 어느 상태에서나 작동해야 합니다.
💡 상태 전환을 이벤트 기반으로 만들면 더 확장 가능합니다. "날짜_입력됨" 이벤트를 발생시키면 해당 리스너가 다음 상태로 전환하는 식입니다.
6. 사용자_프로파일_기반_적응
시작하며
여러분이 매번 AI에게 "나는 파이썬 초보자야"라고 설명해야 한다면 얼마나 불편할까요? 또는 이전에 좋아했던 코드 스타일을 다시 요청해야 하는 상황이요.
이런 문제는 AI가 사용자의 선호도, 숙련도, 과거 상호작용을 기억하지 못해서 발생합니다. 같은 사용자가 100번째 대화를 해도 AI는 여전히 처음 만난 것처럼 행동합니다.
이는 사용자 경험을 크게 떨어뜨리고, 반복적인 설명으로 토큰도 낭비합니다. 바로 이럴 때 필요한 것이 사용자 프로파일 기반 적응입니다.
사용자의 특성을 학습하고 저장하여, 매 대화에서 자동으로 반영합니다.
개요
간단히 말해서, 이 시스템은 사용자별로 프로파일(선호도, 전문성, 과거 대화 패턴)을 구축하고, 이를 프롬프트에 자동으로 주입하여 개인화된 응답을 생성하는 방법입니다. 실무에서 이것이 중요한 이유는 개인화가 사용자 만족도와 retention에 직접적인 영향을 미치기 때문입니다.
GitHub Copilot이 사용자의 코딩 스타일을 학습하여 맞춤형 제안을 하거나, Netflix가 취향에 맞는 콘텐츠를 추천하는 것처럼, AI 어시스턴트도 사용자를 이해해야 합니다. 예를 들어, 시니어 개발자에게는 간결한 설명을, 주니어에게는 상세한 설명을 자동으로 제공할 수 있습니다.
기존에는 모든 사용자를 동일하게 대했다면, 이제는 각 사용자의 컨텍스트를 반영하여 더 적절하고 효율적인 응답을 제공할 수 있습니다. 핵심은 프로파일 수집, 동적 업데이트, 그리고 프롬프트 커스터마이제이션을 결합하는 것입니다.
이러한 요소들이 장기적인 사용자 관계를 구축합니다.
코드 예제
# 사용자 프로파일 기반 적응 시스템
class UserProfileAdapter:
def __init__(self):
# 사용자별 프로파일 저장소 (실무에서는 DB 사용)
self.profiles = {}
def get_or_create_profile(self, user_id):
# 프로파일 조회 또는 생성
if user_id not in self.profiles:
self.profiles[user_id] = {
"expertise_level": "intermediate", # beginner, intermediate, expert
"preferred_language": "Python",
"code_style": "verbose", # concise, verbose, commented
"interaction_history": [],
"topics_of_interest": []
}
return self.profiles[user_id]
def update_profile_from_interaction(self, user_id, query, response):
# 상호작용으로부터 프로파일 업데이트
profile = self.get_or_create_profile(user_id)
profile["interaction_history"].append({"query": query, "response": response})
# 간단한 패턴 인식 (실무에서는 ML 모델 사용)
if "초보" in query or "잘 모르겠" in query:
profile["expertise_level"] = "beginner"
elif "advanced" in query.lower() or "optimization" in query.lower():
profile["expertise_level"] = "expert"
def build_personalized_prompt(self, user_id, base_prompt):
# 프로파일을 반영한 개인화 프롬프트 생성
profile = self.get_or_create_profile(user_id)
context = f"""User Profile:
- Expertise: {profile['expertise_level']}
- Preferred Language: {profile['preferred_language']}
- Code Style: {profile['code_style']}
Adjust your response accordingly. For beginners, provide detailed explanations. For experts, be concise.
"""
return context + base_prompt
설명
이것이 하는 일: 사용자가 누구인지, 어떤 스타일을 선호하는지, 어떤 수준인지를 기억해뒀다가, 다음 대화 때 자동으로 그에 맞춰서 응답을 조정합니다. 첫 번째로, get_or_create_profile은 사용자가 처음 방문하면 기본 프로파일을 생성하고, 이미 있으면 불러옵니다.
기본값으로 "intermediate" 수준을 가정하며, 이는 대부분의 사용자에게 적절한 균형점입니다. 실무에서는 이 프로파일을 PostgreSQL이나 MongoDB에 저장하여 영구 보존하고, 사용자 간 프라이버시를 보장하기 위해 암호화합니다.
그 다음으로, update_profile_from_interaction이 매 대화 후 호출되어 프로파일을 업데이트합니다. 여기서는 간단한 키워드 기반 업데이트를 사용했지만, 실제로는 더 정교한 방법을 사용합니다.
예를 들어, 사용자가 자주 묻는 주제를 topics_of_interest에 축적하고, 질문의 복잡도를 분석하여 expertise_level을 동적으로 조정할 수 있습니다. 머신러닝을 적용하면 사용자의 만족도(좋아요/싫어요 피드백)를 학습하여 더 정확하게 선호도를 파악할 수 있습니다.
build_personalized_prompt는 프로파일 정보를 시스템 프롬프트에 주입합니다. "For beginners, provide detailed explanations"라는 지시가 있으면 AI는 자동으로 응답 스타일을 조정합니다.
이는 zero-shot instruction following을 활용한 것으로, 별도 학습 없이도 효과적입니다. 프로파일의 각 필드를 활용하여 더 구체적인 지시를 만들 수도 있습니다.
여러분이 이 시스템을 사용하면 사용자가 "AI가 나를 이해한다"고 느끼게 됩니다. 반복적인 설명이 줄어들어 대화 효율이 높아지고, 개인화된 경험으로 인해 사용자 이탈률이 감소합니다.
장기적으로는 사용자 데이터를 분석하여 제품 개선 인사이트도 얻을 수 있습니다.
실전 팁
💡 명시적 프로파일 설정을 제공하세요. 사용자가 직접 "나는 초보자입니다" 또는 "간결한 답변 선호"를 설정할 수 있게 하면 더 정확합니다.
💡 프로파일 업데이트는 점진적으로 하세요. 한 번의 상호작용으로 크게 바꾸지 말고, 여러 번의 패턴을 보고 확신이 생기면 조정합니다.
💡 프라이버시를 최우선으로 하세요. 프로파일에 민감한 정보(나이, 위치, 직장 등)는 최소한으로 저장하고, 사용자가 언제든 삭제할 수 있게 합니다.
💡 컨텍스트 창 제한을 고려하여 프로파일 정보를 압축하세요. 모든 과거 대화를 넣는 대신, 요약된 특성만 추출하여 토큰을 절약합니다.
💡 A/B 테스트로 개인화 효과를 측정하세요. 개인화가 실제로 만족도를 높이는지, 어떤 요소가 가장 영향력 있는지 데이터로 검증합니다.
7. 컨텍스트_압축_기법
시작하며
여러분이 50턴에 걸친 긴 대화를 나눈 후, AI가 처음 10턴의 중요한 정보를 잊어버린 경험이 있나요? 대화 히스토리가 길어질수록 토큰 제한에 걸리거나, API 비용이 폭증하는 문제가 발생합니다.
이 문제는 특히 컨설팅, 기술 지원, 교육 같은 장기 대화 시나리오에서 심각합니다. 사용자가 처음에 말한 문제 상황이나 제약 조건이 나중에 필요한데, 이미 컨텍스트에서 밀려난 경우가 많습니다.
단순히 최근 N개 메시지만 유지하면 중요한 정보를 잃게 됩니다. 바로 이럴 때 필요한 것이 컨텍스트 압축 기법입니다.
긴 대화를 핵심 정보만 남기고 요약하여 토큰은 절약하면서도 컨텍스트는 유지합니다.
개요
간단히 말해서, 이 기법은 오래된 대화 내용을 AI가 요약하여 압축된 형태로 저장하고, 새로운 대화에서는 이 요약본을 컨텍스트로 사용하는 방법입니다. 실무에서 이것이 필수인 이유는 토큰 효율성과 정보 보존의 균형을 맞추기 위해서입니다.
예를 들어, 20턴의 대화(5000 토큰)를 500 토큰의 요약으로 압축하면, 90%의 토큰을 절약하면서도 핵심 내용은 유지할 수 있습니다. 고객 지원 챗봇에서 "고객이 이전에 시도한 해결 방법"을 기억하면서도 토큰을 절약하는 데 매우 효과적입니다.
기존에는 오래된 메시지를 단순히 삭제했다면, 이제는 지능적으로 압축하여 중요한 정보는 계속 유지할 수 있습니다. 핵심은 주기적 요약, 계층적 압축, 그리고 중요도 기반 필터링을 결합하는 것입니다.
이러한 전략들이 긴 대화에서도 안정적인 품질을 보장합니다.
코드 예제
# 컨텍스트 압축 시스템
import openai
class ContextCompressor:
def __init__(self, compression_threshold=10, max_summary_tokens=500):
# compression_threshold: 이 개수 이상 메시지가 쌓이면 압축
self.compression_threshold = compression_threshold
self.max_summary_tokens = max_summary_tokens
self.messages = []
self.compressed_context = None
def add_message(self, role, content):
# 메시지 추가 및 압축 트리거
self.messages.append({"role": role, "content": content})
if len(self.messages) >= self.compression_threshold:
self._compress_context()
def _compress_context(self):
# 오래된 메시지를 요약으로 압축
messages_to_compress = self.messages[:-5] # 최근 5개는 유지
# AI에게 요약 요청
summary_prompt = "다음 대화를 핵심 정보만 남겨 요약해주세요:\n\n"
for msg in messages_to_compress:
summary_prompt += f"{msg['role']}: {msg['content']}\n"
# 실제로는 openai.ChatCompletion.create() 호출
# summary = call_ai_for_summary(summary_prompt)
summary = "[이전 대화 요약] 사용자는 파이썬 웹 개발을 학습 중이며..."
self.compressed_context = summary
# 압축된 메시지 제거, 최근 것만 유지
self.messages = self.messages[-5:]
def get_full_context(self):
# 압축된 컨텍스트 + 최근 메시지 조합
context = []
if self.compressed_context:
context.append({"role": "system", "content": f"Previous conversation summary: {self.compressed_context}"})
context.extend(self.messages)
return context
설명
이것이 하는 일: 대화가 길어지면 중간 부분을 요약본으로 압축해서, 마치 "이전에 이런저런 얘기를 했었죠"라고 간단히 언급하는 것처럼 처리합니다. 첫 번째로, add_message는 새 메시지를 추가하고, 메시지 개수가 임계값(예: 10개)을 넘으면 자동으로 압축을 트리거합니다.
이 임계값은 대화의 성격에 따라 조정해야 합니다. 짧은 질의응답 스타일이면 10개, 긴 컨설팅 스타일이면 20개 정도가 적절합니다.
그 다음으로, _compress_context가 실제 압축을 수행합니다. 최근 5개 메시지는 원본 그대로 유지하는데, 이는 바로 직전 맥락이 가장 중요하기 때문입니다.
나머지 오래된 메시지들은 하나의 요약 프롬프트로 만들어서 AI에게 전달합니다. 여기서 중요한 점은 요약 품질을 높이기 위해 "핵심 정보, 결정 사항, 미해결 문제를 중심으로 요약하라"는 구체적인 지시를 주는 것입니다.
요약 생성에 사용하는 모델은 본 대화와 다른 저렴한 모델(GPT-3.5 등)을 사용할 수 있습니다. 요약은 완벽한 응답만큼 정교할 필요가 없으므로 비용을 절약할 수 있습니다.
생성된 요약은 compressed_context에 저장되고, 원본 메시지는 삭제됩니다. get_full_context는 API 호출 시 사용할 전체 컨텍스트를 구성합니다.
요약이 있으면 시스템 메시지로 앞에 배치하고, 그 뒤에 최근 메시지들을 붙입니다. 이렇게 하면 AI는 "이전 대화 요약"을 참고하면서 최근 대화에 집중할 수 있습니다.
여러분이 이 기법을 사용하면 50턴, 100턴의 긴 대화도 안정적으로 처리할 수 있습니다. 토큰 비용을 크게 절감하면서도, 사용자가 처음에 언급한 중요한 정보를 끝까지 기억하게 됩니다.
실전 팁
💡 계층적 요약을 사용하세요. 10턴을 1개로 압축하고, 그 요약 10개를 다시 1개로 압축하는 식으로 여러 레벨을 유지하면 더 많은 컨텍스트를 담을 수 있습니다.
💡 중요도 점수를 부여하여 선택적으로 압축하세요. "문제 정의", "결정 사항" 같은 중요한 메시지는 원본 유지, 잡담은 적극 압축합니다.
💡 요약의 정확도를 검증하세요. 원본과 요약을 비교하여 중요 정보가 누락되지 않았는지 샘플 체크하고, 필요하면 요약 프롬프트를 개선합니다.
💡 사용자에게 압축 사실을 알리세요. "이전 대화 내용이 요약되었습니다"라고 표시하면 투명성이 높아지고, 필요 시 원본을 다시 불러올 수 있는 옵션을 제공합니다.
8. 동적_Temperature_조절
시작하며
여러분이 AI에게 코드 디버깅을 요청할 때와 창의적인 아이디어를 요청할 때, 같은 설정을 사용하면 어떻게 될까요? 디버깅에는 정확하고 결정론적인 답변이 필요한 반면, 아이디어 브레인스토밍에는 다양하고 창의적인 답변이 필요합니다.
이 문제는 GPT의 temperature 파라미터가 고정되어 있을 때 발생합니다. Temperature는 응답의 무작위성을 제어하는데, 높으면(1.0 이상) 창의적이지만 불안정하고, 낮으면(0.2 이하) 일관적이지만 반복적입니다.
모든 작업에 하나의 값을 사용하면 어느 한쪽에서 최적이 아닙니다. 바로 이럴 때 필요한 것이 동적 temperature 조절입니다.
작업 유형을 자동으로 판단하여 적절한 temperature를 설정합니다.
개요
간단히 말해서, 이 시스템은 사용자 요청의 성격(사실 확인, 창의적 생성, 분석 등)을 분석하여, 각 상황에 최적화된 temperature 값을 자동으로 선택하는 방법입니다. 실무에서 이것이 중요한 이유는 품질과 다양성의 트레이드오프를 상황별로 최적화하기 위해서입니다.
예를 들어, 법률 문서 작성(낮은 temperature)과 마케팅 슬로건 생성(높은 temperature)은 완전히 다른 접근이 필요합니다. 하나의 고정값으로는 두 작업을 모두 잘 처리할 수 없습니다.
기존에는 개발자가 수동으로 temperature를 설정했다면, 이제는 AI가 작업 유형을 인식하여 자동으로 조절할 수 있습니다. 핵심은 작업 분류, temperature 매핑 규칙, 그리고 피드백 루프를 결합하는 것입니다.
이러한 요소들이 각 작업에서 최고 품질을 달성하게 합니다.
코드 예제
# 동적 Temperature 조절 시스템
class DynamicTemperatureController:
def __init__(self):
# 작업 유형별 최적 temperature 매핑
self.temperature_map = {
"factual": 0.2, # 사실 확인, 정보 검색
"coding": 0.3, # 코드 생성, 디버깅
"analysis": 0.4, # 데이터 분석, 문제 해결
"translation": 0.3, # 번역
"creative_writing": 0.9, # 스토리, 시 작성
"brainstorming": 1.0, # 아이디어 생성
"general": 0.7 # 일반 대화
}
def classify_task_type(self, query):
# 쿼리로부터 작업 유형 분류
query_lower = query.lower()
if any(word in query_lower for word in ["사실", "정보", "what is", "when did"]):
return "factual"
elif any(word in query_lower for word in ["코드", "code", "debug", "function"]):
return "coding"
elif any(word in query_lower for word in ["분석", "analyze", "compare"]):
return "analysis"
elif any(word in query_lower for word in ["번역", "translate"]):
return "translation"
elif any(word in query_lower for word in ["스토리", "story", "시", "poem"]):
return "creative_writing"
elif any(word in query_lower for word in ["아이디어", "brainstorm", "창의"]):
return "brainstorming"
else:
return "general"
def get_temperature(self, query):
# 쿼리에 맞는 최적 temperature 반환
task_type = self.classify_task_type(query)
temperature = self.temperature_map[task_type]
print(f"Task type: {task_type}, Temperature: {temperature}")
return temperature
설명
이것이 하는 일: 사용자가 무엇을 원하는지 분석해서, 정확한 답이 필요하면 AI를 보수적으로, 창의적인 결과가 필요하면 AI를 자유롭게 만듭니다. 첫 번째로, __init__에서 작업 유형별 최적 temperature 값을 딕셔너리로 정의합니다.
이 값들은 실험과 경험을 통해 도출된 것입니다. 예를 들어, "factual"에 0.2를 설정한 이유는 사실 정보는 일관되고 정확해야 하며, 창의성이 오히려 해롭기 때문입니다.
반대로 "brainstorming"에 1.0을 설정한 것은 다양한 아이디어가 목적이므로 예측 불가능성이 장점이 되기 때문입니다. 그 다음으로, classify_task_type이 쿼리를 분석하여 작업 유형을 판단합니다.
간단한 키워드 매칭을 사용했지만, 실무에서는 더 정교한 분류기를 사용합니다. 예를 들어, 사전 학습된 텍스트 분류 모델(BERT fine-tuned)을 사용하면 더 정확하게 의도를 파악할 수 있습니다.
또한 사용자의 과거 패턴을 학습하여 개인화된 분류도 가능합니다. 작업 유형 분류는 다중 레이블일 수도 있습니다.
"파이썬으로 창의적인 게임 코드를 작성해줘"는 "coding"과 "creative_writing"의 중간이므로, 두 값을 평균내서 사용할 수 있습니다. 또한 사용자가 명시적으로 "다양한 답변을 원해요"라고 하면 이를 우선시합니다.
get_temperature는 분류 결과에 따라 적절한 temperature를 반환하며, 로깅을 통해 어떤 결정을 내렸는지 추적 가능하게 합니다. 이 정보는 A/B 테스트나 품질 분석에 유용하게 사용됩니다.
여러분이 이 시스템을 사용하면 각 작업에서 최적의 결과를 얻을 수 있습니다. 디버깅 요청에는 정확한 수정을 제공하고, 마케팅 슬로건 요청에는 창의적인 아이디어를 제공하여 사용자 만족도를 높입니다.
실전 팁
💡 temperature뿐만 아니라 top_p도 함께 조절하세요. 정확성이 중요한 작업은 top_p=0.1로 낮추고, 창의성이 중요한 작업은 top_p=0.9로 높입니다.
💡 사용자 피드백을 수집하여 temperature 값을 지속적으로 최적화하세요. "이 답변이 도움이 되었나요?"에 대한 반응을 분석하여 작업별 최적값을 조정합니다.
💡 동일 작업을 여러 temperature로 생성하여 앙상블하는 방법도 효과적입니다. 예를 들어, 0.5와 0.9로 각각 3개씩 생성하여 사용자에게 선택하게 합니다.
💡 특정 도메인(의료, 법률 등)에서는 안전을 위해 temperature 상한선을 설정하세요. 아무리 창의적 작업이라도 0.7을 넘지 않도록 제한할 수 있습니다.
💡 실시간 조정 기능을 제공하세요. 사용자가 "더 창의적으로" 또는 "더 정확하게"라고 요청하면 즉시 temperature를 조절하여 재생성합니다.