GitHub은 이번 주에 대부분의 개발자가 자신의 에디터가 고장 나지 않는 한 절대 읽어보지 않을 법한 종류의 엔터프라이즈 설정을 추가했습니다.

엔터프라이즈 관리 설정(Enterprise managed settings)은 이제 VS Code 및 GitHub Copilot CLI를 위한 strictKnownMarketplaces를 지원합니다. 쉽게 말해, 조직은 사람들이 실제로 사용하는 개발 도구 내에서 어떤 확장 프로그램(extension) 및 플러그인 마켓플레이스(plugin marketplaces)가 알려져 있고 허용될지를 제한할 수 있습니다.

이것은 데스크톱 관리처럼 들립니다.

하지만 저는 이것이 그보다 더 흥미롭다고 생각합니다.

만약 코딩 에이전트(coding agents)가 IDE나 터미널에서 도구를 발견하고, 플러그인을 설치하며, 명령을 호출하고, 리포지토리(repositories)를 읽고, 파일을 수정하며, 워크플로(workflows)를 실행할 수 있다면, 플러그인 마켓플레이스 정책은 더 이상 사소한 선호 사항이 아닙니다. 그것은 런타임 경계(runtime boundary)의 일부입니다.

에이전트에게는 단순히 생각할 권한만 필요한 것이 아닙니다.

도구에 손을 뻗을 권한도 필요합니다.

그리고 그 도구들이 어디에서 오느냐 하는 지점이 이제 보안 표면(security surface)이 되었습니다.

도구 카탈로그가 개발자에게 더 가까워졌다

오랫동안 확장 프로그램 마켓플레이스는 생산성 인프라처럼 느껴졌습니다. 포맷터(formatter), 테마(theme), 언어 서버(language server), 테스트 익스플로러(test explorer), Docker 헬퍼(Docker helper), 클라우드 플러그인(cloud plugin), 데이터베이스 브라우저(database browser), 혹은 존재조차 잊어버린 세 가지 정도의 항목을 설치하곤 했습니다.

어떤 기업들은 이를 매우 중요하게 여겼습니다. 많은 기업은 엔드포인트 보안 제품이 정말로 나쁜 것이 있는지 알아차려 주기만을 바랐습니다.

그 세계도 이미 위험했지만, 폭발 반경(blast radius)은 보통 인간 개발자를 중심으로 구성되었습니다. 플러그인은 파일을 읽거나, 코드를 실행하거나, 데이터를 유출하거나, 로컬 환경을 약화시킬 수 있었습니다. 나쁘긴 하지만 익숙한 상황이었습니다.

에이전트는 이 프레임을 바꿉니다.

IDE나 CLI에 앉아 있는 AI 코딩 어시스턴트(AI coding assistant)는 플러그인을 기능(capabilities)으로 사용할 수 있습니다. 개발자 도구를 호출하거나, 설치된 확장 프로그램을 컨텍스트(context)로 사용하거나, 작업을 수행하기 위해 로컬 통합(local integrations)에 의존할 수 있습니다. 에이전트 자체가 직접 무엇인가를 설치하지 않더라도, 사용 가능한 도구 환경이 에이전트가 할 수 있는 일을 결정합니다.

따라서 질문은 "개발자에게 어떤 확장 프로그램을 설치하도록 허용할 것인가?"에서 멈추지 않습니다.

질문은 이제 "어떤 도구 공급망 (tool supply chains)이 우리의 자동화된 개발 루프 (automated development loop)의 일부가 되는 것을 허용할 것인가?"로 바뀝니다.

그것이 훨씬 더 나은 질문입니다.

또한 더 어려운 질문이기도 합니다.

에이전트는 로컬 도구를 프로덕션 의존성처럼 느끼게 만든다

개발자 머신 (developer machines)에 대해 불편한 점은, 그것이 프로덕션 (production)이 아니라는 사실입니다. (물론 예외적인 경우도 있지만 말입니다.)

그곳에는 소스 코드 (source code)가 있습니다. 자격 증명 (credentials)이 있습니다. 아티팩트 (artifacts)를 빌드합니다. 테스트를 실행합니다. 풀 리퀘스트 (pull requests)를 생성합니다. 클라우드 계정에 연결합니다. 패키지 레지스트리 (package registries), 이슈 트래커 (issue trackers), 관측성 시스템 (observability systems), 피처 플래그 (feature flag) 도구, 그리고 내부 API와 통신합니다.

우리는 로컬 개발 (local development)과 프로덕션 인프라 (production infrastructure) 사이에 깨끗한 경계선이 있다고 가정합니다. 그래야 마음 편히 잠들 수 있기 때문입니다.

에이전트는 그 경계를 더 모호하게 만듭니다.

CLI를 통해 실행되는 에이전트가 저장소 (repository)를 수정하고, 명령어를 실행하며, 자격 증명을 사용하고, 배포 가능한 변경 사항을 준비할 수 있다면, 로컬 툴체인 (toolchain)은 프로덕션으로 가는 경로의 일부가 됩니다. 물론 모든 도구가 동일한 권한을 갖는 것은 아닙니다. 컬러 테마가 클라우드 배포 플러그인 (cloud deployment plugin)은 아니니까요. 하지만 "단순한 에디터 확장 프로그램 (editor extension)"이라는 기존의 사고 모델은 너무 안일합니다.

우리가 에이전트에게 더 많은 작업을 위임할수록, 주변의 도구 환경 (tool environment)은 더욱 중요해집니다.

에이전트가 무엇을 호출할 수 있는가? 어떤 플러그인 (plugins)을 발견할 수 있는가? 경로 (path)에 어떤 명령어들이 있는가? 어떤 확장 프로그램 마켓플레이스 (extension marketplace)가 신뢰할 수 있는가? 어떤 게시자 (publisher)가 허용되는가? 이 기능은 어떤 업데이트 채널 (update channel)을 통해 왔는가? 누가 이를 검토했는가?

이것들은 편집증적인 질문이 아닙니다.

이것들은 기묘한 옆문(side door)을 통해 들어오는, 아주 평범한 플랫폼 (platform) 관련 질문들입니다.

마켓플레이스는 정책 경계이다

"마켓플레이스 (marketplace)"라는 단어는 현재 그것이 변모한 모습에 비해 너무 상업적으로 들립니다.

개발자 도구 (developer tools)에 있어 마켓플레이스는 배포 채널 (distribution channel), ID 시스템 (identity system), 신뢰 모델 (trust model), 업데이트 메커니즘 (update mechanism), 발견 접점 (discovery surface), 그리고 사회적 증거 엔진 (social proof engine)입니다. 마켓플레이스는 다음과 같은 질문에 답합니다:

• 이 도구는 어디에서 왔는가?
• 누가 이것을 게시했는가?
• 어떻게 업데이트되는가?
• 어떤 메타데이터 (metadata)가 이를 설명하는가?
• 제거하거나 차단할 수 있는가?
• 조직에서 기본적으로 허용하는 것은 무엇인가?

에이전트가 이러한 도구들에 의존하기 시작하면, 마켓플레이스(marketplace)는 정책 경계(policy boundary)가 됩니다.

그렇다고 해서 모든 기업이 모든 것을 차단하고, 개발자가 구문 강조(syntax highlighting) 기능을 설치하기 위해 티켓을 제출해야 한다는 뜻은 아닙니다. 그것은 섀도우 툴체인(shadow toolchain)을 만드는 가장 빠른 방법이 될 것입니다.

하지만 이는 기본 설정(default)이 의도적(intentional)이어야 함을 의미합니다.

기업은 IDE와 CLI가 무작위의 공개 마켓플레이스, 내부 마켓플레이스, 승인된 미러(mirrors), 또는 이들의 혼합 형태를 사용하는 것이 허용되는지 여부를 알고 있어야 합니다. 또한 개인적인 실험과 업무용 리포지토리(repositories)를 분리할 수 있어야 합니다. 특정 플러그인 소스가 취미용 코드에는 괜찮지만, 고객 데이터를 포함하는 리포지토리에는 허용되지 않는다고 명시할 수 있어야 합니다.

이것이 바로 strictKnownMarketplaces와 같은 제어(controls) 기능의 목적입니다.

이러한 기능들은 선을 그을 수 있는 지점을 만들어 줍니다.

에이전트 공급망은 npm만이 아니다

사람들이 소프트웨어 공급망 보안(software supply chain security)에 대해 이야기할 때, 우리는 보통 패키지(packages), 컨테이너(containers), SBOM, 서명(signing), 출처(provenance), 그리고 CI/CD로 바로 넘어갑니다.

그 모든 것들은 여전히 중요합니다.

하지만 에이전트 기반 개발(agentic development)은 또 다른 계층을 추가합니다. 바로 코드가 패키지나 컨테이너가 되기 전, 코드가 작성되는 방식에 영향을 미치는 도구들입니다.

코딩 에이전트는 리포지토리 지침(repository instructions), MCP 서버, 에디터 플러그인, CLI 확장 기능, 브라우저 자동화(browser automation), 비밀 정보 스캐너(secret scanners), 테스트 러너(test runners), 클라우드 CLI, 그리고 로컬 환경이 노출하는 그 어떤 것이든 사용할 수 있습니다. 이러한 도구 중 일부는 퍼스트 파티(first-party) 제품입니다. 일부는 오픈 소스(open source)이고, 일부는 내부용입니다. 어떤 것들은 2년 전 더 나은 디프 뷰(diff view)를 원했던 개발자가 설치한 것일 수도 있습니다.

이는 매우 무질서한 인벤토리(inventory)입니다.

또한 이는 에이전트가 물려받게 될 인벤토리이기도 합니다.

이것이 제가 마켓플레이스 정책이 처음 보이는 것보다 더 설득력 있다고 생각하는 이유입니다. 이것이 완전한 정답은 아니지만, 에이전트의 역량이 실제로 어디에 존재하는지를 인정하는 최초의 지루한 제어(controls) 중 하나이기 때문입니다.

깔끔한 아키텍처 다이어그램(architecture diagram) 속에 있는 것이 아닙니다.

개발자의 에디터, 터미널, 플러그인 목록, 그리고 경로(path) 속에 존재합니다.

거버넌스(governance)는 실행 전에 이루어져야 한다

모든 것이 사후에 검토되는 잘못된 방식의 에이전트 거버넌스(agent governance)가 존재합니다.

에이전트가 무언가를 수행했습니다. 로그가 이를 포착했습니다. 감사 추적(audit trail)이 존재합니다. 나중에 누군가 조사할 수 있습니다.

그것은 유용하지만, 불완전합니다.

어떤 통제(controls)는 도구가 사용 가능해지기 전에 이루어져야 합니다. 만약 플러그인 마켓플레이스(plugin marketplace)가 업무용 저장소(work repositories)에서 신뢰할 수 없는 곳이라면, 에이전트가 해당 마켓플레이스의 도구를 통해 경로를 설정한 뒤, 나중에 실수를 설명하는 아름다운 감사 로그(audit log)를 남기도록 방치해서는 안 됩니다.

실행 전 정책(Pre-execution policy)은 화려하지 않습니다. 그것은 대부분 허용 목록(allowlists), 식별(identities), 범위(scopes), 서명(signatures), 출처(provenance), 그리고 지루한 관리 설정(admin settings)들입니다.

좋습니다.

그것이 바로 진정한 플랫폼을 구성하는 요소입니다.

에이전트 세계는 프롬프팅(prompting), 추론(reasoning), 모델 선택(model choice), 평가(evals), 컨텍스트 윈도우(context windows), 그리고 자율성(autonomy)에 많은 에너지를 쏟아왔습니다. 그것들은 중요합니다. 하지만 운영상의 질문은 종종 더 단순합니다:

이것이 무엇을 건드릴 수 있는가?

마켓플레이스 정책(Marketplace policy)은 그에 대한 하나의 해답입니다. 유일한 해답은 아니지만, 실용적인 해답입니다.

개발자들에게는 여전히 작업할 공간이 필요하다

여기에는 균형이 필요합니다.

만약 기업들이 에이전트 보안을 탈출구가 없는 동결된 데스크톱 이미지(frozen desktop image)로 만들어 버린다면, 숙련된 개발자들은 이를 우회할 것입니다. 그들은 개인용 컴퓨터, 사이드 도구(side tools), 로컬 스크립트, 승인되지 않은 CLI, 그리고 업무를 완수할 수 있는 무엇이든 사용할 것입니다.

그것은 보안이 아닙니다. 그것은 스크린샷을 동반한 거부(denial)일 뿐입니다.

더 나은 방식은 계층화(tiered)하는 것입니다.

저위험 저장소(low-risk repositories)에 대해서는 더 많은 실험을 허용하십시오. 민감한 저장소(sensitive repositories)에 대해서는 플러그인 소스(plugin sources)를 제한하십시오. 운영 환경 자격 증명(production credentials)에 대해서는 더 강력한 식별(identity)을 요구하십시오. 풀 리퀘스트(pull requests)를 열거나 배포 관련 명령(deployment-adjacent commands)을 실행할 수 있는 에이전트의 경우, 승인된 도구(approved tools)를 요구하십시오. 내부 마켓플레이스(internal marketplaces)의 경우, 사람들이 싫어하지 않을 정도로 승인 프로세스를 충분히 빠르게 만드십시오.

목표는 개발에서 호기심을 제거하는 것이 아닙니다.

목표는 알 수 없는 도구들이 자동화된 엔지니어링 워크플로(automated engineering workflows)의 일부로 조용히 스며드는 것을 막는 것입니다.

이 지점이 바로 플랫폼 팀이 실제로 도움을 줄 수 있는 부분입니다. 검증된 마켓플레이스(blessed marketplace)를 제공하십시오. 일반적인 확장 프로그램(extensions)을 미러링하십시오. 내부 도구들을 적절하게 게시하십시오. 허용되는 것이 무엇인지 문서화하십시오. 에이전트 워크플로(agent workflows)에 신뢰할 수 있는 도구 카탈로그를 제공하십시오. 우회하는 경로보다 보안이 확보된 경로를 더 쉽게 만드십시오.

이는 개발자들에게 무언가를 설치한다고 소리치는 것보다 훨씬 더 나은 방법입니다.

내가 가장 먼저 확인할 것

만약 내가 엔지니어링 조직에서 이 업무를 담당하게 된다면, 매우 지루한 인벤토리(inventory) 조사부터 시작할 것입니다.

업무에 어떤 IDE와 CLI가 사용되는가? 어떤 확장 프로그램 마켓플레이스가 활성화되어 있는가? 어떤 플러그인이 흔하게 사용되는가? 어떤 플러그인이 파일을 읽거나, 명령을 실행하거나, 외부 서비스에 접속할 수 있는가? 어떤 것들이 공식 워크플로에서 요구되는가? 어떤 것들이 방치되어 있는가? 어떤 것들이 에이전트의 기능과 중복되는가?

그런 다음, 그 인벤토리를 리포지토리 리스크(repository risk)와 연결할 것입니다.

프론트엔드 연습용 앱(toy app)과 결제 서비스(payments service)는 동일한 정책을 가져서는 안 됩니다. 문서 리포지토리와 인프라 리포지토리는 에이전트에게 동일한 로컬 권한(local capabilities)을 노출해서는 안 됩니다. 계약직 직원의 머신과 플랫폼 엔지니어의 머신은 아마도 서로 다른 기본 설정(defaults)이 필요할 것입니다.

마지막으로, 에이전트 트레이스(agent traces)에 도구의 출처(tool provenance)가 표시되도록 만들 것입니다.

만약 에이전트가 플러그인, CLI 확장 프로그램, MCP 서버, 또는 마켓플레이스에서 제공하는 기능을 사용했다면, 나는 그것이 정확히 무엇인지 알고 싶습니다. 버전, 게시자, 출처, 그리고 정책 결정 사항을 알고 싶습니다. 내가 서류 작업을 즐기기 때문이 아닙니다. 무언가 이상한 일이 발생했을 때, "에이전트가 도구를 실행했다"라는 정보만으로는 충분한 세부 정보가 되지 않기 때문입니다.

어떤 도구인가?

어디에서 가져왔는가?

누구에 의해 허용되었는가?

어떤 정책 하에 있는가?

이러한 질문들은 포렌식 고고학(forensic archaeology) 수준의 조사 없이도 답할 수 있어야 합니다.

핵심(the punchline)

GitHub의 strictKnownMarketplaces 지원은 대규모 키노트(keynote)의 주인공이 될 만한 종류의 발표는 아닙니다.

바로 그 점 때문에 나는 이 기능이 마음에 듭니다.

코딩 에이전트 (Coding Agents)의 미래는 모델 설정(model settings)과 채팅 프롬프트 (chat prompts)에 의해서만 결정되지 않을 것입니다. 대신 작업이 실제로 일어나는 무미건조한 접점들, 즉 IDE 설정 (IDE settings), CLI 정책 (CLI policy), 플러그인 마켓플레이스 (plugin marketplaces), 신원 (identity), 감사 로그 (audit logs), 리포지토리 권한 (repository permissions), 그리고 도구 카탈로그 (tool catalogs)에 의해 결정될 것입니다.

에이전트는 개발 환경을 더욱 강력하게 만듭니다.

이는 개발 환경에 더 나은 경계 (boundaries)가 필요함을 의미합니다.

플러그인 마켓플레이스는 과거에 에디터 주변의 편의 계층 (convenience layer)처럼 느껴졌습니다. 하지만 에이전트 기반 코딩 (agentic coding) 시대에, 이들은 실행 계약 (execution contract)의 일부가 되어가고 있습니다.

만약 당신의 에이전트가 도구 (tools)를 사용할 수 있다면, 그 도구들이 어디에서 오는지 반드시 신경 써야 합니다.

이것은 관료주의가 아닙니다.

이것은 공급망 보안 (supply chain security)이 마침내 개발자들이 실제로 일하는 방식에 발맞추어 나아가는 과정입니다.

references

• GitHub Changelog: Enterprise-managed settings now support strictKnownMarketplaces in VS Code and GitHub Copilot CLI

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.