컨텍스트 엔지니어링이 뭔데? 프롬프트 엔지니어링과 뭐가 다를까

AI 개발을 좀 하다 보면 “프롬프트 엔지니어링은 이제 끝났다”라는 말을 여기저기서 듣게 됩니다. 대신 떠오르는 게 컨텍스트 엔지니어링(Context Engineering)이에요. 한 줄로 요약하면 “AI에게 질문을 잘 하는 것”보다 “AI에게 어떤 정보를 주느냐”가 결과를 좌우한다는 뜻인데, 저는 이 개념을 책이나 아티클로 익혔다기보다 블로그 파이프라인·자동매매 봇·주식 분석 웹앱 3개 프로젝트를 굴리다가 몸으로 깨달았어요. 이 글은 그 경험을 정리한 기록입니다.

왜 프롬프트만으로는 부족할까?

처음 AI 도구를 쓸 때는 “질문을 잘 하면 좋은 답이 나온다”가 거의 진리처럼 느껴졌어요. 실제로 단발성 질문에는 이 원칙이 잘 통합니다. 그런데 제가 블로그 자동화 파이프라인을 만들기 시작하면서 이상한 벽에 부딪혔어요. 같은 질문을 해도 결과물의 톤·구조·품질이 일관되지 않는 문제였습니다. 프롬프트를 아무리 정교하게 고쳐도, 어제는 괜찮았던 글이 오늘은 엉망이 되는 식이었어요.

원인을 돌아보니 단순했어요. AI는 매번 “제로 상태”에서 제 질문을 받고 있었던 거예요. 어제 제가 선호했던 톤도 기억 안 하고, 지난주에 제가 정한 카테고리 규칙도 모르고, 이 프로젝트가 어떤 독자를 겨냥하는지도 모른 채로요. 제가 프롬프트를 아무리 잘 써도, AI가 매번 “이 프로젝트는 처음 봅니다” 상태라면 결과가 튀는 건 당연했습니다. 이 지점에서 “질문을 잘 하는 것”이 아니라 “질문 이전에 뭘 알려둘 것인가”가 진짜 과제라는 걸 깨달았어요.

프롬프트 엔지니어링 vs 컨텍스트 엔지니어링, 한 표로 정리

비유하자면 이렇게 구분할 수 있어요. 프롬프트 엔지니어링은 “신입에게 업무 지시를 잘 하는 법”이고, 맥락 설계는 “신입이 일할 수 있도록 매뉴얼·자료·권한을 미리 갖춰주는 법”이에요. 아무리 지시를 잘 해도 배경 자료가 없으면 엉뚱한 결과가 나오죠. 두 개념은 대체 관계가 아니라 보완 관계입니다.

본인 프로젝트 3곳에 적용해본 경험

① 블로그 자동화 파이프라인 — 글 품질이 갑자기 일정해진 순간

제가 이 접근법의 효과를 가장 먼저 실감한 건 블로그 파이프라인이었어요. 처음엔 프롬프트만 열심히 고쳤는데 품질이 들쑥날쑥했죠. 그러다 CLAUDE.md와 글 작성 Skill 문서에 “이 블로그의 톤은 이렇다, 제목은 몇 자 이하, 이미지는 이 HTML 구조, 본인 경험 섹션은 반드시 포함”처럼 규칙과 배경을 전부 적어두었어요. 그 후로는 AI가 매번 이 문서를 먼저 읽고 작업을 시작합니다. 같은 “글 써줘”라는 요청이라도 결과물의 일관성이 완전히 달라졌어요. 프롬프트를 고친 게 아니라 “AI가 보는 세계”를 고친 결과였습니다.

② 자동매매 봇 — 아키텍처 규칙을 CLAUDE.md에 적어둔 효과

자동매매 봇 프로젝트의 CLAUDE.md에는 “데이터 흐름은 이렇다, 전략은 이런 구조로, 주요 버그 패턴은 이런 것들”처럼 프로젝트의 규칙과 과거 히스토리를 적어두었어요. 덕분에 새로운 기능을 붙일 때 “이거 어떻게 만들어줘”가 아니라 “우리 프로젝트 규칙에 맞게 이걸 추가해줘”만 말해도 AI가 결과물을 예측 가능한 방향으로 내놓습니다. 프롬프트가 짧아지고, 결과는 일관된 상태가 됐어요. 이 프로젝트에서 겪은 버그 수정 과정은 첫 실전 거래 결과 글에서도 볼 수 있어요.

③ 주식 자동 분석 웹앱 — 4주 만에 완성 가능했던 진짜 이유

이 웹앱을 바이브코딩으로 4주 만에 만든 이야기를 썼었는데, 돌이켜 보니 4주를 가능케 한 숨은 축이 이 맥락 설계 방식이었어요. “어떤 지표를 어떻게 조합해서 어떤 시그널을 만들지”가 이미 제 머릿속에 있었고, 그걸 AI에게 정리된 맥락으로 전달할 수 있는 상태였거든요. AI는 빠르게 구현을 해주지만 “무엇을 만들지”는 사람이 결정합니다. 그 결정을 얼마나 잘 문서화해서 AI에게 건네느냐가 결국 속도를 결정해요.

3개 프로젝트에서 공통으로 얻은 원칙 3가지

① “매번 설명하는 것”은 컨텍스트로 격상시킨다. 같은 설명을 세 번 이상 반복하고 있다면, 그건 프롬프트가 아니라 CLAUDE.md·Skill 파일 같은 컨텍스트 문서로 옮길 때예요. 이 이동 한 번으로 앞으로의 모든 작업이 자동으로 그 규칙을 따르게 됩니다. “지금 당장 한 번 말하는 비용”과 “앞으로 매번 말하지 않아도 되는 이익”의 차이는 큽니다.

② 컨텍스트는 “규칙” + “배경” + “예시”의 세 축으로 쓴다. 규칙만 적어두면 딱딱하고, 배경만 적어두면 모호하고, 예시만 적어두면 패턴이 고정돼요. 저는 Skill 문서를 쓸 때 “이 작업의 목적은 뭔가(배경) → 지켜야 할 규칙(규칙) → 좋은 예시와 나쁜 예시(예시)”의 3단 구조를 기본으로 갑니다. 이 3축이 갖춰지면 AI가 훨씬 안정적으로 작업해요.

③ 한 번 만든 컨텍스트는 “살아있는 문서”로 유지한다. 컨텍스트 문서는 한 번 쓰고 끝이 아니에요. 프로젝트가 바뀌면 컨텍스트도 같이 바뀌어야 합니다. 저는 월 1회 정도 CLAUDE.md·Skill 문서를 훑으면서 “지금도 맞는지” 체크해요. 오래된 컨텍스트는 오히려 AI에게 잘못된 방향을 줄 수 있어서, 업데이트가 오히려 핵심 작업이 됩니다.

자주 묻는 질문

Q. 프롬프트 엔지니어링은 이제 필요 없는 건가요?

A. 아닙니다. 이 접근법은 프롬프트 엔지니어링의 대체가 아니라 확장이에요. 잘 짜인 컨텍스트 위에서 좋은 프롬프트를 쓰면 결과가 한 단계 더 올라갑니다(Anthropic 프롬프트 엔지니어링 가이드 참고). 둘은 같이 써야 하는 도구예요. 다만 단일 질문만 계속 고민하면 한계에 부딪히니, “질문 이전의 환경”에 더 많은 시간을 쓰는 방향으로 무게 중심을 옮기라는 이야기예요.

Q. CLAUDE.md는 어디서부터 쓰기 시작하면 되나요?

A. 완벽한 문서를 만들려 하지 말고 “지금 내가 AI에게 매번 반복하는 3가지”부터 적어두세요. 저도 처음엔 3줄짜리 CLAUDE.md로 시작했고, 프로젝트가 커지면서 한 줄씩 추가해 나갔어요. 처음부터 모든 규칙을 쓰려고 하면 관리가 부담스러워져서 오히려 안 쓰게 됩니다.

Q. RAG·MCP도 컨텍스트 엔지니어링인가요?

A. 네, 같은 축에 있는 도구예요. RAG는 외부 지식을 AI에게 붙여주는 방식이고, MCP는 외부 도구·서비스를 AI와 연결하는 표준이에요. 둘 다 “질문을 잘 하는 것”이 아니라 “AI가 볼 수 있는 맥락·자원을 늘리는 것”이라는 같은 원리를 공유합니다. 이 연장선에 있는 Claude Code의 기능 구분은 Claude Code 기능 총정리 글에서 자세히 다뤘어요.

Q. 어떤 프로젝트부터 컨텍스트 엔지니어링을 적용하는 게 좋을까요?

A. “AI에게 반복적으로 같은 설명을 하고 있는 프로젝트”부터 시작하는 게 가장 효과가 빨리 납니다. 반복이 많다는 건 이미 컨텍스트로 격상시킬 거리가 쌓여 있다는 뜻이거든요. 저는 블로그 파이프라인이 첫 대상이었는데, “매번 톤·규칙·이미지 스펙을 설명한다”는 반복이 눈에 띄어서 CLAUDE.md를 쓰기 시작했어요.