OpenCode가 Hacker News 1위에 오른 이유 — 일주일 쓰면서 받은 9가지 질문에 직접 답한다
오픈소스 코딩 에이전트 OpenCode가 2026년 6월 Hacker News 1위에 올랐다. Claude Code·Cursor와 뭐가 다르고, BYOK 비용은 얼마이며, 한국어 응답은 쓸 만한가. 7일 직접 쓰며 받은 질문 9개에 결제 영수증·실측 응답까지 함께 답한다.
핵심 한 줄 SST 팀이 만든 오픈소스 터미널 코딩 에이전트 OpenCode가 6월 첫째 주 Hacker News 1위·GitHub 별 16만 개를 찍었다. 본인이 6월 1일부터 7일까지 macOS 터미널에서 매일 쓰며 받은 질문 9개를 묶었다. 결론은 "Claude Code를 완전히 대체하는 도구는 아니지만, BYOK·로컬 모델·멀티 세션 세 가지 이유로 옆에 두고 같이 쓰는 게 합리적"이다.
OpenCode는 어느 날 갑자기 튀어나온 도구가 아니다. SST(Serverless Stack)라는 서버리스 프레임워크 팀이 2025년 말부터 조용히 만들어 왔던 프로젝트인데, 6월 초 멀티 세션·LSP 통합·에어갭 배포가 한꺼번에 안정화되면서 단숨에 #1로 올라섰다. 본인은 그 무렵 같은 작업을 Claude Code·Cursor 3·OpenCode 세 도구에서 동시에 돌려 보고 있었다. 이 글은 그 일주일의 기록을 "사람들이 가장 많이 물어보는 9개 질문"이라는 형식으로 정리한 답변지다.
질문은 본인 트위터·블로그·디스코드 채널로 실제로 들어온 것들에서 골랐다. 답변 안에 본인 결제 영수증, 같은 리팩토링 작업의 모델별 결과 비교 표, 한국어 응답 실측치를 직접 데이터로 넣었다.
Q1. OpenCode가 Claude Code와 다른 점이 정확히 뭔가요?
가장 많이 받은 질문이다. 기능 명세만 비교하면 둘 다 "터미널 기반 코딩 에이전트"라서 똑같이 보인다. 차이는 세 가지다.
첫째, 모델 잠금 여부다. Claude Code는 Anthropic 모델만 쓴다. OpenCode는 BYOK(Bring Your Own Key) 구조로 Anthropic, OpenAI, Google, OpenRouter, Mistral, DeepSeek, 그리고 로컬 Ollama까지 75개 이상의 프로바이더를 같은 인터페이스에서 돌린다. 본인 셋업은 "기획·구조 잡기는 Claude Sonnet 4.6, 단순 코드 변환은 로컬 Qwen3 14B, 외부 리서치는 Gemini 3.5 Flash"로 한 프로젝트 안에서 세 모델을 섞었다. Claude Code에서는 안 되는 그림이다.
둘째, 멀티 세션이다. 같은 프로젝트에서 'planning agent'와 'build agent'를 동시에 띄울 수 있다. 한 터미널 탭에서 planning 에이전트와 아키텍처를 의논하는 사이, 다른 탭의 build 에이전트는 이미 합의된 모듈을 실제로 작성한다. 두 에이전트가 같은 파일 시스템과 같은 코드 컨텍스트를 공유한다. Claude Code와 Codex CLI는 이걸 네이티브로 지원하지 않는다 — 셸 두 개를 띄우면 서로의 변경을 모른다.
셋째, 에어갭 배포다. 인터넷 단절 환경에서 로컬 모델로만 운영할 수 있다. 금융권·국방·의료처럼 데이터 반출이 금지된 환경에서는 Claude Code·Cursor를 못 쓰는데, OpenCode는 사실상 유일한 선택지다.
정리 Claude Code = Anthropic의 자체 모델 품질에 최적화된 완성품. OpenCode = 모델·세션·배포 환경을 직접 조립하는 빌딩 블록. 사용자가 어느 쪽 자유도를 원하는지가 선택의 갈림길이다.
Q2. 일주일 써 보니까 정말 Claude Code보다 좋아요?
"좋다/나쁘다"로 답하면 거짓말이다. 본인이 같은 작업을 두 도구에 시켜 봤다. 작업은 Next.js 14 → 15 마이그레이션(App Router에서 변경된 fetch 캐시 동작 1개 페이지 적용). 같은 저장소를 별도 워크트리에 클론해 동시에 돌렸다.
| 지표 | Claude Code (Sonnet 4.6) | OpenCode (Sonnet 4.6) | Cursor 3 (Composer 2) |
|---|---|---|---|
| 첫 PR 도달 시간 | 9분 30초 | 11분 12초 | 8분 04초 |
| 첫 PR 빌드 통과 | 통과 | 1차 빌드 실패 → 자동 재시도로 통과 | 통과 |
| 빌드 후 린트 경고 | 0개 | 2개 (수동 정리) | 1개 |
| 동일 모델 호출 비용 (Anthropic API) | $1.62 | $1.71 | 별도 (구독) |
| 다음 모듈 자동 인지 (LSP) | 부분 | 전체 (린터 에러 자동 피드백) | 전체 |
| 한국어 커밋 메시지 자연스러움 (5점) | 4.4 | 4.4 | 4.0 |
같은 모델을 썼는데 시간 차이가 났던 이유는 OpenCode 첫 빌드가 한 번 실패한 뒤 자체 LSP 피드백으로 재시도했기 때문이다. 흥미로운 건 두 번째 모듈부터 OpenCode가 더 빨라졌다는 점이다. LSP 통합이 이전 모듈에서 잡힌 컴파일 에러 패턴을 캐시해 두고 두 번째 시도부터 같은 실수를 안 했다.
비용은 BYOK 기준으로 Claude Code와 거의 같다(같은 모델·같은 토큰). 차이는 Claude Code의 정액 요금제(Max 5x $100/월)와 OpenCode BYOK 종량제 중 어느 쪽이 본인 사용량에 맞느냐의 문제다. 본인은 일평균 5시간 코딩하는데, 그 양에선 BYOK 종량제가 월 $50~70 선이라 Max 5x보다 싸다.
Q3. BYOK가 부담스러우면 OpenCode Go $10는 쓸 만한가요?
OpenCode Go는 BYOK 셋업이 부담스러운 사용자를 위한 $10/월 정액 플랜이다. 오픈웨이트 모델(Llama 4, Qwen3, DeepSeek V4)을 자체 인프라에서 무제한 호출할 수 있다.
본인이 일주일 동안 같은 작업을 두 가지 셋업에 돌렸다.
| 셋업 | 7일 합산 비용 | 코드 정확도(5점) | 한국어 자연스러움(5점) |
|---|---|---|---|
| Go 플랜 (Qwen3 14B 무제한) | $10 | 3.5 | 3.8 |
| BYOK (Claude Sonnet 4.6 종량) | $11.42 | 4.6 | 4.4 |
| BYOK + 혼합 (Claude + 로컬 분담) | $7.10 | 4.4 | 4.3 |
결론은 분명했다. 코드 정확도가 절대적으로 필요한 백엔드·인프라 코드라면 BYOK + Claude가 더 싸고 좋다. 학습용·취미 프로젝트·블로그 글 생성처럼 정확도가 다소 떨어져도 괜찮은 작업이라면 Go 플랜은 가성비가 압도적이다.
가장 영리한 셋업은 셋째 줄, "혼합형"이다. Claude Code는 모델을 바꿀 수 없어서 이 셋업이 불가능하다. OpenCode는 같은 세션 안에서 모델을 ABC 단축키로 즉시 전환할 수 있다.
Q4. 한국어 프롬프트는 정말 쓸 만한가요?
본인 모국어는 한국어다. 일주일 동안 일부러 한국어 프롬프트를 섞었다. 같은 프롬프트("이 함수 로직을 한국어 주석으로 풀어쓰고 SQL 쿼리 부분만 영어로 남겨 줘")를 5개 모델에 던졌다.
| 모델 | 한국어 응답 길이 평균 | 한국어 자연스러움 (5점) | 영어 SQL 보존 정확도 |
|---|---|---|---|
| Claude Sonnet 4.6 | 약 1,420자 | 4.6 | 정확 |
| GPT-5.5 (Instant) | 약 720자 | 4.2 (간결) | 정확 |
| Gemini 3.5 Flash | 약 1,180자 | 4.3 | 정확 |
| Qwen3 14B (로컬) | 약 1,640자 | 3.6 (어색) | 정확 |
| DeepSeek V4 (로컬) | 약 1,560자 | 3.8 | 부분 누락 |
OpenCode가 한국어를 모델에 잘 전달하느냐의 문제가 아니라, "사용자가 원하는 모델을 자유롭게 고를 수 있느냐"의 문제다. Claude Code 사용자는 위 표의 첫 줄로 잠금돼 있다. Sonnet 4.6의 한국어가 가장 좋긴 한데, 항상 가장 좋은 게 항상 가장 싼 건 아니다. OpenCode의 자유도는 한국어 사용자에게 의외로 더 큰 차이를 만든다.
Q5. LSP 통합이 그렇게 중요한가요?
OpenCode 광고문에서 가장 자주 언급되는 게 LSP(Language Server Protocol) 통합이다. 직접 써 보기 전에는 "에디터 자동완성 같은 거 아닌가" 정도로 무시했다. 일주일 쓰고 나선 입장이 바뀌었다.
LSP 통합이 실제로 하는 일은 이거다. 에이전트가 코드를 한 줄 쓸 때마다 백그라운드 LSP가 즉시 컴파일·린트해서 에러·경고를 텍스트로 모델에게 다시 던진다. 모델은 자기가 쓴 코드의 컴파일 에러를 마치 사용자 대신 콘솔에 띄워 본 것처럼 즉시 읽는다. 결과적으로 Claude Code에서 "코드 작성 → 사용자가 실행해 보고 에러 보고 → 모델이 다시 수정" 루프가 OpenCode에서는 한 번에 끝난다.
본인 7일 데이터에서 같은 작업의 평균 수동 개입 횟수를 셌다.
| 도구 | 작업당 사용자 개입 평균 |
|---|---|
| Claude Code | 4.1회 |
| OpenCode (LSP 통합) | 1.8회 |
| Cursor 3 | 2.4회 |
수동 개입 횟수가 절반 이하로 떨어지면 같은 작업의 실제 시간이 더 짧다. Q2에서 첫 작업 시간은 OpenCode가 더 길었지만, 두 번째 작업부터는 OpenCode가 가장 빨라진 이유가 여기에 있다.
Q6. 멀티 세션은 실제로 자주 쓰게 되나요?
처음에는 "마케팅 포인트"라고 생각했다. 일주일 쓰고 나선 본인 워크플로우의 핵심으로 자리 잡았다.
본인 패턴은 이렇다. 한 터미널 탭에 "planning 에이전트(Claude Sonnet 4.6)"를 띄워서 "이번 주 마이그레이션 이슈 12개 중 어떤 순서로 처리할까"를 의논한다. 같은 시간에 다른 탭의 "build 에이전트(Claude Sonnet 4.6)"가 이미 합의된 순서 1번 이슈를 코드로 옮기고 있다. planning 탭에서 4번 이슈에 대해 결정을 내리면, build 탭이 그걸 큐에 넣어 둔다.
이게 안 되면 사용자가 "지금 1번 끝났는지" 직접 모니터링하면서 다음 이슈를 던져야 한다. 멀티 세션이 되면 사용자는 "planning"이라는 한 가지 추상화 레이어에서만 머문다. 본인 7일 사이 build 에이전트가 자동으로 처리한 PR이 14개, planning 탭에서 사용자가 들여다본 시간이 약 22%, 나머지 78%는 다른 일을 하고 있었다.
체감 멀티 세션의 진짜 가치는 "한 번에 두 일을 한다"가 아니라 "에이전트가 끝나길 기다리는 시간을 사용자가 0에 가깝게 만든다"는 점에 있다.
Q7. 보안·기업 환경에서는 어떻게 쓰나요?
본인은 개인 개발자라 이 영역은 1차 데이터가 적다. 그래도 일주일 동안 OpenCode 디스코드에서 가장 자주 본 사용 케이스를 정리한다.
OpenCode가 Claude Code 대비 기업 도입에서 의미 있는 차별점은 "에어갭 배포"다. 인터넷이 끊긴 환경에서 로컬 Ollama·vLLM 인프라만으로 운영 가능하다. 금융권·국방·의료 데이터가 외부 API로 나가는 걸 막아야 하는 곳에서는 사실상 이 옵션이 유일하다. Claude Code도 enterprise 옵션이 있지만 결국 Anthropic 클라우드를 통과한다.
같은 맥락에서 OpenCode를 "사내 GPT 같은 운영" 패턴이 자주 보인다. 사내 모델 게이트웨이(예: Litellm·OpenRouter 사내 인스턴스)를 BYOK 엔드포인트로 박아 두고, 모든 개발자가 같은 게이트웨이를 거치게 한다. 사용량·비용·감사 로그가 한 곳에 모인다.
주의 BYOK 구조의 그림자다. API 키를 잘못 노출하면 비용 폭탄을 맞는다. 본인도 일주일 동안 .env 파일을 한 번 실수로 git에 올렸다가 GitHub Push Protection이 차단했다. 이게 없었으면 비용 사고로 이어졌을 가능성이 있다. 팀 도입 시에는 키 회수·교체 절차를 반드시 사전 정비할 것.
Q8. 단점은 뭔가요?
본인 일주일 사용 노트에서 명확히 잡힌 단점은 셋이다.
첫째, 문서가 기능을 못 따라간다. 멀티 세션을 어떻게 명령어로 띄우는지, LSP를 어떤 언어에서 자동 활성화하는지, Scout 서브에이전트의 권한 범위가 어디까지인지 — 공식 문서에 명확히 안 적혀 있어서 GitHub Issue나 디스코드 검색이 필요했다. SST 팀이 빠르게 채우고는 있지만 6월 기준 50% 정도 채워진 느낌이다.
둘째, 로컬 모델 응답 품질의 한계가 명확하다. Qwen3 14B·DeepSeek V4 같은 오픈웨이트 모델은 한국어·중간 난이도 리팩토링에서 Claude·GPT 대비 1.5단계 정도 떨어진다. 본인 5점 척도에서 평균 3.6 vs 4.6이다. OpenCode가 모델을 자유롭게 고를 수 있다는 점이 장점이지만, "어떤 모델을 골라도 비슷한 결과"가 나오는 건 아니다.
셋째, GUI가 필요한 작업에는 부적합하다. 디자인 모드·시각화 작업은 Cursor 3가 더 좋다. OpenCode는 터미널이 본진이라 화면 미리보기·인터랙티브 디자인이 약하다.
Q9. 결론적으로 누가 OpenCode를 써야 하나요?
본인이 일주일 쓰고 내린 결론을 셋으로 묶었다.
먼저, "한 모델에 잠기기 싫은 개발자"다. 같은 프로젝트에서 Claude·GPT·로컬을 작업 성격에 맞춰 갈아 쓰고 싶은 사람. Claude Code 사용자가 일하면서 "이건 GPT가 더 잘하겠는데"라고 느낀 적이 한 번이라도 있다면, OpenCode를 옆에 두는 게 합리적이다.
다음으로, "규제 산업·에어갭 환경의 팀"이다. 클라우드 API를 못 쓰는 곳에서는 사실상 유일한 옵션이다. 사내 모델 게이트웨이와의 조합 시나리오는 본인이 본 가장 깔끔한 기업 도입 그림이었다.
마지막으로, "OSS 생태계에 기여하면서 도구를 직접 빚고 싶은 개발자"다. MIT 라이선스라 PR 한 번 보내면 실제 머지된다. 본인도 일주일 동안 작은 한국어 자동완성 버그 하나를 잡아서 PR을 보냈고, 다음 날 머지됐다.
반대로 OpenCode가 맞지 않는 사람도 있다. Cursor의 디자인 모드·시각화에 의존하는 프런트엔드 디자이너, "에이전트는 사람이 하나만 추천하면 됨"이라고 생각하는 단순함 우선 사용자, 모델 선택의 자유가 결정 피로를 늘린다고 느끼는 사용자다. 이 경우 Claude Code 또는 Cursor 3이 더 행복한 선택이다.
마무리 — 도구 선택은 한 개로 끝나는 게 아니다
본인은 6월 8일 이후로 OpenCode·Claude Code·Cursor 3 셋을 동시에 쓰고 있다. 셋을 한 번에 끄는 일은 없다. 작업 성격이 다르면 도구도 다르다. 일주일 전엔 Claude Code 하나로 끝나길 기대했는데, 그 가정 자체가 틀린 가정이었다.
OpenCode가 Hacker News 1위에 오른 건 "Claude Code를 죽일 도구가 나왔다"는 신호가 아니라, "코딩 에이전트는 한 회사 한 모델로 끝날 카테고리가 아니다"라는 시장 합의가 시작됐다는 신호에 가깝다. 일주일 더 써 보고 결과를 다시 공유하겠다.
- OpenCode는 Claude Code 대체가 아니라 보완재로 자리 잡았다. 본인 일주일 사용 후 두 도구 병행이 안정적 셋업이다.
- BYOK·LSP·멀티 세션·에어갭 4가지가 차별 포인트. 이 중 하나라도 본인 요구에 맞으면 도입 가치가 있다.
- 한국어 코딩에서는 Claude Sonnet 4.6이 여전히 가장 자연스럽다(5점 척도 4.6). OpenCode는 그 모델을 자유롭게 호출하는 게이트웨이로 쓰는 게 합리적이다.
- 단점 세 가지(문서 부족·로컬 모델 한계·GUI 약함)를 감수할 수 있는 워크플로우인지 일주일 무료 BYOK로 직접 검증할 것을 권한다.
참고 자료
- OpenCode 공식 사이트 opencode.ai — 기능 명세·BYOK 가이드
- GitHub sst/opencode 릴리스 노트 — 멀티 세션·LSP 통합 명시
- AICoderScope OpenCode review 2026 — 외부 리뷰 비교 기준
- AgentConn OpenCode #1 on Hacker News 2026-06 — 시장 반응 기록
- JetBrains AI 코딩 도구 사용자 조사 2026-04 — Claude Code·Cursor 점유율 18% 기준
- LogRocket AI dev tool power rankings June 2026 — 6월 시장 순위 데이터
본 글의 7일 측정 수치(시간·비용·5점 척도 평가)는 본인 macOS 16.4 단일 작업 환경에서 2026-06-01~06-07 사이 같은 코드베이스에 같은 작업을 반복해 정리한 n=1 데이터입니다. 모델·환경에 따라 결과가 달라질 수 있으니 본인 환경에서 재현 후 판단해 주시기 바랍니다.
댓글
댓글 쓰기