실행 간 Devin이 작업 컨텍스트를 잃지 않도록 방지하는 방법 (2026)

Knowledge는 작업이 아닌 코드베이스로 범위가 지정됩니다

이후의 모든 것을 결정하므로 다시 강조할 가치가 있습니다. Knowledge는 "Devin이 모든 세션에서 참조할 수 있는 지침 및 조언의 모음"입니다. 문서화된 예시는 모두 영구적인 리포지토리 수준의 자료입니다. "코드 준수 관행, 배포 워크플로, PR 명명 규칙, 테스트 워크플로, 독점 도구와의 상호 작용 방법 등"이 이에 해당합니다.

이 중 어느 것도 "지난 화요일에 이 버그에 대해 알아낸 사실"이 아닙니다. 작업 수준의 발견 사항은 저장소의 범위에 포함되지 않으므로, 의도적으로 승격시키거나 다른 곳에 기록하지 않는 한 유지되지 않습니다.

고정되지 않은 Knowledge는 트리거될 때만 사용됩니다

두 번째로 큰 원인이자 사람들이 간과하는 구성 세부 사항입니다. "Knowledge는 설정한 트리거(Trigger)를 기반으로 검색됩니다. 트리거가 구체적일수록(예: Knowledge가 적용되는 파일, 리포지토리 또는 작업 유형) 검색이 더 잘 됩니다."

그리고 모범 사례 목록에 따르면 다음과 같습니다. "Devin이 세션에서 작업할 때마다 Knowledge 노트를 검색하도록 하려면 모든 리포지토리에 고정(pin)해야 합니다. 그렇지 않고 정보가 특정 컨텍스트에서만 관련이 있는 경우 특정 리포지토리에 고정할 수 있습니다. Knowledge가 고정되지 않은 경우 트리거될 때만 사용되므로 트리거 설명(Trigger Description)이 명확해야 합니다."

따라서 작성하고 고정하지 않은 Knowledge 노트는 트리거 설명 뒤에 숨어 있게 됩니다. 해당 설명이 모호하면 단순히 트리거가 실행되지 않을 수 있습니다. 노트는 존재하지만 세션에 도달하지 못하는 것입니다. 이는 에이전트가 작성된 지침 파일을 무시하는 이유에서 설명한 것과 동일한 종류의 실패입니다.

여기에 정말 유용한 기능이 있지만 잘 사용되지 않고 있습니다. "Devin은 세션에서 어떤 Knowledge를 사용했는지 알려주며, 이는 세션 채팅의 'Accessed Knowledge'에서 확인할 수 있습니다." 이는 "내 노트를 실제로 읽었는가?"에 대한 직접적인 답변이므로, 지레짐작하기 전에 먼저 확인해 보세요.

자동 생성된 Knowledge는 기록이 아니라 시작점입니다

Devin은 사용자를 위해 자동으로 초기 설정을 수행합니다. "Devin은 연결된 리포지토리의 기존 README, 파일 구조 및 콘텐츠를 기반으로 리포지토리 Knowledge를 자동으로 생성합니다."

도움이 되는 기능이지만, 이는 Knowledge 베이스가 README에 적힌 내용을 설명하는 것으로 시작함을 의미합니다. 대부분의 리포지토리에서 README는 부분적으로 오래된 정보입니다.

문서에 명시된 첫 번째 모범 사례가 바로 이것입니다. "자동 생성된 모든 Knowledge를 검토하고 (a) 완전성과 (b) 정확성을 확인하십시오."

이 단계를 건너뛰면 자신 있게 검색할 수 있지만 약간 잘못된 컨텍스트가 남게 됩니다. 이는 사용되기 때문에 비어 있는 저장소보다 더 나쁩니다.

Devin은 특화된 파일을 읽고 일반 .md 파일은 건너뜁니다

정확하지만 놓치기 쉬운 규칙입니다. "Devin은 .rules, .mdc, .cursorrules, .windsurf, CLAUDE.md, AGENTS.md를 포함하여 코드베이스의 특화된 파일을 기반으로 Knowledge를 자동으로 가져오고 업데이트합니다. Devin은 .md와 같은 보다 일반적인 파일 형식은 자동으로 가져오지 않습니다."

두 가지 결과가 따릅니다. 첫째, 규칙이 docs/engineering-standards.md에 있는 경우 Devin은 이를 자동으로 가져오지 않습니다. 문서에서 권장하는 해결책은 다음과 같습니다. "코드베이스에 중앙 집중식 특화 문서 파일이 없는 경우, 특화된 파일 확장자를 사용하여 파일을 설정하는 것을 적극 권장합니다."

둘째, 반가운 소식은 리포지토리에 다른 도구에서 사용하는 CLAUDE.md, AGENTS.md 또는 .cursorrules가 이미 있는 경우 Devin이 이를 감지한다는 점입니다. 다른 에이전트를 위해 작성한 지침 파일이 여기에서도 이미 작동하고 있는 것입니다.

리포지토리 액세스 권한이 없으면 Knowledge도 없습니다

단순한 경고로 명시되어 있습니다. "Devin에게 리포지토리 액세스 권한을 부여하지 않으면 관련 Knowledge가 생성되지 않습니다." 특정 리포지토리가 Devin에게 아무것도 없는 백지 상태처럼 느껴진다면 다른 것을 확인하기 전에 액세스 권한부터 확인해 보세요.

매 세션 시작 시 Devin에게 다시 브리핑하기. 작동은 하지만, 매번 문제에 대한 비용을 다시 지불하는 셈입니다. 이는 AI에게 컨텍스트를 반복해서 설명하지 않는 방법에서 다룬 루프와 같습니다.

모든 작업 발견 사항을 Knowledge에 기록하기. 이해는 가지만, 코드베이스 수준의 저장소를 작업 수준의 노이즈로 채우게 되어 실제로 그곳에 있어야 할 자료의 검색 품질을 떨어뜨립니다.

모든 것을 모든 리포지토리에 고정하기. 검색은 보장되지만 모든 세션에 무관한 컨텍스트가 포함됩니다. 더 세밀하게 조정할 수 있는 다이얼을 뭉툭하게 사용하는 격입니다.

자동 생성된 Knowledge를 검토하지 않고 방치하기. 가장 흔한 지름길이지만, 오래된 README를 권위 있어 보이는 지침으로 변형시킵니다.

리포지토리에 의사 결정 진행 문서를 notes.md로 유지하기. 합리적인 직관이지만 확장자가 잘못되었습니다. Devin은 일반 .md 파일을 자동으로 가져오지 않습니다.

코딩 선호도가 실행 간에 알아서 전달될 것이라 가정하기. Knowledge에 있고 접근 가능해야만 전달됩니다. 이는 Devin이 코딩 스타일을 잊어버리는 이유의 배경이 되는 사례입니다.

두 가지 작업이 필요합니다. 코드베이스 수준의 자료에 대해 Knowledge가 올바르게 작동하도록 설정하고, 작업 수준의 추론을 세션이 아닌 다른 곳에 보관하는 것입니다.

오늘 바로 자동 생성된 Knowledge를 검토하세요. 문서의 지침대로 완전성과 정확성을 확인하십시오. 더 이상 사용하지 않는 시스템을 설명하는 내용은 모두 삭제하세요. 오래된 항목도 올바른 항목과 동일한 신뢰도로 검색됩니다.

각 노트에 대해 고정할지 트리거할지 결정하세요. 항상 적용되어야 하나요? 모든 리포지토리에 고정하세요. 하나의 리포지토리에만 관련이 있나요? 거기에 고정하세요. 상황에 따라 다른가요? 트리거되도록 두고, 적용되는 파일, 리포지토리 또는 작업 유형을 지정하여 실행될 수 있을 만큼 구체적인 트리거 설명을 작성하세요.

특화된 문서 파일이 없다면 새로 만드세요. AGENTS.md가 좋은 기본값입니다. Devin이 자동으로 가져오며 다른 에이전트도 이를 읽습니다. 이미 CLAUDE.md나 .cursorrules를 관리하고 있다면 이미 준비가 된 것입니다. 이 파일들도 목록에 포함되어 있습니다.

"Accessed Knowledge"를 피드백 루프로 사용하세요. 세션이 끝난 후 Devin이 실제로 사용한 항목을 확인하세요. 예상한 노트가 목록에 없다면 작성 내용이 아니라 트리거 또는 고정 설정에 문제가 있는 것입니다.

비어 있는 것처럼 느껴지는 리포지토리가 있다면 액세스 권한을 확인하세요. 액세스 권한이 없으면 생성된 Knowledge도 없습니다.

이렇게 하면 코드베이스 수준의 컨텍스트를 안정적으로 유지할 수 있습니다. 하지만 문서에서 명시적으로 Knowledge 외부로 분류한 범주인 '작업 수준의 추론'이 여전히 남습니다. 지난 실행에서 시도했으나 실패한 이유, 도중에 발견한 제약 조건, 검토 후 거부한 접근 방식 등이 이에 해당합니다. 이 모든 것을 Knowledge로 승격시키는 것은 잘못된 조치입니다. 코드베이스 수준이 아닐 뿐더러, 실제 코드베이스 수준 정보의 검색 품질을 떨어뜨리기 때문입니다.

이것이 바로 MemoryLake가 보관하는 것입니다. 리포지토리 수준의 저장소와 분리되어 에이전트가 쿼리하는 레이어에 작업 및 프로젝트 추론을 보관합니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 도구 전반에서 하나의 자격 증명만 사용하면 됩니다.

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

각각 하나의 사실을 담은 짧은 항목들입니다. 자율 에이전트를 사용할 때 가장 빠르게 가치를 발휘하는 범주는 다음과 같습니다.

시도했으나 거부된 방식과 그 이유. 에이전트가 사람의 개입 없이 작동할 때 가장 가치 있는 항목입니다. 이것이 없으면 세 번째 실행에서 첫 번째 실행이 이미 반증한 내용을 다시 도출하느라 실제 시간을 낭비하게 됩니다.

실행보다 오래 지속되는 실행 결과. "스테이징 시드 데이터에 2024년 이후의 행이 없으므로 날짜 범위 테스트가 로컬에서는 통과하고 거기서는 실패합니다." 이는 코드베이스 수준의 조언이 아니며 일회성 정보도 아닙니다.

작업 도중에만 명확해진 제약 조건. 속도 제한, 문서와 다르게 작동하는 종속성, 아무도 기록하지 않은 순서 요구 사항 등입니다.

의사 결정과 그 배경이 되는 제약 조건. 규칙은 Knowledge에 들어갈 수 있습니다. 하지만 그 규칙에 대한 논거는 검색 및 추론이 가능한 곳에 위치해야 합니다.

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

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

세 가지 분명한 한계가 있습니다. MemoryLake는 Devin의 Knowledge에 기록하지 않으며 이를 대체하지도 않습니다. Knowledge는 코드베이스 수준의 컨텍스트를 위한 올바른 위치이므로 올바르게 설정해야 합니다. 또한 MemoryLake는 사용자나 에이전트가 기록한 내용만 보관하므로 2단계는 실제 작업이 필요합니다. 마지막으로 규정 준수를 보장하지는 않습니다. 검색 가능한 컨텍스트가 강제 적용되는 구성은 아니기 때문입니다.

세 번째 실행이 첫 번째 실행을 반복하지 않습니다. 거부된 접근 방식이 기록되어 있으므로, 관리되지 않는 에이전트가 세션을 낭비하며 이를 다시 발견하는 일이 없습니다.

Knowledge가 깔끔하게 유지되고 검색이 정확해집니다. 코드베이스 수준의 저장소에 코드베이스 수준의 자료만 있으면 트리거 설명이 더 적고 더 관련성 높은 항목과 일치하게 됩니다.

"Accessed Knowledge"가 유용한 정보를 제공합니다. 저장소가 쓰레기통이 아닐 때, 사용된 항목을 확인하는 것만으로도 의미 있는 정보를 얻을 수 있습니다.

지침 파일이 이중 역할을 수행합니다. AGENTS.md 및 CLAUDE.md는 Devin의 Knowledge에 자동으로 정보를 제공하는 동시에 다른 에이전트에서도 읽히므로, 하나의 파일로 여러 도구를 지원할 수 있습니다.

도구를 변경해도 작업 추론이 유지됩니다. 자체 시스템에 대해 배운 내용은 Devin에만 국한되지 않습니다. 이는 AI 에이전트를 위한 일화적 메모리(episodic memory)에서 다룬 형태입니다.

Knowledge는 코드베이스 수준으로 유지하세요. 이것이 문서에 명시된 목적입니다. 작업 발견 사항은 다른 곳에 두지 않으면 저장소의 품질을 떨어뜨립니다.

항상 적용되어야 하는 항목은 고정하세요. 고정되지 않은 Knowledge는 트리거될 때만 사용됩니다. 이는 문서화된 동작이며 우회해야 할 버그가 아닙니다.

구체적인 대상을 지정하는 트리거 설명을 작성하세요. 파일, 리포지토리 또는 작업 유형을 명시해야 합니다. 구체적인 트리거가 더 잘 검색된다고 문서에 직접 명시되어 있습니다.

자동 생성된 Knowledge를 신뢰하기 전에 검토하세요. 이는 README, 파일 구조, 리포지토리 콘텐츠에서 파생되며, 이러한 정보는 노후화됩니다. 완전성과 정확성을 확인하세요.

특화된 파일 확장자를 사용하세요. 일반 .md 파일은 자동으로 가져오지 않으므로 .rules, .mdc, .cursorrules, .windsurf, CLAUDE.md 또는 AGENTS.md를 사용해야 합니다.

중요한 세션이 끝난 후 "Accessed Knowledge"를 확인하세요. 가장 비용이 적게 드는 진단 방법이지만 대부분의 사람들은 확인하지 않습니다.

거부된 사항은 즉시 기록하세요. 특정 접근 방식이 배제되는 순간이 그 이유가 머릿속에 가장 온전히 남아 있는 유일한 순간입니다.

환경적인 요소에는 날짜를 기록하세요. 스테이징 환경의 특이사항이나 속도 제한은 변경됩니다. 날짜가 없는 항목은 미래에 잘못된 답이 될 수 있습니다. 이는 AI 메모리의 본질과 한계에서 다룬 일반적인 문제입니다.

Devin의 Knowledge 시스템은 세션 간에 컨텍스트를 유지하며, 그 경계에 대해 문서에 정확히 명시되어 있습니다. 즉, 작업 수준이 아닌 코드베이스 수준의 컨텍스트를 위한 것이며, 고정하지 않는 한 설정한 트리거에 의해 검색되고, 검토가 필요한 자료로부터 자동 생성되며, 일반 .md 파일이 아닌 특화된 파일에서 정보를 가져옵니다.

이러한 사항들을 올바르게 설정하면 리포지토리 수준의 문제는 해결됩니다. 그런 다음 작업 수준의 추론(거부된 사항, 작업 도중 발견한 사실, 환경적 제약, 각 결정의 배경 논거)을 별도의 범주로 취급하여 에이전트가 쿼리할 수 있는 레이어에 보관하세요. 이것이 바로 매번 유능한 신입 사원으로 실행을 시작하는 에이전트와, 매번 첫 출근한 신입 사원처럼 실행을 시작하는 에이전트의 차이입니다.