컨텍스트 엔지니어링이란? 사내 지식으로 실천하는 5단계

사내 AI를 도입하고 몇 개월. 프롬프트 작성법을 몇 번이나 바꾸고, 지시문을 길게 쓰고, 역할 설정까지 더해도 묻는 방식에 따라 맞았다 틀렸다 하는 상태에서 벗어나지 못한다. 이런 단계에서 상담을 주시는 경우가 늘고 있습니다.

이때 문제는 대개 묻는 방식이 아니라 AI에게 실제로 건네지고 있는 정보 쪽에 있습니다. 2026년 들어 자리 잡은 「컨텍스트 엔지니어링(Context Engineering)」이라는 말은 바로 이 부분을 가리킵니다.

이 글에서는 컨텍스트 엔지니어링이 무엇인지, 프롬프트 엔지니어링이나 RAG와 무엇이 다른지 정리한 뒤, 자사의 사내 지식에 오늘부터 적용할 수 있는 5단계를 소개합니다.

---

이 글에서 알 수 있는 것

• 컨텍스트 엔지니어링의 의미와 프롬프트 엔지니어링과의 차이
• RAG는 불필요해졌는지, 아니면 컨텍스트 엔지니어링의 일부인지
• 사내 AI의 답변이 불안정할 때 의심해야 할 「4가지 실패 모드」
• 자사의 지식을 점검하는 구체적인 절차
• 정보를 건네는 방식(아키텍처)을 고를 때의 판단 재료

---

컨텍스트 엔지니어링이란 -- 「묻는 방식」이 아니라 「건네는 정보 전체」를 설계하는 것

컨텍스트 엔지니어링이란, AI가 답을 만들어 내는 순간에 보고 있는 정보 일체를 목적에 맞게 설계하는 작업입니다.

여기서 말하는 컨텍스트는 사람이 입력한 질문문만이 아닙니다. AI가 한 번의 답변을 만들 때, 실제로는 다음과 같은 것들이 한꺼번에 전달됩니다.

요소	내용	누가 정하는가
지시	역할·답변 규칙·금지 사항	서비스 제공 측 또는 관리자
질문	이용자가 그 자리에서 입력한 문장	이용자
사내 정보	참조된 사내 문서의 내용	지식 정비 상태와 검색 구조
대화 이력	직전까지의 주고받음	자동
도구 결과	검색·API 등의 실행 결과	시스템 설계
출력 형식	항목 정리 방식, 출처 표기 방식	설계자

이용자가 손대는 것은 이 중 「질문」 한 줄뿐입니다. 나머지 대부분은 설계자가 정하고 있는데도, 많은 현장에서는 그쪽을 건드리지 않은 채 질문문 작성법만으로 정확도를 올리려 합니다. 프롬프트를 다듬어도 한계에 부딪히는 이유가 여기에 있습니다.

프롬프트 엔지니어링과의 차이

둘은 자주 혼동되지만 다루는 범위가 다릅니다.

	프롬프트 엔지니어링	컨텍스트 엔지니어링
설계 대상	질문문·지시문의 작성법	AI에게 전달되는 정보 일체와 수집 방식
주요 수단	역할 설정, 절차 명시, 예시 제공	정보 취사선택, 최신성 관리, 구조화, 권한 제어
효과가 큰 상황	단발 작업을 잘 처리시키고 싶을 때	같은 업무를 매일 안정적으로 돌리고 싶을 때
한계	원본 정보가 없으면 어떻게 써도 답할 수 없다	정보 정비에 손이 든다

프롬프트 엔지니어링이 불필요해진 것은 아닙니다. 다만 사내 지식 활용처럼 「원본 정보가 사내에 있는」 용도에서는 효과가 압도적으로 컨텍스트 쪽에 있습니다. 취업규칙이 업로드되어 있지 않다면, 아무리 교묘하게 질문해도 휴직 조건은 나오지 않습니다.

RAG와의 관계 -- 대립이 아니라 포함

「컨텍스트 엔지니어링이 왔으니 RAG는 끝났다」는 설명을 보곤 하지만, 이는 정확하지 않습니다. RAG는 컨텍스트를 조립하는 방법 중 하나입니다.

• 프롬프트 엔지니어링: 건네는 문장의 작성법을 다듬는다
• RAG: 질문과 관련될 법한 문서를 자동으로 찾아 컨텍스트에 더한다
• 컨텍스트 엔지니어링: 무엇을·얼마나·어떤 순서로·어떤 형태로 건넬지 설계한다(RAG를 쓸지 여부도 이 판단에 포함)

즉 관계는 상하입니다. RAG는 수단 중 하나이고, 컨텍스트 엔지니어링은 그 위에 있는 설계의 이야기입니다. 「RAG는 낭비였다」고 이야기되는 사례의 상당수는 기술 자체가 아니라 건넬 것을 설계하지 않은 채 검색만 붙인 결과로 발생합니다. 이 쟁점은 「RAG 불필요론」은 정말일까? 사내 지식 AI 판단 축 6가지에서 자세히 정리했습니다.

---

프롬프트를 다듬어도 답변이 안정되지 않는 이유 -- 4가지 실패 모드

사내 AI의 답변이 불안정할 때, 원인은 거의 다음 네 가지로 분류됩니다. 증상은 비슷한데 대응책은 정반대이므로, 먼저 어느 쪽인지 가려내십시오.

실패 1: 부족 -- 애초에 전달되지 않았다

사내 AI가 「기재가 없습니다」라고 답할 때, 대부분은 정보가 전달되지 않은 상태입니다. 문서 자체가 없는 경우도 있고, 담당자의 PC나 메일 안에 있어서 취합되지 않은 경우도 있습니다.

암묵적인 규칙(「이 신청은 부서장을 거친 뒤에」 등)은 애초에 문서로 존재하지 않는 경우가 대부분입니다. 이는 검색 정확도가 아니라 지식의 재고 문제입니다.

실패 2: 과다 -- 너무 많이 건네서 희석된다

반대도 문제입니다. 관련될 법한 문서를 대량으로 건네면 정확도가 떨어집니다. 긴 입력의 중반에 있는 정보가 잘 잡히지 않는 현상은 "Lost in the Middle"로 알려져 있으며, 「전부 읽히면 정확해진다」는 성립하지 않습니다.

비용 면에서도 마찬가지입니다. 질문할 때마다 대량의 문서를 계속 보내는 설계는 이용이 늘수록 비용이 부풀어 오릅니다. 이 점은 RAG는 이제 한물갔나? 롱 컨텍스트 시대의 지식 베이스 설계에서 수치와 함께 검토했습니다.

실패 3: 오염 -- 구버전과 신버전이 함께 있다

실무에서 가장 까다로운 것이 이것입니다. 2024년판과 2026년판 규정이 둘 다 들어 있으면, AI는 양쪽 모두를 「사내의 올바른 정보」로 취급합니다. 그 결과 그럴듯한데 오래된 답변이 돌아옵니다.

게다가 이 오류는 이용자 입장에서 틀렸다고 알아차리기 어렵다는 점이 성가십니다. 운용에서는 「넣는 것」보다 **「오래된 것을 지우는 것」**이 정확도에 더 효과적입니다.

실패 4: 형태 불량 -- 쓰여 있는데 읽어내지 못한다

스캔만 한 이미지 PDF, 이미지로 붙여 넣은 표, 여러 주제가 섞인 방대한 파일. 이런 것들은 내용이 있어도 AI가 제대로 꺼내지 못합니다.

작성법의 세부가 답변 정확도를 어떻게 바꾸는지는, 내용은 같고 작성법만 다른 문서를 실제로 취합해 검증한 AI가 제대로 답하는 사내 문서 작성법에 정리했습니다. 결론만 말하면, 정중한 문장보다 「1파일 1주제」 「첫 줄에 무슨 문서인지 쓰기」가 훨씬 효과적입니다.

---

실천편: 컨텍스트 재고조사의 5단계

여기서부터가 본론입니다. 컨텍스트 엔지니어링은 개념으로 이해해도 의미가 없고, 자사 업무에 대입해야 비로소 효과가 납니다. 전사의 지식을 한 번에 정리하려 하면 반드시 좌초하므로, 업무를 하나로 좁혀서 진행하십시오.

단계 1: AI에게 맡기고 싶은 판단을 하나만 정한다

「사내의 무엇이든 답하는 AI」는 목표로 삼기에 너무 큽니다. 질문의 형태가 정해져 있는 업무를 하나 고르십시오.

• 경비 정산에서 「이건 경비 처리가 되는가」를 판단한다
• 연차·경조·육아휴직 등 휴가 관련 문의에 답한다
• 견적 의뢰에 대해 표준 가격과 할인 조건을 답한다
• 고객의 제품 사양 질문에 답한다

고르는 기준은 「같은 질문이 달에 여러 번 온다」는 점입니다. 빈도가 높을수록 정비 효과가 바로 숫자로 나타납니다.

단계 2: 사람이 판단할 때 보고 있는 것을 전부 적어낸다

그 업무의 베테랑이 판단할 때, 머릿속과 손에 있는 정보를 빠짐없이 나열합니다. 여기서 중요한 것은 문서가 되어 있지 않은 것도 적어내는 일입니다.

예를 들어 경비 정산의 가부 판단이라면 이렇게 됩니다.

• 경비 규정(문서 있음)
• 계정과목 일람(엑셀)
• 과거에 승인·반려된 사례(담당자의 기억)
• 「5,000엔을 넘으면 영수증의 품목란을 확인한다」는 운용 규칙(구전)
• 부서별 예외(일부만 메일에 남아 있음)

이 목록이 그 업무에서 AI에게 건네야 할 컨텍스트의 설계도가 됩니다.

단계 3: 하나씩 「AI에게 건넬 수 있는 형태인가」를 점검한다

적어낸 항목을 다음 3열로 점검합니다. 스프레드시트에 옮겨 채우기만 해도 충분합니다.

판단 재료	문서로 존재하는가	최신판이 하나로 정해지는가	AI가 읽을 수 있는 형태인가
경비 규정	있음	구버전이 폴더에 잔존	PDF(텍스트)
계정과목 일람	있음	있음	엑셀 표
과거 승인 사례	없음(기억)	--	--
품목란 운용 규칙	없음(구전)	--	--
부서별 예외	메일에 산재	불명	불명

이 표가 채워진 시점에 왜 AI가 안정되지 않는지는 거의 설명할 수 있습니다. 위 예라면 판단 재료 다섯 중 셋이 애초에 AI에게 전달되지 않고 있습니다. 프롬프트를 아무리 다듬어도 해결되지 않는 영역입니다.

단계 4: 구멍을 메운다 -- 완벽을 목표로 하지 않는다

점검에서 발견된 구멍을 메웁니다. 순서는 「자주 질문받는 것부터」입니다.

• 구전은 한 장으로 만든다: 완성도는 필요 없고 항목 나열로 충분합니다. 「품목란에 품명이 없는 영수증은 재발행을 요청한다」 한 줄만 있어도 AI는 답할 수 있게 됩니다
• 구버전을 지운다: 참조시키고 싶지 않은 문서는 보관 위치에서 빼는 것이 가장 확실합니다
• 표는 텍스트로 보관한다: 이미지로 붙여 넣은 표는 인식 정확도가 떨어집니다
• 산재한 것을 한곳에 모은다: 메일이나 채팅에 묻힌 예외는 찾아낸 만큼이라도 문서로 옮깁니다

전부 메울 필요는 없습니다. 판단 재료의 8할이 갖춰지면 실무에서는 충분히 돌아갑니다.

단계 5: 10문항으로 검증하고, 빗나간 질문부터 고친다

마지막으로, 그 업무에서 실제로 오고 있는 질문을 10개 준비해 AI에게 던지고 답을 맞춰봅니다. 상정 질문이 아니라 문의 이력에서 실제 문구를 가져오는 것이 중요합니다.

• 제대로 답한 질문은 그대로 운용에 올린다
• 빗나간 질문은 단계 3의 표로 돌아가 어느 재료가 빠졌는지 특정한다
• 「기재가 없습니다」라고 정직하게 답하는지도 확인한다(추측으로 답하는 상태가 더 위험합니다)

이 10문항은 문서를 추가·개정한 뒤 매번 돌리는 회귀 테스트로 남겨 두십시오. 지식은 더할 때마다 망가질 가능성이 있으므로, 확인의 틀을 가지고 있으면 운용이 안정됩니다.

---

「건네는 방식」을 어떻게 설계할까 -- 세 가지 접근

재고조사로 재료가 갖춰지면, 다음은 「매번 어떻게 모아서 건넬까」의 설계입니다. 크게 세 가지 사고방식이 있고, 조직의 문서량과 권한 요건에 따라 적절한 선택이 달라집니다.

접근	모으는 방식	적합한 상황	주의점
전부 건넨다(롱 컨텍스트)	문서를 통째로 매번 투입	문서가 적고 모두가 같은 것을 봐도 될 때	양이 늘면 비용과 정확도 양쪽에서 무너진다
검색해서 더한다(RAG)	질문에 가까운 조각을 검색해 투입	문서량이 많고 권한을 나누고 싶을 때	단편화 탓에 문서를 넘나드는 질문에 약하다
따라가며 모은다(내비게이션형)	목차 구조에서 관련 문서를 따라가 수집	문서에 구조가 있고 근거를 제시하고 싶을 때	문서의 구조화가 전제된다

어느 것이 우수하다는 이야기가 아니라, 앞의 재고조사 결과에 따라 답이 달라집니다. 판단 축의 자세한 내용은 「RAG 불필요론」은 정말일까?를 참조하십시오.

Monoshiri AI의 설계 -- 목차를 따라가며 컨텍스트를 조립한다

Monoshiri AI는 세 번째 내비게이션형을 채택하고 있습니다. 업로드된 사내 문서를 미리 계층 구조(스킬 트리)로 정리해 두고, 질문이 오면 AI가 그 목차를 따라가 필요한 문서만 모아 근거로 제시합니다.

이는 기술적 유행을 좇은 선택이 아니라 위에서 든 4가지 실패 모드에 대한 대응으로 설계한 것입니다.

• 과다에 대한 대응: 관련될 법한 것을 전부 건네는 대신, 도달한 문서만 건넨다
• 오염에 대한 대응: 어느 문서를 근거로 삼았는지 제시하므로, 구버전을 참조했다면 이용자가 알아차릴 수 있다
• 부족에 대한 대응: 해당 문서에 도달하지 못한 경우에는 추측하지 않고 「기재가 없다」고 답한다

왜 검색 방식에서 이 방식으로 옮겼는지는 실제 실패 사례와 함께 Corpus2Skill이란? RAG와 skill 모드의 차이 해설에서 다뤘습니다. 정리한 문서를 그대로 채팅 위젯이나 LINE에서 물어볼 수 있는 형태로 만들 수 있어, 재고조사로 정비한 지식을 그대로 업무 동선에 올릴 수 있습니다.

---

자주 묻는 질문

Q. 컨텍스트 엔지니어링은 전문 엔지니어가 없으면 무리인가요?

아닙니다. 이 글의 5단계에 기술적인 작업은 포함되어 있지 않습니다. 업무를 아는 사람이 판단 재료를 적어내는 작업이 중심이며, 오히려 현장 담당자가 더 적임입니다. 도구 설정은 도입하는 서비스 측이 맡는 부분입니다.

Q. 문서를 정비하고 나서 AI를 넣어야 하나요?

반대를 권합니다. 먼저 넣고, 답하지 못한 질문부터 고치는 편이 확실합니다. 정비할 곳은 책상 위에서는 알 수 없고, 실제로 빗나간 질문이 알려줍니다.

Q. AI 에이전트를 만들 때도 같은 사고방식이면 되나요?

같습니다. 오히려 에이전트 쪽이 중요도가 높아집니다. 여러 절차를 자동으로 돌리는 만큼 각 단계에서 전달되는 정보가 쌓여, 실패 2(과다)와 실패 3(오염)이 일어나기 쉬워지기 때문입니다. 1단계마다 무엇을 건넬지 정하는 설계가 필요합니다.

Q. 프롬프트를 다듬는 것은 이제 의미가 없나요?

의미는 있습니다. 다만 순서가 다릅니다. 컨텍스트가 제대로 갖춰진 상태에서 비로소 프롬프트의 개선이 효과를 냅니다. 재료가 부족한 요리는 레시피를 고쳐도 나아지지 않습니다.

---

정리

컨텍스트 엔지니어링은 새로운 기술이 아니라, AI에게 무엇을 건넬지 정한다는, 당연하지만 생략되기 쉬운 설계 작업입니다. 요점을 정리합니다.

• 컨텍스트 엔지니어링이란 AI가 답변할 때 보고 있는 정보 일체를 설계하는 것. 질문문은 그 일부에 지나지 않는다
• 프롬프트 엔지니어링은 「묻는 방식」, 컨텍스트 엔지니어링은 「건네는 정보 전체」를 다룬다. 사내 지식 용도에서는 후자의 효과가 더 크다
• RAG는 대립 개념이 아니라 컨텍스트를 조립하는 수단 중 하나. 「RAG가 낭비였다」는 사례의 상당수는 설계 없이 검색만 붙인 경우
• 답변이 안정되지 않는 원인은 부족·과다·오염·형태 불량의 넷으로 분류된다. 증상은 비슷하지만 대응책은 정반대
• 실천은 업무를 하나로 좁히고, 판단 재료를 적어내고, 건넬 수 있는 형태인지 점검하고, 구멍을 메우고, 10문항으로 검증한다

우선 지금 가장 문의가 많은 업무를 하나 골라, 베테랑이 무엇을 보고 판단하는지 적어내는 것부터 시작해 보십시오. 그 종이 한 장이 사내 AI의 정확도를 결정하는 가장 큰 요소입니다.

관련 글

• 「RAG 불필요론」은 정말일까? 사내 지식 AI 판단 축 6가지
• Corpus2Skill이란? RAG와 skill 모드의 차이 해설
• RAG는 이제 한물갔나? 롱 컨텍스트 시대의 지식 베이스 설계
• AI가 제대로 답하는 사내 문서 작성법