구분자로 필드 나누기, 실제로 뭘 바꾸나?

구분자 자체가 모델을 똑똑하게 만들진 않는다. 목표·제약·입력·형식·평가를 서로 섞이지 않게 분리해 누락과 검증 실패를 줄이는 인터페이스에 가깝다. 2026년 기준 공개된 한 연구는 구조화된 평가 프롬프트에서 모델 평균 정확도가 6% 증가했다고 보고했지만, 이는 해당 실험 조건 안에서의 수치다.출처 이 글은 그 구조를 직접 만들어보고 어디까지 신뢰할 수 있는지 확인한다.

핵심 정리

  • 목표·제약·형식·평가는 ###, """, XML 태그 같은 구분자로 각각 감싸는 편이 역할 혼동을 줄인다.
  • OpenAI는 ###/"""를, Anthropic은 <task>, <constraints>, <output_requirements> 같은 태그를 구분자로 제시한다.
  • 평가 필드는 "좋은 답변" 대신 "필수 항목 누락 없음", "JSON 파싱 성공"처럼 자동 확인 가능한 문장으로 써야 검증이 성립한다.
  • 제약이 많아지면 의미별 그룹화나 단계적 전달(Stepwise Planning, Multi-turn)이 한 문단 나열보다 비교 대상이 된다.
  • 특정 수치는 모델·버전·평가 데이터에 따라 달라지므로 실험 조건을 함께 기록해야 재현이 가능하다.

이번 실험에서 검증하려 한 것은 단순하다. "같은 입력을 구분자 없이 한 문장으로 줬을 때"와 "목표·제약·형식·평가를 각각 필드로 나눴을 때", 어느 쪽이 요구사항 누락을 덜 일으키는지를 직접 비교해보는 것. 성능 점수를 매기기보다는 구조가 실제로 어떤 실패를 줄이는지, 어디서는 그대로인지를 보고 싶었다.

목표와 제약을 같은 문장에 섞으면 어떤 문제가 생기나?

섞으면 모델이 "할 일"과 "하지 말아야 할 일"을 같은 비중으로 처리하다가 둘 중 하나를 놓치는 경우가 관찰됐다. Google의 2025년 프롬프트 자료는 지시사항(원하는 작업·형식·내용)과 제약(피해야 할 한계)을 서로 다른 요소로 구분한다.출처 직접 비교해본 방식은 이렇다. 한 버전은 "고객 문의를 3문장으로 요약하되 원문에 없는 사실은 추가하지 말고 한국어로 쓰고 숫자는 유지해줘"처럼 한 문장에 전부 넣었고, 다른 버전은 아래처럼 필드를 나눴다.

<goal>고객 문의를 3문장으로 요약한다</goal>
<constraints>
- 원문에 없는 사실을 추가하지 않는다
- 한국어로 작성한다
- 핵심 수치는 유지한다
</constraints>

나열형 버전에서는 숫자 유지 조건이 가끔 빠지는 경우를 반복 실행 중 체감했다. 이 관찰은 통계적으로 집계하지 않았으므로 일반화하지는 않지만, 제약을 별도 필드로 둘 때 "무엇을 검증할지"가 더 명확해지는 건 분명했다.

출력 형식을 필드로 고정하면 무엇이 달라지나?

형식을 별도 필드로 고정하면 "어떤 모양으로 답할지"에 대한 오해가 줄어든다는 설명이 통계 추론 프롬프트 연구에도 나온다. 예를 들어 표를 요구할 때 "표로 정리해줘" 대신 표 열: 검정통계량, 자유도, p값처럼 열 이름까지 지정하는 방식이다.출처 같은 원리를 고객 응대 요약에 적용하면 format 필드에 "핵심 요약 1개와 근거 bullet 3개"처럼 구조를 명시하게 된다. 형식 필드가 없을 때는 모델이 문단형으로 쓸지 목록형으로 쓸지 매번 다르게 선택했고, 형식을 고정한 뒤에는 출력 구조가 일관됐다. 다만 이 비교도 소규모 반복 실행 안에서의 체감이라, 모델 버전이 바뀌면 재확인이 필요하다.

평가 기준을 프롬프트 안에 넣으면 검증이 쉬워지나?

평가 기준을 실행 가능한 문장으로 넣으면 "통과/실패"를 기계적으로 가를 수 있다는 점에서 검증이 쉬워진다. 2025년 ULTRABENCH는 길이·구조, 필수 키워드·수치, 출력 형식·인코딩 같은 자연어 제약을 각각 검증기로 검사하는 방식을 썼고, ACL 2025의 IOPO 논문은 각 제약을 0~10점으로 채점한 뒤 합산하는 평가 지시문을 사용했다.출처 이를 본떠 정확성 0~10, 제약 준수 0~10, 형식 준수 0~10처럼 항목을 분리하면 사람이 재채점할 때도 기준이 같아진다. 다만 구조 유효성 같은 항목은 규칙 기반으로 자동 검증할 수 있지만, 의미적 완성도는 임베딩 비교나 LLM-as-a-judge가 필요하고 이 경우 별도의 채점 루브릭과 샘플 검수가 따로 요구된다.출처

제약이 많아지면 단계별로 나눠야 하나?

제약이 늘어날수록 한 문단에 나열하기보다 의미별로 묶거나, 아예 단계를 나누는 쪽이 검증하기 쉬웠다. ULTRABENCH는 제약을 내용·문체·구조·길이로 묶는 Grouped Constraints, 먼저 계획을 세운 뒤 답하는 Stepwise Planning, 제약을 여러 차례에 나눠 전달하는 Multi-turn 방식을 서로 비교 대상으로 다뤘다.출처 직접 테스트에서는 제약이 3개 이하일 때는 한 필드 안에 bullet로 나열해도 큰 문제가 없었지만, 5개를 넘어가자 문체와 형식 조건이 서로 뒤섞이는 경우가 생겼다. 이 지점에서는 그룹화가 도움이 됐고, 아주 복잡한 멀티스텝 작업에서는 단계를 나눠 전달하는 편이 더 안정적이었다.

이 구조는 어떤 공개 자료에 근거하나?

이 글의 구조는 특정 서비스의 내부 실험이 아니라 공개된 문서·논문을 조합한 것이다. OpenAI와 Anthropic의 프롬프트 권고, Google의 2025년 엔지니어링 자료가 지시·제약 구분의 근거이고, ULTRABENCH와 IOPO 논문이 그룹화·단계화·채점 방식의 실험적 근거다.출처 구조화된 평가 프롬프트의 평균 정확도 6% 증가 수치 역시 하나의 논문이 보고한 조건부 결과이며, 전체 모델 목록이나 통계적 유의성까지는 검색 결과만으로 확인되지 않는다.출처 따라서 이 수치는 "해당 연구의 실험 조건에서 평균 6%"로 한정해 읽는 편이 안전하다.

구분자 구조로 안 되는 것은 뭘까?

구분자는 역할 분리를 돕지만, 모델이 제약 자체를 잘못 이해했을 때는 필드를 나눠도 소용이 없다. 일부 실무 글은 구조화 프롬프트가 수작업 수정량을 약 50% 줄이고 안전성 준수를 두 배 이상 높였다고 주장하지만, 검색 결과상 원 논문이나 실험표가 확인되지 않아 이 수치는 이 글에서 인용하지 않는다.출처 또한 평가 필드를 LLM-as-a-judge로 채점할 경우, 채점 모델 자체의 편향을 사람이 다시 검수해야 하므로 구조화만으로 평가 신뢰도가 자동으로 올라가지는 않는다. 같은 모델·같은 temperature·같은 출력 토큰 제한을 유지한 반복 실행 비교 없이는, 구분자 구조가 특정 작업에서 얼마나 효과가 있는지 수치로 단정하기 어렵다.

이번 실험에서 남은 질문은 무엇인가?

이번 관찰은 소규모 반복 실행에 기반한 체감 비교였고, 통계적으로 집계하지 않았다는 한계가 있다. 다음에 확인하고 싶은 것은 세 가지다. 같은 템플릿을 모델 버전을 바꿔가며 돌렸을 때 결과가 얼마나 흔들리는지, 제약 개수가 몇 개를 넘어야 그룹화가 실제로 필요해지는지, 그리고 평가 필드를 규칙 기반 검증과 LLM 채점으로 각각 돌렸을 때 판정이 얼마나 갈리는지다. 구분자는 분명 "무엇을 검증할지"를 명확하게 만드는 도구였지만, 그 검증 결과까지 자동으로 보장해주지는 않았다.