컨텍스트 엔지니어링 개발자 가이드: AI 에이전트의 기억을 설계하는 법
들어가며: 왜 지금 컨텍스트 엔지니어링인가?
2025년, AI 에이전트 개발의 패러다임이 바뀌고 있습니다. 불과 1년 전만 해도 우리는 “더 큰 컨텍스트 윈도우”가 모든 문제를 해결할 것이라 믿었습니다. OpenAI가 128K 토큰을 지원하고, Anthropic이 200K를 발표했을 때, 우리는 환호했습니다. Gemini가 1M 토큰을 선보였을 때는 혁명이라고 생각했습니다.
하지만 실전에 투입하면서 우리는 불편한 진실을 마주하게 되었습니다. 컨텍스트 윈도우가 커질수록 AI는 오히려 더 헷갈려 했습니다. 정확히 필요한 정보를 찾지 못하고, 관련 없는 내용에 주의를 빼앗기고, 때로는 아예 답변을 거부하기도 했습니다. Cognition AI의 엔지니어들이 “컨텍스트 엔지니어링이 AI 에이전트 개발자의 가장 중요한 업무”라고 선언한 것은 바로 이런 이유 때문입니다.
컨텍스트 엔지니어링은 AI에게 무엇을 보여주고, 무엇을 숨길지 결정하는 기술입니다. 프롬프트 엔지니어링이 “어떻게 물어볼 것인가”에 집중한다면, 컨텍스트 엔지니어링은 “무엇을 보여줄 것인가”에 집중합니다. 이것은 단순히 토큰을 절약하는 기술이 아닙니다. AI의 주의력을 관리하고, 기억을 설계하고, 성능을 보장하는 종합적인 엔지니어링 분야입니다.
이 가이드는 2025년 12월 현재, 컨텍스트 엔지니어링 분야의 최신 연구와 실전 경험을 종합합니다. GitHub에서 화제가 된 Agent-Skills 프로젝트, Chroma Research의 획기적인 Context Rot 연구, LangChain 팀의 실전 전략, 그리고 Anthropic의 공식 Agent Skills 시스템까지 모두 다룹니다. 이론과 실전, 연구와 엔지니어링의 균형을 맞춰 여러분이 실제로 적용할 수 있는 지식을 제공하고자 합니다.
제1장: 컨텍스트 엔지니어링의 본질
컨텍스트란 무엇인가
Andrej Karpathy는 컨텍스트 윈도우를 컴퓨터의 RAM에 비유했습니다. RAM은 기억이 아닙니다. 지금 이 순간 프로세서가 보고 있는 것들일 뿐입니다. 전원을 끄면 사라집니다. 컨텍스트 윈도우도 마찬가지입니다. AI는 컨텍스트 안의 내용을 “기억”하는 것이 아니라, 그저 “보고” 있을 뿐입니다. 세션이 끝나면 모두 잊어버립니다.
컨텍스트는 여러 층으로 구성됩니다. 가장 기본이 되는 것은 시스템 프롬프트입니다. 이것은 AI의 정체성을 정의합니다. “당신은 친절한 고객 지원 담당자입니다”라는 한 문장이 AI의 모든 행동을 규정합니다. 그 다음은 도구 정의입니다. AI가 사용할 수 있는 함수들, 그들의 파라미터, 실행 방법이 여기 들어갑니다. 그리고 검색된 문서들, 대화 이력, 도구 실행 결과들이 차례로 쌓입니다.
문제는 이 모든 것이 하나의 제한된 공간에 들어가야 한다는 점입니다. Claude Sonnet 4가 128,000 토큰을 지원한다고 해서, 우리가 128,000 토큰을 모두 사용해야 하는 것은 아닙니다. 오히려 사용하면 안 됩니다. 왜냐하면 AI의 주의력은 제한되어 있기 때문입니다.
주의력의 경제학
인간의 뇌를 생각해봅시다. 여러분이 이 글을 읽고 있는 지금, 여러분은 2019년에 먹은 아침식사를 생각하지 않습니다. 2002년의 이별을 떠올리지 않습니다. 1990년대에 본 스타트렉 에피소드를 회상하지 않습니다. 만약 이 모든 기억이 동시에 의식 속에 떠오른다면, 여러분은 이 글을 읽을 수 없을 것입니다. 주의력이 분산되어 아무것도 집중할 수 없게 됩니다.
AI도 마찬가지입니다. 컨텍스트 윈도우에 100,000 토큰이 들어있다면, AI는 새로운 토큰 하나를 생성하기 전에 이 100,000개를 모두 “생각”해야 합니다. 이것을 어텐션 메커니즘이라고 부릅니다. 토큰이 많아질수록 각 토큰에 쏟을 수 있는 주의력은 줄어듭니다. 마치 100명이 동시에 말을 걸 때 한 사람도 제대로 듣지 못하는 것과 같습니다.
2025년 Chroma Research의 획기적인 연구는 이 문제를 정량화했습니다. 그들은 GPT-4.1, Claude 4, Gemini 2.5를 포함한 18개의 최신 모델을 테스트했습니다. 놀랍게도, 단순한 문자열 반복 같은 쉬운 작업조차 컨텍스트가 길어지면 실패했습니다. 2,500단어를 넘어가면 모델들은 거부하거나, 중간에 잘라버리거나, 심지어 없는 내용을 지어내기 시작했습니다.
이것이 “Context Rot”, 즉 컨텍스트 부패입니다. 컨텍스트가 부패하면 AI의 성능은 예측 불가능하게 저하됩니다. 정확도가 떨어지고, 응답 시간이 늘어나고, 환각이 증가하고, 비용이 폭증합니다. 그리고 가장 심각한 것은, 이것이 비선형적으로 발생한다는 점입니다. 10,000 토큰에서는 괜찮다가, 50,000 토큰에서 갑자기 무너질 수 있습니다.
정보 선별의 중요성
컨텍스트 엔지니어링의 첫 번째 원칙은 선별성입니다. 모든 정보를 제공하지 마십시오. 작업에 필요한 정보만 제공하십시오. 이것은 직관에 반합니다. 우리는 “더 많은 정보가 더 좋다”고 배웠습니다. 하지만 AI에게는 그렇지 않습니다. 더 많은 정보는 더 많은 노이즈를 의미합니다. 신호 대 잡음비가 떨어집니다.
Stanford 대학의 연구진은 20개의 문서를 AI에게 제공하는 실험을 했습니다. 총 4,000 토큰 정도였습니다. 필요한 정보가 첫 번째 문서에 있을 때 정확도는 70-75%였습니다. 마지막 문서에 있을 때도 70-75%였습니다. 하지만 열 번째, 즉 중간에 있을 때는 55-60%로 떨어졌습니다. 이것을 “Lost in the Middle” 현상이라고 합니다. U자 형태의 주의력 곡선입니다.
이 발견은 실전에 큰 영향을 미칩니다. 만약 여러분이 RAG 시스템을 구축한다면, 검색된 문서를 그냥 순서대로 나열하면 안 됩니다. 가장 중요한 정보를 맨 앞이나 맨 뒤에 배치해야 합니다. 중간은 덜 중요한 정보를 위한 공간입니다. 이것이 전략적 배치입니다.
두 번째 원칙은 정보 밀도 최적화입니다. 같은 내용을 더 적은 토큰으로 전달할 수 있다면, 그렇게 해야 합니다. 이것은 단순히 요약을 의미하지 않습니다. 계층적 구조화, 점진적 노출, 동적 로딩을 모두 포함합니다. Anthropic의 Agent Skills 시스템이 좋은 예입니다. 시작할 때는 각 스킬의 이름과 한 줄 설명만 로드합니다. 스킬당 30-40 토큰 정도입니다. 100개 스킬이 있어도 4,000 토큰밖에 안 됩니다. 실제로 스킬을 사용할 때만 전체 내용을 로드합니다. 이것을 Progressive Disclosure, 점진적 노출이라고 합니다.
세 번째 원칙은 구조적 조직화입니다. 정보는 무작위로 쌓이면 안 됩니다. 계층과 우선순위가 있어야 합니다. 핵심 작업 정보가 레벨 1입니다. 주요 참조 정보가 레벨 2, 보조 정보가 레벨 3, 메타 정보가 레벨 4입니다. AI가 먼저 읽어야 할 것이 위에, 나중에 읽어도 되는 것이 아래에 배치됩니다. XML 태그나 마크다운 헤더로 명확히 구분합니다.
제2장: Agent-Skills와 Skill-Creator, 무엇이 다른가
혼란의 시작
2025년 10월, Anthropic이 Agent Skills를 발표했을 때 많은 개발자들이 혼란스러워했습니다. 그로부터 몇 주 후, Muratcan Koylan이 “Agent-Skills for Context Engineering”이라는 GitHub 리포지토리를 공개했습니다. 이름이 너무 비슷했습니다. 사람들은 물었습니다. “이거 같은 거 아닌가요?” “Anthropic이 만든 건가요?” “왜 두 개가 있나요?”
사실 이 질문은 당연합니다. 표면적으로는 둘 다 “스킬”이라는 용어를 사용하고, 둘 다 에이전트의 능력을 향상시키고, 둘 다 마크다운 파일을 사용합니다. 하지만 깊이 들어가면 완전히 다른 도구입니다. ChatGPT와 Gemini가 둘 다 “대화형 AI”이지만 근본적으로 다른 것처럼, 이 둘도 그렇습니다.
Anthropic Skill-Creator: 도구를 만드는 도구
Anthropic의 Skill-Creator는 메타 도구입니다. 스킬을 만드는 도구입니다. 선반이나 밀링 머신처럼, 다른 도구를 제작하기 위한 기계입니다. Claude에게 “브랜드 가이드라인을 적용하는 스킬을 만들어줘”라고 하면, Skill-Creator가 작동합니다. Claude는 대화형으로 질문합니다. “어떤 브랜드인가요?” “주요 색상은?” “로고 파일이 있나요?” 답변에 따라 SKILL.md 파일을 생성하고, 필요한 리소스를 구조화하고, 메타데이터를 작성합니다.
생성된 스킬은 Claude 플랫폼에 등록됩니다. 이후 대화에서 Claude는 자동으로 이 스킬을 감지하고 로드합니다. “Q3 보고서 만들어줘”라고 하면, Claude는 브랜드 가이드라인 스킬이 관련 있다고 판단하고 활성화합니다. 스킬의 전체 내용이 컨텍스트에 주입됩니다. 이제 Claude는 회사의 공식 색상, 폰트, 로고 사용 규칙을 알고 있습니다. 문서는 자동으로 브랜드에 맞게 생성됩니다.
이것이 Progressive Disclosure의 핵심입니다. 시작할 때는 “브랜드 가이드라인 스킬 사용 가능”이라는 한 줄 메타데이터만 있습니다. 40-50 토큰 정도입니다. 실제로 필요할 때만 전체 스킬이 로드됩니다. 5,000-10,000 토큰일 수도 있습니다. 하지만 99%의 대화에서는 필요 없습니다. 토큰을 절약하고, 속도를 높이고, 비용을 줄입니다.
Anthropic의 문서 생성 기능이 모두 이렇게 작동합니다. PowerPoint, Excel, Word, PDF 스킬들이 이미 내장되어 있습니다. 여러분도 보셨을 겁니다. Claude에게 “분기 보고서를 엑셀로 만들어줘”라고 하면, 몇 초 만에 완성된 xlsx 파일이 나옵니다. 차트도 있고, 수식도 작동합니다. 이것이 바로 xlsx 스킬의 작품입니다.
API를 통해서도 사용할 수 있습니다. 베타 기능이지만 이미 많은 기업이 활용하고 있습니다. 스킬을 프로그래밍 방식으로 생성하고, 버전을 관리하고, 팀 전체에 배포할 수 있습니다. 각 팀원의 Claude가 같은 스킬 세트를 공유합니다. 일관성이 보장됩니다.
Agent-Skills: 지혜를 전달하는 지식 저장소
반면 Muratcan Koylan의 Agent-Skills는 지식 저장소입니다. 공구가 아니라 공구 사용 설명서입니다. Python 언어가 아니라 GoF 디자인 패턴입니다. 도구를 만드는 법을 가르치는 것이 아니라, 이미 증명된 패턴과 원칙을 제공합니다.
이 프로젝트는 7개의 핵심 스킬로 구성됩니다. 각 스킬은 마크다운 문서이지만, 단순한 문서가 아닙니다. 연구 논문, 프로덕션 경험, 베스트 프랙티스를 압축한 지식 캡슐입니다. context-fundamentals는 컨텍스트의 구성 요소와 메커니즘을 설명합니다. context-degradation은 성능 저하 패턴을 분류합니다. context-optimization은 최적화 기법을 가르칩니다.
이것은 “메타 에이전트” 지식입니다. AI가 자신의 인지 자원을 관리하는 방법을 배웁니다. 마치 사람이 메타인지를 통해 자신의 사고 과정을 모니터링하고 조절하는 것처럼, AI도 자신의 컨텍스트를 의식하고 관리할 수 있게 됩니다. “지금 내 컨텍스트가 너무 크다”, “이 정보는 우선순위가 낮다”, “요약이 필요하다” 같은 판단을 할 수 있습니다.
중요한 것은 플랫폼 독립성입니다. Agent-Skills는 Claude만을 위한 것이 아닙니다. Cursor에서도 작동하고, 커스텀 에이전트 프레임워크에서도 작동합니다. 심지어 GPT나 Gemini에서도 작동합니다. 왜냐하면 이것은 특정 API를 호출하는 코드가 아니라, 원칙을 설명하는 문서이기 때문입니다. 어떤 LLM이든 읽을 수 있습니다.
실제로 테스트해본 개발자들의 보고가 있습니다. context-fundamentals 스킬을 읽게 한 후 복잡한 RAG 작업을 시키면, AI의 컨텍스트 관리가 눈에 띄게 개선됩니다. 불필요한 정보를 요청하지 않고, 메모리를 효율적으로 사용하고, 토큰 예산을 의식합니다. 마치 경험 많은 개발자가 메모리 누수를 피하고 캐시를 활용하는 것처럼, AI도 학습합니다.
비유로 이해하기
공구 제작 도구와 작업 지침서를 생각해보십시오. Skill-Creator는 선반입니다. 원하는 부품을 만들 수 있습니다. 나사, 볼트, 커넥터, 무엇이든 만들 수 있습니다. 하지만 선반 사용법을 알아야 합니다. 재료를 고정하고, 날을 선택하고, 속도를 조절하고, 마무리를 다듬어야 합니다.
Agent-Skills는 숙련공의 노트입니다. “나사를 만들 때는 이렇게”, “볼트는 이렇게”, “표면 처리는 이렇게” 같은 노하우가 담겨 있습니다. 선반이 없어도 읽을 수 있습니다. 다른 공작 기계를 사용하더라도 원칙은 같습니다. 핸드 드릴이든, CNC 밀링이든, 3D 프린터든 적용됩니다.
프로그래밍으로 비유하면 더 명확합니다. Skill-Creator는 Python 언어입니다. 문법, 함수, 클래스, 모듈 시스템을 제공합니다. 무엇이든 만들 수 있지만, 어떻게 만들지는 스스로 결정해야 합니다. Agent-Skills는 디자인 패턴 카탈로그입니다. Singleton, Factory, Observer, Strategy 같은 검증된 패턴들입니다. Python이 아니어도 적용할 수 있습니다. Java든, C++이든, JavaScript든 원칙은 같습니다.
언제 무엇을 사용할까
실무에서는 둘 다 필요합니다. 상황에 따라 선택하거나 조합합니다.
기업 내부 워크플로우를 자동화한다면 Skill-Creator가 좋습니다. “회사 브랜드 가이드라인 적용”, “표준 이메일 템플릿 사용”, “JIRA 티켓 생성 규칙” 같은 반복적 작업을 스킬로 만듭니다. 팀원들이 Claude를 사용할 때 자동으로 적용됩니다. 일관성이 보장되고, 실수가 줄어들고, 시간이 절약됩니다.
하지만 RAG 시스템 성능을 개선한다면 Agent-Skills가 필요합니다. Skill-Creator는 직접적 해결책을 주지 않습니다. 도구 생성 프레임워크이기 때문입니다. Agent-Skills는 context-degradation 스킬로 문제를 진단하고, context-optimization으로 검색 결과를 압축하고, memory-systems로 계층적 검색을 구현하고, evaluation으로 성능을 측정하는 방법을 가르칩니다.
가장 좋은 방법은 순차적 활용입니다. Agent-Skills로 원칙을 배웁니다. 컨텍스트가 어떻게 작동하는지, 왜 실패하는지, 어떻게 최적화하는지 이해합니다. 그런 다음 Skill-Creator로 구현합니다. 배운 원칙을 Claude 스킬로 만들어 프로덕션에 배포합니다. 지식이 자동화로 전환됩니다.
제3장: Context Rot, AI의 치매
발견의 순간
2025년 7월, Chroma의 연구팀은 충격적인 논문을 발표했습니다. 제목은 단순했습니다. “Context Rot: How Increasing Input Tokens Impacts LLM Performance”. 하지만 내용은 AI 커뮤니티를 뒤흔들었습니다. 18개의 최신 모델을 테스트한 결과, 모든 모델이 컨텍스트가 길어질수록 성능이 저하되었습니다. GPT-4.1도, Claude 4도, Gemini 2.5도 예외가 없었습니다.
가장 놀라운 것은 작업의 단순함이었습니다. 복잡한 추론도 아니고, 창의적인 글쓰기도 아니었습니다. 그냥 단어를 반복하는 것이었습니다. “apple banana cherry”라는 시퀀스를 2,000번 반복해달라고 하면, 1,000 토큰 정도까지는 완벽했습니다. 10,000 토큰에서는 80% 정확도로 떨어졌습니다. 50,000 토큰에서는 30%까지 추락했습니다. 100,000 토큰에서는 거의 무작위 수준인 10%만 정확했습니다.
더 복잡한 작업은 상황이 더 나빴습니다. “드레스덴이 어느 주에 있는지” 같은 2단계 추론(드레스덴→작센 주)이 필요한 질문에서는, 컨텍스트가 길어질수록 정확도가 기하급수적으로 떨어졌습니다. 이것은 우리가 만들려는 실전 에이전트에게 심각한 문제입니다. 고객 지원 챗봇이 며칠간의 대화 이력을 기억해야 한다면? 코드 에이전트가 대규모 코드베이스를 분석해야 한다면? 연구 에이전트가 수십 편의 논문을 종합해야 한다면?
Lost in the Middle: 중간이 가장 위험하다
Stanford 연구팀의 발견은 더욱 구체적이었습니다. 그들은 “바늘 찾기(Needle in a Haystack)” 실험을 했습니다. 긴 문서 속에 특정 문장을 숨기고, AI에게 찾게 하는 것입니다. 예를 들어 “샌프란시스코에서 가장 좋은 것은 샌드위치를 먹고 Dolores Park에서 햇볕을 쬐는 것이다”라는 문장을 4,000 토큰짜리 문서 어딘가에 숨깁니다. 그리고 “샌프란시스코에서 뭐 하는 게 좋아?”라고 묻습니다.
이 문장이 문서의 맨 앞에 있으면 75% 확률로 찾았습니다. 맨 뒤에 있어도 72%였습니다. 하지만 중간에 있으면? 55%로 떨어졌습니다. U자 곡선입니다. 시작과 끝은 기억하지만 중간은 잊어버립니다. 마치 사람이 목록의 첫 항목과 마지막 항목은 기억하지만 중간은 헷갈리는 것과 같습니다.
이것은 어텐션 메커니즘의 구조적 한계입니다. Transformer 아키텍처는 시퀀스의 시작과 끝에 더 많은 가중치를 줍니다. 위치 인코딩이 그렇게 설계되어 있습니다. 중간은 상대적으로 “흐릿”합니다. 그리고 컨텍스트가 길어질수록 중간 영역이 넓어집니다. 1,000 토큰에서는 중간이 500 토큰입니다. 100,000 토큰에서는 중간이 50,000 토큰입니다. 엄청난 사각지대입니다.
실전 영향은 즉각적입니다. RAG 시스템을 구축한다면, 검색된 문서를 무작위로 나열하면 안 됩니다. 가장 관련성 높은 문서를 맨 앞에 배치합니다. 두 번째로 중요한 것은 맨 뒤에 배치합니다. 덜 중요한 정보만 중간에 넣습니다. 또는 아예 중간을 피하고, 핵심 정보를 앞뒤로 반복 배치합니다.
Distractor의 독: 비슷한 것이 가장 위험하다
Chroma 연구의 또 다른 발견은 “방해 요소(Distractor)”의 영향이었습니다. 예를 들어 “Python 비동기 프로그래밍”에 대해 묻는데, 컨텍스트에 JavaScript의 async/await 문서가 섞여 있다면 어떻게 될까요? 모델은 혼란스러워합니다. 둘 다 “비동기”에 대한 것이고, 둘 다 “프로그래밍”에 대한 것이지만, 하나는 Python이고 하나는 JavaScript입니다.
연구진은 의미론적 유사도를 조절하며 테스트했습니다. 완전히 다른 주제(예: Python 비동기 vs 요리 레시피)일 때는 70% 정확도였습니다. 완전히 같은 주제일 때는 65%였습니다. 하지만 비슷하지만 다른 주제(Python 비동기 vs JavaScript 비동기)일 때는 55%로 떨어졌습니다. 중간 유사도가 가장 위험합니다.
왜일까요? 완전히 다른 주제는 쉽게 걸러집니다. 모델이 “이건 관련 없네”라고 판단합니다. 완전히 같은 주제는 모두 유용합니다. 정보가 중복되긴 하지만 일관성은 있습니다. 하지만 비슷하지만 다른 주제는? 모델이 “이것도 관련 있는 것 같은데…“라고 혼란스러워합니다. 주의력이 분산됩니다. 두 가지를 섞어서 답변하기 시작합니다.
실무 교훈은 명확합니다. 벡터 유사도 검색만으로는 부족합니다. 상위 K개 문서를 무조건 포함하면 안 됩니다. 추가 필터링이 필요합니다. 쿼리와의 유사도가 0.3-0.6 사이인 “위험 구간”의 문서는 제외하거나, 키워드 매칭 같은 추가 검증을 거쳐야 합니다. 너무 다르거나 충분히 유사한 것만 포함합니다.
구조화의 역설: 정돈된 것이 더 어렵다
가장 놀라운 발견은 문서 구조의 영향이었습니다. 연구진은 같은 내용을 두 가지 방식으로 제공했습니다. 하나는 잘 쓰인 에세이, 도입-본론-결론의 논리적 흐름이 있는 일관된 텍스트였습니다. 다른 하나는 같은 문장들을 무작위로 섞은 것이었습니다. 직관적으로는 구조화된 에세이가 더 쉬워야 합니다. 하지만 결과는 반대였습니다. 정돈된 에세이에서 55% 정확도, 무작위 문장에서 70% 정확도였습니다.
왜 이런 일이 벌어질까요? 가설은 이렇습니다. 구조화된 텍스트는 내러티브를 만듭니다. 모델이 이야기를 따라갑니다. “도입부에서 이렇게 시작했으니, 본론에서는 이렇게 전개되고, 결론은 이렇게 나오겠지” 같은 기대를 형성합니다. 하지만 필요한 정보가 이 흐름의 중간 어딘가에 숨어있다면, 모델은 내러티브를 쫓느라 정보를 놓칩니다. 반면 무작위 문장은 내러티브가 없습니다. 각 문장이 독립적입니다. 모델이 한 문장 한 문장 집중해서 읽습니다.
실전 의미는 RAG 시스템 설계에 영향을 줍니다. 긴 문서를 통째로 넣지 마십시오. 독립적인 청크로 분할하십시오. 각 청크가 자체적으로 의미를 가져야 합니다. 문맥을 위해 약간의 중복을 허용하십시오. “이 섹션은 X에 대해 설명합니다”처럼 명시적 라벨을 추가하십시오. 내러티브보다 검색 최적화를 우선하십시오.
모델별 차이: 환각 vs 침묵
흥미로운 것은 모델마다 실패 방식이 다르다는 점입니다. GPT 시리즈는 확신에 찬 오답을 선호했습니다. 컨텍스트가 길어져서 혼란스러울 때, GPT는 그냥 추측했습니다. 그리고 그 추측을 확신 있게 제시했습니다. “샌프란시스코의 가장 좋은 곳은 Golden Gate Bridge입니다”처럼, 컨텍스트에 없는 답을 자신 있게 말했습니다. 환각입니다.
반면 Claude 시리즈는 거부를 선호했습니다. 확신이 없으면 답하지 않았습니다. “죄송하지만 제공된 정보에서 명확한 답을 찾을 수 없습니다”라고 했습니다. 더 안전하지만 덜 유용합니다. Gemini는 중간 어딘가였습니다.
이것은 안전성과 유용성의 트레이드오프를 보여줍니다. 의료나 금융 같은 고위험 분야에서는 Claude의 접근이 낫습니다. 틀린 답변보다 답변 거부가 안전합니다. 하지만 창의적 브레인스토밍이나 아이디어 생성에서는 GPT의 접근이 나을 수 있습니다. 완벽하지 않아도 시도하는 것이 가치 있습니다.
프로덕션에서는 이것을 모니터링해야 합니다. 거부율이 갑자기 높아지면 컨텍스트가 너무 길거나 혼란스럽다는 신호입니다. 환각률이 높아지면 같은 문제지만 다른 증상입니다. 둘 다 Context Rot의 징후입니다. 즉시 컨텍스트 크기를 줄이고, 정보를 필터링하고, 구조를 개선해야 합니다.
제4장: 4대 전략 - Write, Select, Compress, Isolate
LangChain의 실전 지혜
LangChain 팀은 수천 개의 프로덕션 에이전트를 운영하며 배운 교훈을 4가지 전략으로 정리했습니다. 이것은 이론이 아닙니다. 실제로 작동하는 것이 검증된 패턴입니다. 각 전략에는 구체적인 구현 방법과 노트북 예제가 있습니다.
Write: 컨텍스트 밖에 쓰기
첫 번째 전략은 역설적으로 들립니다. 컨텍스트를 줄이려면 더 많이 써야 합니다. 컨텍스트 윈도우 밖에 씁니다. 스크래치패드, 메모장, 외부 저장소를 사용합니다.
인간을 생각해보십시오. 복잡한 수학 문제를 풀 때 머릿속으로만 하지 않습니다. 종이에 씁니다. 중간 계산을 적고, 그림을 그리고, 메모를 남깁니다. 작업 기억(working memory)은 제한적이니까요. 7±2 청크만 동시에 유지할 수 있습니다. 나머지는 외부화합니다.
AI도 마찬가지입니다. Anthropic의 Multi-Agent Researcher가 좋은 예입니다. LeadResearcher 에이전트가 연구 계획을 세울 때, 전체 계획을 컨텍스트에 넣지 않습니다. 외부 메모리에 저장합니다. 컨텍스트에는 “연구 계획 수립 완료 (세부사항은 메모리 ID: plan_001에 저장)”라는 요약만 넣습니다. 50 토큰입니다. 전체 계획은 5,000 토큰일 수 있지만, 지금은 필요 없습니다.
나중에 SubResearcher 에이전트가 특정 부분을 담당할 때, 전체 계획을 불러오지 않습니다. 자신의 부분만 읽습니다. “섹션 3: 관련 연구 조사”만 메모리에서 가져옵니다. 500 토큰입니다. 나머지 4,500 토큰은 여전히 컨텍스트 밖입니다.
이것을 구현하는 방법은 여러 가지입니다. 가장 간단한 것은 Python 딕셔너리입니다. 세션 동안 유지되는 상태 객체입니다. 좀 더 정교하게는 Redis나 SQLite 같은 외부 저장소를 사용합니다. 세션을 넘어 지속됩니다. 벡터 데이터베이스를 쓸 수도 있습니다. 의미론적 검색이 필요할 때 유용합니다.
중요한 것은 선택적 로딩입니다. 모든 것을 메모리에 저장하되, 필요한 것만 컨텍스트에 로드합니다. 인간이 책장을 가지고 있지만 한 번에 한 권만 읽는 것과 같습니다. 책장은 외부 메모리, 손에 든 책은 컨텍스트입니다.
Select: 관련 정보만 선택하기
두 번째 전략은 필터링입니다. 전체가 아닌 부분만 가져옵니다. RAG의 핵심이지만, 단순한 벡터 검색 이상입니다.
전통적인 RAG는 이렇습니다. 사용자가 “Python 비동기 프로그래밍”을 묻습니다. 시스템은 쿼리를 임베딩하고, 벡터 DB에서 상위 K개 문서를 검색하고, 컨텍스트에 추가합니다. K=10이면 10개 문서가 들어갑니다. 각 문서가 500 토큰이면 5,000 토큰입니다.
개선된 RAG는 추가 필터를 적용합니다. 먼저 메타데이터 필터링입니다. 문서의 날짜, 카테고리, 언어를 확인합니다. “Python” 태그가 없으면 제외합니다. 1년 이상 된 것은 우선순위를 낮춥니다. 그러면 10개가 5개로 줄어듭니다.
다음은 리랭킹입니다. 벡터 유사도가 높아도 실제로 관련 없을 수 있습니다. 크로스 인코더로 재평가합니다. 쿼리와 문서를 함께 인코딩해서 더 정확한 관련성 점수를 얻습니다. 5개가 3개로 줄어듭니다.
마지막은 청크 선택입니다. 문서 전체가 아니라 관련 섹션만 가져옵니다. 각 문서를 문단으로 분할하고, 각 문단의 관련성을 평가합니다. 가장 관련성 높은 문단 2-3개만 컨텍스트에 넣습니다. 문서당 500 토큰이 아니라 200 토큰입니다. 3개 문서에서 600 토큰입니다.
5,000 토큰이 600 토큰으로 줄었습니다. 88% 감소입니다. 하지만 정보 손실은 거의 없습니다. 오히려 노이즈가 제거되어 품질이 향상됩니다. 이것이 선택의 힘입니다.
코드 에이전트에서 이것은 더욱 중요합니다. Windsurf의 Varun이 지적했듯이, 코드베이스가 커질수록 일반적인 임베딩 검색은 신뢰할 수 없게 됩니다. AST(Abstract Syntax Tree) 파싱이 필요합니다. 코드를 의미적으로 분할합니다. 함수, 클래스, 모듈 단위로 임베딩합니다. 그리고 호출 그래프를 고려합니다. 함수 A를 수정하려면 A를 호출하는 B와 A가 호출하는 C도 필요할 수 있습니다. 단순 유사도가 아니라 구조적 관계를 고려합니다.
Compress: 필요한 토큰만 유지하기
세 번째 전략은 압축입니다. 선택이 정보를 고르는 것이라면, 압축은 정보를 줄이는 것입니다. 같은 의미를 더 적은 토큰으로 전달합니다.
가장 간단한 압축은 대화 이력 요약입니다. 고객 지원 챗봇이 100턴의 대화를 했다고 상상해봅시다. 각 턴이 평균 50 토큰이면 5,000 토큰입니다. 새로운 질문에 답하려면 이 모든 이력이 컨텍스트에 있어야 할까요? 아닙니다. 최근 3턴이면 충분합니다. 나머지는 요약합니다.
LangChain의 실험이 보여줍니다. 115,000 토큰의 긴 대화를 종료 후 요약했더니 60,000 토큰으로 줄었습니다. 48% 감소입니다. 실시간으로는 더 공격적입니다. 매 10턴마다 요약합니다. 현재 3턴 + 이전 요약으로 유지합니다. 총 토큰은 2,000 이하로 유지됩니다.
요약 방법도 여러 가지입니다. 추출 요약(Extractive Summarization)은 원문에서 중요한 문장을 선택합니다. TF-IDF나 TextRank 알고리즘을 사용합니다. 빠르고 정확하지만, 원문의 표현에 갇힙니다. 생성 요약(Abstractive Summarization)은 LLM으로 새로 씁니다. 더 간결하고 유연하지만, 환각 위험이 있습니다. 실무에서는 하이브리드를 씁니다. 추출로 핵심 문장을 찾고, 그것을 기반으로 생성합니다.
도구 출력도 압축 대상입니다. API가 10,000줄의 JSON을 반환했다면? 전체를 컨텍스트에 넣으면 토큰이 폭증합니다. 필요한 필드만 추출합니다. 배열은 상위 N개만 유지합니다. 중첩 객체는 평탄화합니다. 10,000 토큰이 500 토큰으로 줄어듭니다.
계층적 압축도 있습니다. 대용량 문서를 청크로 나눕니다. 각 청크를 요약합니다. 요약들을 다시 요약합니다. 피라미드 구조입니다. 필요에 따라 적절한 레벨을 선택합니다. 개요만 필요하면 최상위 요약, 세부사항이 필요하면 중간 레벨, 원문이 필요하면 하위 레벨입니다.
중요한 것은 정보 손실과 토큰 절감의 균형입니다. 너무 압축하면 중요한 정보를 잃습니다. 너무 적게 압축하면 효과가 없습니다. 실험과 평가가 필요합니다. A/B 테스트로 최적 압축률을 찾습니다.
Isolate: 컨텍스트를 분리하기
네 번째 전략은 격리입니다. 하나의 큰 컨텍스트가 아니라 여러 개의 작은 컨텍스트로 나눕니다. 멀티 에이전트 패턴의 핵심입니다.
문제 상황을 생각해봅시다. 복잡한 보고서를 작성합니다. 데이터 수집, 분석, 시각화, 글쓰기가 필요합니다. 단일 에이전트로 하면 어떻게 될까요? 모든 단계의 컨텍스트가 섞입니다. 데이터 수집 결과, 분석 코드, 차트 생성 스크립트, 글쓰기 가이드라인이 동시에 컨텍스트에 있습니다. 100,000 토큰입니다. Context Rot가 발생합니다.
멀티 에이전트로 하면 어떻게 될까요? DataCollector 에이전트가 먼저 작동합니다. 컨텍스트에는 데이터 소스 정보와 수집 도구만 있습니다. 5,000 토큰입니다. 결과를 외부 메모리에 저장합니다. Analyzer 에이전트가 이어받습니다. 컨텍스트에는 수집된 데이터와 분석 도구만 있습니다. 8,000 토큰입니다. 분석 결과를 저장합니다. Visualizer가 차트를 만들고, Writer가 글을 씁니다. 각각 10,000 토큰 이하입니다.
총 토큰은 더 많을 수 있습니다. 하지만 각 에이전트는 자신의 작업에 집중합니다. 컨텍스트가 깨끗합니다. 노이즈가 없습니다. 각 에이전트의 성능이 최적화됩니다. 그리고 병렬화할 수 있습니다. DataCollector가 끝나면 Analyzer와 Visualizer를 동시에 돌립니다. 시간도 절약됩니다.
격리는 에러 격리도 제공합니다. Analyzer가 실패해도 DataCollector는 영향받지 않습니다. 재시도가 쉽습니다. 디버깅이 쉽습니다. 각 에이전트의 입출력이 명확하니까요.
LangGraph가 이것을 쉽게 만듭니다. 각 에이전트는 노드입니다. 엣지는 데이터 흐름입니다. 상태는 외부 객체로 관리됩니다. 체크포인트를 찍어 복구할 수 있습니다. 일시 중지하고 재개할 수 있습니다.
실무에서는 이 4가지 전략을 조합합니다. Write로 외부 메모리를 만들고, Select로 관련 정보를 가져오고, Compress로 압축하고, Isolate로 에이전트를 분리합니다. 각 단계마다 토큰이 줄어듭니다. 품질은 유지되거나 향상됩니다. 이것이 진정한 컨텍스트 엔지니어링입니다.
제5장: 메모리 시스템 - AI의 장기 기억을 설계하기
메모리 계층의 필요성
컨텍스트 윈도우는 단기 기억입니다. 세션이 끝나면 사라집니다. 하지만 실전 에이전트는 장기 기억이 필요합니다. 고객 정보를 기억하고, 이전 대화를 참조하고, 학습한 것을 축적해야 합니다. 이것이 메모리 시스템입니다.
인간의 메모리를 모델로 삼을 수 있습니다. 심리학은 메모리를 3계층으로 나눕니다. 감각 기억(Sensory Memory)은 1초도 안 됩니다. 보고 듣는 순간입니다. 단기 기억(Short-term Memory)은 몇 초에서 몇 분입니다. 전화번호를 외우는 것입니다. 장기 기억(Long-term Memory)은 평생입니다. 어린 시절 추억입니다.
AI 메모리도 비슷하게 설계할 수 있습니다. 작업 메모리(Working Memory)는 컨텍스트 윈도우입니다. 지금 이 순간 필요한 정보입니다. 8,000 토큰 정도입니다. 지연 시간이 0입니다. 즉시 접근 가능합니다. 하지만 휘발성입니다. 세션 종료시 사라집니다.
단기 메모리(Short-term Memory)는 세션 내에서 유지됩니다. 대화 이력, 중간 결과, 임시 메모입니다. 50,000 토큰까지 가능합니다. 빠른 검색이 가능합니다. 인메모리 자료구조나 Redis 같은 것입니다. 세션이 끝나면 사라지거나 장기로 이동합니다.
장기 메모리(Long-term Memory)는 영구 저장소입니다. 벡터 데이터베이스, 지식 그래프, SQL 데이터베이스입니다. 용량 제한이 사실상 없습니다. 하지만 검색이 필요합니다. 지연 시간이 있습니다. 데이터베이스 쿼리나 벡터 검색을 해야 합니다.
핵심은 계층 간 이동입니다. 자주 사용하는 정보는 상위 계층으로 올라갑니다. 캐싱입니다. 오래 사용하지 않는 정보는 하위 계층으로 내려갑니다. 축출입니다. 인간이 최근 일은 잘 기억하지만 오래된 일은 흐릿한 것과 같습니다.
Vector Store의 한계
RAG의 기본은 벡터 데이터베이스입니다. 텍스트를 임베딩으로 변환하고, 벡터 공간에 저장하고, 유사도로 검색합니다. 간단하고 효과적입니다. 하지만 한계가 있습니다.
첫째, 관계 정보가 손실됩니다. “고객 김철수가 제품 A를 2024년 1월 15일에 구매했다”는 사실을 벡터화하면, 고객-제품-날짜의 관계 구조가 사라집니다. 단지 의미론적 공간의 한 점이 됩니다. “제품 A를 산 고객들이 또 뭘 샀나요?”같은 질문에 답할 수 없습니다. 벡터 검색으로는 관계를 추적할 수 없습니다.
둘째, 시간 정보가 부재합니다. 벡터는 정적입니다. 언제 생성되었는지, 언제 업데이트되었는지 알 수 없습니다. 최신 정보인지 오래된 정보인지 판단이 어렵습니다. 타임스탬프를 메타데이터로 추가할 수 있지만, 시간 범위 쿼리가 비효율적입니다.
셋째, 복잡한 쿼리가 불가능합니다. “2024년 1월에 제품 A를 구매한 고객 중 3월에 반품하지 않은 사람들”같은 다단계 논리 쿼리는 벡터 검색만으로는 할 수 없습니다. SQL이나 그래프 쿼리가 필요합니다.
Knowledge Graph의 장점
지식 그래프는 이 문제를 해결합니다. 노드와 엣지로 정보를 표현합니다. 고객은 노드, 제품도 노드, 구매는 엣지입니다. 엣지에 날짜, 금액, 상태 같은 속성이 붙습니다. 이제 그래프 쿼리로 복잡한 질문에 답할 수 있습니다.
“제품 A를 구매한 고객들”은 제품 A 노드에서 나가는 ‘구매’ 엣지를 따라갑니다. “그 고객들이 또 구매한 제품들”은 그 고객 노드들에서 나가는 다른 ‘구매’ 엣지를 따라갑니다. “1월에서 3월 사이”는 엣지의 날짜 속성을 필터링합니다. 그래프 순회로 답을 찾습니다.
시간 정보를 추가하면 Temporal Knowledge Graph가 됩니다. 각 사실에 유효 기간이 있습니다. “김철수는 서울에 산다”는 2024년 1월부터 유효합니다. “김철수는 부산으로 이사했다”는 2024년 6월부터 유효합니다. 시점을 지정해서 쿼리할 수 있습니다. “2024년 3월에 서울에 살던 고객은?”
하지만 지식 그래프도 완벽하지 않습니다. 구조화된 정보에는 좋지만, 비구조화된 텍스트 검색에는 약합니다. “Python 비동기 프로그래밍”같은 의미론적 쿼리는 벡터 검색이 낫습니다. 그래프 구축과 유지보수가 복잡합니다. 스키마 설계가 필요하고, 데이터 정제가 중요합니다.
하이브리드 시스템
실무 해답은 하이브리드입니다. 벡터 데이터베이스와 지식 그래프를 함께 씁니다. 각각의 강점을 활용합니다.
문서 검색은 벡터 DB입니다. 사용자가 “비동기 프로그래밍 가이드”를 요청하면, 임베딩으로 관련 문서를 찾습니다. 빠르고 유연합니다. 정확한 키워드 매칭이 필요 없습니다. 의미가 비슷하면 찾습니다.
사실 확인은 지식 그래프입니다. “이 고객이 지난달에 뭘 샀나?”는 그래프 쿼리입니다. 정확하고 구조적입니다. 관계를 추적하고, 집계하고, 필터링합니다.
복합 쿼리는 두 가지를 조합합니다. “Python 비동기 프로그래밍에 관심 있는 고객에게 추천할 제품”은 먼저 벡터 검색으로 관련 문서를 찾고, 그 문서를 읽은 고객을 그래프에서 찾고, 그 고객들이 구매한 제품을 다시 그래프에서 찾습니다. 의미론적 유사도와 구조적 관계를 모두 활용합니다.
Zep 같은 도구가 이것을 통합합니다. 세션 메모리, 벡터 검색, 지식 그래프 추출을 자동화합니다. 대화 중 중요한 사실을 감지하고, 자동으로 그래프에 추가합니다. “제 이름은 김철수입니다”라고 하면, (user, hasName, “김철수”) 트리플이 생성됩니다. 나중에 “제 이름이 뭐죠?”라고 물으면 그래프에서 찾습니다.
계층적 메모리와 하이브리드 저장소를 결합하면 강력한 에이전트를 만들 수 있습니다. 즉시 필요한 정보는 작업 메모리에, 세션 동안 필요한 정보는 단기 메모리에, 영구 보관할 정보는 벡터 DB와 지식 그래프에 분산 저장합니다. 검색은 계층을 따라 올라갑니다. 작업 메모리에 없으면 단기 메모리를 보고, 거기도 없으면 장기 메모리를 검색합니다. 찾은 정보는 상위 계층으로 캐싱됩니다. 다음번에는 더 빠릅니다.
제6장: 실전 구현 - 프로덕션급 시스템 만들기
전체 아키텍처 설계
지금까지 배운 모든 원칙을 통합해봅시다. 프로덕션 환경에서 실제로 작동하는 컨텍스트 엔지니어링 시스템입니다. 고객 지원 챗봇을 예로 들겠습니다. 수천 명의 고객이 동시에 사용하고, 각 대화가 수십 턴에 걸치고, 제품 문서가 수백 페이지이고, 히스토리를 기억해야 합니다.
시스템은 여러 레이어로 구성됩니다. 최상위는 대화 관리자입니다. 사용자 입력을 받아 응답을 반환합니다. 단순해 보이지만 내부는 복잡합니다. 그 아래 컨텍스트 엔지니어링 엔진이 있습니다. 이것이 핵심입니다. 쿼리에 맞게 최적의 컨텍스트를 구성합니다. 메모리 시스템이 세 계층으로 작동합니다. 검색 시스템이 벡터 DB와 지식 그래프를 통합합니다. 모니터링 시스템이 모든 것을 추적합니다.
작동 방식은 이렇습니다. 사용자가 “지난번 주문이 어떻게 됐나요?”라고 묻습니다. 대화 관리자가 받아 컨텍스트 엔진에 전달합니다. 엔진은 먼저 작업 복잡도를 평가합니다. 이것은 단순 정보 검색입니다. ‘simple’ 카테고리입니다. 목표 컨텍스트 크기는 4,000 토큰입니다.
다음은 메모리 검색입니다. 계층적 메모리 시스템이 작동합니다. 작업 메모리에 현재 세션 정보가 있습니다. 사용자 ID, 세션 시작 시간, 최근 3턴 대화입니다. 500 토큰입니다. 단기 메모리를 검색합니다. 이 세션의 이전 대화가 요약되어 있습니다. “사용자는 제품 A에 대해 문의했고, 배송 지연 문제를 보고했다.” 200 토큰입니다.
장기 메모리를 쿼리합니다. 지식 그래프에서 사용자의 주문 이력을 찾습니다. “2024년 12월 20일 주문 번호 ORDER_12345, 제품 A, 상태: 배송 중” 100 토큰입니다. 벡터 DB에서 관련 문서를 검색합니다. “배송 추적 가이드” 1,000 토큰입니다.
이제 컨텍스트를 구성합니다. 계층적 구조입니다. 레벨 1은 핵심 작업입니다. “사용자 쿼리: 지난번 주문 상태 확인. 주문 번호: ORDER_12345” 50 토큰입니다. 레벨 2는 주요 정보입니다. 주문 상세, 현재 배송 상태, 예상 도착일입니다. 300 토큰입니다. 레벨 3은 참조 정보입니다. 배송 추적 가이드의 관련 섹션입니다. 1,000 토큰입니다. 레벨 4는 컨텍스트입니다. 이전 대화 요약입니다. 200 토큰입니다.
총 1,550 토큰입니다. 목표인 4,000 토큰보다 훨씬 적습니다. 여유가 있습니다. 좋습니다. Claude API를 호출합니다. 응답이 옵니다. “ORDER_12345 주문은 현재 배송 중이며, 예상 도착일은 12월 27일입니다. 배송 추적은 [링크]에서 확인하실 수 있습니다.”
응답을 평가합니다. 정확한가? 주문 정보가 맞습니다. 유용한가? 사용자가 원하는 정보를 제공했습니다. 안전한가? 개인정보가 적절히 처리되었습니다. 메트릭을 수집합니다. 총 토큰: 1,550 + 200(응답) = 1,750. 응답 시간: 1.2초. 정확도 점수: 0.95.
모니터링 시스템이 기록합니다. 이 세션의 컨텍스트 크기는 1,750이었고, 응답 품질은 우수했고, 시간은 목표 내였습니다. 정상입니다. 만약 컨텍스트가 50,000 토큰이었다면? 경고를 발생시킵니다. Context Rot 위험입니다. 자동으로 압축 모드로 전환합니다.
메모리를 업데이트합니다. 이 교환이 중요한가? “주문 상태 확인”은 일상적입니다. 단기 메모리에 추가하지만 장기 메모리까지는 아닙니다. 하지만 만약 “제품에 결함이 있어요”였다면? 중요합니다. 지식 그래프에 추가합니다. (user_12345, reported_defect, product_A, 2024-12-25) 트리플이 생성됩니다.
성능 최적화 기법
프로덕션에서는 성능이 생명입니다. 느린 응답은 사용자 이탈로 이어집니다. 비용 폭증은 사업성을 위협합니다. 최적화가 필수입니다.
첫 번째는 캐싱입니다. Anthropic의 Prompt Caching을 활용합니다. 시스템 프롬프트와 도구 정의는 거의 변하지 않습니다. 매번 같은 토큰을 보내는 것은 낭비입니다. 캐싱하면 90% 할인됩니다. 1,000 토큰짜리 시스템 프롬프트가 있다면, 첫 요청은 풀 프라이스지만 이후는 100 토큰 가격입니다.
캐시 키를 신중히 설계해야 합니다. 너무 특정적이면 캐시 히트율이 낮습니다. 너무 일반적이면 부정확한 컨텍스트를 재사용합니다. 사용자별로 캐시하되, 공통 부분은 공유합니다. 시스템 프롬프트는 전체 공유, 도구 정의는 역할별 공유, 사용자 데이터는 개인별 저장입니다.
두 번째는 프리페칭입니다. 사용자가 질문하기 전에 미리 데이터를 로드합니다. 세션 시작 시 사용자 프로필을 가져옵니다. 최근 주문, 선호도, 이전 문의를 미리 메모리에 올립니다. 첫 질문이 들어오면 이미 준비되어 있습니다. 지연 시간이 줄어듭니다.
세 번째는 배치 처리입니다. 여러 사용자의 요청을 모아서 한 번에 처리합니다. 벡터 검색은 배치가 효율적입니다. 10개 쿼리를 따로 하는 것보다 한 번에 하는 것이 빠릅니다. 지식 그래프 쿼리도 마찬가지입니다. 물론 지연 시간이 약간 증가하지만, 처리량이 크게 늘어납니다.
네 번째는 적응형 품질입니다. 모든 쿼리가 최고 품질을 필요로 하지 않습니다. “안녕하세요”같은 인사는 간단한 템플릿 응답이면 됩니다. LLM을 호출할 필요가 없습니다. “계정 삭제 방법”같은 FAQ는 검색만으로 충분합니다. 복잡한 문제 해결만 full context로 처리합니다. 80%의 쿼리를 경량 처리하면 전체 비용이 급감합니다.
에러 처리와 복구
프로덕션에서는 모든 것이 실패할 수 있습니다. API가 타임아웃 되고, 데이터베이스가 느려지고, 메모리가 부족합니다. 우아한 실패(graceful degradation)가 필요합니다.
컨텍스트가 너무 크면 어떻게 할까요? 긴급 압축 모드로 전환합니다. 가장 오래된 대화 이력을 제거합니다. 문서를 요약으로 교체합니다. 목표 크기에 맞출 때까지 계속 줄입니다. 사용자에게는 “복잡한 질문이니 조금 시간이 걸립니다”라고 알립니다.
API 호출이 실패하면? 재시도합니다. 지수 백오프로 간격을 늘려가며 3번까지 시도합니다. 그래도 실패하면 폴백 응답을 제공합니다. “죄송합니다. 일시적 문제가 발생했습니다. 잠시 후 다시 시도해주세요.” 하지만 세션 상태는 보존합니다. 사용자가 재시도하면 처음부터 다시 시작하지 않습니다.
메모리 검색이 느리면? 타임아웃을 설정합니다. 2초 안에 결과가 안 오면 캐시된 데이터나 최근 데이터만 사용합니다. 완벽하지 않아도 빠른 응답이 낫습니다. 백그라운드에서 검색을 계속하고, 결과가 나오면 다음 턴에 활용합니다.
Context Rot이 감지되면? 즉시 컨텍스트를 축소합니다. 현재 대화만 유지하고 나머지는 제거합니다. 클린 슬레이트로 시작합니다. 사용자에게는 “대화가 길어져서 요약하겠습니다”라고 알립니다. 투명성이 중요합니다.
보안과 프라이버시
컨텍스트에는 민감한 정보가 들어갑니다. 사용자 이름, 주소, 주문 내역, 결제 정보입니다. 보호해야 합니다.
첫째, 최소 권한 원칙입니다. 각 에이전트는 필요한 정보만 접근합니다. 고객 지원 에이전트는 주문 정보를 볼 수 있지만, 결제 카드 번호는 볼 수 없습니다. 마스킹됩니다. “**--**-1234”로 표시됩니다. 분석 에이전트는 집계 데이터만 봅니다. 개인 식별 정보는 제거됩니다.
둘째, 암호화입니다. 메모리에 저장되는 데이터는 암호화됩니다. 특히 장기 메모리입니다. 벡터 DB에 저장하기 전에 민감 필드를 암호화합니다. 지식 그래프의 엣지 속성도 마찬가지입니다. 키 관리가 중요합니다.
셋째, 로깅과 감사입니다. 누가, 언제, 어떤 데이터에 접근했는지 기록합니다. 이상 패턴을 감지합니다. 한 사용자가 1분에 100번 검색한다면? 봇일 수 있습니다. 차단합니다. 데이터 유출 시도를 모니터링합니다.
넷째, 데이터 보존 정책입니다. 모든 데이터를 영원히 보관하지 않습니다. 법적 요구사항과 비즈니스 필요에 따라 보존 기간을 설정합니다. 90일 후 대화 이력은 자동 삭제됩니다. 사용자가 요청하면 즉시 삭제합니다. GDPR의 “잊힐 권리”를 존중합니다.
제7장: 측정과 개선
무엇을 측정할 것인가
“측정할 수 없으면 개선할 수 없다”는 피터 드러커의 말은 컨텍스트 엔지니어링에도 적용됩니다. 하지만 무엇을 측정해야 할까요?
토큰 메트릭이 기본입니다. 총 토큰 수는 비용과 직결됩니다. 요청당 평균 토큰을 추적합니다. 목표를 설정합니다. 10,000 토큰 이하로 유지하겠다. 시간에 따른 추세를 봅니다. 증가하는가? Context Rot 징후일 수 있습니다. 감소하는가? 최적화가 작동하고 있습니다.
컨텍스트 구성 비율도 중요합니다. 시스템 프롬프트가 몇 퍼센트, 대화 이력이 몇 퍼센트, 검색 문서가 몇 퍼센트인가? 균형이 맞아야 합니다. 대화 이력이 80%라면? 너무 많습니다. 압축이 필요합니다. 검색 문서가 5%라면? 너무 적습니다. 더 많은 컨텍스트를 제공해야 할 수 있습니다.
품질 메트릭은 더 중요합니다. 정확도를 측정합니다. 응답이 사실적으로 맞는가? 인간 평가자가 샘플을 검토합니다. 또는 LLM-as-a-Judge를 사용합니다. Claude에게 다른 Claude의 응답을 평가시킵니다. 유용성도 측정합니다. 사용자가 원하는 답을 얻었는가? 후속 질문으로 추론합니다. 바로 “감사합니다”라고 하면 성공입니다. “무슨 말인지 모르겠어요”라고 하면 실패입니다.
성능 메트릭은 사용자 경험입니다. 응답 시간이 가장 직접적입니다. 90 퍼센타일을 봅니다. 평균이 아니라. 90%의 사용자가 3초 이내에 응답을 받는다면 좋습니다. 10%가 10초를 기다린다면 문제입니다. 처리량도 봅니다. 초당 몇 개 요청을 처리하는가? 부하 테스트로 한계를 찾습니다.
비용 메트릭은 사업성입니다. 사용자당 월간 API 비용을 계산합니다. 목표 대비 실제를 비교합니다. $5 이하로 유지하려 했는데 $12가 나온다면? 최적화가 시급합니다. ROI를 계산합니다. 챗봇이 고객 지원 티켓을 30% 줄인다면? 인건비 절감액과 API 비용을 비교합니다.
A/B 테스트
개선 아이디어는 많습니다. 하지만 실제로 효과가 있을까요? 추측하지 말고 테스트해야 합니다.
간단한 A/B 테스트를 설계합니다. 사용자 트래픽을 50:50으로 나눕니다. A 그룹은 기존 컨텍스트 전략을 씁니다. B 그룹은 새로운 전략을 씁니다. 예를 들어 대화 이력 압축입니다. A는 최근 10턴을 전부 포함합니다. B는 최근 3턴 + 요약을 씁니다.
일주일 후 데이터를 분석합니다. B 그룹의 평균 토큰은 30% 적습니다. 좋습니다. 비용이 줄었습니다. 하지만 품질은? 정확도가 같습니다. 유용성 점수도 비슷합니다. 응답 시간은 20% 빨라졌습니다. 명확한 승리입니다. B 전략을 전체에 배포합니다.
하지만 항상 그렇게 명확하지는 않습니다. B 그룹의 토큰은 40% 줄었지만, 정확도도 10% 떨어졌다면? 트레이드오프입니다. 비즈니스 판단이 필요합니다. 비용 절감이 품질 저하를 정당화하는가? 경우에 따라 다릅니다. 고객 지원에서는 품질 우선입니다. 브레인스토밍 도구에서는 비용 우선일 수 있습니다.
다변량 테스트도 가능합니다. 여러 변수를 동시에 테스트합니다. 압축 방법(요약 vs 추출), 메모리 계층(2단계 vs 3단계), 검색 전략(벡터만 vs 하이브리드)을 조합합니다. 8가지 변형을 만들고, 각각 12.5%의 트래픽을 할당합니다. 가장 좋은 조합을 찾습니다. 하지만 해석이 복잡합니다. 통계적 유의성을 확인해야 합니다.
지속적 개선
A/B 테스트는 일회성이 아닙니다. 계속됩니다. 이번 달의 최선이 다음 달에도 최선일까요? 아닙니다. 사용 패턴이 변합니다. 새로운 제품이 출시되고, 시즌이 바뀌고, 사용자가 익숙해집니다. 지속적 모니터링과 개선이 필요합니다.
대시보드를 만듭니다. 실시간으로 메트릭을 봅니다. 토큰 사용량, 응답 시간, 에러율, 비용이 그래프로 표시됩니다. 이상 징후를 즉시 발견합니다. 갑자기 토큰이 2배로 늘었다면? 무슨 일이 생겼습니다. 조사합니다. 새로운 제품 문서가 추가되었고, 검색 결과가 많아졌습니다. 검색 필터를 조정합니다.
주간 리뷰를 합니다. 팀이 모여 지난주 데이터를 봅니다. 무엇이 잘 됐나? 새로운 압축 알고리즘이 토큰을 15% 줄였습니다. 무엇이 안 됐나? 금요일 저녁에 응답 시간이 급증했습니다. 트래픽 스파이크였습니다. 스케일링 정책을 조정합니다.
월간 회고를 합니다. 큰 그림을 봅니다. 이번 달 목표를 달성했나? 평균 토큰을 12,000에서 8,000으로 줄이려 했습니다. 실제로 9,500입니다. 부분 성공입니다. 왜 목표에 못 미쳤나? 특정 유형의 쿼리(기술 지원)가 여전히 토큰을 많이 씁니다. 다음 달 초점은 여기입니다.
사용자 피드백을 수집합니다. 정량 메트릭만으로는 부족합니다. 정성적 인사이트가 필요합니다. 만족도 설문을 보냅니다. “응답이 도움이 되었나요?” 5점 척도입니다. 낮은 점수에는 왜 그런지 묻습니다. “너무 일반적이었어요”, “제가 물은 게 아니에요”, “너무 기술적이에요” 같은 답변이 옵니다. 패턴을 찾습니다. 개선점을 도출합니다.
맺음말: 컨텍스트 엔지니어링의 미래
우리는 AI 에이전트 시대의 초입에 있습니다. Claude Code가 개발자 워크플로우를 바꾸고, 챗봇이 고객 지원을 자동화하고, 연구 에이전트가 논문을 요약합니다. 하지만 이것은 시작일 뿐입니다. 진짜 에이전트는 며칠, 몇 주, 몇 달에 걸친 작업을 수행할 것입니다. 대규모 소프트웨어 프로젝트를 관리하고, 복잡한 연구를 수행하고, 장기 고객 관계를 유지할 것입니다.
그러려면 컨텍스트 관리가 더욱 중요해집니다. 1M 토큰 윈도우도 충분하지 않을 것입니다. 100M 토큰이어도 마찬가지입니다. Context Rot는 근본적 한계입니다. 어텐션 메커니즘의 구조적 문제입니다. 더 큰 윈도우가 아니라 더 스마트한 관리가 답입니다.
컨텍스트 엔지니어링은 계속 진화할 것입니다. 새로운 패턴이 발견되고, 새로운 도구가 등장하고, 새로운 연구가 발표될 것입니다. Agent-Skills 같은 오픈 소스 프로젝트가 지식을 공유하고, 커뮤니티가 함께 배우고, 표준이 형성될 것입니다. agentskills.io 같은 오픈 스탠다드가 플랫폼 간 호환성을 보장할 것입니다.
개발자로서 우리의 역할도 바뀔 것입니다. 단순히 프롬프트를 쓰는 것을 넘어, AI의 인지 아키텍처를 설계하게 될 것입니다. 어떤 정보를 언제 로드할지, 어떻게 구조화할지, 언제 잊을지 결정합니다. 마치 데이터베이스 아키텍트가 스키마를 설계하고 인덱스를 최적화하듯, 우리는 컨텍스트를 설계하고 메모리를 최적화합니다.
이 가이드가 그 여정의 시작점이 되기를 바랍니다. 여기 담긴 원칙들은 검증되었습니다. Progressive Disclosure, 계층적 메모리, 4대 전략은 실제로 작동합니다. Context Rot은 실재하는 문제이고, 우리는 해결 방법을 알고 있습니다. Agent-Skills의 지혜와 Anthropic의 도구를 결합하면 강력한 에이전트를 만들 수 있습니다.
하지만 이것은 레시피가 아닙니다. 맹목적으로 따를 지침이 아닙니다. 원칙입니다. 이해하고, 적용하고, 조정해야 합니다. 여러분의 도메인, 사용자, 제약사항에 맞게 변형해야 합니다. 실험하고, 측정하고, 배워야 합니다. 실패는 학습의 기회입니다. 성공은 공유해야 할 지식입니다.
컨텍스트 엔지니어링은 예술이자 과학입니다. 데이터와 직관, 이론과 실전, 최적화와 창의성의 균형입니다. 완벽한 답은 없습니다. 항상 더 나은 방법이 있습니다. 그것을 찾는 과정이 바로 엔지니어링입니다.
이제 시작하십시오. 작게 시작하십시오. 간단한 챗봇에 계층적 메모리를 추가해보십시오. RAG 시스템에 Distractor 필터를 적용해보십시오. 토큰을 측정하고, 품질을 평가하고, 개선하십시오. 실패해도 괜찮습니다. 배우면 됩니다. 성공하면 공유하십시오. 커뮤니티가 함께 성장합니다.
컨텍스트 엔지니어링의 미래는 우리가 함께 만들어갑니다. 여러분의 기여를 기대합니다.
행운을 빕니다. 🚀
작성 일자: 2025-12-25