프롬프트에서의 XML 태깅: Claude 및 GPT로부터 더 나은 출력을 얻는 비결

지저분하고 예측 불가능한 LLM 출력을 깔끔하고 신뢰할 수 있는 출력으로 바꾸는 간단한 구조화 기법.

Claude, GPT 또는 기타 대규모 언어 모델 (LLM)을 위한 프롬프트를 작성하는 데 시간을 할애해 보았다면, 아마 다음과 같은 벽에 부딪혀 보았을 것입니다. 간단한 요청에는 프롬프트가 잘 작동하지만, 여러 지침(일부 컨텍스트, 몇 가지 예시, 형식 규칙 및 실제 작업)을 한꺼번에 넣는 순간 모델이 내용들을 뒤섞기 시작합니다. 질문의 잘못된 부분에 답변하거나, 형식 지침을 무시하거나, 예시 출력을 실제 작업의 일부로 취급해 버립니다.

해결책은 부끄러울 정도로 간단합니다. 프롬프트 섹션들을 XML 태그로 감싸는 것입니다.

XML 태그가 매우 효과적인 이유

LLM은 방대한 양의 코드, 문서 및 마크업 (Markup) 데이터로 학습되었습니다. XML (및 HTML) 구문은 해당 학습 데이터에 깊이 내재되어 있으며, 이는 모델이 하나의 태그된 섹션이 끝나고 다른 섹션이 시작되는 지점을 인식하는 데 매우 능숙함을 의미합니다. "여기는 내 컨텍스트입니다"와 "여기는 내 지침입니다" 사이의 경계가 모호한 일반적인 문단과 달리, 태그는 명확한 경계를 생성합니다.

Anthropic은 실제로 Claude를 위해 이를 명시적으로 권장합니다. 프롬프트의 별도 부분(지침, 컨텍스트, 예시, 출력 형식)을 <instructions>, <context>, <example>, <output_format>와 같은 태그로 감싸면, 특히 길거나 복잡한 프롬프트에서 일관성이 눈에 띄게 향상됩니다.

이는 누군가에게 텍스트 덩어리를 건네주는 것과 라벨이 붙은 필드가 있는 양식을 건네주는 것의 차이와 같다고 생각하면 됩니다. 둘 다 동일한 정보를 포함하고 있지만, 하나는 인간에게나 모델에게나 올바르게 파싱 (Parse)하기 훨씬 쉽습니다.

전후 비교 예시

태그가 없는 경우:

아래 기사를 3개의 불렛 포인트로 요약하세요. 50단어 이내로 작성하세요.
중립적인 어조를 사용하세요. 내가 원하는 스타일의 예시는 다음과 같습니다:
"- Company X가 시리즈 A 펀딩에서 1,000만 달러를 유치했습니다."
...

모델은 지시 사항이 어디서 끝나고 본문이 어디서 시작되는지를 추측해야 합니다. 본문이 길어질 경우, 모델은 실제 내용 대신 예시를 요약하기 시작할 때가 있습니다.

태그를 사용할 경우:

<instructions>
기사를 3개의 불렛 포인트로 요약하세요. 총 50단어 미만이어야 합니다.
중립적인 톤을 사용하세요.
...

이제 모호함이 전혀 없습니다. 모델은 무엇이 지시 사항이고, 무엇이 스타일 참조이며, 무엇이 작업할 원본 콘텐츠인지 정확히 알게 됩니다.

사용할 가치가 있는 일반적인 태그들

정식 스키마 (Schema)가 필요하지는 않습니다. 이것들은 단지 모델이 인식할 수 있는 의미론적 컨테이너 (Semantic containers)일 뿐입니다. 가장 유용한 것들은 다음과 같습니다:

• <instructions> — 실제 작업 (Task)
• <context> — 모델이 필요하지만 직접적으로 수행해서는 안 되는 배경 정보
• <example> / <examples> — 샘플 입출력 (Few-shot prompting)
• <document> 또는 <article> — 분석하거나 변환할 소스 텍스트
• <output_format> — 응답이 구조화되기를 원하는 정확한 방식
• <thinking> — 최종 답변 전에 단계별 추론 (Step-by-step reasoning)을 지원하는 모델을 위한 태그

태그를 중첩할 수도 있습니다. 예를 들어, 여러 소스를 한 번에 제공할 때 여러 개의 <document index="1">, <document index="2"> 블록을 사용할 수 있습니다. 속성 (Attributes) 또한 작동하며, 모델은 이를 정확하게 파싱 (Parse)합니다.

보너스: 태그가 포함된 출력을 요청하세요

이 기술은 입력에만 국한되지 않습니다. 모델에게 답변을 태그 안에 담아 _반환_하도록 요청할 수도 있으며, 이는 프로그래밍 방식으로 응답을 파싱하는 것을 매우 쉽게 만들어 줍니다:

<answer>
여기에 최종 응답을 작성하세요.
</answer>

만약 이것을 앱(예: AI SDK를 호출하는 Next.js API 라우트)에 구축하고 있다면, 이는

단일하고 단순한 지시사항("이것을 프랑스어로 번역하세요")의 경우, 태그를 사용하는 것은 과합니다. 이점 없이 노이즈만 추가할 뿐입니다. 프롬프트에 지시사항(instructions) + 컨텍스트(context) + 예시(examples) + 처리할 문서(document)와 같이 서로 혼동될 수 있는 **여러 개의 뚜렷한 구성 요소(multiple distinct components)**가 하나의 메시지에 포함되어 있다면 XML 태깅을 사용하세요.

핵심 요약 (Takeaway)

XML 태깅은 편법(hack)이 아닙니다. 이는 프롬프트에 적용된 훌륭한 API 설계에 더 가깝습니다. 여러분은 모델이 산문(prose)으로부터 의도를 추론하기를 바라는 대신, 모델에게 명시적인 계약(explicit contract)을 제공하는 것입니다. 다음에 프롬프트가 "거의 작동할 것 같은데"라는 느낌이 든다면, 문구를 다시 쓰기 시작하기 전에 각 부분을 태그로 감싸보세요. 종종 문제는 문구(phrasing)가 아니라 구조(structure)였습니다.