커서 대안: 미르 코드(Mirr Code)가 맞는 경우와 계속 커서를 써야 하는 경우

30초 결론: Cursor를 떠나야 하는 사람과 남아야 하는 사람#

이 페이지는 아직 전체 검증을 마치지 않았습니다. 확인한 자료와 확인하지 못한 항목을 구분했습니다.

Cursor의 에디터와 클라우드 에이전트가 지금 하는 일에 잘 맞으면 유지할 이유가 있습니다. 한국어를 우선하는 터미널 작업이 주라면 Mirr Code도 살펴보세요. 옮기기 전에는 구독료뿐 아니라 확장, 프로젝트 규칙, MCP 연결을 다시 설정할 비용도 확인하세요.

한눈에 보기: Cursor와 미르 코드#

아래는 두 제품의 공개 자료에서 확인한 내용입니다. Cursor의 요금과 모델 조건은 신규 구독 기준입니다. 기존 구독은 다를 수 있습니다. Cursor 자료 확인일은 2026-11-01이고, Mirr의 현재 이용 조건은 요금제 페이지와 결제 화면에서 다시 확인하세요.

어디가 더 나은가: Cursor가 강한 경우 / 미르 코드가 맞는 경우 / 미르 코드가 아직 부족한 점#

Cursor는 에디터 안에서 작업하면서 클라우드 에이전트까지 쓰고 싶을 때 선택지가 넓습니다. 신규 구독에서 클라우드 에이전트를 쓰려면 Premium 이상 조건을 확인하세요. Mirr Code는 한국어를 우선하는 터미널 작업이 주라면 후보가 됩니다. 다만 Mirr Code에서 Cursor의 에디터 확장과 클라우드 작업을 같은 방식으로 쓸 수 있다는 근거는 아직 확인하지 못했습니다.

같은 과제를 비교할 때 확인할 점#

비교할 때는 민감 정보가 없는 합성 저장소를 쓰고, 각 서비스와 모델 제공자의 데이터 처리·보관 조건부터 확인하세요. Cursor 보안 안내와 Mirr 개인정보 처리방침을 참고하세요(2026-11-01 확인).

같은 과제를 두 도구로 실행한 기록은 아직 준비되지 않았습니다. 결과물이나 테스트 통과 여부를 비교할 근거도 없습니다. 직접 비교한다면 같은 저장소와 과제에서 변경 diff와 테스트 출력을 각각 확인하세요.

출처 확인(2026-11-03): 같은 Cursor 보안 안내의 Privacy Mode 항목에 따르면 이 설정은 설정 화면이나 팀·기업 관리자에서 켤 수 있습니다. 켜져 있으면 Cursor는 해당 데이터로 학습하지 않습니다. 무료·Pro 사용자 모두에서 쓸 수 있고, 새 팀원은 팀의 설정을 상속합니다. 이전 계획을 세울 때는 학습 여부보다 보관과 학습의 제어 주체를 먼저 적는 편이 정확합니다.

추가로 필요한 증거: 실행 기록과 테스트 출력은 아직 준비되지 않았습니다.

가격: 구독료와 모델 사용료#

2026-11-01에 확인한 신규 구독료와 모델별 과금 조건은 위 표에 있습니다. 공식 모델·요금 문서에 따르면 신규 구독에서 이용 가능한 타사 모델은 첫 요청부터 선불 크레딧으로 별도 과금됩니다. 신규 유료 구독에 포함된 Cursor 모델 사용량은 Grok과 공유하며 매주 갱신됩니다.

2026-11-01 확인 기준 Cursor 요금표는 신규 Plus에 Grok 모델만 사용 가능하다고 설명하지만, 모델 요금 문서는 Grok 외에 Composer 2.5도 명시합니다. 실제 이용 범위는 현재 계정과 결제 화면, 모델 선택기에서 확인하세요.

기존 Cursor 요금제 문서에 따르면 레거시 Pro·Pro+·Ultra와 Teams는 타사 모델 사용량을 포함하는 별도 월간 한도가 있습니다. 기존 구독의 가격과 조건은 변경하거나 해지하지 않는 한 유지됩니다. 자신의 구독 유형과 실제 청구 조건을 확인하세요.

Mirr의 현재 요금제를 살펴보고 결제 화면에서 선택한 상품의 금액과 이용 조건을 확인하세요.

옮기는 방법: 설치, 규칙, MCP, 첫 작업#

1. 기존 규칙 파일은 .mdc 형식으로 옮기고, 파일마다 적용 방식을 먼저 적으세요. 일반 .md 파일은 .cursor/rules에서 무시됩니다. 확장자만 바꾸고 끝내면 안 됩니다. 자동 이전은 검증되지 않았습니다.
2. 규칙을 옮긴 뒤 같은 작은 과제에서 diff와 테스트 결과를 직접 확인해 적용 여부를 판단하세요.

검증일 · 출처 · 관련 페이지#

전체 검증 상태: 미완료.

출처: Cursor 요금표, Cursor 문서, Cursor 모델·요금 문서, Mirr 요금제. 위 Cursor 자료와 Mirr 공개 요금제 페이지는 2026-11-01에 확인했습니다. 페이지 전체를 새로 검증한 것은 아닙니다.

아직 확인하지 못한 항목: 동일 리팩토링 과제의 Cursor diff와 Mirr Code 터미널 transcript·테스트 출력, 한글 파일명·한글 주석 저장소에서 검색·편집한 실제 작업 기록.

그래서 Mirr Code는?#

한국어를 우선하는 터미널 코딩 에이전트입니다. Cursor와 같은 과제로 비교한 실행 기록은 아직 없으므로 작업 결과나 성능 우열은 판단할 수 없습니다.

가격과 이용 조건은 요금제, 모델은 Mirr 1.0 Pro를 참고하세요. 결제 화면에서 선택한 상품과 조건을 확인하세요.

관련#

• 한국어로 작업하기

확장·규칙·청구 주체를 기준으로 보면 다음 후보도 비교할 수 있습니다. 공식 문서의 제공 방식에 근거한 선택지입니다. 같은 과제의 품질 순위는 아닙니다.

이 표는 이전할 항목을 빠뜨리지 않기 위한 문서 비교입니다. 호환성이나 이전 완료를 보여 주는 실행 기록은 아닙니다.

커서 구독 해지 전에 남길 작업 자산#

커서 대안을 고르는 첫 질문은 지금 불편한 일이 어디에서 생기는가입니다. 코드 제안이 마음에 들지 않는 경우와 회사가 허용한 모델을 선택할 수 없는 경우는 해결책이 다릅니다. 편집 화면이 불편한데 모델 구독을 바꾸거나, 청구가 문제인데 새 확장을 설치하면 원래 문제는 남습니다. 아래는 이전 결정을 위한 제안입니다 — 실제 전환 시간이나 절감액은 아직 측정하지 않았습니다.

현재 작업 하나를 처음부터 끝까지 적어 보세요. 이슈를 읽고, 파일을 찾고, 규칙을 확인하고, 코드를 고치고, 테스트를 보고, PR을 만드는 순서입니다. 단계마다 Cursor가 하는 일과 사람이 하는 일을 나눠 적어 보세요. 파일 탐색에 에디터 검색을 쓰고 코드 검토에 다른 프로그램을 쓴다면 모든 기능을 한꺼번에 대체할 필요가 없습니다. 반대로 에디터의 진단 표시를 보고 에이전트에 바로 수정을 맡긴다면 그 연결을 잃는 비용은 따로 시험해야 합니다.

자산 목록에는 확장 이름만 적지 마세요. 어떤 언어에서 무슨 명령을 쓰는지, 프로젝트 설정이 필요한지, 조직에서 설치를 관리하는지까지 적습니다. 저장할 때 실행되는 포맷터와 사람이 선택해서 실행하는 테스트는 다른 역할입니다. 터미널 도구에서 테스트를 실행할 수 있다고 해서 저장 시 포맷, 파일별 진단과 디버거 화면까지 옮겨졌다고 판단하면 안 됩니다. 기존 에디터를 유지하고 에이전트만 병행하는 안도 같은 목록으로 비교할 수 있습니다.

이 목록을 작성할 때 계정 비밀번호나 키 값은 필요하지 않습니다. 서버의 용도, 담당자와 승인 범위만 남겨도 이전 계획을 세울 수 있습니다. 개인 계정의 토큰을 동료에게 전달하는 방식으로 설정을 맞추지 마세요. 새 환경에서 필요한 연결만 정한 뒤 승인된 로그인 절차를 따르는 편이 비교 범위를 분명하게 만듭니다.

규칙은 파일보다 적용 조건을 옮깁니다#

출처 확인(2026-11-02): Cursor 규칙 문서. 문서는 프로젝트 규칙을 .cursor/rules의 .mdc 파일로 설명하며 항상 적용, 파일 패턴에 따른 적용, 설명에 따른 선택, 수동 호출을 구분합니다. 따라서 규칙 본문만 한 파일에 합치면 같은 뜻으로 적용된다고 볼 수 없습니다. 이 문서 확인은 새 도구에서 규칙이 실제로 지켜졌다는 시험과 별개입니다.

출처 확인(2026-11-03): 규칙 원문은 활성 조건을 다음처럼 나눕니다. alwaysApply: true는 description과 globs를 무시하고 포함됩니다. false이면서 globs가 있으면 일치 파일이 컨텍스트에 들어올 때 붙고, description만 있으면 관련성에 따라 Agent가 선택하며, 둘 다 없으면 @로 수동 호출하는 유형입니다. “내용을 한 파일에 붙였다”는 작업만으로 이 네 선택을 보존할 수는 없습니다. 옮기기 전에 파일마다 이 네 유형 가운데 하나를 적고, 조건이 없는 규칙을 항상 적용할지 수동 호출로 둘지 정하세요.

파일 이름도 의미가 있습니다. 문서는 .cursor/rules 안의 평범한 .md는 규칙 시스템에서 무시하고 .mdc를 사용한다고 설명합니다. 단순 Markdown 지침을 원하면 AGENTS.md가 대안이며 루트와 하위 디렉터리의 적용을 지원합니다. 따라서 새 도구에 텍스트 지침을 옮길 때는 파일의 형식과 조건을 먼저 해석하세요. 호환 여부가 확인되지 않은 .mdc 메타데이터를 무작정 같은 뜻으로 복사하지 마세요.

규칙 안의 @파일 참조도 문서 내용이 자동으로 전부 삽입된다는 뜻은 아닙니다. 원문은 Agent가 필요할 때 그 파일을 읽도록 위치를 알려 준다고 설명합니다. 항상 필요한 짧은 금지 조건과 길어서 필요할 때 읽을 설계 문서를 구분할 수 있습니다. 이전 후보가 이 참조를 이해하는지 모르면 필수 조건은 직접 전달하고 자료의 위치는 따로 적는 편이 맞습니다.

Team Rules는 Project Rules의 폴더 구조와 다른 자유 형식 텍스트로 안내됩니다. 팀 규칙에도 glob을 두면 일치 파일이 컨텍스트에 있을 때 적용하고, glob이 없으면 모든 대화에 적용한다고 문서는 설명합니다. 같은 규칙 본문이라도 배포 위치와 적용 범위를 함께 옮겨야 합니다. 이게 구체적인 차이입니다.

MCP는 서버 이름보다 허용한 행동을 봅니다#

규칙을 팀 저장소에서 배포하는 경로도 이전 자산입니다. 출처 확인(2026-11-03): Cursor 문서는 GitHub 저장소의 규칙이 저절로 가져와지는 것이 아니라 플러그인으로 패키징해 marketplace 경로로 설치한다고 설명합니다. Customize의 From GitHub Repository 경로에는 .cursor-plugin/marketplace.json 같은 구조가 필요하다고 안내합니다. 규칙 파일 몇 개를 내려받는 일과 팀의 배포·업데이트 경로를 유지하는 일은 다릅니다. 새 터미널이 같은 플러그인 형식을 읽는다고 가정할 근거는 없습니다.

가상 팀의 저장소에 규칙 원문과 배포 플러그인이 따로 있다면 두 자산을 다르게 취급할 수 있습니다. 원문은 요구의 뜻을 옮길 자료입니다. 플러그인은 누가 어떤 버전을 제공하는지 관리하는 수단입니다. 개인 실험에서는 필요한 조건을 요청에 직접 넣는 안이 가능하지만, 조직의 강제 규칙을 그 방식으로 대체했다고 표현하지 않습니다. 팀 규칙의 관리 권한과 새 호스트의 허용 범위를 별도로 다뤄야 하는 이유입니다.

작은 프로젝트는 AGENTS.md 같은 읽기 쉬운 지침으로 출발할 수도 있습니다. Cursor 문서는 하위 디렉터리의 지침이 부모 지침과 함께 적용되며 더 구체적인 지침이 우선한다고 설명합니다. 따라서 가상 프런트엔드 폴더의 말투 지침과 루트의 식별자 보존 조건을 하나의 긴 전역 규칙으로 합치지 마세요. 어떤 조건이 전역이고 어떤 조건이 해당 폴더용인지 먼저 정하면 됩니다.

프로젝트 지침은 행동을 설명하고 MCP 연결은 외부 도구에 접근하는 경로를 만듭니다. 두 항목을 따로 다루는 이유입니다. Mirr MCP 안내를 기준으로 연결, 인증과 제공 도구를 확인하되 기존 Cursor 설정의 자동 호환은 전제하지 마세요. 같은 서버 이름이 표시되어도 같은 계정과 권한으로 연결됐는지 확인하세요.

예를 들어 이슈를 읽는 데 필요한 연결을 검토하면서 이슈 생성과 상태 변경까지 허용할 이유는 없습니다. 읽기 과제로 시작해 어떤 도구가 제안되는지 살피세요. 쓰기가 필요하면 별도 승인을 받는 순서를 권합니다. 실제 회사 프로젝트에 접속하지 않는 합성 환경에서 시험할 때도 외부 발송과 배포는 제외하세요. 파일 변경을 되돌릴 수 있다는 이유로 외부 서비스의 변경까지 복구된다고 보아서는 안 됩니다.

연결 실패가 나면 먼저 서버 주소, 인증 만료, 허용 범위와 호스트의 지원 여부를 나눠 기록하세요. 모델이 도구를 선택하지 않은 경우와 서버에 연결할 수 없는 경우는 다릅니다. 오류가 났다는 이유로 토큰을 대화에 붙이거나 모든 권한을 켜는 방식은 피하세요. 담당자가 검토할 수 있도록 비밀값을 지운 오류 문구와 실패 단계만 남깁니다.

이전 비용을 비교하는 세 가지 선택#

전면 교체, 병행, 현재 설정 정리는 서로 다른 선택입니다. 전면 교체는 기존 도구에서 하던 모든 필수 작업을 새 환경에서 끝내야 합니다. 병행은 에디터를 남기고 특정 조사나 수정만 터미널에 맡깁니다. 현재 설정 정리는 구독과 규칙, 연결을 조정한 뒤 Cursor를 계속 쓰는 선택입니다. 어느 쪽도 이 글에서 더 저렴하다고 입증한 것은 아닙니다.

가상의 자산 목록을 채워 봅시다. 저장 시 포맷은 기존 에디터, 타입 오류는 언어 확장, 원인 조사는 Agent, 빌드는 저장소 스크립트가 담당합니다. 터미널 후보에 조사만 맡긴다면 앞의 두 에디터 자산은 교체 대상이 아닙니다. 에디터까지 바꾸려면 포맷과 진단을 어디에서 이어 갈지 추가 선택이 필요합니다. 두 안은 같은 전환이 아니므로, 한쪽의 설치 시간으로 다른 쪽의 이전 비용을 대표하지 않습니다.

같은 가상 팀에서 Cursor는 화면/ 문구 변경만, 터미널 후보는 별도 복사본의 서버/ 원인 조사만 담당하게 할 수 있습니다. 터미널이 조사 중 화면 파일을 수정하면 병행의 역할 경계를 벗어난 것입니다. 반대로 필요한 결과가 서버 호출 경로 설명뿐이라면, 터미널이 IDE의 디버거 화면까지 재현할 필요는 없습니다. 이렇게 담당 산출물을 다르게 정하면 무엇을 잃고 무엇을 남기는지 구체적입니다.

현재 설정만 정리하는 안에도 제품 고유의 근거가 있습니다. Cursor 문서는 규칙이 Agent(Chat)에 적용되며 Cursor Tab에는 영향을 주지 않는다고 설명합니다. Tab의 제안이 마음에 들지 않아 프로젝트 규칙을 계속 늘리는 상황이라면 규칙 이전보다 문제를 다른 기능으로 분류하는 것이 먼저입니다. 팀 규칙·프로젝트 규칙·사용자 규칙이 충돌한다면 문서상 우선순위도 살펴볼 수 있습니다.

청구 항목을 같은 기간으로 맞추기#

비용 기록에는 기존 구독의 남은 이용 기간, 새 구독을 시작하는 날짜, 별도 모델 비용과 사람이 설정을 옮기는 시간을 나눠 적으세요. 이 글은 시간에 임의의 시급을 붙이거나 환율과 세금을 가정해 합계를 만들지 않습니다. 회사가 사용하는 비용 기준이 있다면 그 기준과 계산일을 함께 남겨 비교할 수 있습니다. 원화 구독과 달러 사용료는 원래 통화도 보존하세요.

이미 낸 구독료와 앞으로 피할 수 있는 비용도 구분하세요. 현재 결제 기간의 비용을 돌려받는지 확인하지 않은 채 해지 즉시 그 금액이 절감된다고 계산하면 안 됩니다. 새 도구를 시험하기 위한 중복 구독 기간은 따로 표시하세요. 그 기간의 비용을 평소 월 비용으로 일반화하지 않으면 이후 도입 결정에서도 기록을 다시 쓸 수 있습니다.

모델 비용은 실제 선택 경로를 기준으로 기록합니다. 구독 포함 사용량을 쓴 요청과 별도 크레딧을 쓴 요청을 섞으면 원인을 찾기 어렵습니다. 테스트 실패 때문에 추가 요청을 보냈다면 그 요청도 해당 과제의 비용입니다. 반대로 다른 프로젝트의 사용량을 이 과제에 모두 붙이면 비교가 왜곡됩니다. 과제별 내역을 구할 수 없다면, 계정 전체 관찰이라고 범위를 밝혀 두세요.

세 가지 작업 상황으로 이전 범위를 좁히기#

다음 상황은 실제 고객 사례가 아니라 선택을 돕는 가상 예시입니다. 자신이 쓰는 확장과 규칙, 청구 경로를 대입해 읽어 보세요. 같은 Cursor 사용자라도 무엇을 남기고 무엇을 옮길지는 다를 수 있습니다. 상황별로 필수 조건을 적으면 새 도구를 평가할 과제도 작게 정할 수 있습니다.

편집기는 익숙하지만 조사만 터미널에 맡기고 싶을 때#

이 사람의 미실행 요청 예는 “서버/반품.py가 환불금액을 계산하는 호출 경로를 설명하고, 수량 0이 어디에서 거부되는지 알려 줘. 파일은 고치지 마”입니다. 가상 저장소는 라우터, 입력 검증과 계산 함수로 구성돼 있고 0 거부는 입력 검증에만 있다고 정합니다. 기대 답은 그 세 위치와 거부 조건을 연결한 설명이지 전체 저장소 요약이 아닙니다.

설명이 계산 함수만 고치라고 하면 호출 전 검증을 놓친 답입니다. 실제 위치를 찾았지만 구현까지 바꿨다면 요청 범위를 벗어납니다. 이처럼 정답의 조건을 정해 두면 터미널 조사가 필요한지 판단할 수 있습니다. 현재 사용하는 진단·디버그·포맷은 Cursor에 그대로 두므로 확장 이전은 이번 선택의 조건이 아닙니다. 한국어 설명만 비교하려는 사람에게 맞는 작은 병행안입니다.

여러 확장이 업무의 필수 조건일 때#

가상 팀이 사내 스키마 확장으로 API 코드를 생성한다고 가정합니다. 이 확장이 없으면 생성 파일을 만들 수 없고, 사람 손으로 생성 파일을 바꾸는 것은 팀 규칙상 금지입니다. 반면 테마와 파일 아이콘은 편의 항목입니다. 이 팀이 터미널 후보로 생성 파일만 수정하게 하는 안은 원래 절차의 대체가 아닙니다. 승인된 생성기를 계속 쓸 수 있는 작업면을 남기는 쪽이 필요합니다.

다른 자산은 Team Rules입니다. 출처 확인(2026-11-03): Cursor 규칙 문서에 따르면 Team Rules는 팀 관리자가 관리합니다. 강제된 규칙은 사용자가 끌 수 없습니다. 충돌할 때는 Team → Project → User 순으로 먼저 온 지침이 우선합니다. 규칙 파일만 복사해서 사내 정책의 관리·강제 경로까지 옮겼다고 볼 수 없는 이유입니다. 새 후보의 조직 관리가 검증되지 않았다면 그 항목은 유지안의 중요한 근거가 됩니다.

따라서 이 팀의 가상 선택은 “스키마 생성과 조직 규칙 관리는 현재 환경에 남기고, 한국어 원인 조사만 별도 도구로 시험한다”입니다. 테마 차이 때문에 전환을 막을 필요는 없지만 생성기와 중앙 정책의 공백을 테마처럼 가벼운 불편으로 취급해서도 안 됩니다. 필수와 선호가 구체적으로 나뉘면 같은 기능 수를 세지 않고도 선택할 수 있습니다.

구독 해지가 먼저 떠오를 만큼 비용이 불편할 때#

레거시 구독 사용자와 신규 구독 사용자는 같은 표를 출발점으로 삼지 않습니다. 앞의 공식 자료에 따르면 기존 요금제는 별도 포함량과 조건을 가집니다. “새로 표시된 Plus가 더 낮다”는 이유만으로 이전 계약을 대체한다고 계산할 수는 없습니다. 가상의 사용자에게 필요한 것이 특정 타사 모델인지, Cursor 모델인지와 클라우드 에이전트인지에 따라 남길 기능도 달라집니다. Plus의 상충하는 공식 안내는 현재 계정에서 확인할 조건으로 유지합니다.

가상 비용표에는 금액 대신 세 항목을 채울 수 있습니다. 유지하는 기존 계약의 용도는 클라우드 위임, 새 터미널의 용도는 한국어 로컬 조사, 이전하지 않는 자산은 IDE 확장입니다. 이 경우에는 전면 구독 대체가 아니라 추가 도구의 적합성 판단입니다. 원래 계약을 실제로 없애지 않는 안을 절감 사례로 표현할 수는 없지만, 업무를 어디에 둘지는 분명하게 정할 수 있습니다.

이전 검토에서 합의할 수용 기준#

수용 기준은 “Cursor와 똑같다”보다 관찰 가능한 문장으로 쓰는 편이 좋습니다. 예를 들어 지정한 한글 파일을 찾고 필요한 문구만 바꾸며 같은 테스트를 통과해야 한다고 정할 수 있습니다. 기존 규칙의 금지 행동을 지키고 외부 서비스에 쓰지 않는다는 조건도 넣으세요. 필수 조건과 선택 조건을 나누면 — 하나의 편리한 기능이 다른 누락을 가리지 못하게 할 수 있습니다.

스키마 팀이 이 표를 적용하면 생성기는 필수, 테마는 선택, 한국어 원인 조사는 새 후보의 평가 항목입니다. “모든 확장을 옮긴다”는 목표 대신 생성된 API 계약을 유지하고 원하는 조사 결과를 얻는지가 기준이 됩니다. 한글 경로를 찾는 과제는 아래 예시로, 규칙 활성은 마지막 매핑 예시로 다룹니다. 각 예시는 완료 보고 하나로 끝내지 말고 조건별로 따로 확인하세요.

이 페이지의 한계는 다음과 같습니다. 동일 리팩토링을 양쪽 도구로 실행한 기록과 한글 검색·편집 화면은 아직 없습니다. 출처 표만으로 호환이나 성능을 인증하지도 않습니다. 파일 복구는 외부 계정·구독·게시를 되돌리지 않습니다. 비밀값은 대화와 기록에서 제외하세요. 이 조건을 전제로 이후 사례는 선택을 연습하는 미실행 설계로 읽으면 됩니다.

한글 저장소에서 첫 과제를 고르는 법#

커서 대신 쓸 터미널 AI를 찾는다면 첫 과제는 화면을 크게 바꾸는 기능보다 한글 경로와 기존 동작을 함께 확인할 수 있는 작은 수정이 낫습니다. 다음은 제안 예시입니다. 합성 저장소의 주문/환불정책.md와 이를 읽는 테스트를 준비하고, 환불 조건의 설명 문구만 바꾸도록 요청합니다. 실제 고객 정보나 업무 규정은 넣지 않습니다.

요청에는 바꿀 문구와 유지할 숫자, 수정할 파일과 건드리지 않을 파일을 적습니다. 완료 기준은 한국어 설명이 자연스러운가만으로 끝내지 마세요. 파일명이 그대로인지, 인코딩이 바뀌지 않았는지, 기존 링크가 유지되는지, 테스트가 같은 명령으로 통과하는지도 봅니다. 이 기록을 확보해야 한글 파일을 검색하고 편집하는 흐름을 말할 수 있습니다. 그 실행 기록은 아직 없습니다.

다음 과제로는 한글 주석이 있는 작은 함수의 중복 분기를 정리할 수 있습니다. 입력과 출력 계약은 그대로 두고 테스트를 먼저 고정합니다. 결과가 동작하더라도 주석의 예외 조건이 사라졌다면 검토 항목에 남기세요. 번역이 매끄러운 것과 요구사항을 보존한 것은 다른 판단입니다. 코드 diff와 한국어 설명을 따로 읽어야 놓친 조건을 찾기 쉽습니다.

첫 요청이 실패하면 같은 요청을 무작정 반복하지 말고 실패를 분류하세요. 파일을 못 찾았는지, 지침을 다르게 읽었는지, 도구 실행이 거절됐는지, 테스트 환경이 준비되지 않았는지에 따라 다음 행동이 다릅니다. 각 도구에 서로 다른 도움을 줬다면 그 차이를 기록하세요. 한쪽에만 정답 위치를 알려 준 결과를 같은 조건의 비교로 읽으면 안 됩니다.

해지 판단에 쓸 종료 조건#

앞의 가상 스키마 팀은 생성기와 중앙 규칙을 계속 쓰므로 전면 해지가 이번 시험의 종료 조건이 아닙니다. 로컬 조사만 채택하거나 기존 도구를 유지하는 것으로 결정을 끝낼 수 있습니다. 반대로 IDE를 모두 바꾸려는 개인은 필수 확장과 클라우드 용도가 실제로 남는지에 따라 계약 변경을 검토할 수 있습니다. 구독의 환불과 재가입 조건은 현재 계정의 안내를 따를 일이며 이 사례가 특정 조건을 보장하지 않습니다.

규칙을 이전할 때의 검토 예#

규칙이 “사용자에게 보이는 오류 문구는 한국어로 쓰고 내부 오류 코드는 유지한다”라고 정해져 있다고 가정합니다. 이 규칙을 새 도구로 옮길 때는 문장만 복사하지 말고 화면 파일에 적용할 조건과 서버 응답에서 유지할 계약을 함께 적습니다. 원래 규칙이 특정 폴더에만 적용됐다면 그 범위를 전체 저장소로 넓히지 않습니다.

합성 입력은 화면/오류.ts의 {code: "OUT_OF_STOCK", message: "품절"}입니다. message를 “상품이 품절되었습니다”로 바꾸되 code는 그대로 두라는 요청입니다. .cursor/rules/문구.mdc의 가상 조건은 화면 경로에만 맞는 glob, alwaysApply: false, 한국어 존댓말 문구입니다. 기대 결과는 code가 OUT_OF_STOCK 그대로 유지되고 서버 응답 구조가 바뀌지 않는 것입니다. 이 예시는 실제 규칙 파일이나 실행 출력이 아닙니다.

다른 후보로 옮길 때는 “화면 경로”, “한국어 존댓말”, “code 불변” 세 조건을 분리해 매핑합니다. 후보가 glob 기반 규칙을 읽는지 확인되지 않았다면, 이 작은 과제의 요청에 세 조건을 직접 적는 방법이 있습니다. 문구는 맞지만 code를 번역했다면 계약 보존에 실패합니다. 서버 파일까지 고쳤다면 범위가 달라집니다. 모든 작업에 같은 긴 규칙을 붙이는 것보다, 필요한 조건만 정리해서 옮기는 편이 낫습니다.

같은 문서 폴더에 수동으로만 불러야 하는 “대규모 마이그레이션 검토” 규칙이 있다면, 이 문구 과제에 자동으로 합치지 않습니다. 수동 규칙을 항상 적용 지침으로 바꾸면 작은 작업에도 불필요한 설계 요구가 따라올 수 있습니다. 반대로 모든 수정에서 지켜야 할 식별자 불변 조건을 선택형 설명만으로 남기면 누락 위험이 있습니다. 활성 조건에 따라 이전 방법이 달라지는 지점이, 규칙을 옮기는 실제 판단입니다.