OpenCode

중급

OpenCode는 바이브 코딩 문맥에서 자주 등장하는 개념입니다. 이 페이지는 중급 난이도로 OpenCode의 뜻과 쓰임을 빠르게 이해할 수 있도록 정리한 AI 용어사전 항목입니다.

OpenCode를 처음 보는 독자도 헷갈리지 않도록 정의와 맥락, 관련 용어 6개, 관련 글 1개를 한 페이지에 묶었습니다. 아래 설명을 먼저 읽고, 이어서 연결된 개념과 글까지 보면 이해가 훨씬 빨라집니다.

OpenCode는 터미널에서 동작하는 오픈소스 AI 코딩 에이전트입니다. 공식 문서는 스스로를 오픈소스 AI 코딩 에이전트라고 소개하며, 터미널 화면과 데스크톱 앱, 편집기 확장 세 가지 형태로 쓸 수 있다고 설명합니다. 만드는 곳은 Anomaly이고 소스는 GitHub에 공개돼 있습니다.

설치 경로가 많다는 점이 눈에 띕니다. 공식 문서는 설치 스크립트 한 줄로 시작하는 방법을 가장 빠른 경로로 안내하고, npm과 Homebrew, Arch 리눅스 패키지, Chocolatey, Scoop, Mise, Docker도 함께 지원합니다. 운영체제나 팀 표준에 맞춰 골라 쓸 수 있어서 사내 배포가 수월합니다.

모델을 가리지 않는 설계

OpenCode의 성격을 가장 잘 보여주는 부분은 모델 선택입니다. 특정 회사 모델에 묶이지 않고, API 키를 설정하면 어떤 제공사 모델이든 쓸 수 있습니다. 처음 쓰는 사람을 위해 opencode Zen이라는 자체 게이트웨이도 제공합니다. Zen은 여러 모델과 제공사 조합을 미리 시험해 추천 목록을 만들어 둔 서비스이고, 요금은 100만 토큰 단위 종량제입니다.

ℹ️쉽게 말하면

터미널에서 돌리는 오픈소스 AI 코딩 도구입니다. 어떤 모델을 쓸지 내가 정할 수 있고, 소스가 공개돼 있어서 외부 도구 도입에 심사가 필요한 조직에서도 검토하기 쉽습니다.

Claude Code나 Gemini CLI, Codex 같은 도구와 자리가 겹칩니다. 이들은 각 회사가 자사 모델을 전제로 만든 도구입니다. OpenCode는 모델 제공사가 아닌 곳에서 만들어 여러 모델을 같은 방식으로 쓰게 하는 데 무게가 있습니다. 모델을 바꿔가며 비교하거나, 회사가 이미 계약한 모델을 그대로 써야 하는 상황에서 이 차이가 실질적으로 작용합니다.

CLI 기반 도구의 장점은 자동화입니다. 화면을 띄우지 않고 명령으로 실행할 수 있어서 스크립트나 배포 파이프라인 안에 끼워 넣기 좋습니다. 원격 서버에 접속해 그 자리에서 코드를 고치는 일도 편합니다. 반대로 변경 사항을 눈으로 비교하는 경험은 편집기 쪽이 낫기 때문에, Cline 같은 편집기 기반 도구와 함께 쓰는 사람도 많습니다.

도입할 때 볼 것

오픈소스라는 점은 도입 검토를 크게 단순하게 만듭니다. 에이전트가 어떤 파일을 읽고 어떤 내용을 외부로 보내는지 코드에서 확인할 수 있기 때문입니다. 사내 코드가 외부로 나가는 경로가 문제라면, 로컬에서 모델을 돌리는 Ollama 같은 방식과 묶어 완전히 내부에서만 도는 구성을 만들 수도 있습니다.

실무에서 자주 쓰는 방식은 저장소마다 규칙 파일을 두는 것입니다. AGENTS.md처럼 프로젝트 규칙을 적어 두는 문서를 저장소에 넣어 두면, 에이전트가 매번 같은 기준으로 작업합니다. 코딩 컨벤션, 테스트 실행 명령, 건드리면 안 되는 파일을 미리 적어 두는 것이 반복 설명을 줄이는 가장 확실한 방법입니다.

주의할 점은 자율성의 폭입니다. 터미널 에이전트는 파일을 고치고 명령을 실행할 수 있으므로, 작업 전에 커밋 상태를 정리해 두어야 되돌릴 수 있습니다. 처음에는 승인 단계를 켜 두고 어떤 명령을 실행하려 하는지 확인하면서 감을 잡는 편이 안전합니다. 익숙해진 뒤에 자동 승인 범위를 넓히는 순서가 낫습니다.

터미널 화면이라고 해서 옛날 도구를 떠올릴 필요는 없습니다. 파일 목록과 변경 내용, 대화 기록이 화면 안에 나뉘어 표시되고 키보드만으로 이동할 수 있습니다. 마우스를 잘 쓰지 않는 개발자에게는 오히려 편집기보다 손이 덜 갑니다.

여러 모델을 같은 도구에서 쓸 수 있다는 점은 비교 실험에 유리합니다. 같은 요청을 서로 다른 모델에 던져 결과를 나란히 보면, 어떤 작업에 어떤 모델이 맞는지 감이 빨리 잡힙니다. 회사에서 모델 도입을 검토하는 단계라면 이런 비교가 실제 결정 근거가 됩니다.

설정은 프로젝트 폴더와 사용자 홈 양쪽에 둘 수 있습니다. 팀 공통 규칙은 저장소에, 개인 취향과 API 키는 홈 설정에 두는 방식이 일반적입니다. 키를 저장소에 올리지 않도록 나누는 것이 기본이고, 이 구분을 처음에 정해 두지 않으면 나중에 정리하기 번거로워집니다.

비용은 대부분 모델 요금에서 나옵니다. 도구 자체는 무료지만 긴 파일을 반복해서 읽으면 토큰 소비가 빠르게 늘어납니다. 작업 범위를 필요한 폴더로 좁히고, 주제가 바뀌면 새 세션을 여는 습관이 도움이 됩니다. 계획 단계에는 저렴한 모델을, 실제 수정에는 강한 모델을 붙이는 식으로 나누면 소모를 눈에 띄게 줄일 수 있습니다.