에이전트 도구에 공급망 제어(Supply-chain controls)가 지금 당장 필요한 이유

통제되지 않은 에이전트 도구를 사용하는 저장소(repo)는 더 나은 프롬프트만으로는 구제할 수 없습니다.

코딩 에이전트가 실제로 무엇이 되어가고 있는지를 살펴보기 전까지는 이 말이 다소 극단적으로 들릴 수 있습니다. 에이전트들은 코드를 제안하는 채팅창 수준을 넘어섰습니다. 그들은 저장소(repo)의 지침을 읽습니다. 도구(tools)를 호출합니다. 마켓플레이스(marketplaces)에 연결합니다. 파일, 이슈(issues), 풀 리퀘스트(pull requests), 패키지 매니저(package managers), CI, 문서(docs), 내부 API, 그리고 팀이 "시간을 절약해 준다"는 이유로 연결해 둔 그 어떤 것에도 접근할 수 있는 개발자 워크플로우(workflows) 내부에서 실행됩니다.

그 시점이 되면, 흥미로운 질문은 "모델이 충분히 똑똑한가?"가 아니게 됩니다.

더 나은 질문은 이것입니다: 누가 이 도구를 워크플로우에 허용했는가, 이 도구가 어디까지 접근할 수 있는가, 그리고 그 권한이 변경되었을 때 누군가 이를 어떻게 알아챌 수 있는가?

이것은 프롬프트 엔지니어링(prompt engineering)이 아닙니다. 이것은 공급망 제어(supply-chain control)입니다.

위험이 이동한 곳은 도구 계층(tool layer)이다

현재의 에이전트 관련 논의는 여전히 모델 출력(model output)에 너무 많은 시간을 할애하고 있습니다. 환각(hallucinated)된 코드는 중요합니다. 잘못된 리팩터링(refactors)도 중요합니다. 자신감 있지만 틀린 설명은 오후 시간을 통째로 낭비하게 만들 수 있습니다.

하지만 에이전트가 도구를 통해 행동할 수 있게 되면, 실패 모드(failure mode)는 더 이상 가벼운 문제가 아닙니다.

잘못된 제안은 하나의 문제입니다. 하지만 셸(shell), 저장소 토큰(repo token), 패키지 설치기(package installer), 브라우저 세션(browser session), 또는 쓰기 가능한 프로젝트 디렉토리(writable project directory)에 대한 접근 권한을 가진 잘못된 제안은 차원이 다른 문제입니다. 모델은 더 이상 인간이 검토할 텍스트만을 생성하는 것이 아닙니다. 모델은 실행 능력(capability)의 앞에 앉아 있는 것입니다.

이것이 최근 DEV.to에서 플러그인 마켓플레이스(plugin marketplaces)를 엔드포인트 정책(endpoint policy)으로 규정하는 프레임워크가 적절하게 느껴지는 이유입니다. 팀들은 모든 개발자가 무작위 엔드포인트(endpoints), 플러그인 매니페스트(plugin manifests), MCP 서버, 그리고 에이전트 통합(agent integrations)을 처음부터 일일이 수동으로 감사(hand-auditing)하기를 원하지 않습니다. 그들에게는 제어 평면(control plane)이 필요합니다. 알려진 출처, 범위가 지정된 권한(scoped permissions), 검토 가능한 설치 경로, 그리고 무엇이 허용되는지에 대한 지루한 규칙들이 필요합니다.

개발자들은 이미 패키지(packages)를 통해 이 교훈을 배웠습니다.

우리는 느낌(vibes)에 따라 의존성(dependencies)을 설치하지 않습니다. 적어도 그래서는 안 됩니다. 우리는 레지스트리(registry), 유지 관리자(maintainer), 버전(version), 락파일(lockfile), 이행적 그래프(transitive graph), 설치 스크립트(install script), 업데이트 경로(update path), 그리고 검토용 디프(review diff)를 신경 씁니다.

에이전트 도구 역시 동일한 수준의 의심을 받아야 합니다.

리포지토리 지침(Repo instructions)은 이제 인프라입니다

Copilot 코딩 에이전트(coding agent)에서 GitHub이 AGENTS.md를 지원하기 시작한 것은 매우 유용한 신호입니다. 이는 이미 비공식적으로 일어나고 있던 일을 명시적으로 만들었기 때문입니다.

에이전트 지침(Agent instructions)은 프로젝트 산출물(artifacts)이 되어가고 있습니다.

이는 좋은 현상입니다. 리포지토리(repo)는 에이전트에게 테스트가 어떻게 실행되는지, 생성된 파일이 어디에 위치하는지, 어떤 명령어가 안전한지, 프로젝트가 어떤 스타일을 사용하는지, 그리고 어떤 워크플로(workflows)를 피해야 하는지를 알려줄 수 있어야 합니다. 이를 한 개인의 채팅 기록에 숨겨두는 것보다 버전 관리(version control) 시스템에 유지하는 것이 훨씬 더 낫습니다.

하지만 에이전트의 동작을 리포지토리에 포함하는 것은 리뷰의 부담 또한 변화시킵니다.

만약 풀 리퀘스트(pull request)가 AGENTS.md를 수정한다면, 그것은 "단순한 문서(docs)"가 아닙니다. 그것은 향후 에이전트가 코드를 수정하고, 명령어를 실행하며, 소유권 경계(ownership boundaries)를 해석하거나, 어떤 테스트가 유효한지 결정하는 방식을 바꿀 수 있습니다. 실제로 이는 README를 수정하는 것보다 CI 설정(CI config)을 변경하는 것에 더 가깝게 작동할 수 있습니다.

따라서 그런 방식으로 리뷰해야 합니다.

다음과 같은 불편한 질문들을 동일하게 던져야 합니다:

이 지침이 프로젝트가 예상하는 것보다 에이전트에게 더 많은 자유를 부여하는가?
테스트, 승인, 또는 검증(verification) 단계를 건너뛰는가?
아무도 관리하지 않는 도구를 통해 작업을 수행하도록 경로를 지정하는가?
에이전트에게 생성된 출력물(generated output)을 너무 쉽게 신뢰하도록 지시하는가?
CI, 배포(deployment), 또는 로컬 개발(local development)의 보안 모델과 충돌하는가?

핵심은 모든 지침 파일을 무섭게 만드는 것이 아닙니다. 핵심은 그것을 일회용 텍스트로 취급하는 것을 멈추는 것입니다. 리포지토리 수준의 에이전트 파일은 산문(prose)으로 작성된 운영 정책(operational policy)입니다.

산문 또한 버그를 배포할 수 있습니다.

마켓플레이스 정책은 실질적인 보안 기능입니다

GitHub의 strictKnownMarketplaces 지원은 문제의 나머지 절반인 도구 소스 제어(tool source control)를 가리킵니다.

유용한 질문은 "에이전트가 도구를 설치할 수 있는가?"가 아닙니다. 유용한 질문은 "어떤 도구 소스가 허용될 만큼 충분히 알려져 있는가?"입니다.

그것은 소규모 기업 환경처럼 들립니다. 그렇지 않습니다. 이것은 개발자들이 이미 다른 모든 곳에서 사용하고 있는 패턴과 같습니다. 승인된 패키지 레지스트리(Approved package registries). 컨테이너 베이스 이미지 정책(Container base image policies). 브라우저 확장 프로그램 허용 목록(Browser extension allowlists). 내부 Terraform 모듈(Internal Terraform modules). 신뢰할 수 있는 발행자에게 고정된 CI 액션(CI actions pinned to trusted publishers).

에이전트 마켓플레이스는 그렇게 해야 하므로 그 세계로 나아가고 있습니다.

만약 에이전트가 임의의 장소에서 도구를 발견하고 연결할 수 있다면, 사용자의 워크플로우는 새로운 의존성 채널을 갖게 됩니다. 어쩌면 그 도구는 괜찮을 수도 있습니다. 어쩌면 마켓플레이스에 실제 검토가 있을 수도 있습니다. 어쩌면 매니페스트(manifest)가 정직할 수도 있습니다. 어쩌면 그 도구가 이름이 시사하는 것과 정확히 같은 일을 할 수도 있습니다.

어쩌면요.

저는 '어쩌면'이라는 것에 팀 프로세스를 구축하고 싶지 않습니다.

알려진 마켓플레이스 정책이 모든 에이전트 보안 문제를 해결하지는 못합니다. 그것은 프롬프트 주입(prompt injection), 데이터 유출(data leakage), 과도한 권한(overbroad permissions), 오해의 소지가 있는 도구 설명, 또는 사람이 잘못된 조치를 승인하는 것을 마법처럼 막지 못할 것입니다. 하지만 팀에게 하나의 구체적인 레버리지(lever)를 제공합니다: 도구는 무작위로 편리한 경로에서 오는 것이 아니라 승인된 출처에서 와야 한다는 것입니다.

그 레버리지는 중요합니다.

에이전트 도구를 의존성처럼 다루기

제가 사용할 정신 모델(mental model)은 간단합니다: 만약 에이전트 도구가 저장소(repo), 파일 시스템, 계정, 네트워크 요청, 배포 또는 사용자에게 보이는 아티팩트에 영향을 줄 수 있다면, 그것을 의존성처럼 취급해야 합니다.

이는 그 도구가 소유자(owner)를 필요로 한다는 것을 의미합니다.

출처(source)가 필요합니다.

권한 스토리(permission story)가 필요합니다.

업데이트 경로(update path)가 필요합니다.

고고학적 발굴 없이 제거할 방법이 필요합니다.

여기가 많은 에이전트 도입이 부실해지는 지점입니다. 팀은 하나의 워크플로우가 더 빨라지기 때문에 로컬 헬퍼, MCP 서버, 마켓플레이스 플러그인, 브라우저 커넥터 또는 저장소별 스크립트를 추가합니다. 데모는 작동하고 모두 속도를 좋아합니다. 그러다가 6주 후 아무도 그 도구가 전체 작업 공간을 읽을 수 있는 이유나 에이전트가 검토 중에 그것을 호출하는 것이 허용되는 이유를 기억하지 못합니다.

그것은 AI 문제가 아닙니다. 그것은 모델 기반 인터페이스(model-shaped interface)가 덧씌워진 일반적인 엔지니어링 문제입니다.

해결책은 신비롭지 않습니다.

에이전트 도구의 인벤토리(inventory)를 유지하세요. 각 도구가 어디에서 왔는지, 무엇을 할 수 있는지, 그리고 누가 소유하고 있는지를 기록하세요.

리포지토리 수준의 에이전트 지침(agent instructions)에 버전을 부여하세요. CI, 의존성(dependency), 또는 빌드 시스템(build-system)의 변경 사항을 검토하는 것과 동일한 방식으로 변경 사항을 검토하세요.

도구 소스에 대한 허용 목록(Allowlist)을 만드세요. 플랫폼이 알려진 마켓플레이스 정책(marketplace policy)을 지원한다면 이를 활용하세요. 지원하지 않는다면, 사람들이 데모를 그럴싸하게 만들기 위해 무엇이든 설치하기 시작하기 전에 수동으로 수행할 대응 절차를 문서화하세요.

읽기 도구(read tools)와 쓰기 도구(write tools)를 분리하세요. 문서 검색 도구와 이슈(issue), 파일, 또는 배포 상태(deployment state)를 변경(mutate)하는 도구는 동일한 종류의 권한으로 취급되어서는 안 됩니다.

인간이 읽을 수 있는 형태로 도구 호출(tool calls)을 로그(log)로 남기세요. 감사 추적(audit trail)이 기술적으로는 존재하지만 실질적으로 쓸모가 없다면, 그것은 감사 추적이 아닙니다. 그저 JSON 쓰레기 매립지일 뿐입니다.

위험한 기능은 명확하게 드러내세요. 셸 액세스(Shell access), 파일 시스템 쓰기(filesystem writes), 자격 증명 액세스(credential access), 브라우저 상태(browser state), 외부 네트워크 호출(external network calls), 그리고 패키지 설치(package installation)는 검토 과정에서 눈에 띄어야 합니다.

비활성화 경로를 마련하세요. 도구가 잘못되었거나, 오래되었거나, 침해되었거나, 혹은 단순히 권한이 너무 광범위하다는 것이 밝혀지면, 팀은 이를 빠르게 제거하는 방법을 알고 있어야 합니다.

이 중 어느 것도 화려하지 않습니다. 좋습니다. 화려함이란 사람들이 지루한 통제 절차를 건너뛰도록 스스로를 설득할 때 사용하는 수단입니다.

이것은 기업적 편집증이 아닙니다

이 내용을 "대기업의 거버넌스(governance)" 항목으로 분류하고 넘어가고 싶은 유혹이 들 것입니다.

하지만 그것은 실수입니다.

소규모 팀은 가장 빠르게 움직이기 때문에 종종 엉망인 에이전트 워크플로우(agent workflows)에 가장 많이 노출됩니다. 한 개발자가 도구를 연결합니다. 다른 개발자가 그 설정을 복사합니다. 세 번째 개발자가 리포지토리 지침을 추가합니다. 누군가는 특정 작업을 해결해 준다는 이유로 마켓플레이스 플러그인을 추가합니다. 팀이 작고 "우리 모두 상황을 파악하고 있다"는 이유로 아무도 정책을 작성하지 않습니다.

상황이 통제 불능이 되기 전까지는 말입니다.

1인 빌더(solo builders)의 경우도 마찬가지입니다. 에이전트가 당신의 머신에서, 당신의 리포지토리 내부에서, 당신의 계정을 대상으로 행동할 수 있다면 경계(boundary)는 여전히 중요합니다. 공식적인 승인 위원회가 필요하지 않을 수는 있습니다. 하지만 당신이 무엇을 설치했는지, 그리고 그것이 무엇을 건드릴 수 있는지는 여전히 알고 있어야 합니다.

자율 에이전트 (autonomous-agent)의 보안 및 프라이버시에 관한 arXiv의 연구는 대화의 초점을 계속해서 행동(actions)과 권한(permissions)으로 되돌려 놓는다는 점에서 여기서 유용한 배경 지식이 됩니다. 잘못된 답변은 짜증을 유발할 뿐입니다. 하지만 위임된 능력 (delegated capability)을 가진 시스템이 중요한 곳에서 잘못된 행동을 하는 것은 훨씬 더 심각한 문제입니다.

이것이 바로 개발자들이 내재화해야 할 부분입니다.

실무적인 도입 체크리스트

만약 당신의 팀이 이번 주에 코딩 에이전트 (coding agents)를 추가할 계획이라면, 저는 아주 직설적인 체크리스트부터 시작할 것을 권합니다.

첫째, 에이전트가 접촉할 수 있는 접점 (surfaces)을 나열하십시오. 저장소 (Repos), 로컬 파일, 터미널, 브라우저, SaaS 계정, 패키지 매니저 (package managers), CI 시스템, 이슈 트래커 (issue trackers), 문서, 데이터베이스, 클라우드 콘솔, 내부 API 등이 있습니다. 솔직해지십시오. 위험은 보통 기이한 예외 상황 (edge cases)에서 발생합니다.

둘째, 에이전트 지침 (instructions)을 버전 관리 (version control) 시스템에 넣고, 행동이 변함에 따라 이를 검토하십시오. 지침이 에이전트에게 기대되는 동작을 변경한다면, 그것은 제대로 된 검토를 거칠 가치가 있습니다.

셋째, 승인된 도구 출처 (approved tool sources)를 정의하십시오. 플랫폼에서 제공하는 경우 마켓플레이스 정책 (marketplace policy)을 사용하십시오. 로컬 도구나 MCP 서버를 사용하는 경우, 출처와 소유자를 기록하십시오.

넷째, 폭발 반경 (blast radius)에 따라 권한을 분리하십시오. 읽기 전용 컨텍스트 도구 (read-only context tools)는 쓰기 권한이 있는 도구와 동일한 방식으로 검토되어서는 안 됩니다. 문서를 검색할 수 있는 도구는 파일을 편집하거나, 콘텐츠를 게시하거나, 설정을 변경(rotate config)하거나, 풀 리퀘스트 (pull requests)를 생성할 수 있는 도구와 같지 않습니다.

다섯째, 실행 전에 권한을 가시화하십시오. 인간이 친근한 도구 이름만 보고 에이전트가 실제 시스템을 변형 (mutate)하려 한다는 것을 추측하게 해서는 안 됩니다.

여섯째, 발생한 일을 로그 (log)로 남기십시오. "도구 호출 성공"은 너무 빈약합니다. 사용된 도구, 대상, 가시적인 파라미터 (parameters), 사용된 권한 (authority), 그리고 결과를 기록하십시오. 미래의 검토자가 사고를 재구성하기 위해 복잡한 의식을 치를 필요가 없어야 합니다.

일곱째, 제거를 연습하십시오. 도구를 빠르게 비활성화할 수 없다면, 당신은 그것을 제어하고 있는 것이 아닙니다. 그저 그것이 제대로 작동하기를 바랄 뿐입니다.

이 체크리스트가 에이전트 워크플로우를 완벽하게 안전하게 만들어주지는 않을 것입니다. 완벽한 안전이 목적이 아닙니다. 핵심은 우연한 신뢰 (accidental trust)에서 의도적인 신뢰 (intentional trust)로 이동하는 것입니다.

지루한 팀들이 승리할 것입니다

다음 단계의 진정한 코딩 에이전트 (coding-agent) 우위는 가장 화려한 프롬프트 파일을 가진 팀에서 나오지 않을 것입니다.

그것은 모든 도구를 검토되지 않은 뒷문 (side door)으로 만들지 않으면서도, 에이전트가 유용한 작업을 수행할 수 있도록 허용하는 팀에서 나올 것입니다. 즉, 지루한 인벤토리 (inventories), 지루한 허용 목록 (allowlists), 지루한 리포지토리 지침 (repo instructions), 지루한 로그 (logs), 지루한 롤백 경로 (rollback paths)를 갖춘 팀 말입니다.

이것은 "에이전트가 어떤 도구든 사용할 수 있다"는 말보다 덜 흥미롭게 들릴 수 있습니다.

하지만 이것이야말로 실제 프로젝트와 맞닥뜨렸을 때 살아남는 방식입니다.

에이전트 도구는 운영 측면에서 의존성 (dependencies)과 다를 바 없으므로, 의존성처럼 검토되어야 합니다. 도구들은 코드, 권한, 설정, 네트워크 경로, 그리고 실패 모드 (failure modes)를 워크플로 (workflow) 안으로 가져오기 때문입니다.

스택 (stack)이 아직 이해할 수 있을 만큼 작을 때, 지금 바로 그들을 그런 방식으로 취급하십시오.

도구 계층 (tool layer)이 보이지 않을 정도로 커질 때까지 기다리는 것은, 팀이 최악의 시점에 자신들의 신뢰 모델 (trust model)을 디버깅하게 만드는 지름길입니다.

출처 노트 (Source notes)