경계는 경쟁이 아니라 계층이다
프롬프트 엔지니어링과 컨텍스트 엔지니어링은 자주 비교된다. 그래서 둘 중 하나가 다른 하나를 대체한다고 오해하기 쉽다. 하지만 실제 시스템에서는 둘이 경쟁하지 않는다. 서로 다른 계층에서 작동한다.
프롬프트 엔지니어링은 모델에게 어떻게 응답해야 하는지 알려주는 기술이다. 역할을 정하고, 지시문을 쓰고, 예시를 넣고, 출력 형식을 고정하고, 하지 말아야 할 행동을 제한한다. "고객 지원 담당자처럼 답하라", "JSON 형식으로 출력하라", "모르면 모른다고 말하라", "다음 세 단계를 따라 분석하라" 같은 문장이 여기에 속한다.
컨텍스트 엔지니어링은 모델이 무엇을 보고 판단해야 하는지를 설계하는 기술이다. 시스템 프롬프트, 검색된 문서, 대화 이력, 사용자 프로필, 장기 메모리, 도구 호출 결과, 데이터베이스 조회값, 메타데이터, 권한, 정책, 출처 정보까지 포함한다. Anthropic은 컨텍스트 엔지니어링을 추론 시점에 모델에게 들어가는 토큰, 즉 정보의 집합을 최적으로 선별하고 유지하는 전략으로 설명한다1.
한 문장으로 줄이면 이렇다.
프롬프트 엔지니어링은 지시의 설계다.
컨텍스트 엔지니어링은 입력 환경의 설계다.
좋은 프롬프트는 여전히 중요하다. 모호한 지시문은 좋은 컨텍스트 위에서도 나쁜 답을 만든다. 하지만 운영 환경에서는 지시문만 좋아서는 부족하다. 모델이 최신 가격표를 보지 못하고, 사용자의 권한을 알지 못하고, 이전 도구 호출 결과를 받지 못했다면 아무리 정교한 문장도 정확한 답을 보장하지 못한다.
프롬프트 엔지니어링이 강한 영역
프롬프트 엔지니어링만으로 충분한 작업도 많다. 조건은 단순하다. 필요한 정보가 사용자의 입력 안에 이미 들어 있고, 외부 지식이나 상태가 거의 필요하지 않은 경우다.
예를 들어 다음 작업은 프롬프트 설계의 효과가 크다.
긴 글을 세 문장으로 요약하기
이메일을 더 정중한 문체로 바꾸기
한국어 문장을 영어로 번역하기
리뷰를 긍정, 부정, 중립으로 분류하기
회의록에서 액션 아이템만 추출하기
주어진 글을 특정 독자 수준에 맞게 다시 쓰기
이런 작업에서는 "무엇을 보게 할 것인가"보다 "어떻게 처리하게 할 것인가"가 더 중요하다. 사용자가 원문을 제공했고, 모델은 그 원문을 바탕으로 변환하거나 분류하거나 정리하면 된다.
이때 좋은 프롬프트는 세 가지를 분명히 한다.
첫째, 작업을 명확히 말한다. "요약해줘"보다 "핵심 의사결정, 근거, 남은 쟁점을 나누어 요약해줘"가 낫다.
둘째, 출력 형식을 고정한다. "표로 정리해줘", "불릿 5개로 작성해줘", "다음 JSON 스키마를 지켜줘"처럼 결과의 모양을 정하면 후속 처리도 쉬워진다.
셋째, 좋은 예시를 제공한다. 특히 분류, 평가, 문체 변환처럼 기준이 애매한 작업에서는 few-shot 예시가 효과적이다. 예시는 모델에게 "이런 입력에는 이런 식으로 답하라"는 패턴을 보여준다.
즉, 단일 입력 안에 충분한 정보가 있고 결과의 품질이 표현 방식에 좌우된다면 프롬프트 엔지니어링이 가장 빠르고 경제적인 출발점이다.
컨텍스트 엔지니어링이 필요한 순간
문제는 시스템이 현실의 업무로 들어갈 때 시작된다. 고객 지원, 코드 에이전트, 금융 분석, 법무 검토, 내부 지식 검색, 데이터베이스 질의, 영업 코파일럿은 단일 프롬프트로 끝나지 않는다.
이런 작업은 다음 정보를 필요로 한다.
최신 문서와 변경 이력
조직별 업무 규칙
사용자별 접근 권한
이전 대화와 작업 상태
외부 도구의 선택 기준
도구 호출 결과
답변의 출처와 감사 가능성
정책, 보안, 개인정보 제약
예를 들어 고객이 "제 요금제에서 이 기능을 쓸 수 있나요?"라고 묻는다고 하자. 프롬프트에 "정확히 답하고, 모르면 추측하지 마라"라고 쓰는 것은 좋은 출발이다. 그러나 모델이 고객의 현재 요금제, 최신 기능별 가격표, 지난달 변경된 약관, 해당 고객의 지역 정책을 보지 못한다면 답은 둘 중 하나다. 그럴듯하게 추측하거나, 답할 수 없다고 말한다. 둘 다 운영 시스템에서는 좋은 결과가 아니다.
이때 성능을 좌우하는 것은 문장 다듬기가 아니다. 필요한 정보를 어떤 저장소에서 가져올지, 어떤 버전을 신뢰할지, 어떤 사용자가 어떤 정보를 볼 수 있는지, 모델에게 얼마나 압축해서 넣을지의 문제다. Neo4j는 복잡한 에이전트 시스템에서 단순 프롬프트만으로는 기억, 도구 사용, 최신 정보, 구조화된 지식을 안정적으로 다루기 어렵다고 설명한다2.
컨텍스트 엔지니어링이 필요한 신호는 분명하다.
같은 질문인데 사용자나 시점에 따라 답이 달라져야 한다.
답변이 내부 데이터나 최신 문서에 의존한다.
모델이 도구를 선택하고 호출해야 한다.
이전 단계의 결과가 다음 단계의 판단에 영향을 준다.
권한, 보안, 감사 로그가 중요하다.
답변에 출처가 필요하다.
프롬프트가 점점 길어지고 중복 규칙이 늘어난다.
이 중 하나라도 강하게 해당하면 프롬프트 문제가 아니라 컨텍스트 문제일 가능성이 높다.
프롬프트에 지식을 박아 넣는 방식의 한계
많은 팀이 처음에는 모든 것을 프롬프트에 넣는다. "매출은 환불을 제외한 순매출로 계산하라", "VIP 고객은 최근 12개월 구매액이 1천만 원 이상인 고객이다", "A 상품의 환불 가능 기간은 14일이다", "유럽 고객에게는 이 문구를 쓰지 마라" 같은 규칙을 시스템 프롬프트에 계속 추가한다.
초기에는 잘 작동하는 것처럼 보인다. 하지만 곧 문제가 생긴다.
첫째, 변경 추적이 어렵다. 가격표가 바뀌었을 때 어떤 프롬프트를 고쳐야 하는지 알기 어렵다. 같은 규칙이 여러 프롬프트에 조금씩 다른 문장으로 들어가 있으면 더 위험하다.
둘째, 재사용이 어렵다. 고객 지원 에이전트, 영업 에이전트, 데이터 분석 에이전트가 모두 같은 정책을 필요로 하는데 각자 프롬프트에 따로 복사해 두면 일관성이 깨진다.
셋째, 입력이 비대해진다. 규칙과 예외 조건을 계속 추가하면 모델이 봐야 할 토큰이 늘어난다. 긴 컨텍스트는 비용을 높이고, 중요한 정보가 묻힐 위험도 키운다. Anthropic은 컨텍스트가 늘어날수록 모델의 주의가 분산되고 회상 정확도가 떨어지는 현상을 설명하며, 컨텍스트를 유한한 자원으로 다뤄야 한다고 강조한다1.
넷째, 거버넌스가 약해진다. "개인정보를 출력하지 마라"라는 문구는 안전장치가 될 수 있지만, 실제 접근 제어를 대신할 수는 없다. 권한 검사는 모델이 보기 전에 시스템 레이어에서 처리되어야 한다.
따라서 자주 바뀌고 여러 곳에서 공유되는 지식은 프롬프트가 아니라 인프라로 분리하는 편이 낫다. 비즈니스 규칙은 정책 레이어에, 지표 정의는 의미 계층에, 문서는 검색 가능한 저장소에, 데이터 출처와 품질 정보는 메타데이터 카탈로그에 둔다. 실행 시점에는 현재 작업에 필요한 조각만 골라 컨텍스트로 주입한다. Atlan도 기업 환경에서는 지표 정의, 계보, 정책, 의미 계층 같은 맥락을 프롬프트에 박아 넣기보다 지속 가능한 컨텍스트 레이어로 관리해야 한다고 설명한다3.
운영 문제는 대개 문구 문제가 아니다
프로덕션에서 반복되는 실패를 보면 원인이 더 분명해진다.
모델이 환각을 일으킨다. 오래된 정보를 사용한다. 엉뚱한 도구를 호출한다. 사용자가 볼 수 없는 정보를 답한다. 같은 질문에 매번 다른 기준을 적용한다. 입력 토큰이 늘어나 비용이 계속 증가한다.
이 문제들은 프롬프트 문장을 조금 바꾸는 것으로 줄어들 수는 있지만, 근본적으로 해결되지는 않는다.
환각은 "정확히 답하라"는 지시보다 올바른 검색 결과와 출처 주입으로 줄어든다. 오래된 정보 사용은 "최신 정보를 사용하라"는 문구보다 문서 버전 관리와 신선도 필터로 막아야 한다. 잘못된 도구 선택은 "적절한 도구를 사용하라"가 아니라 도구 설명, 입력 스키마, 호출 조건, 실패 시 처리 규칙을 명확히 해야 줄어든다. 권한을 넘는 답변은 프롬프트가 아니라 데이터 접근 제어와 감사 로그가 필요하다.
결국 운영 환경의 품질은 좋은 문장보다 좋은 정보 인프라에서 더 크게 갈린다. 검색 품질, 컨텍스트 압축, 메모리 관리, 도구 결과 주입, 데이터 거버넌스, 출처와 계보 관리가 함께 설계되어야 한다. Contextual AI도 컨텍스트 엔지니어링을 단순 RAG보다 넓은 개념으로 설명하며, 데이터 수집, 파싱, 검색, 재랭킹, 필터링, 접근 제어, 평가까지 포함하는 전체 시스템으로 본다4.
실무 판단 기준
현장에서 두 접근을 나누는 기준은 복잡하지 않다. 먼저 프롬프트로 시작하되, 작업이 외부 세계와 연결되는 순간 컨텍스트 엔지니어링으로 확장한다.
다음 질문을 던져보면 된다.
사용자의 입력만으로 답할 수 있는가?
최신 정보나 내부 문서가 필요한가?
사용자별 권한이 답변에 영향을 주는가?
이전 대화나 작업 상태를 기억해야 하는가?
도구 호출이나 데이터베이스 조회가 필요한가?
답변의 출처를 남겨야 하는가?
같은 규칙을 여러 에이전트가 공유하는가?
프롬프트가 지식 저장소처럼 길어지고 있는가?
1번만 "예"이고 나머지가 대부분 "아니오"라면 프롬프트 엔지니어링이 충분할 수 있다. 명확한 지시, 적절한 예시, 일관된 출력 스키마에 집중하면 된다.
반대로 2번 이후 질문에 "예"가 많다면 컨텍스트 엔지니어링이 필요하다. 검색 파이프라인, 메모리 정책, 도구 정의, 권한 필터, 출처 표기, 컨텍스트 압축 전략을 함께 설계해야 한다.
좋은 시스템은 둘을 결합한다
프롬프트 엔지니어링은 사라지지 않는다. 오히려 컨텍스트 엔지니어링 안에서 더 분명한 역할을 갖는다. 프롬프트는 모델의 행동 계약이다. 무엇을 해야 하는지, 어떤 형식으로 답해야 하는지, 어떤 경우에 거절해야 하는지, 어떤 기준으로 출처를 표시해야 하는지 알려준다.
컨텍스트 엔지니어링은 그 계약을 실행할 재료를 공급한다. 모델이 볼 문서, 기억할 상태, 사용할 도구, 적용할 정책, 검증할 출처를 준비한다.
따라서 실무적인 순서는 다음과 같다.
먼저 프롬프트로 지시와 출력 계약을 명확히 한다. 그다음 작업에 필요한 정보가 단일 입력을 넘어서는지 확인한다. 외부 지식, 상태, 도구, 권한, 최신성, 감사 가능성이 필요해지는 순간 컨텍스트 레이어를 설계한다.
좋은 프롬프트는 모델이 일을 수행하는 방식을 정리한다. 좋은 컨텍스트는 모델이 일을 수행할 수 있는 현실을 제공한다. 둘 중 하나만으로는 충분하지 않다. 단순한 작업에서는 프롬프트가 대부분의 차이를 만들고, 운영 환경에서는 컨텍스트 인프라가 더 큰 차이를 만든다.
이 경계를 이해하면 불필요한 프롬프트 수정을 멈출 수 있다. 그리고 진짜 문제, 즉 모델이 봐야 할 정보를 어떻게 고르고, 구조화하고, 최신 상태로 유지할 것인지에 집중할 수 있다.
참고
1Effective context engineering for AI agents
2Why AI Teams Are Moving From Prompt Engineering to Context Engineering
3Context Engineering vs Prompt Engineering: What Enterprise AI Teams Need to Know
4What is Context Engineering? Definition, Benefits & Best Practices | Contextual AI
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.