대부분의 사람들이 Bitcoin Core를 다운로드할 때, 빌드 시스템과의 상호작용은 몇 번의 클릭으로 끝납니다. 그들은 소프트웨어의 실행 파일을 가져오고, 서명을 확인한 후(희망적으로!), 비트코인 노드를 실행하기 시작합니다. 그들이 즉시 보는 것은 실행 중인 소프트웨어입니다. 그들이 보지 못하는 것은 그 소프트웨어를 생성한 빌드 시스템과 광범위한 과정입니다. 비트코인의 분산화, 투명성 및 검증 가능성의 원칙을 나타내는 빌드 시스템입니다.
그 다운로드 뒤에는 “왜 누구도 이 소프트웨어를 신뢰해야 하는가?”라는 간단한 질문에 답하기 위해 설계된 수년 간의 엔지니어링 작업이 있습니다. 답은: 당신은 신뢰할 필요가 없습니다. 당신은 검증할 수 있어야 합니다.
소프트웨어 공급망 공격이 전 세계의 헤드라인을 장식하는 시대에, 손상된 npm 패키지, 백도어가 있는 라이브러리, 악의적인 CI 서버 등과 함께, Bitcoin Core의 빌드 과정은 조용한 규율의 프로젝트로 자리 잡고 있습니다. 그 방법은 “배포를 위해 푸시”의 마찰 없는 편리함에 비해 느리고 복잡해 보일 수 있지만, 그것이 요점입니다. 보안은 편리하지 않습니다.
Bitcoin Core의 빌드 시스템을 이해하기 위해서는 다음을 이해해야 합니다:
- Bitcoin Core의 빌드 시스템 철학
- 재현 가능한 빌드
- 의존성 최소화
- 자동 업데이트 없음
- 지속적 통합
- 지속적인 적응
Bitcoin Core의 빌드 시스템 철학
비트코인의 분산화에 관해서는 대부분의 사람들이 채굴자, 노드 및 개발자에 집중합니다. 그러나 분산화는 프로토콜의 참가자에만 국한되지 않습니다. 소프트웨어 자체가 구축되고 배포되는 방식까지 확장됩니다.
비트코인 생태계의 한 원칙은 “신뢰하지 말고 검증하라”입니다. 자신의 노드를 운영하는 것은 검증의 행위로, 모든 블록과 거래를 합의 규칙에 따라 확인하는 것입니다. 그러나 빌드 시스템 자체는 소프트웨어 수준에서 검증할 수 있는 또 다른 기회를 제공합니다. 비트코인은 신뢰할 수 있는 중개인 없이 돈이며, Bitcoin Core는 신뢰할 수 있는 빌더 없이 소프트웨어가 되기 위해 노력합니다. 빌드 시스템은 누구나 어디서나 bitcoincore.org 웹사이트에 나타나는 동일한 바이너리를 독립적으로 재현할 수 있도록 보장하기 위해 많은 노력을 기울입니다.
이 철학은 Ken Thompson의 1984년 에세이 신뢰하는 신뢰에 대한 반성으로 거슬러 올라갑니다. 이 에세이는 깔끔해 보이는 소스 코드조차도 그 소프트웨어를 빌드한 컴파일러가 손상되었다면 신뢰할 수 없다고 경고했습니다. 비트코인 개발자들은 그 교훈을 마음에 새겼습니다. Bitcoin Core 기여자인 Michael Ford(fanquake)의 말에 따르면:
“재현 가능한 빌드는 중요합니다. 우리의 소프트웨어 사용자는 내부에 포함된 것이 우리가 말하는 것과 동일하다는 것을 신뢰할 필요가 없어야 합니다. 이는 항상 독립적으로 검증 가능해야 합니다.”
기술적 목표이자 비트코인 정신의 일부인 진술입니다.
보안 세계에서는 “공격 표면”에 대해 이야기합니다. Bitcoin Core의 빌드 시스템은 빌드 프로세스 자체를 최소화하고 방어해야 할 공격 표면으로 취급합니다.
재현 가능한 빌드: 끝까지 검증
Bitcoin Core 릴리스를 생성하는 과정은 GitHub의 오픈 소스 코드베이스로 시작됩니다. 모든 변경 사항은 공개됩니다. 모든 풀 리퀘스트는 검토됩니다. 그러나 사람이 읽을 수 있는 코드에서 실행 가능한 바이너리 소프트웨어로의 여정은 컴파일러, 서드파티 라이브러리 및 운영 체제를 포함하며, 이들은 모두 변조, 백도어 또는 오류의 잠재적 경로입니다.
“신뢰할 수 있는 제3자는 보안 구멍이다” – Nick Szabo (2001)
이러한 우려를 해결하기 위해 Bitcoin Core는 재현 가능하고 결정론적인 소프트웨어 환경을 생성하기 위해 설계된 패키지 관리자 Guix를 사용하여 빌드 프로세스 파이프라인을 설계했습니다.
새로운 Bitcoin Core 릴리스가 태그되면, 여러 독립적인 기여자가 Guix를 사용하여 처음부터 바이너리를 빌드합니다. 각 빌더는 동일한 툴체인, 컴파일러 버전 및 시스템 라이브러리를 보장하는 격리된 환경에서 작업합니다. 모든 빌더가 동일한 비트 출력을 생성하면 그들은 빌드가 결정론적임을 알고 있습니다.
기여자들은 결과 바이너리를 암호적으로 서명한 후, 각 Bitcoin Core 릴리스에 대한 이러한 증명을 나열하는 별도의 GitHub 리포지토리 ‘guix.sigs’에 해당 서명을 게시합니다. 일부 빌더는 Bitcoin Core 개발자이지만, 증명 과정은 일반 대중 누구에게나 열려 있으므로 필수 사항은 아닙니다. 사실, 많은 비코드 기여자들이 정기적으로 서명을 기여합니다.
이 과정은 재현 가능한 빌드로 알려져 있으며, Thompson의 “신뢰하는 신뢰”에 대한 해독제입니다. 이는 누구나 오픈 소스 코드를 가져가고, 동일한 Guix 환경을 사용하여 공식 바이너리가 자신이 직접 빌드한 것과 일치하는지 독립적으로 확인할 수 있음을 의미합니다. 재현 가능한 빌드는 소프트웨어가 소스 코드의 진정한 표현임을 검증할 수 있지만, 소프트웨어의 정확성은 철저한 테스트 및 코드 검토와 관련된 프로세스에 맡겨집니다.
대부분의 사람들은 전체 컴파일을 수행하거나 Guix 매니페스트를 확인하거나 빌드 해시를 비교하지 않을 것입니다. 그들은 그럴 필요가 없습니다. 그러한 인프라의 존재와 이를 유지하는 사람들은 모든 사용자에게 신뢰의 기초를 제공합니다.
bitcoincore.org의 공식 바이너리는 단순히 “Bitcoin Core 유지 관리자가 생성한 것”이 아닙니다. 그것들은 수십 개의 독립적인 빌더의 출력이 교차하는 지점입니다. 당신이 결국 다운로드하는 것은 다른 모든 사람들이 구축하고 진정성을 검증한 것입니다.
끝까지 검증입니다.
의존성 최소화: 신뢰할 것이 적다
재현 가능성은 방정식의 한 면입니다. 다른 한 면은 재현해야 할 것을 최소화하는 것입니다. Bitcoin Core의 코드는 Bitcoin Core를 실행할 때 실행되는 유일한 코드가 아닙니다. Bitcoin Core는 개발 속도와 생산성을 높이기 위해 외부의 서드파티 코드와 라이브러리에도 의존합니다.
지난 10년 동안 Bitcoin Core 개발자들은 OpenSSL 및 MiniUPnP와 같은 불필요하고 때로는 문제가 되는 서드파티 의존성을 꾸준히 제거해 왔습니다. 외부 라이브러리나 툴킷이든, 이러한 의존성은 복잡성을 추가하거나 숨겨진 가정을 가져옵니다. 한때 Core의 코드베이스의 필수 요소였던 Boost 및 Libevent와 같은 프로젝트는 점차 폐기되거나 더 간단하고 독립적인 대안으로 대체되고 있습니다.
왜 그럴까요? 모든 의존성을 상속받는 것은 잠재적인 공급망 위험이기 때문입니다. 그것은 당신이 작성하지 않았고, 감사하지 않으며, 완전히 통제할 수 없는 더 많은 코드입니다. 의존성을 줄이면 빌드 시스템이 더 간결하고 안전하며 검증하기 쉬워집니다.
Brink는 최근 “의존성 최소화” 블로그 게시물에서 이 노력을 강조하며, 단순성의 문제일 뿐만 아니라 프로젝트의 보안과 자율성을 유지하는 것과 관련이 있다고 언급했습니다. 제거된 각 의존성은 프로젝트가 신뢰해야 할 외부 당사자가 하나 줄어들고, 백도어의 잠재성이 하나 줄어듭니다.
궁극적인 목표는 완전히 정적 바이너리를 생성하는 것입니다: 실행에 필요한 모든 것을 포함하는 실행 파일로, 동적 또는 런타임 의존성이 없습니다. 이러한 자기 포함성은 하나의 운영 체제에서 다른 운영 체제로 다를 수 있는 외부 라이브러리에 대한 의존성을 없애줍니다.
대부분의 소프트웨어가 더 무겁고 중앙 집중식 패키지 생태계에 더 의존하게 되는 세상에서, Bitcoin Core는 반대 방향으로 나아가고 있습니다: 최소주의와 독립성을 향해.
자동 업데이트 없음
대부분의 현대 소프트웨어에서 사용자들은 어떤 소프트웨어 버전으로 업데이트할지 또는 소프트웨어를 전혀 업데이트할지에 대한 결정에서 차단됩니다. 당신은 앱을 설치하고, 그것은 조용히 자동으로 최신 버전으로 업데이트됩니다. 이것은 편리하지만, Bitcoin Core의 철학과는 정반대입니다.
Bitcoin Core는 자동 업데이트를 포함한 적이 없으며, 개발자들은 앞으로도 포함하지 않을 것이라고 말했습니다. 자동 업데이트는 권력을 집중시킵니다. 그것들은 네트워크의 모든 노드에 (잠재적으로 악의적인) 코드를 푸시할 수 있는 단일 그룹을 만듭니다. 이것은 비트코인이 피하고자 했던 중앙 집중식 통제의 전형적인 형태입니다. 사용자가 수동으로 다운로드하고, 검증하고, 새 버전을 설치하도록 요구함으로써, Bitcoin Core는 개인의 책임과 검증 가능한 동의를 강화합니다.
빌드 시스템과 자동 업데이트의 부재는 동일한 원칙의 두 가지 측면입니다. 오직 노드 운영자만이 무엇을 실행할지 결정하고, 실행되는 소프트웨어가 진정한 것인지 검증할 수 있습니다.
지속적 통합: 천천히 움직이고 문제를 해결하라
실리콘 밸리에서는 지속적 통합 및 지속적 배포(CI/CD)가 민첩한 소프트웨어 개발의 특징입니다. 빠르게 배송하고, 더 빠르게 반복합니다. 자동화가 나머지를 처리하게 하십시오.
Bitcoin Core는 다른 접근 방식을 취합니다. 그 CI 시스템은 배포를 가속화하기 위해 존재하는 것이 아니라 무결성을 보호하기 위해 존재합니다. 자동화된 빌드는 플랫폼 간 일관성을 테스트합니다. Bitcoin Core의 빌드 시스템은 가능한 한 하드웨어 및 운영 체제에 무관하게 설계되었습니다. 이 프로젝트는 Linux, macOS 및 Windows를 위한 바이너리를 빌드할 수 있을 뿐만 아니라 x86_64, aarch64(ARM) 및 심지어 riscv64를 포함한 여러 아키텍처를 위한 바이너리도 빌드할 수 있습니다. 지속적 통합 시스템은 이러한 호환성과 소프트웨어 무결성을 보장하기 위해 각 제안된 변경 사항에 대해 수백 가지 테스트를 수행합니다.
그 결과 “지속적 통합”이 지속적인 테스트, 검증 및 보안을 의미하며, 지속적인 혁신이 아님을 의미하는 문화가 형성됩니다.
천천히 움직이고 문제를 해결하십시오.
지속적인 적응: 이제 끝났나요?
빌드 시스템은 정적이지 않습니다. 개발자들은 의존성을 줄이고, 크로스 아키텍처 빌드를 개선하며, 런타임 의존성이 없는 완전 정적 빌드 미래를 탐색함으로써 계속해서 이를 개선하고 있습니다.
Bitcoin Core의 빌드 시스템은 결정론성을 추구하지만, 빌드 시스템 자체는 정적일 수 없습니다. 그것이 작동하는 세계는 끊임없이 변화하고 있습니다. 운영 체제, 컴파일러, 라이브러리 및 하드웨어 아키텍처는 모두 변합니다. macOS 또는 glibc의 새로운 릴리스, 컴파일러 플래그의 모든 폐기 또는 새로운 CPU 아키텍처의 출현은 해결해야 할 미세한 호환성 문제를 도입합니다. 정지해 있는 빌드 시스템은 시간이 지남에 따라 전혀 빌드를 하지 못하게 될 것입니다.
재현 가능한 빌드의 역설은 그것들이 재현 가능성을 유지하기 위해 지속적인 진화를 요구한다는 것입니다. 개발자들은 변화의 움직이는 배경에 대해 결정론을 유지하기 위해 툴체인을 지속적으로 고정하고, 패치하고, 때로는 교체해야 합니다. 안정성과 적응성 간의 이 균형을 유지하는 것은 비트코인의 지속적인 회복력의 일부입니다.
당신의 기회를 놓치지 마세요 The Core Issue — 많은 Core 개발자들이 자신이 작업하는 프로젝트를 설명하는 기사를 포함하고 있습니다!
이 글은 최신 인쇄판 Bitcoin Magazine의 The Core Issue에 실린 편집자의 편지입니다. 우리는 전체 호에서 탐구된 아이디어를 미리 엿볼 수 있도록 여기에서 공유하고 있습니다.
[1] https://brink.dev/blog/2025/09/19/minimizing-dependencies/
