오픈 소스는 보안 경계가 아니에요

2026년 5월 14일, 영국 Government Digital Service는 공공 부문의 AI, 공개 코드, 취약점 위험에 관한 지침을 발표했어요. 이 지침은 핵심 질문에 답해요. AI는 취약점 발견 비용을 낮출 수 있지만, 그렇다고 저장소 비공개가 보안 경계가 되지는 않아요.¹

그보다 9일 앞서 나온 공개 보도에 따르면, NHS England는 AI 취약점 도구가 공개 코드를 대규모로 살펴볼 수 있다는 내부 우려 때문에 수백 개의 GitHub 저장소를 비공개로 전환할 계획이었어요.² 그런 불안은 이해할 수 있어요. 하지만 제안된 통제 방식은 맞지 않아요. 코드를 숨기는 방식은 발견 자체를 위협으로 취급해요. 진지한 보안 작업은 고쳐지지 않은 약점을 위협으로 봐야 해요.

오픈 소스 보안은 팀이 실제 노출을 줄일 때 좋아져요. 코드에 비밀값을 두지 않고, 예외를 명확히 하고, 저장소마다 소유자를 두고, 작동하는 신고 경로를 마련하고, 빠르게 패치하고, 수정 사항이 사용자에게 도달했다는 공개 증거를 남겨야 해요. 저장소 비공개는 특정한 예외 상황을 보조할 수는 있지만, 이런 운영 체계를 대신할 수는 없어요.

요약

GDS는 공공 부문 팀이 코드를 기본적으로 공개 상태로 유지하고, 예외를 신중하게 검토하며, 실제 위험을 바꾸는 실질적인 요소에 집중해야 한다고 말해요.¹ 이 답은 저장소 비공개 공포보다 훨씬 나아요. 공개 코드는 이미 포크, 미러, 캐시, 패키지 산출물, 컨테이너 이미지, 스크린샷, 생성된 클라이언트, 이전 클론 안에 남아 있을 수 있기 때문이에요. 더 중요하게는, 공개 코드는 더 많은 사람이 검토하고, 재사용하고, 신고하고, 개선할 수 있게 해요.¹³

AI 취약점 발견에 대한 올바른 대응은 “전부 비공개로 바꾸자”가 아니에요. 올바른 대응은 비밀값을 제거하고, 민감한 코드를 분류하고, 명확한 예외를 공개하고, 의존성과 비밀값 검사를 실행하고, 취약점 신고 경로를 유지하고, 빠르게 패치하고, 공개 코드에 소유자가 있다는 증거를 남기는 것이에요.¹⁴⁵

핵심 정리

• 엔지니어링 리더에게: 비공개는 좁은 사례에서 노출을 줄일 수 있지만, 소유권, 목록 관리, 패치, 신고 체계를 대신할 수는 없어요.
• 공공 부문 팀에게: 비밀값, 사기 방지 통제, 민감한 아키텍처, 공개 전 정책에 대한 명시적 예외와 함께 운영한다면 기본 공개 원칙은 여전히 유효해요.
• 보안 팀에게: AI는 대응 역량의 가치를 높여요. 분류와 처리 경로가 없는 비공개 저장소는 여전히 실패해요.
• 에이전트 팀에게: 코드 가시성은 공격 표면 중 하나일 뿐이에요. 도구 권한, 상태 경계, 외부 전송 통제, 출시 기준이 저장소가 비공개처럼 보이는지보다 더 중요해요.
• 유지보수자에게: 알 수 없는 부분을 줄이세요. 좋은 문서, 명확한 보안 연락처, 작고 소유권이 분명한 서비스는 비공개 저장소 장벽보다 위험을 더 잘 줄여요.

공포는 가시성을 취약점으로 착각해요

AI 취약점 스캐너는 검토의 경제성을 바꿔요. 예전에는 한 사람이 코드베이스를 살펴보려면 시간, 기술, 끈기가 필요했어요. 성능이 좋은 모델은 더 많은 코드를 더 빠르게 검토하고, 파일 사이의 단서를 연결하며, 더 많은 후보 발견 사항을 만들어낼 수 있어요. 이 변화는 이미 취약한 코드, 모호한 소유권, 느린 패치 경로를 가진 팀에 더 큰 압박을 줘요.

하지만 저장소 가시성은 취약점과 같지 않아요. 공개 코드는 버그를 드러낼 수 있어요. 비공개 코드에도 같은 버그가 있을 수 있어요. 공격자는 바이너리, API 트래픽, 클라이언트 번들, 패키지 내용, 컨테이너 레이어, 로그, 문서, 의존성 메타데이터, 오래된 클론에서 동작을 추론할 수 있는 경우가 많아요. GDS도 같은 현실적인 지점을 짚어요. 인기 있는 프로젝트에는 포크나 미러가 흔하고, 눈에 띄지 않는 저장소도 이미 연구자나 공격자에게 도달했을 수 있기 때문에, 예전에 공개였던 저장소를 비공개로 바꾼다고 해서 역량 있는 공격자의 접근이 사라지는 것은 아니에요.¹

이 단서가 중요한 이유는 “닫자”라는 말이 행동처럼 느껴지기 때문이에요. 하지만 그 행동은 기술적 약점을 그대로 둔 채 공개 책임성만 줄일 수 있어요. 팀은 외부 검토, 공유된 수정, 재사용의 이점을 잃는 반면, 이미 코드를 복사한 사람에게는 거의 보호를 얻지 못할 수 있어요.

오픈 소스는 감사 기록도 만들어요. 공개 이력은 누가 무엇을 바꿨는지, 수정이 언제 들어갔는지, 유지보수자가 신고에 어떻게 대응했는지, 프로젝트가 아직 적극적으로 관리되는지를 보여줘요. 비공개 코드는 그 신호를 동료 팀, 공급업체, 연구자, 그리고 그 작업을 재사용하거나 개선할 수 있는 다른 공공 기관으로부터 숨겨요.

기본 공개 원칙은 순진한 생각이 아니에요

GDS는 모든 코드 한 줄이 공개 인터넷에 올라가야 한다고 주장하지 않아요. 기존 GOV.UK 오픈 소스 지침도 키, 자격 증명, 사기 탐지 알고리즘, 공개 전 정책처럼 코드를 닫아 둘 정당한 이유를 이미 제시해요.³ Technology Code of Practice 역시 개방성을 보안과 개인정보 보호 의무에 맞서는 것이 아니라, 함께 충족해야 하는 것으로 다뤄요.⁴

더 강한 규칙은 구체적인 예외가 있는 기본 공개예요. 이런 정책 형태는 팀이 “보안”을 포괄적인 분류로 쓰는 대신 위험을 직접 이름 붙이게 해요. 비밀값은 저장소에 있어서는 안 돼요. 사기 신호는 제한된 가시성이 필요할 수 있어요. 공개 전 정책 서비스는 기한이 정해진 보류가 필요할 수 있어요. 그저 부끄럽게 느껴지는 코드베이스는 예외에 해당하지 않아요.

영국 공공 부문 플레이북도 같은 방향을 가리켜요. 이 문서는 정부 소프트웨어와 코드는 적절한 경우 기본적으로 오픈 소스여야 하고, 공개적으로 개발되어야 하며, 승인된 라이선스에 따라 게시되어야 한다는 기대를 설명해요.⁵ DWP의 오픈 소스 코드 게시 정책도 같은 패턴을 따라요. 공개 라이선스에 따른 게시를 장려하면서도, 정의된 통제를 통해 민감한 소스 코드를 보호해요.⁶

이 구분은 품질을 보호해요. 공개적으로 코드를 작성하는 팀은 더 나은 README, 더 깔끔한 설정 안내, 더 명확한 이슈 이력, 더 분명한 데이터 경계를 작성하는 경향이 있어요. 외부인이 그 작업을 읽을 수 있기 때문이에요. GOV.UK 지침은 코드를 게시하면 문서화, 유지보수성, 데이터 명확성, 보안 피드백이 좋아질 수 있다고 말해요.³ 팀이 AI 압박에 대응해 모든 것을 묻어 버리면 이런 이점은 사라져요.

진짜 통제는 수정 속도예요

AI는 시간을 바꿔요. 발견은 더 빨라져요. 신고량도 늘어요. 오탐도 함께 늘어요. 저는 에이전트가 취약점을 발견했을 때에서 같은 역량 압박을 다뤘어요. 발견은 검증과 수정이 없으면 큰 의미가 없어요. 팀에는 분류, 소유자에게 전달하는 절차, 패치, 취약점 공개 절차, 그리고 출시 증거가 필요해요. 저장소 비공개는 그중 어느 것도 제공하지 않아요.

CISA의 Vulnerability Disclosure Policy 플랫폼은 바로 그 이유로 존재해요. 이 플랫폼은 연방 민간 기관이 공개 연구자가 신고한 취약점을 접수하고, 분류하고, 전달할 수 있는 경로를 제공해요.⁷ CISA의 조율된 취약점 공개 프로그램은 오픈 소스 소프트웨어와 AI 시스템을 포함한 핵심 인프라 전반의 취약점도 다루며, 공개 전 완화 조율을 강조해요.⁸

NCSC도 취약점 신고 및 공개 지침을 통해 영국 조직에 같은 운영 틀을 제공해요. 여기에는 도구 모음과 정부 부처를 위한 준비된 신고 경로가 포함돼요.⁹ 공통된 흐름은 단순해요. 외부인이 버그를 찾을 것이라고 받아들이고, 신고와 수정을 실제로 작동하게 만들라는 것이에요.

이 틀은 AI 취약점 발견을 숨을 이유가 아니라 대응 고리를 개선할 이유로 바꿔요. 모델이 공개 코드에서 버그를 찾을 수 있다면, 팀은 다음 5가지를 물어야 해요.

이 답들은 코드가 공개되어 있든 닫혀 있든 위험을 줄여요. 저장소를 숨기는 일은 오늘 소스를 볼 수 있는 사람만 바꿔요. 소유자, 패치, 신고 경로를 만들어 주지는 않아요.

더 나은 결정 규칙

팀에는 부끄러움, 노출, 진짜 민감성을 구분하는 결정 규칙이 필요해요.

이 규칙은 흔한 실패도 막아 줘요. 아무것도 분류할 수 없어서 전부 닫아 버리는 실패예요. 저장소 목록은 서비스가 무엇을 하는지, 어떤 데이터를 다루는지, 누가 소유하는지, 어떤 비밀값 스캐너가 실행되는지, 어떤 의존성이 중요한지, 신고가 어떻게 유지보수자에게 도달하는지를 답할 수 있어야 해요. 팀이 이 답을 갖고 있지 않다면 운영상 빈틈이 있는 거예요. 저장소 가시성을 바꾸면 그 빈틈을 대중에게서 숨길 수는 있어도, 빈틈 자체는 그대로 남아요.

에이전트는 경계 문제를 더 크게 만들어요

AI 코딩 에이전트는 같은 교훈을 더 선명하게 보여줘요. 저장소 경계는 에이전트가 허용된 권한 안에서 안전하지 않은 결정을 내리는 것을 막지 못해요. 저는 에이전트 샌드박스 보안은 제안일 뿐이에요에서 이 패턴을 다뤘어요. 위험한 행동은 종종 권한 밖이 아니라 권한 안에서 일어나요. 소프트웨어 공급망 공격도 같은 조합 문제에서 비롯돼요. 각각은 합리적으로 보이는 요소들이 합쳐져 해로운 경로를 만들 수 있어요.

보이지 않는 에이전트 문제는 오픈 소스 정책에도 적용돼요. 팀은 보이지 않는 것을 관리할 수 없어요. 도구 경로, 생성된 산출물, 캐시, 출시 상태, 공개 신고 대기열, 소유자 인계가 모두 중요해요.

오픈 소스 정책은 에이전트 보안에서 배워야 해요. 유용한 경계는 행동과 대응 계층에 있어요.

• 도구가 처리하기 전에 신뢰할 수 없는 입력을 분류하세요.
• 코드, 이력, 로그, 패키지, 생성된 자산에서 비밀값을 제거하세요.
• 빌드 캐시와 출시 산출물을 신뢰 수준별로 분리하세요.
• 자동화된 작업 흐름의 외부 네트워크 경로를 제한하세요.
• 게시, 배포, 수정 완료 선언 전에 증거를 요구하세요.
• 외부 연구자에게 안전하고 문서화된 신고 경로를 제공하세요.

이 통제들은 소스 비밀성에 의존하지 않아요. 민감한 자료가 어디에 있고 어떤 행동이 피해를 만들 수 있는지 팀이 알고 있는지에 달려 있어요. 저장소에 실제 비밀값이 들어 있다면, 노출 후 비공개로 바꾸는 것은 잘못된 문제를 푸는 일이에요. 비밀값을 교체하고, 가능하다면 이력에서 제거하고, 오래된 산출물을 무효화하고, 사고 처리 경로를 문서화해야 해요. 게시 경계가 중요한 이유는 외부로 나가는 출력에는 로컬 분석보다 더 강한 기준이 필요하기 때문이에요.

그래서 GDS 지침이 맞게 느껴져요. 이 지침은 AI가 취약점 발견을 바꾼다는 사실을 부정하지 않아요. 얕은 결론을 거부해요. AI는 약한 시스템을 더 쉽게 검토하게 만들어요. 그러니 답은 시스템을 더 쉽게 소유하고, 감사하고, 신고받고, 고칠 수 있게 만드는 것이어야 해요.

오늘 제가 한다면

AI가 촉발한 저장소 공포에 직면한 팀이라면, 기본값을 바꾸기 전에 48시간 공개 코드 검토를 실행해야 해요.

1. 공개 저장소 목록을 만들고 각 저장소를 소유자와 매핑하세요.
2. 현재 트리와 git 이력에 대해 비밀값 검사를 실행하세요.
3. 각 저장소에 보안 연락처나 취약점 공개 정책이 있는지 확인하세요.
4. 사기, 악용, 실제 운영 아키텍처, 공개 전 정책 예외를 식별하세요.
5. 의존성 업데이트, 패치 출시, 롤백 경로를 확인하세요.
6. 이름 붙인 예외와 맞는 특정 저장소만 닫거나 지연하세요.
7. 미래의 팀이 같은 공포를 반복하지 않도록 결정 규칙을 게시하세요.

이 계획은 리더에게 실제로 통제할 수 있는 지점을 제공해요. 동시에 증거도 만들어요. 훗날 검토자는 왜 어떤 저장소는 공개로 남았는지, 왜 다른 저장소는 비공개가 되었는지, 어떤 작업이 실제 위험을 줄였는지 볼 수 있어요.

FAQ

AI는 공개 코드를 더 위험하게 만드나요?

AI는 공개 코드를 더 쉽게 검토하게 만들 수 있어요. 따라서 팀은 더 많은 취약점 신고와 더 많은 자동화된 탐색을 예상해야 해요. 위험은 고쳐지지 않은 취약점, 노출된 비밀값, 약한 대응 고리에서 나와요. 공개 가시성은 발견을 늘릴 수 있지만, 비공개가 근본 버그를 제거하지는 않아요.¹

팀이 저장소를 비공개로 만들어야 할 때도 있나요?

있어요. 팀은 비밀값, 사기 통제, 민감한 실제 운영 아키텍처, 공개 전 정책, 그 밖의 구체적 피해를 포함하거나 드러내는 코드를 제한해야 해요. 예외를 문서화하고, 그 이유가 만료되면 다시 검토해야 해요.³⁶

검토가 끝날 때까지 전부 닫으면 안 되나요?

일괄 폐쇄는 실제 공개 이점을 불확실한 보호와 맞바꾸는 일이에요. GDS는 이전에 공개였던 코드가 이미 미러, 포크, 클론 복사본에 존재할 수 있다고 경고해요.¹ 짧고 표적화된 검토가 소유권 문제를 숨기는 무기한 기본값보다 나아요.

팀이 충분히 안전하다고 부르기 전에 공개 저장소에는 무엇이 있어야 하나요?

최소한 비밀값이 없어야 하고, 소유자, 라이선스, 명확한 설정 안내, 의존성 업데이트 관행, 보안 연락처 또는 취약점 공개 경로, 빠르게 수정 사항을 배포할 수 있는 출시 절차가 있어야 해요.

이것은 AI 코딩 에이전트와 어떤 관련이 있나요?

에이전트는 같은 경계 문제를 확장해요. 위험은 대개 눈에 보이는 파일 하나에 있지 않아요. 권한, 생성된 산출물, 캐시, 외부 요청, 빌드 상태, 출시 권한 안에 있어요. 좋은 에이전트 보안과 좋은 오픈 소스 정책은 모두 그 경계에서 증거를 요구해요.

참고 문헌