시스템 프롬프트 학습: AI 시스템의 새로운 패러다임

잘 작동하던 특정 프롬프트가 갑자기 작동하지 않은 적이 있나요?

결과를 개선하려고 시스템 프롬프트를 계속 수정해도 아무 소용이 없는 악순환에 빠진 적이 있나요?

시스템 프롬프트 학습이 바로 필요한 해법일 수 있습니다.

시스템 프롬프트 학습(SPL)은 AI 커뮤니티에서 새롭게 주목받는 분야로, 5월에 Andrej Karpathy가 X에서 널리 알렸습니다.

시스템 프롬프트 학습은 정적인 시스템 프롬프트나 번거로운 미세 조정 설정에 의존하는 경직되고 취약한 AI 시스템의 한계를 해결합니다. AI 시스템의 지속적인 학습을 지원하는 또 하나의 방법입니다.

본격적으로 살펴보기 전에 프롬프팅의 기본 원리를 간단히 되짚어 보겠습니다.

에이전트나 맞춤형 모델을 개발할 때는 먼저 두 가지 핵심 요소를 설계해야 합니다.

1. 시스템 프롬프트

2. 사용자 프롬프트

시스템 프롬프트는 모델이 어떻게 행동해야 하는지에 관한 기본 규칙을 정합니다. 맞춤형 AI 솔루션을 위한 시스템 프롬프트는 흔히 다음과 같이 시작합니다.

“You are an intelligent assistant. Your role is to perform <insert task here>.

You must not do (A), (B), or (C).”

반면 사용자 프롬프트에는 일반적으로 사용자의 질문과 시간대, 선호도 같은 관련 정보가 포함됩니다. 사용자 프롬프트는 다음과 같은 형태일 수 있습니다.

I’m in the capital city of Portugal. Can you suggest some things I can do tonight?

주요 AI 연구소가 새 모델을 출시한 뒤 사용자가 챗봇을 탈옥시켜 내부 지침을 공개하면서 시스템 프롬프트 유출이 흔해졌습니다. 현재 인기 있는 GitHub 리포지터리 한 곳에 이러한 시스템 프롬프트가 다수 모여 있습니다. 이 프롬프트들은 AI 연구소가 적절한 모델 행동을 유도하기 위해 오랜 시간 개발해 온 ‘비법’을 보여 줍니다. 예를 들어 최근 유출된 GPT-5 시스템 프롬프트(ChatGPT 내에서 노출됨)는 약 6,000단어에 달합니다. 이는 시스템의 행동을 형성하려면 얼마나 많은 지식과 지침을 담아야 하는지 보여 줍니다.

이처럼 포괄적인 시스템 프롬프트는 일반적으로 다음과 같은 핵심 영역을 다룹니다.

• 검색 지침

• 도구 정의

• 사용자 선호도

• 인용 지침

• 알려진 문제에 대한 임시 패치

실제로 맞춤형 AI 시스템 개발자는 애플리케이션을 테스트하고 개선하면서 시스템 프롬프트를 수동으로 반복 수정하며, 이 개선 과정은 주로 평가를 통해 진행합니다.

모델의 행동을 유도하는 다른 방법은 다음과 같습니다.

• 모델에 제공되는 콘텐츠를 제어하는 검색 증강 생성(RAG)을 포함한 프롬프트 엔지니어링

• 미세 조정(모델의 기본 가중치를 직접 변경)

모델의 행동에 영향을 미칠 다른 방법이 있다면 어떨까요? 이전에 생성한 생각, 계획, 전략을 활용해 자체 시스템 프롬프트를 동적으로 학습하고 개선하는 시스템을 상상해 보세요. 사용자 피드백과 LLM 심사자 평가를 모두 활용해 출력을 평가할 수 있습니다.

에이전트형 시스템으로 자동화하고 싶은 고질적인 비즈니스 과제가 있다고 가정해 보겠습니다. 효과적인 해법에는 기본적인 워크플로 자동화를 넘어서는 추론 역량이 필요합니다. 이런 경우에는 AI 시스템에 계획 생성 구성 요소를 포함하는 것이 필수적입니다. 이를 통해 시스템은 작업에 따라 여러 에이전트와 다양한 방식으로 협력할 수 있습니다. 개별 단계에는 하위 작업을 완료하기 위해 다른 에이전트에 접근하거나 도구를 사용하는 지침이 포함될 수 있습니다.

참고: 에이전트 도구란 AI 에이전트가 텍스트 생성을 넘어 실제 작업을 수행하기 위해 호출할 수 있는 외부 함수, API 또는 리소스를 말합니다.

사람이 따를 법한 논리적 단계로 구성된 계획을 모델의 시스템 프롬프트에 ‘시드’로 제공할 수 있습니다. 다만 LLM에는 일반적으로 도구 사용, 출력 형식 및 관련 요건에 관한 더 구체적인 지침이 필요합니다. 때로는 최적의 전략이 분명하지 않거나, 이미 해결된 문제로 여겨져 오랫동안 재검토되지 않은 문제를 다루게 될 수 있습니다. 바로 이때 시스템 프롬프트 학습(SPL)이 필요합니다.

SPL은 이전에 생성된 전략을 반영해 시스템 프롬프트를 반복적으로 개선합니다. 새로운 문제가 생길 때마다 시스템은 점차 지식을 축적하고 더 견고해집니다. 특정 분야의 문제를 해결하기 위한 지침서를 만든다고 생각하면 됩니다.

SPL은 사용자 피드백에서 얻은 통찰을 시스템 프롬프트에 점진적으로 반영합니다. 시스템이 성숙함에 따라 반복되는 문제를 발견하고 이를 더 일반적이고 상위 수준인 원칙으로 정리할 수 있습니다.

이 과정이 어떻게 진행되는지 단계별로 자세히 살펴보겠습니다.

1. 먼저 사용자 쿼리를 통해 시스템에 특정 작업을 요청합니다.

2. 1. 시스템이 한 가지 문제만 다룬다면 이전 실행에서 가장 높은 점수를 받은 전략을 선택하는 ‘탐욕적’ 접근 방식을 사용할 수 있습니다. 또는 높은 평가를 받은 전략을 우선하되 때때로 낮은 평가의 전략도 포함하는 분포에서 샘플링해 탐색을 장려할 수 있습니다. 이는 전략을 수집하기 시작한 초기 단계에 특히 유용합니다.

   2. 다양한 문제군을 처리하도록 설계된 시스템이라면 분류 계층을 추가하거나, RAG에서 흔히 사용하는 것과 같은 임베딩과 코사인 유사도를 사용해 관련 접근 방식을 찾는 방법을 고려하세요. 이렇게 하면 코딩 작업에 특화된 전략처럼 특정 문제에 적합한 전략을 선택할 수 있습니다.

참고: 임베딩을 코사인 유사도와 함께 사용하면 두 정보가 얼마나 밀접하게 관련되어 있는지 측정할 수 있어, 정확한 표현이 다르더라도 문서, 쿼리 또는 아이디어를 더 쉽게 연결할 수 있습니다.

코딩 문제를 해결하기 위한 간소화된 전략 저장소의 시작점 예시

참고: 여기에 표시된 ‘시드 전략’은 예시입니다. 실제 코딩 상황에서는 이러한 전략을 더 다듬어야 합니다. 특수한 비즈니스 문제라면 시간이 지나면서 추가 통찰을 수집해야 합니다.

3. N개를 샘플링한 후 시스템 프롬프트에 반영합니다. 그러면 모델이 최소한의 지침만으로 계획을 만들게 두는 대신, 이전 전문가 피드백을 토대로 계획을 생성할 수 있습니다. 모델이 샘플 전략을 그대로 복사하지 않고 ‘틀을 깨고 생각’하며 필요할 때 단계를 추가하도록 유도하세요.

4. 동적으로 생성한 시스템 프롬프트를 사용해 사용자의 요청을 처리할 새로운 전략을 생성합니다. 이 과정에서는 최종 출력을 개선할 추가 작업이 도출되어야 합니다. 목표는 창의성입니다. 기존 전략의 가장 뛰어난 요소를 결합하고, 중복되는 단계를 통합하며, 필요한 경우 유용한 새 단계를 추가합니다.

참고: 온도는 출력을 더욱 다양하고 덜 결정적으로 만들도록 조정할 수 있는 매개변수이며, 창의성이 필요할 때 유용합니다. 온도가 0이 아니면 생성되는 계획이 매번 달라질 수 있습니다.

5. 모델의 출력을 받은 뒤, 문제의 좋은 해법을 정의하는 구체적인 기준에 따라 사람 평가자나 LLM 심사자를 이용해 평가합니다. 앞서 언급한 포르투갈 활동 예시의 평가 기준은 다음과 같을 수 있습니다.

• 간결성(한 문장으로 제한된 답변)

• 추천 활동의 관련성

• 위치의 정확성

6. 이 평가를 바탕으로 다른 모델을 사용해 전략을 개선합니다. 선택적으로 피드백 루프에 사람의 의견을 반영해 협업을 통한 개선을 지원할 수 있습니다. 버전과 변경 사항을 추적할 수 있도록 적절한 메타데이터와 함께 개선된 전략을 데이터베이스에 저장합니다.

그렇다면 왜 이 모든 수고를 감수해야 할까요? 출력을 직접 검토하고 그에 맞춰 시스템 프롬프트를 조정할 수도 있습니다. 하지만 강력한 추론 모델은 출력의 맥락과 사람의 피드백을 모두 활용해 전략을 개선할 수 있습니다. 단순한 접근 방식의 결함은 사람이 쉽게 발견할 수 있지만, 더 폭넓은 문제를 다루는 복잡한 시스템에서는 결함을 찾기가 어렵고 번거로워집니다.

LLM이 사람이 문제에 자연스럽게 적용하는 맥락 지식을 수집하려면 세부 지침과 추가 단계가 필요한 경우가 많습니다. 시스템이 더 폭넓은 문제를 다루도록 확장되면 필요한 작업 수가 빠르게 늘어날 수 있습니다. 예를 들어 코딩 문제를 푸는 사람은 주변 코드베이스를 직관적으로 이해할 수 있지만, LLM은 먼저 여러 파일을 ‘읽어야’ 할 수 있습니다.

• 유용한 경우: 고객 지원팀을 운영하고 있으며 AI 에이전트가 티켓 분류를 담당한다고 가정해 보겠습니다. 시간이 지나면서 SPL은 팀에서 생각하지 못했던 분류 방법을 발견해 상위 단계로 이관되는 비율을 낮출 수 있습니다.

• 유용하지 않은 경우: 재무 보고처럼 규정 준수 요건이나 법규가 워크플로를 이미 정하고 있다면 창의성이 자산이 아니라 위험 요소가 되므로 SPL의 가치는 크지 않을 수 있습니다.

• 유용한 경우: 시장 정보나 제품 전략처럼 연구 중심의 업무에서는 AI의 계획을 개선하고 출력을 보강한 뒤, 이러한 개선 사항을 향후 작업에 반영하며 AI와 협업할 수 있습니다. 상호작용할 때마다 시스템의 효율성이 높아집니다.

• 유용하지 않은 경우: 팀이 주로 송장 처리처럼 사람의 개입이 거의 필요 없는 단순한 워크플로에 AI를 사용한다면 협업에 드는 부담이 이점보다 클 수 있습니다.

• 유용한 경우: 새로운 지역으로 사업을 확장하면서 AI가 갑자기 현지 세금 문의를 처리해야 한다고 가정해 보겠습니다. SPL을 사용하면 새롭게 등장하는 규칙과 휴리스틱을 신속하게 반영해 같은 오류가 반복되는 것을 막을 수 있습니다.

• 유용하지 않은 경우: 회의 기록을 표준화된 요약으로 변환하는 작업처럼 환경이 고정적이라면 지속적인 적응으로 얻는 이점은 거의 없습니다.

이론적으로는 모두 유망해 보이지만 SPL을 구현하는 데는 현실적인 어려움이 따릅니다. 아래에서 몇 가지 주요 과제를 살펴보겠습니다.

전략 생성 초기에는 진전이 자주 정체됩니다. 새로운 출력이 이전 출력을 발전시키지 못하면서 추진력이 떨어집니다. 일반적으로 두 가지 주요 문제가 원인입니다.

• • 해결책: 시스템이 충분히 활용할 수 있도록 가용한 모든 비즈니스 지식을 처음부터 반영합니다.

• • 해결책: 정확성, 명확성, 관련성 등 답변의 여러 측면을 평가하는 정교한 루브릭을 설계하고, 이러한 신호를 반영하도록 샘플링을 조정합니다.

시스템이 수백 개의 전략을 생성하지만 좋은 전략과 나쁜 전략을 구분할 피드백이 거의 없다면 샘플링은 금세 관리하기 어려워집니다. 해답은 가지치기입니다.

전략 저장소를 개선할 때는 다음을 고려하세요.

• 수명: 정해진 기간이나 생성 횟수를 넘긴 전략은 폐기합니다.

• 점수: 평가 루브릭을 사용해 지속적으로 성과가 낮은 전략을 걸러냅니다. 이를 수명 기준과 결합하면 시간이 지나도 가치가 입증되는 접근 방식만 유지할 수 있습니다.

• LLM 심사: 유용한 요소가 이미 새 버전에 반영되었을 가능성이 있으므로, 더 이상 고유한 통찰을 제공하지 않는 전략을 찾기 위해 주기적으로 평가합니다.

해결책: 전략 데이터베이스를 살아 있는 시스템으로 다루세요. 관련성 높고 가치 있는 지식만 남도록 정기적으로 가지치기해야 합니다.

시스템 프롬프트 학습은 아직 초기 단계지만 잠재력은 막대합니다. 정적인 프롬프트나 끝없는 미세 조정에만 의존하는 기업은 취약한 시스템, 증가하는 비용, 낭비되는 노력이라는 익숙한 한계에 부딪히게 됩니다. SPL은 개별적인 패치가 아닌 상위 수준의 원칙을 반영하고 시간이 지날수록 개선되는 시스템을 구축해 이러한 악순환에서 벗어날 방법을 제시합니다.

SPL은 아직 발전 중이지만 방향은 분명합니다. 스스로 학습할 수 있는 시스템이 그렇지 못한 시스템을 앞서게 될 것입니다. 지금이 바로 실험할 때입니다. 작게 시작하고 교훈을 축적해 상호작용할 때마다 개선되는 AI 시스템의 기반을 마련하세요.