컨텍스트 엔지니어링이 하는 일

AWS AI Practitioner 시험 가이드 v1.1이 도메인 2에 새로 넣은 목표 가운데 하나가 컨텍스트 엔지니어링입니다. 앞 편에서 모델이 읽는 것은 토큰이고 한 번에 읽을 수 있는 양은 컨텍스트 윈도우가 정한다고 했습니다. 이 편은 그 한정된 자리에 무엇을 얼마만큼, 어떤 차례로 넣을지 정하는 일을 다룹니다. 문항은 「이 에이전트의 답이 대화가 길어질수록 엉뚱해진다 — 무엇을 고쳐야 하는가」처럼 증상을 주고 원인과 처방을 고르게 하는 꼴이 많습니다.

컨텍스트 엔지니어링

정의

컨텍스트는 모델이 한 번의 호출에서 읽는 입력 전체입니다. 사람이 친 질문 한 줄만이 아니라, 앱이 앞에 붙이는 시스템 프롬프트, 지금까지의 대화 이력, 검색해 온 문서 조각, 모델이 부를 수 있는 도구의 설명이 모두 한 덩어리로 들어갑니다. 컨텍스트 엔지니어링은 이 덩어리를 매 호출마다 설계하고 관리하는 일입니다. 모델의 가중치는 호출 사이에 바뀌지 않으므로, 모델이 그 순간 아는 것은 컨텍스트에 든 것과 학습 때 익힌 것이 전부입니다.

FM 애플리케이션에서의 역할

파운데이션 모델을 쓰는 애플리케이션에서 사람은 질문만 치고, 나머지 컨텍스트는 애플리케이션 코드가 조립합니다. 챗봇이라면 이전 대화를 붙이고, RAG라면 검색 결과를 붙이고, 에이전트라면 도구 목록과 도구 실행 결과를 붙입니다. 같은 모델을 쓰는 두 서비스의 품질이 크게 다르다면, 모델이 아니라 이 조립 방식이 다른 경우가 많습니다. 시험이 「모델을 바꾸지 않고 답의 품질을 높이는 방법」을 물을 때 파인튜닝보다 앞서 고려하는 선택지가 이 자리입니다.

프롬프트 엔지니어링과의 경계

다루는 범위

프롬프트 엔지니어링은 모델에 줄 지시문 자체를 잘 쓰는 일입니다. 역할을 정해 주고, 예시를 넣고, 출력 형식을 못 박는 기법이 여기 속하고, 뒤의 프롬프트 엔지니어링 편에서 자세히 다룹니다. 컨텍스트 엔지니어링은 그 지시문을 포함하는 더 넓은 일입니다. 지시문 옆에 무엇을 함께 넣을지, 대화 이력을 어디까지 남길지, 검색 결과를 몇 개 붙일지가 전부 컨텍스트 엔지니어링의 결정입니다.

경계를 가르는 신호

문항에서 「지시문의 말투를 바꾼다」·「예시 세 개를 넣는다」가 답이면 프롬프트 엔지니어링이고, 「최근 대화 다섯 턴만 남기고 나머지는 요약해 붙인다」·「관련 문서 셋만 골라 넣는다」가 답이면 컨텍스트 엔지니어링입니다. 동사가 신호입니다. 쓰는 일이면 앞쪽, 고르고 덜어 내는 일이면 뒤쪽입니다.

컨텍스트 윈도우 예산

차지하는 몫

컨텍스트 윈도우는 입력과 출력이 함께 쓰는 한정된 예산입니다. 그 안을 채우는 것은 대개 다섯입니다.

• 시스템 프롬프트: 호출마다 똑같이 붙는다
• 도구 정의: 도구마다 이름·설명·입력 형식이 붙어 도구가 늘수록 커진다
• 대화 이력: 턴이 쌓일수록 계속 커진다
• 검색 결과: 붙이는 청크 수에 비례한다
• 출력 자리: 모델이 답을 쓸 몫을 남겨 둬야 한다

앞 넷은 호출할 때마다 입력 토큰으로 과금되므로, 예산은 한도의 문제이면서 비용의 문제입니다.

예산 계산

윈도우가 32,000토큰인 모델로 에이전트를 만든다고 합시다. 시스템 프롬프트 1,500토큰, 도구 12개가 각 400토큰, 대화 이력 9,000토큰, 검색 청크 5개가 각 1,200토큰이고, 답을 위해 4,000토큰을 남겨 둡니다.

남은 여유는 6,700토큰입니다. 대화가 한 턴에 평균 1,500토큰씩 쌓인다면 다섯 턴이 안 되어 한도에 닿습니다. 처방은 한도에 닿은 뒤가 아니라 닿기 전에 무엇을 덜어 낼지 정해 두는 것입니다. 이 경우 가장 빨리 자라는 몫이 대화 이력이므로 그쪽에 상한을 둡니다.

긴 컨텍스트의 정확도

가운데의 정보

윈도우가 넉넉해도 많이 넣을수록 좋아지지는 않습니다. 긴 입력에서 모델은 앞부분과 끝부분의 정보는 잘 쓰지만 가운데에 놓인 정보를 놓치는 경향이 관찰되어 있습니다. 긴 컨텍스트 한가운데 정답 문서를 두면 같은 문서를 맨 앞에 둘 때보다 정답률이 떨어진다는 연구가 있고, 이 현상을 흔히 「가운데서 길을 잃는다」(lost in the middle)고 부릅니다.

방해 정보

두 번째 원인은 관련 없는 내용입니다. 질문과 비슷해 보이지만 답이 아닌 청크, 이미 끝난 옛 주제의 대화, 이번 일에 쓰지 않을 도구 설명이 섞이면 모델이 그쪽을 근거로 삼아 틀린 답을 씁니다. 오래된 정책 문서와 새 정책 문서를 함께 넣으면 옛 규정으로 답하는 식입니다. 그래서 시험에서 「검색 결과를 20개로 늘린다」·「전체 대화를 항상 다 넣는다」는 정확도를 높이는 방법으로 나오면 오답입니다. 긴 컨텍스트는 비용과 지연을 늘리면서 정확도는 오히려 깎을 수 있습니다.

비용과 지연

컨텍스트가 길면 값이 두 군데서 오릅니다. 첫째는 앞 편의 토큰 단위 과금이라, 입력 토큰이 두 배면 입력 비용도 두 배입니다. 에이전트는 한 작업에 모델을 여러 번 부르고 부를 때마다 도구 정의와 이력을 다시 싣기 때문에, 한 번 늘린 몫이 호출 횟수만큼 곱해집니다. 둘째는 첫 토큰이 나오기까지의 지연입니다. 모델은 답을 쓰기 전에 입력 전체를 먼저 읽어야 하므로 입력이 길수록 사용자가 기다리는 시간이 늘어납니다. 그래서 컨텍스트를 줄이는 일은 정확도·비용·지연 셋을 한꺼번에 움직이는 드문 조치입니다.

컨텍스트를 줄이는 방법

요약

오래된 대화 이력을 그대로 두지 않고 요약문 하나로 바꿔 붙입니다. 최근 몇 턴은 원문으로 남기고 그 앞은 요약하는 방식이 흔합니다. 요약에는 결정된 사항·사용자의 선호처럼 뒤에서 다시 필요할 것을 남깁니다. 에이전트가 세션을 넘어 기억해야 할 내용은 매번 이력을 늘리는 대신 Amazon Bedrock AgentCore Memory 같은 메모리 저장소에 두었다가 필요한 것만 꺼내 넣습니다.

def build_messages(history, summary, keep_turns=4):
    """최근 keep_turns턴은 원문으로, 그 앞은 요약 한 덩어리로 넣는다."""
    recent = history[-keep_turns * 2:]  # 한 턴 = 사용자 + 모델 메시지 둘
    messages = []
    if summary:
        messages.append({"role": "user", "content": [{"text": f"지난 대화 요약: {summary}"}]})
        messages.append({"role": "assistant", "content": [{"text": "요약을 확인했습니다."}]})
    return messages + recent

Bedrock의 Converse API는 메시지가 사용자와 모델 차례로 번갈아 오기를 요구하므로 요약도 한 쌍으로 넣었습니다.

선별

넣을 후보를 질문에 맞는 것만 골라 넣습니다. 검색 결과는 유사도 상위 몇 개만 붙이고, Bedrock Knowledge Bases의 재순위화(reranking)로 한 번 더 추립니다. 도구도 이번 작업에 필요한 것만 노출합니다. 도구 12개를 늘 싣던 앞 절의 예에서 이번 일에 쓰는 셋만 싣는다면 4,800토큰이 1,200토큰으로 줄어 3,600토큰이 비어납니다.

순서 조정

앞의 「가운데의 정보」 현상 때문에 가장 중요한 것을 앞이나 끝에 둡니다. 지켜야 할 지시는 시스템 프롬프트 첫머리에, 이번 질문은 맨 끝에, 가장 관련 높은 청크는 질문 가까이에 둡니다. 순서는 토큰을 한 개도 줄이지 않으면서 정확도를 올리는 방법이라, 「비용을 늘리지 않고」라는 조건이 붙은 문항에서 자주 정답이 됩니다.

같은 머리말을 매번 보내는 비용 자체를 줄이는 장치로 프롬프트 캐싱이 있습니다. 컨텍스트의 양은 그대로 두고 반복되는 앞부분의 처리를 재사용하는 것이라 줄이는 방법과는 갈래가 다르고, 추론 파라미터 편에서 따로 다룹니다.

연습 문제

1. 고객 상담 에이전트가 대화 초반에는 정확하다가 30턴을 넘기면 옛 주제를 끌어와 엉뚱하게 답합니다. 가장 알맞은 처방은?
   ① 출력 최대 토큰을 늘린다
   ② 오래된 이력은 요약해 넣고 최근 몇 턴만 원문으로 둔다
   ③ 매번 전체 대화 이력을 빠짐없이 넣는다
   ④ temperature를 높인다

   ②. 이력이 쌓이며 관련 없는 옛 내용이 컨텍스트를 채운 것이 원인입니다. ③은 증상을 키우고, ①과 ④는 입력에 무엇이 들어가는지를 바꾸지 않습니다.
2. 윈도우가 16,000토큰인 모델에 시스템 프롬프트 1,200토큰, 도구 8개(각 300토큰), 검색 청크 4개(각 1,500토큰)를 넣고 출력용으로 2,000토큰을 남깁니다. 대화 이력에 쓸 수 있는 토큰은 최대 몇 개입니까?
   ① 2,400
   ② 4,400
   ③ 6,400
   ④ 8,800

   ②. 고정 몫이 $1{,}200 + 8 \times 300 + 4 \times 1{,}500 + 2{,}000 = 11{,}600$ 이므로 $16{,}000 - 11{,}600 = 4{,}400$ 입니다. ③은 출력 자리를 빼는 것을 잊은 값입니다.
3. 다음 중 컨텍스트 엔지니어링에 해당하는 조치를 둘 고르시오.
   ① 지시문의 말투를 공손하게 고친다
   ② 이번 작업에 쓰는 도구만 골라 도구 정의를 싣는다
   ③ 검색 결과를 재순위화해 상위 셋만 넣는다
   ④ 모델을 더 큰 파라미터 모델로 바꾼다
   ⑤ 출력 예시 두 개를 지시문에 넣는다

   ②와 ③. 둘 다 무엇을 컨텍스트에 넣을지 고르는 일입니다. ①과 ⑤는 지시문을 쓰는 프롬프트 엔지니어링이고, ④는 모델 선택입니다.
4. 정답 문서가 검색 결과 열 개 가운데 여섯 번째에 들어 있는데 모델이 그 내용을 쓰지 않습니다. 토큰 수를 늘리지 않고 먼저 시도할 조치는?
   ① 검색 결과를 스무 개로 늘린다
   ② 가장 관련 높은 문서를 질문 바로 앞에 오도록 순서를 바꾼다
   ③ 임베딩 차원을 두 배로 올린다
   ④ 대화 이력을 전부 붙인다

   ②. 긴 입력의 가운데 정보를 놓치는 현상에 대한 처방이 순서 조정입니다. ①과 ④는 토큰을 늘리고 방해 정보도 함께 늘립니다.
5. 컨텍스트 윈도우 예산이 모자랄 때 대응을 순서대로 배열하시오.
   (가) 호출마다 무엇이 몇 토큰을 차지하는지 센다
   (나) 가장 빨리 자라는 몫을 찾는다
   (다) 그 몫에 요약이나 선별로 상한을 둔다
   (라) 줄인 뒤 같은 질문으로 답의 정확도를 다시 확인한다

   (가) → (나) → (다) → (라). 재지 않고 줄이면 엉뚱한 몫을 깎게 되고, 줄인 뒤 확인하지 않으면 필요한 사실까지 덜어 냈는지 알 수 없습니다.
6. 여러 도구를 가진 에이전트의 입력 토큰이 대부분 도구 정의에서 나오고 있습니다. 비용을 줄이면서 정확도도 지키는 방법은?
   ① 도구 설명을 한 단어로 줄인다
   ② 작업 종류에 따라 필요한 도구만 골라 싣는다
   ③ 도구를 전부 없앤다
   ④ 모든 도구 정의를 대화 이력 가운데로 옮긴다

   ②. 선별입니다. ①은 모델이 도구를 언제 써야 하는지 알 수 없게 만들어 정확도를 깎고, ③은 작업 자체를 못 하게 합니다.

여섯 문항이 겨누는 것은 셋입니다. 쓰는 일과 고르는 일의 경계, 예산을 토큰으로 계산하는 것, 그리고 많이 넣을수록 좋다는 직관이 틀리는 자리입니다. 보기 가운데 무엇이든 「늘린다」로 끝나는 것은 한 번 의심하고 보면 됩니다.