챗봇이 어제 한 말을 또 잊어버리는 이유 - 컨텍스트 엔지니어링

원문 출처 "How to Master Context Engineering" — Digital Bricks https://www.digitalbricks.ai/blog-posts/how-to-master-context-engineering

한국어 독자를 위해 다듬어 옮겼습니다.

프롬프트만 잘 쓰면 다 될 줄 알았습니다. 그런데 어느 순간부터 챗봇의 대답이 이상해집니다. 5분 전에 분명히 알려준 내용을 잊어버리고, 코딩 어시스턴트는 우리 프로젝트 구조를 자꾸 놓치고, RAG로 만든 사내 봇은 문서 두 개를 한꺼번에 참고하지 못합니다.

이게 "프롬프트가 부실해서"가 아니라는 게 핵심입니다. AI 앱이 복잡해질수록 한 줄짜리 프롬프트는 빙산의 일각이 됩니다. 진짜 핵심은 그 모델이 무엇을 보는지, 무엇을 기억하는지를 시스템 차원에서 설계하는 데에 있습니다. 컨텍스트 엔지니어링이 바로 그 얘기입니다.

이 글에서는 컨텍스트 엔지니어링이 뭔지, 프롬프트 엔지니어링과 어떻게 다른지, 실전에선 어떤 모양으로 등장하는지(RAG·에이전트·코딩 어시스턴트), 그리고 무엇보다 컨텍스트가 망가지는 4가지 대표 패턴과 그 대응법을 같이 살펴봅니다.

컨텍스트 엔지니어링이란

한마디로 정리하면 "모델이 답을 만들기 전에 무엇을 보여줄지를 시스템 차원에서 설계하는 일" 입니다. 프롬프트 한 줄을 다듬는 게 아니라, 모델 주변에 살아있는 정보 생태계 같은 걸 만드는 것입니다.

여기서 말하는 컨텍스트는 생각보다 훨씬 넓습니다. 사용자가 방금 던진 질문만 컨텍스트가 아닙니다. 모델이 답을 만들기 직전까지 받은 모든 게 다 컨텍스트입니다.

• 시스템 지시문: "너는 친절한 고객지원 담당자야" 같은 역할·규칙 세팅

• 현재 질문 + 대화 기록: 5분 전에 무슨 얘기를 했는지

• 장기 메모리·사용자 취향: 이 사람이 평소 어떤 말투를 좋아하는지

• 외부에서 가져온 자료: 사내 위키, 정책 문서, DB 검색 결과

• 쓸 수 있는 도구 목록: "캘린더 확인", "메일 보내기" 등 도구들

• 출력 형식 틀: JSON 스키마, 메일 템플릿 같은 정해진 구조

• 실시간 데이터: 방금 호출한 API가 돌려준 주가나 날씨 등

문제는 모델이 인지할 수 있는 컨텍스트의 양이 무한이 아니라는 점입니다. 그래서 컨텍스트 엔지니어링은 사실상 선별과 압축의 기술입니다. 무엇을 지금 보여주고, 무엇을 요약하고, 무엇을 잠시 치워둘 것인가. 짧은 대화엔 단기 메모리, 오래된 사실엔 장기 메모리, 시간 지난 내용엔 요약 — 이런 식으로 층층이 짜야 합니다.

이게 잘 짜이면 AI가 비로소 "사람처럼 기억한다"는 느낌이 듭니다. 어제 했던 얘기를 끌어오고, 사용자의 취향을 반영하고, 회사 문서를 참고하고, 실시간 정보까지 같이 보면서 답을 만들죠. 그제서야 단발성 Q&A가 아니라 "일을 같이 하는" 경험이 됩니다.

프롬프트 엔지니어링과는 어떻게 다른가

ChatGPT에 "이메일 답장 정중하게 써줘"라고 하는 것은 프롬프트 엔지니어링입니다. 그런데 회사 고객지원 챗봇을 만들 때, 이 챗봇이 이전 대화를 기억하고, 사용자 계정 정보를 끌어오고, 관련 제품 문서를 들춰보고, 대화 내내 톤도 유지해야 한다면 그 순간부터 컨텍스트 엔지니어링의 영역입니다.

차이를 짧게 정리하면 이렇습니다.

• 프롬프트 엔지니어링: 모델한테 무엇을 요청할지를 설계

• 컨텍스트 엔지니어링: 모델한테 무엇을 줄지를 시스템으로 설계

Andrej Karpathy의 표현을 참고하면 이해하기 쉽습니다.

"사람들은 프롬프트를 일상에서 LLM에 던지는 짧은 작업 지시로 생각합니다. 그런데 산업에서 쓸 만큼 견고한 LLM 앱은 컨텍스트 엔지니어링 — 다음 한 스텝에 딱 맞는 정보로 컨텍스트 창을 채우는 섬세한 기술 — 위에서 굴러갑니다."

좋은 프롬프트는 여전히 필요합니다. 다만 그 프롬프트가 빈 공간이 아니라, 잘 정돈된 배경 정보 위에서 작동하느냐가 차이를 만듭니다.

실전에선 어떤 모양으로 등장하나

실제 제품에선 컨텍스트 엔지니어링이 세 가지 형태로 나타납니다.

RAG: 모델이 "오픈북 시험"을 보게 하는 법

가장 익숙한 패턴이 RAG입니다. 어려워 보이지만, 아이디어 자체는 단순합니다. 사용자가 뭔가 물으면, 관련 자료를 외부 지식 베이스에서 찾아와 모델에게 같이 보여줍니다. 그러면 모델은 학습 때 보지 못한 정보도 답할 수 있게 됩니다.

예전엔 사내 정책을 답하려면 모델을 사내 문서로 파인튜닝해야 했습니다. RAG는 이걸 뒤집습니다. 모델은 그대로 두고, 그때그때 필요한 정보를 검색해서 컨텍스트에 끼워 넣죠. 모델에게 오픈북 시험을 보게 한다고 이해하시면 빠릅니다.

장점은 뚜렷합니다. 모델의 실수가 줄고, 회사 내부와 관련 있는 사실이 답으로 나옵니다. 그래서 사내 Q&A 봇, 고객지원 봇, 개인 비서 등, 회사 자료가 핵심인 거의 모든 케이스에서 RAG가 첫 단계로 들어갑니다.

에이전트: 컨텍스트를 직접 채워가는 모델

RAG가 자료를 컨텍스트에 넣는 거라면, 에이전트는 한 단계 더 갑니다. 모델이 직접 도구를 골라 부르고, 그 결과를 다시 자기 컨텍스트에 채워 넣으면서 일을 진행하죠. 컨텍스트가 정적인 글 뭉치에서 살아있는 작업대로 바뀌는 것입니다.

예를 들어 "테슬라 주가 알려주고 관련 뉴스 요약해줘"라고 부탁했다고 해보겠습니다. 잘 만든 에이전트는 (1) "최신 데이터가 필요하네" 판단 → (2) 주가 API 호출 → (3) 뉴스 검색 도구 호출 → (4) 둘을 묶어 정리, 이렇게 움직입니다. 각 단계의 결과가 컨텍스트에 누적되고, 그걸 보고 다음 행동을 정하는 겁니다. 관찰 → 행동 → 컨텍스트 업데이트 → 다시 관찰의 루프입니다.

요즘은 한 에이전트가 다 하지 않고 여러 에이전트가 역할을 나눠 일하는 방식도 늘고 있습니다. 한쪽이 문서 요약, 한쪽이 DB 검색, 다른 에이전트가 두 결과를 합치는 식이죠. 다만 여러 에이전트가 컨텍스트를 잘못 주고받으면 서로 헷갈리며 무한 루프에 빠지기 쉽다는 게 함정입니다. 그래서 컨텍스트 엔지니어링이 더 중요해지죠.

코딩 어시스턴트 : 가장 어려운 케이스

GitHub Copilot, Cursor, Windsurf 같은 코딩 어시스턴트는 사실 컨텍스트 엔지니어링의 끝판왕에 가깝습니다. 코드베이스는 보통 너무 크고, 서로 얽혀 있고, 한 파일만 봐도 다른 파일 수십 개에 영향을 주죠.

"process_data 함수가 빈 값도 처리하게 리팩토링해줘" — 이 한 줄 요청을 잘 처리하려면 어시스턴트가 알아야 할 게 많습니다. 이 함수가 어디서 호출되는지, 어떤 타입을 받고 돌려주는지, 프로젝트 코딩 스타일은 뭔지, 최근에 어떤 커밋이 있었는지. 이걸 다 컨텍스트로 채워주는 게 코딩 어시스턴트의 본업입니다. 어떻게 보면 코드베이스 위에서 돌리는 RAG라고 봐도 될 정도예요.

같은 도구라도 프로젝트에 오래 붙어 쓸수록 좋아지는 느낌이 드는데, 당연하게도 컨텍스트가 점점 두꺼워지기 때문입니다.

컨텍스트가 망가지는 4가지 패턴

여기서 자연스럽게 떠오르는 질문이 하나 있죠. "그럼 에이전트가 이해할 수 있는 컨텍스트를 그냥 100만 토큰까지 키우면 다 해결되는 거 아닌가?"

최근 연구들은 정반대 얘기를 합니다. AI 연구자 Drew Breunig는 "긴 컨텍스트가 더 좋은 답을 만드는 건 아니다"라고 못 박았어요. 오히려 컨텍스트가 너무 많아지면 모델이 오염되거나, 정신이 팔리거나, 헷갈리거나, 자기 말과 부딪히는 새로운 방식으로 망가지기 시작합니다.

1. 컨텍스트 오염: 가짜 정보가 진실처럼 박힐 때

대화 도중 모델이 한 번이라도 사실이 아닌 걸 "사실"로 컨텍스트에 박아 넣으면, 그 다음부턴 가짜 사실을 기준으로 추론을 이어갑니다. 작은 환각 하나가 전체 흐름을 망치는 거죠.

DeepMind의 Gemini 에이전트가 포켓몬을 플레이한 사례가 대표적입니다. 캐릭터가 멀쩡한데 "쓰러졌다"고 잘못 인식한 순간, 그 정보가 에이전트의 목표 리스트에 박혔어요. 그 뒤로 에이전트의 모든 행동이 망가졌습니다.

대응법은 격리(Quarantine)입니다. 모델이 자기가 안다고 주장하는 걸 그냥 받지 말고, 한 번 검증한 다음에 장기 메모리에 옮기는 것입니다. 의심스러운 부분은 별도 세션이나 별도 에이전트에서 처리해서, 한 줄기의 오류가 다른 줄기를 오염시키지 않게 막는 게 핵심입니다. 노트 여러 권을 따로 쓰는 거랑 비슷합니다. 한 권이 엉망이어도 나머지는 멀쩡합니다.

2. 컨텍스트 분산: 자기 기록에 정신이 팔리는 모델

컨텍스트가 너무 커지면, 모델이 학습 때 익힌 지식보다 그 자리에 쌓인 기록에 더 끌리기 시작합니다. 결국 새 답을 만들기보다 과거에 했던 행동을 똑같이 반복하는 데 빠지죠.

앞에서 본 Gemini 에이전트도 컨텍스트가 10만 토큰을 넘어가자 새 계획을 못 내고 과거 행동을 반복했습니다. Databricks가 측정한 결과로는 4050억 파라미터짜리 Llama 3.1조차 3만 2천 토큰 근처에서 정확도가 떨어지기 시작한다고 합니다. 100만 토큰을 받을 수 있다는 것과, 100만 토큰을 써먹을 수 있다는 건 다른 얘기죠.

대응법은 요약과 가지치기입니다. 대화가 길어지면 원본 기록을 그대로 끌고 가지 말고, 핵심만 추려낸 요약본으로 갈아 끼우는 거죠. 긴 회의 끝나고 액션 아이템 몇 줄로 정리하는 것과 같습니다. 모델이 일에 집중할 수 있게 책상 위를 한 번씩 정리해주는 것과 같습니다.

3. 컨텍스트 혼동: 도구가 많아질수록 잘못 고른다

모델한테 "이런 도구도 있어, 저런 도구도 있어" 하고 잔뜩 알려주면, 정작 핵심 도구를 잘 못 고릅니다. UC 버클리의 함수 호출 리더보드에서도 같은 결과가 나왔습니다. 도구를 한 개 줬을 때보다 여러 개 줬을 때 거의 모든 모델이 더 안 좋은 결과를 낸 것입니다.

"Less is More"라는 연구는 더 구체적입니다. Llama 3.1 8B 모델에 도구 46개를 다 보여줬더니 아예 실패했는데, 같은 모델에 관련도 높은 19개만 추려서 보여주니까 잘 풀렸다는 거죠. 컨텍스트 창에 다 들어가는데도 그렇습니다. 문제는 길이가 아니라 "관련 없는 선택지가 많다"는 것이었어요.

대응법은 도구 로드아웃 관리(Tool Loadout Management)입니다. 게이머가 임무마다 무기를 골라서 들고 나가듯, 사용자의 질문을 본 다음에 거기 어울리는 도구 2~3개만 추려서 모델에게 알려주는 거죠. 흥미롭게도 도구 설명을 벡터 DB에 넣고 RAG로 골라주는 방법이 잘 통한다고 합니다. 결국 컨텍스트 엔지니어링의 원리를 그 자체에 다시 적용한 셈입니다.

4. 컨텍스트 충돌: 자기가 한 말과 부딪히는 모델

마지막이 제일 심각한 문제입니다. 사용자가 정보를 한 번에 다 주지 않고 여러 턴에 걸쳐 조금씩 던지면, 모델은 정보가 다 모이기 전에 어설픈 추측 답을 먼저 내놓게 됩니다. 그리고 그 어설픈 추측이 다시 컨텍스트에 남죠. 나중에 진짜 정보가 들어와도, 모델은 자기가 앞에서 한 말과 새 정보 사이에서 헷갈리기 시작합니다.

Microsoft·Salesforce 합동 연구가 정확히 이걸 측정했는데, 같은 정보를 한 번에 주는 것 대비 여러 턴에 쪼개서 주면 평균 39% 성능이 떨어졌습니다. 한 모델은 98%에서 64%까지 추락했죠. 정보량은 똑같은데, 단지 "단계별로 흘러들었다"는 이유로요.

대응법은 두 가지입니다.

가지치기: 잘못된 중간 추측이 컨텍스트에 남아 있으면, 다음 턴을 만들 때 그 부분을 잘라냅니다. 새 정보가 옛 추측과 싸우지 않게 미리 치워주는 거죠.

오프로딩: 모델이 머릿속으로 굴리는 중간 사고를 따로 만든 "메모장"에 옮기는 방식입니다. Anthropic이 Claude에 붙인 think 도구가 대표적이죠. 최종 답을 만드는 컨텍스트에선 그 메모장을 빼버려서, 답을 낼 땐 "지저분한 중간 풀이" 없이 깔끔한 상태에서 작업합니다. Anthropic은 이 방법만으로 특정 에이전트 작업에서 성능이 최대 54% 올라갔다고 보고했습니다.

정리

여기까지 보면 컨텍스트 엔지니어링이 거창해 보일 수도 있는데, 처음부터 다 갖춰서 시작할 필요는 없습니다. 작게 시작해도 충분히 효과가 납니다.

• 사내 챗봇에 "사내 위키 검색" 한 단계만 붙여보기 (기본 RAG)

• 최근 대화 몇 턴만 기억하게 작은 메모리 버퍼 붙이기

• 잘 굴러가던 프롬프트 앞에 "이 사용자에 대한 한 줄 요약"만 끼워 넣어보기

그 다음엔 "우리 AI가 자기 일을 잘하기 위한 컨텍스트가 다 들어가 있나?"라는 질문을 계속 던지는 거죠. 답이 "아니오"라면, 이 글이 그 다음 한 걸음을 어디로 옮길지 알려주는 지도라고 보시면 됩니다.

좋은 모델 + 좋은 프롬프트의 시대에서, 좋은 모델 + 좋은 컨텍스트의 시대로 넘어가고 있습니다. 사용자 입장에선 그 차이가 "AI가 진짜 일을 같이 해주네" vs "또 까먹네" 정도로 크게 느껴지죠. 다음 프로젝트에선, 모델보다 컨텍스트를 먼저 다듬어보시는 걸 추천드립니다.

회의는 컨텍스트의 가장 큰 빈 공간입니다

이 글 흐름에서 한 가지만 더 짚겠습니다. 외부 자료를 모델에게 잘 가져다 주는 게 컨텍스트 엔지니어링의 출발점이라고 했는데, 정작 대부분의 회사에서 가장 중요한 맥락은 어디에도 디지털화되어 있지 않습니다.

Notion에 정리된 문서, Slack에 남은 메시지, Jira의 티켓 — 이것들은 회사 맥락의 10% 정도밖에 안 돼요. 나머지 90%는 회의에서 나온 결정, "왜 그렇게 정했는지"의 이유, 누군가가 한마디 던졌던 우려 — 즉 구두로 오갔던 모든 것입니다. 그리고 이 90%는 회의가 끝나는 순간 사라지죠. AI 에이전트가 아무리 좋은 RAG로 사내 위키를 뒤져도, 이 자리엔 들어갈 수가 없습니다.

티로(Tiro) 가 채우려는 자리가 정확히 그곳입니다. 회의 음성을 받아서 AI 에이전트가 곧바로 읽을 수 있는 형태(LLM-Ready Data)로 바꿔두는 일을 합니다. 그리고 그걸 끝이 아니라 시작으로 두고, API·MCP·CLI·Skill 네 가지 길로 에이전트가 그 데이터에 닿게 해두었죠.

흥미로운 건, 이 글에서 다룬 컨텍스트 망가짐 패턴들이 티로 설계에도 그대로 반영되어 있다는 점입니다. 컨텍스트 혼동을 막기 위해 MCP는 Progressive Disclosure 패턴으로 토큰을 단계적으로 쓰게 했고(목록 → 요약 → 전문 순), 컨텍스트 분산을 막기 위해 큰 회의록은 CLI로 디스크에 떨어뜨려서 메인 컨텍스트엔 영수증만 남깁니다. 이 글에서 다룬 원리들이 실제 제품 설계로 옮겨졌을 때 어떤 모양이 되는지 궁금하시면, 티로가 비즈니스 맥락을 기억하는 법 글에서 더 자세히 다뤘습니다.

회사의 회의 데이터를 AI 에이전트와 연결해보고 싶으신 분들은 아래에서 시작해보세요.

시작하기