OpenCode 2.0 vs Claude Code, 맥 개발자 이주 판단

먼저 분리해야 할 세 가지 이주 목표

OpenCode 2.0을 검토할 때 “Claude Code의 대체품”이라는 한 문장으로 판단하면 안 됩니다. 실제 목표는 다음 세 가지로 나뉩니다.

• 모델을 바꾸려는 경우: 같은 터미널 흐름을 유지하면서 다른 모델을 시험하려는 목적입니다.
• 도구 잠금을 줄이려는 경우: 한 회사의 구독이나 인증 방식에 묶이지 않고 여러 제공자를 선택하려는 목적입니다.
• 대리인 작업 흐름 전체를 바꾸려는 경우: 계획, 파일 수정, 셸 실행, 자식 대리인, 복구와 승인 정책까지 바꾸는 목적입니다.

OpenCode 2.0은 첫 번째와 두 번째 목표에는 분명한 실험 가치가 있습니다. 공식 문서는 여러 제공자 연결과 자체 API 키, 사용자 지정 끝점, 자체 모델 구성을 안내합니다. 반면 공식 이주 문서는 새 실행 방식을 정기 업무에 쓰기 전에 모델, 인증 정보, 대리인, 권한, 확장 기능을 확인하라고 명시합니다. 이는 기능이 없다는 뜻이 아니라, 현재 단계에서 설정 호환성과 운영 안정성을 별도로 검증해야 한다는 뜻입니다.

이번 주 판단선은 간단합니다.

• 주력 저장소가 배포 일정과 복구 절차를 우선하면 Claude Code 유지입니다.
• 여러 모델, 자체 키, 로컬 모델을 연결해야 하면 OpenCode 2.0 병행 시험입니다.
• 권한 규칙과 설정 형식을 문서화할 담당자가 없으면 이주 평가를 보류합니다.

구독 제한과 자체 키가 바꾸는 비용 구조

Claude Code는 맥, 리눅스, 윈도우의 가상 리눅스 환경에서 실행할 수 있고, 설치 안내에는 맥 운영체제 10.15 이상, 메모리 4GB 이상, 노드 실행 환경 18 이상이 요구 조건으로 제시되어 있습니다. 인증은 앤스로픽 콘솔, 클로드 앱의 유료 요금제, 기업용 클라우드 플랫폼 경로로 나뉩니다. 고정 구독은 작업량이 일정한 사용자에게 예산을 설명하기 쉽다는 장점이 있습니다. (공식 설치 안내)

OpenCode 2.0은 제공자 연결 명령으로 인증 정보를 저장하고, 환경 변수나 사용자 지정 주소를 통해 자체 키와 게이트웨이를 연결할 수 있습니다. 공식 문서는 제공자 목록을 모델 카탈로그에서 구성하며, 자체 호환 끝점과 로컬 모델도 지원하는 흐름을 설명합니다. 따라서 모델 선택의 폭은 넓지만, 비용 관리는 자동으로 해결되지 않습니다.

비용을 비교할 때 모델의 입력 단가만 보면 안 됩니다. 다음 기록을 같은 저장소에서 남겨야 합니다.

1. 같은 기능 요청에 사용한 입력 문맥의 양입니다.
2. 생성된 출력량과 다시 실행한 횟수입니다.
3. 사람이 수정한 시간과 실패 뒤 재시도 횟수입니다.
4. 호출한 제공자와 모델, 요청 경로입니다.
5. 테스트가 끝난 뒤 남은 캐시와 저장된 인증 정보입니다.

고정 구독은 반복 작업이 많고 매일 일정한 양을 처리하는 팀에 유리할 수 있습니다. 반대로 OpenCode 2.0의 자체 키 방식은 짧은 실험, 모델 교체, 특정 작업의 저비용 모델 사용에 유리할 수 있습니다. 그러나 여러 제공자를 연결하면 청구서가 여러 곳으로 나뉘고, 모델이 자동으로 바뀌는 설정에서는 비용 원인을 찾기 어려워집니다.

export ANTHROPIC_API_KEY="시험용_키"
opencode2

예상되는 확인 흐름은 다음과 같습니다.

연결된 제공자 확인
사용할 모델 선택
권한 요청 대기
작업 실행

키를 저장소 설정 파일에 직접 넣으면 안 됩니다. OpenCode 공식 문서도 환경 변수나 연결 기능을 사용하고, API 키와 인증 헤더를 저장소에 커밋하지 말라고 안내합니다.

실패한 작업에서 드러나는 복구 비용

첫 응답이 빠른지가 아니라 실패 뒤 얼마나 빨리 정상 상태로 돌아오는지가 주력 프로젝트에서는 더 중요합니다. 같은 저장소에서 다음과 같은 교차 파일 작업을 시험하는 것이 좋습니다.

• 화면 구성 파일과 상태 관리 파일을 함께 수정합니다.
• 테스트 파일을 추가하고 기존 명령으로 검증합니다.
• 의존성 파일을 변경하되 잠금 파일의 차이를 확인합니다.
• 변경 내용을 하나의 커밋으로 만들지 않고 단계별로 검토합니다.
• 실패를 일부러 남긴 뒤 이전 상태로 되돌립니다.

Claude Code는 명령줄에서 최근 대화를 이어가거나 세션 식별자로 다시 열 수 있는 명령을 제공합니다. 허용 도구와 차단 도구, 계획 권한도 명령줄 인자와 설정 파일로 조절할 수 있습니다. 이런 흐름은 사람이 중간에 개입해야 하는 작업에서 복구 지점을 만들기 쉽습니다. (공식 명령줄 문서)

OpenCode 2.0은 대리인별 권한과 작업 도구를 세밀하게 설정할 수 있습니다. 공식 권한 문서에는 읽기, 편집, 셸, 외부 디렉터리, 자식 대리인과 같은 작업 단위가 제시되어 있으며, 마지막으로 일치하는 규칙이 적용됩니다. 설정은 강력하지만 규칙 순서를 잘못 배치하면 의도한 차단이 풀릴 수 있습니다. (공식 권한 문서)

실행 결과는 다음처럼 기록해야 합니다.

작업 성공: 예 또는 아니오
사람의 개입: 횟수와 개입 이유
수정 파일: 목록
실패 명령: 명령과 오류
복구 방법: 되돌리기, 재실행, 수동 수정 중 하나
최종 테스트: 통과 또는 실패

단일 시연에서 코드가 완성되었다고 해서 안정적인 대리인이라고 판단하면 안 됩니다. 핵심은 같은 작업을 여러 차례 실행해도 변경 범위가 예측 가능하고, 실패 시 원래 상태로 되돌릴 수 있는지입니다.

권한 설정과 코드 데이터 경로

두 도구 모두 터미널에서 실행되지만, 실행 파일이 로컬에 있다는 사실만으로 코드가 로컬에만 남는 것은 아닙니다. Claude Code는 로컬에서 실행되지만 모델과 상호작용하려면 사용자 요청과 모델 출력을 네트워크로 전송합니다. 공식 데이터 사용 안내는 코드와 요청의 처리 방식, 네트워크 전송, 계정 유형에 따른 정책 차이를 별도로 설명합니다. (공식 데이터 사용 안내)

OpenCode 2.0도 연결한 제공자에 따라 데이터 경로가 달라집니다. 클라우드 모델을 선택하면 프롬프트와 필요한 코드 문맥이 해당 제공자 또는 게이트웨이를 통과합니다. 자체 호환 주소를 사용하면 회사 게이트웨이, 기록 시스템, 모델 제공자의 정책을 함께 확인해야 합니다. 로컬 모델을 사용하더라도 확장 기능이나 웹 조회 도구가 별도의 네트워크 요청을 만들 수 있으므로 “공개 저장소라서 안전하다”와 “데이터가 외부로 나가지 않는다”를 같은 뜻으로 보면 안 됩니다.

개인 프로젝트의 최소 기준은 다음과 같습니다.

• 비밀 파일과 개인 키는 기본 차단합니다.
• 처음에는 읽기와 변경 제안만 허용합니다.
• 패키지 설치와 네트워크 명령은 매번 승인합니다.
• 외부 디렉터리는 프로젝트별로 좁게 허용합니다.
• 배포 명령과 원격 저장소 전송은 자동 허용하지 않습니다.

팀 저장소에는 여기에 다음 기준을 더해야 합니다.

• 프로젝트 설정을 저장소에 기록하되 키는 환경 변수로 분리합니다.
• 허용 규칙의 변경을 코드 검토 대상으로 둡니다.
• 게이트웨이에서 사용자·저장소·모델별 사용량을 기록합니다.
• 자동 실행 계정과 개발자 개인 계정을 분리합니다.
• 승인 없이 실행할 수 있는 셸 명령의 목록을 좁게 유지합니다.

OpenCode 2.0의 새 권한 형식에서는 예전 설정의 permission, bash, task 이름을 그대로 사용하지 말고 새 규칙인 permissions, shell, subagent를 확인해야 합니다. 공식 문서가 설정 형식 변화를 별도로 경고하는 이유가 여기에 있습니다.

맥 터미널과 엑스코드의 작업 경계

macOS에서 두 도구를 시험할 때 확인할 것은 설치 성공 여부보다 작업 경계입니다. Claude Code는 공식 설치 흐름에 따라 노드 환경을 통해 설치하고 프로젝트 디렉터리에서 실행합니다. 인터넷 연결은 인증과 모델 처리에 필요합니다.

OpenCode 2.0 역시 터미널에서 저장소를 열고 모델을 연결한 뒤 파일과 셸 작업을 수행하는 방식입니다. 따라서 다음 단계는 비교적 쉽게 병행할 수 있습니다.

1. 저장소를 별도 디렉터리에 복제합니다.
2. 터미널에서 각 도구를 실행합니다.
3. 변경 전후를 git diff로 확인합니다.
4. 엑스코드에서 프로젝트를 열어 파일 인덱싱 상태를 확인합니다.
5. 의존성 설치와 테스트 명령을 별도로 실행합니다.
6. 서명, 시뮬레이터, 보관 파일 생성을 엑스코드에서 검증합니다.

git clone <시험용_저장소>
cd <시험용_저장소>
git status
git diff

출력은 적어도 다음 조건을 만족해야 합니다.

현재 작업 트리: 깨끗함
변경 파일: 예상한 범위 안
의존성 상태: 잠금 파일과 일치
테스트: 통과
엑스코드 빌드: 통과
서명 및 시뮬레이터: 별도 확인

터미널 대리인은 코드 생성과 파일 수정에는 도움을 줄 수 있지만, 엑스코드 프로젝트 설정, 개발자 인증서, 프로비저닝, 시뮬레이터 상태와 최종 보관 파일을 자동으로 보증하지 않습니다. 이 경계를 생략하면 “코드는 완성됐지만 실제 앱을 빌드할 수 없는” 이주가 됩니다.

맥 환경이 계속 필요하지만 주력 장비를 오염시키고 싶지 않다면 NodeMini의 맥 미니 렌탈 환경을 격리 시험용으로 검토할 수 있습니다. 서울에서 접속할 개발자는 서울 맥 미니 렌탈 안내처럼 작업 위치와 접속 조건을 먼저 확인하는 편이 좋습니다.

일주일 병행 시험의 통과 조건

OpenCode 2.0을 정식 이주 대상으로 삼으려면 기능 목록보다 기록표가 필요합니다. 최소 일주일 동안 같은 저장소에서 다음 항목을 기록합니다.

• 작업 성공률과 재실행 횟수
• 사람의 수정과 승인 횟수
• 실패 뒤 복구에 걸린 과정
• 사용한 모델과 제공자
• 청구액을 설명할 수 있는지 여부
• 비밀 파일과 외부 디렉터리 접근 경고
• 엑스코드 테스트와 최종 빌드 결과
• 설정 파일을 유지하는 데 필요한 수작업

이주 결정 체크리스트

아래 항목에서 예가 나온 조건만 통과한 것으로 기록합니다.

• [ ] 같은 코드 저장소에서 두 도구의 작업 결과를 비교했습니다.
• [ ] 교차 파일 수정 뒤 git diff로 변경 범위를 확인했습니다.
• [ ] 실패한 작업을 사람이 되돌리고 다시 실행했습니다.
• [ ] 사람의 개입 횟수와 개입 이유를 기록했습니다.
• [ ] 모델, 제공자, 요청량, 재시도 횟수를 확인했습니다.
• [ ] API 키와 비밀 파일이 저장소에 남지 않았습니다.
• [ ] 셸, 외부 경로, 자식 대리인의 허용 범위를 재현했습니다.
• [ ] 엑스코드 테스트와 시뮬레이터 실행을 별도로 확인했습니다.
• [ ] 서명과 최종 빌드가 통과했습니다.
• [ ] 팀원이 같은 설정으로 다시 실행할 수 있습니다.

판단은 다음 조건으로 나눕니다.

• 모든 항목이 통과하고, OpenCode 2.0이 모델 선택이나 비용 관리에서 분명한 이점을 보이면 시험 저장소에서 일반 저장소로 확대합니다.
• 비용은 줄었지만 실패와 수동 복구가 늘면, 절약된 모델 비용보다 운영 비용이 커진 것이므로 Claude Code를 주력으로 유지합니다.
• 권한이나 데이터 경로를 설명할 수 없으면, 개인 실험 저장소에서만 사용하고 팀 이주는 보류합니다.
• 엑스코드 빌드와 서명이 통과하지 않으면, 터미널 작업이 성공해도 이주를 승인하지 않습니다.
• 설정 변경이 반복되거나 테스트 상태가 계속 불안정하면, OpenCode 2.0은 병행 도구로만 남깁니다.

결론은 세 가지 중 하나입니다.

첫째, 안정적인 납품과 통일된 지원이 가장 중요하면 2026년에도 Claude Code를 주력으로 남깁니다. 둘째, 여러 모델과 자체 API를 쓰는 가치가 크면 OpenCode 2.0을 별도 저장소에서 병행합니다. 셋째, 모델 선택은 OpenCode 2.0에서 하고 복구와 납품은 Claude Code에서 담당하는 장기 조합도 가능합니다. 테스트 단계에서는 이 세 번째 방식이 모델 잠금과 운영 위험을 동시에 줄이는 현실적인 선택이 될 수 있습니다.

주력 맥에서 바로 설정을 바꾸기 어려운 개발자는 원격 맥 환경에서 복제 저장소를 만들고, 일주일 동안 같은 작업·같은 검증·같은 복구 절차를 기록하는 편이 안전합니다. NodeMini의 맥 미니 주문 환경은 이런 격리 시험과 엑스코드 최종 검증을 분리할 때 활용할 수 있지만, 장기간 고정 부하를 처리하거나 물리 장치 연결이 필요한 팀에는 자체 맥 장비가 더 적합할 수 있습니다. 중요한 점은 원격 맥을 도구 우열의 근거로 쓰는 것이 아니라, 이주 전에 실제 납품 경로를 검증하는 별도 환경으로 쓰는 것입니다.