자, 여러분 안녕하세요! 일타 강사 저스틴입니다. 오늘 강의는 2025년 6월 30일에 작성된 Philipp Schmid 님의 블로그 글 “The New Skill in AI is Not Prompting, It’s Context Engineering”을 기반으로 진행됩니다. 인공지능(AI) 분야에서 새롭게 떠오르는 핵심 기술, 바로 ‘Context Engineering’에 대해 쉽고 명쾌하게 파헤쳐 보겠습니다!

본문 전개 (강의):

Context Engineering이란 무엇인가?

최근 AI 업계의 화두는 Prompt Engineering에서 Context Engineering으로 옮겨가고 있습니다. Tobi Lutke는 Context Engineering을 “LLM(Large Language Model)이 과제를 해결할 수 있도록 모든 맥락을 제공하는 기술”이라고 정의했는데요. 아주 적절한 표현입니다.

Agent의 중요성이 커지면서, 제한된 작업 기억에 어떤 정보를 로드하느냐가 더욱 중요해졌습니다. Agent의 성공과 실패를 가르는 가장 큰 요인은 바로 제공하는 맥락의 품질이라는 것을 알 수 있습니다. 이제 Agent의 실패는 모델 자체의 문제가 아니라, 맥락의 문제인 경우가 더 많다는 거죠. 자, 이 부분은 별표 세 개!

맥락(Context)의 정의

Context Engineering을 이해하려면, 먼저 “맥락”에 대한 정의를 확장해야 합니다. 단순히 LLM에 보내는 프롬프트 하나만을 맥락이라고 생각하면 안 됩니다. 모델이 응답을 생성하기 전에 보는 모든 것을 맥락이라고 생각해야 합니다.

Instructions / System Prompt (시스템 프롬프트): 대화 중 모델의 행동을 정의하는 초기 지침 세트입니다. 예시, 규칙 등을 포함할 수 있고, 또 포함해야 합니다.
User Prompt (사용자 프롬프트): 사용자가 즉시 던지는 작업 또는 질문입니다.
State / History (단기 기억): 현재 대화 내용, 즉 사용자와 모델 간의 이전 응답들을 포함합니다.
Long-Term Memory (장기 기억): 이전 대화에서 얻은 지속적인 지식 기반으로, 학습된 사용자 선호도, 과거 프로젝트 요약, 또는 미래 사용을 위해 기억해야 할 사실들이 저장됩니다.
Retrieved Information (RAG – 검색 증강 생성): 특정 질문에 답변하기 위해 문서, 데이터베이스, API 등에서 가져온 외부의 최신 정보입니다.
Available Tools (사용 가능한 도구): inventory 확인, 이메일 보내기 등 LLM이 호출할 수 있는 모든 기능 또는 내장 도구에 대한 정의입니다.
Structured Output (구조화된 출력): JSON 객체와 같이 모델 응답 형식에 대한 정의입니다.

왜 Context Engineering이 중요한가?

진정으로 효과적인 AI Agent를 구축하는 비결은 복잡한 코드 작성 기술이 아니라, 얼마나 양질의 맥락을 제공하느냐에 달려있습니다. Agent 구축은 코드나 프레임워크보다 맥락의 품질이 중요하다는 의미입니다. Philipp Schmid 님은 저렴한 데모 Agent와 “마법 같은” Agent의 차이를 맥락의 품질에서 찾고 있습니다.

예를 들어, AI 비서에게 간단한 이메일을 기반으로 회의 일정을 잡도록 요청하는 상황을 상상해 봅시다.

저렴한 데모 Agent: 맥락이 부족합니다. 사용자의 요청만 보고 다른 정보는 보지 못합니다. 코드는 완벽하게 작동하여 LLM을 호출하고 응답을 받지만, 결과는 무미건조하고 도움이 되지 않습니다.
마법 같은 Agent: 풍부한 맥락으로 구동됩니다. 코드는 응답 방법을 파악하는 것이 아니라, LLM이 목표를 달성하는 데 필요한 정보를 수집하는 데 집중합니다. LLM을 호출하기 전에 다음과 같은 맥락을 확장합니다.
- 달력 정보 (일정이 꽉 차 있음을 보여줍니다).
- 이 사람과의 과거 이메일 (적절한 비공식적 어조를 결정하기 위해).
- 연락처 목록 (이 사람이 핵심 파트너임을 식별하기 위해).
- send_invite 또는 send_email 도구.

그러면 다음과 같은 응답을 생성할 수 있습니다.

“Hey Jim! Tomorrow’s packed on my end, back-to-back all day. Thursday AM free if that works for you? Sent an invite, lmk if it works.”

마법은 더 똑똑한 모델이나 더 영리한 알고리즘에 있는 것이 아닙니다. 바로 올바른 과제에 적합한 맥락을 제공하는 데 있습니다. 이것이 Context Engineering이 중요한 이유입니다. Agent의 실패는 모델의 실패가 아니라 맥락의 실패입니다.

Prompt Engineering에서 Context Engineering으로

Prompt Engineering은 완벽한 지침 세트를 텍스트 문자열 하나에 담는 데 집중하는 반면, Context Engineering은 훨씬 더 광범위합니다. 간단하게 정의해 보겠습니다.

Context Engineering은 LLM이 과제를 완수하는 데 필요한 모든 것을 제공하기 위해 적절한 정보와 도구를 적절한 형식으로 적절한 시기에 제공하는 동적 시스템을 설계하고 구축하는 학문입니다. 자, 이 부분도 별표 세 개!

Context Engineering은 단순히 프롬프트 템플릿이 아닌 시스템입니다. 즉, 주요 LLM 호출 전에 실행되는 시스템의 결과물입니다. 또한 동적입니다. 즉, 즉각적인 작업에 맞춰 실시간으로 생성됩니다. 어떤 요청에는 달력 데이터가 필요하고, 다른 요청에는 이메일이나 웹 검색이 필요할 수 있습니다. 핵심은 모델이 중요한 세부 정보를 놓치지 않도록 하는 것입니다 (“Garbage In, Garbage Out”). 즉, 지식(정보)과 역량(도구)을 필요할 때만 제공해야 합니다. 또한 형식이 중요합니다. Philipp Schmid 님은 간결한 요약이 원시 데이터 덤프보다 낫고, 명확한 도구 스키마가 모호한 지침보다 낫다고 강조합니다.

강의 마무리:

결론적으로, 강력하고 안정적인 AI Agent를 구축하는 것은 마법 같은 프롬프트나 모델 업데이트를 찾는 것보다 Context Engineering, 즉 적절한 정보와 도구를 적절한 형식으로 적절한 시기에 제공하는 데 달려 있습니다. 이는 비즈니스 사용 사례를 이해하고, 출력을 정의하고, LLM이 “과제를 완수”할 수 있도록 필요한 모든 정보를 구조화하는 다기능적 과제입니다. Philipp Schmid 님은 Context Engineering의 중요성을 강조하며 글을 마무리합니다.

자, 오늘 강의는 여기까지입니다! Context Engineering, 이제 여러분도 전문가가 되셨을 겁니다! 다음 강의에서 또 만나요!