AI 에이전트를 만들어본 사람이라면 한 번쯤 경험했을 거다. 프롬프트를 아무리 정교하게 써도 에이전트가 엉뚱한 도구를 호출하고, 이전 대화를 까먹고, 같은 실수를 반복한다. 모델을 바꿔봐도, 도구를 교체해봐도 상황은 비슷하다.
범인은 프롬프트가 아니다. 맥락(Context)이다.
2025년 중반 Andrej Karpathy와 Shopify CEO Tobi Lütke가 “컨텍스트 엔지니어링”이라는 용어를 본격적으로 언급하면서 업계의 관심이 쏠렸고, 2025년 9월 Anthropic이 공식 블로그에서 이 개념을 체계화했다. 그리고 최근 이 분야를 실무 수준으로 정리한 오픈소스가 하나 등장했다. GitHub 스타 11,000개를 넘긴 Agent Skills for Context Engineering이다.
이 글에서는 해당 저장소의 핵심 내용을 분석하고, 보안 엔지니어 관점에서 실무에 어떻게 적용할 수 있는지 정리한다.
컨텍스트 엔지니어링이란 무엇인가
먼저 개념을 명확히 하자. 프롬프트 엔지니어링과 컨텍스트 엔지니어링은 다른 것이다.
프롬프트 엔지니어링은 LLM에게 보내는 지시문(instruction)을 어떻게 쓸 것인가에 집중한다. “이렇게 말하면 더 잘 대답한다”는 차원의 이야기다. 한 번의 입력을 최적화하는 기술이다.
컨텍스트 엔지니어링은 그보다 상위 개념이다. LLM의 컨텍스트 윈도우에 들어가는 모든 정보를 설계하는 것이다. 시스템 프롬프트, 도구 정의, RAG로 검색한 문서, 대화 이력, 도구 실행 결과까지 전부 포함된다. Anthropic의 표현을 빌리면, “주어진 토큰 예산 안에서 원하는 결과를 일관되게 달성하기 위해 토큰의 효용을 최적화하는 엔지니어링 문제”다.
LangChain의 2025 State of Agent Engineering 리포트에 따르면 57%의 조직이 이미 AI 에이전트를 프로덕션에 배포하고 있지만, 32%가 품질을 최대 장벽으로 꼽았다. 그리고 대부분의 실패 원인은 LLM의 능력 부족이 아니라 맥락 관리 실패로 추적됐다.
Agent Skills for Context Engineering 저장소 분석
이 저장소는 캐나다 토론토 기반의 컨텍스트 엔지니어 Muratcan Koylan이 만든 커뮤니티 프로젝트다. MIT 라이선스로 공개되어 있고, 북경대학교 AI 연구소의 논문에서 인용될 정도로 학술적 깊이도 인정받고 있다.
저장소 구조는 크게 4개 카테고리의 스킬로 나뉜다.
Foundational Skills로는 context-fundamentals, context-degradation, context-compression이 있다. 맥락이 무엇인지, 어떻게 실패하는지, 어떻게 압축하는지를 다룬다. Architectural Skills에는 multi-agent-patterns, memory-systems, tool-design, filesystem-context, hosted-agents가 포함된다. 에이전트 시스템의 설계 패턴이다. Operational Skills는 context-optimization, evaluation, advanced-evaluation으로 구성되며 운영과 성능 측정을 담당한다. 그리고 Development Methodology와 Cognitive Architecture Skills가 메타 수준의 프로젝트 방법론과 BDI(Belief-Desire-Intention) 인지 모델링을 커버한다.
이 스킬들은 Claude Code 플러그인으로 직접 설치해서 사용할 수 있다. /plugin marketplace add 명령어 하나로 등록하고, 필요한 스킬만 골라서 설치하는 구조다. Cursor나 다른 IDE에서는 .rules 파일에 복사해서 적용할 수도 있다.
핵심 내용을 하나씩 뜯어보자.
핵심 원칙 1: 정보량이 아니라 정보 밀도
“토큰을 많이 넣으면 더 잘 이해하겠지?”라는 생각은 직관적이지만 틀렸다.
LLM에는 Lost-in-the-Middle이라는 잘 알려진 현상이 있다. 컨텍스트가 길어질수록 모델은 앞부분과 뒷부분에만 주의를 집중하고 중간 정보를 놓친다. U자 형태의 어텐션 커브라고 부른다. 2025년 Chroma Research가 Claude 4, GPT-4.1, Gemini 2.5 등 18개 LLM을 대상으로 테스트한 결과도 이를 뒷받침한다. 단순한 단어 반복 태스크조차 컨텍스트가 길어지면 실패율이 올라갔다. 이건 추론 능력의 문제가 아니라 어텐션 메커니즘의 근본적 한계다.
Databricks 연구에서는 Llama 3.1 405B 모델의 정확도가 32,000토큰 부근에서 하락하기 시작하는 것을 확인했다. 128K 토큰 윈도우가 있다고 해서 128K를 다 채워야 하는 게 아니라는 뜻이다.
이 저장소가 가장 먼저 강조하는 원칙도 바로 이것이다. “같은 토큰 수 안에 쓸모 있는 정보를 얼마나 밀도 높게 담았느냐.” 실제로 128K까지 채운 컨텍스트보다 32K로 압축한 버전이 정확도가 높은 경우가 많다. 처리 비용은 토큰 수에 비례하는 게 아니라 기하급수적으로 올라가고, 컨텍스트를 절반으로 줄이면 응답 대기 시간이 40~60% 단축된다.
보안 관점에서도 이 원칙은 중요하다. 컨텍스트가 비대해지면 공격 표면(attack surface)도 넓어진다. Prompt Injection 공격의 성공률은 컨텍스트 길이와 상관관계가 있다는 연구 결과도 있다. 긴 컨텍스트 안에 악성 지시문을 숨기면 모델이 놓칠 확률이 높아지기 때문이다.
핵심 원칙 2: 도구 설계가 에이전트 성능의 80%를 결정한다
프롬프트를 아무리 잘 써도 도구(Tool) 설명이 엉성하면 에이전트는 도구를 잘못 고른다. 이 저장소는 “도구는 사람이 아니라 LLM이 읽는 계약서”라고 표현한다. Anthropic의 공식 가이드에서도 가장 흔한 실패 모드로 “기능이 겹치는 도구 세트”를 꼽고 있다.
도구 설계 원칙을 정리하면 이렇다. 도구 설명에는 반드시 “언제 사용하는지”와 “무엇을 반환하는지”를 명시해야 한다. 비슷한 도구가 2개 이상이면 사람도 헷갈리는데 LLM은 더 헷갈린다. 하나의 포괄적 도구가 여러 개의 좁은 도구보다 낫다. 그리고 에러 메시지에 “다음에 뭘 해야 하는지”를 포함시켜야 에이전트가 자동 복구할 수 있다.
이건 MCP(Model Context Protocol) 서버를 설계할 때 바로 적용할 수 있는 내용이다. 내가 클로드 코드로 앱을 만들면서도 느낀 건데, 도구 설명문의 품질이 에이전트 행동의 정확도를 직접적으로 좌우한다. 도구 설명을 대충 쓰면 에이전트는 확실히 삐끗한다.
보안 엔지니어라면 여기서 한 가지 더 생각해야 한다. 도구에는 반드시 권한 범위(scope)와 에러 핸들링 정책이 명시되어야 한다. 에이전트가 잘못된 도구를 호출하는 것 자체가 보안 이벤트일 수 있다. 예를 들어 읽기 전용이어야 할 도구가 쓰기 권한을 가진 도구로 호출되는 시나리오를 생각해보면 이해가 빠르다.
핵심 원칙 3: 멀티 에이전트 아키텍처의 구조 선택
에이전트를 여러 개 띄우면 알아서 협업할 거라는 건 착각이다. 이 저장소는 세 가지 구조를 명확히 구분한다.
첫 번째는 Orchestrator(총괄) 패턴이다. 하나의 메인 에이전트가 하위 에이전트에게 작업을 지시하는 방식이다. 가장 예측 가능하고 디버깅이 쉽다. 두 번째는 Peer-to-Peer(동등) 패턴으로, 에이전트끼리 대등하게 메시지를 주고받는다. 창의적 작업에 강하지만 무한 루프 위험이 있다. 세 번째는 Hierarchical Delegation(계층적 위임) 패턴으로, 위에서 아래로 단계별로 작업을 내려보내는 구조다.
실무에서는 Orchestrator 패턴이 압도적으로 안정적이다. 그리고 에이전트 수는 3개 이하로 제한하는 게 현실적이다. 에이전트 간 통신은 벡터 검색보다 공유 파일 시스템이 구조적 쿼리에 강하다는 점도 실용적인 인사이트다.
보안 관점에서 멀티 에이전트 시스템은 각 에이전트의 권한 격리가 필수다. 하위 에이전트가 상위 에이전트의 권한을 상속받아서는 안 되고, 에이전트 간 통신 채널도 입력 검증이 필요하다. 에이전트 A가 에이전트 B에게 전달하는 데이터에 Injection 페이로드가 포함될 수 있기 때문이다. 이건 전통적인 마이크로서비스 보안에서의 서비스 간 인증(mTLS)과 유사한 문제 구조다.
핵심 원칙 4: 메모리 시스템의 4단계 구조
벡터 검색만으로는 부족하다. “고객 X가 제품 Y를 Z 날짜에 샀다”는 벡터 검색으로 찾을 수 있다. 하지만 “제품 Y를 산 고객이 또 뭘 샀는가?”는 못 찾는다. 관계 정보가 사라지기 때문이다.
이 저장소는 4단계 메모리 구조를 제안한다. Working Memory는 현재 컨텍스트 윈도우 안의 정보다. Short-term Memory는 현재 세션 내의 대화 이력이다. Long-term Memory는 세션을 넘어 지속되는 기억이다. Archival Memory는 영구 보관 아카이브다.
특히 파일 시스템을 메모리처럼 활용하는 패턴이 실용적이다. ls와 grep만으로 맥락을 탐색할 수 있고, 스크래치패드에 도구 결과를 빼놓으면 컨텍스트 윈도우를 크게 절약할 수 있다.
내가 클로드 코드로 MusicMatch 앱을 만들면서 겪은 것도 비슷한 문제였다. 세션이 길어지면 초반에 설정한 아키텍처 결정을 에이전트가 까먹는다. CLAUDE.md 파일에 핵심 결정사항을 기록해두는 것도 결국 파일 시스템 기반 메모리 패턴의 일종이다.
핵심 원칙 5: 평가 없는 에이전트는 운에 맡기는 것
가장 과소평가되지만 가장 중요한 스킬이다. 이 저장소는 LLM-as-a-Judge 평가 프레임워크를 TypeScript로 구현해서 포함하고 있다. Direct Scoring과 Pairwise Comparison 두 가지 방식을 모두 지원하고, 도메인별 채점 기준표를 AI가 자동 생성하는 기능도 있다.
인상적인 건 Position Bias 완화 기법이다. 두 응답을 비교할 때 순서를 바꿔서 두 번 평가한다. LLM은 앞에 놓인 답변을 더 좋게 평가하는 편향이 있는데, 이걸 구조적으로 잡는 거다.
평가 파이프라인을 만들어두면 프롬프트나 도구를 수정할 때마다 성능 변화를 정량적으로 비교할 수 있다. 보안 분야에서 CI/CD 파이프라인에 SAST/DAST를 통합하는 것과 같은 개념이다. 변경할 때마다 자동으로 품질을 검증하는 체계가 없으면 결국 운에 의존하게 된다.
보안 엔지니어를 위한 컨텍스트 엔지니어링 체크리스트
정보보안 실무자 입장에서 이 저장소의 원칙들을 보안 프레임워크에 매핑하면 다음과 같다.
컨텍스트 범위 최소화는 최소 권한 원칙(Principle of Least Privilege)과 동일한 개념이다. 에이전트에게 필요한 정보만 주고 나머지는 차단한다. 도구 설계의 명확한 계약은 API 보안에서의 입출력 스키마 검증과 같다. 멀티 에이전트 간 권한 격리는 Zero Trust 아키텍처의 마이크로세그멘테이션이다. 메모리 계층 구조는 데이터 분류 체계(Data Classification)와 보존 정책(Retention Policy)에 대응한다. 평가 파이프라인은 지속적 모니터링(Continuous Monitoring)이다.
AI 에이전트 시스템이 프로덕션에 배포되는 비율이 57%를 넘긴 시점에서, 에이전트 보안은 더 이상 먼 이야기가 아니다. 컨텍스트 엔지니어링은 성능 최적화이자 동시에 보안 강화 전략이다.
마무리: 에이전트가 틀릴 때 모델을 의심하지 마라
“모델이 멍청해서”라고 생각하기 전에 맥락을 먼저 까봐야 한다. 대부분의 에이전트 실패는 모델의 한계가 아니라 우리가 모델에게 제공한 정보의 문제다.
프롬프트 엔지니어링이 “무슨 말을 할 것인가”의 문제였다면, 컨텍스트 엔지니어링은 “무슨 정보를 보여줄 것인가”의 문제다. 2023년에 모두가 프롬프트 템플릿에 집착했다면, 2026년에는 컨텍스트 아키텍처를 설계하는 사람이 AI 시스템의 품질을 결정한다.
직접 확인하고 싶다면 GitHub에서 저장소를 살펴보길 추천한다.
GitHub: https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering
참고 자료
- Muratcan Koylan, “Agent Skills for Context Engineering”, GitHub, 2025
- Anthropic, “Effective context engineering for AI agents”, 2025.09
- LangChain, “2025 State of Agent Engineering Report”, 2025
- Chroma Research, “LLM Context Window Performance Study”, 2025
- Peking University, “Meta Context Engineering via Agentic Skill Evolution”, 2026
- Neo4j, “Why AI Teams Are Moving From Prompt Engineering to Context Engineering”, 2026.01
- Elastic, “Context engineering vs. prompt engineering”, 2026.01