Replit Agent가 프로젝트를 잊어버리지 않게 만드는 방법 (2026)

직접 켜기 전까지는 Memory가 꺼져 있습니다

Settings를 열고 Customization을 선택한 다음 Memory 탭으로 이동합니다. 문서에 따르면, 이곳은 "Memory를 옵트인하고, 나중에 끄고, 협업자와 공유할지 여부를 선택하고, Memory file을 보거나 업데이트하는" 곳입니다. 두 가지 기본 설정이 명시되어 있습니다. "기본적으로 Memory는 비공개이며, 협업자 공유는 기본적으로 꺼져 있습니다."

따라서 새로운 Workspace는 설계상 아무것도 기억하지 않습니다. 다른 부분에 문제가 있다고 결론 내리기 전에 먼저 확인해 볼 가치가 있습니다.

세 가지 메모리 범위가 있으며, 서로 겹치지 않습니다

Memory를 켜고 나면, 저장되는 내용은 콘텐츠가 어떤 범위에 속하느냐에 따라 달라집니다. 문서에서는 다음과 같이 구분합니다.

User memory는 "지속적인 workspace 환경 설정 및 작업 스타일"을 캡처하며, "한 명의 빌더와 workspace에 귀속"됩니다.

Project memory는 "컨벤션, 주의 사항(gotchas), 해결책"을 캡처합니다. 이는 "하나의 Project에 유지되며 관련이 있을 때 검색"됩니다.

Custom memory는 "자체 액세스 및 가시성 설정으로 정의하는 컨텍스트"이며, "정의된 액세스 및 가시성 설정을 따릅니다."

이를 라우팅 테이블로 이해하면 많은 부분이 명확해집니다. 한 Project에서 작업하면서 설정한 컨벤션은 다음 프로젝트로 이어지지 않습니다. Project memory는 해당 Project에만 머무르기 때문입니다. 작업 스타일 환경 설정은 한 명의 빌더와 Workspace에 묶여 있습니다. 이 중 하나라도 범용적일 것이라 기대했다면, 지금 겪고 있는 격차는 시스템 오류가 아니라 문서에 명시된 경계 때문입니다.

Memory는 지침이 아니라 컨텍스트를 보관합니다

이 문장이 기능 전체를 재정의합니다. "Memory는 실행 가능한 지침이 아니라 유용한 컨텍스트를 유지합니다."

우선순위 또한 명시되어 있습니다. "사용자의 명시적인 요청과 Custom Instructions가 memory보다 우선합니다."

즉, Memory는 Replit이 참고하는 근거일 뿐, 복종해야 하는 규칙이 아닙니다. 만약 memory에 "항상 리포지토리 패턴을 사용하라", "묻지 않고 새 종속성을 설치하지 마라" 같은 지시 사항을 작성했다면, 규칙을 위한 레이어가 아닌 곳에 규칙을 넣은 것입니다. 문서에서는 memory를 "실행 가능한 지침이 아닌 맥락적 근거"라고 부릅니다. 이러한 지침은 Custom Instructions에 속해야 하며, 이는 "Replit이 해당 Workspace의 Project 및 세션 전반에 걸쳐 사용"하고, 특히 "사용자가 작성하며 Replit은 이를 수정하지 않습니다."

다시 옵트인하지 않으면 공유 Project는 제외됩니다

팀들이 가장 많이 놓치는 기본 설정은 다음과 같습니다. "기본적으로 Replit은 다른 협업자가 편집할 수 있는 Project에서는 사용자의 Memory를 사용하지 않습니다."

이는 합리적인 개인정보 보호 설계(내가 쌓은 컨텍스트가 다른 사람들이 작업하는 공간으로 유출되지 않음)이지만, 동시에 공유 컨텍스트가 가장 필요한 Project가 정작 아무런 컨텍스트도 받지 못하게 된다는 의미이기도 합니다. 문서에 안내된 스위치도 같은 위치에 있습니다. "다른 협업자가 편집할 수 있는 Project에서 Replit이 Memory를 사용하도록 하려면 Settings → Customization → Memory에서 이 기능을 켜세요."

개인 Project는 괜찮은데 팀 Project가 마치 기억상실증에 걸린 것처럼 느껴진다면 거의 확실히 이 설정 때문입니다.

Memory는 일부 카테고리를 의도적으로 제외합니다

오지 않을 기능을 기다리지 않기 위해 알아두어야 할 점이 있습니다. 문서에 따르면, "Memory는 개인 정보를 유지하지 않으며", 특히 "민감한 특성, 제3자 개인 데이터, 자격 증명(credentials) 또는 프로젝트 기밀 사실"은 저장하지 않습니다. Replit은 Memory가 workspace 활동에서 파생되기 때문에 안전하게 처리한다고 설명합니다.

이는 올바른 결정이며, 해당 카테고리에 속하는 모든 정보는 사용자가 직접 제어하는 보관소가 필요하다는 뜻입니다.

Custom Instructions와 Skills는 서로 다른 역할을 하는 별개의 레이어입니다

Replit은 의사결정 테이블을 공개하고 있으며, 이는 모델을 가장 명확하게 설명해 줍니다.

이어지는 가이드는 문자 그대로 받아들일 가치가 있습니다. Custom Instructions는 승인된 라이브러리나 데이터 처리 요구 사항과 같이 "Workspace 전반에 걸쳐 유효해야 하는 규칙"을 위한 것이며, Workspace Settings → Customization에서 관리되고, "당장 진행 중인 작업을 방해하지 않을 만큼" 짧고 "항상 참인 소수의 가이드라인"으로 유지되어야 합니다. Skills는 "특정 종류의 작업에 대한 재사용 가능한 접근 방식"을 위한 것인데, "안정적인 절차적 지식은 Skills에 속하기" 때문입니다. 그리고 MCP는 가이드라인이나 컨텍스트를 제공하기보다는 외부 도구를 연결하기 위한 것입니다.

세 개의 레이어, 세 개의 관리 주체, 세 개의 활성화 조건. "프로젝트를 잊어버렸다"는 보고의 대부분은 엉뚱한 분류 아래에 항목을 잘못 넣었기 때문에 발생합니다.

매 대화 시작 시 프로젝트를 다시 설명하기. 비용이 계속 발생하지만 무기한 작동합니다. 이는 AI에게 컨텍스트를 반복해서 설명하지 않는 방법에서 다룬 루프입니다.

Memory 파일에 규칙 작성하기. 편집이 가능하다는 점을 고려하면 이해할 수 있는 시도입니다. 하지만 Memory는 실행 가능한 지침이 아닌 컨텍스트를 유지하며, 사용자의 명시적인 요청과 Custom Instructions가 어차피 더 높은 우선순위를 가집니다.

모든 것을 Custom Instructions에 넣기. 이는 Workspace 전반에 걸쳐 항상 켜져 있으므로, 문서에서 짧고 구체적으로 유지하라고 조언하는 이유가 바로 이 때문입니다. 긴 지침 블록은 당장 처리해야 할 작업과 경쟁하게 됩니다.

모든 작업을 하나의 Project로 만들기. 원하는 분리성을 희생하는 대가로 공유 Project memory를 얻을 수 있지만, 저장된 컨텍스트가 서로 무관한 빌드들 사이에서 모호하게 뒤섞이게 됩니다.

공유 Project가 사용자의 Memory를 상속받는다고 가정하기. 기본적으로는 상속받지 않습니다. 이는 버그가 아니라 설정의 문제입니다.

리포지토리에 결정 사항 문서를 보관하기. 직관은 맞았으나 그릇이 틀렸습니다. 무언가가 가리키지 않는 한 아무도 그것을 읽지 않습니다. 이는 Replit Agent가 작업 이력을 잊어버리는 이유에서 다룬 일반적인 형태입니다.

15분만 투자해 라우팅을 정리하면 큰 차이를 만들 수 있습니다.

Memory 옵트인하기. Settings → Customization → Memory로 이동합니다. 간 김에 Memory 파일을 검토하고(직접 보고 업데이트할 수 있음), 더 이상 유효하지 않은 내용은 삭제하세요.

협업자 공유 여부를 신중하게 결정하기. 다른 사람이 편집할 수 있는 Project에서 팀이 작업하고 Replit이 거기서 사용자의 Memory를 사용하도록 하려면 공유를 켜세요. 원치 않는다면 꺼두고, 해당 Project는 공유되는 레이어에서 컨텍스트를 가져와야 한다는 점을 받아들이세요.

규칙을 Custom Instructions로 이동하기. 승인된 라이브러리, 보안 요구 사항, 데이터 처리 정책 등 항상 참인 항목들입니다. 사용자가 작성하고 Replit이 수정하지 않으며, Workspace의 Project 및 세션 전반에 걸쳐 적용됩니다. 목록은 작게 유지하세요.

절차를 Skills로 이동하기. 출시 준비, 리뷰 체크리스트 등 반복하는 다단계 작업들입니다. 안정적인 절차적 지식은 여기에 속하며, 작업과 관련이 있을 때 호출됩니다.

Memory가 실제 제 역할을 하도록 두기. 이전 작업에서 파악할 수 있는 환경 설정과 작업 스타일을 알아서 학습하게 하여, 사용자가 이를 반복해서 설명하지 않도록 합니다. 직접 작성하기보다는 감독하는 역할을 하세요.

이것으로 방향과 절차가 정리되었습니다. 하지만 어떤 레이어도 담지 못하는 것은 프로젝트 뒤에 숨겨진 의사결정 배경입니다. 즉, 특이한 선택을 올바른 선택으로 만드는 제약 조건, 2주 차에 시도했다가 실패한 접근 방식, 빌드하는 모든 Project에 걸쳐 적용되는 도메인 지식 등입니다. Custom Instructions는 짧게 유지되어야 합니다. Project memory는 해당 Project에만 머무릅니다. 그리고 Replit이 의도적으로 제외하는 카테고리들은 어차피 다른 보관처가 필요합니다.

이것이 바로 MemoryLake가 존재하는 이유입니다. 단일 Workspace나 단일 Project에 종속되지 않고, 도구들이 읽어갈 수 있는 레이어에 지속적인 지식을 보관하는 것입니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 여러 도구에서 이 하나의 자격 증명을 공유하여 사용합니다.

2단계: 첫 번째 기억 업로드

각각 하나의 주장만 담은 짧은 항목들입니다. 다음과 같은 내용들이 들어갈 만합니다.

제약 조건이 첨부된 결정 사항. "클라이언트 번들이 이미 예산을 초과했으므로 인증은 서버 측에 유지함." 단순한 환경 설정은 이를 담을 수 없지만, 메모리 항목은 가능합니다.

무엇이 왜 고장 났는지. Project memory가 잘 포착하는 주의 사항(gotchas)들을 단 하나의 Project 범위에 국한되지 않는 곳에 한 번만 기록해 둡니다.

여러 Project에 걸쳐 적용되는 지식. 도메인 어휘, 표준, 통합 특이점 등입니다. 설계상 Project memory는 해당 Project에만 머무르므로, 이러한 지식은 특정 프로젝트에 속해서는 안 됩니다.

Memory에 넣을 수 없는 요구 사항. Replit의 Memory가 의도적으로 제외하는 기밀 정보나 자격 증명 관련 제약 조건들은 여전히 에이전트가 읽을 수 있는 어딘가에 보관되어야 합니다.

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

사용하는 도구들을 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw 등을 포함한 MCP 네이티브 에이전트들은 MCP 서버를 가리켜 연결하고, 다른 어시스턴트들은 API를 통해 동일한 메모리를 읽습니다.

세 가지 솔직한 한계가 있습니다. MemoryLake는 Replit의 Memory 파일에 직접 쓰지 않으며, Custom Instructions나 Skills를 대체하지 않습니다. 이들은 Replit 내부에서 에이전트를 조종하는 방법입니다. 또한 사용자가 직접 또는 에이전트가 작성한 내용만 보관하므로 2단계는 수동으로 진행됩니다. 마지막으로, 비밀번호 관리자가 아닙니다. 자격 증명은 어떤 종류의 메모리가 아닌 비밀 저장소(secrets store)에 보관해야 합니다.

새로운 Project가 정보를 갖춘 상태로 시작됩니다. Project memory는 프로젝트 간에 이동하지 않습니다. 하지만 프로젝트 외부에 보관된 지식은 이동하므로, 네 번째 빌드는 세 번째 빌드가 끝난 지점부터 시작할 수 있습니다.

팀 Project가 더 이상 기억상실증에 걸리지 않습니다. 협업자 공유를 켜든 켜지 않든, 외부 레이어에 공유된 지식은 그곳에서 작업하는 모든 사람이 사용할 수 있습니다.

Custom Instructions가 다시 짧아집니다. 실질적인 내용이 다른 곳에 보관되면, 항상 켜져 있는 목록은 프롬프트와 경쟁하는 긴 문서가 아니라 몇 가지 진짜 규칙들로만 구성됩니다.

제외되었던 카테고리들의 보관처가 생깁니다. Memory는 프로젝트 기밀 사실을 의도적으로 건너뜁니다. 이러한 제약 조건들은 여전히 작업에 영향을 미치며, 이제 에이전트가 읽을 수 있는 곳에 기록됩니다.

컨텍스트가 Replit 전용에 국한되지 않습니다. 동일한 논리가 Cursor나 Claude Code에서도 유용하게 사용됩니다. 이는 지속성 메모리의 실제 의미에서 다룬 형태입니다.

가장 먼저 Memory 토글을 확인하세요. 옵트인 방식입니다. 다른 모든 것은 이 설정의 하위에 있습니다.

편의성이 아닌 영속성을 기준으로 라우팅하세요. 항상 참인 내용 → Custom Instructions. 반복 가능한 절차 → Skills. 이전 작업에서 학습한 내용 → Memory.

Memory에 절대 규칙을 작성하지 마세요. Memory는 실행 가능한 지침이 아닌 컨텍스트를 유지하며, 사용자의 명시적인 요청과 Custom Instructions가 어차피 더 높은 우선순위를 가집니다.

Custom Instructions를 짧게 유지하세요. 문서에서는 당장 진행 중인 작업을 방해하지 않도록 여유를 두라고 조언합니다. 항상 참인 소수의 가이드라인을 목표로 하세요.

협업자 공유 여부를 의도적으로 결정하세요. 기본값은 꺼짐입니다. 어떤 방식을 원하는지, 그리고 그 이유가 무엇인지 파악하세요.

주기적으로 Memory 파일을 검토하세요. 보고 편집할 수 있습니다. 오래되어 유효하지 않은 환경 설정은 아예 없는 것보다 나쁩니다.

메모리 근처에 비밀 정보를 절대 두지 마세요. Replit은 자격 증명과 기밀 사실을 의도적으로 제외합니다. 비밀 저장소(secrets store)를 사용하세요.

규칙 옆에 이유를 함께 적으세요. 규칙은 하나의 Project에서만 살아남을 수 있지만, 그 이유는 다음 네 개의 프로젝트까지 살아남습니다. 이는 RAG가 메모리가 아닌 이유에서 다룬 일반적인 핵심입니다.

Replit Agent는 실제로 컨텍스트를 유지합니다. 그렇지 않은 것처럼 보이는 이유는 대개 문서에 명시된 네 가지 사실로 귀결됩니다. 즉, Memory는 옵트인 방식이고, memory는 실행 가능한 지침이 아닌 컨텍스트를 유지하며, 세 가지 메모리 범위는 빌더, Project 또는 자체 가시성 설정으로 제한되고, 공유 Project는 기본적으로 제외된다는 점입니다.

Memory를 켜고, 규칙은 Custom Instructions에 분류하고, 절차는 Skills에 넣고, 협업자 공유 여부를 신중하게 결정하세요. 그런 다음 이 중 어느 레이어에도 맞지 않는 영역(의사결정과 그 제약 조건, 실패했던 경험, 단일 Project보다 오래 지속되는 도메인 지식)을 선택하여 에이전트가 쿼리할 수 있는 곳에 보관하세요. 이것이 바로 다섯 번째 Project를 첫 번째 프로젝트가 끝날 때만큼이나 풍부한 정보를 갖춘 상태로 시작할 수 있게 만드는 비결입니다.