코인·네트워크 변화 | 2026년 10월 21일 UTC 활성화 발표
발표문에 더해 실제 응답으로 확인한 변화
알펜글로우는 이제 적용 예정인 업그레이드가 아닙니다. 다만 전환이 끝났다는 사실과 모든 서비스가 일정한 속도로 작동한다는 주장은 구분해야 합니다. 이번에는 전환 기준 블록을 공개 RPC로 확인하고, 이용자가 접하는 확정 상태와 통계를 어떻게 읽어야 하는지 살펴봅니다.
적용 대기에서 실제 메인넷 운영으로 바뀌었다
개발사 Anza는 10월 21일 공식 배포자료에서 슬롯 459,653,000부터 Solana mainnet-beta가 Alpenglow로 전환됐다고 발표했습니다. 시각은 약 14:00 UTC로 안내했습니다. 기존 합의 방식 TowerBFT를 실제 운영 네트워크에서 교체했다는 발표입니다. [Anza 발표]
Solana 공식 업그레이드 페이지도 상태를 ‘Live on Mainnet’으로 바꿨습니다. 첫 단계 Votor가 epoch 1064에서 가동됐으며, 해당 epoch는 10월 21일 약 13:36 UTC에 시작했다고 설명합니다. [공식 활성화 상태]
기존 알펜글로우 설명 글은 10월 초 메인넷 적용을 기다리던 시점을 다뤘습니다. 이번 글의 새로운 사실은 설계 목표를 다시 소개하는 것이 아니라 실제 전환 완료를 확인했다는 점입니다. 아래에서는 예정일, 소프트웨어 버전, 전환 인증서를 서로 다른 증거로 구분합니다.
두 시각이 다르게 보이는 이유도 살펴볼 필요가 있습니다. epoch가 시작돼 기능을 활성화하는 단계와 새 합의가 실제로 블록을 이어받는 단계 사이에는 전환 과정이 있습니다. 따라서 ‘epoch 시작 시각’만 떼어 전체 전환 완료 시각으로 쓰면 과정의 순서를 놓치게 됩니다.
공개 RPC 응답과 슬롯 계산이 일치했다
공식 RPC 문서는 getAgGenesisCert가 전환 인증서를 반환하며, 아직 TowerBFT를 사용하는 경우에는 null을 반환한다고 안내합니다. 구버전 노드의 ‘지원하지 않는 메서드’ 오류는 null과 다른 결과입니다. 날짜가 지났거나 새 버전이 설치됐다는 사실만으로 전환 여부를 판단하는 대신 이 응답을 확인할 수 있습니다. [조회 방법의 의미]
이 글에서는 2026년 10월 21일 20:49 UTC, 공식 공개 메인넷 RPC에 읽기 전용 조회를 실행했습니다. 지갑을 연결하거나 거래를 전송하지 않았습니다. 응답에는 비어 있지 않은 인증서가 있었고, 그 인증서가 가리키는 블록 슬롯은 459,652,999였습니다. 같은 조회 묶음의 주요 결과는 다음과 같습니다.
| 조회 항목 | 확인한 값 | 읽는 방법 |
|---|---|---|
| 전환 인증서 | 존재 · 블록 슬롯 459,652,999 | 전환 기준 블록 확인 |
| 현재 epoch | 1064 | 공식 활성화 epoch와 일치 |
| 현재 절대 슬롯 / epoch 내 위치 | 459,770,098 / 122,098 | 두 값의 차이는 459,648,000 |
| epoch 길이 / 응답 노드 버전 | 432,000슬롯 / 4.3.2 | 일정 계산과 조회 환경 확인 |
전환 설계 문서 SIMD-0384는 기능 활성화 슬롯에 5,000을 더해 전환 경계를 정하고, 마지막 TowerBFT 블록을 새 합의의 출발점으로 삼는 구조를 설명합니다. [전환 설계]
459,770,098 − 122,098 = epoch 시작 슬롯 459,648,000
459,648,000 + 5,000 = 전환 경계 슬롯 459,653,000
인증서의 기준 슬롯 459,652,999 + 1도 같은 값입니다.
또한 1064 × 432,000도 같은 epoch 시작 슬롯이 됩니다. 이번 조회에서는 기준 블록에 1을 더한 값이 공식 발표의 전환 슬롯과 일치합니다. 이 숫자 대조가 첫 Alpenglow 블록을 별도로 검증한 것은 아닙니다.
확인 범위는 제한적입니다. 위 결과는 한 공개 RPC 경로에서 얻은 시점별 응답입니다. 여러 독립 노드를 비교하거나 인증서 서명을 별도로 암호학적으로 검증한 것은 아닙니다. 전환 발표와 응답의 일치 여부를 대조한 것이며, 장기 안정성이나 확정 속도를 측정한 시험 결과는 아닙니다.
confirmed와 finalized를 읽는 기준이 달라졌다
Anza의 확정 상태 문서는 Alpenglow에서 confirmed와 finalized가 같은 확정 상태를 나타낸다고 설명합니다. 반면 processed는 블록에 거래가 포함돼 처리된 상태이며, 영구 원장에 확정됐다는 보장은 구분됩니다. 기존 TowerBFT의 표와 Alpenglow의 표를 따로 제시하는 이유입니다. [확정 상태 문서]
이 변화는 앱 화면의 ‘처리 중’, ‘확인됨’, ‘완료’ 같은 표현을 볼 때 중요합니다. 서비스가 자체적으로 붙인 한국어 문구만으로 어떤 네트워크 상태를 기준으로 삼았는지 알 수는 없습니다. 거래가 보인 시점, 합의로 확정된 시점, 서비스가 이용 가능 잔액에 반영한 시점을 구분해야 합니다.
예를 들어 거래소 입금 화면이 늦게 갱신됐다고 가정해 보겠습니다. 원장 확정이 늦었는지, 조회 서버가 뒤늦게 상태를 받았는지, 거래소 내부 반영에 시간이 걸렸는지는 별도 확인 대상입니다. 화면의 대기 시간 하나만으로 합의 업그레이드의 성능을 판정하기 어렵습니다. 반대로 화면에 먼저 표시됐다는 이유로 모든 후속 절차가 끝났다고 판단해서도 안 됩니다.
확정 시간과 화면의 대기시간을 나눠 보자
Anza 발표는 약 150ms의 확정을 설명하지만, 이는 개발사가 제시한 합의 계층의 성능 설명입니다. 이 글의 RPC 확인으로 그 속도를 독립 실측했다고 볼 수는 없습니다. [개발사 성능 설명]
Anza의 운영 문서는 정상적인 네트워크 조건에서 약 150ms를 목표로 하며, 합의에 직접 참여하지 않는 노드는 확정 정보를 나중에 받을 수 있다고 설명합니다. 이후 블록에 실린 인증서를 통해 정보를 얻는 경로는 블록 간격만큼 추가 지연이 생길 수 있고, 블록이 건너뛰거나 늦어지면 더 길어질 수 있습니다. [확정 정보 전달 경로]
따라서 블록이 합의로 확정되는 시간과 사용자가 서명을 누른 뒤 결과를 보는 시간은 측정의 시작점과 끝점부터 다릅니다. 전송 경로, 블록 포함까지의 대기, 정보 전달, 서비스의 표시 과정을 한 숫자로 압축하면 서로 다른 성능을 비교하게 됩니다. 거래 체결 가격이나 원하는 주문이 성사되는지 역시 확정 시간만으로 설명할 수 없습니다.
앞으로 실제 성능 자료를 읽을 때는 평균이나 중앙값뿐 아니라 느린 구간도 함께 봐야 합니다. 어떤 지역과 노드에서 측정했는지, 혼잡한 시간대가 포함됐는지, 실패하거나 늦어진 요청을 통계에서 제외했는지도 중요합니다. 한 번 빠르게 보인 사례보다 조건이 공개된 반복 측정이 비교에 적합합니다.
이번에 측정하지 않은 것: 거래별 확정 지연 분포, 모든 서비스의 입금 반영 시간, 장기간 장애 없는 운영.
전환 전후 TPS는 같은 집계 기준으로 비교해야 한다
공식 페이지는 Alpenglow에서 검증자 투표가 블록 속 거래에서 빠졌으므로, 투표를 포함하던 거래 수와 TPS 지표의 기준을 다시 잡아야 한다고 설명합니다. 숫자 감소를 그대로 사용자 활동 감소로 해석하지 말라는 안내입니다. [거래 집계 변경]
가령 예전 지표가 사용자 거래와 합의용 투표를 함께 세고 새 지표가 사용자 거래만 센다면, 두 값의 차이는 이용량 변화만을 보여주지 않습니다. 이때 먼저 할 일은 전환 전 자료에서도 투표를 제외해 비교 대상을 맞추는 것입니다. 반대로 집계 방식이 바뀌었다는 이유로 실제 활동의 모든 감소까지 무시할 수는 없습니다.
일반 이용자와 운영자의 할 일을 나눠 보자
Solana는 일반 이용자의 지갑과 앱은 기존처럼 작동하며, 거래 실행·프로그램·수수료 구조는 이번 합의 전환으로 바뀌지 않는다고 설명합니다. 반면 검증자와 블록·확정 데이터를 처리하는 인프라는 별도의 변경 사항을 확인해야 합니다. [이용자와 인프라 범위]
운영 문서에 나오는 epoch당 0.8 SOL의 VAT는 참여 검증자의 투표 계정에서 차감·소각되는 Validator Admission Ticket입니다. 첫 부과는 epoch 1064에서 다음 epoch 참여를 위한 것으로 안내됩니다. 일반 지갑 이용자에게 새로 청구하는 업그레이드 비용으로 읽으면 안 됩니다. [검증자 비용의 대상]
업그레이드 소식을 보고 자산을 새 주소로 옮기거나 복구문구를 제출해야 한다고 생각할 이유는 없습니다. 특히 ‘전환 등록비’나 ‘지갑 동기화’를 요구하는 메시지를 공식 네트워크 전환 절차와 혼동하지 않아야 합니다. 일반 독자는 운영자용 문서의 자금·서명 절차를 자신의 지갑에 적용할 필요가 없습니다.
또한 Anza는 블록 전파를 바꾸는 Rotor 등 후속 개선은 나중 릴리스에 남아 있고 확정 일정은 없다고 밝혔습니다. 이번 전환에 미래 로드맵의 기능까지 모두 포함됐다고 설명하면 범위를 부풀리게 됩니다. [남은 개발 단계]
이제 후속 확인의 중심은 예정일이 아니라 운영 자료입니다. 공개 RPC의 응답이 일관되는지, 서비스별 지연 측정의 조건이 명확한지, 통계가 새 집계 기준을 반영했는지 살펴볼 수 있습니다. 실제 전환 완료는 중요한 기술적 변화지만 가격 상승이나 모든 서비스의 무중단을 보장하지는 않습니다.
[1] Anza 공식 발표 · 2026년 10월 21일 10:14 ET. 메인넷 전환, 시작 슬롯, 성능 설명과 후속 계획.
[2] Solana 공식 Alpenglow 상태 페이지 · 활성화 상태, epoch, 거래 집계와 적용 범위.
[3] getAgGenesisCert 공식 RPC 문서 · 인증서·null·구버전 오류 구분. 직접 조회는 api.mainnet-beta.solana.com에 getAgGenesisCert, getEpochInfo, getEpochSchedule, getVersion을 사용했습니다.
[4] Anza 확정 상태 문서 · TowerBFT와 Alpenglow의 상태 구분.
[5] Anza 합의 정보 전달 문서 · 노드의 정보 수신 경로와 관측 지연. 페이지의 이전 ‘예정’ 문구는 최신 활성화 상태의 근거로 사용하지 않았습니다.
[6] SIMD-0384 전환 설계 · 5,000슬롯 경계와 전환 기준 블록의 관계. 실제 가동 여부는 발표와 RPC 응답으로 별도 확인했습니다.
[7] Anza 검증자 투표 계정 문서 · VAT의 비용 대상과 첫 부과 epoch.
자료와 RPC 응답은 2026년 10월 21일 UTC 기준으로 확인했습니다. 직접 조회 시각은 한국시간 10월 22일 05:49입니다. 기술 설명과 공개 응답의 대조이며 투자 권유나 독립적인 성능 인증이 아닙니다. 계정 접속·거래 서명·자산 전송은 수행하지 않았습니다.