같은 지시라도 한국어의 존대·문체·포맷 설정에 따라 결과가 크게 달라집니다. Claude 3.5 Sonnet 프롬프트를 한국어로 설계할 때 꼭 챙겨야 할 톤·형식·컨텍스트 전략과 바로 가져다 쓸 수 있는 템플릿을 정리했습니다.
왜 한국어 특화 전략이 필요한가
한국어는 존대 체계와 문체 변화가 뚜렷합니다. 같은 요구라도 “정중한 안내문”과 “개발자 메모”는 길이, 어휘, 종결어미가 달라집니다. Claude 3.5 Sonnet은 지시가 구체적일수록 안정적으로 따르므로, 한국어 프롬프트에서 다음을 명시하면 품질이 올라갑니다.
- 대상 독자: 초보자/전문가/내부팀 등
- 톤 앤 매너: 존댓말/반말, 친근/격식, 홍보성 배제 등
- 출력 포맷: HTML/JSON/불릿/표 등
- 길이·구조 제약: 글자/문단/소제목 규칙
- 용어 정책: 한글 우선, 괄호 병기, 번역투 금지
프롬프트 골격: 역할·목표·컨텍스트·규칙·포맷·검증
아래 프레임을 기본으로 쓰면 누락을 줄이고 재현성을 높일 수 있습니다.
[역할] 당신은 (…역할/전문성/시점…)입니다. [목표] 이번 요청의 최우선 목표는 (…)입니다. 1문장으로 요약해 다시 확인하세요. [대상/톤] 대상은 (…), 톤은 (…존댓말/격식/간결…)로 통일합니다. [컨텍스트] 참고 자료/제약/가정: (…핵심만 불릿 3~5개…) [규칙] 금지/우선순위/길이/용어 정책: (…) [출력 포맷] 반드시 (…HTML/JSON/불릿…) 구조를 따릅니다: (…샘플 스켈레톤…) [검증] 제출 전 체크리스트: (…3~5개 항목…) [확인 질문] 누락 방지를 위해 작업 전 질문 1~2개만 하세요.
샘플 스켈레톤(HTML 기사)
<h2>소제목</h2> <p>단락(3~4문장)</p> <h3>세부 소제목</h3> <ul> <li>핵심 포인트 1</li> <li>핵심 포인트 2</li> </ul>
톤·문체를 확실히 고정하는 문구
- 존댓말 고정: “모든 문장은 ‘습니다/합니다’ 체로 작성합니다. 감탄사와 과장 표현은 사용하지 않습니다.”
- 격식·간결: “문장은 20자 내외로 간결하게, 한 문단은 3문장 이내로 제한합니다.”
- 홍보성 배제: “광고·선정적 표현 금지. 기능·절차 위주로 설명합니다.”
- 용어 정책: “영문 용어는 첫 번째만 (영문) 병기, 이후 한글만 사용합니다.”
예시:
톤 가이드: 내부 실무자 대상, 존댓말, 결정론적 어조 금지, 선택지 제시(최대 3개), 과장 금지.
컨텍스트 주입은 “짧고 정확하게”
길게 붙이기보다 핵심만 구조화해 전달하세요.
프로젝트 배경 - 대상: 전자상거래 운영팀 신입 교육 자료 - 목표: 반품 응대 스크립트 표준화 - 제약: 환불 정책 최신 버전(2024-08) 기준, 예외 사례는 보류
긴 자료를 줄 때는 구획 표시로 범위를 분명히 합니다.
다음의 [정책 발췌]만 참고하세요. 다른 지식은 사용하지 마세요. [정책 발췌 시작] ...핵심 10~15줄... [정책 발췌 종료]
출력 포맷을 안정화하는 방법
Claude 3.5 Sonnet 프롬프트에서 포맷 일탈을 줄이려면 스키마를 먼저 보여주고, 필수/선택 필드를 분리하세요.
반드시 아래 JSON 스키마로만 응답합니다.
{
"title": "string(60자 이내, 키워드 포함)",
"summary": "string(2문장)",
"bullets": ["string", "string", "string"]
}
제출 전 확인: 키 누락 금지, 추가 텍스트 금지.
HTML을 요구할 때는 <article> 내부에 들어갈 최소 골격까지 제시하세요.
<h2>문제 정의</h2> <p>...</p> <h2>해결 전략</h2> <ul><li>...</li></ul>
품질을 올리는 한국어 평가 루브릭
- 적합성: 사용자 목표와 대상 독자에 부합하는가
- 명료성: 문장 길이·어휘 난도가 지시에 맞는가
- 일관성: 존댓말·표기·용어가 전면 일관한가
- 구조: 요구한 H2/H3·불릿·표 등 구조를 지켰는가
- 검증 가능성: 근거가 필요한 부분은 출처/조건을 밝히는가
루브릭을 프롬프트 말미에 포함하면 자가 점검이 자동화됩니다.
흔한 실패와 디버깅 루프
1) 톤이 섞임
원인: 존댓말 규칙·대상 독자 누락. 해결: 톤·대상·금칙어를 상단에 고정하고, “제출 전 톤 점검” 체크박스 포함.
제출 전 체크: [ ] 모든 문장 ‘습니다’체 [ ] 2인칭 호칭 금지 [ ] 과장/광고 표현 없음
2) 포맷 붕괴
원인: 스키마 미제시·예시 부족. 해결: 포맷 스켈레톤+불용 텍스트 금지 문구+검증 질문.
“추가 설명 없이 아래 포맷만 출력하세요. 포맷 외 텍스트가 있으면 실패로 간주합니다.”
3) 길이 초과/부족
원인: 목표 길이 미지정. 해결: 문단/문장/총자수 범위 제시, 초과 시 요약 재시도 규칙 명시.
“총 900~1,100자. 초과 시 핵심만 남기고 요약해 800~900자로 재제출.”
4) 번역투·어색한 어휘
원인: 직역. 해결: 금칙 표현 목록·대체 표현 사전 제공.
금칙어: “실행하세요”, “~될 것입니다” → 대체: “실행합니다”, “~합니다”
실무 예시 프롬프트 3종
1) 기술 문서 초안
[역할] 기술 문서 작성자 [목표] 내부 위키용 기능 업데이트 노트 초안 작성 [대상/톤] 사내 엔지니어, 존댓말, 간결·사실 위주 [컨텍스트] 버전 2.1 주요 변경: API rate limit 상향, 오류 코드 추가(4292) [규칙] 과장 금지, 능동태, 표준 용어 사용(한글 우선, 첫 언급만 영문 병기) [출력 포맷] H2/H3/불릿으로 HTML 구성 [검증] 변경점/영향/마이그레이션/주의사항 4블록 존재 확인
2) 고객 응대 스크립트
[역할] 고객센터 스크립트 디자이너 [목표] 반품 요청 3단계 응대 흐름 제시 [대상/톤] 일반 고객, 존댓말, 공감+정확 [규칙] 사과→정책 안내→대안 순서. 과장/보장 표현 금지. [출력 포맷] 단계별 불릿, 말풍선형 문장 각 2개
3) 마케팅 카피(비홍보형)
[역할] 웹 카피라이터 [목표] 기능 하이라이트 3개를 정보 중심으로 요약 [대상/톤] 비교 검토 중인 잠재 고객, 격식·중립 톤 [규칙] 성능 수치 미기재, 과장 금지, CTA 1문장
워크플로우 팁: 재현성과 협업을 위한 운영
- 버전 태깅: 프롬프트 상단에 v0.1, 날짜, 변경 로그 1줄을 남깁니다.
- 테스트 세트: 대표 시나리오 5~10개로 회귀 테스트. 결과를 표준 포맷으로 저장.
- A/B 비교: 톤·포맷 지시의 차이만 둔 두 버전을 동일 입력으로 비교.
- 가드레일: 금칙어, 포맷 일탈 시 재요청 규칙을 프롬프트에 포함.
최종 체크리스트
- 대상·톤·길이·용어 정책이 상단에 명시되었는가
- 컨텍스트가 짧고 구조화되어 있는가
- 출력 포맷(HTML/JSON/불릿) 예시가 있는가
- 품질 루브릭/체크박스가 포함되었는가
- 금칙어/오류 시 재시도 규칙을 넣었는가
위 요소를 갖춘 한국어 프롬프트는 Claude 3.5 Sonnet에서 톤·문체·포맷의 일관성을 높이고, 수정 비용을 크게 줄여 줍니다. 작은 지시의 차이가 결과를 바꾸니, 템플릿으로 시작해 팀 상황에 맞게 점진적으로 다듬어 보세요.
