제목
RISC-V 시대, 아키텍처를 모르는 개발자는 3년 뒤 도태됩니다.
솔직히 고백하자면, 스타트업에서 '야생형 개발자'로 구르던 시절에는 CPU 아키텍처따위 신경 쓸 겨를이 없었습니다. 당장 내일 배포할 기능 구현이 급했고, 서버가 느리면 AWS 인스턴스 사양을 올리는 '금융 치료'로 해결했으니까요. 하지만 대기업으로 이직하고 대규모 트래픽과 비용 효율화를 마주하면서, 제가 얼마나 안일했는지 뼈저리게 느꼈습니다. 특히 최근 V8 엔진의 RISC-V 포팅 과정을 뜯어보며 등골이 서늘해지는 경험을 했습니다. 단순히 코드를 짜는 것을 넘어, 코드가 하드웨어 위에서 어떻게 도는지 이해하지 못하면 결코 '시니어'라는 타이틀을 달 수 없다는 사실을 깨달았기 때문입니다.
최근 RISC-V용 V8 개발 현황을 살펴보면, 우리가 흔히 접하는 고수준 언어(JavaScript)가 저수준 하드웨어와 어떻게 치열하게 싸우고 있는지 적나라하게 보입니다. 가장 흥미로웠던 건 'Pool' 관리 방식의 변화였습니다. V8은 점프 명령어를 처리할 때 거리가 멀어지면 'Trampoline pool'이나 'Constant pool'을 사용합니다. 예전에는 이 풀(Pool)들이 코드 중간중간에 끼어들어 서로의 위치에 영향을 주는 바람에, 이를 계산하는 로직이 끔찍하게 복잡했습니다. 마치 스파게티처럼 꼬인 레거시 코드와 다를 바 없었죠.
그런데 최근 개발팀은 32비트 오프셋을 활용해 코드 생성이 끝난 뒤에야 Constant pool을 배치하도록 구조를 뜯어고쳤습니다. 이 변화가 주는 교훈은 명확합니다. 복잡한 로직을 단순화하니, 상수 데이터를 실행 불가능(non-executable) 영역으로 격리할 수 있게 되어 보안성까지 확보했다는 점입니다. 우리가 비즈니스 로직을 짤 때 '관심사의 분리'를 외치는 이유가, 하드웨어 레벨에서도 똑같이, 아니 더 절실하게 적용되고 있었던 겁니다.
더 충격적이었던 건 WebAssembly(Wasm) 구현에서 발견된 레이스 컨디션(Race Condition) 버그였습니다. 멀티스레드 환경에서 점프 테이블을 패치할 때, auipc와 jalr 두 명령어 사이에 미세한 틈이 발생했습니다. 메모리는 원자적으로 써졌지만, CPU가 첫 번째 명령어를 실행하고 두 번째 명령어를 실행하기 직전에 코드가 업데이트되면 엉뚱한 곳으로 튀어버리는 문제가 있었던 거죠.
이 사례를 보며 저는 과거에 DB 트랜잭션 격리 수준을 제대로 설정하지 않아 데이터를 오염시켰던 제 실수가 떠올라 얼굴이 화끈거렸습니다. V8 팀은 이를 해결하기 위해 타겟 주소를 메모리에서 한 번에 로드하거나, 거리가 가까우면 jal 명령어를 사용하는 방식으로 패치 시퀀스를 변경했습니다. 동시성 문제는 자바 스프링(Spring) 레벨에서만 일어나는 게 아니라, CPU 명령어 파이프라인 레벨에서도 치명적일 수 있다는 사실을 다시금 확인했습니다.
성능 최적화 부분도 인상 깊습니다. RISC-V의 Zba 확장에 포함된 shxadd나 zext.w 같은 명령어를 적극 도입하면서, 주소 계산이나 포인터 압축 해제에 드는 명령어 수를 절반 이하로 줄였습니다. 특히 zext.w를 사용해 5개의 명령어를 2개로 줄인 사례는, 막대한 트래픽을 처리하는 시스템에서 티끌 같은 최적화가 얼마나 큰 리소스 절감으로 이어지는지 보여줍니다.
저는 요즘 Cursor나 Claude 같은 AI 도구를 활용해 이런 로우 레벨 변경 사항들을 분석하며 공부하고 있습니다. AI가 코드를 짜주는 시대에 개발자가 살아남는 방법은, AI가 짠 코드가 기계 위에서 어떻게 작동하는지 검증하고 최적화할 수 있는 '깊이'를 갖추는 것뿐이라고 생각합니다. RISC-V 지원이 메인 V8 저장소로 upstream 되고 안정화되었다는 것은, 이제 다양한 아키텍처가 서버 시장에 들어온다는 신호탄입니다. "나는 백엔드 개발자니까 몰라도 돼"라고 생각하신다면, 죄송하지만 그 안일함이 당신의 커리어에서 가장 큰 기술 부채가 될 것입니다. 지금이라도 하드웨어와 소프트웨어의 경계면을 들여다보세요. 그곳에 진짜 성장의 열쇠가 있습니다.
