안녕하세요, 저는 Maneshwar입니다. 저는 모든 커밋에서 실행되는 마이크로 AI 코드 리뷰어인 git-lrc를 만들고 있습니다. 이 프로젝트는 무료이며 Github에서 소스 코드를 확인할 수 있습니다. 개발자들이 이 프로젝트를 발견하는 데 도움이 되도록 git-lrc 스타하기를 눌러주세요. 한번 사용해 보시고 피드백을 공유해 주시면 감사하겠습니다.

시리즈의 1부입니다. 이 글은 컨텍스트 엔지니어링의 지도를 보여줍니다. 다음 포스팅들이 실제 영역이 될 것입니다.

개발자라면 누구나 LLM(대규모 언어 모델)을 사용하면서 한 번쯤 겪는 순간이 있습니다.

완벽한 프롬프트를 작성합니다. 명확한 지침, 멋진 페르소나. 어쩌면 '단계별로 생각하기(think step by step)' 같은 것을 양념처럼 뿌리기도 합니다. 그런데 모델은... 거의 맞지만 자신감 있게 틀린 답을 내놓습니다.

그래서 단어를 수정하고, 또 다른 단어를 수정합니다. 분명 효과가 있을 거라고 생각해서

**컨텍스트 엔지니어링 (Context engineering)**은 모델이 답변할 때 볼 수 있는 모든 것에 관한 것입니다. 지시 사항 (instruction)은 물론이고, 검색된 문서 (retrieved documents), 대화 기록 (conversation history), 도구 출력값 (tool outputs), 사용자의 선호도 (user's preferences), API 스키마 (API schema), 지난 시도의 에러 메시지, 데이터베이스의 관련 행 (relevant rows) 등이 모두 포함됩니다. 즉, 질문을 중심으로 당신이 구성하는 정보 환경 전체를 의미합니다.

제가 이 개념을 마침내 이해하게 된 비유는 다음과 같습니다:

프롬프트 엔지니어링 (Prompt engineering)이 좋은 질문을 던지는 것이라면,
컨텍스트 엔지니어링 (Context engineering)은 질문을 받는 사람이 실제로 질문과 관련된 파일들을 눈앞에 펼쳐놓고 있는지 확인하는 것입니다.

빈 책상을 바라보고 있는 사람에게 아주 훌륭한 질문을 던져도 엉뚱한 답을 얻을 수 있습니다. 반대로, 정확히 필요한 문서 세 개를 펼쳐놓고 있는 사람에게 평범한 질문을 던지면 금광 같은 답을 얻을 수도 있습니다.

모델의 지능은 추론 (inference) 시점에 당신이 건네주는 컨텍스트 (context)만큼만 발휘됩니다.

그리고 한 가지 냉혹한 제약 조건 때문에 이 점은 그 어느 때보다 중요합니다:

컨텍스트 윈도우 (Context window)는 하드 드라이브가 아니라 RAM입니다

모델의 컨텍스트 윈도우(200K, 1M, 혹은 그 어떤 K 토큰이든 간에)는 저장 공간이 아닙니다.

그것은 작업 기억 장치 (working memory)입니다.

파일 캐비닛이 아니라 책상입니다.

모델이 그 순간에 "알고 있는" 모든 것은 그 책상 위에 올라가 있어야 하며, 책상에는 명확한 경계가 있습니다.

컨텍스트 엔지니어링은 본질적으로, 무엇을, 언제, 어떤 형태로 책상 위에 올릴지 결정하는 기술입니다.

너무 적으면 모델은 추측을 합니다.

너무 많으면 모델은 주의가 산만해지고, 느려지며, 비용이 많이 들고, 중간 내용을 이상하게 잊어버리는 현상(두려운 "lost in the middle" 효과)이 발생합니다.

그렇다면 어떻게 책상을 잘 관리할 수 있을까요? 다섯 가지 기둥이 있습니다. 하나씩 살펴보겠습니다.

기둥 1: 외부 메모리 (External Memory)

LLM은 금붕어 문제를 가지고 있습니다.

기본적으로 모델은 두 가지만 알고 있습니다: 학습 (training) 과정에서 가중치 (weights)에 구워진(baked) 내용, 그리고 현재 컨텍스트 윈도우 (context window)에 당신이 넣은 내용입니다.

대화가 끝나자마자, 대부분의 경우 두 번째 정보는 사라집니다.

이때 우리가 '죽음'을 속이는 방법이 바로 **외부 메모리(External memory)**입니다. 모델이 필요로 할 수 있는 모든 것을 매개변수(parameters)에 집어넣거나(불가능함), 단일 프롬프트에 넣는 대신(비용이 많이 들고 한계가 있음), 우리는 정보를 모델 밖에 보관합니다. 즉, 데이터베이스, 벡터 스토어(vector stores), 지식 그래프(knowledge graphs), 일반 파일 등에 저장하고 필요할 때 관련 조각들만 다시 불러오는 것입니다.

이것을 마치 모델에게 우주를 암기하라고 요구하는 대신, 언제든 펼쳐볼 수 있는 공책을 주는 것이라고 생각해보세요.

[ 모델 가중치 (Model weights) ] → 학습 과정에서 배운 내용 (고정적, 일반적)
[ 컨텍스트 윈도우 (Context window) ] → 현재 볼 수 있는 것 (작음, 비쌈)
[ 외부 메모리 (External memory) ] → 나머지 모든 것 (거대함, 저렴함, 필요할 때 검색 가능)

이것이 다음 기둥(pillar)을 가능하게 만드는 기반입니다. 왜냐하면 지식이 모델 밖에 존재하게 되면, 당연히 떠오르는 질문은 이것이 됩니다: 어떻게 그 정보의 올바른 조각들을 다시 가져올 수 있을까?

기둥 2: RAG와 동적 필터 (Dynamic Filters)

**검색 증강 생성(Retrieval-Augmented Generation, RAG)**은 현대 LLM 애플리케이션의 핵심 엔진입니다.

원리는 간단합니다. 모델이 답변하기 전에, 외부 메모리에서 관련성 높고 최신이며 사실적인 정보를 가져와 컨텍스트에 넣어주는 것입니다.

이제 모델은 2년 전 인터넷에 대한 흐릿한 반쯤 기억 대신, 사용자의 데이터로 답변하게 됩니다.

만약 최근 LLM을 이용해 무언가를 구축했다면, 비록 그렇게 부르지 않았더라도 RAG를 수행했을 가능성이 높습니다.

사용자가 질문 → 이를 임베딩(embed) → 벡터 DB에서 검색 → 상위 결과를 프롬프트에 삽입 → 모델이 답변합니다. 완벽하죠.

하지만 순진한 RAG에는 지저분한 비밀이 있습니다: 유용한 것이 아니라, 비슷한 것을 가져온다는 것입니다.

벡터 유사성(Vector similarity)은 사용자가 청구서(billing) 버그에 대해 질문했을 때도

상위 k개의 매치(top-k matches)를 맹목적으로 쏟아붓는 대신, 실제 상황에 기반하여 검색 결과(retrieval)를 필터링해야 합니다.

누가 질문하는가? 사용자, 테넌트(tenant), 권한에 따라 필터링합니다. (다른 고객의 데이터를 컨텍스트(context)로 가져오는 것은 기능이 아니라 사고(incident)입니다.)
언제 적용되는가? 최신성(recency), 버전, 환경에 따라 필터링합니다.
의도가 무엇인가? "어떻게 하나요"라는 질문은 문서(docs)로, "왜 고장 났나요"라는 질문은 로그(logs)로 라우팅(route)합니다.

Pillar 3: 컨텍스트 압축 (Context Compaction)

이제 외부 메모리(external memory)와 스마트한 검색(smart retrieval)을 갖추었습니다. 축하합니다. 이제 그 어느 때보다 빠르게 컨텍스트 창(context window)을 가득 채울 수 있게 되었습니다.

그것이 새로운 문제입니다. 긴 컨텍스트(long contexts)는 느리고, 비용이 많이 들며, 직관과는 반대로 종종 더 나쁩니다.

모델은 거대한 덩어리 중간에 파묻힌 세부 사항을 놓칩니다.

모든 불필요한 토큰(redundant token)은 중요한 정보를 주의(attention)의 가장자리로 밀어내는 토큰입니다.

**컨텍스트 압축 (Context compaction)**은 중요한 것을 잃지 않으면서 전송하는 양을 줄이는 규율입니다.

이는 의미를 위한 손실 압축(lossy compression)입니다.

몇 가지 방식은 다음과 같습니다:

요약 (Summarization): 40개의 메시지로 이루어진 대화를 실제로 결정되었고 관련이 있는 내용의 간결한 요약본으로 대체합니다.
필터링 / 가지치기 (Filtering / pruning): 제 역할을 하지 못하는 청크(chunks), 턴(turns), 또는 도구 출력(tool outputs)을 제거합니다.
재순위화 (Re-ranking): 검색된 결과의 순서를 재조정하여 진정으로 가장 관련 있는 자료가 모델이 가장 집중하는 위치에 놓이도록 합니다.

구체적인 예: 긴 에이전트(agent) 실행 과정에서 모든 개별 도구 호출(tool call)과 그 전체 원시 출력(raw output)을 영원히 유지하지는 않습니다.

압축을 해야 합니다. "DB를 검색하여 사용자의 테이블이 documents_v2임을 확인했습니다"는 유지할 가치가 있습니다.

그것이 나온 400줄의 JSON은요? 요약하고 버리십시오. (documents_v2라는 생각은 잠시 간직하세요. 나중에 다시 등장할 이유가 있습니다.)

만트라(mantra): 최고의 토큰은 보내지 않아도 되었던 토큰입니다. 압축은 실제로 성과를 내는 핵심 요소들을 위해 책상 공간을 확보하는 방법입니다.

Pillar 4: 컨텍스트 격리 (Context Isolation)

여기 모든 사람이 결국 발견하게 되는 실패 모드(failure mode)가 있습니다.

당신은 모든 것을 수행하는 하나의 메가 프롬프트 에이전트 (mega-prompt agent)를 만듭니다. 고객 지원 질문에 답하고, 코드를 작성하며, 데이터베이스를 쿼리하고, 이메일 초안을 작성하며, 심지어 당신의 화분에 물을 주기까지 합니다. 그리고 그 에이전트는 이 모든 일에서 어중간한 성능을 보입니다.

왜 그럴까요? 다섯 가지 업무 분량의 지침 (instructions), 도구 (tools), 그리고 컨텍스트 (context)를 하나의 창에 쑤셔 넣었기 때문에, 이들이 서로 간섭하기 때문입니다.

SQL을 작성하려는 모델이 이메일 작성 지침 때문에 주의가 산만해집니다.

관련 없는 정보가 작업 간에 스며듭니다.

이는 파티장에서 세금 신고를 하려는 것과 인지적으로 동일한 상황입니다.

**컨텍스트 격리 (Context isolation)**가 해결책입니다. 각 작업에 전용의 깨끗한 컨텍스트를 부여하십시오.

모든 것을 아는 하나의 전지전능한 에이전트 대신, 각자의 작업에 필요한 지침, 도구, 정보만을 가진 여러 개의 작고 집중된 에이전트 (또는 서브 에이전트, 혹은 단순히 별도의 호출)를 사용하십시오.

리서치 에이전트에게는 당신의 코드 스타일 가이드가 필요하지 않습니다.

코더에게는 고객에게 사과하는 문구를 어떻게 작성해야 하는지 알 필요가 없습니다.

컨텍스트를 분리함으로써 각 에이전트는 예리함을 유지하며, 한 곳의 혼란이 다른 곳을 오염시키지 않습니다.

격리는 신뢰성을 확보해 줄 뿐만 아니라, 각 개별 창을 실제로 성능을 발휘할 수 있을 만큼 충분히 작게 유지해 줍니다.

책상을 다시 정리하기

한 걸음 물러나 이 다섯 가지 기둥 (pillars)을 살펴보면, 이들이 모두 서로 다른 모자를 쓰고 있는 동일한 아이디어라는 것을 알게 될 것입니다.

기둥	답변하는 질문
외부 메모리 (External memory)	지식이 창(window) 안에 없을 때 어디에 존재하는가?
...

이들 각각은 그 희소하고 소중한 책상, 즉 컨텍스트 창 (context window)을 관리하는 방법입니다. 이를 통해 모델이 정확히 필요한 것만 보고, 필요 없는 것은 보지 않게 합니다.

이것이 바로 컨텍스트 엔지니어링 (context engineering)입니다. 모델에게 대문자로 애원하는 것이 아닙니다.

그저 정보에 대한 의도적이고, 거의 지루할 정도의 결정들입니다. 무엇을 포함할지, 무엇을 제외할지, 어디에 저장할지, 그리고 언제 다시 가져올지에 대한 결정 말입니다.

프롬프트 (Prompt)는 질문입니다. 컨텍스트 (Context)는 답변을 훌륭하게 만드는 모든 것입니다.

AI 에이전트 (AI agents)는 코드를 빠르게 작성합니다. 하지만 사용자에게 알리지도 않은 채 조용히 로직을 제거하고, 동작을 변경하며, 버그를 유발하기도 합니다. 이러한 문제는 종종 프로덕션 (production) 환경에서 발견되곤 합니다.

git-lrc가 이를 해결합니다. 이 도구는 git 커밋 (git commit)에 후킹하여, 변경 사항이 반영되기 전에 모든 디프 (diff)를 검토합니다. 설정은 60초면 충분하며, 완전히 무료입니다.

모든 피드백과 기여자를 환영합니다! 이 프로젝트는 온라인에 공개되어 있으며, 소스 사용이 가능 (source-available)하여 누구나 사용할 준비가 되어 있습니다.

⭐ GitHub에서 별 (Star)을 눌러주세요:

HexmosTech / git-lrc

커밋 시 실행되는 무료 마이크로 AI 코드 리뷰 (Micro AI Code Reviews)

모델에게 속삭이는 대신, 모델의 지식을 채우는 법

요약

핵심 포인트