OpenCode의 성가시고 불안한 문제들
요약
OpenCode 에이전트 도구의 성능 저하, 메모리 문제, 그리고 심각한 보안 취약점(RCE)을 비판적으로 분석한 글입니다. 에이전트형 CLI 도구가 가진 구조적 한계와 보안 위험성을 지적하며, 더 나은 설계를 촉구합니다.
핵심 포인트
- OpenCode의 코드베이스 비대화로 인한 안정성 및 성능 악화
- 에이전트형 CLI 도구에서 발생하는 원격 코드 실행(RCE) 보안 취약점
- 프롬프트 캐시 미스 및 컨텍스트 압축 문제 등 기술적 불편함
- Claude Code 등 최첨단 모델 에이전트들이 공유하는 공통적 문제점
이 글의 더 나은 제목은 “고치면 OpenCode가 개선될 사소한 불편들” 정도로 보임 AGENTS.md를 매번 다시 읽거나 날짜 변경으로 프롬프트 캐시 미스가 나는 건 감수할 만함 압축과 가지치기가 제대로 작동하지 않는 문제는 Codex와 Claude에서도 봤고, 기본 시스템 프롬프트도 일관성을 위한 것이니 마음에 들지 않으면 바꾸면 됨
이제 코드베이스가 분위기 코딩으로 추가된 기능들 때문에 심각하게 비대해졌고, Claude Code와 똑같은 문제를 보임 안정성·성능·메모리 사용량도 모두 악화됐으며, 예전에는 OpenCode를 좋아했지만 잘 작성된 소프트웨어라고 보긴 어려움
지금은 Pi로 완전히 대체했고, OpenCode에서 배워 필요한 곳에 더 절제된 설계를 적용한 새 선택지도 꽤 있음
OpenCode에서 일하고 있음
이제 도구 호출 가지치기는 하지 않지만, 한정된 컨텍스트 창에서 같은 작업을 오래 이어가려면 현재 진행 상황을 요약해야 하므로 압축은 당분간 필요악임
현재 베타인 V2에는 AGENTS.md, 사용 가능한 기술 등 변경되는 시스템 지시를 최신으로 유지하면서도 캐시 미스를 최대한 피하는 새 방식이 들어감 https://x.com/kitlangton/status/2075749116760457346/video/1
그 내용들은 “Annoying Things”로 분류돼 있으니 “Alarming Things”도 읽어봐야 함
지금 다룬 건 글의 “Annoying Things” 절에 있는 항목들임
별도의 “Alarming Things” 절에는 “It’s Fucking Full of RCEs”라는 하위 절도 있으며, 앞 절에서 드러난 문제로 생기는 것 외에도 여러 원격 코드 실행 취약점이 있음
그래서 OpenCode가 내 코드의 주석을 무작위로 삭제하던 것이었음
에이전트형 CLI의 위험을 잘 정리했지만, OpenCode에만 초점을 맞춘 제목은 두 가지 이유로 이상함
첫째, 명확한 대안을 제안하지 않음. 다수 문제가 근본적이라 거의 처음부터 재설계하고 다시 작성해야 할 수 있으므로 단순히 OpenCode 수정안을 내는 것도 충분치 않지만, 건설적인 제안이 전혀 없어 사실상 “LLM 사용을 중단하라”는 글처럼 보임
둘째, “Alarming Things”의 주요 문제는 OpenCode만의 것이 아니며 Claude CLI와 아마 다른 최첨단 모델 제공사의 에이전트에도 모두 적용됨
그래도 더 나은 도구를 처음부터 만들도록 촉구하는 기록으로는 가치가 커서 북마크하고 널리 공유할 생각이지만, 본문이 훌륭한 만큼 제목과 초점은 더욱 잘못 잡힌 느낌
셸 접근을 허용하면서 임의 명령 실행만 안전하게 막을 수 있다고 어떻게 생각하는지 궁금함
특히 echo git | bash가 여전히 실행된다는 불평은 터무니없어 보임
“OpenCode를 모른다면 인간의 얼굴을 영원히 짓밟는 장화를 상상하라. 장화는 TypeScript로 만들어졌고 얼굴은 1940년대 전자식 컴퓨터 발명 이후 우리가 보안과 시스템 소프트웨어에 관해 배운 모든 것이다”라는 문장은 억지스러운 비유 부문의 Bulwer-Lytton 상 후보감임
이 비유는 George Orwell의 1984에 나오는 “미래의 모습을 보고 싶다면 인간의 얼굴을 영원히 짓밟는 장화를 상상하라”에서 가져온 것임
글의 문체가 지나치게 분노에 차 있고 박함
여러 요점에는 대체로 동의하지만 OpenCode를 “보안 태세가 ‘아빠, 몸을 숙여드릴게요’ 수준인 광대 차 터보 쓰레기”라며 모두 사용을 중단하라고 하는 대목부터는 읽고 싶지 않아짐
이 소프트웨어도 평범한 사람들이 만들었는데, 오픈소스를 이런 식으로 공격하는 게 언제부터 당연해졌는지 모르겠고 내가 만든 소프트웨어가 이런 평가를 받는다면 어떨지 생각하게 됨
이런 정서에는 동의하지만, 이런 문화는 적어도 1990년대부터 있었음
예전 comp.lang.lisp에서도 상아탑 기준에 못 미치는 코드를 쓴 사람을 깎아내리며 즐기는 이들이 있었고, 누군가는 떠났으며 누군가는 실력 향상에 필요한 질책이라 착각해 훈장처럼 받아들였음
관련된 예전 HN 토론: https://news.ycombinator.com/item?id=587045
요즘은 무언가를 “분위기 코딩됐다”고 부르면 공격받는 사람이 없다고 가정하고 과장과 모욕을 퍼부어도 된다는 허가증처럼 쓰임
이런 수사가 유탄을 맞는 개발자와, 그런 행동을 정상화하는 당사자 자신에게 얼마나 해로운지 이해하지 못하는 듯함
“OpenCode 내부 구조를 잘 아는 사람이라면—OpenCode 개발팀은 여기에 포함되지 않는다고 가정하겠다—위의 python3 예시에 이의를 제기했을 수 있다”는 대목은 재미있었음
OpenCode에 기여했더라도 유머 감각이 있다면 웃었을 것이니 모든 걸 너무 심각하게 받아들이지 않아도 됨
지금도 정상적인 표현은 아니지만 새롭지도 않으며, 이런 언어는 오래전부터 존재했음
고객사 기술 스택 때문에 Claude Code를 쓰고 개인 작업에는 특정 버전의 OpenCode를 썼는데, OpenCode가 훨씬 나았기에 이 글이 슬프게 다가옴
지금까지 보고도 넘겼던 이상 현상들이 모두 글과 맞아떨어지고 원인까지 설명됨. 과장된 표현과 정서적으로 동의하지 않는 부분을 제외하면 대체로 맞는 말이라 다른 실행 도구를 찾아야겠음 Pi의 아키텍처가 실제로 더 나은지, 또는 더 좋은 대안이 있는지 추천을 원함
결함과 무관하게 여러 도구를 모두 써본 가운데 OpenCode에서 생산성이 가장 높았음
글에 나온 내용은 대부분 사소한 불편이나 견해 차이이며, 특히 명령 필터링의 목적을 근본적으로 오해했음. 이는 보안 장치가 아니라 모델의 행동을 유도하는 장치임
글쓴이가 OpenCode로 실제 무언가를 만들어본 것 같지 않고, 사용했다면 가장 중요한 결과물의 품질을 전혀 다루지 않았음
나도 OpenCode가 방해하지 않으면서도 컴퓨터를 망가뜨리지 않는 적절한 균형을 갖췄다고 느낌
특히 계획 모드를 쉽게 사용해 빠르게 작업을 끝낼 수 있음
이는 OpenCode가 나빠서라기보다 Pi가 좋아서임. Claude와 Pi를 비교해도 같은 말을 할 수 있음
OpenCode의 장점 중 하나가 LSP 통합인데 Pi에서는 이를 어떻게 처리하는지 궁금함
최근 OpenCode와 Pi를 사용해봤는데, Claude Code에서 넘어온 입장에서는 둘 다 확인 창 없이 기본적으로 편집을 허용하는 듯해 놀랐음
기억상 하나는 설정에서 확인을 켤 수 있고 다른 하나는 플러그인이 필요함
사용자에게 묻지 않고 백그라운드에서 npm 패키지를 내려받는 것을 보고 OpenCode를 완전히 삭제했음
이 동작은 공급망 공격 위험을 더 키움
텍스트를 보여줄 뿐인 TUI 데스크톱 앱이 네이티브 앱은 물론 대부분의 브라우저 기반 데스크톱 앱보다 무거운 건 터무니없으며, RAM·CPU·에너지·배터리를 낭비함
C++ Qt6로 자체 AI 실행 도구 겸 채팅 앱을 개발 중인데, 하위 에이전트, 코드 차이, 터미널 에뮬레이터, 간단한 편집기, Markdown 미리보기, 반투명 배경, 사용자 테마, 권한, MCP, Git 통합, 도킹 시스템, 프로젝트 탭까지 갖추고도 다른 도구보다 가벼움
아직 몇 가지 버그를 제거하고 UI를 단순화하며 다듬는 중이라 공개하지 않았음: https://zeteo.krysoph.com/preview.html
OpenCode가 주석을 삭제하던 이유가 기본 시스템 프롬프트의 “Use ABSOLUTELY NO COMMENTS”였다는 걸 이제 알았고 매우 짜증남
다만 사소한 불편이 아니라 보안 위험은 다른 실행 도구에도 적용됨. 이 도구들은 방대한 데이터에 접근하고 거의 매일 업데이트되며, 분위기 코딩된 특성상 끌어오는 수많은 npm 의존성을 제대로 감사하는 사람이 없을 가능성이 큼 left-pad 같은 사건이 한 번만 터져도 공급망 전체에 재앙이 될 수 있음
시스템 프롬프트에 날짜를 넣어 자정에 캐시가 무효화되는 건 합리적인 결정이며, 다른 실행 도구도 대부분 같은 방식을 사용함
전체 날짜와 시간을 넣는다면 무책임하겠지만 OpenCode는 그렇게 하지 않음
자정에 사용하다 로컬 GPU의 KV 캐시를 다시 채우느라 10분을 기다렸을 때는 합리적으로 느껴지지 않았음
날짜를 세션당 한 번, 또는 오래 실행된 세션이 과거 날짜에 머무는 것을 막기 위해 opencode 바이너리를 실행할 때마다 한 번만 평가하면 간단히 해결 가능함
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기