왜 고급 설계가 필요한가
같은 질문을 해도 결과가 들쭉날쭉하다면, 문제는 모델이 아니라 프롬프트 설계일 가능성이 큽니다. Claude 3.5 Sonnet 프롬프트는 단순 지시보다 역할·목표·제약·출력 포맷을 함께 명시할 때 안정적으로 동작합니다. 이 글에서는 컨텍스트 관리, 툴 사용, 출력 포맷 고정까지 한 번에 정리해 실무에서 재사용 가능한 기준을 제시합니다.
기본 프레임: R-G-C-O-R-F
프롬프트 엔지니어링의 출발점은 구조입니다. 다음 프레임을 Claude 3.5 Sonnet 프롬프트의 기본 골격으로 사용해 보세요.
역할(Role)·목표(Goal)·제약(Constraints)·산출물(Output)·평가기준(Rubric)·폴백(Fallback)
[Role] 당신은 B2B 소프트웨어 기술 문서를 작성하는 시니어 에디터입니다.
[Goal] 제품 기능 변경 내역을 고객 공지용 릴리즈 노트로 정리합니다.
[Constraints]
- 길이: 600~800자, 한국어 존댓말
- 금지: 내부 코드명, 미공개 일정, 과장된 표현
- 근거: 제공한 변경 내역 표에 한정
[Output]
- 섹션: 개요, 주요 변경, 영향/조치, 문의처
- 형식: HTML h3/h4 소제목 + 단락문
[Rubric]
- 정확성(근거 일치), 간결성(불필요 수식 X), 일관성(용어 가이드 준수)
[Fallback]
- 근거 불충분 시 '추가 정보 필요'를 먼저 출력하고 질문 3가지를 제시핵심은 모델의 판단 범위를 좁혀 의도·근거·출력을 동시에 고정하는 것입니다. Claude 3.5 Sonnet은 이런 명시적 제약에 잘 반응합니다.
컨텍스트 관리 전략
좋은 답을 위한 첫 조건은 좋은 입력입니다. 컨텍스트 관리의 기본 원칙을 정리합니다.
1) 시스템 프롬프트로 상위 규칙 고정
- 변하지 않는 팀 규칙(톤, 금지어, 포맷 우선순위)은 시스템 프롬프트에서 고정합니다.
- 사용자 메시지에는 작업별 지시만 남겨 충돌을 줄입니다.
2) 근거 우선, 요약은 근거 뒤에
- 원문 자료 → 작업 지시 → 출력 포맷 순으로 배열합니다.
- 긴 자료는 먼저 근거 인덱스(제목·출처·범위)를 제공하고, 본문은 필요 구간만 발췌합니다.
3) 길이와 범위의 이중 제약
- 길이 제약: “핵심 5문장 내 요약”처럼 양적 한도를 명시합니다.
- 범위 제약: “아래 표의 ‘변경’·’영향’ 열만 사용”처럼 질적 범위를 고정합니다.
4) 출처와 버전 태그
- 자료 블록에
[SRC: 이름 | 버전 | 날짜]를 붙여 혼선을 줄입니다. - 출력에도 사용된 출처 태그를 남기도록 지시합니다.
툴 사용을 고려한 설계
Claude 3.5 Sonnet은 함수 호출/툴 사용 워크플로우에서 특히 강점을 보입니다. 도구를 언제, 무엇으로, 어떻게 쓰게 할지 명확히 선언하세요.
1) 도구 선택 규칙
[Tools]
- searchDocs(query): 내부 문서 검색(요약 X, 인용 O)
- fetchAPI(path): JSON 데이터 조회
- runTest(code): 유닛 테스트 실행(타임아웃 20초)
[Tool Policy]
- 근거가 필요하면 searchDocs를 먼저 사용
- 수치/상태는 반드시 fetchAPI로 검증
- 코드 변경 제안 시 runTest로 실패 케이스 확인이처럼 도구의 목적·입출력·우선순위를 규칙화하면 불필요한 호출을 줄이고 결과 신뢰도를 높일 수 있습니다.
2) 도구 호출 전 확인 질문
네트워크 호출이나 비용이 수반되는 경우, 다음과 같이 질의-응답 단계를 추가하세요.
도구 호출 전 질문: 목표·범위·허용 시간·예산·출력 포맷을 5줄 이내로 재확인3) 구조화된 출력으로 후처리 단순화
다음 JSON 스키마로만 반환하세요.
{
"summary": "string",
"changes": [{"id": "string", "impact": "low|med|high"}],
"actions": ["string"],
"sources": ["SRC:..."]
}출력 포맷을 고정하면 파이프라인 연결이 쉬워집니다. 실패 시에는 폴백으로 "error" 키를 반환하도록 미리 정의하세요.
출력 안정화: 형식과 품질을 동시에
- 포맷 우선: “형식이 내용보다 우선” 같은 문장을 시스템 프롬프트에 명시
- 예시 제공: 정답 예시 1개, 오답 예시 1개를 함께 제공
- 검증 단계: 최종 출력 전 자체 검증 체크(필드 누락, 값 범위) 수행 지시
- 금지 목록: 과장/추측 금지, 불확실 시 추가 질문
[Self-Check]
- 모든 필드가 존재하는가?
- 값이 허용된 형태인가?(impact=low|med|high)
- 출처 배열이 비어있지 않은가?디버깅 루프: 실패를 빠르게 줄이는 법
- 최소 재현: 실패한 입력을 1~2개 사례로 축약
- 경계 분석: 길이·형식·금지어 등 제약을 위반하는 사례를 의도적으로 투입
- 대조 프롬프트: 규칙을 한 줄씩 더하거나 빼며 영향 확인
- 오류 레이블링: 누락/왜곡/형식 깨짐/근거 없음 등으로 분류
- 폴백 강화: 실패 유형별 복구 절차를 시스템 프롬프트에 편입
실전 예시 1: 요약 + 인용 출처 고정
[Role] 기술 보고서 요약가
[Goal] 보안 공지 3건을 8문장 내 브리핑
[Constraints]
- 각 문장 끝에 [SRC:ID] 인용
- 미확인 정보 금지, 추측 금지
[Output]
- h3 제목 + p 단락 2개
[Sources]
- [SRC:CN-1023] ...
- [SRC:CN-1024] ...
- [SRC:CN-1025] ...출력에는 반드시 [SRC:...]가 남도록 강제해 신뢰성과 감사 가능성을 높입니다.
실전 예시 2: 데이터 정리 파이프라인
[Role] 데이터 클리너
[Goal] 고객사 엑셀 열 이름을 표준 스키마로 매핑
[Constraints]
- 금지: 신설 필드 임의 생성
- 중복: 가장 완전한 값을 우선
[Output]
- JSON {"mapping": [{"from":"", "to":"", "confidence":0~1}]}
[Rubric]
- 충실도, 일관성, 재현성불확실하면 confidence를 낮추고 추가 질문을 유도하도록 지시합니다.
실전 예시 3: 코드 리뷰 + 테스트 연동
[Role] 타입스크립트 코드 리뷰어
[Tools] runTest(code)
[Goal] 성능 이슈 2건과 근거 제시
[Constraints]
- 제안은 모두 테스트 결과로 뒷받침
[Output]
- h4 문제 요약, 코드 블록, 테스트 로그 인용툴 사용이 결과의 근거가 되도록 루브릭에 포함시키는 것이 포인트입니다.
팀 운영 팁: 일관성을 만드는 작은 습관
- 스니펫 보관: 반복 작업 템플릿을 팀 저장소로 공유
- 용어 가이드: 프로젝트별 금칙어/권장어 매트릭스 유지
- 변경 로그: 프롬프트 버전과 성능 메모를 함께 기록
마무리: 작게 시작해 안정화하라
Claude 3.5 Sonnet 프롬프트는 구조가 성능을 결정합니다. 역할·목표·제약·출력 포맷을 먼저 고정하고, 컨텍스트 관리와 툴 사용 규칙을 더하세요. 마지막으로 자체 검증과 폴백을 붙이면 예측 가능한 결과가 나옵니다. 작은 템플릿 하나를 팀 표준으로 굳히는 것부터 시작해 보세요.
