MCP Prompts의 멀티턴 messages — 서버가 모델의 첫 생각을 설계하는 방법

assistant 롤은 MCP가 만든 게 아니다

user / assistant 롤 구조는 2023년 3월 OpenAI가 Chat Completions API를 공개하면서 업계 표준이 됐다. 이후 Anthropic Messages API, Google Gemini, Mistral 등 사실상 모든 LLM 제공자가 동일한 구조를 채택했다. messages 배열에 user와 assistant 턴을 번갈아 넣어 대화 history를 표현하는 방식은 MCP 이전부터 이미 보편적 관행이었다.

MCP(Model Context Protocol)는 2024년 11월 Anthropic이 발표했고, prompts/get 응답의 messages 배열도 이 기존 표준을 그대로 빌려왔다. MCP가 새로 더한 것은 롤 자체가 아니라 서버가 assistant 턴을 미리 만들어 심을 수 있다는 구조적 허용이다. 사용자가 실제로 대화를 시작하기 전에, 서버가 "AI가 이미 이렇게 답했다"는 가상의 과거를 설계해 넣을 수 있게 된 것이다.

system 프롬프트만으로는 부족한 순간

LLM에게 복잡한 작업을 시킬 때 system 프롬프트로 "이렇게 분석해라"고 지시하는 건 기본이다. 그런데 실제로 써보면 system 프롬프트가 잘 안 먹히는 상황이 있다.

코드 보안 분석을 예로 들자. "unsafe 블록, 외부 입력 경로, 에러 핸들링 순으로 검토해라"고 system에 써도, 모델은 자기 흐름대로 대답하는 경우가 많다. system 프롬프트는 "규칙"이지만, 모델은 그 규칙을 얼마나 충실히 따를지 스스로 결정한다. 반면 이미 그 방향으로 대화가 진행된 상태라면 이야기가 달라진다. 모델은 자신이 한 말을 이어간다.

MCP Prompts의 messages 배열이 assistant 롤을 지원하는 이유가 여기 있다. 서버는 "AI가 이렇게 답했다"는 가상의 과거 대화를 미리 심을 수 있고, 모델은 그 대화를 이어받아 추론한다.

1-turn vs 멀티턴 — 어디서 차이가 나는가

같은 질문에 두 방식이 어떻게 다른지 구체적으로 보자.

▲ 1-turn: system 지시

▲ 멀티턴: 가짜 history 주입

핵심 차이: system 프롬프트는 모델에게 "이렇게 해라"는 지시다. 멀티턴 history는 "나는 이미 이렇게 시작했다"는 기정사실이다. 모델은 지시보다 자신이 이미 시작한 방향을 더 일관되게 따른다.

assistant 턴이 필수적으로 쓰이는 세 가지 패턴

어떤 상황에서 멀티턴이 실질적으로 필요한지 패턴별로 보자.

패턴 1 — 추론 방향 고정 (Reasoning Anchor)

모델이 어떤 프레임으로 문제를 바라볼지 미리 결정해 두는 패턴이다. 복잡한 분석 작업에서 모델이 "어디서부터 시작할지"를 스스로 선택하게 두면 매번 다른 결과가 나온다.

효과: 팀원 10명이 각자 다른 방식으로 요청해도 서버가 심어둔 체크리스트 프레임을 이어받기 때문에 분석 구조가 일관된다. 모델이 어떤 요점을 빠뜨리거나 엉뚱한 방향으로 달리는 것을 막는다.

패턴 2 — 출력 형식 강제 (Format Locking)

모델에게 "JSON으로 답해라"고 system에 써도 자연어가 섞이는 경우가 흔하다. assistant 턴에 원하는 형식의 예시를 미리 심으면 모델이 그 형식을 이어받는다.

효과: system 프롬프트에 JSON 형식을 설명하는 것보다 assistant가 그 형식으로 이미 시작한 것처럼 보여주는 것이 훨씬 강력하다. 특히 긴 목록 형태의 구조화된 출력에서 효과가 크다.

패턴 3 — 단계적 분해 유도 (Step Decomposition)

복잡한 작업을 모델이 한 번에 처리하려 하면 품질이 떨어진다. 미리 "단계별로 나눠서 보겠다"고 assistant가 선언하게 하면, 모델이 실제로 단계적으로 추론한다.

효과: 모델이 "생각해야 할 것"을 서버가 미리 분해해 줬기 때문에 각 단계를 깊이 있게 다룬다. 단일 질문으로 받았을 때 얕게 훑는 문제를 해결한다.

실제 messages 배열 구조

MCP prompts/get 응답에서 서버가 돌려주는 messages 배열은 이렇게 생겼다.

// prompts/get 응답 — 멀티턴 messages
{
  "messages": [
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "이 Rust 코드의 잠재적 보안 취약점을 분석해 줘:\n[현재 편집 중인 파일 내용]"
      }
    },
    {
      "role": "assistant",           // ← 서버가 만들어 넣은 가짜 AI 답변
      "content": {
        "type": "text",
        "text": "코드를 분석하겠습니다. 보안 관점에서 다음 순서로 검토합니다:\n1. unsafe 블록 사용 현황\n2. 외부 입력 처리 경로\n3. 에러 핸들링 패턴\n분석을 시작합니다:"
      }
    },
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "특히 외부 입력(네트워크/파일 I/O)을 처리하는 부분에 집중해서 분석해 줘."
      }
    }
  ]
  // 클라이언트는 이 배열을 현재 대화 context 앞에 prepend하고 LLM에 전달
}

코드 설명: role: "assistant"가 있는 2번째 메시지는 실제로 모델이 생성한 것이 아니다. 서버가 "모델이 이렇게 답했다"고 가정하고 만든 텍스트다. 클라이언트는 이 배열 전체를 LLM에 넘기고, 모델은 자신이 이미 이 방향으로 시작했다고 인식한 채 다음 답변을 생성한다.

클라이언트 입장에서 보는 전체 흐름

클라이언트가 이 배열을 받아서 실제 LLM 호출까지 이어지는 흐름을 한눈에 보면 이렇다.

클라이언트 코드는 단순하다. 서버에서 받은 messages 배열을 그대로 LLM API의 messages 파라미터 앞에 붙이면 끝이다. 배열 안에 assistant 턴이 있어도 클라이언트는 특별히 할 일이 없다. LLM API가 알아서 history로 처리한다.

1-turn system 프롬프트 vs 멀티턴 messages — 언제 무엇을 쓰나

결정 기준은 간단하다: 모델이 자유롭게 구조를 잡아도 되면 system 프롬프트, 구조 자체를 서버가 통제해야 하면 멀티턴이다. 특히 같은 프롬프트를 팀 전체가 쓸 때 결과 품질 편차를 줄여야 한다면 멀티턴이 훨씬 강력하다.

세 가지 효과 — 정리

멀티턴 messages가 실제로 주는 효과를 정리하면 세 가지다.

세 번째 효과가 MCP Prompts 전체의 핵심이기도 하다. 클라이언트는 서버가 심어둔 assistant 턴의 내용을 모른다. 알 필요도 없다. 서버 팀이 프롬프트를 개선하면 — 체크리스트 항목을 추가하거나, 형식 예시를 더 정교하게 만들거나 — 클라이언트는 아무것도 바꾸지 않아도 자동으로 개선된 버전을 사용하게 된다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.