프로젝트 컨텍스트

에이전트는 저장소를 읽습니다. 이를 통해 필요한 대부분의 정보를 확보하지만, 사람의 머릿속에 있거나 위키·2년 전 대화 속에 존재하는 결정 사항은 포함되지 않습니다.

프로젝트 컨텍스트저장소의 지침과 Coroid에 저장된 사용자의 안내 내용을 결합합니다.

저장소의 지침도 컨텍스트에 해당합니다.#

Coroid는 루트 레벨의 메모리 파일을 읽어들입니다.AGENTS.md, CLAUDE.md및GEMINI.md, 그리고 Cursor의 규칙도 포함됩니다..cursor/rules. 작업이 시작되기 전에 활성화된 소스는 에이전트의 프로젝트 컨텍스트에 포함됩니다. 저장소 로컬 설정도 마찬가지입니다.@임포트를 통해 다른 지침 파일을 불러올 수 있습니다. 중복된 임포트, 순환 참조 및 동일한 지침 내용은 한 번만 포함됩니다. 이러한 지침을 앱 컨텍스트 항목에 복사할 필요는 없습니다.

에서설정 → 지식 → 컨텍스트, 저장소 소스는 에이전트가 수신할 파일을 제어하며,앱 컨텍스트에는 수동으로 작성한 노트와 Coroid에 저장된 생성된 컨텍스트가 포함됩니다. 명시적으로 비활성화하지 않는 한 소스는 모두 활성화되며, 결합을 원하지 않는 중복되거나 상충되는 지침은 끄면 됩니다.

저장소의 지침은 Git 내 코드와 함께 관리됩니다. 앱 컨텍스트는 저장소 외부에 보관하는 안내 및 참고 자료용으로 유용합니다. 규칙이 변경될 때는 둘 다 업데이트해야 합니다.프로젝트 컨텍스트 설정에서 지원되는 경로, 파일 감지 및 제어 방법을 확인하세요.

Coroid가 스스로 판단하는 내용#

저장소만으로도 에이전트는 다음 정보를 확인할 수 있습니다:

• 사용 중인 언어, 프레임워크 및 라이브러리
• 프로젝트의 빌드, 테스트 및 실행 방식
• 기존 패턴 — 오류 처리 방식, 모듈 구조, 명명 규칙 등
• 의존 관계

이러한 내용을 별도로 문서화할 필요는 없습니다. 다시 적는 것은 불필요한 노력이며 코드보다 구식이 될 위험도 있습니다. 코드가 더 신뢰할 수 있는 정보원이기 때문입니다.

추론할 수 없는 내용#

코드는_무엇을_했는지는 보여주지만,왜:

• 명백한 대안보다 특정 라이브러리를 선택한 이유가 여전히 유효한 경우
• 중복처럼 보이지만 의도적인 구분선인 패턴
• 특정 팀과 상의 없이는 건드리면 안 되는 모듈
• 합의는 했지만 아직 적용되지 않은 규칙
• 코드베이스 외부의 제약 조건 — 규제, 계약, 진행 중인 마이그레이션 등

이것이 바로 프로젝트 컨텍스트에 포함되어야 할 내용입니다. 간단한 기준은 다음과 같습니다:저장소만 읽어도 이를 파악할 수 있는가?그렇다면 포함시키지 마세요. 그렇지 않다면 반드시 기록해 두세요.

컨텍스트 추가하기#

프로젝트의 컨텍스트 섹션에 문서, 정책 및 참고 자료를 첨부하세요.컨텍스트섹션에 아키텍처 노트, 의사결정 기록, 스타일 가이드 및 API 계약서 등을 포함할 수 있습니다.

좋은 컨텍스트는 짧고 구체적입니다. 사람을 위한 40페이지 분량의 온보딩 가이드는 대부분 서술형 내용이며, 실제 제약 조건을 명시한 세 단락만이 중요합니다. 이 부분만 추출하세요.

작업별 컨텍스트#

프로젝트에 첨부된 컨텍스트는 모든 작업에 적용됩니다. 특정 작업—티켓, 설계 문서, 고객 보고서—과 관련된 내용은 그 작업에 직접 첨부하세요.

프로젝트 컨텍스트에는 영구적으로 유효한 정보만 저장하세요. 특정 작업에 한정된 메모가 프로젝트 컨텍스트에 포함되면 향후 모든 작업에서 불필요한 잡음으로 작용합니다.

정확성을 유지하기#

시간이 지나서 더 이상 유효하지 않은 컨텍스트는 아예 컨텍스트가 없는 것보다 더 해롭습니다. 왜냐하면 에이전트들이 이를 권위 있는 정보로 간주하기 때문입니다. 규칙이 변경될 경우 코드 변경과 동일한 커밋에서 컨텍스트도 함께 업데이트해야 합니다.

재작업 관련 코멘트에서 동일한 내용을 반복적으로 수정하고 있다면, 이는 컨텍스트에 누락된 정보가 있거나 컨텍스트 내의 일부 내용이 잘못되었음을 나타내는 신호입니다.

관련 항목#

• 단계별 역량 향상
• 사양
• 프로젝트 컨텍스트 설정