실제로 작동하는 AI 애플리케이션을 구축하는 것은 완벽한 프롬프트를 작성하는 일이라기보다, 모델에 제공하는 정보를 제어하는 일에 더 가깝습니다. 어시스턴트와 긴 채팅을 하다가 10분 전에 말한 내용을 모델이 잊어버렸다는 사실을 깨달은 적이 있다면, 여러분은 이미 컨텍스트 엔지니어링이 실패했을 때 어떤 일이 일어나는지 경험해 본 것입니다. AI의 기억력이 나쁘다고 생각하기 쉽지만, 실제로는 컨텍스트 윈도우(context window)의 물리적 한계에 부딪힌 것입니다.

신뢰할 수 있고 반응성이 좋은 시스템을 구축하려면 세 가지 기본 요소인 토큰, 컨텍스트 윈도우, 그리고 컨텍스트와 메모리의 차이를 이해해야 합니다.

토큰이 진정한 화폐입니다

토큰은 단어가 아닙니다. 모델에 텍스트를 보낼 때, 토크나이저(tokenizer)는 이를 더 작은 조각으로 나눕니다. "cat"이나 "the"와 같은 짧고 흔한 단어는 각각 하나의 토큰을 차지할 수 있습니다. "internationalization"과 같은 복잡한 기술 용어는 여러 개로 쪼개집니다. 문장 부호, 공백, 특수 문자도 모두 토큰으로 계산됩니다. 이것이 중요한 이유는 토큰이 API 비용, 응답 속도, 출력 품질 등 모든 것을 결정하기 때문입니다.

단어 수를 세어 비용을 계획하는 개발자는 눈을 감고 비행하는 것과 같습니다. 코드 괄호와 긴 변수명이 포함된 100단어 분량의 프롬프트는 예상치를 훨씬 초과하여 부풀어 오를 수 있습니다. 이것이 토크나이저가 독립적인 도구로 존재하는 이유입니다. 기능을 출시하기 전에 일반적인 페이로드(payload)를 토크나이저로 실행해 보십시오. 시스템 지침, 포맷팅 보일러플레이트(boilerplate), 채팅 기록이 실제 사용자 쿼리보다 더 많은 예산을 잡아먹는다는 사실을 자주 발견하게 될 것입니다. 첫날부터 토큰을 희소 자원으로 취급하십시오.

컨텍스트 윈도우는 고정된 화이트보드입니다

컨텍스트 윈도우는 모델이 단일 요청에서 볼 수 있는 정보의 총량입니다. 이를 크기가 고정된 화이트보드라고 생각하십시오. 시스템 규칙, 대화 기록, 검색된 문서, 그리고 현재 질문으로 화이트보드를 채울 수 있습니다. 하지만 표면이 가득 차면 무언가는 밀려나야 합니다. 오래된 메모를 지우거나, 사진을 찍어 요약하거나, 그렇지 않으면 보드가 넘쳐버립니다.

최신 모델들은 수천 토큰에서 수십만 토큰에 이르는 컨텍스트 윈도우를 광고합니다. 더 큰 윈도우를 무제한 저장소로 취급하고 싶은 유혹이 생기겠지만, 그렇지 않습니다. 화이트보드에는 여전히 가장자리가 있습니다. 기록이 한도를 초과하면 애플리케이션은 오래된 메시지를 삭제하거나 압축해야 합니다. 이러한 제약 사항을 이해하면 윈도우를 데이터베이스처럼 다루는 대신 활성 작업 공간으로 다루기 시작할 수 있습니다.

컨텍스트는 메모리가 아닙니다

이는 숙련된 개발자조차 혼동하기 쉬운 차이점입니다. 모델 자체는 상태를 유지하지 않습니다(stateless). 모델은 어제, 지난주, 또는 다른 세션에서 10분 전에 대화했던 당신을 기억하지 못합니다. AI가 당신이 JavaScript보다 Python을 선호한다거나 간결한 답변을 좋아한다는 것을 기억하는 것처럼 보인다면, 그 메모리는 모델이 아닌 애플리케이션 레이어에 존재하는 것입니다.

애플리케이션은 이러한 사실을 데이터베이스, 캐시 또는 메모리 저장소에 저장합니다. 새로운 요청이 있을 때마다 관련 프로필 데이터를 프롬프트에 다시 주입합니다. 모델은 단순히 1막의 대사가 포함된 대본을 읽고 있을 뿐입니다. 모델에게는 지속적인 자아가 없습니다. 이 분리를 내재화하면 아키텍처가 바뀝니다. 모델에게 기억해 달라고 요청하는 대신, 적절한 시점에 적절한 컨텍스트를 가져오는 시스템을 설계하기 시작하게 됩니다.

왜 더 많은 컨텍스트가 역효과를 낼 수 있는가

상식적으로는 배경 정보가 많을수록 더 나은 답변이 나올 것 같지만, 종종 그 반대의 결과가 나타납니다. 과도한 컨텍스트는 노이즈를 생성합니다. 단 하나의 함수만 수정하면 되는데 모델에게 전체 코드베이스를 건네준다면, 모델은 정적(static) 속에서 신호(signal)를 찾기 위해 애써야 합니다. 연구자들은 "Lost in the Middle(중간에서 길을 잃음)" 효과를 발견했습니다. 모델은 프롬프트의 시작과 끝 부분의 세부 사항에는 주의를 기울이지만, 중간에 묻힌 정보는 희석되거나 무시되는 경향이 있습니다. 이것은 교묘한 문구로 해결할 수 있는 버그가 아닙니다. 트랜스포머(transformer) 기반 아키텍처에 존재하는 구조적 동작입니다.

비대해진 프롬프트는 뼈아픈 타격을 줍니다. 추가되는 토큰마다 연산이 필요합니다. 지연 시간(latency)이 늘어나고, 비용이 상승하며, 사용자의 인내심은 줄어듭니다. 무관한 문서로 가득 찬 프롬프트는 모순을 일으키고, 지엽적인 세부 사항으로 모델의 주의를 분산시키며, 응답이 잘못된 문제에 집착할 확률을 높입니다. 양은 정밀함의 적입니다.

더 나은 컨텍스트를 엔지니어링하는 방법

훌륭한 컨텍스트 엔지니어링은 무자비한 편집의 과정입니다. 이를 실천하는 방법은 다음과 같습니다.

작업에 필요한 내용만 전송하세요. 사용자가 환불 정책에 대해 물으면 직원 핸드북, API 문서, 지난 분기 마케팅 문구를 포함하지 마세요. 포괄성보다는 관련성이 중요합니다.

RAG를 사용하여 관련 문서를 검색하세요. 검색 증강 생성(Retrieval-Augmented Generation)을 사용하면 방대한 지식 베이스를 검색하고 가장 잘 일치하는 구절만 프롬프트에 주입할 수 있습니다. 수천 페이지 분량의 매뉴얼을 창에 한꺼번에 쏟아붓는 대신, 문서를 임베딩하고 사용자의 쿼리에 대해 시맨틱 검색을 수행한 뒤 가장 관련성이 높은 세 개의 단락만 포함하세요. 모델은 정확히 필요한 정보만 받게 되며, 토큰 예산도 유지할 수 있습니다.

이전 대화를 요약하세요. 전체 채팅 트랜스크립트는 비용이 많이 들고 노이즈가 많습니다. 긴 메시지 기록을 지속적인 요약본으로 대체하세요. 예를 들어, 모델에 30개의 주고받은 메시지를 입력하는 대신, "사용자가 Django 배포에 대해 문의했고, 정적 파일 오류가 발생했으며, 권한 문제를 해결했습니다. 현재 문제는 Postgres 14에서 데이터베이스 마이그레이션이 실패하는 것입니다."라는 단일 단락을 저장하세요. 이러한 요약은 화이트보드를 어지럽히지 않으면서도 상태를 유지해 줍니다.

장기 기억과 활성 채팅을 분리하세요. 사용자 기본 설정, 프로젝트 설정 및 계정 기록은 외부 메모리 저장소에 보관해야 합니다. 해당 저장소를 선택적으로 쿼리하세요. 실시간 컨텍스트 창에는 즉각적인 작업과 연속성을 유지하는 데 필요한 아주 짧은 개인적 맥락만 포함되어야 합니다.

운영 환경에서 토큰 사용량을 모니터링하세요. 지연 시간(Latency) 급증은 종종 컨텍스트 비대화와 직접적인 관련이 있습니다. 요청이 모델의 한계치에 도달하면 알림을 설정하세요. 불필요한 내용을 담고 있는 프롬프트를 식별하기 위해 로그를 검토하세요. 최적화는 항상 동일한 질문에서 시작됩니다: "작업을 망가뜨리지 않으면서 제거할 수 있는 것은 무엇인가?"

핵심 요약

최고의 AI 애플리케이션은 컨텍스트 창이 가장 커서 승리하는 것이 아닙니다. 컨텍스트를 절제하며 관리하기 때문에 승리하는 것입니다. 아무리 거대한 화이트보드라도 낙서로 가득 차 있다면 무용지물입니다. 검색, 요약, 필터링을 수행하는 시스템을 구축하세요. 그러면 사용자는 더 빠른 답변을 얻고, 인프라 비용은 예측 가능해지며, 모델은 마침내 실제로 중요한 것에 집중하게 됩니다.

출처: AI Context Engineering: Tokens, Context Windows, & Memory

커뮤니티: GyaanSetu AI on Telegram