(번역) 왜 더 많은 개발자가 웹 플랫폼을 활용하지 않을까요?

원문: https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/

수년 동안 웹 표준, 성능, 접근성을 옹호하는 사람들은 웹 개발자들에게 “플랫폼을 사용하라”고 간곡히 요청해 왔습니다. 저 역시 자주 그 옹호자 중 한 사람이었습니다.

논지는 간단합니다. 브라우저가 대신 해줄 수 있는 일을 왜 자바스크립트로 직접 만들까요? 무엇을 만들든 브라우저가 기본으로 제공할 수 있는 것보다 성능이 떨어지고 사용성이 나쁠 가능성이 큽니다.

하지만 저는 반대편의 입장도 살펴볼 가치가 있다고 생각합니다. 다른 이유가 없더라도 “플랫폼 회의론자”인 개발자들이 어떤 생각을 하는지 이해하기 위해서입니다. “플랫폼을 사용하라”가 그렇게 자명하다면, 왜 그렇게 많은 사람을 설득해야 하는 것처럼 보일까요?

가장 분명한 이유는 역사적인 배경에서 찾을 수 있습니다. 아주 오랫동안 브라우저는 자신들 위에 형성된 생태계를 뒤따라가기에 바빴습니다. jQuery 같은 라이브러리는 브라우저가 이에 해당하는 API를 구현하는 동안 중요한 빈틈을 메웠습니다. 그 후에도 실제로 그 API를 사용하려면 IE6 같은 뒤처진 브라우저가 사라지기를 기다려야 할 때가 있었습니다. 오늘날 대부분의 브라우저는 에버그린(evergreen) 브라우저입니다(Safari는 논란의 여지가 있지만 1년에 약 7회 업데이트되는 것도 나쁘지 않습니다). 그러나 대략 2020년대에 이르기 전까지 웹 개발자들은 분명히 불안정한 웹(lumpy web) 환경에 직면해야 했습니다. 이러한 환경에서는 자체 라이브러리를 개발하는 것이 현명한 선택이었습니다.

또 다른 이유는 익숙함입니다. npm에서 리액트 컴포넌트를 찾는 데 익숙해지면, 어떤 문제를 마주하든 그런 것을 찾게 됩니다. npm에서 “sticky positioning”을 검색해도 “그냥 CSS position: sticky를 쓰세요, 이 바보야”라고 말해 주는 패키지는 없습니다.

그리고 탄탄한 표준이 있더라도 npm 라이브러리는 종종 프레임워크의 사용 편의성과 그 아래 플랫폼 사이에 있는 유용한 간극을 메워 주었습니다. 저는 많은 리액트 개발자가 JSX와 리액트의 관용적인 방식에 머무르기를 선호한다는 점이 늘 흥미로웠습니다. 원시 DOM API는 “찜찜하게” 느껴졌지만, 원시 DOM 조작이 흔히 쓰이는 더 저수준의 라이브러리는 기꺼이 사용했습니다. 예를 들어 가상 리스트 라이브러리는 순전히 성능을 위해 원시 DOM API를 거리낌 없이 사용하면서도, 리액트 초보 개발자가 더 쉽게 이해할 수 있는 고수준 프리미티브를 노출할 수 있습니다. 어떤 의미에서는 리액트 컴포넌트 생태계가 자연스러운 분업으로 이어졌습니다. 더 전문적인 지식을 가진 사람들이 낯선 플랫폼 API를 더 친숙한 형태로 묶어 제공한 것입니다.

이러한 효과의 일부는 문서화에서도 비롯되었습니다. 많은 npm 패키지에는 예제, 튜토리얼, 스크린샷이 포함된 정성스럽고 상세한 README나 웹사이트가 있습니다. 반면 MDN이 웹 문서의 대표적인 장소로 확고하게 자리 잡기 전까지(구글의 좀 더 미래 지향적인 축으로는 web.dev가 있습니다), 웹 플랫폼 문서는 블로그와 StackOverflow, CSS Tricks 같은 사이트에 흩어져 있었습니다. 그리고 이런 사이트들 중 상당수는 그냥 jQuery나 GreenSock 같은 잘 알려진 라이브러리를 쓰라고 말하곤 했습니다!

Dragula 웹사이트와 MDN의 Drag and Drop API 문서를 비교한 모습입니다. 지금도 전자가 더 매력적으로 보인다고 주장할 만합니다.

하지만 서드파티 라이브러리와 플랫폼 API 사이의 문제일 뿐이라면, 그것만으로는 “플랫폼을 사용하라”에 대한 반감을 충분히 설명할 수 없다고 생각합니다. 게으른 개발자들(아니면 제가 같은 말을 두 번 한 건가요?)은 자신이 직면한 문제에 대한 기성 해결책만 원하는데, 그 해결책이 npm에서 나왔는지, 브라우저에서 나왔는지, 누군가의 무작위 GitHub Gist에서 복사해 온 것인지 신경 쓰지 않을 가능성이 큽니다. 그들은 문제를 해결하고 다음으로 넘어가기를 원합니다. 하지만 제가 살펴보고 싶은, “플랫폼을 사용하라”에 반대하는 태도의 또 다른 근원이 있습니다.

어떤 유형의 개발자에게는 직접 만드는 일이 그저 더 재미있습니다. 그리고 특히 웹 플랫폼에 대한 백과사전 같은 지식이 없다면, 그렇게 만들어진 코드를 이해하고 추론하기가 더 쉬운 경우도 많습니다. 일단 무언가를 만들고 나면, 자신이 직접 만든 코드를 유지보수하고 이것저것 손보고 싶어지는 일종의 이케아 효과(IKEA effect)가 생길 수도 있습니다.

예를 들어 모달 다이얼로그를 만들려고 한다고 상상해 봅시다. 모달이 어떻게 작동해야 하는지 시각적으로는 이해할 수 있을 것입니다. 콘텐츠가 화면에 나타나고, 배경은 일부 가려져도 여전히 보이며, 다이얼로그 바깥을 클릭하면 닫힐 수도 있습니다. 그래서 다이얼로그를 올바르게 배치하려고 position:absolute와 z-index를 사용합니다. 아하, 그런데 배경이 여전히 스크롤되니 body의 overflow를 비활성화해야 합니다… 그리고 접근성에 대해 조금 알고 있다면, Esc 키로 닫히게 하고 포커스 트랩(focus trap)을 만들고 다이얼로그를 연 요소로 포커스를 되돌려야 한다는 사실을 깨닫게 됩니다. 그리고…

많은 개발자에게 제가 방금 묘사한 일은 악몽처럼 들릴 것입니다(그리고 반쯤만 작동하는 무언가를 만들기에도 좋은 방법입니다). 하지만 많은 개발자에게는 이 일이 재미있게 들립니다! 이것을 만들기 시작하면서 얼마나 많은 것을 배울지 생각해 보세요. 그리고 애니메이션, 테마, 선택적인 “닫기” 버튼을 추가하면서 어떻게 자기만의 방식을 입히기 시작할 수 있을지도 생각해 보세요… 어느새 npm에 올릴 준비가 된 라이브러리를 만들게 됩니다. 그것은 그냥 <dialog>를 가져다 쓰고 끝내는 것보다 훨씬 재미있습니다. 그렇게 끝내다니, 맥이 빠지잖아요!

그리고 우리 중 많은 사람에게는 <dialog> 같은 API가 존재하기 전에, 이것이 바로 우리가 웹 플랫폼을 배운 방식이었습니다! 지금 “플랫폼을 사용하라”고 주장하는 많은 사람이 과거에는 직접 폴리필(polyfill), 심(shim), 라이브러리를 만든 사람들이었습니다. 제가 바로 그중 한 사람이기 때문에 압니다! 저는 PouchDB 작업의 일부로 IndexedDB, WebSQL 및 다른 브라우저 저장소 API용 도구를 만드는 데 여러 해를 보냈습니다. 그 경험은 결국 제가 W3C 표준 회의에 참석하고 IndexedDB 명세 자체에 이슈와 풀 리퀘스트까지 열 수 있을 만큼 자신감을 갖게 해 주었습니다. 메워야 할 플랫폼의 빈틈이라는 강제적인 동력이 없었다면, 그 수준의 전문성에 도달할 관심이나 동기를 찾았을지 모르겠습니다.

물론 직접 하는 일이 언제나 순수하게 좋은 것만은 아닙니다. 때로는 그저 순전한 무지에서 비롯됩니다. 특히 웹 플랫폼에서 CSS로 더 잘 해결할 수 있는 문제에 자바스크립트 해결책이 그토록 많이 생겨난 이유 중 하나는, 많은 개발자가 CSS가 어떻게 작동하는지 깊이 이해하는 데 시간을 들이지 않았기 때문이라고 생각합니다.

그리고 공정하게 말하면, CSS는 역사적으로 이해하기 어려웠습니다! 그 사이트 이름이 “CSS Tricks”인 데에는 이유가 있습니다. clearfix, float, min-width: 0 트릭 같은 것은 결코 직관적이지 않습니다. CSS의 내부 알고리즘을 이해하려고 하기보다, 원하는 명령형 로직을 상상한 다음 자바스크립트로 표현하는 것이 훨씬 쉬울 때가 많습니다. 게다가 수년 동안 CSS에는 여러 줄 말줄임(line clamping), textarea 크기 조절, 스크롤바 숨기기 같은 흔한 패턴을 간단히 표현하는 방법이 없었습니다. 그러니 개발자들이 이미 이해하는 도구로 직접 만든 것도 당연합니다.

저는 이 “플랫폼을 피하는” 현상이 웹에만 국한된다고 생각하지도 않습니다. 자신이 완전히 이해하지 못하는 플랫폼 위에서 일하는 모든 개발자에게 적용될 수 있습니다. 예를 들어 제 직장에서는 여러 종류의 분석 데이터를 저장하기 위해 ClickHouse를 사용합니다. 한때 동료와 저는 큰 JSON 데이터를 컬럼에 저장하는 방법을 두고 의견이 달랐습니다. 동료는 저장 전에 데이터를 압축하는 시스템을 만들었고, 저는 데이터를 별도의 키-값 저장소에 넣은 다음 ClickHouse에는 키만 삽입했습니다. 결과적으로 우리 둘 다 틀렸습니다! ClickHouse는 자동으로 데이터를 압축하고, 컬럼 지향 데이터 저장소이기 때문에 ClickHouse가 직접 처리하게 두면 실제로 행 전체에 걸쳐 더 나은 압축률을 얻을 수 있습니다. 그리고 별도의 키-값 저장소는 컬럼 지향 SELECT가 이미 하는 일을 조악하게 재현한 것에 불과했습니다.

저는 시간을 들여 ClickHouse 문서를 철저히 읽고 나서 제 가설을 입증하기 위한 벤치마크를 작성한 뒤에야 이런 사실을 깨달았습니다. 결국 플랫폼 자체가 기본으로 제공할 수 있는 것보다 더 느리고 다루기 불편한 것을 우리가 만들었다는 사실에 충격을 받았습니다. 자바스크립트와 웹 플랫폼 사이의 유사점을 무시하기는 어려웠습니다.

여러분이 iOS나 Android 개발자이거나, 게임 엔진 위에서 무언가를 만드는 사람이거나, 정말 어떤 플랫폼 계층 위에서든 개발하는 개발자라면 비슷한 이야기가 있을 것이라고 확신합니다. 노련한 시니어 엔지니어에 대한 전형적인 이미지가 주니어의 지나치게 복잡하고 얽힌 코드를 한 줄로 바꿀 수 있는 사람인 데에는 이유가 있습니다. 더 많이 배울수록 전체 시스템이 처음부터 끝까지 어떻게 작동하는지에 관한 지식을 활용해 그 시스템에 가능한 한 최소한만 기여할 수 있게 됩니다(따라서 장기적으로 유지보수 부담도 줄일 수 있습니다).

저는 이 글 내내 AI에 관해 이야기하지 않으려고 정말 열심히 노력해 왔습니다(지난 1년 동안 그 이야기를 너무 많이 했으니까요). 하지만 당연히 AI 코딩이 이 현상에 어떤 영향을 미칠지 궁금해하지 않을 수 없습니다. 사실 저는 낙관적인 견해와 비관적인 견해를 둘 다 가지고 있습니다.

• 낙관적: LLM은 여러분이 작업하는 플랫폼이 무엇이든 그에 관한 백과사전 같은 지식을 가지고 있으므로, 프롬프트를 작성한 사람이 모호한 영어로 요청한 경험을 제공하는 데 정확히 알맞은 플랫폼 API를 선택할 수 있습니다. 그리고 이 해결책은 사용자 영역(userland)의 코드보다 더 빠르고 정확할 가능성이 높으므로, 에이전트는 엄격한 테스트와 벤치마킹 후에 이를 선호할 것입니다. 게다가 개발자가 실제로 코드를 직접 작성하지 않으면 “이케아 효과”도 사라집니다.
• 비관적: LLM은 코드를 중복 작성하는 일을 좋아하는 것처럼 보입니다. 예를 들어 이미 존재하는 헬퍼 함수를 무시하고 몇 번째인지도 모를 자체 함수를 새로 작성합니다. 그래서 플랫폼의 관용적인 방식에서 벗어난 사용자 정의 코드의 양이 폭증할 것입니다. 개발자들은 에이전트에게 충분히 테스트하거나 충분한 대안을 시도하라고 지시하지 않고, 에이전트의 첫 초안을 그대로 커밋할 것입니다. 그리고 언제나 더 많은 주전원(epicycles)을 덧붙일 수 있으므로, 에이전트는 애초에 존재하지 말았어야 할 과도하게 설계된 해결책을 계속 반복해서 수정할 것입니다.

저는 AI 코딩을 직접 사용하면서 두 현상이 모두 일어나는 것을 보았습니다. 모델과 코딩 하네스(coding harness)가 개선되면서 낙관적인 결과 쪽으로 기울기 시작할 것이라고 믿고 싶지만, 확신할 수는 없습니다.

어쨌든 이것이 “플랫폼을 사용하라”에 관한 저의 장황하고 다소 상충하는 생각들입니다. 저는 이 말을 금언으로서 좋아합니다. 지나치게 복잡한 스파게티 코드 더미를 보면서, 작성자가 그 아래 계층을 조금만 더 잘 이해했다면 얼마나 더 훌륭하고 우아했을까 생각할 때 느끼는 감정을 간결하게 포착하기 때문입니다. 동시에 저 역시 그런 작성자였고, 그렇게 아름답고 지저분한 코드(어쨌든 제 눈에는 아름다운 코드)를 만드는 기쁨을 느꼈습니다. 그래서 그런 개발자들이 어떤 생각을 하는지 이해할 가치가 있다고 생각합니다. 그런 이유로 플랫폼이 존재하는 한 우리는 “플랫폼을 사용하라”는 말을 계속 듣게 될 것이라고 확신합니다.