매 메시지 사이에 모델이 당신을 완전히 잊어버린다고 가정해 봅시다. 기억도 없고, 이력도 없으며, 당신이 누구인지 또는 30초 전에 무엇을 하고 있었는지에 대한 개념도 없습니다. 당신이 전송 버튼을 누를 때마다, 모델은 완전한 기억상실증 상태로 깨어나서 당신이 눈앞에 놓아둔 것을 읽고, 답변한 뒤, 다시 죽습니다.

이것은 사고 실험이 아닙니다. 이것이 바로 거대 언어 모델 (Large Language Model, LLM)이 작동하는 방식입니다. 가중치 (Weights)는 고정되어 있습니다. 두 번의 API 호출 사이에서 모델은 아무것도 기억하지 못합니다. 연속성처럼 느껴지는 모든 것(모델이 당신의 코드베이스, 당신의 말투, 당신이 쫓고 있던 버그를 "알고 있는" 것처럼 보이는 것)은 누군가가 조립하여 마치 처음인 것처럼 다시 한번 전달한 텍스트일 뿐입니다.

저는 이 사실을 받아들여 그 결론까지 밀어붙이는 것이 유용하다고 생각합니다. 왜냐하면 그 결론이 이러한 도구들을 다룰 때 제가 무엇을 만들고 있는지에 대한 생각을 조용히 변화시키기 때문입니다.

여기서 도출되는 첫 번째 사실이 있습니다. 만약 모델이 기억상실증에 걸려 있다면, 프롬프트 (Prompt)는 전체 시스템에서 가장 일회성인 산출물입니다. 저는 예전에 프롬프트를 제가 공들여 만드는 대상으로 취급했습니다. 신중한 문구 선택, 역할극, "당신은 전문가입니다"와 같은 서문 같은 것들 말이죠. 하지만 프롬프트는 정확히 단 한 번의 호출을 위해 존재하며 그 후에는 사라집니다. 그것은 종이비행기와 같습니다. 제가 프롬프트 작성 기술에 기대했던 모든 가치는 전송과 동시에 대부분 증발해 버렸습니다.

지속적인 것, 즉 답변이 좋은지 아닌지를 실제로 결정하는 것은 프롬프트 주변에 제가 조립한 컨텍스트 (Context)입니다. 어떤 파일을 가져왔는지, 어떤 과거의 결정을 다시 붙여넣었는지, 어떤 에러 로그, 어떤 스키마 (Schema), 그리고 "제가 왜 이런 이상한 방식으로 하는지"에 대한 세 문장 같은 것들 말입니다. 그 조립 과정이 진짜 작업입니다. 또한 그것은 제가 지시 사항(Instruction) 줄에서 형용사를 만지작거리는 동안 부차적인 것으로 취급해 왔던 부분이기도 합니다.

왜 이러한 재구성이 중요할까요?

왜냐하면 이것이 엔지니어링의 영역을 대부분의 사람들이 바라보는 곳과는 다른 곳으로 이동시키기 때문입니다.

업계는 약 1년 동안 이 문제를 중심으로 움직여 왔습니다. 2025년 중반쯤 "컨텍스트 엔지니어링 (context engineering)"이라는 문구가 "프롬프트 엔지니어링 (prompt engineering)"의 후계자로 등장하기 시작했고, 2026년에 이르러서는 기본 프레임워크가 되었습니다. Anthropic은 에이전트를 위한 컨텍스트 엔지니어링에 관한 글을 통째로 발표했으며, 업계 보고서들은 이 용어로 가득 차 있습니다. 이러한 변화를 요약하자면 다음과 같습니다. 프롬프트 엔지니어링은 '어떻게 질문하느냐'에 관한 것이고, 컨텍스트 엔지니어링은 '질문했을 때 모델이 무엇을 볼 수 있느냐'에 관한 것입니다. 전자가 문장이라면, 후자는 시스템입니다.

저는 이러한 재구성이 옳다고 생각하지만, 벤더(vendor)들의 게시물보다 더 직설적으로 표현하고 싶습니다. 프롬프트는 저렴한 부분입니다. 쓰기 쉽고, 복사하기 쉽고, 버리기도 쉽습니다. 컨텍스트가 곧 제품입니다. 조립하기 어렵고, 최신 상태를 유지하기 어려우며, 아무도 당신으로부터 빼앗아 갈 수 없는 유일한 부분입니다. 왜냐하면 그것은 전적으로 당신만의 특수성, 즉 당신의 코드, 당신의 제약 조건, 당신이 내린 수년간의 작은 결정들로 만들어지기 때문입니다.

그리고 컨텍스트가 제품이 되는 순간, 당신은 대형 윈도우(big-window) 마케팅이 건너뛰는 문제에 정면으로 마주하게 됩니다. 더 많은 컨텍스트는 공짜가 아닙니다. 2026년의 모델들은 백만 토큰 규모의 윈도우를 탑재하여 출시되며, 몇몇은 천만 토큰을 광고하기도 합니다. 하지만 긴 컨텍스트는 그냥 채워 넣고 잊어버려도 되는 서류 보관함이 아닙니다. 제가 읽은 모든 진지한 평가(evaluation)는 동일한 실패 지점에 도달합니다. 긴 컨텍스트 중간에 묻힌 사실들은 유실되며, 동일한 사실이 시작 부분이나 끝에 배치되었을 때와 비교하면 정확도가 약 10~25% 정도 떨어집니다. 윈도우가 커질수록, 무언가를 잃어버릴 수 있는 "중간" 영역도 더 넓어집니다.

따라서 컨텍스트는 "모든 것을 붙여넣는 것"이 아닙니다. 컨텍스트는 관련성 예산(relevance budget) 내에서의 큐레이션(curation)입니다. 그것은 저장 작업이 아니라 편집 작업이며, 바로 이 점 때문에 윈도우가 커진다고 해서 일이 쉬워지지 않는 것입니다. 더 큰 트럭을 가진다고 해서 당신이 더 짐을 잘 싸는 사람이 되는 것은 아닙니다.

이것이 내 노트에 가져온 변화

이 지점에서 나는 이론적인 생각을 멈추고 내 책상을 바라보았습니다. 만약 컨텍스트 (Context)가 제품이라면, 혼자 일하는 나에게 그 제품을 위한 원재료는 내가 적어 내려간 것들의 더미입니다. 이제 내 노트는 더 이상 기억을 돕는 도구가 아닙니다. 그것은 내가 모델에게 전달하는 모든 것들이 끌어다 쓰이는 저장 계층 (Storage layer)입니다. 3월 회의 중에 기록해 둔 반쪽짜리 문장이 6월이 되면, 내가 이미 거절했으나 거절했다는 사실조차 잊어버린 방식을 모델이 다시 제안하지 못하도록 붙여넣는 정확한 문장이 됩니다.

이는 병목 현상 (Bottleneck)이 모델도 아니고, 프롬프트 (Prompt)도 아니라는 것을 의미합니다. 그것은 바로 캡처 (Capture)입니다. 기록하는 데 실패한 생각은 컨텍스트 윈도우 (Context window)가 아무리 커지더라도 결코 존재할 수 없는 컨텍스트가 됩니다. 나는 노트-이메일 앱을 만들기 때문에 이 부분에서 편향되어 있을 수 있지만, 이 편향은 반대의 경우라기보다 문제로부터 비롯되었습니다. 내 컨텍스트의 품질을 높이는 가장 저렴한 지렛대는 바로 그것을 기록하는 과정의 마찰 (Friction)을 줄이는 것입니다. 이제 나의 많은 기록은 음성으로 이루어집니다. 내가 말하면 기기에서 전사 (Transcription)가 이루어지고, 내 손이 여전히 키보드나 운전대를 잡고 있는 동안 그 문장이 기록됩니다. 방법이 중요한 것이 아닙. 핵심은 캡처의 마찰을 낮추는 것이 미래의 모든 프롬프트에 대한 천장을 높여준다는 것이며, 거의 아무도 이를 위해 예산을 할당하지 않는다는 점입니다.

이것이 추상적인 개념이 아니게 된 순간을 저는 기억할 수 있습니다. 4월의 어느 오후, 저는 Cursor의 동일한 제안과 두 시간 동안 씨름했습니다. Cursor는 제가 오직 제 머릿속에만 존재하는 이유로 인해 의도적으로 캐싱하지 않기로 결정한 값을 계속해서 캐싱하라고 제안했습니다. 매번 저는 그 이유를 채팅창에 다시 입력했고, 그 한 번의 턴(turn)에 대해서는 괜찮은 답변을 얻었지만, 탭을 닫으면 그 설명은 다시 사라졌습니다. 저는 프롬프트 엔지니어링 (Prompt Engineering)을 하고 있었고, 유능하게 수행하고 있었지만, 그것은 가치가 없었습니다. 그 어떤 것도 세션(session) 동안 살아남지 못했기 때문입니다. 해결책은 더 날카로운 프롬프트가 아니었습니다. 해결책은 결정 사항과 그 이유라는 하나의 내구성 있는 한 줄을 이미 제가 노트를 작성하고 있는 곳에 적어두는 것이었습니다. 그래야 다음에 같은 질문이 떠올랐을 때 다시 논쟁하는 대신 붙여넣기를 할 수 있기 때문입니다. 제가 허비한 두 시간은 모델의 실패가 아니었습니다. 그것은 컨텍스트 (Context)의 실패였으며, 그 격차는 전적으로 키보드 앞의 제 쪽에 있었습니다.

저에게 있어 제 역할을 다하는 컨텍스트 (Context) 한 줄의 형태는 의도적으로 지루해 보입니다:

2026-03-14 결정 사항: 워치 앱에서 백그라운드 새로고침(background refresh)을 하지 않기로 함.
이유: watchOS가 오래 실행되는 전송을 종료함; 대신 폰을 통해 중계할 것.

이것은 나 자신에게 남기는 메모가 아닙니다. 이것은 바로 붙여넣을 수 있는 컨텍스트 (Context) 단위입니다. 3개월 후 모델이 워치에서 백그라운드 새로고침을 하라고 쾌활하게 제안할 때, 저는 모델과 논쟁하지도 않고 그 이유를 다시 도출하지도 않습니다. 저는 그 한 줄을 붙여넣습니다. 결정 사항과 그 이유는 마치 제가 방금 처음으로 두 가지를 모두 설명한 것처럼, 모델의 건망증 심한 작은 세계 속으로 함께 전달됩니다. 제가 보내는 모든 프롬프트의 버전 관리 로그를 유지하는 이유도 같습니다. 제가 작성한 프롬프트는 일회용이지만, 그것을 작동하게 만든 컨텍스트 (Context)는 기록할 가치가 있기 때문입니다.

제가 믿지 않는 이 이론의 절반

이제 제 자신의 논지에 반론을 제기하는 부분입니다. 왜냐하면 저는 이 이론을 절반만 실행하고 있기 때문입니다.

만약 컨텍스트 (Context)가 진정으로 제품이라면, 논리적인 움직임은 축적하는 것일 겁니다. 모든 것을 포착하고, 모든 것을 저장하며, 공격적으로 검색하여, 매번 모델에게 두툼한 서류 뭉치를 먹이는 것이죠. 저는 그렇게 하지 않으며, 두 가지 이유로 인해 축적이 함정이라고 생각하게 되었습니다. 첫째, '중간 유실 문제 (lost-in-the-middle problem)'는 비대해진 컨텍스트가 능동적으로 해를 끼친다는 것을 의미합니다. 즉, 정보의 양(volume) 속에 신호 (signal)가 파묻혀 버립니다. 둘째, 결코 가지치기 (prune)하지 않는 컨텍스트 저장소는 부패합니다. 제가 지난 3월에 번복했던 작년의 결정은, 그것이 오래된 정보라는 것을 알 방법이 없는 모델을 오도할 준비를 마친 채 여전히 그곳에 놓여 있습니다. 만료된 컨텍스트로 가득 찬 '제2의 뇌 (second brain)'는 작은 뇌보다 더 나쁩니다. 이는 확신에 찬 잘못된 코드 주석이 주석이 아예 없는 것보다 더 나쁜 것과 같은 이치입니다.

따라서 제 입장의 솔직한 버전은 제목의 슬로건보다 더 좁습니다. 컨텍스트가 제품인 것은 맞지만, 그 제품은 축적되는 것이 아니라 편집되는 것입니다. 기술은

저는 1인 개발자입니다. 생각을 잊어버리기 전에 이메일 노트로 변환해 주는 iOS 앱인 Simple Memo를 만들고 있습니다. 저는 이곳에 며칠 간격으로 LLM (Large Language Models)을 활용하는 방법과 혼자서 제품을 출시하는 과정에 대해 글을 씁니다.