프롬프트 잘 쓰는 것만으로는 부족하다
"AI한테 물어보니까 답이 영 엉뚱해요." 팀에서 자주 듣는 말입니다. 대부분의 경우 모델이 나빠서가 아닙니다. 모델에게 필요한 정보가 충분히 전달되지 않아서입니다. Towards Data Science에 게재된 컨텍스트 엔지니어링 심층 분석 글은 이 문제를 정면으로 다룹니다. 컨텍스트 엔지니어링(Context Engineering) 이란 AI 모델의 컨텍스트 윈도우를 '성공 확률을 극대화하는 정보'로 동적으로 채우는 규율이자 방법론입니다. 프롬프트를 잘 쓰는 것과는 차원이 다른 이야기입니다.
핵심 명제는 단순합니다. 당신이 보유한 도메인 전문성을 AI 시스템이 실제로 활용할 수 있게 만들 수 있다면, 그것이 곧 경쟁 우위가 됩니다. 범용 LLM은 누구나 쓸 수 있지만, 당신 회사의 파이프라인 스테이지 정의, 과거 클로즈율 패턴, 할인 정책 로직 같은 고유 지식은 흉내 낼 수 없습니다. 문제는 그 지식을 모델에게 '어떻게' 전달하느냐입니다.
컨텍스트 빌더: 지식·도구·메모리의 삼각 구조
원문에서는 컨텍스트 빌더(Context Builder) 라는 추상 컴포넌트를 중심으로 설계를 설명합니다. 사용자 요청이 들어오면 컨텍스트 빌더가 외부 리소스에서 가장 관련성 높은 정보를 조합해 모델에게 전달하고, 모델 출력 이후에는 사용자 피드백 같은 새로운 정보를 저장합니다. 이 구조가 관리해야 할 자원은 세 가지입니다.
- 지식(Knowledge): 도메인 특화 정보. 범용 AI를 도메인 전문가로 만드는 핵심 재료
- 도구(Tools): 에이전트가 실제 시스템과 상호작용하는 능력 (CRM 조회, 계산, 알림 등)
- 메모리(Memory): 사용자 피드백과 과거 맥락을 학습해 개인화된 행동을 가능케 하는 레이어
이 세 요소가 성숙할수록 상호 의존성이 생기고, 이를 조율하는 오케스트레이션이 시스템의 품질을 좌우합니다.
RAG는 시작점일 뿐 — 왜 대부분의 RAG MVP가 실패하나
RAG(Retrieval-Augmented Generation)는 컨텍스트 엔지니어링의 가장 기본적인 패턴입니다. 문서를 청크로 나누고, 벡터 임베딩으로 변환해 DB에 저장한 뒤, 쿼리가 들어오면 유사도 검색으로 관련 청크를 프롬프트에 주입하는 방식입니다. 국내 개발자 커뮤니티(velog)의 관련 분석도 이 구조를 명확하게 정리하고 있습니다: 키워드 검색, 심볼 검색, 벡터 검색, 의존성 그래프 확장을 결합한 하이브리드 리트리벌이 실제 시스템의 정답에 가깝다고 말합니다.
그런데 원문은 날카로운 진단을 내놓습니다. "모든 자사 B2B AI팀은 RAG 이니셔티브를 갖고 있지만, 대부분의 프로토타입과 MVP는 도입에 실패한다." 이유는 순진한 RAG의 세 가지 과잉단순화 때문입니다. ① 고립된 텍스트 단편을 진실의 원천으로 사용, ② 문서 내부 일관성 가정, ③ '관련성'을 '유사도'로 축소. 실제 엔터프라이즈 문서는 업데이트되고, 정책은 진화하고, 같은 개념이 팀마다 다르게 문서화됩니다. 이 혼란을 그대로 모델에게 넘기면 리더십이 신뢰할 수 없는 아웃풋이 나옵니다.
지식 그래프: RAG의 한계를 넘는 구조화된 표현
원문이 제시하는 다음 단계는 지식 그래프(Knowledge Graph) 입니다. 문서를 느슨하게 연결된 아카이브로 보는 대신, 비즈니스의 핵심 객체와 관계를 모델링합니다. 딜, 세그먼트, 어카운트, 담당자 같은 핵심 비즈니스 객체를 정의하는 온톨로지, 복잡한 비계층적 의존성을 담는 카노니컬 지식 그래프, 과거 의사결정 추적을 기록하는 컨텍스트 그래프 등 세 유형을 상황에 따라 조합합니다.
중요한 실천 포인트가 있습니다. 그래프는 일회성 구축 투자가 아니라 지속적 협업 과정이어야 합니다. 사용자가 일상 업무를 수행하면서 AI 시스템과 함께 지식을 축적해 나가는 구조를 만들면, 도입 장벽도 낮추고 시스템 품질도 높일 수 있습니다. GraphRAG 같은 접근법이 이 통합의 청사진을 제공합니다. 단, 그래프 설계에는 명확한 의도가 필요합니다 — 무엇을 인코딩할지, 어떻게 유지할지, 추론 사이클에서 어떤 부분을 모델에 노출할지.
보안과 신뢰: 엔터프라이즈 RAG의 숨겨진 리스크
RAG를 프로덕션에 올리기 전에 반드시 짚어야 할 지점이 있습니다. dev.to의 보안 심층 분석에 따르면, 일반적인 RAG 파이프라인에는 최소 다섯 곳의 데이터 노출 지점이 존재합니다. 문서 수집, 임베딩 생성, 벡터 저장, 쿼리 처리, 응답 생성 — 각 단계에서 민감 데이터가 외부 서비스를 거칩니다. Vec2Text 공격은 임베딩 벡터에서 원본 텍스트를 92% 정확도로 복원할 수 있음을 보여줬고, BadRAG는 코퍼스의 0.04%만 오염시켜도 98.2%의 공격 성공률을 달성합니다. 컨텍스트 엔지니어링의 정교함이 높아질수록 보안 설계도 함께 정교해져야 합니다.
AI-First 팀에게 주는 시사점
OrkaJS 같은 TypeScript 기반 RAG 프레임워크가 등장하면서 파이프라인 구축의 기술적 장벽은 낮아지고 있습니다. 하지만 원문의 핵심 메시지는 오히려 기술 이전에 있습니다: 도메인 전문가와 엔지니어의 긴밀한 협업. 도메인 전문가는 지식과 워크플로우를 인코딩하고, 엔지니어는 지식 표현, 오케스트레이션, 동적 컨텍스트 구성을 담당합니다. 이 역할 분담 없이는 아무리 정교한 기술 스택도 빈 껍데기입니다.
결국 컨텍스트 엔지니어링이 중요한 이유는 역설적입니다. AI 모델 자체는 점점 범용화·상품화되고 있습니다. 차별화는 모델이 아니라, 모델에게 무엇을 어떻게 전달하는가에서 나옵니다. 기획 단계부터 도메인 지식의 구조화를 고민하고, RAG를 프로토타입이 아닌 지속 진화하는 지식 시스템으로 바라보는 팀이 12~18개월 후 진짜 경쟁 우위를 가져갈 것입니다. AI 도구는 이제 팀원입니다 — 그 팀원에게 제대로 된 맥락을 전달하는 것이 테크 리드의 새로운 핵심 역량입니다.