대부분의 사람들은 페르소나(persona), 규칙, 형식, 그리고 실제 질문을 모두 하나로 뭉쳐서 하나의 메시지에 붙여넣습니다. 하지만 모델에는 두 개의 분리된 채널이 있으며, 그 차이를 아는 것이 핵심 비결입니다. 사용자 턴(user turn)은 매번 바뀌는 질문이고, 시스템 프롬프트(system prompt)는 모든 턴에 걸쳐 지속되는 고정된 지침입니다. 저는 여러 부분으로부터 시스템 프롬프트를 조립하고, 동일한 질문이 시스템 프롬프트에 따라 어떻게 다르게 답변되는지 보여주는 라이브 플레이그라운드(playground)를 구축했습니다. 이를 만들면서 배운 점은 다음과 같습니다.

하나의 문자열이 아닌 두 개의 채널

사용자 메시지(user message)는 변화하는 요청입니다. 시스템 메시지(system message)는 한 번 설정하면 뒤따르는 모든 질문에 적용되는 행동 양식입니다. 이러한 분리가 핵심입니다. 동일한 사용자 턴이라도 그 위에 놓인 시스템 프롬프트에 따라 완전히 다른 답변을 내놓습니다. 아무 설정이 없는 모델은 자유 연상(free-associates)을 하며 답변해서는 안 될 것들에 대해서도 답할 것입니다. 역할(role)만 지정된 프롬프트는 브랜드 이미지는 맞지만 형태가 없습니다. 반면 전체 사양(full spec)이 갖춰진 프롬프트는 구조화되어 있고, 브랜드 정체성을 유지하며, 범위를 벗어난 요청을 안전하게 거절합니다. 이것은 미세 조정(fine-tuning)이 아니라 프롬프트 구성(prompt-construction)입니다. 즉, 행동 양식은 읽고, 차이점을 비교(diff)하고, 토글(toggle)할 수 있는 편집 가능한 문자열 안에 존재합니다.

고정된 순서의 다섯 가지 블록

좋은 시스템 프롬프트는 동일한 구성 요소들을 계층적으로 쌓으며, 저는 각 요소를 켜거나 끌 수 있는 스위치로 구축했습니다.

• ROLE (역할) — 모델이 누구인지 설정합니다 ("당신은 ...의 시니어 지원 엔지니어입니다"). 목소리와 기본 가정을 설정합니다.
• RULES (규칙) — 명시적인 해야 할 것 / 하지 말아야 할 것의 목록입니다. 여기서 실제 행동 양식이 고정됩니다.
• OUTPUT FORMAT (출력 형식) — 답변을 어떻게 구성할지 결정합니다: JSON, 번호가 매겨진 단계, 한 문장 등. 산문을 구조로 바꿉니다.
• FEW-SHOT (퓨샷) — 원하는 행동을 설명하는 대신 보여주는 한두 개의 기준점입니다.
• GUARDRAILS (가드레일) — 무엇을 거절할지, 그리고 어떻게 거절할지입니다. 위험한 답변을 안전한 거절로 전환하는 블록입니다.

스위치가 켜진 블록들만 고정된 표준 순서로 나타나며, 전체 문자열은 system 채널을 통해 한 번에 전송됩니다. 사용자 메시지에 절대 섞이지 않습니다.

가드레일이 작동하는 모습 관찰하기

데모는 여러분이 활성화한 블록에 정확히 반응하는, 문서화된 결정론적 모의 응답(mock reply, API 키나 실제 호출 불필요)을 실행합니다. 따라서 인과 관계를 직접 볼 수 있습니다. 아무런 설정이 없는 모델(bare model)에 위험한 질문을 던지면 모델은 답변합니다. 여기에 가드레일(guardrail) 블록을 추가하면 동일한 질문이 거절로 바뀝니다. 형식(format) 블록을 추가하면 산문 형태의 답변이 번호가 매겨진 단계로 변합니다. 역할(role)을 추가하면 평이한 답변이 브랜드 이미지에 맞게 변합니다. 메시지 구조 패널은 이를 세 개의 턴(turn)으로 보여줍니다:

system:    역할(ROLE) + 규칙(RULES) + 형식(FORMAT) + 가드레일(GUARDRAILS)   (한 번 설정되면 지속됨)
user:      "매번 동일한 질문"                                               (매 턴마다 변경됨)
assistant: 상단의 시스템 프롬프트에 의해 형성된 답변                          

시스템 프롬프트를 바꾸고 사용자 턴을 동일하게 유지하면 어시스턴트 턴이 바뀝니다. 이것이 이 데모의 핵심입니다.

콘텐츠가 아닌 행동(Behaviour)

마침내 깨달은 점은 이것입니다: 시스템 프롬프트는 _행동(behaviour)_을 구성하고, 사용자 턴은 _콘텐츠(content)_를 전달한다는 것입니다. 이는 추론 기술(reasoning techniques)과는 구별됩니다. 생각의 사슬(chain-of-thought) 등을 포함한 나머지 기술들은 모델이 문제를 어떻게 풀어나가는지에 관한 것입니다. 반면 시스템 프롬프트는 추론이 시작되기도 전에 _모델을 어디서 어떻게 설정할 것인가_에 관한 것입니다. 해당 지시 사항(standing instruction)에서 역할, 규칙, 형식, 가드레일을 올바르게 설정하면 모든 사용자 턴은 이를 자동으로 상속받습니다. 반대로 이를 잘못 설정하면 질문을 아무리 영리하게 구성하더라도 답변을 살릴 수 없습니다.

두 가지를 분리해야 하는 두 번째 이유는 규모가 커질 때만 나타납니다: 시스템 프롬프트는 모든 요청에 대해 동일하므로, 사용자 입력과 독립적으로 캐싱(cache), 버전 관리(version), _A/B 테스트(A/B test)_를 할 수 있는 부분입니다. 거절 로직이 새어 나가거나 형식이 어긋날 때, 수천 개의 엉킨 메시지를 뒤질 필요 없이 차이점(diff)을 확인할 수 있는 단 하나의 편집 가능한 문자열만 있으면 됩니다. 또한 이것은 가중치(weights)가 아닌 선언적 텍스트(declarative text)이기 때문에, 행동을 변경하는 것은 학습(training run)이 아니라 코드 리뷰(code review)의 영역입니다.

실질적인 결과는 다음과 같습니다: 질문 안에 규칙을 억지로 집어넣는 것을 중단하십시오. 페르소나 (persona), 엄격한 제약 조건 (hard constraints), 출력 형태 (output shape) 및 거절 규칙 (refusals)을 그것들이 마땅히 있어야 할 시스템 채널 (system channel)에 배치하고, 사용자 턴 (user turn)은 오직 요청 사항 (ask)으로만 남겨두십시오. 그러면 동일한 질문이라도 매 턴마다 일관되고, 브랜드 정체성에 부합하며, 안전하게 답변하게 됩니다. 구성 요소들을 조합하여 시스템 프롬프트를 구축하고, 동일한 질문이 각 프롬프트 하에서 어떻게 다르게 답변하는지 확인해 보십시오:

https://dev48v.infy.uk/prompt/day51-system-prompt.html