에이전트 스킬이 메모리가 아닌 이유 — 그리고 이에 대해 어떻게 대처해야 하는가 (2026)

Agent Plugins 1.0.0이 2026년 8월 6일에 출시되었습니다. Google Developers Blog를 통해 발표된 이 포맷은 Agent Skills와 MCP 서버를 각각 고정된 위치를 가진 이식 가능한 디렉토리 구조로 묶는 패키지 포맷입니다. 참여 기업 목록이 흥미롭습니다. Amazon, Cursor, Microsoft, OpenAI, Vercel이 참여했으며, Google이 Core Maintainer로 합류했습니다. 지원 범위는 이미 Antigravity, Gemini CLI, Claude Code, Cursor를 포함하는 Agents CLI와 Data Agent Kit에 이르며, 호환 클라이언트 목록은 agent-plugins.org에서 관리됩니다.

이 포맷이 해결하고자 하는 문제는 발표문에 명확히 기재되어 있습니다. "플러그인 작성자가 모든 클라이언트에 도달하는 것과 각 클라이언트의 장점을 활용하는 것 사이에서 선택할 필요가 없어야 합니다." 목표는 플러그인의 구성 요소를 "호환되는 모든 클라이언트에서 이식 가능하게 사용할 수 있도록" 하는 것입니다.

그다음에 메모리에 대해 고민하는 모든 이들에게 중요한 문장이 나옵니다. 이 사양서는 스스로의 경계를 다음과 같이 정의합니다. Agent Plugins v1은 "패키지 포맷일 뿐 그 이상도 이하도 아닙니다. 설치 메커니즘, 배포 프로토콜, 권한 모델, 샌드박싱 요구 사항, 신뢰 또는 출처 검증, 사용자 경험을 정의하지 않습니다."

이는 비판이 아닙니다. 명확하고 좁은 범위 덕분에 사양서가 출시될 수 있었기 때문입니다. 하지만 범위 외로 분류된 목록을 읽어보고, 그 목록에조차 없는 것이 무엇인지 주목해 보십시오. 메모리와 지속성 상태(persistent state)는 제외된 것이 아니라, 처음부터 논의 대상조차 아니었습니다. 이 포맷은 기능(capability) 레이어를 표준화하는 것이며, 기능 레이어는 누적된 컨텍스트와는 완전히 다른 것입니다.

연구 결과도 같은 방향을 가리킵니다. SkillOpt: Executive Strategy for Self-Evolving Agent Skills라는 제목의 프리프린트 논문(arXiv 2605.23904, 2026년 5월 22일 제출, 8월 5일 업계 뉴스에 보도됨)은 스킬 문서를 고정된 에이전트를 위한 학습 가능한 외부 상태로 취급합니다. 옵티마이저 모델은 점수가 매겨진 롤아웃을 단일 스킬 파일에 대한 제한된 추가/삭제/대체 편집으로 변환하며, 편집은 보류된 검증 점수를 엄격하게 향상시킬 때만 수락됩니다. 6개의 벤치마크, 7개의 대상 모델, 3개의 실행 하네스(직접 채팅, Codex, Claude Code)에 걸쳐 저자들은 평가된 52개의 모든 (모델, 벤치마크, 하네스) 셀에서 자신들의 방법이 가장 우수하거나 공동 1위를 기록했다고 보고했습니다. 이는 GPT-5.5의 스킬 없는 평균 정확도를 직접 채팅에서 +23.5포인트, Codex 루프 내에서 +24.8포인트, Claude Code 내에서 +19.1포인트 향상시켰습니다.

기억해야 할 핵심은 전이(transfer) 결과입니다. 최적화된 스킬 아티팩트는 추가적인 최적화 없이도 모델 규모를 가로질러, Codex와 Claude Code 실행 환경 간에, 그리고 유사한 수학 벤치마크로 이동할 때도 그 가치를 유지합니다. 한 하네스에서 학습된 절차가 다른 하네스에서도 계속 작동하는 것입니다.

이것이 정설이 되기 전에 두 가지 주의할 점이 있습니다. 이는 피어 리뷰를 거치지 않은 프리프린트 논문입니다. 또한 이 논문은 2026년 5월에 발표된 것으로, 8월은 관련 보도가 확산된 시점이지 연구가 처음 등장한 시점이 아닙니다. 이번 주에 진정으로 새로운 것은 패키징 표준이며, SkillOpt는 표준화되고 있는 대상이 실제로 전이 가능하다는 증거입니다.

하나는 일반적이고, 다른 하나는 당신의 것입니다

스킬은 반복 가능한 절차를 인코딩합니다. 이것이 바로 스킬이 전이되는 이유입니다. "손상된 참조가 있는지 스프레드시트를 감사하는 방법"에서 어떤 스프레드시트인지, 어떤 회사인지, 어떤 분기인지에 의존하는 부분은 전혀 없습니다. 구체적인 내용을 제거하면 배포 가능한 무언가가 남게 되며, 이것이 바로 패키지 포맷이 전제하는 바입니다.

메모리는 구체적인 내용입니다. 계정 과목표, 강제하는 명명 규칙, 실패 시 200을 반환하는 벤더의 API, 지난 3월에 내린 결정과 그 배경 등이 이에 해당합니다. 이러한 정보는 다른 사람에게 유용할 리 없으며, 한 번 작성해서 설치할 수 있는 형태도 아닙니다. 이는 작업 과정에서 캡처되어야 하며, 계속해서 늘어납니다.

하나는 작성되고, 다른 하나는 누적됩니다

스킬은 의도적으로 작성하며 고정되어 있습니다. 검토하고, 버전을 관리하고, 1.1 버전을 출시할 수 있습니다. 이는 작성자가 있는 아티팩트입니다.

메모리에는 작성하는 특정 순간이 없습니다. 작업의 부수 효과로 생성됩니다. 여기서의 수정 사항, 저기서의 결정, 오후 6시에 발견된 제약 조건 등이 그렇습니다. 즉, 실패 모드가 완전히 다릅니다. 스킬은 내용이 틀려서 실패하지만, 메모리는 아예 기록되지 않아서 실패합니다. 패키지 포맷은 두 번째 문제를 해결할 수 없습니다. 아직 패키징할 것이 아무것도 없기 때문입니다.

스킬은 에이전트에게 방법을 알려주고, 메모리만이 이곳의 상황을 알려줍니다

이 지점에서 혼동이 발생하면 큰 비용을 치르게 됩니다. 잘 최적화된 코드 리뷰 스킬을 에이전트에 설치하면 코드를 잘 리뷰할 것입니다. 다만 일반적인 수준에서 말이죠. 에이전트는 누락된 null 체크는 찾아내겠지만, 업스트림의 특이한 동작 때문에 팀에서 어댑터 레이어에 해당 패턴을 의도적으로 허용했다는 사실은 놓칠 것입니다. 절차는 훌륭했지만, 컨텍스트가 없었습니다.

팀들은 이러한 결과를 보고 "스킬을 튜닝해야 한다"고 판단하여 스킬을 반복 수정합니다. 스킬은 문제가 없었습니다. 누락된 것은 이곳에서는 이런 방식으로 처리하며, 그 이유는 다음과 같다라고 말해줄 레이어였습니다. 이것이 바로 문서 검색이 메모리와 같지 않은 이유이기도 합니다. 어댑터 레이어를 언급하는 문서를 찾는 것과 에이전트가 기존의 결정을 인지하고 있는 것은 다릅니다.

이식성은 격차를 좁히는 것이 아니라 더 잘 보이게 만듭니다

약간 직관에 반하는 결과가 여기 있습니다. Claude Code, Cursor, Codex 등 사이에서 스킬을 이동하는 것이 쉬워질수록 실제로 더 자주 이동하게 될 것입니다. 그리고 이동할 때마다 기능 레이어는 온전히 유지되지만 지식 레이어는 제로로 리셋됩니다. 표준은 스택의 절반에서 마찰을 제거합니다. 하지만 표준이 건드리지 않는 나머지 절반은 여러분이 축적하는 데 6개월이 걸린 바로 그 부분입니다.

프로젝트 컨텍스트를 스킬 내부에 넣기. 뻔한 방법이며, 문제가 생기기 전까지는 작동합니다. 하지만 이렇게 하면 스킬을 배포할 수 없고, 프로젝트 간에 버전을 관리할 수 없으며, 결정이 바뀌는 순간 쓸모없어집니다. 또한 패키지 포맷의 본래 목적인 공유도 불가능해집니다.

모든 것을 지침(instructions) 파일에 밀어넣기. AGENTS.md, CLAUDE.md, .cursor/rules 등은 상시 규칙을 두기에 진정으로 적합한 곳이며, Cursor의 자체 문서에서도 타당한 이유로 규칙을 500행 미만으로 유지할 것을 권장합니다. 지침 파일은 모든 작업마다 로드되므로 요청당 비용(tax)이 발생합니다. 이는 규칙을 위한 것이지, 누적된 기록을 위한 것이 아닙니다.

클라이언트당 하나의 거대한 플러그인 만들기. 일부 팀은 컨텍스트가 내장된 도구별 번들을 유지 관리함으로써 이식성 문제를 해결하려고 합니다. 이는 동일한 지식의 복사본 세 개가 서로 어긋나게 만드는 결과를 초래하며, 아무도 이동할 수 없는 단일 복사본을 두는 것보다 더 나쁩니다.

매 세션 시작 시 다시 설명하기. 보편적인 방법이지만 점차 품질이 저하됩니다. 목요일에 입력하는 내용은 월요일에 입력하는 내용보다 짧아집니다. 기억에 의존해 요약하게 되고 예외 사항들을 설명하는 것은 귀찮기 때문입니다.

각 도구의 내장 메모리가 처리하도록 하기. 합리적이며, 기능이 존재한다면 활성화할 가치가 있습니다. 문제는 이러한 저장소가 도구별로, 대개 장치별로 분리되어 있고 내보낼 수 없다는 점입니다. 결국 플러그인 사양서가 해결하고자 했던 바로 그 문제를 한 단계 아래 레이어(아직 표준이 존재하지 않는 곳)에서 그대로 재현하게 됩니다.

의도적으로 레이어를 분리하고 각 레이어에 적합한 저장소를 제공하십시오.

스킬은 플러그인에 들어갑니다. 스킬을 깔끔하고 일반적인 형태로 작성하고, 코드베이스나 클라이언트를 식별할 수 있는 정보를 포함하지 않으며, 버전을 관리하고, 새로운 포맷을 통해 이번 분기에 사용하는 어떤 하네스로든 전송되도록 하십시오. 이것이 바로 플러그인의 용도이며 이제 실제로 작동합니다.

컨텍스트는 단일 도구 외부에 존재하며 모든 도구가 읽을 수 있는 메모리 레이어에 들어갑니다. 더 큰 지침 파일이 아니라, 작업 과정에서 생성된 문서, 결정 사항, 제약 조건을 보관하고 모든 요청마다 로드하는 대신 관련이 있을 때만 검색하는 저장소입니다. MemoryLake는 이러한 분리를 위해 구축되었습니다. 에이전트가 MCP 또는 API를 통해 읽는 단일 저장소이므로, 하네스를 전환할 때 조직의 지식을 처음부터 다시 구축하는 대신 구성 항목만 변경하면 됩니다.

한 가지 분명한 경계가 있습니다. 메모리 레이어가 있다고 해서 에이전트가 읽은 내용을 무조건 따르는 것은 아닙니다. 어텐션(attention)과 지침 준수는 모델의 행동 영역이며, 어떤 저장소 레이어도 규정 준수를 보장하지 않습니다. 메모리 레이어가 바꾸는 것은 모델이 파일 중간 부분을 무시할 정도로 파일이 커지거나 컨텍스트가 아예 누락되는 대신, 중요한 순간에 관련 컨텍스트를 짧고 유용하게 사용할 수 있도록 만드는 것입니다.

Step 1: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 수행해 보세요. 환경 변수나 시크릿 관리자에 보관하십시오. Agent Plugins v1은 권한 모델을 정의하지 않으므로, 번들에 포함시킨 자격 증명을 보호해 주지 않는다는 점에 유의하십시오.

Step 2: 첫 번째 메모리 업로드하기

아키텍처 결정 사항, 이유가 포함된 컨벤션 문서, 클라이언트 브리프, 사후 분석(postmortem) 등 구체적인 내용이 담긴 문서, 이미지, 파일을 업로드하세요. 가능한 한 요약본보다는 원본 소스를 업로드하는 것이 좋습니다. 이것이 바로 공유 가능한 플러그인에 들어갈 수 없는 자료들이며, 독립된 공간이 필요한 이유입니다.

Step 3: AI 및 에이전트 연결하기

Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 하십시오. 플러그인은 이미 고정된 구성 위치를 가진 MCP 서버를 번들로 제공하므로, 메모리 레이어는 스킬이 사용하는 것과 동일한 배선에 끼워 맞출 수 있습니다. 즉, 기능 레이어와 지식 레이어가 서로 다른 저장소로부터 동일한 경로를 통해 도달하게 됩니다.

설치한 스킬이 마치 여러분의 팀이 작성한 것처럼 작동하기 시작합니다. 동일한 일반적인 절차가 컨벤션과 예외 사항을 검색할 수 있는 코드베이스에 적용되므로, 코드 리뷰 스킬이 팀에서 의도적으로 허용한 어댑터 레이어 패턴을 지적하는 일을 멈추게 됩니다.

양방향 모두에서 도구 전환 비용이 저렴해집니다. 포맷 덕분에 스킬이 이동하고, 컨텍스트는 도구 내부에 있었던 적이 없으므로 함께 이동합니다. 에이전트 설정의 두 절반이 동시에 이식 가능해진 것은 이번이 처음이며, 이는 Codex와 Claude Code를 함께 실행할 때 동일한 컨벤션의 복사본 두 개를 유지 관리할 필요가 없어지는 실제적인 이유입니다.

지침 파일이 더 작아집니다. 누적된 기록이 보관될 곳이 생기면, AGENTS.md는 계속 늘어나는 아카이브 대신 상시 규칙의 짧은 목록으로 돌아갑니다. 이는 비용 면에서도 유리하고 준수율 면에서도 더 좋습니다. 500행짜리 규칙 파일은 모델이 일관되게 주의를 기울이지 못하기 때문입니다.

또한 스킬을 공유할 수 있게 됩니다. 현재 대부분의 팀은 컨텍스트가 스킬에 결합되어 있기 때문에 내부 스킬을 공개하지 못합니다. 레이어를 분리하면 구조적으로 스킬을 배포할 수 있게 됩니다.

"경쟁사도 이것을 사용할 수 있는가?" 테스트 적용하기

스킬을 작성한 후, 동종 업계의 다른 회사가 이를 그대로 설치해서 혜택을 볼 수 있는지 자문해 보십시오. 그렇다면 그것은 스킬입니다. 일반적인 형태로 유지하고 패키징하십시오. 그렇지 않다면 스킬의 탈을 쓴 컨텍스트를 작성한 것이므로, 새 버전을 출시하지 않고도 업데이트할 수 있는 메모리 레이어에 두어야 합니다.

지침 파일은 기록이 아닌 규칙을 위해 유지하기

모든 요청마다 로드되는 모든 것은 짧고, 명령조이며, 안정적이어야 합니다. 결정 사항, 이력, 참조 자료는 필요할 때 쿼리하는 저장소에 속해야 합니다. 이 둘을 섞으면 모든 작업에서 비용이 많이 들면서도 정작 필요한 내용은 담겨 있지 않은 파일이 만들어집니다.

스킬은 버전을 관리하고, 메모리는 날짜를 기록하기

스킬은 작성된 아티팩트이므로 시맨틱 버전을 가집니다. 메모리 항목은 결정의 기록이므로 발효일(effective date)을 가집니다. 대체된 결정도 계속 읽을 수 있어야 지난 분기의 작업을 해석할 수 있기 때문입니다. 서로 다른 실패 모드에 대해 서로 다른 저장 방식을 적용해야 합니다.

메모리 표준을 기다리지 마십시오

MCP는 에이전트가 도구에 도달하는 방식을 표준화했고, Agent Plugins는 기능이 패키징되는 방식을 표준화했습니다. 이식 가능한 사용자 메모리에 대한 합의는 존재하지 않으며, 플러그인 사양서 자체의 범위 선언에서도 이를 시도하지 않는다고 명확히 밝히고 있습니다. 모든 클라이언트가 MCP나 API를 통해 읽을 수 있는 저장소를 선택하는 것이 현재 가능한 해답이며, 향후 어떤 표준이 도입되더라도 살아남을 방법입니다.

8월 6일은 진정한 이정표였습니다. 6개 벤더가 스킬과 MCP 서버를 위한 단일 패키지 포맷에 합의한 것은 생태계가 도구별로 파편화되는 것을 막는 계기가 되었습니다. 그리고 사양서 자체의 경계 정의는 발표문에서 가장 유용한 문장입니다. 이는 패키지 포맷일 뿐 그 이상도 이하도 아니며, 즉 여러분의 구체적인 정보를 담는 레이어는 처음부터 범위에 포함되지 않았음을 의미합니다.

따라서 이 두 가지를 별개의 문제로 취급하십시오. 스킬은 깔끔하고 일반적인 형태로 작성하여 표준을 통해 전송되도록 하십시오. 결정, 컨벤션, 이유와 같은 누적된 기록은 에이전트가 읽고 여러분이 편집할 수 있는 저장소에 보관하여, 현재 사용 중인 하네스보다 더 오래 유지되도록 하십시오. 기능 레이어는 이제 이식 가능해졌습니다. 지식 레이어를 이식 가능하게 만드는 것은 여전히 여러분의 몫이며, 이는 구축하는 데 6개월이 걸린 절반의 영역입니다.