LLM 성능, 프롬프트가 아니라 '컨텍스트 엔지니어링'이 갈라놓는다

"토큰 더 많이 넣으면 더 똑똑해지겠지?" LLM 처음 쓸 때 대부분 한 번쯤 하는 오해입니다.

하지만 실제 프로덕션 서비스를 만들다 보면 완전히 반대라는 걸 곧 깨닫게 됩니다. 더 많이가 아니라, 더 적절하게. 양이 아니라, 구조와 위치와 시점이 성능을 결정합니다.

오늘은 AI CRM을 실제로 구축하며 얻은 인사이트를 바탕으로,

• 왜 컨텍스트 엔지니어링이 LLM 최적화의 핵심인지

• 어떤 원칙과 패턴이 효과적인지

• 반드시 피해야 할 함정은 무엇인지 를 한 번에 정리해 보겠습니다.

컨텍스트 창의 진짜 현실: 128K가 있어도 다 쓰면 망한다

요즘 LLM 스펙을 보면 "128K 컨텍스트", "200K 지원" 같은 숫자가 먼저 눈에 들어옵니다. 왠지 '문서 다 때려 넣고 질문하면 끝'일 것 같죠.

문제는 모델이 이 긴 컨텍스트를 "균일하게" 잘 보는 존재가 아니라는 데 있습니다.

실제 현상은 이렇습니다.

먼저, 중간 구간의 정보가 잘 날아갑니다. 트랜스포머 구조 특성상 컨텍스트의 맨 앞과 맨 뒤에 놓인 정보에 더 민감하게 반응하고, 가운데 부분은 상대적으로 관심이 떨어지는 경향이 있습니다. 애써 한가운데에 중요한 내용을 채워 넣으면, 모델 눈에는 흐릿한 배경 정도로 취급되기 쉽습니다.

둘째, 이론상 토큰 한도와 실제 활용 한도는 다릅니다. 스펙에 128K라고 써 있어도, 실제로는 3만~6만 토큰을 넘기는 순간부터 답변 품질이 미묘하게 떨어지는 경우가 많습니다. 사람으로 치면 "머릿속에 들어가긴 했는데, 제대로 생각하면서 쓸 수 있는 건 일부뿐"인 상태와 비슷합니다.

셋째, 길어질수록 비용과 지연 시간이 무섭게 커집니다. 컨텍스트 길이는 연산량에 거의 제곱에 가까운 영향을 주기 때문에, 1만 토큰을 10만 토큰으로 늘리면 체감 비용은 10배가 아니라 많게는 100배까지도 튈 수 있습니다.

결론은 간단합니다. "컨텍스트 창이 크다"는 건 '마구 채우라'는 초대장이 아니라, '잘 설계해서 효율적으로 쓰라'는 숙제에 가깝습니다.

많은 컨텍스트보다 '최신성'과 '관련성'이 훨씬 중요하다

실제 AI CRM을 운영하면서 가장 크게 체감한 교훈은 하나였습니다. "더 많이 넣을수록 모델이 더 잘 안다"는 생각은 완전히 틀리다는 것.

예를 들어, 특정 고객과의 거래를 이해하기 위해 지메일에서 그 고객과 주고받은 이메일을 가져온다고 해볼까요.

• 수년간의 모든 이메일을 몽땅 넣었을 때보다

• 지금 진행 중인 거래와 "의미적으로 연관된" 최근 이메일만 선별해 넣었을 때

후자가 훨씬 더 정확하고 실용적인 응답을 냅니다.

컨텍스트가 과해지면 모델은 중요한 신호와 잡음을 구분하기 힘들어집니다. 실제로 오래된 다른 거래에서 언급된 날짜를 거래 종료일로 착각하는 식의 오류도 쉽게 발생합니다.

그래서 컨텍스트 엔지니어링의 첫 번째 원칙은 이겁니다.

• "얼마나 많이 넣었나?"가 아니라

• "지금 질문과 얼마나 가깝고, 얼마나 최근 정보인가?"입니다.

LLM에게는 도서관이 아니라, 지금 이 질문에 꼭 필요한 얇은 브리핑 자료를 주는 게 훨씬 효과적입니다.

LLM은 '내용'만이 아니라 '구조'에 강하게 반응한다

LLM은 자연어를 잘 이해하는 것처럼 보이지만, 무질서한 데이터 덤프에는 의외로 약합니다.

예를 들어 이런 정보를 생각해 볼까요. "존 스미스, 35세, 뉴욕 거주, 피자를 좋아함, A회사 근무, 2020년 가입, 어제 마지막 로그인"

사람은 이 문장을 읽고도 대충 구조를 머릿속에 정리할 수 있지만, 모델 입장에서는 여러 타입의 정보가 뒤섞인 평문입니다.

반대로, 같은 내용을 XML, JSON, 마크다운 헤더처럼 구조화해서 주면 상황이 달라집니다. 이름은 어디, 나이는 어디, 가입일은 어디 있는지 모델이 훨씬 빠르게 파악합니다.

여기서 중요한 포인트는 두 가지입니다.

• "무슨 정보냐"만큼, "어떻게 담았느냐"가 중요하고

• 구조화된 표현은 토큰도 덜 쓰고, 모델의 주의도 더 잘 끌어온다는 것

프롬프트에 문단을 마구 붙여 넣는 대신, 섹션 구분, 태그, 키–값 구조 등을 활용해 주면 응답 품질이 눈에 띄게 달라집니다.

컨텍스트 배치는 전략 게임이다: 앞·뒤에 무엇을 둘 것인가

긴 컨텍스트를 쓸 수 있다면, 그 안에서 "어디에 무엇을 둘 것인지"가 성능을 좌우합니다.

앞서 말했듯 LLM은 컨텍스트의 앞과 뒤에 훨씬 더 민감하게 반응합니다. 따라서 중요한 정보는 이 두 구역을 적극적으로 활용해야 합니다.

실무적으로는 이런 흐름이 효과적입니다.

• 맨 앞에는 시스템 지시문과 현재 사용자 질문, 그리고 가장 관련성 높은 정보

• 중간에는 부가적인 설명, 참고용 자료, 덜 중요한 히스토리

• 맨 끝에는 최종 제약 조건이나 답변 형식 안내

이렇게 조직하면, 모델이 앞에서 "문맥과 목표"를 확실히 잡고, 뒤에서 "최종 제약과 형식"을 다시 한 번 상기한 상태로 답변을 생성하게 됩니다.

반대로, 긴 컨텍스트의 한가운데 어딘가에 정말 중요한 사실을 묻어 두면, 그 정보는 있는 듯 없는 듯 취급될 가능성이 꽤 높습니다.

LLM은 본질적으로 '무상태'다, 이걸 활용해야 한다

처음 챗봇을 만들면 대부분 이런 생각을 합니다. "지난 대화 전체를 계속 들고 다니게 하면 되겠지?"

하지만 LLM 호출은 설계상 무상태(stateless)입니다. 매번 "완전히 새로운 호출"로 취급하는 게 기본 전제입니다.

이걸 결함으로 볼 게 아니라, 아예 전제로 삼고 시스템을 설계하는 편이 훨씬 낫습니다.

좋은 접근은 이렇습니다.

• 전체 대화 상태는 애플리케이션이 따로 관리하고

• 그때그때 필요한 '일부'만 선별해서 모델에 넘기며

• 오래된 내용은 요약, 중요 정보는 시맨틱 청킹으로 정리하는 방식입니다.

이렇게 하면 대화가 길어져도 컨텍스트가 무한히 불어나지 않고, 필요한 정보만 뽑아 쓰는 "똑똑한 기억" 구조를 만들 수 있습니다.

시맨틱 청킹과 단계적 로딩: 컨텍스트를 잘게 나누고, 조금씩 꺼내 쓰자

실제 프로덕션에서 가장 많이 쓰이는 패턴 중 하나가 시맨틱 청킹입니다.

핵심 아이디어는 단순합니다. 문서를 통째로 붙이지 말고,

• 주제·섹션·개념 단위로 잘게 나눈 다음

• 임베딩을 활용해 질문과 가장 가까운 청크 몇 개만 골라서

• 그 조각들만 컨텍스트로 전달하는 것

이렇게 하면 컨텍스트 크기를 60~80% 줄이면서도, 오히려 답변 품질이 20~30% 좋아지는 경우가 흔합니다.

여기에 "단계적 컨텍스트 로딩"을 섞으면 더 효율적입니다. 처음에는 지시문과 질문만으로 시도해 보고, 모델이 애매한 답을 내놓으면 그때 관련 문서를 추가하고, 그래도 부족하면 예시나 엣지 케이스를 보강하는 식입니다.

한 번에 모든 걸 던져 넣는 대신, 정말 필요할 때만 조금씩 꺼내 쓰는 방식이 지연 시간과 비용 모두에서 유리합니다.

컨텍스트 압축·창 관리·캐싱: 비용과 품질을 동시에 잡는 요령

컨텍스트 엔지니어링은 결국 "같은 정보를 더 싸고 더 똑똑하게 쓰는 법"입니다. 여기에는 세 가지 축이 특히 중요합니다.

첫째, 컨텍스트 압축입니다.

• 엔티티 추출로 사람·회사·날짜·숫자 등 핵심만 남기고

• 오래된 대화는 자동 요약으로 줄이고

• 자연어 설명 대신 JSON·XML처럼 구조화해 토큰을 아낄 수 있습니다.

둘째, 컨텍스트 창을 계층으로 나누는 방식입니다. 최근 몇 턴은 그대로, 그 이전은 요약, 더 이전은 고수준 개요만 남겨두면 대화가 길어져도 전체 맥락을 잃지 않으면서 토큰 사용량을 안정적으로 유지할 수 있습니다.

셋째, 스마트 캐싱입니다. 시스템 지시문, 공통 규칙, 자주 쓰는 참조 문서처럼 바뀌지 않는 부분은 항상 프롬프트 앞쪽에 두고 캐시를 활용하면, 반복 요청의 입력 비용을 크게 줄일 수 있습니다.

이 세 가지를 잘 조합하면, "같은 품질을 훨씬 저렴하게" 혹은 "비슷한 비용으로 훨씬 더 똑똑한" 시스템을 만들 수 있습니다.

고급 패턴과 피해야 할 함정: 프로덕션에서 진짜 중요한 것들

조금 더 깊이 들어가면, 에이전트 시스템이나 복잡한 RAG에서 자주 쓰이는 패턴들이 보입니다.

다중 턴 컨텍스트 관리에서는, 턴이 쌓일수록 과거 응답을 통째로 들고 다니지 않고 일정 시점 이후에는 요약본으로 교체하는 방식이 효과적입니다. 이렇게 하면 "대화가 길어져도 절대 무너지지 않는" 안정성을 확보할 수 있습니다.

검색증강생성(RAG)에서는, 한 번의 검색으로 끝내지 않고

• 먼저 관련 문서를 고르고

• 그 안에서 섹션을 고르고

• 다시 문단을 고르는 다단계 검색이 컨텍스트 품질을 크게 끌어올려 줍니다.

또 하나 강력한 무기는 컨텍스트 인지형 프롬프트 템플릿입니다. 사용 가능한 컨텍스트 크기를 보고, 여유가 있으면 예시와 설명을 넉넉히 넣고, 빡빡하면 최소 지시문만 넣는 식으로 동적으로 템플릿을 바꾸는 전략입니다.

반대로, 프로덕션에서 특히 피해야 할 패턴도 분명합니다.

• 대화 이력을 통째로 계속 보내는 것

• 데이터베이스 내용을 필터 없이 덤프하는 것

• 모든 메시지에 같은 지시문을 반복해서 붙이는 것

• 긴 컨텍스트의 한가운데에 핵심 정보를 처박는 것

• "컨텍스트가 크니까 그냥 꽉 채우자"는 식의 설계

이 다섯 가지는 비용과 품질 모두에 치명적인 안티 패턴입니다.

컨텍스트 엔지니어링의 미래와 지금 우리가 할 수 있는 것

앞으로는 컨텍스트 자체를 다루는 기술이 더 고도화될 가능성이 큽니다.

• 사실상 무한 길이를 다루는 '무한 컨텍스트' 모델

• 본 모델에 넘기기 전에 정보를 압축·요약해 주는 전용 보조 모델

• "어떤 컨텍스트가 좋을지"를 학습으로 골라주는 선택 모델

• 텍스트뿐 아니라 이미지·오디오·구조화 데이터를 함께 다루는 멀티모달 컨텍스트

이런 흐름이 이미 시작됐습니다.

하지만 방향성은 하나로 모입니다. "컨텍스트를 많이 쓰는 시스템"이 아니라, "가장 관련성 높은 컨텍스트만 똑똑하게 쓰는 시스템"이 승리한다는 것.

지금 우리가 할 수 있는 가장 현실적인 액션은 세 가지 정도입니다.

• 현재 시스템에서 요청당 컨텍스트 크기와 응답 품질을 측정해 보고

• 시맨틱 검색·청킹·요약·구조화를 단계적으로 도입하고

• 품질 지표를 계속 보면서 컨텍스트 전략을 다듬는 것

LLM 시대의 진짜 경쟁력은 더 큰 모델이나 더 긴 컨텍스트 창이 아니라, "어떤 정보를, 어떤 구조로, 어디에 배치할지"를 설계하는 컨텍스트 엔지니어링에 있습니다.

프롬프트를 어떻게 쓸지 고민하기 전에, 모델이 보고 있는 컨텍스트를 어떻게 설계할지부터 고민해 보세요. 성능이 달라 보이기 시작할 것입니다.

출처 및 참고 : “무조건 많은 게 정답은 아니다” LLM 최적화의 핵심, 컨텍스트 엔지니어링의 기술 | ITWorld