컨텍스트 엔지니어링이 새로운 프롬프트 엔지니어링이다

2025년 9월, Anthropic은 한 분야를 조용히 은퇴시킨 엔지니어링 글을 올렸습니다.

컨텍스트 엔지니어링은 프롬프트 엔지니어링의 자연스러운 다음 단계다. 프롬프트 엔지니어링이 LLM 지시문을 쓰고 정리하는 방법을 가리킨다면, 컨텍스트 엔지니어링은 LLM 추론 과정에서 최적의 토큰 묶음을 골라내고 유지하는 전략을 가리킨다.

그 글은 한 범주의 죽음을 알리는 형식이 아니었습니다. 하지만 실제로는 그랬습니다. 2년 동안 사람들이 “프롬프트 엔지니어링”이라는 이름으로 해 오던 일이 이제 더 큰 무언가의 부분집합이 되었고, 진짜 지렛대는 그 더 큰 쪽에 있었습니다.

몇 달 앞서 Andrej Karpathy가 한 문장으로 그 개념적 토대를 놓았습니다.

LLM은 CPU다. 컨텍스트 창은 RAM이다. 컨텍스트 엔지니어링은 매 단계마다 무엇을 RAM에 올릴지 골라내는 운영체제다.

이 비유는 프롬프트 엔지니어링 튜토리얼 천 편보다 이 분야에 더 큰 기여를 했습니다.

프롬프트 엔지니어링은 실제로 무엇이었나

신비로운 껍질을 벗겨 내면 프롬프트 엔지니어링은 세 가지였습니다.

• 표현의 요령. “심호흡을 하세요.” “당신은 X 전문가입니다.” “단계별로 생각하세요.” 추론 모드로 슬쩍 밀어 줘야 했던 약한 모델에게는 통했습니다.
• 형식 강제. 예시와 구분자, 역할극 뼈대를 동원해 구조화된 출력을 억지로 끌어내는 일. 모델이 스키마를 안정적으로 따르지 못하던 시절에는 필요했습니다.
• 탈옥의 이웃. 이 분야의 절반은 안전 계층을 우회하는 일이었고, 나머지 절반은 서식 계층을 우회하는 일이었습니다.

2026년이 되자 이 셋은 대부분 모델 수준에서 해결됐습니다. Claude 4와 GPT-5는 시키지 않아도 추론합니다. JSON 스키마를 그대로 따릅니다. 형식이 잘 갖춰진 도구 호출을 만들어 냅니다. 이제 프롬프트의 문구는 거의 중요하지 않습니다. 중요한 것은 프롬프트 주변에 무엇이 있느냐입니다.

컨텍스트 엔지니어링은 실제로 무엇인가

컨텍스트 엔지니어링은 한 턴 동안 LLM의 작업 기억에 들어가는 모든 것을 설계하는 일입니다. 프롬프트는 그중 하나의 구성 요소일 뿐이고, 지렛대는 나머지 구성 요소들에 있습니다.

2026년 기준, 컨텍스트 봉투 전체는 이렇습니다.

• 시스템 프롬프트: 정체성, 행동, 절대 규칙, 출력 형식.
• 도구 정의: 모델이 부를 수 있는 함수, 그 함수가 하는 일, 언제 써야 하는지.
• 검색된 지식: 벡터 스토어나 파일 시스템에서 끌어온 문서, 조각, 임베딩.
• 작업 디렉터리 상태: 모델이 읽고 고치고 grep할 수 있는 파일들. CLAUDE.md, AGENTS.md, helpers.py, 프로젝트 README.
• 메시지 기록: 이전 턴들, 이전 도구 호출과 그 결과.
• 실시간 데이터: API 응답, 검색 결과, 페이지 DOM, 데이터베이스 행.
• 예시: 원하는 동작을 보여 주는 few-shot 시연.

컨텍스트 엔지니어링은 이 중 무엇이 이번 작업에 중요한지, 어떤 순서로, 어느 밀도로, 얼마나 자주 갱신할지를 정하는 일입니다.

프롬프트 엔지니어는 이렇게 물었습니다. 모델이 옳은 일을 하도록 어떻게 문장을 다듬을까?

컨텍스트 엔지니어는 이렇게 묻습니다. 프롬프트 주변의 토큰을 어떻게 배치해야 옳은 일이 가장 자연스러운 다음 수가 될까?

Anthropic의 글은 이 질문을 더 날카롭게 벼려 냅니다.

어떤 컨텍스트 구성이 우리가 원하는 모델의 행동을 이끌어 낼 가능성이 가장 높은가?

한 문장에 이 분야 전체가 담겨 있습니다.

왜 이렇게 빨리 프롬프트 엔지니어링을 대체했나

2024년 중반부터 2025년 말 사이에 세 가지가 나란히 움직였습니다.

컨텍스트 창이 싸졌습니다. 100만 토큰 컨텍스트란 코드베이스 전체와 문서 전체, 대화 기록 전체를 모델에 던져 넣고 필요할 때 다시 읽게 할 수 있다는 뜻입니다. 2023년 프롬프트 엔지니어링을 지배하던 사전 청킹과 검색 곡예가 선택 사항이 됐습니다. 그냥 파일을 올리면 됩니다.

도구 사용이 믿을 만해졌습니다. 모델이 검증 계층 없이도 형식이 잘 갖춰진 함수 호출을 내놓기 시작했습니다. 그러면서 도구 표면이 프롬프트 위에 덧댄 부속물이 아니라 컨텍스트의 일급 구성 요소가 되었습니다.

에이전트가 더 이상 시연품이 아니게 됐습니다. 200턴짜리 에이전트 루프를 돌릴 때, 1턴의 프롬프트는 50턴쯤이면 아무 의미가 없습니다. 중요한 것은 작업 디렉터리에 누적된 상태, 메시지 기록을 압축하는 전략, 무엇을 쳐냈고 무엇을 요약했으며 무엇을 다시 가져왔는가입니다. 그것이 컨텍스트 엔지니어링입니다. “지시문을 어떻게 쓸까”와는 아무 상관이 없습니다.

이 셋이 참이 되자 최적화의 무게중심이 위층으로 옮겨 갔습니다. 프롬프트는 값싸졌고, 컨텍스트가 병목이 되었습니다.

Karpathy의 OS 비유를 끝까지 풀어 보면

Karpathy의 CPU/RAM 구도는 진지하게 받아들일 가치가 있습니다. 이 분야가 실무에서 어떻게 굴러가는지를 그대로 규정하기 때문입니다.

LLM이 CPU라면:

• 컨텍스트 창은 RAM입니다. 유한하고, 빠르고, 바이트당 비싸고, 매 턴 비워집니다.
• 디스크의 파일은 하드 드라이브입니다. 읽는 데 느리지만 무한합니다. 이번 단계에 어떤 파일을 RAM에 올릴지 골라내는 것이 여러분의 몫입니다.
• 시스템 프롬프트는 펌웨어입니다. 세션마다 한 번 설정되고 늘 존재하며, CPU가 할 수 있는 일과 없는 일을 정합니다.
• 도구 정의는 디바이스 드라이버입니다. CPU가 무엇과 대화할 수 있는지 드러냅니다(파일 시스템, HTTP, 브라우저, 데이터베이스).
• 검색은 페이징입니다. 필요할 때 디스크에서 RAM으로 바이트를 끌어오고, 필요 없어지면 밀어냅니다.
• 에이전트 루프는 스케줄러입니다. 다음에 무엇을 올리고, 무엇을 내리고, 무엇을 요약할지 결정합니다.

컨텍스트 엔지니어의 일은 이 스케줄러를 설계하는 것입니다. 어떤 종류의 작업에 어떤 파일을 올릴지, 기록을 어떻게 압축할지, 언제 새 데이터를 다시 가져오고 언제 오래된 데이터를 믿을지, 무엇을 펌웨어(시스템 프롬프트)에 두고 무엇을 흘려보낼지.

이건 추상적인 이야기가 아닙니다. Anthropic이 Claude Code 안에서 정확히 하는 일이고, Cursor가 에이전트 모드에서 정확히 하는 일이며, 하니스 패턴이 형식화한 바로 그것입니다. 도구 표면 하나와, 모델이 진행하면서 스스로 골라 담는 작업 디렉터리 하나.

공들일 가치가 있는 구성 요소, 순위대로

2026년에 LLM을 쓰는 무언가를 만들고 있다면, 대략 영향이 큰 순서로 이렇습니다.

1. 작업 디렉터리. 어떤 파일이 있는지, 이름이 어떻게 붙었는지, 첫 20줄이 어떻게 생겼는지. 에이전트는 이 파일들을 grep하고 읽고 고칠 것입니다. 이것들이 에이전트의 모든 판단을 좌우합니다. 시간을 쏟기에 단연 가장 지렛대가 큰 곳입니다.

2. CLAUDE.md / AGENTS.md 같은 프로젝트 메타 파일. 에이전트의 방향을 잡아 주는 문서입니다. 이 프로젝트가 무엇이고, 관례가 무엇이며, 무엇을 해야 하고 하지 말아야 하는지. 2026년의 모든 코딩 에이전트는 이 중 하나를 가장 먼저 읽습니다.

3. 도구 설계. 어떤 도구가 있느냐는 이진 문제라 별개입니다. 중요한 것은 그 도구의 이름, 독스트링에 쓰인 말, 오류 메시지의 모양입니다. 모델은 이 신호를 보고 언제 무엇을 부를지 정합니다.

4. 검색 전략. 언제 파일을 통째로 올리고, 언제 문자열을 grep하고, 언제 임베딩을 질의할지. 대부분의 프로젝트가 이 부분을 과하게 만듭니다. 잘 정리된 폴더에 대한 grep 하나가 웬만한 RAG 구성보다 낫습니다.

5. 기록 압축. 대화가 길어질 때 이전 턴을 어떻게 요약할지. 대부분의 에이전트 루프의 기본값은 순진한 잘라내기입니다. 더 나은 전략은 신호 밀도를 지켜 냅니다.

6. 시스템 프롬프트. 여전히 중요하지만, 사람들이 생각하는 것보다는 덜합니다. 좋은 시스템 프롬프트는 50줄 안에 정체성과 절대 규칙을 정합니다. 그보다 길다면 대개 작업 디렉터리가 해야 할 일을 대신하고 있는 것입니다.

이 목록에 없는 것을 눈여겨보세요. 사용자가 쓰는 프롬프트. 문구. “당신은 시니어 엔지니어입니다” 같은 서두. 이제 그런 것들은 흔한 부품입니다.

Markdown이 이긴 이유

컨텍스트 엔지니어링을 진지하게 하는 곳이라면 어디서나 나타나는 패턴이 하나 있습니다. 디스크 위의 Markdown입니다.

Claude Code는 Markdown을 읽습니다. Codex도 Markdown을 읽습니다. Cursor의 에이전트 모드도 Markdown을 읽습니다. Browser Harness도 Markdown을 읽습니다. Karpathy의 autoresearch 루프는 program.md를 읽습니다. 2026년에 나온 모든 하니스는 안에 무엇이 있는지 설명하는 Markdown 파일 폴더를 기대합니다.

우연이 아닙니다. Markdown이 컨텍스트의 바탕으로 알맞은 이유는 이렇습니다.

• 사람이 읽을 수 있어서, 모델에게 무엇을 먹이는지 직접 확인할 수 있습니다.
• 모델이 깔끔하게 파싱할 만큼은 구조가 있습니다(제목, 목록, 코드 블록).
• diff가 잘 되어서 Git으로 버전 관리할 수 있습니다.
• 평범한 텍스트라 모든 도구, 모든 플랫폼, 모든 셸에서 동작합니다.
• 컨텍스트 창 안에서 잘 압축됩니다. XML의 군살도, JSON의 격식도 없습니다.

진지하게 컨텍스트를 설계하고 있다면, 여러분은 Markdown 라이브러리를 관리하고 있는 셈입니다. 남은 질문은 그것이 여러분의 Markdown 라이브러리인가, 남의 것인가 하는 점뿐입니다.

Minibase가 놓이는 자리

2026년의 모든 컨텍스트 설계 시스템은 디스크에서 Markdown을 읽습니다. 기준으로 삼는 CLAUDE.md, grep한 문서들, 참고한 API 레퍼런스, 방금 정리해 둔 API 설명까지 — 전부 에이전트가 볼 수 있는 폴더에 놓여 있습니다.

Minibase는 어떤 웹페이지든 클릭 한 번으로 깔끔한 Markdown으로 바꿔 주는 도구입니다. 문서 페이지, GitHub README, Anthropic의 컨텍스트 엔지니어링 글, Karpathy의 스레드, Stack Overflow 답변까지 — 다음에 돌릴 에이전트가 읽어야 할, 조사 중에 마주치는 무엇이든요.

하니스는 오픈소스입니다. 모델은 흔한 부품입니다. 한 에이전트를 다른 에이전트보다 낫게 만드는 것은 컨텍스트 라이브러리입니다. 그리고 그 라이브러리는 결국 폴더에 놓인 Markdown, 필요할 때 RAM에 올릴 준비가 된 Markdown일 뿐입니다.

컨텍스트 엔지니어링은 그 분야의 이름이고, 잘 고른 Markdown 라이브러리는 그 결과물입니다.

---

Minibase는 어떤 웹페이지든 여러분의 AI 컨텍스트 엔진이 읽을 수 있는 Markdown으로 바꿔 줍니다. 확장 프로그램을 설치하고 에이전트를 더 똑똑하게 만들 라이브러리를 쌓아 보세요.