03. 프롬프트 vs 컨텍스트 엔지니어링

🎯 이 장의 목표

"프롬프트 엔지니어링"과 "컨텍스트 엔지니어링"을 구분하고, 동시에 연결한다
왜 업계의 무게중심이 후자로 옮겨가는지 이해한다
두 개념이 같은 목표의 두 측면임을 직관으로 잡는다

같은 질문, 더 넓은 시야

1장에서 프롬프트 엔지니어링을 "모델에게 무엇을·어떻게 말할지 설계하는 일"이라고 했습니다. 그런데 2장에서 본 것처럼, 모델은 지금 컨텍스트에 든 모든 것에 반응합니다. 당신이 직접 타이핑한 지시뿐 아니라, 함께 들어간 시스템 설정, 붙여넣은 자료, 이전 대화, 도구가 돌려준 결과까지 전부 말이죠.

그래서 더 큰 질문이 떠오릅니다. "내가 쓴 한 문장"이 아니라 "모델이 보는 것 전체를 어떻게 구성해야 원하는 행동이 나올까?" 이 더 넓은 질문을 다루는 것이 컨텍스트 엔지니어링입니다.

한 제공자의 정의를 빌리면, 빌딩의 초점이 "프롬프트에 들어갈 딱 맞는 단어와 문구를 찾는 것"에서 "어떤 컨텍스트 구성이 우리가 원하는 모델 행동을 만들어낼 가능성이 가장 높은가"라는 더 넓은 질문으로 옮겨가고 있습니다.

📌 핵심: 프롬프트 엔지니어링이 말의 내용이라면, 컨텍스트 엔지니어링은 말이 놓이는 환경 전체입니다. 후자가 전자를 포함하는 더 넓은 개념입니다.

두 개념을 한 그림으로

flowchart TB
    subgraph CTX["모델이 한 번에 보는 것 전체 (컨텍스트)"]
        sys["시스템 프롬프트<br/>(역할·규칙)"]
        usr["사용자 프롬프트<br/>(이번 지시) ← 좁은 의미의 '프롬프트'"]
        docs["참고 자료<br/>(문서·데이터)"]
        hist["이전 대화 기록"]
        tools["도구 결과<br/>(검색·계산 등)"]
    end
    budget["유한한 attention 예산"]
    out["출력"]

    CTX --> budget --> out

    classDef prompt fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef context fill:#ede9fe,stroke:#8b5cf6,color:#4c1d95
    classDef limit fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class usr prompt
    class sys,docs,hist,tools context
    class budget limit
    class out good

가운데 파란 칸(사용자 프롬프트)이 좁은 의미의 "프롬프트"입니다. 컨텍스트 엔지니어링은 이 칸을 포함해 상자 전체를 설계하는 일입니다. 그리고 그 전체는 유한한 attention 예산이라는 좁은 문을 통과해야 합니다.

비유: 무대와 대사

연극에 비유해봅시다.

프롬프트 엔지니어링 = 배우에게 줄 대사를 잘 쓰는 일. 무슨 말을, 어떤 톤으로, 어떤 순서로 할지.
컨텍스트 엔지니어링 = 무대 전체를 꾸미는 일. 배경, 소품, 조명, 앞 장면에서 무슨 일이 있었는지, 무대에 무엇을 두고 무엇을 치울지.

훌륭한 대사도 엉망인 무대 위에서는 살지 않습니다. 반대로 무대가 완벽해도 대사가 모호하면 장면이 무너집니다. 둘은 경쟁 관계가 아니라 협력 관계입니다.

무엇이 어느 쪽인가 — 구분 표

활동	주로 어느 쪽?	예
지시 문장을 명확히 다듬기	프롬프트	"요약해줘" → "각 항목 한 문장, 5개 이하로 요약"
역할·톤 지정	프롬프트	"친근한 톤으로", "변호사 관점에서"
예시(few-shot) 넣기	둘 다	좋은 예시 선택은 컨텍스트, 예시 문구는 프롬프트
어떤 참고 자료를 넣을지 고르기	컨텍스트	관련 문서만 선별, 무관한 것 제외
자료의 배치 순서 정하기	컨텍스트	질문을 자료 뒤에 둘지 앞에 둘지
긴 대화를 요약해 압축하기	컨텍스트	누적된 기록을 핵심만 남기고 줄이기
도구·검색 결과를 어떻게 끼워넣을지	컨텍스트	RAG에서 검색된 문단을 어떤 형식으로

⚠️ 흔한 실수·미신: "컨텍스트 엔지니어링은 개발자·에이전트 전용"이라는 오해가 있습니다. 사실 챗봇 창에 자료를 붙여넣을 때 무엇을 붙이고 무엇을 뺄지, 대화가 길어졌을 때 새 창에서 핵심만 다시 줄지 결정하는 것도 모두 컨텍스트 엔지니어링입니다. 비개발자도 매일 하고 있는 일입니다.

왜 무게중심이 컨텍스트로 옮겨가나

세 가지 흐름이 맞물립니다.

첫째, 모델이 똑똑해질수록 "마법 같은 한 문장"의 효용이 줄어듭니다. 최신 모델은 의도를 더 잘 추론하므로, 표현을 미세 조정해 얻는 이득이 작아집니다. 대신 무엇을 보여줄지의 영향력은 그대로거나 커집니다. 한 제공자는 "더 똑똑한 모델일수록 덜 처방적인(prescriptive) 엔지니어링을 요구한다"고 표현합니다.

둘째, 실무 작업이 길고 복잡해졌습니다. 단발 질문이 아니라 여러 단계, 여러 도구, 긴 대화로 이어지는 작업에서는 "한 프롬프트"보다 "컨텍스트의 흐름 관리"가 결과를 좌우합니다.

셋째, attention이 유한하다는 제약은 사라지지 않습니다. 컨텍스트 윈도우가 아무리 커져도, 그 안을 무엇으로 채우느냐는 영원히 중요합니다. 한 제공자의 정리처럼, 능력이 커져도 "컨텍스트를 귀하고 유한한 자원으로 다루는 것"은 핵심으로 남습니다.

💡 팁: 그렇다고 프롬프트 기법이 쓸모없어진 건 아닙니다. 오히려 2부의 기법들은 컨텍스트라는 큰 그림 안에서 어떻게 말할지를 담당하는 필수 부품입니다. 이 안내서가 2부(프롬프트 기법)와 3부(컨텍스트)를 모두 비중 있게 다루는 이유입니다.

그래서 이 안내서의 구조

CODE

1부 (지금)  : 공통 직관 — 둘 다의 토대
2부         : 프롬프트 기법 — "어떻게 말할까"
3부         : 컨텍스트 엔지니어링 — "무엇을 보게 할까"
4~6부       : 신뢰성·고급·운영 — 둘을 결합한 실전

두 기술을 따로 배우되, 1부의 직관과 4부 이후의 실전에서 다시 하나로 묶입니다.

이 장에서 배운 것

프롬프트 엔지니어링은 모델에게 무엇을 어떻게 말할지, 컨텍스트 엔지니어링은 모델이 무엇을 보게 할지 전체를 설계하는 일이다.
후자가 전자를 포함하는 더 넓은 개념이다. (대사 vs 무대 전체)
자료 선택·배치·압축·도구 결과 통합은 컨텍스트 쪽이며, 비개발자도 매일 하는 일이다.
모델이 똑똑해지고 작업이 복잡해질수록 무게중심이 컨텍스트로 이동하지만, 프롬프트 기법은 그 안의 필수 부품으로 남는다.
attention이 유한하다는 제약은 사라지지 않으므로, 컨텍스트를 귀한 자원으로 다루는 관점이 핵심이다.

✍️ 확인 문제

다음 활동을 "주로 프롬프트" / "주로 컨텍스트"로 분류하고 한 줄 이유를 적어보세요.
- (a) "정중한 사과 톤으로 써줘"라고 지시
- (b) 고객 문의 답변을 위해 관련 FAQ 3개만 골라 붙여넣기
- (c) 대화가 너무 길어져 핵심만 요약해 새 창에서 다시 시작
- (d) 출력 형식을 "제목·요약·다음 행동" 순서로 지정

"모델이 똑똑해지면 프롬프트 엔지니어링은 필요 없어진다"는 주장에 대해, 이 장의 내용을 근거로 동의 또는 반박해보세요.

(실습) 같은 질문("이 분기 매출이 왜 떨어졌어?")이라도, 프롬프트만 다듬는 개선과 컨텍스트를 더하는 개선은 어떻게 다른지 각각 한 가지씩 구체적으로 적어보세요.

다음 → 04. 좋은 프롬프트의 공통 속성

← 이전02. LLM이 텍스트를 다루는 방식다음 →04. 좋은 프롬프트의 공통 속성