제약을 적었는데 왜 프롬프트가 말을 안 들을까?
제약을 문장으로 적는 것과 그 제약이 실제로 지켜지는 것은 다른 문제다. 2025~2026년 실측 자료들은 공통적으로, 제약을 "하지 마"류 한 줄로 뭉쳐 적는 것보다 잘게 쪼개고 형식·평가기준까지 같이 적을 때 준수율이 올라간다고 보고한다[2][3][10]. 이 글은 그 차이가 어디서 나는지, 그리고 그걸 얻으려면 어떤 비용을 치러야 하는지를 실제 실패 사례 기준으로 정리한다.
- 제약을 한 줄로 뭉쳐 적으면 프롬프트 전체가 통과하는 비율(Prompt-level Accuracy)이 개별 지시 통과율보다 먼저 무너진다[2].
- 제약을 출력 규칙·경계 조건·평가 항목으로 층화하면 측정 가능한 형태가 된다[8][11].
- 멀티턴·다국어 환경에서는 명시된 제약도 대화가 길어질수록 누적되며 깨진다[10].
- 대표 입력 10~50개로 회귀 테스트하지 않으면 "지켜지는 것처럼 보이는" 상태에 그친다[7].
- 제약이 많아질수록 검증·유지에 드는 손이 같이 늘어난다.
흔한 함정은 이렇다. 처음 제약 하나를 추가했더니 결과가 좋아 보여서, 그다음부터 "이것도 하지 마", "저것도 하지 마"를 계속 덧붙이는 식으로 프롬프트를 키운다. 초반에는 개별 지시 하나하나는 잘 따라오는 것처럼 보이지만, 제약 개수가 늘어날수록 그 모든 제약을 한 응답 안에서 동시에 만족시키는 비율은 따로 떨어진다. IFEval, FollowBench, InFoBench 같은 지시 따르기 벤치마크들이 2025년 여러 논문에서 공통 평가축으로 쓰인 이유도, 개별 지시 준수율과 전체 지시 묶음 준수율을 분리해서 봐야 하기 때문이다[1][2].
제약을 많이 적으면 다 지켜질까?
아니다, 오히려 그 반대 방향의 실험이 더 자주 관찰됐다. ULTRABENCH는 극도로 세분화된 제어 생성 상황에서 하드 제약을 Instruction-level Accuracy(IA)와 Prompt-level Accuracy(PA)로 나누어 본다. IA는 개별 지시 하나를 따랐는지를 보고, PA는 한 프롬프트 안의 모든 지시를 동시에 만족했는지를 본다[2]. 실무에서 흔히 착각하는 지점이 여기다. 제약을 5개 넣었을 때 각 제약이 개별적으로는 90% 가까이 지켜져도, 5개를 동시에 만족한 응답의 비율(PA)은 그보다 훨씬 낮게 나올 수 있다는 것이 ULTRABENCH의 설명 취지다[2]. 즉 "제약을 많이 적을수록 안전해진다"는 직관은 개별 지시 단위에서만 성립하고, 프롬프트 전체 단위에서는 오히려 제약 간 충돌이나 누락이 늘어나는 지점이 된다. 소프트 제약(스타일, 톤 같은 정성적 요구)은 별도로 Constraint Satisfaction Rate(CSR)로 측정되는데, 이는 하드 제약과 소프트 제약을 같은 잣대로 섞어서 보면 안 된다는 뜻이기도 하다[2]. 실사용 관점에서 정리하면, 제약을 여러 개 쌓을 때는 "개별로는 지켜지는데 전체로는 안 지켜지는" 구간이 항상 존재한다고 보고 시작하는 편이 안전하다.
형식과 평가기준까지 같이 적으면 뭐가 달라질까?
제약만 따로 떼어 적는 것보다, 목표·맥락·제약·출력 형식·평가 기준을 블록으로 나눠 적을 때 검증 가능성이 올라간다. 2026년 공개 자료들에서 공통적으로 Task, Constraints, Format, Evaluation을 별도 블록으로 두는 패턴이 반복 제안되는 이유도 여기 있다[8][9][12][13]. NeurIPS 2025에 발표된 연구는 정확한 지시 따르기를 "자동 검증 가능한 출력 제약을 가진 작업"으로 정의하는데, 이 정의가 중요한 이유는 제약이 사람이 눈으로 봐야만 판정 가능한 형태로 남아 있으면 애초에 검증 루프를 돌릴 수 없기 때문이다[6]. 예를 들어 "간결하게 써줘" 같은 제약은 검증이 어렵지만, "3문장 이내로, 각 문장은 100자를 넘지 않게"는 자동으로 셀 수 있다. 2026년 자료들은 정확성, 관련성, 명확성, 구조/형식 준수, 제약 준수, 검증 가능성, 안전성 같은 항목을 프롬프트 품질 판정 기준으로 함께 놓으라고 권한다[9][11]. 즉 제약을 적는 행위와 그 제약을 어떻게 채점할지 적는 행위를 분리하지 않으면, 나중에 "지켜졌는지 아닌지"를 판단할 기준 자체가 없는 상태로 남는다.
멀티턴이나 다국어에서는 왜 더 쉽게 깨질까?
대화가 길어지고 언어가 섞이면 명시된 제약도 암묵적 제약과 뒤섞이며 누적적으로 무너진다. TRUEBench는 12개 언어, 누적 제약, 문맥 전환이 있는 멀티턴 대화 환경을 포함해 "명시된 제약과 암묵적 제약"을 함께 평가하는 벤치마크다[10]. 단일 턴에서는 잘 지켜지던 형식 제약이, 대화가 3~4턴 넘어가면서 앞서 준 제약을 모델이 놓치거나, 새 턴에서 준 제약과 이전 제약이 충돌하는 상황이 반복적으로 관찰된다는 것이 이 벤치마크의 문제의식이다[10]. 다국어 환경에서는 여기에 한 겹이 더 붙는다. 같은 제약 문구라도 언어가 바뀌면 모델이 그 제약을 하드 제약으로 볼지 소프트 권고로 볼지 다르게 해석하는 경우가 있어서, 단일 언어 테스트에서 통과한 제약 준수율을 다국어 서비스에 그대로 옮기는 것은 근거가 약하다. 실무적으로는 멀티턴 시나리오에서는 매 턴마다 핵심 제약을 짧게 재확인하는 구조가, 처음 한 번만 길게 적고 마는 구조보다 실측 기준으로 더 안정적으로 보고된다[10].
제약은 "하지 말 것"만 나열하면 충분할까?
아니다, 이 부분이 가장 흔한 오해다. "하지 말 것" 나열만으로는 모델이 애매한 상황에서 무엇을 해야 하는지 알 수 없다. 2026년 자료들은 제약을 세 층으로 나눠 적으라고 제안한다: 첫째 출력 규칙(형식·길이·금지 표현), 둘째 판단 경계 조건(예를 들어 데이터가 없을 때 unknown으로 답할 것 같은 조건), 셋째 평가 항목(정확성·형식 준수 여부를 어떻게 채점할지)[8][11]. 이 중 두 번째 층이 빠지면, 모델은 금지된 것만 알고 대신 무엇을 해야 하는지는 모르는 상태가 된다. 예를 들어 "추측하지 마"라는 제약만 있으면, 정보가 부족할 때 모델이 침묵하거나 관련 없는 답을 지어내는 두 방향으로 갈릴 수 있다. 반면 "정보가 부족하면 unknown이라고 답할 것"까지 명시하면 경계 조건이 생겨서 검증도 가능해진다. 즉 제약 명시의 목적은 "하지 마"를 모으는 것이 아니라, 애매한 경계에서 모델이 취할 행동을 하나로 좁히는 것이다.
제약을 구조화하면 실제로 뭘 더 해야 할까?
제약을 층화하고 형식·평가를 같이 적는 순간부터, 그걸 유지하는 작업이 새로 생긴다. 2026년 공개 가이드들은 실제 입력 10~50개 정도를 모아 회귀 테스트를 돌리고, 스키마가 유효한지, 금지 표현이 실제로 포함되지 않았는지, 이전 버전 대비 성능이 어떻게 바뀌었는지를 확인하라고 권한다[7]. 이 말은 곧 제약을 프롬프트에 적는 순간 그 제약을 확인할 테스트 세트도 같이 만들어야 한다는 뜻이다. 프롬프트가 길어질수록 제약 누락이나 제약 간 충돌 가능성이 커지기 때문에, Role–Task–Format이나 Goal–Context–Source–Expectations 같은 틀을 쓰고 비협상 제약(반드시 지켜야 하는 것)을 프롬프트 앞쪽에 배치하라는 권고도 2026년 자료에서 반복된다[7][12][13]. 실무에서 이 비용은 작지 않다. 제약 하나를 추가할 때마다 회귀 테스트 케이스도 하나 늘려야 하고, 제약끼리 충돌하는 케이스가 없는지 수동으로 한 번은 훑어야 한다. 제약을 안 쪼개고 뭉쳐 적으면 이 과정 자체를 생략할 수 있지만, 그 대가로 "왜 이번엔 제약이 안 지켜졌는지" 원인을 특정하기 어려워진다.
핵심 정리
- 제약을 개별로 지키는 것과 여러 제약을 동시에 지키는 것은 다른 지표이며, ULTRABENCH는 이를 IA/PA로 분리해 측정한다[2].
- 제약은 출력 규칙·판단 경계 조건·평가 항목 세 층으로 나눠 적을 때 검증 가능해진다[8][11].
- 멀티턴·다국어 환경에서는 명시 제약도 누적적으로 무너지므로, 매 턴 재확인 구조가 실측상 더 안정적이다[10].
- 정확한 지시 따르기는 자동 검증 가능한 제약을 전제로 정의된다는 점이 2025년 연구에서 제시됐다[6].
- 제약을 구조화하는 만큼 대표 입력 10~50개 기준의 회귀 테스트 비용이 따라온다[7].