AI에게 일을 맡겨본 사람이라면 다 겪어봤을 장면이 있다. 아침에 한참 설명해서 겨우 원하는 결과물을 얻었는데, 오후에 다시 부르면 그 회사가 뭘 하는 곳인지부터 처음처럼 되묻는다. 긴 대화를 이어가다 보면 앞에서 분명히 정해놓은 규칙을 슬그머니 어기기 시작한다. 이럴 때 대부분은 이렇게 결론 낸다. "역시 AI는 아직 멀었네."
그런데 자료를 파보니 원인이 좀 달랐다. 2025년 기업 AI 도입 사례를 분석한 자료에 따르면, 에이전트 실패의 약 65%는 모델이 그 일을 해낼 능력이 없어서가 아니라 컨텍스트 이탈(context drift)이나 기억 손실 때문이었다고 한다. 즉 머리가 나빠서가 아니라, 필요한 정보를 필요한 순간에 제대로 못 받아서 틀린다는 뜻이다. 나는 코딩을 직접 하지 못하는 상태로 AI를 동업자처럼 고용해 1인 회사를 굴리고 있는데, 이 문장이 유독 뼈아프게 와닿았다. 지난 몇 달간 내가 "AI 성능 문제"라고 여겼던 사건들 대부분이 사실은 내 설계 문제였다는 얘기니까.
오늘은 요즘 업계에서 가장 뜨거운 키워드 중 하나인 컨텍스트 엔지니어링(Context Engineering) 이야기를 해보려 한다. 이름은 거창하지만, 코딩 몰라도 오늘 당장 적용할 수 있는 개념이다.
컨텍스트 엔지니어링이란 뭔가 — 프롬프트 엔지니어링의 다음 단계
가트너는 2026년을 아예 "컨텍스트의 해(The Year of Context)"라고 선언했다. 구글 딥마인드의 필 슈미트(Phil Schmid)가 내놓은 정의가 업계에 빠르게 퍼졌는데, 요지는 이렇다. 컨텍스트 엔지니어링은 "적절한 정보와 도구를, 적절한 형식으로, 적절한 시점에 제공하는 동적 시스템을 설계하는 일"이다.
프롬프트 엔지니어링과 뭐가 다를까. 프롬프트 엔지니어링이 "질문을 어떻게 잘 던질까"였다면, 컨텍스트 엔지니어링은 "AI가 그 순간 보고 있는 화면 전체를 어떻게 구성할까"에 가깝다. 시스템 프롬프트, 지금까지의 대화 기록, 참고 문서, 도구가 뱉어낸 결과, 저장된 기억까지 — AI 눈앞에 놓이는 모든 재료를 관리하는 일이다.
비유하자면 이렇다. 프롬프트는 신입 직원에게 던지는 지시 한 마디고, 컨텍스트는 그 직원의 책상 위 상태다. 지시를 아무리 명확하게 해도 책상 위가 3개월치 서류로 뒤덮여 있고 정작 필요한 파일은 그 더미 한가운데 파묻혀 있다면, 결과물이 좋을 리 없다. 대부분의 사람은 지시(프롬프트)만 다듬고 책상(컨텍스트)은 방치한다.
'컨텍스트 로트' — 창을 키운다고 해결되지 않는 이유
여기서 중요한 개념이 하나 나온다. 컨텍스트 로트(context rot), 우리말로 하면 '컨텍스트 부패'쯤 된다. 컨텍스트 창이 채워질수록 모델 성능이 떨어지는 현상인데, 무서운 건 기술적 한계치에 한참 못 미쳐도 벌어진다는 점이다. 요즘 컨텍스트 창은 20만 토큰까지 커졌지만, 실전에 투입된 에이전트 대부분은 13만 토큰에 닿기 전에 이미 무너진다는 분석이 있다.
이유 중 하나는 위치 효과다. 모델은 입력의 맨 앞이나 맨 뒤에 있는 정보는 잘 붙잡지만, 긴 컨텍스트의 한가운데 있는 정보는 눈에 띄게 놓친다. 긴 문맥을 지원한다고 광고하는 모델에서도 이 현상은 그대로 나타난다. 그러니 "창이 커졌으니 그냥 다 때려넣으면 되겠지"는 틀린 전략이다. 오히려 넣을수록 정확도가 떨어지는 구간이 존재한다.
나도 이걸 실전에서 겪었다. 프로젝트 지시 문서를 계속 덧붙여 키웠더니, 어느 순간부터 문서 중간쯤에 적어둔 규칙(예: 캡션 분량 제한)을 에이전트가 반복해서 놓치기 시작했다. 문서를 더 길고 자세하게 쓴 게 오히려 독이 됐던 셈이다.
실제로 효과가 검증된 처방 세 가지
다행히 대응책은 꽤 명확하게 정리돼 있고, 숫자로도 검증되고 있다. 앤트로픽 내부 평가에서는 컨텍스트를 정리해주는 '컨텍스트 편집'만 적용해도 성능이 29% 개선됐고, 여기에 메모리 도구를 함께 쓰면 39%까지 올라갔다고 한다. 코딩 없이도 개념만 빌려 쓸 수 있는 것 세 가지를 뽑아봤다.
첫째, 압축(compaction)을 습관화한다. 대화가 길어지면 지금까지의 맥락을 요약해서 새 창에서 다시 시작하는 방식이다. 실무 권장치는 컨텍스트가 60% 정도 찼을 때 선제적으로 압축하는 것. 꽉 찰 때까지 기다리면 이미 품질은 떨어져 있다. 나는 요즘 긴 작업을 할 때 중간에 "지금까지 확정된 것만 목록으로 정리해줘"를 시키고, 그 요약본을 들고 새 대화로 옮겨간다.
둘째, 지시 문서는 짧고 뾰족하게 유지한다. 실무에서 나온 권장은 에이전트용 지시 파일을 300줄 이내로 유지하고, "이걸 안 적어두면 AI가 틀릴 만한 것"만 담으라는 것이다. 일반적인 상식이나 AI가 알아서 잘하는 내용은 뺀다. 문서를 늘리는 게 아니라 깎는 게 일이다.
셋째, 무거운 조사는 분리해서 요약만 받는다. 이건 서브에이전트 전략이라고 부르는데, 원리가 우아하다. 조사 담당 에이전트가 수만 토큰을 써가며 실컷 파헤치더라도, 본체에게는 1,000~2,000토큰짜리 압축된 요약만 돌려준다. 지저분한 중간 과정은 하위 작업 안에 가둬두고, 본체는 깨끗한 책상에서 판단만 하는 구조다. 코딩 없이 흉내 내려면, 리서치는 별도의 대화창에서 돌리고 결론 요약만 본 작업 대화로 가져오면 된다.
1인 기업에게 이게 왜 특히 중요한가
직원이 있는 회사라면 사람의 기억이 시스템의 백업 역할을 한다. 누군가는 "저번에 그거 이렇게 하기로 했잖아요"라고 말해준다. 혼자 일하는 사람에게는 그 백업이 없다. AI가 어제 정한 규칙을 오늘 까먹으면, 그걸 알아채는 사람도 나 하나고 다시 설명하는 사람도 나 하나다. 그래서 1인 기업일수록 기억을 사람 머리가 아니라 파일로 옮겨두는 설계가 절실하다.
내가 지금 쓰고 있는 방식은 단순하다. 회사의 배경과 규칙은 프로젝트 지시 문서에 고정해두고, 반복 업무는 각각 별도의 작업 지침서(SOP) 파일로 쪼개둔다. 그날 무슨 결정을 했는지는 세컨 브레인에 날짜별로 쌓고, 세션이 끝날 때는 인수인계 문서를 남긴다. 그러면 다음에 어떤 에이전트를 켜든 "우리 회사가 뭘 하는 곳인지"부터 다시 설명할 필요가 없다. 자산이 대화창이 아니라 파일에 남기 때문이다.
역설적이지만, AI를 더 잘 쓰기 위해 필요한 건 더 좋은 AI가 아니라 더 잘 정리된 내 문서였다. 컨텍스트 엔지니어링이라는 말이 어렵게 들려도, 결국 하는 일은 "AI 책상 위를 매일 정리해주는 것"에 가깝다.
마무리
AI가 자꾸 까먹는다고 느껴진다면, 모델을 바꾸기 전에 세 가지만 점검해보자. 지시 문서가 너무 길어지지 않았는가. 대화가 너무 길어질 때까지 방치하고 있지 않은가. 반복해서 설명하는 내용이 어딘가에 파일로 남아 있는가.
에이전트 실패의 65%가 모델 능력이 아니라 컨텍스트 문제라는 말은, 뒤집으면 내가 손댈 수 있는 영역이 그만큼 크다는 뜻이기도 하다. 좋은 소식이라고 생각한다. 모델 성능은 내가 어쩌지 못하지만, 책상 정리는 오늘 당장 할 수 있으니까. 이런 1인 AI 회사 운영의 시행착오를 처음부터 끝까지 기록한 게 「AI 회사를 만들었습니다 -실전편-」입니다.
작성: Art Gourmet