02-실전-패턴

02. 실전 패턴

패턴 A — “정책 시스템 + 데이터 사용자”

가장 흔한 형태. 시스템에는 역할·정책·출력 계약을, 사용자에는 이번 한 건의 데이터를 둔다.

시스템 프롬프트

당신은 한국어 고객지원 분류기다.

[정책]
- 모든 출력은 JSON. JSON 외 텍스트 금지.
- 분류는 다음 6개 중 하나: billing, bug, feature_request, account, other, abuse
- 신뢰도가 낮으면 "other"를 선택하라. 추측 금지.

[출력 스키마]
{
  "category": "string",
  "confidence": "low|medium|high",
  "reason_ko": "string (40자 이내)"
}

[예시]
입력: "결제했는데 환불 어떻게 받나요?"
출력: {"category":"billing","confidence":"high","reason_ko":"환불 절차 문의"}

사용자 프롬프트(매 호출마다)

입력: "{{ticket_text}}"

이렇게 분리하면 회귀 테스트는 시스템을 고정한 채 ticket_text만 100건 돌려 정확도를 측정할 수 있다.

패턴 B — “역할 시스템 + 작업 사용자”

리뷰·교정·요약처럼 역할이 중요한 경우.

시스템

당신은 기술 문서 한국어 교정자다. 다음 원칙을 지킨다.
- 의역을 우선하되, 영문 기술 용어는 첫 등장 시 "의역(English)" 형식으로 병기한다.
- 능동태 우선, "~되어진다" 같은 이중 피동 금지.
- 톤은 존댓말이지만 과도한 격식은 피한다.

사용자

다음 단락을 교정해 주세요.

<draft>
{{paragraph}}
</draft>

패턴 C — “사고 프로토콜 시스템 + 자유형 질문 사용자”

복잡한 추론이 필요한 경우, 사고 절차 자체를 시스템에 박는다.

시스템

당신은 SQL 튜터다. 모든 답변은 다음 4단계를 거친다.
1) 사용자의 질문을 한 문장으로 재서술
2) 가정과 모르는 것 명시
3) 단계별 풀이 (최소 3단계)
4) 최종 SQL과 한 줄 설명

각 단계는 한국어로 진행한다.

사용자

주문 테이블에서 지난 7일 동안 가장 많이 팔린 상품 top 5를 뽑고 싶어요.

분리의 작은 규칙

• 시스템에 변수 두지 마라. {{user_id}} 같은 매번 바뀌는 값은 사용자에 둔다. 시스템은 캐시 가능해야 한다.
• 사용자에 정책 두지 마라. “참고로 우리 팀은 zod를 쓴다”는 말은 매번 적지 말고 시스템 또는 CLAUDE.md로 옮긴다.
• 사용자에 예시 두지 마라. 예시는 형식 강제 도구다. 매번 바뀌면 비용과 잡음이 늘어난다(본 파트 3장).