코딩 에이전트가 리포지토리의 보안 경계가 되다

GitHub은 이번 주에 대부분의 출시 데모보다 코딩 에이전트(coding agents)의 미래에 대해 더 많은 것을 시사하는 작은 변경 로그(changelog) 항목을 발표했습니다.

제3자 코딩 에이전트에 대한 보안 검증(Security validation) 기능이 이제 일반적으로 사용 가능(generally available)해졌습니다. GitHub 자체의 Copilot 클라우드 에이전트뿐만 아니라, Claude 및 OpenAI Codex를 포함한 제3자 에이전트에게도 적용됩니다.

이 기능은 가장 긍정적인 의미에서 지루하게 들릴 수도 있습니다.

에이전트가 코드를 생성할 때, GitHub은 CodeQL을 실행하고, 새로운 의존성(dependencies)을 GitHub Advisory Database와 대조하여 확인하며, 비밀 스캐닝(secret scanning)을 사용하여 토큰, API 키 및 기타 민감한 자료를 탐지할 수 있습니다. 만약 문제를 발견하면, 에이전트는 이를 수정하려고 시도합니다.

이것은 에이전트 기반 코딩(agentic coding)에서 화려한 부분은 아닙니다.

하지만 중요한 부분입니다.

왜냐하면 일단 에이전트가 리포지토리(repos) 내부에서 활동할 수 있게 되면, 질문은 "어떤 모델이 이 diff를 작성했는가?"에서 "리포지토리가 모든 자동화 액터(automation actor)에게 동일한 정책을 적용할 수 있는가?"로 바뀌기 때문입니다.

저작권(authorship)은 잘못된 추상화입니다

우리는 여전히 생성된 코드를 다룰 때 마치 저작권(authorship)이 가장 중요한 요소인 것처럼 이야기합니다.

이것은 Copilot이 작성했나요? Claude인가요? Codex인가요? 탭 완성(tab completion)을 사용하는 사람인가요? 채팅창에서 무언가를 복사해 붙여넣고 정리한 사람인가요? 2018년의 Stack Overflow 답변을 따르는 주니어 엔지니어인가요?

그러한 구분은 조달(procurement)과 제품 마케팅 측면에서는 중요합니다. 하지만 리포지토리 입장에서는 덜 중요합니다.

리포지토리는 더 단순한 문제를 안고 있습니다: 변경 사항이 시스템에 진입하려고 한다는 것입니다. 그것은 취약점(vulnerability)을 유발하거나, 위험한 의존성을 추가하거나, 비밀 정보를 유출하거나, 내부 규칙을 위반하거나, 혹은 아무런 문제가 없을 수도 있습니다.

이것이 바로 GitHub의 변경 사항이 흥미로운 이유입니다. 이는 유용한 경계를 "우리가 승인한 코딩 어시스턴트"에서 "이 리포지토리에서 작동하는 모든 코딩 에이전트"로 이동시킵니다.

에이전트는 이제 하나의 액터(actor)입니다

수년 동안 리포지토리 자동화는 대부분 지루하고 판독 가능(legible)했습니다.

CI는 테스트를 실행했습니다. Dependabot은 의존성 업데이트를 열었습니다. 릴리스 봇(Release bots)은 버전을 올렸습니다. 린터(Linters)는 경고를 보냈습니다. 보안 스캐너(Security scanners)는 의견을 남겼습니다. 인간은 검토(review)했습니다. 자동화는 짜증스러울 수 있었지만, 그 형태는 예측 가능했습니다.

코딩 에이전트 (Coding agents)는 다릅니다.

그들은 단순히 리포지토리 (repository)에 대해 보고만 하지 않습니다. 그들은 리포지토리를 수정합니다.

그들은 이슈 (issues)를 읽고, 파일을 검사하며, 코드를 수정하고, 테스트를 추가하고, 의존성 (dependencies)을 업데이트하며, 풀 리퀘스트 (pull requests)를 생성합니다. 이는 그들을 린터 (linter)보다는 계약업체 (contractor)에 더 가깝게 만듭니다.

그리고 쓰기 권한 (write access)을 가진 모든 계약업체와 마찬가지로, 그들에게도 경계 (boundaries)가 필요합니다.

느낌 (vibes)이 아니라, 경계가 필요합니다.

그들이 어떤 도구를 호출할 수 있는가? 어떤 데이터를 읽을 수 있는가? 어떤 비밀 정보 (secrets)가 노출되는가? 어떤 체크 (checks)를 통과해야 하는가? 누가 최종 머지 (merge)를 승인하는가? 나중에 발생한 일을 어떻게 감사 (audit)할 것인가?

이것들은 철학적인 질문이 아닙니다. 이것들은 리포지토리 관리 (repository administration)에 관한 질문들입니다.

재미있는 점은, 이로 인해 에이전트 기반 코딩 (agentic coding)이 미래지향적인 기술이라기보다 지루한 엔터프라이즈 소프트웨어 (enterprise software)처럼 느껴진다는 것입니다. 신원 (Identity), 권한 부여 (authorization), 감사 로그 (audit logs), 정책 상속 (policy inheritance), 기본값 (defaults), 예외 (exceptions), 그리고 강제 적용 (enforcement) 같은 것들 말입니다.

늘 그렇듯, 지루한 부분이 바로 프로덕션 (production)이 시작되는 지점입니다.

보안 체크 (security checks)는 벤더 충성도 (vendor loyalty)에 의존해서는 안 됩니다

에이전트 거버넌스 (agent governance)의 최악의 형태는 특정 벤더 (vendor)에 종속된 정책입니다.

Copilot이 생성한 코드는 하나의 보안 경로를 가집니다. Claude가 생성한 코드는 다른 경로를 가집니다. Codex가 생성한 코드는 팀이 구성하는 것을 기억해낸 것에 따라 달라집니다. 개발자 머신에서 실행되는 로컬 에이전트 (local agent)는 다른 처리 방법을 아무도 모르기 때문에 인간의 디프 (diff)처럼 취급됩니다.

이는 확장 가능하지 (scale) 않습니다. 또한 잘못된 인센티브를 만듭니다. 팀들은 생성된 작업 전반에 대해 리포지토리를 탄력적 (resilient)으로 만드는 대신, 어떤 에이전트가 안전한지에 대해 논쟁하게 됩니다.

보안 태세 (security posture)는 다음과 같아서는 안 됩니다:

"우리는 이 모델을 신뢰한다."

다음과 같아야 합니다:

"우리는 이 경계를 통해 검증되지 않은 변경을 허용하지 않는다."

이 두 문장은 매우 다릅니다.

첫 번째 문장은 모델 선택을 보안 통제 (security control)로 만듭니다. 이는 취약합니다. 왜냐하면 모델은 변하고, 벤더는 기본값을 변경하며, 프롬프트 (prompts)는 드리프트 (drift)하고, 생성된 출력물은 여전히 출력물이기 때문입니다.

두 번째 문장은 지루하지만 견고합니다. 모든 변경 사항이 검사됩니다. 모든 행위자가 동일한 게이트 (gates)를 통과합니다. 리포지토리 (repo)는 해당 디프 (diff)가 사람으로부터 왔는지, 퍼스트 파티 에이전트 (first-party agent)로부터 왔는지, 아니면 서드 파티 에이전트 (third-party agent)로부터 왔는지에 관계없이 정책을 강제합니다.

그것이 바로 이 기술이 나아가야 할 방향입니다.

자동 복구 (automatic remediation)는 유용하지만 기이하다

제가 잠시 멈춰 서게 만든 부분은 GitHub이 보안 분석을 수행한다는 점이 아닙니다.

문제가 발견되었을 때, 에이전트가 풀 리퀘스트 (pull request)를 확정하기 전에 이를 해결하려고 시도한다는 점입니다.

그것은 유용합니다. 또한 리뷰 루프 (review loop)를 변화시킵니다.

전통적으로는 스캐너 (scanner)가 문제를 보고하면 사람이 이를 수정합니다. 에이전트와 함께라면 루프는 다음과 같이 변할 수 있습니다: 도구가 불만을 제기하고, 에이전트가 코드를 수정하고, 도구가 다시 확인하고, 에이전트가 코드를 다시 수정하며, 그 후에 최종 디프 (diff)가 리뷰를 위해 나타납니다.

그것이 아마도 옳은 방식일 것입니다. 또한 로그 (logs)와 출처 (provenance)에 대해 더 엄격한 규율을 가져야 하는 이유이기도 합니다.

만약 에이전트가 의존성 (dependency)을 도입했고, 스캐너가 이를 플래그 (flag) 처리했으며, 에이전트가 이를 다른 것으로 교체했다면, 최종 풀 리퀘스트 (pull request)에는 최종 상태만 나타날 수 있습니다. 흥미로운 부분은 그 상태에 도달하기 위해 거쳐온 경로일 것입니다.

작은 버그에 대해서는 아무도 신경 쓰지 않을 것입니다.

하지만 보안에 민감한 변경 사항, 규제 환경, 그리고 비용이 많이 드는 사고의 경우에는 사람들이 매우 신경을 쓸 것입니다.

이 지점에서 "에이전트가 코드를 작성했다"라는 말은 너무 모호해집니다. 우리는 어떤 에이전트가 어떤 권한 하에 작동했는지, 어떤 도구들이 실행되었는지, 그리고 어떤 검사 (checks)가 권위가 있었는지를 알아야 합니다.

첫 번째 사고 검토 (incident review)가 있기 전까지는 이것이 서류 작업처럼 들릴 것입니다.

그 이후에는 이것이 최소한의 실행 가능한 진실 (minimum viable truth)처럼 들릴 것입니다.

이것은 플랫폼 팀의 문제다

에이전트 툴링 (agent tooling) 뉴스 전반에서 하나의 패턴이 반복되고 있습니다: 유용한 기능들이 플랫폼 기능 (platform features)이 되고 있다는 점입니다.

보안 검증 (Security validation). MCP 서버 설정 (MCP server configuration). 리포지토리 수준의 리뷰 설정 (Repository-level review settings). 에이전트 스킬 (Agent skills). 비용 제어 (Cost controls). 샌드박스 (Sandboxes). 감사 추적 (Audit trails). 도구 사용 전후의 훅 (Hooks).

이것들은 개별 개발자가 모든 리포지토리마다 일일이 직접 만들어야 하는 기능들이 아닙니다.

만약 기업이 수백 개의 리포지토리 (Repositories)를 보유하고 있다면, 플랫폼 팀은 지루한 질문들에 답해야 합니다. 어떤 에이전트 (Agents)가 어디에서 허용되는가? 어떤 검증 (Validations)이 필수적인가? 에이전트 실행으로부터 비밀 정보 (Secrets)를 어떻게 격리하는가? 회사가 모든 리포지토리에 동일한 규칙이 적용됨을 증명할 수 있는가? 금요일 오후 5시에 규칙이 팀의 작업을 방해한다면, 그 정책의 책임자는 누구인가?

이 중 어느 것도 AI 데모처럼 보이지 않지만, 이것이 에이전트 도입이 생산적인 인프라가 될지, 아니면 영리하지만 일회성인 워크플로 (Workflows)의 더미가 될지를 결정합니다.

리포지토리가 집행 계층 (Enforcement layer)이 되고 있다

저는 이러한 GitHub의 변화가 올바른 멘탈 모델 (Mental model)을 가리키고 있다는 점에서 마음에 듭니다.

에이전트가 신뢰 경계 (Trust boundary)가 아닙니다.

리포지토리가 신뢰 경계입니다.

그렇다고 해서 에이전트가 무모하게 행동해도 된다는 뜻은 아닙니다. 에이전트 신원 (Agent identity), 샌드박싱 (Sandboxing), 도구 권한 (Tool permissions), 그리고 프롬프트 제어 (Prompt controls)는 여전히 중요합니다. 하지만 리포지토리는 작업이 시스템의 일부가 되는 곳입니다. 코드 리뷰 (Code review), CI, 보안 스캐닝 (Security scanning), 브랜치 보호 (Branch protection), 의존성 정책 (Dependency policy), 그리고 감사 이력 (Audit history)이 이미 만나는 지점입니다.

따라서 에이전트 거버넌스 (Agent governance) 또한 그곳에 안착하는 것이 타당합니다.

이는 또한 "AI 네이티브 개발 (AI-native development)"이 사람들이 생각하는 것만큼 빠르게 기존의 소프트웨어 인도 메커니리 (Software delivery machinery)를 대체하지 않을 것이라는 점을 상기시켜 주는 좋은 사례입니다. 오히려 AI는 해당 메커니리에 가해지는 부하를 주로 증가시킬 것입니다. 더 많은 풀 리퀘스트 (Pull requests), 더 많은 생성된 의존성 (Dependencies), 그리고 리뷰어가 편안하게 처리할 수 있는 속도보다 더 빠르게 도착하는 그럴듯한 실수들이 늘어날 것입니다.

해답은 순수한 의지력만으로 모든 인간 리뷰어를 더 빠르게 만드는 것이 아닙니다.

해답은 명백한 체크 사항들을 경계 (Boundary)에 더 가깝게 옮기고 이를 일관되게 만드는 것입니다.

지금 당장 내가 한다면

만약 제가 실제 엔지니어링 조직에서 에이전트 도입을 책임지고 있다면, 더 많은 라이선스 (Seats)를 구매하거나 더 많은 도구를 활성화하기 전에 리포지토리 정책 (Repository policies)부터 시작하겠습니다.

오늘날 어떤 자동화 액터 (Automation actors)들이 풀 리퀘스트를 생성할 수 있는지 목록을 만드십시오. 지루한 것들도 포함해야 합니다: 의존성 봇 (Dependency bots), 릴리스 봇 (Release bots), 내부 스크립트 (Internal scripts), CI 워크플로 (CI workflows), 그리고 개발자 머신에서 실행되는 모든 에이전트 실험들까지 말입니다.

그런 다음, 진입 규칙 (Entry rules)을 명시적으로 만드십시오.

최소한으로, 저는 필수적인 보안 스캐닝 (security scanning), 의존성 체크 (dependency checks), 비밀 정보 스캐닝 (secret scanning), 브랜치 보호 (branch protections), 그리고 "에이전트가 제안할 수 있음"과 "에이전트가 병합할 수 있음" 사이의 명확한 구분을 요구할 것입니다. 또한 에이전트의 행동을 나중에 재구성할 수 있도록 만드는 로그 (logs)도 필요할 것입니다.

저는 이것을 모델 순위 매기기 연습으로 만드는 것은 피할 것입니다.

질문은 Claude, Codex, Copilot, 혹은 다음 모델이 이번 달에 가장 좋은 벤치마크 점수를 가졌느냐가 아닙니다. 질문은 당신의 리포지토리 (repository)가 당신이 이해하고 있는 정책 하에 그들 중 누구의 작업이라도 안전하게 수용할 수 있느냐 하는 것입니다.

그것이 데모 (demo)와 엔지니어링 시스템 (engineering system)의 차이입니다.

핵심 요약 (the punchline)

제3자 코딩 에이전트 (third-party coding agents)에 대해 흥미로운 점은 그들이 코드를 작성할 수 있다는 점이 아닙니다.

우리는 그들이 코드를 작성할 수 있다는 것을 알고 있습니다.

흥미로운 점은 그들이 소프트웨어 인도 (software delivery) 과정 내에서 일반적인 행위자 (actors)가 되고 있다는 것입니다. 일단 그런 일이 발생하면, 리포지토리는 더 느슨해지는 것이 아니라 더 엄격해져야 합니다. 행위자가 더 자율적일수록, 경계 (boundary)는 더 지루할 정도로 견고해야 합니다.

GitHub가 자체 에이전트를 넘어 보안 검증 (security validation)을 확장하는 것은 큰 시사점을 가집니다. 즉, 에이전트 거버넌스 (agent governance)는 특정 제품에 대한 사후 고려 사항이 되어서는 안 된다는 것입니다. 그것은 리포지토리의 속성 (property)이 되어야 합니다.

그것이 올바른 방향입니다.

모델이 마음에 든다고 해서 디프 (diff)를 신뢰하지 마십시오.

다른 모든 변경 사항이 통과해야 하는 것과 동일한 경계를 디프가 통과했기 때문에 신뢰하십시오.

참고 문헌 (references)

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