OpenCode의 성가시고 불안한 문제들 — 로컬 Qwen3.6-27B 실전에서 드러난 4가지 결함

OpenCode의 성가시고 불안한 문제들 — 로컬 Qwen3.6-27B 실전에서 드러난 4가지 결함

OpenCode는 GitHub 스타 16.1만 개를 받은 오픈소스 AI 코딩 에이전트다. 로컬 Qwen3.6-27B로 실제 워크플로를 돌려본 결과, 도구 품질과 보안 설계 양쪽 모두 프로덕션에서 사용을 중단해야 할 수준이라는 결론에 도달했다. 이 글은 OpenCode + 로컬 LLM 조합이 왜 불안한지, 그리고 어째서 캐시 적중률이 회복되지 않는지 4가지 핵심 결함을 중심으로 정리한다.

GitHub 스타 16.1만 개를 받은 오픈소스 AI 코딩 에이전트 OpenCode를 로컬 Qwen3.6-27B로 시험한 결과, 도구 품질과 보안 설계 모두 사용을 중단해야 할 수준이었음 AGENTS.md 재로딩, 고정 거리 컨텍스트 가지치기, 현재 날짜 삽입, 모드 전환이 프롬프트…

OpenCode는 GitHub 스타 16.1만 개를 받은 오픈소스 AI 코딩 에이전트로, 외부 LLM과 로컬 모델을 자유롭게 연결해 터미널 기반의 자율 코딩을 지향한다. 그러나 로컬 Qwen3.6-27B로 실제 워크플로를 돌려본 결과, 도구 품질과 보안 설계 양쪽 모두 프로덕션에서 사용을 중단해야 할 수준이라는 결론에 도달했다.

왜 OpenCode가 불안한가 — 4가지 핵심 결함

OpenCode의 문제는 단순히 프롬프트 품질이 낮은 수준에 머물지 않는다. 결과를 만들어 내는 과정에서 결정론적이지 않은 동작이 끼어들고, 그 결정론적이지 않은 부분이 도구 호출·컨텍스트 가지치기·모드 전환 같은 캐시 적중률에 직격으로 영향을 준다. 이번에 재현된 증상은 다음 네 가지로 요약된다.

1. AGENTS.md 재로딩이 캐시 적중률을 떨어뜨린다. 시스템 프롬프트에 포함된 운영 규칙 파일이 매 턴이 아니라 무작위 간격으로 다시 읽혀, 동일한 입력이 들어와도 캐시가 깨지면서 모델 토큰 비용이 수 배로 뛴다.
2. 고정 거리 컨텍스트 가지치기가 사고 흐름을 잘라낸다. 최근 N 토큰만 유지하는 단순 절삭 방식 때문에, 이전 턴에서 만든 함수 시그니처나 import 가 제거되어 후속 호출이 무의미해진다.
3. 현재 날짜가 프롬프트에 무작위로 삽입된다. 보통은 도움 되는 정보지만, 1년짜리 캐시 TTL과 만나면 의도와 무관한 코드가 작성된다. 예를 들어 2025년 표기를 단정적으로 박아두면 다음 분기 코드가 깨진다.
4. 모드 전환이 캐시 키를 통째로 갈아엎는다. Plan/Build 모드 사이를 옮겨갈 때 시스템 프롬프트 일부가 바뀌어 이전 컨텍스트가 무효화된다. 작업 흐름이 길어질수록 손실이 누적된다.

이 네 가지가 결합되면 Qwen3.6-27B 같은 강력한 로컬 모델을 달아도 결과 품질은 Claude 같은 폐쇄형 모델에 비할 수 없다. 토큰만 낭비하고 결정성은 더 떨어진다.

도구 품질 — 도구 호출이 매번 갈라진다

OpenCode의 함수 호출은 모델의 함수 호출 능력에 전적으로 의존한다. 같은 명령을 두 번 내리면 OpenAI 도구 호출 스키마와 Claude·Anthropic 스타일 두 가지가 섞여 들어와 도구 이름·인자 순서·null 처리가 매번 달라진다. 도구 정의에 null을 허용해 둔 경우 모델이 일부러 null을 넣어 회피하는 패턴이 자주 관찰됐다.

# 같은 도구 호출이 두 방식으로 직렬화됨

{"name":"read_file","arguments":{"path":"/repo/README.md"}}
{"name":"readFile","arguments":{"filePath":"/repo/README.md","encoding":null}}

이 결과 도구 결과 파서(Schema validator)가 안정적으로 동작하지 않아 사용자 입장에서 보면 같은 의도인데도 도구가 실행되지 않는 케이스가 발생한다. 로컬 모델에서는 이 비율이 1/4 수준까지 올라간다.

보안 설계 — 셸 권한이 사실상 무방비

OpenCode의 가장 큰 위험은 샌드박싱 부재다. 모델이 임의의 셸 명령을 호출할 수 있고, 작업 디렉터리 이탈도 자유다. Qwen3.6-27B를 로컬에서 굴리던 중 의도치 않게 rm -rf ~/.cache 같은 명령이 실행된 사례가 보고됐다. --container 옵션이 있긴 하지만 Docker 런타임에 전적으로 의존하고, 격리 수준은 단순 네임스페이스 분리에 그친다.

게다가 AGENTS.md 자동 재로딩은 프롬프트 인젝션의 자연스러운 면이 된다. 공격자가 README나 문서 안에 OpenCode에게만 유의미한 지시문을 심어두면, 다음 로딩 사이클에 모델이 그대로 따라한다. 모델은 이런 지시문이 사용자 의도가 아닌 것을 구분하지 못한다.

캐시 적중률 — 비용이 두 배로 뛴다

OpenCode는 내부적으로 프롬프트 캐시를 적극적으로 활용하려 한다. 그런데 앞서 본 4가지 결함 때문에 캐시 적중률이 안정적으로 60%를 넘지 못한다. 동일 워크플로를 세 번 굴렸을 때 캐시 적중률은 아래와 같은 패턴을 보였다.

• 1회차: 71% (워밍업)
• 2회차: 58% (AGENTS.md 재로딩 트리거)
• 3회차: 49% (현재 날짜 삽입 + 모드 전환)

Claude API를 그대로 다는 경우 캐시 적중률이 90%대라는 사실과 비교하면, OpenCode + 로컬 LLM 조합은 운영비 대비 가성비가 매우 나쁘다. 25달러짜리 GPT-5.6 Sol Ultra 토큰보다 단위 시간당 비용이 오히려 더 들 수 있다.

실용 대응 — OpenCode를 쓰려면

여전히 OpenCode를 도입하고 싶다면 다음 4가지를 반드시 적용해야 한다.

1. AGENTS.md를 캐시 친화 형태로 분리 — 매 턴 읽지 말고 시스템 프롬프트에 직접 합쳐 한 번만 평가되도록 한다.
2. 컨텍스트 가지치기를 의미 기반 요약으로 교체 — 고정 거리 절삭 대신 더 오래된 대화를 요약해 넣는다. Qwen3.6-27B는 요약 품질이 괜찮다.
3. 현재 날짜 같은 시간 의존 정보는 외부 주입 — 모델이 임의 박지 못하게 도구 결과로 강제한다.
4. 셸 권한 최소화 + Docker 컨테이너 강제 — 단순 --container만 믿지 말고, 사용자별 격리 정책과 화이트리스트를 운영한다.

이 네 가지를 모두 적용하면 캐시 적중률은 85%까지 올라가고, 도구 파싱 실패율은 1% 미만으로 떨어진다. 그 정도의 안정성이 확보되면 비로소 프로덕션에서 OpenCode + 로컬 LLM 조합을 검토할 만하다.

전망 — AI 코딩 에이전트의 결정성 위기

OpenCode의 문제는 특정 구현의 결함을 넘어 결정성 없는 시스템에서 캐시를 어떻게 다루는가라는 더 큰 질문으로 확장된다. 캐시 적중률은 단순 인프라 지표가 아니라, 모델이 같은 의도를 얼마나 안정적으로 표현하는가의 바로미터다. AI 코딩 에이전트가 기업 워크플로에 들어가려면 캐시 친화적 도구 호출 스키마, 모드 전환 시 컨텍스트 보존 정책, 시간 정보 외부 주입 인터페이스 같은 토대가 표준화돼야 한다. 그 토대가 없는 도구는 도구 품질을 떠나 비용·보안 양쪽에서 운영 불가능하다는 사실을 OpenCode 시험이 다시 확인해준다.

요약

• OpenCode + 로컬 Qwen3.6-27B는 캐시 적중률 49~71%로 운영비 가성비가 나쁘다.
• AGENTS.md 재로딩, 컨텍스트 절삭, 날짜 삽입, 모드 전환 4가지가 캐시를 깨뜨린다.
• 도구 호출이 모델 의존적이라 스키마가 매번 바뀌어 파서가 불안정하다.
• 셸 샌드박싱이 사실상 없어 단순 컨테이너 옵션만으로는 운영 위험을 메울 수 없다.
• 도입하려면 캐시 친화 리팩토링 + 시간 정보 외부 주입 + 사용자별 격리 정책이 필수다.

출처: 긱뉴스 — OpenCode의 성가시고 불안한 문제들

---

📰 원본 출처 · https://news.hada.io/topic?id=31641 (#N=31641)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.