들어가며
안녕하세요, 카카오뱅크 프론트엔드 클랜의 Jake와 Dewey입니다.
2025년, 카카오뱅크에는 ‘프론트엔드 클랜’ 이라는 조직이 신설되었습니다. 저희는 클랜의 기술 방향성을 설정하고 글로벌 트렌드를 파악하기 위한 공식 활동의 일환으로 해외 컨퍼런스 참석을 계획하게 되었고, 어떤 곳에 참여할지 논의를 시작했습니다. 클랜의 목표인 ‘글로벌 프론트엔드 기술 트렌드 파악’에 가장 적합한 곳을 찾기 위해, 먼저 클랜 구성원들에게 다양한 컨퍼런스를 추천받았습니다.
추천받은 여러 컨퍼런스의 특성을 비교하며 신중하게 검토한 끝에, 저희는 React Summit US 2025를 최종 목적지로 결정했습니다. React는 전 세계적으로는 물론, 카카오뱅크의 웹 프론트엔드 영역에서도 가장 핵심적으로 사용되고 있는 라이브러리입니다. 따라서 해당 기술의 최신 아젠다를 가장 깊이 있게 다루어야 했고 이와 동시에 프론트엔드 클랜 차원에서 참여하는 만큼, React 생태계뿐만 아니라 순수 프론트엔드 기술 전반의 트렌드까지 폭넓게 파악할 수 있는 컨퍼런스가 필요했습니다. 이러한 두 가지 목적에 가장 완벽하게 부합하는 곳이 바로 React Summit US라고 판단했습니다.
💡 프론트엔드 클랜에 대한 더 자세한 내용은 🔗 여기에서 확인하실 수 있습니다.
이번 글에서는 뉴욕 컨퍼런스 현장에서 직접 체감한 생생한 기술 흐름을 정리하고, 인사이트를 얻었던 핵심 세션들을 공유하고자 합니다.
React Summit US 2025란?
React Summit US 2025는 전 세계 프론트엔드 및 풀스택 개발자들이 주목하는 주요 행사로, 2025년 11월 17일부터 21일까지 온·오프라인 하이브리드 형태로 개최되었습니다. 이번 행사에는 현장 참가자 약 800명, 온라인 참가자 1만 명 이상이 함께했습니다.
행사는 JSNation US와 연계하여 날짜별로 프로그램이 구성되었습니다. JSNation US는 ‘Community’와 ‘Residents’ 트랙으로, React Summit US는 ‘Summit’과 ‘Base Camp’ 트랙으로 나뉘어 진행되었습니다. 각 메인 트랙 외에도 연사와의 질의응답을 위한 Q&A 존과 참가자 간 자유로운 토론이 가능한 Discussion Room이 운영되어 깊이 있는 학습과 네트워킹을 지원했습니다.
오프라인 세션은 미국 뉴저지주 저지시티(Jersey City)에 위치한 리버티 사이언스 센터(Liberty Science Center) 에서 열렸습니다. 강연장은 크게 돔 형태의 플라네타리움(Planetarium)과 별도 강연장 두 곳으로 나뉘었습니다.
특히 메인 세션이 진행된 플라네타리움은 잊을 수 없는 경험을 선사했습니다. 반구형 천장 스크린을 가득 채운 웅장한 오프닝 영상과 발표 자료는 시각적으로 매우 신선했습니다. 다만, 천장 화면을 보느라 고개를 계속 젖히고 있어야 해서 목이 다소 뻐근하기도 했던 재미있는 기억이 남습니다.
GitNation: 기술적 중립성과 커뮤니티 중심의 컨퍼런스
이번 행사를 주최한 GitNation은 2015년 암스테르담의 작은 밋업에서 시작해, 현재는 오픈 소스 커뮤니티 지원과 기술 생태계의 다양성을 목표로 하는 글로벌 비영리 재단입니다.
GitNation 컨퍼런스의 가장 큰 특징은 ‘기술적 중립성’ 입니다. 특정 기업의 생태계 확장이나 제품 홍보가 주를 이루는 빅테크 기업 주최 행사와 달리, 이곳에서는 순수한 기술 토론과 다양한 관점의 발표가 자유롭게 이루어집니다. 특정 기술에 종속되지 않고 폭넓은 시각을 얻을 수 있다는 점, 이것이 저희가 GitNation의 컨퍼런스를 선택한 이유이기도 합니다.
인상 깊었던 세션
2일간의 컨퍼런스를 통해 프론트엔드 생태계의 세 가지 큰 흐름을 발견할 수 있었습니다. 첫 번째는 “프론트엔드 영역에서의 AI 실무 엔지니어링”, 두 번째는 “리액트 거버넌스의 변화와 재단의 역할”, 마지막으로 “추상화 속 변하지 않는 기본기의 중요성” 입니다. 이 흐름을 관통하는 주요 세션 일부를 소개해 드립니다.
1. Addy Osmani: 프론트엔드와 React, AI는 정말 ‘쓸 만’한가?
프론트엔드 개발자라면 친숙한 이름인 Addy Osmani가 이틀에 걸쳐 AI 활용에 대한 심도 있는 발표를 진행했습니다. “How Good is AI at Coding React (REALLY)?” 라는 도발적인 제목의 세션을 다섯 가지 핵심 포인트로 정리했습니다.
💡 이 세션의 내용은 이후 Addy Osmani가 자신의 블로그에 글로 정리하기도 했습니다. 🔗 링크
-
Vibe Coding vs AI-assisted(Agentic) Engineering: 단순히 ‘느낌(Vibe)’대로 코드를 생성하는 것과 엔지니어링은 다릅니다. 후자는 성숙한 소프트웨어 개발 수명 주기(SDLC, Software Development Life Cycle)에 AI를 방법론적으로 통합하는 것을 의미하며, 결과물에 대한 통제권과 최종 품질에 대한 책임이 엔지니어에게 있음을 강조합니다.
-
복잡도 절벽 (The Complexity Cliff): AI 모델의 성능은 작업의 격리 수준에 따라 비선형적으로 급격히 떨어집니다. 단일 컴포넌트 생성은 잘하지만, 기존 코드 베이스와의 통합, 복잡한 상태 관리, 비즈니스 로직 변경이 필요한 지점에서는 성공률이 급락하는데, 이를 ‘복잡도 절벽’이라 정의했습니다. 이는 모델이 복잡한 애플리케이션의 맥락을 완전히 파악하지 못하기 때문에 발생합니다.
-
Design Arena와 ‘Taste’의 부재: 크라우드 소싱 기반의 벤치마크 플랫폼인 Design Arena를 통해 확인한 결과, AI는 논리적인 구현에는 능숙하지만 ‘취향(Taste)’ 은 아직 갖추지 못했습니다. 즉, 동작은 하지만 유지보수가 어렵거나 투박한 결과물을 내놓을 수 있다는 뜻입니다.
-
실패의 원인: AI는 프로젝트의 전역 맥락(Global Context)을 알지 못하므로 아키텍처와 어긋나는 코드를 제안하곤 합니다. 이를 ‘맥락 결핍(Context Failure)’ 이라 표현했습니다. 다른 원인으로는 ‘설계 감각 부재(Lack of Taste)’를 이야기합니다. 이는 AI가 논리(Logic)적인 구현에는 강하지만, “좋은 설계”나 “미적 감각(Taste)”은 부족하므로 기능은 동작하더라도 유지보수가 어려운 구조를 만들거나 투박한 UI를 생성하는 경향이 있다는 의미입니다.
-
업무 흐름의 변화: 단순한 느낌에 의존해 코드를 생성하는 방식에서 벗어나 체계적인 엔지니어링 접근이 필요하다고 강조합니다. 이를 위해서는 코드를 바로 생성하기보다 설계를 우선하고(Plan First) 상세한 명세나 계획을 먼저 작성하게 해야 합니다.
결론적으로, 이 발표를 통해 전하고 싶은 중요한 메시지는 엔지니어의 역할 변화였습니다. 이제 코드를 직접 타이핑하는 것보다, AI에게 명확한 요구사항(Spec)과 맥락(Context)을 제공하고 결과물의 품질을 검수하는 설계자(Architect) 의 역할이 더욱 중요함을 강조하며, “도구는 변하고 업무는 진화하지만, 기회는 어느 때보다 큽니다” 라는 맺음말로 발표를 마무리했습니다.
2. 패널 토론: The Future of React and Its Ecosystem
컨퍼런스 발표 중간중간 여러 토론 세션도 있었습니다. 그중 가장 흥미로웠던 “리액트와 에코시스템의 미래” 에 대한 내용을 5가지 주제로 요약했습니다.
-
React 재단(Foundation) 출범과 거버넌스 변화: 그동안 Meta 내부에서 주도하던 의사결정이 React 재단을 통해 외부로 투명하게 공개됩니다. 단순히 행사 주최를 넘어, 핵심 라이브러리 기여자들에 대한 재정적 지원과 오픈소스 진입 장벽을 낮추는 역할을 맡게 됩니다.
-
React Compiler의 진정한 의미: 단순한 자동 메모이제이션 도구를 넘어, 개발자가 성능 최적화라는 반복적인 작업에서 벗어나 비즈니스 로직에만 집중할 수 있게 해주는 ‘렌더링 모델의 패러다임 변화’를 의미합니다.
-
AI 시대의 가이드라인: 프레임워크 작성자들은 이제 AI 모델이 올바른 코드를 생성할 수 있도록 지침(Instructions)과 평가 기준(Evals)을 명확히 제공해야 한다는 논의가 있었습니다.
-
기초 지식(Fundamentals)의 역설: 도구가 강력해지고 추상화(Magic)가 심화할수록, 문제가 발생했을 때 내부 원리(Under the hood)를 파악하는 능력은 더욱 중요해집니다. AI의 환각(Hallucination)을 검증하기 위해서라도 엔지니어의 기초 실력은 필수적입니다.
-
아키텍처의 딜레마: SPA, SSR, 스트리밍 등 다양한 옵션 중 ‘정답’은 없습니다. 현재 리액트 문서는 개념 설명에는 훌륭하지만, “실제 프로덕션 레벨에서 어떤 아키텍처를 선택할 것인가"에 대한 가이드가 더 보강되어야 한다는 지적이 있었습니다.
본 패널 토론을 통해 리액트 생태계를 이끌어가는 기술 리더들의 다양한 이야기를 들어볼 수 있어 좋았습니다.
3. Ken Wheeler: 언제나 바이브(Vibe)였다
개발자 커뮤니티의 뜨거운 감자인 “바이브 코딩(Vibe Coding)” 에 대해 켄 휠러(Ken Wheeler)가 유쾌하면서도 통찰력 있는 시각을 제시했습니다. 그는 AI에게 ‘느낌’으로 지시해 코드를 짜는 방식이 사실 우리가 늘 해오던 개발의 본질과 다르지 않다고 주장했습니다.
바이브 코딩의 재정의: 과거 개발자들이 구글과 Stack Overflow를 넘나들며 정보를 찾고 직관에 의존해 코드를 조합하던 과정 자체가 이미 “바이브"였습니다. AI는 그저 리서치와 타이핑을 도와주는 더 강력한 도구일 뿐입니다.
실패하지 않는 규칙: 하지만 “느낌"만으로 코딩하는 것은 위험합니다. 켄은 AI가 뻔뻔한 거짓말쟁이임을 상기시키며, 성공적인 활용을 위한 규칙을 제안했습니다. 특히 ‘자신이 뭘 말하는지 정확히 아는 도메인 지식’과 ‘생성된 모든 코드를 검증하는 책임감’ 이 필수적입니다.
결정론(Determinism)의 확보: AI를 워크플로에 제대로 통합하려면 명확한 맥락과 함께, AI가 특정 기능을 확실하게 호출할 수 있도록 잘 만들어진 ‘도구(Function Calling/Tools)’를 제공하여 결과의 예측 가능성을 확보해야 합니다.
실생활 속 사례: 켄은 직접 AI와 함께 만든 ‘나만의 디즈니 앱(칠면조 다리 찾기)’, ‘VR 사냥 지도’, ‘스마트 가든 프로젝트’를 소개했습니다. 특히 하드웨어 설계 오류를 직접 수정하고, 욕조에서 아이패드로 코딩해 정원 관리 시스템을 완성한 일화는 AI가 명확한 목표를 가진 개발자에게 얼마나 강력한 무기가 되는지 보여주었습니다.
결국 바이브 코딩은 AI에게 ‘알아서 해줘’라고 떠넘기는 요행이 아니라 전문가(엔지니어) 가 거짓말쟁이인 AI를 꼼꼼히 검증하고 통제해서, ‘언제 실행해도 의도한 대로 정확하게(결정론적)’ 작동하게 만드는 과정이라는 점이 인상 깊었습니다.
4. Alexander Lichter: 프론트엔드 파편화의 끝과 Rust
새로운 프로젝트를 시작할 때마다 수많은 도구(Linter, Formatter, Testing 등)를 선택하고 설정해야 하는 ‘선택의 피로(Decision Fatigue)’ 는 프론트엔드 개발의 고질적인 문제입니다. 알렉산더 리히터는 JSNation 세션에서 Rust 기반의 통합 툴링이 이 문제를 어떻게 해결하는지 제시했습니다.
문제의 핵심은 개발과 배포의 불일치: 현재의 Vite 스택은 개발(Dev)에는 빠른 esbuild를, 프로덕션(prod) 빌드에는 번들링 최적화가 뛰어난 Rollup을 사용합니다. 이원화된 빌드 도구는 복잡성을 높이고, ‘로컬에선 되는데 배포하면 안 되는’ 미묘한 버그를 유발하는 원인이 됩니다.
Rolldown, 속도와 호환성을 잡은 통합 번들러: Vite 팀이 주도하는 Rolldown은 이 문제를 해결하기 위해 탄생했습니다. Rust로 작성되어 esbuild만큼 빠르면서도, 기존 Rollup의 API와 플러그인 생태계를 호환하도록 설계되었습니다. 이를 통해 개발과 배포 환경의 번들러를 하나로 통일하여 불일치 문제를 근본적으로 제거합니다.
Oxc, 압도적 성능의 기반 기술 (The Anchor): Rolldown을 뒷받침하는 핵심 엔진인 Oxc(Oxidized JavaScript Tools)는 Parser, Linter, Formatter 등을 포함한 고성능 툴킷입니다. 특히 ESLint 대비 50~100배 빠른 Linting 속도와 독자적인 고성능 Parser는 대규모 프로젝트의 개발 경험(DX)을 개선합니다.
단일화된 툴체인: 앱 코드 → Vite(서버) → Vitest(테스트/브라우저 모드) → Rolldown(번들링) → Oxc(Linting/Formatting)으로 이어지는 단일화된 툴체인은 개발자가 복잡한 설정 설정에서 벗어나 코드 자체에 집중할 수 있게 합니다. 이 세션은 도구의 속도 개선을 넘어, 복잡성 자체를 제거하려는 ‘Rust 중심의 툴링 통합’ 에 대해서 다루었는데 기존에 겪고 있던 툴링에 대한 이슈들을 여러 측면에서 개선할 수 있어 보여 흥미롭게 다가왔습니다.
그 외 주목할 만한 세션
1. Amy Dutton: DX와 UX의 잘못된 이분법
RSC가 ‘개발자 경험(DX)을 희생해 사용자 경험(UX)을 얻는 기술’이라는 업계의 오해를 반박하며, 이는 초기 생태계의 부족함 때문임을 지적합니다. 또한 RSC의 본질은 앱의 무게중심을 클라이언트에서 서버로 옮기는 ‘웹 표준으로의 회귀이자 합리적 진화’ 임을 강조했습니다.
2. Chaitanya Deorukhkar: Figma에서 코드까지, AI와 커스텀 디자인 시스템의 결합 (온라인)
AI는 코드를 빠르게(Fast) 짜지만, 품질이 낮고, 디자인 시스템은 품질(Good)은 높지만, 적용이 번거롭다는 딜레마를 MCP(Model Context Protocol) 기술로 해결했습니다. AI에게 디자인 시스템의 문맥(Context)을 주입하여 Figma 디자인을 곧바로 프로덕션 레벨의 코드로 변환하는 워크플로우를 제시하며, 이를 통해 엔지니어가 단순 구현을 넘어 프로덕트를 만들어내는 ‘빌더(Builder)‘로 진화할 수 있음을 강조했습니다.
에필로그
이번 컨퍼런스를 관통하는 메시지는 명확했습니다. “도구는 더 마법(Magic)처럼 변하고 있지만, 엔지니어는 더 깊은 원리(Fundamentals)를 이해해야 한다” 라는 것입니다.
현업에서 다양한 AI 도구를 직접 사용해 보며 느낀 점 중 하나는, 결국 “훌륭한 엔지니어가 AI 도구도 잘 활용한다” 는 것이었습니다. 뛰어난 동료들은 상대적으로 쉽고 반복적인 업무는 AI에게 위임하고, 본인은 더 복잡하고 어려운 문제를 푸는 데 집중하거나 “어떻게 AI를 활용해 결과물의 완성도를 높일지” 치열하게 고민하는 모습을 보여주었습니다. 평소 이러한 과정을 지켜봐 왔기에, AI가 코딩을 돕고 컴파일러가 최적화를 대신해 주더라도 결국 도구가 만들어낸 복잡도 절벽을 넘어서는 것은 엔지니어의 탄탄한 설계 역량과 디버깅 능력이라는 이번 컨퍼런스의 메시지가 더욱 깊이 와닿았습니다. 엔지니어의 미래에 대해 여러 해석이 오가고 있지만, 적어도 현시점에서는 AI를 영리하게 활용하는 엔지니어들을 중심으로 엄청난 생산성 폭발이 일어날 것이라는 긍정적인 미래 또한 엿볼 수 있었습니다.
핵심 기술 세션 외에도 최신 Testing 동향, Feature Flag 관리와 같은 실무적인 주제, 그리고 리더십과 같은 소프트 스킬까지 폭넓은 논의가 이루어졌습니다. 프론트엔드 영역이 얼마나 다채롭게 확장되고 있는지 확인할 수 있었고, 이러한 변화의 흐름은 갓 출범한 저희 카카오뱅크의 프론트엔드 클랜이 앞으로 나아가야 할 방향과 고민해야 할 지점들과도 맞닿아 있어 더욱 의미 깊은 시간이었습니다.
긴 글 읽어주셔서 감사합니다.