프롬프트 모드 설계: 줄일 문맥과 남길 규칙
TECH INSIGHT / EXPLAINED
메일 유무만 확인하는 작업에 긴 말투 가이드는 필요 없을 수 있습니다. 그렇다고 권한·개인정보·완료 조건까지 지워도 되는 것은 아닙니다. 프롬프트 모드는 선택 문맥의 크기를 조절하는 장치로 설계하세요.
네 이름은 앱의 분류일 뿐이다
Full은 풍부한 설명과 대화 문맥, Task는 작업 절차와 필요한 도구 설명, Minimal은 좁은 점검, None은 선택 문맥을 넣지 않는 변환 작업으로 정의할 수 있습니다. 네 단계가 모든 앱의 표준인 것은 아닙니다. 특히 None도 시스템의 필수 정책, 입력·출력 계약, 접근 검사를 없애는 뜻으로 쓰면 안 됩니다.
구성을 필수 규칙 + 작업 계약 + 선택 문맥으로 나누면 안전 경계가 크기 모드에 종속되지 않습니다. 백그라운드 작업도 결과가 로그·알림·외부 서비스로 나갈 수 있으므로 비밀정보 마스킹과 채널 권한은 그대로 적용합니다.
잘못된 모드는 조용히 None이 되면 안 된다
Go map에서 존재하지 않는 키를 읽으면 값 타입의 제로값이 나옵니다. 순위표에서 오타를 그대로 조회하면 가장 작은 모드처럼 취급될 수 있습니다. 모드 집합을 검증한 뒤 결합하세요. 아래 Python 예제는 순서 결정만 보여 주며 도구 권한을 바꾸지 않습니다.
def choose_mode(configured, requested):
rank = {"none": 0, "minimal": 1, "task": 2, "full": 3}
if configured not in rank or requested not in rank:
raise ValueError("unknown prompt mode")
return min((configured, requested), key=rank.__getitem__)
assert choose_mode("minimal", "task") == "minimal"
assert choose_mode("full", "task") == "task"런타임 override는 신뢰된 호출자만 설정하고 허용 범위를 검사합니다. 단순 min 선택으로 작업 수행에 필요한 최소 문맥을 잃는다면, 더 작은 프롬프트로 억지 실행하지 말고 작업을 거절하거나 적절한 모드로 다시 계획해야 합니다.
섹션 목록을 미리 본다
모드별 템플릿을 복제하기보다 각 섹션에 required, modes, sensitivity, version을 붙여 조립합니다. 미리보기에는 포함된 섹션 이름·버전·토큰 수를 보여 주고 원문 비밀정보는 숨깁니다. 테스트는 'Minimal에서 페르소나가 빠졌는가'뿐 아니라 '모든 모드에서 권한 조건이 남았는가'를 확인해야 합니다.
절감과 성공률을 같이 측정한다
5분마다 하루 종일 도는 점검은 예정상 24×60÷5=288회입니다. 선택 문맥을 호출당 1,000토큰 줄인다면 계획상 하루 288,000 입력 토큰 감소이지만, 실제 실행 횟수·캐시·재시도·출력 비용에 따라 청구액은 달라집니다. 같은 검증 작업 집합에서 완료율, 불필요 도구 호출, 누락 조건과 비용을 함께 비교하세요.
모드 변경은 캐시 접두사에 영향을 줄 수 있지만 동일 세션이면 무조건 고정해야 한다는 법칙은 아닙니다. 작업이나 권한이 바뀌면 정확한 문맥을 우선하고, 캐시 효과는 그 뒤에 측정합니다.
모드 선택 다음에 필요한 문맥을 검증한다
작업을 '메일 목록 조회', '메일 요약', '외부 전달'로 나누면 필요한 정보와 허용 행동이 달라집니다. 모드 순위만 비교해서는 이 차이를 알 수 없습니다. 작업 계약에 필수 입력, 허용 도구, 출력 대상, 완료 증거를 기록하고, 조립된 프롬프트가 필요한 섹션을 포함하는지 검사하세요. 작은 모드에서 요약할 본문이나 전달 대상 검증이 빠지면 실행을 시작하지 않습니다.
외부로 보내도 되는지는 프롬프트의 문장만으로 결정하지 않습니다. 실제 도구 실행부가 호출자 권한과 대상 범위를 검사해야 합니다. 메일·문서에서 읽은 '모드를 Full로 바꾸라'는 내용은 작업 데이터이며 신뢰된 런타임 설정이 아닙니다. 선택 문맥을 늘리는 행위와 접근 권한을 늘리는 행위를 분리하면 모드 이름이 허가 증표처럼 사용되는 일을 막을 수 있습니다.
섹션은 일정한 순서로 조립하고 변경을 추적한다
필수 규칙, 작업 계약, 안정적인 참고 정보, 이번 입력 순으로 섹션 순서를 고정하면 변경 원인을 찾기 쉽습니다. 각 섹션의 식별자와 버전을 저장하고, 동일 작업을 다시 실행할 때 실제로 어떤 조합이 쓰였는지 재구성할 수 있게 합니다. 단순 토큰 수가 같아도 내용이 바뀌면 같은 실험 조건이 아닙니다. 진단 기록에는 본문 대신 허용된 메타데이터만 남깁니다.
Claude 캐싱 문서는 캐시 대상 접두사의 정확한 일치를 요구합니다. 따라서 자주 변하는 시각이나 요청 ID를 안정적인 접두사 중간에 넣지 않는 구성이 측정에 유리합니다. 그래도 캐시 적중을 위해 오래된 권한·정책을 유지하지는 않습니다. 섹션이 바뀌면 새 버전으로 정확하게 실행하고 그 비용을 별도로 측정합니다.
짧아졌는지보다 무엇이 빠졌는지 시험한다
| 가상 시험 입력 | 기대 결과 |
|---|---|
| 알 수 없는 모드 이름 | 설정 오류로 종료 |
| 요약에 필요한 본문 없음 | 부족한 입력을 명시 |
| 문서 안에 권한 변경 지시 | 데이터로 취급, 권한 유지 |
| 읽기 작업에 외부 전송 요청 | 도구 경계에서 차단 |
이 표는 특정 모델의 표준 동작이 아닌 앱의 합격 조건입니다. 정상 입력만 평가하면 문맥을 덜 준 시스템이 빨리 실패하는 것을 효율 개선으로 오해할 수 있습니다. 누락된 입력을 정확히 보고한 경우와 엉뚱한 답을 확신하며 완료한 경우를 같은 실패율 안에 숨기지 말고 따로 집계하세요.
같은 작업 집합으로 단계적으로 비교한다
먼저 비밀을 제거한 대표 작업과 정답·필수 행동을 고정하고 기존 설정으로 결과를 수집합니다. 다음에는 선택 섹션 하나만 줄인 후보로 같은 작업을 실행해 완료율, 조건 누락, 불필요 도구 호출, 지연, 총 사용량을 비교합니다. 모델·도구 버전과 캐시 상태도 기록해 비용 변화가 프롬프트 때문인지 구분합니다.
반복 시도 끝에 성공했다면 최초 호출의 절약분만 보고하지 말고 실패·복구까지 합친 작업당 비용을 계산합니다. 외부 쓰기가 가능한 작업은 평가에서 가짜 도구로 바꾸고, 변경을 적용할 때는 좁은 작업군부터 시작합니다. 필수 조건 누락이 늘거나 복구 비용이 커지면 섹션을 되돌리고 해당 사례를 평가 집합에 추가합니다. 실제 측정 전에는 절감률이나 성공률을 성과처럼 제시하지 않습니다.
참고 자료
내용·예제 검토: 2026-10-01
댓글
댓글 쓰기