작게 시작해야 오래 간다
컨텍스트 엔지니어링은 거대한 플랫폼을 먼저 사는 일에서 시작하지 않는다. 첫걸음은 AI가 작업을 시작하기 전에 반드시 알아야 할 정보를 한곳에 적는 것이다. 개인 프로젝트라면 AGENTS.md, CLAUDE.md, SKILL.md 같은 파일이 좋은 출발점이다.
이 파일에는 화려한 설명보다 실행 가능한 규칙을 적어야 한다.
빌드 명령:
npm run build,pytest,pnpm test처럼 실제로 검증할 명령테스트 절차: 어떤 변경 후 어떤 테스트를 반드시 돌릴지
코딩 규칙: 파일 구조, 네이밍, 에러 처리 방식, 금지 패턴
작업 흐름: 이슈 확인 → 계획 작성 → 구현 → 테스트 → 요약 보고
산출물 형식: PR 설명, 변경 요약, 체크리스트 형식
핵심은 "AI에게 친절한 온보딩 문서"를 만드는 것이다. 신입 개발자가 프로젝트에 들어왔을 때 필요한 정보가 있다면, 에이전트에게도 필요하다. 다만 에이전트에게는 더 명시적으로 써야 한다. "알아서 해줘"가 아니라 "이 저장소에서는 API 변경 시 계약 테스트를 먼저 갱신한다"처럼 판단 기준을 문장으로 남겨야 한다.
SKILL.md는 특히 반복 업무에 유용하다. 예를 들어 "릴리스 노트 작성", "버그 재현 보고서 작성", "마이그레이션 PR 검토"처럼 자주 반복되는 절차를 하나의 기술 단위로 분리한다. 모든 지침을 항상 컨텍스트에 넣지 않고, 필요한 작업에서만 해당 스킬을 불러오면 컨텍스트가 가벼워진다. 이는 필요한 정보만 단계적으로 노출하는 방식이며, 여러 에이전트 도구가 채택하는 실용적 패턴이기도 하다.1
처음부터 완벽한 메모리 시스템을 만들 필요는 없다. 한 개의 컨텍스트 파일, 한 개의 체크리스트, 한 개의 작업 로그면 충분하다. 중요한 것은 AI가 매번 같은 질문을 반복하지 않게 만들고, 사람이 매번 같은 설명을 다시 하지 않게 만드는 것이다.
개인 프로젝트에서 팀 워크플로로
두 번째 단계는 컨텍스트를 개인 파일에서 팀의 업무 흐름으로 옮기는 것이다. 이때 가장 좋은 저장소는 이미 팀이 쓰고 있는 도구다. GitHub Issue, Linear, Jira, Notion, Confluence, Slack 스레드가 모두 후보가 된다.
많은 팀이 실패하는 이유는 AI용 컨텍스트를 별도로 만들기 때문이다. 별도 문서는 빠르게 낡는다. 반대로 티켓, PR, 설계 문서, 운영 로그처럼 실제 업무가 흐르는 곳에 컨텍스트를 남기면 사람과 AI가 같은 문맥을 공유할 수 있다.
예를 들어 기능 개발을 시작하기 전에 티켓에 다음 항목을 적는다.
문제 정의: 사용자가 겪는 불편은 무엇인가
변경 범위: 수정할 모듈과 건드리지 말아야 할 영역
결정 사항: 이미 합의된 정책과 논의 결과
수용 기준: 완료를 판단하는 테스트 또는 화면 동작
관련 링크: PR, 장애 로그, 고객 문의, 이전 실험
이런 티켓은 단순한 업무 관리 도구가 아니라 컨텍스트 패킷이 된다. 실제 개발팀에서도 MCP를 통해 Linear 같은 티켓 시스템을 에이전트와 연결하고, 이슈의 상태·우선순위·하위 작업 같은 메타데이터를 함께 전달해 작업 계획과 실행을 정렬하는 방식이 활용되고 있다.2
여기서 중요한 원칙은 하나다. 컨텍스트는 사람이 읽어도 유용해야 한다. AI만을 위한 비밀 프롬프트는 오래 유지되지 않는다. 팀원이 읽고 이해할 수 있는 문서, 리뷰할 수 있는 결정 로그, 재사용할 수 있는 체크리스트가 좋은 컨텍스트의 기반이다.
기존 챗봇과 RAG 서비스의 성숙도 높이기
이미 챗봇이나 RAG 서비스를 운영하고 있다면, 한 번에 에이전트 플랫폼으로 바꾸려 하지 말아야 한다. 성숙도는 순서대로 높이는 것이 안전하다.
첫 단계는 관측성이다. 어떤 사용자 질문에 어떤 문서가 검색되었고, 어떤 컨텍스트가 모델에 들어갔고, 최종 답변이 어떤 근거를 사용했는지 기록한다. 이 로그가 없으면 개선은 감으로만 이루어진다.
두 번째는 검색 품질 개선이다. 단순 벡터 검색만으로 부족하다면 키워드 검색, 메타데이터 필터, 권한 필터, 재순위화를 추가한다. 엔터프라이즈 환경에서는 관련성만큼 권한도 중요하다. 사용자가 볼 수 없는 문서는 모델도 보지 못해야 한다. Elastic은 컨텍스트 엔지니어링의 핵심을 데이터 연결, 검색, 도구, 메모리, 보안과 관측성의 결합으로 설명한다.3
세 번째는 대화 기록 관리다. 모든 대화를 계속 붙이는 방식은 비용과 품질을 동시에 악화시킨다. 오래된 대화는 버리거나, 요약하거나, 상태로 승격해야 한다. OpenAI의 세션 메모리 예시도 최근 턴만 유지하는 트리밍과 오래된 대화를 구조화 요약으로 대체하는 방식을 구분한다.4
네 번째는 메모리다. 처음부터 장기 기억을 자동으로 쓰게 만들면 위험하다. 먼저 사용자가 명시적으로 저장한 선호, 프로젝트 설정, 반복되는 업무 규칙부터 저장한다. 이후 성공한 답변 패턴, 자주 쓰는 도구 조합, 실패한 검색 쿼리까지 확장한다.
다섯 번째는 도구 선택이다. 에이전트에게 모든 도구를 한꺼번에 보여주지 않는다. 현재 작업에 맞는 도구만 선택해 제공한다. 도구가 많아질수록 모델은 더 똑똑해지는 것이 아니라 더 헷갈릴 수 있다. 컨텍스트 성숙도는 도구 수가 아니라, 필요한 순간에 필요한 도구만 보이게 하는 능력으로 결정된다.
자기 개선형 컨텍스트: 실행, 반영, 큐레이션
성숙한 컨텍스트 시스템은 단순히 정보를 넣고 답을 받는 구조가 아니다. 실행 결과를 다시 컨텍스트 자산으로 바꾼다. 이를 세 단계로 볼 수 있다.
첫째, 실행이다. 에이전트는 작업을 수행하고, 사용한 입력·도구·검색 결과·오류·최종 산출물을 남긴다.
둘째, 반영이다. 작업이 끝난 뒤 시스템이나 사람이 결과를 평가한다. 무엇이 잘 작동했는지, 어떤 정보가 부족했는지, 어떤 도구 선택이 틀렸는지 짧게 기록한다.
셋째, 큐레이션이다. 모든 실행 로그를 메모리로 승격하지 않는다. 반복 가치가 있는 것만 플레이북, 스킬, 정책, 테스트 케이스로 정리한다.
이 패턴을 "실행-반영-큐레이션" 루프로 운영하면 조직은 점점 더 좋은 컨텍스트를 갖게 된다. 실패한 프롬프트가 사라지는 것이 아니라, "다음에는 이렇게 묻지 말 것"이라는 규칙이 된다. 성공한 워크플로는 "이 상황에서는 이 순서로 도구를 호출할 것"이라는 플레이북이 된다.
여기서 조심할 점은 자동 학습의 과신이다. 실패 로그를 그대로 장기 메모리에 넣으면 오염이 된다. 성공 사례도 맥락 없이 복사하면 과적합이 된다. 자기 개선형 컨텍스트는 모든 것을 기억하는 시스템이 아니라, 기억할 가치가 있는 것을 선별하는 시스템이다.
기업용 에이전트 플랫폼으로 확장하기
기업 단계에서는 컨텍스트가 더 이상 프롬프트나 RAG 파이프라인의 일부가 아니다. 조직 인프라가 된다. 이때 필요한 구성은 네 가지다.
첫째, 표준 연결 계층이다. MCP는 AI 애플리케이션이 외부 도구와 데이터 소스에 연결되는 방식을 표준화하려는 흐름이다. 2026년 로드맵에서도 원격 서버 확장성, 에이전트 작업 생명주기, 거버넌스, 기업 준비성이 핵심 우선순위로 제시된다.5 이는 컨텍스트가 로컬 파일을 넘어 조직의 SaaS, 데이터베이스, 업무 시스템으로 확장되고 있음을 보여준다.
둘째, 에이전트 간 통신 계층이다. MCP가 주로 에이전트와 도구의 연결을 다룬다면, A2A 같은 흐름은 에이전트와 에이전트 사이의 위임, 상태 전달, 결과 계약을 다룬다. 앞으로의 시스템은 하나의 거대한 에이전트가 아니라, 역할이 나뉜 여러 에이전트가 구조화된 산출물을 주고받는 형태에 가까워질 것이다.
셋째, 컨텍스트 그래프다. 기업 지식은 문서 더미가 아니라 관계망이다. 고객, 계약, 제품, 장애, 코드, 담당자, 정책은 서로 연결되어 있다. Zep 같은 메모리 플랫폼은 대화와 비즈니스 데이터를 엔터티·관계·사실로 추출하고 시간에 따라 변하는 컨텍스트 그래프로 조립하는 방향을 보여준다.6 앞으로의 RAG는 문서를 찾는 수준을 넘어, 조직의 의미 관계를 탐색하는 방식으로 발전할 것이다.
넷째, ContextOps다. MLOps가 모델을 운영 대상으로 만들었듯이, ContextOps는 컨텍스트를 운영 대상으로 만든다. 컨텍스트의 버전, 출처, 권한, 품질, 사용량, 비용, 실패율을 관리한다. 어떤 컨텍스트 조각이 어떤 답변에 영향을 주었는지 추적하고, 잘못된 정책 문서가 여러 에이전트에 퍼지기 전에 차단한다.
이 단계에서 필요한 것이 에이전트 하네스다. 하네스는 에이전트를 감싸는 실행 환경이다. 입력 조립, 도구 권한, 상태 저장, 테스트, 롤백, 감사 로그를 제공한다. 좋은 하네스가 있으면 개별 에이전트는 바뀌어도 조직의 컨텍스트 규칙은 유지된다.
도입 로드맵
실무에서는 다음 순서를 추천한다.
1주차: 컨텍스트 파일 만들기
저장소 루트에AGENTS.md나CLAUDE.md를 만들고 빌드, 테스트, 규칙, 금지 사항을 적는다.2~4주차: 반복 업무를 스킬로 분리하기
PR 리뷰, 릴리스 노트, 장애 분석처럼 반복되는 절차를SKILL.md또는 플레이북으로 만든다.1~2개월차: 티켓과 PR을 컨텍스트 소스로 만들기
이슈 템플릿에 문제 정의, 수용 기준, 관련 링크, 결정 사항을 넣는다.2~3개월차: RAG와 대화 기록에 관측성 추가하기
검색 결과, 주입 컨텍스트, 답변, 사용자 피드백을 연결해 기록한다.3~6개월차: 메모리와 요약 정책 도입하기
최근 대화, 장기 메모리, 요약본, 원본 로그의 역할을 분리한다.6개월 이후: ContextOps로 운영하기
권한, 버전, 평가, 비용, 감사 로그를 표준 파이프라인으로 묶는다.
이 로드맵의 목적은 AI를 더 많이 쓰는 것이 아니다. 조직이 알고 있는 것을 AI가 안전하게 사용할 수 있는 형태로 바꾸는 것이다.
미래의 컨텍스트 엔지니어링
앞으로 모델은 더 길고 복잡한 입력을 처리할 것이다. 하지만 컨텍스트 엔지니어링의 중요성은 줄어들지 않는다. 컨텍스트 창이 커질수록 "무엇을 넣을 수 있는가"보다 "무엇을 넣지 않을 것인가"가 더 중요해진다.
미래의 컨텍스트 엔지니어링은 세 방향으로 발전할 가능성이 크다.
첫째, 컨텍스트는 파일에서 그래프로 이동한다. 문서 검색은 시작점일 뿐이다. 에이전트는 조직의 개념, 사람, 결정, 시스템 의존성을 그래프로 이해하게 된다.
둘째, 컨텍스트는 수동 작성에서 운영 자산으로 바뀐다. 플레이북, 스킬, 메모리, 평가 로그가 지속적으로 갱신되고, 오래된 컨텍스트는 폐기된다.
셋째, 컨텍스트는 개별 앱의 기능에서 조직의 공통 계층으로 이동한다. 어떤 모델을 쓰든, 어떤 에이전트 프레임워크를 쓰든, 동일한 권한·정책·지식·도구 계약을 공유해야 한다.
결국 컨텍스트 엔지니어링은 AI에게 더 긴 설명을 붙이는 일이 아니다. 조직의 지식을 실행 가능한 형태로 정리하는 일이다. 작은 프로젝트에서는 하나의 마크다운 파일로 시작한다. 팀에서는 티켓과 PR이 컨텍스트가 된다. 기업에서는 컨텍스트 그래프와 운영 파이프라인이 된다.
이 책의 핵심은 단순하다. 좋은 AI 시스템은 좋은 모델만으로 만들어지지 않는다. 좋은 컨텍스트를 만들고, 고르고, 압축하고, 격리하고, 관측하고, 다시 개선하는 조직이 만든다. 컨텍스트 엔지니어링은 한 번에 완성하는 기술이 아니라, 지식을 일하는 방식으로 바꾸는 긴 여정이다.
참고
1Agent Skills for Context Engineering
2Context Engineering? 원래 하던거 아닌가?
3Context engineering for AI agents that always know what to do
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.