프롬프트 비만이 정확도를 낮춘다? 실측 수치로 보는 3단계 해법

프롬프트 비만은 어디에서 오는가

문제는 ‘실패할 때마다 규칙을 프롬프트 끝에 붙이는’ 습관에서 시작됩니다. 성능이 안 나오는 예시를 보고 “이런 경우에는 ~하지 마라”, “이런 단어가 나오면 ~로 처리하라” 같은 지침을 계속 추가하는 방식입니다. 반복할수록 프롬프트는 커지지만, 지침이 쌓이는 것과 정확도가 오르는 것은 별개입니다. 오히려 지나친 규칙은 훈련 데이터의 잡음에 맞춰 과적합되어 검증되지 않은 예외를 만들어냅니다.

축구팀에 비유하면 이런 방식은 매 경기 실점할 때마다 전술판에 “23분에는 상대 7번을 막고, 45분 코너킥에서는 헤딩을 조심하라”는 잔소리를 수십 줄 적어두는 것과 같습니다. 선수는 그 많은 메모를 읽지도 못하고, 다음 경기에선 또 다른 예외가 생깁니다.

반면 연구의 핵심 아이디어는 이렇게 나눌 수 있습니다. 실패한 오류 전체를 먼저 모아 공통 패턴을 찾은 뒤(진단), 여러 각도의 수정안을 만들고(다양화), 검증 단계에서 가장 견고한 안을 통계적으로 고르는(안정화) 것입니다. 이 세 단계만 바꿔도 프롬프트는 짧아지면서 더 정확해집니다.

왜 지금까지는 프롬프트가 계속 불어났나

기존 진화형 프롬프트 최적화는 실패 예시 몇 개의 피드백을 받아 프롬프트를 라운드를 거듭하며 조금씩 진화시키는 방법입니다. 이런 방식은 매 라운드마다 오류 3~8개만 무작위로 보고 수정안을 제안합니다. 여기에 수리적인 한계가 있습니다. 새 패턴을 만날 확률은 라운드를 거듭할수록 떨어지기 때문에, 쿠폰 모으기 문제로 계산하면 전체 실패 패턴을 95% 확률로 모두 관찰하려면 약 15번의 라운드가 필요합니다. 그 사이 몇 라운드는 이미 본 증상을 또 수정하느라 불필요한 규칙만 쌓게 됩니다.

이렇게 만들어진 프롬프트는 정제된 후보 대비 최대 3배, 평균 1.87배까지 길어졌습니다. 길어질수록 지연 시간과 토큰 비용도 함께 올라갑니다. 모든 진화형 최적화가 이 함정에 빠지는 것은 아니지만, 오류를 부분적으로만 보고 고치는 구조라면 피하기 어렵습니다.

해법 1. 먼저 오류 전체를 패턴으로 진단한다

첫 단계에서는 현재 프롬프트로 발생한 훈련 오류를 전부 모읍니다. 분석용 LLM이 이를 3~7개의 구조적 패턴으로 묶어 주고, 패턴마다 실패 원인과 대표 예시, 수정 방향을 정리합니다. 한 번의 전수 진단이기 때문에 라운드를 반복해도 빈 패턴이 남지 않습니다.

이 진단 결과물의 힘은 구체성에 있습니다. 예컨대 감성 분류 오류를 분석하다 보면 “스포츠 결과를 사실대로 보도한 문장을 긍정으로 잘못 분류한다”, “순위 표현은 사실 진술이어도 긍정의 평가를 담는다” 같은 뚜렷한 패턴이 드러납니다. 원인을 알고 나면 지침 한 줄이 여러 예외 규칙을 대체합니다. 그게 프롬프트가 짧아지는 정확한 지점입니다.

해법 2. 서로 다른 각도의 수정안을 만든다

진단 결과를 바탕으로 후보 프롬프트를 만들 때는 한 가지 방법만 쓰지 않습니다. 네 가지 전략을 병행합니다. 진단된 오류의 원인을 직접 고치는 진단적 수정, 중복 규칙을 합치고 언어를 간결하게 하는 통합, 지나치게 발동하는 규칙을 빼는 제거, 오류 사례에서 얻은 도메인 지식을 문맥으로 넣는 지식 주입이 그것입니다.

이 전략들이 중요한 이유는 서로 보완적이기 때문입니다. 같은 오류라도 고치는 방향과 덜어내는 방향, 지식을 더하는 방향이 따로 존재합니다. 한 방식만 쓰면 그 방식이 놓치는 오류 유형 때문에 다시 규칙이 쌓이는 일이 반복됩니다. 네 전략으로 만든 후보 중 상위권을 두 차례 교차 결합·정제해 최대 10개까지 후보를 유지하는 것이 전체 프로세스입니다.

해법 3. 검증에서 부트스트랩으로 선택 오류를 막는다

마지막 단계가 가장 삐걱거리기 쉬운 부분입니다. 검증 데이터가 30건 정도로 작으면 어떤 후보가 우연히 1등이 되기 쉽습니다. 여러 후보를 한 번에 비교하면 다중 비교 문제도 생깁니다. 그래서 연구는 검증셋을 20번 다시 추출(부트스트랩)해, 각 추출에서 1등을 가장 많이 차지한 후보를 선택합니다. 동률이면 더 짧은 프롬프트를 택합니다.

진짜 1등 후보가 재표본마다 이길 확률이 절반을 넘는다면, 잘못 고를 확률은 부트스트랩 횟수에 따라 지수적으로 줄어드는 것이 수리적 근거입니다. 이 선택 단계를 생략하고 다양성만 챙기면 오히려 성능이 1.20%p 떨어졌습니다. 후보가 늘면 그만큼 분산도 커지는데, 이를 통제할 검증 절차가 함께 있어야 한다는 뜻입니다.

기존 방식이 이 세 단계 중 하나라도 갖추지 못했다는 점이 재미있습니다. 전략을 1개만 쓰고, 재표본을 1번 하고, 오류를 3개만 보도록 조처하면 이 프레임워크는 곧바로 기존 진화형 방식이 됩니다. 즉 이 프레임워크는 기존 방식을 대체하는 것이 아니라, 그 방식을 감싸면서 세 결함을 하나씩 고친 확장판입니다.

성과: 줄였는데 더 정확해졌다

일곱 개의 공개 벤치마크(감성 분류, 다지선다 지식, 초등 수학, 다중 홉 추론, 자연어 추론, 사실 검증, 개인정보 보호 생성)에서, 이 방법은 기존 최고 성능 대비 평균 정확도 +3.76%p와 프롬프트 길이 47% 단축(1,004자 대 1,878자)을 동시에 달성했습니다. 데이터셋별로 보면 네 곳에서 오차범위 밖의 확실한 우위(문서 검증 HoVer +8.80%p가 최대)를 보였고, 나머지는 양쪽 모두 성능 상한에 닿아 동률(GSM8K 96.80)이거나 오차범위 안의 동급(HotpotQA, PUPA)이었습니다.

가장 극적인 사례는 경량 모델에서 나왔습니다. 초기 정확도가 15%에 불과하던 Qwen3 32B 모델은 GSM8K 수학 과제에서 91.4%까지 치솟았는데, 같은 과제에 기존 최적화를 적용한 결과(35.4%)와 비교하면 무려 56%p 차이입니다. 원인은 프롬프트 문구가 아니라 모델이 출력하는 형식이 기대 규격과 달라 답안이 통째로 무시되고 있었던 것이었습니다. 오류 전체를 패턴으로 진단한 덕분에 이 구조적 결함이 한 라운드 만에 드러났습니다.

이 효과는 다른 모델들에서도 일관되게 나타났습니다. 네 종류의 추가 모델 전부에서 평균 정확도가 기존 최고치를 넘었고, 시작 성능이 가장 낮았던 Qwen3 32B의 평균 격차가 약 9.6%p로 가장 컸습니다. 심지어 처음부터 잘 만든 강한 시작 프롬프트에서 출발한 경우에도 상대보다 평균 4.79%p 높았습니다. 약한 프롬프트를 고치는 데만 쓰이는 기법이 아니라는 뜻입니다.

한계도 함께 보기

한계부터 짚으면 이렇습니다. 여러 데이터셋 중 다수에서 우세했지만 일부는 통계적으로 동급이었고, 모델별로는 특정 과제(사실 검증, 개인정보 보호 생성)에서 오히려 기존 방식이 이기기도 했습니다. 짧아진 프롬프트가 무조건 좋은 것도 아닙니다. 억지로 길이만 줄인(길이 제약만 추가한) 변형은 정확도를 높이지 못했으므로, 압축이 성과의 원인이라기보다 진단이 먼저 살아 있어야 성과가 납니다.

이론적으로도 절대적 보증은 아닙니다. 네 전략의 독립성은 관찰상 완전히 충족되지 않았고(쌍별로 보면 완전히 독립은 아니지만 의존도는 낮은 수준), 오류 진단은 정답 라벨이 있는 과제를 전제합니다. 자유 생성형 과제는 파일럿 단계까지 검증된 수준입니다. 실무에서 쓴다면 이 여유를 감안하는 것이 맞습니다.

지금 당장 적용하는 세 문장

방법론을 다 읽지 않아도 오늘부터 쓸 수 있는 실천 항목은 셋입니다.

1. 실패 사례를 3~5건 보고 고치는 대신, 최근 오류 로그를 모아 공통된 실패 유형을 두세 개로 묶습니다.
2. 묶은 원인마다 지침을 새로 쓰되, 기존 규칙과 겹치는 것은 합치고 잘못 발동하는 것은 뺍니다.
3. 후보를 한 번에 하나만 시험하지 말고, 검증 데이터를 여러 번 섞어 가장 꾸준히 좋은 후보를 고릅니다.

프롬프트 최적화는 직관과 시행착오의 영역에 머물 필요가 없습니다. 오류를 구조적으로 진단하고, 후보를 다양하게 만들고, 선택을 통계로 안정화하면 프롬프트는 짧아지고 정확도는 올라갑니다. 규칙이 계속 쌓이는 프롬프트를 처음부터 다시 설계하고 싶다면, 이 세 단계를 그대로 밟아 보시기 바랍니다.