안녕하세요 여러분. 저처럼 솔라나 생태계에 깊숙이 발 담그고—고속 트랜잭션을 좇고 인터넷 자본시장을 꿈꾸는 사람이라면—Jito의 최신 산물인 BAM 얘기를 한 번쯤은 들어봤을 겁니다. Block Assembly Marketplace의 약자 BAM은 솔라나에서 블록을 구성하는 방식을 표준화하고 탈중앙화하려는 Jito의 과감한 시도입니다. 그런데 혁신이 클수록 회의론도 큽니다. BAM이 정말로 탈중앙화의 탈을 쓴 중앙화된 늑대일까? 성능을 저하시켜 검증인 보상을 깎아먹는 건 아닐까?

바로 이 지점에서 Jito의 공식 X 계정의 스레드가 요긴하게 다가옵니다. @0xMert의 스틸맨 접근법—상대 주장의 가장 강한 형태를 호의적으로 재구성한 뒤 그것을 반박하는 기법—을 차용해 Jito 팀은 BAM에 대한 가장 강한 비판들을 정면으로 다룹니다. 방어적 태도가 아니라 솔라나의 미래를 더 깊이 고민하자는 초대입니다. 자, 하나씩 신화별로 풀어봅시다. (기술적인 부분도 조금 섞어 설명할게요.)

오해 1: BAM은 사실상 중앙화된 sequencer이며 블록 빌딩 독점

거대한 문제 하나: 트랜잭션 순서를 한 곳이 모두 결정하는 단일 실패 지점은 아무도 원치 않습니다. 우려는 BAM이 모든 걸 Jito가 통제하는 시스템으로 흡수해 솔라나의 다양한 스케줄러 생태계를 지루한 독점으로 바꾸는 것이라는 점입니다.

스틸맨 현실: Jito도 그 우려를 이해합니다—분명 무섭게 들리죠. 하지만 BAM은 처음부터 탈중앙화를 염두에 두고 설계됐습니다. 2026년 1분기부터 코드베이스는 완전한 오픈소스가 되어 자격을 갖춘 운영자는 누구나 자신만의 BAM Node를 띄울 수 있습니다. 전 세계에 분산된 노드, 암호학적 증명으로 검증 가능한 스케줄링 등으로 구성될 예정입니다. 지금은 Jito가 주도하고 있지만 그건 단지 출발점일 뿐입니다. 잠긴 문이 아니라 선택 가능한 개방성입니다.

오해 2: 검증인들은 하나의 스케줄러에 묶여 혁신이 죽는다

상상해보세요: 당신은 검증인이고 커스텀 스케줄러를 만지작거리거나 A/B 테스트를 하며 도구를 자유롭게 바꾸는 걸 좋아합니다. 그런데 BAM이 들어오면—짠!—Jito의 획일적인 방식에 묶여 버려요. 더 이상 실험은 없고 기업의 지시만 따르는 상황이라는 거죠.

스틸맨 현실: 자유가 우선입니다, 항상. BAM은 100% 옵트인(opt-in)입니다. 마음이 변하면 언제든지 연결을 끊고 Agave, Jito-Solana, 혹은 새로운 Firedancer 클라이언트로 돌아갈 수 있습니다. 벤더 락인은 없습니다. BAM을 선택하는 이유는 명확합니다—DeFi 같은 고위험 애플리케이션이 요구하는 결정론적이고 투명한 주문체계를 제공합니다. 개발자들이 BAM Plugins로 혁신할 수 있는 플러그앤플레이 플랫폼으로 생각하면 네트워크 전체를 향상시키되 강제하지는 않습니다.

오해 3: BAM이 모든 orderflow를 독점해 경쟁을 밀어낸다

Orderflow는 솔라나의 생명줄—공개된 mempool에서 트랜잭션이 자유롭게 섞입니다. 비판론자는 BAM이 이 모든 것을 사유 파이프라인으로 빨아들여 Jito에 무적의 해자를 만들어준다고 말하죠. 새로운 경쟁자는 그 벽을 깨기 어렵다는 겁니다.

스틸맨 현실: 전혀 그렇지 않습니다. BAM은 솔라나의 표준 TPU(Transaction Processing Unit) 프로토콜과 호환됩니다. 모든 tx는 공개적이며 "BAM 전용" 차선은 없습니다. 검증인들은 동일한 orderflow를 받고, 다만 공정하고 검증 가능한 레이어를 통해 스케줄링됩니다. 기본 TPU로 즉시, 비용 없이 되돌아가는 것도 가능합니다. 이는 다른 체인들에서 사유 흐름이 mempool을 유령 도시로 만드는 파편화를 방지합니다.

오해 4: 추가 지연? BAM이 빠른 트랜잭션에 불필요한 홉을 더한다

솔라나의 핵심은 속도입니다: 트랜잭션은 거의 우회 없이 리더의 TPU로 바로 전달됩니다. BAM을 중간에 끼워 넣으면 갑자기 지연이 생기고, 한 번의 DDoS로 시스템이 곤두박질할 수 있다는 걱정이 나옵니다. 왜 리스크를 감수하느냐는 거죠.

스틸맨 현실: 속도에 민감한 분들 걱정 노노. BAM의 글로벌 네트워크는 100개 이상의 노드를 가지고 있고 검증인과 공동 배치(co-located)되어 왕복 시간이 5ms 미만입니다. thread pinning과 TEE(Trusted Execution Environments)에서의 CPU 격리로 조율되어 현재 Agave와 동등한 성능을 냅니다. DoubleZero 마이그레이션이 완료되면 베어메탈 벤치마크를 능가할 것으로 예상됩니다. 홉을 추가하는 게 아니라 고속도로를 정리하는 방식입니다.

오해 5: 보상이 감소한다—검증인에게 팁이 줄어든다

누가 자기 수입을 깎는 스케줄러를 원하겠습니까? 초기 도입자들은 BAM의 로직이 다른 더 높은 보상의 대안보다 팁을 제한할 수 있다고 불평합니다. Plugin 수수료가 아직 완전히 활성화되지 않은 상황에서 이론적 이익보다 당장 손해가 크다는 얘기죠.

스틸맨 현실: 장기적 관점이 중요합니다. BAM의 수익률은 이미 Jito-Agave와 어깨를 나란히 하고 있으며, 예전의 수탈적 기법(예: sandwiching)은 점점 사라지고 있습니다. 진짜 수익원은 Plugins와 ACE(Application-Controlled Execution)를 통해 폭발하는 온체인 활동에서 새로 열리는 수수료 흐름입니다. 단발성 카지노식 수익이 아니라 지속 가능한 성장입니다.

오해 6: 스테이커들은 즉시 최대 수익을 요구한다—BAM이 검증인 유출을 초래한다

스테이커들은 수익에 민감합니다. 한 에포크만 보상이 하락해도 스테이크는 더 높은 수익으로 이동합니다. 초기 BAM 도입자들이 손해 보는 동안 지연된 자들이 이득을 본다는 우려가 있습니다.

스틸맨 현실: 단기 수익 극대화는 기본입니다. 하지만 시야를 넓혀보면 slot-lagging 같은 단기 해킹은 신뢰를 훼손하고 지연을 증가시키며 유동성을 멀어지게 합니다. BAM은 더 깊은 마켓과 더 좁은 스프레드를 조성함으로써 이를 방지합니다. 앱들이 성장할 때 이를 믿고 베팅한 검증인들이 큰 수혜를 봅니다—팁 몇 페니가 아니라 수십억 달러 단위의 거래량을 생각해보세요.

오해 7: ACE는 과잉 설계다—우선 수수료(priority fees)로 충분하다

솔라나 앱들은 우선 수수료와 팁으로 잘 돌아갑니다. 왜 ACE로 앱이 주문을 지시하게 해 복잡하게 만드느냐는 비판이 있습니다. 편애와 개발자 불평등을 초래할 수 있다는 거죠.

스틸맨 현실: 기본적인 경우엔 맞습니다—수수료로도 충분한 경우가 많습니다. 하지만 파워 유저들(퍼프, 청산 등)은 cancel-priority 같은 확실한 보장이 필요합니다. Hyperliquid을 보세요: permissioned ordering 덕분에 솔라나의 perp 거래량 대비 10–15배에 달하는 거래가 이뤄졌습니다. ACE가 없다면 이런 앱들은 맞춤형 L1s/L2s로 떠나버립니다. BAM의 ACE는 솔라나를 경쟁력 있게 유지하면서 모두의 수준을 끌어올립니다.

오해 8: FIFO(선입선출)가 공정성의 황금 기준이다

First in, first out—단순하고 직관적이며 성실 기반입니다. 줄 서서 먼저 온 사람부터 처리하는 거죠. 더 복잡한 방법은 모두 '돈 내고 앞질러 가기' 같은 엘리트주의로 보입니다.

스틸맨 현실: FIFO는 트래픽이 적은 이상향에서는 빛을 발합니다. 하지만 수요가 폭증하면 상황은 달라집니다—스팸 전쟁, 지연 경쟁에 돈을 태우는 레이턴시 레이스, 모두를 질식시키는 큐가 발생합니다. 또한 애플리케이션별 요구(예: 원자적 번들)를 무시합니다. BAM은 혼잡을 완화하면서 맞춤형 로직을 가능하게 해 네트워크 규모에서 더 공정한 결과를 만들어냅니다.

오해 9: TEE는 공격의 시한폭탄이다

TEE? 하드웨어 인클레이브는 멋지게 들리지만 사이드채널 공격, 펌웨어 버그, 공급망 문제 같은 위험이 큽니다. 한 번의 익스플로잇이면 BAM은 끝장이라는 우려, Intel/AMD 같은 벤더에 코드보다 하드웨어를 신뢰하는 게 위험하다는 주장입니다.

스틸맨 현실: 보안은 최우선입니다. BAM은 ISO 27001/SOC 2 준수 데이터센터에서 AMD SEV-SNP를 활용하고, 원격 증명(remote attestations)으로 각 부팅 과정을 증명합니다. 최악의 시나리오에서는 손상된 노드가 주문 프라이버시를 잃을 수 있지만 검증인 키는 안전하며 체인의 불변성은 유지됩니다. 검증인들은 직접 하드웨어 스택을 검토할 수 있습니다—맹목적 신뢰 대신 투명성을 제공합니다.

휴—전체 스레드를 다 풀어봤습니다. Jito는 비판을 피하지 않고 정면으로 맞서며 BAM을 솔라나가 필요로 하는 검증 가능한 마켓플레이스로 제시하려 합니다. MEV 남용을 억제하고 애플리케이션 제어 실행을 여는 것까지, 블록 빌딩 시대를 더 공평하게 만드는 한 걸음입니다. 정말로 수십억이 BAM해야 할지도 모릅니다.

솔라나 위에서 빌드 중이거나 그냥 암호화폐 밈으로 즐기고 있다면, 자세한 내용은 전체 블로그를 확인해 보세요. 여러분의 의견은? BAM 지지자인가요, 아니면 신중한 관찰자인가요? 댓글로 남겨주세요. 혹시 FOMO가 생겼다면 MEV 혜택을 위해 Jito에 stake하세요. 탈중앙화를 지키세요, 여러분.

원문 영감: 2025년 12월 3일자 Jito의 X 스레드.