시스템 프롬프트 분리, 실제로 뭘 검증하는 장치인가?
결론부터 쓴다. 시스템 프롬프트를 목표·제약·형식·평가 네 블록으로 나누는 것은 지시문을 보기 좋게 정리하는 글쓰기 기법이 아니라, 각 블록을 독립적으로 통과/실패 판정할 수 있게 만드는 검증 설계다. 분리의 목적은 "잘 썼다"는 인상이 아니라 어느 블록에서 실패가 나는지 추적하는 것이다. 2026년 기준으로도 이 구조는 여전히 모델·과제별 재측정이 필요한 실험 단위로 취급해야 한다.
- 분리는 보기 좋은 포맷이 아니라 검증 단위를 만드는 작업이다.
- 복합 지시를 세부 요구사항으로 쪼개 통과율을 재는 DRFR 같은 지표가 이를 뒷받침한다.
- 10개 안팎의 하드 제약을 동시에 걸어도 완전 자동 준수는 보고되지 않았다.
- 분리는 보안 영역에서도 "시스템 지시 vs 외부 데이터" 구분의 근거로 쓰인다.
- 비용은 성공률이 아니라 재시도·수동 수정·토큰 소요로 따로 기록해야 비교가 된다.
흔히 빠지는 함정은 "시스템 프롬프트를 길고 자세하게 쓰면 자동으로 지켜질 것"이라는 가정이다. 18개 LLM을 대상으로 2,100~2,400단어 분량, 정확히 3개의 H2 장면, 금칙어, 장면별 주인공 이름 등장 횟수, 메타·계획 문구 금지 등 10개 제약을 동시에 부여한 비교 글에서는 어떤 모델도 별도 수정 없이 모든 제약을 완벽히 충족하지 못했다18-model hard constraint 벤치마크. 분리는 통과율을 올리는 마법이 아니라, 실패가 어디서 나는지 보이게 만드는 장치에 가깝다.
목표·제약·형식·평가로 나누면 뭐가 달라지나?
달라지는 것은 "결과가 좋아 보이는가"가 아니라 "어느 요구사항이 깨졌는지 숫자로 남는가"다. 2025년 공개된 평가 프레임워크는 프롬프트 요구사항을 형식 준수, 내용 제약, 논리적 순서, 다단계 실행으로 쪼개 20개 진단 프롬프트로 측정했고, 2025년 10월 14일 기준 OpenRouter에서 작동이 확인된 256개 모델을 대상으로 돌렸다DRFR 평가 연구. 여기서 소개된 DRFR(Decomposed Requirements Following Ratio)은 복합 지시를 세부 요구사항으로 분해해 각각 충족했는지 계산하는 방식으로, "잘 썼는가"가 아니라 목표·제약·출력 형식별 통과율을 따로 기록한다.
실무 리뷰에서 쓰기 좋은 분리 구조는 기능적 목표, 제약·견고성, 해결 구조·설계 지침, 입출력 형식 네 범주로 나누는 것이다프롬프트 세부화 프레임워크. 이를 리뷰용 블록으로 고정하면 "목표: 무엇을 완성해야 하는가", "제약: 금지·분량·순서·예외 조건은 무엇인가", "형식: 제목·JSON·표·필수 필드는 무엇인가", "평가: 각 조건을 어떻게 통과/실패로 판정할 것인가"로 비교가 쉬워진다. 다만 이 구조는 블록을 나눈다고 자동으로 지켜지는 게 아니라, 실패를 블록 단위로 집계할 수 있게 해준다는 점이 핵심이다.
제약을 많이 걸수록 결과가 좋아지나?
항상 그렇지는 않다는 게 실측 결과다. PartialOrderEval은 하나의 문제에 최소 설명부터 단계별·세부 명세까지 여러 수준의 프롬프트를 만들고, 각 수준에서 pass@1을 측정해 "프롬프트가 자세할수록 항상 좋은가"를 모델·과제별로 실측하는 설계를 썼다PartialOrderEval. 즉 제약을 더 세밀하게 쓴다고 특정 모델·과제에서 성능이 비례해 오른다는 보장은 없고, 과제 종류에 따라 결과가 갈린다.
한편 2025년 의학 연구용 통계 추론 실험은 GPT-4.1과 Claude 3.7 Sonnet에 대해 무지시, 명시적 지시, 추론 보조, 하이브리드 프롬프트를 비교했고, 평가는 가정 확인, 검정 선택, 결과 완결성, 해석 품질 4개 기준으로 구성됐다통계 추론 실험. 이 실험에서는 추론 보조와 형식 제약을 결합한 하이브리드 방식이 가장 정확하고 해석 가능한 결과를 냈다고 보고됐다. 다만 인공 데이터셋, 특정 모델 버전, LLM-as-a-judge와 사람 검토를 함께 쓴 실험이므로 이 결과를 일반 업무 성능으로 그대로 확장하면 안 된다. "제약을 많이 넣을수록 좋다"가 아니라 "제약과 추론 보조를 어떤 비율로 섞느냐가 과제마다 다르다"가 더 정확한 요약이다.
시스템 프롬프트 분리가 보안에서도 쓰이나?
쓰인다. 2026년 공개된 LLMail-Inject 데이터셋은 이메일 기반 간접 프롬프트 인젝션을 평가하기 위해 171,999개 프롬프트 쌍을 구성했으며, 주입-정상 쌍과 정상-정상 쌍을 포함한다LLMail-Inject 데이터셋. 이는 시스템 지시와 외부 문서의 데이터를 분리해야 하는 이유를 실측하는 사례로, 시스템 프롬프트 분리가 단순히 출력 품질 문제가 아니라 "어디까지가 지시이고 어디부터가 외부 입력인가"를 가르는 보안 경계이기도 하다는 점을 보여준다.
이 데이터셋을 활용한 탐지 결과는 범주별 탐지율이 모두 86%를 넘었고, 인코딩 조작·프롬프트 혼동·시스템 유출 범주는 대체로 90% 이상, 탈옥과 작업 재정의는 90~92% 수준으로 보고됐다. 탐지기가 높은 성능을 보여도 오탐·미탐 조건과 공격 유형별 편차는 따로 기록해야 하는데, 이는 "시스템 프롬프트를 분리했으니 안전하다"가 아니라 "분리 후에도 공격 유형별 탐지율 편차가 남는다"는 뜻이다. 보안 목적의 분리도 성능 지표와 마찬가지로 유형별 통과율을 따로 기록해야 신뢰할 수 있다.
분리하면 완벽하게 통제된다는 말인가?
아니다. 이 오해가 가장 흔하고, 바로잡을 필요가 있다. 앞서 본 18개 LLM 비교에서 10개 제약을 동시에 부여했을 때 어떤 모델도 별도 수정 없이 모든 조건을 완벽히 충족하지 못했고, 인터페이스와 프롬프트 전략에 따라 결과와 편집량이 달라졌다18-model 벤치마크. 시스템 프롬프트 분리는 요구사항을 추적 가능하게 만드는 작업이지, 모델 출력을 완전히 통제하는 장치가 아니다.
따라서 실사용 리뷰에서는 "한 번에 성공"이라는 표현 대신 재시도 횟수, 수동 수정 시간, 제약별 실패율을 함께 기록하는 편이 타당하다. 분리된 블록 수가 많다고 해서 실패율이 0에 가까워진다는 근거는 검색된 자료 어디에도 없다. 오히려 분리는 "몇 번째 시도에서, 어느 제약이, 얼마나 자주 깨지는가"를 숫자로 남기기 위한 전제 조건에 가깝다.
실제로 뭘 기록해야 비용을 비교할 수 있나?
비교 가능한 기록은 가격을 임의로 환산한 숫자가 아니라 재현 가능한 측정값이다. 공개 사례들만으로 특정 API의 최신 단가를 확정하기는 어려우므로, 리뷰에서는 입력·출력 토큰 수, 실행 횟수, 재시도 횟수, 총 소요 시간, 수동 편집 시간을 먼저 측정한 뒤 당시 공식 가격표와 함께 기록하는 쪽이 안전하다. 실험 기록에는 모델명뿐 아니라 API 모델 식별자, 실행일, temperature·seed, 입력 토큰 수, 출력 토큰 제한, 재시도 정책, 평가자 모델을 함께 적어야 한다는 점도 같은 맥락이다통계 추론 실험 기록 방식.
실사용 재현 템플릿은 다음 순서로 고정하면 비교가 쉬워진다: 제품·모델(정확한 식별자와 실행일) → 목표(한 문장으로 판정 가능한 결과) → 제약(번호를 매긴 필수·금지 조건) → 형식(제목 수, 필드명, 분량, JSON 스키마 등) → 평가(조건별 0/1 판정표) → 반복(동일 조건 최소 여러 회 실행) → 기록(성공률, 제약별 실패율, 재시도 수, 토큰·시간·비용) → 버전 주의(모델·API·프롬프트·평가 코드 변경 이력). 이 여덟 항목 중 어느 하나라도 생략하면 "분리했더니 좋아졌다"는 결론이 재현 불가능한 인상 비평으로 남는다.
핵심 정리
- 시스템 프롬프트 분리는 목표·제약·형식·평가를 독립 검증 단위로 만드는 운영 방식이며, 보기 좋은 포맷이 아니다.
- DRFR처럼 세부 요구사항별 통과율을 재는 지표가 "잘 썼는가"보다 유용한 판단 근거다.
- 10개 안팎의 하드 제약을 동시에 걸어도 완전 자동 준수는 보고되지 않았으며, 재시도·수동 수정 시간을 함께 기록해야 한다.
- 제약이 많을수록 결과가 좋아진다는 보장은 없고, 과제·모델별로 재측정이 필요하다.
- 분리는 보안에서도 쓰이지만 탐지율은 공격 유형별로 86~92% 수준의 편차가 남는다.