OpenCode 대안: '무료'의 범위를 먼저 따져보기

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

OpenCode의 "무료"를 모델 키·설정·유지보수 노동 등의 비용 요인과 함께 살펴보고 이름이 같은 다른 프로젝트를 구분하는 체크리스트를 먼저 제공합니다.

이름이 같은 프로젝트를 구분할 때는 다음을 확인하세요. 공식 자료 확인일: 2026-11-01.

• anomalyco/opencode는 이 글에서 비교하는 OpenCode입니다. V2 설치 문서의 npm 패키지는 @opencode/cli입니다.
• 같은 프로젝트의 V1 설치 문서는 npm 패키지 opencode-ai를 안내합니다. V1과 V2의 기본 명령은 모두 opencode이므로 설치 충돌에 주의하세요.
• 별개의 opencode-ai/opencode 저장소는 보관됐으며, 저장소 안내에 따르면 해당 프로젝트는 Crush로 이어졌습니다.

위 구분은 2026-11-01에 확인한 문서의 식별 정보입니다. 검색 결과의 제품명만 보고 설치하지 말고 저장소와 패키지, 버전을 함께 확인하세요. 실제 설치 성공을 기록한 표는 아닙니다.

모델과 프로바이더를 직접 고르는 유연성이 중요하고 현재 설정에 만족한다면 OpenCode에 남아도 좋습니다. 한국어 중심 작업 흐름을 비교하려면 먼저 민감 정보가 없는 합성 저장소를 쓰고, 선택한 각 모델 제공자의 데이터 보관·학습 조건을 확인하세요. OpenCode의 무료 모델도 있지만, 모든 모델 사용이 무료인 것은 아닙니다.

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

아래 비교에서 OpenCode는 anomalyco/opencode를 뜻합니다. 공식 문서 확인일은 2026-11-01이며, 모델과 가격은 바뀔 수 있습니다.

OpenCode의 제품 형태와 프로바이더 설명은 V2 소개와 프로바이더 문서를 참고했습니다. 가격은 미국 달러 표시이며 세금·환율·지역별 결제 조건은 별도로 확인하세요. 이 표는 성능 순위나 동일 과제의 실측 결과가 아닙니다.

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

강점과 한계를 비교해 각 도구가 맞는 경우와 맞지 않는 경우를 구분합니다. 한쪽이 무조건 좋은 것은 아니며 두 도구는 모델 선택과 한국어 작업에 두는 초점이 다릅니다.

OpenCode는 다양한 모델 프로바이더와 로컬 모델을 고를 수 있다는 점이 강점입니다. 그만큼 연결한 서비스의 인증, 청구, 데이터 처리 조건과 설정을 직접 확인하세요. Mirr Code는 한국어로 요구사항을 입력하고 리뷰하는 흐름에 관심이 있을 때 비교할 만합니다. 다만 여기에는 같은 과제를 수행한 결과가 없으므로 Mirr Code가 더 정확하거나 빠르다고 판단할 근거는 없습니다. 프로바이더 선택 폭이나 로컬 모델 연결이 중요하다면 OpenCode를 계속 쓰는 편이 나을 수 있습니다.

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

아직 두 도구의 동일 과제 실행 기록, diff, 테스트 출력은 확보하지 못했습니다. 아래는 실제 실행 결과가 아닌 비교 방법입니다.

먼저 데이터 조건을 확인하세요. 민감 정보가 없는 합성 저장소에서 시험하고, 각 도구에 선택한 모델 제공자의 보관·학습 정책을 확인하세요. OpenCode Console 개인정보 안내(2026-11-01 확인)에 따르면 Big Pickle과 Flint 40B Free는 무료 기간에 수집된 데이터가 모델 개선에 사용될 수 있고, Flint는 30일 보관됩니다. 같은 안내는 NVIDIA의 Nemotron 무료 엔드포인트를 시험용으로 제한하고 개인정보나 기밀 데이터를 제출하지 말라고 합니다. 조건은 모델·제공자별로 다르므로 모든 무료 모델에 이 예외를 적용해서는 안 됩니다.

1. 위 조건을 확인한 뒤, 합성 저장소의 같은 기준 커밋에서 각각 별도 작업 브랜치나 작업 트리를 준비합니다.
2. 동일한 한국어 요구사항과 완료 조건을 입력하고, 모델·버전·설정을 기록합니다.
3. 각 도구가 제안한 변경을 검토하고 같은 테스트 명령을 실행합니다. 실패와 수동 수정도 함께 기록합니다.
4. diff, 실제 테스트 출력, 비용과 소요 시간을 비교합니다. 한 번의 결과만으로 일반적인 우열을 결론 내리지 않습니다.

추가로 필요한 증거: 동일 과제의 실행 기록과 테스트 출력.

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

OpenCode 공식 문서 확인일: 2026-11-01. 위 표의 로컬 모델은 별도 실행 환경이 필요하며, 하드웨어·전기·운영 비용은 무료 모델 요금과 구분해 계산합니다.

Go의 Extra Usage를 켜고 Console 잔액이 있으면 한도 이후 종량제 잔액을 사용할 수 있습니다. Go Teams는 기본적으로 켜져 있다고 안내합니다. Go 요금·한도와 Console 모델별 요금·데이터 조건을 결제 전 다시 확인하세요.

키를 연결하는 경로와 개인 키 없이 시작하는 경로 — 2026-11-02 문서·소스 확인. 아래는 설정을 비교하는 설명이며 실제 인증·요청을 실행한 기록이 아닙니다.

공식 문서에 나온 연결·선택 명령은 다음과 같습니다. 아래 두 줄은 명령 예시이며 응답 출력이 아닙니다. 실제 키는 연결 화면 등 제공자가 안내하는 방법으로 입력하고 대화·문서·Git에 넣지 마세요.

/connect
/models

모델 문서는 무료 모델을 숨기는 OPENCODE_DISABLE_FREE_MODELS도 안내합니다. 공개 dev 소스가 현재 설치 버전과 같다고 가정하지 말고 버전·계정·설정을 기록한 실제 첫 요청으로 확인하세요. 이 비교에서는 그 요청이나 키 저장 파일을 직접 검증하지 않았습니다.

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

V1과 V2는 같은 opencode 명령을 쓰므로, 옮기기 전에 지금 설치된 버전을 먼저 확인하세요. 설정은 직접 파일과 .opencode 중 한 형식으로 통일하고, MCP 서버는 규칙 파일과 별개로 MCP 안내를 보고 다시 연결하세요.

아래 FAQ의 Mirr Code 요금제명·가격·체험 조건과 설치 소요 시간은 이번에 확인하지 못했습니다. 현재 결제 조건은 요금 안내와 실제 결제 화면에서 확인하세요.

무료 범위보다 설정 유지 책임이 부담이라면 다음 후보의 연결 방식을 비교하세요. 단순히 도구를 바꿔도 모델과 키, 보관 정책을 확인할 책임이 사라지지는 않습니다.

OpenCode Console은 선택형이므로 Go나 다른 도구를 결제하기 전에 현재 제공자 설정을 정리하는 것만으로 문제가 해결되는지도 살펴보세요. 위 표는 실제 이전 성공이나 유지보수 시간의 비교가 아닙니다.

무료 설치 다음에 누가 운영할 것인가#

설치가 복잡해서 대안을 찾는다면 모델 구독을 바꾸기 전에 설치 대상을 바로잡는 것이 먼저입니다. **출처 확인(2026-11-03): 공식 V2 소개**의 npm 설치 명령 원문은 다음과 같습니다. 실행하지 않은 공식 명령 예시이며 설치 성공 transcript가 아닙니다.

npm install -g @opencode/cli

이 경로에는 npm을 사용할 수 있는 환경과 전역 패키지 설치 권한이 필요합니다. 해당 소개는 Node/npm의 최소 버전을 명시하지 않으므로 임의의 버전 조건을 붙이지 않습니다. npm 패키지는 postinstall 스크립트로 플랫폼에 맞는 네이티브 opencode 바이너리를 선택합니다. 설치 정책이 스크립트 실행을 막는다면 패키지 이름을 내려받은 것만으로 실행 파일 준비가 끝났다고 보기 어렵습니다. 조직에서 스크립트를 차단했다면 우회 옵션부터 켜기보다 승인된 배포 경로를 선택해야 합니다.

같은 문서는 Bun의 --trust, pnpm의 --allow-build=@opencode/cli를 필요한 스크립트 허용으로 설명하고, Vite+에는 추가 플래그가 필요 없다고 안내합니다. Windows 패키지 관리자는 지원하지 않는다고 명시하면서 Windows ARM64/x64용 독립 CLI 파일을 따로 제공합니다. macOS와 Linux도 아키텍처별 파일을 제공하며 Linux는 glibc와 musl을 구분합니다. 따라서 “npm 명령이 모든 운영체제의 공통 설치법”이라는 판단은 피해야 합니다. 다운로드 방식이 달라도 모델 인증은 다음 단계입니다.

프로바이더를 바꾸기 전에 고정할 조건#

가령 개인 노트북에서 공개 예제만 다루던 개발자가 팀의 비공개 코드를 읽으려 한다고 가정해 봅시다. 소프트웨어는 그대로 OpenCode V2여도 개인 무료 모델, 팀 API 프로젝트와 로컬 런타임은 서로 다른 선택입니다. 아래는 실제 계정이 아닌 채워 놓은 가상 선택표입니다. 이 예에서는 기밀 코드가 외부 무료 엔드포인트로 나가지 않아야 한다는 조건을 우선합니다.

출처 확인(2026-11-02): V2 제공자 문서는 제공자와 사용자 지정 엔드포인트, 로컬 런타임의 설정을 나눕니다. 여기서 “조직 승인”은 예제의 전제이지 특정 제공자의 보안 인증이 아닙니다. 무료 모델을 숨기는 설정이 필요한 팀과 여러 제공자를 계속 고르고 싶은 개인은 같은 기본 구성을 쓸 필요가 없습니다. 반면 Mirr로 옮길 경우 이 제공자 선택을 그대로 유지할 수 있다는 근거는 없으므로 모델 선택이 필수라면 OpenCode를 남길 이유가 생깁니다.

로컬 모델을 고를 때 남겨 둘 질문#

로컬 경로를 선택할 이유는 “무료니까”보다 작업의 제약으로 설명하는 편이 낫습니다. 다음은 가상의 문서 분류 과제입니다. 입력은 공개예제/문의.txt의 세 문장이고 외부 검색과 MCP는 쓰지 않습니다. “로그인이 안 됩니다”는 계정, “청구서가 필요합니다”는 결제, “메뉴 글자가 작습니다”는 화면으로 분류하되 파일을 덮어쓰지 않는 것이 요구입니다. 기대 결과는 원문 순서대로 계정·결제·화면 세 항목입니다.

이 작은 입력에도 응답이 오지 않으면 모델 적재와 런타임 연결을 먼저 살필 수 있습니다. 응답은 오지만 파일 변경 도구를 쓰지 못한다면 추론 가동과 편집 작업의 조건이 다릅니다. 분류는 맞지만 새 원문을 외부 검색에 보냈다면 이 사례의 전송 금지 조건을 만족하지 못합니다. 한 번의 점수 대신 어느 제약 때문에 선택을 유지하거나 바꿀지가 드러나는 시험입니다. 이 과제는 실행하지 않았습니다.

장비가 이미 있어도 작업 중 공유 자원을 차지하는지, 필요한 모델 파일과 업데이트를 누가 관리하는지는 남습니다. 장비를 새로 사야 한다면 구매 비용이 구독료와 다른 지출이라는 점도 고려할 수 있습니다. 여기에는 장비 가격이나 전기료를 가정하지 않았습니다. 외부 연결을 추가하는 순간 이 예제의 전송 금지 조건은 다시 설계해야 하며, 로컬 모델이라는 명칭만으로 연결 도구까지 로컬이 되지는 않습니다.

Go와 Console을 비교할 때 읽어야 할 내역#

Go는 설치의 필수 요건이 아니라 선택형 구독입니다. 따라서 “V2를 쓰려면 Go 결제부터 해야 하는가”에는 아니라고 답할 수 있습니다. 반대로 Go를 선택한 요청과 별도 제공자 키로 보낸 요청을 한 잔액으로 보면 안 됩니다. 위의 모델별 한도와 Console 종량제 수수료는 서로 다른 비용 조건입니다. Go 안내와 모델 안내의 2026-11-01 기록을 기준으로 읽으세요.

가상의 선택 A는 공개 코드 설명만 간헐적으로 요청하고 제공자 선택을 계속 바꾸는 사람입니다. 이 사람에게는 구독을 추가하기 전에 현재 제공자 경로를 유지하는 안이 있습니다. 선택 B는 Go에 포함된 모델을 정해 반복적으로 쓰려는 사람입니다. 이 경우에는 그 모델의 여러 사용 창과 Extra Usage가 핵심입니다. 포함 모델을 벗어난 별도 제공자 사용까지 정액에 들어간다고 가정하면 B의 선택 근거가 무너집니다.

팀 예제에서는 구성원 전원이 같은 구독을 쓴다고 해도 비용 초과를 허용할지 따로 정합니다. Go Teams의 Extra Usage 기본값 설명은 개인 Go와 동일한 선택을 했다는 뜻이 아닙니다. 단가를 비교할 때는 크레딧 구매 처리 수수료와 실제 모델 요율을 각각 놓고 봐야 합니다. 이 사례는 지출 총액을 계산한 예가 아니라 어떤 경로를 선택할지 결정한 예이며 환율이나 예상 토큰 수는 넣지 않았습니다.

오픈코드 대체를 위한 작은 운영 실험#

미실행 합성 과제: 설정/알림.json에 채널 email, 활성 여부 true, 재시도 횟수 0이 있다고 가정합니다. 유효한 채널은 email과 console이고 재시도 횟수는 음수가 아니어야 합니다. 요청은 “음수 입력을 거부하는 검사를 추가하되 0은 허용하고 알림을 실제로 보내지 말라”입니다. 수정 대상은 파서와 그 단위 테스트뿐입니다. 기대 결과는 0 허용, -1 거부, 기존 두 채널 유지입니다.

이 과제에서 선택할 조건은 두 가지입니다. 이미 승인된 제공자와 모델이 있는 팀은 그 경로를 고정하고 OpenCode의 설정 부담만 봅니다. 새 모델까지 고르려는 개인은 제공자 선택과 코드 결과를 한꺼번에 판단하지 않고 먼저 경로를 정합니다. 알림 전송 MCP를 붙이지 않아도 요구를 검토할 수 있으므로 이 예제에는 외부 연결이 없습니다. 에이전트가 실제 전송을 제안하면 필요한 기능을 추가한 것이 아니라 과제 밖 행동을 제안한 것입니다.

같은 이름의 설치를 구분하는 실무 메모#

V2 소개는 mise 경로에도 별도 조건을 붙입니다. mise 2026.10.9 이상이 필요하며 이전 버전은 OpenCode 1을 설치한다고 설명합니다(2026-11-03 확인). 즉 명령 이름이 맞는데 V1 화면이 보이는 상황을 반드시 인증 오류로 볼 필요는 없습니다. 선택한 설치 수단과 그 수단의 버전이 먼저 갈림길이 됩니다. npm 경로와 독립 바이너리 경로의 문제를 같은 해결책으로 처리하지 마세요.

가상 설치 선택표를 채워 보면 다음과 같습니다. macOS ARM64 사용자가 npm을 이미 승인받았다면 V2 npm 명령을 검토할 수 있습니다. Windows x64 사용자는 같은 명령을 공통 해법으로 복사하기보다 공식 독립 x64 배포 경로를 검토합니다. Linux 컨테이너가 musl 환경이라면 glibc 파일과 구분해서 해당 배포 파일을 골라야 합니다. 여기서 환경은 사례의 입력일 뿐 실제 설치 성공을 뜻하지 않습니다.

설정 정리만으로 해결되는지 확인하기#

구체적인 설정 출처도 볼 수 있습니다. **출처 확인(2026-11-03): V2 설정 문서**는 프로젝트의 opencode.jsonc와 JSON/JSONC 형식을 설명합니다. JSONC는 주석과 후행 쉼표를 쓸 수 있는 선택입니다. 전역 설정은 ~/.config/opencode/opencode.json(c), 프로젝트 설정은 직접 파일 또는 .opencode/opencode.json(c) 경로로 안내합니다. 파일 형식을 골랐다는 사실과 특정 모델에 연결할 자격은 다른 문제입니다.

프로젝트 탐색에는 중요한 순서가 있습니다. 현재 위치에서 파일시스템 루트까지 찾은 직접 opencode.json(c)를 바깥에서 안쪽 순으로 합치고, 그 뒤 .opencode 안의 설정을 같은 순서로 합친다고 문서는 설명합니다. 따라서 발견된 .opencode 설정은 직접 파일보다 뒤에서 적용됩니다. “현재 폴더에 가장 가까운 파일이 언제나 이긴다”라는 한 줄로 요약하면 이 형식 간 순서를 놓칠 수 있습니다.

가상 모노레포에서 루트 .opencode/opencode.jsonc는 팀 모델 선택을 두고, 하위 패키지의 직접 opencode.jsonc는 개인 실험 모델을 둔다고 가정합니다. 파일 위치가 가까운 개인 설정이 무조건 우선한다고 기대하면 안 됩니다. 직접 파일과 .opencode 중 한 형식으로 통일하거나, 두 형식의 우선순위를 의도적으로 정하세요. 실제 모델 이름과 키는 예제에 필요 없고 설정 파일도 만들지 않았습니다.

관리형 시스템 설정은 다시 높은 우선순위입니다. 문서는 시스템 디렉터리와 macOS 관리형 환경설정을 설명하고 사용자·프로젝트가 관리자가 정한 값을 덮어쓰지 못한다고 안내합니다. 한편 설정값 병합과 policies의 평가 순서는 같지 않다고 명시하므로 이 절의 파일 병합 순서를 정책 허용·거부에 그대로 적용하지 않습니다. 새 호스트로 옮길 때 팀 관리의 강제 경로가 필요한지 판단할 근거입니다.

이것은 설치 명령보다 뒤의 선택이지만 인증 오류와 혼동하기 쉽습니다. 사용자는 하위 폴더의 모델을 바꿨다고 생각해도 실제 설정 출처가 다를 수 있기 때문입니다. 모델 응답이 오는데 예상 모델이 아닌 것처럼 보이면 새 키를 발급하기 전에 적용할 설정을 먼저 정할 수 있습니다. 반대로 설정을 이해했다고 실제 제공 모델과 청구를 확인한 것은 아닙니다. 필요한 제공자 선택과 한국어 작업면을 유지할지라는 원래 대안 질문에 이 차이를 연결할 수 있습니다.

앞의 알림 과제에서 답변은 오지만 파일을 못 고친다면 무료 여부보다 도구 권한과 선택 모델의 기능이 먼저입니다. 반대로 파일을 읽기 전 제공자 인증에서 멈췄다면 파서 구현을 고칠 이유가 없습니다. 팀 계정만 실패한다면 개인 키로 바꾸는 대신 승인된 연결의 적용 범위를 살펴보는 쪽이 이 사례에 맞습니다. 이 세 경우는 해결할 대상이 서로 다릅니다.

요청을 한국어로 쓰는 불편과 제공자 운영의 불편도 나눌 수 있습니다. “재시도 0을 유지하라”는 요구를 잘 전달하는 것이 목적이면 동일한 입력의 한국어 응답과 변경을 살펴봅니다. 모델을 자주 바꾸는 일이 목적이면 어떤 제공자·모델 조합을 계속 관리할지를 먼저 봅니다. 한국어 터미널이 필요하다는 이유만으로 이미 필요한 로컬 제공자 선택을 포기해야 하는 것은 아닙니다.

전환 판단을 남기는 짧은 결정문#

V2 설정 문서는 업데이트 선택도 전역 설정으로 설명하며 기본은 notify, 프로젝트 값은 무시한다고 안내합니다. 자동 설치와 실행 중 서버의 재시작은 별도라는 조건도 있습니다. 모델 설정을 바꾸는 파일과 업데이트 정책을 정하는 파일의 역할을 혼동하지 않는 편이 좋습니다.

앞의 팀 사례라면 결정은 “OpenCode V2를 유지하고 승인된 API 프로젝트 하나로 연결을 줄인다”가 될 수 있습니다. 이유는 로컬 제공자와 모델 선택이 필수이고 비용 혼란은 소프트웨어 교체보다 연결 책임의 문제이기 때문입니다. 반면 개인 사례에서 제공자 선택이 중요하지 않고 한국어 중심 터미널을 원한다면 Mirr를 별도 후보로 시험할 수 있습니다. 이 결론들은 조건에 따른 가상 판단이며 실제 비교의 승자를 뜻하지 않습니다.

선택을 뒤집을 조건도 구체적입니다. 알림 과제의 0을 잘못 거부하거나 새 의존성을 요구한다면 그 조합은 요구에 맞지 않습니다. 필요한 모델을 현재 계정에서 사용할 수 없다면 모델 선택을 전제로 한 유지안도 다시 봐야 합니다. 새로운 구독의 가격만 보고 이 두 문제를 모두 해결했다고 결론 내릴 수는 없습니다.

유지 결정을 내렸을 때 남길 것#

유지안에서 남길 것은 제공자 후보의 긴 목록보다 실제 사용할 경로입니다. 예제 팀은 승인된 API 프로젝트를 기본으로 두고 개인 무료 모델은 공개 연습 저장소에서만 쓴다고 정했습니다. 로컬 경로는 외부 연결 없는 분류 과제에 한정하고, 알림 전송 기능은 이번 선택에서 제외합니다. 이렇게 용도를 나누면 “무료 OpenCode”라는 한 단어에 서로 다른 결제와 자료가 섞이지 않습니다.

설치 명령과 조건은 공식 문서로 제시할 수 있지만, 실제 설치, 개인 키 없는 첫 요청과 같은 과제의 성과는 아직 확인하지 않았습니다. 따라서 이 글이 제공하는 결론은 현재 기능과 공개 사례에 따른 선택 방향까지입니다.

설정 파일이 병합되는 순서와 업데이트 기본값#

V2 설정 문서는 직접 설정 파일이 .opencode 설정보다 먼저 병합된다고 설명하고, 관리형 설정(managed settings)이 가장 높은 우선순위를 가진다고 적습니다(2026-11-03 확인). 정책(policies)은 스칼라 설정 값의 병합 순서와 별도로 평가됩니다. 자동 업데이트 기본값은 notify이며, 자동 설치는 실행 중인 서버를 재시작하지 않는다고 같은 문서가 설명합니다.

이 순서를 알면 팀 설정과 개인 설정이 같은 키를 다르게 정했을 때 어느 값이 남는지 시험 전에 계산할 수 있습니다. 다만 이 페이지는 실제 설정 파일을 병합해 결과를 아직 확인하지 않았습니다. 필요한 시험은 합성 저장소에서 같은 키를 두 위치에 두고, 실행 결과로 어느 값이 남는지 기록하는 것입니다. 업데이트 기본값은 팀 정책으로 정하고, 개인 설치본의 기본값에 기대지 마세요.

같은 주의가 LSP 항목에도 필요합니다. 출처 확인(2026-11-03): OpenCode LSP 문서는 LSP 연동이 코드 진단·심볼·정의·참조 같은 언어 인식을 제공할 수 있다고 설명하지만, 현재 V2에는 내장 LSP 서버가 없다고 명시합니다. 설정에서 lsp를 true로 두면 내장 서버를 활성화하겠다고 선언하는 것뿐이며, V2가 서버 레지스트리와 실행 경로를 제공하기 전까지 실행에 영향이 없다고 안내합니다. 진단을 필요로 하는 팀은 이 항목을 설정 파일 이전과 함께 자동화도 이어졌다에 넣지 말고, 현재 V2에서 실제로 쓰이는 기능인지 별도 확인하는 항목으로 남길 수 있습니다.

수정·보완 기록#

출처 범위: 설치 명령과 Go·무료 모델의 조건은 공식 문서 항목으로만 적었습니다. 설치, 키 설정과 모델 호출은 이 페이지에서 실행하지 않았습니다.

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

아래 자료의 확인일은 항목별로 다릅니다. V2 소개와 설정 문서는 2026-11-03, V2 제공자 문서는 2026-11-02, V1 소개와 Console·Go 요금 문서는 2026-11-01 기록입니다. 이는 페이지 전체나 Mirr Code 요금에 대한 재검증을 뜻하지 않습니다.

• OpenCode V2 소개·설치: V2 npm 패키지는 @opencode/cli입니다.
• OpenCode 1 소개·설치: V1 npm 패키지는 opencode-ai입니다. V1과 V2는 기본 명령 opencode를 공유하므로 설치가 충돌할 수 있습니다.
• V2 프로바이더, Console 모델·요금, Go 요금·한도: 인증과 과금은 선택한 경로에 따라 다릅니다.
• OpenCode V2 소스: API 키나 Console 연결이 없을 때 무료 모델 경로를 활성화하는 구현입니다. 배포 버전과 서비스 가용성에 따라 동작이 달라질 수 있으며, 이 페이지에서는 실제 호출을 시험하지 않았습니다.
• 옛 opencode-ai/opencode 저장소: 2026-11-03 확인 기준 보관(archived) 상태입니다. 마지막 코드 푸시는 2025-09-18이며 저장소에는 보관 날짜가 적혀 있지 않습니다. README는 이 프로젝트가 Crush로 이어졌다고 안내합니다. 위 Anomaly의 OpenCode와 다른 프로젝트입니다.

아직 확인하지 못한 항목: 설치 명령의 실제 실행 기록, 프로바이더 키 설정과 키 없이 무료 모델을 쓰는 경로의 실제 실행 기록, 같은 과제의 양쪽 transcript·diff·테스트 출력·비용 기록.

그래서 Mirr Code는?#

한국어 중심 터미널 코딩 에이전트입니다. 한국어로 작업을 요청하고 명령을 초성으로 검색할 수 있습니다. HWP·HWPX 문서에 대해 질문하거나 처리 코드를 작성하도록 요청할 수 있지만, 실제 파일 읽기·수정·변환의 지원 범위는 연결된 도구에 따라 달라집니다. 자세한 내용은 한국어 작업 안내를 확인하세요.

현재 가격과 이용 조건은 요금 안내, 모델 설명은 Mirr 1.0 Pro를 참고하세요. 최신 영어 벤치마크나 방대한 생태계 자체가 목적이라면 기존 도구가 더 나을 수 있습니다.

관련#

• MCP 외부 도구 연결