Cognition의 Devin, 이제 Git Repo에 Memory 보관 — Dreaming이 정리하는 것과 팀과 공유되지 않는 이유 (2026)

제품 발표에서는 Memory를 "세션 전반에 걸쳐 사용자가 선호하는 작업 방식에 대한 유용한 학습 내용(선호도, 수정 사항, 프로젝트 및 워크플로우에 대해 배운 교훈)을 전달하는" 방법으로 설명합니다. X(구 트위터)에서 Cognition은 이를 더 간략하게 표현했습니다. "세션을 거치며 Devin은 사용자가 일하고 싶어 하는 방식에 대한 memory 그래프를 구축합니다."

문서에서는 저장소에 대해 설명합니다. "사용자의 memory는 memory drive에 저장됩니다. 이는 Markdown 노트로 구성된 영구적인 Git 리포지토리입니다." 짧은 MEMORY.md 파일이 일반적인 선호도와 인덱스를 보관하며, 다른 노트들은 프로젝트나 주제별 폴더에 저장됩니다.

또한 3단계 루프에 대해서도 설명합니다. 첫 번째 단계에서는 "각 세션이 드라이브의 자체 체크아웃을 가져오고 MEMORY.md를 context로 받습니다." Devin은 작업에 필요할 때만 다른 노트를 검색하고 읽습니다. 두 번째 단계에서는 사용자가 Devin을 수정하거나 Devin이 재사용 가능한 것을 알아냈을 때 노트를 편집하며, 각 항목은 학습된 세션으로 다시 연결되는 한 줄짜리 글머리 기호가 됩니다. 세 번째 단계에서는 Devin이 커밋하고, 다른 세션의 변경 사항을 병합(merge)한 다음 저장합니다. 병렬 세션들은 동일한 드라이브에 쓸 수 있으며, 블로그에서는 "충돌하는 편집은 자동으로 덮어쓰여지는 대신 해결을 위해 표면화됩니다"라고 설명합니다.

놓치기 쉬운 타이밍 세부 정보가 하나 있습니다. "새로운 memory는 이를 기록한 세션이 아니라 향후 세션에 적용됩니다."

다음으로 오픈 표준이 있습니다. 문서에 따르면 Devin의 memory는 "에이전트 memory를 MEMORY.md 진입점이 있는 Git 리포지토리로 취급하는 오픈 사양인 Agent Memory Repo를 기반으로 구축되었습니다"라며, "자체 에이전트에서도 동일한 형식을 사용할 수 있습니다"라고 덧붙였습니다.

Devin은 명시된 제한 내에서 저장할 대상을 결정합니다. 문서에는 표가 포함되어 있습니다. 저장 대상: 선호도, 수정 사항, 사용자가 제공한 이유가 포함된 결정 사항, 리포지토리에 대한 주의 사항(gotchas). 저장되지 않는 대상: "세션 요약", "PR 번호나 상태와 같은 작업 상태", "다시 찾아내기 쉬운 모든 것", "비밀번호 및 자격 증명(credentials)". 블로그에서는 동일한 개념을 다른 방식으로 표현합니다. "Memory는 세션의 요약이 아닙니다."

Dreaming은 추가, 병합 및 제거를 수행합니다. "Dreaming은 Devin을 사용한 날 하루에 한 번 정도 실행되는 백그라운드 세션입니다." 중복되는 노트를 통합하고, 캡처되지 않은 교훈을 추가하며, 인덱스를 재구성합니다. 또한 "어떤 세션에서도 사용하지 않은 일시적인 세부 정보와 오래된 노트를 제거합니다." 블로그에서는 이 단계를 "어떤 세션에서도 사용되지 않은 오래된 memory 기록"을 제거하는 것으로 나열합니다. Cognition은 "소스 링크와 명시적인 선호도는 보존됩니다"라고 언급합니다.

Memory is personal. 이 부분이 팀에게 가장 중요한 대목입니다. "Memory는 각 조직 내에서 사용자 개인에게 귀속됩니다. 팀원이나 조직과 공유되지 않습니다." 블로그에서는 이를 디자인 선택으로 설명합니다. "조직을 위한 공유 지침이 되기보다는 사용자 개인에게 귀속됩니다."

자동화(Automations)는 여기에 관여하지 않습니다. "자동화로 시작된 세션은 사용자의 memory를 읽거나 쓰지 않습니다." Devin이 일정, Slack 트리거 또는 웹훅(webhook)에 의해 시작하는 작업은 사용자의 개인 노트 없이 실행됩니다.

Devin을 통해 관리합니다. Customize 메뉴 아래의 Memory에서 memory 파일을 찾아보고 각 dreaming 세션이 무엇을 변경했는지 확인할 수 있습니다. 하지만 "앱에서 memory 파일은 읽기 전용입니다." 무언가를 변경하려면 세션 내에서 Devin에게 선호도를 잊어버리거나 규칙을 기억하라고 요청해야 합니다.

기능을 꺼도 노트는 유지됩니다. Memory는 기본적으로 켜져 있습니다. 개인 memory를 끄면 "Devin은 memory 읽기 및 쓰기를 중단하지만, 다시 켜면 기존 노트가 유지됩니다." 관리자가 조직 전체에 대해 이 기능을 끄면 "Dreaming이 실행되지 않고 Memory 탭이 숨겨집니다. 기존 노트는 삭제되지 않습니다."

팀 가이드는 자체적인 공간이 있으며, 이동 중입니다. 공유 지침의 경우 Devin은 skills를 가리킵니다. skills 페이지에서는 "Skills는 사용자가 의도적으로 작성하는 절차입니다"라고 설명하며, 플러그인의 skills는 "개인, 조직 또는 엔터프라이즈 범위에 설치할 수 있습니다"라고 덧붙입니다. Devin의 이전 Knowledge 기능에는 이제 다음과 같은 배너가 표시됩니다. "Knowledge는 더 이상 사용되지 않으며(deprecated) 향후 업데이트에서 제거될 예정입니다." 기존 Knowledge는 자동으로 skills로 마이그레이션되고 있습니다. Devin Knowledge 가이드에서 설명한 방식으로 트리거를 설정했다면, 해당 트리거들이 skills로 변환될 것을 예상할 수 있습니다.

이는 Cognition의 로컬 에이전트인 Devin Desktop과도 별개입니다. Devin Desktop의 Cascade 시절 memory는 Devin의 Cascade 전용 memory를 skills로 이동하기에서 다루고 있습니다. 여기서 설명하는 memory drive는 devin.ai의 Devin에 해당합니다.

Devin이 이제 팀이 결정한 사항을 기억할 것이라고 가정하는 것. Devin은 사용자와 함께 작업하면서 배운 것을 기억합니다. 팀원의 Devin은 자체 드라이브를 가지고 있습니다. 지난주에 사용자가 Devin에게 설명한 결정 사항은 사용자의 memory에 있을 뿐, 팀원의 memory에는 없습니다.

오픈 사양의 팀 유스케이스를 Devin의 memory에 대한 설명으로 읽는 것. 사양서에는 팀 memory가 유스케이스로 나열되어 있습니다. "특히 코드 리포지토리가 없는 팀을 위해 고객, 프로세스 및 도구에 대한 지식을 공유합니다." 이는 해당 형식이 지원할 수 있는 기능을 설명하는 것입니다. 거기서도 공유는 선택 사항(opt-in)입니다. 한 세션에 두 사람이 참여하는 사양서의 예시에서 "Bob의 memory는 그가 세션과 공유하기로 선택한 경우에만 복제됩니다." 그리고 각 리포지토리는 "자체 소유권, 권한 및 기록"을 유지합니다. Devin의 제품 문서에서는 자체 memory를 개인용으로 설명하며, 팀 가이드는 skills를 통해 제공됩니다.

Devin이 한 번 배웠다면 다음 달에도 그대로 있을 것이라고 가정하는 것. Dreaming은 어떤 세션에서도 사용하지 않은 노트를 제거합니다. 이를 통해 memory를 집중된 상태로 유지할 수 있지만, 마이그레이션을 중단한 이유나 규정 준수 검토에 필요했던 사항과 같이 드물게 중요한 결정은 필요할 때가 오기 전에 정리(prune)될 수 있음을 의미합니다.

예약된 실행이 사용자의 세션에서 Devin이 배운 내용의 혜택을 받을 것이라 기대하는 것. 자동화는 개인 memory를 읽거나 쓰지 않습니다.

Git 형식이므로 memory가 사용자와 함께 이동할 것이라고 가정하는 것. 사양서 자체의 테스트 지침에는 "클라우드 세션이나 다른 머신에서 세션 간에 memory를 전달하려면 프라이빗 원격 저장소나 기타 영구 저장소가 필요하다"고 명시되어 있으며, 독립 실행형 버전에는 "자동 시작 및 예약된 Dreaming이 포함되어 있지 않다"고 나와 있습니다. 형식은 이식 가능하지만, 이를 둘러싼 동작은 이를 구현하는 각 에이전트에서 비롯됩니다.

이 중 어느 것도 비판이 아닙니다. 개인적이고 스스로 정리하는 memory는 한 명의 개발자와 함께 일하는 에이전트에게 합리적인 디자인입니다. 핵심은 에이전트가 어떤 종류의 context를 보유하고 있는지 파악하여 나머지는 다른 곳에 보관하는 것입니다.

1단계: Devin이 사용자에 대해 배워야 할 것과 팀에 필요한 것 구분하기

Devin에게 자주 말하는 내용들을 나열해 보세요. 그런 다음 이를 분류합니다.

개인적인 context는 Devin의 memory에 속합니다. 업데이트 작성 방식, 선호하는 도구, 본인의 스타일을 반영한 수정 사항 등이 이에 해당합니다. 작업하는 동안 Devin이 이를 자연스럽게 학습하도록 두고, 잘못된 부분이 있으면 세션 내에서 수정해 주세요.

팀 context는 다른 공간이 필요합니다. 모두가 사용하는 빌드 및 테스트 명령어, 아키텍처 경계, 릴리스 규칙 및 그 이면의 이유 등이 있습니다. 팀원의 세션이나 자동화된 실행에 적용되어야 하는 내용이라면 개인 memory는 적절한 장소가 아닙니다.

유용한 테스트 방법은 다음과 같이 자문해 보는 것입니다. "내일 동료가 동일한 리포지토리에서 세션을 시작할 때 이것이 필요할까?" 그렇다면 그것은 팀 context입니다.

2단계: 절차는 skills 및 리포지토리 파일에 넣고, 이유를 함께 기록하기

Devin의 자체 가이드에 따르면 skill은 "절차를 제공하고, memory는 이를 작업에 적용하기 위한 context를 제공합니다." 따라서 반복 가능한 절차는 리포지토리의 .agents/skills/ 폴더에 작성하거나 플러그인을 통해 조직 범위의 skill로 작성하세요. 리포지토리 컨벤션은 Devin이 읽는 AGENTS.md와 같은 파일에 보관하세요.

절차를 작성할 때는 그 이유도 함께 포함하세요. 병합하기 전에 통합 테스트 스위트를 실행하라는 skill은 그대로 실행됩니다. 하지만 왜 실행해야 하는지, 지난번에 이를 건너뛰었을 때 어떤 문제가 발생했는지도 함께 명시한 skill은 다음 리팩토링 과정에서도 살아남을 것입니다. Skills와 memory는 서로 다른 목적을 수행하며, 이 차이점은 에이전트 skills가 memory가 아닌 이유에서 다루고 있습니다.

그런 다음 마이그레이션되는 기존 Knowledge 항목들을 확인하세요. 각 항목이 의도한 범위에 올바르게 도달했는지, 더 이상 실행되지 않는 트리거에만 중요한 내용이 남아 있지 않은지 확인하세요.

3단계: 드물게 발생하지만 절대 잃어버려서는 안 되는 결정 사항 기록하기

일부 context는 최근 사용 여부에만 의존하기에는 너무 중요합니다. 서비스가 분할된 이유, 특정 벤더가 거절된 이유와 그 배경, 고객 계약에서 요구하는 사항 등이 이에 해당합니다. 이러한 사항들은 일 년에 몇 번만 발생하므로, 정리(pruning) 작업이 지워버리기 딱 좋은 패턴입니다.

이러한 정보는 날짜와 출처를 명시하여 의도적으로 관리하는 기록에 보관하세요. Devin의 항목들은 이미 해당 항목이 생성된 세션으로 다시 연결되는데, 이는 memory 출처(provenance)에서 더 자세히 설명하는 좋은 습관입니다. 직접 관리하는 결정 사항에도 동일한 습관을 적용해 보세요.

드물게 사용되는 결정 사항이 관련이 있어지면 세션에 명시적으로 가져오세요. 그러면 Devin이 이를 사용할 수 있고, 개인적으로 중요한 내용이라면 다시 memory에 저장할 수 있습니다.

3단계는 한 사람의 에이전트에 의존해서는 안 되는 팀 및 장기 보존 context 레이어를 설명합니다. MemoryLake는 이를 위해 구축되었습니다. 한 번 작성하면 이를 필요로 하는 사람들과 에이전트들 간에 공유할 수 있는 장기 memory입니다.

사용자는 자신의 언어로 직접 항목을 작성합니다. Devin의 memory drive, 사용자의 skills 또는 다른 벤더의 저장소에서 아무것도 읽거나 쓰거나 삭제하지 않습니다.

1단계: API 키 생성하기

로그인한 후 대시보드에서 키를 생성합니다. 이 키는 Devin 조직과 무관하게 사용자의 MemoryLake 워크스페이스에 속합니다.

2단계: 첫 번째 memory 업로드하기

3단계의 결정 사항(날짜와 이유가 포함된 드물지만 중요한 결정 사항)부터 시작하세요. 1단계에서 파악한 팀 context 중 skill에 자연스럽게 맞지 않는 내용을 추가합니다.

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

Devin 및 팀이 사용하는 다른 에이전트들을 연결합니다. 그러면 개인 memory 없이 시작되는 실행을 포함하여 모든 팀원과 모든 도구에서 동일한 결정 사항을 사용할 수 있게 됩니다.

첫 번째 차이점은 Devin의 memory가 자신 있는 일을 잘 수행할 수 있게 된다는 것입니다. 개인적인 선호도와 수정 사항은 별도의 관리 없이도 누적되며, Dreaming이 이를 깔끔하게 정리해 줍니다.

두 번째는 팀 context가 세션을 실행한 사람에게 더 이상 의존하지 않는다는 점입니다. 절차는 skills에, 컨벤션은 리포지토리에, 장기 보존 결정 사항은 공유 기록에 보관됩니다. 팀원의 세션과 자동화된 실행이 동일한 기반에서 시작됩니다. 더 광범위한 설정에 대해서는 팀을 위한 공유 AI memory 설정하기를 참조하세요.

세 번째는 정리(pruning)가 더 이상 위험 요소가 되지 않는다는 점입니다. 드물게 중요한 결정 사항이 다른 곳에 기록되어 있으면, Dreaming이 사용되지 않는 노트를 제거하는 것은 손실이 아니라 정리 정돈이 됩니다.

네 번째는 이동하는 대상에 대한 명확성입니다. Memory 형식은 개방되어 있지만, 팀의 지식이 한 사람의 에이전트와 함께 이동할 필요는 없습니다. 여러 에이전트를 병렬로 실행하는 팀은 멀티 에이전트 시스템을 위한 공유 memory에서 논의한 것처럼 더 큰 규모에서 동일한 문제에 직면하게 됩니다.

Devin이 개인 선호도를 학습하도록 하세요. 그것이 memory의 목적입니다.

세션 내에서 memory를 수정하세요. 앱에서는 memory 파일이 읽기 전용으로 표시되므로, Devin에게 잊어버리거나 기억하라고 요청하세요.

팀 절차는 skills에 넣으세요. Memory는 개인용이며, skills는 조직 범위로 설정할 수 있습니다.

마이그레이션된 Knowledge를 확인하세요. 각 항목이 올바른 범위의 skill로 안착했는지 확인하세요.

자동화에는 명시적으로 브리핑하세요. 예약되거나 트리거된 실행은 개인 memory를 사용하지 않습니다.

드문 결정 사항은 영구적인 곳에 보관하세요. Dreaming은 어떤 세션에서도 사용하지 않은 노트를 제거합니다.

가정하기 전에 디자인을 비교해 보세요. Claude의 dreaming memory 저장소에서 볼 수 있듯이, 다른 어시스턴트들도 이제 백그라운드에서 memory를 통합하며, 각각 경계를 다르게 설정하고 있습니다.

Devin의 새로운 memory는 원래 의도한 목적에 맞게 잘 설계되었습니다. 선호도, 수정 사항 및 교훈을 Git 리포지토리에 짧은 노트로 저장하고, 각 노트를 출처에 연결하며, 통합, 추가 및 제거를 수행하는 일일 Dreaming 작업을 실행합니다. Cognition은 다른 에이전트도 이를 사용할 수 있도록 형식을 공개했습니다.

문서에서는 범위에 대해 명확히 설명하고 있습니다. Memory는 "각 조직 내에서 사용자 개인에게 귀속"되며, 자동화는 이를 읽거나 쓰지 않고, Dreaming은 어떤 세션에서도 사용하지 않은 노트를 제거합니다. 팀 가이드는 skills에 속하며, Devin의 이전 Knowledge 기능은 그곳으로 마이그레이션되고 있습니다.

그러므로 Devin이 사용자에 대해 배우도록 두고, 팀 절차는 skills 및 리포지토리 파일에 넣고, 드물게 발생하지만 절대 잃어버려서는 안 되는 결정 사항은 온 팀이 접근할 수 있는 기록에 보관하세요.