에이전트는 저장소를 읽어들입니다. 이를 통해 필요한 대부분의 정보를 확보하지만, 사람의 머릿속에 있거나 위키·과거 대화 속에 남아 있는 결정 사항은 파악할 수 없습니다.
프로젝트 컨텍스트여기에 나머지 정보를 입력하면 됩니다.
Coroid가 스스로 판단하는 내용
저장소만으로도 에이전트는 다음을 확인할 수 있습니다:
- 사용 중인 언어, 프레임워크 및 라이브러리
- 프로젝트의 빌드, 테스트 및 실행 방식
- 기존 패턴 – 오류 처리 방식, 모듈 구조, 명명 규칙 등
- 의존 관계
이러한 내용을 별도로 문서화할 필요는 없습니다. 다시 작성하는 것은 불필요한 노력일 뿐이며, 코드가 더 신뢰할 수 있는 정보원이므로 내용이 뒤처질 위험도 있습니다.
추론할 수 없는 내용
코드는무엇을했는지는 보여주지만,왜 그랬는지는 알 수 없습니다.:
- 명백한 대안보다 특정 라이브러리를 선택한 이유가 여전히 유효한 경우
- 중복처럼 보이지만 의도적으로 만든 구분선인 패턴
- 특정 팀과 상의하지 않고는 건드려서는 안 되는 모듈
- 합의는 했지만 아직 적용되지 않은 규칙
- 코드베이스 외부의 제약 사항 – 규제 준수 요건, 계약 조건, 진행 중인 마이그레이션 등
이것이 바로 프로젝트 컨텍스트에 포함되어야 할 내용입니다. 판단 기준은 간단합니다:**저장소만 읽어도 누군가 이를 파악할 수 있을까요?**그렇다면 굳이 포함할 필요가 없고, 그렇지 않다면 반드시 기록해 두세요.
컨텍스트 추가하기
문서, 정책 및 참고 자료를 해당 프로젝트의컨텍스트섹션에 첨부하세요. 아키텍처 노트, 의사결정 기록, 스타일 가이드 및 API 계약서 등 모두 활용할 수 있습니다.
좋은 컨텍스트는 짧고 구체적이어야 합니다. 사람을 위한 40페이지 분량의 온보딩 가이드 중 실제 제약 사항을 명시한 단락 세 개가 핵심입니다. 이 부분만 추출하세요.
작업별 컨텍스트
프로젝트에 첨부된 컨텍스트는 모든 작업에 적용됩니다. 특정 업무와 관련된 내용이라면 – 티켓, 설계 문서, 고객 보고서 등 – 해당 작업에 직접 첨부하세요.
영구적으로 변하지 않는 정보는 프로젝트 컨텍스트에 저장하세요. 작업별 메모를 프로젝트 컨텍스트에 넣으면 향후 모든 작업에서 불필요한 잡음이 발생합니다.
정확하게 유지하기
오래된 컨텍스트는 아예 없는 것보다 더 해롭습니다. 에이전트가 이를 권위 있는 정보로 간주하기 때문입니다. 규칙이 바뀌면 코드를 수정하는 것과 동시에 컨텍스트도 업데이트해야 합니다.
리워크 코멘트에서 동일한 내용을 반복적으로 수정해야 한다면, 이는 컨텍스트에 누락된 정보가 있거나 잘못된 내용이 포함되어 있다는 신호입니다.