비트코인 코어, 숨기기 어려운 결함은 더 빨리 알린다

보안 결함을 발견했다면 먼저 고치고, 사람들이 충분히 업데이트한 뒤 자세한 내용을 알리는 편이 안전해 보인다. 아직 고치지 않은 프로그램을 쓰는 사람이 있는데 결함부터 설명하면 공격자에게 힌트를 줄 수 있기 때문이다. 그런데 공격자가 그 설명을 기다리지 않고도 같은 결함을 쉽게 찾아낼 수 있다면 어떨까. 이때도 오래 침묵하는 것이 이용자를 보호하는 최선의 방법일까.

비트코인 네트워크에서 널리 쓰이는 프로그램인 비트코인 코어가 이 문제를 두고 공개 절차를 바꿨다. 코인데스크 보도에 따르면, 쉽게 재발견될 수 있다고 판단한 결함은 지원 중인 모든 버전에 수정을 반영하고, 가능한 한 빨리 수정본과 보안 권고의 일부 내용을 함께 내놓도록 정책 변경안이 반영됐다. 모든 결함을 즉시 공개한다는 뜻은 아니다.

핵심은 AI가 비트코인을 해킹했다는 이야기가 아니다. 특정 결함을 숨겨서 얻는 보호가 작아졌을 때, 개발자가 공개와 수정본 제공 시점을 어떻게 다시 정할지에 관한 이야기다. 이를 이해하려면 결함을 발견하는 순간뿐 아니라, 고친 프로그램이 실제 운영자에게 도착하는 과정까지 봐야 한다.

고친 프로그램은 누가 받아 쓰는가

비트코인 거래는 누군가 전송 버튼을 누르는 것만으로 네트워크 전체에서 받아들여지지 않는다. 네트워크에 참여하는 컴퓨터들이 정해진 규칙에 맞는 거래인지 확인하고 다른 참여자에게 전달한다. 이런 컴퓨터를 노드라고 한다. 노드가 거래를 확인하고 전달하려면 그 일을 수행하는 프로그램이 필요하다. 비트코인 코어는 여기에 널리 쓰이는 소프트웨어 가운데 하나다.

비트코인 네트워크의 규칙과, 그 규칙에 따라 작동하도록 만든 프로그램은 구분할 필요가 있다. 프로그램에 결함이 있다는 소식이 곧 비트코인의 모든 규칙이 무너졌다는 뜻은 아니다. 어떤 기능에 어떤 문제가 생겼는지에 따라 영향이 달라진다. 이번 정책 변경도 특정 공격이나 자산 피해를 발표한 것이 아니라, 발견된 결함을 어떻게 고쳐 전달할지 정한 것이다.

소프트웨어를 고치는 일과 노드들이 고친 프로그램을 쓰게 되는 일도 다르다. 개발자가 수정본을 완성해 배포하더라도, 이를 사용하는 운영자가 새 버전을 설치해야 자신의 컴퓨터에서 수정이 작동한다. 네트워크 전체가 한 회사의 서버처럼 한 번에 바뀌는 구조가 아니므로, 배포가 끝난 뒤에도 여러 버전이 함께 쓰이는 시간이 생길 수 있다. 개발자가 수정본을 내놓았다는 소식만으로 모든 노드의 결함이 해결됐다고 볼 수 없는 이유다.

거래소나 모바일 지갑으로 비트코인을 이용하는 사람 모두가 비트코인 코어를 직접 설치하거나 관리하는 것은 아니다. 따라서 이번 소식이 모든 보유자에게 같은 업데이트 의무를 뜻하지는 않는다. 직접 노드를 운영하는 사람에게는 수정본을 언제 받을 수 있는지가 더 직접적인 문제다. 다른 보유자에게는 비트코인의 운영이 암호 기술뿐 아니라 프로그램의 유지보수와 배포에도 기대고 있음을 보여주는 사례다.

결함을 늦게 알리는 데에는 이유와 대가가 있다

결함이 알려지지 않았다면 공격자도 어디를 살펴봐야 할지 모를 수 있다. 반면 어느 기능에서 문제가 생기는지 공개되면 공격을 시도할 실마리가 늘어난다. 운영자에게 수정의 필요성을 알려주는 공지가, 아직 이전 버전을 쓰는 노드를 노릴 공격자에게도 유용한 정보가 될 수 있다. 공개는 방어하는 사람에게만 정보를 전달하는 수단이 아니다.

그래서 보안에서는 공개 시점이 중요하다. 고친 버전을 먼저 제공하고 충분한 시간이 흐른 뒤 결함을 자세히 설명하면, 공격자가 정보를 얻기 전에 더 많은 운영자가 보호받을 수 있다. 다만 이 방식이 효과를 내려면 기다리는 동안 결함이 널리 알려지지 않아야 한다. 공격자가 이미 문제를 알고 있거나 독자적으로 쉽게 찾아낼 수 있다면, 공개를 늦춘 시간의 의미가 달라진다.

비트코인 코어의 보안정책 변경안 작성자는 기존 정책이 투명성과 이용자의 업데이트 시간을 저울질해 왔다고 설명한다. 특히 이 프로젝트에서는 이용자들이 천천히 업데이트하는 문화를 고려해 공개를 오래 늦추는 쪽을 택했다는 것이다. 공격자에게 정보를 덜 주면서 운영자들이 새 버전으로 옮겨갈 시간을 확보하려는 선택이었다.

작성자가 설명한 기존 절차에서는 보안 수정이 대체로 다음 주요 버전에서야 이용자에게 제공됐다. 지원 중인 이전 버전들에 수정을 미리 반영하기도 어려웠다고 한다.

이것이 결함을 비공개하면 수정본도 반드시 늦어진다는 일반 법칙은 아니다. 고친 프로그램을 먼저 배포하고 설명은 나중에 하는 방식도 가능하다. 이번 논의에서 중요한 것은 비트코인 코어의 기존 절차가 어떤 절충을 해왔느냐다. 작성자는 쉽게 다시 발견될 결함에까지 같은 기다림을 적용하면, 숨기는 이익은 작으면서 고칠 수단을 제공하는 일만 늦어질 수 있다고 본다.

AI가 바꿨다는 것은 다시 찾는 데 드는 수고다

여기서 주목할 것은 최초 발견보다 재발견이다. 개발자가 결함을 비공개로 보고받았더라도 다른 사람이 같은 문제를 별도로 찾아낼 수 있다. 처음 보고한 사람이 비밀을 지킨다고 해서 결함 자체가 사라지는 것은 아니다. 다른 사람이 알아내는 데 많은 시간과 전문성이 필요할수록, 비공개로 유지하는 기간은 운영자에게 더 유리한 시간이 될 수 있다.

변경안 작성자는 최근 쉽게 발견하거나 다시 발견할 수 있는 취약점 보고가 늘었다고 설명한다. 그 배경으로 챗봇에 쓰이는 언어 AI가 일부 종류의 문제를 찾거나 조용히 이뤄진 수정을 알아보는 문턱을 낮췄다는 점을 들었다. 이는 작성자가 경험한 보고 경향에 대한 설명이다. AI가 비트코인 코어의 결함을 어느 비율로 찾아내는지 측정한 결과나, 모든 결함을 찾을 수 있다는 증거는 아니다.

간단한 AI 질문으로 문제가 드러날 정도라면, 공격자가 개발자의 자세한 설명을 기다릴 이유는 줄어든다. 공식 발표를 하지 않았다는 사실만으로 공격자도 모를 것이라고 기대하기 어려워지는 것이다. 이때 공개 여부를 판단하는 기준은 AI가 처음 결함을 찾았는지가 아니라, 다른 사람도 얼마나 쉽게 같은 문제를 찾아낼 수 있는지에 가까워진다.

새 절차는 접수된 결함을 검토하면서 쉽게 발견될 수 있는 문제를 따로 분류하도록 한다. 간단한 AI 질문으로 찾을 수 있는 결함은 예상되는 사례이지, 분류의 전부도 필수 조건도 아니다. 또한 찾기 쉽다는 말이 피해가 작다는 뜻은 아니다. 심각도는 문제가 일어났을 때의 영향을 묻는 기준이고, 재발견 가능성은 다른 사람이 그 문제를 알아내기 얼마나 쉬운지를 묻는 기준이다.

고치는 행위 자체가 단서를 줄 수도 있다. 프로그램에서 무엇이 달라졌는지 살펴본 사람이 왜 그 부분을 고쳤는지 추론할 수 있기 때문이다. 작성자는 특히 여러 지원 버전에 수정을 적극적으로 반영하면 문제를 감추기 어렵다고 설명한다. 이런 결함은 조용히 고치더라도 은폐 효과를 오래 유지하기 어렵다. 수정본을 제공하는 순간과 결함의 단서가 퍼지는 순간을 떼어놓기 힘든 경우다.

새 절차는 설명만 앞당기는 것이 아니다

쉽게 재발견될 것으로 분류한 결함에 대해서는 현재 지원하는 모든 버전에 수정을 반영하고, 가능한 한 빨리 수정 버전을 내도록 한다. 그때 보안 권고에 일부 세부사항도 함께 공개한다. 기존의 장기 비공개 절차와 비교해 달라지는 것은 발표 시점만이 아니다. 고친 프로그램을 제공할 대상과 시점, 이용자에게 정보를 알리는 시점을 함께 바꾸는 방식이다.

재발견이 쉬운 결함은 지원 중인 버전의 수정본과 일부 정보를 빠르게 공개하지만, 시험과 운영자의 설치는 별도로 필요합니다.

지원 중인 이전 버전에도 수정을 반영한다는 점은 중요하다. 최신 주요 버전으로 옮기는 일과 지금 쓰는 버전의 보안 문제를 고치는 일은 운영자에게 같은 부담이 아닐 수 있다. 이전 버전에 머무르는 운영자도 그 버전을 위한 수정본을 받을 수 있다면, 다음 주요 버전으로 옮겨야만 고칠 수 있는 상황과는 선택지가 달라진다. 다만 지원이 끝난 모든 과거 버전까지 고친다는 뜻은 아니다.

함께 나오는 보안 권고는 운영자가 문제와 수정의 필요성을 이해하도록 돕는 정보다. 공격자가 이미 쉽게 알아낼 수 있는 상황이라면, 방어하는 사람만 공식 설명 없이 남겨두는 것도 유리한 선택이라고 단정하기 어렵다. 작성자가 말한 투명성의 이익은 이런 정보의 불균형을 줄이는 데 있다. 그렇다고 공격 방법까지 모두 즉시 공개하겠다는 규칙은 아니다. 변경안이 제시한 것은 수정본과 함께 일부 세부사항을 알리는 절차다.

이 절차가 앞당길 수 있는 것은 우선 수정본의 제공 시점이다. 공지는 정보를 전달하고 수정본은 고칠 수단을 제공하지만, 실제 프로그램을 바꾸는 일은 그다음에 일어난다. 공지를 보고도 바로 설치하지 못하는 운영자가 남으면, 공개된 정보가 공격 단서로 쓰일 여지도 남는다. 따라서 수정본을 빨리 배포한다는 말과 네트워크 전체의 수정이 빨리 끝난다는 말은 구분해야 한다.

개발자의 시험 시간과 운영자의 설치 시간은 다르다

결함이 쉽게 드러난다고 해서 수정본을 서둘러 내는 데 대가가 없는 것은 아니다. 프로그램의 한 부분을 고치면 원래 문제는 해결해도 다른 동작에 영향을 줄 수 있다. 개발자는 결함을 막았는지뿐 아니라 수정 때문에 다른 기능이 잘못 작동하지 않는지도 살펴야 한다. 수정안을 만들었다는 사실과 운영자에게 배포할 만큼 확인했다는 판단은 다르다.

변경안 작성자도 빠른 배포로 인해 수정 사항을 개발 과정에서 시험할 시간이 줄어들 수 있다고 밝혔다. 이는 새 정책이 이미 오류를 늘렸다는 보고가 아니라, 정책을 바꾸며 예상한 부담이다. 실제 시험 시간이 얼마나 달라졌는지, 그 결과 배포 뒤 문제가 늘거나 줄었는지는 확인되지 않았다. 배포 일정을 앞당겼다는 사실만으로 수정본의 품질까지 평가할 수는 없다.

시험할 여유가 줄 수 있는 만큼, 작성자는 수정안을 고를 때 남은 은폐 효과보다 다른 기능에 문제가 생기지 않는다는 확신에 더 무게를 둘 수 있다고 설명했다. 단순한 수정안이 그런 확신을 더 준다면, 그 수정안으로 인해 결함의 단서가 드러나더라도 채택하겠다는 뜻이다. 이는 결함을 공개해서 시험 시간을 늘리겠다는 말이 아니다. 시험 시간이 줄 수 있는 상황에서, 결함을 감추는 데 도움이 된다는 이유만으로 더 확신할 수 있는 수정안을 포기하지 않겠다는 선택이다.

여기에는 서로 다른 두 시간이 있다. 하나는 개발자가 배포 전에 수정본을 시험하는 시간이고, 다른 하나는 운영자가 배포 후에 새 버전을 설치하는 시간이다. 전자가 부족하면 고친 프로그램 자체에 문제가 남을 수 있다. 후자가 길면 올바른 수정본이 나와도 이전 프로그램을 쓰는 컴퓨터가 남는다. 개발자가 충분히 시험했다고 설치가 자동으로 끝나는 것도, 운영자가 빨리 설치했다고 수정본의 품질이 증명되는 것도 아니다.

여기에 공격자가 결함을 다시 찾아내는 시간이 겹친다. 그 시간이 짧다면 비공개 기간을 늘려도 개발과 설치에 쓸 안전한 여유가 그만큼 늘어난다고 보기 어렵다. 반대로 쉽게 재발견되지 않을 결함이라면 공개를 늦춰 얻는 이익이 더 클 수 있다. 이번 정책이 모든 결함을 한꺼번에 같은 방식으로 처리하지 않고, 재발견하기 쉬운 문제를 선별하는 이유가 여기에 있다.

확인된 것은 정책의 논리이며, 성과는 아직 아니다

코인데스크는 보도 시점까지 새 규칙에 따라 분류된 결함이 아직 없었다고 전했다. 따라서 이번 변화가 공격이나 피해를 줄였다고 말할 단계는 아니다. 운영자들이 수정본을 얼마나 빨리 설치했는지, 공개된 정보가 공격과 방어에 각각 어떤 영향을 줬는지도 이 보도와 정책 논의만으로는 알 수 없다. 절차를 바꾼 이유와 그 절차가 실제로 효과를 냈는지는 별개의 문제다.

그럼에도 이번 논의는 ‘오래 숨길수록 안전하다’는 직관의 조건을 분명하게 해준다. 비공개가 보호에 도움이 되려면, 숨기는 동안 공격자가 알아내기 어렵고 방어하는 쪽은 실제로 준비할 수 있어야 한다. 쉽게 재발견될 결함에서는 첫 번째 조건이 약해진다. 그런데도 수정본 제공을 오래 늦춘다면, 비공개 기간은 보호를 위한 여유라기보다 고칠 기회를 기다리는 시간이 될 수 있다.

비트코인 코어의 새 절차는 그 좁은 상황에 대한 답이다. 공격자가 결함을 다시 찾는 시간, 개발자가 수정본을 확인하는 시간, 운영자가 받아 쓰는 시간을 함께 고려한 선택이다. AI가 이 과정을 모두 대신하거나 빠른 공개가 언제나 안전을 보장한다는 뜻은 아니다. 쉽게 드러날 결함을 고치면서 알리는 이유는 공개 자체가 더 안전해서가 아니다. 이런 결함을 비공개로 유지하느라 이용자에게 수정본을 제공하는 일까지 늦추지 않으려는 것이다.