월요일에 AIE 워크숍 휴식 시간을 갖고 크레페를 먹으러 음식 가판대 쪽으로 나갔습니다. 그때 Fourth Street가 내다보이는 Moscone West 창문 전체를 따라 줄이 길게 늘어서 있는 것을 보았습니다. 수백 명이나 되는 줄이 무엇을 위한 것인지 상상할 수 없었고, 가서 물어보니 Context Engineering 워크숍을 위한 줄이라고 하더군요. 그 일로 인해 저는 탐구하고 이해하며 배우는 과정에 깊이 빠져들게 되었습니다. 그래서 이제 여러분을 위해 제가 알아낸 것들을 공유하고자 합니다.

지난 몇 년 동안 AI 세계는 프롬프트 엔지니어링 (Prompt Engineering), 즉 기계와 대화하는 기술에 집착해 왔습니다. 하지만 개발자들이 단순한 챗봇에서 복잡한 자율 에이전트 (Autonomous Agents)로 이동함에 따라, 새로운 분야가 중심 무대에 등장했습니다. 바로 컨텍스트 엔지니어링 (Context Engineering)입니다.

Major League Hacking (@mlhacks)의 CEO인 Mike Swift (@theycallmeswift)가 저에게 중요한 배경 지식을 제공해 주었습니다. 그는 첫 번째 AI Engineer World's Fair에서 기본적으로 이 용어를 만들어낸 HumanLayer의 Dex Horthy(이번 주 후반에 발표 예정)를 소개해 주었습니다. Swift에 따르면, Dex의 핵심 논지는 "에이전트는 약 100,000 토큰(tokens) 이후부터 성능이 저하된다"는 것이며, 이는 전체 사용 가능한 컨텍스트 윈도우 (Context Window)의 약 10%에 해당합니다.

따라서 컨텍스트 엔지니어링은 본질적으로 AI의 작업 기억 (Working Memory)을 관리하는 것입니다. Swift는 컨텍스트 엔지니어링이 "루프가 몇 번 도느냐에 따라 매번 기억해야 하는 양을 관리하는 것"이라고 언급했습니다. 이는 인간에게는 직관에 어긋나는 개념입니다. 인간은 특정 주제에 대해 더 많이 이야기할수록 공유된 이해가 더 깊어지기 때문입니다. 하지만 모델은 정반대로 작동합니다. 컨텍스트 윈도우 (Context Window)가 채워질수록 모델은 집중력을 잃습니다.

많은 개발자에게 이 작업 메모리 (working memory)를 세심하게 큐레이션하는 것은 실질적인 필수 사항입니다. 저는 MLH의 상주 창립자(founder in residence)이자 DEV의 공동 창립자인 Ben Halpern (@ben)과 이야기를 나누었습니다. 그는 컨텍스트 엔지니어링 (context engineering)이 개발자들이 자신의 전문성을 활용할 수 있는 "최신 최적화 지점의 개척지 (latest frontier of the optimization point)"라고 말했습니다. Ben은 단순히 모델의 일관성을 유지하는 것을 넘어, 제품 작업을 수행하는 개발자들이 "지연 시간 (latency)과 비용 효율성"을 위해 컨텍스트를 관리한다고 지적했습니다.

대화 도중, 저는 제가 발전시켜 온 다소 도발적인 가설을 테스트해 보았습니다. 그것은 컨텍스트 엔지니어링이 통제력을 위한 대리물처럼 느껴지며, 어쩌면 모델이 우리를 앞지르기 전 "통제력을 관리하려는 우리의 마지막 실질적인 시도"일지도 모른다는 생각이었습니다. Ben은 제 생각에 완전히 동의하지는 않았지만, 이 분야에 인간이 영향력을 미칠 수 있는 거대한 기회가 있다는 점에는 동의했습니다. 그는 "모델의 발전 속도는 도구(tooling)의 발전 속도보다 느릴 것이기 때문에", 컨텍스트 엔지니어링을 통해 개발자들이 "모델을 블랙박스 (black box)로 느끼는 기분을 줄일 수 있다"고 언급했습니다. 다음 파운데이션 모델 (foundational model)이 메모리 한계를 마법처럼 해결해주기를 기다리는 대신, 개발자들은 오늘날 워크플로 (workflows)에 능동적으로 가치를 더할 수 있습니다.

다음으로, 저는 Codex의 개발자 경험 (developer experience)을 담당하는 Dominik Kundel과 이야기를 나누었습니다. Dominik은 엄격한 컨텍스트 관리 (context management)가 예를 들어 좁은 범위의 고객 대응 지원 봇에서는 가치가 있지만, 범용 에이전트 (general-purpose agents)에게는 오히려 방해가 된다고 주장했습니다.

개발자들이 컨텍스트 윈도우 (context windows)를 세심하게 제작할 때, Dominik은 "당신이 하고 있는 일은 모델이 해결할 수 있는 가능한 작업의 범위를 축소하고 제한하는 것"이라고 말했습니다. 모델이 보는 것을 필터링하는 대신, Dominik은 점진적 발견 (progressive discovery)을 옹호합니다. 그는 "저는 아무것도 필터링하지 않습니다"라고 말하며, Codex가 Slack, Gmail, Notion과 같은 방대한 비정형 소스 (unstructured sources)에 직접 연결되어 스스로 노이즈 (noise)를 탐색하는 법을 배울 수 있도록 설계되었다고 설명했습니다.

이러한 비구조적 (unstructured) 접근 방식은 그가 "모호한 프롬프팅 (vague prompting)"이라고 부르는 것을 가능하게 합니다. 에이전트가 모든 것에 접근할 수 있기 때문에, 사용자는 에이전트에게 동료처럼 말을 걸며 "어제 Karen이 나에게 물어봤던 그 문제를 해결해줘"라고 요청할 수 있습니다. 그러면 에이전트는 어떤 Karen이 관련이 있는지 독립적으로 파악하고, Slack 스레드를 찾아내어 필요한 컨텍스트 (context)를 가져옵니다. 제가 컨텍스트 엔지니어링 (context engineering)이 인간의 통제를 위한 대리인 (proxy) 역할을 한다는 논제를 제기했을 때, Dominik은 엄격한 관리가 출력값 (outputs)을 확실히 더 예측 가능하게 만든다는 점을 인정했습니다. 하지만 그는 이러한 "결정론 (determinism)은 능력의 축소 (reduction capabilities)와 심각한 유연성 상실을 초래한다"고 경고했습니다.

결국, 어젯밤 Moscone West를 떠나며 분명해진 것은 컨텍스트 엔지니어링 (context engineering)이 결코 모든 상황에 적용되는 단일한 방식 (one-size-fits-all)이 아니라는 점입니다. 개발자가 인간의 흔적 (human thumbprint)을 유지하기 위해 에이전트의 작업 메모리 (working memory)를 강력하게 필터링하기로 선택하든, 혹은 모호한 프롬프팅 (vague prompting)을 실현하기 위해 점진적 발견 (progressive discovery)을 수용하기로 선택하든, AI의 컨텍스트 윈도우 (context window)를 끝없는 쓰레기통 (dumping ground)처럼 취급하던 시대는 확실히 끝났습니다.