Warp의 Cloud Agents가 이전 실행을 기억하도록 만드는 방법 (2026)

새로운 세션은 실패가 아니라 약속입니다

Warp는 이 보장을 레퍼런스와 빠른 시작 가이드에서 각각 한 번씩 명시하고 있으며, 빠른 시작 가이드의 표현은 훨씬 더 명확합니다. "각 실행은 이전 실행의 상태가 이월되지 않는 독립된 새 세션으로 시작되며, 모든 실행은 Oz 웹 앱에서 추적 및 검토할 수 있습니다."

나머지 실행 모델은 이것이 단순히 편리해서가 아니라 왜 바람직한지 설명합니다. "실행은 사람의 개입 없이 자동으로 수행됩니다." 그리고 "예약된 실행이 실패하더라도 향후 실행을 차단하지 않습니다. 각 실행은 독립적입니다." 독립성은 무인 예약 실행을 안전하게 만드는 속성입니다. 지난주의 손상된 상태를 상속받은 실행은 아무도 보지 않는 상태에서 그 오류를 영원히 조용히 전파할 것이기 때문입니다.

따라서 격리는 의도된 설계입니다. 누락된 것은 격리가 아니라 채널입니다. 즉, 한 실행이 결론을 저장하고 다음 실행이 이를 읽을 수 있는 공간입니다.

환경은 재현성을 위한 것이지, 기억을 위한 것이 아닙니다

가장 먼저 살펴보게 되는 곳은 환경이며, 대부분의 팀이 여기서 하루를 허비합니다. Warp의 정의는 단 한 문장으로 이를 배제합니다. "환경은 에이전트가 작업을 어떻게 실행하는지를 설명하는 것이지, 무엇을 하는지를 설명하는 것이 아닙니다."

환경은 Docker 이미지, 에이전트가 복제하는 하나 이상의 리포지토리, 설정 명령, 환경 변수, Agent Secrets를 그룹화합니다. 그 목적은 동일성입니다. "환경은 클라우드 에이전트가 실행될 때마다 동일한 컨테이너, 리포지토리 및 설정을 제공합니다." 그리고 가능성을 닫아버리는 문장이 이어집니다. "이러한 설정들이 결합되어 각 실행을 위한 새로운 작업 공간을 생성합니다."

이것은 빌드 환경에는 정확히 올바른 설계이지만, 메모리(기억)로서는 완전히 잘못된 설계입니다. 매번 동일한 시작점을 갖는 것은 축적된 지식과 정반대입니다. "환경에서 데이터를 명시적으로 유지하지 않는 한"이라는 조항은 유효하지만, 이는 에이전트가 커밋하는 리포지토리, 외부 저장소, 데이터베이스 등 자체적인 영속성 레이어를 직접 연결해야 함을 의미할 뿐, 환경 자체가 스스로 무언가를 기억한다는 뜻이 아닙니다.

Warp는 인접한 슬롯으로 실행별 컨텍스트(per-run context)를 나열하는데, 이는 "Slack 스레드, PR 메타데이터, CI 로그와 같은 작업별 데이터를 제공"합니다. 이는 트리거의 페이로드일 뿐 저장소가 아니며, 해당 컨텍스트를 수신한 실행으로 범위가 제한됩니다.

Handoff는 세 가지 전제 조건 하에 실행을 재개합니다

사람들이 다음으로 발견하는 메커니즘은 Handoff이며, 이는 원래 목적에 아주 충실합니다. Cloud-to-cloud handoff를 사용하면 완료된 실행에 후속 작업을 보낼 수 있으며, Warp는 이와 함께 전달되는 항목을 정확히 명시합니다. "Handoff는 수신 에이전트가 작업을 단순히 읽는 것을 넘어 재개할 수 있을 만큼 충분한 상태를 보존합니다." 후속 작업은 "동일한 대화"로 전달되며, "이전 세션의 리포지토리 변경 사항(추적됨 및 추적되지 않음)은 에이전트가 후속 질문에 답변하기 전에 복원됩니다." 실행 ID, 작업, 생성자, 환경, 예약 트리거, 통합 소스 등의 실행 식별 정보도 모두 보존됩니다.

하지만 이는 특정 실행의 수동 연속일 뿐이며, 실제 적용 시 중요한 세 가지 조건이 있습니다:

실행이 충분히 깔끔하게 종료되어야 합니다. "실행은 성공, 실패 또는 취소와 같은 최종 상태여야 합니다." 그리고 "사용자 입력이나 승인을 기다리는 차단된 실행은 cloud-to-cloud handoff를 통해 계속할 수 없습니다." "에이전트 대화 모델 이전의" 아주 오래된 실행도 계속할 수 없습니다.

스냅샷이 있어야 합니다. 실행은 "각 세션이 끝날 때 작업 공간 스냅샷을 캡처"하며, 스냅샷이 캡처되지 않은 경우(Warp는 일시적인 스토리지 오류를 예로 듭니다) "실행은 계속되지만 복원된 작업 공간 상태 없이 진행됩니다." 경고는 더 단호합니다. "파일에 스냅샷이 없는 오래된 클라우드 실행은 handoff할 수 없으므로 대신 새 실행을 시작해야 합니다."

소유권에 따른 제한도 있습니다. "local-to-cloud handoff에서 시작된 클라우드 실행은 다른 팀원이 아닌 해당 실행을 생성한 사용자만 계속할 수 있습니다." Warp는 또한 handoff가 "최선 노력(best-effort)" 방식임을 언급합니다. 변경 사항을 깔끔하게 적용할 수 없는 경우 에이전트는 실패한 부분을 보고하고 나머지를 계속 진행합니다.

이 중 어느 것도 handoff를 폄하하는 것이 아닙니다. 단지 형태가 다를 뿐입니다. 이는 학습하는 스케줄이 아니라, 인간이 특정 실행을 연장하기로 결정하는 방식입니다.

Warp 자체의 해결책이 존재하며, 현재 리서치 프리뷰 단계입니다

Warp는 누락된 레이어를 구축하고 있으며, 이를 성급하게 배제하거나 성급하게 계획에 반영하지 않도록 현재 상태를 정확히 파악해 둘 가치가 있습니다.

Agent Memory는 "Warp에 상주하며 내장된 Warp Agent, Claude Code, Codex 및 추가될 예정인 다른 에이전트 하네스를 포함하여 지원되는 모든 에이전트 하네스에서 공유되는 영구 메모리 시스템"으로 설명됩니다. 여기에는 백그라운드 작업도 명시적으로 포함됩니다. "로컬 및 클라우드 에이전트 모두 지원 - Warp의 대화형 로컬 에이전트 및 백그라운드 클라우드 에이전트를 지원합니다." 메모리는 자동으로 추출됩니다. "대화가 끝나면 Warp는 지속 가능한 사실, 학습 내용 및 결과를 추출하여 메모리로 기록합니다." 그리고 "새로운 지식은 기존 메모리와 병합되거나 충돌 시 이를 대체합니다." 이는 개인, 에이전트, 팀 저장소로 구성되며, 각 메모리는 "출처를 기록"하고 "메모리에 대한 모든 변경 사항이 기록되므로 팀은 시간이 지남에 따라 메모리가 어떻게 변경되었는지 검사할 수 있습니다." 생성 및 검색은 백그라운드에서 실행되므로 "토큰을 소비하거나 활성 작업에 대기 시간을 추가하지 않습니다."

이는 잘 짜여진 설계이며, 출처(provenance)와 감사 가능성(auditability)은 흔치 않은 기능입니다. 이 두 가지 속성이 왜 중요한지 알아보려면 why memory provenance matters를 참조하세요.

제약 사항은 현재 상태입니다. "Agent Memory는 리서치 프리뷰(research preview) 단계에 있으며 디자인 파트너를 위해 팀별로 활성화됩니다." 액세스를 요청하기 위한 대기자 명단이 있습니다. 서드파티 하네스를 실행하는 경우 주의 깊게 읽어야 할 커버리지 제한도 있습니다. "서드파티 하네스는 클라우드 에이전트로 실행될 때 지원됩니다." 그리고 "(리서치 프리뷰 기간 동안 서드파티 하네스를 로컬에서 실행하는 것은 지원되지 않습니다.)" 프로그래밍 방식의 API 액세스 및 셀프 호스팅은 현재 제공되지 않고 예정 사항으로 나열되어 있습니다.

따라서 정확한 요약은 Warp에 메모리 레이어가 없다는 것이 아닙니다. Warp에는 메모리 레이어가 있고, 정확히 이 문제를 겨냥하고 있으며, 현재로서는 디자인 파트너여야만 사용할 수 있다는 점입니다.

상태를 리포지토리에 커밋하기. 작동하며, 일부 작업에는 이것이 올바른 답입니다. 에이전트가 추가하는 체크인된 원장은 내구성이 있고, 검토 가능하며, diff를 볼 수 있습니다. 하지만 이는 모든 실행이 코드가 아닌 파일에 대해 풀 리퀘스트(PR)를 생성함을 의미하며, 여러 리포지토리에 걸쳐서는 도움이 되지 않습니다.

스케줄을 더 구체적으로 만들기. "이미 처리한 것은 건너뛰기"는 말은 되지만 실행할 수는 없습니다. 새로운 세션에는 이전 세션이 무엇을 처리했는지에 대한 기록이 없기 때문입니다.

수동으로 후속 작업 체이닝하기. 매주 실행을 다음 실행으로 handoff합니다. 이는 작업 공간 상태를 전달하지만, 매 사이클마다 사람의 개입이 필요하므로 예약 실행의 의미가 퇴색되며, 위에서 언급한 스냅샷 및 소유권 조건에 걸리게 됩니다.

환경이 무언가를 유지한다고 가정하기. 위에서 다루었습니다. 환경은 무엇을이 아니라 어떻게로 정의되며, 실행할 때마다 새로운 작업 공간을 빌드합니다.

Warp 클라우드 에이전트에는 메모리가 전혀 없다고 결론 내리기. 실행 모델만 읽었다면 이해할 수 있는 결론이지만, 틀렸습니다. Agent Memory는 설계상 클라우드 에이전트를 지원합니다. 정확한 사실은 현재 리서치 프리뷰 단계이며 디자인 파트너 팀으로 제한되어 있다는 점입니다.

스케줄 끄기. 가장 흔한 결과이며, 가장 많은 노력을 낭비하는 방법입니다.

Warp가 식별한 경계는 정확합니다. 세션 외부에서 상태를 유지하지 않는 한 상태는 실행 경계를 넘어설 수 없습니다. 따라서 세션 외부에 메모리 레이어를 두고, 각 실행이 시작할 때 이를 읽고 끝날 때 기록하도록 하십시오.

MemoryLake가 바로 그 레이어입니다. API를 통해 액세스하는 여러분 소유의 단일 저장소이므로, 실행이 스케줄에 의해 트리거되었든, Slack 멘션에 의해 트리거되었든, 키보드 앞의 사람에 의해 트리거되었든 동일한 지식을 사용할 수 있습니다. 단 세 단계로 가능합니다.

1단계: API 키 생성

로그인하고 워크스페이스 설정에서 API 키를 생성합니다. 이를 이미지에 포함하는 대신 런타임에 주입되도록 Agent Secret으로 저장합니다. 이것이 바로 Warp의 secrets 메커니즘이 존재하는 이유입니다.

2단계: 첫 번째 메모리 업로드

실행이 계속해서 반복해서 도출하는 결론들을 미리 채워 넣으세요. 이슈 분류의 경우: 어떤 이슈가 이미 중복으로 판단되었고 그 이유는 무엇인지, 어떤 보고자에게 특정 후속 질문이 필요한지, 팀이 어떤 라벨을 최종 상태로 취급하는지 등입니다. 종속성 작업의 경우: 이미 시도했다가 포기한 업그레이드와 그 이유입니다. 정리 작업의 경우: 사용되지 않는 것처럼 보이지만 실제로는 사용 중인 파일들입니다. 멀티모달 파일을 포함하여 파일이 있는 그대로 들어가므로, 런북 다이어그램이나 소유권 스프레드시트를 바로 넣을 수 있습니다.

3단계: AI 및 에이전트 연결

실행 중인 다른 도구들과 함께 Warp를 연결합니다. 그런 다음 프롬프트에서 읽기와 쓰기를 명시적으로 지정합니다. 이 작업에 대해 이전 실행이 내린 결론을 확인하는 것으로 시작하고, 향후 실행이 다시 알아낼 필요가 없는 내용을 기록하는 것으로 끝냅니다. 스케줄의 프롬프트는 실행 간에 유지되는 유일한 요소이므로, 이 지침이 지속 가능한 부분이 됩니다.

세 가지 솔직한 한계가 있습니다. 이것이 Warp의 격리 모델을 바꾸지는 않습니다. 모든 실행은 여전히 새로운 세션으로 시작되며, 이는 좋은 일입니다. 또한 작업 공간 상태를 복원하지는 않습니다. 리포지토리 변경 사항은 handoff의 역할이며, MemoryLake는 diff가 아닌 지식을 보유합니다. 그리고 이것은 환경을 대체하지 않습니다. 이미지, 리포지토리 및 설정 명령은 그대로 유지됩니다.

첫 번째 변화는 예약된 에이전트가 스스로를 반복하는 일을 멈춘다는 것입니다. 두 번째 실행은 첫 번째 실행이 내린 결론을 읽고, 전체 영역 대신 변경된 부분(delta)에 대해서만 작업을 수행합니다.

두 번째 변화는 실행 기록이 단순히 제공되는 것을 넘어 유용해진다는 점입니다. Warp는 모든 것을 보관합니다. "스케줄을 삭제하면 즉시 향후 모든 실행이 중단됩니다. 이전 실행 및 해당 세션 기록은 검사 및 검토를 위해 계속 액세스할 수 있습니다." 그리고 "변경 사항은 향후 실행에만 적용됩니다. 과거 실행 및 해당 세션 기록은 변경되지 않은 상태로 유지됩니다." 이는 훌륭한 감사 추적(audit trail)이지만, 다음 실행을 대신해 이를 읽는 주체가 없기 때문에 검색 메커니즘으로서는 부족합니다. 메모리 레이어는 대화 기록 아카이브를 에이전트가 참조할 수 있는 자료로 전환하는 역할을 합니다.

세 번째 변화는 둘 이상의 에이전트를 실행할 때 나타납니다. Warp 자체 설계에서도 공유 에이전트에 연결된 팀 저장소를 통해 이를 지향하고 있으며, 동일한 논리가 외부 레이어에도 적용됩니다. 하나의 저장소를 함께 읽는 분류 에이전트와 검토 에이전트는 서로 모순되는 행동을 하지 않게 됩니다. 이는 shared memory for multi-agent systems에서 설명하는 일반적인 사례입니다.

1년 동안 사람의 개입 없이 실행될 것처럼 프롬프트를 작성하세요. 프롬프트는 모든 실행에서 살아남는 유일한 요소이므로, 가장 먼저 무엇을 읽어야 하는지, 보고할 가치가 있는지 판단하는 방법, 그리고 언제 중단해야 하는지를 명시해야 합니다.

지식과 작업 공간 상태를 분리하여 유지하세요. 리포지토리 변경 사항은 handoff의 영역입니다. 결론, 결정 및 제외 사항은 저장소에 속합니다. 이들을 혼합하면 아무도 검토할 수 없는 원장이 만들어집니다.

저장소가 형태 없이 무작정 커지게 두지 마세요. "지속 가능한 사실, 학습 내용 및 결과"를 추출하는 Warp의 모델은 모방하기 좋은 필터입니다. 대화 기록 전체가 아니라 결정 사항과 그 이유를 기록하세요. How much memory to give an agent에서 메모리 한계가 어디에 위치하는지 더 자세히 다룹니다.

출처를 기록하세요. Warp는 에이전트가 각 저장소의 목적을 알 수 있도록 모든 첨부 파일에 대해 저장소별 지침을 요구합니다. "에이전트가 각 저장소의 목적을 알 수 있도록 모든 첨부 파일에 지침이 필요합니다." 외부에서도 동일한 원칙을 적용하세요. 어떤 실행이 결론을 도출했는지 기록하여, 잘못된 결론을 추적하고 제거할 수 있도록 하십시오.

실행 식별자(identity)를 신중하게 선택하세요. Warp의 기본값은 스케줄 생성자의 권한으로 실행되는 반면, 클라우드 에이전트 식별자는 앱으로 인증합니다. 이 결정은 에이전트의 풀 리퀘스트를 누가 검토할 수 있는지에 영향을 미치며, 메모리와는 별개이지만 동시에 실수하기 쉬운 부분입니다.

규모를 확장하기 전에 스케줄의 영향 범위(blast radius)를 모니터링하세요. 실행 비용은 팀의 공유 크레딧 잔액에서 청구되며 개입 없이 실행됩니다. 메모리 레이어는 검사해야 할 범위를 좁혀 각 실행 비용을 낮춰주는데, 이는 측정해 볼 만한 부가적인 이점입니다.

여러분의 스택에 적합하다면 Agent Memory 대기자 명단에 등록하세요. 팀이 자격을 갖추었다면 네이티브 크로스 하네스 저장소를 갖추는 것은 좋은 일입니다. 다만 이번 분기 계획을 리서치 프리뷰 단계의 기능에 의존하여 세우지는 마십시오.

Warp는 처음에 규칙을 명확히 밝혔습니다. 모든 실행은 새로운 세션으로 시작되며, 세션 외부에서 상태를 유지하지 않는 한 어떤 것도 경계를 넘어설 수 없습니다. 이는 무인 자동화에 올바른 설계이며, 단 하나의 공백을 남깁니다. 즉, 한 실행이 다음 실행을 위해 결론을 남겨둘 수 있는 공간입니다.

Warp는 클라우드 에이전트를 지원하고 디자인 파트너 팀을 대상으로 리서치 프리뷰 단계에 있는 Agent Memory로 이 공백을 메우고 있습니다. 이것이 정식 출시되기 전까지는 Warp 자체 문장에서 설명하는 것과 동일한 메커니즘을 사용해야 합니다. 즉, 각 실행이 시작할 때 읽고 끝날 때 기록하는 외부 저장소입니다. 새로운 세션과 축적된 지식. 이 두 가지는 지식이 세션 내부에 상주할 때만 서로 충돌합니다.