Copilot CLI, 로컬 AI 모델 선택 기능 추가 및 GA 사양: 주의할 점은?

Copilot CLI에서 로컬 AI 모델을 선택하고 샌드박싱(Sandbox)까지 지원합니다: 주의할 점은 무엇인가요?

Nokka 작성 | 2026년 10월 10일

본 기사는 AI (deepseek-v4.1-flash)가 Hermes Agent를 통해 작성했으며, Nokka에 의해 인간의 통제와 품질 검사를 거쳤습니다.

하루 만에 발표된 두 가지 공지사항이 다른 질문에 답하다

2026년 10월 7일, GitHub는 몇 시간 간격으로 두 가지 소식을 발표했습니다. 첫 번째 소식은 "내가 로컬에서 실행할 수 있는 모델을 사용하고 싶다"라는 질문에 답했고, 두 번째 소식은 "에이전트(Agent)가 내 기기에서 명령을 실행하도록 놔두면 무엇을 할 수 있는가?"라는 질문에 답했습니다.[1][2]

이 두 가지 주제는 관련 없어 보이지만, 종합적으로 보면 같은 문제의 서로 다른 측면을 해결하고 있음을 알 수 있습니다. 즉, 사용자가 실제로 통제할 수 있는 방식으로 에이전트가 기기에서 작동하게 하는 것입니다.

첫 번째 주제: 화면을 벗어나지 않고도 Ollama에서 CLI로 모델 선택하기

CLI 버전 1.0.94-0부터는 /model 명령어가 사용자의 로컬에서 실행 중인 Ollama에 지원되는 모델과 사용자가 직접 설정한 모델, 그리고 GitHub Copilot의 클라우드 모델을 검색합니다.[1]

제가 가장 마음에 드는 부분은 이것이 사용자 대신 결정을 내리지 않는다는 점입니다. 모델을 찾는 것이 자동으로 추가된다는 의미가 아닙니다.

사용자는 스스로 선택해야 하며, 제공업체와 최종 목적지를 확인한 후 "추가하고 이 세션에서 사용" 또는 "미리 추가하되 전환하지 않기" 중 하나를 확정해야 합니다. 선택이 완료되면 CLI를 재시작할 필요 없이 현재 세션에서 바로 사용할 수 있습니다.[1]

만약 제공업체 연결에 문제가 있다면, 옵션에 설명이 표시되어 어떤 부분을 수정해야 하는지 알 수 있도록 도와줍니다.[1]

사용하기 전에 알아야 할 세 가지 사항

1. Ollama와 모델은 미리 설치되어 있어야 합니다. 이 과정은 런타임(runtime)을 설치하거나 모델을 다운로드하지 않습니다.[1]
2. 모델은 도구 호출 및 스트리밍(streaming)을 지원해야 합니다. 그렇지 않으면 이 경로에서 사용할 수 없습니다.[1]
3. 로컬 모델 선택이 오프라인 모드를 활성화하는 것은 아니며, GitHub 사용 데이터 저장을 비활성화하는 것도 아닙니다. 이 두 가지는 별개의 부분입니다. 변경 로그(changelog)에는 CLI의 오프라인 모드도 여전히 환경 변수 COPILOT_OFFLINE=true를 통해 직접 선택해야 한다고 명시되어 있습니다.[1]

저는 세 번째 사항이 사람들이 생각하는 것보다 더 중요하다고 봅니다. 왜냐하면 뒤에 읽어야 할 문장이 붙어 있기 때문입니다.

변경 로그(changelog)에는 오프라인 모드에서도 원격 서비스 제공업체가 네트워크를 통해 프롬프트와 코드 컨텍스트를 수신할 수 있다고 명시되어 있습니다[1]. 이는 오프라인 모드가 스스로 데이터를 네트워크에서 차단하지 않는다는 의미입니다. 만약 이 부분에 대해 확실한 보장이 필요하다면, 서비스 제공업체 설정 문서를 직접 확인해야 합니다[1].

GitHub는 또한 지능형 경로 지정(intelligent routing) 기능을 발표했는데, 이는 작업을 로컬 모델로 라우팅하는 기능이지만 아직 사용 가능하지 않습니다[1].

두 번째 주제: 온디바이스 샌드박스가 프리뷰에서 GA로 전환

두 번째 공지는 자동 에이전트(agent)를 다루는 사람들에게 더 흥미롭습니다. 왜냐하면 이는 '사용자의 장치에서 명령을 실행하는 에이전트가 무엇에 접근할 수 있는가?'라는 질문에 답하기 때문입니다.

온디바이스 샌드박스는 현재 세 곳에서 **GA(General Availability, 일반 사용 가능)**가 되었습니다. 바로 Copilot CLI, Copilot 앱, 그리고 Agent Host를 사용하는 VS Code 세션입니다[2].

이 기능의 역할은 개발자나 조직이 정의한 정책을 기반으로, Copilot이 시작하는 명령이 접근할 수 있는 파일, 디렉터리, 네트워크, 자격 증명 및 시스템의 기타 기능에 대한 접근을 제한하는 것입니다[2].

배후의 구동 엔진은 **Microsoft eXecution Container (MXC)**이며, 이는 MXC로 약칭됩니다. 이 개념은 동일한 샌드박스 정책을 Windows, macOS, Linux 등 각 플랫폼에서 운영체제 수준의 제어 메커니즘으로 변환하는 것입니다[2][4].

사용자가 정의할 수 있는 것들

GitHub 문서에는 CLI에서 제어 가능한 여러 차원이 명시되어 있습니다[3]:

파일 및 디렉터리 : 읽기 전용, 쓰기 가능 또는 경로 거부
네트워크          : 인터넷, 로컬 네트워크의 아웃바운드 통신을 제어하고 개별 호스트를 허가하거나 거부
자격 증명       : Git 및 gh 인증 활성화/비활성화 또는 환경 변수 추가 은폐
...

잘 설계된 부분은 자격 증명(credentials) 처리입니다. 샌드박스 내의 도구는 먼저 대리 값(placeholder value)을 받고, 승인된 HTTPS 목적지로만 실제 자격 증명을 전송하는 온디바이스 프록시가 존재합니다[3]. 제가 이해하기로는 이 개념은 샌드박스 내의 도구가 속임수를 당해 데이터를 외부로 보내는 경우 피해를 줄이기 위해 설계되었습니다.

조직에게 유용한 또 다른 부분은 개발자가 직접 설정하여 완화할 수 없는 **관리자 설정(administrator settings)**입니다[2]. 그리고 이 샌드박스는 GitHub Copilot 사용자에게 추가 비용을 발생시키지 않습니다. 문서에는 표준 유료 좌석 레벨에 대한 언급이 있습니다[2][3].

문서에서 언급된 세 가지 간극

이것은 제가 신뢰하기 전에 읽어야 할 부분이며, GitHub의 문서에 명시되어 있고 숨겨진 부분이 아닙니다.

1. CLI 자체가 샌드박스 안에 있지 않다

이것은 천천히 읽어야 하는 내용입니다. 시스템 전체의 범위를 설명하고 있기 때문입니다.

CLI에 포함된 파일 관리 도구는 CLI 자체의 명령어이며, sed와 같은 셸(shell) 명령어가 아닙니다. 그리고 이것은 CLI와 동일한 프로세스 내에서 실행됩니다[3]。

CLI가 샌드박스 안에 있지 않기 때문에, 운영체제 수준의 샌드박스는 이러한 도구들이 수행하는 파일 작업을 볼 수 없고 통제할 수도 없습니다[3]。

대신에, 이러한 도구들은 자체적으로 샌드박스 정책을 확인하고 사용자의 설정에 따라 **최선의 노력(best-effort)**으로 작동하도록 작성되었습니다[3]。

여기서 '최선의 노력'이라는 말은 비난이 아니라 범위의 한계를 알려주는 것입니다. 즉, 이 통제는 운영체제의 강제 메커니즘에서 나오는 것이 아니라 소프트웨어 수준에 머물러 있다는 의미입니다.

2. 원격 MCP 서버는 전혀 샌드박스되지 않는다

문서에는 로컬 MCP 서버와 언어 서버가 샌드박스 내에서 실행될지 여부를 선택할 수 있다고 명확하게 나와 있지만, 원격 MCP 서버는 샌드박스되지 않습니다[3]。

만약 원격 MCP에 연결하여 사용한다면, 설정한 제한 사항이 그 경로까지 포괄하지 못합니다.

3. 격리 수준은 스펙트럼의 낮은 끝에 있다

문서는 자체적으로 기술적 격리가 하이퍼바이저(Hypervisor)나 완전한 컨테이너와 같은 강력한 방식부터 프로세스 및 운영체제 파일 시스템을 가두는 약한 방식까지 스펙트럼으로 존재함을 인정합니다. 그리고 현재의 온디바이스 샌드박스는 그 스펙트럼의 낮은 끝에 위치합니다[3]。

직역하자면, 이는 단일 프로세스가 네트워크에서 무엇을 읽고, 쓰거나 접근할 수 있는지 제한한다는 의미입니다. 하지만 사용자의 명령을 가상 머신이나 별도의 컨테이너 내에서 실행하는 것은 아닙니다[3]。

만약 더 강력한 격리가 필요하다면, 문서에서는 사용자 스스로가 이 수준이 자신의 위험도에 적합한지 평가해 보라고 권고합니다[3]。

제가 읽기로는 이 세 가지 사항이 기능 자체를 손상시키는 것은 아닙니다. 범위를 명확히 밝혀주는 것이 사용자가 통제할 수 있다고 오해하게 만드는 것보다 낫기 때문입니다.

고려해야 할 관점은 이것이 모델과 관련이 없다는 것입니다.

제가 생각하기에 독자들이 자주 건너뛰지만 시스템 보안을 이해하는 방식에 큰 영향을 미치는 발표 내용이 하나 있습니다. 바로 **모델 실행과 도구 분리(Tool Separation)**를 별개의 문제로 다룬 것입니다. 샌드박스 정책은 Copilot이 어떤 모델을 사용하든 관계없이 도구 실행에 적용됩니다[2].

다시 말해, 비록 여러분이 완전히 자체 로컬 모델로 전환하더라도 여전히 기존의 샌드박스 정책 하에 놓여 있으며, 그 반대도 마찬가지입니다. 즉, 좋은 샌드박스는 모델 자체가 아니라 정책에서 비롯된다는 것입니다.

제 관점에서 볼 때, 이것은 이 두 발표 내용 중 가장 기억해야 할 문장입니다. 왜냐하면 사람들이 흔히 혼동하는 두 가지 우려 사항을 분리하고 있기 때문입니다.

시작하려면 (간단 가이드)

1. CLI를 1.0.94-0 이상으로 업데이트해야 로컬 모델 검색 명령어 /model을 사용할 수 있습니다[1].
2. Ollama를 설치하고 도구 호출이 가능한 모델을 미리 다운로드하세요. 시스템이 자동으로 처리해주지 않습니다[1].
3. 여러분이 실제로 사용하는 경로가 샌드박스 정책에 포함되는지 확인하세요. 특히 원격 MCP 서버에 의존하는 경우, 해당 경로는 샌드박스 범위를 벗어날 수 있습니다[3].
4. 오프라인 모드가 자동으로 네트워크에서 데이터를 분리해준다고 가정하지 마세요. 서비스 제공업체의 설정을 확인해야 합니다[1].

누가 이 글을 읽어야 하는가

로컬 모델을 사용해보고 싶지만 현재 사용하는 CLI를 벗어나고 싶지 않은 개발자라면, 이 두 발표 내용이 그 경로를 매우 짧게 만들어 주었습니다.

조직 내에서 에이전트 사용을 승인해야 하는 사람이라면, 두 번째 발표 내용을 자세히 읽어야 합니다. 왜냐하면 그것은 정책을 강제하는 도구와 그 범위에 대한 설명을 동시에 제공하기 때문입니다. 저는 이것이 희귀하다고 생각합니다. 보통 제조사들은 실행 가능한 부분만 작성하는 경향이 있습니다.

여러 팀이 개발자 장치에서 명령어를 실행하는 에이전트를 사용한다면, 현재 그것이 무엇을 건드릴 수 있는지, 그리고 누가 그 범위를 정의하는지 알고 계십니까?

참고 자료

[1] GitHub,

[2] GitHub, "GitHub Copilot을 위한 로컬 샌드박싱이 일반 사용 가능(GA)", github.blog 변경 로그, 2026년 10월 7일. [https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available]

[3] GitHub, "GitHub Copilot을 위한 클라우드 및 로컬 샌드박스에 대하여", GitHub Docs, 2026년. [https://docs.github.com/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes]

[4] Microsoft, "mxc (Microsoft eXecution Container)", GitHub 저장소, 2026년. [https://github.com/microsoft/mxc]