프롬프트 엔지니어링과 컨텍스트 엔지니어링, 뭐가 다른가 (2/6)

요약 — 프롬프트 엔지니어링은 AI에게 “어떻게 말을 걸 것인가”에 대한 노하우이고, 컨텍스트 엔지니어링은 AI에게 “어떤 정보를 어떤 구조로 미리 채워둘 것인가”에 대한 노하우다. 전자는 한 번의 지시 문장에 집중하고, 후자는 지시 이전에 이미 갖춰져 있어야 할 정보 환경에 집중한다.

이전 글에서 AI 에이전트의 기본 개념을 다뤘습니다. 이번 글은 그 다음 단계 — AI를 “잘 쓴다”는 게 정확히 무엇을 잘하는 것인지를 다룹니다.

두 용어가 헷갈리는 이유

AI를 잘 쓰는 방법을 검색하면 “프롬프트 엔지니어링”과 “컨텍스트 엔지니어링”이라는 말이 뒤섞여 나옵니다. 둘 다 “AI에게 뭔가를 잘 전달하는 방법”처럼 들려서 같은 말처럼 느껴지기 쉽습니다. 하지만 이 둘은 AI가 발전해온 시기도 다르고, 초점을 맞추는 대상도 다릅니다.

프롬프트 엔지니어링 — “어떻게 말을 걸 것인가”

초기 LLM(대형 언어모델)은 구조가 단순했습니다. 사용자가 입력하면, 모델이 그 입력만 보고 바로 답을 생성했습니다. 이 시기의 고민은 하나였습니다. “어떤 문장으로 지시해야 AI가 더 잘 알아듣는가.”

• “너는 20년 차 카피라이터야”처럼 역할을 부여하면 답변의 톤이 달라진다
• 예시를 몇 개 보여주면(few-shot) 원하는 형식에 더 가까운 답이 나온다
• “단계별로 생각해봐”라고 덧붙이면 추론 정확도가 올라간다

이런 식으로 한 번의 지시 문장을 어떻게 구성해야 좋은 결과가 나오는지에 대한 노하우들이 쌓이면서 프롬프트 엔지니어링이라는 이름이 붙었습니다.

컨텍스트 엔지니어링 — “무엇을 미리 채워둘 것인가”

AI 에이전트가 코드를 작성하고, 여러 파일을 다루고, 오랜 시간 작업을 이어가게 되면서 문제가 달라졌습니다. 이제는 한 번의 잘 쓴 문장보다, 에이전트가 작업 내내 참고할 정보가 애초에 잘 갖춰져 있는지가 결과물의 품질을 더 크게 좌우하게 됐습니다.

이게 컨텍스트 엔지니어링입니다. 앞선 글에서 다룬 Context Window(에이전트가 정보를 담아두는 공간)를 의도적으로, 체계적으로 채워 넣는 작업이라고 보면 됩니다.

가장 대표적인 도구가 AGENTS.md(도구에 따라 CLAUDE.md 등으로도 불림) 파일입니다. 프로젝트 루트 폴더에 이 파일을 두면, 에이전트는 작업할 때마다 이 내용을 자동으로 참고합니다.

AGENTS.md에 보통 담기는 내용

• 프로젝트가 무엇을 하는 프로젝트인지에 대한 설명
• 지켜야 할 규칙 (예: “허락 없이 새 파일을 만들지 마라”, “결과 확인 전에는 배포하지 마라”)
• 프로젝트 구조에 대한 안내 (어떤 폴더에 무엇이 있는지)

이 파일 하나를 잘 써두면, 매번 프롬프트에 같은 설명을 반복할 필요가 없어집니다. 프로젝트의 “헌법”을 미리 정해두고, 에이전트가 항상 그 헌법을 참고하며 일하게 만드는 방식입니다.

실무 예시로 비교해보기

같은 작업을 프롬프트 엔지니어링 관점과 컨텍스트 엔지니어링 관점에서 어떻게 접근하는지 비교하면 차이가 분명해집니다.

상황: 사내 보고서 초안을 AI에게 계속 맡기고 싶다.

프롬프트 엔지니어링만으로는 매번 같은 내용을 반복 입력해야 하고, 사람마다 표현이 조금씩 달라져 결과도 들쭉날쭉해집니다. 컨텍스트 엔지니어링을 함께 쓰면, 지시는 짧아지고 결과는 더 일관됩니다.

어느 하나만 잘해서는 안 되는 이유

둘은 경쟁 관계가 아니라 층이 다른 기술입니다.

• 컨텍스트가 아무리 잘 갖춰져 있어도, 그날 필요한 구체적인 지시(프롬프트)가 엉성하면 원하는 결과가 안 나옵니다.
• 반대로 프롬프트를 아무리 정교하게 써도, 에이전트가 프로젝트의 배경·규칙을 전혀 모른 채 시작하면 매번 처음부터 설명해야 하고, 일관성도 떨어집니다.

실무에서는 반복되는 배경 정보는 컨텍스트(AGENTS.md 등)로 미리 갖춰두고, 그날그날 다른 구체적 지시만 프롬프트로 전달하는 방식이 가장 효율적입니다.

정리

다음 글에서는 이 둘만으로는 부족한 지점 — AI를 오랜 시간 안정적으로 돌리기 위한 하네스 엔지니어링을 다룹니다.