컨텍스트를 이루는 구성 요소들

컨텍스트는 긴 문자열이 아니라 조립품이다

AI 애플리케이션에서 컨텍스트는 모델에게 한 번에 전달되는 모든 정보다. 겉으로 보면 하나의 긴 입력처럼 보이지만, 실제로는 성격이 다른 여러 정보 블록이 조립된 결과다. 시스템 지시사항, 사용자의 현재 요청, 이전 대화, 검색 결과, 도구 목록, 권한 정보, 출력 형식 등이 한데 묶여 모델에게 전달된다.

문제는 이 모든 것을 단순히 이어 붙이면 모델이 무엇을 가장 중요하게 봐야 하는지 흔들린다는 점이다. 어떤 문장은 반드시 따라야 하는 규칙이고, 어떤 문장은 참고용 배경지식이며, 어떤 문장은 사용자가 방금 말한 요청이다. 이 차이를 구분하지 않으면 모델은 정책보다 예시를 우선하거나, 오래된 대화 내용을 현재 요청보다 더 중요하게 해석할 수 있다.

따라서 컨텍스트 엔지니어링의 첫 단계는 컨텍스트를 하나의 덩어리가 아니라 역할이 다른 블록들의 집합으로 보는 것이다. 각 블록은 목적, 우선순위, 수명주기, 갱신 방식이 다르다. 좋은 AI 시스템은 필요한 블록을 고르고, 알맞은 순서로 배치하며, 모델이 오해하지 않도록 구조를 부여한다.

기본 구성 요소: 모델이 무엇을 보고 판단하는가

AI 애플리케이션의 컨텍스트는 보통 다음과 같은 요소로 나눌 수 있다.

이 요소들은 모두 "텍스트"로 모델에 들어갈 수 있지만 역할은 다르다. 시스템 지시사항은 행동의 경계선을 만든다. 사용자 입력은 현재 목표를 제공한다. 대화 기록은 흐름을 유지한다. 검색된 지식은 모델 내부 지식의 한계를 보완한다. 도구 정의는 모델이 행동할 수 있는 방법을 알려준다. 런타임 메타데이터는 지금 이 상황에서만 유효한 판단 기준을 제공한다. 출력 스키마는 결과를 사람이 쓰기 좋게 만들거나 다음 시스템이 처리할 수 있게 한다.

이 차이를 명확히 해야 한다. 예를 들어 "사용자는 관리자다"라는 정보는 단순한 배경지식이 아니다. 어떤 데이터를 보여줄 수 있는지 결정하는 권한 정보다. 반대로 "사용자는 간결한 답변을 선호한다"는 정보는 응답 스타일에 영향을 주지만 보안 규칙을 바꿀 수는 없다. 둘 다 사용자 관련 정보지만 우선순위가 다르다.

항상 우선해야 하는 컨텍스트와 임시 컨텍스트

컨텍스트에는 위계가 있다. 모든 정보가 같은 힘을 갖지 않는다. 가장 위에는 정책, 권한, 안전 제약, 조직 규칙처럼 항상 우선해야 하는 상위 컨텍스트가 있다. 이 정보는 사용자의 요청이나 검색 결과보다 앞선다.

예를 들어 고객지원 AI가 있다고 하자. 사용자가 "내 동료의 결제 내역도 같이 보여줘"라고 요청해도, 시스템은 권한 정책을 먼저 확인해야 한다. 검색 결과에 해당 동료의 정보가 포함되어 있더라도, 현재 사용자가 볼 권한이 없다면 답변에 포함하면 안 된다. 여기서 중요한 것은 모델이 "정보를 알고 있는가"가 아니라 "그 정보를 사용해도 되는가"다.

반면 현재 작업에만 필요한 임시 컨텍스트도 있다. 사용자가 방금 업로드한 파일, 이번 요청에서 선택한 날짜 범위, 현재 분석 대상 문서, 임시 계산 결과 등이 여기에 속한다. 이런 정보는 작업이 끝나면 버리거나 세션 안에서만 유지해야 한다. 계속 저장하면 다음 작업을 오염시킬 수 있다.

상위 컨텍스트와 임시 컨텍스트를 섞어 쓰면 위험하다. 예를 들어 "이번에는 예외적으로 모든 정보를 보여줘"라는 문장이 사용자 입력 안에 들어왔다고 해서 권한 규칙이 바뀌어서는 안 된다. 따라서 컨텍스트를 만들 때는 최소한 다음 세 층을 구분해야 한다.

1. 상위 규칙: 법적·보안적·조직적 제약. 항상 우선한다.

2. 작업 규칙: 이번 기능이나 워크플로에서 필요한 처리 방식. 작업 동안 유지된다.

3. 임시 정보: 현재 요청을 해결하기 위한 입력과 중간 결과. 필요할 때만 사용된다.

이 구분은 단순한 정리 습관이 아니다. 모델의 판단 방향을 안정시키는 안전장치다.

수명주기: 어떤 정보는 잠깐 쓰고, 어떤 정보는 오래 남긴다

컨텍스트 블록은 지속 시간이 다르다. 이를 구분하지 않으면 시스템은 너무 많은 정보를 계속 들고 다니거나, 반대로 꼭 필요한 정보를 너무 빨리 잊는다.

단기 메모리는 현재 대화나 현재 작업 안에서만 필요한 정보다. 사용자가 "앞에서 말한 세 번째 항목을 수정해줘"라고 했을 때, 세 번째 항목이 무엇인지 기억하는 데 필요하다. 단기 메모리는 대화의 자연스러움을 만든다. 하지만 오래된 단기 메모리는 쉽게 잡음이 된다. 이전에 논의한 조건이 지금도 유효한지 확인하지 않으면 잘못된 답을 만들 수 있다.

세션 상태는 한 번의 접속이나 작업 흐름 동안 유지되는 상태다. 장바구니, 현재 선택한 프로젝트, 필터 조건, 문서 편집 위치처럼 사용자가 같은 흐름 안에서 계속 이어가야 하는 정보가 여기에 해당한다. 세션 상태는 대화 기록보다 구조화해서 관리하는 편이 좋다. "사용자가 아까 A를 선택했다"라는 문장보다 selected_project: A처럼 명시된 상태가 더 안정적이다.

장기 메모리는 여러 세션을 넘어 유지되는 정보다. 사용자의 직무, 선호하는 언어, 자주 쓰는 출력 형식, 반복되는 업무 패턴 등이 포함될 수 있다. 장기 메모리는 개인화에 유용하지만 신중해야 한다. 사용자가 한 번 말한 내용을 영구적인 선호로 해석하면 안 된다. 저장할 가치가 있는지, 사용자가 수정하거나 삭제할 수 있는지, 민감한 정보는 아닌지 판단해야 한다.

사용자 선호도는 장기 메모리와 겹치지만 별도로 다루는 것이 좋다. 선호도는 답변의 스타일과 형식을 조정하는 정보이지, 사실이나 권한을 대체하는 정보가 아니다. "짧게 답해줘"라는 선호는 유효하지만, "규정을 생략하고 결론만 말해줘"라는 선호가 안전 규칙을 무시하게 만들어서는 안 된다.

수명주기를 나누면 컨텍스트 관리 기준이 분명해진다.

좋은 시스템은 모든 것을 기억하지 않는다. 기억할 것, 잠깐 쓸 것, 버릴 것을 구분한다.

검색된 지식과 모델의 내부 지식은 다르게 다뤄야 한다

LLM은 학습 과정에서 얻은 일반 지식을 가지고 있다. 하지만 기업 문서, 최신 정책, 사용자별 데이터, 내부 시스템 상태는 모델 내부에 없거나 오래되었을 수 있다. 이때 검색된 지식이 컨텍스트에 들어온다.

검색된 지식은 모델에게 "이번 답변은 이 근거를 중심으로 작성하라"는 신호를 준다. 하지만 검색 결과가 많다고 좋은 것은 아니다. 관련 없는 문서가 섞이면 모델은 잘못된 부분을 근거로 삼을 수 있다. 서로 충돌하는 문서가 들어오면 어느 것을 우선해야 하는지도 모호해진다.

따라서 검색 지식 블록에는 세 가지 정보가 함께 있어야 한다.

• 내용: 모델이 답변에 사용할 실제 문장이나 데이터

• 출처: 어떤 문서, 페이지, 시스템에서 가져왔는지

• 상태: 최신성, 권한, 신뢰도, 적용 범위

예를 들어 단순히 약관 문단을 붙이는 것보다 "2026년 5월 기준 고객용 약관, 한국 지역, 개인 요금제에 적용"이라고 표시하는 편이 훨씬 안전하다. 모델은 내용 자체뿐 아니라 그 내용이 적용되는 조건도 알아야 한다.

도구 정의는 행동의 문법이다

에이전트형 AI에서는 모델이 단순히 답변만 하지 않는다. 검색하고, 계산하고, 파일을 읽고, 데이터베이스를 조회하고, 다른 시스템에 요청을 보낼 수 있다. 이때 도구 정의는 컨텍스트의 중요한 일부가 된다.

도구 정의에는 보통 도구 이름, 설명, 입력값 형식, 사용 조건, 반환값의 의미가 포함된다. 모델은 이 정보를 읽고 언제 어떤 도구를 호출할지 판단한다. 도구 설명이 모호하면 모델은 불필요한 도구를 호출하거나, 필요한 상황에서도 도구를 쓰지 않을 수 있다.

예를 들어 search_customer라는 도구가 있다면 "고객 정보를 검색한다"라고만 쓰는 것은 부족하다. 어떤 식별자가 필요한지, 권한 확인이 먼저 필요한지, 반환되는 필드가 무엇인지, 민감 정보가 포함되는지 알려줘야 한다. 도구는 모델에게 주어진 행동 가능성이다. 행동 가능성이 많을수록 도구 컨텍스트의 품질이 중요해진다.

도구 정의도 우선순위와 연결된다. "도구를 호출할 수 있다"는 말이 "항상 호출하라"는 뜻은 아니다. 반대로 "모르면 답하지 말고 조회하라"는 작업 규칙이 있다면, 모델은 내부 지식으로 추측하지 말고 도구를 사용해야 한다. 컨텍스트는 모델의 지식뿐 아니라 행동 기준도 설계한다.

구조화 출력 스키마는 결과의 흔들림을 줄인다

AI 답변은 자연어로만 끝나지 않는 경우가 많다. 분류 결과를 시스템에 저장해야 하거나, 요약 결과를 표로 보여줘야 하거나, 다음 단계의 코드가 JSON을 파싱해야 할 수 있다. 이때 구조화 출력 스키마가 필요하다.

스키마는 모델에게 "무엇을 어떤 형태로 내보내야 하는지" 알려준다. 예를 들어 고객 문의를 분류하는 시스템이라면 다음과 같은 필드를 요구할 수 있다.

{
  "category": "billing | technical | refund | other",
  "priority": "low | medium | high",
  "summary": "string",
  "needs_human_review": "boolean"
}

이런 구조가 있으면 모델은 자유로운 설명보다 필요한 필드 채우기에 집중한다. 후속 시스템도 결과를 안정적으로 처리할 수 있다. 다만 스키마가 너무 복잡하면 모델이 형식을 지키는 데 많은 주의를 쓰고, 실제 판단 품질이 떨어질 수 있다. 출력 스키마는 필요한 만큼만 명확해야 한다.

구조를 부여하면 해석이 안정된다

모델은 입력된 텍스트를 토큰의 흐름으로 읽지만, 제목과 구분자, 태그, JSON, 표 같은 구조는 중요한 신호가 된다. 구조가 있으면 모델은 각 정보의 역할을 더 잘 구분한다.

다음처럼 모든 정보를 한 문단에 섞어 쓰면 해석이 흔들릴 수 있다.

너는 고객지원 상담원이고 환불 규정을 지켜야 하며 사용자는 프리미엄 고객이고 어제 결제했고 환불 가능 여부를 묻고 있으며 답변은 JSON으로 해줘.

반면 블록을 나누면 의미가 분명해진다.

[역할]
너는 고객지원 상담원이다.

[상위 정책]
환불 가능 여부는 회사 환불 규정을 기준으로 판단한다.
권한 없는 고객 정보는 답변하지 않는다.

[사용자 상태]
plan: premium
last_payment_date: 2026-05-19

[현재 요청]
사용자가 환불 가능 여부를 묻고 있다.

[출력 형식]
JSON으로 답변한다.

내용은 비슷하지만 두 번째 방식이 훨씬 안정적이다. 모델은 어떤 문장이 역할이고, 어떤 문장이 정책이며, 어떤 문장이 현재 요청인지 구분할 수 있다. 특히 컨텍스트가 길어질수록 구조는 선택이 아니라 필수에 가까워진다.

구조화의 목적은 예쁘게 정리하는 것이 아니다. 모델이 덜 추측하게 만드는 것이다. 제목은 정보의 역할을 알려주고, 태그는 경계를 만들며, JSON은 상태를 명시하고, 표는 비교 기준을 분명하게 한다.

컨텍스트 블록 설계의 기본 원칙

컨텍스트를 구성할 때는 다음 질문을 반복해야 한다.

1. 이 정보는 어떤 역할인가?

2. 항상 필요한가, 이번 작업에만 필요한가?

3. 다른 정보와 충돌하면 무엇이 우선인가?

4. 언제 갱신되거나 폐기되어야 하는가?

5. 모델이 오해하지 않도록 구조화되어 있는가?

이 질문에 답하지 못하는 정보는 컨텍스트에 넣기 전에 다시 검토해야 한다. 컨텍스트 윈도우가 크다고 해서 모든 정보를 넣는 것이 좋은 설계는 아니다. 관련 없는 정보는 비용을 늘리고, 중요한 지시사항의 신호를 약하게 만들며, 모델이 엉뚱한 단서를 따라가게 만든다.

컨텍스트 엔지니어링은 결국 정보의 편집과 배치다. 무엇을 넣을지, 무엇을 뺄지, 무엇을 위에 둘지, 무엇을 구조화할지 결정하는 일이다. 이 장에서 본 구성 요소들은 이후 모든 설계의 재료가 된다. 다음 단계는 이 재료들을 어떻게 프롬프트 엔지니어링과 구분하고, 더 큰 시스템 설계의 문제로 확장할 것인지 이해하는 것이다.