프롬프트 잘 쓰는 법 2026 — 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

“프롬프트를 잘 쓴다”는 말의 의미가 바뀌었다

한동안 “프롬프트 잘 쓰는 법” 류의 글은 대부분 마법의 주문 모음집이었다. “당신은 20년 차 시니어 개발자다”로 시작하라, “단계별로 생각해 보라”를 붙여라, 끝에 “틀리면 100달러를 잃는다”를 협박처럼 달아라. 이런 팁이 틀린 건 아니다. 다만 2026년 현재, 이것만으로는 절반도 못 간다.

내가 매일 Claude Code로 코드를 짜면서 체감한 건 명확하다. 결과 품질을 가르는 건 문장을 얼마나 그럴싸하게 쓰느냐가 아니라, 모델에게 무엇을 보여주느냐다. 실전 에이전트는 모델 자체의 한계보다 컨텍스트 층위 — 프롬프트 문장을 어떻게 쓰느냐보다 무엇을 컨텍스트에 채우느냐 — 에서 훨씬 더 자주 실패한다.

이 글은 세 부분으로 나뉜다. ① 여전히 유효한 프롬프트 기본기, ② 2026년의 진짜 게임체인저인 컨텍스트 엔지니어링, ③ 내가 매일 쓰는 실전 도구다.

1부. 아직도 유효한 프롬프트 기본기

기본기는 죽지 않았다. 다만 이제는 “잘하면 유리한 기술”이 아니라 “안 하면 손해 보는 기본값(table stakes)”이 됐다. 구글이 공개한 프롬프트 엔지니어링 백서와 여러 가이드가 공통으로 짚는 핵심만 추린다.

1) 모호함을 없애라 — 가장 흔한 실패 원인

프롬프트가 어긋나는 가장 흔한 원인은 모델의 무능이 아니라 지시의 모호함이다. 멋진 단어보다 명확한 구조가 거의 항상 이긴다. “코드 좀 깔끔하게 정리해줘”가 아니라 “이 함수에서 중복된 분기 3개를 early return으로 합치고, 함수 길이를 40줄 이하로 줄여라”라고 써야 한다.

2) 역할은 현실적이고 과제에 맞게

역할 부여(role prompting)는 효과가 있다. 단, “당신은 세계 최고의 천재”가 아니라 과제에 직접 관련된 현실적인 역할이어야 한다. 그리고 역할은 프롬프트 맨 앞에서 한 줄로 짧게 선언하고, 곧바로 구체적 지시를 붙인다. 역할은 행동의 톤을 잡는 장치지, 그 자체로 정답률을 올리는 마법이 아니다.

3) few-shot — 형식이 중요하면 예시를 넣어라

프롬프트 엔지니어링 문헌이 공통으로 권하는 건 예시(few-shot)다. 출력의 형식·스타일·구조가 중요한 작업이라면, 원하는 모양을 보여주는 예시 3~5개가 zero-shot(예시 없음)보다 결과를 안정적으로 만든다. 코드라면 입력/기대 출력 쌍을, 분류 작업이라면 라벨링된 예시 몇 개를 함께 넣는다. 단, 예시는 공짜가 아니다 — 토큰을 먹고, 잘못 고르면 편향을 부른다(이 긴장은 2부에서 다시 다룬다).

4) 출력 형식을 강제하라

“유효한 JSON만 반환하라”, “마크다운 표로 답하라” 같은 시스템 수준 지시는 일관성과 후처리 자동화에 직결된다. 결과를 코드로 파싱할 거라면 형식을 반드시 못 박아야 한다.

5) 데이터는 앞에, 질문은 맨 뒤에

긴 데이터·문맥을 먼저 깔고, 구체적인 질문은 맨 마지막에 둔다. 이건 단순한 미신이 아니라 모델이 컨텍스트를 읽는 방식과 관련이 있다(뒤에서 다룰 “Lost in the Middle”과도 이어진다).

6) 복잡한 추론엔 Chain-of-Thought

복잡한 문제는 “단계별로 생각하라(Let’s think step by step)”는 한 줄만 붙여도 중간 추론을 펼쳐서 정답률이 올라간다. 다만 최신 모델은 이런 추론을 상당 부분 내부에서 알아서 하므로, CoT의 효용은 예전만큼 극적이지 않다. 그래도 “왜 그렇게 판단했는지” 근거를 받아 검증하려면 여전히 유용하다.

여기까지가 1부다. 이걸 다 지켜도 복잡한 작업에서 AI가 끝의 한 끗을 못 넘기고 멈춘다면, 문제는 프롬프트 문장이 아니라 그 바깥에 있다.

2부. 진짜 변화 — 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

2025년 6월 Andrej Karpathy가 “컨텍스트 엔지니어링(context engineering)”이라는 말을 띄웠고(“다음 스텝에 딱 맞는 정보로 컨텍스트 윈도우를 채우는 섬세한 기술과 과학”), 그해 9월 말 Anthropic이 context editing API와 memory tool을 내놓으며 이를 정식 엔지니어링 주제로 문서화했다. 용어가 유행을 탔다는 게 핵심이 아니다. 일을 잘하는 사람들의 관심사가 “문장”에서 “정보 환경”으로 옮겨 갔다는 신호라는 게 핵심이다.

둘의 차이는 이렇게 정리된다.

	프롬프트 엔지니어링	컨텍스트 엔지니어링
질문	지시를 어떻게 쓸까	매 순간 윈도우에 무엇을 채울까
다루는 범위	한 번의 지시문	시스템 프롬프트·대화 이력·도구 정의·검색 문서·메모리 전체
잘 맞는 상황	일회성 단발 작업	멀티턴·장기 에이전트·복잡한 작업
비유	좋은 질문하기	OS가 되어 메모리를 관리하기

가장 좋은 비유는 RAM이다. 컨텍스트 윈도우는 모델의 작업 기억(working memory), 즉 책상 위 공간이다. 모델이 학습으로 외운 지식은 머릿속(가중치)에 있지만, 지금 이 작업에 펼쳐 놓고 동시에 볼 수 있는 서류는 책상 크기만큼만 올라간다. 컨텍스트 엔지니어링은 이 책상 위에 매 순간 정확히 필요한 서류만 올리고, 다 쓴 건 치우는 운영체제 역할을 하는 일이다.

더 많이 넣는다고 좋아지지 않는다 — context rot

여기서 가장 반직관적인 사실. 컨텍스트는 많이 넣을수록 좋은 게 아니다. Anthropic 공식 문서가 직접 못 박는 표현이 있다.

“more context isn’t automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot.” (컨텍스트가 많다고 자동으로 좋아지지 않는다. 토큰이 늘수록 정확도와 회상이 떨어지는데, 이를 context rot이라 부른다.)

즉 ‘context rot’은 블로거가 지어낸 유행어가 아니라 Anthropic이 자기 문서에서 쓰는 용어다. 같은 문단은 이렇게 이어진다 — “이것이 컨텍스트에 무엇을 담을지(curating)를, 공간이 얼마나 남았는지만큼 중요하게 만든다.”

여기에 더해 두 가지 고전적 함정이 있다.

Lost in the Middle: 모델은 컨텍스트의 처음과 끝은 잘 쓰지만 가운데에 묻힌 정보는 잘 놓친다(U자형 성능). 긴 컨텍스트 전용 모델에서도 관찰된다. 그래서 핵심 지시를 한가운데 파묻으면 안 된다.
광고된 상한 ≠ 쓸 수 있는 길이: 여러 벤치마크는 모델이 광고된 최대 윈도우보다 한참 전부터 흔들린다고 보고한다. retrieval 정확도는 수만 토큰 구간부터 떨어지기 시작하고, distraction(엉뚱한 토큰에 휘둘림)은 그보다 더 일찍 나타나기도 한다. 정확한 임계점은 모델·과제마다 다르지만 방향은 한결같다 — 윈도우가 크다고 그걸 다 채우면 손해다.

결론: 1M 토큰 윈도우가 있어도 거기에 코드베이스를 통째로 부어 넣는 건 하수다. 무엇을 넣을지(curation)가 얼마나 넣느냐만큼 중요하다.

이쯤에서 1부의 “few-shot 예시를 넣어라”와 모순처럼 보일 수 있다. 화해는 간단하다 — 예시도 큐레이션 대상이다. 과제의 형식을 정확히 보여주는 예시는 토큰값을 한다. 하지만 관련 없거나 중복된 예시를 5개씩 욱여넣으면 그게 바로 noise이고 context rot의 연료다. “넣어라”의 진짜 의미는 “많이”가 아니라 “맞는 걸”이다.

컨텍스트 관리 4대 전략: Write / Select / Compress / Isolate

업계에서 수렴한 컨텍스트 관리 패턴은 네 가지로 요약된다.

Write (외부에 적어둔다): 모든 걸 윈도우에 이고 다니지 말고 파일·DB·벡터스토어에 저장해 둔다. 나는 진행 상황을 마크다운에 적어두고 세션이 바뀌면 다시 읽힌다(memory tool이 이걸 돕는다).
Select (필요한 것만 꺼낸다): RAG처럼 지금 이 작업에 관련된 것만 검색해서 주입한다. 코드베이스 전체가 아니라 “이 기능이 건드리는 3개 파일”만.
Compress (압축한다): 오래된 대화·도구 결과를 요약(compaction)해서 자리를 비운다. 긴 작업에서 초반 탐색 로그는 결론만 남기면 된다.
Isolate (격리한다): 작업별로 컨텍스트를 분리한다. 서브에이전트가 자기 윈도우를 갖고 결과 요약만 부모에게 돌려주면, 부모 윈도우가 노이즈로 오염되지 않는다.

나는 멀티에이전트 하네스를 짤 때 이 Isolate 원칙을 가장 많이 쓴다. 리서치·검수·구현을 각각 다른 서브에이전트에 맡기고, 메인 컨텍스트에는 결론만 흘려보낸다. 컨텍스트 압축 자체를 다룬 글은 headroom 리뷰에 따로 정리해 뒀다.

3부. 실전 도구 — 내가 실제로 쓰는 프롬프트 패턴

이론은 이쯤 하고, 매일 쓰는 구체적 도구 세 가지를 공유한다.

도구 1: PRP — “신입에게 일을 넘기듯” 프롬프트를 짠다

PRP(Product Requirement Prompt)는 한 줄로 이렇다.

PRP = PRD + 큐레이션된 코드베이스 지식 + 에이전트 런북

발상은 단순하다. 유능하지만 이 코드베이스를 처음 보는 신입에게 일을 맡긴다고 상상하라. “무엇을·왜”만 던지면(=평범한 PRD/요청) 신입은 “어느 파일에, 어떤 패턴으로, 어떤 버전으로 짜라”가 비어서 80% 지점에서 막힌다. PRP는 거기에 정확한 파일 경로, 따라야 할 기존 코드 예시, 라이브러리 버전, 그리고 스스로 통과 여부를 확인할 검증 명령까지 담는다.

완성도의 리트머스 시험은 한 문장이다.

“이 코드베이스를 전혀 모르는 사람이 이 문서만 받아도 성공적으로 구현할 수 있는가?”

원저자 Rasmus Widing의 진단이 정곡을 찌른다. “무엇을 만들지는 과하게 적으면서 컨텍스트와 어떻게 만들지는 부족하게 적는 것 — 이것이 수많은 AI 코딩이 80%에서 멈추는 이유다.” PRP는 세 개의 레이어로 이 구멍을 메운다.

레이어	내용
① Context	파일 경로·코드 스니펫·라이브러리 버전·외부 문서
② Implementation	어떻게 만들지 — 작업 순서, 따를 패턴, 의사코드
③ Validation Gates	`ruff`/`pytest`/빌드 같은 결정론적 검증 명령

“긴 프롬프트를 쓰자”가 아니다. 문서·예시·규칙·검증을 갖춘 시스템을 설계하자는 것이다. 이게 컨텍스트 엔지니어링의 산출물이다.

말로만 하면 와닿지 않으니 같은 과제를 맨몸 요청과 PRP화로 비교한다. 이 글에서 끝까지 끌고 갈 예시는 “JWT 인증 미들웨어 추가”다.

# ❌ 맨몸 요청 — what만 있고 context·how·검증이 없다
"JWT 인증 미들웨어 좀 추가해줘."
# → 어느 파일에? 기존 패턴은? 라이브러리는? 실패 코드는?
#   비어 있는 걸 모델이 추측으로 메우다 끝에서 막힌다.

# ✅ PRP화 — 처음 보는 사람도 끝낼 수 있게
## 목표
- src/middleware/ 에 JWT 인증 미들웨어 추가
- 완료 정의: 보호된 라우트가 유효 토큰만 통과시킨다

## 컨텍스트 (Context)
- 기존 패턴: src/middleware/rate_limit.py 의 미들웨어 구조를 그대로 따른다
- 검증: PyJWT 2.8 / HS256 / 시크릿은 settings.JWT_SECRET
- gotcha: FastAPI 미들웨어 함수는 async def 여야 한다

## 구현 (How)
1. verify_token(token) -> payload | None
2. Authorization 헤더 파싱 → 검증 → request.state.user 주입
3. 검증 실패 401, 만료 403

## 검증 (Validation — 전부 green이어야 완료)
- ruff check . 통과
- pytest tests/test_auth.py 전부 통과
- 기동 후 curl -H "Authorization: Bearer <만료토큰>" /me → 403

차이는 문장 솜씨가 아니다. 아래쪽이 더 정중하거나 더 똑똑한 영어를 쓰는 게 아니라, 모델이 추측해야 할 빈칸을 미리 메웠을 뿐이다. 그게 컨텍스트 엔지니어링이다.

도구 2: 프롬프트 체이닝 — 거대한 한 방을 쪼갠다

복잡한 작업을 프롬프트 하나로 끝내려 하면 모델이 실수한다. 대신 공장 조립 라인처럼 쪼갠다. 작업을 순차 단계로 분해하고, 앞 단계의 출력을 다음 단계의 입력으로 흘려보낸다. 핵심은 단계 사이에 게이트(gate) 를 두는 것이다.

draft  = LLM(generate, task)            # 1단계: 초안 생성
review = LLM(critique, draft, criteria) # 2단계: 기준 대비 검토
final  = LLM(refine, draft, review)     # 3단계: 검토 반영 수정

이 “초안 → 검토 → 수정”(self-correction) 패턴은 Anthropic이 가장 흔한 체이닝 패턴으로 꼽는다. 각 단계가 별개 호출이라 어느 지점에서든 로깅·평가·분기가 가능하다. 트레이드오프는 명확하다 — 호출 수가 늘어 지연(latency)은 증가하지만 정확도를 산다.

주의할 점 둘. ① 게이트는 LLM이 아니라 코드로 둬야 신뢰된다(결정론적 검사). ② 단계 간 출력은 <quotes>, <result> 같은 XML 태그로 감싸서 다음 단계가 안정적으로 파싱하게 한다.

도구 3: 검증을 프롬프트에 내장하라

가장 저평가된 기술이다. 좋은 프롬프트는 “잘 부탁한다”로 끝나지 않고 AI가 스스로 채점할 수 있는 객관적 신호를 함께 준다. 앞서 PRP화한 JWT 과제에서 유독 이 세 줄이 결과를 가른다.

## 검증 (이 줄들이 self-correction을 가능하게 한다)
- ruff check . 통과
- pytest tests/test_auth.py 전부 통과
- 기동 후 curl -H "Authorization: Bearer <만료토큰>" /me → 403

이 세 줄이 없으면 모델은 “다 됐습니다”로 끝낸다. 있으면 에이전트는 self-correct 한다. 실패 출력을 읽고, 고치고, 다시 돌려서 green이 될 때까지 반복한다. “should work(아마 될 거다)”라며 검증을 건너뛰는 게 AI 코딩 최악의 안티패턴이다. 검증을 프롬프트 안에 박아 넣으면 이걸 구조적으로 막는다. 이 사고방식을 방법론 레벨로 확장한 게 SDD/TDD/BDD 흐름이고, 내 전체 작업 환경은 Claude Code 울트라 하네스에 정리해 뒀다.

내가 의심하는 지점 / 한계

유행을 그대로 받아 적기는 싫으니 솔직한 단서도 단다.

컨텍스트 엔지니어링이 만병통치는 아니다. 일회성 단발 작업 — “이 에러 메시지 무슨 뜻이야”, “이 정규식 설명해줘” — 에는 PRP니 체이닝이니 다 과잉이다. 그냥 명확한 한 문장이 낫다. 도구는 작업 복잡도에 맞춰 꺼내야 한다.
선행 비용이 든다. 좋은 PRP를 쓰려면 코드베이스를 리서치해야 한다. 5분짜리 작업에 20분짜리 컨텍스트를 짜는 건 손해다. (그래서 컨텍스트 수집 자체를 자동화하는 게 다음 과제다.)
GIGO는 두 배로 적용된다. 잘못된 컨텍스트나 죽은(실행 안 되는) 검증 명령을 넣으면 결과는 오히려 더 불안정(brittle)해진다. 검증 게이트는 실제로 결정론적으로 돌아갈 때만 의미가 있다.
비용도 트레이드오프다. 프롬프트 체이닝은 호출 수만큼, 큰 컨텍스트는 토큰 수만큼 돈이 더 든다. 정확도를 사는 대신 latency와 비용을 치르는 것이므로 작업 가치에 견줘 판단해야 한다 — 5분짜리 질문에 3단계 체인은 낭비다.
저하 임계점을 절대 수치로 외우지 마라. “몇 토큰부터 무너진다”는 모델·과제·평가 방식에 따라 크게 다르다. 방향(많이 넣으면 손해)은 견고하지만 우리 작업의 임계점은 직접 재야 안다. 재는 법은 단순하다 — 같은 과제를 컨텍스트 길이만 늘려가며 여러 번 돌려, 정답률이 꺾이는 지점을 찾으면 된다.

결론 — 좋은 질문에서 좋은 환경 설계로

“프롬프트를 잘 쓴다”는 말은 이제 좋은 질문 한 문장을 짓는 기술에서 모델이 일할 정보 환경을 설계하는 기술로 무게중심이 옮겨 갔다.

그래서 다음 한 번이라도 AI에게 복잡한 걸 시킬 때, 문장을 멋지게 다듬는 데 시간을 쓰기 전에 이 세 가지를 먼저 점검해 보길 권한다.

컨텍스트: 처음 보는 사람이 성공할 만큼 충분한 정보를 줬는가? (그러나 과하지 않게)
구조: 한 방에 끝내려 하는가, 쪼개서 게이트를 둘 수 있는가?
검증: AI가 스스로 채점할 객관적 신호를 줬는가?

기본기(역할·few-shot·CoT)는 깔고 가되, 진짜 차이는 그 바깥의 환경 설계에서 난다. 마법의 주문을 찾는 시대는 끝났다. 이제는 책상 위를 정리하는 사람이 이긴다.

참고

Context windows — Claude Docs — context rot 원문, working memory 정의
Effective context engineering for AI agents — Anthropic Engineering
Building effective agents — Anthropic Engineering — 프롬프트 체이닝·게이트·latency↔정확도
Context Engineering: Agent Reliability Playbook 2026 — Digital Applied — Karpathy(2025-06-25)·Anthropic context editing(2025-09-29)·컨텍스트 층위 실패
Google’s Prompt Engineering Best Practices 요약 — PromptHub — few-shot·CoT·역할·데이터 우선 배치
Lost in the Middle: How Language Models Use Long Contexts (arXiv:2307.03172)
PRPs-agentic-eng (Rasmus Widing) — PRP 개념 원전

프롬프트를 잘 쓴다는 것은 멋진 문장을 만드는 일이 아니라 필요한 맥락을 고르고, 작업을 나누고, 검증 방법을 함께 주는 일이다.