컨텍스트 엔지니어링은 AI 에이전트가 답을 쓰거나 일을 처리하는 순간에 읽는 정보 전체를 고르고 관리하는 설계입니다. 지시문 한 편을 다듬는 프롬프트 작성과 달리, 어떤 사내 자료를 누구의 질문에, 어느 시점 기준으로, 어디서 왔는지 밝혀 넣을지를 정합니다.

한 경쟁사가 AI 에이전트로 사내 문의 응대를 시작했다는 소식이 돌고, 우리도 이번 분기 안에 시범을 보여 달라는 주문이 떨어졌다고 가정해 보겠습니다. 가장 빠른 길은 공유 드라이브를 통째로 연결하는 것처럼 보입니다. 연결은 하루면 끝나고, 시연 자리에서 「올해 출장비 기준이 어떻게 되나요」라고 물으면 에이전트는 막힘없이 답합니다.

그 답이 재작년 규정에서 나왔는지, 인사팀만 보던 초안에서 나왔는지는 화면만 봐서는 알 수 없습니다.

이 빈틈을 메우는 설계를 부르는 이름이 컨텍스트 엔지니어링입니다. AI 에이전트 구축 방법을 모델과 도구 고르기 중심으로 알아보고 있다면, 그 목록에서 빠지기 쉬운 항목이 이 설계입니다. 코드를 짜지 않는 기획·운영 담당자도 이 설계에 직접 참여하게 됩니다. 어떤 자료를 어떤 조건으로 붙일지 정하려면 그 자료를 매일 다루는 현업의 판단이 필요하기 때문입니다.

컨텍스트 엔지니어링은 프롬프트를 잘 쓰는 것과 무엇이 다른가요?

프롬프트 작성이 에이전트에게 줄 지시문을 다듬는 일이라면, 컨텍스트 엔지니어링은 그 지시문을 포함해 에이전트가 한 번에 읽게 되는 정보 전부를 고르는 일입니다. 손대는 범위가 지시문 밖으로 넓어집니다.

「컨텍스트」는 AI 모델이 답을 쓰기 직전에 눈앞에 펼쳐 놓는 글 전체를 가리킵니다. 사람으로 치면 회의 직전 책상 위에 올려 둔 서류 더미와 비슷합니다. 거기에는 우리가 쓴 지시문 말고도 앞서 나눈 대화, 에이전트가 쓸 수 있는 기능 목록, 검색해서 가져온 사내 문서가 함께 놓입니다.

2025년 9월 29일 앤트로픽이 공개한 글은 두 개념을 이렇게 나눕니다. 프롬프트 엔지니어링은 좋은 결과를 얻도록 모델에 줄 지시를 쓰고 정리하는 방법이고, 컨텍스트 엔지니어링은 모델이 답을 만드는 동안 들어갈 정보의 최적 묶음을 고르고 유지하는 전략 전체라고 정의했습니다. 앤트로픽은 후자를 전자가 자연스럽게 이어진 다음 단계로 봅니다.

두 일을 가르는 지점이 하나 더 있습니다. 앤트로픽은 프롬프트 작성을 따로 떨어진 한 건의 작업으로, 컨텍스트 선별을 모델에 무엇을 넘길지 정할 때마다 되풀이되는 일로 대비했습니다. 지시문도 시험하며 실패한 자리를 보고 보강해 가지만, 에이전트가 도구를 여러 차례 부르며 일하는 동안에는 가져온 정보가 계속 쌓이니 무엇을 남기고 무엇을 뺄지 그때마다 다시 골라야 합니다.

사내 자료를 많이 넣을수록 답이 좋아지지 않나요?

그렇지 않습니다. 넣는 양이 늘수록 정작 필요한 한 줄을 모델이 놓칠 가능성이 커집니다.

같은 글에 「컨텍스트 부패(context rot)」라는 개념이 나옵니다. 모델에 넣은 토큰이 늘어날수록 그 안의 정보를 정확히 떠올리는 능력이 떨어진다는 관찰입니다. 토큰은 모델이 문장을 잘게 쪼개 세는 단위로, 한국어 한 문장도 여러 토큰으로 나뉩니다. 앤트로픽은 정도의 차이는 있어도 이 특성이 모든 모델에서 나타난다고 설명합니다.

그래서 앤트로픽이 내놓은 원칙은 원하는 결과가 나올 가능성을 가장 높이는, 신호가 강한 정보의 가장 작은 묶음을 찾으라는 것입니다. 공유 드라이브를 통째로 연결하는 방식과는 방향이 반대입니다.

자료를 골라 넣으려면 고르는 기준이 있어야 합니다. 사내 자료라면 세 가지를 묻습니다. 지금 묻는 사람이 이 자료를 봐도 되는가. 이 자료가 지금도 맞는가. 답에 이 자료의 이름을 달 수 있는가. 차례로 권한, 최신성, 출처 표시입니다.

사내 데이터 AI 에이전트를 만들 때, 자료는 언제 어떤 방식으로 넘기나요?

크게 두 갈래입니다. 모든 질문에 앞서 늘 읽히도록 미리 넣어 두는 방식과, 질문이 들어온 뒤 필요한 문서만 찾아 가져오는 방식입니다.

미리 넣어 두는 쪽에는 에이전트가 매번 알아야 하는 정보가 갑니다. 부서 이름, 사내에서만 쓰는 약어, 답하지 말아야 할 주제처럼 양이 적고 좀처럼 바뀌지 않는 정보입니다. 이 자리가 길어지면 그 자체로 컨텍스트 부패를 부르므로, 규정 전문을 통째로 넣기보다 규정의 이름과 있는 자리만 적어 둡니다.

찾아서 가져오는 쪽의 대표 방식은 「검색 증강 생성」, 영어 약자로 RAG입니다. 질문과 관련 있는 문서 조각을 먼저 검색한 뒤 그 조각을 모델에 함께 넘겨 답을 쓰게 하는 구조입니다. 뜻이 비슷한 문서를 찾으려면 글을 숫자 묶음으로 바꿔 두어야 하는데, 이렇게 바꾼 결과를 임베딩이라고 하고 임베딩을 모아 보관하는 저장소를 벡터 데이터베이스라고 부릅니다.

앤트로픽은 한 걸음 더 나간 방식도 소개했습니다. 문서를 미리 전부 가공해 두는 대신 파일 경로나 링크 같은 가벼운 표시만 들고 있다가, 일하는 도중에 필요한 것만 도구, 곧 에이전트가 호출해 쓰는 기능으로 불러오는 「그때그때(just in time)」 방식입니다.

대가 가운데 하나는 속도입니다. 실행 중에 찾아 읽는 방식은 미리 계산해 둔 자료를 꺼내는 것보다 느립니다. 두 방식을 섞는 방식에 대해서는, 앤트로픽이 법무나 재무처럼 내용이 잘 바뀌지 않는 업무에 더 맞을 수 있다고 따로 적었습니다.

사내 예로 옮기면 이런 모습입니다. 매달 바뀌는 단가표를 검색 저장소에 미리 가공해 넣어 두는 대신, 단가표 파일이 있는 위치만 에이전트에 알려 두고 단가를 묻는 질문이 들어올 때 그 파일을 열어 읽게 합니다.

세 방식 모두 자료가 에이전트에 넘어가기 전에 거르는 자리를 하나씩 갖고 있습니다. 미리 넣을 내용을 고를 때, 검색 저장소에 문서를 넣을 때, 파일 위치를 알려 줄 때입니다. 권한·최신성·출처 표시는 이 세 자리에 똑같이 걸어 두는 조건입니다.

첫째, 지금 묻는 사람이 이 자료를 봐도 되나요?

권한의 기준은 질문한 사람입니다. 에이전트가 자료를 읽을 수 있는지와 질문한 사람이 그 자료를 봐도 되는지는 별개이고, 사내 자료를 붙일 때 따지는 것은 뒤쪽입니다.

사람끼리라면 권한은 폴더 단위로 지켜집니다. 인사팀 폴더는 인사팀만 열고, 영업팀 직원은 그 안의 평가 기준을 볼 수 없습니다. 그런데 여러 폴더의 문서를 검색 저장소 하나에 모아 넣으면 폴더의 벽이 사라집니다. 영업팀 직원이 「평가」라는 말이 든 질문을 던졌을 때 인사팀 문서 조각이 검색 결과로 올라올 수 있는 구조가 됩니다.

대형 언어 모델(LLM) 응용의 위험 목록을 내는 OWASP 생성형 AI 보안 프로젝트는 2025년판에 「벡터와 임베딩의 약점」을 올렸고, 앞서 풀어 둔 임베딩 저장소에서 생기는 바로 이 문제를 다룹니다. 접근 통제가 부족하거나 어긋나 있으면 모델이 개인정보나 기밀 정보를 꺼내 보여 줄 수 있고, 여러 사용자 집단이 벡터 데이터베이스 하나를 함께 쓰면 한 집단의 질문에 다른 집단의 정보가 섞여 나올 수 있다고 적었습니다.

대응으로는 권한을 인식하는 저장소를 두고 집단별로 데이터를 논리적으로 나누라고 권합니다.

비전문가가 이 원칙을 확인하는 방법은 자료를 연결하기 전에 그 자료가 원래 있던 자리의 열람 범위를 적어 두는 것입니다. 「전 직원」, 「인사팀과 임원」, 「해당 프로젝트 참여자」처럼 적습니다. 에이전트를 쓸 사람이 그 범위 밖에 있다면 그 자료는 연결 대상에서 빼거나 따로 나눠 둡니다.

열람 범위는 새로 정하지 말고 원래 시스템에 걸려 있는 권한을 옮겨 적습니다. 새로 정하려 들면 부서마다 의견이 갈려 연결이 늦어지고, 원래 시스템과 에이전트의 권한이 어긋나는 순간 어느 쪽이 맞는지 다시 따져야 합니다. 옮겨 적다가 원래 권한이 지나치게 넓게 열려 있었다는 사실이 드러나면, 원래 시스템 쪽을 먼저 고치는 것이 순서입니다.

직원이 에이전트에 무엇을 입력하면 안 되는지는 방향이 반대인 문제입니다. 그쪽은 생성형 AI 사용 규정에 넣을 조항이 다룹니다.

둘째, 이 자료는 지금도 맞나요?

최신성은 자료 스스로 알려 주지 않습니다. 사내 문서는 새 판이 나와도 옛 판 파일이 폴더에 그대로 남아 있을 수 있습니다. 두 파일 가운데 어느 쪽이 현행인지 가려낼 단서를 에이전트는 갖고 있지 않습니다.

OWASP는 같은 항목에서 여러 출처의 데이터가 서로 모순될 때 생기는 충돌을 위험 사례로 들었습니다. 모델이 학습 때 익힌 옛 지식을 검색으로 가져온 새 데이터로 대체하지 못할 때도 같은 충돌이 생긴다고 설명합니다. 권고는 여러 출처를 합칠 때 합친 데이터를 꼼꼼히 검토하고, 지식 베이스, 곧 에이전트가 찾아 읽도록 모아 둔 문서 모음 안의 데이터에 꼬리표를 달아 분류하라는 것입니다.

앤트로픽은 폴더 구조, 파일 이름 규칙, 날짜 표시가 사람과 에이전트 모두에게 정보를 언제 어떻게 쓸지 알려 주는 신호라고 봤습니다. 날짜를 관련성을 가늠하는 대리 지표로 삼을 여지도 짚었습니다.

확인할 칸은 셋입니다. 이 문서가 언제 기준인지(기준일), 이 문서가 대체한 이전 판이 무엇인지(대체한 판), 다음에 누가 언제 고치는지(갱신 담당). 앞의 가정한 시연에서 재작년 규정이 답의 근거가 될 수 있었던 것은 「대체한 판」을 적는 칸이 없었기 때문입니다. 옛 판은 연결에서 빼고, 이력이 필요하면 에이전트가 읽지 않는 보관 폴더로 옮깁니다.

업종별 적용 사례를 전하는 에반젤리스트로서 제가 세 조건의 칸 가운데 가장 무겁게 보는 칸이 이 「대체한 판」입니다. 열람 범위는 원래 시스템의 권한을 옮겨 적을 수 있고 출처 이름은 문서 제목에서 정할 수 있지만, 어느 판이 현행인지는 그 문서를 개정한 부서가 가장 정확히 알고 파일만 봐서는 가려내기 어렵기 때문입니다.

같은 문서가 두 부서 폴더에 따로 복사돼 있을 때도 같은 충돌이 생깁니다. 한쪽만 고쳐지면 두 판이 동시에 현행처럼 보이므로, 목록에는 원본이 있는 자리 하나만 적고 사본은 연결하지 않습니다.

셋째, 답이 어느 문서에서 왔는지 밝힐 수 있나요?

출처 표시는 틀린 답을 잡는 장치입니다. 에이전트의 답 끝에 근거 문서의 이름과 판을 붙이게 하면, 틀린 답을 사람이 잡아낼 길이 생깁니다. 출처가 없는 답은 맞았는지 틀렸는지 확인할 방법부터 막혀 있습니다.

OWASP는 「잘못된 정보」 항목에서 모델이 그럴듯하지만 틀린 내용을 만드는 문제와 함께, 사용자가 AI의 답을 확인 없이 지나치게 믿는 「과의존」을 위험으로 꼽았습니다. 사례로는 에어캐나다의 챗봇이 여행객에게 잘못된 정보를 안내했고 항공사가 소송에서 진 일을 들었습니다. 대응책에는 신뢰할 수 있는 출처와 교차 확인하도록 권하는 것, 중요하거나 민감한 정보에는 사람의 사실 확인 절차를 두는 것이 들어 있습니다.

교차 확인은 무엇과 대조할지 알아야 가능합니다. 답에 「여비 규정 2026년 3판, 4쪽」이 붙어 있으면 직원은 그 문서를 열어 한 줄만 맞춰 보면 됩니다. 붙어 있지 않으면 확인하려는 사람이 공유 드라이브를 처음부터 뒤져야 합니다.

그래서 자료 목록에 답에 붙일 이름을 미리 정해 둡니다. 「여비규정_최종_수정2」 같은 파일명 말고, 직원이 알아듣는 문서 이름과 판 번호입니다. 규칙 하나를 더 붙입니다. 근거로 달 문서를 찾지 못한 질문에는 추측해 답하지 말고 담당 부서를 안내하게 합니다.

문서 이름을 답에 붙이면 기록도 남습니다. 어떤 문서가 근거로 몇 번 불렸는지, 어떤 질문이 근거를 찾지 못해 담당 부서로 넘어갔는지가 쌓이고, 뒤쪽 기록은 목록에서 빠진 자료를 찾는 단서가 됩니다.

자료 목록에는 어떤 칸을 붙여 확인하나요?

연결하려는 자료마다 한 줄씩, 다섯 칸을 채웁니다. 다섯 칸이 다 채워진 자료만 에이전트에 붙이고, 한 칸이라도 비면 그 칸을 채울 수 있는 담당자부터 찾습니다.

아래 표의 문서와 부서는 모두 가상의 예시이며, 특정 회사의 자료가 아닙니다.

자료	열람 범위	기준일 · 갱신 담당	대체한 판	답에 붙일 이름
국내 출장 여비 규정	전 직원	2026-03-01 · 총무팀(개정 시)	2024년판 — 연결에서 뺌	여비 규정 2026년 3판
제품 A 설치 설명서	전 직원 · 협력사	2026-07-15 · 기술지원팀(판올림 시)	1.8판 — 보관 폴더로	제품 A 설치 설명서 2.0
거래처별 공급 단가표	영업팀 · 재무팀	매월 1일 · 영업관리 담당	전월 파일 — 덮어씀	공급 단가표 ○월분
인사 평가 기준 초안	인사팀	미정	—	—

마지막 줄은 붙이지 않을 자료입니다. 열람 범위가 인사팀으로 좁고 기준일도 정해지지 않은 초안이라, 전 직원이 쓰는 에이전트에 올릴 이유가 없습니다. 앞의 시연에서 인사팀 초안이 섞여 들 수 있었던 자리가 바로 이 줄입니다.

셋째 줄은 조건부입니다. 단가표는 두 팀만 보는 자료라서, 전 직원용과 영업팀용 에이전트가 검색 저장소 하나를 함께 쓴다면 질문한 사람의 소속에 따라 검색 결과를 거르는 설정이 먼저 확인돼야 합니다. 그 설정을 확인하지 못했다면 단가표는 영업팀용 저장소에만 둡니다.

표를 채우는 사람은 개발자보다 각 자료를 관리하는 부서 담당자가 맞습니다. 누가 볼 수 있는지, 어느 판이 현행인지는 그 부서가 가장 정확히 압니다. 기술 담당은 이 칸들이 실제 검색 설정에 반영됐는지를 확인하는 쪽을 맡습니다.

사내 자료를 하마다랩스의 윈디플로로 연결한다면 무엇을 물어야 하나요?

하마다랩스가 만드는 에이전트 플랫폼 WindyFlo(윈디플로)도 사내 자료를 에이전트에 붙이는 경로를 갖고 있습니다. 하마다랩스 플랫폼 페이지의 「RAG 파이프라인 엔지니어링」 항목은 「벡터 데이터베이스 및 지식 베이스에 연결하세요. 고급 검색 증강 생성(RAG) 파이프라인을 쉽게 구축할 수 있습니다」라고 적고 있습니다.

이 문언을 다섯 칸 표에 대어 보면, 표의 어느 열에도 직접 답하지 않습니다. 문언이 말하는 것은 자료를 잇는 길이고, 열마다 필요한 동작은 따로 물어야 합니다. 열 이름을 그대로 질문으로 바꾸면 다음과 같습니다.

• 열람 범위: 질문한 사람의 소속에 따라 검색 결과를 거를 수 있는가, 아니면 저장소를 부서별로 나눠야 하는가
• 기준일 · 갱신 담당: 문서를 고쳤을 때 검색 저장소에는 언제, 누구의 손으로 다시 반영되는가
• 대체한 판: 옛 판을 검색 대상에서 빼는 작업은 어느 화면에서 하는가
• 답에 붙일 이름: 답 끝에 근거 문서의 이름과 판을 표시할 수 있는가

경쟁사가 먼저 시작했다는데, 무엇부터 손대야 하나요?

연결할 자료 열 개를 고르고, 그 열 줄의 다섯 칸을 채우는 일부터입니다. 시연 뒤에 「이 답은 어디서 나왔느냐」는 질문에 대답할 수 있는 쪽은 이 순서입니다.

열 개는 에이전트가 받을 질문에서 거꾸로 고릅니다. 시범 부서가 지난 한 달 동안 받은 사내 문의를 모아 답의 근거가 된 문서를 적어 보면 후보가 좁혀집니다. 처음이라면 연결 대상이 적을수록 다섯 칸을 끝까지 채우기도 수월합니다.

에이전트가 챗봇과 어떻게 다른지부터 정리하고 싶으시면 AI 에이전트와 챗봇의 차이를, 에이전트 하나로 시작할지 여럿으로 나눌지가 고민이라면 멀티 에이전트는 언제 필요한가를 함께 보시면 앞뒤 순서가 잡힙니다.

열 줄을 채우고 나도 빈칸은 남고, 두 종류로 나뉩니다. 갱신 담당처럼 부서 안에서 정하면 채워지는 칸과, 열람 범위를 검색 결과에 반영하는 방식처럼 도구의 동작을 알아야 채워지는 칸입니다.

뒤쪽 칸이 남았다면 그 칸의 열 이름과 자료 이름을 적어 도입 상담으로 보내 주세요. 상담은 그 칸이 설정으로 채워지는지, 자료를 나누는 쪽으로 풀어야 하는지부터 답합니다.

자주 묻는 질문

컨텍스트 창이 큰 모델을 쓰면 자료를 고르지 않아도 되나요?

아닙니다. 컨텍스트 창은 모델이 한 차례에 받아 읽는 분량의 상한인데, 창이 커지면 넣을 수 있는 양은 늘어도 무엇이 현행이고 누가 봐도 되는지는 여전히 사람이 정해야 합니다. 앤트로픽도 가장 강한 에이전트 성능이 필요한 상황이라면, 가까운 미래에도 컨텍스트 창은 크기와 상관없이 불필요한 정보가 섞이는 문제와 관련성 문제를 안고 갈 것으로 봤습니다.

사내 자료로 모델을 추가 학습시키는 것과는 무엇이 다른가요?

추가 학습(파인튜닝)은 모델 자체가 자료의 패턴을 익히게 하는 방식이고, 컨텍스트 엔지니어링은 모델은 그대로 둔 채 답할 때 읽을 자료를 골라 넘기는 방식입니다. 규정처럼 판이 바뀌는 자료는 넘길 문서만 바꾸는 쪽이 관리가 단순합니다.

스캔한 PDF나 한글 파일도 그대로 연결할 수 있나요?

연결 전에 글자가 제대로 뽑히는지 확인해야 합니다. 스캔본은 이미지라서 글자 인식을 거쳐야 검색 대상이 되고, 표가 많은 문서는 칸이 섞여 읽힐 수 있습니다. OWASP는 흰 바탕에 흰 글씨로 숨긴 지시문을 넣은 이력서가 RAG 기반 심사 시스템을 속이는 공격 예를 들며, 문서를 지식 베이스에 넣기 전에 검증하라고 권했습니다.

자료 목록은 한 번 만들면 끝인가요?

아닙니다. 규정이 바뀔 때마다 고쳐야 하는 목록이고, 「기준일 · 갱신 담당」 칸을 두는 이유가 여기에 있습니다. 규정이 개정되면 담당 부서가 목록의 그 줄을 고치고, 옛 판을 연결에서 빼는 일까지 한 묶음으로 처리하도록 정해 둡니다. 분기마다 기준일이 오래된 줄을 훑는 점검을 더합니다.

프롬프트 엔지니어링은 이제 신경 쓰지 않아도 되나요?

지시문은 여전히 컨텍스트의 한 부분입니다. 앤트로픽은 지시문이 세세한 조건문으로 딱딱해지는 쪽과 막연한 원칙만 늘어놓는 쪽, 두 극단을 피하고 행동을 이끌 만큼 구체적이면서 유연한 수준을 찾으라고 권했습니다.

개인정보가 섞인 문서는 어떻게 다루나요?

열람 범위 칸에서 먼저 걸러집니다. 개인정보가 섞인 문서를 꼭 붙여야 하는 업무라면, 연결 전에 개인정보 보호 책임자와 사용 목적·범위를 확인하는 절차를 거치는 편이 안전합니다.

참고 자료

• Anthropic, “Effective context engineering for AI agents”(2025-09-29) — 프롬프트 엔지니어링과 컨텍스트 엔지니어링의 정의와 관계, 컨텍스트를 고르는 일의 반복성, 컨텍스트 부패(context rot), 신호가 강한 최소 정보 묶음 원칙, 사전 검색과 「just in time」 방식·혼합 방식, 폴더 구조·파일 이름·날짜 표시의 신호, 지시문의 적정 수준, 컨텍스트 창 크기와 무관한 오염·관련성 문제(2026-10-01 확인): https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• OWASP GenAI Security Project, “LLM08:2025 Vector and Embedding Weaknesses” — 접근 통제 부족·어긋남에 따른 정보 노출, 공유 벡터 데이터베이스의 집단 간 정보 유출, 출처 간 모순과 옛 지식 대체 실패, 권한 인식 저장소·데이터 분할·꼬리표 분류 권고, 숨긴 지시문 이력서 공격 예(2026-10-01 확인): https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
• OWASP GenAI Security Project, “LLM09:2025 Misinformation” — 그럴듯한 오류와 과의존, 에어캐나다 챗봇 사례, 교차 확인·사람의 사실 확인 권고(2026-10-01 확인): https://genai.owasp.org/llmrisk/llm092025-misinformation/
• 하마다랩스, WindyFlo 플랫폼 페이지 — 「RAG 파이프라인 엔지니어링」 항목 문언(2026-10-01 확인): https://www.hamadalabs.com/platform

작성자

유수호 — 하마다랩스 윈디플로 에반젤리스트이자 한양대학교 ERICA 겸임교수. 생성AI 업무 활용·자동화·AI 에이전트를 주제로 기업 교육을 진행하며, AI 에이전트와 챗봇의 차이 같은 기본 개념부터 업종별 도입 시나리오까지 현장 관점에서 다룹니다. 프로필: https://www.linkedin.com/in/수호-유-852852258/