AI 프롬프트 하나로 달라질 수 있는 비트코인 코어 버그 공개 방식

인공지능 프롬프트에 따라 소프트웨어 결함의 공개 시점이 달라질 수 있습니다. 비트코인 코어(Bitcoin Core) 사용자에게 실질적으로 중요한 것은 취약점이 공개될 때 수정된 소프트웨어도 함께 제공되는지입니다.

인공지능 프롬프트 하나로 비트코인 코어의 버그 공개 시점이 달라질 수 있나요?

그렇습니다. 간단한 대규모 언어 모델 프롬프트로 비트코인 코어의 취약점을 쉽게 발견할 수 있음을 입증하면, 유지보수 담당자가 수정본과 보안 권고문을 동시에 공개할 수 있습니다. 다만 담당자가 해당 결함을 정책상 요건에 부합한다고 판단해야 합니다. 인공지능을 사용했다는 이유만으로 공개 시점이 자동으로 앞당겨지지는 않습니다. 이 기준은 보안 정보 공개 정책에 명시되어 있습니다.

핵심 답변: 인공지능 프롬프트 하나로 취약점을 쉽게 발견할 수 있음을 입증하면, 유지보수 담당자가 비트코인 코어 수정본과 보안 권고문을 함께 공개하는 근거가 될 수 있습니다. 이 정책 변경은 2026년 10월 22일 채택되었습니다 . 요건에 부합하는 결함의 공개 시점을 바꾸는 정책이며, 인공지능이 발견한 모든 취약점을 조기 공개한다는 뜻은 아닙니다.

다로지오르(darosior)라는 이름으로 활동하는 앙투안 푸앵소(Antoine Poinsot)는 2026년 10월 16일 풀 리퀘스트 #1281을 제출했고, 팬퀘이크(fanquake)가 6일 뒤인 10월 22일 이를 병합했습니다 . 제안과 검토 논의에서는 인공지능 도구가 처음 버그를 발견했는지보다, 그 버그를 얼마나 쉽게 발견하거나 재발견할 수 있는지를 정책 변경의 기준으로 삼습니다. 푸앵소는 다른 사람도 결함을 쉽게 찾아내거나 수정 내역을 알아볼 수 있다면, 공개를 늦춰 얻는 보호 효과가 줄어든다고 설명합니다.

핵심은 수정된 소프트웨어를 제공하는 것과 해당 결함이 보안에 미치는 영향을 설명하는 것이 서로 다르다는 점입니다. 공개된 정책에 따르면, 요건에 부합하는 취약점은 유지보수가 진행 중인 모든 주 버전의 소규모 업데이트를 통해 가능한 한 빨리 수정되며, 해당 업데이트와 함께 보안 권고문이 공개됩니다. 정해진 배포 기한은 없습니다. 각 용어는 이 과정의 서로 다른 부분을 가리킵니다.

• 수정 사항은 취약점을 바로잡는 코드 변경입니다.
• 소규모 업데이트는 기존 소프트웨어 주 버전 내에서 이루어지는 유지보수 업데이트로, 사용자는 이를 통해 수정된 소프트웨어를 받을 수 있습니다.
• 보안 권고문은 취약점과 그 보안상 영향을 설명해 사용자가 자신의 시스템이 위험에 노출되어 있는지 판단하도록 돕습니다.
• 공개 유예는 이러한 영향의 대외 공개를 늦추는 조치입니다. 따라서 사용자가 수정의 보안상 의미에 관한 공개 설명을 받기 전에 수정본이 먼저 제공될 수 있습니다.

독자가 실질적인 판단을 하려면 먼저 자신의 시스템이 위험에 노출되어 있는지 확인해야 합니다. 비트코인 코어를 직접 운영하는지, 설치된 버전이 릴리스 수명 주기 정책에 따라 여전히 유지보수 대상인지, 실제 보안 권고문에서 자신의 운영 환경에 영향을 미치는 취약점을 명시하는지 살펴보세요. 지갑 서비스나 거래소가 인프라를 운영한다면, 해당 업체의 대응이 운영상 중요한 확인 사항이 됩니다. 공개 절차가 빨라질수록 인공지능 관련 기사 제목만 보고 반응하기보다는 보안 권고문을 검토할 준비를 갖추는 편이 더 유용합니다.

정책 발표 자체가 새로운 취약점 악용 수법이나 금전적 손실, 측정으로 확인된 보안 개선을 입증하는 것은 아닙니다. 비공개 신고 절차도 계속 유지됩니다. 저장소의 보안 지침은 취약점을 security@bitcoincore.org로 신고하도록 안내합니다. 이번 변경은 요건에 부합하는 수정본이 사용자에게 전달되는 시점과 그 보안상 영향이 공개되는 시점에 관한 것입니다.

어떤 버그가 신속 공개 대상이 되나요?

비트코인 코어(Bitcoin Core) 취약점은 유지관리자가 쉽게 발견할 수 있다고 분류하면 신속 공개 대상이 됩니다. 누군가 큰 노력 없이 찾아내거나 다시 발견할 수 있는 결함이 여기에 해당합니다. 대규모 언어 모델에 간단한 프롬프트를 입력하는 것만으로 발견할 수 있는 경우가 그 기준의 한 예이며, 인공지능이 처음 발견한 버그여야 한다는 뜻은 아닙니다. 공개된 보안 정책은 발견 용이성을 추가 분류 기준으로 삼습니다. 따라서 보안 권고문을 검토할 때는 다른 누군가가 해당 취약점을 독자적으로 얼마나 쉽게 발견할 수 있는지, 그리고 유지관리자가 어떤 공개 절차를 적용했는지를 살펴보는 것이 중요합니다.

다음 기준을 참고하면 정책을 이해하는 데 도움이 됩니다. 이는 이해를 돕기 위한 편집상의 안내이며, 공식 점수 체계도 아니고 유지관리자의 취약점 분류와 우선순위 판단을 대신하지도 않습니다.

• 발견하거나 다시 발견하는 데 얼마나 노력이 드는지 살펴보세요. 취약점을 찾아내려면 상당한 조사가 필요한가요, 아니면 조금만 살펴봐도 드러날 수 있나요? 정책의 발견 용이성 기준은 취약점을 찾아내는 데 필요한 노력을 따집니다. 인공지능과 관련됐다는 설명만으로는 이 질문에 답할 수 없습니다.
• 유지관리자가 어떻게 분류했는지 확인하세요. 쉽게 발견할 수 있는 취약점이라는 명시적인 평가가 있는지 살펴보세요. 이 평가는 심각도와 구분해야 합니다. 발견 용이성은 결함을 찾아내는 문제이고, 심각도는 그 결함이 초래할 결과에 관한 문제입니다. 정책 도입 근거에서는 이 분류를 취약점 평가 절차의 일부로 설명합니다.
• 수정 버전과 보안 권고문이 어떤 절차로 공개되는지 확인하세요. 공개된 정책에 따르면, 대상 결함은 유지보수 중인 각 주요 버전의 소규모 수정 릴리스를 통해 가능한 한 빨리 수정하고 보안 권고문도 함께 공개해야 합니다. 이 절차에서는 통상적으로 심각도에 따라 적용하는 공개 유예 기간을 생략하지만, 수정 버전의 배포 기한을 특정 시점으로 정하지는 않습니다.

따라서 처음 발견한 방식만으로는 신속 공개 대상인지 판단할 수 없습니다. 사람이 발견한 취약점도 다른 누군가가 쉽게 다시 발견할 수 있다면 대상이 될 수 있습니다. 반대로 인공지능이 발견한 취약점이라고 해서 조사에 모델이 참여했다는 이유만으로 자동으로 대상이 되지는 않습니다. 이는 별도의 예외 조항이 아니라 유지관리자가 정한 기준에서 도출되는 해석입니다. 어느 쪽이든 발견 방식만으로는 취약점 악용 시 발생할 피해의 규모를 판단할 수 없습니다.

“이는 대규모 언어 모델 덕분에 특정 유형의 문제를 찾아내거나 공개하지 않은 수정 사항을 알아채기가 훨씬 쉬워졌기 때문입니다.” — 비트코인 코어 개발자 앙투안 푸앵소(Antoine Poinsot)가 변경 요청의 근거를 설명하며 (source: 비트코인 코어 정책 논의).

푸앵소의 발언은 특정 유형의 취약점과 외부에서 알아챌 수 있는 수정 사항에 한정됩니다. 모델이 모든 결함을 확실하게 찾아내거나, 발견한 모든 문제를 실제로 작동하는 공격 수단으로 만들 수 있다는 뜻은 아닙니다. 그의 주장은 다른 누군가가 독자적으로 다시 발견하기 쉬운 상황에서는 공개 유예의 보호 효과가 줄어드는 반면, 수정 버전의 배포를 미루면 영향을 받는 사용자는 계속 기다려야 한다는 것입니다.

신속한 대응에는 개발 측면에서 감수해야 할 점도 있습니다. 푸앵소는 검토 논의에서 완화 조치를 서둘러 배포하면 개발 브랜치에서 충분히 검증하고 다듬을 시간이 줄어든다는 점을 인정했습니다. 그는 취약점이 더 쉽게 드러나더라도, 의도치 않은 오작동을 일으킬 가능성이 낮다고 확신할 수 있는 단순한 수정 방식을 선호했습니다. 운영자에게 유용한 판단 근거는 유지관리자의 분류, 영향을 받는 기능, 적용할 수 있는 수정 사항을 함께 살펴보는 데서 나옵니다. 기사 제목에서 인공지능을 얼마나 부각하는지는 핵심이 아닙니다.

신속 공개는 기존의 공개 유예 일정과 어떻게 다른가요?

신속 공개는 쉽게 발견할 수 있는 취약점에 대해 패치 배포와 보안 권고문 공개를 동시에 진행하는 방식입니다. 일반적인 공개 절차에서는 심각도와 버전 출시 시점에 따른 공개 유예 기간을 유지합니다. 비트코인 코어(Bitcoin Core) 정책은 해당 조건에 맞는 수정 사항을 유지보수 중인 모든 주 버전의 소규모 업데이트에 최대한 빨리 반영하고, 배포와 함께 권고문을 공개하도록 규정합니다. 다만 배포 기한을 정해 두지는 않았습니다. 따라서 장기간의 공개 유예가 사라진 것은 아닙니다. 신속 공개 절차는 특정 범주의 취약점을 다루는 방식만 바꾸며, 다른 취약점에는 기존 일정을 계속 적용할 수 있습니다. 운영자에게 중요한 차이는 권고문이 유지보수 패치와 함께 나오는지, 아니면 수정 사항이 담긴 버전이 먼저 배포된 뒤에 나오는지입니다. 비트코인 코어 공개 정책을 참고하세요.

공개 유예 기간은 취약점의 보안 관련 세부 사항을 비공개로 유지하는 기간입니다. 패치가 배포되기까지의 기간과 혼동해서는 안 됩니다. 일반적인 일정에서는 수정 사항이 포함된 버전이 이미 배포되어 있어도 보안 관련 설명은 아직 공개되지 않을 수 있습니다. 반면 신속 공개 절차에서는 권고문과 유지보수 버전을 함께 공개합니다. 새 권고문을 읽는 운영자라면 이 차이를 바탕으로 다음 사항을 확인해야 합니다. 새로 배포된 패치에 관한 내용인지, 이미 배포된 수정 사항을 설명하는 내용인지 살펴보는 것입니다. 공식 공개 일정에서는 이 두 시점을 구분합니다.

공개 유예 절차에서는 공개 예정인 취약점의 수와 심각도를 2주 전에 알리는 사전 공지도 유지됩니다. 운영자는 이 공지를 통해 상세 권고문이 나오기 전에 대응을 계획할 수 있습니다. 이를 신속 공개 대상 패치나 치명적 보안 사고에도 일률적으로 적용되는 예고 기간으로 해석해서는 안 됩니다. 마찬가지로 일반 절차를 따르는 중간 및 높은 심각도의 취약점에 제시된 대략적인 공개 간격은 버전의 지원 수명과 공개 시점의 관계를 설명할 뿐, 패치 배포 기한을 약속하는 것이 아닙니다. 이처럼 각 시점을 구분해야 공개 일정 안내를 업데이트를 미루라는 지침으로 오해하지 않을 수 있습니다.

따라서 실제로 비교해야 할 것은 수정 사항을 적용할 수 있는 시점과 관련 정보를 얻을 수 있는 시점입니다. 권고문을 검토할 때는 어떤 공개 절차를 따르는지 파악하고, 수정 사항이 포함된 버전을 찾은 다음, 현재 운영 환경이 영향을 받는지 확인하세요. 신속 공개라면 함께 배포된 유지보수 업데이트를 신속히 검토하세요. 공개 유예 절차를 거쳤다면 이전 업그레이드에서 이미 수정 사항을 적용했는지 확인하세요. 치명적 문제라면 해당 사안에 맞는 지침을 따르세요. 어느 일정도 그 자체만으로 실제 악용이나 금전적 손실이 발생했음을 입증하지는 않습니다. 그런 판단은 권고문에 담긴 기술적 조사 결과를 근거로 내려야 합니다.

사용 중인 비트코인 코어(Bitcoin Core) 버전은 신속 패치 대상인가요?

설치된 비트코인 코어가 유지보수 중인 주 버전에 속하고 신속 공개 대상으로 선정된 취약점의 영향을 받는다면 신속 패치 대상에 해당합니다. 비트코인 코어는 최신 주 버전 3개를 유지보수하며, 약 6개월마다 새 주 버전 출시를 목표로 합니다. 지원이 종료된 버전에는 일반적으로 보안 수정 사항이 제공되지 않습니다 . 정책에 따르면 대상 취약점의 수정 사항은 유지보수 중인 각 주 버전의 유지보수 업데이트를 통해 최대한 빨리 제공해야 합니다 . 따라서 먼저 설치된 버전과 지원 상태를 확인한 다음, 보안 권고문에서 영향을 받는 버전의 세부 정보를 살펴보세요.

주 버전은 릴리스 계열을 구분하며, 포인트 릴리스는 해당 계열 내의 유지보수 업데이트를 뜻합니다. 신속 처리 절차에서는 지원 중인 계열의 유지보수 업데이트로 대상 취약점의 수정 사항을 제공하므로 이 구분이 중요합니다. 모든 과거 버전에 백포트, 즉 이전 계열에 맞게 조정한 수정 사항을 제공한다는 의미는 아닙니다. 업그레이드를 결정할 때는 오래된 안내서에 복사된 지원 버전 목록에 의존하기보다 공식 지원 수명 주기 일정을 확인하세요 .

다음 운영자 점검 목록으로 설치 환경에 정책을 적용해 보세요.

• 설치된 버전을 확인하세요. 운영하는 각 노드의 주 버전과 포인트 버전을 빠짐없이 기록하세요. 각 버전을 보안 권고문과 대조할 수 있도록 설치 환경별로 정보를 구분해 두세요.
• 유지보수 지원 여부를 확인하세요. 공식 지원 수명 주기 일정에서 설치된 버전 계열을 찾아 아직 유지보수 중인지 확인하세요. 정상적으로 작동하는 설치 환경이라도 지원 기간이 지났을 수 있습니다 .
• 영향을 받는 버전 정보를 읽어보세요. 보안 권고문에서 관련 항목을 열고 명시된 영향 범위를 설치 환경과 대조하세요. 취약점 설명을 바탕으로 관련 설정이나 운영 조건도 검토하세요.
• 해당 계열에서 수정 사항을 포함한 버전을 확인하세요. 사용 중인 계열의 어느 버전에 수정 사항이 포함되어 있는지 확인하세요. 신속 처리 대상 취약점의 경우, 정책에 따라 유지보수 중인 주 버전에 포인트 릴리스로 수정 사항을 제공합니다 . 업데이트 일정을 잡기 전에 현재 버전과 업데이트할 목표 버전을 기록하세요.

유지보수 중인 계열을 운영한다면 대상 취약점의 보안 권고문이 나왔을 때 해당 포인트 릴리스의 적용을 검토하는 것이 좋습니다. 지원이 종료된 계열을 운영한다면 기존 계열에 패치가 나올 것이라고 가정하지 말고, 유지보수 중인 버전으로 이전할 계획을 세우세요. 지원이 종료된 버전은 일반적으로 보안 유지보수 대상에서 제외되므로, 과거 계열의 업데이트를 기다리는 것은 신뢰할 만한 대응 계획이 아닙니다 .

지원 대상 여부와 취약점 노출 여부는 구분해서 판단하세요. 유지보수 상태는 사용 중인 계열이 릴리스 정책의 지원 범위에 포함되는지를 알려줍니다. 보안 권고문은 특정 결함이 사용 중인 버전과 관련 운영 조건에 영향을 미치는지를 알려줍니다. 지원 중인 설치 환경이라고 해서 공개된 모든 버그의 영향을 받는 것은 아니며, 지원이 종료되었다는 사실만으로 특정 결함에 노출되었다고 단정할 수도 없습니다. 지원 수명 주기 일정과 개별 보안 권고문을 함께 살펴보고 결정하세요. 먼저 이용 가능한 업그레이드 경로를 확인한 다음, 해당 수정 사항이 설치 환경의 취약점 노출 문제를 해결하는지 판단하세요.

노드 운영자, 지갑 사용자, 거래소 고객은 어떻게 대응해야 할까요?

노드 운영자는 자신이 설치한 소프트웨어가 해당 보안 권고문의 적용 대상인지 확인하고, 영향을 받는다면 그에 맞는 공식 릴리스를 받아야 합니다. 지갑 사용자와 수탁형 거래소 고객은 이용 중인 서비스 제공업체의 관련 공지를 확인해야 합니다. 비트코인(Bitcoin)을 보유하고 있다는 이유만으로 비트코인 코어(Bitcoin Core)를 설치할 필요는 없습니다. 신속 처리 절차는 유지보수 중인 주요 버전 전반에 걸쳐 요건에 해당하는 취약점의 수정본을 제공하는 절차입니다. 모든 설치 환경이나 서비스가 영향을 받는다는 뜻은 아닙니다 (source: 비트코인 코어 보안 공개 정책). 다음 조치는 소프트웨어를 직접 관리할 수 있는 범위와 취약점에 노출되었다는 근거를 함께 고려해 결정해야 합니다.

이는 운영상 권장사항이며, 공개 정책이 부과하는 추가 의무는 아닙니다. 개인 노드의 경우 권고문에 설명된 영향받는 버전과 연결된 수정 사항부터 확인하는 것이 실질적인 출발점입니다. 비트코인 코어 수명주기 정책으로 유지보수 상태를 파악하고, 설치하려는 릴리스가 현재 환경의 업그레이드 경로에 맞는지 확인하세요. 업데이트가 있다는 사실만으로 모든 구성 환경이 똑같이 취약점에 노출되어 있다고 판단해서는 안 됩니다.

인프라 운영자는 권고문이 자신의 노드가 지원하는 서비스와 어떤 관련이 있는지 살펴야 합니다. 실제 운영 시스템을 변경하기 전에 조치가 필요한 배포 환경을 파악하고, 연결된 애플리케이션과의 호환성을 점검하며, 복구 성공의 기준을 정해야 합니다. 모니터링에는 노드 작동 상태와 노드에 의존하는 애플리케이션 기능이 모두 포함되어야 합니다. 복구 계획에서도 취약점을 고려해야 합니다. 영향을 받는 릴리스로 되돌리면 서비스는 복구될 수 있지만 문제가 다시 발생할 수 있습니다. 권고문에 명시된 심각도와 운영 조건에 맞춰 이러한 예방 조치의 수준을 정하세요.

지갑 및 거래소 사용자는 소프트웨어를 직접 보유·관리하는 것과 서비스에 의존하는 것을 구분해야 합니다. 제공업체가 사용자가 직접 점검하거나 업데이트할 수 없는 인프라를 운영할 수는 있지만, 그 사실만으로 취약점에 노출되었다고 볼 수는 없습니다. 해당 권고문이 자신이 사용하는 제품과 관련 있다는 명시적인 설명과 그에 따른 조치 요청이 있는지 확인하세요. 공지가 불분명하다면 사용자가 소프트웨어를 업데이트해야 하는지, 서비스 이용 제한이 예정되어 있는지 문의하세요. 공지가 없다는 사실은 문제가 있다는 확인도, 서비스가 영향을 받지 않는다는 증거도 아닙니다.

거래자에게 이번 발표는 유지보수 정책의 변화이며, 매매 신호나 거래소 장애, 자금 손실의 증거는 아닙니다. 정책 변경 논의는 패치 배포와 공개 시점을 다루며, 저장소의 보안 지침은 취약점 신고 방법을 설명합니다. 어느 쪽도 특정 제공업체에서 사고가 발생했음을 입증하지 않습니다. 서비스와 관련된 매매 판단은 구체적인 권고문과 실제로 이용하는 플랫폼에서 확인된 영향을 근거로 내려야 합니다.

비트코인 코어의 과거 패치와 공개 사이의 시차는 무엇을 보여 주나요?

비트코인 코어(Bitcoin Core)의 과거 사례는 보안 패치가 취약점에 대한 공개 설명보다 훨씬 먼저 제공될 수 있음을 보여 줍니다. 심각도가 낮은 겟데이터(GETDATA) 서비스 거부 취약점 CVE-2024-52920은 2020년 6월 3일 비트코인 코어 0.20.0에서 수정되었고, 2024년 7월 3일 공개되었습니다 . 두 날짜는 서로 다른 시점을 가리킵니다. 하나는 수정된 소프트웨어를 사용할 수 있게 된 시점이고, 다른 하나는 사용자에게 취약점을 명시적으로 설명한 시점입니다. 그 사이에 패치가 없었다는 뜻은 아닙니다.

공식 겟데이터 보안 권고문은 발견자를 존 뉴베리(John Newbery)로 명시하며, 잘못된 형식의 메시지로 인해 영향을 받는 스레드가 자신에게 할당된 프로세서 처리 용량을 소진할 수 있다고 설명합니다 . 서비스 거부 취약점은 자원을 고갈시키거나 가용성을 떨어뜨려 정상적인 작동을 방해할 수 있는 결함입니다. 이 사례에서 보고된 영향은 해당 스레드의 처리 자원에 관한 것입니다. 이 설명만으로 자금 도난, 무단 거래 또는 네트워크 전체의 장애가 발생했다고 볼 수는 없습니다.

• 패치 제공 — 2020년 6월 3일: 비트코인 코어 0.20.0에 수정 사항이 포함되어 배포되었습니다. 수정된 소프트웨어를 언제부터 사용할 수 있었는지 판단할 때 기준이 되는 시점입니다 .
• 공개 설명 — 2024년 7월 3일: 보안 권고문을 통해 취약점의 작동 원리, 심각도, 발견자가 공개되었습니다. 이미 수정된 결함을 문서로 알린 것입니다 .

운영자에게 중요한 것은 패치가 제공된 시점과 실제로 적용된 시점을 구분하는 일입니다. 출시일은 수정된 소프트웨어가 존재했다는 사실을 보여 줄 뿐, 특정 노드가 언제 이를 설치했는지는 알려 주지 않습니다. 마찬가지로 보안 권고문의 게시일만으로 해당 노드가 그날까지 취약한 상태였다고 판단할 수도 없습니다. 개별 설치 환경을 평가하려면 버전과 업그레이드 이력을 확인해야 합니다. 따라서 권고문의 제목만 읽으면 운영상 핵심 질문을 놓칠 수 있습니다. 취약점 설명이 공개되었을 때, 영향을 받는 소프트웨어가 여전히 실행 중이었을까요?

이 과거 사례의 시차를 현행 공개 정책에 따른 일반적인 일정으로 받아들여서는 안 됩니다. 현행 정책은 쉽게 발견할 수 있는 취약점에 대한 신속 처리와, 그 밖의 문제에 대한 심각도별 공개 유예를 구분합니다. 이 과거 사례는 출시일과 공개일의 의미를 분명히 해 주지만, 앞으로 발견될 취약점이 얼마나 오래 비공개로 남을지 예측하는 근거는 되지 않습니다.

겟데이터 보안 권고문은 인공지능이 발견한 취약점 사례도 아니고, 2026년 10월 22일 도입된 신속 처리 절차를 적용한 사례도 아닙니다 . 발견자와 당시 진행 경과는 과거 권고문에 기록되어 있습니다 . 정책 변경 논의에서는 취약점을 다시 발견하기 쉬울 때 패치와 보안 권고문을 함께 제공하는 이유를 설명합니다. 이 오래된 사례로는 그러한 접근 방식이 취약점 악용을 줄였는지, 업그레이드 적용률을 높였는지 판단할 수 없습니다. 여기서 얻을 수 있는 실무적 교훈은 더 한정적입니다. 수정일, 공개일, 영향을 받는 버전 정보를 각각 별개의 근거로 읽어야 한다는 것입니다.

다음 보안 권고가 나오면 무엇을 확인해야 할까요?

다음 비트코인 코어(Bitcoin Core) 보안 권고가 나오면 운영 중인 소프트웨어가 영향을 받는지 확인하고, 취약점이 수정된 적절한 릴리스를 찾은 뒤, 업데이트 후 실제 실행 중인 버전을 검증하세요. 권고문은 공식 공개 정책 및 유지보수 일정과 함께 읽으세요. 실제로 판단해야 할 것은 현재 설치 환경에 패치가 필요한지, 그리고 지원되는 릴리스 중 어느 것이 해당 패치를 제공하는지입니다. 공개 속도를 다룬 기사 제목만으로는 개별 운영 환경에 대한 답을 얻을 수 없습니다.

• 출처를 확인하세요. 비트코인 코어의 공식 보안 권고 페이지에서 해당 권고문을 찾으세요. 소셜 미디어 게시물, 거래 관련 채널, 고객 알림에서 유통되는 주장은 원문 공지를 기준으로 판단하세요.
• 영향을 받는 버전과 발생 조건을 파악하세요. 영향을 받는 릴리스 정보와 취약점이 발현되는 데 필요한 조건을 읽으세요. 이를 실행 중인 소프트웨어 및 설정과 비교하고, 취약점에 노출된 것으로 확인된 부분과 추가 확인이 필요한 부분을 구분하세요.
• 유지보수 상태를 확인하세요. 사용 중인 버전 계열을 지원 주기 일정과 대조하세요. 지원이 종료된 버전에는 일반적으로 보안 수정이 제공되지 않으므로, 오래된 설치 환경이라면 유지보수 업데이트 대신 현재 유지보수 중인 버전 계열로 옮겨야 할 수 있습니다 .
• 취약점이 수정된 적절한 릴리스를 선택하세요. 권고문의 릴리스 정보를 바탕으로 해당 취약점을 해결하는 버전을 선택하세요. 신속 공개 정책은 유지보수 중인 모든 주 버전에 대해 가능한 한 빨리 소규모 업데이트 릴리스로 수정 사항을 제공하도록 규정하지만, 제공 기한을 정해 두지는 않습니다 .
• 배포 결과를 검증하세요. 업데이트 후 관련된 각 노드에서 실제 실행 중인 버전을 확인하세요. 그 결과를 해당 권고문과 연결해 기록하여, 패키지를 내려받거나 설치했다는 사실만으로 작업이 완료됐다고 판단하지 않도록 하세요.

릴리스와 권고문이 함께 공개됐다면, 유지보수 담당자가 쉽게 발견할 수 있다고 분류한 취약점에 신속 공개 절차를 적용한 결과일 수 있습니다. 이 분류는 발견에 드는 노력에 관한 것입니다. 동시 공개라는 사실만으로 심각도가 치명적이거나 실제 악용이 진행 중이라고 판단할 수는 없습니다. 이 두 가지는 취약점 설명을 읽고 별도로 확인하세요. 정책 변경 논의에서는 패치 제공 시점과 취약점 공개 시점을 맞추는 이유를 설명합니다.

취약점 제보는 비공개로 진행하세요. 비트코인 코어의 제보 안내는 security@bitcoincore.org로 제보하도록 안내합니다. 공개 시점을 조율하는 절차는 유지보수 담당자가 수정 사항과 권고문을 배포하는 방식에 관한 것이며, 이 제보 접수 채널을 대체하지 않습니다. 아직 보고되지 않은 결함이 의심된다면 제보 안내를 따르세요.

정책이 실제로 어떻게 시행되는지 평가하려면, 적용 요건을 충족하는 실제 권고문, 유지보수 중인 각 버전 계열에 대응하는 소규모 업데이트 릴리스, 문서에 기록된 릴리스 시점을 추적하세요. 이를 통해 설명된 대로 절차가 운영되는지 확인할 수 있습니다. 다만 이런 관찰만으로 악용이 줄었거나 사용자의 업그레이드 적용이 빨라졌다고 입증할 수는 없습니다.

실무에서 기억할 점: 권고문에 나온 취약점을 해결하는 버전이 실제로 실행 중임을 검증해야 작업이 끝납니다. 다른 사람이 인프라를 운영한다면, 업데이트가 완료됐다고 판단하기 전에 수정 사항이 배포됐는지 확인을 요청하세요.

자주 묻는 질문

비트코인 코어는 장기간의 보안 취약점 공개 유예를 모두 없앴나요?

아닙니다. 비트코인 코어의 신속 공개 절차는 쉽게 발견할 수 있다고 분류된 취약점에 적용됩니다. 다른 취약점에는 심각도에 따른 공개 유예 일정이 유지되며, 치명적인 문제는 표준 일정과 별개로 상황에 맞춘 대응이 필요할 수 있습니다. 비트코인 코어 공개 정책을 참고하세요.

인공지능으로 발견한 버그는 모두 즉시 공개되나요?

아닙니다. 적용 여부는 인공지능이 처음 버그를 발견했는지가 아니라, 해당 버그를 발견하거나 재발견하기가 얼마나 쉬운지에 따라 결정됩니다. 정책 변경 논의에서는 대규모 언어 모델에 간단한 프롬프트를 입력하는 것을 발견에 거의 노력이 들지 않는 사례로 제시합니다. 요건에 해당하는 취약점은 패치된 릴리스와 함께 권고문이 공개되지만, 공개된 정책은 패치 제공 기한을 정해 두지 않습니다.

이전 비트코인 코어 버전에도 신속한 수정이 제공되나요?

이전 버전이라도 해당 주 버전 계열이 계속 유지보수되고 있다면 대상에 포함됩니다. 공개 정책은 유지보수 중인 모든 주 버전에 대해 소규모 업데이트 릴리스로 해당 수정 사항을 제공하도록 규정합니다. 비트코인 코어는 최신 주 버전 세 개를 유지보수합니다 . 지원이 종료된 버전에는 일반적으로 보안 수정이 제공되지 않으므로, 오래된 설치 환경을 계속 사용하려면 먼저 지원 주기 정책을 확인하세요.

이번 정책 변경은 제 비트코인이 위험하다는 뜻인가요?

발표만으로 특정 취약점 악용이나 금전적 손실이 발생했다고 볼 수는 없습니다. 이번 변경은 정책 변경 내용에 설명된 것처럼 적용 요건을 충족하는 수정 사항과 권고문의 배포 방식을 바꾸는 것입니다. 실제로 발표되는 각 보안 권고를 운영 중인 소프트웨어와 대조해 평가하세요. 지갑 서비스나 거래소가 관련 인프라를 운영한다면, 해당 업체의 공지와 조치 완료 확인 내용을 살펴보세요.

비트코인 코어의 취약점이 의심되면 어디에 제보해야 하나요?

저장소의 보안 제보 안내에 따라 security@bitcoincore.org로 비공개 제보하세요. 신속 공개 정책은 비공개 취약점 제보 절차를 대체하지 않습니다.