'컨텍스트 엔지니어링' 실전 구현체 공개 — 프롬프트 엔지니어링 이후의 새 패러다임

프롬프트 엔지니어링은 끝났다, 이제는 '컨텍스트 엔지니어링'

작년까지만 해도 LLM을 잘 쓰는 비결은 '프롬프트 엔지니어링'이라는 말로 통했죠. 모델한테 질문하는 문장을 어떻게 다듬느냐가 전부인 것처럼 느껴졌거든요. 그런데 최근 업계 분위기가 슬슬 바뀌고 있어요. 이제는 한 줄의 프롬프트보다 어떤 정보를, 어떤 순서로, 얼마만큼 모델의 컨텍스트 창에 집어넣느냐가 훨씬 중요해졌다는 인식이 퍼지고 있거든요. 이걸 '컨텍스트 엔지니어링(Context Engineering)'이라고 부릅니다.

이번에 outcomeops라는 팀에서 공개한 오픈소스 레포지토리는 바로 이 컨텍스트 엔지니어링을 실전에서 어떻게 구현하는지 보여주는 참고용 구현체(reference implementation)예요. 이론으로만 돌아다니던 개념을 실제 동작하는 코드로 정리해둔 거라, 개인적으로는 꽤 반가운 프로젝트입니다.

컨텍스트 엔지니어링이 뭐냐면

쉽게 비유하자면 이래요. 똑똑한 신입 직원이 새로 왔는데, 이 친구한테 '이 문제 해결해줘'라고만 던지면 당연히 헤매잖아요. 그런데 회사 내부 문서, 관련된 과거 사례, 참고할 코드베이스, 팀의 스타일 가이드를 같이 손에 쥐여주면 꽤 훌륭하게 해냅니다. LLM도 똑같아요. 모델 자체의 성능이 아무리 좋아져도, 결국 모델의 '책상 위'에 올려둘 자료를 누가 어떻게 큐레이션하느냐가 결과물의 질을 좌우하게 된 거죠.

전통적인 RAG(검색 기반 생성)가 '관련 문서 찾아서 붙여넣기' 정도였다면, 컨텍스트 엔지니어링은 한 단계 더 나아갑니다. 어떤 시점에 어떤 도구 결과를 넣을지, 긴 대화 히스토리를 어떻게 압축할지, 중간에 모델이 길을 잃으면 어떻게 다시 궤도로 돌릴지 같은 워크플로우 전체의 설계를 다루거든요.

구현체에서 눈여겨볼 지점

이번 공개된 레퍼런스 구현체는 몇 가지 흥미로운 구조를 보여줍니다. 우선 컨텍스트를 '정적 컨텍스트'와 '동적 컨텍스트'로 나눠서 관리해요. 정적 컨텍스트는 시스템 프롬프트, 페르소나, 팀의 규칙처럼 잘 안 바뀌는 정보고, 동적 컨텍스트는 사용자가 방금 한 말, 방금 실행한 도구의 결과, 최근 파일 변경 내역처럼 매 턴마다 달라지는 정보죠.

그리고 '컨텍스트 예산(context budget)' 개념도 명시적으로 다룹니다. 모델의 컨텍스트 창은 유한하니까, 어떤 조각을 넣으면 어떤 조각을 빼야 하는지 우선순위를 매기는 거예요. 마치 한정된 예산으로 장을 보는 것처럼요. 중요도가 낮은 과거 대화는 요약본으로 압축하고, 지금 작업에 직접 관련된 파일 내용은 원본 그대로 넣는 식이죠.

또 재미있는 건 '실패 복구' 패턴이 포함돼 있다는 점입니다. 에이전트가 잘못된 도구 호출을 했을 때 그 실패 자체를 컨텍스트에 남겨서, 다음 턴에 모델이 '아, 이건 안 되는구나'를 학습하게 만드는 구조예요.

업계 흐름에서의 위치

이런 움직임은 Anthropic의 Claude Code, Cursor, Windsurf 같은 에이전트형 코딩 도구들이 내부에서 이미 쓰고 있던 노하우를 오픈소스 영역으로 끌어내는 시도라고 볼 수 있어요. LangChain이나 LlamaIndex가 RAG 파이프라인을 추상화했다면, 이제는 에이전트의 컨텍스트 수명 주기(context lifecycle) 자체를 추상화하는 라이브러리들이 등장하는 단계입니다.

최근에는 Model Context Protocol(MCP) 같은 표준도 나오면서, 외부 도구가 컨텍스트에 어떻게 정보를 공급할지에 대한 공통 언어가 만들어지고 있어요. 이번 레퍼런스 구현체도 그 흐름과 자연스럽게 맞닿아 있는 느낌이에요.

한국 개발자에게 주는 의미

국내에서도 사내 LLM 에이전트나 AI 코파일럿을 만드는 팀이 빠르게 늘고 있죠. 처음엔 프롬프트 한 줄 잘 쓰면 되던 게, 규모가 커지면 꼭 '모델이 엉뚱한 소리를 한다', '긴 대화에서 맥락을 잃는다' 같은 문제에 부딪히게 되거든요. 이때 필요한 게 바로 컨텍스트 엔지니어링이에요.

당장 이 레포를 그대로 프로덕션에 붙이기보다는, 우리 팀의 에이전트가 컨텍스트를 어떻게 구성하고 있는지 되짚어보는 체크리스트로 활용하는 게 현실적입니다. 특히 사내 문서 기반 봇이나 코드 리뷰 에이전트를 만드시는 분들이라면 한 번쯤 읽어볼 만해요.

마무리

결국 LLM 시대의 소프트웨어 엔지니어링은 '모델에게 세상을 어떻게 보여줄 것인가'라는 질문으로 수렴하는 것 같아요. 여러분은 지금 만드시는 AI 기능에서, 컨텍스트를 어떻게 설계하고 계신가요? 혹시 '프롬프트만 고치면 되겠지' 하다가 벽에 부딪혔던 경험이 있다면 공유해주세요.