멀티모달 에이전트가 비슷한 화면에서 같은 실수를 반복한다면 실패 경험과 성공 절차를 구분해 검색하는 XSkill 방식이 대안이 될 수 있습니다. XSkill 논문 자료는 짧은 행동 단위의 experience와 작업 전체 절차를 담는 skill을 세션 밖에 분리해 저장합니다. 다만 잘못 정리된 기억도 재사용되므로 저장 품질, 검색 조건, 삭제 통제가 성능의 일부입니다.
멀티모달 에이전트가 같은 실수를 반복한다면? XSkill의 경험, 스킬 메모리
경험은 화면 단위의 실패 복구를 남긴다
Experience는 특정 화면에서 어떤 행동이 실패했고 무엇으로 복구했는지를 기록합니다. 버튼 위치나 오류 메시지처럼 시각적 문맥과 행동 결과가 함께 있어야, 다음에 비슷한 장면을 만났을 때 쓸 수 있습니다. 단순한 대화 요약과 달리 “이 상태에서는 이 클릭이 통하지 않았다”는 국소적인 단서를 보존합니다.
재사용할 때는 현재 화면과 과거 경험의 시각, 문맥 유사도를 비교합니다. 여기서 텍스트만 비슷하고 UI 버전이 다른 기록을 가져오면 오히려 실패를 유도할 수 있습니다. 앱 버전, 화면 상태, 성공 여부 같은 필터가 필요한 이유입니다.
스킬은 여러 경로에서 반복되는 성공 절차를 압축한다
Skill은 한 번의 클릭이 아니라 작업 전체의 재사용 가능한 절차입니다. XSkill은 같은 과제를 여러 경로로 수행한 rollout을 비교하고, 상호 비평을 거쳐 공통된 성공 패턴과 실패 조건을 추립니다. 한 번 우연히 성공한 궤적을 규칙으로 저장하는 위험을 줄이려는 단계입니다.
새 작업에서는 관련 experience와 skill을 함께 검색해 모델 문맥에 넣습니다. VisualToolBench와 Gemini-2.5-Pro를 사용한 원문의 분석에서는 스킬이 구문, 런타임 오류를 줄이고, 실행 경로 수가 늘수록 성능이 나아지는 경향을 보고합니다. 이는 해당 벤치마크와 모델 조합의 결과이며, 새 앱에서 자동으로 이어지는 보장은 아닙니다.
파라미터를 고정해도 비용이 사라지는 것은 아니다
재학습을 피하면 모델 배포를 다시 하지 않아도 되는 장점이 있습니다. 그러나 여러 rollout을 생성하고 비평하며 저장하는 비용, 매 요청에서 기억을 검색해 문맥에 넣는 지연이 생깁니다. 오래된 기록이 쌓이면 검색 후보와 토큰도 늘어납니다.
평가할 때는 성공률과 함께 평균 rollout 수, 검색 시간, 추가 토큰, 잘못된 기억을 가져온 비율을 기록해야 합니다. 파라미터가 변하지 않았다는 말은 학습 비용이 0이라는 뜻이 아니라, 비용의 위치가 메모리 생성과 검색으로 이동했다는 뜻입니다.
운영에서는 기억의 입학과 퇴학 기준이 필요하다
실무에 적용한다면 먼저 반복 작업 하나에서 성공한 실행만 후보로 모으고, 사람이 확인한 뒤 스킬로 승격하는 편이 안전합니다. UI가 바뀌거나 일정 기간 사용되지 않은 기록은 만료시키고, 실패를 유발한 기억은 원인과 함께 격리해야 합니다. 검색 결과 없이 수행한 기준선과 비교해야 실제 이득도 알 수 있습니다.
XSkill은 에이전트가 경험을 축적하는 구조를 보여 주지만, 신뢰할 수 있는 장기 기억을 완성한 것은 아닙니다. 보안 화면을 저장할 수 있는지, 다른 사용자의 기록을 섞어도 되는지, 잘못된 절차를 누가 지울지도 해결해야 합니다. 기억을 많이 남기는 것보다 검증된 기억만 다시 꺼내는 체계가 먼저입니다.
Experience에는 어떤 문맥을 남겨야 할까
스크린샷이나 화면 특징만 저장하면 같은 모양의 다른 상태를 구분하기 어렵습니다. 앱과 버전, 작업 목표, 직전 행동, 관찰된 오류, 성공 여부와 복구 행동을 함께 남기는 편이 좋습니다. 버튼 위치처럼 UI 변경에 취약한 단서와 의미가 오래 유지되는 레이블, 상태를 구분합니다.
민감한 화면을 원본 그대로 저장할 필요가 있는지도 검토합니다. 계정 정보와 문서 내용을 마스킹하고 사용자, 프로젝트별 공간을 분리합니다. 검색 결과에서 원래 실행과 근거로 돌아갈 수 있어야 요약이 틀렸을 때 고칠 수 있습니다.
검색이 틀리는 경우는 어떻게 찾을까
텍스트가 비슷하지만 화면이 다른 경우, 화면은 비슷하지만 목표가 다른 경우, 오래된 UI와 새 UI를 평가 세트에 포함합니다. 현재 요청에 관련 없는 experience가 상위에 나오거나 필요한 skill이 빠진 비율을 측정합니다. 검색된 기억을 넣지 않은 기준선과 비교해 도움이 된 사례와 방해한 사례를 나눕니다.
유사도 임계값이 낮으면 관련 없는 기억이 늘고 높으면 필요한 기억을 놓칠 수 있습니다. 앱, 버전, 사용자, 성공 여부 필터를 먼저 적용하고 의미 검색을 결합할 수 있습니다. 확신이 낮을 때는 억지로 기억을 사용하기보다 현재 상태에서 새로 계획하도록 합니다.
오래된 기억은 어떻게 만료시킬까
UI 버전이 바뀌거나 스킬이 일정 기간 사용되지 않으면 검토 대상으로 표시합니다. 실패를 유발한 기억은 즉시 검색에서 제외하되 원인 분석을 위해 격리 보관할 수 있습니다. 사용 횟수만으로 유효성을 판단하지 말고 최근 성공률과 적용 버전을 함께 봅니다.
새 기억이 기존 절차와 충돌할 때 조용히 둘 다 제공하면 모델이 임의로 선택할 수 있습니다. 우선순위와 대체 관계를 기록하고 승인된 최신 버전만 기본 검색에 노출합니다. 삭제와 복구, 사용자 요청에 따른 전체 기억 초기화가 실제 저장소와 캐시에 함께 반영되는지 시험해야 합니다.
성능 향상은 어떤 기준선과 비교할까
메모리 없음, experience만, skill만, 둘 다 사용한 구성을 같은 작업, 모델, 예산으로 비교합니다. 성공률 외에 평균 행동 수, 잘못된 클릭, rollout 수, 검색 시간과 추가 토큰을 기록합니다. 기억을 읽느라 시간이 늘었지만 실패와 재시도가 줄어 전체 비용이 낮아질 수도 있으므로 끝단 비용을 봅니다.
VisualToolBench의 결과는 연구 출발점이며 새 사내 앱의 보장이 아닙니다. 실제 UI 업데이트와 권한 오류, 비슷한 프로젝트가 섞인 조건을 포함합니다. 평균 향상보다 잘못된 기억 때문에 크게 실패한 꼬리 사례를 우선 검토해야 합니다.
운영 책임은 누구에게 남겨야 할까
사용자는 어떤 경험과 스킬이 저장됐는지 보고 수정, 삭제할 수 있어야 합니다. 자동 생성자는 후보를 만들 수 있지만 승인, 권한과 만료 정책의 책임은 운영 주체가 가져야 합니다. 스킬이 외부 시스템을 바꾸는 경우 실행 전 사람 승인과 결과 검증을 유지합니다.
기억 저장소의 접근 로그, 스킬 사용 이력과 최종 행동을 실행 ID로 연결합니다. 다른 사용자의 성공 절차를 공유할 경우 데이터 권한과 환경 차이를 검토합니다. 지속 학습이라는 표현이 통제 없이 계속 저장하고 실행한다는 뜻이 되지 않게 해야 합니다.
기억 시스템이 사용할 수 없을 때 에이전트가 어떻게 행동할지도 정합니다. 오래된 로컬 캐시를 사실처럼 쓰기보다 메모리 없이 기준 절차로 수행하거나 작업을 보류하고 한계를 표시할 수 있습니다. 저장 실패가 났는데 성공 experience를 남겼다고 보고하지 않도록 쓰기 결과와 후속 검색을 검증합니다.
백업과 복구 시험에서는 특정 시점의 기억, 스킬 버전을 되살린 뒤 동일 요청의 검색 결과를 비교합니다. 원문은 복구되었지만 검색 인덱스나 캐시가 다른 버전을 가리키는 문제도 확인해야 합니다. 장기 기억은 생성 기능뿐 아니라 데이터 운영과 장애 복구까지 포함할 때 신뢰할 수 있습니다.
평가 보고서에는 성공률 평균과 함께 기억을 쓰지 않았을 때보다 더 나빠진 사례를 별도 목록으로 남깁니다. 이 역효과 사례가 어떤 검색 조건과 오래된 스킬에서 나왔는지 추적하면 전체 평균에 가려진 오염 위험을 줄일 수 있습니다.
함께 읽으면 이해가 이어지는 글
- GenericAgent는 30K 컨텍스트로 충분할까: Skill 결정화의 효과와 오염 위험 — GenericAgent가 긴 대화 기록 대신 성공한 작업을 실행 가능한 Skill로 저장하는 구조를 살펴보고, 반복 비용 절감과 스킬 오염, 콜드 스타트, 실행 권한의 교환 조건을 정리합니다.
- 이미지 한 장이 5턴 뒤 답변을 바꿀 수 있을까? VMI 공격이 노리는 기억 — VMI 공격이 처음에는 정상 이미지처럼 보이다가 뒤늦은 주제에서 모델 답변을 바꾸는 원리와 다중 턴 서비스가 점검할 방어 범위를 정리합니다.
- memU는 LLM 기억 비용을 90% 줄일까: Locomo 92%와 거짓 기억 점검 — memU의 3단계 기억 구조와 Locomo 92%, 토큰 비용 최대 90% 절감 주장을 살펴보고, 거짓 기억, 동시성, 운영 비용까지 도입 기준으로 정리합니다.
자주 묻는 질문
XSkill은 모델을 다시 학습하지 않고도 같은 실수를 완전히 없애나요?
아닙니다. 관련 경험을 정확히 검색하고 현재 화면과 버전이 맞아야 하며 잘못된 기억을 가져오면 오히려 같은 오류를 반복할 수 있습니다.
한 번 성공한 실행을 바로 스킬로 저장해도 되나요?
권장하지 않습니다. 우연한 성공과 하드코딩된 경로가 포함될 수 있으므로 여러 실행에서 반복되는 절차와 실패 조건을 확인하고 사람 검토 뒤 승격하는 편이 안전합니다.
XSkill의 비용은 파인튜닝보다 항상 낮나요?
그렇게 단정할 수 없습니다. 여러 rollout과 비평, 저장, 검색, 추가 컨텍스트 비용이 생기므로 성공률과 함께 작업당 호출, 검색 지연, 추가 토큰을 측정해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.