필요한 세션에서 올바른 Devin Knowledge를 트리거하는 방법 (2026년 가이드)

먼저 검색 모델부터 살펴보겠습니다. 이는 일반적인 지침(instruction) 파일의 작동 방식과 정반대이기 때문입니다. Cognition의 자체 팁에서도 이를 직접적으로 언급하고 있습니다. "Devin은 한꺼번에 또는 시작할 때 모두 가져오는 것이 아니라, 관련이 있을 때 Knowledge를 검색합니다. 검색 트리거가 콘텐츠와 높은 관련성을 갖도록 설정하세요."

따라서 트리거 설명은 단순한 메타데이터가 아닙니다. 그것은 관문입니다. 온보딩 가이드에서도 좋은 트리거의 형태를 명시하며 이 점을 반복합니다. "Knowledge는 설정한 트리거를 기반으로 검색됩니다. 트리거가 구체적일수록(예: Knowledge가 적용되는 파일, 리포지토리 또는 작업 유형) 검색이 더 잘 됩니다."

이는 모든 프롬프트에 병합되는 규칙 파일과는 근본적으로 다른 설계이며, 실패하는 지점도 다릅니다. 규칙 파일이 너무 길면 내용이 희석됩니다. 반면 트리거가 모호한 Knowledge 항목은 건너뛰게 됩니다. 지침 파일이 카테고리 전체에서 조용히 무시되는 이유는 이와 관련된 문제로, 저희는 why agents skip your instruction files에서 이 문제를 다룬 바 있습니다.

항목이 세션에 도달하지 못할 수 있는 세 가지 이유가 더 있으며, 모두 문서화되어 있습니다.

어디에도 고정(Pin)되어 있지 않음. Cognition은 고정을 예외 조항으로 설명합니다. "리포지토리에 고정하지 않음: Knowledge는 Devin이 현재 컨텍스트와 관련이 있다고 판단할 때만 검색됩니다." 특정 리포지토리에 고정하면 동작이 완전히 바뀝니다. "Devin이 해당 특정 리포지토리에서 작업할 때마다 Knowledge가 항상 사용됩니다." 모든 리포지토리에 고정하면 "Knowledge가 모든 세션에서 Devin이 작업하는 모든 리포지토리에 자동으로 적용됩니다." 온보딩 가이드는 이 결정 규칙을 명시하고 있습니다. "Devin이 세션에서 작업할 때마다 Knowledge 노트를 검색하도록 하려면 모든 리포지토리에 고정해야 합니다."

비활성화되어 있음 (폴더에 의해 비활성화되었을 수 있음). 항목은 개인별로 끌 수 있습니다. "각 Knowledge 항목은 사용자별로 개별적으로 활성화 또는 비활성화할 수 있습니다. Knowledge 항목을 비활성화하면 조직에서 삭제하지 않고도 세션에서 Devin이 이를 검색하지 못하도록 방지합니다." 폴더도 이 스위치를 상속받습니다. "폴더가 비활성화되면 그 안의 모든 Knowledge 항목이 세션에서 비활성화됩니다." 동료의 세션에서는 해당 항목이 작동한다고 해서 여러분의 말이 틀린 것은 아닙니다. 단지 활성화된 설정이 다를 뿐입니다.

생각한 것과 다른 범위(Scope)에 있음. 새 항목은 기본적으로 한 수준으로 설정됩니다. Organization Knowledge 항목은 "조직의 모든 구성원에게 보이며 새 Knowledge 항목의 기본 범위입니다." Enterprise Knowledge 항목은 "엔터프라이즈의 모든 조직에 적용"되며, 범위를 상향하려면 권한이 필요합니다. "승격에는 엔터프라이즈 지식 관리 권한이 필요하며, 엔터프라이즈에 속한 조직에서 사용자가 생성한 Knowledge 항목에만 사용할 수 있습니다."

직접 작성하기 전에 알아두어야 할 사항이 하나 더 있습니다. 일부 Knowledge는 여러분이 작성하지 않아도 자동으로 생성됩니다. "Devin은 연결된 리포지토리의 기존 README, 파일 구조 및 콘텐츠를 기반으로 리포지토리 지식을 자동으로 생성합니다." 단, 액세스 권한에 대한 경고가 따릅니다. "Devin에게 리포지토리 액세스 권한을 주지 않으면 관련 Knowledge를 생성하지 않습니다." Cognition의 첫 번째 온보딩 단계는 이 자료를 확인하는 것입니다. "자동 생성된 Knowledge를 검토하고 (a) 완전성과 (b) 정확성을 확인하세요."

그리고 Devin은 계속해서 더 많은 제안을 합니다. "Devin은 채팅 피드백을 기반으로 기억할 Knowledge를 자동으로 제안합니다." 편집 및 거부는 사용자가 직접 제어할 수 있으며, "새로운 Knowledge 항목을 제안하는 것 외에도 기존 Knowledge 항목에 대한 업데이트를 제안할 수도 있습니다."

모든 내용을 담은 긴 Knowledge 항목 하나 작성하기. 이해는 가지만, 이는 검색 모델의 취지에 두 번 어긋납니다. Cognition의 지침은 그 반대입니다. "하나의 워크플로우나 작업에 초점을 맞춘 구체적인 Knowledge를 만드세요. Devin은 Knowledge 콘텐츠 전체를 읽으므로 모든 내용을 관련성 있고 최신 상태로 유지해야 합니다!" 그리고 "가능하면 Knowledge를 더 작게 나누세요." 단일 옴니버스 항목은 그 안의 모든 내용을 어떻게든 설명하는 하나의 트리거 설명이 필요하게 됩니다.

콘텐츠를 Playbook으로 이동하기. Playbook은 다른 도구이며, Cognition은 이 구분에 대해 이례적으로 직접적으로 설명합니다. "대부분의 모범 사례, 스타일 가이드 또는 기타 프로젝트별 지침은 Knowledge를 사용하여 Devin과 공유해야 합니다. Playbook을 만들기 전에 Knowledge 문서를 읽고 어떤 방법이 귀하의 요구에 더 잘 맞는지 이해하는 것이 좋습니다." 그들의 표현을 빌리자면 Playbook은 "반복되는 작업을 위한 맞춤형 시스템 프롬프트와 같습니다." 즉, 세션을 시작할 때 첨부하는 것입니다. 또한 그들은 이것이 쉬운 옵션이 아니라고 지적합니다. Playbook은 "현재 작성하는 데 기술이 필요합니다."

리포지토리의 마크다운 파일에 모든 것을 넣기. 합리적인 직관이지만, 파일 확장자 제한에 부딪힙니다. Devin은 ".rules, .mdc, .cursorrules, .windsurf, CLAUDE.md, AGENTS.md를 포함하여 코드베이스의 특수 파일을 기반으로 Knowledge를 자동으로 가져오고 업데이트합니다." 이어서 다음과 같은 제한이 따릅니다. "Devin은 .md와 같은 보다 일반적인 파일 형식은 자동으로 가져오지 않습니다." 규칙을 담고 있는 규칙 전용 파일은 일반 메모 파일과는 다르게 작동합니다.

매번 프롬프트에서 지침을 반복하기. 이는 문제를 감추는 임시방편입니다. 작동은 하기 때문에 아무도 트리거를 수정하지 않고, 반복은 끝없이 계속됩니다. 무엇이 Knowledge에 속해야 하는지에 대한 Cognition의 자체 조언은 이와 정반대입니다. "정기적으로 반복해서 사용하는 프롬프트나 Playbook의 요소를 포함하는 것을 권장합니다."

세션이 단순히 컨텍스트를 잃었다고 가정하기. 실제로 그럴 때도 있으며, 이는 when Devin forgets task context에서 설명한 다른 형태의 문제입니다. 애초에 검색되지 않은 Knowledge 항목은 세션에 존재한 적이 없으므로 잃어버릴 수도 없습니다.

Knowledge를 Skill로 대체하기. 이 또한 실제 절충안이 있는 실질적인 옵션이며, 저희는 moving Devin memories into skills에서 이를 정리했습니다. 이 방법은 검색 문제를 해결하는 것이 아니라 다른 곳으로 옮길 뿐입니다.

세 단계로 나뉩니다. 처음 두 단계는 10분 정도 소요되며, 전체 기능을 확률적인 것에서 예측 가능한 것으로 바꿔줍니다.

1단계: 항목을 트리거형과 상시 활성화형으로 분류하기

가지고 있는 항목들을 살펴보며 각 항목에 대해 한 가지 질문을 던져보세요. "이것이 특정 종류의 작업에 적용되는가, 아니면 리포지토리의 모든 세션에 적용되는가?"

작업별 항목은 트리거를 유지하고 설명을 더 명확하게 다듬습니다. 좋은 트리거가 지칭하는 대상(어떤 파일, 어떤 리포지토리 또는 어떤 유형의 작업)에 대한 Cognition의 팁을 따르세요. "Deployment"는 카테고리입니다. "infra 리포지토리 아래의 릴리스 파이프라인 또는 배포 스크립트를 건드리는 모든 작업"이 트리거입니다.

리포지토리 전체에 적용되는 항목은 대신 고정(Pin)합니다. 특정 리포지토리에 고정하면 Devin이 해당 리포지토리에서 작업할 때마다 해당 항목이 항상 사용되므로 트리거가 필요 없어집니다. 모든 리포지토리에 고정하는 기능은 실제로 모든 곳에 적용되는 소수의 항목에만 아껴서 사용하세요. 여기에 고정된 모든 항목은 모든 세션에서 읽히기 때문입니다.

수동으로 불러오고 싶은 몇 가지 항목의 경우, 프롬프트에 입력할 수 있는 "!로 시작하는 짧은 식별자"인 매크로를 할당하세요. Cognition은 매크로가 "문자, 숫자, 하이픈만 포함할 수 있으며 조직 내에서 고유해야 한다"고 명시하고 있습니다.

2단계: 세션을 하나 실행하고 Accessed Knowledge 확인하기

이것은 검증 단계이며, 실제로 존재합니다. Cognition은 이를 문서화했습니다. "Devin은 세션에서 어떤 Knowledge를 사용했는지 알려줍니다." 이는 세션 채팅의 Accessed Knowledge 제목 아래에서 확인할 수 있습니다.

항목을 작성한 작업을 하나 선택하여 실행하고 확인해 보세요. 항목이 목록에 있으면 트리거가 작동하는 것입니다. 목록에 없다면, 이제 Knowledge 자체의 문제와 트리거 문제의 차이를 알게 된 것이며, 이 구분을 통해 다른 모든 문제를 해결할 수 있게 됩니다. 그런 다음 명백한 혼란 요인을 확인하세요. 해당 항목이 본인에게 활성화되어 있는지, 폴더가 활성화되어 있는지, 예상한 범위에 있는지 확인합니다.

규칙 트리거 모드는 특이한 기능이 아니라 에이전트 설정의 표준적인 부분으로 자리 잡고 있으며, 다른 벤더가 동일한 선택을 어떻게 모델링하는지 비교하는 것은 직관을 기르는 빠른 방법입니다. 저희는 choosing rule trigger modes에서 이를 정리한 바 있습니다.

3단계: 검색 규칙이 운명을 결정할 수 없는 곳에 의사결정 배경을 보관하기

Knowledge는 코딩 에이전트를 위한 검색 레이어이며, 그 역할을 잘 수행합니다. 규칙 뒤에 숨겨진 의사결정 배경(처음에 시도했던 것, 실패한 이유, 규칙이 존재하는 이유 등)은 작업에 의해 트리거되지 않습니다. 이는 6개월 후에 다른 도구에서라도 여러분이 직접 읽고 싶어 할 내용들입니다.

이러한 내용은 검색 규칙이 지배하지 않는 곳에 보관하세요. 항목의 콘텐츠에 이유가 암묵적으로만 담겨 있는 규칙은 다음 사람이 쉽게 뒤집을 수 있는 규칙이 됩니다.

지속되어야 하는 정보는 트리거 설명에 의해 차단되지 않는 보금자리가 필요합니다. MemoryLake는 이러한 의사결정을 의도적으로 기록하는 저장소로, 단일 에이전트의 검색 규칙과 분리되어 있으며 연결하는 모든 어시스턴트에서 읽을 수 있습니다. 여러분이 직접 자신의 언어로 항목을 작성합니다. Cognition의 시스템이나 다른 벤더의 저장소에서 데이터를 읽거나 쓰거나 삭제하지 않으므로, 여러분의 Knowledge 항목, Playbook 및 리포지토리는 전적으로 자체 제어 하에 유지됩니다.

1단계: API 키 생성하기

대시보드에서 키를 생성합니다. 이 키를 통해 클라우드 에이전트, 터미널 어시스턴트, 채팅 클라이언트가 각자 자체 버전을 유지하지 않고도 동일한 사실 정보에 접근할 수 있습니다.

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

규칙보다는 이유에서부터 시작하세요. 배포 순서가 왜 그렇게 되었는지, 어떤 접근 방식이 어떤 근거로 제외되었는지, 서비스 소유자가 누구이며 그들에게 무엇을 전달해야 하는지 등입니다. Knowledge 항목은 지침을 전달하지만 논거를 담는 경우는 드뭅니다. 그리고 지침이 덮어써지는 것을 막아주는 것은 바로 그 논거입니다.

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

설명이 일치하는지 여부에 의존하지 않고 작업 시작 시점에 이러한 사실 정보가 로드되도록 도구를 레이어에 연결하세요. 그런 다음 의미 있는 유일한 방법으로 테스트해 보세요. 다른 어시스턴트에게 이전 의사결정 중 하나를 다시 물어보는 것입니다. 답변을 한다면, 여러분의 논거는 더 이상 특정 벤더의 검색 경로에 갇혀 있지 않은 것입니다.

첫 번째 변화는 "Devin이 내 Knowledge를 무시했다"는 주장을 테스트할 수 있게 된다는 점입니다. Accessed Knowledge는 무엇이 사용되었는지 알려줍니다. 항목이 검색되었거나 검색되지 않았거나 둘 중 하나이며, 해결 방법은 서로 다릅니다.

두 번째는 고정(Pinning)이 건너뛴 필드가 아니라 의도적인 선택이 된다는 점입니다. 리포지토리에 고정하면 항상 적용되어야 하는 항목에 대해 검색 여부를 판단할 필요가 없어집니다.

세 번째는 항목이 더 짧아진다는 점입니다. 검색이 콘텐츠를 설명하는 트리거에 의존하게 되면, 워크플로우당 하나의 항목을 만드는 것이 자연스러운 형태가 되며, Cognition도 정확히 이를 권장합니다.

네 번째는 자동 생성 및 자동 제안된 Knowledge가 단순한 소음으로 남지 않게 된다는 점입니다. Devin은 README, 파일 구조 및 리포지토리 콘텐츠에서 리포지토리 지식을 생성하고, 채팅 피드백을 통해 새로운 항목을 제안합니다. 이 두 가지를 검토하는 것은 유지보수 작업이며, 그렇지 않으면 아무도 읽지 않은 항목들만 쌓이게 됩니다.

다섯 번째는 지속되어야 하는 의사결정 배경이 파일 확장자나 범위 수준에 의존하지 않게 된다는 점입니다. 여러 도구에 걸쳐 중요한 자료는 사용자를 따라다니는 레이어에 속해야 합니다. 이는 저희가 turning project docs into AI memory에서 주장한 내용이기도 합니다.

콘텐츠를 작성하기 전에 트리거를 먼저 작성하세요. 항목을 언제 가져와야 하는지 설명할 수 없다면, 그 항목은 아마 두 개의 항목으로 나누어야 할 것입니다.

항목당 하나의 워크플로우만 담으세요. Cognition의 지침은 하나의 워크플로우나 작업에 초점을 맞추고 가능한 한 분할하는 것입니다. 일단 검색되면 항목 전체를 읽기 때문입니다.

조건 없이 적용되는 것은 고정하세요. 리포지토리 전체에 적용되는 규칙이 매 세션마다 관련성 경쟁을 벌이게 해서는 안 됩니다.

리포지토리 내 컨텍스트에는 특수 파일 확장자를 사용하세요. Devin은 지정된 특수 파일 목록에서만 가져오고 일반 마크다운은 자동으로 가져오지 않으므로, 확장자 선택도 설계의 일부입니다.

무언가를 다시 작성하기 전에 활성화 여부를 확인하세요. 사용자별 비활성화 및 폴더 수준 토글은 다른 사람에게는 작동하는 항목이 나에게는 작동하지 않는 가장 흔한 이유입니다.

제안을 무조건 수락하지 말고 검토하세요. Devin은 새 항목과 기존 항목의 업데이트를 모두 제안하며, 저장하기 전에 편집할 수 있는 데는 다 이유가 있습니다.

논거는 항목 외부에 보관하세요. 지침은 Knowledge에 위치하지만, 그것이 존재하는 이유는 모든 도구가 읽을 수 있는 곳에 위치해야 합니다.

Devin의 Knowledge 시스템은 문서화가 잘 되어 있지만 다소 직관적이지 않은 면이 있습니다. 항목은 세션 시작 시 로드되지 않으며, 작업이 트리거와 관련이 있을 때 검색되고, 모든 항목에는 트리거 설명이 필요합니다. 이 단 하나의 설계 결정이 잘 작성된 항목이 무시된 것처럼 보이는 대부분의 사례를 설명해 줍니다.

Cognition은 또한 검색에 의존하지 않는 방법들도 문서화해 두었습니다. 항목을 특정 리포지토리에 고정하면 Devin이 거기서 작업할 때 항상 사용됩니다. 모든 리포지토리에 고정하면 모든 세션에 적용됩니다. 매크로를 할당하면 이름으로 직접 불러올 수 있습니다. 그리고 세션 채팅의 Accessed Knowledge 뷰는 Devin이 실제로 무엇을 사용했는지 알려주므로, 의구심을 확실한 확인으로 바꾸어 줍니다.

기억해 둘 만한 두 가지 경계선이 있습니다. Devin은 일반 마크다운이 아닌 지정된 특수 파일 목록에서만 Knowledge를 자동으로 가져온다는 점과, 사용자별 또는 폴더별 비활성화 기능 때문에 동료의 세션과 여러분의 세션이 동일한 세트로 실행되지 않을 수 있다는 점입니다.

항목을 트리거형과 상시 활성화형으로 분류하고, Accessed Knowledge를 통해 각각 하나씩 검증한 다음, 규칙 뒤에 숨겨진 의사결정 배경은 검색 트리거가 노출 여부를 결정할 수 없는 곳에 보관하세요.