AI의 새로운 핵심 역량은 프롬프트가 아닌 "컨텍스트 엔지니어링"

• "프롬프트 엔지니어링"에서 한 단계 발전한 "컨텍스트 엔지니어링"으로 논의가 전환되고 있음
• 컨텍스트란 단순한 프롬프트 문장이 아니라, LLM이 답변을 생성하기 전 볼 수 있는 모든 정보(지침, 대화이력, 장기 메모리, 외부 정보, 가용 도구 등) 를 의미함
• 에이전트의 성공과 실패는 이제 모델의 성능보다 컨텍스트의 질에 달려 있음
• 고도화된 에이전트는 사용자의 캘린더, 과거 이메일, 연락처 등 다양한 맥락을 통합해 더 실제 문제 해결에 가까운 응답을 생성함
• 컨텍스트 엔지니어링은 상황 맞춤형 동적인 시스템 설계로, 올바른 정보와 도구를 정확한 시점에 LLM에 제공하는 과정임

---

Context Engineering이란 무엇인가

• 최근 AI 분야에서 "컨텍스트 엔지니어링" 이라는 용어가 빠르게 확산 중임
• 기존 "프롬프트 엔지니어링" 이 단일 질문 또는 명령문 설계에 집중했다면, 컨텍스트 엔지니어링은 그보다 더 폭넓고 강력한 접근
• Tobi Lutke는 이를 "LLM이 작업을 신뢰할 수 있게 풀 수 있도록 모든 컨텍스트를 제공하는 예술"로 정의함

컨텍스트의 주요 요소

• 에이전트 시스템에서 성공적으로 작동하는지 여부는 작업 메모리(working memory)에 어떤 정보가 포함될지에 의해 크게 좌우됨
• 대부분의 에이전트 실패는 모델 문제가 아니라, 적절한 컨텍스트 부족 때문임

컨텍스트의 구성 요소

• 시스템 프롬프트/지침: 모델의 행동을 정의하는 기본 지침과 예시, 규칙 등
• 유저 프롬프트: 사용자의 즉각적인 요청이나 질문
• 상태/대화 히스토리: 현재까지의 대화 흐름 및 맥락 정보
• 장기 기억: 여러 단계를 거친 이전 대화, 사용자 선호도, 과거 프로젝트 요약, 모델이 장기적으로 기억하도록 학습된 정보 모음
• RAG(검색 기반 증강): 외부 문서, 데이터베이스, API 등에서 가져온 최신의 관련성 높은 정보
• 사용 가능한 도구: 모델이 호출할 수 있는 함수, 내장 툴들의 정의 (예: check_inventory, send_email 등)
• 구조화된 출력: 모델이 따라야 할 응답 형식 정의 (예: JSON)

컨텍스트가 중요한 이유

• 실질적으로 효과적인 AI 에이전트를 만드는 요인은 복잡한 코드나 모델 품질이 아니라, 얼마나 적절한 컨텍스트를 제공하느냐임
• 단순한 "데모용" 에이전트는 사용자 요청만 받아들여 기본 응답만 제공하는 반면, "마법 같은" 에이전트는 풍부한 컨텍스트를 고려하여 훨씬 유용하고 인간다운 답변을 생성함
• 비교
  • 저품질(데모) 에이전트: 단순 요청만 보고 틀에 박힌 답변만 생성함. 예) "내일 시간 있으세요?" 메일에 "내일 가능합니다. 몇 시가 좋으신가요?" 등 기계적인 답변임
  • 고품질(마법 같은) 에이전트: 본인의 캘린더, 과거 이메일 히스토리, 상대방 신원 정보, 필요한 도구 호출 옵션 등까지 모두 활용하여 자연스럽고 상황 맞춤형 답변 생성 가능함. 예) "내일은 일정이 꽉 찼고, 목요일 오전이 비어 있으니 일정 초대장 보내드렸습니다. 가능하다면 알려주세요"
• 이처럼 알고리듬이나 모델이 중요한 게 아니라, 작업에 맞는 올바른 컨텍스트를 제공하는 것이 성공 요인임
• 대부분의 AI 에이전트 실패는 모델이 아니라 컨텍스트 설계 실패의 결과임

프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로의 진화

• 프롬프트 엔지니어링이 한 줄 텍스트 지침 최적화에 초점을 둔다면, 컨텍스트 엔지니어링은 훨씬 넓은 범위의 정보와 도구, 구조적 설계를 포함
• 컨텍스트 엔지니어링이란 "필요한 정보와 도구를, 올바른 형식과 시점에, LLM이 과업을 성취할 수 있게 시스템적으로 제공하는 설계 및 구축의 전문 역량"임

컨텍스트 엔지니어링의 특징

• 전체 시스템 설계: 컨텍스트란 단순 프롬프트 템플릿이 아니라, LLM 호출 이전에 동작하는 전체 시스템의 산출물임
• 동적 생성: 작업에 맞게 상황별로 캘린더/이메일/웹 검색 등 다양한 정보를 실시간으로 선택·가공
• 적시적소의 정보 및 도구 제공: "Garbage In, Garbage Out" 원칙, 모델에 불필요 혹은 누락된 정보가 없게끔 하는 것이 중요함
• 형식의 명확성 중요: 정보를 업로드할 때 산만하게 나열하기보다 요약·구조화가 필요하며, 도구의 사용법도 명확히 전달되어야 함

결론

• 강력하고 신뢰할 수 있는 AI 에이전트 개발의 본질은 "마법 같은 프롬프트"나 최신 모델이 아니라, 컨텍스트 엔지니어링(컨텍스트를 설계 및 제공)
• 이는 단순한 기술적 문제를 넘어, 비즈니스 요구와 목적에 맞는 정보·도구·구조화된 출력 정의 등 전방위적인 시스템 설계 역량이 필요
• LLM이 과제를 완수할 수 있도록, 정확한 시점에 적절한 정보를 올바른 형식으로 제공하는 것이 핵심

참고자료

• Tobi Lutke - "I really like the term “context engineering” over prompt engineering."
• Karpathy - "+1 for "context engineering" over "prompt engineering".
• The rise of "context engineering"
• Own your context window
• Context engineering by Simon Willison
• Context Engineering for Agents

[kimjoin2]

이름만 바뀌는 느낌이 강하내요.

[GN⁺]

Hacker News 의견

• 나는 최근 이 주제에 대해 블로그에 글을 쓴 경험이 있음 내 글 - Context Engineering 참고 바람
  Drew Breunig의 글들이 이 주제를 정말 환상적으로 다루고 있다고 생각함
  타이밍이 우연히 “context engineering”이라는 밈이 돌던 시기긴 했지만, 실제로는 그 밈과는 상관 없는 작업
  How Long Contexts Fail - 긴 컨텍스트가 실패하는 이유 글에서는 긴 컨텍스트가 어떻게 문제를 일으키는지, 소위 말하는 “context rot”가 어떻게 발생하는지에 대해 다양한 방식으로 설명
  How to Fix Your Context - 당신의 컨텍스트를 고치는 방법 글에서는 Tool Loadout, Context Quarantine, Context Pruning, Context Summarization, Context Offloading 등 다양한 테크닉에 이름을 붙여 문제 해결 방법을 제시

  • Drew Breunig의 포스트는 꼭 읽어볼 가치가 있다고 생각함
    이건 자신의 에이전트 제작뿐 아니라, 지금 에이전트 코딩을 사용할 때도 정말 중요
    이러한 한계와 행동 방식은 당분간 계속될 전망

  • 누가 최초로 context 엔지니어를 자동화하는 Logic Core를 개발할지 기대

  • 이것 역시도 **“한 달짜리 스킬”**이라고 생각함
    결국엔 수많은 다른 유행처럼 곧 사라질 것

  • 이러한 이슈들은 LLM 연구계에서는 현행 LLM의 산물로 간주
    이미 수백만 개의 툴을 동시에 쓰고, 안정적인 롱 컨텍스트를 사용하는 방법에 대한 연구가 진행 중
    앞으로는 다른 공급자와 연결이 필요한 특수 케이스를 빼면, 대부분 하나의 에이전트만으로도 충분한 상황 예상
    현행 LLM 기반으로 미래 에이전트 시스템을 설계하는 사람들은 LangChain처럼 될 가능성
    GPT-3 용으로 만든 LangChain이 GPT-3.5에서 곧바로 구식이 되어버린 현상과 같음

• LLM을 써본 사람이거나 LLM이 어떻게 작동하는지 아는 사람에게는 상당히 자명한 이야기
  프롬프트 엔지니어링이라는 “스킬” 역시 일시적인 핵으로 오래가지 않을 것이 뻔했음
  기본적으로는 LLM에게 입력(컨텍스트)과 행동(출력)을 주는 것, 그리고 이를 위한 많은 파이프라인 작업이 필요한 상황

• “파워풀하고 신뢰할 수 있는 AI 에이전트 제작이 마법의 프롬프트나 모델 업데이트 찾기에서 멀어진다”는 결론에는 동의
  “적절한 정보와 도구를 적합한 포맷, 타이밍에 제공하는 컨텍스트 엔지니어링”에 더 집중해야 한다는 말이 맞음
  그런데 그 “적절한 포맷”과 “적절한 시점”이 본질적으로 정의되어 있지 않다면, 여전히 “마법의 솔루션”을 쫓는 것 아닌가
  “적절한 정보”가 “LLM이 충분히 정확한 답을 내게 하는 정보”라면, 본질적으로 프롬프트 엔지니어링과 다른 점이 없다고 판단
  이런 비결정적 머신들은 결국 “프롬프트를 시도해보고 결과를 본다”는 접근 외에 신뢰할 만한 휴리스틱이 별로 없다고 봄

  • 결국 끝없는 마법 같은 사고
    지금 “프롬프트 엔지니어링”에서 “컨텍스트 엔지니어링”으로 이름을 바꿔도 결국 불확실한 공간에서 효과가 있는 무언가를 찾기 위해 계속 이것저것 만져보는 행위임

  • 본질적으로는 오버피팅
    프롬프트 엔지니어링이란 결국 그것임

  • “적절한 포맷, 적절한 시점”이 본질적으로 정의되어 있지 않다는 게 문제
    실제 “AI를 잘 쓰는 방법” 관련 조언은 대부분 이런 문제에서 출발
    결국은 북을 치고 무속 의식을 하는 느낌

  • 최신 이론적 프레임워크에서는 이 과정을 두 가지 탐구(Exploratory)와 발견(Discovery) 단계로 구분
    탐구 단계는 일종의 대기중 물질 분사 장치로 생각
    쉽게 식별할 수 있는 마커 물질(대개 분변 비유)을 고속으로 도입
    발견 단계는 그 확산 패턴 분석으로 개념화
    이 두 단계를 요약하면 “막 해본다” 다음에 “결과를 확인한다”로 표현 가능

  • 이제 와서 “프롬프트 엔지니어링”이 대단한 스킬이 아니라는 걸 모두가 깨닫자 AI 업계에서 목표 기준이 계속 옮겨지는 느낌

• 새로운 스킬은 결국 “프로그래밍”
  예전 스킬과 동일
  이런 것들을 이해하려면 프로그램을 직접 작성
  LLM 훈련, 인퍼런스 실행, 행동 분석하는 프로그램을 써보며 점점 더 많이 이해
  나는 초기에는 이론과 기대 결과가 있었지만, 실제로 LLM을 여러 방식으로 훈련해본 후에는 전혀 다른 결과와 확신을 얻게 됨
  실제로 도구를 구현하는 과정이 결정적 차이를 만들어냄
  나 역시 중간 난이도의 머신러닝 프로그래밍 경험만 있지만, 중간 수준의 컴파일러를 직접 만들어본 것이 복잡한 시스템에서 좋은 결과를 얻는 핵심이라고 생각
  Karpathy가 어떻게 이걸 알게 됐다고 생각?
  답은 Karpathy의 블로그에 있음

  • LLM을 이해하는 최고의 방법이 LLM을 직접 만들어보는 거라니
    컴파일러를 이해하려면 컴파일러를 직접 써보라는 조언과 같음
    기술적으로는 맞지만, 대부분은 그만큼 깊이 들어가고 싶어하지 않음

• 이 논의가 점점 WoW 같은 게임 포럼에서 게이머들이 전략을 실험하고 괴상한 집단 언어로 서로 논쟁하는 양상과 비슷해지는 느낌
  소위 전략이라는 건 거의 시행착오로 찾는 것이고, 해당 그룹 내부에서만 통하는 언어로 얘기
  프로그래밍도 점점 게이미피케이션 시대로 적응
  파워유저들이 가짜 전략을 초보자나 지나치게 게이머 기질인 경영진에게 팔아넘기는 현상

  • 나도 비슷한 시각을 가짐
    사실 이전 엔터프라이즈 소프트웨어 유행 때도 비슷한 일이 반복
    이번엔 다만 그 ‘파워유저 주도 유행’이 개발자, 즉 빌더들이 갖고 있던 영향력/통제/워크플로우 영역까지 깊숙이 침투
    요즘 개발자들이 느끼는 감정은 이전 QA, SRE, CS 직군 사람들이 “이게 대세래!” 하면서 툴링이나 관행이 강요받을 때 겪었던 기분과 다르지 않을 것

• 결론:
  “파워풀하고 신뢰할 수 있는 AI 에이전트 제작은 마법 프롬프트나 모델 업데이트가 아니라, 비즈니스 용도에 맞는 올바른 정보와 툴을 올바른 포맷과 시점에 제공하는 컨텍스트 엔지니어링이 중요”
  이건 사실 인간한테도 똑같이 적용되는 원리
  적시에 제대로 된 정보를 준다면 인간도 더 잘 해결

  • 나는 이런 피상적인 머신러닝-인간 비교 트렌드를 좋아하지 않음
    통찰도 없고, 거의 맞지도 않음

  • 결국엔 환경 내에서 효과적으로 목표 버튼을 찾아 누르는 일
    기존 소프트웨어 엔지니어링과 크게 다르지 않음
    결과만 좀 더 비결정적일 뿐

  • 나는 언제나 UX와 제품 담당자들에게 “목업, 요구사항, 인수 기준, 샘플 인·아웃풋, 이 기능이 왜 중요한지” 등에 대한 설명을 끊임없이 요청
    뇌를 스캔해서 원하는 걸 추출할 수 없는 한, 현실적으로 원하는 걸 제대로 설명하는 게 반드시 필요
    단순히 ‘감’에 의존하면 안 되는 부분

  • 더 많은 컨텍스트가 아니라, 더 나은 컨텍스트가 핵심
    (대표적 예시: X-Y problem)

• 최신 LLM에 굉장히 훌륭한 컨텍스트를 줘도 여전히 실패
  우리 회사는 벌써 2년 넘게 이 부분을 깊이 탐구
  ‘컨텍스트가 답’이라는 입장에 대한 맹신이 놀라울 정도

  • 어느 순간부터는 AI 없이 직접 작업하는 게 더 빠르다고 생각
    그게 최소한 유용한 교훈이라도 남기지, LLM 컨텍스트 생성에 몇 시간씩 쏟는 건 아니다 싶음

  • 충분한 컨텍스트를 줬는데도 LLM이 실패하는 사례가 궁금
    구체적 예시를 공유해주면 좋겠음

• 마법의 프롬프트 찾기가 정말 “프롬프트 엔지니어링”이었던 적은 없음
  본질적으로는 항상 “컨텍스트 엔지니어링”
  많은 AI 자칭 전문가들이 이걸 프롬프트 엔지니어링이라 팔았지만, 사실 본질은 잘 몰랐던 것
  RAG(검색 증강 생성)는 올해 갑자기 생긴 개념이 아님
  임베딩, 벡터 DB, 그래프 DB 등 복잡한 노하우를 래핑하는 툴도 점점 더 대중화
  대형 플랫폼들도 관련 툴을 개선해 더 많은 생태계를 제공 중

• 항상 같은 이슈로 새로운 개념을 만들고 이름만 바꾸는 듯한 느낌
  결국은 모닥불 앞에서 북 치며 주문 외는 샤먼 의식 같은 일의 반복

  • 나도 이런 방식에 처음 도전해 봤을 때 친구에게 비슷하게 묘사한 적 있음
    악마 소환하는 기분이었고, 올바른 주문을 올바른 단어로 외워서 내 명령을 잘 따르길 희망해야 하는 상황
    내 속에선 신뢰성, 반복 가능성, 강한 테스트 커버리지를 원하는 엔지니어 마음과 지금의 제어할 수 없는 복잡성 사이에서 고민
    이런 시스템으로 대규모 데모하는 사람들 정말 존경
    예전 보안 취약점 연구 데모 시절 생각
    아무리 잘 준비해도 현장에서 언제든 결과가 비틀어질 수 있어, 발표 중 땀을 뻘뻘 흘렸던 기억

• 내 경험과 정말 비슷한 관점
  LLM에 컨텍스트를 넣을 때 “이 정보만으로 인간이 풀 수 있을까?”라는 질문을 자주 활용
  과거 text2SQL 제품을 만들 때, 모델이 실패하면 실제 데이터 분석가도 “아 그 테이블은 예전 거예요. 지금은 이 테이블 써요” 같은 답을 하곤 했음
  결국엔 LLM이 ‘인간 분석가’에게 필요한 컨텍스트가 부족하면 실수한다는 것
  이 주제에서 빠진 게 있다면 바로 “평가(evaluations)”
  아직도 AI 프로젝트에서 평가 없거나 엉성하게 넘어가는 경우를 보면 놀라움
  평가가 전통적 엔지니어링의 테스트보다 더 중요
  평가 집합이 크지 않아도 되고, 문제 영역을 잘 커버하면 충분
  없으면 그저 “추측”에 불과
  그리고, 나는 “이 정보만으로 인간이 해결할 수 있나?”를 스스로 묻는 일이 많음
  인간도 못 푸는 문제를 LLM이 푸는 걸 기대하곤 했던 경험

  • 전통적인 컴퓨터 프로그래밍 법칙
    “프로그래머가 영어로 코딩할 수 있게 하자고 하면, 실제로는 프로그래머들이 영어로도 제대로 못 쓴다는 사실을 알게 된다”
    다소 농담이지만, 어느 정도 진실
    대부분의 자연어는 그다지 명확하지 않음
    만약 영어로 아주 정확히 원하는 걸 표현할 수 있다면, 차라리 그걸 기계가 해석할 언어로 바로 썼어도 됐을 것

  • 예/아니오 질문을 하면 50% 확률로 거짓 대답
    그런 특징이 있음

  • 나는 모델이 실제로 작업을 시작하기 전에 이런 질문을 먼저 하곤 함
    예를 들어, 불확실한 부분이 있으면 질문하고, 기존에 쓰이는 코드 패턴 예시를 요청하도록 지침을 주는 편
    이미 쓰이고 있는 템플릿을 예제로 삼을 수 있도록 유도

  • 데이터 사이언티스트 코스프레하는 사람들은 평가를 원하지 않음
    그래서 실제 수익화되는 제품 외에는 평가가 거의 없음
    “임금님이 알몸”이라는 말을 하게 되면 돈이 안 되기 때문
    실제 실무에 필요한 경우에는 반드시 평가 작업이 들어감