왜 리팩토링이 필요한가
Claude 3.5 Sonnet은 균형 잡힌 추론·요약·코딩·글쓰기 능력을 제공하지만, 결과 품질은 결국 프롬프트 설계에 달려 있습니다. 초안으로 시작해도 되지만, 실제 운영에서 일관성과 재현성을 얻으려면 리팩토링이 필수입니다. 이 글은 실패 원인 진단부터 시스템 프롬프트 구성, 출력 형식 고정, 자동 평가까지 이어지는 실전 리팩토링 흐름을 제시합니다.
프롬프트가 실패하는 진짜 이유 8가지
1) 목표가 모호하다
“잘 정리해줘”는 기준이 없습니다. 무엇을 누구를 위해 어떤 형식으로 정리할지 명시하세요.
2) 컨텍스트가 부족하다
도메인·독자 수준·톤·사용 목적이 빠지면 모델은 평균적인 답을 냅니다. 핵심 배경과 예시를 최소 1~2개는 포함하세요.
3) 제약조건이 비어 있다
길이, 금지사항, 참고 순서, 출력 스키마가 없으면 변동성이 커집니다. 필수 제약을 앞단에 고정하세요.
4) 역할 지시가 없다
역할이 없으면 답변 관점이 흐립니다. “당신은 SEO 에디터”처럼 태세를 지정하면 판단 기준이 선명해집니다.
5) 입력 구조가 들쭉날쭉하다
매번 입력 필드가 달라지면 모델은 혼란스러워집니다. 고정된 섹션 헤더와 플레이스홀더를 사용하세요.
6) 평가 기준이 없다
뭘 개선할지 모르면 고치기 어렵습니다. 평가 루브릭으로 수용 기준을 정하고 예시를 축적하세요.
7) 토큰 낭비·초과
장황한 지침과 반복 컨텍스트는 품질을 떨어뜨립니다. 요약·참조 앵커·링크 키만 남기는 토큰 최적화가 필요합니다.
8) 톤·독자 정의 부재
대상 독자와 문체를 지정하지 않으면 결과 톤이 흔들립니다. “실무자 대상, 단계별 안내, 예시는 한국 서비스 기준”처럼 구체화하세요.
리팩토링 접근법: 최소 수정·측정·학습 루프
- 현 상태 측정: 기준 데이터 10~20개로 실행해 실패 패턴을 수집합니다. 어디서 왜 빗나갔는지 간단 기록을 남깁니다.
- 가설 수립: 한 번에 한 변수만 바꿉니다. 예: 출력 스키마 추가, 금지사항 명시, 컨텍스트 예시 1개 보강 등.
- 평가 루브릭: 정확성, 일관성, 포맷 준수, 톤 적합도 등 3~5개 기준으로 점검 체크를 만듭니다.
- 버전 관리: 프롬프트 상단에 버전, 변경 이유, 날짜를 주석으로 남깁니다.
Claude 3.5 Sonnet에 맞춘 시스템 프롬프트 설계
시스템 프롬프트는 프롬프트의 헌법입니다. 가벼운 문장으로 역할, 우선순위, 금지사항을 먼저 고정하세요.
[role] 당신은 한국어 SEO 전문 편집자이자 WordPress 콘텐츠 작성자다.
[priority]
1) 사실 검증과 명확성 우선
2) 지정된 출력 스키마 엄수
3) 불필요한 반복·수식어 최소화
[constraints]
- 한국어 존댓말, 과장 금지
- 통계·수치는 출처 없는 생성 금지
- 체계적 소제목(H2/H3) 구조 활용
[style]
- 간결한 문장, 예시는 한국 서비스·툴 기준
이 시스템 프롬프트 위에 작업별 사용자 지시를 얹으면 안정적 일관성이 생깁니다.
컨텍스트 설계: 자료·규칙·예시 순
- 자료: 원문, 표, 정책, 용어집을 핵심만 발췌. 길 경우 요약본을 먼저 제공하고 전문은 참조 앵커로 남깁니다.
- 규칙: 금지·필수·우선순위를 번호로 명시. 모호한 형용사 대신 수용 기준을 정량·정성 혼합으로 기술합니다.
- 예시: 잘된/잘못된 한 쌍을 제공하면 경계를 명확히 학습합니다.
출력 형식 고정: 포맷 드리프트 방지
운영에서 가장 흔한 문제는 포맷 드리프트입니다. JSON, HTML, 마크다운 등 스키마를 먼저 고정하고, 위배 시 재시도 규칙을 넣으세요.
필수 출력 스키마(엄수):
{
"title": "문자열",
"summary": "120~160자",
"headings": ["H2...", "H2..."],
"html": "<h2>...</h2>"
}
위 스키마에서 키 누락·추가 금지. 위배 시 스키마만 재출력.
토큰 최적화와 비용 관리
- 규칙 압축: 중복 지시를 합치고, “항상·절대” 같은 표현을 줄여 실제 제약만 남겨둡니다.
- 컨텍스트 앵커: 길이가 큰 참고는 [REF:ID]로 앵커만 남기고 필요 시 요약을 요청합니다.
- 요약 지시: “근거는 3문장으로”처럼 간단 근거 요약만 요구해 과도한 중간 추론 출력을 피합니다.
- 반복 금지: “질문·지시문 재인용 금지”를 넣어 쓸데없는 에코를 막습니다.
실패 프롬프트 리팩토링 예시 1: 블로그 글 작성
Before
주제: 데이터 백업 가이드
요약하고 글 써줘. 길이는 적당히.
After
[role] 한국어 IT 실무 블로거
[task] 중소기업 관리자 대상 데이터 백업 입문 글 작성
[audience] IT 비전공 실무자
[constraints]
- H2/H3 구조, 과장 금지, 예시는 한국 SaaS 중심
- 2,500~3,000자, 체크리스트 포함, 중복 문장 금지
[output]
- HTML 본문만, 마지막에 140자 메타디스크립션 1개
[content]
- 왜 지금 백업이 필요한가(위험 시나리오 2가지)
- 3-2-1 원칙 개요와 국내 현실 적용
- 자동화 스케줄 설정 예시(주/월 단위)
실패 프롬프트 리팩토링 예시 2: 정보 추출
Before
아래 문단에서 회사명과 날짜를 뽑아줘.
After
[task] 문단에서 지정 스키마로 정보 추출
[schema] {"company": "string", "date_iso": "YYYY-MM-DD"}
[rules]
1) 없으면 null
2) 한국어 날짜는 ISO로 변환(연-월-일)
3) 스키마 이외 키 금지
[output] JSON만 출력
실패 프롬프트 리팩토링 예시 3: 코드 생성
Before
파이썬으로 CSV를 JSON으로 바꾸는 코드 짜줘.
After
[role] 파이썬 표준 라이브러리 우선 엔지니어
[task] CSV -> JSON 변환 스크립트(UTF-8, 큰 파일 스트리밍 처리)
[constraints]
- 외부 패키지 금지, 에러 처리 포함, 함수형 분리
- 주석은 한국어, 사용 예시 제공
[output]
- 코드 블록 1개, 마지막에 사용법 3줄 요약
자동 평가와 운영 팁
- 샘플 세트: 실제 업무 입력 20~50개를 축적하고, 기대 출력의 핵심 특징(키워드, 길이, 필드 유효성)을 정의합니다.
- A/B 비교: 버전 간 제목 길이 준수율, 스키마 위반 횟수, 금지어 발생률 등 간단 지표로 비교합니다.
- 실패 로그: 위반 사례를 카테고리화(포맷·사실성·톤)하고 각 카테고리별로 지시문을 보강합니다.
- 롤백 전략: 신버전이 악화되면 즉시 이전 버전으로 복귀할 수 있게 버전 태그와 변경 사유를 남깁니다.
협업·버전관리 베스트 프랙티스
- 파일 구조: 01_system.md, 02_task.md, 03_examples.md로 분리해 모듈화합니다.
- 명명 규칙: {도메인}-{목적}-{날짜}-{버전}.md 형태로 재현성을 높입니다.
- 변경 이유 기록: “스키마 위반 감소 목적, 금지사항 보강”처럼 의도를 남겨야 향후 회귀를 막을 수 있습니다.
자주 묻는 질문
Q. 예시를 몇 개 넣어야 하나요?
한 쌍(좋음/나쁨)만으로도 경계를 크게 선명히 할 수 있습니다. 다만 포맷 준수 안정화가 필요하면 2~3쌍까지 권장합니다.
Q. 길이 제한은 어떻게 설정하나요?
자·문단·섹션 기준을 혼용하세요. 예: “요약 140자 내”, “본문 2,500~3,000자”, “H3는 5개 이내”.
Q. 과도한 중간 추론을 어떻게 줄이나요?
최종 답변만 요구하고, 근거는 3문장 이내로 제한하세요. 불필요한 사고 과정 출력 지시는 피합니다.
정리: 작은 수정이 큰 안정성을 만든다
Claude 3.5 Sonnet 프롬프트의 품질은 역할·규칙·컨텍스트·포맷을 얼마나 명료하게 고정하는가에 달려 있습니다. 모호함을 줄이고, 스키마를 엄격히 지키게 하며, 짧은 루프로 평가·개선을 반복하세요. 리팩토링은 거창함이 아니라 작은 수정의 누적입니다. 오늘 다루지 못한 케이스가 보이면 실패 로그부터 쌓고, 그 실패를 다음 버전의 규칙으로 승화시키면 됩니다.
