요약
"플랫폼을 쓰라"는 조언이 잘 안 통하는 데는 습관, 문서, 직접 만드는 재미 같은 이유가 있습니다.
웹 표준 지지자들은 오래전부터 라이브러리 대신 브라우저 기본 기능을 쓰라고("use the platform") 권해 왔습니다. 그 말을 자주 해 온 개발자 놀런 로슨이 이번에는 이 조언이 왜 잘 먹히지 않는지 개발자 입장에서 따져 봤습니다.
왜 중요한가
- 기본 기능을 외면하는 개발자를 나무라기보다 그 동기부터 이해하자는 제안입니다.
- 직접 만들어 보는 일은 웹을 깊이 배우는 길이기도 해서 무조건 낭비로 볼 수 없다고 짚었습니다.
- AI가 코드를 쓰게 되면 이 문제가 줄어들지 오히려 커질지 아직 알 수 없다고 봤습니다.
핵심 내용
- 브라우저가 오랫동안 생태계보다 뒤처져 jQuery 같은 라이브러리가 빈틈을 메웠고, 그 습관이 남았습니다.
- 개발자는 문제를 만나면 npm부터 찾았고, 예전 문서와 튜토리얼도 기본 기능보다 라이브러리를 권했습니다.
- dialog 요소가 없던 시절 모달 창을 직접 만드는 일은 재미있었고, 그것이 곧 웹을 배우는 방법이었습니다.
- 직접 만든 것을 더 아끼는 이케아 효과 때문에 개발자는 자작 코드를 쉽게 놓지 못합니다.
- LLM은 플랫폼 기능을 두루 알지만, 기존 코드를 무시하고 같은 기능을 또 만드는 경향도 있다고 했습니다.
HN 반응
- 웹 컴포넌트(브라우저 기본 UI 부품 기술) API가 불편해 결국 Lit 같은 라이브러리를 얹게 된다는 불만이 가장 많았습니다.
- datalist처럼 기본 구현이 조악한 경우가 많다는 반론과, 표준 쪽에 문서와 홍보가 부족하다는 지적도 나왔습니다.
이 대목이 마음에 걸렸습니다.
플랫폼 API는 형편없었습니다. React가 "더 재미있어서" 쓰인 게 아닙니다. 플랫폼 API만으로는 안정적으로 돌아가게 만들기가 극도로 어렵고 번거로웠던 일을, React 덕분에 플랫폼 위에서 할 수 있게 된 겁니다.
제가 보기에 웹 컴포넌트는 구현이 부실했던 훌륭한 아이디어입니다. 그나마 있던 얼마 안 되는 채택도 대부분 Lit 같은 프레임워크 위에서 이뤄졌고, 그 프레임워크들은 개발 경험을 견딜 만하게 만들려고 웹 컴포넌트를 감싼 것들입니다.
도시계획에는 "욕망 경로(desire paths)"라는 개념이 있습니다. 보도나 길을 제대로 된 자리에 내주지 않으면 사람들이 알아서 자기 길을 낸다는 것입니다. 웹 커뮤니티도 플랫폼을 땜질하는 데 엄청난 시간과 노력을 쏟아 왔다고 생각합니다.
물론 인정할 건 인정해야죠. 플랫폼은 분명히 많이 나아졌습니다. 현대적인 표준이 갖춰진 만큼, 이런 땜질이 어디서 언제 필요한지 다시 따져 볼 때가 된 것도 맞습니다. 하지만 플랫폼이 약속한 잠재력을 제대로 발휘하게 하려고 사람들이 들인 그 지긋지긋하고 고통스러운 노력을 "직접 만드는 게 더 재미있어서"라는 한마디로 치부해서는 안 됩니다.
실제로 어떻게 생겼는지 궁금하시다면, Reddit에 현장에서 찾은 사진을 올리는 사람들이 있습니다.
https://reddit.com/r/DesirePaths/
출처: < https://en.wikipedia.org/w/index.php?title=Desire_path&oldid=1366655989#Accommodation >
이미 그런 용어가 있었다니 신기하네요! 제가 전에 일하던 YC 출신 창업자는 이 현상을 가리키는 "이상적인 경로(idealized path)"라는 말을 자기가 만들어 냈다고 굳게 믿고 있었거든요.
길 찾기는 GoodMaps 같은 회사들이 풀려고 애쓰는 도시 분야의 미해결 문제입니다. 방식이 좀 복잡하긴 하지만요(센서가 많을수록 정확해지긴 하는데, 폐쇄적인 생태계(walled garden)라는 점은 영 별로예요).
어떤 점에서요?
이 일을 20년 넘게 하면서 같은 질문을 수백 번 던져 봤는데, 답은 거의 항상, 95% 이상이 미적인 문제였습니다. 그 미적인 이유로 내린 결론들도 대부분은 스스로 해결할 방법을 찾지 못하고, 누군가 원하던 답을 주는 도구를 만들어 주기만 기다립니다. 그나마도 그 답은 기술적 평가보다 사회적 수용에 기대는 경우가 많습니다. 이건 기술 문제라기보다 교육이나 인적 역량의 문제입니다. 이런 질문을 던질 줄 아는 사람들조차 그게 교육 문제라는 걸 알면서도, 훨씬 적은 돈으로 인적 자본 문제를 고치는 대신 연봉을 올려 주고 기술 부채를 떠안는 쪽을 택한다니, 업계가 어떤 곳인지 많은 걸 말해 줍니다.
어쨌든 혼자 쓰려고 직접 만드는 개발자에게는 분명히 평가할 만한 점이 있습니다. 많은 경우 그 결과물은 회사에서 돈 받고 만드는 소프트웨어보다 빠르고, 가볍고, 더 많은 걸 해냅니다. 개인 소프트웨어는 자기가 통제할 수 없는 관례나 추상화에 묶여 있지 않으니까요.
상태를 저장하는 데 API 비용이 큽니다(속성 읽기). 쓰는 쪽도 비싸고요(리플로와 페인트를 일으키는 경로가 너무 많은데, 이를 묶어서 처리할 좋은 방법이 없습니다).
웹 컴포넌트는 보일러플레이트가 산더미예요. 속성을 관찰 가능하게 만들려면 쓸데없이 번거로운 절차를 거쳐야 하고요. 심지어 커스텀 엘리먼트에는 이름이 같은 속성(attribute)과 프로퍼티(property)가 공존할 수 있는데, 명시적으로 동기화 설정을 해 주지 않으면 둘은 따로 관리됩니다. 끔찍한 설계예요.
내장 요소는 확장도 안 됩니다. 쓸 만한 number 타입 input을 만들려면 직접 구현해야 하고, 그 요소가 폼 제출 데이터에 참여하게 하려면 또 번거로운 절차를 밟아야 합니다.
인기 있는 프레임워크가 인기 있는 데는 이유가 있습니다. 충분히 쓸 만하고, 이미 그걸 아는 사람을 채용할 수 있고, 관리자들이 버그를 대신 고쳐 주니까요.
프레임워크의 광기를 바닐라 API에 억지로 끼워 맞추려는 것처럼 들리네요. 그건 광기인데, 왜 그러는지는 압니다. 그게 익숙한 방식이니까요.
바닐라 API의 좋은 점은 고장 난 걸 알면서 그런 짓을 할 필요가 없다는 겁니다. API 자체도 엄청나게 빠르고요.
저는 상태를 저장할 때 모든 상태를 객체 하나에 담습니다. 딱 하나요. 아주 큰 애플리케이션에서도 보통 작습니다. 사용자 상호작용이 요구하는 만큼 그 객체를 갱신하고, 어디에 기록할지는 애플리케이션의 필요에 맞춰 정합니다. localStorage든 파일이든 데이터베이스든 다른 무엇이든요. 이상한 프레임워크식으로 하지 않으니, 그 상태 객체가 필요한 건 페이지를 로드하거나 다시 로드할 때뿐입니다.
내장 요소는 데이터 구조로 표현되니 본질적으로 프로그래밍 실력이 허락하는 만큼 확장할 수 있습니다.
고용주가 채용 조건으로 그걸 요구하니까요. 일을 하려면 초보들을 위한 멍청한 짓을 해야 합니다. 그리고 프레임워크가 인기 있다고 해서 다른 장점까지 있다는 뜻은 아닙니다. 여기서 다들 비대한 웹을 욕하는 가장 큰 원인이 바로 그 인기 프레임워크들이에요.
모든 웹사이트에 프레임워크를 써야 한다고 말하는 게 아닙니다. 이 사이트는 프레임워크가 필요 없어요. 프레임워크를 쓰지 말라고 하는 것도 똑같이 터무니없고요.
저는 예전에 PSD 파일을 잘라 붙여 IE5~8에서 픽셀 단위로 똑같이 렌더링하던 프런트엔드 시절에 성장한 에이전시에서 일했습니다. 온갖 버그와 별난 동작을 다 감수하면서요. 프레임워크는 일절 금지였어요. CSS(bootstrap)도, JS도(jQuery 정도만 빼고) 안 됐습니다.
애플리케이션이 점점 커지면서 코드도, 제때 납품하는 능력도 나빠졌습니다. 불가능한 건 없었지만, 보일러플레이트를 줄이려고 사내에서 만든 즉흥적인 프레임워크들은 프로젝트의 요구를 따라가지 못했습니다.
그러다 조금씩 backbone 같은 걸 허용하기 시작했고, 이후 angularjs, 그리고 제가 회사를 떠나기 직전에 React가 등장하기 시작했습니다. 이들에게도 나름의 문제가 있었지만, 대체로 일으킨 문제보다 해결한 문제가 더 많았습니다.
"프레임워크의 광기"는 의미 없는 말입니다. 마음에 안 드는 프레임워크도 많고, 제가 쓰는 프레임워크에도 싫은 점이 있습니다. 그래도 지금 순수 바닐라 JS로 하고 있는 일로 돌아가느니 거의 어느 것이든 쓰겠습니다. 저는 상호작용이 별로 필요 없는 단순한 블로그나 뉴스 사이트, 레시피 사이트를 만드는 게 아니니까요. 그런 걸 만든다면 저도 바닐라 JS를 쓰겠죠.
플랫폼에서는 제 코드가 HTML, JS, CSS 파일로 나뉩니다.
저는 모듈을 좋아합니다. 모듈은 대부분의 프로그래밍 언어에 어떤 형태로든 있고, 소프트웨어 공학에서 확실히 좋다고 할 만한 몇 안 되는 아이디어 중 하나입니다. 작업의 일부를 공개 API와 숨겨진 내부 구현으로 떼어 낼 수 있게 해 주세요. 모듈들로 이루어진 재사용 가능한 라이브러리처럼 여러 층위에서도 통하고요.
JS에는 모듈 체계가 있습니다. 그런데 HTML과 CSS는 JSX 같은 걸 쓰지 않는 한 거기에 연결되지 않습니다.
그래서 저는 매번 "플랫폼 쓰기"를 포기하게 됩니다.
코드가 이렇게 세 갈래로 나뉘는 환경은 브라우저 말고는 저도 알지 못합니다.
저도 HTML용 컴포넌트 라이브러리를 직접 만들어 본 적이 있지만, 같은 문제를 하고 또 하고 또 푸는 건 싫습니다. 즉흥적으로 만든 것보다는 잘 지원되고 검증된 라이브러리를 쓰고 싶어요.
이 글의 논지는 jQuery나 React 같은 라이브러리가 한때는 유용했지만 이제 브라우저에 더 나은 API가 생겼으니 그걸 쓰자는 것입니다.
브라우저에 컴포넌트 API가 있는 건 맞습니다. 하지만 많은 사람이 인정하듯 컴포넌트 API치고는 꽤 저수준입니다. 컴포넌트나 애플리케이션에서 데이터 흐름이나 렌더링을 어떻게 관리할지는 해결해 주지 않고, 불편한 구석도 많습니다.
문제없습니다. 그런 문제 중 일부를 해결해 주는 꽤 괜찮은 라이브러리로 LitElement가 있으니까요.
하지만 그러면 우리는 사실 플랫폼만으로 먹고사는 게 아니잖아요? 이 경우에도 Lit가 필요하니까요.
그러면 웹 컴포넌트의 무엇이 문제일까요? 솔직히 이건 질문 자체가 잘못됐다고 생각합니다. 더 나은 질문은, 왜 사람들은 웹 컴포넌트가 애초에 React와 경쟁하는 물건이라고 생각하느냐입니다. 웹 컴포넌트는 Polymer 같은 라이브러리가 가져다 쓰도록 일부러 저수준으로 설계되었기 때문에, 컴포넌트를 만들 때 가장 짜증스러운 문제 몇 가지를 의도적으로 해결하지 않았습니다. 그래서 많은 문제가 열린 채로 남습니다. 예를 들어 웹 컴포넌트는 HTML 엘리먼트처럼 동작합니다. 좋죠? HTML 속성으로 데이터를 내려보낼 수 있습니다. 멋지네요. 문제는 HTML 속성이 문자열이라는 겁니다. 그렇군요... 그러면 전부 문자열로 직렬화하든지, 아니면 별도의 우회 경로(보통은 따로 할당하는 프로퍼티)로 객체를 넘겨야 합니다. 사실 웹 컴포넌트 안에 다른 웹 컴포넌트를 조합하는 건 대체로 최악입니다. 웹 컴포넌트는 말단(leaf) 컴포넌트에 가장 잘 맞는다는 얘기가 전에 나왔던 걸로 알고 있습니다. 그러니 대규모 애플리케이션을 쌓아 올리는 기반으로 쓰이도록 만들어진 React 같은 라이브러리를 대체하기에는 분명히 적합하지 않습니다.
네, 저도 웹 컴포넌트는 별로 좋아하지 않습니다. 웹 컴포넌트 API를 제대로 살펴볼 시간은 내지 못했고요. 그냥 아키텍처 수단으로서의 개념 자체가 마음에 들지 않습니다.
저한테 중요한 건 설계의 자유와 최대한의 유연성입니다. 그걸 얻으려고 저는 스택을 아래로, 주어진 플랫폼이 허락하는 한 가장 낮은 곳까지 내려갑니다. 이 일을 아주 오래 해 왔기 때문에 브라우저에서 최대한 원시적으로 작업하는 데 따르는 위험은 걱정하지 않습니다. 적어도 제 경험으로는, DOM4 스펙이 나오고 JSON 메서드가 언어 메서드로 JavaScript에 들어오고 나중에 WebSocket이 생긴 뒤로 가장 중요한 API와 관례는 크게 바뀌지 않았습니다.
다른 곳에서는 더 낮은 층으로 내려가면 위험이 더 큽니다. 우리가 으레 당연하게 여기는 게 너무 많으니까요. 우리가 쓰면서도 별로 생각하지 않는 가장 복잡한 것들 가운데 일부를 바퀴 재발명하듯 다시 만드는 데에는 위험이 따릅니다. 하지만 기술이 허락하는데도 아무도 갖지 못한 능력을 만들어 낼 수 있다면 이점은 엄청납니다. 이런 일은 들리는 것보다 흔하게 일어나는데, 대부분의 사람이 시도하지 않기 때문일 뿐입니다.
경력 초기에 제가 바퀴를 재발명한 원래 동기는 회사에서 업무 과정을 간소화해서 맡은 일에 쓰는 시간을 줄이고 웹을 돌아다니는 시간을 늘리려는 것이었습니다. 지금은 첫 창업을 앞두고 있어서, 더 싸고 더 오래가는 기술로 기존 강자들의 발목을 꺾는 게 동기입니다. 그 기술 위에 앞으로 만들 도구들이 경쟁자들이 따라올 수 없는 방식으로 확장될 수 있게요.
이렇게 길게 써 주셔서 감사합니다. 저는 그렇게 잘 풀어 쓰지 못했을 텐데, 제가 그 댓글에 하고 싶던 말이 정확히 이거였거든요.
브라우저 쪽 대부분은 사람들이 무엇을 만들려는지 모르는 무지의 거품 속에 살고 있습니다.
리치 텍스트 입력 필드나 정렬되는 테이블이 있기를 바라는 게 과한 야심은 아니잖아요. 어설픈 xpath 구현도 있는데 장바구니와 상품 정도는 있을 수 있죠.
아는 게 많은 어떤 분이 한번은 제가 어설프게 만든 걸 들고 가서는, 제가 허공에서 금을 캐낸 것처럼 호들갑을 떤 적이 있습니다.
그건 페이지에서 id들을 가져와서, 같은 이름으로 inner html을 담은 문자열을 만들고, 복사본을 만들어 50ms마다 복사본과 문자열을 비교해서, 더 이상 같지 않으면 DOM 노드와 복사본을 새 값으로 갱신하는 식이었습니다. 입력 필드도 복사본을 입력 값과 비교했고요.
그래서 이런 게 가능했습니다.
<div id="myname">my name <div>
그다음에 myname += "John"; 이라고 쓰면 되고요.
또는 <div id="a">42<div><input id="b" value="123">
그다음에 a = a * b / 2 라고 쓰면 됩니다.
멋지네요. 번거로운 절차 없이 반응형이라니요.
상태 관리입니다.
핸들러마다 어떤 항목을 제거하고, 숨기고, 보여 주고, 바꿀지를 제가 일일이 추적해야 합니다.
그건 번거로운 사고 모델이고, 그래서 React, Angular, Vue, Svelte를 비롯한 모든 웹 프레임워크가 그걸 자동으로 계산해 주는 겁니다.
오해는 마세요. 변경(mutation) API 자체를 탓하려는 건 아닙니다. 다만 아주 단순한 일을 빼면 그걸 직접 쓸 생각은 전혀 없습니다.
이 주제를 논할 때 반프레임워크 진영이 이해하지 못하는 게 바로 이 점이라고 생각합니다. 그들은 "플랫폼" 방식으로 실제 프로덕션 환경에서 부딪히는 온갖 현실적인 문제를 처리하는 게 얼마나 어렵고 불쾌한지를 보지 못합니다. 동시에 JavaScript 기반 프레임워크들이 그 문제들을 구현 세부 사항으로 숨겨서 해결할 뿐 아니라 개발자 경험을 개선하려고 엄청난 노력까지 기울인다는 것도 보지 못하고요.
JSX만 봐도 그렇습니다. 프레임워크의 복잡성 상당 부분이 거기에 있지만 모든 걸 그만큼 단순하게 만들어 줍니다. 플랫폼 기능과는 정반대죠.
어떤 이념이든 광신적으로 100% 고수하려 들면 이렇게 됩니다. 리눅스가 전 세계 서버 인프라의 상당 부분에서 돌아가고 GNU HURD에서 도는 서버는 사실상 하나도 없는 데는 아주 분명한 이유가 있죠. 현실 세계는 여러분의 모델이 이론적으로 더 낫든 말든 신경 쓰지 않습니다. 결국 중요한 건 실제로 제품을 내놓는 것이고, 이념을 엄격하게 고수하면 보통 그 길을 가로막습니다.
우선 https://caniuse.com 부터 확인해 보세요.
그다음 폴리필 개념을 파고들어 보면, 플랫폼을 평준화하려고 모두가 어떤 추가 작업을 거쳐야 하는지 알 수 있습니다.
그러고 나서 기능 자체를 보세요. 웹 컴포넌트가 좋은 예입니다. 웹 컴포넌트는 JavaScript 웹 프레임워크가 제공하는 기본 기능을 현재 플랫폼이 따라잡도록 확장하려는 해킹으로 개발되었습니다. 그런데 사실상 쓸 수가 없어서, JavaScript 프레임워크로 먹기 좋게 다듬어야만 쓸 수 있습니다.
마지막으로 그걸 주류 JavaScript 프레임워크를 그냥 쓰는 경험과 비교해 보세요. 어느 것이든 좋습니다. 하늘과 땅 차이예요. JavaScript 프레임워크들은 개발자 경험을 최우선으로 삼아서, 자기네 JavaScript가 매끄럽게 이어지도록 XML 같은 DSL까지 만드는 수고를 감수했습니다. 반면 웹 컴포넌트 같은 건 정반대로 가서, 플랫폼의 일급 기능이 그냥 바닐라 JavaScript처럼 느껴지게 만듭니다.
웹 플랫폼은 여전히 쓰레기입니다. 저는 클래식 MacOS나 GTK2처럼 단순한 걸 원해요. 예를 들어 위키 같은 텍스트 편집 페이지라면 최상위 "App" 컴포넌트가 있고, 그 안에 VerticalBox와 HorizontalBox를 조합해 레이아웃을 잡고, 위에는 MenuBar, 아래에는 TextBox, 그리고 버튼 몇 개가 있는 식으로요. 깊이가 기껏해야 4~5단계인 트리면 충분하고, 합리적인 기본값이 있어서 "CSS 렌더링 알고리즘"이니 div, CSS 선택자, Z-index 같은 쓸데없는 세부 사항은 전혀 신경 쓸 필요가 없어야 합니다. 그런 건 UI 컴포넌트 라이브러리의 스킨을 설계하는 사람들이 알아서 하면 됩니다. 웹 디자인은 30년 전 데스크톱 UI 프레임워크도 아직 따라잡지 못했습니다.
저는 성공한 플랫폼 구축과 실패한 플랫폼 구축을 모두 겪어 봤습니다. 성공한 경우에는 제게 절대적인 권한이 있었거나, 제가 바라던 "완벽한" 길이 아니더라도 욕망 경로에 맞춰 만들었습니다. 타협할 수 없는 것을 최소한으로만 정해 그것을 중심으로 삼고, 사람들이 합류하도록 최적화했습니다. 제가 그리던 완벽한 비전에서 벗어나야 하더라도요.
제가 욕망 경로를 벗어나지 않게 스스로를 점검하는 방법 하나는, 전체 구축 과정의 일부로 승리에서 승리로 반복해서 나아가는 것이었습니다(승리란 누군가가 플랫폼을 쓰고 만족한 "고객"이 되는 것입니다). 이렇게 하면 플랫폼 피로감도 피할 수 있고, 우선순위가 바뀌더라도 그 노력에서 얻은 가치가 남습니다.
마인크래프트 욕망 경로를 다루는 유튜브 쇼츠 장르가 있었습니다. 욕망 경로가 생기는 걸 막으려는 점점 더 황당한 시도들을 보여 주는 영상이었어요. 웃음 포인트는 물론, 열성적인 마인크래프트 플레이어들은 부술 수 없는 기반암 사이로도 어떻게든 길을 낸다는 거고, 결국 관리자나 서버 주인이 두 손 든다는 겁니다.
안타깝게도 브라우저는 마인크래프트 서버가 아닙니다. 하위 호환성을 유지해야 하는 리빙 스탠다드(living standard)죠. 욕망 경로(React, Svelte 등)는 앞으로도 계속 생길 거고, 그걸 막으려는 황당한 시도들도 계속될 겁니다.
몇 년 전 여기서 언급된 적이 있는 책인데, 제가 특히 좋아하는 책 중에 이걸 줄거리의 한 요소로 다룬 게 있습니다. 존 브루너의 Squares of the City입니다.
좀 더 덧붙이자면, 일부러 길을 내지 않고 두면 사람들의 자연스러운 행동이 뚜렷이 드러납니다. 생각지도 못한 구역들 사이에 길이 생기는 걸 보게 됩니다. 보행자들이 풀밭을 밟아 눕히면서, 미관이나 예산처럼 서로 충돌하는 우선순위를 염두에 두고 그어 놓은 선을 따라가는 게 아니라 실제로 쓸모 있는 연결을 보여 주는 거죠. 그런 다음 그 데이터를 가져다가 이전 시스템에서의 행동과 사용 양상을 토대로 "사용자"가 실제로 원하는 길을 만들면 됩니다.
저도 현실에서 이 방식을 아주 좋아합니다. 소프트웨어에서 이에 가장 가까운 건, 사용자가 애플리케이션에 익숙하지 않을 때 무엇을 시도하는지 지켜보는 거라고 생각해요. 안타깝게도 실제 사용자 테스트는 요즘 어느 때보다 드물어진 것 같습니다.
"UX 디자이너"들은 조니 아이브/앨런 다이식 미니멀리즘과 "여백의 미"라는 제단에 절을 하면서, 모든 유형의 사용자가 모든 종류의 작업에서 '선택지가 너무 많으면' "압도당한다"고 듣는 사람마다 붙잡고 말합니다. 그래서 요즘 소프트웨어는 사람들이 자연스럽게 택했을 직선 경로 대신, 출구가 딱 세 개씩 달린 흰 방들의 연속 같아졌어요. 그 출구에는 라벨이 붙어 있어도 아이콘뿐이고(스와이프 제스처라서 라벨을 붙일 수조차 없는 것도 많고요), 다른 출구는 가까이 다가가야만 나타납니다(그 호버 헛짓거리 말입니다).
애플리케이션 사용성을 해치는 또 다른 요인은 신규 사용자에게 지나치게 맞추는 겁니다. 중요한 측면이긴 하지만, 사실상 늘 초보자 모드에 갇혀 있는 기분은 끔찍합니다.
어려운 점은 신규 사용자에게 맞추는 것과 숙련 사용자에게 맞추는 것이 인터페이스 설계에서 서로 정반대라는 겁니다. 일 년에 몇 번만 쓸 신규 사용자나 가끔 쓰는 사용자에게는 깊이 있는 설계가 낫습니다. 애플리케이션에 낯선 사람을 단계마다 부드럽게 안내하고, 모드와 클릭은 많되 각각에 담긴 정보는 적게 하는 식이죠. 숙련 사용자에게는 얕은 설계가 최고입니다. 정보 밀도가 높고, 모든 게 한 번의 동작으로 되고, 아무것도 숨기지 않는 거죠. 최고의 디자이너들은 이 역설을 어떻게든 헤쳐 나가지만, 대부분은 한쪽에 집중하고 다른 쪽은 어떻게든 때워야 합니다.
디자인을 위한 디자인, 즉 얼마나 멋져 보이느냐가 핵심인 디자인은 모두에게 최악입니다. 그래도 광고에서는 멋져 보이죠.
공감은 하지만, 적어도 저한테는 React가 확실히 일을 더 재미있게 만들어 줬어요.
반면 웹 컴포넌트는 실제로 겪는 사람이 거의 없는 문제를 풀려는 것 같았고, 아니면 비대하다는 둥의 이유로 React나 현대 프레임워크를 혐오하는 사람들을 위한 것 같았어요.
"재미"라는 관점은 AI를 싫어하는 개발자들에 대한 또 다른 거짓 서사와 딱 맞아떨어집니다.
제가 다니던 대학 캠퍼스에도 풀밭을 가로지르는 잘 다져진 길이 있었습니다. 학생들이 식사 시간마다 기숙사에서 식당까지 일직선으로 질러가던 길이었어요.
결국 거기에 보도가 놓이긴 했습니다. 하지만 한동안은 그 길을 포장한 건 학생들의 발걸음뿐이었습니다.
웹 컴포넌트가 왜 그렇게 형편없는 아이디어라는 건지 이해가 안 됩니다. 저는 단순한 사이트 대부분의 프런트엔드 코드를 짤 때 일부러 웹 컴포넌트를 택했는데 아무 문제 없었어요. 훌륭하진 않아도 괜찮았습니다.
웹 컴포넌트는 별 수고 없이 제 몫을 하고, 어디서나 쓸 수 있습니다.