Context Engineering

모델 실패를 보면 종종 '더 자세히 써 주면 되지 않나'라고 생각하기 쉽지만, 실제로는 잘못된 문서가 섞이거나 오래된 대화가 앞을 차지하거나 관련 없는 도구 결과가 길게 붙어서 생기는 경우가 많습니다. 정보가 많다고 항상 좋은 것이 아니고, 현재 단계에 맞는 정보가 선별되지 않으면 오히려 노이즈가 늘어납니다.

LLM 앱이 검색, 메모리, 도구 호출을 붙이기 시작하면서 프롬프트는 더 이상 한 장의 텍스트가 아니게 됐습니다. 어느 정보를 현재 호출에 포함하고, 어느 정보는 요약하거나 버릴지 정하는 로직이 품질을 크게 좌우하면서 context engineering이라는 별도 설계층이 강조됐습니다.

보통은 사용자 질문을 기준으로 후보 정보원을 모읍니다. 그다음 관련성, 최신성, 권한, 길이 같은 조건으로 걸러서 정렬하고, 필요하면 요약이나 필드 추출로 압축한 뒤 지시문과 참고 자료를 구분해 패킷으로 묶습니다. 결국 핵심은 '무엇을 더 넣을까'보다 '무엇을 지금은 빼야 하나'를 판단하는 데 있습니다.

context engineering과 context window, prompt engineering은 모두 한 호출의 품질에 관여하지만 보는 축이 다릅니다. 전체 용량이 모자라는지가 문제면 context window를 보고, 작업 지시 자체가 모호하면 prompt engineering을 보고, 어떤 기록과 문서를 이번 호출에 실을지가 문제면 context engineering을 봐야 합니다. 정보를 잘 고른다고 해서 잘못된 지시문까지 해결되지는 않는다는 점이 한계입니다.

context engineering의 가장 큰 이득은 모델이나 프롬프트를 바꾸지 않고도 현재 단계에 필요한 신호 밀도를 높일 수 있다는 점입니다. 대신 후보 수집, 순위화, 압축, 권한 필터 같은 로직이 늘어나면서 파이프라인이 복잡해지고, 잘못 설계하면 모델 문제가 아니라 선택 로직 버그를 계속 디버깅하게 됩니다. 정보원과 대화 길이가 짧은 단일 호출 앱에서는 과할 수 있지만, 검색, 메모리, 도구 결과가 겹치는 순간부터는 이 교환이 빠르게 합리적이 됩니다.

실무에서는 RAG, 장기 대화, 에이전트, 고객 지원 시스템에서 특히 중요합니다. 검색 결과를 무조건 많이 붙이기보다 질문 의도와 문서 단위를 맞추고, 도구 결과는 그대로 재주입하기보다 필요한 필드만 추려 다시 넣는 식으로 설계합니다. context engineering이 약하면 모델 성능 문제가 아니라 정보 배치 문제가 모델 문제처럼 보이기 쉽습니다.