Brennan Watt

Brennan Watt는 Solana blockchain의 핵심 인프라 소프트웨어를 구축하는 기업인 Anza의 최고경영자(CEO)를 맡고 있는 소프트웨어 엔지니어이자 경영인입니다. 그는 블록체인 인프라 분야로 옮기기 전, 대규모 고성능 시스템 분야에서 근무하고 엔지니어링 조직을 이끌었으며, 2026년 초에 현재의 직책을 맡았습니다.^{[1] [3]}

경력

Watt은 자신의 전문적 배경을 "대규모 고성능 시스템을 구축하고 엔지니어링 조직을 이끄는 데 보낸 경력"이라고 설명했습니다.^[1] 그의 궤적을 특징짓는 한 팟캐스트 출연에서는 그의 경로를 스토리지 엔지니어에서 Solana 인프라 구축으로 이동한 것으로 묘사하며, 이는 시스템 엔지니어링에서 blockchain 프로토콜 개발로의 전환을 반영합니다.^[2]

2026년 1월 15일에 게시된 블로그 포스트에서 Watt은 2026년부터 "Anza의 CEO 역할을 맡게 되었다"고 발표했습니다.^[1] 그는 "뛰어난 엔지니어, 연구원 및 운영자 팀과 함께" 회사를 이끌고 있으며, 핵심 개발자 및 더 넓은 Solana 생태계와 긴밀히 협력하여 즉시 프로덕션에 적용 가능한 프로토콜 개선 사항을 제공하고 있다고 밝혔습니다.^[1]

Anza에서의 업무

​Anza는 Solana가 성능, 탈중앙화 또는 보안을 타협하지 않고 계속해서 확장할 수 있도록 설계된 소프트웨어를 개발하고 출시합니다.^[1] Watt는 그가 CEO가 되기 전 해에 회사가 "Agave 검증인(validator)을 강화하고, 적대적 테스트를 확대했으며, 가동 중단 시간 제로를 경험했다"고 보고했습니다.^[1] Watt에 따르면, Anza는 검증인이 블록을 생성하는 간격인 슬롯 타임을 400밀리초 미만으로 유지하면서 첫 번째 블록 한도 증대를 실현했으며, 이는 이전에 Solana의 메인넷(mainnet)에서 볼 수 없었던 처리량 수준을 이끌어냈다고 말했습니다.^[1] 그는 또한 새롭고 개선된 스케줄러의 배포와 가십 네트워크 오버헤드(검증인들이 정보를 공유하기 위해 사용하는 P2P(peer-to-peer) 통신 레이어)의 감소를 보고했습니다.^[1]​

Alpenglow

Watt 로드맵의 핵심 요소는 Alpenglow로, 그는 이를 Anza의 "장기적 합의 솔루션"이라고 설명합니다.^[1] 그는 Alpenglow가 Solana의 기존 합의 메커니즘인 TowerBFT보다 더 엄격한 타이밍 집행을 제공하며, 네트워크의 안전 보장을 유지하면서 트랜잭션이 되돌릴 수 없게 되는 데 걸리는 시간인 확정 지연 시간(finalization latency)을 줄이기 위해 BLS 암호화 프리미티브(많은 서명을 효율적으로 집계할 수 있는 서명 방식)를 사용한다고 밝혔습니다.^[1] Watt는 2026년 초 기준으로 Alpenglow의 코어가 수개월 동안 테스트 클러스터에서 실행되고 있다고 보고했습니다.^[1] 그의 2026년 로드맵에서 그는 2026년 3분기에 Alpenglow를 개발 클러스터에서 메인넷으로 이동시키는 것을 목표로 설명했으며, 네트워크 결함 및 이중 서명(equivocation) 시나리오에 대한 스트레스 테스트, 보상 및 인센티브 메커니즘 강화, 성능 및 엔드 투 엔드 지연 시간 예산 최적화를 해당 추진 과제의 주요 집중 분야로 꼽았습니다.^[1]​

다중 동시 제안자 (Multiple Concurrent Proposers)

Watt는 트랜잭션 정렬 방식을 해결하기 위해 Anza가 개발 중인 프로토콜 변경 사항으로 다중 동시 제안자(MCP)를 발표했습니다.^[1] 그는 MCP가 "재생 단계(replay stage)에서 정렬을 강제함으로써 프로토콜 내로 정렬 기능을 가져오며", 단일 제안자가 아닌 다수의 제안자를 둠으로써 검열 저항성을 확보한다고 설명했습니다. 이는 특정 슬롯에서 트랜잭션 순서를 결정하는 보통의 "단일 리더 독점" 구조를 깨는 것으로 프레임화되었습니다.^[1] 그는 예측 가능한 정렬이 Solana 위에 구축된 애플리케이션에 대한 실행 제어 가능성을 열어줄 것이라고 말했습니다.^[1] 2026년 로드맵에서 Watt는 Anza가 2026년 중에 프로토콜 내 배치(batch) 내 트랜잭션 정렬을 강제하는 데 중점을 둔 MCP의 초기 버전을 출시할 계획이라고 밝혔습니다.^[1]​

성능 및 처리량 이니셔티브

Watt은 일련의 성능 변화를 "대역폭 증가, 지연 시간 감소"를 뜻하는 IBRL(Increase Bandwidth, Reduce Latency)이라는 포괄적인 용어로 그룹화했으며, 이를 Solana의 소프트웨어 및 커널 경로에서 하드 실링(상한선)을 제거하기 위한 작업이라고 설명했습니다.^[1] 그가 나열한 2026년 IBRL 이니셔티브에는 Solana의 블록 전파 프로토콜인 Turbine의 대역폭을 늘리기 위해 XDP shred 전송을 기본으로 배포하는 것, 블록 내 트랜잭션의 계산 비용을 측정하는 지표인 블록 한도를 1억 컴퓨팅 유닛(CU)으로 상향하는 것, 온체인 프로그램의 실행 환경인 Solana Virtual Machine (SVM) 내부의 메모리 복사 비용을 줄이기 위해 직접 매핑(direct mapping)을 활성화하는 것, 그리고 슬롯 시간을 400밀리초 미만으로 단축하는 것이 포함됩니다.^[1] Watt은 이러한 변화가 네트워킹, 실행, 메모리 및 시간 전반에 걸친 여러 독립적인 병목 현상을 제거한다고 밝혔습니다.^[1]​

그는 또한 Anza가 Agave의 트랜잭션 전송 한도를 높여 클라이언트가 현대적인 하드웨어 및 소프트웨어 기능을 더 잘 반영하도록 하고 있으며, 이를 통해 모든 사용자에 대해 더 큰 트랜잭션 유입을 허용하고, 글로벌 혼잡 기간에만 스테이크 가중치에 따라 스로틀링(제한)을 적용할 것이라고 말했습니다.^[1]​

운영자 및 개발자 경험

Watt은 네트워크를 운영하는 검증인(validators)을 위한 개선 사항을 강조했습니다. 그는 블록 수익 분배(SIMD-0123)를 블록 보상 및 수수료의 회계 처리 및 분배 방식을 변경하는 것으로 설명하며, 이는 투명성을 높이고 운영상의 모호함을 줄이기 위한 것이라고 밝혔습니다.^[1] 그는 이것이 사용자가 블록 보상에 직접 참여할 수 있게 하고, 검증인이 보상의 일정 비율을 인프라 제공업체와 같은 지정된 파트너에게 자동으로 재지정할 수 있게 해줄 것이라고 말했습니다.^[1] 그는 또한 "스케줄러 바인딩(Scheduler Bindings)"을 트랜잭션 스케줄링 로직과 패킹 메커니즘 사이의 깔끔한 분리를 만드는 것으로 설명하며, 이를 "MCP를 앞둔 의도적인 기초 작업"이자 운영자 실험을 위한 저위험 샌드박스라고 불렀습니다.^[1]​

개발자를 위해 Watt은 몇 가지 2026년 이니셔티브를 나열했습니다: 네트워크의 장기 저장 비용을 낮추기 위한 임대료 인하(Rent Reduction), 더 표현력이 풍부한 트랜잭션을 허용하고 원자성 보장이 부족한 다단계 패턴을 줄이기 위한 트랜잭션 크기 확대(Larger Transaction Sizes), 그리고 그가 p-ATA라고 부르는 버전으로 전환하여 Associated Token Account (ATA) 프로그램과 상호 작용할 때 비용을 절감하는 것을 목표로 하는 "최적화된 온체인 프로그램(Optimized Onchain Programs)"입니다.^[1] 그는 2026년 전반을 "다음 단계의 확장을 위한 토대를 마련하는" 해로 규정했습니다.^[1]​

인터뷰

Anza Protocol Developments #01

2025년 12월 12일, Anza의 Brennan Watt는 Solana 유튜브 채널에 게시된 발표를 통해 Solana 프로토콜의 발전 사항을 논의했습니다. 그는 네트워크가 약 2,000억 건의 트랜잭션을 처리하는 동안 지속적인 운영을 유지해 왔다고 설명했습니다. Watt는 이러한 운영 성과의 일부를 Anza의 Invalidator 팀이 수행한 스트레스 테스트 덕분으로 돌렸는데, 이 팀은 퍼블릭 테스트넷을 대상으로 네트워크 수준 및 트랜잭션 수준의 공격 시나리오를 테스트합니다.

Watt는 2025년 동안 Solana의 리소스 제한 및 트랜잭션 처리 방식에 발생한 변화를 설명했습니다. 그의 발표에 따르면, 블록 연산 단위(compute-unit) 제한이 4,800만에서 6,000만으로 상향됨에 따라 메인넷 처리량이 약 25% 증가했습니다. 그는 또한 애플리케이션이 사용자 공간에서 네트워크 하드웨어와 상호 작용할 수 있게 하여 기존 커널 네트워크 경로와 관련된 처리 과정을 줄여주는 네트워크 처리 메커니즘인 XDP에 대해서도 논의했습니다. 발표에서는 이러한 변화가 향후 블록당 연산 단위를 1억 개까지 늘릴 수 있게 하는 원동력이 될 것이라고 명시했습니다.

또한 이번 발표에서는 Tower를 대체하기 위해 개발 중인 합의 엔진인 Alpine Glow도 다루었습니다. Watt는 Alpine Glow가 트랜잭션 확정 시간(finality times)을 약 150밀리초로 단축하고, 네트워크보다 뒤처지는 검증인을 처리하기 위한 추가 메커니즘을 제공하도록 설계되었다고 밝혔습니다. 발표 당시, 지리적으로 분산된 클러스터에서 테스트가 진행 중이었습니다. Watt는 또한 Solana의 트랜잭션 처리 아키텍처에 제안된 변경 사항의 일부로, 검증인이 블록 생성에서 서로 다른 역할을 맡을 수 있는 설계인 다중 동시 제안자(multiple concurrent proposers)에 대해서도 논의했습니다.

Watt가 논의한 다른 변경 사항으로는 상태 저장 비용 절감, 최대 트랜잭션 크기를 4KB로 증대, 검증인 디스크 사용량을 줄이기 위한 수정, 그리고 더 빠른 재시작 절차 등이 포함되었습니다. 그는 또한 스테이커와 인프라 제공자 간의 검증인 수익 분배 방식을 수정하는 SIMD-123에 대해서도 설명했습니다. Watt는 Anza의 개발 프로세스가 고정된 로드맵 중심이 아닌 릴리스 중심(release-oriented)으로 조직되어 있다고 설명하며 발표를 마쳤습니다. ^[4]

Agave Engineering and Scaling #02

2025년 5월 19일, Solana 유튜브 채널은 Anza의 핵심 엔지니어링 부사장인 Brennan Watt의 발표를 게시했습니다. 이 발표는 Solana 네트워크에서 사용되는 검증인 클라이언트인 Agave의 개발 및 운영에 관한 것이었습니다. Watt는 클라이언트의 최근 변경 사항을 설명하고 트랜잭션 처리, 블록 생성, 연산 용량 및 네트워크 데이터 전파와 관련된 조치들을 논의했습니다.

Watt는 블록 스킵률(검증인이 블록을 생성할 수 있었음에도 생성하지 못한 경우)이 0.5% 미만으로 떨어졌다고 보고했습니다. 그는 또한 많은 트랜잭션이 단일 슬롯 내에서 확정되고 있으며, 발표에서 제시된 대부분의 트랜잭션이 1초 미만 내에 확정되었다고 밝혔습니다. 그는 이러한 변화를 트랜잭션 및 블록 처리 파이프라인의 개선 덕분으로 돌렸습니다.

발표에서는 연산 단위 용량에 대해서도 다루었습니다. Watt는 블록이 네트워크의 연산 단위 제한에 자주 도달하고 있으며, 이는 트랜잭션 수요가 때때로 가용 블록 공간을 초과할 수 있음을 나타낸다고 언급했습니다. 그는 5,000만에서 6,000만 연산 단위로의 상향을 다가올 변경 사항으로 설명했으며, 2025년의 추가 목표로 1억 연산 단위를 지목했습니다.

Watt은 메모리 할당 감소, 자주 사용되는 처리 경로를 따라 실행되는 코드의 최적화, 해싱 방법 및 데이터 구조 조정 등 Agave 내의 여러 엔지니어링 작업 영역에 대해 논의했습니다. 그는 이러한 변화를 단일 아키텍처 수정이라기보다는 실행 효율성을 개선하기 위한 작은 최적화들의 집합이라고 설명했습니다.

또 다른 주제는 Solana의 블록 재전송 시스템이었습니다. Watt은 Turbine이 트리 기반 구조를 통해 리더로부터 검증인에게 블록 데이터를 분배한다고 설명하며, 이 방식의 확장으로서 Rotor의 개발에 대해 논의했습니다. 그는 제안된 변경 사항이 데이터를 직접 받는 노드의 수를 늘리고 블록 데이터가 전파되어야 하는 레이어의 수를 줄일 것이라고 언급했습니다. 또한 발표에서는 블록 재전송으로 인해 발생하는 네트워크 트래픽과 더 높은 컴퓨팅 유닛(compute-unit) 한도를 수용하기 위해 필요한 변경 사항들도 다루었습니다.

Watt은 또한 블록 실행을 위한 트랜잭션 스케줄링에 대해서도 논의했습니다. 그는 가용 컴퓨팅 리소스에 맞춰 트랜잭션 선택 및 실행을 조정하는 것을 목표로 하는 로컬 수수료 시장 및 다양한 스케줄러 구현과 관련된 연속적인 변화들을 언급했습니다.

네트워크 운영을 논의하면서 Watt은 검증인 가용성, 클라이언트 회복탄력성, 그리고 수요가 많은 기간 동안의 트랜잭션 수수료를 엔지니어링 고려 사항으로 꼽았습니다. 그는 Anza의 개발 프로세스가 고정된 장기 로드맵보다는 점진적인 릴리스와 지속적인 반복에 중점을 두고 있다고 설명했습니다. ^[5]