엔지니어링 속도: Alessandro Decina와 함께 들여다본 Anza 성능 팀

소개

기술 낙관주의는 의심할 여지 없이 Solana의 시대정신입니다. 한계 없는 속도와 진보, 혁신에 대한 확고한 믿음이 메인넷에 배포되는 모든 풀 리퀘스트의 바탕에 깔려 있습니다. 구호는 IBRL, 즉 Increase Bandwidth, Reduce Latency입니다. 엔지니어링의 명령이자 문화적 암호이며 세속적 기도입니다. Bitcoin이 영속성을 기리는 대성당이고 Ethereum이 중립성을 위한 광장이라면, Solana는 측정 가능한 기계적 속도가 지배하는 경주장입니다.

하지만 이 속도가 주석까지 깔끔하게 달린 diff의 형태로 하늘에서 내려오는 일은 없습니다. 온종일 코드를 들여다볼 용기가 있는 이들이 캐내고, 다듬고, 가공해 만들어 냅니다. Alessandro Decina만큼 집요하게 들여다보는 사람은 드뭅니다. 그는 원래 끊기는 비디오 버퍼를 개인적인 모욕으로 받아들이던 GStreamer의 귀재였습니다. 지금은 4명으로 구성된 Anza 성능 팀을 이끌고 있습니다. 이 팀에게 “자기 관리”란 새벽 3시에 검증인 트레이스에서 노란 막대를 지우는 일입니다. 이들은 매일 플레임 그래프를 들여다보고, 워크플로 전체를 뜯어내며, 최적화할 수 있는 것은 결국 최적화된다는 믿음으로 실전에서 검증된 프로덕션 코드를 다시 작성합니다.

이 속도로 살아간다는 것이 어떤 의미인지 알고 싶었습니다. 그래서 Alessandro Decina를 직접 만나 현존하는 가장 빠른 블록체인을 어떻게 계속 더 빠르게 만드는지 물었습니다. 다음 인터뷰는 속도에 대한 부검입니다. 멀티미디어 파이프라인을 다루던 시절부터 엔지니어 4명이 조직 전체보다 더 빠르게 결과물을 내놓게 하는 문화적 안전장치까지 이야기했습니다. 

명확성과 간결성을 위해 대화를 편집하고 축약했습니다.

인터뷰

시작과 세계관

Ichigo: 과거로 잠시 돌아가 보겠습니다. 처음 사랑한 기술은 GStreamer와 멀티미디어 파이프라인이었죠. 그 시절 배운 가장 큰 지연 시간 관련 교훈은 무엇인가요? 실시간 오디오와 비디오를 추구한 경험이 Agave에서 밀리초를 줄이는 데 어떤 가르침을 주었나요? 

Decina: 우선 저를 제대로 조사하셨네요, 하하. GStreamer에서 15년 정도, 어쩌면 그보다 조금 더 오래 일했습니다. 말 그대로 제가 아는 모든 것을 배운 곳입니다. 프로젝트가 오픈 소스로 막 시작했을 때 기여하기 시작했습니다. 운이 좋게도 당시 창립자와 가까워졌습니다. 저보다 한 15살 많았던 것 같은데 정말 뛰어난 사람이었습니다. Wikipedia에 등재된 사람이니 아마 똑똑하겠죠. 저처럼 똑똑한 척하는 사람이 아니고요. 그 사람이 그냥 자기가 아는 모든 것을 무료로 가르쳐 주겠다고 했습니다. 그렇게 일을 시작했습니다.

지금 Solana에서 일하며 낮은 지연 시간을 이야기한다는 게 재미있습니다. 사실 전혀 낮은 지연 시간이 아니기 때문입니다. 오디오 처리, DPS, 멀티미디어 하드웨어를 이야기할 때는 Solana에서 하는 작업의 지연 시간이 엄청나게 높습니다. 오디오나 비디오의 응답 시간이 400밀리초라면 사실상 고장 난 것입니다. 제대로 작동하지 않습니다.

어느 순간부터 비디오와 오디오를 인코딩하고 디코딩하는 Linux 드라이버와 하드웨어를 다루기 시작했습니다. 지금 하는 많은 일이 당시 하던 일과 본질적으로 같습니다. 하드웨어를 다룰 때 지연 시간이 발생한다는 것은 어딘가에 큐가 있다는 뜻입니다. 그 큐를 찾아 최대한 작게 줄이고, 언더런이 절대 발생하지 않게 해야 합니다.

예를 들어 지금 하는 XDP 작업은 오디오 링 버퍼의 작동 방식과 매우 비슷합니다. 지금 진행 중인 이 통화에서도 수많은 패킷이 순서 없이 도착합니다. 어딘가의 링 버퍼가 모든 패킷의 순서를 다시 맞추고 있으며, 여기서 언더런이 발생하지 않게 해야 합니다.

지난 20년 동안 같은 일을 해 온 기분입니다.

말하자면 달라진 건 날짜뿐이고 하는 일은 같군요. Spotify에서도 일하셨고 Firefox 관련 경력도 조금 있던데요—

아, 아닙니다. Firefox 관련 작업은 해커톤을 위한 통합 작업에 불과했습니다. 하하, 제가 워낙 오래된 사람이라 GStreamer를 사용하는 Firefox 최초의 video 태그를 작성했습니다.

세상에, 하하. 결국 모든 길은 GStreamer로 통하는군요? 

GStreamer는 제게 멀티스레드 프로그래밍을 제대로 가르쳐 줬습니다. 제가 이 생태계에 있는 이유이기도 합니다. Assembly를 작성하고 온갖 저수준 해킹을 하는 사람들이 있습니다. 저는 그런 일을 오랫동안 해 왔습니다. 그리고 강력한 타입 시스템과 좋은 컴파일러를 갖춘 언어가 없으면 결국 스스로 문제를 일으킨다는 사실을 배웠습니다. Assembly로 조금 더 빠른 무언가를 만들 수는 있겠지만, 저는 정말 Rust를 원합니다. 

Rust 컴파일러가 이렇게 말해 주길 바랍니다. 멍청한 짓이야. 여기에 버그가 있으니 작동하지 않을 거야. Rust 전에는 제가 10%는 소프트웨어 엔지니어이고 90%는 인간 디버거라고 느꼈습니다. 그저 계속 디버깅만 했습니다. 그래서 GStreamer와 Rust에 대한 애정이 Solana에서 일하기 시작한 이유라고 생각합니다. Rust의 인기가 높아지고 있었지만 풀타임으로 다룰 수 있는 일자리는 많지 않았고, 저는 오직 Rust로만 일하기로 결심했습니다. 

C를 작성하기에는 나이가 너무 들었습니다. 메모리 안전성이 없는 언어는 원하지 않습니다. 시간을 낭비하고 싶지 않습니다. 그렇게 지금 여기까지 왔습니다.

아주 좋습니다. 전환 당시 검증인 코드를 다루기 전에는 탈중앙화 시스템에 대해 잘못 알고 있던 점이 있었나요? Solana의 아키텍처가 실제로 확장될 수 있다고 확신한 계기는 무엇인가요? 

사실 Rust 컴파일러 작업으로 바빴기 때문에 Solana에 거의 2년이나 늦게 합류했습니다. 당시 Solana에서 가상 머신 작업을 막 시작한 누군가가 이메일을 보냈습니다. “저도 같은 작업을 하고 있는데, 당신이 조금 더 앞서 있는 것 같으니 함께 일합시다.” 하지만 그 이메일에 답하지 않았습니다. Bitcoin과 Ethereum을 살펴보니 무언가를 실행할 수는 있어도 10 TPS에 불과했습니다. 진지한 프로젝트라고 보기 어렵잖아요? 10 TPS로는 현실에서 아무것도 할 수 없습니다. 

그래서 그 이메일을 받고도 답하지 않았습니다. 그저 이 암호화폐 사람들은 아직 진지하지 않구나라고 생각했습니다.

2년 후 Toly가 연락했고 저는 SOL 가격을 확인했습니다. 그 이메일을 열어 봤어야 했다고 생각했죠, 하하. 이번에는 결국 그와 대화했습니다. 대화 전에 그가 코드 몇 개를 알려 줬습니다. 살펴보니 솔직히 끔찍했습니다. 정말 형편없는 Rust 코드였습니다.

하지만 Toly를 검색해 보지 않고 대화해서 그가 누구인지 전혀 몰랐습니다. 그는 똑똑했고 옳은 말만 했습니다. 우리가 이것을 만들고 있다고 했습니다. 현재는 이렇게 작동합니다. 분명 최첨단은 아니지만 하드웨어와 함께 확장하는 것이 목표입니다. 가장 성능이 뛰어난 블록체인을 만들고, 궁극적으로 하드웨어가 병목이 되게 합니다. 하드웨어를 더 투입할수록 더 확장되는 구조입니다.

그 말은 설득력이 있었습니다. 제3차 세계대전을 두고 흥분하는 블록체인 광인들의 모임만은 아니라는 느낌이 들었습니다…저는 기술에 관심이 있습니다. 실제로 기술 때문에 이 업계에 있는 몇 안 되는 암호화폐 업계 사람 중 하나입니다.

Solana에는 기술 낙관주의의 영향을 강하게 받은 엔지니어링 문화가 있습니다. 바로 Increase Bandwidth, Reduce Latency라는 문화 전체입니다. 개인적으로는 어떻게 생각하시나요? Anza의 일상 업무에는 어떤 영향을 주나요? 

제가 보기에 Ethereum은 근본적으로 희소성 중심의 사고방식을 갖고 있습니다. 벽에 부딪혔으니 그 벽을 우회할 방법을 찾겠다는 식입니다. 본질적으로는 자신들의 지식 격차이고 도저히 해결할 수 없다고 느끼는 문제를 위해 이 모든 인프라를 새로 만들겠다는 것이죠.

반대로 우리는 정반대라고 생각합니다. 문제가 있으면 해결하면 됩니다. 물리 법칙을 위반하는 문제 외에는 해결할 수 없는 문제란 없습니다. 문화적으로 엄청난 차이입니다.

무언가가 고장 나면 일단 앉아서 프로파일링을 조금 해 보고 문제가 무엇인지 살펴봅니다. 트레이더와 마켓 메이커에게 어떤 문제가 있는지 묻습니다. 최근에는 정말 구체적인 문제 몇 가지를 발견했고 대부분을 해결했습니다. 솔직히 2~3개월이면 모두 해결할 수 있습니다. 

오늘날 Solana에는 제대로 작동하지 않는 부분이 많습니다. 우리도 알고 있습니다. 하지만 한 번도 앉아서 “완벽한 해결책을 찾았다! 이제 더 나아가려면 새로운 것을 발명하거나 연구해서 다른 무언가를 해야 한다”고 말한 적은 없습니다. 아닙니다. 구체적인 문제들입니다. 대부분은 정말 어이없는 문제입니다. 

그리고 최근에는 중단 사고가 없었습니다. 개인적으로는 약세 신호라고 생각합니다. 일부 사람들이 조금 보수적으로 변하기 시작한 것 같기 때문입니다. 훨씬 더 빨라질 수 있다는 것을 알고 있습니다. 내일 당장 1억 CU 블록을 처리할 수 있다는 것도 압니다. 몇 가지를 빠르게 밀어붙이기만 하면 됩니다. 저는 모든 것을 빠르게 밀어붙이는 쪽입니다.

근본적으로 알고 있습니다. 현재 성능을 10배 높일 수 있다는 사실을 확인하는 데 로드맵은 필요하지 않습니다. 방법이 보이고, 어떻게 해야 하는지 알고 있습니다. 코드를 이미 작성했지만 완전히 끝내지 못했거나, 코드를 작성했지만 수정해야 할 엣지 케이스가 남아 있어 배포하지 못했을 뿐입니다. 무엇을 해야 하는지 정확히 알고 있습니다.

이 시스템을 확장하는 방법을 알고 있습니다.

성능 엔지니어링

성능 작업 이야기가 나왔으니 말인데, Anza에 전담 성능 팀이 있다는 사실을 아는 사람은 많지 않은 것 같습니다. 잘 알려지지 않았죠. 팀 구조를 설명해 주세요. Anza의 다른 엔지니어링 팀과는 어떻게 다른가요? 

맞습니다. Anza에는 여러 팀이 있습니다. 지금은 Alpenglow에 집중하는 합의 팀이 있습니다. 주로 Gossip에 집중하는 네트워킹 팀도 있습니다. 사실상 계정 데이터베이스 작업만 하는 AccountsDB 팀이 있고, 스케줄러를 담당하는 블록 생성 팀도 있습니다. 물론 제가 잊어버린 다른 팀도 모두 있고요.

성능 팀의 차이점은 모든 영역을 다룬다는 것입니다. 프로파일링으로 병목을 찾은 뒤 관련 팀에 시간과 전문성이 있는지 물어봅니다. 때로는 모두가 해결할 수 있는 문제가 아닌 경우도 있기 때문입니다. 예를 들어 합의 담당자라면 전문 분야가 다르므로 저수준 프로그래밍에 가장 능숙한 사람은 아닐 수 있습니다. 그런 경우에는 보통 우리가 직접 들어가 코드를 수정합니다.

한 가지에만 집중하지 않습니다. 다음 병목을 찾습니다. 대략 2주마다 진행 상황을 맞추고, 다음에 무엇을 해야 하는지, 다음 릴리스를 어떻게 더 빠르게 만들지 결정합니다.

또 다른 큰 차이점은 Anza가 똑똑한 사람을 채용하는 편이라는 것입니다. Rust를 몰라도 괜찮습니다. 저수준 프로그래밍을 몰라도 괜찮습니다. 똑똑한 사람이라면 업무 중에 이런 기술 대부분을 가르칠 수 있다고 봅니다. 하지만 성능 팀에는 현재 마주하는 병목의 특성상 커널이나 다른 저수준 영역을 실제로 다뤄 본 사람을 주로 채용합니다.

예를 들어 계정 데이터베이스에는 해결해야 할 알고리즘 문제가 있습니다. 하지만*,* 2.3 릴리스에서 계정 데이터베이스가 두 달 전보다 약 10배 빨라진 이유는 I/O 처리 방식을 고쳤기 때문입니다. 더 빠르게 만들려면 작동 원리를 알아야 합니다. 데이터베이스를 상위 수준에서만 이해하면 디스크가 실제로 어떻게 작동하는지 잘 모르고, 커널이 I/O 요청을 어떻게 스케줄링하는지도 알 필요가 없기 때문입니다.

그래서 개인적으로 성능 팀에는 저수준 기술에 더 익숙한 사람을 채용하는 편입니다. 다시 말하지만 Rust를 아는지는 중요하지 않습니다. 다만 다른 저수준 작업에서 C나 C++를 사용한 경험은 있기를 바랍니다.

성능 팀의 존재가 잘 알려지지 않은 이유는 사실상 12월에 시작했기 때문입니다. 저는 원래 컴파일러 작업을 위해 채용됐지만 2024년 3월경의 중단 사고를 계기로 성능 작업으로 전환해 최적화를 시작했습니다. 어느 날 갑자기 원하는 작업을 하겠다고 말했기 때문에 사람들이 별로 좋아하지 않았습니다. 네, 하하, 좋아하지 않았지만 이후 정말 좋은 성과가 나왔습니다. 그러자 사람들이 제게 와서 “좋아요. 이 일을 할 사람을 더 채용하시겠어요?”라고 물었습니다. 그리고 12월에 성능 개선 작업을 공식화하고 팀을 만들었습니다.

솔직히 편향된 의견이지만, 단연코 성능 팀이 Anza 최고의 팀입니다.

의심하지 않습니다, 하하. 팀원은 몇 명인가요? 

풀타임으로는 4명입니다. 하지만 프로파일러를 더 많은 사람과 공유하기 시작한 뒤로 Brooks와 몇몇 사람이 합류했다고 Twitter에서 농담하고 있습니다. 약 두 달 전까지만 해도 성능 담당자만 프로파일러에 접근할 수 있었습니다. 이제는 모두가 쓸 수 있습니다. 예를 들어 Brooks는 제가 프로파일러를 준 뒤 저보다 성능 작업을 더 많이 합니다, 하하. 완전히 빠져들었습니다. 이제 모든 것을 더 빠르게 만들고 있습니다.

그래서 비공식적으로는 Brooks와 성능 작업을 많이 하는 몇 명이 더 있습니다. 하지만 성능을 풀타임으로 담당하는 인원은 4명입니다. 

성능 작업을 할 때 프로파일링에서 대부분의 엔지니어가 놓칠 만한 어떤 “냄새”를 찾나요? 무엇을 최적화해야 할지는 어떻게 결정하나요? 

정말 명백한 징후가 몇 가지 있습니다. Agave를 처음 프로파일링했을 때는 사용자 공간 코드를 실행하는 시간보다 커널 내부에서 보내는 시간이 훨씬 길었습니다. 말도 안 되는 일이죠. 우리는 저수준 애플리케이션이 아닙니다. 멀티미디어 프레임워크라면 궁극적으로 샘플을 하드웨어로 보내야 하므로 대부분의 작업을 커널에서 처리하는 것이 자연스럽습니다. 하지만 우리가 하는 작업 중 진정한 저수준 작업은 Turbine뿐입니다.

그래서 프로파일링을 시작할 때 가장 큰 이상 신호는 보통 플레임 그래프에 노란색이 많이 보이는 경우입니다. 커널에서 너무 많은 시간을 보내고 있다는 뜻이기 때문입니다. 누군가 겉보기에는 무해한 상위 수준 API를 사용하지만, 내부적으로는 성능이 끔찍하다는 의미일 가능성이 큽니다.

지난 1년 동안 Agave가 사용하는 메모리를 약 10분의 1로 줄였습니다. 대체로 같은 문제를 반복해서 마주하기 때문입니다. 메모리를 너무 많이 할당하면 어느 순간 커널과 상호작용해야 합니다. 프로파일러에서 커널과의 상호작용을 확인할 수 있습니다. 어디에서 시작됐는지 살펴보면 이 체인이 계속 메모리를 과도하게 사용하고 있다는 사실이 보입니다. 메모리를 지나치게 교체하고 할당하는 지점까지 거슬러 올라간 뒤 수정합니다.

더 어려운 문제도 있습니다. 예를 들어 우리가 발견했고 제가 수정 중인 근본적인 설계 문제가 있습니다. 잘 알려진 것처럼 Solana는 여러 단계로 구성된 파이프라인 구조이며, 모든 것이 병렬화되어 동시에 실행되도록 설계됐습니다.

실제로는 아키텍처 구성 방식 때문에 파이프라인 설계가 있어도 중단이 너무 많이 발생합니다. 단계는 여러 개지만 곳곳에서 지연 시간을 유발하는 어이없는 설계 버그 때문에 모든 단계의 처리량을 극대화하지 못합니다. 사람들이 트랜잭션을 보낼 수 없거나 시스템에 지터가 있다고 말할 때 주로 불평하는 것이 바로 이 지연 시간입니다. 이 지터는 근본적인 요소나 하드웨어 때문에 생기는 것이 아닙니다. 우리가 작업을 비효율적으로 처리하기 때문에 발생합니다. 

하지만 완전히 솔직하게 말하면 우리가 다루는 문제들은 어이없을 정도입니다. 아주 명백한 버그가 몇 개 있고, 우리는 그 명백한 버그를 고치고 있을 뿐입니다.

이런 버그를 다룰 때 마이크로 벤치마크를 사용할지, 메인넷 트래픽을 완전히 리플레이할지는 어떻게 결정하나요? 

우리가 겪는 성능 문제 대부분은 사람들이 마이크로 벤치마크를 작성했다는 데서 비롯된다고 생각합니다. 마이크로 벤치마크를 더 빠르게 만들고 격리된 환경에서 테스트했습니다. 하지만 모든 것을 Agave에 합치면 마이크로 벤치마크처럼 작동하는 것이 하나도 없습니다.

그래서 저는 개인적으로 이렇게 말합니다. 어떤 경우에도 마이크로 벤치마크를 사용하지 마세요. 트랜잭션 리플레이조차 지난 1년 동안 세 번 정도만 했습니다. 메인넷 트래픽을 리플레이해도 실제 메인넷 트래픽을 실행할 때와 정확히 같은 속도로 재현할 수 없어서 많은 것이 달라지기 때문입니다. 

시작 속도를 크게 높이고 있는 이유 중 하나도 이것입니다. 수정 사항이 작동하는지 확인할 때마다 30분씩 기다려야 한다면 짜증 나는 일이기 때문입니다.

Agave가 현재 도달한 단계에서는 하나의 컴포넌트만 놓고 깊은 토끼굴로 들어갈 수 없습니다. 지적으로 흥미로운 작업일 수는 있지만 전체 시스템을 고려하지 않으면 아무 쓸모가 없습니다. 실제로 아무런 진전도 만들지 못합니다. 

그렇다면 전체 시스템 관점에서 Turbine이 XDP를 사용하도록 다시 작성하는 것이 왜 그렇게 중요한가요? 

Solana에 합류하기 직전에는 네트워킹 작업을 했습니다. 심층 패킷 검사를 수행하는 스타트업에 있었습니다. 기본적으로 NIC로 들어오는 모든 트래픽을 가로채 실시간으로 분석해 악성 흐름을 차단한 뒤 다시 커널에 주입하는 방식입니다. Rust, Tokio, 그리고 당연히 XDP를 사용해 사용자 공간에 TCP와 UDP 스택 전체를 작성했습니다.

Anza에 합류했을 때 언젠가는 XDP를 사용해야 한다는 점이 분명했습니다. Firedancer가 시작할 때 그들은 “Turbine의 XDP 구현부터 시작하겠다”고 했고, 저는 어리석은 생각이라고 말했습니다. 말이 되지 않았습니다. XDP는 객관적으로 끔찍한 API라 훨씬 더 많은 시간이 걸립니다. 따라서 바퀴가 말 그대로 빠져 버릴 때까지 최대한 오래 사용을 피해야 합니다.

그러다 결국 아, [삭제됨], 이제 XDP를 써야겠다고 말하게 됩니다. 우리에게도 실제로 그런 일이 일어났습니다. 파이프라인의 다른 모든 병목을 제거하다가 부하 테스트를 시작한 날 Turbine이 완전히 작동을 멈춘 것을 확인했습니다.

그래서 이제는 분명 실현 가능한 방식이 아니라고 판단했습니다. 과거에 XDP를 사용해 봤고 얼마나 끔찍한지 알았기 때문에 정말 필사적으로 피하려고 했습니다. io_uring 기반 Turbine 구현을 만들려고 했습니다. 그러다 io_uring에서 버그를 발견해 수정하기 시작했습니다. 아직 보내고 싶은 커널 패치가 몇 개 남아 있지만, 어느 순간 모든 검증인 운영자에게 제 커스텀 커널로 Solana를 실행하라고 할 수는 없다는 사실을 깨달았습니다.

결국 XDP를 사용해야 했고, 실제로 사용했습니다. 이제는 작동합니다.

답은 간단합니다. 다음 병목을 찾아 수정합니다. 발견하는 모든 병목을 계속 수정합니다. 내일의 문제는 내일 생각하면 됩니다. 이것이 제 좌우명입니다. 내일만 걱정할 수도 있겠지만 그러면 오늘은 엉망이 됩니다. 현재 Solana는 엉망입니다. 블록은 너무 작고, Turbine은 지연 시간을 지나치게 늘리며, 스케줄러에는 여전히 문제가 있습니다. 오늘 문제를 해결해야 합니다. 그렇지 않으면 그렇게 빨라질 내일도 없습니다.

성능 회귀는 어떻게 방지하나요? Firedancer와는 어떻게 협업하나요? 

성능 회귀는 정말 골치 아픈 문제입니다. 저는 개인적으로 매일 Agave의 무언가를 프로파일링합니다. 적어도 하루에 몇 번씩 합니다. 성능이 자주 회귀하는 이유는 고성능 코드를 작성하는 것 자체가 전문적인 일이기 때문입니다. 성능이 뛰어난 코드를 작성하는 방법을 알아야 합니다. Rust 코드를 작성하면 평균적으로 Node.js나 Python 같은 코드보다 성능이 좋습니다. 하지만 예를 들어 수백만 개의 항목으로 구성된 컬렉션을 다루는 AccountsDB에서 일한다면 단순히 코드를 작성하는 것으로 끝나지 않습니다. 알고리즘을 만들고 대규모 데이터세트를 효율적으로 다루는 것은 어렵습니다. 

그래서 때때로 성능 회귀가 발생합니다. 한 달 전까지만 해도 저는 사실상 모두에게 소리를 질렀습니다, 하하. AccountsDB를 담당하는 Brooks는 한때 저를 싫어했을 겁니다. 지금은 사이가 아주 좋지만, 한 달 전까지만 해도 대화의 절반은 AccountsDB의 무언가가 느려졌다며 제가 그에게 소리치는 내용이었습니다.

프로토콜 측면에서는 Firedancer와 협업하면서 상황이 나아졌습니다. 프로토콜의 여러 부분이 다양한 문제에 대응하는 과정에서 유기적으로 커진 것 같습니다. 프로토콜 개발은 하나의 아이디어에서 시작했습니다. 프로덕션에 적용했지만 대부분의 아이디어가 그렇듯 처음부터 작동하지는 않았습니다. 그래서 그 위에 무언가를 계속 추가하기 시작했습니다. 그 위에 추가된 것 중 상당수는 성능 측면에서 정말 나쁜 아이디어였습니다.

예를 들어 Gossip에는 epoch slots라는 기능이 있었습니다. 클러스터가 어떤 검증인이 어떤 슬롯을 확인했는지 사실상 모든 참여자에게 브로드캐스트하는 방식이었습니다. 그런데 6개월 전쯤 다른 것을 프로파일링하다가 우연히 이 epoch slots가 CPU 기준으로 실제 트랜잭션 실행보다 더 많은 시간을 차지한다는 사실을 발견했습니다. 대역폭 기준으로는 Turbine이 사용하는 대역폭의 4배를 차지했습니다. 과거 어느 시점에 문제를 완화하려고 프로토콜 위에 만든 임의의 패치일 뿐입니다.

이제는 이런 일이 일어나지 않습니다. 어느 정도는 Firedancer 덕분입니다. 이제 누군가 제안을 내놓으면 Firedancer와 협업해야 합니다. 당연히 그들은 다른 클라이언트를 만들고 있으므로, 하하, 작업 예산을 잡아야 합니다. 이 제안을 구현하는 데 얼마나 걸릴지, 우선순위는 무엇인지 결정해야 합니다. 그래서 좋든 나쁘든 이의를 제기합니다. 우리가 진행하는 변경 사항 대부분, 거의 전부에 이의를 제기합니다. 특히 아주 나쁜 변경 사항에 이의를 제기하는 데 탁월합니다. 

Turbine에 XDP가 적용된 뒤 회의도 충돌도 없이 한 달 동안 무엇이든 자유롭게 작업할 수 있다면, Agave에서 가장 먼저 최적화하거나 아키텍처를 재설계할 부분은 어디인가요? 

정말 하고 싶습니다. 말 그대로 꿈까지 꿉니다. 약 2년 동안 AccountsDB를 다시 작성하고 싶었습니다. 하지만 시작하면 말 그대로 제 인생에서 한두 달이 사라질 거라는 사실을 압니다. 지금은 제 시간을 쓰는 최선의 방법이 아닙니다. 그래도 언젠가는 할 겁니다. Brooks가 하도록 계속 압박하고 있지만, 그가 하지 않으면 언젠가 제가 할 겁니다.

향후 개발

비동기 실행이나 다중 동시 리더처럼 예정된 기능을 고려할 때, 성능 팀에 가장 큰 골칫거리는 무엇일까요? 

본능적으로 비동기 방식을 싫어합니다. 현재 모델은 매우 단순합니다. 트랜잭션을 받아 아주 빠르게 리플레이한 뒤 투표합니다. 개념적으로 매우 쉽습니다. 비동기 방식은 설계를 더 어렵게 만들지만 실제 체인 사용 경험은 훨씬 개선합니다.

다중 동시 리더 설계도 싫어합니다, 하하. 특히 초고속 트레이딩을 하려면 여러 리더가 필요하다는 점은 이해합니다. 대안이 없습니다. 하지만 개인적으로는 적어도 12개월 동안 실현되지 않을 기능입니다. 그래서 너무 신경을 빼앗기고 싶지 않습니다.

1년 안에 Alpenglow를 완성하는 것도 중요하지만, 다음 달에 1억 CU를 처리하는 것도 중요합니다. Alpenglow도 새로운 코드이고 다중 동시 리더도 새로운 코드이므로 지금 가진 것을 빠르게 만드는 데 집중해야 합니다. 우리가 모른다는 사실조차 모르는 변수가 있습니다. 어떤 이유로든 Alpenglow의 일정이 Firedancer처럼 늦어진다고 해 보겠습니다. 그러면 어떻게 할까요? 지금처럼 형편없고 느린 체인을 계속 사용해야 할까요? 아닙니다. 오늘 더 빨라지는 데 집중해야 합니다.

성능 엔지니어링에 관한 조언

Rust 경험이 있고 성능 코딩과 프로파일링을 시작하려는 사람에게 어떤 자료를 추천하시나요?

우선 좋은 프로파일러를 사용하라고 권하고 싶지만, 지금은 그런 것이 없습니다, 하하. 그래도 곧 제 프로파일러를 공개할 수 있기를 바랍니다. 그리고 무엇이든 가장 잘 배우는 방법은 자신이 진심으로 관심 있는 대상에 직접 적용해 보는 것이라고 생각합니다.

성능 작업을 배우려는 사람에게 드리는 조언은 매일 사용하고 좋아하는 소프트웨어를 찾아 프로파일링하고 더 빠르게 만들어 보라는 것입니다. 많은 소프트웨어가 매우 느립니다. 빠른 소프트웨어도 훨씬 더 빨라질 수 있습니다. 컴퓨터는 정말 빠릅니다. 워낙 빠르기 때문에 느린 작업을 만들어 놓고도 알아채지 못하기가 매우 쉽습니다.

많은 사람이 빠져드는 과정을 보면 자신이 사용하는 것을 찾아 프로파일링하고, 더 빠르게 만든 뒤 풀 리퀘스트를 보냅니다. 장담하는데 받아들여질 겁니다. 완전히 빠져들게 될 것입니다.

커널도 다른 의존성과 다르지 않습니다. 무언가를 작업하며 라이브러리를 사용하고 있다면, 제대로 작동하지 않거나 느릴 때 어느 순간 그 라이브러리의 내부를 살펴봐야 할 가능성이 큽니다. 커널도 또 하나의 라이브러리일 뿐입니다. 그러니*,* 커널 코드를 읽으세요. 커널 코드는 제가 본 코드 중에서도 가장 단순한 편입니다. 커널의 스케줄러를 보면 개념적으로 Solana의 스케줄러보다 단순합니다. 

그냥 Linux 코드를 읽어 보세요. C라는 점은 이상적이지 않고, 하드웨어를 건드리는 모든 부분은 보통 저주받은 코드 같지만, 하하, Solana의 대부분은 하드웨어와 직접 상호작용하지 않습니다. syscall이나 Tokio, 파일 시스템 코드처럼 매일 사용하는 범용적인 부분을 찾아보세요. 아주 쉽습니다. 그냥 읽으세요. 일주일 동안 읽으면 다른 코드처럼 익힐 수 있습니다. 그러면 자신이 엄청난 천재처럼 느껴질 겁니다. 이제 커널 작업도 할 수 있겠다고 생각하게 되죠.

지금 기여를 시작하는 가장 좋은 방법은 무엇인가요?

저는 Discord에 접속해 Solana Tech Discord의 개발 채널에 참여하는 방법을 선호합니다. 예를 들어 네트워킹 관련 작업을 하던 한 사람이 며칠 전 TPU 코드에 관한 대화를 시작했습니다. 솔직히 그 코드를 이해하는 수준이 Anza의 대부분 사람보다 높습니다. 누구나 기여할 수 있습니다. 그 사람만큼 뛰어나고 제게 패치를 보내면 바로 병합하겠습니다.

비공개 내부 개발은 많이 하지 않습니다. 잘 알고 있고 느리다고 생각하며*,* 수정하고 싶은 코드에 풀 리퀘스트가 보이지 않는다면 Discord에서 제게 알려 주세요. 이슈를 만들고 담당자로 지정하겠습니다. 그러면 직접 수정하면 됩니다.

사람들이 제게 패치를 보내면 좋겠습니다. 패치를 보내는 방식으로 커뮤니티를 키우고 싶습니다.

단답형 질문

올해 해결한 버그 중 가장 어려웠던 것은 무엇인가요?

불과 몇 달 전 2.2 릴리스를 막고 있던 일부 부동 소수점 코드의 잘못된 컴파일 문제였습니다. 가장 어려운 문제는 아니었지만 며칠 동안 Assembly 코드만 읽어야 해서 가장 지루했습니다.

플레임 그래프를 들여다볼 때 반복해서 듣는 음악은 무엇인가요? 

보통 하우스나 미니멀 테크노를 듣습니다. Stephan Bodzin을 주로 반복 재생합니다.

가장 좋아하는 Linux 배포판은 무엇인가요? 

단연 Debian입니다. 엄청나게 귀찮지 않은 유일한 배포판입니다, 하하.

Alpenglow에서 제공될 최고의 최적화는 무엇인가요? 

투표를 실행하지 않게 되는 것입니다. 투표 트랜잭션은 [삭제됨]입니다. 투표 전체가 더 이상 트랜잭션이 아니라는 점이 정말 좋습니다.

ZK에 대해서는 어떻게 생각하시나요? 

훌륭한 기술이지만 블록체인 확장 측면에서는 여전히 연구 단계에 가깝다고 생각합니다. 그래서 큰 관심은 없습니다. 

지금부터 1년 뒤인 2026년 7월의 슬롯 시간을 예측한다면요?

개인적으로는 그보다 더 빨리 200밀리초 슬롯을 달성하고 싶습니다. Toly에게 밈으로 만들어 현실화해야 한다고 계속 말하고 있습니다. 그때까지는 실현되기를 바랍니다. 지금도 가능하다고 생각합니다. 그보다 긴 시간은 실패라는 의미에서 200밀리초가 최소 기준이라고 생각하지만, 더 낮출 수도 있습니다.

Agave가 운명처럼 예고된 100만 TPS를 달성하는 때는 언제일까요? 

하하, 그 질문에는 단답으로 답하지 않겠습니다. 저는 계속 사람들에게 “100만 건의 트랜잭션이 어디에서 나올까요?”라고 묻습니다.

사람들이 보낼 100만 TPS가 생기면 우리도 100만 TPS를 처리할 겁니다. 하지만 안타깝게도 조만간 일어날 것 같지는 않습니다. Agave가 10월까지 100만 TPS를 달성하지 못하면 회사를 그만두겠다고 말한 적이 있습니다. 그러니 엉터리 데모라도 만들어야 할지 모르겠네요, 하하. 

결론

Alessandro Decina는 Solana 성능 문화의 고동치는 심장과도 같습니다. 이론적 완벽함이 아니라 실용적인 엔지니어링을 바탕으로 끊임없이 속도를 추구합니다. 그의 성능 팀은 규모를 훨씬 뛰어넘는 성과를 냅니다. 누적되어 시스템 전체의 속도를 떨어뜨리는 “어이없는 버그”를 찾아 수정합니다.

많은 팀이 거대한 아키텍처 비전에 빠져 길을 잃는 세상에서 Anza 성능 팀은 바로 눈앞의 병목에 집중합니다. 프로파일링하고, 식별하고, 수정하고, 반복합니다. 화려하지 않은 작업이지만 화려한 결과를 만듭니다. 하드웨어를 우회하는 대신 하드웨어와 함께 실제로 확장되는 블록체인을 구현합니다.

위 대화는 고성능 시스템 구축에 관한 근본적인 진실을 보여 줍니다. 속도는 영리한 알고리즘이나 최첨단 하드웨어만으로 달성되지 않습니다. 기술적으로 “탁월함”을 달성할 수 있다면 “이 정도면 충분하다”는 수준을 결코 받아들이지 않는 문화적 의지가 필요합니다. Solana에서 200밀리초 슬롯, 비동기 실행, 다중 동시 리더, 100만 TPS 이상의 지속적인 처리는 단순한 기술적 이정표가 아닙니다. 필연적으로 실현될 미래입니다.