React를 오래 써온 개발자라면 두 가지 불편함에 익숙하다. 하나는 렌더링마다 가상 DOM(VDOM) 트리를 만들고 비교하는 런타임 비용이고, 다른 하나는 useEffect의 의존성 배열이나 '훅 규칙(rules of hooks)'처럼 사람이 손으로 지켜야 하는 제약이다. Octane은 이 두 층위를 모두 겨냥한다. 슬로건은 간결하다. 'React의 프로그래밍 모델을, 사전에 컴파일한다.' 즉 개발자가 쓰는 코드의 표면은 React와 거의 같지만, 그 실행 방식은 빌드 시점에 결정되어 VDOM과 훅 규칙 없이 동작하도록 바뀐다.
훅 규칙과 의존성 배열이 사라지는 이유
Octane의 핵심은 컴파일러가 코드를 정적으로 분석해 effect·memo·callback이 실제로 무엇을 참조하는지 추적한다는 점이다. 이 덕분에 의존성 배열을 직접 나열할 필요가 없어진다. React에서 의존성 배열은 오래된 값을 붙잡는 버그(stale closure)와 불필요한 재실행의 온상이었고, 이를 검사하는 린트 규칙까지 별도로 존재했다. 컴파일러가 참조 관계를 스스로 파악하면 이 수작업이 통째로 없어진다.
같은 맥락에서 훅을 조건문이나 이른 반환(early return) 뒤에 둘 수 있게 된다. 기존 React는 훅이 항상 같은 순서로 호출된다는 전제 위에서 상태를 추적했기 때문에, if 안에서 훅을 부르는 것을 금지했다. Octane은 이 전제를 컴파일 단계로 옮기면서 제약을 푼다. 다만 이것이 '아무렇게나 써도 된다'는 뜻은 아니다. 컴파일러가 분석 가능한 형태로 코드를 짜야 그 이점을 얻는다는 조건이 남으며, 정적 분석이 놓치는 동적 패턴에서 어떻게 동작하는지는 실제 도입 시 검증이 필요한 지점이다.
데이터 로딩과 SSR: 병렬성이 기본값
Octane이 강조하는 또 다른 축은 비동기 처리다. 서로 독립적인 use() 호출들이 트리를 따라 하나씩 순차적으로 서스펜드되는 대신 함께 시작된다. React의 Suspense는 편리하지만, 부주의하게 쓰면 컴포넌트 트리를 내려가며 요청이 폭포수(waterfall)처럼 직렬화되어 지연이 쌓이는 문제가 잘 알려져 있다. Octane은 중첩된 fetch를 미리 예열(warm up)해 이 폭포 현상을 줄이려 한다.
스트리밍 SSR도 같은 철학을 따른다. 각 Suspense 경계(boundary)를 준비되는 즉시 전송하므로, 느린 데이터 하나가 전체 페이지 응답을 붙잡지 않는다. 사용자 입장에서는 화면의 준비된 부분부터 순차적으로 그려지고, 서버 입장에서는 응답을 더 잘게 흘려보낼 수 있다. 이는 초기 로딩 체감 속도와 직결되는 실무적 이점이다.
렌더링과 점진적 도입
렌더링 계층에서는 템플릿이 복제 가능한 노드(cloned node)와 직접적인 DOM 쓰기로 컴파일된다. VDOM 비교 과정을 거치지 않고 필요한 지점을 곧바로 갱신하는 방식으로, Svelte나 SolidJS 같은 컴파일 기반 프레임워크가 취해온 접근과 결이 같다. 키를 지정한 @for 리스트는 갱신 시 가장 적은 수의 노드만 이동시키도록 최적화된다고 설명한다. 목록 렌더링에서 불필요한 재배치는 성능과 애니메이션 깨짐의 흔한 원인이므로, 이 최적화의 실측 효과는 눈여겨볼 만하다.
도입 방식에서 현실적인 배려가 보인다. 기존 .tsx 파일이 그대로 동작하고, 새로운 .tsrx 형식을 컴포넌트 단위로 하나씩 채택할 수 있다. 프레임워크 전환에서 가장 큰 장벽은 '전부 다시 써야 한다'는 부담인데, 점진적 마이그레이션 경로를 제공한다는 점은 기존 React 코드베이스를 가진 팀에게 실질적인 진입 문턱을 낮춘다.
익숙함을 유지하려는 설계
Octane은 훅, memo, context, 포털(portal), 트랜지션, 액션, 제어 컴포넌트 폼, Suspense가 기대한 대로 동작한다고 밝힌다. 이벤트는 네이티브이고, ref는 별도 개념이 아니라 그냥 prop이며, 이미 쓰고 있는 라이브러리를 위한 53개의 1차 바인딩을 제공한다고 한다. 이는 새 패러다임을 들이밀기보다 React의 멘탈 모델과 생태계를 최대한 보존하려는 전략으로 읽힌다.
정리하면 Octane은 'React처럼 쓰되 컴파일러가 뒤를 봐준다'는 방향의 시도다. 다만 현재 공개된 정보는 프레임워크가 표방하는 설계 목표와 특성에 가깝고, 실제 프로덕션 규모에서의 성능 수치나 안정성, 53개 바인딩의 완성도, 컴파일러가 복잡한 동적 코드를 얼마나 견고하게 분석하는지에 대한 구체적 근거는 아직 이 소개만으로 판단하기 어렵다. React 생태계에 남으면서 런타임 오버헤드와 훅 규칙의 부담을 덜고 싶은 팀이라면, 작은 컴포넌트 하나를 .tsrx로 옮겨 직접 검증해보는 것이 합리적인 첫 단계가 될 것이다.