AI 핵심 개념 (3): 프롬프트 엔지니어링 / 컨텍스트 엔지니어링#

이번 장에서는 “어떻게 질문 / 지시를 구성할지"에 대한 프롬프트 엔지니어링, 그리고 “답을 만들 때 참고할 재료(배경 정보)를 어떻게 제공할지"에 대한 컨텍스트 엔지니어링을 다룹니다. 앞 장에서 본 컨텍스트 윈도우를 떠올리면, 프롬프트 엔지니어링은 그 안에 넣는 “지시문"을 잘 쓰는 일이고, 컨텍스트 엔지니어링은 그 안에 넣는 “모든 것"을 설계하는 일입니다.

프롬프트 엔지니어링(Prompt Engineering)#

프롬프트는 AI 모델에게 질의(질문 / 지시)하는 텍스트를 의미합니다. 예를 들어 ChatGPT를 사용할 때 사용자가 입력창에 쓰는 내용이 바로 프롬프트입니다. 프롬프트 엔지니어링은 AI 모델로부터 원하는 결과를 얻어내기 위해 프롬프트를 작성하는 기술입니다. 채팅창에 글을 입력하는 것일 뿐인데 이것을 “엔지니어링"이라고 부르는 이유는, 그만큼 어떻게 입력하는가에 따라 결과물의 품질이 달라지고, 기본 원칙 위에 경험과 노하우가 쌓여야 하는 기술이기 때문입니다.

OpenAI와 Anthropic은 각각 공식 프롬프트 가이드를 공개하고 있습니다(OpenAI, Anthropic). 세부 기법은 모델마다 조금씩 다르지만, 핵심 원칙은 공통적입니다. 여기서는 그 공통 원칙을 여섯 가지로 압축합니다.

원칙 1. 지침을 구체적으로 쓴다#

원하는 결과에 대한 맥락과 필요로 하는 정보를 구체적으로 적습니다. “Excel에서 숫자를 어떻게 합산하나요?“보다는 “Excel에서 달러 금액 행을 합산하고 싶습니다. ‘Total’ 열 왼쪽의 모든 값을 자동으로 더해 ‘Total’ 열에 넣고 싶습니다.“가 낫습니다. 결과의 양도 명시합니다. “한 문장으로”, “제목 3개를”, “500자 내외로"처럼 말입니다.

원칙 2. 역할(페르소나)을 준다#

“당신은 Python 프로그래머입니다. 코드가 주어지면 주석을 추가하고 설명해 주세요.“처럼 모델의 역할을 미리 설정하면, 답변의 관점과 어휘 수준이 그 역할에 맞춰집니다.

원칙 3. 입력을 구분자로 나눈다#

지시문과 처리 대상 텍스트가 섞이면 모델이 헷갈립니다. 삼중 따옴표나 XML 태그로 경계를 분명히 합니다.

동일한 주제에 대한 한 쌍의 기사(XML 태그로 구분됨)가 제공됩니다.
먼저 각 기사의 주장을 요약하고, 어느 쪽 주장이 더 나은지 이유와 함께 설명해 주세요.

<article>첫 번째 기사 내용</article>
<article>두 번째 기사 내용</article>

원칙 4. 단계를 나누고 예시를 보여 준다#

복잡한 작업은 “Step 1 요약, Step 2 번역"처럼 단계로 나눠 지시하고, 말로 설명하기 어려운 형식이나 스타일은 예시를 하나 보여 주고 “이와 같은 방식으로"라고 지시합니다. 고객 문의를 분류한 뒤 분류별로 다른 지침을 적용하는 식으로, 하나의 큰 프롬프트를 여러 개의 작은 프롬프트로 쪼개는 것도 같은 원칙입니다.

원칙 5. 참고 자료를 주고, 없으면 모른다고 하게 한다#

근거가 필요한 질문에는 참고 자료를 함께 넣고, “자료에서 답을 찾을 수 없으면 ‘정보가 부족합니다’라고 답하라"는 규칙을 붙입니다. 이 한 줄이 할루시네이션(그럴듯하게 지어내는 답변)을 줄이는 데 가장 효과적인 장치 중 하나입니다.

삼중 따옴표로 구분된 문서만 사용하여 질문에 답하고, 답에 사용한 구절을 인용하세요.
문서에 필요한 정보가 없으면 "정보가 부족합니다"라고 적으세요.
"""
문서 내용
"""
질문: 질문 내용

원칙 6. 먼저 생각하게 한다#

모델이 “맞다 / 틀리다"를 판정해야 하는 경우, 바로 정답 여부를 묻기보다 먼저 스스로 풀어 보게 한 뒤 비교하게 하면 신뢰도가 올라갑니다. “학생의 풀이가 맞는지 알려 주세요"보다 “먼저 문제를 직접 풀어 보세요. 그런 다음 학생의 풀이와 비교해 평가하세요. 직접 풀기 전에는 판단하지 마세요.“가 낫습니다. 최근 모델들은 내부적으로 “생각하는 단계"를 가진 추론 모드를 제공하기도 하는데, 그 경우에도 “무엇을 검토하라"는 지시는 여전히 유효합니다.

프롬프트는 코드처럼 관리해야 합니다#

채팅 서비스를 쓸 때는 위 원칙만으로 충분합니다. 하지만 API로 서비스를 만들어 운영하는 개발자라면 한 가지를 더 알아야 합니다. 모델이 업데이트되면 같은 프롬프트의 결과가 달라질 수 있다는 점입니다. 어제까지 항상 비슷한 형식으로 답하던 모델이, 업데이트 이후에는 답변 스타일이나 출력 형식이 미묘하게 달라질 수 있습니다. 서비스 입장에서는 갑자기 동작이 바뀐 것처럼 느껴집니다.

그래서 프로덕션에서는 보통 특정 모델 스냅샷(버전) 을 고정해 예측 가능성을 높이고, 프롬프트를 소스 코드처럼 버전 관리하며, 프롬프트를 수정하거나 모델을 교체할 때는 평가(evals), 즉 미리 준비해 둔 “시험 문제 세트"로 핵심 케이스들이 잘 동작하는지 확인합니다. 평가의 구체적인 방법은 실행 편의 “운영” 장에서 다룹니다.

컨텍스트 엔지니어링(Context Engineering)#

프롬프트 엔지니어링이 “무엇을 시킬지(지침 / 형식)“를 설계하는 일이라면, 컨텍스트 엔지니어링은 “모델이 답을 만들 때 참고할 재료(배경 정보) 를 어떤 방식으로 넣어 줄지"를 설계하는 일입니다. 같은 프롬프트라도 어떤 컨텍스트를 함께 제공하느냐에 따라 답변의 정확도와 일관성이 크게 달라집니다.

컨텍스트 엔지니어링의 제1원칙은 단순합니다. 모델의 관점에서, 컨텍스트에 없는 것은 존재하지 않는 것입니다. 내 머릿속에 있는 프로젝트 규칙, 동료와 나눈 대화, 다른 문서에 적힌 결정 사항은 모델에게 보이지 않습니다. 모델이 엉뚱한 답을 할 때 “왜 이걸 모르지?“라고 묻기 전에, “내가 이걸 컨텍스트에 넣었나?“를 먼저 확인해야 합니다.

잘 되는 컨텍스트 구성의 원칙#

• 우선순위를 정해 넣기: 중요한 것부터, 그리고 “무엇이 정답 근거인지"가 드러나게 넣습니다.
• 길이를 관리하기: 너무 길면 핵심을 놓치고, 컨텍스트 윈도우 한계를 빨리 소진하며, 비용이 늘어납니다. 긴 대화는 요약하고, 문서는 필요한 부분만 고릅니다.
• 섹션을 나눠 구분하기: Markdown 헤더나 XML 태그처럼 경계가 명확한 형식이 도움이 됩니다.
• 최신성 / 정합성 확인하기: 오래된 정책 문서가 섞이면 오히려 품질이 떨어집니다.
• 근거 기반으로 답하게 만들기: “아래 문서만 근거로 답하고, 없으면 모른다고 말하기” 같은 규칙을 함께 줍니다.
• 반복되는 부분은 앞에, 바뀌는 부분은 뒤에: 고정 지침과 참고 자료를 앞에 두면 프롬프트 캐싱의 효과를 받습니다.

RAG와 Function Calling도 컨텍스트 엔지니어링의 한 형태#

앞 장의 RAG는 “필요한 문서를 자동으로 찾아 컨텍스트에 붙여 주는 방식"이고, Function Calling으로 DB 조회 / 계산 / API 호출을 수행한 뒤 그 결과를 컨텍스트로 제공하는 것도 컨텍스트 엔지니어링의 중요한 부분입니다. 즉, 컨텍스트 엔지니어링은 사람이 직접 문서를 붙여 넣는 일부터, 검색과 도구 실행으로 컨텍스트를 자동 구성하는 일까지 포함하는 넓은 개념입니다.

필자가 실제로 하는 방식: 규칙 파일, 메모리, 스킬#

채팅창에 매번 긴 지침을 붙여 넣는 방식은 오래 가지 못합니다. 필자는 회사 프로젝트와 이 블로그를 포함한 개인 프로젝트에서, 컨텍스트를 저장소 안의 파일로 관리합니다. 코딩 에이전트(Cursor, Claude Code 등)는 프로젝트를 열 때 특정 파일을 자동으로 읽어 컨텍스트에 넣기 때문에, 그 파일에 지침과 재료를 써 두면 매 세션 같은 컨텍스트에서 출발합니다.

<프로젝트 루트>/
├── CLAUDE.md              # 에이전트 지침의 진입점 (목차 역할, 100줄 이내)
├── ARCHITECTURE.md        # 프로젝트 구조 지도
├── .cursor/rules/         # Cursor용 규칙 (문체, 프론트매터, 금지 사항 …)
├── .claude/skills/        # 반복 작업 절차서 (예: "뉴스 브리프 작성", "에세이 발행")
├── .memory/
│   ├── learnings.md       # 작업 중 발견한 패턴, 실패 원인, 노하우
│   └── current-focus.md   # 현재 관심사와 우선순위
└── docs/decisions/        # 설계 결정 기록

이 구조를 앞의 다섯 층에 대응시키면 이렇습니다.

이렇게 해 두면 “지침을 잘 쓰는 것"이 개인의 기억이 아니라 프로젝트의 자산이 됩니다. 새 세션을 열어도 에이전트가 프로젝트의 문체, 구조, 배포 방식을 즉시 이해하고, 지난 세션에서 발견한 실수를 반복하지 않습니다. 이 구조가 다음 장에서 다룰 하네스의 출발점입니다.

정리#

• 프롬프트 엔지니어링의 핵심은 구체적인 지침, 역할, 구분자, 단계와 예시, 참고 자료, 먼저 생각하게 하기의 여섯 가지입니다.
• 서비스를 운영한다면 프롬프트를 코드처럼 버전 관리하고, 모델 스냅샷을 고정하고, 평가로 검증합니다.
• 컨텍스트 엔지니어링은 “모델이 보는 모든 것"을 설계하는 일이며, 컨텍스트에 없는 것은 모델에게 존재하지 않습니다.
• 컨텍스트는 고정 지침, 참고 자료, 상태, 도구 결과, 현재 요청의 다섯 층으로 나눠 설계합니다.
• 지침과 재료를 저장소 안의 파일로 관리하면, 컨텍스트가 개인의 기억이 아니라 프로젝트의 자산이 됩니다.