728x90
반응형

LLM(Large Language Model)은 텍스트 완성 모델이에요. 시퀀스에서 다음에 가장 적합한 단어(토큰)를 예측하기 때문에 기존 입력 시퀀스를 더 많이 안내할수록 모델의 출력이 더 안정적이고 유용해지죠. 기존 입력 시퀀스를 모델 컨텍스트라고 부른답니다.

컨텍스트 엔지니어링은 Prompt Engineering의 진화된 형태인데, 2025년 중반에 등장했어요. Prompt Engineering만으로는 해결할 수 없는 문제들을 해결하면서 관심을 끌었죠. 둘 사이의 기본적인 차이점은 간단해요. Prompt Engineering은 LLM에 제공되는 일회성 텍스트 지침에 중점을 두는 반면, 컨텍스트 엔지니어링은 모델과의 지속적인 상호 작용을 위한 컨텍스트 정보 아키텍처에 초점을 맞추거든요.

Prompt Engineer는 작업을 정의하고, 예를 제공하고, 모델을 특정 스타일이나 결과로 안내해요. LLM 초기에는 그것만으로도 충분한 경우가 많았어요. 대부분의 작업이 간단한 단일 회전 상호 작용이었으니까요. 필요한 모든 정보는 단일 프롬프트 안에 들어가야 했죠.

하지만 챗봇보다 더 야심찬 무언가를 만들려고 하자마자 기술의 한계가 분명해졌어요. 모델이 주요 세부 사항을 잊어버리거나 도구를 잘못 사용하거나 정보에 환각을 느끼는 경우가 생겼거든요.

이와는 대조적으로 컨텍스트 엔지니어링은 모델에 제공되는 정보 조립 파이프라인(무엇을 알아야 하는지, 언제 알아야 하는지, 해당 정보가 어떻게 구성되어야 하는지)을 재구성해요. 더 큰 컨텍스트 창은 더 많은 정보를 처리할 수 있지만, 적시에 올바른 정보를 전달해야 하는 더 깊은 과제를 해결하지는 못하죠. 그리고 해당 정보가 구조화되지 않은 경우 모델은 중요한 것이 무엇인지 식별하는 데 어려움을 겪게 돼요. 주의가 흐려지고 정확도가 떨어지게 되는데, 이러한 과정을 "컨텍스트 부패"라고 부른답니다.

최신 AI 시스템, 특히 여러 단계에 걸쳐 계획하고 관찰하고 행동하는 에이전트는 안정적으로 작동하려면 각 단계에서 구조화된 맞춤형 컨텍스트가 필요해요. Knowledge Graph는 에이전트에게 도메인의 연결되고 설명 가능한 모델과 복잡한 AI 애플리케이션이 의존하는 상황 인식을 제공함으로써 해당 구조를 제공할 수 있어요.

A quote from Lance Martin (LangChain) defining context engineering

이 가이드의 추가 내용:

  •  
  • Prompt Engineering이 실패하는 곳
  •  
  • 새로운 격차 Prompt Engineering이 채울 수 없음
  •  
  • 올바른 결정을 뒷받침하는 아키텍처
  •  
  • Context Engineering이 필요한 경우
  •  
  •  
  • 에이전트에 대한 Prompt Engineering이 실패하는 이유
  •  
  •  
  • 추론을 위한 구조화된 정보
  •  
  • 환각 감소 및 더욱 확실한 출력
  •  
  •  
  • 비정형 RAG의 한계
  •  
  • RAG에 대한 Knowledge Graph(GraphRAG)의 이점
  •  
  • Context Engineering이 실제로 어떻게 구현되는가
  •  
  • 컨텍스트 엔지니어링을 채택하기 위한 실제 단계
  •  
  • 현대 AI 개발자를 위한 기술
  • 컨텍스트 엔지니어링이 AI 시스템의 차세대 시대를 정의하는 이유
  • GraphRAG에 대해 자세히 알아보기
  •  
  • 필수 GraphRAG
  •  

프롬프트 엔지니어링의 역할과 한계

Prompt Engineering은 LLM이 작업을 해석하는 방법을 결정하는 지침을 작성하는 거예요. 여기에는 모델의 역할을 정의하는 시스템 메시지, 작업을 지정하는 사용자 프롬프트, 사용자 질문(RAG)에서 미리 로드된 데이터 소스의 정보, 특정 유형의 출력을 권장하는 형식이 포함돼요.

초기 실험에서는 문구의 미묘한 변화가 답변을 향상시킬 수 있다는 사실이 밝혀졌고, Prompt Engineering이 모델 동작에 영향을 미치는 가장 좋은 도구임이 입증되었어요. 요약, 이메일 초안 작성, 콘텐츠 재작성과 같은 작업에서는 정말 인상적으로 잘 작동했죠.

하지만 AI 시스템의 성능이 향상되고 복잡해짐에 따라 저맥락, 프롬프트 전용 접근 방식의 한계가 점점 더 분명해지고 있어요.

프롬프트 엔지니어링이 작동하는 곳

Prompt Engineering이 여전히 뛰어난 부분을 이해하려면 완전히 독립적인 작업 유형을 고려해 보세요. LLM의 대부분의 "생성" 기능은 요약, 추출, 번역 및 생성과 같은 영역에 속해요. 예를 들어, LLM에게 문장을 긍정적 또는 부정적인 감정으로 분류하거나 기사를 요약하도록 요청하는 경우 일반적으로 단일 프롬프트와 하나의 예에 의존할 수 있어요. 모델은 이미 사전 학습을 통해 충분히 알고 있으므로 검색, 메모리 또는 추가 구조가 필요하지 않거든요.

Prompt Engineering은 다음과 같은 시나리오에서 안정적으로 수행돼요.

  • 모델에 규칙과 예시만 필요한 일회성 분류
  • 일반적인 세계 지식을 기반으로 한 텍스트 생성(요약, 번역, 추출 등)
  • 최소한의 기록으로 간단한 채팅 상호 작용
  • 시스템 프롬프트에 직접 인코딩된 정적 논리 작업(런타임 데이터, 메모리 또는 다단계 추론에 의존하지 않는 고정 규칙)
  • 검색된 백엔드 정보에서 직접 생성할 수 있는 사용자 질문에 대한 답변 생성

이러한 경우 모델은 훈련 데이터에서 관련 정보를 이미 "알고" 있거나 단일 포괄적인 명령으로 작업할 수 있는 거죠.

A diagram showing the strengths of prompt engineering

Prompt Engineering이 실패하는 경우

시스템이 상황 변화에 따라 여러 단계로 기억, 검색 또는 작동해야 하는 순간, Prompt Engineering은 취약해지기 시작하고 일상적인 작업에서 한계를 드러내요.

일반적으로 문제가 발생하는 경우는 다음과 같아요.

  • 전체적인 프롬프트가 너무 일반적이기 때문에 모델에는 다음 단계나 작업에 필요한 정보가 없어요.
  • 보상하려고 하면 메시지가 거대해지고 관리하기 어려워져요.
  • 모델은 긴 워크플로 동안 이전 세부 정보(생성한 세부 정보도 포함)를 잊어버려요.
  • 지침이 소음에 묻혀서 도구 사용을 신뢰할 수 없게 돼요.

에이전트가 자신의 계획을 추적하지 못하거나 잘못된 도구를 반복적으로 호출하는 것을 본 적이 있다면 컨텍스트 오류를 경험한 것일 거예요. Prompt Engineering은 역동적이고 진화하는 작업 상태를 처리할 수 없거든요.

새로운 격차, Prompt Engineering이 채울 수 없음

LLM 시스템의 성능이 향상됨에 따라 시스템의 복잡성도 함께 증가했어요. 정적인 프롬프트로 작업하는 대신 모델, 도구, 데이터 및 사용자 간의 진화하는 대화를 조율하고 있죠. 그리고 인간 대화에서와 마찬가지로 초점이 맞춰진 정보(맥락)는 성공적인 진행을 위해 변경되고 조정되어야 해요.

A quote from Jason Liu defining context engineering’s potential to help agents work reliably in complex information environments through better tool outputs and interaction patterns

여러분은 종종 다음과 같은 상담원과 협력하고 있을 거예요.

  • 여러 단계를 미리 계획하세요
  • 도구를 실행하고 API를 호출하여 검색하거나 조치를 취하세요.
  • 긴 문서 분석
  • 추론 체인을 따르세요
  • 기업의 제약 내에서 운영
  • 신뢰할 수 있고 설명 가능해야 함

시스템이 이 정도의 복잡성에 도달하면 단일 프롬프트만으로는 시스템을 지원하는 데 필요한 역동적이고 구조화된 컨텍스트를 제공할 수 없어요. 그 이유를 이해하려면 Prompt Engineering이 극복할 수 없는 구체적인 한계를 살펴보는 것이 도움이 될 거예요.

1. 모델의 기능이 Prompt Engineering을 능가합니다.

LLM은 대규모 컨텍스트 창을 사용하고 정교한 추론을 수행할 수 있지만 더 많은 공간이 자동으로 더 나은 성능을 의미하지는 않아요. Transformer는 정보에 주의를 기울이는 능력이 제한되어 있으며, 길고 구조화되지 않은 텍스트로 창을 오버로드하면 모델이 중요한 내용을 식별하는 데 어려움을 겪게 돼요.

이것이 바로 컨텍스트 부패예요. 더 많이 입력할수록 모델이 관련 부품을 찾기가 더 어려워지죠.

A quote by Lisa Maria Martin from Everyday Information Architecture about organizing information to improve understanding

2. 신뢰할 수 있는 최신 도메인별 정보가 필요해요.

모델은 정적 데이터 세트로 학습되었어요. 여기에는 여러분의 제품이나 플랫폼 내부에서 발생하는 독점 프로세스나 최신 이벤트가 포함되지 않죠. 하지만 프로덕션 환경으로 넘어가면 에이전트에게는 가상의 컨텍스트가 필요하지 않아요. 운영 체제가 매일 의존하는 것과 똑같은 정보가 필요한 거죠.

실제 시스템은 다음에 액세스할 수 있어야 해요.

  • 라이브 서비스 상태 및 상태 정보
  • 실제 작동 방식을 반영하는 내부 문서
  • 고객 내역 및 계정 세부 정보
  • 허용 가능한 작업을 관리하는 정책 및 제약
  • 유효한 입력 및 출력을 포함한 명시적 도구 정의
  • 지금까지 학습한 모든 것을 저장하는 세션별 메모리

이 정보가 누락되었거나, 오래되었거나, 불완전하다면 모델은 억지로 추측하게 되고, 추측은 곧 환각으로 이어지게 돼요. 대부분의 프로덕션 문제는 모델 자체의 한계가 아니라 컨텍스트의 차이에서 비롯되는 경우가 많죠.

3. 거버넌스, 규정 준수 및 추적성이 필요해요.

만약 여러분이 금융, 의료, 보험, 보안 분야에서 일하고 있다면, 단순히 좋은 답을 얻으려고 노력하는 것만이 전부가 아닐 거예요. 다음 사항들을 통제해야 하죠.

  • 상담원이 볼 수 있는 내용
  • 결정을 내리는 방법
  • 출력을 정당화할 수 있는지 여부

단순한 Prompt Engineering만으로는 이러한 기능을 보장할 수 없지만, 구조화된 컨텍스트는 가능하게 해줘요.

4. 정적 프롬프트는 동적 컨텍스트를 제공할 수 없어요.

여러분의 시스템은 모든 도구 호출이 새로운 데이터를 생성하고, 각 단계가 작업에 대한 이해를 업데이트하는 진화하는 환경에서 작동해요. 신뢰성을 유지하려면 모델은 모든 단계에서 가장 작고 관련성이 높은 정보를 받아야 하고, 컨텍스트 엔지니어링만이 이를 제공할 수 있죠.

컨텍스트 엔지니어링이란 무엇일까요?

프롬프트를 한계 이상으로 밀어붙이는 대신, 모델이 보는 세상을 형성하기 시작하세요. 이것이 바로 컨텍스트 엔지니어링의 핵심이에요.

“이 메시지를 어떻게 표현해야 할까요?”라고 묻는 대신, "모델이 성공하려면 어떤 정보가 필요하며, 해당 정보를 어떻게 명확하게 제공해야 할까요?"라고 묻기 시작하는 거죠.

컨텍스트 엔지니어링은 다음을 관리해요.

Prompt Engineering은 여전히 중요하지만, 컨텍스트 엔지니어링의 하위 집합일 뿐, 대체할 수는 없어요.

A diagram showing the components of context engineering

올바른 결정을 뒷받침하는 아키텍처

모델 중심 사고에서 아키텍처 중심 사고로 전환하면 초점이 달라져요. 기발한 문구를 만드는 것보다 다음 사항에 집중하게 되죠.

  • 모델이 알아야 할 것
  • 해당 정보를 저장하는 방법
  • 효율적으로 검색하는 방법
  • 일관성을 유지하는 방법
  • 시간 경과에 따른 드리프트를 방지하는 방법

컨텍스트 엔지니어링은 작업을 이해하고, 올바른 도구를 선택하고, 다단계 계획을 실행하는 데 필요한 정보를 제공하므로 현대 에이전트의 기본이라고 할 수 있어요.

컨텍스트 엔지니어링이 필요한 경우

컨텍스트 엔지니어링이 필요한 시기를 이해하려면, 프롬프트가 처리할 수 있는 것 이상을 수행하는 작업 유형을 고려해 보세요.

  • 대화가 컨텍스트 창을 초과하는 장거리 작업
  • 특정 거버넌스 요구 사항이 있는 엔터프라이즈 워크플로
  • 메모리를 공유하는 다중 에이전트 시스템
  • 사고 관리 등 복잡한 진단 업무
  • 새로운 정보가 나타나면서 진화하는 연구 흐름
  • 새로운 증거를 바탕으로 계획하고, 행동하고, 수정해야 하는 모든 에이전트

문제 해결을 위해 모델이 연속성을 유지하고, 구조화된 사실에 액세스하고, 도구를 사용하여 안전하게 작동해야 한다면 컨텍스트 엔지니어링은 선택 사항이 아니에요.

AI 에이전트가 상황에 의존하는 이유

AI 에이전트는 단순히 더 긴 프롬프트를 제공하는 챗봇이 아니라, Large Language Model(LLM)을 사용하여 추론하고, 도구를 사용하고, 결과를 통해 학습하고, 작업이 완료될 때까지 이 루프를 반복하는 시스템이에요.

예를 들어 에이전트에게 API 중단 문제를 해결해 달라고 요청하면 다음과 같은 결과가 나올 수 있어요.

  1. 로그를 분석하여 패턴 식별
  2. 진단 도구 호출
  3. 이해를 업데이트하세요
  4. 실행 계획 생성
  5. 다음 단계 실행

이 루프는 강력하지만, 에이전트가 각 단계에서 올바른 컨텍스트를 갖고 있는 경우에만 제대로 작동해요. 그렇지 않으면 추론 사슬이 무너질 수 있죠.

Diagram of an agentic workflow showing how an LLM planner orchestrates tool selection, execution, and summarization loops to complete a task.

에이전트에 대한 Prompt Engineering이 실패하는 이유

프롬프트만으로는 문제가 발생하는 이유를 이해하려면, 프롬프트가 수행할 수 없는 작업을 고려해 보세요.

  • 새로운 발견을 저장하세요
  • 긴 워크플로 전반에 걸쳐 연속성 유지
  • 시간이 지남에 따라 변경되는 도구 지침 관리
  • 새로운 정보에 대응하여 컨텍스트 재구성

Prompt Engineering은 컨텍스트를 정적으로 처리하지만, 에이전트는 컨텍스트가 자신이 내리는 결정 및 발견한 데이터와 보조를 맞출 때만 안정적으로 행동할 수 있어요.

컨텍스트 엔지니어링이 에이전트를 지원하는 방법

컨텍스트 엔지니어링은 에이전트가 기반, 일관성 및 지능을 유지하는 데 필요한 구조적 백본을 제공해요. 실제로 해당 구조를 제공하려면 모델이 안정적으로 탐색할 수 있는 도메인 표현이 필요하죠. 이럴 때 Knowledge Graph가 필수적이에요. 분산된 정보를 체계적이고 연결된 컨텍스트 에이전트로 전환하여 추론할 수 있게 해주거든요.

핵심 구성 요소를 한번 살펴볼까요?

추론을 위한 구조화된 정보

Knowledge Graph와 같은 구조화된 시스템은 에이전트에게 도메인의 데이터에 대한 체계적인 보기를 제공해요. 에이전트가 시스템 중단을 진단하려는 경우, Knowledge Graph를 통해 다음을 확인할 수 있죠.

  • 어떤 서비스가 어떤 서비스에 의존하는지
  • 각 서비스를 소유한 팀
  • 최근에 변경된 구성 요소
  • 유사한 패턴을 따르는 사건

이 구조를 통해 에이전트는 텍스트만으로는 불가능한 다단계 추론을 수행할 수 있어요.

외부 메모리

대부분의 작업은 모델의 내장 메모리를 초과해요. 다음을 사용하여 에이전트를 지원할 수 있어요.

  • 이전 단계를 요약하는 압축
  • 컨텍스트 창 외부에 주요 정보를 저장하는 구조화된 메모 작성
  • 장기 작업을 추적하는 영구 파일

이를 통해 에이전트는 컨텍스트 창에 과부하를 주지 않고 중요한 세부 정보를 기억할 수 있어요.

환각 감소 및 더욱 확실한 출력

검색 파이프라인이 GraphRAG(구조화된 관계 인식 컨텍스트를 검색하는 RAG의 그래프 기반 확장)을 사용하는 경우, 모델은 추측하는 대신 권위 있는 정보에 고정되어 있어요. 이러한 접지는 정확성이 중요한 운영 환경에서 매우 중요하죠.

향상된 설명 가능성

구조화된 컨텍스트는 명시적인 그래프 경로를 통해 검색되므로, 모델이 특정 출력을 생성한 이유를 항상 알 수 있어요. 이를 통해 안전성, 거버넌스 및 사용자 신뢰가 향상되죠.

고품질 컨텍스트를 위한 기반이 되는 Knowledge Graph

Knowledge Graph가 어떻게 도움이 되는지 살펴보기 전에, 요즘 많은 팀들이 Large Language Model(LLM)에 외부 정보를 전달하는 방식을 먼저 짚고 넘어가는 게 좋을 것 같아요. 바로 Retrieval-Augmented Generation(RAG)이죠. 기존의 RAG 파이프라인은 구조화되지 않은 텍스트 조각(보통 Vector Embedding 유사도에 따라 순위가 매겨진 문서 청크)을 검색해서, 이걸 모델에 컨텍스트로 전달해요. 간단한 조회 작업에는 괜찮지만, 도메인이 복잡해지고 추론이 많이 필요해지면 한계가 드러나기 시작하죠.

비정형 RAG의 한계

구조화되지 않은 RAG는 문서를 그냥 뚝 떨어진 조각으로 취급하기 때문에 몇 가지 문제가 생겨요.

  • Vector Embedding 검색은 겉보기엔 관련 있어 보이지만, 깊은 의미는 없는 텍스트를 가져올 수 있어요.
  • 관계가 연결되어 있지 않아서, 여러 단계를 거치는 질문에는 제대로 답을 못하죠.
  • 너무 긴 텍스트를 검색하면 노이즈가 많아지고, 컨텍스트 이해를 방해하기도 해요.
  • Vector Embedding 유사성은 속이 훤히 보이지 않아서 설명 가능성이 떨어져요.
  • 메타데이터나 정책 관리가 제대로 안 되면 거버넌스도 어려워지고요.

쉽게 말해서, 구조화되지 않은 RAG는 어떤 단락이 비슷하게 들리는지는 알려줘도, 내용이 어떻게 연결되는지는 알려주지 못한다는 거예요. 만약 여러분의 사용 사례가 다단계 추론, 상황 인식, 또는 규정 준수를 필요로 한다면, 텍스트뿐만 아니라 관계도 중요하겠죠?

RAG를 위한 Knowledge Graph(GraphRAG)의 장점

Knowledge Graph는 시스템에 도메인의 구조화된 모델을 제공해서 이 문제를 해결해 줘요.

이 모델은 다음과 같은 요소들을 포함하죠.

  • 고객, 서비스, 제품, 팀 같은 엔터티(Entity)
  • DEPENDS_ON 또는 OWNED_BY 같은 관계(Relationship)
  • 타임스탬프, 소유자, 소스 등의 메타데이터

이런 구조 덕분에 GraphRAG는 시스템이 다음과 같은 일들을 할 수 있게 도와줘요.

  • 관련 있는 컨텍스트 조각만 딱 골라서 검색
  • 여러 단계의 관계를 탐색해서 통찰력을 얻기
  • 검색할 때 정책에 맞게 필터링 적용
  • 설명 가능한 결과를 만들어내기

결국, 연결이 끊어진 텍스트 조각이 아니라 실제 도메인 로직을 반영하는 방식으로 시스템이 정보를 검색한다는 뜻이에요.

A flow diagram showing the GraphRAG phases from chunking, extracting, enriching, to searching

컨텍스트 엔지니어링, 어떻게 구현될까요?

그렇다면 실제로 작동하는 컨텍스트 엔지니어링 파이프라인은 어떻게 구축해야 할까요? 바로 이럴 때 그래프 기반 컨텍스트가 엄청난 힘을 발휘하는 거죠. 상황 인식 시스템 설계를 시작할 때 가장 먼저 마주치는 어려움 중 하나는 에이전트가 탐색하고 추론할 수 있는 구조화된 지식을 어디에 저장하느냐 하는 문제일 거예요.

Graph Database는 환경이 실제로 작동하는 방식을 그대로 반영해서 Entity, Relationship, 메타데이터를 표현할 수 있게 해주기 때문에, 훌륭한 기반이 되어 줘요. Neo4j는 분산된 정보를 AI 시스템이 믿고 사용할 수 있는 살아있는 컨텍스트 레이어로 바꿔주는 데 필요한 그래프 모델, 인프라, 그리고 생태계를 제공하고 있답니다.

이런 기반이 마련되면, 이제 작업을 명확한 단계로 나눌 수 있어요.

1. 에이전트에게 구조화된 살아있는 기억을 제공하세요

여기저기 흩어진 문서 뭉치에 의존하는 대신, 고객, 서비스, 사건, 종속성, 그리고 팀을 연결된 Node와 Relationship으로 모델링할 수 있어요. 그러면 에이전트는 이 연결을 따라서, 실패한 서비스가 업스트림 구성 요소와 어떻게 연결되는지, 최근에 변경된 사항은 무엇인지, 또는 어떤 Runbook을 적용해야 하는지 등을 파악할 수 있게 되죠.

이게 실제로 어떻게 돌아가는지 궁금하시다면, Neo4j AuraDB를 한번 살펴보세요. 인프라를 직접 관리할 필요 없이 항상 켜져 있는 그래프 환경을 제공해 준답니다.

2. 추론하는 방식과 똑같이 컨텍스트를 검색하세요

그래프 기반 검색은 시스템이 사람이 컨텍스트를 구성하는 방식과 비슷하게 정보를 찾도록 도와줘요. 관련 있는 시작점을 찾은 다음, 관련 개념, 종속성, 또는 정책을 따라서 바깥으로 확장해 나가는 거죠. GraphRAG Python 라이브러리 같은 도구를 사용하면 Vector Embedding 검색과 그래프 순회를 결합해서, 검색된 컨텍스트의 모든 부분이 연결되고 의미를 갖도록 만들 수 있어요.

3. 시스템을 안전하고, 설명 가능하며, 관리하기 쉽게 유지하세요.

컨텍스트가 여기저기 흩어진 문서가 아니라 구조화된 저장소에 있다면, 세분화된 액세스 제어, 감사 추적, 그리고 Query 수준 필터링을 적용할 수 있어요. 다시 말해, 에이전트가 보면 안 되는 중요한 데이터를 실수로 검색하는 일은 절대 없을 거라는 뜻이죠. 그리고 그래프 Query는 정보가 어떤 과정을 거쳐서 검색되었는지 정확하게 보여주기 때문에, 규제가 엄격한 산업에서 흔히 요구하는 투명한 의사 결정 추적을 확보할 수 있답니다.

그래프 환경 내에서 거버넌스와 설명 가능성이 어떻게 작동하는지 궁금하다면, 플랫폼에 내장된 보안 및 역할 기반 액세스 기능을 한번 살펴보세요.

4. 작업 흐름 속도를 높여주는 도구로 부담을 줄여봐요

만약 구조화되지 않은 문서가 있고, 이걸 그래프로 바꾸고 싶다면 Neo4j의 LLM Knowledge Graph Builder를 사용해보세요. 엔티티 및 관계 추출 프로세스를 자동화해서, 복잡한 ETL 작업 없이도 도메인 Knowledge Graph를 훨씬 쉽게 구축할 수 있도록 도와주거든요. 그래프가 준비되면 AuraDB는 프로덕션 환경에서 에이전트를 안정적으로 지원하는 데 필요한 지속적이고 확장 가능한 스토리지를 제공해 줄 거예요.

구조화된 메모리, 의미 있는 검색, 강력한 거버넌스, 그리고 매끄러운 개발자 워크플로우의 조합! 이 모든 걸 통해 프롬프트 중심의 프로토타입에서 실제로 확장 가능한 컨텍스트 엔지니어링 시스템으로 멋지게 전환할 수 있어요.

Screenshot of the Neo4j LLM Knowledge Graph Builder interface displaying unstructured text being converted into a visualized knowledge graph.

Prompt Engineering에서 컨텍스트 엔지니어링으로 전환

Prompt Engineering에서 컨텍스트 엔지니어링으로의 전환은, 사고방식 자체를 바꾸는 거라고 생각하면 좋을 것 같아요. 단순히 "어떻게 지시를 표현해야 할까?"를 고민하는 대신, 모델이 제대로 작동하려면 어떤 정보가 필요한지를 먼저 생각하는 거죠.

이걸 설명하는 데 유용한 방법이 바로 '컨텍스트 피라미드'입니다.

  • 피라미드의 가장 아래쪽은 지속적인 지식과 정책으로 구성돼요.
  • 중간은 동적인 메모리와 예시들이 자리 잡고 있죠.
  • 그리고 맨 위에는 즉각적인 사용자 쿼리 및 도구 출력이 놓여 있습니다.

여러분의 목표는 컨텍스트 창에 가장 작고, 가장 관련성이 높은, 즉 'high-signal' 토큰 세트를 보내는 거예요.

최소 실행 가능한 컨텍스트 (Minimum Viable Context)

MVC (Minimum Viable Context)는 모델이 딱 필요한 만큼만 볼 수 있도록 보장해줍니다. 더도 말고, 덜도 말고 딱 필요한 정보만요!

이상적인 호출에 포함되어야 할 내용은 다음과 같아요.

  • 가장 관련성이 높은 검색된 정보
  • 다음 단계에 필요한 경우 도구 정의
  • 압축된 메모리 요약

이 중 어느 하나라도 빠지면 문제가 생길 수 있어요. 정보가 너무 많으면 혼란스러워지고, 관련 없는 정보가 컨텍스트 창을 가득 채워서 중요한 정보에 대한 집중도가 떨어지죠. 게다가 정확성을 높이지도 못하면서 토큰 사용량만 늘어나게 돼요.

George A. Miller’s research shows chunking improves retention and reduces cognitive load

컨텍스트 엔지니어링을 적용하기 위한 실질적인 단계

컨텍스트 엔지니어링은 모델이 필요로 하는 바로 그 순간에, 명확하고 구조화된 high-signal 컨텍스트를 제공하는 안정적인 파이프라인으로 전환될 때 비로소 현실이 됩니다.

1. 핵심 지식 영역 및 관계 식별
예를 들어 서비스, 인시던트, 팀, 런북, 종속성 등 중요한 엔터티와 이들 간의 관계를 정의하는 거예요.

2. Knowledge Graph 구축
에이전트가 도메인을 자연스럽게 탐색할 수 있도록 이 정보를 그래프에 저장하세요.

3. 기본 RAG에서 GraphRAG로 진화
Vector Embedding 검색과 그래프 탐색을 결합해서, 필요한 정보를 정확하게 수집하는 거죠.

4. 검색 파이프라인 평가
MVC를 제공하는지 테스트하세요. 맥락 부패, 환각 또는 누락된 세부 정보의 징후를 찾으세요.

현대 AI 개발자를 위한 기술

이제 AI 작업에는 Prompt Engineering 이상의 기술이 필요해요. 더 이상 모델의 반응 방식만 형성하는 것이 아니에요. 모델이 알고 있는 내용, 새로운 정보를 학습하는 방법, 해당 정보를 사용하여 실제 시스템에서 결정을 내리는 방법을 형성하고 있죠.

이를 잘 수행하려면 다음과 같은 보다 광범위한 기능 기반이 필요해요.

  • Prompt Engineering
  • 검색 및 인덱싱
  • 에이전트 설계 및 도구 사용 프레임워크

이러한 기술을 통해 명확하게 추론하고, 자신감 있게 행동하고, 긴 워크플로우 전반에 걸쳐 일관되게 행동하는 시스템을 구축할 수 있어요.

하지만 실제로는 어떤 모습일까요?

컨텍스트 엔지니어는 모든 단계에서 모델이 보는 정보를 제어하는 ​​파이프라인을 설계해요. 검색할 항목, 구성 방법, 사용 가능한 형식으로 모델에 도달하는 방법을 결정하죠. 여러분의 작업은 고정된 에이전트와 표류하거나 환각하는 에이전트 사이의 차이가 될 거예요.

컨텍스트 엔지니어로서 수행하는 책임은 다음과 같아요.

  • 비즈니스 영역을 세상이 실제로 어떻게 작동하는지를 반영하는 Knowledge Graph로 변환
  • 적절한 순간에 적절한 컨텍스트를 표시하는 검색 파이프라인 설계
  • 시스템이 컨텍스트 창을 압도하지 않고 중요한 세부 정보를 보존할 수 있도록 메모리 전략 정의
  • 모델이 시스템과 상호 작용하는 방법을 이해하는 데 도움이 되는 도구 스키마 만들기
  • 시스템을 안전하고 예측 가능하게 유지하기 위한 정책 및 제약 조건 설정
  • 모델에 유입되는 정보가 정확하고 최신이며 관련성을 유지하도록 컨텍스트 품질을 모니터링합니다.
  • 시스템이 학습하고 발전함에 따라 런타임에 컨텍스트가 조립되는 방식을 개선합니다.

이는 생성 모델을 엔터프라이즈 환경에서 안전하게 작동하는 에이전트를 구축할 수 있도록 준비하는 운영상 안정적인 AI 시스템으로 바꾸는 작업이에요.

컨텍스트 엔지니어링이 AI 시스템의 차세대 시대를 정의하는 이유

Prompt Engineering은 여전히 ​​중요해요. 이는 올바른 기대치와 톤을 설정하는 데 도움이 되죠. 하지만 그 자체로는 복잡한 추론이나 안전한 도구 사용을 지원할 수 없어요.

컨텍스트 엔지니어링은 안정성, 확장성, 거버넌스라는 더 깊은 문제를 해결해요. Knowledge Graph는 상담원에게 상황 인식을 제공하고 환각을 줄이며 의사 결정 경로를 설명할 수 있는 구조화된 백본을 제공하죠.

단순한 상호 작용을 넘어 실제 환경에서 안정적으로 작동하는 AI 애플리케이션을 구축하는 것이 목표라면 컨텍스트 엔지니어링이 그 목표를 달성하는 길이에요. 이는 시스템이 압력을 받는 상황에서도 잘 작동하는 데 필요한 구조, 접지 및 명확성을 제공하죠. AI가 실제 추론에 사용할 수 있는 엔터티, 관계 및 정책 모델링을 위한 그래프 기반 기반을 제공하여 작업을 단순화해요.

GraphRAG에 대해 자세히 알아보기

Knowledge Graph를 사용하여 컨텍스트 엔지니어링 시스템을 설계하는 방법에 대한 실용적이고 심층적인 가이드는 Manning의필수 GraphRAG is a helpful resource. It walks you through the process of modeling your domain, designing retrieval pipelines, and implementing context that scales.

컨텍스트 엔지니어링 FAQ

컨텍스트 엔지니어링은 Prompt Engineering과 어떻게 다릅니까?

Prompt Engineering은 표현에 중점을 둬요. 컨텍스트 엔지니어링은 모델이 작업할 수 있는 올바른 지식을 제공하는 데 중점을 두죠. 프롬프트는 모델이 생각하는 방식을 형성해요. 컨텍스트는 모델이 실제로 알고 있는 내용을 형성하죠. 프롬프트를 계속 구체화해도 여전히 일관되지 않은 결과가 나온다면 이는 일반적으로 모델이 애초에 올바른 컨텍스트를 받지 못했다는 의미에요.

LLM에 맥락이 중요한 이유는 무엇입니까?

LLM은 컨텍스트 창에 있는 정보에 대해서만 추론해요. 해당 정보가 불완전하거나 오래되었거나 잡음이 있는 경우 모델은 추측으로 공백을 채우죠. 컨텍스트가 구조화되고 관련성이 있으면 모델이 훨씬 더 정확하게 작동해요. 강력한 컨텍스트는 모델이 설 수 있는 명확한 기반을 제공하므로 고급 모델이 없어도 추론이 향상되죠.

상황 AI와 프롬프트 AI의 차이점은 무엇인가요?

프롬프트 AI는 단어를 통해 응답을 제어하는 ​​데 중점을 둬요. Context AI는 적시에 올바른 지식을 제공하는 시스템을 구축하는 데 중점을 두고 있어 보다 안정적인 행동을 가능하게 하죠.
신뢰성을 원한다면 표현뿐만 아니라 모델에 대한 이해를 형성하는 시스템이 필요해요.

신속한 엔지니어링을 대체하는 것은 무엇입니까?

Prompt Engineering은 여전히 ​​유용하지만 더 이상 AI 개발의 중심이 아니에요. 현대 에이전트는 정확한 검색, 메모리 및 도구 사용에 의존하기 때문에 이제 컨텍스트 엔지니어링이 그 역할을 해요. 이러한 변화는 더 큰 추세를 반영하죠. 신뢰할 수 있는 AI는 영리한 표현이 아닌 아키텍처에서 나와요.

컨텍스트 엔지니어는 어떤 일을 하나요?

컨텍스트 엔지니어는 정보가 모델에 유입되는 방식을 설계해요. 여기에는 지식 구조화, 검색 파이프라인 구축, 도구 스키마 생성, 메모리 전략 정의, 규칙 적용, 런타임 시 컨텍스트 구체화가 포함되죠. 이들의 임무는 모델이 항상 올바른 구조에서 올바른 정보를 볼 수 있도록 해서 시스템이 자신감 있게 작동하도록 하는 거예요.


에이치시스템즈LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지

728x90
반응형

+ Recent posts