1~2년 전만 해도 LLM을 잘 쓰는 기술이라고 하면 다들 '프롬프트 엔지니어링'을 떠올렸어요. '너는 10년 차 시니어 개발자야' 같은 역할 문장을 넣고, 예시를 몇 개 붙이고, 단어 하나하나를 다듬는 식이었죠. 그런데 요즘 에이전트를 만드는 사람들 사이에서는 컨텍스트 엔지니어링(context engineering)이라는 말이 훨씬 자주 들려요. AI 엔지니어링 분야에서 꾸준히 글을 써온 Drew Breunig이 최근 이 분야의 현황을 정리한 글을 냈는데요, 이 기회에 컨텍스트 엔지니어링이 뭔지, 지금 어디까지 왔는지 차근차근 짚어볼게요.
컨텍스트 엔지니어링이 뭐냐면
LLM은 기억이 없어요. 호출할 때마다 우리가 넣어주는 텍스트, 즉 컨텍스트 윈도우 안의 정보만 보고 답을 만들어요. 컨텍스트 엔지니어링은 '모델이 일을 잘하려면 지금 이 순간 무엇을 보고 있어야 하는가'를 설계하는 일이에요. 시스템 프롬프트뿐 아니라 대화 기록, 검색해온 문서, 쓸 수 있는 도구 목록, 이전 도구 실행 결과, 장기 기억까지 전부 여기에 들어가요.
비유하자면 프롬프트 엔지니어링은 '신입에게 지시를 잘 내리는 말솜씨'고, 컨텍스트 엔지니어링은 '신입 책상 위에 어떤 서류를 어떤 순서로 올려둘지 정하는 일'이에요. 말을 아무리 잘해도 책상에 필요 없는 서류가 산더미처럼 쌓여 있으면 일이 안 되거든요. 이 용어는 2025년 중반 Shopify의 토비 뤼트케와 안드레이 카파시가 언급하면서 널리 퍼졌어요.
컨텍스트는 길다고 좋은 게 아니에요
요즘 모델은 수십만에서 백만 토큰까지 받으니까 '그냥 다 넣으면 되잖아?' 싶기 쉬워요. 하지만 현실은 그렇지 않아요. Breunig은 이전 글에서 긴 컨텍스트가 실패하는 방식을 네 가지로 정리했는데, 지금도 자주 인용되는 분류예요.
- 컨텍스트 오염(poisoning): 한 번 들어간 환각이나 잘못된 정보가 계속 참조되면서 에이전트가 엉뚱한 목표를 고집하게 돼요.
- 컨텍스트 산만(distraction): 컨텍스트가 너무 길어지면 모델이 새로 추론하기보다 과거 기록을 되풀이하는 쪽으로 쏠려요.
- 컨텍스트 혼란(confusion): 관련 없는 정보나 도구 설명이 많아서 엉뚱한 도구를 부르게 돼요.
- 컨텍스트 충돌(clash): 서로 모순되는 정보가 함께 들어가서 성능이 떨어져요.
지금 자리 잡은 기법들
필요할 때 불러오기(just-in-time retrieval). 문서를 미리 다 밀어 넣는 대신, 에이전트가 grep이나 파일 읽기 도구로 필요한 부분만 찾아보게 해요. Claude Code 같은 코딩 에이전트가 코드베이스 전체를 임베딩하지 않고 사람처럼 검색하며 탐색하는 게 대표적인 예예요.
점진적 공개(progressive disclosure). Anthropic의 Agent Skills처럼 처음엔 각 기능의 이름과 한 줄 설명만 보여주고, 실제로 필요해질 때 자세한 지침을 읽어오게 해요. 기능이 수십 개로 늘어도 컨텍스트가 넘치지 않아요.
압축과 요약(compaction). 대화가 길어지면 지난 기록을 요약본으로 바꿔 공간을 확보해요. 이때 요약하면서 중요한 디테일이 빠지지 않도록 '무엇을 남길지'를 설계하는 게 관건이에요.
격리(sub-agent). 탐색이나 조사처럼 지저분한 작업은 별도 하위 에이전트에게 맡기고, 메인 에이전트는 정리된 결과 요약만 받아요. 각자 깨끗한 책상에서 일하는 셈이에요.
외부 메모리. CLAUDE.md나 AGENTS.md 같은 파일, 작업 노트, TODO 목록을 파일 시스템에 적어두고 필요할 때 다시 읽어요. 기억을 컨텍스트 윈도우 밖에 두는 방식이에요.
업계 흐름
RAG가 처음 유행하던 때와 비교하면 이해가 쉬워요. 그때는 '검색해서 붙이기'가 거의 유일한 답이었다면, 지금은 검색, 요약, 격리, 도구 선별, 기억 관리를 어떻게 조합할지 고민하는 설계 문제가 됐어요. MCP(Model Context Protocol)로 연결할 수 있는 도구가 폭발적으로 늘면서 '도구 설명만으로 컨텍스트가 꽉 차는' 새로운 문제도 생겼고요. 모델이 똑똑해질수록 프롬프트 문구를 다듬는 효과는 줄어드는데, 어떤 정보를 언제 보여주느냐에 따른 성능 차이는 오히려 커지고 있어요.
한국 개발자에게 주는 시사점
사내 챗봇이나 에이전트를 만들고 있다면 오늘 바로 점검해볼 게 있어요. 시스템 프롬프트에 '혹시 몰라서' 넣어둔 규칙이 몇 줄인지, 연결된 도구가 몇 개인지, 대화가 길어지면 어떻게 정리되는지요. 성능이 기대만큼 안 나올 때 모델을 바꾸기 전에 컨텍스트부터 다이어트해보면 의외로 해결되는 경우가 많아요. 그리고 모델이 실제로 본 컨텍스트를 로그로 남겨서 디버깅할 수 있게 해두는 것도 강력 추천해요. 에이전트 버그는 모델보다 컨텍스트에서 나오는 경우가 꽤 많거든요.
마무리
한 줄 정리: 이제 LLM 앱의 품질은 '무엇을 물어보느냐'보다 '무엇을 보여주느냐'에서 갈려요.
여러분은 에이전트나 RAG를 만들면서 컨텍스트 때문에 겪은 가장 황당한 실패가 뭐였나요? 어떻게 해결하셨는지도 궁금해요.
🔗 출처: Hacker News