당신의 프롬프트가 모델이 보는 것의 단 5%에 불과한 이유

대부분의 개발자들은 자신이 AI에게 프롬프팅을 하고 있다고 생각합니다. 하지만 실제로는 훨씬 더 큰 기계 속에 아주 작은 메시지를 주입하고 있는 것이며, 그 기계는 대부분 사용자의 개입 없이 작동하고 있습니다.

불편한 수학적 사실은 다음과 같습니다. 실제 운영되는 AI 시스템에서 사용자의 실제 프롬프트는 모델로 전송되는 전체 컨텍스트 (Context)의 5% 미만인 경우가 많습니다. 나머지 95%는 무엇일까요? 시스템 지침 (System instructions), 검색된 문서 (Retrieved documents), 대화 기록 (Conversation history), 주입된 데이터 (Injected data), 도구 결과 (Tool results), 그리고 당신의 메시지가 도착하기도 전에 개발자가 구성한 예시 (Examples)들입니다.

이러한 차이에는 이름이 있습니다: 바로 컨텍스트 엔지니어링 (Context engineering) 입니다. 만약 이를 이해하지 못한다면, 당신은 실제로는 당신의 잘못인 문제들에 대해 계속해서 모델을 탓하게 될 것입니다.

모델이 실제로 보는 것

ChatGPT나 다른 AI 제품에 메시지를 입력할 때, 당신은 모델과 직접 대화하는 것이 아닙니다. 당신은 추론 (Inference)이 일어나기 전 백그라운드에서 조립되는 더 큰 문서, 즉 전체 컨텍스트 창 (Context window)에 기여하고 있는 것입니다.

개발자가 "Add error handling to this function"이라는 일곱 단어를 입력했을 때, Cursor와 같은 도구에서 실제로 어떤 일이 일어나는지 단순화하면 다음과 같습니다:

[System prompt: 당신은 숙련된 소프트웨어 엔지니어입니다. 깨끗하고 운영 가능한 코드를 작성하세요. 기존 코딩 스타일을 따르세요...]
[Current file: 당신의 코드 500-2000 토큰 (tokens)]
[Related files: 임포트, 타입, 인터페이스 300-1000 토큰 (tokens)]
...

전체 컨텍스트: 2,000–5,000 토큰 (tokens). 당신의 메시지: 7단어.

이것이 바로 Cursor가 프로젝트에 실제로 부합하는 코드(정확한 임포트, 일치하는 스타일, 올바른 에러 타입)를 작성하는 이유입니다. 모델 자체가 더 똑똑한 것이 아닙니다. 컨텍스트 구성 (Context construction)이 똑똑한 것입니다.

출력을 실제로 형성하는 5가지 계층

최근 ML 코호트 (ML cohort) 과정을 거치며, 컨텍스트를 5가지 계층으로 나누는 프레임워크가 진정으로 유용하다는 인상을 받았습니다. 각 계층은 모델이 추출하는 확률 공간 (Probability space)을 좁혀줍니다.

계층 1: 역할 (Role). 모델에게 자신이 누구인지 알려주세요. "당신은 시니어 백엔드 엔지니어입니다"라고 말하는 것은 어휘, 깊이, 그리고 가정을 변화시킵니다. 모델은 해당 역할과 일치하는 학습 데이터 (Training data) 내의 패턴을 활용합니다.

레이어 2: 작업 (Task). 당신이 원하는 것이 무엇인지 구체적으로 명시하세요. "트레이드오프 (tradeoffs)가 포함된 3가지 옵션을 주세요"는 "이것을 설명해 주세요"와 다릅니다. 모델은 좋은 결과물을 생성하기 전에 출력의 형태 (shape)를 알아야 합니다.

레이어 3: 지식 (Knowledge). 이것은 가장 강력한 레이어입니다. 모델이 가지고 있지 않은 컨텍스트 (context) — 당신의 코드베이스 (codebase), 당신의 도메인 (domain), 당신의 제약 사항 (constraints) — 를 주입하세요. 당신의 구체적인 컨텍스트를 가진 모델은 일반적인 프롬프트를 사용하는 더 큰 모델을 언제나 이깁니다.

레이어 4: 형식 (Format). 구조를 정의하세요. 불렛 포인트 (bullet points), 각 항목당 최대 두 문장, 예시 포함 등과 같은 방식입니다. 모델은 수백만 개의 형식화된 문서로 학습되었으며, 형식 지침을 정확하게 따릅니다.

레이어 5: 제약 사항 (Constraints). 원하지 않는 것을 말하세요. "일반적인 조언은 제외할 것. 유료 광고 제외. 개발자 도구에 효과적인 접근 방식만 제시할 것." 이는 당신이 관심 없는 확률 공간 (probability space)의 부분들을 제거합니다.

이러한 레이어를 전혀 사용하지 않은 프롬프트와 다섯 가지를 모두 사용한 프롬프트의 차이는 점진적인 수준이 아닙니다. 그것은 모델이 특정 주제에 대한 가능한 모든 응답의 평균을 내는 것과, 작고 매우 관련성 높은 조각 (slice)에서 응답을 추출하는 것의 차이입니다.

동일한 모델, 완전히 다른 동작

제가 이해하는 데 시간이 좀 걸렸던 사실은 이것입니다: 모델의 가중치 (weights)는 변하지 않습니다. 변하는 것은 컨텍스트 (context)입니다.

예를 들어, Claude에는 당신이 결코 볼 수 없는 시스템 프롬프트 (system prompt)가 있습니다. 이는 당신의 메시지가 도착하기 전에 내장된 일련의 행동 지침입니다. 그것이 불확실성에 대한 모델의 정직함, 추론 과정을 보여주려는 경향, 그리고 말을 지어내기를 거부하는 성향을 형성합니다. 시스템 프롬프트를 바꾸면, 동작이 바뀝니다. 동일한 모델, 동일한 파라미터 (parameters)이지만, 완전히 다른 어시스턴트가 됩니다.

이것이 바로 동일한 베이스 모델 (base model)이 완전히 다른 제품들을 구동하는 이유이기도 합니다. 고객 지원 문의에 답변하는 AI와 코드를 작성하는 AI는 종종 서로 다른 컨텍스트 구성 (context construction)을 가진 동일한 기반 모델입니다.

API를 구축하고, 마이크로서비스 (microservices)를 관리하며, 모든 구성 요소가 추적 가능한 시스템을 작성하는 백엔드 엔지니어링 배경을 가진 저에게 이 프레임워크는 즉각적으로 이해되었습니다. 컨텍스트 엔지니어링 (Context engineering)은 그저 설정 (configuration)일 뿐입니다. 모델은 런타임 (runtime)입니다. 당신이 무엇을 주입하느냐가 무엇이 실행될지를 결정합니다.

이것이 실무적으로 의미하는 바

만약 당신의 AI 기능이 평범한 결과물을 내놓고 있다면, 기본적으로는 더 큰 모델을 사용하거나 더 나은 프롬프트를 시도하려 할 것입니다. 하지만 대부분의 경우, 실제 해결책은 당신이 구성하고 있는 컨텍스트에 있습니다.

모델을 업그레이드하기 전에 다음을 질문해 보세요:

• 요청이 도착했을 때 모델이 실제로 무엇을 보는가?
• 관련 컨텍스트가 검색되어 주입되고 있는가, 아니면 단순히 가정되고 있는가?
• 역할 (role), 작업 (task), 형식 (format), 그리고 제약 조건 (constraints)이 명시적으로 정의되어 있는가, 아니면 모델이 추측하도록 방치되어 있는가?

RAG 시스템은 본질적으로 자동화된 컨텍스트 엔지니어링입니다. 모델이 무엇을 알아야 하는지 수동으로 파악하는 대신, 벡터 데이터베이스 (vector database)에서 동적으로 정보를 검색하여 프롬프트에 주입합니다. 모델의 역할은 변하지 않습니다. 모델이 보는 것에 대해 다음 토큰을 예측 (next-token prediction)하는 것입니다. 엔지니어링 작업은 모델이 올바른 것을 보도록 보장하는 데 있습니다.

"프롬프트 엔지니어링 (prompt engineering)"에서 "컨텍스트 엔지니어링 (context engineering)"으로의 전환은 단순히 말장난처럼 들릴 수 있습니다. 하지만 그렇지 않습니다. 프롬프트 엔지니어링은 사용자의 메시지를 최적화해야 할 대상으로 취급합니다. 반면 컨텍스트 엔지니어링은 모델이 보는 모든 것, 즉 전체 입력을 설계해야 할 시스템으로 취급합니다.

이러한 관점의 재정의는 당신이 무엇을 구축하고, 무엇을 디버깅하며, 무언가 잘못되었을 때 무엇을 원인으로 지목할지를 변화시킵니다.

LinkedIn에서 연결하세요 : https://www.linkedin.com/in/abhijeethiwale/