이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
최근 관심을 갖고 공부한 기술은 React Server Components였습니다. 클라이언트 번들에 포함되지 않으면서 서버에서 직접 데이터를 패치하는 구조가 기존 CSR/SSR 방식과 어떻게 다른지 직접 실습하며 파악했습니다.
또한 Edge Runtime 환경도 살펴봤습니다. 데이터센터가 아닌 사용자 근처 엣지에서 코드가 실행되면 레이턴시가 줄어드는 구조가 흥미로웠고, Cloudflare Workers로 간단한 API를 배포해 응답 시간을 비교했습니다.
WebAssembly는 브라우저에서 네이티브에 가까운 성능을 내는 방식이 신기해서 공부 중입니다. Rust로 작성한 함수를 WASM으로 컴파일해 브라우저에서 호출하는 흐름을 따라해봤는데, JavaScript로는 어려운 연산 집약적 작업에 활용할 수 있다는 가능성을 확인했습니다.
React Server Components를 실습하면서 단순히 빠르다는 것 외에 어떤 트레이드오프가 있는지까지 이해하려고 했습니다. 서버 컴포넌트는 클라이언트 번들 크기를 줄일 수 있지만, 인터랙티브 상태가 필요한 컴포넌트는 클라이언트 컴포넌트로 분리해야 하는 경계 판단이 계속 필요하다는 것을 직접 구현하면서 체감했습니다. Edge Runtime도 응답 속도 이점이 있지만, Node.js API 전체를 쓸 수 없다는 제약이 있어서 기존 라이브러리와 호환성을 먼저 확인해야 한다는 것을 알았습니다. 이 기술들을 실제 프로젝트에 적용한다면 초기 로딩 성능이 중요한 콘텐츠 페이지에는 RSC가 유효하고, 전 세계에 분산된 사용자에게 낮은 지연시간이 필요한 API에는 Edge Runtime이 적합하다는 기준을 정리했습니다.
신기술을 공부할 때 장점만 보는 것보다 어떤 상황에 맞고 어디서는 맞지 않는지를 함께 파악해야 실제로 쓸 수 있다는 것을 이 경험에서 배웠습니다.
WebAssembly를 공부하게 된 계기는 JavaScript로는 처리가 너무 느려서 다른 방법이 필요했던 경험이었습니다. 이미지 필터링 알고리즘을 JavaScript로 구현했는데 60fps를 유지하지 못했고, Rust로 동일 알고리즘을 작성해 WASM으로 컴파일한 뒤 브라우저에서 호출했습니다.
같은 알고리즘을 JavaScript로 실행했을 때와 WASM으로 실행했을 때 처리 시간을 직접 비교했는데, 연산 집약적인 구간에서 차이가 눈에 띄었습니다. WASM이 만능은 아니라는 것도 확인했습니다. DOM 조작이나 네트워크 요청이 많은 경우는 WASM이 오히려 JavaScript보다 번거롭고, 연산 자체가 병목인 경우에만 WASM이 의미 있다는 것을 실습하면서 이해했습니다. 지금 하는 작업에 연결하자면, 클라이언트에서 무거운 데이터 처리가 필요한 경우 WASM을 선택지로 고려할 수 있다는 기준이 생겼습니다.
브라우저에서 성능이 필요한 연산은 언어 선택지가 JavaScript에만 국한되지 않는다는 것을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.