OpenCode 비판에서 드러난 AI 코딩 도구의 권한 설계 문제

OpenCode 비판에서 드러난 AI 코딩 도구의 권한 설계 문제

AI 뉴스 썸네일

오픈소스 AI 코딩 도구 OpenCode를 로컬 모델로 시험한 개발자가 성능과 보안 문제를 함께 제기했어요. 긴 작업에서 입력 캐시가 자주 깨지고, 오래된 도구 결과를 지우는 과정에서 초기 명세까지 잃을 수 있다는 지적이에요. 더 큰 쟁점은 셸 명령을 문자열로 검사하는 권한 장치가 간접 실행과 리디렉션을 제대로 막지 못한다는 점이에요. 1

핵심 요약

구분	핵심	확인할 점
시험 환경	M4 Max에서 로컬 Qwen3.6-27B와 특정 OpenCode Git 버전을 사용했어요	모든 모델과 최신 버전에서 같은 결과가 난다는 뜻은 아니에요
작업 성능	지시 파일 재로딩과 모드 전환이 입력 캐시를 무효화할 수 있어요	긴 세션에서는 첫 응답 대기 시간이 크게 늘 수 있어요
맥락 보존	가지치기와 세션 압축 뒤에 초기 명세나 도구 결과가 사라질 수 있어요	구현 전에 읽은 요구사항을 계속 참조할 수 있는지 봐야 해요
권한 관리	명령 문자열과 경로 패턴만으로 위험한 실행을 가려내기 어려워요	실행 파일, 파일시스템, 네트워크를 별도 경계로 막아야 해요
적용 범위	한 개발자의 특정 버전 시험과 코드 검토에 기반한 비판이에요	OpenCode 전체와 AI 코딩 도구 전반을 같은 수준으로 단정하면 안 돼요

1. 느린 응답보다 권한 경계가 더 큰 문제예요

원문 저자는 OpenCode를 로컬 Qwen3.6-27B와 함께 사용하면서 성능, 작업 맥락, 터미널 사용성, 보안을 차례로 점검했어요. 검토 대상은 특정 Git 커밋이므로 현재 배포판 전체에 그대로 적용되는 평가는 아니에요. 글의 표현도 강한 편이에요. 그래도 코드 경로와 재현 예시를 함께 제시해 어떤 설계를 확인해야 하는지는 구체적으로 보여줘요. 2

긴 작업에서 캐시와 작업 맥락이 함께 흔들려요

OpenCode는 작업 중 지시 파일을 다시 읽고, 현재 날짜와 모드별 설정을 대화 앞부분에 넣어요. 앞쪽 입력이 달라지면 기존 계산 결과를 재사용하기 어려워져요. 저자의 M4 Max 환경에서는 긴 입력을 다시 처리하느라 응답 생성이 시작되기까지 최대 10분이 걸린 사례가 있었어요. 이 수치는 해당 하드웨어와 로컬 모델에서 나온 관찰값이에요.

728x90

속도만 느려지는 것은 아니에요. 오래된 도구 결과를 일정 기준으로 지우면 세션 초기에 읽은 명세도 함께 빠질 수 있어요. 사용자가 잘못된 진행을 중단한 뒤 다시 작업을 이어갈 때, 모델이 원래 요구사항을 보지 못한 채 코드를 작성할 위험이 생겨요. 세션 압축도 전체 작업을 짧은 요약으로 바꾸기 때문에 파일 경로, 예외 조건, 이전 결정처럼 작은 정보가 빠질 수 있어요.

개발팀이 확인할 항목은 명확해요. 중요한 요구사항을 일반 도구 출력과 구분해 보존하는지, 압축 전후에 빠진 내용을 확인할 수 있는지, 작업 인계 내용을 사람이 편집 가능한 파일로 남길 수 있는지 살펴봐야 해요. 세션이 길어졌을 때 속도와 정확도가 동시에 떨어지는지도 짧은 데모가 아니라 실제 저장소에서 시험할 필요가 있어요.

문자열 기반 셸 차단은 우회 경로가 많아요

원문에서 가장 구체적인 대목은 Bash 권한 검사예요. 예를 들어 `git *`을 거부해도 명령을 다른 셸에 전달하거나, 절대 경로와 환경 변수를 쓰거나, Python의 프로세스 실행 기능을 통하면 같은 프로그램을 간접 실행할 수 있다고 지적해요. 리디렉션 대상이 명령 노드 밖에 있으면 허용된 `echo` 명령으로 다른 파일에 쓰는 경우도 놓칠 수 있어요. 2

AI 모델이 악성 코드를 의도적으로 작성하지 않아도 문제는 남아요. 실패한 명령을 다른 방식으로 계속 시도하는 행동이 보안 장치 우회와 같은 결과를 낼 수 있기 때문이에요. `python3` 같은 넓은 명령 접두사에 영구 권한을 주면 다음 세션에서도 예상보다 큰 파일 접근 권한이 이어질 수 있다는 지적도 있어요.

명령 문자열을 더 정교하게 검사하는 것만으로는 한계가 있어요. 실행 가능한 프로그램 자체를 제한하고, 저장소의 `.git` 디렉터리를 읽기 전용으로 두고, 작업 폴더 밖 파일 접근을 운영체제 수준에서 막는 방식이 필요해요. 외부 통신이 필요하지 않은 작업이라면 네트워크도 기본 차단한 뒤 필요한 주소만 열어주는 편이 안전해요.

과거 RCE 사례는 기본 설정의 무게를 보여줘요

원문은 OpenCode의 과거 HTTP 서버 취약점도 근거로 들어요. CVE-2026-22812 설명에 따르면 인증 없이 접근할 수 있는 로컬 서버와 과도하게 열린 CORS 설정이 결합돼, 사용자가 악성 웹페이지를 열었을 때 임의 명령 실행으로 이어질 수 있었어요. NVD는 해당 취약점이 1.1.10 이전 버전에 영향을 줬다고 기록해요. 3

패치된 과거 취약점 하나가 현재 버전도 위험하다는 증거는 아니에요. 다만 코딩 도구는 저장소와 셸에 접근하므로 일반 채팅 앱보다 기본 설정의 책임이 커요. 로컬 서버를 기본으로 열지 않는지, 인증이 필요한지, 웹사이트가 브라우저에서 로컬 API를 호출할 수 있는지, 업데이트 뒤에도 설정이 유지되는지 확인해야 해요.

원문의 평가와 확인된 사실을 나눠 읽어야 해요

"사용을 중단해야 한다"는 결론은 원문 저자의 판단이에요. GeekNews 댓글에 정리된 반론처럼 캐시와 압축 문제는 다른 코딩 도구에서도 나타날 수 있고, 일부 동작은 새 버전에서 바뀌었을 가능성이 있어요. OpenCode 개발에 참여한 댓글 작성자는 V2에서 변경되는 지시를 최신으로 유지하면서 캐시 손실을 줄이는 방식을 시험 중이라고 설명했어요. 이 내용은 정식 릴리스 문서와 실제 코드로 다시 확인해야 해요. 1

따라서 특정 도구를 곧바로 안전하지 않다고 단정하기보다 현재 설치 버전에서 재현되는지 확인하는 편이 맞아요. 보안 문제는 권한 규칙 파일만 읽어서는 판단하기 어려워요. 격리된 시험 저장소에서 외부 파일 읽기, 간접 명령 실행, 리디렉션, 네트워크 접근, 영구 권한 저장을 각각 시험해야 해요.

왜 중요한가요

AI 코딩 도구는 코드를 제안하는 단계를 넘어 파일을 수정하고 테스트를 실행하며 패키지를 설치해요. 이때 정확도 문제는 잘못된 코드로 끝날 수 있지만, 권한 경계 문제는 저장소 손상과 비밀정보 노출로 이어질 수 있어요. 모델 성능표보다 실행 환경의 격리 방식과 감사 기록을 먼저 확인해야 하는 이유예요. 2

팀에서 도입할 때는 운영체제 계정과 작업 디렉터리를 분리하고, 자격증명 파일을 마운트하지 않는 시험 환경부터 시작하는 편이 안전해요. 셸과 네트워크는 기본 거부로 두고 작업에 필요한 범위만 열어야 해요. 명령 실행 전 확인창이 자주 뜬다면 승인 횟수보다 어떤 권한이 얼마나 오래 저장되는지 확인해야 해요.

긴 세션의 품질도 별도 검증 항목이에요. 같은 요구사항으로 짧은 세션과 긴 세션의 결과를 비교하고, 압축 전후에 필수 조건이 남아 있는지 기록해 보세요. 도구가 실패했을 때 다른 경로로 자동 재시도하는지, 사용자가 중단한 뒤 초기 명세를 다시 읽는지도 봐야 해요. 이 과정을 통과하지 못하면 실제 저장소 대신 복사본이나 일회성 작업 공간에서만 쓰는 게 나아요.

참고 자료

1. OpenCode의 성가시고 불안한 문제들 — GeekNews
2. Stop Using OpenCode — wren.wtf
3. CVE-2026-22812 — NVD