요약
같은 앱을 AI 에이전트로 만들어 보니 프레임워크에 따라 비용이 2배 가까이 갈렸습니다.
놀런 로슨이 자신의 블로그에 쓴 글입니다. 그는 프레임워크 선택이 증거 없이 분위기로 결정된다고 비판하며, Claude Opus 5.5에 같은 포켓몬 앱을 12가지 방식으로 5번씩 만들게 해 직접 측정했습니다.
왜 중요한가
- "에이전트에 더 좋다"는 이유로 프론트엔드를 다시 쓰는 일이 벌어지는데, 그 주장을 따져 볼 수치가 나왔습니다.
- 사람이 코드를 직접 치지 않으면 개발 편의보다 증거를 기준으로 스택을 고를 수 있다는 것이 저자의 메시지입니다.
- 벤치마크가 GitHub에 공개되어 있어 누구나 재현하거나 다른 조건으로 시험할 수 있습니다.
핵심 내용
- 1회 비용은 Hono+htmx가 2.67달러로 가장 적었고, 소요 시간은 Astro가 8.2분으로 가장 짧았습니다.
- Angular는 4.97달러와 17.2분으로 비용과 시간이 모두 가장 많이 들었습니다.
- 전송되는 JavaScript는 Astro가 0KiB, Next.js가 142KiB로 차이가 컸습니다.
- 프레임워크 없이 만든 Vanilla는 Lighthouse(구글의 웹 성능 측정 도구) 성능 점수가 97점으로 가장 낮았습니다.
- 저자는 작은 콘텐츠 앱 하나만 시험했으므로 대시보드나 게임에서는 결과가 다를 수 있다고 밝혔습니다.
HN 반응
- 일부 이용자는 앱이 너무 단순하고, 프레임워크는 유지보수성과 숙련도까지 따져 고르므로 이 수치만으로는 부족하다고 비판했습니다.
- Astro의 성적은 벤치마크가 콘텐츠 사이트라서 나온 결과라는 지적과, 상호작용이 많으면 다른 프레임워크를 얹어 쓰면 된다는 반론이 맞섰습니다.
AI는 접어두고라도, 순수 네이티브 모바일(Swift)에서 React Native로 억지로 넘어가야 했을 때 이 점이 정말 거슬렸습니다.
사람들은 어떤 SDK의 홍보 문구를 측정 한 번 안 해 보고 사실로 받아들였고, 그러고는 앱 전체가 왜 느린지 영문을 몰라 했습니다(XYZ 때문일 리가 없다, XYZ 개발자가 엄청 빠르다고 했으니까!!).
다행히 우리 팀은 제가 확실한 데이터를 내놓자 받아들여 줬습니다(그 프레임워크가 어떤 작업에서는 JS 스레드를 200ms, 때로는 1초 가까이 붙잡고 있어서 UI 전체가 끔찍하게 버벅거렸습니다).
React Native는 처음부터 끝까지 형편없었어요. 저는 이걸 밀던 사람들은 취향도 없고 UX에 신경도 안 쓰는 줄 알았다니까요.
제 경험으로는 이래요.
Flutter는 좋고 React Native는 별로예요. (모바일 기준)
React가 나온 초창기부터 JS 프레임워크 세계를 헤쳐 온 제 경험도 대체로 이렇습니다. React가 끝없이 큰 API·설계 개편을 거치다 보니, 초기 발표 내용 중 일부가 얼마나 형편없이 낡아 버렸는지 놀라울 정도입니다.
게다가 요구 사항이 복잡하고 열려 있는 빌드를 두고 기술을 평가하는 데 벤치마크는 아주 결함이 많은 방법입니다. 제약이 분명한 환경에서 특정 도구가 풀어 줄 확실한 병목이 있다면 벤치마크가 정말 도움이 될 수 있습니다. 하지만 방향 전환이 자유로워야 하는 새 제품을 0부터 시작할 때는, 창고에서 가장 빠른 도구를 고른다고 꼭 이득을 보는 것은 아닙니다.
AI로 다른 프레임워크로 갈아엎는 방법 말고, AI로 지금 쓰는 프레임워크를 현대화하는 방법도 있습니다. 저는 Mithril을 몇 년 쓰다 보니 좋아하게 됐습니다. 더 잘 관리되는 대안으로 다시 짜는 대신(Mithril은 2015년 이후로 활발한 개발이 별로 없습니다), 에이전트를 시켜 시그널, 제대로 된 상태 관리, 타입, SSR, 계산된 속성, Bun 툴링 등을 붙였습니다. 기존 테스트 스위트 덕분에 변경 사항이 꽤 믿을 만하게 반영됐습니다. 소스: https://code.garage44.eu/jeroen/mithril
맞아요, Mithril은 아름답죠. 사람들이 대체로 이미 완성됐다고 생각해서 업데이트가 없는 거라고 봅니다. 저도 같은 작업을 하면서 기능을 잔뜩 얹고 있어요. 올려 두신 것도 한번 볼게요. 슈퍼 Mithril을 만들어 봅시다!
처음부터 깔끔하고 단순하고 빠르면서 AI가 다루기 쉽게 만든 새로운 미니멀 프런트엔드 SPA 프레임워크도 있습니다. 예를 들면 https://arrow-js.com/ 같은 것이요.
정말 에이전트스럽네요. 2021년 봄에 커밋 몇 개, 그 뒤로 2023년 봄에 커밋이 몰아치고, 그 뒤로는 2026년 3월까지 완전히 감감무소식이다가 커밋이 160개 올라왔고, 그 뒤로 오늘까지는 변경이 단 하나도 없습니다. https://github.com/standardagents/arrow-js/graphs/contributors?from=2%2F1%2F2021&to=10%2F25%2F2026
저만 그런지 모르겠지만, 다시 남의 UI 프레임워크에 의존하게 된다면 제일 먼저 안정성을 볼 거고, 그러려면 "에이전트"가 붙은 건 최대한 멀리하고 싶을 것 같습니다.
추가: 방금 알았는데 그 "프레임워크"가 예전에는 "라이브러리"였던 ArrowJS와 같은 거네요. 그때는 작다는 것이 셀링 포인트였고 프레임워크가 아니라는 점을 내세웠는데( https://web.archive.org/web/20230609020338/https://www.arrow-js.com ), 결국 완전한 프레임워크로 방향을 틀었다니 정말 웃깁니다.
하하하, "React도 쓸데없는 군더더기가 붙기 전에는 (프레임워크가 아니라) 라이브러리였던 거 기억나? 내 새롭고 깔끔하고 단순한 라이브러리(프레임워크 아님)는 딱 필요한 것만 하고 앞으로도 절대 더 하지 않을 거야" 코스를 속성으로 밟는 거네요. 지난 세월 'React 킬러'를 자처한 수백 개가 개척해 놓은 길인데, 이번에는 AI를 얹었다는 게 다르겠죠.
ㅋㅋ 맞는 말씀이에요.
저도 응답이 없는 이슈를 두 개 올려 놨어요.
그래도 제가 본 마이크로 SPA 프레임워크 중에서는 여전히 단연 가장 깔끔합니다.
아, 만드신 분이셨군요? :P 화룡점정이네요.
맞아요, 낡고 방치된 의존성을 전체 코드베이스를 바꾸지 않고도 멋지고 타입 안전하고 ESM에 테스트도 잘 갖춘 물건으로 바꿔 놓을 수 있다는 게 정말 즐겁습니다.
꽤 흥미롭긴 한데, React를 비롯한 프레임워크들이 그토록 끈질기게 살아남는 진짜 근본 이유와는 동떨어져 있습니다.
React를 10년 쓴 마당에, 새 프로젝트라고 htmx나 그 비슷한 모양에 조금 나은 도구를 새로 배우지는 않을 겁니다. 특히 다른 행위자(AI)가 만든 결과물을 리뷰하고 디버깅하는 제 능력이 떨어지는 상황이라면 더 그렇죠. 프레임워크를 갈아타는 비용은 이제 훨씬 커졌고 얻는 이득은 훨씬 줄었습니다.
근본적으로 프레임워크 성능이란 추상화에 너무 큰 비용을 치르지 않는 것이고, 그다음이 개발 효율을 높이는 것입니다. 이건 "탐색"/프로토타입 단계에서 가장 중요한데, 그 단계에서는 성능이 나빠 고민하게 되는 것조차 행복한 고민일 겁니다.
제 프로젝트에서는 진짜 질문이 "이제 앱의 절반을 wasm으로 던져 버려야 하나?" 같은 한 단계 높은 질문으로 옮겨 갔습니다.
요즘 최신 모델들이 네이티브 macOS/iOS 앱을 만드는 능력에 정말 감탄했습니다. 얼마 전만 해도 웹 앱으로 만들었을 앱을 Claude에게 네이티브 앱으로 만들게 했습니다.
또 AI로 만들기 시작한 초기에는 제가 아는 프레임워크와 프로그래밍 언어를 쓰도록 꼭 챙겼습니다. 지금은 전혀 신경 쓰지 않고 가장 좋은 기술을 알아서 고르게 합니다. AI가 생성한 코드는 한 줄도 읽지 않고, 하니스에서만 작업하며 에디터는 더 이상 열지 않습니다.
다만 저는 전문 개발자가 아니고 저 혼자 쓸 앱만 만듭니다.
보통 프레임워크에는 한참 못 미치는 헬퍼나 "마이크로 프레임워크"를 허용하면 어떻게 나오는지 궁금합니다. 예를 들어 바닐라 JS에 nanostores를 짝지어 보는 식으로요.
아니면 그냥 프레임워크보다 더 잘 만들라고 시키면 그때는 아마 해낼 수도 있겠죠.
이 벤치마크는 너무 단순화돼서 의미가 없습니다. 프레임워크 선택은 속도만으로 정해지는 경우가 드물고, 사용자의 도메인 지식, 장기적인 유지보수성, 보안과 기능 개발 면에서 그 프레임워크가 쌓아 온 실적 같은 요소도 따집니다.
이 점 하나만 봐도, 배포만 빨리 하려고 뚝딱 만든 코드보다는 장기적으로 유지보수할 수 있고 이해하며 다룰 수 있는 코드베이스를 얻기 위해 $2와 2분을 더 쓰는 것이 훨씬 말이 됩니다.
제 경우에는 Svelte 5가 되겠지만, 사람마다 다른 무언가가 될 거라고 확신합니다.
동의하지만, 저는 피상적이고 얄팍한 펠리컨 얘기보다는 이런 체계적이고 방법론을 갖춘 작업이 훨씬 좋습니다.
게다가 아주 단순한 앱에 쓴 거잖아요. 이런 비교는 거의 항상 할 일 목록 앱 정도 수준의 앱을 쓰는데, 실제 상용 제품과는 광년 단위로 동떨어져 있죠.
맞아요, 글쓴이도 Figma 같은 건 아니라고 짚긴 하는데, 그럼 그 중간쯤은 어떨까요? 예를 들어 UI 흐름이 비교적 복잡한 소셜 미디어 앱 같은 거요. Astro야 단순히 정적인 콘텐츠를 보여 주는 사이트에서는 당연히 압도하겠지만, 더 빠르고 쓰기 좋은 reddit 같은 사이트를 만들 때는 어떨까요? 그리고 100개가 넘는 기능의 로드맵을 짜 놓고 서브에이전트 "팀" 예닐곱 개를 동시에 투입하면 어느 쪽이 가장 잘 돌아갈까요?
결론은 Angular가 AI 이전에도 최악의 선택이었고 AI 이후에도 여전히 그렇다는 거겠네요.
저는 Angular가 꽤 좋은데, 왜 그렇게 욕을 먹는지 모르겠어요.
Astro가 최고 시간, 지출 2위, 클라이언트 측 JS는 제로로 1위네요. 다음 프로젝트에 뭘 쓸지 알겠습니다.
여기서 Astro 점수가 좋은 건 Astro가 "콘텐츠 중심 웹사이트"용이고 벤치마크 앱이 바로 그런 앱이었기 때문입니다. 앱이 상호작용이 아주 많고 간단치 않은 실시간·비동기 처리가 돌아가는 경우라면 결과가 얼마나 달라질지 궁금해요.
그럴 땐 그냥 좋아하는 JS 프레임워크를 Astro와 같이 쓰면 여전히 좋습니다. 저는 Astro에 react와 heroui를 자주 씁니다. heroui는 이제 많은 컴포넌트에 JS가 필요 없어서, 정말 상호작용이 필요한 경우가 아니면 JS 제로 빌드를 그대로 얻을 수 있어요.
저는 에이전트가 "Astro에 뭐든 얹어 쓰는" 방식에서 성능이 특별히 좋지 않다고 느꼈습니다.
둘 사이의 경계를 추론하는 데 애를 먹는 것 같아요.
저는 그런 걸 못 느꼈어요. Astro + SolidJS를 쓰는데 아주 잘 되는 것 같습니다.
저는 하이드레이션(늘 불안정하다고 느꼈습니다)과 SolidStart 같은 하이드레이션 기반 프레임워크는 일부러 피하는데, 그게 도움이 됐을 수도 있고요. 아니면 그냥 제 편견일 수도 있죠!
동의합니다. 비동기, 에러 처리, 동시성이 많은 동작을 아주 우아하게 풀고 싶다면 solidstart(몇 달 전에 큰 V2 업그레이드를 막 내놨죠)로 가세요.
설정이 아주 쉽고, 같은 일을 하는 React 코드보다 훨씬 읽기 좋습니다.
상호작용이 많은 프로젝트에서도 Astro는 여전히 제가 가장 좋아하는 빌드 시스템입니다. SPA 컴포넌트를 Astro 파일 하나에 던져 넣으면 끝이에요.
Astro가 아주아주 쓰기 편하다는 건 저도 확인해 드릴 수 있습니다. 좀 더 무거운 작업이 필요할 때 쓰는 탈출구도 아주 잘 설계된 느낌이에요.