왜 Mirr Code인가: 한국어로 일하는 개발자를 위한 선택

Mirr Code는 터미널에서 동작하는 코딩 에이전트입니다. 파일을 읽고 고치며 명령을 실행하고 결과를 검증합니다. 다른 도구와 다른 점은 하나입니다. 한국어로 끝까지 일하게 만든 것입니다.

저장소에는 한글 파일명, 한글 주석과 한국어 리뷰가 섞여 있을 수 있습니다. Mirr Code는 한국어로 요청하고 결과를 확인할 때 생기는 마찰을 줄이는 데 집중합니다. 초성 검색과 한국어 화면·리뷰를 제공합니다. 한국어로 작업하기에서 사용법을 확인하세요.

한국어로 지시해서 한국어로 결과를 확인하고, 한글 파일명과 경로가 섞인 저장소를 검색·편집하는 흐름에 집중합니다. HWP·HWPX나 엑셀 문서에 관한 질문이나 처리 코드 작성 도움도 요청할 수 있습니다. HWP·HWPX 파일을 읽거나 수정·변환하는 범위는 연결된 도구와 환경에 따라 달라집니다. 엑셀 파일 작업의 실제 가능 범위도 사용 환경과 도구를 확인하세요. 한국어 작업 안내를 참고하세요. 변경 사항을 확인하고 /rewind의 체크포인트를 살펴볼 수 있습니다. 체크포인트가 없거나 일부 파일은 복구되지 않을 수 있어 별도 백업이 필요합니다. 외부 작업은 자동으로 취소되지 않습니다. 자세한 내용은 세션과 복구를 참고하세요.

최신 영어 벤치마크 점수, 방대한 플러그인 생태계, 팀·기업 기능의 깊이에서는 아직 앞서가는 도구가 있습니다. 그 부분은 솔직하게 인정합니다. 다른 도구가 더 나은 작업도 있습니다.

영문 벤치마크 점수가 최우선이거나 특정 IDE에 깊이 의존하는 경우에는 다른 도구가 더 맞을 수 있습니다. 대규모 팀 정책(SSO, 감사 로그)이 먼저라면 해당 기능의 제공 여부를 담당자에게 확인한 뒤 비교하세요. 그런 경우 억지로 옮길 필요는 없습니다.

Mirr Code는 한국에서 개발하고 운영합니다. 한국어로 바로 물어볼 수 있는 지원 채널도 있습니다. 지원 채널에서 확인할 수 있습니다.

현재 요금과 이용 조건은 요금제에서 확인하고, 결제 전에 결제 화면의 안내도 확인해 주세요.

한국어 네이티브는 한국어 요청·화면·명령 검색·리뷰 흐름을 가리키는 표현이며 속도나 일반 성능 우위의 측정값이 아닙니다. 이 페이지에는 실제 과제의 제품 화면과 실행·복구 기록이 아직 없습니다.

가격 표의 실제 금액과 회사·팀 소개의 근거, 제품 화면은 담당자의 확인이 필요합니다. 기존 도구를 바로 해지하지 말고 승인된 작은 과제부터 비교하세요.

제안하는 확인 절차입니다. 민감정보가 없는 연습 폴더를 만들고, 바꿀 파일과 기대하는 결과를 요청 전에 적어 둡니다. 예를 들어 한글 파일 이름을 가진 설정 파일에서 오류 문구 한 줄만 바꿔 달라고 요청할 수 있습니다. 실행이 끝나면 변경된 파일 목록과 실행한 명령을 봅니다. 문서에 따르면 작업 결과는 변경된 파일과 실행한 명령을 기준으로 확인할 수 있습니다. 바꾸지 말아야 할 파일이 바뀌었다면 그 실행은 기대와 다른 결과로 적습니다. 테스트 명령을 실행하지 못했다면 그 사실도 함께 남깁니다. 같은 과제를 다시 실행하면 결과의 차이를 비교할 수 있습니다.

한글 파일이 섞인 저장소에서는 파일을 찾는 단계부터 확인합니다. 입력창에서 @를 입력하면 한글 파일 이름으로도 검색할 수 있습니다. 선택된 파일의 경로가 원하던 파일과 같은지 먼저 확인하세요. 요청에 파일 이름이나 경로를 함께 적어 두면 비슷한 이름의 다른 파일을 고칠 가능성이 줄어듭니다. 승인 요청이 나오면 표시된 파일 경로와 명령이 요청한 대상과 맞는지 대조합니다. 수정이 끝나면 바꾸지 말아야 할 파일이 그대로인지 확인하고, 원문 보존이 필요하면 작업 전에 원본 복사본을 따로 만들어 두세요.

소개 문서는 두 이름을 이렇게 구분합니다. Mirr는 요청을 이해하고 해결 방법을 생각하는 모델 제품군이고, Mirr Code는 그 모델을 실제 프로젝트에 연결해 파일을 읽고, 수정하고, 명령을 실행하고, 결과를 확인하게 하는 코딩 도구입니다. 설치와 로그인 방법은 설치 문서와 로그인 안내에서 확인하세요.

소개 문서에 따르면 Patty는 여러 고성능 AI 모델을 쓰면서 같은 뜻의 요청을 영어와 한국어로 각각 전달했을 때 해석과 결과물의 품질이 달라지는 현상을 반복해서 겪었다고 합니다. 한국어로 답하는 능력과 한국어 요구사항을 이해하는 능력도 다르다고 봤습니다. 이것은 회사가 밝힌 출발점입니다.

소개 문서는 Mirr가 HWP와 HWPX 같은 국내 문서 형식을 이해하도록 강화했다고 적고 있습니다. 또 국내 개발 현장에서 많이 쓰는 Java 기반 개발 역량에 특히 집중한다고 밝힙니다. 새 코드를 쓰는 일과, 이미 운영 중인 프로젝트 구조를 파악하고 오류 원인을 찾아 고치는 일을 모두 중요하게 본다고 합니다. 다른 언어나 프레임워크에서의 적합성은 문서만으로 판단하지 말고 같은 과제를 직접 실행해 확인하세요.

개발 용어로 바꾸거나 영어로 번역하지 않아도 됩니다. 원하는 결과를 한국어로 설명하고, 바꾸지 않을 조건도 함께 적으면 됩니다. 문서의 예시는 이런 식입니다. “회원가입할 때 이메일 형식이 잘못되면 입력란 아래에 안내를 보여 줘. 기존 회원가입 방식과 화면 디자인은 유지해 줘.” 오류 메시지나 코드에 영어가 들어 있으면 원문 그대로 함께 전달하면 됩니다. 화면 문구의 말투가 중요하다면 존댓말로 작성해 달라고 덧붙일 수 있습니다. 결과는 실제 diff와 실행 결과로 확인하세요.

입력창에 /를 입력하면 명령 목록이 열립니다. 명령은 한글 이름, 영어 이름이나 초성으로 검색할 수 있습니다. 파일은 @로 찾아 선택하며, 한글 파일명도 입력해 검색할 수 있습니다. 화면과 응답의 기본 언어를 한국어로 맞추려면 /language ko를 실행합니다. 특정 요청에서만 다른 언어가 필요하다면 요청 안에 그 언어를 적으면 됩니다. 전체 명령과 키 조작은 명령과 단축키에서 확인할 수 있습니다.

한국어 요청에는 바꿀 것과 유지할 것을 함께 적으면 편합니다. 예를 들어 로그인 화면 파일을 @로 고른 뒤, 로그인 버튼 아래에 비밀번호 찾기 링크를 추가하고 기존 버튼의 색상과 크기는 유지하라고 요청할 수 있습니다. 작업 방향을 바꿀 때는 디자인은 그대로 두고 로그인 오류만 고쳐 달라는 식으로 바뀐 조건을 설명하세요. 다른 프로그램에서 파일을 고쳤다면 그 사실도 알려 주는 것이 좋습니다.

모델 문서는 모델을 바꿔도 파일 수정이나 명령 실행 권한은 그대로라고 설명합니다. 대화 중 /model을 입력하면 모델 선택 화면이 열리고, 현재 모델과 선택할 수 있는 항목을 확인할 수 있습니다. 실행 권한은 작업 모드와 도구 권한 설정으로 정해집니다. 그러므로 한국어로 요청하더라도 승인을 받으며 진행할지, 계획을 먼저 세울지는 모드에서 따로 고르게 됩니다. 연결한 외부 도구의 실행 권한도 같은 설정의 영향을 받습니다.

문서는 세 가지 모드를 용도에 따라 나눕니다. Ask는 필요한 도구 실행에 승인을 요청하므로 실행할 작업을 하나씩 확인하며 진행하고 싶을 때 맞습니다. Auto는 승인 설정에 따라 작업을 자동으로 진행하고 필요한 경우에만 확인을 요청하므로 반복 승인을 줄이고 싶을 때 씁니다. Plan은 먼저 조사하고 계획을 제안하므로 수정 전에 접근 방법과 범위를 정하고 싶을 때 맞습니다. 자동 실행은 결과의 정확성이나 안전을 보장하지 않습니다. 파일 삭제나 외부 서비스 변경처럼 되돌리기 어려운 작업이 있다면 실행 범위와 백업을 먼저 정하세요.

소개 문서는 문서 형식을 이해하는 것과 실제 파일을 처리하는 기능을 구분합니다. 중요한 문서라면 처리 전에 원본을 복사해 보관하고, 결과 파일을 원본과 대조해 확인하세요. 처리 코드가 필요하다면 어떤 입력을 받아 어떤 결과를 내야 하는지 요청에 함께 적으세요. 외부 도구를 연결하는 방법은 외부 도구 연결하기에서 확인할 수 있습니다.

한글이 중복되거나 마지막 글자가 사라지는 증상은 입력 중에만 생기는지, 입력을 마친 뒤에도 남는지부터 나눠 봅니다. 같은 문장을 일반 텍스트 편집기와 Mirr Code에서 각각 입력해 보면 문제가 생기는 위치를 좁힐 수 있습니다. 커서가 어긋나면 한글을 지원하는 고정폭 글꼴과 터미널의 확대 비율을 확인하세요. 파일을 열었을 때 글자가 깨진다면 예전 한국어 파일이 EUC-KR이나 CP949로 저장되었을 수 있습니다. 원본을 복사해 보관한 뒤 편집기의 인코딩 선택 기능으로 맞는 형식을 찾으세요. 화면 문제를 해결하려고 프로젝트 파일의 내용을 바꿀 필요는 없습니다.

Git 프로젝트에서는 mirr review 명령으로 아직 커밋하지 않은 변경을 검토할 수 있습니다. 스테이징한 변경과 스테이징하지 않은 변경을 함께 다룹니다. 다만 Git이 아직 추적하지 않는 새 파일은 이 비교에 들어가지 않으며, 변경이 없으면 검토할 내용이 없다는 메시지가 나옵니다. 기본 브랜치와 비교하려면 mirr review --base main을, 가장 최근 커밋만 보려면 mirr review --commit HEAD를 사용합니다. 기본 브랜치 이름이 main이 아니라면 해당 이름으로 바꿔 입력하세요.

지원 환경은 macOS(Apple Silicon과 Intel), Windows(x64와 ARM64), Linux(x64와 ARM64)입니다. WSL에서 쓰려면 Windows에 설치한 것과 별도로 WSL 안에서 Linux용 설치 안내를 따라야 합니다. 설치와 버전 확인은 로그인 전에 할 수 있습니다. 다만 요청을 보내고 응답을 받으려면 인터넷 연결이 필요하며, 모델을 쓰려면 Patty 계정으로 로그인해야 합니다. Mirr Code를 설치하는 데 Node.js나 npm은 필요하지 않습니다. 개발 도구는 진행하려는 작업에 필요한 것부터 준비하면 됩니다. 외부 도구를 연결할 때는 그 도구의 안내에 따라 추가 프로그램이 필요할 수 있습니다. 회사나 기관이 관리하는 컴퓨터라면 프로그램 설치와 프로젝트 파일 접근이 허용되는지 먼저 확인하세요. 파일을 새로 만들거나 고치려면 쓰기 권한도 필요합니다.

소개 문서는 AI가 제안한 코드와 설명에 오류가 있을 수 있다고 적고 있습니다. 중요한 변경은 직접 검토하고 실행 결과와 테스트를 확인하라는 것이 문서의 권고입니다. 리뷰 기능도 모든 오류를 찾지는 못하므로, 중요한 변경은 테스트와 사람의 검토를 함께 거치는 편이 좋습니다. 실행 후에는 변경된 파일 목록, 실행한 명령과 테스트 출력을 함께 봅니다. 실행하지 못한 검사는 결과에 남겨 두세요. 이렇게 하면 실제 변경과 실행 기록으로 결과를 판단할 수 있습니다.

Mirr Code는 실행한 폴더를 기준으로 프로젝트를 살펴봅니다. 여러 프로젝트를 쓴다면 작업할 폴더로 이동한 뒤 mirr를 실행하세요. 이전 대화를 이어가려면 mirr --continue를, 저장된 대화 목록에서 고르려면 mirr --resume을 사용합니다. 이미 실행 중이라면 /resume으로 저장된 대화를 열 수 있습니다. 대화를 불러오는 것은 파일을 과거 상태로 되돌리는 작업과 다릅니다. 파일을 되돌리는 것은 /rewind의 체크포인트 기능입니다.

소개 문서가 그리는 기본 흐름은 다섯 단계입니다. 먼저 한국어로 요청하고, 다음으로 Mirr Code가 프로젝트와 관련 파일을 확인합니다. 그 뒤 코드를 쓰거나 고치고, 명령을 실행해 결과를 확인하며, 필요한 부분을 보완합니다. 각 단계에서 무엇을 볼지 정해 두면 문제가 생긴 단계를 찾기 쉽습니다.

소개 문서는 처음 시작할 때 쓸 수 있는 요청 예를 세 가지 듭니다. 기존 프로젝트를 이해하고 싶다면 “이 Java 프로젝트의 구조를 먼저 설명해 줘. 로그인 요청이 어떤 파일과 메서드를 거쳐 처리되는지 알려 주고, 수정하기 전에 확인해야 할 부분도 정리해 줘”처럼 물을 수 있습니다. 반복 업무를 자동화하고 싶다면 폴더의 CSV 파일을 하나로 합치고, 중복된 행을 빼고, 오류가 난 파일을 알 수 있게 해 달라고 요청하는 예가 있습니다. 처음 무언가를 만들고 싶다면 필요한 내용을 먼저 물어보고, 만든 페이지를 내 컴퓨터에서 확인하는 방법을 알려 달라고 하면 됩니다. 개발 용어를 모두 알지 못해도 괜찮다는 안내도 함께 있습니다.

소개 문서는 Mirr가 코딩과 일상적인 질문에 함께 쓰일 수 있다고 설명합니다. 낯선 개념을 이해하거나, 글의 초안을 쓰고 내용을 정리하거나, 아이디어를 검토하는 데도 쓸 수 있다고 합니다. 코딩을 하다가 필요한 개념을 물어보고, 작업 방향을 정리한 뒤 구현으로 이어 가는 대화도 가능하다고 안내합니다. 용도별 품질에 관한 측정 자료는 확인되지 않았습니다.

Mirr Code에 기능을 더하는 방법은 세 가지로 나뉩니다. 반복해서 쓸 작업 지침은 스킬로 추가하며, 설치된 스킬은 /skills에서 확인합니다. 외부 서비스의 데이터와 도구는 MCP로 연결합니다. 여러 확장 기능을 묶어 배포하는 패키지는 배포자가 제공하는 설치 안내를 따릅니다. 설치 전에는 출처와 제공 기능을 확인하라고 설정 문서가 안내합니다.

대화 화면을 열지 않고 요청 하나를 전달하려면 mirr -p에 요청을 넣어 실행합니다. 다른 프로그램에서 결과를 처리해야 하면 --output-format json 옵션으로 JSON 출력을 고를 수 있습니다. 터미널 명령 문서는 출력이 요청과 프로젝트에 따라 달라진다고 적고 있으므로, 자동화에 넣을 때는 오류 출력과 종료 코드도 함께 처리하세요.

Mirr Code는 요청에 따라 파일을 검색하고 필요한 내용을 골라 읽는다고 문서는 설명합니다. 특정 파일이 중요하다면 @로 선택하거나 이름과 경로를 요청에 적으세요. 긴 대화에서는 /compact로 요약해 이어 갈 수 있습니다. 민감한 파일이 프로젝트에 있다면 작업에 필요하지 않은 파일이 선택되지 않도록 대상을 좁혀 두는 것이 좋습니다.

문제 해결 문서는 증상별로 찾을 곳을 나눠 둡니다. 설치 명령이 실패하거나 mirr를 찾을 수 없으면 설치와 로그인 문제를, 요청이 실패하거나 응답이 오지 않으면 연결과 응답 문제를 봅니다. 한글이 중복되거나 커서가 어긋나면 터미널과 한글 입력 문제를, 도구 실행이 거절되거나 승인을 기다리면 도구와 권한을, 외부 서비스의 도구가 보이지 않으면 외부 도구 연결하기를 확인하세요.

“테스트를 실행해 줘”라는 요청은 실제로 프로젝트의 테스트 명령을 실행하는 작업으로 이어질 수 있습니다. 도구와 권한 문서는 승인 요청에 표시된 명령을 확인한 뒤 허용하거나 거절하라고 설명합니다. 요청한 테스트와 같은 명령인지 확인한 뒤 허용하세요. 실행이 끝나면 테스트 출력도 직접 읽어야 합니다.

요청 안에 영어 오류 문구나 코드 식별자가 있으면 원문 그대로 두고, 설명만 한국어로 달라고 요청할 수 있습니다. 문서는 영어 원문을 그대로 전달하라고 안내하며, 개발 용어로 바꾸거나 번역할 필요는 없다고 설명합니다.

Plan 모드가 제안한 계획은 대화로 고칠 수 있습니다. 예를 들어 화면 디자인을 바꾸지 않는 방향으로 계획을 다시 세워 달라고 요청하면 됩니다. 계획을 승인하면 실행으로 이어지므로, 승인 전에 범위가 맞는지 확인하는 편이 좋습니다.

방침은 기업용이나 조직용 관리 기능이 적용되는 경우에만 지정된 관리자가 조직 안의 이용 기록과 감사 기록을 확인할 수 있다고 적고 있습니다. 이 기능이 사용하는 계약에 포함되는지는 이 페이지에서 확인되지 않았습니다. 그 내용은 계약 조건과 조직 전용 관리 기능에서 직접 확인해야 합니다.

승인 요청에서 의도와 다르면 거절하고, 조건을 다시 설명하면 됩니다. 권한 규칙은 작업을 허용하거나 승인을 요청하거나 실행을 막을 수 있습니다. 거절한 뒤에는 같은 대화에서 파일 범위나 명령을 좁혀 다시 요청할 수 있습니다.