AI는 똑똑하지만, 당신의 프로젝트를 '이미 알고' 시작하지는 않습니다. 컨텍스트가 부족하면 모델은 가장 그럴듯한 추측을 채워 넣어 답을 완성하려고 합니다. 반대로 필요한 근거를 프롬프트 안에 넣어 주면, 답은 '추측'이 아니라 '자료 위의 판단'으로 바뀝니다.
이 장의 목표는 간단합니다. AI가 추측하게 두지 않고, 근거 위에서 답하도록 만드는 컨텍스트 제공법을 익히는 것입니다.
컨텍스트는 "많이"가 아니라 "정확히"다
컨텍스트는 모델이 한 번의 응답을 생성할 때 참고하는 토큰들의 집합입니다.1 문제는 이 토큰이 무한하지 않다는 점입니다. 길게 넣을수록 '더 잘하겠지'라고 생각하기 쉽지만, 실제로는 컨텍스트가 커질수록 집중력이 떨어지거나 중요한 정보를 놓치는 현상이 보고됩니다(일명 context rot). 그래서 컨텍스트는 유한한 자원이며, "가장 작은 고신호(high-signal) 정보 세트"를 찾는 일이 핵심이 됩니다.1
여기서 말하는 '작다'는 단순히 '짧다'는 뜻이 아닙니다. 목표 행동을 확실히 만들기 위해 필요한 정보는 충분히 줘야 합니다. 다만 중복·장식·배경지식 자랑이 토큰을 잠식하지 않도록, 정보의 밀도를 관리해야 합니다.1
무엇을 컨텍스트로 줄 것인가: 4가지 재료
컨텍스트는 대체로 네 가지 재료로 구성됩니다. 이 장의 제목이기도 합니다.
배경은 "지금 왜 이 일을 하는지"를 설명합니다. 자료는 "근거로 삼을 텍스트/데이터"를 제공합니다. 예시는 "이런 방식으로 답하라"를 보여 줍니다. 용어정의는 "같은 단어를 같은 의미로 쓰자"를 고정합니다.
이 네 가지는 서로 역할이 다릅니다. 섞어 쓰면 모델도 섞습니다. 따라서 섹션을 나누고, 경계를 표시하는 것이 먼저입니다.
구분자(섹션/태그)로 컨텍스트를 '분리'하라
긴 프롬프트가 실패하는 가장 흔한 이유는 내용의 질이 아니라 경계가 흐려져서입니다. 모델 입장에서 "지시문"과 "참고문서"가 한 덩어리면, 무엇을 따라야 하는지 애매해집니다.
구분자는 이 애매함을 줄여 줍니다. 간단한 따옴표/삼중 따옴표/대시/꺾쇠괄호 같은 delimiter로도 섹션을 분리할 수 있고, 더 복잡한 구조가 필요하면 XML 태그를 쓰는 방식이 실용적입니다.2 또한 프롬프트를 <background_information>, <instructions> 같은 섹션으로 나누는 구조화가 권장되기도 합니다.1
아래는 '같은 내용'이라도 구조가 달라지면 안정성이 달라지는 전형적인 예입니다.
나쁜 예: 모두 한 덩어리
"아래 내용을 참고해서 요약해줘. 우리는 B2B SaaS고, 고객은 인사팀이고, 이 문서는 보안 가이드고… (이하 문서 원문)"
이런 프롬프트는 모델이 배경과 원문을 섞어 요약하거나, 원문에 없는 내용을 배경지식으로 채우기 쉽습니다.
좋은 예: 섹션을 분리
아래 템플릿처럼 지시 / 배경 / 자료 / 출력 요구를 분리하면, 모델은 '어떤 텍스트를 근거로 답해야 하는지'를 더 잘 구분합니다.
<instructions>
아래 <sources>에 포함된 내용만 근거로 사용해 요약해라.
<background>는 독자/목적 이해를 위한 정보이며, 사실 근거로 인용하지 마라.
</instructions>
<background>
독자: B2B SaaS 인사팀(비기술자). 목적: 보안 가이드를 1페이지로 축약.
</background><sources> """ (원문 붙여넣기) """ </sources>
핵심은 '태그' 자체가 아니라 역할을 분리하는 습관입니다. 태그는 그 습관을 강제하는 도구입니다.
배경 제공의 요령: "필요한 만큼만" 주는 법
배경을 잘 주면 모델이 올바른 방향으로 달립니다. 배경을 과하게 주면 모델이 배경을 '규칙'처럼 오해하거나, 답이 배경 설명으로 부풀어 오릅니다.
배경은 다음 네 가지 질문에만 답하면 충분한 경우가 많습니다.
독자는 누구인가(지식 수준/직무/관심사)
목표는 무엇인가(결정/설득/설명/초안 작성 등)
성공 기준은 무엇인가(정확성, 안전성, 실행 가능성, 톤 등)
금지/주의는 무엇인가(추측 금지, 특정 범위 밖은 모른다고 말하기 등)
여기서 중요한 디테일 하나가 있습니다. 같은 개념을 여러 단어로 부르지 말아야 합니다. 대화 중 같은 것을 "스프레드시트/매트릭스/탭"처럼 바꿔 부르면 모델이 혼동할 수 있으니, 핵심 용어는 한 단어로 고정하는 편이 좋습니다.4
자료 제공의 요령: "근거"를 프롬프트 안으로 끌고 오기
AI에게 "조사해서 알려줘"라고 하면, 모델은 내부 지식과 추측을 섞어 그럴듯한 답을 만듭니다. 하지만 실무에서 원하는 것은 대개 우리 문서, 우리 데이터, 우리 규정에 맞는 답입니다.
그래서 자료 제공은 다음 원칙으로 접근합니다.
첫째, 자료는 가능한 한 원문 그대로 붙입니다. 요약된 자료는 이미 누군가의 해석이 들어가며, 그 해석이 틀리면 모델도 틀립니다.
둘째, 자료는 분할합니다. '전부 붙여넣기'는 편하지만, 모델의 주의력 예산을 소모시킵니다.1 섹션별로 붙여넣고, 필요한 섹션만 보게 만드는 편이 안정적입니다.
셋째, 자료에는 신뢰 규칙을 함께 둡니다. 예를 들어 "아래 자료에 없는 내용은 '자료에 없음'이라고 답하라" 같은 규칙을 넣으면, 답이 안전해집니다.
자료 제공 템플릿(복사-붙여넣기)
<task> 아래 <docs>만 근거로 답하라. <docs>에 없는 사실은 추측하지 말고 "자료에 없음"이라고 말하라. </task>
<question> (질문) </question>
<docs>
<doc id="A" title="..."> """ (원문) """ </doc>
<doc id="B" title="..."> """ (원문) """ </doc>
</docs>
이때 <doc id> 같은 메타데이터는, 모델이 "A문서 기준/ B문서 기준"으로 근거를 구분하도록 돕습니다. 자료가 길수록 이런 표식의 효과가 커집니다.
예시 제공(few-shot): 규칙을 설명하지 말고 '정답 모양'을 보여줘라
예시는 컨텍스트 중에서도 영향력이 큽니다. 예시를 넣는 few-shot prompting은, 프롬프트 안에 몇 개의 시범(입력-출력)을 제공해서 모델이 그 패턴을 따라오게 하는 기법입니다.3 복잡한 작업일수록 "설명 10줄"보다 "예시 2개"가 잘 먹히는 경우가 많습니다.
1) 예시는 '다양하지만 정석'으로
예시를 많이 넣는다고 항상 좋아지는 것은 아닙니다. 특히 엣지 케이스를 전부 때려 넣으면 프롬프트가 비대해지고, 오히려 모델이 혼란스러워질 수 있습니다. 대신 다양한 상황을 대표하는 정석 예시(canonical examples)를 고르는 접근이 권장됩니다.1
2) 예시는 '형식'을 강하게 고정한다
few-shot의 숨은 효과는 '내용'보다 '형식'입니다. 연구/가이드에서도 예시에서 보여 준 라벨 공간(label space)과 입력 분포, 그리고 형식 자체가 성능에 중요한 신호가 된다는 점을 강조합니다.3
실무적으로는 이렇게 이해하면 쉽습니다.
"이 작업을 해"는 지시다.
"이렇게 해"는 예시다.
모델은 예시를 보고 "아, 이 모양으로 완성하는 거구나"를 배운다.
3) 예시 기반 템플릿
예를 들어 고객 문의를 '정중하지만 짧게' 답하는 패턴을 만들고 싶다면, 규칙을 길게 쓰기보다 다음처럼 예시를 줍니다.
<examples> Q: 배송이 늦어요. A: 불편을 드려 죄송합니다. 주문번호를 알려주시면 배송 상태를 즉시 확인해 드리겠습니다.
Q: 환불 가능한가요? A: 가능합니다. 결제일로부터 7일 이내라면 전액 환불되며, 주문번호를 주시면 절차를 안내해 드리겠습니다. </examples>
<now> Q: (새 문의) A: </now>
이 방식은 '톤'도 같이 전염됩니다. 따라서 예시는 원하는 말투/길이/정보량을 그대로 담아야 합니다.
용어정의: 같은 단어를 같은 뜻으로 쓰게 하라
프로젝트에서는 같은 단어가 사람마다 다르게 쓰이는 순간이 많습니다. "전환(Conversion)"이 회원가입인지 결제인지, "고객(Customer)"이 리드인지 유료 고객인지, "세션(Session)"이 GA 기준인지 앱 기준인지가 다르면 답이 흔들립니다.
용어정의는 길 필요가 없습니다. 대신 충돌을 제거해야 합니다.
용어: 정의(한 문장)
포함/제외: 경계 조건(한 줄)
예시: 대표 예시(한 줄)
또한 대화 내에서 같은 개념은 같은 단어로 반복해야 합니다. 일관된 어휘 사용이 혼동을 줄인다는 점은 실무 가이드에서도 강조됩니다.4
용어정의 섹션 예시
<glossary>
전환: '유료 결제 완료'만 의미한다. 무료 체험 신청은 전환이 아니다.
고객: 결제 완료 후 1회 이상 갱신한 계정만 의미한다.
이탈: 30일 연속 미접속이 아니라, '구독 해지'만 의미한다. </glossary>
이렇게 정의해 두면 모델은 더 이상 "전환이 뭐지?"를 추측하지 않고, 주어진 정의로 답을 구성합니다.
컨텍스트를 잘 주는 사람의 프롬프트 구조(실전 레이아웃)
여기서는 5장에서 다룬 '출력 고정'이 아니라, 입력(컨텍스트)의 관리에 초점을 둔 기본 레이아웃을 제안합니다.
<role> 너는 (역할)이다. </role>
<background> 독자/목적/제약을 3~6줄로 설명. </background>
<glossary> 용어정의(충돌 가능성이 큰 것만). </glossary>
<sources> 근거 문서/데이터. </sources>
<examples> 원하는 답변의 예시 1~3개(필요할 때만). </examples>
<task> 지금 해야 할 일(한 문단). </task>
이 레이아웃은 두 가지 장점이 있습니다. 첫째, 프롬프트가 길어져도 어디에 무엇을 넣을지 흔들리지 않습니다. 둘째, "자료가 없으면 없다"고 말하게 만들기 쉬워집니다.
흔한 실패 모드와 처방
컨텍스트 제공이 실패할 때는 대개 패턴이 같습니다.
1) 배경이 '사실 근거'로 오해된다
배경에 "우리는 업계 1위" 같은 홍보 문장이 섞이면, 모델이 이를 사실처럼 전제할 수 있습니다. 배경에는 목적과 독자, 그리고 작업 기준만 두고, '주장'은 자료 섹션으로 내리는 편이 안전합니다.
2) 자료가 너무 길어 핵심을 놓친다
컨텍스트는 유한한 주의력 예산을 소모합니다.1 길어진다면 문서를 쪼개고(섹션/문단), "이 질문엔 A의 2절과 B의 표만 참고"처럼 범위를 지정하세요.
3) 예시가 편향을 만든다
예시가 한 유형만 대표하면, 모델이 새로운 입력도 그 유형으로 끼워 맞춥니다. 예시는 2~3개만 넣더라도 서로 다른 대표 케이스로 구성하는 편이 낫습니다.1
미니 체크리스트: '근거 위에서 답하게' 만드는 7문장
아래 문장들은 상황에 맞게 골라 붙이면, 컨텍스트의 품질이 빨리 올라갑니다.
"아래 <sources>에 없는 사실은 추측하지 말고 '자료에 없음'이라고 답하라."
"<background>는 문맥 이해용이며, 사실 근거로 인용하지 마라."
"용어는 <glossary> 정의를 따른다."
"동일 개념은 동일 단어로만 부른다."4
"자료가 충돌하면, 충돌 지점을 표시하고 추가 정보가 필요하다고 말하라."
"예시는 형식과 톤을 모방하기 위한 것이다."4
"요청이 바뀌어 새 주제가 되면 새 대화에서 시작하라(컨텍스트가 섞이지 않게)."4
연습: 한 번에 끝내지 말고 '컨텍스트 먼저' 요청하기
컨텍스트를 잘 쓰는 사람은, 답부터 달라고 하지 않고 컨텍스트부터 정리합니다. 예를 들어 이렇게 시작할 수 있습니다.
지금부터 내가 줄 정보를 바탕으로만 답할 수 있도록, 먼저 아래를 질문해 줘.
빠진 배경 정보
필요한 자료(문서/데이터) 목록
용어정의가 필요한 단어
이렇게 하면 모델이 "모르는 부분을 추측으로 채우는" 대신, 무엇이 부족한지 드러내는 쪽으로 움직이기 쉽습니다.
마무리
좋은 컨텍스트는 모델을 '더 똑똑하게' 만드는 것이 아니라, 모델이 엉뚱한 방향으로 똑똑해지는 것을 막아 줍니다. 컨텍스트는 유한한 자원이고, 작은 고신호 정보 세트를 설계하는 일이 핵심입니다.1 섹션/태그로 경계를 세우고,12 근거 자료를 넣고, 예시로 패턴을 보여 주고,3 용어정의로 의미를 고정하면,4 모델이 추측할 공간이 급격히 줄어듭니다.
다음 장에서는 같은 원리로, 원하는 것과 원치 않는 것을 명시해 모델의 행동 공간을 더 좁히는 방법(Do & Don't, 제약조건)으로 넘어가겠습니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.