MemoryLake
모든 글로 돌아가기
Tutorial2026년 9월 3일·11 분 소요

Devin의 Cascade 전용 메모리를 스킬로 이동하는 방법 (2026)

Devin Desktop을 한동안 사용해 오셨다면, 한 번도 열어보지 않은 자동 생성된 메모리가 수없이 쌓여 있을 것입니다. Cascade는 대화 중에 이를 작성하고, 관련이 있을 때 검색하여 사용하며, 비용은 전혀 들지 않습니다. 공식 문서에서도 "자동 생성된 메모리를 생성하고 사용하는 것은 크레딧을 소비하지 않습니다"라고 명시하고 있습니다.

하지만 여기서 꼭 알아두어야 할 점이 있습니다. 대부분의 새로운 작업에서는 이 메모리들이 전혀 작동하지 않는다는 사실입니다.

"메모리는 레거시 Cascade 에이전트에만 적용됩니다. 새 탭의 기본 에이전트인 Devin Local 에이전트는 메모리를 유지하지 않습니다. 자주 사용하는 메모리는 Devin: Open Cascade Migration Wizard 명령을 사용하여 스킬로 마이그레이션하세요."

이 문장을 순서대로 읽어보세요. 메모리는 Cascade의 기능입니다. 새 탭의 기본 에이전트는 Cascade가 아닙니다. 그리고 여러분이 의존하는 정보를 여전히 적용 가능한 곳으로 옮겨주는 공식 마법사 도구가 존재합니다.

오해를 방지하기 위해 명확히 하자면, Devin Desktop에는 영구적인 컨텍스트가 충분히 존재합니다. 규칙(Rules), AGENTS.md, 워크플로우(Workflows), 스킬(Skills)은 모두 영구적으로 유지되며, 문서화된 네 가지 활성화 모드를 제공합니다. 여기서 다루는 구체적인 문제는 자동 생성된 메모리 레이어가 특정 에이전트에 종속되어 있으며, 새 탭을 열 때 실행되는 에이전트는 더 이상 그 에이전트가 아니라는 점입니다.

시작하기 전에 한 가지 선을 긋고자 합니다. 이 글은 문서화된 명령어를 사용하는 마이그레이션 작업에 관한 것이며, 대화 중에 Cascade가 맥락을 놓치는 현상을 진단하는 글이 아닙니다. 그 문제는 다른 원인에 기인하며, why Devin loses task context에서 다루고 있습니다. 아래의 모든 내용은 이미 존재하는 지식을 재배치하는 방법에 관한 것입니다.

메모리가 에이전트에 도달하지 못하는 이유

기능의 이면에서 기본 에이전트가 변경되었습니다

위에서 인용한 문장은 두 가지 사실을 동시에 말해줍니다. 메모리의 범위를 "레거시 Cascade 에이전트 전용"으로 제한하는 것과, 현재 실제로 사용 중인 에이전트가 무엇인지 알려주는 것입니다: "새 탭의 기본 에이전트인 Devin Local 에이전트"

무언가 고장 난 것은 아닙니다. 더 새로운 에이전트가 기본값이 되었고, 이전의 영구 저장 메커니즘 중 하나가 함께 이전되지 않았을 뿐입니다. 하지만 그동안 쌓아온 컨텍스트가 계속 자신을 따라다닐 것이라고 생각했던 사용자들에게 실질적인 영향은 분명합니다. 새 탭을 열면 그 컨텍스트는 존재하지 않습니다.

개발사에서도 이미 메모리에 의존하지 말 것을 권장하고 있습니다

이는 문서와 실제 사용법이 충돌하는 경우가 아닙니다. 에이전트 관련 문제가 제기되기 전부터 작성된 Devin의 자체 가이드에서는 지속적인 지식을 어디에 두어야 하는지 명시하고 있습니다:

"권장 사항: Cascade가 안정적으로 재사용하기를 원하는 지식은 자동 생성된 메모리에 의존하기보다, 규칙(Rule)으로 작성하거나 리포지토리의 AGENTS.md에 추가하세요. 규칙은 버전 관리가 가능하고, 팀과 공유할 수 있으며, 활성화를 명시적으로 제어할 수 있습니다."

그리고 기능 비교 표에서는 메모리의 용도를 다음과 같이 명확하게 규정하고 있습니다: "일회성 사실은 Cascade가 기억하도록 두고, 지속적인 지식은 규칙이나 AGENTS.md를 선호하세요."

So the migration wizard is not a workaround for a regression. It is tooling that helps you do what the docs recommended anyway.

서로 다른 트리거를 가진 네 가지 영구 저장 메커니즘

"그냥 규칙으로 옮기세요"라는 한 마디로 끝낼 수 없는 이유는, Devin Desktop이 네 가지 개념을 구분하고 있으며 올바른 대상지는 여러분이 가진 정보의 종류에 따라 달라지기 때문입니다.

Rules는 "Cascade의 작동 방식(예: 'npm 대신 bun 사용')을 지시"하며, always_on, glob, model_decision, manual 중 하나에 의해 활성화됩니다. "코딩 컨벤션, 스타일 가이드, 프로젝트 제약 조건"에 가장 적합합니다.

AGENTS.md는 설정 없이 "위치 범위가 지정된 규칙"을 제공하며, 자동으로 활성화됩니다: "루트 = always-on, 하위 디렉토리 = glob." 프론트매터가 없는 "디렉토리별 특정 컨벤션"에 가장 적합합니다.

Workflows는 "반복 가능한 다단계 작업을 위한 프롬프트 템플릿"으로, "/[workflow-name] 슬래시 명령어를 통한 수동 활성화만 가능"합니다. "배포, PR 리뷰, 릴리스 체크리스트"에 가장 적합합니다.

Skills는 "지원 파일(스크립트, 템플릿)과 함께 번들로 제공되는 다단계 절차"로, "모델에 의해 동적으로 호출되거나 @멘션"됩니다. 문서에서는 이를 특별히 강조합니다: "Cascade에 참조 파일이 필요한 복잡한 작업 — 여기에 투자하세요."

이 마지막 문장은 마법사가 왜 규칙이 아닌 스킬을 구체적인 대상으로 삼는지 설명해 줍니다.

활성화 모드에 따른 문서화된 컨텍스트 비용

많은 콘텐츠를 규칙으로 옮기려고 한다면, Devin이 각 모드의 비용을 공개하고 있으므로 이 표를 가장 먼저 읽어보아야 합니다.

always_on은 "전체 규칙 콘텐츠를 매 메시지마다 시스템 프롬프트에 포함"하므로, 비용은 "모든 메시지"에 발생합니다. model_decision은 "설명만 시스템 프롬프트에 표시하고, Cascade가 설명이 관련이 있다고 판단할 때 전체 규칙 파일을 읽습니다." 즉, 비용은 "설명은 항상, 전체 콘텐츠는 요청 시에만" 발생합니다. glob은 "Cascade가 glob 패턴과 일치하는 파일을 읽거나 편집할 때" 적용되며, 비용은 "일치하는 파일을 터치할 때만" 발생합니다. manual은 "시스템 프롬프트에 포함되지 않으며" @rule-name을 입력할 때 활성화됩니다.

기억해야 할 두 가지 예외: "글로벌 규칙 파일(global_rules.md)과 루트 수준의 AGENTS.md 파일은 프론트매터를 사용하지 않으며, 항상 켜져 있습니다(always on)."

엄격한 글자 수 제한이 존재합니다

마이그레이션 도중 사람들이 자주 부딪히는 제약 조건은 다음과 같습니다:

"워크스페이스 규칙 파일은 각각 최대 12,000자로 제한됩니다. 글로벌 규칙 파일은 최대 6,000자로 제한됩니다."

글로벌 규칙은 ~/.codeium/windsurf/memories/global_rules.md에 단일 파일로 존재하며, "모든 워크스페이스에 적용"되고 항상 켜져 있으며 6,000자로 제한됩니다. 워크스페이스 규칙은 "규칙당 하나의 파일로 각자의 활성화 모드를 가집니다." 파일당 12,000자로 제한되며, .devin/rules/*.md(권장) 또는 .windsurf/rules/*.md(대체)에 위치합니다. 워크스페이스 루트에 있는 레거시 단일 파일인 .windsurfrules도 여전히 읽힙니다.

따라서 글로벌 파일은 가장 적은 용량을 제공하지만 대부분의 사람들이 가장 먼저 선택하는 곳입니다. 여기에 1년 치 메모리를 한꺼번에 쏟아붓는 것은 불가능합니다.

사람들이 시도하는 잘못된 방법들

메모리가 새 에이전트에도 적용될 것이라 가정하는 것. 가장 흔한 오해이자 이 글이 존재하는 이유입니다. 메모리는 레거시 Cascade 에이전트에만 적용됩니다.

Devin에 영구적인 컨텍스트가 없다고 결론 내리는 것. 반대 방향으로 잘못된 생각입니다. 규칙, AGENTS.md, 워크플로우, 스킬은 모두 유지되며, 자동 생성된 메모리보다 훨씬 명시적인 활성화 제어를 제공합니다.

모든 내용을 global_rules.md에 붙여넣는 것. 이해는 갑니다. 파일 하나만 관리하면 되고, 항상 켜져 있으며, 배울 프론트매터도 없으니까요. 하지만 이 파일은 6,000자로 제한되어 있으며 모든 워크스페이스의 모든 메시지에서 비용을 지불해야 합니다.

모든 규칙을 always_on으로 설정하는 것. 안전하게 느껴지지만 컨텍스트 창을 조용히 갉아먹는 선택입니다. model_decision은 긴 규칙을 저렴하게 설명하고 필요할 때만 읽을 수 있도록 하기 위해 존재합니다.

메모리를 하나씩 수동으로 마이그레이션하는 것. 불필요합니다. 이를 위한 명령어인 Devin: Open Cascade Migration Wizard가 있습니다.

규칙을 서류 캐비닛처럼 취급하는 것. Devin의 모범 사례에서는 이에 대해 직접적으로 경고합니다: "규칙은 간단하고 간결하며 구체적으로 유지하세요. 너무 길거나 모호한 규칙은 Cascade를 혼란스럽게 할 수 있습니다." 또한 "일반적인 규칙(예: '좋은 코드 작성하기')은 추가할 필요가 없습니다." 프로젝트의 사실 정보는 행동 지침이 아니며, 이를 규칙에 넣으면 규칙 디렉토리가 제대로 작동하지 않게 됩니다. 이는 스타일이 어딘가에 적혀 있음에도 불구하고 why Devin forgets your coding style 현상이 발생하는 원인이기도 합니다.

해결책: 메모리를 분류하고 각각에 맞는 위치로 보내기

1단계: 메모리에 실제로 무엇이 들어있는지 확인하기

마법사를 실행하기 전에 현재 가지고 있는 정보를 살펴보세요. 메모리는 "대화 중에 Cascade가 자동으로 생성하는 컨텍스트"이므로 다양한 내용이 섞여 있을 것입니다. 바로 이 혼합된 특성 때문에 단 하나의 목적지로만 보내는 것은 잘못된 방법입니다.

읽으면서 발견한 내용을 다음 네 가지 범주로 분류해 보세요.

행동 지침(Behavior). "npm 대신 bun 사용", "조기 반환(early return) 선호". 이들은 규칙(Rules)이 되며, 활성화 모드는 단순한 형식이 아닌 실제 신중한 결정이 필요합니다.

위치 특정 컨벤션(Location-specific conventions). 특정 디렉토리 내부에서만 유효한 모든 규칙입니다. 이들은 AGENTS.md 파일이 되며, 프론트매터 없이도 glob 동작을 적용받을 수 있습니다.

지원 파일이 포함된 절차(Procedures with supporting files). 스크립트나 템플릿이 필요한 다단계 작업입니다. 이들은 스킬(Skills)이 되며, 문서에서 투자를 권장하는 영역입니다.

사실 정보(Facts). API 경로에 버전이 지정된 이유, 내부 도메인 용어의 의미, 어떤 서비스가 어떤 큐를 소유하는지 등입니다. 이들은 네 가지 메커니즘 중 어느 것에도 깔끔하게 들어맞지 않으며, 이에 대해서는 뒤에서 다시 다루겠습니다.

2단계: 마법사를 실행한 후 활성화 모드에 따라 나머지 배치하기

명령 팔레트를 열고 Devin: Open Cascade Migration Wizard를 실행합니다. 이는 신뢰할 수 있는 메모리를 마이그레이션하기 위해 문서화된 경로이며, 참조 파일과 함께 번들로 제공되는 절차를 위해 구축된 메커니즘인 스킬을 대상으로 합니다.

마법사가 다루지 않는 다른 모든 정보는 의도적으로 배치해야 합니다:

모든 곳에 적용되어야 하는 행동 지침은 ~/.codeium/windsurf/memories/global_rules.md에 넣습니다. 이때 6,000자 제한이 있으며 프론트매터 없이 항상 켜져 있다는 점을 기억하세요.

프로젝트 범위의 행동 지침은 .devin/rules/*.md에 넣습니다. 이곳은 .windsurf/보다 "우선순위를 갖는" 권장 위치입니다. 프론트매터에서 각 규칙에 trigger를 부여하세요. 파일 형식 규칙에는 패턴과 함께 glob을 사용하고, 전체 파일을 읽는 것보다 설명 비용만 지불하는 것이 나을 정도로 긴 규칙에는 model_decision을 사용하며, 진정으로 모든 메시지에 적용되는 짧은 목록에만 always_on을 남겨두세요.

디렉토리 컨벤션은 해당 디렉토리의 AGENTS.md에 넣습니다. 루트 수준은 항상 켜져 있고(always-on), 하위 디렉토리는 "해당 디렉토리에 대한 자동 glob"으로 작동합니다.

디버깅 시간을 줄여줄 두 가지 발견 사항이 있습니다. Devin은 "상위 디렉토리의 규칙을 찾기 위해 git 루트 디렉토리까지 검색"하며, 여러 폴더가 열려 있을 때 "규칙은 중복 제거되어 가장 짧은 상대 경로로 표시"됩니다. 하지만 규칙을 생성할 때 규칙은 "git 루트가 아닌 현재 워크스페이스의 .devin/rules 디렉토리에 저장"되므로 어디에 저장되었는지 확인해야 합니다.

작업하는 동안 포맷 가이드를 따르세요. Devin은 긴 단락 대신 "글머리 기호, 번호 매기기 목록, 마크다운"을 사용할 것을 요청하며, "XML 태그는 유사한 규칙을 전달하고 그룹화하는 효과적인 방법이 될 수 있다"고 언급합니다.

3단계: 네 번째 범주의 정보가 머무를 곳 마련하기

이제 네 가지 범주 중 세 가지는 적합한 보금자리를 찾았습니다. 하지만 네 번째 범주는 그렇지 않으며, 그렇지 않은 척 방치하는 것이 규칙 디렉토리를 망가뜨리는 원인이 됩니다.

프로젝트에 대한 사실 정보는 지침이 아닙니다. 이들에게는 자연스러운 활성화 모드가 없습니다. always_on은 가끔 필요한 정보에 과도한 비용을 지불하게 만들고, glob은 사실 정보에는 없는 파일 패턴을 요구하며, manual은 규칙이 존재한다는 사실을 알고 직접 @멘션해야 하고, model_decision은 그나마 가깝지만 사실 자체보다는 사실에 대한 설명을 작성해야 합니다. 한편, 글로벌 파일은 6,000자, 워크스페이스 규칙은 12,000자의 제한이 있으며, 이 소중한 용량을 배경 지식에 낭비해서는 안 됩니다.

메모리 레이어는 활성화 모드 없이도 이러한 정보를 보관할 수 있습니다. 에이전트는 패턴이 일치할 때가 아니라 해당 주제가 언급될 때 이를 읽기 때문입니다. MemoryLake는 단 세 단계로 설정할 수 있습니다.

1단계: API 키 생성하기

로그인한 후 대시보드에서 API 키를 생성합니다. 이 키는 특정 에이전트에 종속되지 않으므로, 이 글의 발단이 된 문제(Cascade에만 종속되고 Local 에이전트에는 적용되지 않는 문제)가 발생하지 않습니다.

절차도 규칙도 아닌 Devin 메모리를 위해 MemoryLake API 키 생성하기
절차도 규칙도 아닌 Devin 메모리를 위해 MemoryLake API 키 생성하기

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

네 번째 범주의 정보를 입력하세요: 아키텍처 결정 사항과 그 배경 이유, 도메인 어휘, 서비스 소유권, 임시방편(workaround)이 존재하는 이유, 한 번 이상 지시했던 수정 사항 등입니다.

Cascade 메모리에서 복구한 사실 정보를 MemoryLake에 업로드하기
Cascade 메모리에서 복구한 사실 정보를 MemoryLake에 업로드하기

행동 지침은 규칙에, 절차는 스킬에 그대로 두세요. 이러한 메커니즘은 각자의 역할에 최적화되어 있으며 문서화된 활성화 의미론을 가지고 있습니다. 이 단계는 그러한 특성이 없는 자료들을 위한 것입니다.

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

Devin Desktop이 이 저장소를 가리키도록 설정하세요. 글자 수 제한은 행동 지침에 온전히 사용되고, 항상 켜져 있는 규칙 세트는 준수하기 쉬울 정도로 짧게 유지되며, 이전 메모리를 가치 있게 만들었던 지식들은 더 이상 탭이 어떤 에이전트로 열리는지에 의존하지 않게 됩니다. 이에 대한 자세한 내용은 turning project docs into AI memory에서 다루고 있습니다.

네 번째 범주의 정보가 머무를 수 있도록 MCP를 통해 Devin Desktop을 MemoryLake에 연결하기
네 번째 범주의 정보가 머무를 수 있도록 MCP를 통해 Devin Desktop을 MemoryLake에 연결하기

실제 사용 시 변화하는 점

첫 번째 변화는 에이전트 선택이 지식 활용 여부를 결정하는 요인이 되지 않는다는 점입니다. 현재는 자동 생성된 레이어가 적용되는지 여부가 탭이 Cascade인지 Local인지에 따라 달라집니다. 지식은 탭에 종속되어서는 안 됩니다.

두 번째는 글자 수 제한이 더 이상 설계상의 제약 조건이 되지 않는다는 점입니다. 글로벌 6,000자 및 워크스페이스 규칙당 12,000자는 행동 지침만 담기에는 충분하지만, 행동 지침에 사실 정보까지 더하기에는 턱없이 부족합니다. 그리고 사실 정보는 애초에 그곳에 있을 필요가 없습니다.

세 번째는 버전 관리의 이점이 마침내 모든 정보에 적용된다는 점입니다. 메모리보다 규칙을 권장하는 Devin의 제안은 규칙이 "버전 관리가 가능하고, 팀과 공유할 수 있으며, 활성화를 명시적으로 제어할 수 있다"는 점에 기반합니다. 이는 매우 올바른 특성이며, 배경 사실 정보 역시 이러한 혜택을 누려야 합니다. 이는 keeping team AI context when someone leaves에서 다루는 핵심 고민이기도 합니다.

Devin Desktop 규칙 및 스킬에 대한 모범 사례

  • 수동으로 마이그레이션하기보다 마법사를 실행하세요. Devin: Open Cascade Migration Wizard가 문서화된 경로입니다.
  • 각 메모리를 적절한 메커니즘에 매칭하세요. 행동 지침은 규칙(Rules)으로, 디렉토리 컨벤션은 AGENTS.md로, 파일이 포함된 절차는 스킬(Skills)로 보냅니다.
  • trigger를 신중하게 선택하세요. 문서에는 각 모드의 컨텍스트 비용이 공개되어 있습니다. always_on이 가장 비용이 많이 드는 모드입니다.
  • 글자 수 제한을 준수하세요. 워크스페이스 규칙 파일당 12,000자, 글로벌 파일은 6,000자입니다.
  • .windsurf/보다 .devin/을 선호하세요. 이곳이 권장 위치이며 우선순위를 가집니다. 레거시 .windsurfrules도 여전히 읽힙니다.
  • 새 규칙이 어디에 저장되었는지 확인하세요. 규칙은 git 루트가 아닌 현재 워크스페이스의 .devin/rules에 저장됩니다.
  • 규칙은 짧고 구체적으로 유지하세요. 길거나 모호한 규칙은 "Cascade를 혼란스럽게 할 수 있으며", 일반적인 조언은 이미 모델 자체에 내장되어 있습니다.
  • 시스템 규칙은 덮어쓰는 것이 아니라 추가된다는 점을 알아두세요. 엔터프라이즈 시스템 수준 규칙은 "사용자 정의 규칙을 재정의하지 않고 워크스페이스 및 글로벌 규칙과 병합"되며, 사용자가 삭제할 수 없는 "System" 레이블이 표시됩니다.

결론

지금 바로 실행해야 할 구체적인 조치는 작고 명확합니다. 자동 생성된 메모리는 레거시 Cascade 에이전트에만 적용되고, 새 탭의 기본 에이전트는 이를 유지하지 않으며, 자주 사용하는 정보를 스킬로 이동할 수 있는 공식 마법사가 존재합니다. 지금 실행하세요.

더 큰 핵심은 Devin의 자체 문서가 지적하는 바와 같습니다. 자동 생성된 메모리는 일회성 사실을 기억하는 데는 좋지만, 안정적으로 필요한 지식을 구축하기에는 취약한 기반입니다. 가지고 있는 정보를 분류하고, 행동 지침과 절차를 적절한 활성화 모드와 함께 제자리에 배치하며, 배경 사실 정보는 특정 에이전트에 종속되지 않는 레이어에 보관하세요.

자주 묻는 질문

내 Devin 메모리는 여전히 작동하나요?

레거시 Cascade 에이전트에서는 작동합니다. "메모리는 레거시 Cascade 에이전트에만 적용됩니다. 새 탭의 기본 에이전트인 Devin Local 에이전트는 메모리를 유지하지 않습니다." 따라서 기본 에이전트로 열린 새 탭은 이 메모리를 활용하지 않습니다.

어떻게 이동하나요?

명령 팔레트에서 Devin: Open Cascade Migration Wizard를 실행하세요. 문서에서는 이를 스킬로 보낼 것을 안내하고 있으며, 스킬은 "지원 파일(스크립트, 템플릿)과 함께 번들로 제공되는 다단계 절차"로 설명되며 집중적으로 투자해야 할 영역으로 강조됩니다.

대신 메모리를 규칙으로 변환해야 하나요?

행동 지침에 해당하는 모든 정보는 그렇습니다. Devin은 에이전트 변경과 무관하게 다음과 같이 독립적으로 권장하고 있습니다: "Cascade가 안정적으로 재사용하기를 원하는 지식은 자동 생성된 메모리에 의존하기보다, 규칙(Rule)으로 작성하거나 리포지토리의 AGENTS.md에 추가하세요." 각 규칙에 trigger를 부여하여 컨텍스트 비용을 제어하세요.

규칙의 크기 제한은 어떻게 되나요?

"워크스페이스 규칙 파일은 각각 최대 12,000자로 제한됩니다. 글로벌 규칙 파일은 최대 6,000자로 제한됩니다." 워크스페이스 규칙은 .devin/rules/*.md에 규칙당 하나의 파일로 저장되며, 글로벌 파일은 항상 켜져 있는 단일 global_rules.md 파일입니다.

어떤 활성화 모드를 사용해야 하나요?

비용에 맞게 선택하세요. always_on은 모든 메시지에 전체 규칙을 포함합니다. model_decision은 설명만 시스템 프롬프트에 표시하고 관련이 있을 때 전체 파일을 읽습니다. glob은 Cascade가 일치하는 파일을 읽거나 편집할 때 트리거됩니다. manual@rule-name 언급이 필요합니다. global_rules.md와 루트 수준의 AGENTS.md는 프론트매터가 없으며 항상 켜져 있습니다.

Devin Desktop에 영구적인 컨텍스트가 전혀 없나요?

아닙니다. 규칙, AGENTS.md, 워크플로우, 스킬 등 여러 종류가 영구적으로 유지되며, 자동 생성된 메모리보다 훨씬 명시적인 활성화 제어를 제공합니다. 변경된 부분은 지극히 좁은 영역으로, 하나의 메커니즘이 하나의 에이전트에 종속되게 된 것뿐입니다. 스킬이 대체할 수 있는 것과 없는 것에 대한 더 넓은 질문은 why agent skills aren't memory를 참조하세요.