최근 참석한 글로벌 개발자 컨퍼런스에서는 단순한 신기술 소개를 넘어, 우리의 개발 방식 자체에 대한 근본적인 질문들이 쏟아졌어요. '과연 우리가 사용하는 프레임워크는 여전히 필요한가?', '브라우저 자체의 능력을 얼마나 활용하고 있는가?' 같은 질문들이죠. 이 글은 그 현장에서 느낀 생생한 인사이트와 실무적인 고민을 공유합니다. 자세한 근거자료는 원문에서 확인할 수 있어요.
1. '브라우저의 반격': 프레임워크에 대한 재고찰
컨퍼런스의 한 키노트에서는 React와 같은 현대 프레임워크를 '더 이상 존재하지 않는 한계를 위해 만들어진 루브 골드버그 장치'에 비유했어요. 핵심 주장은 이렇습니다:
- 2025년의 브라우저는 이미 많은 것을 할 수 있다: View Transitions API, CSS Scroll-Driven Animations 등 네이티브 기능이 풍부해졌지만, 프레임워크 습관에 가려 제대로 활용되지 않고 있습니다.
- 의존성 목록이 화면보다 길다: 생산성 향상이라는 명분 아래, 도구가 오히려 우리의 상상력을 제한하고 동일한 웹사이트를 반복적으로 만들게 하는 '지역 최대치(Local Maximum)'에 도달했다는 지적이 있었죠.
- LLM의 함정: AI가 React 코드로 학습되면서 '모든 웹 앱은 SPA여야 한다'는 가정이 더욱 공고해지고 있어, 대안을 만들기 어려운 환경이 조성되고 있습니다.
2. 접근성: 자동화 도구만 믿으면 안 되는 이유
접근성(A11y) 세션에서는 자동화된 테스트 도구의 한계가 명확히 지적되었어요.
- 가짜 긍정/부정: 장식용 이미지에
alt텍스트가 없다고 경고하는 것은 쉽지만, 오히려 불필요한alt를 추가하면 스크린 리더 사용자에게 해가 될 수 있습니다. - 목표의 전도: Lighthouse 감사 통과가 목표가 되면, 진정한 접근성 문제를 놓치기 쉽습니다.
- 해결책은 도구가 아니다: 궁극적인 해결책은 더 많은 법과 규제, 그리고 장애를 가진 사람들의 직접적인 피드백을 개발 과정에 포함시키는 것이라는 주장이 설득력 있게 다가왔어요. 접근성은 프로젝트 마지막에 추가할 '프로요거트 토핑'이 아니라, 디자인부터 엔지니어링까지 전 과정에 스며들어야 합니다.
3. 실무적 시사점: 우리 팀은 무엇을 해야 할까?
이러한 통찰을 바탕으로, 우리의 일상적인 개발 흐름에 적용할 수 있는 점을 정리해봤어요.
- '플랫폼 우선' 사고 실험하기: 다음번 작은 기능을 구현할 때, '일단 프레임워크 없이 브라우저 API로 할 수 있는지' 먼저 고민해보는 시간을 가져보세요.
- 접근성 체크리스트 개선하기: 자동화 도구 리포트를 맹신하지 말고, 실제 스크린 리더 사용자 테스트나 동료 리뷰를 정기적으로 도입하는 것이 중요합니다.
- 개발의 '재미'와 '의미' 찾기: 기술이 유틸리티적으로만 논의되는 분위기에서, CSS 스크롤 애니메이션 데모처럼 문제 해결에 대한 창의적이고 장난기 어린 접근이 오히려 큰 영감을 줄 수 있음을 보여줬어요.
컨퍼런스는 웹 개발의 미래가 단순한 도구의 교체가 아니라, 우리가 문제를 바라보는 시각과 창의성의 회복에 달려 있음을 일깨워주었습니다. 변화의 흐름 속에서 우리가 잃지 말아야 할 것은 바로 이 '개발의 본질'에 대한 탐구 정신이 아닐까요?