LLM의 성능이 프롬프트만으로 결정된다고 생각했다면 오산이다. 진짜 실력은 모델이 보는 모든 정보, 즉 '컨텍스트'를 설계하는 데서 나온다. 프롬프트 엔지니어링을 넘어, 메모리, 도구, 데이터를 총괄하는 컨텍스트 엔지니어링에 대한 이야기다.
프롬프트에 집착하던 나, 바보였을까?
개발자라면 한 번쯤 이런 고민을 해봤을 것이다. "분명히 프롬프트는 완벽한 것 같은데, 왜 LLM은 어떨 땐 똑똑하고 어떨 땐 엉뚱한 소리를 할까?" 나 역시 마찬가지였다. RAG(검색 증강 생성)로 최신 정보까지 알려줬는데도 사실과 다른 답변을 내놓는 모델을 보며 답답함을 느끼곤 했다.
이 문제의 원인은 대부분 '컨텍스트(Context)'의 부재 혹은 오염에 있다. LLM은 강력한 연산 장치(CPU)지만, 그 작업 공간인 컨텍스트 창(Context Window)은 한정된 메모리(RAM)와 같다. 이 한정된 공간에 어떤 정보를, 어떻게 넣어주느냐에 따라 결과물의 품질이 극명하게 갈린다. 여기서 '컨텍스트 엔지니어링'이라는 개념이 등장한다.
컨텍스트 엔지니어링이란, LLM이 특정 작업을 성공적으로 수행하는 데 필요한 모든 정보와 도구를 최적의 형태로 조합하여 제공하는, 체계적인 시스템을 구축하는 기술을 말한다. 단순히 질문을 잘 다듬는 '프롬프트 엔지니어링'에서 한 단계 나아간, LLM이 처한 전체 정보 환경을 설계하는 일에 가깝다. 프롬프트 엔지니어링이 요리사에게 '맛있는 파스타 만들어줘'라고 말하는 것이라면, 컨텍스트 엔지니어링은 최고의 파스타를 만들 수 있도록 신선한 재료와 잘 닦인 조리도구, 상세한 레시피까지 준비해 주는 것과 같다.
그래서 컨텍스트가 뭔데?
그렇다면 LLM에게 제공되는 '컨텍스트'라는 브리핑 자료는 구체적으로 무엇으로 구성될까? 정보 과학의 '온톨로지(Ontology)'는 세상의 모든 것을 분류하고 관계를 정의하는 학문인데, 이걸 빌려와 컨텍스트를 한 번 해부해 보자.
- 시스템 지침 (System Instructions): 모델의 역할이나 정체성을 지정해 주는 가장 기본적인 설정이다. "당신은 친절한 개발자 도우미입니다" 또는 "모든 답변은 JSON 형식으로 출력하세요"와 같은 규칙을 부여하여 일관된 톤앤매너와 결과물 형식을 유지하게 만든다.
- 사용자 프롬프트 (User Prompt): 사용자가 바로 지금 입력한 질문이나 명령이다. 컨텍스트의 가장 직접적인 구성 요소다.
- 대화 기록 (Conversation History): 이전 대화 내용을 요약하거나 그대로 포함하여 대화의 연속성을 보장한다. "방금 내가 말한 거 기억하지?"를 가능하게 만드는 단기 기억 장치 역할을 한다.
- 외부 데이터 (External Data): RAG를 통해 검색된 최신 정보, 데이터베이스 조회 결과, 사내 문서 등 LLM이 사전 학습 과정에서 보지 못했던 지식을 제공한다. 이를 통해 환각(Hallucination)을 줄이고 답변의 신뢰도를 높인다.
- 도구 (Tools): LLM이 스스로의 한계를 극복하기 위해 사용할 수 있는 외부 기능들이다. 웹 검색, 계산기, 코드 실행기, 다른 API 호출 등이 여기에 해당한다. LLM은 필요하다고 판단하면 특정 도구를 호출하고 그 결과를 다시 컨텍스트에 포함하여 다음 행동을 결정한다.
결국 컨텍스트 엔지니어링은 위와 같은 다양한 정보 조각들을 작업에 맞게 실시간으로 조합하고, 한정된 컨텍스트 창 안에서 우선순위를 정해 최적화하는 과정이다. 오류나 노이즈가 섞인 정보를 걸러내고(Context Poisoning), 너무 많은 정보에 모델이 길을 잃지 않도록(Context Distraction) 관리하는 것이 핵심이다.
과거에는 프롬프트에 기발한 문장 몇 개를 넣어 모델을 구슬리는 것이 중요했다면, 이제는 신뢰할 수 있는 AI 시스템을 만들기 위한 아키텍처 설계가 더 중요해졌다. 어쩌면 우리는 프롬프트를 속삭이는 심리학자에서, LLM이 마음껏 뛰어놀 수 있는 정보의 놀이터를 설계하는 아키텍트로 진화하고 있는지도 모른다.
Ref: