릴리스 공지는 버전 번호, 대상 네트워크, breaking change, 필수 업그레이드 높이와 보안 수정 범위를 읽어야 한다. latest 태그만 보고 바이너리를 바꾸면 사전 마이그레이션이나 구성 변경을 놓칠 수 있다. 따라서 서명·체크섬, 공식 저장소, 지원 OS와 롤백 가능성을 점검한다.
릴리스의 신원은 tag 하나보다 넓다
클라이언트 릴리스는 버전 tag, 연결된 commit, 게시자, release note와 플랫폼별 binary asset의 묶음이다. 저장소 이름이 비슷하거나 파일명이 같아도 공식 조직·commit·서명이 다르면 같은 릴리스로 보지 않는다.
latest 표시는 저장소의 최신 게시 릴리스를 가리킬 뿐 내 mainnet·testnet 노드에 즉시 필요한 버전이라는 의미가 아니다. network activation과 보안 권고, 지원 운영체제를 함께 읽는다.
latest 배지는 배포 우선순위를 결정하지 않는다. 내 네트워크의 활성화 조건과 변경 범위가 결정한다.
JOBCOIN 해설
필수 시각·호환성·마이그레이션을 먼저 찾는다
fork가 block height나 UTC timestamp에 활성화된다면 그 전에 호환 버전으로 올라가야 한다. release note가 testnet만 지목했는지 mainnet도 포함하는지 구분하고 실행·합의 클라이언트 양쪽의 호환 표를 확인한다.
제거된 flag, 바뀐 기본값, 데이터베이스 migration은 재시작 실패와 rollback 가능성을 좌우한다. 성능 개선 목록보다 운영 전제와 breaking change를 먼저 추출해 변경표를 만든다.
v1.2.3이라는 숫자만으로 알 수 없는 것
교육용 가정으로 v1.2.3 노트에 testnet fork 시각 T, 설정키 rename, 데이터베이스 migration이 적혀 있다면 운영자는 버전 숫자보다 T 이전 설치 여부와 migration rollback 가능성을 먼저 판단한다. patch처럼 보이는 세 번째 자리도 프로젝트가 엄격한 semantic versioning을 보장하지 않으면 breaking change가 없다는 뜻이 아니다.
GitHub release의 tag, release commit, assets와 프로젝트 공식 다운로드 페이지의 build를 맞춘다. 소스 tag가 맞아도 다른 commit으로 빌드된 비공식 바이너리는 같은 산출물이 아니다. 파일명, OS, architecture, SHA-256 또는 PGP signature를 배포 기록에 남긴다.
| 항목 | 확인 질문 | 놓치면 생기는 문제 |
|---|---|---|
| 네트워크·fork 조건 | mainnet·testnet 중 어디, height·timestamp는 언제인가 | 엉뚱한 체인에 긴급 배포 |
| 호환성 | 실행·합의 client와 Engine API 요구는 무엇인가 | 페어는 실행되지만 블록 추적 실패 |
| 데이터·설정 변경 | DB migration·flag 제거·기본값 변경이 있는가 | 재시작 실패·성능 변화 |
| 산출물 검증 | tag·commit·서명·플랫폼이 일치하는가 | 다른 빌드 또는 손상 파일 설치 |
실행 클라이언트와 합의 클라이언트를 한 쌍으로 본다
이더리움 노드는 실행 클라이언트와 합의 클라이언트가 Engine API로 연결된다. Geth만 업데이트했거나 Lighthouse만 업데이트했을 때도 상대 버전의 지원 범위를 확인해야 한다. 한쪽의 새 method나 fork 규칙을 다른 쪽이 이해하지 못하면 노드가 프로세스 수준에서는 살아 있어도 head를 따라가지 못할 수 있다.
릴리스 노트의 recommended for all users, mandatory, security, testnet only 같은 표현을 구분한다. 보안 수정이 구체적으로 공개되지 않았다고 영향이 없다는 뜻은 아니며, 운영 공지·보안 채널과 공식 저장소만 근거로 삼는다.
- 현재 binary version과 commit을 먼저 캡처한다
- release tag·commit·게시자를 공식 저장소에서 확인한다
- 대상 chain과 fork height·timestamp를 UTC로 기록한다
- config·flag·DB migration과 disk 여유를 점검한다
- 바이너리 서명 검증 후 canary·rollback 절차를 준비한다
체크섬과 서명이 증명하는 범위
체크섬 일치는 내려받은 파일이 게시된 checksum 대상과 동일함을 보여 주지만 게시자 신원까지 단독으로 증명하지 않는다. Geth 다운로드 페이지는 MD5를 전송 오류 확인용으로 설명하고 보안 보증에는 첨부 PGP signature 검증을 안내한다. 서명키의 공식 배포 경로도 확인해야 한다.
GitHub의 verified commit 표시는 해당 commit 서명 검증 정보다. 별도 release asset 바이너리의 내용까지 자동으로 보증하지 않는다. container image라면 immutable digest를 기록하고 mutable latest tag만 배포 manifest에 남기지 않는다.
업그레이드 전후 검증 체크포인트
업그레이드 전 chain head, finalized height, peer count, sync 상태, DB 경로와 설정 파일 hash를 저장한다. canary 한 대에서 새 바이너리를 시작해 로그의 schema migration, Engine API 연결과 head 증가를 확인한 뒤 확대한다.
문제가 생기면 이전 binary로 되돌릴 수 있어도 DB migration이 비가역이면 단순 rollback이 실패한다. 릴리스 노트의 downgrade 지원 여부와 백업 복구 절차를 사전에 시험한다. 실제 운영 배포는 별도 승인과 백업이 필요한 작업이다.
공식 Geth·Lighthouse release 페이지는 버전별 변경과 산출물의 출처다. release note를 읽었다는 사실만으로 내 노드의 성공적 업그레이드나 네트워크 정상 동작을 증명하지 않는다.
자주 묻는 질문
GitHub의 latest 릴리스면 바로 설치해야 하나요?
아니다. 대상 네트워크, 필수 fork 시각, 보안 권고와 내 현재 버전의 지원 범위를 확인해 우선순위를 정한다.
commit이 Verified면 binary도 검증된 건가요?
commit 서명과 release asset 검증은 별개다. 공식 다운로드의 PGP signature·checksum 또는 container digest를 따로 확인한다.
이전 binary만 보관하면 항상 롤백할 수 있나요?
DB schema migration이나 설정 변경이 비가역일 수 있다. downgrade 지원 여부와 데이터 백업 복구를 사전에 검증해야 한다.
