프롬프트 최적화와 모델 이전

프롬프트를 오래 다뤄 본 팀일수록 묘한 함정에 빠지기 쉽다. 문제가 생길 때마다 문장을 하나씩 덧붙이고, 예외가 생길 때마다 경고를 한 줄 더 붙이고, 특정 모델에서 잘 먹히던 표현을 아낌없이 쌓아 올린다. 처음에는 이것이 정교함처럼 보인다. 하지만 시간이 지나면 프롬프트는 정교해지는 대신 무거워진다. 읽기 어려워지고, 테스트하기 어려워지고, 다른 모델로 옮기기 더 어려워진다.

이 장의 핵심은 단순하다. 운영 가능한 프롬프트는 가장 긴 프롬프트가 아니라 목적 대비 가장 효율적인 프롬프트다. 좋은 최적화는 말을 줄이는 기술이 아니라, 모델이 반드시 알아야 할 신호를 더 선명하게 만드는 기술이다. 최근 모델 가이드들도 예전보다 더 짧고 결과 중심적인 프롬프트가 잘 작동하는 경우가 많다고 권한다.¹ 그래서 고급 실무에서 프롬프트 최적화는 꾸미기가 아니라 구조조정에 가깝다.

최적화의 목표는 짧음이 아니라 선명함이다

짧은 프롬프트가 항상 좋은 것은 아니다. 필요한 제약까지 같이 지워 버리면 그건 최적화가 아니라 손실이다. 반대로 긴 프롬프트가 항상 나쁜 것도 아니다. 긴 문서 요약이나 다단계 정책 판단처럼 본질적으로 많은 조건이 필요한 작업도 있다. 중요한 것은 길이가 아니라 신호 대 잡음비다.

프롬프트에서 신호는 모델이 반드시 지켜야 하는 핵심 요소다. 예를 들면 작업 목표, 성공 기준, 근거의 출처, 금지 범위, 출력 계약 같은 것들이다. 반면 잡음은 없어도 거의 영향이 없거나, 오히려 해석을 흐리게 만드는 요소다. 장식적인 역할 설정, 같은 뜻의 반복, 과거 모델의 버릇을 달래기 위해 붙여 둔 임시 문장, 예외를 설명한다며 핵심 규칙보다 길어진 해설이 여기에 들어간다.

그래서 프롬프트 최적화의 첫 질문은 "몇 토큰 줄일까"가 아니다. 먼저 "이 문장이 어떤 실패를 막기 위해 존재하는가"를 물어야 한다. 답을 말할 수 없는 문장은 대개 삭제 후보다. 실무에서는 프롬프트의 각 블록을 다음 다섯 가지 중 하나로 분류해 보면 도움이 된다.

• 목표: 무엇을 만들어야 하는가

• 기준: 무엇이면 성공인가

• 근거: 무엇을 보고 답해야 하는가

• 경계: 어디까지 허용되고 어디서 멈춰야 하는가

• 형식: 어떤 구조로 내놓아야 하는가

이 다섯 칸 어디에도 들어가지 않는 문장은 꽤 자주 프롬프트의 지방이다. 지방이 조금 있다고 당장 시스템이 쓰러지지는 않지만, 많이 쌓이면 움직임이 둔해진다.

중복 지시 제거: 같은 말을 세 번 쓰면 더 강해지는 것이 아니다

프롬프트가 길어지는 가장 흔한 이유는 새 규칙이 많아서가 아니라, 같은 규칙이 여러 방식으로 반복되기 때문이다. 어떤 팀의 프롬프트를 보면 "정확하게 답하라", "틀리지 말라", "사실에 근거하라", "환각하지 말라"가 서로 다른 위치에 반복된다. 사람 눈에는 꼼꼼해 보이지만, 모델에게는 강한 신호라기보다 비슷한 문장이 여러 번 나오는 배경음으로 읽힐 수 있다.

중복은 보통 네 가지 형태로 나타난다.

• 같은 규칙이 시스템 지시, 개발자 지시, 출력 설명에 중복된다.

• 형용사가 겹친다. 예를 들어 "간결하고 짧고 불필요한 말 없이 핵심만" 같은 식이다.

• 예시가 규칙을 보완하는 대신 규칙을 다시 장문으로 반복한다.

• 이전 모델에서만 필요했던 보정 문장이 새 모델에서도 습관처럼 남아 있다.

이럴 때 좋은 방법은 문장을 더 세게 쓰는 것이 아니라, 한 규칙을 한 자리에서만 책임지게 만드는 것이다. 예를 들어 출력 형식은 형식 블록에서만 정의하고, 사실성 규칙은 근거 블록에서만 정의하고, 실패 시 행동은 경계 블록에서만 정의한다. 같은 내용을 세 군데에 나눠 넣는 대신, 한 군데에서 테스트 가능하게 쓰는 편이 훨씬 낫다.

다음 두 프롬프트를 비교해 보자.

너는 매우 정확하고 신중하며 사실 기반으로 답하는 훌륭한 정책 도우미다.
절대로 틀리면 안 된다.
환각하지 말고 사실만 말하라.
정확하고 간결하게 답하라.
모르면 추측하지 말라.
정책 문서를 참고해서 정확한 답을 하라.
짧고 명확하게 답하라.

역할: 사내 정책 도우미
근거: 제공된 정책 문서만 사용
규칙: 문서 근거가 없으면 추측하지 말고 "문서 근거 없음" 반환
출력: 3문장 이내, 결론 먼저

두 번째가 더 짧아서 좋은 것이 아니다. 무엇을 지키면 되는지가 더 분명해서 좋다. 첫 번째는 좋은 말이 많지만, 실제 운영 규칙은 흐릿하다. 두 번째는 예쁘지 않아도 시스템이 검사하기 쉽다.

outcome-first 설계: 과정보다 먼저 결과를 고정하라

최적화에서 가장 효과적인 습관 중 하나는 프롬프트를 outcome-first, 즉 결과 중심으로 다시 쓰는 일이다. 최신 가이드들은 많은 경우 모델에게 긴 절차를 미리 설교하기보다, "좋은 답이 어떤 모습인지"를 먼저 분명히 말하는 편이 더 낫다고 설명한다.¹²

이 말은 과정을 완전히 버리라는 뜻이 아니다. 다만 순서를 바꾸라는 뜻이다. 예전 프롬프트는 종종 이렇게 시작한다. "천천히 생각하라. 단계별로 분석하라. 놓치지 말라. 세심하게 검토하라." 그런데 이런 문장은 모델이 무엇을 산출해야 하는지보다, 어떻게 행동하길 바라는지에 먼저 초점을 둔다. 특정 모델에서는 잘 듣지만, 다른 모델에서는 불필요하게 장황해지거나 형식 준수가 약해질 수 있다.

결과 중심 프롬프트는 보통 다음 순서가 더 안정적이다.

첫째, 산출물을 먼저 정의한다. 무엇을 만들 것인가. 둘째, 성공 기준을 적는다. 어떤 답이면 통과인가. 셋째, 근거의 범위를 정한다. 무엇을 보고 답할 것인가. 넷째, 실패 시 행동을 정한다. 모를 때는 어떻게 할 것인가. 마지막으로 정말 필요할 때만 과정 힌트를 얹는다.²

예를 들어 문서 요약 시스템이라면 "중요 내용을 빠짐없이 잘 요약해 줘"보다 아래 구조가 더 낫다.

작업: 회의록을 임원용 브리핑으로 요약하라.
성공 기준: 5문장 이내, 결정사항 먼저, 미결 이슈는 마지막에 별도 표시.
근거: 입력된 회의록 내용만 사용.
실패 규칙: 결정사항이 불분명하면 추측하지 말고 "결정사항 불명확" 표시.
출력 형식: summary, open_issues

이 구조가 모델 이전에 강한 이유는 분명하다. 모델마다 선호하는 말투와 사고 습관은 달라도, 산출물 계약 자체는 바뀌지 않기 때문이다. 반대로 "이 모델은 단계별 설명을 좋아하더라", "저 모델은 존댓말로 길게 풀어야 잘 듣더라" 같은 경험칙은 모델이 바뀌는 순간 흔들리기 쉽다.

긴 프롬프트 압축: 덜 넣는 것이 아니라 더 중요한 것만 남기는 일

프롬프트 압축을 이야기하면 많은 사람이 먼저 토큰 절감을 떠올린다. 물론 그것도 중요하다. 하지만 더 본질적인 이유는 따로 있다. 프롬프트가 길어질수록 중요한 규칙과 근거가 중간에 묻히기 쉽고, 모델이 덜 중요한 정보까지 함께 처리하느라 주의가 흩어진다. 효율적 프롬프팅 연구와 프롬프트 압축 연구는 이런 맥락에서, 더 짧은 입력이 단지 싸기만 한 것이 아니라 더 잘 작동할 수도 있음을 보여 준다.³⁴

실무에서 압축은 대개 세 층에서 일어난다.

• 지시 압축: 중복 규칙, 장식 문장, 과거 보정 문장을 줄인다.

• 예시 압축: 많은 예시를 유지하는 대신 경계 사례 몇 개만 남긴다.

• 문맥 압축: 긴 검색 결과나 긴 문서를 질문과 관련 있는 부분 위주로 줄인다.

이 중에서도 문맥 압축은 특히 조심스럽게 다뤄야 한다. 질의와 무관하게 문서를 통째로 압축하는 방식보다, 현재 질문을 알고 관련 부분을 남기는 질의 인식형 압축이 보통 더 효율적이다.⁴ 쉽게 말해, 사용자가 묻는 것이 "출장비 상한"인데 복리후생 전체 규정을 균등하게 압축하면 정작 필요한 조항이 희미해질 수 있다.

압축을 할 때는 무엇을 줄일지보다 무엇을 보존할지를 먼저 정해야 한다. 아래 기준은 특히 유용하다.

여기서 중요한 함정이 하나 있다. 압축은 흔히 "말을 예쁘게 요약하는 일"로 오해되지만, 운영 관점에서는 그렇지 않다. 압축된 프롬프트는 읽기 좋은 글보다 실패를 덜 만드는 구조여야 한다. 그래서 정책 문서를 요약하더라도 조항 번호나 금지 조건을 빼면 안 되고, 예시를 줄이더라도 실제로 자주 깨지는 경계 사례는 남겨야 한다.

모델 변경 시 프롬프트는 어디서 깨지는가

모델 이전이 어려운 이유는 프롬프트 전체가 한꺼번에 망가져서가 아니다. 보통은 몇 군데가 먼저 깨진다. 문제는 그 몇 군데가 파이프라인 전체를 무너뜨리기에 충분하다는 점이다. 최근 프롬프트 마이그레이션 연구는 최적화된 프롬프트를 다른 모델에 그대로 옮기면 성능이 떨어질 수 있으며, 그 과정에서 중요한 지시가 사라지거나 약해지는 일이 흔하다고 지적한다.⁵

실무에서 자주 보는 파손 지점은 다섯 가지다.

• 형식 파손: JSON 키 이름, 배열 구조, 마크다운 구성이 미묘하게 달라진다.

• 우선순위 파손: 예전에는 강하게 먹던 규칙이 새 모델에서는 덜 중요하게 취급된다.

• 추론 스타일 파손: 설명이 너무 짧아지거나 반대로 길어져서 후처리가 깨진다.

• 안전/거절 파손: 같은 요청인데 더 쉽게 거절하거나, 반대로 더 넓게 허용한다.

• 도구/행동 파손: 같은 업무라도 도구 호출 횟수나 선택 순서가 달라진다.

현업 보고를 보면 모델 변화는 두 가지 방식으로 문제를 만든다. 하나는 강제 교체처럼 눈에 띄는 명시적 회귀이고, 다른 하나는 같은 계열 안에서 서서히 행동이 달라지는 조용한 드리프트다.⁶ 전자는 파서가 바로 깨지기 때문에 빨리 발견된다. 후자는 더 위험하다. 답은 얼핏 멀쩡해 보이지만, 점점 장황해지거나 인용 방식이 바뀌거나, 특정 엣지 케이스에서만 실패율이 오른다.

이때 기억해야 할 원칙은 하나다. 프롬프트가 깨지는 이유는 대개 모델이 나빠져서가 아니라, 우리가 프롬프트에 작업 요구사항이 아니라 특정 모델의 습관을 너무 많이 박아 넣었기 때문이다. 모델 친화적 표현은 도움이 되지만, 그것이 구조의 중심이 되면 이전 비용이 급격히 올라간다.

모델 이전에 강한 프롬프트는 핵심과 보정을 분리한다

같은 작업을 여러 모델에서 돌려야 한다면 프롬프트를 두 층으로 생각하는 편이 좋다. 하나는 모델이 바뀌어도 유지되어야 하는 핵심 계약이고, 다른 하나는 특정 모델에서만 필요한 얇은 보정층이다.

핵심 계약에는 이런 것들이 들어간다. 무엇을 해야 하는지, 어떤 근거만 사용할 수 있는지, 근거가 없을 때 어떻게 해야 하는지, 어떤 스키마로 반환해야 하는지, 어떤 조건이면 실패로 간주하는지다. 이것은 서비스 요구사항이므로 모델이 바뀌어도 크게 변하지 않는다.

반면 보정층에는 이런 것들이 들어간다. 특정 모델에서 형식 준수를 높이기 위한 표현, 지나치게 장황한 응답을 줄이기 위한 짧은 제약, 툴 호출 순서를 더 안정화하기 위한 국소 규칙 같은 것들이다. 이것은 필요할 수 있지만, 어디까지나 보조 장치다.

이 분리가 되어 있으면 이전 작업이 훨씬 쉬워진다. 새 모델로 갈 때 먼저 핵심 계약만 옮겨서 기준선을 본다. 그다음 실제로 측정된 실패에만 얇은 보정을 추가한다. 반대로 기존 프롬프트를 통째로 복사하면, 핵심 계약과 구형 보정이 한 묶음으로 이동하면서 새 모델과 불필요하게 충돌한다. OpenAI의 최신 마이그레이션 가이드들도 이런 식의 단순화와 재구성을 권한다.²⁷

이전 절차: 옮기기 전에 먼저 가볍게 만들어라

모델 이전을 할 때 많은 팀은 곧바로 "새 모델용 프롬프트를 어떻게 새로 쓸까"로 들어간다. 하지만 순서는 보통 반대여야 한다. 먼저 해야 할 일은 현재 프롬프트를 정리하는 것이다. 어수선한 창고를 통째로 이사 가면 새 집도 금방 어수선해진다.

실무에서는 다음 흐름이 가장 안전하다.

먼저 현재 프롬프트에서 핵심 계약과 보정 문장을 분리한다. "없으면 서비스 요구가 깨지는 문장"과 "예전 모델에서만 도움 되던 문장"을 나눠 보는 것이다. 이 단계만 해도 생각보다 많은 문장이 삭제 후보가 된다.

다음으로 가장 작은 기준선 프롬프트를 만든다. 목표, 근거, 경계, 출력 형식만 남긴 최소 버전이다. 이 버전으로 새 모델에서 성능을 먼저 본다. 의외로 새 모델은 예전보다 덜 많은 프롬프트 공학을 필요로 하기도 한다.¹²

그다음에는 회귀 테스트셋과 실제 로그 샘플을 함께 돌린다. 여기서 중요한 것은 문자열 동일성보다 의미 수준의 통과 기준이다. 답이 조금 더 짧아졌다고 해서 실패는 아니다. 반대로 문장은 자연스러워졌는데 인용 위치가 틀리면 그것은 실패다.

그 후에야 국소 보정을 추가한다. 예를 들어 특정 모델이 배열 대신 객체를 자주 내놓는다면 출력 계약을 더 명시한다. 응답이 너무 길어지면 성공 기준에 길이 제약을 강화한다. 거절 경향이 강해졌다면 허용 범위와 금지 범위를 더 또렷하게 분리한다. 중요한 것은 실패를 측정한 뒤 그 실패에만 수술하듯 손대는 것이다.

자동 프롬프트 최적화 도구나 메타프롬프팅 도구는 이 과정을 빠르게 해 줄 수 있다. 다만 그것들은 설계자를 대신하지 않는다. 자동 최적화는 후보를 잘 제안할 수 있지만, 무엇이 서비스의 핵심 계약인지까지 대신 판단해 주지는 못한다.⁵⁷

긴 프롬프트 스택을 버티는 가장 좋은 방법은 애초에 덜 쌓는 것이다

고급 시스템을 만들다 보면 프롬프트 스택이 생기는 것은 자연스럽다. 시스템 규칙, 제품 규칙, 도구 설명, 포맷 계약, 예시, 문서 문맥, 세션 상태가 모두 필요할 수 있다. 문제는 이것을 계속 누적만 할 때다. 오래된 규칙은 남고, 새 규칙이 위에 덧붙고, 삭제는 아무도 하지 않는다. 그러면 어느 순간 팀은 프롬프트를 이해하지 못한 채 두려워하게 된다. "이 문장 지우면 혹시 뭔가 깨질까 봐" 건드리지 못하는 상태가 된다.

이 상태를 피하려면 프롬프트도 코드처럼 다뤄야 한다. 즉 추가뿐 아니라 삭제가 있어야 하고, 각 블록의 책임이 명확해야 하고, 모델 이전 전에 리팩터링이 있어야 한다. 프롬프트 최적화는 완성 뒤에 하는 다이어트가 아니라, 주기적으로 하는 정리정돈에 가깝다.

길고 복잡한 프롬프트가 언제나 나쁜 것은 아니지만, 길고 복잡한 프롬프트가 왜 그렇게 길어졌는지 아무도 설명하지 못하는 상태는 거의 항상 나쁘다. 운영 가능한 시스템은 복잡성을 숨기지 않는다. 대신 복잡성이 어디에 있는지, 무엇을 위해 존재하는지, 어떤 테스트가 그것을 지켜 주는지 드러낸다.³⁸

정리: 좋은 최적화는 더 적게 말하면서도 덜 흔들리는 구조를 만든다

이 장에서 기억할 것은 네 가지다. 첫째, 프롬프트 최적화의 목표는 짧음이 아니라 선명함이다. 둘째, 중복 지시를 없애고 outcome-first 구조로 바꾸면 모델이 읽어야 할 핵심이 또렷해진다. 셋째, 긴 프롬프트 압축은 토큰 절감이 아니라 중요한 정보의 밀도를 높이는 작업이다. 넷째, 모델 이전에 강한 프롬프트는 특정 모델의 버릇보다 서비스의 핵심 계약을 중심에 둔다.

운영 가능한 프롬프트는 멋진 문장이 아니다. 새 모델로 옮겨도 다시 읽을 수 있고, 실패가 생겨도 어디를 고쳐야 할지 보이고, 같은 목적을 더 적은 비용과 더 적은 흔들림으로 달성하는 구조다.

프롬프트를 오래 운영할수록, 잘 쓴 프롬프트는 대개 짧아진다. 다만 그 짧아짐은 대충 줄인 결과가 아니라, 무엇이 핵심인지 배운 결과다. 그 차이가 실무의 내구성을 만든다.

참고

¹Prompt guidance

²GPT-5.2 Prompting Guide

³Efficient Prompting Methods for Large Language Models: A Survey

⁴The Fundamental Limits of Prompt Compression

⁵Rethinking Prompt Optimization: Reinforcement, Diversification, and Migration in Blackbox LLMs

⁶Model updates and prompt stability: what the data shows

⁷GPT-5 Prompt Migration and Improvement Using the New Optimizer

⁸Impromptu: a framework for model-driven prompt engineering