옮기기 전에: 무엇이 달라지는가#
Cursor를 바로 삭제하지 말고 기존 작업을 보관한 상태에서 작은 프로젝트로 병행해 보세요. Mirr에서 읽기나 MCP 연결을 포함한 어떤 작업을 요청하기 전에도 Yolo를 끄고 Ask 모드를 선택한 뒤 작업별 권한 규칙을 확인하세요. 저장소에 남는 파일과 각 도구가 별도로 관리하는 설정은 다릅니다. 아래는 공식 문서에서 확인한 기능과 이전 시 직접 확인할 항목입니다. 자동 이전을 검증한 결과는 아닙니다.
옮겨지는 것과 안 옮겨지는 것 (table)#
공개 보류 조건: 원래 이전 가이드는 확장·규칙·결제의 전환 표를 제품 문서로 확인한 뒤 공개하도록 정했습니다. Mirr에서의 규칙·확장·설정 호환과 실제 이전은 아직 검증되지 않았습니다. 아래 표는 확인할 목록이며 완료된 이전 표가 아닙니다.
| 항목 | 기존 환경에서 확인할 것 | Mirr로 전환할 때 |
|---|---|---|
| 저장소와 변경 사항 | Git 저장소의 커밋과 작업 디렉터리의 변경 사항 | 같은 디렉터리를 사용하면 파일과 Git 기록을 확인할 수 있습니다. 별도 복제본에는 미커밋 변경이 자동으로 포함되지 않으므로 먼저 보관하세요. |
| 규칙 | Cursor 프로젝트 규칙은 .cursor/rules의 .mdc 파일이며 적용 범위가 있습니다. | 자동 적용 여부는 확인되지 않았습니다. 규칙의 내용과 적용 범위를 검토해 필요한 지침을 직접 전달하고 동작을 확인하세요. |
AGENTS.md | Cursor 규칙 문서는 프로젝트 루트와 하위 디렉터리의 AGENTS.md를 설명합니다. | 파일이 남더라도 Mirr가 동일하게 읽거나 적용하는지는 확인되지 않았습니다. 내용과 적용 범위를 별도로 검토하세요. |
| 훅 | Cursor 훅은 이벤트에 맞춰 스크립트를 실행할 수 있습니다. | 자동 이전과 동등한 훅 동작은 확인되지 않았습니다. 보안상 필수인 검사는 기존 CI나 별도 통제로 유지하세요. |
| MCP | Cursor MCP 문서에서 연결 설정 방식을 확인하세요. | 자동 이전 여부는 확인되지 않았습니다. 필요한 연결만 Mirr MCP 안내에 따라 다시 설정하고 권한을 확인하세요. |
| 대화·세션 | 기존 대화 기록과 필요한 결정 사항 | Mirr로 대화가 이전되는지는 확인되지 않았습니다. 민감정보를 제외한 작업 맥락만 직접 정리하세요. |
| 편집기 설정·확장 | 테마, 단축키, 확장 기능 | 호환성이나 자동 이전은 확인되지 않았습니다. 기존 편집기를 유지하면서 필요한 기능을 개별 확인하세요. |
Cursor 규칙, 에이전트 보안, 훅, MCP 문서는 2026-11-03에 확인했습니다. 연결된 Mirr 문서는 MCP 기준 2026-10-16 검증으로 표시되어 있으며, 이 표는 실제 이전 결과가 아닙니다.
설치와 로그인#
운영체제별 명령, 버전 확인과 로그인은 Mirr 설치 문서를 따르세요. 이 문서의 검증일 표시는 2026-10-15입니다. 실행 전 설치 스크립트의 출처와 조직 정책을 확인하세요.
남은 검증: 이 페이지에서는 설치와 로그인을 직접 실행하지 않아 transcript가 없습니다.
규칙과 MCP 다시 연결#
- Cursor의 프로젝트·개인·팀 규칙,
AGENTS.md와 훅을 목록화하고, 보안상 필수인 통제가 무엇인지 구분합니다. 원본은 보관하고 자동 호환을 가정하지 마세요. - 필요한 지침만 민감정보를 제외해 Mirr 작업에 직접 전달합니다. 규칙의 범위와 강제 방식이 같은지 확인되지 않았으므로 결과를 검토하세요.
- 필요한 MCP 서버의 공식 주소와 인증 방식을 확인한 다음 Mirr의
/mcp안내에 따라 연결합니다. 서버 출처와 제공 도구를 검토하고 가능하면 읽기 전용 권한부터 부여하세요. - 토큰·비밀번호는 대화, 프로젝트 파일, 공유 로그에 넣지 마세요. 연결 제거와 서비스 측 권한 철회는 별도로 확인합니다.
남은 검증: 실제 규칙 전환과 MCP 재연결 transcript는 아직 없습니다.
규칙이 적용되지 않는 것 같다면 파일이 남아 있다는 사실과 실제 적용을 구분하세요. 필요한 지침을 요청에 직접 포함하고 적용 여부를 작은 결과로 확인합니다. MCP 도구가 안 보이면 이전 설정을 통째로 복사하지 말고 서버 주소·인증·노출 도구를 각각 확인하세요. 필수 보안 훅의 동등성이 확인되기 전에는 기존 통제를 해제하지 않습니다.
Cursor 규칙 네 종류와 적용 순서#
Cursor의 지침은 네 곳에 나뉘어 있습니다. 프로젝트 규칙은 저장소의 .cursor/rules에 두고 버전 관리에 포함합니다. 사용자 규칙은 Customize의 Rules에서 모든 프로젝트에 적용하는 개인 선호로 설정합니다. 팀 규칙은 대시보드에서 관리하며 Team과 Enterprise 요금제에서만 쓸 수 있습니다. 프로젝트 루트와 하위 폴더의 AGENTS.md도 지침으로 읽히는데, 하위 폴더의 파일은 상위 지침과 합쳐지고 더 구체적인 지침이 우선합니다. Cursor 문서는 루트에는 전체 지침을, 프런트엔드와 그 안의 컴포넌트 폴더에는 해당 영역의 지침을 두는 예시를 보여 줍니다.
프로젝트 규칙 파일은 머리말 정보가 있는 .mdc 파일이어야 인식됩니다. .md 확장자로 .cursor/rules에 둔 파일은 규칙 시스템에서 무시됩니다. 규칙은 항상 적용, 설명을 보고 에이전트가 관련성을 판단해 적용, 특정 파일 패턴에 맞을 때 적용 중 하나로 설정하며, 관련성 판단 방식은 설명이 정의되어 있어야 작동합니다.
여러 지침이 겹치면 팀 규칙, 프로젝트 규칙, 사용자 규칙 순서로 적용됩니다. 해당하는 규칙은 함께 들어가고, 지침이 충돌하면 앞의 출처가 우선합니다. 팀 규칙에서 강제 적용을 켠 항목은 구성원이 Customize에서 끌 수 없습니다. Cursor 문서는 이런 규칙이 있어도 AI 지침을 유일한 보안 통제로 삼으면 안 된다고 덧붙입니다. 팀 규칙은 자유 형식 텍스트이며 프로젝트 규칙처럼 폴더 구조를 쓰지 않습니다. 팀 규칙에도 글롭 패턴을 걸 수 있고, 패턴이 없는 규칙은 모든 대화에 들어갑니다.
훅 파일 위치와 실패 시 동작#
Cursor 훅은 프로젝트의 .cursor/hooks.json이나 사용자 홈의 ~/.cursor/hooks.json에 정의합니다. 프로젝트 훅은 프로젝트 루트에서 실행되므로 스크립트 경로를 루트 기준으로 적으세요. 프로젝트 훅은 그 프로젝트에만 적용되고, 홈 디렉터리의 훅은 모든 프로젝트에 적용됩니다. 설정 파일을 고치면 Cursor가 자동으로 다시 읽습니다. 훅 스크립트는 표준 입출력으로 JSON을 주고받는 별도 프로세스입니다. Windows에서는 데스크톱 앱이 훅 명령을 PowerShell로 실행하고 JSON을 명령에 넘기므로, 스크립트가 입력을 읽는 방식도 운영체제에 맞춰 확인하세요. 훅은 셸 명령 실행 전후, MCP 실행 전후, 파일 읽기와 편집, 세션 시작과 종료, 하위 에이전트의 시작과 종료 같은 이벤트에 걸 수 있습니다. 스크립트 대신 LLM이 자연어 조건을 판단하는 프롬프트형 훅도 있지만, 클라우드 에이전트에서는 명령형 훅만 쓸 수 있습니다.
실패 처리 규칙이 중요합니다. 종료 코드 0은 성공이며 JSON 결과를 씁니다. 종료 코드 2는 작업을 차단하며, JSON 응답에서 권한을 deny로 돌려준 것과 같은 효과입니다. 권한을 판단하는 훅이 종료 코드 0을 내면서 JSON이 잘못되어도 작업은 차단됩니다. 그 밖의 종료 코드로 실패한 훅은 작업을 그대로 진행시킵니다. 따라서 훅으로만 막고 있던 검사는 훅이 실행되지 못하는 순간 통과될 수 있습니다. 클라우드 에이전트는 명령형 훅만 실행하고, 사용자 홈의 훅 파일은 포함하지 않습니다. 클라우드 에이전트는 처음 몇 턴을 읽기 전용 환경에서 시작하며, 그 턴에는 훅이 실행되지 않는다고 Cursor 문서가 설명합니다. 팀이 함께 쓸 훅은 프로젝트 파일로 두어야 합니다.
Mirr 한국어 문서에는 훅 설정 파일의 위치나 실패 처리 방식이 나오지 않습니다. 따라서 Cursor 훅과 같은 보장을 Mirr에서 기대할 근거는 문서에 없습니다.
MCP 설정 파일과 승인 방식#
Cursor의 MCP 설정은 프로젝트의 .cursor/mcp.json과 사용자 홈의 ~/.cursor/mcp.json에 둡니다. 인증 값은 설정에서 환경 변수로 넘깁니다. 원격 서버가 OAuth를 요구하면 Cursor는 PKCE를 쓰는 인증 코드 흐름으로 로그인하고, 갱신 토큰이 있으면 만료 때 자동으로 갱신합니다. 갱신 토큰이 없으면 만료될 때마다 다시 로그인해야 합니다.
Cursor는 MCP 연결을 처음 승인받은 뒤에도 도구 호출마다 개별 승인을 요구합니다. 실행 모드도 터미널 명령과 같은 규칙을 따릅니다. 서버 연결 승인과 도구 호출 승인은 다른 단계이므로, 옮긴 뒤에도 두 단계를 따로 확인하세요. 자주 쓰는 도구는 MCP 허용 목록에 넣어 미리 승인해 둘 수 있습니다.
Mirr는 /mcp에서 서버를 추가하고, 연결 상태와 제공 도구를 보고, 제거합니다. Mirr 한국어 문서는 연결 정보를 어느 파일에 저장하는지 설명하지 않으므로, Cursor의 mcp.json을 옮겨 쓸 근거는 없습니다. 서버마다 주소와 인증을 /mcp에서 새로 등록하고 연결 상태를 확인하세요.
실행 모드와 파일 접근 범위#
Cursor의 실행 모드는 셸 명령, MCP 도구, 가져오기 호출을 얼마나 자주 묻는지 정합니다. 자동 검토(Auto-review)는 알려진 안전한 호출을 바로 실행하고, 샌드박스가 가능한 셸 명령은 샌드박스에서 돌리며, 나머지는 분류기가 검토합니다. 허용 목록(Allowlist) 모드는 목록에 있는 호출만 묻지 않습니다. 모든 호출 실행(Run Everything) 모드는 묻지 않고 샌드박스도 쓰지 않습니다. 데스크톱 앱에서는 설정의 Agents 메뉴에 있는 Approvals & Execution에서 고릅니다. 허용 목록 모드에서도 샌드박스를 켜면 지원되는 셸 명령은 샌드박스에서 실행됩니다. 샌드박스는 실행 모드 위에 얹힌 층이어서 명령이 어디서 도는지만 정하고, 분류기를 쓸지 여부는 바꾸지 않습니다. 자동 검토 모드에서는 허용 목록에 든 MCP 도구가 바로 실행되고 나머지는 분류기로 넘어갑니다.
Cursor 문서는 자동 검토가 보안 경계가 아니라고 밝힙니다. 분류기가 허용해야 할 호출을 막거나 막아야 할 호출을 허용할 수 있습니다. 분류기는 Cursor 백엔드에서 실행되며, 판단에 필요하면 로컬 파일을 읽기 전용 도구로 읽을 수 있습니다. 전체 네트워크 접근이나 작업 공간 밖 쓰기처럼 샌드박스로 할 수 없는 명령은 분류기로 넘어갑니다. 샌드박스 안 명령이 권한 오류로 실패하면 에이전트가 샌드박스 밖에서 다시 실행할 수 있고, 이 재실행도 분류기가 검토합니다. 파일 접근에도 기본값이 있습니다. 파일 읽기와 코드 검색은 승인이 필요 없고, 민감한 정보를 드러낼 수 있는 작업만 승인을 요구합니다. 작업 공간 파일은 설정 파일을 제외하고 승인 없이 바뀔 수 있으며, 변경 사항은 바로 디스크에 저장됩니다. 에이전트 접근에서 특정 파일을 빼려면 .cursorignore를 씁니다.
기본 네트워크 범위도 좁습니다. Cursor 도구는 GitHub, 직접 링크 가져오기, 웹 검색 제공자에만 요청을 보내며, 기본 설정에서는 임의의 네트워크 요청을 보낼 수 없다고 설명합니다. Mirr 한국어 문서에서는 이런 파일과 네트워크 범위가 확인되지 않으므로 옮긴 뒤 작은 파일과 공개 주소로 직접 확인하세요.
Mirr 설정 파일과 언어 설정#
Mirr의 설정 파일은 개인 설정과 프로젝트 설정으로 나뉩니다. 개인 설정은 macOS와 Linux에서 ~/.mirr/config.toml, Windows에서 %APPDATA%\mirr\config.toml에 있고, 프로젝트 설정은 프로젝트 폴더의 mirr.toml입니다. 공통으로 지원되는 값은 기본값, 개인 설정, 프로젝트 설정, 실행할 때 지정한 옵션 순서로 우선합니다. Mirr 문서에는 Cursor 설정을 자동으로 변환하는 기능이 없으므로 필요한 항목만 직접 옮기세요.
응답과 화면의 언어는 입력창에서 /language ko, /language en, /language auto로 바꾸고, 색 테마는 /theme에서 고릅니다. 프로젝트에서만 고정하려면 mirr.toml의 최상위 language 항목을 설정하되, 기존 파일을 고칠 때는 그 항목만 바꾸라고 안내합니다.
반복 지침과 개인·프로젝트 설정 나누기#
Cursor에서 반복해서 쓰던 작업 지침은 Mirr에서 스킬로 옮기는 것이 한 방법입니다. Mirr 설정 안내에 따르면 반복 작업 지침은 /skills에서 설치된 스킬로 확인하며, 스킬은 작업 지침이고 MCP는 외부 도구를 연결하는 방식, 패키지는 확장 기능을 묶는 배포 단위입니다. 다만 Cursor 규칙 파일을 스킬로 자동 변환하는 방법은 Mirr 문서에 없습니다. 스킬을 새로 설치하기 전에는 출처와 제공 기능을 확인하세요.
나눌 때는 적용 대상으로 구분하세요. 개인 취향은 개인 설정 파일에, 저장소 전체가 함께 써야 하는 값은 프로젝트의 mirr.toml에 두는 것이 Mirr 설정 안내의 구분입니다. Mirr 문서에는 팀 규칙처럼 구성원에게 강제하는 기능이 나오지 않으므로, 강제가 필요한 규칙은 저장소 문서나 검토 절차로 따로 유지하세요.
적용 범위를 요청 문장으로 옮기기 (제안, 미실행)#
Cursor 문서의 사용자 규칙 예시는 간결하게 답하고 불필요한 반복과 군더더기를 피하라는 문장입니다. 이 문장을 Mirr로 옮길 때는 규칙 파일 대신 요청 첫머리에 직접 적는 방식을 제안합니다. 예를 들면 이번 작업의 답변은 간결하게, 같은 설명을 반복하지 말고 작성해 달라고 한 번에 적는 식입니다. 이것은 실행하지 않은 문장 제안이며, 결과가 같은지는 같은 작업을 두 도구에서 비교해야 알 수 있습니다.
Cursor의 파일 패턴 규칙은 패턴에 맞는 파일이 맥락에 들어올 때만 적용됩니다. Mirr 한국어 문서에는 경로 조건으로 지침을 자동 적용하는 기능이 나오지 않으므로, 그런 규칙은 해당 경로에서 작업할 때 요청에 경로와 조건을 명시해야 합니다.
MCP 서버 목록 정리 항목#
옮기기 전에 Cursor의 mcp.json 항목마다 세 가지를 적어 두면 Mirr에서 다시 등록할 때 빠뜨리는 것을 줄일 수 있습니다. 첫째, 로컬 명령을 실행하는 방식인지 원격 주소를 쓰는 방식인지입니다. Cursor 문서는 명령과 인수, 환경 변수를 적는 방식과 원격 주소와 OAuth 설정을 적는 방식을 나눠 설명합니다. 둘째, 인증 값이 환경 변수인지 OAuth인지입니다. 셋째, 서버가 노출하는 도구 중 실제로 쓰는 것이 무엇인지입니다. Cursor는 도구 호출마다 승인을 묻지만, 목록을 정리해 두면 Mirr의 /mcp 도구 목록에서 필요한 도구만 골라 확인할 수 있습니다.
첫 작업: 읽기 → 수정 → 테스트#
- 커밋되지 않은 변경과 Git이 추적하지 않는 파일,
.cursor폴더의 규칙과 훅 파일을 별도 위치에 백업하고 복구 가능 여부를 확인합니다. 운영 데이터나 민감정보가 없는 작은 과제를 고르고, 추가 격리가 필요하면 별도 브랜치에서 작업하세요. - 어떤 작업을 요청하기 전에도 작업 모드에서 Yolo가 켜져 있으면 끄고 Ask를 선택해 표시를 확인합니다. 도구별 권한 규칙도 확인하세요. Cursor의 자동 검토와 허용 목록 설정이 Mirr로 옮겨진다는 근거는 없으므로 Mirr 규칙을 직접 확인합니다. Yolo를 끄는 것만으로 모든 실행에 승인이 보장되지는 않습니다. 읽기와 계획부터 요청하고 승인 요청의 경로와 명령을 검토하세요.
- 범위를 정해 수정을 요청하고 diff를 직접 검토합니다. 승인된 테스트 명령이 외부 데이터를 바꾸지 않는지도 확인한 뒤 실행합니다.
- 결과와 실패를 기록하고 필요한 규칙·권한을 조정한 후에만 적용 범위를 넓힙니다.
남은 검증: 실제 첫 작업의 diff와 테스트 출력은 아직 수집하지 않았습니다.
옮긴 뒤 확인할 시험 (제안, 미실행)#
아래 시험은 실행하지 않은 제안입니다. 작은 샘플 저장소에서 Cursor 사용자 규칙 하나를 골라 같은 문장을 요청하고, 두 도구의 응답 길이와 언어를 날짜와 함께 기록하세요. 이 비교는 Cursor 규칙이 Mirr에 적용되는지 보여 주지 않으며, 응답 결과만 비교합니다. 나중에 같은 조건으로 다시 비교하려면 두 도구의 버전과 설정 파일 내용도 함께 적어 두세요.
훅은 Cursor에서 샘플 스크립트를 종료 코드 2로 바꿔 차단되는지 확인하는 방식으로 옮기기 전에 점검할 수 있습니다. 이 결과는 Cursor의 동작 기록일 뿐 Mirr에서 같은 결과가 나온다는 근거가 되지 않습니다. MCP는 읽기 전용으로 쓸 수 있는 서버 하나를 연결해, /mcp의 연결 상태와 제공 도구 목록이 기대와 같은지 확인하세요.
실행 모드 차이도 같은 방식으로 기록할 수 있습니다. Mirr에서는 Ask 모드로 시작해 셸 명령 하나가 승인 요청을 띄우는지 보고, Cursor의 자동 검토에서 같은 명령이 샌드박스 안에서 바로 도는지 비교하세요. 두 도구의 승인 기준이 같다고 가정하지 말고, 요청 목록과 결과를 날짜별로 남기세요.
되돌리기#
- 작업을 멈추고 현재 변경 사항을 확인한 뒤 보존할 내용을 따로 저장합니다. 기존 Cursor 설정과 저장소를 유지했다면 그 환경에서 다시 작업할 수 있습니다.
- 파일 복구가 필요하면 백업이나 Git 기록을 기준으로 범위를 확인하세요. Mirr의
/rewind는 사용 가능한 체크포인트와 복구 범위에 제한이 있으며 백업을 대체하지 않습니다. 복구 안내를 확인하세요. - 외부 게시, 배포, 데이터베이스 변경은 해당 서비스의 복구 절차로 따로 처리합니다. Cursor 시절 연결했던 MCP 서버 가운데 쓰지 않는 것은 서비스에서 토큰 권한을 철회하세요.
데이터 처리는 각 서비스와 계정 조건을 따릅니다. Mirr와 모델 제공자, MCP 서비스의 전송 대상·저장 위치·보존 기간·삭제 절차는 계약과 현재 정책을 각각 확인하세요. Mirr의 보존 기간과 학습 사용 여부는 이 한국어 문서에서 확인되지 않습니다.
그래서 Mirr Code는?#
한국어로 끝까지 일하는 터미널 코딩 에이전트입니다. 한국어로 요청하고 한글 명령을 검색할 수 있습니다. 한국어 작업 안내에 따르면 HWP·HWPX에 관해 질문하거나 처리 코드 작성을 요청할 수 있지만, 실제 파일 읽기·수정·변환 지원은 연결된 도구에 따라 달라집니다.
가격은 Mirr Code 요금제, 모델은 Mirr 1.0 Pro를 참고하세요. 최신 영어 벤치마크나 방대한 생태계 자체가 목적이라면 기존 도구가 더 나을 수 있습니다.
| 결제 전환 확인 | 확인할 내용 |
|---|---|
| 기존 Cursor 구독 | 결제처와 관리 권한은 실제 계정의 결제 화면에서 확인하세요. |
| 기존 사용량 | 구독 방식별 사용량과 추가 청구는 실제 계정의 결제 화면에서 확인하세요. |
| Mirr 이용 조건 | Mirr 요금제에서 현재 요금과 이용 조건을 별도로 확인하세요. |
Cursor 결제와 해지 문서의 내용은 이 한국어 문서에서 확인되지 않았습니다. 실제 계정의 청구 상태와 해지 여부도 확인되지 않았습니다.
첫 과제의 전후 상태를 남기는 양식#
기준 상태에는 저장소 커밋뿐 아니라 미커밋·비추적 파일의 보관 여부도 포함합니다. 새 브랜치 이름만 적으면 원래 변경이 보호됐는지 알 수 없습니다. 작업 전에 어떤 파일이 이미 바뀌어 있었는지 기록하고 이번 과제에서 허용한 경로를 정하세요. 결과 검토에서는 이 경로와 실제 diff를 비교합니다. 다른 작업자가 동시에 수정한다면 파일 소유 범위와 검토 시점도 맞추세요.
| 기록 항목 | 작성할 내용 | 다음 판단에 쓰는 방법 |
|---|---|---|
| 기준 상태 | 커밋, 기존 변경과 별도 백업 위치 | 이번 과제의 변경을 분리 |
| 수용 기준 | 바꿀 동작과 그대로 둘 계약 | 결과가 요구를 충족하는지 판정 |
| 지침 적용 | 직접 전달한 규칙과 적용 경로 | 자동 호환 가정과 구분 |
| 실제 검사 | 명령, 대상, 실패와 미실행 항목 | 확대 전에 남은 검증 확인 |
| 외부 작업 | 승인 대상과 반영 여부 | 파일 복구와 별도로 정리 |
이 양식은 독자가 쓸 기록 제안입니다. 실제 Cursor에서 Mirr로 이전한 계정이나 저장소의 완료 보고서가 아닙니다. 제품 화면, 재연결 transcript와 실제 테스트 출력은 별도 증거로 확보해야 합니다.
Cursor에서 넘어올 때 옮겨지는 것과 남는 것을 구분해 기록하면, 첫 과제의 전후 상태가 더 읽기 쉬워집니다. 설정·규칙·MCP 연결이 새 환경에서 실제로 재연결되는지, 그리고 첫 과제를 돌렸을 때 어떤 파일이 바뀌고 어떤 명령이 실행되었는지를 따로 남깁니다. 이전 환경에서 '있었다'는 사실과 새 환경에서 '동작한다'는 사실은 별개이므로 한 문장으로 합치지 않습니다. 재연결과와 첫 작업 출력이 확보되기 전까지는 이동을 완료로 적지 않는 것이 안전합니다. 이 방식으로 나누면 실제 재연결이 안 된 항목과 아직 실행하지 않은 항목을 구분할 수 있고, 다음 단계에서 무엇이 남았는지 바로 알 수 있습니다.
관련#
편집 메모 (2026-11-02): 원래 호환성 공개 보류 조건을 명시하고 규칙·MCP 진단 및 복구 전 보관 범위를 보충했습니다. 규칙 비교 화면, 설치·로그인·MCP 재연결 transcript와 첫 작업 diff·테스트는 아직 없습니다. 상태나 검증일은 바꾸지 않았습니다.