LLM 지시문·데이터 분리

LLM에 문서를 넣을 때, 어디까지가 지시문이고 어디부터가 데이터인지 모델이 제대로 구분하는지는 오래된 문제다. arXiv에 올라온 2603.22519는 이 문제를 다룬다. 원문 발췌에 따르면 제안의 출발점은 단순하다. LLM의 입출력은 여전히 “문자열 1개”지만, 실제로 전달하는 정보는 그보다 더 구조적이라는 점이다. 핵심은 성능 과장이 아니다. 프롬프트 엔지니어링을 인터페이스 설계 문제로 다루려는 시도라는 데 의미가 있다.

세 줄 요약

이번 이슈의 핵심은 자연어 한 덩어리에 섞여 있던 지시문과 데이터를 구분해 전달하는 LLM 네이티브 마크업 제안이다. 원문 발췌와 2603.22519 식별자 기준으로 확인되는 지점은 “문자열 인터페이스의 의미 손실” 문제 제기다.
중요한 이유는 추론 성능 우위가 입증돼서가 아니다. 구조화 입력은 프롬프트 해석 오류를 줄이고 데이터 흐름을 제한해 안전성과 운영 안정성을 높일 가능성이 있다. Anthropic은 XML 태그가 프롬프트 오해를 줄일 수 있다고 설명하고, OpenAI는 Structured Outputs와 JSON Schema 일치 신뢰성을 강조한다.
독자는 지금 프롬프트를 길게 다듬기보다 지시문, 비신뢰 데이터, 툴 입력을 분리하는 인터페이스 규칙부터 점검해야 한다. 새 마크업 채택 여부는 그다음 문제다. 먼저 현재 워크플로에서 모델이 무엇을 “명령”으로 읽는지 검증해야 한다.

현황

이번 논문의 제목은 LLMON: An LLM-native Markup Language to Leverage Structure and Semantics at the LLM Interface다. 제공된 발췌에서 확인되는 핵심 주장은 명확하다. 텍스트 LLM은 입력과 출력을 문자열로 주고받지만, 실제 프롬프트 안에는 “요약하라” 같은 지시와 “요약할 논문 본문” 같은 데이터가 함께 들어간다. 문제는 이 둘이 보통 같은 평문 채널에 섞여 전달된다는 점이다.

이 문제의식 자체는 새롭지 않다. Anthropic 문서는 XML 태그를 활용해 프롬프트를 구조화하면 모델이 프롬프트 일부를 잘못 해석해 생기는 오류를 줄일 수 있다고 설명한다. OpenAI 문서도 비슷한 방향을 취한다. Structured Outputs와 함수 호출은 모델 출력을 JSON Schema에 맞추는 신뢰성을 높이는 방식으로 소개된다. 즉 업계는 이미 “자연어 하나면 충분하다”보다는 “구조를 추가해야 운영이 수월해진다”는 방향으로 움직이고 있다.

다만 여기서는 선을 분명히 그어야 한다. 이번에 제안된 마크업이 JSON, XML, 함수 호출 스키마보다 실제 추론 품질을 얼마나 끌어올리는지에 대한 직접 정량 비교는 조사 범위에서 확인되지 않았다. 구조화 인터페이스의 장점은 현재로서는 벤치마크 우위보다 입력 의미의 분리, 출력 형식의 안정성, 안전한 데이터 흐름 설계에 더 가깝다. 2408.11061 StructuredRAG도 구조화 출력의 신뢰성과 일관성에는 추가 연구가 필요하다고 짚는다.

분석

이 신호가 중요한 이유는 프롬프트를 “문장 잘 쓰는 기술”이 아니라 “계층이 있는 인터페이스”로 다시 보게 만들기 때문이다. 에이전트, 툴 호출, 문서 처리, 평가 파이프라인으로 갈수록 이 구분은 더 중요해진다. 예를 들어 웹에서 가져온 문서, 사용자 업로드 파일, 외부 API 응답은 모두 비신뢰 데이터다. 이 텍스트가 시스템 지시와 같은 평면에 놓이면 모델은 경계를 흐리게 읽을 수 있다. OpenAI의 에이전트 안전 가이드는 비신뢰 데이터가 에이전트 행동을 직접 구동하지 않게 설계하고, 필요한 필드만 구조적으로 추출하라고 권한다. 이건 마크업 취향의 문제가 아니라 권한 경계 설계의 문제다.

반론도 분명하다. 구조를 넣는다고 추론이 자동으로 좋아지는 건 아니다. XML 태그를 붙인다고 사고력이 늘어나는 것은 아니고, JSON Schema를 강제한다고 사실 검증이 해결되는 것도 아니다. 더구나 업계 공통 표준으로 수렴할지도 아직 알 수 없다. 현재 확인되는 흐름은 텍스트 호출 계층에서는 OpenAI 호환 API가 널리 쓰이고, 도구 연결 계층에서는 MCP가 개방형 프로토콜로 제시된다는 정도다. 이번 제안이 이 둘을 가로지르는 공통 문법으로 자리 잡을지, 아니면 연구 아이디어로 남을지는 아직 판단하기 이르다.

실전 적용

지금 팀이 할 일은 새 마크업 언어를 곧바로 도입하는 것이 아니다. 먼저 현재 프롬프트를 점검해야 한다. 시스템 지시, 개발자 지시, 사용자 입력, 검색 결과, 첨부 문서, 툴 반환값이 한 문자열에 섞여 있다면 이미 문제의 일부가 드러난 상태다. 구조화 인터페이스의 첫 효과는 모델을 더 똑똑하게 만드는 데 있지 않다. 개발자가 “무엇을 명령으로 취급해야 하는지”를 명시하게 만드는 데 있다.

예를 들어 계약서 요약 에이전트를 만든다고 해보자. 기존 방식은 “다음 계약서를 읽고 핵심 조항을 요약하라” 아래에 계약서 원문을 그대로 붙인다. 구조화 방식은 instruction, document, constraints, output_schema처럼 역할을 나눈다. 그러면 모델에도 경계가 더 선명해지고, 후처리 코드도 어느 필드를 검증해야 하는지 분명해진다. 프롬프트 인젝션을 막을 수는 없더라도, 외부 문서의 문장을 내부 정책처럼 오인하는 위험은 낮출 수 있다.

오늘 바로 할 일 체크리스트 3개:

현재 프롬프트에서 지시문, 비신뢰 데이터, 툴 입력값을 분리해 각각 별도 필드나 태그로 표현하라.
외부 문서에서 필요한 값만 구조적으로 추출하고, 원문 전체가 직접 툴 호출 인자로 들어가지 않게 하라.
새 마크업을 검토하더라도 먼저 JSON Schema, 구조화 출력, 승인 단계 같은 기존 안전 장치와 함께 비교 실험하라.

FAQ

Q. 이 마크업이 JSON이나 XML보다 더 낫다고 봐야 하나요?
그렇게 단정할 근거는 아직 부족합니다. 조사 범위에서는 이 제안이 JSON, XML, 함수 호출 스키마보다 추론 품질이나 안정성을 얼마나 개선하는지 직접 비교한 정량 벤치마크가 확인되지 않았습니다.

Q. 구조화 인터페이스가 프롬프트 인젝션을 막아주나요?
위험을 낮추는 데는 도움이 됩니다. 신뢰된 지시와 비신뢰 데이터를 구분하면 모델이 외부 텍스트를 명령으로 오해할 가능성을 줄일 수 있습니다. 다만 그것만으로 충분하지는 않으며, 승인 절차, 가드레일, 격리 실행 같은 장치를 함께 써야 합니다.

Q. 업계 표준으로 굳어질 가능성이 있나요?
가능성은 있지만 확인된 결론은 없습니다. 현재는 OpenAI 호환 API가 널리 쓰이고, MCP가 도구 연동 계층의 개방형 표준으로 제시되는 흐름이 보입니다. 이번 제안된 마크업이 벤더 전반의 공통 표준으로 채택될지는 더 지켜봐야 합니다.

결론

이번 논문이 던지는 문제의식은 분명하다. LLM 인터페이스의 다음 경쟁은 더 긴 프롬프트가 아니라, 지시문과 데이터를 어떻게 분리해 전달하느냐에 있을 수 있다. 다만 지금 단계에서 중요한 건 새 문법의 승자를 점치는 일이 아니다. 구조 없는 문자열 인터페이스가 이미 만들고 있는 운영 리스크를 줄이는 일이 더 중요하다.

Aionda

LLM 지시문·데이터 분리

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기