이더리움 코어 거버넌스 설명

이더볼더(ETHBoulder)에서 이더리움 재단의 닉소 로키시(Nixo Rokish)가 진행한 프레젠테이션으로, 이더리움의 코어 프로토콜 거버넌스, 하드 포크가 조정되는 방식, 이더리움을 누가 통제하는지에 대한 흔한 오해, 그리고 거버넌스 프로세스에 참여하는 방법을 설명합니다.

이 스크립트는 이더볼더가 게시한 원본 동영상 스크립트 (opens in a new tab)의 접근성 향상 버전입니다. 가독성을 위해 약간의 편집을 거쳤습니다.

소개 (0:12)

참석해 주신 여섯 명의 친구들 모두 감사합니다. 좋습니다. 오늘 저는 이더리움 코어 거버넌스에 대해 이야기하려고 합니다. 제 이름은 닉소(Nixo)입니다. 저는 이더리움 재단(EF)에서 프로토콜 지원 팀을 이끌고 있습니다. 저희의 여러 임무 중 하나는 거버넌스 프로세스를 더 명확하게 만들고, 참여하는 모든 사람이 더 쉽게 탐색할 수 있도록 돕는 것입니다. 이더리움에는 코어 개발자들보다 훨씬 더 많은 사람들이 참여하고 있기 때문입니다.

발표 개요는 다음과 같습니다. 코어 거버넌스가 무엇인지 이야기할 것입니다. 오해와 이더리움 거버넌스가 현재 어떻게 기능하는지에 대해서도 다룰 것입니다. 다른 탈중앙화된 거버넌스 시스템과 어떻게 비교되는지, 빌더들이 왜 관심을 가져야 하는지, 그리고 참여를 위한 실행 가능한 방법에 대해서도 짚어보겠습니다.

그렇다면 코어 프로토콜 거버넌스란 무엇일까요? 저는 노드를 운영합니다. 즉, 제 집에 이더리움 소프트웨어를 실행하는 하드웨어, 즉 컴퓨터가 있다는 뜻입니다. 이 이더리움 소프트웨어를 설정할 때, 저는 해당 소프트웨어를 실행할 클라이언트를 선택해야 했습니다. 이더리움은 클라이언트 다양성을 위해 여러 클라이언트를 보유하고 있다는 점에서 다소 독특합니다. 그 목적은 한 클라이언트가 다운되거나 버그가 발생하더라도 전체 네트워크가 다운되지 않도록 하는 것입니다. 다른 클라이언트를 가진 다른 블록체인들도 있습니다. 하지만 이더리움은 실제로 버그로부터 우리를 보호하는 방식으로 설정된 유일한 블록체인입니다. 예를 들어 솔라나(Solana)를 보면, GTO라는 다른 클라이언트가 있는 것으로 알고 있지만 채택률이 20~21%에 불과합니다. 따라서 다수 클라이언트가 다운되면 체인도 다운됩니다. 우리는 다른 네트워크들이 다운되는 것을 보아왔습니다. 이것이 바로 이더리움이 가장 탄력적이고 안전한 블록체인인 이유입니다.

그렇다면 이렇게 많은 다양한 클라이언트와 조정해야 할 때 이더리움에 어떻게 변경 사항을 적용할 수 있을까요? 먼저 하드 포크와 소프트 포크를 구분해 보겠습니다. 소프트 포크는 하드 포크만큼의 조정을 필요로 하지 않습니다. 이더리움은 주로 하드 포크로 작동합니다. 하드 포크란 기본적으로 모든 클라이언트가 이더리움의 새 버전을 구축하고, 미리 설정된 특정 시간에 이 새 버전의 이더리움을 출시하기로 결정하는 것입니다. 여전히 이더리움이지만 새로운 기능, 다른 기능들을 갖추고 있습니다. 그리고 집에서 노드를 운영하는 저와 같은 노드 운영자나 전문 운영자 모두 이 새로운 버전의 이더리움을 수용해야 합니다. 그들은 새로운 소프트웨어를 포함하도록 노드를 업그레이드하거나 업데이트해야 합니다.

그렇다면 하드 포크에 어떤 기능이 들어갈지 어떻게 결정할까요? 그들은 시간과 자원을 할당하기 위해 우선순위에 합의해야 합니다. 할당할 수 있는 시간과 자원이 유한하기 때문입니다. 그들은 보안 결함이나 보안 패치, UX 같은 것들을 우선시합니다. 만약 우리와 경쟁하는 다른 블록체인이 있다면, 우리는 그 블록체인들과 경쟁력을 갖춰야 합니다. 그래서 그들이 고려하는 것 중 하나는 도입되는 모든 기능이 향후 잠재적인 로드맵 항목과 상위 호환(forward compatible)되어야 한다는 점입니다.

작년에 정말 논쟁적인 일이 있었습니다. 들어보셨을 수도 있습니다. 바로 EOF(EVM Object Format)입니다. 이는 푸사카(Fusaka) 하드 포크(펙트라와 푸사카 둘 다였던 것 같습니다)에 포함될 예정이었던 기능 세트였지만, 결국 분리되었습니다. 이 기능이 해당 포크에서 제외된 여러 계기 중 하나는 비탈릭(Vitalik)이 이더리움의 RISC-V 도입 가능성에 대한 글을 올렸기 때문입니다. 그 글을 읽은 많은 사람들은 '좋아, 우리가 RISC-V를 도입한다면 EOF에서 고려 중인 기능들이 RISC-V에 기본으로 제공되겠네. 그렇다면 왜 프로토콜에 이런 복잡성을 추가해야 하지? 왜 이 모든 클라이언트 개발자 자원을 여기에 투입해야 할까? 결국 RISC-V로 넘어가게 된다면 무의미해질 텐데'라고 생각했습니다.

그것이 EOF에 대한 결정적인 타격이 되었고, 결국 포크에서 제외되었습니다. 그들이 고려해야 할 또 다른 사항은 클라이언트들이 6개의 다른 언어로 작성되어 있기 때문에, 6개의 다른 언어로 작성되고 엄격하게 테스트되어야 한다는 점입니다. 이는 그들이 다뤄야 할 매우 큰 테스트 매트릭스입니다. 이 때문에 아주 작은 설계 선택조차도 논쟁의 대상이 되며, 의견 불일치를 해결할 권위자도 없습니다. 그래서 '누가 결정하는가'라는 질문이 제기되며, 이것이 바로 거버넌스의 핵심입니다.

오해 (5:23)

이제 오해에 대해 이야기해 보겠습니다. 몇 가지를 다뤄보죠. 첫 번째는 비탈릭이 이더리움 프로토콜에 들어갈 내용을 결정한다는 것입니다. 그 연장선상에서 이더리움 재단(EF)이 모든 것을 통제한다는 오해도 있습니다. 세 번째는 모든 것이 밀실 거래, 즉 내부자나 고인물(OG)들이 이런 결정을 내린다는 것입니다.

첫 번째, 비탈릭이 결정한다는 오해입니다. 저는 비탈릭이 작성했지만 정체되어 있는 EIP(이더리움 개선 제안)의 일부를 골라봤습니다. 이것이 의미하는 바는 비탈릭이 자리에 앉아 제안을 작성하고 '이것들이 이더리움에 들어갔으면 좋겠다'고 말했지만 아무도 동의하지 않았다는 것입니다. 이 제안들은 그냥 방치되어 있습니다. 그는 이것들을 프로토콜에 포함시키지 못했습니다. 따라서 그가 제안하는 모든 것이 자동으로 포함되는 것은 아닙니다.

그 연장선상에 있는 오해는 이더리움 재단이 모든 것을 통제한다는 것입니다. 저는 이에 모순된다고 생각하는 구체적인 사례를 하나 들겠습니다. 2024년에는 가스 한도에 대한 논의가 많았습니다. 그 이유는 2022년 머지(The Merge) 기간 동안 가스 한도를 3천만으로 올렸기 때문입니다. 이는 블록에서 허용되는 최대 연산량입니다. 그 후 한동안 건드리지 않았는데, 사람들이 "이것 때문에 이더리움으로 넘어가지 않겠다"거나 "이것이 내 현재 이더리움 사용 사례를 제약하고 있다"고 말할 만한 병목 현상이 아니었기 때문입니다.

그러다 2023년 말, 2024년 초에 솔라나가 부상하고 있다는 이야기가 돌았습니다. 이더리움의 파이를 빼앗아 갈 것이라는 이야기였죠. 그래서 사람들은 이더리움이 속도를 내기 위해 무엇을 할 수 있을지 고민했습니다. 그중 하나가 이 가스 지표를 올리자는 것이었습니다. 당시 이더리움 재단과 클라이언트 개발자들은 "우리는 신경 써야 할 다른 것들이 많습니다. 제안은 고맙습니다."라는 반응이었습니다. 하지만 에릭 코너(Eric Connor)와 마리아노 콘티(Mariano Conti)라는 두 사람이 나서서 "아닙니다, 우리는 가스 한도를 올릴 것입니다."라고 말했습니다. 가스 한도는 검증자가 제어하는 매개변수입니다. 그래서 그들은 검증자들, 전문 운영자들에게 다가가 "가스 한도를 올리세요."라고 말하기 시작했습니다.

그리고 어느 시점에 이르러 이더리움 재단과 클라이언트들이 "아, 이거 신경 써야겠네. 이들이 하는 일이 안전한지, 그리고 최종적으로 올리려는 수치가 네트워크에 안전한지 확인해야겠다."라고 할 만큼 충분한 채택이 이루어졌습니다. 그래서 그들은 자원을 재할당해야 했습니다. 네더마인드(Nethermind)는 이 테스트 프레임워크를 고안해 냈습니다. 이더리움 재단은 베를린에서 많은 작업을 수행했습니다. 모든 클라이언트 개발자들이 이를 벤치마킹하고 있었습니다. 저는 이 사례를 좋아하는데, 이더리움 재단이 우선순위를 결정하도록 강제했기 때문입니다.

그리고 제가 여기에 스크린샷으로 찍어둔 이 어리석은 트윗을 좋아합니다. 어떤 무명 뉴스 매체가 에릭 코너와 마리아노 콘티를 코어 개발자라고 불렀기 때문입니다. 그들은 코어 개발자가 아닙니다. 에릭 코너는 스테이커이자 커뮤니티 회원이었습니다. 마리아노 콘티는 전 메이커다오(MakerDAO) 앱 개발자였습니다. 하지만 이더리움 개발은 전통적인 소프트웨어가 작동하는 방식과는 완전히 다르기 때문에, 핵심 매개변수가 수정되는 것을 보고 "아, 이 사람들은 코어 개발자임에 틀림없어."라고 생각해서 코어 개발자라고 불린 것입니다. 그들은 아니었습니다. 이것은 커뮤니티 구성원들이 나서서 변화를 원한다고 말하고 이를 실현시킨 하나의 예일 뿐입니다.

모든 것이 밀실 거래, 내부자, 고인물(OG)들에 의해 이루어진다는 오해에 대해서는 왜 그런 오해가 생기는지 조금은 이해합니다. 기본적으로 이런 거버넌스 회의에 참석해 보면, 회의에 100명 정도의 사람들이 있습니다. 그들은 모두 진행 상황에 대해 매우 편안해 보입니다. 여러분은 길을 잃은 기분일 것입니다. 이런 결정들이 어떻게 내려지는지 전혀 알 수 없습니다. "아직 내 발언 차례가 안 왔나?"라고 생각하게 되죠. 그리고 사람들이 결정을 내리기 위해 항상 같은 10명의 이야기만 듣는 것처럼 느껴집니다.

능력주의와 참여 통계 (10:18)

하지만 사실 이더리움 개발은 제가 대부분의 소프트웨어 개발에서 본 것보다 훨씬 더 능력주의에 가깝습니다. 이 스크린샷에 있는 모든 사람들(제가 무작위로 스크린샷을 찍기로 한 ACD 회의의 세 장 중 하나입니다) 중 누구도 이 자리에 임명된 사람이 아닙니다. 모두가 그냥 자발적으로 참석한 사람들입니다. 이들은 이 프로토콜에 많은 시간을 할애한 개발자들입니다. 이들은 이 분야에서 재능 있는 개발자로 인정받으며 지속적으로 좋은 결정을 내리는 사람들이며, 이들 중 누구도 이 자리에 임명되지 않았습니다.

저는 이더리움 재단에 합류한 지 1년이 조금 넘었습니다. 이 통계 자료를 가져왔는데요. 2025년 3월까지만 거슬러 올라갑니다. 1년도 채 되지 않은 기간이죠. 모든 코어 개발자(All Core Dev) 회의, 즉 거버넌스 회의의 평균 참석자 수는 98명입니다. 평균적으로 98명이 이 회의에 참석한다는 뜻입니다. 그 이후 한 회의의 최대 참석자 수는 153명이었습니다. 제 기억으로는 펙트라 메인넷 날짜를 결정하던 날이었던 것 같습니다. 그리고 작년 한 해 동안의 총 순 참석자 수는 567명입니다. 저는 이 지표를 정말 좋아하는데, 매번 같은 100명이 이 회의에 참석하는 것이 아니라는 것을 보여주기 때문입니다. 앱 개발자, 연구원, 혹은 논의 중인 어떤 기능에 대해 들은 누군가가 나타나 반대나 지지 의견을 표명하고, 그 다음 회의에는 오지 않기도 합니다.

거버넌스 프로세스 작동 방식 (11:52)

이 슬라이드는 다소 지루할 수 있지만 짚고 넘어가는 것이 중요하다고 생각합니다. 이것이 현재 이더리움의 거버넌스가 작동하는 방식입니다. 이러한 포크 중 하나가 논의될 때 가장 먼저 일어나는 일은, 할당된 시간 동안 사람들이 헤드라이너 제안(headliner proposal)을 제출할 수 있다는 것입니다. 헤드라이너 제안은 이번 포크를 위해 사람들이 결집하기를 바라는 주요 기능입니다. 커뮤니티 회원, 연구원, 코어 개발자 등 누구라도 이 헤드라이너 제안을 제출할 수 있습니다. 그런 다음 제출 기간이 끝나고 거버넌스 회의에서 이 중 어떤 것이 타당한지 논의합니다. 사람들은 자신의 주장을 펼치고, 논쟁을 벌이며, 다가오는 포크를 위해 어떤 것을 선택해야 할지에 대한 합의가 이루어집니다.

그 후에는 마이너 기능들을 선택합니다. 포크를 주도하는 주요 기능일 필요는 없는 더 작은 것들입니다. 그리고 이 기간 내내 기능별 데브넷(devnet)을 운영합니다. 데브넷은 테스트넷과 같습니다. 개발자들이 이러한 기능들을 테스트하고 이더리움에서 실제로 작동하는지 확인하기 위한 비공개 테스트 네트워크입니다. 그리고 어느 시점이 되면 기능 동결(feature freeze)이 이루어집니다. 주요 기능을 논의했고, 마이너 기능을 논의했으며, 주로 포크 헤드라이너인 기능별 데브넷을 실행했습니다. 그리고 별표(*)가 붙은 기능 동결 상태가 됩니다. 그 시점에서는 이 포크에 더 이상 기능을 추가하지 않기로 결정했기 때문입니다. 모든 기능을 함께 실행하고, 모든 것이 양호한지, 망가지는 것은 없는지 확인할 것입니다. 하지만 무언가가 진행을 늦추기 시작하거나, 포크가 지연되거나, 너무 복잡하다면 그 시점에서도 기능이 제외될 수 있습니다.

그래서 여러 번의 데브넷(2번일 수도 있고 10번일 수도 있습니다)을 거친 후, 어느 시점에 모든 클라이언트가 이것이 안정적이라고 결정합니다. '우리는 지금 진행 상황을 신뢰한다. 좋은 상태다. 이것을 이더리움 메인넷에 출시할 생각을 시작하자'라고 말이죠. 그들은 클라이언트 릴리스를 확정하고, 이더리움 재단 보안 팀이 버그 바운티를 게시하는 30일의 기간을 갖습니다. 그들은 보안 감사를 계약합니다. 그리고 그 30일의 기간이 끝나면 테스트넷에 포크를 출시합니다. 홀스카이(Holesky)처럼 여러분이 들어보셨을 법한 테스트넷들입니다. 이곳은 포크가 라이브로 전환되기 전에 앱 개발자들이 자신의 작업물을 테스트할 수 있는 곳입니다. 모든 것이 괜찮은지 확인하기 위해 일반적으로 각각 최소 14일 동안 진행됩니다. 이전에 기능별 데브넷과 일반화된 데브넷을 거쳤기 때문에 큰 문제는 예상하지 않지만, 역사적으로 이러한 테스트넷 중 일부를 망가뜨린 적이 있습니다. 따라서 이것은 모든 버그를 찾아내고 해결하기 위한 마지막 단계라고 할 수 있습니다.

그런 다음 무허가성 테스트넷이 안정화되면 메인넷 날짜가 선택됩니다. 그 후 30일의 버퍼 기간이 있습니다. 이 30일의 버퍼는 L2와 프로토콜들이 포크를 준비하기 위해 요청했기 때문에 존재합니다. 따라서 최소 30일이 지나면 포크가 발생합니다.

회의 구조 및 조정 (15:01)

이 전체 기간 동안 몇 가지 주요 회의 시리즈가 진행됩니다. 이들은 모두 유튜브에서 실시간 스트리밍되는 공개 회의입니다. 주요 회의는 ACDE와 ACDC입니다. E는 실행 계층(execution layer)을 의미하며, 트랜잭션, 스마트 컨트랙트 배포, 멤풀 관리 같은 것들을 다룹니다. ACDC는 합의 레이어(consensus layer)를 의미하며, 검증자 관리, 슬래싱 같은 검증자 관련 사항을 다룹니다. 이 회의들은 목요일마다 번갈아 가며 열립니다. 매주 목요일마다 ACD가 열리는데, 한 주는 ACDE, 다음 주는 ACDC가 열리는 식으로 계속됩니다.

ACDE와 ACDC 회의는 현재 진행 중인 포크와 미래를 위해 계획 중인 포크에 중점을 둡니다. ACDT 회의는 훨씬 더 세부적이고 복잡한 내용을 다룹니다. 클라이언트들이 해결하지 못하는 버그나 현재 작업 중인 포크에 대해 해결해야 할 구현 세부 사항에 대해 이야기합니다. 현재 예정된 다음 포크는 글램스테르담(Glamsterdam)입니다. 따라서 이 ACDT 회의는 글램스테르담에 포함될 ePBS와 블록 수준 액세스 목록에 대한 대화가 주를 이룹니다. 이들은 매우 기술적인 회의입니다.

그리고 브레이크아웃(breakout) 회의가 있습니다. 브레이크아웃 회의는 커뮤니티 회원, 연구원, 개발자들이 "저기요, 두 번 뒤의 포크에서 이더리움에 넣고 싶은 기능이 있습니다."라고 말하는 자리입니다. 그래서 그들은 매주, 매월 또는 격월로 회의를 주최하여 구현 세부 사항을 논의하고, 사양을 변경 및 반복하며, 사람들이 가진 모든 질문과 알려진 미지수들을 전반적으로 다루어 두 번 뒤의 포크에 포함될 수 있는 최상의 상태를 만듭니다. 이러한 회의는 진행자가 결정할 때마다 일정을 잡을 수 있습니다.

진화하는 프로세스 (15:29)

제가 여러분 모두에게 강조하고 싶은 한 가지는 이 프로세스가 결코 정적이지 않다는 것입니다. 방금 설명해 드린 이 프로세스는 도입된 지 1년도 채 되지 않았습니다. 이더리움은 10년 동안 운영되어 왔습니다. 하지만 끊임없이 변화하며, 끊임없이 변화하는 이유는 아무도 책임자가 아니기 때문입니다. 그리고 이 프로세스는 가장 효율적으로 운영할 방법을 찾기 위해 진화합니다. 제가 효율적이라고 말하긴 했지만, 이더리움 거버넌스의 평판은 정말 정체되어 있고, 무언가를 통과시키기 어렵고, 혼란스럽다는 것입니다. 100명에서 500명의 사람들이 결정을 내리는 상황에서 이것이 작동한다는 것 자체가 솔직히 놀랍습니다.

그래서 팀(Tim)은 2025년 4월에 "모든 코어 개발자 재구성(Reconfiguring All Core Devs)"이라는 글을 올렸고, 이것이 결국 현재 작동 방식에 대한 제안이 되었습니다. 그 이유는 그 이전에는 이더리움에서 무엇에 집중해야 하는지에 대한 응집력 있는 내러티브가 있었기 때문입니다. 엄청난 작업이었던 머지가 있었습니다. 모두가 매우 흥분했습니다. 대부분의 사람들이 매우 흥분했죠. 채굴자들은 아니었지만요. 그리고 머지 이후에는 인출(withdrawals)이 있었습니다. 우리는 사람들의 ETH가 컨트랙트에 묶여서 영영 ETH를 꺼내지 못할 것이라는 FUD(공포, 불확실성, 의심)가 퍼지는 것을 원하지 않았습니다. 그래서 우리는 그것을 가능한 한 빨리 출시해야 했습니다. 그 다음에는 프로토 댕크샤딩이 있었고, 그 다음 펙트라가 왔는데 펙트라는 서로 관련 없는 다양한 EIP들의 혼합체 같았고 응집력 있는 내러티브가 없었습니다. 응집력이 부족하다 보니 사람들이 그냥 이것저것 밀어 넣어서 규모가 너무 커졌고, 테스트 팀들이 "범위가 너무 넓다. 이 모든 것을 테스트할 수는 없다."라고 해서 결국 두 개의 다른 포크로 분리되어야 했습니다.

그래서 팀이 이 일을 추진하게 된 계기는 '좋아, 이 포크들을 가능한 한 집중적이고 응집력 있게 유지할 방법을 생각해야겠다'는 것이었습니다. 그리고 헤드라이너가 그에 대한 일종의 해답이었습니다. 그 목적은 모두가 포크의 목적이 무엇인지 알고 있다고 느끼게 만드는 것을 우선시하는 방식으로 출시하여, 25개의 서로 다른 EIP를 억지로 밀어 넣을 필요가 없게 만드는 것이었습니다.

상단에 있는 다른 스크린샷은 팀이 이러한 EIP의 포함 단계에 대한 정의를 제안하는 모습입니다. 제가 여기서 강조하고 싶은 점은, 가끔 이 프로세스가 너무 관료적이라고 말하는 사람들의 이야기를 듣게 된다는 것입니다. 하지만 실제로 일어나는 일은, 사람들이 이 거버넌스 프로세스에 들어와서 "EIP를 어떻게 포함시키나요?"라고 물으면 10년 동안 그곳에 있었던 사람들은 "그냥 하면 됩니다."라고 대답하는 식입니다. 그러면 사람들은 "이건 끔찍하네요."라고 반응하죠. 그래서 이러한 정의들이 하는 역할은 외부인이 이 프로세스에 더 쉽게 참여할 수 있도록 진행 상황을 설명하는 것입니다. 만약 여러분이 이곳에 와서 "나는 EIP가 하나 있고, 이더리움 거버넌스에는 관심 없고, 그냥 이 EIP 하나만 포함시키고 싶다"고 한다면, 여러분은 루브릭(평가 기준)을 원하고, 체크리스트를 원하며, 이 EIP를 포함시키는 방법에 대한 매우 명확한 단계별 지침을 원할 것입니다. 따라서 이러한 것들의 대부분은 EIP를 포함시키기 어렵게 만들기 위해 사람들이 따라야 할 관료적인 규칙을 만드는 것이 아니라, 프로세스가 어떻게 작동하는지 설명하는 것에 가깝습니다.

세 번째는 포크캐스트(Forkcast)의 시간 경과에 따른 커밋입니다. 포크캐스트는 제 팀의 제품으로, 현재 형태의 팀이 구성되었던 작년 중반에 제 팀의 울프람 마크(Wolfram Mark)가 만들었습니다. 그리고 이것은 사람들이 포크와 상호 작용하고, 포크에 무엇이 포함되는지, 그리고 그것이 자신에게 어떤 영향을 미치는지 확인하는 데 사용하는 매우 표준적인 리소스가 되었습니다. 이 모든 것들은 만들어진 지 2년도 채 되지 않았습니다. 제가 말씀드리고 싶은 요점은 이 프로세스가 많이 변한다는 것입니다. 전혀 정적이지 않습니다. 발을 들여놓기 힘든 굳어버린 관료주의가 아닙니다.

비교 가능한 거버넌스 시스템 (20:21)

이더리움 거버넌스와 가장 유사하다고 생각되는 탈중앙화된 거버넌스 시스템에 대해 간단히 짚고 넘어가고 싶습니다. 제가 여기서 말씀드리고자 하는 바는 이것이 지속 가능하다는 것입니다. 100명에서 500명의 사람들이 결정을 내릴 수 있다는 것이 놀랍긴 하지만, 현실 세계에서 지속 가능합니다. 우리는 이것이 작동하는 사례들을 실제로 보고 있습니다.

IETF는 국제 인터넷 표준화 기구(Internet Engineering Task Force)입니다. TCP/IP, HTTP를 만든 자원봉사자 운영 표준 기관입니다. 오늘날 우리가 무료 인터넷을 사용할 수 있게 된 데 가장 큰 책임이 있는 조직입니다. 리눅스 커널(Linux kernel)은 리눅스 운영 체제의 핵심입니다. 인터넷 서버, 안드로이드 폰, 슈퍼컴퓨터를 구동하는 오픈 소스 소프트웨어입니다. 차이점이 있다면 리누스 토발즈(Linus Torvalds)라는 자비로운 독재자 모델을 가지고 있다는 것입니다. 하지만 그럼에도 불구하고 17,000명이 넘는 기여자가 있다는 것은 정말 놀라운 일입니다.

이와 유사하지 않은 것들로는 온체인 토큰 투표를 하는 다른 블록체인들이 있습니다. 이더리움은 어떠한 형태의 투표 메커니즘도 특별히 피하고 있습니다. 제 생각에 투표는 장악될 수 있는 길을 열어주고, 사람들이 최고의 코드를 작성하는 사람을 신뢰하는 능력주의를 만들려는 동기를 없애버리기 때문입니다. 그리고 L2들이 있습니다. 그들은 다중 서명(multi-sigs)을 가지고 있습니다. 보안 위원회도 있습니다. 이들은 이러한 결정을 내리는 임명직에 가깝습니다. 그리고 거기에는 장단점이 있습니다. 더 중앙집중화되어 있지만, 더 빠르게 움직입니다.

빌더들이 관심을 가지는 이유 (22:38)

그렇다면 빌더들은 왜 거버넌스에 관심을 가질까요? 빌더들이야말로 이더리움이 만들어진 문자 그대로의 대상이기 때문입니다. 이더리움은 코어 개발자를 위해 만들어진 것이 아닙니다. 검증자를 위해 만들어진 것도 아닙니다. 가끔 이 사람들이 그 점에 대해 혼동하곤 합니다. 이더리움 코어 개발자와 검증자는 이더리움에 봉사하고, 이더리움은 빌더와 사용자에게 봉사합니다.

AI를 사용할 때 너무 세부적인 것에 빠져서 작은 것을 고치려다 프로젝트의 전체 목적을 넓게 보지 못하는 순간을 누구나 경험해 보셨을 것입니다. 코어 개발자들도 코어 개발 프로세스를 완벽하게 만들려다 보면 그럴 수 있습니다. 그런 경우 빌더들이 참여하는 것이 매우 중요합니다. 코어 개발은 너무 많은 에너지를 소모하기 때문에 대부분의 경우 그들은 이더리움 위에서 무언가를 구축하지 못합니다. 그들은 코어 개발에 매우 깊이 관여하고 있습니다. 그것이 그들의 모든 시간을 차지합니다. 그래서 앱 빌더들은 정말 노력해서 참여하여 "저기요, 우리는 이것이 필요합니다. 이것은 이더리움에 매우 중요합니다."라고 말해야 합니다. 관점이 존재하도록 하고, 그들이 단지 코어 개발자들만을 위해 일하는 틀에 갇히지 않도록 확실히 해야 합니다.

참여 방법 (24:40)

그렇다면 어떻게 참여하거나 여러분의 기능을 포함시킬 수 있을까요? 다소 일반적인 조언이지만, 이것이 최선이라고 생각합니다. 여러분의 불편한 점(pain points)에 대해 목소리를 높이세요. 트위터에 글을 올리고, 블로그 게시물을 작성하고, 불편한 점에 대한 해결책을 찾으세요. 여러분에게 도움이 될 수 있는 것들에 대해 추측해 보세요. 같은 불편함을 겪는 다른 사람들을 찾는다면, 일반적으로 그 불편함을 해결하기 위해 존재하는 EIP를 찾거나 누군가의 도움을 받아 그런 역할을 하는 EIP를 작성할 수 있습니다.

제가 오픈 소스 소프트웨어에 대해 좋아하는 점 중 하나는 일반적으로 자본이 풍부한 회사들이 자신들이 사용하는 오픈 소스 도구를 유지 관리하는 데 개발 시간과 자원을 할당한다는 것입니다. 결국 여러 다른 회사들이 협력하여 이것을 유지 관리하게 되며, 이더리움에서도 그런 방식으로 작동할 수 있습니다. 따라서 여러분이 파악한 불편한 점이 있다면, 비슷한 불편함을 겪는 베이스(Base) 개발자를 찾을 수 있습니다. 베이스는 자본이 풍부한 조직이므로 이더리움 하드 포크를 통해 기능을 출시하거나 관리하는 데 기꺼이 자원을 할당할 것입니다.

몇 가지 리소스를 남겨드리겠습니다. Forkcast.org — 이곳에 가면 포크에 무엇이 포함되는지, 특정 이해관계자에게 어떤 영향을 미치는지 확인할 수 있습니다. 앱 개발자라면 앱 개발자를 위한 섹션이 있습니다. 지갑 개발자나 합의 레이어 클라이언트 개발자라면, 그 모든 것이 여러분에게 어떤 영향을 미치는지에 대한 섹션이 있습니다. 유튜브에는 모든 회의 영상이 업로드됩니다. 이 영상들은 forkcast.org/calls 페이지에도 임베드되어 있으며, 요약과 발언자 정보가 있어 회의 내용을 더 쉽게 파악할 수 있습니다. EIP 디렉토리, 잠재적인 해결책이나 작성하고 싶은 EIP에 대해 다른 사람들과 이야기할 수 있는 이더리움 매지션스(Ethereum Magicians) 포럼도 있습니다. 그리고 아주 곧 저희 팀의 프로토콜 지원 사이트가 열릴 예정입니다. 정말 멋지지만 아직 공유할 준비는 안 되었습니다. 제 이메일 주소도 있습니다 — nixo@ethereum.org (opens email client). 이상입니다.