모델을 바꿀 때마다 다시 쓰게 되는 프롬프트

모델을 바꾸는 결정은 대체로 표에서 시작한다. 단가가 얼마고 성능이 어떻고. 그 표를 보고 “바꾸자”가 되면, 실제로 바꾸는 일은 며칠이면 끝날 것 같다. API 주소와 키만 갈면 되니까.

그런데 매번 며칠이 아니었다. 다시 쓰게 되는 건 코드가 아니라 프롬프트였다.

갈아탈 때 실제로 드는 비용

코드 쪽은 요즘 대부분 추상화가 돼 있어서 실제로 하루면 끝난다. 문제는 그다음이다. 잘 돌던 프롬프트를 새 모델에 그대로 넣으면 결과가 미묘하게 달라진다. 아예 틀리면 차라리 낫다 — 미묘하게 다르면 어디부터 봐야 할지 모른다.

구체적으로는 이런 것들이 어긋난다. 출력 길이가 두 배가 된다. 표를 달라고 했는데 앞에 설명이 붙는다. 항목을 다섯 개 뽑으라고 했는데 네 개나 여섯 개가 나온다. 말투가 갑자기 정중해진다.

각각은 사소한데, 뒤에 자동 처리가 붙어 있으면 사소하지 않다. 그래서 실제 이전 작업의 대부분은 프롬프트를 하나씩 다시 확인하는 시간이었다.

이 시간을 미리 계산에 안 넣으면 이전 결정 자체가 틀어진다. 단가가 3분의 1쯤 싼 모델로 옮겨서 월 몇십만 원을 아꼈는데 확인·수정에 사람 며칠이 들어갔다면, 첫 달은 확실히 손해다. 오래 쓸 파이프라인이면 회수되지만, 반년 뒤에 또 옮길 생각이라면 회수 전에 다시 나간다.

그래서 나는 이전 결정을 할 때 프롬프트를 개수로 먼저 센다. 스무 개짜리 시스템과 두 개짜리 시스템은 같은 결정이 아니다.

살아남는 프롬프트와 깨지는 프롬프트

몇 번 옮겨 보고 나서 갈리는 지점이 보였다. 기준은 하나다 — 그 프롬프트가 모델의 성향에 기대고 있는가.

형용사에 기댄 프롬프트는 그 형용사를 모델이 어떻게 해석하느냐에 통째로 의존한다.

가장 자주 깨진 건 ‘간결하게’였다. 어떤 모델은 이걸 세 문장으로 받고 어떤 모델은 한 문단으로 받는다. 둘 다 틀린 게 아니라서 고치기도 애매하다. “세 문장 이내”로 바꾸면 그 뒤로는 안 깨진다.

역할 설정도 비슷하다. “당신은 20년차 컨설턴트다”만 주면 모델이 그 역할을 자기 방식대로 해석한다. 대신 “비용·일정·리스크 순으로 보고, 근거가 없으면 판단을 유보한다”처럼 판단 기준을 주면 어느 모델에서든 같은 걸 요구하게 된다. 역할은 분위기이고 기준은 지시다.

반대로 놀랄 만큼 잘 버틴 건 예시를 붙인 프롬프트였다. 원하는 출력을 짧게라도 한 번 보여 주면 모델이 바뀌어도 형태가 유지됐다. 설명 열 줄보다 예시 세 줄이 이식성이 높았다.

그래서 바꾼 쓰기 방식

이걸 겪고 나서 프롬프트를 쓰는 방식을 세 가지 바꿨다.

첫째, 형용사를 숫자로 바꾼다. ‘간결하게’는 ‘세 문장 이내로’, ‘충분히’는 ‘항목 다섯 개로’. 문장이 딱딱해지지만 결과가 흔들리지 않는다.

둘째, 출력 예시를 프롬프트 안에 넣는다. 길 필요 없다. 두세 줄짜리 견본이면 충분하고, 이게 형식 안정성에 가장 크게 기여했다.

셋째, 모르는 경우를 먼저 적는다. “자료에 없으면 ‘자료 없음’이라고만 적어라.” 이 한 줄이 없으면 모델은 그럴듯한 걸 지어낸다. 모델마다 지어내는 정도가 다르므로, 이 줄이 없는 프롬프트는 갈아탈 때마다 새로 검증해야 한다.

덧붙이면 이 셋을 다 적용하면 프롬프트가 길어진다. 길어지면 입력 토큰이 늘고 그건 비용이다. 다만 재시도가 줄어드는 쪽이 대체로 더 컸다 — 한 번에 제대로 나오는 게 짧게 물어보고 두 번 부르는 것보다 싸다.

프롬프트 엔지니어링이 과대평가됐다고 쓴 적이 있는데, 이 세 가지는 그 글에서 말한 ‘과대평가된 기교’와는 다른 축이다. 화려한 지시문을 짜는 게 아니라 해석의 여지를 줄이는 쪽이다.

그래도 안 되는 것

이렇게 해도 모델을 넘지 못하는 게 있다. 톤과 문체다.

같은 지시로도 모델마다 문장의 리듬이 다르다. 예시를 붙이면 형식은 맞춰지는데 문체까지는 안 따라온다. 사람이 읽고 다시 손보게 되고, 그 손보는 시간은 프롬프트로 못 줄인다.

여기에는 취향도 섞여 있다. 어떤 모델의 문장이 유난히 잘 맞는다고 느끼는 사람이 팀에 꼭 있는데, 그 감각이 틀렸다고 말하기 어렵다. 형식은 재서 비교할 수 있지만 문체는 재기가 어렵고, 재기 어려운 걸 억지로 재려고 하면 논쟁만 길어진다.

그래서 나는 문체가 중요한 작업과 형식이 중요한 작업을 분리해서 관리한다. 형식이 중요한 쪽은 모델을 자유롭게 갈아타고, 문체가 중요한 쪽은 웬만하면 안 바꾼다. 바꿀 거면 갈아타는 비용에 ‘다시 읽고 손보는 시간’을 미리 넣어 둔다.

실제로 모델을 고를 때 보는 네 축을 정리하면서도 이 부분은 단가표에 안 잡히는 비용으로 따로 뒀다.

정리하면

프롬프트는 자산이라고들 하는데, 자산이 되려면 이식 가능해야 한다. 특정 모델에서만 잘 도는 프롬프트는 자산이 아니라 그 모델에 묶인 부채에 가깝다.

이식성을 챙기는 데 드는 추가 비용도 사실 크지 않다. 형용사를 숫자로 바꾸고 예시 세 줄을 붙이는 건 처음 쓸 때 5분이면 되는 일이다. 나중에 옮길 때 그 5분이 몇 시간을 아낀다. 문제는 처음 쓸 때는 옮길 일이 없어 보인다는 것이고, 지난 2년 동안 나는 그 예상이 틀리는 걸 여러 번 봤다.

다음에 프롬프트를 쓸 때 한 가지만 확인해 보시길 권한다. 이 문장을 다른 모델에 그대로 넣어도 같은 걸 요구하는가. 그 답이 ‘아마도’라면 그 자리에 숫자나 예시를 넣을 자리가 있다는 뜻이다.

이 글에 쓴 근거

이 글은 외부 자료 인용 없이, 저자가 실제로 모델을 옮기며 정리한 기준으로 썼다.

필자는 AI 솔루션 공급사에 재직 중이다. 이 글은 개인 견해이며 소속사 입장과 무관하다. 특정 모델·서비스와 금전적 이해관계는 없다.

실무에서 검증한 AI 활용 기록, 계속 받아보기

이 글에서 다룬 판단 기준과 실패담을 카테고리별로 더 모아뒀습니다.

더 보기 →