AI 에이전트가 일을 이어서 못 하는 이유는 기억 저장소에 있다

핵심 요약

AI 에이전트가 긴 일을 맡으면 가장 먼저 부딪히는 문제는 모델의 지능이 아니라 기억입니다. 어제 조사한 내용을 오늘도 알고 있는가. 지난주에 고친 정책을 새 답변에 반영하는가. 운영팀이 바꾼 금지 표현을 코딩 에이전트와 고객지원 에이전트가 동시에 따르는가. 이 질문에 답하지 못하면 에이전트는 매번 처음 출근한 사람처럼 일합니다.

LangChain이 2026년 5월 13일 공개한 LangSmith Context Hub는 이 문제를 정면으로 다룹니다. 발표 자체는 새 UI 기능에 가깝지만, 의미는 더 큽니다. LangChain은 에이전트 시스템을 모델, 하네스, 컨텍스트로 나누고, 컨텍스트를 코드 저장소 옆에 붙은 부속 파일이 아니라 별도로 저장·리뷰·버전 관리해야 하는 운영 자산으로 봅니다.

쉽게 말하면 Context Hub는 에이전트가 읽는 업무 매뉴얼, 스킬, 정책, 예시, 장기 메모리를 한곳에 모아 버전과 태그를 붙이는 공간입니다. GitHub가 코드의 변경 이력을 관리한다면, Context Hub는 에이전트 행동을 바꾸는 파일의 변경 이력을 관리하려는 시도입니다.

이 글은 개발자와 AI 실무자를 위한 글입니다. LangChain 기능 소개로 끝내지 않고, 왜 에이전트 메모리가 벡터DB 하나로 끝나지 않는지, episodic·semantic·procedural memory를 어떻게 나눠 생각해야 하는지, 한국 팀이 지금 어떤 체크리스트로 도입을 검토하면 좋은지 정리합니다.

이미지 출처: LangChain 공식 블로그, 2026-05-13 공개.

왜 지금 컨텍스트 저장소가 문제인가

초기 챗봇 시대에는 프롬프트 하나가 중요했습니다. 시스템 프롬프트에 말투와 역할을 적고, 사용자 질문에 답하면 됐습니다. 그런데 에이전트는 다릅니다. 에이전트는 파일을 읽고, 툴을 호출하고, 여러 번 실패한 뒤 다시 시도하고, 때로는 다른 에이전트에게 일을 나눕니다. 이 과정에서 필요한 정보가 훨씬 많아집니다.

고객지원 에이전트를 생각해 봅시다. 단순 FAQ 봇이라면 환불 정책 문서를 검색하면 됩니다. 하지만 실제로 고객 메일 초안을 쓰는 에이전트라면 더 많은 것이 필요합니다. 회사의 답변 톤, 법무팀이 금지한 문장, VIP 고객 예외 규칙, 최근 장애 공지, 지난 대화의 맥락, 팀장이 승인한 샘플 답변, 상담원이 남긴 수정 피드백이 모두 행동에 영향을 줍니다.

코딩 에이전트도 같습니다. 레포 구조, 테스트 명령, 금지된 리팩터링 범위, 보안 규칙, PR 설명 형식, 과거 실패 로그, 특정 모듈의 설계 의도, 팀의 코드 리뷰 기준이 있어야 실제 업무를 이어갈 수 있습니다. 이전에 정리한 AI 코딩 맥락 도구 글에서 다룬 코드 지식그래프와 스킬 도구의 흐름도 같은 문제를 겨냥합니다. AI가 답을 몰라서가 아니라, 지금 무엇을 읽어야 하는지 모르기 때문에 실패하는 장면이 많아지고 있습니다.

문제는 이런 자료가 보통 한곳에 있지 않다는 점입니다. 일부는 GitHub에 있고, 일부는 Notion에 있고, 일부는 Slack에 있고, 일부는 누군가의 로컬 파일에 있습니다. 더 나쁜 경우는 시스템 프롬프트가 제품 코드 안에 박혀 있고, 정책 문서는 운영팀이 따로 바꾸며, 실제 에이전트는 예전 버전을 계속 읽는 상황입니다. 이러면 실패 원인을 추적하기 어렵습니다. 모델을 바꿔도, 프롬프트를 고쳐도, 운영 문서가 오래됐는지 확인할 방법이 없습니다.

LangSmith Context Hub가 제안한 구조

LangChain 발표의 핵심은 컨텍스트를 “파일 묶음”으로 관리한다는 점입니다. Context Hub는 AGENTS.md, skills, 정책 문서, 예시, 레퍼런스 파일처럼 에이전트가 행동을 정할 때 읽는 자료를 저장합니다. 그리고 여기에 버전, 태그, 댓글을 붙입니다.

버전 관리는 단순한 편의 기능이 아닙니다. 에이전트가 지난주에는 정확했는데 이번 주부터 이상한 답을 한다면, 모델 업데이트 때문인지 컨텍스트 변경 때문인지 구분해야 합니다. Context Hub 같은 저장소가 있으면 “어떤 컨텍스트 버전으로 실행했는가”를 기록할 수 있습니다. 문제가 생기면 이전 버전으로 되돌리거나, dev, staging, prod 같은 태그로 환경별 컨텍스트를 나눌 수 있습니다.

댓글과 협업 기능도 중요합니다. 에이전트 컨텍스트는 개발자만 쓰지 않습니다. 브랜드 톤은 마케터가, 환불 정책은 운영팀이, 보안 규칙은 보안팀이, 지원 매뉴얼은 고객지원 리드가 더 잘 압니다. 모든 변경을 GitHub PR로만 처리하면 비개발자가 참여하기 어렵습니다. LangChain이 “컨텍스트는 코드와 다른 집이 필요하다”고 말한 이유가 여기에 있습니다.

이미지 출처: LangChain 공식 블로그, 2026-05-13 공개.

메모리는 세 종류로 나눠야 한다

이번 발표에서 가장 중요한 문장은 “에이전트 메모리가 몇 가지 공통 범주로 정리되기 시작했다”는 대목입니다. LangChain은 episodic memory, semantic memory, procedural memory를 구분합니다. 이 구분을 이해하면 왜 벡터DB 하나만으로 메모리 문제를 해결하기 어려운지 보입니다.

Episodic memory는 과거 상호작용의 기억입니다. 고객이 지난번에 어떤 불만을 말했는지, 에이전트가 어제 어떤 조사를 했는지, 특정 작업에서 어떤 실패를 겪었는지 같은 기록입니다. 시간 순서와 사건성이 중요합니다. 단순 검색보다 “언제, 어떤 상황에서, 어떤 결정이 있었는가”가 중요합니다.

Semantic memory는 지식의 기억입니다. 제품 정책, API 문서, 코드 구조, 고객사 정보, 용어 정의처럼 사실과 관계를 저장합니다. 여기서는 벡터 검색, 키워드 검색, 하이브리드 검색이 강합니다. Elastic, MongoDB, Pinecone, Redis가 LangChain과 함께 메모리 표준을 논의하는 이유도 이 계층과 맞닿아 있습니다. 에이전트가 정확한 답을 하려면 적절한 순간에 적절한 지식을 꺼내야 합니다.

Procedural memory는 일하는 방법의 기억입니다. AGENTS.md, skills, 정책, 예시, 스타일 가이드, 승인 절차가 여기에 들어갑니다. “고객 환불 요청을 받으면 먼저 주문 상태를 확인하고, 금액이 10만 원 이상이면 사람 승인을 받아라” 같은 절차입니다. 이 계층은 벡터DB에 넣어 검색만 하면 되는 성격이 아닙니다. 누가 승인했는지, 어떤 버전이 운영 환경에 배포됐는지, 하위 팀이 어떤 변형을 쓰는지 관리해야 합니다.

이 세 종류를 섞으면 운영이 어려워집니다. 과거 대화 로그를 정책처럼 취급하면 오래된 예외가 규칙처럼 굳어질 수 있습니다. 반대로 정책 문서를 단순 대화 기억처럼 취급하면 감사와 롤백이 어렵습니다. 제품 지식을 절차와 섞어 두면 검색은 되지만 실행 기준이 흐려집니다. Context Hub의 의미는 이 중 procedural memory와 장기 컨텍스트 파일을 관리 가능한 자산으로 끌어올린 데 있습니다.

AGENTS.md와 skills가 사실상의 절차 메모리가 되는 중

에이전트 생태계에서 AGENTS.md는 빠르게 공통 언어가 되고 있습니다. AGENTS.md 공식 사이트는 이 파일을 AI 코딩 에이전트를 위한 README라고 설명합니다. 빌드 명령, 테스트 방법, 코드 스타일, 보안 주의사항, PR 규칙처럼 사람이 새 팀원에게 알려줄 내용을 에이전트가 예측 가능한 위치에서 읽게 하는 형식입니다.

Skills도 비슷한 역할을 합니다. 하나의 스킬은 특정 업무를 잘 수행하기 위한 절차, 참고 자료, 예시를 묶습니다. 블로그 작성 스킬, 고객지원 답변 스킬, 디자인 검수 스킬, 보안 리뷰 스킬이 모두 procedural memory입니다. 이 파일들이 늘어나면 문제가 생깁니다. 어떤 스킬이 최신인가. 누가 수정했나. 운영 환경에서는 어떤 버전을 써야 하나. 특정 에이전트만 다른 지침을 써도 되는가.

LangSmith Context Hub는 여기에 답하려는 제품입니다. 로컬 파일을 CLI로 업로드하고, UI에서 직접 편집하고, 태그로 배포 환경을 구분하고, 필요하면 에이전트 실행 환경으로 다시 pull 하는 흐름을 제공합니다. LangChain 블로그의 예시는 다음과 같은 식입니다.

langsmith auth login
langsmith hub init --type skill --dir ./skills/support-style --name support-style
$EDITOR ./skills/support-style/SKILL.md
langsmith hub push support-style --type skill --dir ./skills/support-style --description "Support response style guide"
langsmith hub pull support-style:prod --dir ./context/support-style

이 명령의 의미는 단순합니다. 스킬을 로컬에서 만들고, 중앙 저장소에 올리고, 운영 에이전트가 특정 버전을 다시 내려받는 구조입니다. 지금은 LangSmith 생태계 안의 기능이지만, 방향은 더 넓습니다. 에이전트가 어떤 파일을 읽고 행동했는지 추적할 수 있어야 한다는 요구는 어떤 프레임워크를 쓰든 생깁니다.

벡터DB 회사들이 왜 여기 붙었나

LangChain은 Context Hub 발표에서 Elastic, MongoDB, Pinecone, Redis와 함께 agent memory의 open standard를 개발하고 있다고 밝혔습니다. 이 조합은 흥미롭습니다. Context Hub는 겉으로 보기엔 파일 버전 관리 기능인데, 파트너는 검색과 데이터 계층을 가진 회사들이기 때문입니다.

이유는 에이전트 메모리가 결국 두 세계를 이어야 하기 때문입니다. 하나는 사람이 읽고 리뷰하는 파일 세계입니다. AGENTS.md, SKILL.md, 정책 문서, 예시 답변처럼 텍스트 파일로 관리하기 좋은 자료가 있습니다. 다른 하나는 검색과 retrieval 세계입니다. 수백만 건의 대화 로그, 제품 문서, 고객 데이터, 코드 조각, 이벤트 기록은 인덱스와 쿼리 계층이 필요합니다.

좋은 에이전트 메모리 표준은 둘 중 하나만 고르면 안 됩니다. 사람이 승인한 절차는 파일과 버전으로 남아야 하고, 방대한 지식은 검색 시스템에서 빠르게 꺼내야 합니다. 그리고 에이전트 실행 시점에는 둘이 합쳐져야 합니다. “이 고객에게 어떤 절차를 적용할지”는 procedural memory가 정하고, “이 고객의 최근 주문 상태와 관련 정책”은 semantic·episodic memory에서 가져옵니다.

그래서 표준화의 핵심은 저장소 브랜드가 아닙니다. 인터페이스, 메타데이터, 버전, 태그, retrieval semantics입니다. 어떤 기억이 최신인지, 어떤 환경에 배포됐는지, 어떤 에이전트가 읽을 수 있는지, 검색 결과가 어느 근거에서 왔는지, 정책과 과거 사례가 충돌할 때 무엇이 우선인지 정해야 합니다.

실무 도입 시 먼저 정해야 할 것

Context Hub를 바로 도입하든, 자체 저장소를 만들든, 팀이 먼저 합의해야 할 질문은 비슷합니다.

첫째, 컨텍스트 소유자를 정해야 합니다. 개발자는 하네스와 배포를 관리할 수 있지만, 모든 업무 규칙을 가장 잘 알지는 못합니다. 고객지원 정책은 지원 리드가, 법무 문구는 법무팀이, 브랜드 톤은 마케팅팀이 책임져야 합니다. 컨텍스트 저장소는 비개발자가 수정 요청과 리뷰에 참여할 수 있어야 합니다.

둘째, 환경 태그를 분리해야 합니다. 실험용 지침과 운영 지침이 섞이면 위험합니다. dev, staging, prod 같은 태그를 두고, 운영 에이전트가 어떤 태그만 읽을지 고정해야 합니다. 코딩 에이전트라면 특정 브랜치의 AGENTS.md를 읽는 것도 중요하지만, 고객에게 답장을 보내는 에이전트라면 승인된 prod 정책만 읽어야 합니다.

셋째, 충돌 규칙을 정해야 합니다. 사용자 프롬프트, 시스템 지침, 조직 정책, 프로젝트 AGENTS.md, 스킬, 검색 문서가 서로 다른 말을 할 수 있습니다. “가장 가까운 AGENTS.md가 우선” 같은 규칙은 코딩 환경에서는 유용하지만, 법무·보안 정책은 더 높은 우선순위를 가져야 합니다. 충돌을 모델의 즉흥 판단에 맡기면 감사가 어렵습니다.

넷째, 메모리 쓰기 권한을 제한해야 합니다. LangChain 발표는 에이전트가 직접 컨텍스트를 만들거나 업데이트할 수 있다고 설명합니다. 장기적으로는 필요한 기능입니다. 조사 에이전트가 새 wiki 페이지를 만들고, 운영 에이전트가 반복되는 실패를 기록하는 식입니다. 하지만 운영 환경에서는 아무 기억이나 자동 반영하면 안 됩니다. 에이전트가 쓴 메모리는 초안, 사람 리뷰 후 승인된 메모리는 운영, 오래된 메모리는 폐기 같은 단계가 필요합니다.

다섯째, 평가와 연결해야 합니다. 에이전트 답변이 좋아졌는지 보려면 모델 버전만 기록해서는 부족합니다. 어떤 컨텍스트 버전, 어떤 스킬, 어떤 retrieval 결과, 어떤 정책 태그로 실행했는지 함께 기록해야 합니다. LangSmith가 원래 관찰성과 평가를 강조해 온 플랫폼이라는 점을 보면, Context Hub는 단독 기능이라기보다 관찰성·평가·배포와 묶였을 때 가치가 커집니다.

작은 팀은 어떻게 시작하면 좋나

당장 LangSmith Context Hub를 쓰지 않더라도, 작은 팀은 비슷한 원칙을 로컬에서 시작할 수 있습니다.

첫 단계는 procedural memory를 파일로 분리하는 것입니다. 코딩팀은 AGENTS.md를 만들고, 고객지원팀은 support-style.md, 영업팀은 proposal-rules.md처럼 업무 규칙을 파일화합니다. 중요한 것은 “AI에게 넣을 프롬프트”가 아니라 “팀이 승인한 작업 절차”로 다루는 것입니다.

두 번째 단계는 버전과 변경 사유를 남기는 것입니다. Git을 써도 되고, Notion 변경 이력을 써도 되고, Context Hub 같은 제품을 써도 됩니다. 다만 운영 에이전트가 어떤 버전을 읽는지 기록해야 합니다. “지난주부터 답변 톤이 바뀌었다”는 불만이 나오면 어느 파일의 어느 변경 때문인지 추적할 수 있어야 합니다.

세 번째 단계는 검색 지식과 절차 지식을 분리하는 것입니다. 제품 문서와 FAQ는 검색 인덱스로 넣을 수 있습니다. 하지만 환불 승인 규칙, 보안 금지사항, 고객에게 보내는 문장 톤은 절차 파일로 관리하는 편이 낫습니다. 검색 결과가 정책을 덮어쓰지 않도록 우선순위를 정해야 합니다.

네 번째 단계는 에이전트가 메모리를 쓸 때 리뷰 큐를 두는 것입니다. 예를 들어 리서치 에이전트가 새 자료 요약을 만들면 바로 운영 지식으로 쓰지 말고 “검토 필요” 태그를 붙입니다. 담당자가 근거 링크를 확인하고 승인하면 prod 태그를 붙입니다. 이 흐름이 없으면 장기 기억은 빠르게 오염됩니다.

다섯 번째 단계는 작은 평가 세트를 붙이는 것입니다. 대표 고객 문의 20개, 자주 실패하는 코드 수정 10개, 반복 리서치 질문 10개를 고정해 두고 컨텍스트 변경 전후를 비교합니다. 모델을 바꾸지 않았는데 점수가 좋아졌다면 컨텍스트 개선 효과입니다. 반대로 새 정책을 넣었는데 답변이 나빠졌다면 정책 문장이나 retrieval 우선순위를 다시 봐야 합니다.

주의할 점

첫 번째 주의점은 “표준”이라는 단어를 과대 해석하지 않는 것입니다. LangChain은 open standard를 개발 중이라고 밝혔지만, 2026년 6월 1일 현재 발표문 기준으로 완성된 독립 사양서가 공개된 상태는 아닙니다. 지금은 Context Hub라는 제품 기능과 Elastic, MongoDB, Pinecone, Redis와의 표준화 방향을 함께 공개한 단계로 보는 것이 정확합니다.

두 번째는 벤더 종속입니다. Context Hub를 쓰면 LangSmith 워크플로우 안에서는 편해질 수 있습니다. 그러나 회사가 이미 자체 문서 저장소, 벡터DB, 감사 로그, 권한 관리 체계를 갖고 있다면 바로 옮기는 것이 정답은 아닙니다. 중요한 것은 특정 제품보다 컨텍스트 버전, 태그, 리뷰, 실행 로그를 일관되게 남기는 설계입니다.

세 번째는 개인정보와 권한입니다. 에이전트 메모리는 민감 정보가 모이기 쉽습니다. 고객 대화, 사내 정책, 코드 구조, API 키가 섞이면 유출 위험이 커집니다. 특히 episodic memory에는 실제 사용자 정보가 들어갈 수 있으므로 보관 기간, 삭제 요청, 마스킹, 접근 권한을 설계해야 합니다.

네 번째는 잘못된 기억의 고착입니다. 에이전트가 한 번 잘못 판단한 내용을 장기 메모리로 저장하면 다음 에이전트가 그 오류를 근거로 다시 행동할 수 있습니다. 장기 기억은 많을수록 좋은 것이 아닙니다. 승인된 기억, 폐기된 기억, 임시 기억을 구분해야 합니다.

다섯 번째는 하네스와 컨텍스트의 책임 분리입니다. 에이전트 용어를 정리한 기존 글에서도 다뤘듯이, 하네스는 모델을 실제로 움직이는 실행 장치이고 컨텍스트는 모델이 읽는 지시와 정보입니다. “환불 API를 바로 호출하지 말라”는 정책은 컨텍스트에 있을 수 있지만, 실제 차단은 하네스의 권한 제어로도 구현되어야 합니다. 문서에 적었다고 안전해지는 것은 아닙니다.

관전 포인트

앞으로 볼 지점은 세 가지입니다.

첫째, AGENTS.md와 skills 같은 파일형 절차 메모리가 얼마나 넓게 호환될지입니다. OpenAI Codex, Google Jules, Cursor, Aider, Gemini CLI 등 여러 코딩 에이전트가 AGENTS.md를 읽는 흐름에 합류하고 있습니다. Context Hub가 이런 파일을 중앙에서 관리하려는 시도라면, 다음 경쟁은 “어느 도구가 어떤 컨텍스트 포맷을 읽고 쓸 수 있는가”가 됩니다.

둘째, retrieval 회사들이 메모리 표준에서 어떤 메타데이터를 제안할지입니다. 단순 벡터 검색 API가 아니라, 기억의 종류, 출처, 신뢰도, 만료일, 사용 권한, 환경 태그를 함께 다루는 규격이 필요합니다. 이 부분이 정리되면 에이전트는 특정 벡터DB에 갇히지 않고 메모리 계층을 갈아끼울 수 있습니다.

셋째, 컨텍스트 변경이 평가와 배포 파이프라인에 들어갈지입니다. 앞으로는 모델 업데이트만 릴리스 노트에 남는 것이 아니라, “고객지원 스킬 prod v12 배포”, “법무 정책 v7 롤백”, “코딩 에이전트 AGENTS.md v3 평가 통과” 같은 기록이 중요해질 수 있습니다. 에이전트 운영은 소프트웨어 배포와 문서 운영의 중간 형태로 변하고 있습니다.

결론은 분명합니다. 에이전트의 기억은 벡터DB에 데이터를 많이 넣는 문제가 아닙니다. 어떤 기억을 어떤 형식으로 저장하고, 누가 승인하고, 어떤 버전을 운영에 쓰고, 실패했을 때 어떻게 되돌릴지의 문제입니다. LangSmith Context Hub는 그 질문을 제품 기능으로 꺼내 놓았습니다. 아직 표준 전쟁은 시작 단계지만, 에이전트를 실제 업무에 쓰려는 팀이라면 지금부터 컨텍스트를 코드만큼 진지하게 관리해야 합니다.

출처와 더 읽을거리

• LangChain 공식 블로그: Introducing LangSmith Context Hub: Context Hub의 발표 원문으로, 모델·하네스·컨텍스트 구분, 버전·태그 기능, Elastic·MongoDB·Pinecone·Redis와의 메모리 표준화 방향을 확인할 수 있다.
• LangSmith 공식 문서: LangSmith가 관찰성, 평가, 배포, 플랫폼 설정을 한 워크플로우로 묶는 제품이라는 배경을 확인할 수 있는 공식 문서다.
• AGENTS.md 공식 사이트: AI 코딩 에이전트를 위한 지침 파일 형식이 어떤 문제를 풀고, 어떤 도구 생태계에서 쓰이는지 확인할 수 있는 자료다.
• LangChain deepagents LLM wiki 예제: 에이전트가 조사 결과를 장기 지식 파일로 만들고 다시 질의하는 Context Hub식 메모리 패턴을 코드로 볼 수 있는 예제다.
• LangChain samples: deepagents-with-langsmith: LangSmith와 Deep Agents를 연결해 메모리 기반 에이전트와 이슈 보드를 운영하는 샘플 프로젝트다.
• TestingCatalog AI: LangChain Context Hub 이슈가 2026년 5월 말 AI 뉴스 흐름에서 재노출된 맥락을 확인할 수 있는 보조 자료다.
• AI Insight Hub: 팀장이 알아야 할 AI 에이전트 용어: 하네스, 스캐폴드, 모델, 컨텍스트 같은 용어를 실무 의사결정 관점에서 이어서 볼 수 있는 내부 글이다.
• AI Insight Hub: 내 AI가 코딩을 못하는 이유: 코드 지식그래프와 스킬 도구 흐름을 통해 컨텍스트 부족이 AI 코딩 실패로 이어지는 구조를 설명한 내부 글이다.