Cursor는 왜 내 아키텍처 결정을 잊어버리나요?

Cursor는 아키텍처 결정을 잊어버립니다. 그 이유는 프로젝트 규칙이 행동을 설명할 뿐 이유를 설명하지 않으며, 기억은 채팅에서 파생된 짧은 요약이고, /docs의 ADR은 검색이 이를 드러낼 때만 프롬프트에 나타나기 때문입니다. 결정 맥락이 없을 때 모델은 산업 표준 아키텍처로 기본 설정됩니다. 해결책은 Cursor가 아키텍처를 제안하기 전에 읽는 쿼리 가능한 기억으로 결정을 노출하는 것입니다.

Cursor는 리포지토리를 인덱싱하고 턴당 관련 청크를 검색합니다. 아키텍처 결정은 세 가지 이유로 그 파이프라인을 통과하지 못합니다.

1. 이유는 무엇보다 검색하기 어렵습니다. 코드베이스 인덱싱은 코드를 잘 드러내지만, 산문은 덜 신뢰할 수 있습니다. /docs/adr/0017-single-postgres.md의 ADR은 검색이 현재 쿼리와 관련성이 있다고 점수를 매길 때만 프롬프트에 들어갑니다. "새 서비스를 추가하고 있습니다"는 결정 문서에 높은 점수를 주지 않습니다.

2. 프로젝트 규칙은 규칙만 담고 이유는 담지 않습니다. "단일 Postgres를 사용하라"는 규칙은 시행 가능합니다. "우리는 일관성 모델을 위해 서비스 간 두 단계 커밋이 용납되지 않기 때문에 단일 Postgres를 선택했습니다"라는 설명은 .mdc 프론트매터에 맞지 않으므로, 이론이 사라지고, 모델은 표면 작업이 두 번째 DB를 요구하는 것처럼 보일 때마다 규칙과 충돌합니다.

3. 기억은 요약이지 결정 기록이 아닙니다. Cursor의 기억은 채팅에서 짧은 규칙을 자동 생성합니다. 이는 결정 로그가 아닙니다. 아키텍처 선택을 알리는 이유, 고려된 트레이드오프, 중요한 제약 조건은 구조화된 기억으로 남지 않습니다.

결과적으로: Cursor는 결정이 맥락에 있을 때는 따르지만, 그렇지 않을 때는 이를 무시합니다.

잊혀진 결정은 재논의와 때로는 재구현의 비용을 초래하며, 이 비용은 서비스의 수명 동안 누적됩니다:

• 정리된 논쟁이 다시 열립니다. "우리는 JSONB 쿼리와 트랜잭션 무결성 때문에 Postgres를 Mongo보다 선택했습니다"는 보이지 않게 되고, Cursor는 3개월 후 다시 Mongo를 제안합니다.
• 제약 조건이 위반됩니다. "우리는 콜드 스타트 예산 때문에 엣지 함수에서 내부 서비스를 호출하지 않습니다"는 생성된 엣지 핸들러에서 무시됩니다.
• 새 서비스가 표준에서 벗어납니다. Cursor는 새로운 서비스에 대해 웹에서 가장 일반적인 패턴을 선택하며, 이는 당신의 플랫폼 팀이 표준화한 것이 아닙니다.

해결책은 "모든 ADR을 .mdc 규칙으로 만들기"가 아닙니다. 이는 아무도 유지 관리하지 않는 산문으로 규칙 폴더를 넘쳐나게 합니다. 해결책은 결정을 쿼리 가능한 기억으로 노출하여 그 이론을 온전하게 유지하는 것입니다.

Cursor는 여기에서 실제 기능을 출시했습니다. 그러나 그들 중 어느 것도 간극을 완전히 메우지는 못합니다.

*프로젝트 규칙 (`.cursor/rules/.mdc)**은 ADR의 규칙을 인코딩할 수 있으며, 프론트매터와 글로브를 사용하여 언제 발동할지를 제어합니다. 이는 시행 가능한 결론에 좋습니다. 그러나 이론에는 약합니다. alwaysApply` 규칙은 프롬프트 예산을 공유하고 긴 규칙 산문은 잘립니다.

기억은 채팅에서 짧고 자동 생성된 지침을 캡처합니다. 이는 "우리는 런타임 검증을 위해 Zod를 사용합니다"에는 좋지만, "우리는 2024년에 정적 타입 추론을 위해 Zod를 Yup보다 선택했으며, 이 결정을 분기마다 재검토합니다"에는 좋지 않습니다.

네이티브 MCP 지원은 Cursor가 .cursor/mcp.json 또는 설정 UI를 통해 외부 기억에 연결할 수 있게 해줍니다. 이는 아키텍처 결정을 위한 가장 깔끔한 경로입니다. 왜냐하면 MCP는 규칙으로 압축하는 대신 이론과 함께 전체 ADR을 필요에 따라 노출할 수 있기 때문입니다.

Cursor의 MCP 설정 가이드는 공식 Cursor 문서에서 확인할 수 있습니다.

작은 리포지토리의 경우, 규칙과 인덱싱이 이를 처리합니다. 실제 아키텍처가 있는 시스템의 경우, 결정이 미끄러집니다.

더 깊은 문제는 아키텍처 결정이 규칙이 아닌 추론 산물이라는 것입니다. 이들은 Cursor가 무언가를 제안할 때마다 그 이유, 대안 및 날짜와 함께 전체적으로 검색 가능해야 합니다. 또한 팀이 사용하는 모든 AI 편집기에서 적용되어야 합니다. 그렇지 않으면 Claude Code의 한 팀원이 당신이 스프린트 동안 제거한 패턴을 다시 도입할 수 있습니다.

이것이 크로스 툴 기억 계층이 해결하는 문제입니다: 하나의 결정 기록, 필요 시 검색 가능하며, 팀의 모든 AI 편집기에서 공유됩니다.

MemoryLake는 당신과 사용하는 모든 AI 사이에 위치한 크로스 모델 기억 계층입니다. /docs의 ADR이 중요할 때 검색될 것이라고 믿는 대신, 당신은 MemoryLake 프로젝트에 결정을 저장하고, Cursor는 MCP를 통해 턴당 관련 결정을 가져옵니다.

• 쿼리 가능한 기억으로서의 결정. 각 ADR은 규칙, 이론, 대안 및 날짜가 포함된 구조화된 기억으로 존재합니다. Cursor는 압축된 한 줄이 아니라 전체 기록을 검색합니다.
• 결정에 대한 Git 스타일 버전 관리. ADR이 대체될 때, MemoryLake의 버전 관리가 대체를 추적하여 오래된 결정이 조용히 다시 나타나지 않도록 합니다.
• 모든 다른 AI 코딩 도구로 이식 가능. 동일한 결정 기억이 Claude Code, Cline, Windsurf 및 모든 MCP 인식 편집기에서 작동합니다. 다른 도구의 팀원이 실수로 더 이상 사용되지 않는 패턴을 다시 도입할 수 없습니다.

MemoryLake는 LoCoMo 긴 맥락 벤치마크에서 94.03%를 기록했으며, 2026년 기준으로 발표된 최고 결과로, 밀리초 검색 및 AES-256 종단 간 암호화를 제공합니다.

1. 프로젝트를 생성하고 결정을 로드합니다. MemoryLake에 로그인하고 프로젝트 관리로 이동하여 프로젝트 생성 버튼을 클릭하고 시스템 이름(예: "Cursor - 결제 플랫폼 아키텍처")으로 이름을 지정합니다. ADR과 설계 문서를 문서 드라이브에 드롭합니다. 각 결정을 주제별로 검색 가능하도록 기억 탭에 구조화된 항목으로 헤드라인 결론과 이론을 캡처합니다.
2. MCP 서버 엔드포인트를 생성합니다. 프로젝트 내의 MCP 서버 탭을 열고 MCP 서버 추가를 클릭한 후 "Cursor 통합"이라는 이름을 지정하고 생성 버튼을 클릭합니다. MemoryLake는 API 키 ID, 비밀 및 엔드포인트 URL을 반환합니다. 비밀은 한 번만 표시되므로 즉시 복사합니다.
3. Cursor를 연결합니다. Cursor는 2025년부터 네이티브 MCP 지원을 제공하므로 가장 깔끔한 경로입니다. 리포지토리 루트의 .cursor/mcp.json에 MemoryLake 서버 항목을 추가하거나 Cursor 설정 > 기능 > MCP를 통해 연결하고, 엔드포인트 URL과 Bearer 토큰을 붙여넣고 Cursor를 다시 로드합니다. 이제 Cursor는 아키텍처를 제안하거나 새로운 서비스를 연결하기 전에 결정 기록을 쿼리할 수 있습니다.