솔라나, 출범 이후 첫 슬롯타임 단축…400ms→350ms, 목표는 200ms

작성일

솔라나, 8월21일 슬롯타임 350ms로 첫 단축…목표는 200ms
안자 주도 아게이브 업그레이드, 테스트넷선 이미 182ms 기록

솔라나, 출범 이후 첫 슬롯타임 단축…400ms→350ms, 목표는 200ms / AI 생성 일러스트(삽화)
솔라나, 출범 이후 첫 슬롯타임 단축…400ms→350ms, 목표는 200ms / AI 생성 일러스트(삽화)

솔라나(Solana) 네트워크가 출범 이후 처음으로 슬롯타임(slot time·블록 생성 주기)을 줄였다. 2026년 8월21일(현지시각) 에포크(epoch) 1020부터 기존 400ms였던 슬롯타임이 350ms로 단축돼 적용된다. 이번 조정은 솔라나 개발사 안자(Anza)가 주도하는 검증인 클라이언트 업그레이드 아게이브(Agave) v4.2의 일부다. 솔라나 재단(Solana Foundation) 기술 부문 부사장 제이콥 크리치(Jacob Creech)는 자신의 X 게시물에서 “이제 350ms 시대에 들어섰다. 다음 목표는 300ms다”라고 밝혔다. 솔라나는 이번 단축을 시작으로 단계적으로 슬롯타임을 200ms까지 줄이는 것을 목표로 하고 있다.

8월21일 적용된 첫 단축, 목표는 200ms

이번 변경을 규정한 제안 SIMD-0525는 지난 5월14일(현지시각) 승인·병합됐다. 솔라나 재단은 지난 6월 슬롯타임을 400ms에서 200ms로 낮추겠다는 계획을 밝히며 지연시간을 줄이고 트랜잭션 확정을 앞당길 수 있다고 설명했다. 로드맵에 따르면 앞으로 50ms씩 세 차례 추가 단축이 예정돼 있다. 네 단계 모두 아게이브 v4.2에서 메인넷에 순차 적용하는 게 목표지만, 일정은 아직 잠정적이다.

기능 자체는 이보다 앞서 활성화됐다. 2026년 8월6일(현지시각) 공개된 솔라나 엔지니어링 체인지로그에 따르면 350ms로 낮추는 기능 게이트는 이미 디브넷과 테스트넷에서 가동 중이었다. 메인넷에서는 에포크 1019 시작 시점에 기능 계정이 활성화됐고, 한 에포크의 지연을 거쳐 에포크 1020부터 실제 350ms 목표가 적용됐다. 안자 최고경영자 브레넌 와트(Brennan Watt)는 2026년 8월18일(현지시각) X에 “전환 구간이 다소 어수선할 수 있어 개발자들이 대비할 수 있도록 메인넷 첫 번째 슬롯타임 단축을 활성화한다”며 “DEFAULT_MS_PER_SLOT 같은 일부 SDK 상수값은 아직 새 값으로 갱신되지 않았고, 활성화 이후 갱신된 값을 반영한 릴리스를 배포할 것”이라고 밝혔다.

압축되는 컴퓨팅 예산과 리더 창구 / AI 생성 이미지
압축되는 컴퓨팅 예산과 리더 창구 / AI 생성 이미지

압축되는 컴퓨팅 예산과 리더 창구

슬롯타임이 짧아진다고 초당 연산량이 늘어나는 것은 아니다. 목표 주기가 400ms에서 350ms로 짧아지면 스케줄링 빈도는 이론상 약 14.3%(400을 350으로 나눈 값에서 1을 뺀 값) 늘어난다. 다만 이는 트랜잭션 처리량이나 확정 속도의 예측치가 아니라 목표 주기 자체의 변화일 뿐이라는 게 관련 보도의 설명이다. 실제로 블록당 최대 컴퓨팅 유닛(CU) 예시치는 400ms 기준 1억 CU에서 350ms 기준 8750만 CU로 함께 줄어든다. 두 값 모두 초당 약 2억5000만 CU라는 동일한 이론적 상한선에서 나온 수치다.

한 검증인(리더)이 연속으로 블록을 생성하는 창구도 좁아진다. 솔라나는 리더 한 명에게 슬롯 4개를 연속 배정하는데, 400ms 기준으로는 1.6초, 350ms 기준으로는 1.4초에 해당한다. 이 창구가 짧아지면 검증인이 이전 블록을 받아 재생하고 그 위에 새 블록을 쌓아 투표를 남기기까지 주어지는 시간도 줄어든다. 동시에 특정 리더가 블록 생산을 독점하는 시간이 짧아지는 만큼, 검열 저항성을 높이는 효과도 있다는 설명이다.

테스트넷은 이미 182ms…최대 4배 처리량 기대

테스트넷에서는 이미 더 빠른 속도가 검증되고 있다. 안자 최고경영자 브레넌 와트는 테스트넷 슬롯타임이 한때 182ms까지 떨어졌다고 확인했다. 블록 익스플로러 데이터 기준 최근 1시간 평균 슬롯타임도 약 193ms로 나타나, 단계적 단축이 거의 예정대로 이뤄지고 있음을 보여준다. 테스트넷에서는 통상 2개 에포크마다 새로운 단축이 이뤄지는데, 메인넷이 같은 속도로 따라간다면 200ms 목표는 에포크 1026 무렵인 2026년 9월1일(현지시각)경 도입될 수 있다는 관측이 나온다. 다만 솔라나 검증인들은 네트워크 스킵률이 일정 수준을 넘으면 다음 단계로 넘어가지 않기로 합의한 상태라, 실제 일정은 늦춰질 수 있다.

헬리우스(Helius) 최고경영자 머트 뭄타즈(Mert Mumtaz)는 팟캐스트에서 슬롯타임 단축과 블록 처리 한도 상향이 동시에 적용되면 단기적으로 네트워크 처리량이 최대 4배까지 늘어날 수 있다고 말했다. 더 장기적으로는 안자가 준비 중인 합의 알고리즘 재설계 프로젝트 알펜글로우(Alpenglow)가 있다. 이 업그레이드는 트랜잭션 최종 확정(파이널리티) 시간을 150ms까지 줄이고, 검증인이 에포크당 부담하는 투표 비용도 현재 약 2.4 SOL에서 약 1.6 SOL 수준으로 낮추는 것을 목표로 한다.

안정성이 관문…최근 파이널리티 위기도 변수

솔라나가 속도 경쟁에 속도를 내는 배경에는 안정성에 대한 경계심도 깔려 있다. 이달 초에는 인터넷 호스팅업체 테라스위치(Teraswitch)에서 발생한 라우팅 오류로 스테이킹된 SOL의 28.83%가 한꺼번에 딜린퀀트(비활성) 상태에 빠지며 네트워크가 파이널리티 정지 임계치에 근접했던 사건도 있었다. 이런 경험 때문에 검증인들은 스킵률이 높아지면 다음 단계 단축을 보류하기로 뜻을 모은 상태다.

SIMD-0525는 아직 초안(draft) 단계인 제안이며, 350ms는 400ms에서 200ms로 가는 여정의 첫 단계일 뿐이다. 이후 300ms, 250ms, 200ms로 이어지는 각 단계가 같은 일정대로 적용될 것이라는 보장은 없다. 실제로 디브넷은 300ms 단계에 머물러 있고 250ms 게이트는 활성화됐지만 아직 발효되지 않은 상태다. 결국 200ms 목표 달성 여부는 앞으로 몇 차례 에포크에서 네트워크가 얼마나 안정적으로 버텨주는지에 달려 있다.