구글이 컨텍스트 윈도우를 없앴다.

백만 토큰 컨텍스트 창은 대형 언어 모델의 비책으로 여겨졌습니다. 공급업체들은 128K, 200K, 심지어 1M 토큰 프롬프트를 광고하기 위해 경쟁했으며, 단순한 용량이 신뢰할 수 있는 코딩 보조자, 자율 에이전트, 완전 검색 가능한 지식 기반을 열어줄 것처럼 보였습니다. 그러나 현실은 덜 영화 같았습니다: 더 많은 토큰은 종종 더 느리고, 더 비싸며, 여전히 혼란스러운 모델을 의미할 뿐이었습니다.

구글의 최신 컨텍스트 엔지니어링 연구는 이론의 한계를 드러냅니다. 이 회사는 “문제에 더 많은 토큰을 던지는 것은 시간을 벌 수 있지만, 비용, 대기 시간 및 신뢰성의 곡선 형태를 변경하지는 않습니다.”라고 주장합니다. 1M 토큰 윈도우로 복잡성을 잠시 동안 피할 수 있지만, 실제 작업 부하인 RAG 결과, 다중 에이전트 로그, 도구 출력 및 사용자 이력은 빠르게 따라잡을 것입니다.

세 가지 경계가 “그냥 프롬프트를 넣는” 전략을 무너뜨립니다. 첫 번째는 비용과 지연의 악순환입니다: 매 추가 100K 토큰마다 추론 시간과 클라우드 비용이 생산 규모 애플리케이션에서 보통 2-3배 증가합니다. 두 번째는 "중간에 잃어버리는" 현상으로, 과도하게 로드된 프롬프트에 묻혀 있는 중요한 지시사항을 모델이 무시하는 경우입니다. 세 번째는 물리학입니다: 도구와 에이전트를 몇 시간 또는 며칠 동안 연결하기 시작하면 백만 토큰 창도 넘칩니다.

구글의 답변은 "2M 토큰"이 아니라 아키텍처 전환이다. 맥락을 거대한 변경 가능한 채팅 로그로 취급하는 대신, 회사는 이를 더 풍부하고 상태ful 시스템에 대한 컴파일된 뷰로 구성한다. 원시 데이터—세션, 기억, 아티팩트—는 소스 코드 역할을 하며, 프로세서의 파이프라인이 각 모델 호출을 위한 최소한의 작업 특정 맥락을 컴파일한다.

이 변화는 맥락을 단순한 버퍼링 문제에서 시스템 설계 문제로 전환시킵니다. 구글의 에이전트 개발 키트(ADK)는 이를 네 가지 계층의 구조로 다룹니다: 작업 맥락, 세션, 메모리, 아티팩트로, 각 계층은 명확한 책임과 생애주기를 가집니다. 맥락은 “창에 맞는 것”이 되는 것이 아니라 코드, 정책 및 범위의 명시적인 산물이 됩니다.

이 기사는 해당 프레임워크가 실제 프로덕션에서 어떻게 작동하는지를 설명합니다. Google 에이전트 개발 키트(ADK)를 사용하여 컨텍스트 아키텍처, 다양한 컨텍스트 객체 및 권한을 분석하고, 백만 토큰 시대가 이미 끝났음을 보여주는 실제 문서 조사 에이전트를 소개합니다.

더 큰 컨텍스트 윈도우는 전지적 지식을 약속하지만, 대부분 sticker shock만을 제공합니다. 추가 100,000 토큰마다 실제 돈과 시간이 소요되며, 제작팀은 이 두 가지를 모두 체감합니다. 구글의 컨텍스트 엔지니어링 블로그에서는 비용/지연 나선에 대해 설명합니다: 호출당 더 많은 토큰이 소요되고, 수천 명의 동시 사용자가 곱해지면 “좋은 데모”가 빠르게 “예산 초과”로 바뀝니다.

지연은 마찬가지로 잔인하게 증가합니다. 백만 개의 토큰 프롬프트는 느린 디코딩, 더 긴 도구 체인, 그리고 “조수”에서 “티켓 발급 시스템”으로 변하는 사용자 경험을 의미합니다. 다중 에이전트 설정에서는 각 에이전트 호출이 더 많은 모델 호출로 퍼지기 때문에 하나의 부풀려진 컨텍스트가 전체 파이프라인에 영향을 미칩니다.

그 다음은 중간에서 잃어버린입니다. LLM은 거대 프롬프트 전반에 걸쳐 균일하게 주의를 기울이지 않으며, 종종 시작과 끝에 비해 중간을 간과합니다. 구글의 블로그와 후속 연구에서는 중요한 사실이 긴 시퀀스의 중간에 묻혀 있을 때 정확도가 떨어진다는 사실이 나타났습니다. 비록 모델이 기술적으로는 모든 것을 "볼" 수 있더라도 말이죠.

제작 에이전트의 프롬프트를 사용한 지 몇 분 후의 모습을 상상해 보세요. 위쪽에는 새 사용자 질문이 있습니다. 아래쪽에는 최근 도구 오류와 재시도 지침이 있습니다. 그 사이에 실제 정책 제약이나 중요한 시스템 지침이 끼어 있습니다. 모델은 기꺼이 가장자리 주위를 최적화하고 실제로 중요한 것을 넘어 환상을 만들어냅니다.

실제 작업량이 이것을 더 악화시킵니다. 한 번의 전환에는 다음이 포함될 수 있습니다: - 20–50 RAG 문구 - 5–10 도구 호출 로그 - 수십 개의 이전 채팅 메시지

그 모든 것을 “1M-토큰 준비 완료” 모델에 넣더라도, 컨텍스트 창은 여전히 몇 번의 풍부한 상호작용 후에 고장 납니다. 심지어 구글 에이전트 개발 키트(ADK) 데모에서도 모든 것을 무작정 프롬프트에 스트리밍한다면 어떻게 아티팩트, 메모리 및 세션 상태가 급격히 증가하는지를 보여줍니다.

물리적인 한계가 작업을 마무리합니다. 컨텍스트 길이는 계산 및 메모리와 함께 서브선형적으로 증가하며, 128K에서 1M 토큰으로 확장하는 것만으로도 특수한 인프라가 필요합니다. 더 높은 수치를 목표로 하면 GPU RAM, 대역폭 및 학습 안정성과 싸우게 되며, 단순히 똑똑한 프롬프트 디자인으로는 해결할 수 없습니다.

이것들은 실험실의 호기심이 아닙니다. 이것이 생산 팀이 조용히 역사를 통제하고, RAG 결과를 단축하며, 공격적으로 요약하는 이유입니다. 맥락이 더 이상 원시 데이터 흐름이 아니라 정리된 보기로 변하지 않는 한, 대규모 기관들은 계속해서 자신의 데이터에 파묻힐 것입니다.

구글의 새로운 컨텍스트 컴파일러 개념은 무한한 대화 로그로서의 기존 컨텍스트 창의 사고 모델을 제거합니다. 변형 가능한 스트림 버퍼 대신, 컨텍스트는 단일 프롬프트 밖에 존재하는 세션, 기억, 아티팩트와 같은 훨씬 더 풍부한 상태에 대한 컴파일된 뷰로 변모합니다. 각 모델 호출은 전체 건초 더미가 아닌 신중하게 구성된 슬라이스만을 봅니다.

컴파일러 엔지니어처럼 생각하세요, 프롬프트 조정자가 아니고. 원시 상호작용 데이터는 소스 코드가 되고, 프로세서의 파이프라인이 컴파일러 역할을 하며, 최종적으로 Gemini에 전송되는 프롬프트는 최적화된 실행 파일이 됩니다. Google의 공식 블로그, 생산을 위한 효율적인 상황 인식 다중 에이전트 프레임워크 설계에서는 프로덕션 규모의 에이전트에 대한 필수 요건으로 이를 분명히 설명하고 있으며, 단순한 추상이 아님을 강조합니다.

이 모델 하에서 개발자의 역할은 “이 프롬프트를 어떻게 표현하지?”에서 “맥락을 구축하는 파이프라인을 어떻게 설계할 것인가?”로 바뀝니다. 세션이 구조화된 이벤트를 저장하는 방식, 기억이 장기 지식을 인코딩하는 방식, PDF나 CSV와 같은 아티팩트가 ID로 참조되는 방식(창에 덤프되지 않도록) 등을 설계합니다. 대규모 프롬프트를 수작업으로 만들던 것을 중단하고 흐름, 프로세서 및 범위를 정의하기 시작합니다.

Google 에이전트 개발 키트(ADK)는 이를 APIs에 통합합니다. 이는 작업 컨텍스트, 세션, 메모리, 산물과 같은 독립적인 컨텍스트 계층을 드러내고, 이를 `app`, `user`, `temp`와 같은 명시적인 프로세서와 상태 접두사를 통해 연결하도록 강제합니다. 저장소와 프레젠테이션의 분리는 5,000 토큰 이하의 슬림하고 목표 지향적인 프롬프트를 발산하면서 수천 개의 이벤트를 기록할 수 있는 것을 의미합니다.

기본적으로 범위에 따른 권한이 부여됩니다. 모든 모델 호출은 작업에 필요한 최소한의 컨텍스트만을 받으며, 이는 컴파일러 파이프라인에 의해 즉시 조립됩니다. 에이전트가 더 많은 정보가 필요할 경우, 모든 것을 "만약의 경우"를 대비해 미리 로드하는 대신 도구를 호출하여 아티팩트를 가져오거나 메모리에 쿼리합니다.

이 컴파일된 컨텍스트 접근 방식은 세 가지 문제점을 한 번에 해결합니다. 토큰 수가 감소하므로 비용과 대기 시간도 함께 줄어듭니다. "중간에서 잃어버림"은 중간이 대부분 사라짐에 따라 줄어듭니다. 관련 없는 이력이 작업 컨텍스트에 들어오지 않기 때문입니다. 물리적 컨텍스트 제한은 더 이상 고정된 한계가 아니라 코드로 제어할 수 있는 최적화 예산이 됩니다.

컨텍스트 엔지니어링은 정보가 존재하는 곳과 모델이 이를 어떻게 인식하는지 사이의 명확한 구분에서 시작됩니다. 구글의 에이전트 개발 키트(ADK)는 이를 첫 번째 원칙인 저장소와 프레젠테이션을 분리하라는 원칙에 담고 있습니다. 듣기에는 추상적으로 들릴 수 있지만, 이는 발전할 수 있는 시스템과 자체 스크립트에 의해 붕괴되는 시스템의 차이를 의미합니다.

ADK는 세션과 작업 컨텍스트 사이에 명확한 경계를 설정합니다. 세션은 지속적이고 권위 있는 원장 역할을 하며, 모든 사용자 메시지, 도구 호출, 도구 결과 및 시스템 이벤트가 구조화된 상태로 여기에 저장됩니다. 작업 컨텍스트는 단일 LLM 호출을 위해 생성된 일회성 스냅샷이며, 그 후 삭제됩니다.

세션을 데이터베이스로 생각하고, 작업 컨텍스트를 SQL 쿼리 결과로 생각하세요. 각 쿼리에 맞게 데이터베이스를 수정하지 않고, 쿼리를 변경합니다. 여기도 같은 원리입니다: 완전하고 추가만 가능한 세션을 유지하고, 작업, 모델 또는 지연 예산에 따라 다양한 작업 컨텍스트를 이 세션에서 컴파일합니다.

그 분리는 제품이 변경되는 순간에 중요해집니다. Gemini 3 Pro를 더 작은 모델로 교체하거나, 장황한 채팅 스타일의 프롬프트에서 간결한 도구 실행 프롬프트로 전환하고 싶으신가요? 작업 컨텍스트를 구축하는 프로세서를 업데이트하지만, 세션 스키마나 과거 데이터는 변경하지 않습니다. 과거 상호작용은 그대로 유지되며, 모델에 대한 프레임을 근본적으로 변경하더라도 그대로입니다.

Google 에이전트 개발 키트(ADK) 문서는 이를 명확한 컨텍스트 객체와 상태 접두사로 공식화합니다. 세션 기반 상태는 `app` 및 `user`와 같은 내구성 있는 접두사 아래에 존재하며, 일시적이며 호출 전용 데이터는 `temp` 아래에 존재합니다. 오직 작업 컨텍스트만이 이러한 네임스페이스를 가로질러 읽고 현재 호출을 위한 최소한의 뷰를 컴파일합니다.

실제적인 영향은 다중 에이전트 시스템에서 빠르게 나타납니다. 한 에이전트는 마지막 3개의 사용자 전환과 도구 요약만 포함된 작업 맥락을 볼 수 있고, 다른 에이전트는 200개의 메시지 세션과 RAG 히트를 종합한 요약을 받을 수 있습니다. 둘 다 동일한 기본 기록에서 파생되지만, 각 호출은 실제로 필요한 토큰에 대해서만 비용을 지불합니다.

컨텍스트 윈도우는 문자열 연결로 확장되곤 했습니다: 사용자 메시지, 에이전트 응답, 도구 출력, 요금이 폭발할 때까지 반복합니다. 구글 에이전트 개발 키트(ADK)는 이를 제거하고 명시적 변환으로 대체합니다: 원시 상태를 작동 가능한 프롬프트로 컴파일하는 이름이 지정된 순서화된 파이프라인입니다. 컨텍스트는 더 이상 텍스트 덩어리가 아니라 빌드 아티팩트가 됩니다.

`prompt = history + docs + tools` 대신에 `summarize_session`, `select_relevant_artifacts`, `inject_instructions`, `budget_tokens`와 같은 프로세서를 정의합니다. 각 단계에는 이름, 계약, 그리고 파이프라인에서의 위치가 있습니다. 모든 단계를 기록할 수 있고, 실행 간의 출력 차이를 비교하며, 시스템의 나머지 부분을 건드리지 않고 프로세서를 교체할 수 있습니다.

구글의 컨텍스트 블로그와 ADK 문서에서는 이것을 세션, 메모리, 아티팩트 및 작업 컨텍스트의 네 가지 상태를 변환하는 프로세서의 흐름으로 설명합니다. 예를 들어, 문서 연구 에이전트는 다음과 같은 작업을 수행할 수 있습니다: - 메모리에서 이전 결정을 가져오기 - 아티팩트에서 후보 PDF를 순위 매기기 - citation을 2,000토큰 요약으로 압축하기 - Gemini 3 Pro를 위한 최소한의 프롬프트 출력하기

프로세서가 명시적이기 때문에 팀은 이를 단위 테스트할 수 있습니다. `select_relevant_artifacts`가 5개 이상의 문서를 끌어오지 않는다고 확신할 수 있고, `summarize_session`이 1,000 토큰 이하로 유지된다고 장담할 수 있습니다. 디버깅은 "모델이 왜 환각을 일으켰는가?"에서 "어떤 프로세서가 잘못된 데이터를 주입했는가?"로 바뀝니다.

기본적으로 범위 설정은 또 다른 문제인 '누가 무엇을 보는가'를 다룹니다. 전체 다중 에이전트 기록을 모든 도구 호출에 덤프하는 대신, ADK는 최소한의 역할 별 맥락을 유형화된 맥락 객체를 통해 라우팅합니다. 도구, 콜백 및 지침 제공자는 각각 제한된 관점을 갖게 됩니다.

도구 기능은 세션 상태를 읽고 쓸 수 있으며, 아티팩트를 저장하거나 로드하고, 메모리를 검색할 수 있는 ToolContext를 받습니다. 콜백 핸들러는 상태와 아티팩트가 포함된 CallbackContext를 받지만 메모리 검색이 없으므로 사이드 채널 혼란을 방지합니다. 명령 제공자는 읽기 전용 컨텍스트를 보므로 시스템 프롬프트를 생성하는 동안 상태를 비밀리에 변경할 수 없습니다.

스코프가 설정된 컨텍스트는 다중 에이전트 시스템을 AI 조립 라인으로 변화시킵니다. 한 단계에서는 아티팩트를 읽고 구조화된 요약을 생성하며, 다른 단계에서는 보다 좁은 범위로 그 요약을 사용자에게 전달되는 글로 변환합니다. 세 번째 단계에서는 결과를 다시 메모리에 기록합니다. 단일 에이전트가 전체 50,000 토큰 이력을 가져다니지 않습니다.

명시적 변환과 기본적으로 범위가 지정된 요소들이 함께 작동하여 부하가 걸린 상황에서도 예측 가능한 컨텍스트 플로우를 생성합니다. 어떤 프로세서가 실행되고, 어떤 상태에 접근할 수 있으며, 얼마나 많은 토큰을 방출하는지 명확히 알 수 있습니다. 이러한 규율이 백만 토큰 모델을 필수가 아닌 선택으로 만들어줍니다.

Google 에이전트 개발 키트(ADK)의 맥락 인식 에이전트는 맥락을 부수적인 요소가 아니라 제품으로 간주하는 4단계 스택에서 실행됩니다. 각 단계는 다른 질문에 답합니다: 현재 모델이 무엇을 보고 있는지, 실제로 일어난 일은 무엇인지, 어떤 정보가 지속되어야 하는지, 그리고 중요한 자산이 어디에 위치하는지.

상단에는 작업 컨텍스트가 위치합니다. 이것은 ADK가 단일 모델 호출을 위해 Gemini에 컴파일하고 전송하는 간결하고 일시적인 페이로드로, 선택된 메시지, 도구 출력, 메모리의 스니펫 및 몇 가지 아티팩트 참조를 포함합니다. ADK는 호출 후 즉시 이를 폐기하므로 작업 컨텍스트에 있는 내용은 그 자체로는 권위가 없습니다.

그 아래에는 세션이 존재합니다. 이는 상호작용의 오랜 기록인 정식 로그입니다. 모든 사용자 메시지, 모델 응답, 도구 호출 및 도구 결과는 평면 전사 형식이 아닌 구조화된 이벤트 객체로 여기에 저장됩니다. ADK가 작동하는 컨텍스트를 재구축할 때, 이 세션 타임라인을 쿼리하고 현재 작업을 위해 이벤트를 필터링, 요약 또는 재정렬하는 프로세서를 적용합니다.

보다 긴 수명의 지식은 메모리로 이동합니다. 메모리는 사용자 선호도(어조, 언어, 알림 습관), 지속적인 사실(회사 정책, 제품 사양) 및 어떤 단일 대화를 초월해야 할 정제된 결정을 보유하고 있습니다. ADK는 메모리 검색 API를 통해 이를 표면화하여, 상담원이 10,000개의 역사적 토큰을 재생하는 대신 중요한 3-10개의 항목만 끌어올 수 있도록 합니다.

아티팩트는 “프롬프트의 대용량 파일” 문제를 해결합니다. 아티팩트는 한 번 저장되고 안정적인 이름이나 ID로 참조되는 대형 바이너리 또는 텍스트 객체(PDF, CSV, 이미지, 오디오 파일 등)입니다. 도구는 아티팩트를 읽고 쓰며, 작업 컨텍스트에는 필요한 경우 경량 참조와 추출된 조각만 포함됩니다.

이 네 가지 계층은 단일체가 아닌 맥락 파이프라인을 형성합니다. 예를 들어, 문서 연구 에이전트는 세션을 읽어 최신 사용자 질문을 찾고, 이전 결정을 위해 메모리를 검색하고, ID로 PDF 아티팩트를 로드한 후, 몇 개의 관련 단락과 인용으로만 구성된 작업 맥락을 컴파일할 수 있습니다. 비용과 지연 시간은 원본 코퍼스가 아니라 컴파일된 슬라이스에 따라 확장됩니다.

구글의 자체 가이드는 팀이 이러한 계층을 1급 디자인 표면으로 다루도록 권장합니다. ADK 컨텍스트 문서에서는 작업 컨텍스트, 세션, 메모리 및 아티팩트가 구체적인 유형, 권한 및 프로세서와 어떻게 연결되는지를 설명하여 다중 에이전트 시스템이 작업 부하가 증가함에 따라 빠르고 저렴하며 안정적으로 유지되도록 합니다.

상태는 AI가 금붕어처럼 잊어버리는 것이 아니라 지속적인 느낌을 갖도록 하며, Google 에이전트 개발 키트(ADK)는 이를 맥락 API에 직접적으로 통합하는 기만적으로 간단한 접두사 시스템을 제공합니다. 에이전트에게 하나의 모호한 ‘기억’ 덩어리를 전달하는 대신, ADK는 상태를 temp:, user:, 및 app: 이름 공간으로 나누어 실제 소프트웨어가 작동하는 방식에 깔끔하게 매핑합니다.

temp: 스크래치패드로 시작하세요. `temp:` 아래에 작성하는 모든 것은 단일 호출 동안만 존재하고 사라집니다. 한 도구는 파싱된 CSV를 `temp:parsed_doc` 아래에 저장할 수 있고, 다른 도구는 200ms 후에 이를 읽을 수 있으며, 에이전트가 응답한 후 ADK는 이를 삭제합니다—중간 쓰레기로 장기 기록을 오염시킬 위험이 없습니다.

레벨을 한 단계 올리면 user:는 에이전트의 실제 기억으로 작용하는 사람에 대한 정보가 됩니다. `user:reading_level`, `user:last_projects`, 또는 `user:blocked_sources`와 같은 키는 ADK를 백업 스토어에 연결하는 한 세션 간에 지속됩니다. 데모에 구축된 연구 보조원은 사용자가 지난주에 이미 요약한 논문을 기억할 수 있어 이를 다시 가져오거나 다시 설명하는 것을 피할 수 있습니다.

상단에는 app:이 위치하여 전체 배포를 위한 글로벌 상태를 제공합니다. 기능 플래그(`app:enable_vision`), 시스템 전역 속도 제한, 또는 공유 임베딩 인덱스 참조가 모두 여기에 존재합니다. 모든 에이전트 인스턴스와 모든 사용자가 이러한 값을 읽을 수 있으므로, 설정을 한 번 변경하면 수백 개의 동시 세션에서 행동 변화를 관찰할 수 있습니다.

함께, 이 세 개의 접두사는 맞춤형 프레임워크를 만들지 않고도 구체적인 상태 계층 구성을 제공합니다. 다음과 같은 기능이 있습니다: - temp: 도구 간의 상황별 연결을 위한 것 - user: 사용자별 메모리를 위한 것 - app: 사용자 간의 구성을 위한 것

그 계층 구조는 ADK의 디자인 원칙을 직접적으로 인코딩합니다. 저장소와 프레젠테이션 분리: 상태는 `temp:`, `user:`, 또는 `app:` 아래에 존재하며, 작업 컨텍스트는 이러한 키의 컴파일된 슬라이스입니다. 명시적 변환: 도구와 프로세서는 거대한 프롬프트를 변형하는 대신 특정 접두사를 읽고 씁니다. 기본적으로 범위가 설정됨: `temp:`는 턴을 넘지 않고 누수되지 않으며, `user:`는 우연히 글로벌이 되지 않고, `app:`는 침묵 속에서 사용자 특정 행동으로 바뀌지 않습니다.

Google 에이전트 개발 키트(ADK)는 모든 맥락 이론을 실제 연구 봇으로 전환합니다. Yeyu Lab의 데모는 전체 PDF를 프롬프트에 집어넣지 않고도 파일을 검색, 열고, 분석할 수 있는 문서 도우미를 구축합니다. 대신, 각 Gemini 1.5 또는 Gemini 2.0 호출을 위한 충분한 맥락만을 컴파일합니다.

디자인의 핵심은 온디맨드 로딩 패턴입니다. `list_documents` 도구는 경량 메타데이터만 반환합니다: 문서 ID, 제목, 필요시 바이트 크기와 타임스탬프. 모델은 200페이지의 원시 텍스트가 아닌 선택 옵션의 간결한 테이블을 봅니다.

사용자가 "분기 보고서 분석"과 같은 작업을 선택하면, 에이전트는 `analyze_document`를 호출합니다. 해당 도구는 아티팩트 저장소에서 전체 파일을 가져오고, 청크 처리 또는 요약을 수행한 후, 정제된 결과를 모델에 제공합니다. LLM은 원본 문서를 직접 받지 않으며, 요청한 처리된 조각만 전달받습니다.

도구들은 페이로드를 전송하는 대신 `temp:` 상태를 통해 조정합니다. `list_documents`는 `temp.current_doc_id = "report_q2_2024"`로 기록하고, `analyze_document`는 그 동일한 키를 읽어 어떤 아티팩트를 로드할지 정확히 알고 있습니다. base64 블롭도, 50,000 토큰의 JSON이 도구들 사이를 오가는 일도 없습니다.

해당 `temp:` 범위는 단일 호출에만 존재하여 작업 맥락을 최소화합니다. 일반적인 순서는 사용자 요청, 짧은 시스템 프롬프트, 간결한 문서 목록, 그리고 하나의 `current_doc_id` 문자열을 포함할 수 있지만, 여전히 풍부한 다단계 작업 흐름처럼 느껴집니다. 구글 에이전트 개발 키트(ADK)는 시스템의 모든 프로세스를 처리하여 모델이 추론에 집중할 수 있도록 합니다.

장기적인 행동은 `user:` 상태에 따릅니다. 누군가 “나는 간결한 요약을 선호한다”고 말하면, 도구나 콜백이 `user.summary_style = "brief"`로 설정합니다. 미래의 호출—내일, 다음 주, 다른 기기에서—는 이 키를 읽고 3페이지 분량의 분석 대신 자동으로 3문장 요약을 생성할 수 있습니다.

선호는 프롬프트를 부풀리지 않고 쌓일 수 있습니다. 다음을 추적할 수 있습니다: - `user.domain_focus = "재무"` - `user.citation_format = "APA"` - `user.summary_style = "간결"`

각 호출은 관련된 하위 집합만 작업 컨텍스트로 컴파일합니다. 아무도 사용자가 글머리 기호를 싫어한다는 것을 기억하기 위해 200회 대화 로그를 재생하지 않습니다.

이 에이전트의 지능은 효율적인 도구 사용에서 나오며, 방대한 컨텍스트 윈도우에서 오는 것이 아닙니다. 이 모델은 정밀한 도구 호출을 수행하고, `temp:`와 `user:` 상태를 넘나들며, 필요할 때만 아티팩트에 접근합니다. Google 에이전트 개발 키트(ADK)는 매번 똑똑하게 행동하기 위해 전체 기록을 다시 읽어야 한다는 생각을 효과적으로 무너뜨립니다.

프롬프트 엔지니어링은 한때 영리한 주문과 취약한 해킹을 의미했습니다. 구글의 컨텍스트 블로그와 구글 에이전트 개발 키트(ADK)가 제시하는 것처럼, 컨텍스트 엔지니어링은 그 역할을 언어 모델을 위한 분산 시스템 아키텍처에 더 가까운 것으로 업그레이드합니다.

단일 대형 프롬프트에 집착하는 대신, 개발자들은 이제 파이프라인을 설계합니다: 세션, 상태, 메모리, 그리고 아티팩트가 프로세서를 통해 컴파일된 작업 컨텍스트로 흐르는 방식입니다. ADK의 네 개 층으로 구성된 스택—작업 컨텍스트, 세션 로그, 장기 기억, 외부 아티팩트—은 "프롬프트에 무엇이 들어 있는가?"라는 질문을 "이 뷰를 생성한 시스템은 무엇이며, 이유는 무엇인가?"로 변환합니다.

그 변화는 AI 개발의 명확한 성숙을 나타냅니다. 당신은 다음을 정의합니다: - 어떤 데이터가 어디에 저장되는지 - 어떤 변환이 언제 실행되는지 - 어떤 에이전트나 도구가 어떤 범위를 보는지

결과: 행동이 마법 같던 느낌이 사라지고 디버깅할 수 있는 것으로 변한다.

신뢰성이 향상되는 이유는 모든 맥락 슬라이스에 명확한 레시피가 있기 때문입니다. 에이전트가 환각을 일으킬 경우, 40,000개 토큰의 덩어리가 아닌 그것이 본 모습을 구성한 프로세서와 접두사를 검사합니다. ADK의 상태 접두사(`app`, `user`, `temp`)와 범위 지정된 맥락(도구, 콜백, 호출)은 버그를 재현하고, 테스트를 작성하며, 실패 모드에 대해 추론할 수 있는 지렛대를 제공합니다.

예측 가능성이 향상됩니다. 에이전트는 더 이상 전체 기록을 가져오지 않습니다. 그들은 ID로 아티팩트를 요청하고, 제어된 쿼리로 메모리를 검색하며, 제한된 상태 세그먼트에 기록합니다. 비용도 줄어듭니다. 호출당 최소한의 컴파일된 컨텍스트만 스트리밍하면 되므로, 수주간의 로그를 백만 개의 토큰 창으로 재생할 필요가 없습니다.

생산을 목표로 하는 팀에게 이것은 다중 에이전트 백엔드의 청사진처럼 보입니다. 한 에이전트가 조율하며, 전문 에이전트는 도구와 기억을 소유하고, ADK의 컨텍스트 프레임워크는 각 호출이 충분한 정보만을 갖도록 보장합니다. Google의 문서들, 특히 대화 컨텍스트 소개: 세션, 상태 및 기억은 프롬프트 팁보다는 API 디자인 가이드처럼 읽힙니다.

구글 에이전트 개발 키트(ADK)에서 구현된 컨텍스트 엔지니어링은 LLM 앱을 조정하는 주술이 아닌, 여러분이 설계하는 시스템으로 바꿉니다. 이는 진지하고 규제된 다중 에이전트 배포의 전제 조건입니다.

진짜로 시도할 준비가 되셨나요? Google 에이전트 개발 킷(ADK)를 설치하고, Gemini API 키를 발급받고, Google 개발자 블로그의 Google의 컨텍스트 엔지니어링 설명서를 읽는 것으로 시작하세요: 생산을 위한 효율적인 컨텍스트 인식 다중 에이전트 프레임워크 설계. 그 게시물에서는 네 가지 레이어 스택—작동 컨텍스트, 세션, 메모리, 아티팩트—과 귀하의 코드가 반영해야 하는 세 가지 원칙을 정의하고 있습니다.

다음으로, 공식 ADK 컨텍스트 문서에 직접 가세요: google.github.io/adk-docs/context. `InvocationContext`, `ToolContext`, `CallbackContext`가 세션, 메모리 및 아티팩트에 대한 접근을 어떻게 제어하는지, 그리고 `app:`, `user:`, `temp:` 접두사가 어떻게 구체적인 상태를 구현하는지에 초점을 맞추세요. 이 API를 단순한 헬퍼 클래스가 아니라 시스템 경계로 간주하세요.

그럼 Yeyu Lab의 데모를 GitHub에서 내려받으세요: context_demo. 문서 어시스턴트를 실행하고, 아티팩트가 프로프트에 끼워넣는 대신 ID로 저장되고 참조되는 것을 지켜보세요. 또한 도구들이 데이터를 자유 형식의 텍스트에 숨기지 않고 접두사를 통해 상태를 읽고 쓰는 방식을 추적하세요. 이것이 컨텍스트 인식 다중 에이전트 작업 흐름에 대한 참고 구현입니다.

첫 번째 프로젝트로, 기존의 RAG 앱을 이 패턴에 맞게 리팩토링하세요. "모든 것을 프롬프트에 담기" 논리를 다음으로 교체하세요:

• 1구조화된 이벤트의 세션 로그
• 2PDF, CSV 및 긴 문서용 아티팩트 저장소
• 3같은 사실을 다시 전송하는 대신 메모리 검색 사용
• 4도구 간 중간 결과를 전달하기 위한 `temp:` 상태

이제 당신은 단순히 프롬프트를 조정하는 것이 아니라, 자연어로 대화하는 분산 시스템을 설계하고 있습니다. 상황을 컴파일된 뷰로 내면화하고 상태, 아티팩트 및 명시적 변환을 중심으로 아키텍처를 설계하는 개발자들이 생산 준비가 완료된 AI를 배포할 것이며, 그 외의 모든 사람들은 더 큰 컨텍스트 창을 쫓는 데 그칠 것입니다.

컨텍스트 엔지니어링이란 무엇인가요?

컨텍스트 엔지니어링은 AI 에이전트를 위한 구글의 새로운 아키텍처 패턴입니다. 이는 컨텍스트를 단일 텍스트 스트림으로 취급하지 않고, 세션 기록, 메모리, 외부 파일과 같은 다양한 데이터 소스에서 생성된 '컴파일된 뷰'로 간주하며, 각 특정 모델 호출에 최적화됩니다.

대형 컨텍스트 윈도우가 AI 에이전트에게 문제가 되는 이유는 무엇인가요?

겉보기에는 강력해 보이지만, 큰 컨텍스트 윈도우는 높은 비용과 느린 지연의 악순환으로 이어집니다. 또한 모델이 노이즈 속에서 관련 정보를 찾기 어려워지는 '중간에서의 손실' 문제를 겪어 궁극적으로 확장성과 신뢰성을 제한합니다.

구글의 에이전트 개발 키트(ADK)는 이러한 아이디어를 어떻게 구현하나요?

ADK는 컨텍스트 엔지니어링을 위한 기본적인 구성 요소를 갖춘 프레임워크를 제공합니다. 이는 지속적인 저장소(세션, 메모리, 데이터 조각)를 LLM에 전송되는 임시 '작업 컨텍스트'와 분리하여, 도구와 상태 관리 기능을 사용해 필요한 것만, 필요할 때 로드합니다.

컨텍스트 엔지니어링이 검색 증강 생성(RAG)을 대체하나요?

그것은 보완하고 다듬어 줍니다. RAG는 데이터를 검색하는 것에 관한 것이고, 컨텍스트 엔지니어링은 검색된 데이터(및 모든 다른 컨텍스트)가 어떻게 구조화되고 관리되며 모델에 제시되는지를 다룹니다. 이는 RAG 스타일의 워크플로우를 위한 보다 견고하고 확장 가능한 시스템을 제공합니다.