에이전트는 사용자의 코드와 저장소의 지침 파일을 읽습니다.컨텍스트는 해당 메모리 파일들을 프로젝트 노트, 생성된 컨텍스트 및 참조 자료와 함께 통합합니다.
여기에 포함되는 내용의 배경을 알고 싶다면 다음을 읽어보세요.프로젝트 컨텍스트는 개념 섹션에서 다룹니다. 이 페이지에서는 이를 관리하는 방법을 설명합니다.
저장소 메모리 파일
열기설정 → 지식 → 컨텍스트에서 아래 항목을 확인하세요.저장소 소스. Coroid는 연결된 저장소에서 다음 파일들을 읽습니다:
AGENTS.md저장소 루트에 위치한 파일: 일반 에이전트 지침CLAUDE.md저장소 루트에 위치한 파일: Claude 지침GEMINI.md저장소 루트에 위치한 파일: Gemini 지침.cursor/rules: Cursor의 프로젝트 규칙으로, 해당 디렉터리 내의.mdc규칙 파일(하위 폴더 포함) 또는 단일 기존 파일
이러한 파일들은 흔히 메모리 파일이라고 불립니다. 활성화된 내용은 작업 시작 전에 에이전트의 프로젝트 컨텍스트에 포함됩니다. 이름만으로 특정 모델에 국한되지 않으며, 활성화된 소스들은 Coroid의 에이전트들을 위해 결합됩니다.
기존 파일에는편집버튼, 추정 토큰 수 및 에이전트가 이를 사용할지 여부를 제어하는 스위치가 표시됩니다. 소스는 명시적으로 비활성화하지 않는 한 기본적으로 활성화됩니다. 여러 파일이 중복되거나 상충하는 경우, 에이전트가 따라야 할 소스만 활성화하고 나머지는 비활성화하세요.
GitHub 또는 GitLab 저장소에 연결된 프로젝트에서 편집을 저장하면, 프로젝트의 pull request 기준선으로부터 새 브랜치가 생성되고 그 브랜치에 변경 사항이 반영된 pull request가 열립니다. Coroid는 기본 브랜치에 커밋하지 않으며, pull request가 병합될 때까지 에이전트가 새 버전을 읽습니다. Coroid가 호스팅하는 저장소의 프로젝트의 경우 커밋이 발생합니다. 저장하기 전에 편집기에서 이를 안내해 줍니다.
Coroid는 Cursor가 적용하는 방식대로 Cursor의 규칙을 읽습니다:
| 규칙 | 에이전트가 얻는 내용 |
|---|---|
alwaysApply: true | 전체 규칙 |
globs세트 | 적용 대상 파일과 함께 전체 규칙 |
오직description | 규칙의 경로와 설명으로, 관련 있을 때 에이전트가 이를 읽을 수 있도록 합니다. |
| 이 중 아무것도 없음 | 없음: 누군가 언급할 때에만 Cursor가 이를 적용합니다. |
일반적인.md파일은.cursor/rules에 있으면 무시되는데, 이는 Cursor도 이를 무시하기 때문입니다. 해당 디렉터리의 규칙들은 저장소에서 편집되므로 해당 행에는편집버튼이 없습니다.
생성는 해당 파일이 Coroid의 저장소 체크아웃에서 확인되지 않았음을 의미합니다. 읽기 작업이 실패하면 페이지에다시 시도버튼이 표시됩니다. 접근 오류가 반드시 파일이 없음을 의미하는 것은 아닙니다. 연결된 저장소의 브랜치에 해당 파일이 커밋되었는지 확인하세요. 작업 실행 시 에이전트는 작업의 체크아웃 내용을 읽으므로, 해당 브랜치의 지침 파일 변경 사항이 작업에 적용됩니다.
활성화된 메모리 파일은 저장소의 Markdown을@path를 통해 가져올 수 있으며, 예를 들어@AGENTS.md에서CLAUDE.md또는@docs/conventions.md입니다. 경로는 참조가 포함된 파일을 기준으로 해석됩니다. Coroid는 중첩된 임포트를 처리하고 순환 참조를 방지하며, 각 파일과 동일한 지침 본문은 한 번만 포함시킵니다. 코드 예시 및 이메일 주소 내의 참조는 그대로 유지됩니다. 저장소 외부의 참조는 로드되지 않으며, 명시적으로 비활성화된 저장소 소스를 우회하는 임포트도 허용되지 않습니다.
자동으로 감지되는 소스는 목록에 있는 것들뿐입니다. 중첩된AGENTS.md는@임포트를 통해 포함될 수 있으며, 해당 디렉터리 범위는 자동으로 추론되지 않습니다.
앱 컨텍스트
에서앱 컨텍스트, 저장소 파일과 별개로 Coroid에 저장된 지침 및 참조 자료를 관리할 수 있습니다. 수동으로 작성한 메모와 생성된 프로젝트 컨텍스트도 저장소 파일과 독립적으로 활성화하거나 비활성화할 수 있습니다. Git 외부에 속하는 정보는 이 항목에 저장하세요.
컨텍스트 추가
선택하기컨텍스트 추가하여 항목을 추가하세요. 각 항목에는 제목과 본문이 있으며, 나중에 편집하거나 삭제할 수 있습니다.
좋은 항목은 짧고 구체적이며 장기간 유지 가능해야 합니다. 아키텍처 결정 사항, 스타일 규칙, API 계약, 소유권 경계 및 명시적 금지 사항 등이 여기에 해당합니다. 온보딩 관련 내용이나 저장소에서 이미 명확히 알 수 있는 내용은 포함하지 마세요.
항목은 분리해서 명확하게 명명하세요
주제별로 하나의 항목을 만들고, 그 내용을 반영하는 제목을 붙이세요. '오류 처리 규칙'과 '사용이 금지된 모듈'은 검색이 가능하지만, 둘을 모두 포함하는 '참고 자료'라는 단일 항목은 검색이 어렵습니다.
이는 컨텍스트가 현재 작업에 따라 선택적으로 로드되기 때문에 중요한데 —단계별 역량를 참고하세요. 잘 분리된 항목들은 적절한 작업에 맞는 컨텍스트를 정확히 로드할 수 있게 해줍니다.
참조
서면으로 작성한 내용 외에도 참조 자료인 링크와 문서를 첨부할 수 있습니다. 이는 원본이 위키나 디자인 도구에 저장되어 있어 중복 사본이 오래되어 불일치하는 것을 방지하기 위함입니다.
작업별 컨텍스트
프로젝트 전체에 적용되는 컨텍스트는 프로젝트 내의 모든 항목에 영향을 미칩니다. 특정 업무와 관련된 자료—티켓, 고객 보고서, 디자인 문서 등—는 해당 작업에 직접 첨부해야 합니다. 프로젝트 컨텍스트에 남겨진 작업별 메모는 향후 다른 작업에서 불필요한 정보가 됩니다.
정확성을 유지하기
오래된 컨텍스트는 컨텍스트가 없는 것보다 더 심각한 문제인데, 에이전트가 이를 신뢰할 수 있는 정보로 간주하기 때문입니다. 규칙이 변경될 경우 코드 변경과 동일한 수정 작업에서 해당 항목도 함께 업데이트해야 합니다.
기존 컨텍스트 확인하기
가끔은 처음 접하는 사용자처럼 컨텍스트 내용을 읽어보세요. 항목이 계속 누적되다 보면 1년 전에 완료된 마이그레이션 당시 작성된 내용이 현재에는 오해의 소지가 있을 수 있습니다.