* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(컨텍스트 엔지니어링 ①) 정의
한동안 “프롬프트 엔지니어링”이 유행어였다. 마법의 문장 한 줄을 찾으면 모델이 확 좋아진다는 식이었다. 요즘은 그 무게중심이 옮겨갔다. 문장 하나가 아니라, 모델에게 들어가는 컨텍스트 전체를 설계하는 일 — 이걸 컨텍스트 엔지니어링이라고 부른다.
정의를 한 줄로 하면 이렇다. 원하는 결과가 나올 가능성을 가장 높이는, 고신호 토큰의 최소 집합을 찾는 일. 핵심은 “최소”다. 많이 넣는 게 아니라, 필요한 것만 정확히 넣는 것. 관련 없는 토큰은 성능도 갉고 비용도 갉는다.
이걸 잘 조합하는 게 왜 중요하냐면, 컨텍스트는 유한하고 비싸기 때문이다. 창이 아무리 커도 한계가 있고, 토큰마다 돈이 나간다. 게다가 모델은 잔뜩 넣으면 정작 중요한 걸 놓치는 경향이 있다. 넣을수록 좋아지는 게 아니라, 어느 지점을 넘으면 오히려 나빠진다.
컨텍스트는 무엇으로 이루어지나
“컨텍스트를 설계한다”는 게 막연하게 들리지만, 실제로는 모델에 들어가는 정보 뭉치를 조립하는 일이다. 그 구성 요소는 대략 이렇게 나뉜다.
| 구성 요소 | 역할 |
|---|---|
| 시스템 프롬프트 | 역할·톤·규칙 설정 |
| 지시(instruction) | 이번 요청에서 할 일 |
| 예시(few-shot) | 원하는 입출력 형태를 보여줌 |
| 검색 자료(RAG) | 외부 지식 주입 (근거) |
| 대화 히스토리 | 이전 맥락 유지 |
| 도구 정의 | 모델이 부를 수 있는 기능 |
| 출력 형식 | JSON·표 등 결과 틀 |
컨텍스트 엔지니어링은 이 조각들을 무엇을·얼마나·어떤 순서로 넣을지 설계하는 작업이다. 프롬프트 한 줄이 아니라 이 전체 조립이 결과를 좌우한다.
프롬프트 엔지니어링과 뭐가 다른가
| 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 | |
|---|---|---|
| 초점 | 지시문 문장 다듬기 | 들어가는 정보 전체 설계 |
| 범위 | 한 번의 요청 | 자료·기억·도구까지 |
| 예 | “친절하게 요약해줘” | 어떤 문서를 검색해 얼마나 넣을지 결정 |
프롬프트 엔지니어링이 컨텍스트 엔지니어링의 부분집합이라고 봐도 된다. 모델이 좋아질수록 성패는 ‘문장을 어떻게 쓰느냐’보다 ‘무엇을 넣어주느냐’로 옮겨간다.
숫자로 보면 — 문서 3개 vs 30개
‘적게 넣기’가 감성이 아니라 산수라는 걸 간단히 계산해보자. 문서 한 조각을 평균 500토큰이라 치면:
| 관련 문서 3개 | 문서 30개 전부 | |
|---|---|---|
| 입력 토큰 | ~1,500 | ~15,000 |
| 호출당 입력 비용 | 기준 | 약 10배 |
| 첫 응답 지연 | 짧다 | 프리필부터 느려짐 |
| 정답 위치 | 어디든 잘 보임 | 가운데 문서는 묻힘(lost in the middle) |
30개를 넣으면 비용 10배를 내고 정확도를 사는 게 아니라, 비용 10배를 내고 정확도를 잃는다. 필요한 3개를 고르는 검색(RAG)에 공을 들이는 이유가 이 표 한 장이다. 자세한 건 RAG 시리즈의 검색 편에서 다룬다.
같은 질문, 다른 컨텍스트, 다른 답
왜 이게 중요한지는 예로 보면 바로 온다. “우리 환불 정책 알려줘”라는 같은 질문도 컨텍스트에 따라 답이 갈린다.
- 회사 정책 문서를 검색해 넣으면 → 실제 규정대로 정확히 답한다.
- 아무 자료 없이 물으면 → 그럴듯하지만 지어낸(환각) 정책을 답할 수 있다.
- 관련 없는 문서까지 잔뜩 넣으면 → 핵심이 묻혀 엉뚱한 부분을 답한다.
모델 자체는 그대로인데 결과가 이렇게 달라진다. 그래서 ‘무엇을 넣고 무엇을 뺄지’가 곧 품질이다.
컨텍스트 설계 체크리스트
- 관련성 — 지금 요청에 필요한 것만 넣는다. 많이 넣는 게 좋은 게 아니다.
- 분량 — 길수록 비싸고 느리며, 중간 정보가 묻힌다(lost in the middle).
- 순서 — 중요한 지시·자료는 앞이나 끝에. 가운데는 주의가 흐려진다.
- 형식 — 원하는 출력 틀(JSON·표)을 명시하면 후처리가 편해진다.
- 근거 — 사실이 중요하면 출처를 함께 넣어 환각을 줄인다(RAG).
이 원칙들은 뒤에 이어지는 토큰 예산·도구 정의·기억 관리 편에서 하나씩 구체화한다.
자주 묻는 질문 (FAQ)
컨텍스트 엔지니어링이 프롬프트 엔지니어링과 다른가요?
프롬프트가 ‘한 번의 지시문’이라면, 컨텍스트 엔지니어링은 모델에 들어가는 전체 정보(지시·자료·기억·도구)를 설계하는 더 넓은 작업입니다.
왜 요즘 컨텍스트가 더 중요해졌나요?
모델이 좋아질수록 성패는 ‘무엇을 넣어주느냐’로 갈리기 때문입니다. 같은 모델도 컨텍스트 설계에 따라 결과가 크게 달라집니다.

답글 남기기