모델 차이와 프롬프트 아키텍처

1장에서 우리는 프롬프트를 더 이상 한 줄짜리 요령이 아니라 운영 시스템의 일부로 봐야 한다고 이야기했다. 그렇다면 다음 질문은 자연스럽다. 시스템의 일부라면, 그 시스템은 어떤 모델 위에 올라가도 어느 정도는 버텨야 하지 않을까.

실무에서는 같은 프롬프트를 넣었는데도 모델이 전혀 다른 사람처럼 반응하는 순간을 자주 만난다. 어떤 모델은 짧고 단정하게 답하고, 어떤 모델은 과하게 친절하며, 어떤 모델은 형식을 잘 지키지만 어떤 모델은 좋은 뜻으로 형식을 깨뜨린다. 또 어떤 모델은 애매한 요청에도 과감히 추론하고, 어떤 모델은 안전을 우선하다 보니 조금만 위험해 보여도 쉽게 거절한다. 언어모델은 본질적으로 확률적이며, 학습 데이터와 정렬 방식, 도구 사용 설계에 따라 응답 습관이 달라진다.¹

그래서 고급 프롬프트 설계는 특정 모델을 기분 좋게 만드는 문장을 찾는 작업이 아니다. 여러 모델이 제각기 다른 연주를 하더라도, 최소한 같은 악보의 범위 안에서 연주하게 만드는 구조를 설계하는 작업에 가깝다. 이런 관점에서 단일 프롬프트를 넘어 여러 레이어와 여러 호출을 포함한 전체 구성을 생각하는 일을 프롬프트 아키텍처라고 부를 수 있다.²

같은 프롬프트인데 왜 모델마다 다르게 답할까

모델 차이를 이해하는 첫걸음은, 언어모델을 하나의 추상적 존재로 뭉뚱그려 보지 않는 것이다. 겉으로는 모두 텍스트를 받아 텍스트를 내놓는 것처럼 보이지만, 실제로는 적어도 네 가지가 다르다.

첫째, 지시를 해석하는 방식이 다르다. 어떤 모델은 문장을 문자 그대로 읽는 경향이 강하고, 어떤 모델은 사용자의 의도를 더 적극적으로 추정한다. 그래서 같은 요청이라도 한 모델은 요청한 것만 하고, 다른 모델은 아마 이것도 원하겠지 하며 일을 더 벌인다.

둘째, 안전과 거절의 기준이 다르다. 어떤 모델은 경계가 낮아서 조금만 민감해 보여도 조심스럽게 물러서고, 어떤 모델은 가능한 범위 안에서 최대한 도와주려 한다. 둘 다 장단점이 있다. 전자는 안전하지만 실무에서 답답할 수 있고, 후자는 유용하지만 통제가 약하면 위험해질 수 있다.

셋째, 형식 준수 능력이 다르다. JSON처럼 딱 떨어지는 구조를 잘 지키는 모델이 있는가 하면, 사람에게는 더 읽기 좋지만 시스템에는 더 불편한 문장형 응답을 자꾸 섞는 모델도 있다. 자동화 파이프라인에서는 이 차이가 꽤 치명적이다.

넷째, 긴 문맥을 다루는 습관이 다르다. 어떤 모델은 앞부분의 규칙을 오래 붙들고 가고, 어떤 모델은 뒤쪽의 최근 지시를 더 강하게 따르며, 어떤 모델은 긴 프롬프트 중간에 묻힌 중요한 규칙을 놓치기도 한다. 이른바 lost in the middle 문제는 긴 프롬프트를 쌓을수록 더 자주 드러난다.⁵

이 차이를 인정하면 중요한 사실이 보인다. 프롬프트의 품질은 문장 자체만으로 결정되지 않는다. 같은 프롬프트도 어떤 모델에서는 정밀한 명세로 읽히고, 다른 모델에서는 넉넉한 제안 정도로 읽힌다. 따라서 프롬프트를 잘 쓴다는 말은 사실 두 가지 능력을 함께 뜻한다. 하나는 지시를 명확히 쓰는 능력이고, 다른 하나는 모델이 그 지시를 어떻게 오해할지를 미리 상상하는 능력이다.

모델별 응답 성향은 다섯 축으로 읽어라

새 모델을 접했을 때 막연히 좋다, 똑똑하다, 말을 잘 듣는다라고 평가하면 금방 한계에 부딪힌다. 실무에서는 좀 더 분해해서 봐야 한다. 특히 다음 다섯 축으로 살펴보면 프롬프트 아키텍처를 잡기가 훨씬 쉬워진다.

• 지시 충실도: 요청한 일만 정확히 하는가, 아니면 과하게 보충하는가

• 형식 안정성: 지정한 출력 형식과 스키마를 얼마나 잘 지키는가

• 추론 성향: 단계적 설명을 좋아하는가, 결론부터 말하는가

• 안전 민감도: 애매한 요청에서 쉽게 거절하는가, 넓게 허용하는가

• 문맥 활용 방식: 긴 입력에서 중요한 규칙과 근거를 끝까지 유지하는가

예를 들어 요약 시스템을 만든다고 해보자. 한 모델은 핵심 문장을 잘 압축하지만 자꾸 의견을 덧붙일 수 있다. 다른 모델은 의견은 덜 섞지만 길이를 잘 못 줄일 수 있다. 또 다른 모델은 길이와 형식은 잘 맞추는데, 원문에 없는 연결 문장을 너무 자신 있게 만들어 넣을 수 있다. 겉으로는 모두 요약 모델처럼 보이지만, 실제 운영에서는 전혀 다른 통제 전략이 필요하다.

이 다섯 축을 파악하는 가장 좋은 방법은 화려한 예문을 찾는 것이 아니다. 같은 작업을 여러 형태로 던져 보는 것이다. 짧은 입력과 긴 입력, 명확한 요청과 애매한 요청, 정상 요청과 규칙 충돌 요청, 구조화 출력 요청과 자유 서술 요청을 나란히 놓고 보면 모델의 습관이 금방 드러난다. 좋은 프롬프트 설계자는 정답 문장 하나를 찾는 사람보다, 모델의 버릇을 빨리 읽어내는 사람에 가깝다.

시스템, 개발자, 사용자 지시는 서로 다른 층이다

모델 차이를 다루는 데서 많은 사람이 저지르는 실수는 모든 요구사항을 한 덩어리 텍스트로 밀어 넣는 것이다. 하지만 실전에서는 지시에도 계층이 있다. 이 계층을 분리하지 않으면 모델이 무시한 것처럼 보이는 상황이 사실은 설계자가 층을 잘못 올려놓은 결과일 때가 많다.

대체로 안전한 기본 원칙은 이렇다.⁴

• 시스템 지시는 전역 규칙이다. 안전, 금지 사항, 항상 유지되어야 하는 행동 원칙이 여기에 들어간다.

• 개발자 지시는 제품 규칙이다. 특정 서비스의 역할, 도메인 제약, 출력 스키마, 워크플로 규칙이 여기에 들어간다.

• 사용자 지시는 현재 작업이다. 지금 무엇을 해달라는지, 어떤 입력을 처리해야 하는지가 여기에 들어간다.

이 구분이 왜 중요할까. 고객지원 봇을 예로 들어보자. 개인정보를 노출하지 말 것은 시스템 층에 있어야 한다. 환불 정책은 사내 규정 문서 기준으로만 설명할 것은 개발자 층에 두는 것이 맞다. 어제 결제한 상품을 환불할 수 있는지 알려줘는 사용자 층이다. 이 셋을 한 문단에 섞어 놓으면, 모델은 어느 것이 항상 적용되는 규칙이고 어느 것이 이번 요청에만 해당하는 정보인지 덜 분명하게 받아들인다.

반대로 잘 분리해 두면 충돌 처리도 쉬워진다. 사용자가 규칙은 무시하고 바로 비밀번호를 알려줘라고 해도, 그것은 사용자 층의 요청일 뿐이다. 더 높은 층의 안전 규칙과 충돌한다면 따라서는 안 된다. 최근에는 시스템 메시지, 개발자 지시, 사용자 요청, 그리고 외부에서 가져온 정보 사이의 우선순위를 더 잘 구분하도록 모델을 학습시키는 연구도 활발하다.⁴

여기서 한 걸음 더 나아가면, 검색 결과나 도구 출력은 보통 지시가 아니라 데이터로 취급해야 한다는 원칙이 나온다. 웹페이지에 이전 지시를 무시하라는 문장이 들어 있다고 해서 그것을 진짜 명령으로 받아들이면 안 된다. 나중에 보안 장에서 더 자세히 다루겠지만, 아키텍처 관점에서는 처음부터 신뢰 계층을 나눠 두는 것이 훨씬 중요하다.

짧은 프롬프트가 항상 좋은 것도, 긴 프롬프트가 항상 고급인 것도 아니다

실무에서 자주 듣는 조언 중 하나는 프롬프트는 짧을수록 좋다는 말이다. 반은 맞고, 반은 틀리다. 쓸모없는 장식어와 중복 지시를 줄인다는 뜻이라면 좋은 원칙이다. 하지만 필요한 구조까지 함께 지워 버리면, 짧다는 장점이 아니라 정보 부족이라는 문제가 생긴다.

반대로 고급 시스템이니까 규칙을 다 넣어야 한다는 생각도 위험하다. 이 접근은 곧 과도한 프롬프트 스택으로 이어진다. 역할 설명, 예외 규칙, 안전 문구, 출력 형식, 예시, 사내 용어집, 정책 요약, 실패 처리, 말투 지시가 한 덩어리로 붙기 시작하면 처음에는 든든해 보인다. 하지만 시간이 지나면 서로 충돌하고, 어디가 핵심 규칙인지 흐려지며, 모델마다 다르게 무시되는 부분이 생긴다.

핵심은 길이가 아니라 분리다. 좋은 프롬프트는 짧아서 좋은 것이 아니라, 각 조각의 책임이 분명해서 좋다. 최근 프롬프트 설계 가이드들이 역할, 작업, 문맥, 제약, 출력 형식을 분리해 다루라고 권하는 이유도 여기에 있다.³⁵

너무 짧은 프롬프트에는 보통 이런 문제가 생긴다. 작업 목표는 알겠는데 경계가 없다. 형식은 원하는데 실패 시 행동 규칙이 없다. 사용자의 입력은 주어졌는데 어떤 근거를 우선해야 하는지 없다. 결국 모델은 친절한 추측으로 빈칸을 메운다.

너무 긴 프롬프트에는 다른 문제가 생긴다. 규칙이 중복된다. 서로 다른 시점에 붙인 문장이 조용히 충돌한다. 중요한 제약이 중간에 파묻힌다. 예시가 많아질수록 일반 규칙보다 특정 예시를 베끼는 경향이 강해진다. 그리고 무엇보다, 다음 모델로 옮길 때 어디가 핵심이고 어디가 장식인지 구분하기 어려워진다.

그래서 고급 프롬프트 아키텍처는 흔히 짧게 써라보다 레이어를 나눠라에 더 가깝다. 길이를 줄이되, 줄이는 기준은 삭제가 아니라 책임 분해여야 한다.

모델 이전에도 견디는 프롬프트는 구조가 선명하다

그렇다면 어떤 구조가 모델이 바뀌어도 비교적 오래 버틸까. 완전히 보편적인 정답은 없지만, 실무에서 잘 견디는 프롬프트에는 공통점이 있다.

• 목표가 먼저 나온다. 무엇을 잘하면 성공인지가 초반에 명확하다.

• 안정 규칙이 분리되어 있다. 금지 사항, 안전 규칙, 범위 제한이 임시 요청과 섞이지 않는다.

• 입력과 참고 자료가 구분되어 있다. 사용자 질문, 검색 결과, 예시, 시스템 규칙이 덩어리로 섞이지 않는다.

• 출력 계약이 있다. 형식, 필수 필드, 길이, 실패 시 대체값이 정해져 있다.

• 모를 때의 행동이 있다. 추측 대신 질문, 보류, 근거 부족 표시 같은 선택지가 정의되어 있다.

• 예시는 적지만 전략적이다. 평균적인 예시보다 경계 사례를 보여준다.

이 여섯 가지를 잘 지키면 프롬프트는 특정 모델의 성격에 덜 의존한다. 반대로 한 모델에서만 잘 먹히는 프롬프트는 대체로 숨은 전제가 많다. 예를 들어 알아서 자연스럽게, 최대한 똑똑하게, 읽기 좋게 정리해줘 같은 표현은 사람끼리는 통하지만, 모델이 바뀌면 해석 편차가 크게 벌어진다.

좋은 아키텍처는 추상적 표현을 운영 규칙으로 번역한다. 자연스럽게 대신 세 문단 이내, 결론 먼저, 전문 용어는 한 번만 설명이라고 적는다. 정확하게 대신 제공된 문맥에 근거가 없으면 추측하지 말고 근거 부족을 표시라고 적는다. 형식을 지켜 대신 필수 필드는 title, answer, confidence처럼 계약을 쓴다. 문장을 멋지게 쓰는 것보다, 해석의 여지를 줄이는 것이 이 장의 핵심이다.

프롬프트 아키텍처는 문장보다 인터페이스에 가깝다

프롬프트를 인터페이스로 보면 설계가 훨씬 단순해진다. 인터페이스는 멋진 수사가 아니라, 무엇이 들어오고 무엇이 나가며 어떤 규칙이 항상 유지되는지를 정의하는 장치다. 이런 관점에서 보면 프롬프트는 다음처럼 설계하는 편이 좋다.

시스템 레이어에는 오래 유지될 행동 원칙만 둔다. 예를 들어 안전, 비밀 보호, 불확실성 표현, 허용된 응답 스타일이 여기에 온다.

개발자 레이어에는 제품 규칙을 둔다. 예를 들어 내부 정책 문서만 근거로 답할 것, 출력은 특정 스키마를 따를 것, 인용이 없으면 답변 범위를 제한할 것 같은 내용이 여기에 온다.

사용자 레이어에는 현재 요청만 둔다. 지금 무엇을 요약할지, 무엇을 분류할지, 어떤 문서를 읽을지, 원하는 길이와 대상 독자가 누구인지를 여기에 넣는다.

참고 문맥은 별도 블록으로 둔다. 검색 결과, 사내 문서, 테이블 데이터, 예시는 사용자 요청과 섞지 않고 분리한다. 이렇게 해야 모델이 무엇을 규칙으로 읽고 무엇을 재료로 읽어야 하는지 덜 헷갈린다.⁵

이 구조는 거창해 보이지만, 사실 소프트웨어 설계에서 늘 하던 일과 비슷하다. 전역 설정, 애플리케이션 설정, 요청 단위 파라미터를 분리하는 것과 거의 같다. 프롬프트 아키텍처가 어렵게 느껴지는 이유는 새로운 개념이라서가 아니라, 많은 팀이 아직 프롬프트를 코드처럼 관리하지 않고 대화처럼 관리하기 때문이다.

모델 마이그레이션에서 강한 프롬프트는 무엇이 다른가

현실에서는 모델이 바뀌지 않기를 바라는 것보다, 바뀔 것을 전제로 준비하는 편이 낫다. 모델은 계속 업그레이드되고, 어떤 것은 사라지며, 어떤 것은 같은 이름처럼 보여도 내부 성향이 달라진다. 그래서 최근에는 프롬프트 마이그레이션이라는 말까지 등장했다.⁶

여기서 중요한 것은 새 모델에 맞춰 프롬프트를 처음부터 다시 쓰는 일이 아니다. 먼저 지금 프롬프트의 어떤 부분이 안정 규칙이고, 어떤 부분이 작업 명세이며, 어떤 부분이 특정 모델에 맞춘 보정인지 분리해 두는 일이다. 이 분리가 안 되어 있으면 모델을 바꿀 때 전체가 함께 흔들린다.

마이그레이션에 강한 프롬프트는 대체로 이런 특징을 가진다.

첫째, 핵심 규칙이 앞단에 선명하게 있다. 둘째, 예시는 최소한으로 유지되고 목적이 분명하다. 셋째, 출력 형식이 테스트 가능하다. 넷째, 모델이 바뀌어도 바뀌지 않아야 할 성공 기준이 따로 정리되어 있다. 다섯째, 실패했을 때 어느 레이어가 문제인지 추적할 수 있다.

예를 들어 모델 교체 뒤에 갑자기 답변이 장황해졌다고 하자. 시스템 레이어의 말투 규칙이 약해진 것인지, 개발자 레이어의 길이 제약이 모호한 것인지, 사용자 입력에 불필요한 배경 정보가 너무 많이 들어간 것인지 나눠서 볼 수 있어야 한다. 프롬프트가 하나의 거대한 문단이면 이런 진단이 거의 불가능하다.

이 점에서 프롬프트 아키텍처는 품질 향상 기술이면서 동시에 유지보수 기술이다. 새로운 모델이 더 똑똑해지는 것과는 별개로, 우리 시스템이 그 변화를 얼마나 침착하게 흡수할 수 있는지가 실무 경쟁력이다.

모델 친화적 프롬프트보다 모델 독립적 구조를 우선하라

물론 특정 모델에 맞춘 미세 조정은 필요하다. 어떤 모델은 예시를 더 잘 먹고, 어떤 모델은 제약을 짧게 써야 잘 따르며, 어떤 모델은 출력 스키마를 반복해 줘야 덜 흔들린다. 이런 보정은 분명 실용적이다.

하지만 순서를 바꾸면 안 된다. 먼저 해야 할 일은 모델 독립적인 구조를 만드는 것이다. 즉 무슨 일을 시키는지, 어디까지 허용되는지, 무엇을 근거로 삼는지, 어떤 형식으로 내놓아야 하는지를 구조적으로 분리하는 것이다. 그다음에야 모델별 미세 조정을 얹는다.

이 순서를 지키면 모델을 바꿔도 손볼 곳이 비교적 명확하다. 반대로 처음부터 특정 모델의 말투, 특정 모델의 선호 표현, 특정 모델에서만 잘 통하는 묘수에 많이 기대면, 마이그레이션은 곧 재작성 작업이 된다.

한마디로 요약하면 이렇다. 모델 친화적 프롬프트는 단기 성과를 낼 수 있다. 하지만 모델 독립적 구조는 장기 운영을 가능하게 한다. 고급 실무에서는 둘 다 필요하지만, 언제나 후자가 먼저다.

정리: 좋은 프롬프트는 한 모델의 묘수가 아니라 오래 버티는 설계다

이 장의 핵심은 분명하다. 모델은 서로 다르다. 같은 프롬프트도 모델에 따라 다르게 읽히고, 다른 습관으로 실행되며, 다른 종류의 실패를 만든다. 따라서 고급 프롬프트 설계는 어느 모델에서 제일 잘 먹히는 말을 찾는 일이 아니라, 모델 차이를 흡수할 수 있는 아키텍처를 만드는 일이어야 한다.

그 아키텍처의 출발점은 지시 계층을 분리하는 것이다. 시스템 지시는 전역 규칙으로, 개발자 지시는 제품 규칙으로, 사용자 지시는 현재 작업으로 나눈다. 그리고 입력, 근거, 예시, 출력 계약을 섞지 않는다.

또한 좋은 구조는 길이 경쟁을 하지 않는다. 짧다고 무조건 좋지 않고, 길다고 무조건 고급도 아니다. 중요한 것은 책임이 분리되어 있고, 규칙의 우선순위가 보이며, 형식과 실패 처리까지 포함한 인터페이스로 설계되어 있는가다.

결국 좋은 프롬프트는 특정 모델에서만 빛나는 비밀 주문이 아니다. 모델이 바뀌고, 제품이 커지고, 규칙이 늘어나도 중심을 잃지 않는 구조다. 다음 장부터는 바로 그 구조를 어떻게 증명하고 평가할지, 즉 좋아 보인다가 아니라 좋다를 어떻게 입증할지를 다루게 된다.

참고

¹Prompt Design and Engineering: Introduction and Advanced Methods

²Is it Time to Start Talking About Prompt Architecture in LLMs?

³프롬프팅 소개

⁴프런티어 LLM의 명령 계층 구조 개선

⁵The Complete Guide to Structured Prompt Architecture

⁶Prompt Migration: Stabilizing GenAI Applications with Evolving Large Language Models