▲

NHS England에 코드를 공개 상태로 유지해 달라고 요청하는 공개서한

 (keepthingsopen.com)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • NHS England 기술 리더십의 저장소 소스 코드 비공개 결정에 반대하며, 공적 자금으로 만든 코드는 대중에게 공개돼야 한다는 원칙을 재확인함
  • NHS England에는 SDLC-8 red line 철회와 NHS Service Standard Principle 12 “Make new source code open”에 대한 약속 재확인이 요구됨
  • 오픈소스 공개는 비공개 유지보다 더 많은 작업을 요구하지만, 더 높은 품질 기준과 취약점의 사전 발견·수정, 피해를 제한하는 장벽 마련이 필요함
  • 비공개 소스는 필요한 보안 작업을 건너뛰게 만들 수 있고, 깊이 있는 방어 대신 모호성에 의존하며, 충분히 동기화된 공격자에게 주는 이점은 매우 작아 보임
  • 2026년 5월 1일 이후 402명이 서명했으며, 서명자는 이름·이메일·영국 공공부문 소프트웨어 기여 여부 등을 제출할 수 있고 익명 서명은 검증 후 24시간 이내 개인정보가 삭제됨

공개서한의 핵심 요구

  • NHS England 기술 리더십이 모든 저장소의 소스 코드를 숨기기로 한 결정에 반대하며, 공적 자금으로 만든 코드는 대중에게 공개돼야 한다는 원칙을 재확인함
  • 이 원칙은 UK Government Design Principles와 NHS Service Standard에 담겨 있으며, 현재 후퇴하고 있는 것으로 봄
  • NHS England에는 SDLC-8 red line 철회와 NHS Service Standard Principle 12 “Make new source code open”에 대한 약속 재확인이 요구됨
  • 2026년 5월 1일 이후 402명이 서명했으며, 서명은 수작업 검토 후 페이지에 표시됨

오픈소스가 더 엄격한 품질 기준을 만든다는 논리

  • 코드를 오픈소스로 공개하는 일은 비공개로 유지하는 것보다 더 많은 작업을 요구함
  • 그 어려운 작업 자체가 핵심이라고 봄
  • 오픈소스 공개는 더 높은 품질 기준을 요구하고, 취약점을 사전에 찾고 고치며 감시하는 절차를 필요로 함
  • 위험을 식별하고, 문제가 생겼을 때 피해를 제한할 장벽을 마련해야 함
  • 이를 인간 면역 체계에 비유하며, 위협에 노출되는 것이 공격 표면을 더 단단하게 만든다고 봄

비공개 소스에 대한 비판

  • 비공개 소스는 필요한 보안 작업을 건너뛸 수 있게 만듦
  • 비공개 방식은 깊이 있는 방어 대신 모호성에 의존한다고 봄
  • 충분히 동기화된 공격자가 있을 때 모호성이 제공하는 이점은 매우 작아 보임

서명 방식과 개인정보 처리

  • 서명자는 이름, 이메일 주소, 영국 공공부문 소프트웨어 기여 여부, 선택 사항인 역할과 조직을 제출할 수 있음
  • 영국 공공부문 소프트웨어 기여에는 기술적·비기술적 기여, 공개·비공개 기여가 모두 포함될 수 있음
  • 기여가 있는 경우 커밋이나 프로필 링크 정도로 충분하며, 해당 정보는 공개되지 않음
  • 익명 서명을 선택하면 서명은 “Anonymous”로 표시되고, 역할과 조직을 제공한 경우 함께 표시될 수 있음
  • 익명 서명의 경우 검증 후 24시간 이내에 개인정보가 삭제됨
  • 이메일 주소는 서명 관련 연락이 필요할 때만 사용되며 공개되지 않음
  • 개인정보 처리의 법적 근거는 동의이며, 동의 철회가 가능함
  • 데이터 관련 연락은 signatures@keepthingsopen.com로 할 수 있음
  • 개인정보 처리에 대한 불만은 Information Commissioner’s Office에 제기할 수 있음

참고 자료와 지원 링크

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • Mythos 위협에 대한 대응이 전부 보여주기식 조치처럼 보이고, 투명성과 개방성이 생기는 순간 어떤 허술한 핑계든 써서 되돌리려는 모습이 드러남
    비기술자가 “폐쇄 소스로 돌리지 않았고 취약점이 발견됐을 때 충분히 하지 않았다는 비난을 받을 확률이 0.1%라도 있다”고 믿고 내리는 결정에 가깝다
    2026년의 극단적 탐욕과 이기심은 공공선의 비용을 감수하고도 그런 결정을 쉽게 만들고, 민간 부문도 이런 면에서 딱히 낫지 않다는 점은 늘 염두에 둬야 함

    • 예외가 있다면 폐쇄 이후 코드에 상당한 변경이 있었고, 공격자나 대규모 언어 모델이 그 변경분을 읽지 못한 경우뿐임
      내부적으로 대규모 언어 모델을 써서 소스 코드를 공개하지 않고 비공개로 버그를 찾으면 공격자보다 한발 앞설 수 있다
      최근 Copy.fail 공개 재앙처럼, 대규모 언어 모델을 쓴 누군가가 발견한 취약점이 명확한 수정 없이 제로데이로 공개되면서 커뮤니티가 혼란과 공황에 빠진 사례도 봤다
      강력한 대규모 언어 모델이 공개 가중치와 폐쇄 가중치 양쪽에 존재하는 상황에서, 특히 병원에서 쓰이는 소프트웨어라면 무조건 전부 오픈소스로 만드는 건 덜 타당해졌고 균형이 필요함

  • NHS 디지털 서비스의 품질을 걱정해서 이 스레드를 보고 있다면, 장애인 사용자 경험을 실제로 해치고 핵심 서비스 개선에 쓸 돈을 낭비하게 만드는 접근성 오버레이를 NHS 제공자가 사지 못하게 막는 청원에도 서명해주면 좋겠음: https://petition.parliament.uk/petitions/765480/

  • Cloudflare 검증기가 내가 인간이 아니라고 해서 서명할 수가 없음

  • 이 상황을 쉽게 설명한 영상이 있음: https://youtu.be/XNLUfqtgBUk
    이 분야가 전문 영역이라면 공개 서한에 꼭 서명해주면 좋겠음

  • 설령 NHS가 동의해서 실행하려 해도, 관련 지침을 만드는 데만 최소 1년은 걸릴 것임
    그다음 현재 기술팀에 정리하라고 요청하면 또 10년은 걸릴 듯함

  • 관련 글: NHS Goes to War Against Open Source
    https://shkspr.mobi/blog/2026/05/nhs-goes-to-war-against-ope... (https://news.ycombinator.com/item?id=47973710)

  • 지난 몇 주간 CISO, CTO, 유지보수자, 동료들과 이 주제로 이야기했는데, 일부는 F50 기업 소속이고, 이들의 기본 계획은 애플리케이션 보안팀이 하루 안에 문제를 쉽게 검증하고 고칠 수 있을 때까지 오픈소스 기여와 사용을 중단하는 쪽임
    전통적으로 종단 간 대응 시간은 8~10일 정도였지만, 지금은 그 속도로는 버틸 수 없다
    오픈소스의 죽음이라고 보진 않지만, 유지보수자에게 지속 가능한 운영 자원이 제공되지 않으면서 오픈소스의 경제가 공유지의 비극으로 바뀌었음을 보여준다
    또한 조직들이 수십 년 동안 엔지니어링 내부와 조직 차원에서 보안을 우선순위로 두지 않았다는 인정이기도 하지만, 여기 HN의 대화 수준을 보면 그건 별도 논의가 필요해 보인다
    오픈소스를 좋아하는 사람들이 정말 신경 쓴다면 이상론만 말하지 말고 돈을 써야 하며, 오픈코어로 가거나 정식 자금 지원과 후원을 마련하는 방안을 생각해야 한다
    프로젝트 소유자의 상용화를 허용하면서도 훨씬 제한적인 라이선스를 도입하는 것도 중요하다. 비슷한 이념을 가진 몇몇 개인의 선의에 기대는 GNU식 프로젝트 대부분은 살아남기 어렵고, 기여자도 보수를 받아야 함
    “Linux/Kubernetes/Chrome(Edge 포함)/거의 모든 프로그래밍 언어/nginx 등을 중단할 수는 없지 않나”라는 질문에 대해서는, 앞으로 쓰는 모든 의존성과 라이브러리를 동결하고, 종단 간 취약점 수정이 24시간 안에 가능해질 때까지 소스 코드를 공개하지 않겠다는 뜻임
    팀들은 핵심 프로젝트와 의존성을 내부용으로 포크하고, 업스트림 기여가 오염되었거나 추가 취약점을 도입할 수 있다는 두려움 때문에 업스트림에 기여하지 않는 방안도 진지하게 검토 중임

    • simonw의 관점처럼 오히려 오픈소스가 더 가치 있어져야 한다는 말에 동의함
      “흥미로운 결과는 오픈소스 라이브러리가 더 가치 있어진다는 점이다. 보안에 쓴 토큰 비용을 모든 사용자와 공유할 수 있기 때문이다. 이는 오픈소스 라이브러리 대체품을 바이브 코딩으로 저렴하게 만들 수 있어 기존 오픈소스 프로젝트의 매력이 줄어든다는 생각에 정면으로 반박한다”
      코드를 포크해서 내부로 가져가려는 반사적 움직임은 이해하지만, 엔지니어링팀이 관리하고 취약점을 완화해야 할 코드가 더 많아지는 상황에서 그게 얼마나 지속 가능할지는 의문임
      [0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
    • “오픈소스 기여와 사용을 중단”한다는 게 무슨 뜻인지 모르겠음
      Linux/Kubernetes/Chrome(Edge 포함)/거의 모든 프로그래밍 언어/nginx 등을 중단할 수는 없을 텐데 궁금함
답변달기