왜 프롬프트 엔지니어링의 시대는 끝났는가

왜 프롬프트 엔지니어링의 시대는 끝났는가

“어떻게 말하는가"에서 “무엇을 보여주는가"로. 게임이 바뀌었다.

프롬프트 엔지니어링이라는 직업

2023년, 새로운 직업이 나타났다.

프롬프트 엔지니어.

“단계별로 생각해줘.” “너는 20년 경력의 전문가야.” “예시를 먼저 보여줄게.”

이런 문장들이 수만 달러짜리 노하우가 되었다. 같은 질문이라도 어떻게 말하느냐에 따라 AI의 답변 품질이 극적으로 달라졌기 때문이다.

프롬프트 엔지니어링은 실제로 작동했다. Chain-of-Thought 한 줄이 수학 성적을 20% 올렸다. 역할 부여 한 문장이 전문성의 깊이를 바꿨다. Few-shot 예시 세 개가 출력 형식을 완전히 제어했다.

이것은 과대광고가 아니었다. 진짜였다. 그런데 왜 끝나고 있는가.

왜 작동했는가: 모델이 충분히 멍청했기 때문이다

프롬프트 엔지니어링이 작동한 이유를 제1원리로 보면 단순하다.

초기 LLM은 사용자의 의도를 잘 파악하지 못했다. “요약해줘"라고 하면 요약이 아니라 재작성을 했다. “비교해줘"라고 하면 비교가 아니라 나열을 했다.

모델이 의도를 잘못 읽으니까, 의도를 정확하게 전달하는 기술이 가치 있었다. 프롬프트 엔지니어링은 본질적으로 “통역"이었다. 인간의 의도를 LLM이 이해할 수 있는 형태로 번역하는 것.

통역이 가치 있으려면 언어 장벽이 있어야 한다.

무엇이 바뀌었는가: 모델이 똑똑해졌다

GPT-3.5에서 GPT-4로, Claude 2에서 Claude 3.5로. 모델이 세대를 거듭할수록 의도 파악 능력이 급격히 올라갔다.

“요약해줘"라고 하면 요약한다. “비교해줘"라고 하면 비교한다. “단계별로 생각해줘"라고 말하지 않아도 복잡한 문제에서는 알아서 단계를 나눈다.

언어 장벽이 낮아졌다. 통역의 가치가 줄었다.

2023년에 극적인 차이를 만들던 프롬프트 기법들이 2025년에는 미미한 차이만 만든다. 모델이 충분히 똑똑해지면, 말투는 점점 덜 중요해진다.

그렇다면 무엇이 중요해지는가.

컨텍스트 윈도우라는 물리 법칙

LLM에게는 물리적 제약이 하나 있다.

컨텍스트 윈도우.

128K 토큰이든 1M 토큰이든, 유한하다. 이 유한한 공간 안에 들어간 정보만이 추론에 영향을 미친다. 바깥에 있는 정보는, 아무리 중요해도, 존재하지 않는 것과 같다.

이것은 모델 크기와 무관하다. 파라미터가 1조 개여도 컨텍스트 윈도우는 유한하다. 학습 데이터가 인터넷 전체여도 컨텍스트 윈도우는 유한하다.

모델이 아무리 똑똑해도, 잘못된 정보가 컨텍스트에 들어가면 잘못된 답을 낸다. 관련 없는 정보가 컨텍스트를 채우면 핵심을 놓친다. 필요한 정보가 컨텍스트에 없으면 모르는 것과 같다.

프롬프트 엔지니어링은 “어떻게 말하는가"의 문제였다. 새로운 게임은 “무엇을 보여주는가"의 문제다.

이것이 컨텍스트 엔지니어링이다.

비유: 시험장의 오픈북

프롬프트 엔지니어링과 컨텍스트 엔지니어링의 차이를 시험으로 비유하면 이렇다.

프롬프트 엔지니어링은 시험 문제를 잘 쓰는 것이다. “다음 중 올바른 것을 고르시오” 대신 “아래 조건을 모두 만족하는 답을 단계별로 도출하시오"라고 쓰면 학생이 더 나은 답을 낸다.

컨텍스트 엔지니어링은 오픈북 시험에서 어떤 책을 가져가는가의 문제다. 시험 문제를 아무리 잘 써도, 학생이 가져온 책이 엉뚱한 것이면 답을 못 낸다. 가져올 수 있는 책의 수는 한정되어 있다. 어떤 책을 가져가느냐가 성적을 결정한다.

모델이 멍청할 때는 문제 출제법(프롬프트)이 중요했다. 모델이 똑똑해지면 참고 자료(컨텍스트)가 중요해진다.

에이전트 시대가 전환을 가속한다

이 전환은 에이전트의 등장으로 더 빨라지고 있다.

프롬프트 엔지니어링은 인간이 매번 작성한다. 인간이 질문을 쓰고, 인간이 맥락을 설명하고, 인간이 형식을 지정한다.

에이전트는 다르다. 에이전트는 스스로 추론하고, 도구를 호출하고, 다른 에이전트와 협업한다. 각 단계에서 컨텍스트를 스스로 구성해야 한다.

에이전트가 외부 API를 호출해서 데이터를 받아왔다. 이 데이터를 다음 추론의 컨텍스트에 넣어야 한다. 어떤 부분을 넣고 어떤 부분을 뺄 것인가. 이전 추론 결과 중 무엇을 유지하고 무엇을 버릴 것인가. 다른 에이전트가 보내온 정보는 신뢰할 만한가.

이 모든 결정을 인간이 매번 내릴 수 없다. 에이전트가 자율적으로 동작하려면 컨텍스트 구성이 자동화되어야 한다.

프롬프트 엔지니어링은 인간의 기술이었다. 컨텍스트 엔지니어링은 시스템의 능력이어야 한다.

프롬프트 엔지니어링이 사라지는 것은 아니다

오해를 방지하겠다.

프롬프트 엔지니어링이 무의미해진다는 말이 아니다. 시스템 프롬프트는 여전히 중요하다. 출력 형식 지정은 여전히 필요하다. 역할과 제약 조건의 명시는 여전히 효과적이다.

다만, 프롬프트 엔지니어링이 차지하던 비중이 줄어들고 있다.

2023년에 출력 품질의 70%가 프롬프트에 의해 결정되었다면, 2025년에는 30%가 프롬프트, 70%가 컨텍스트에 의해 결정된다.

비율이 역전되었다.

그리고 이 추세는 되돌아가지 않는다. 모델은 계속 똑똑해질 것이고, 똑똑해질수록 말투의 영향은 줄어들고 컨텍스트의 영향은 커질 것이다.

그런데 컨텍스트 엔지니어링에는 인프라가 없다

여기가 핵심이다.

프롬프트 엔지니어링에는 도구가 있었다. 프롬프트 템플릿, 프롬프트 라이브러리, 프롬프트 테스트 프레임워크. “어떻게 말하는가"를 체계적으로 관리하는 생태계가 만들어졌다.

컨텍스트 엔지니어링에는 아직 이것이 없다.

지금 현업에서 컨텍스트를 다루는 방식을 보자.

RAG 파이프라인에서 청크 크기를 수작업으로 조정한다. 시스템 프롬프트에 배경 정보를 수작업으로 작성한다. 에이전트의 메모리에 무엇을 저장할지 수작업으로 설계한다. 검색 결과 중 무엇을 컨텍스트에 넣을지 수작업으로 결정한다.

전부 수작업이다.

그리고 그 수작업의 재료가 전부 자연어다. 자연어 문서를 자연어로 잘라서 자연어 컨텍스트에 넣는다.

자연어의 정보 밀도는 낮다. 출처가 없다. 확신도가 없다. 시점이 없다. 같은 의미를 전달하는 데 불필요한 토큰이 소비된다. 품질 판단을 자동화할 방법이 없다.

이것은 프롬프트 엔지니어링 이전 시대와 비슷하다. 프롬프트 엔지니어링도 처음에는 수작업이었다. 개인의 직관과 경험에 의존했다. 그러다 도구와 방법론이 생기면서 체계화되었다.

컨텍스트 엔지니어링은 지금 그 이전 단계에 있다. 문제는 인식되었지만, 인프라가 없다.

인프라가 갖춰야 할 것

컨텍스트 엔지니어링이 수작업에서 시스템으로 넘어가려면 최소한 다음이 필요하다.

압축. 같은 윈도우에 더 많은 의미를 넣는 방법. 자연어의 문법적 접착제를 걷어내고 의미만 남기면, 모델 변경 없이 실질적 윈도우 크기를 몇 배로 늘릴 수 있다.

색인. 필요한 정보를 정확하게 찾는 방법. 임베딩 유사도가 아니라 의미 구조에 기반한 검색. “애플 매출"을 찾을 때 “사과 영양성분"이 따라오지 않는 검색.

검증. 규격에 맞지 않는 정보를 기계적으로 거부하는 방법. Go 컴파일러가 사용하지 않는 변수를 에러로 잡듯, 출처 없는 주장, 시점 없는 사실을 컨텍스트 진입 전에 걸러내는 것. 가장 싸고 확정적인 검사가 가장 먼저 와야 한다.

필터. 의미적 품질을 판단하는 방법. 검증이 형식을 보는 것이라면, 필터는 내용을 본다. 관련성, 신뢰도, 최신성. 지금 이 추론에 정말 필요한 정보인가.

정합성. 선택된 정보 집합의 내적 일관성을 보장하는 방법. 개별적으로 좋은 정보가 모이면 서로 모순될 수 있다. 2020년의 CEO와 2024년의 CEO가 동시에 컨텍스트에 들어가면 LLM은 혼란스러워한다.

구성. 윈도우 안에서의 배치와 구조를 최적화하는 방법. 같은 정보라도 어디에 놓느냐에 따라 어텐션의 가중치가 달라진다. 앞에 놓느냐 뒤에 놓느냐, 그룹핑을 어떻게 하느냐.

축적. 시간이 지나면서 시스템이 학습하고 성장하는 방법. 캐싱은 개별 결과의 재활용이다. 축적은 어떤 컨텍스트 구성이 좋은 결과를 냈는지를 학습하고, 지식 베이스 자체가 성장하는 것이다.

이 일곱 가지가 컨텍스트 엔지니어링 인프라의 전체 스택이다.

이것은 특정 도구의 문제가 아니다

솔직하게 말하겠다.

이 인프라를 누가 만드느냐는 열린 질문이다. 하나의 도구가 전부 해결할 수도 있고, 여러 도구가 각 층을 담당할 수도 있다.

그러나 인프라가 필요하다는 것 자체는 열린 질문이 아니다.

컨텍스트 윈도우가 유한하다는 것은 물리적 사실이다. 윈도우가 10배 커져도 세계의 정보는 그보다 빠르게 늘어난다. 자연어의 정보 밀도가 낮다는 것은 구조적 사실이다. 에이전트가 자율적으로 동작하려면 자동화된 컨텍스트 관리가 필요하다는 것은 논리적 필연이다.

프롬프트 엔지니어링에 도구가 필요했듯, 컨텍스트 엔지니어링에도 도구가 필요하다. 다만 이번에는 도구의 성격이 다르다.

프롬프트 엔지니어링의 도구는 텍스트 편집기에 가까웠다. 컨텍스트 엔지니어링의 도구는 컴파일러에 가깝다.

정보를 압축하고, 색인하고, 검증하고, 필터하고, 정합성을 확인하고, 배치를 최적화하고, 결과를 축적한다. 이것은 편집이 아니라 엔지니어링이다.

그래서 이름이 컨텍스트 “엔지니어링"이다.

요약

프롬프트 엔지니어링은 모델이 멍청할 때 가치 있었다. 모델이 의도를 못 읽으니, 의도를 잘 전달하는 기술이 중요했다.

모델이 똑똑해지면서 게임이 바뀌었다. “어떻게 말하는가"에서 “무엇을 보여주는가"로. 프롬프트에서 컨텍스트로.

에이전트의 등장이 이 전환을 가속한다. 인간이 매번 컨텍스트를 조립할 수 없다. 시스템이 스스로 해야 한다.

그런데 지금, 컨텍스트 엔지니어링에는 인프라가 없다. 자연어를 수작업으로 잘라붙이고 있다.

필요한 인프라는 일곱 가지다: 압축, 색인, 검증, 필터, 정합성, 구성, 축적.

프롬프트 엔지니어링의 시대가 끝나는 것이 아니다. 프롬프트 엔지니어링만으로 충분한 시대가 끝나는 것이다.