웹 표준과 성능, 접근성을 옹호하는 사람들은 오랫동안 개발자들에게 "플랫폼을 써라(use the platform)"고 권해 왔다. 브라우저가 이미 제공하는 기능을 굳이 자바스크립트로 다시 만들 필요가 있느냐는 것이다. 직접 만든 결과물은 브라우저가 기본 제공하는 것보다 성능도, 사용성도 떨어지기 쉽다. PouchDB 개발과 W3C 표준 논의에 참여해 온 놀란 로슨(Nolan Lawson)은 자신도 이 구호를 지지해 온 사람이라고 밝히면서도, 반대편의 시각을 이해해 볼 필요가 있다고 말한다. 조언이 그렇게 자명하다면, 왜 이토록 많은 사람을 설득해야 하는가라는 질문이다.
역사와 익숙함이 만든 관성
가장 분명한 이유는 역사적이다. 오랫동안 브라우저는 그 위에 쌓인 생태계를 뒤쫓는 처지였다. jQuery 같은 라이브러리가 브라우저가 동등한 API를 구현하기 전까지 중요한 공백을 메웠고, 그마저도 IE6 같은 뒤처진 브라우저가 사라지기를 기다려야 쓸 수 있었다. 오늘날 대부분의 브라우저는 상시 업데이트되지만(사파리는 다소 논쟁적이나 연 7회가량이면 나쁘지 않다), 2020년대 이전까지 개발자들은 제각각인 웹 환경을 감당해야 했다. 그런 환경에서 직접 만드는 선택은 합리적이었다.
익숙함도 한몫한다. npm에서 리액트 컴포넌트를 찾는 데 익숙해지면 문제의 성격과 무관하게 그쪽으로 손이 간다. npm에서 'sticky positioning'을 검색해도 "그냥 CSS의 position: sticky를 쓰라"고 알려 주는 패키지는 없다. 흥미로운 점은, 많은 리액트 개발자가 JSX와 리액트 관용구를 고수하며 날것의 DOM API를 꺼리면서도, 내부적으로 DOM을 직접 조작하는 저수준 라이브러리는 기꺼이 쓴다는 것이다. 예컨대 가상 리스트 라이브러리는 성능을 위해 DOM API를 직접 쓰면서도 초심자가 이해하기 쉬운 상위 수준 요소만 노출한다. 전문성을 가진 이들이 낯선 플랫폼 API를 익숙한 형태로 포장해 주는 자연스러운 분업이 생긴 셈이다. 여기에 문서화 격차도 더해졌다. npm 패키지는 예제와 스크린샷이 가득한 README를 갖춘 반면, 웹 플랫폼 문서는 MDN이 자리 잡기 전까지 블로그와 스택오버플로, CSS Tricks 등에 흩어져 있었고, 그마저도 상당수가 jQuery 같은 라이브러리 사용을 권했다.
직접 만드는 즐거움, 그리고 무지
하지만 서드파티 라이브러리 대 플랫폼 API의 구도만으로는 거부감을 다 설명할 수 없다. 로슨이 주목하는 다른 원천은 '재미'다. 어떤 개발자에게는 직접 만드는 일이 그 자체로 즐겁고, 플랫폼 전반을 꿰고 있지 않다면 자기가 짠 코드가 오히려 이해하기 쉽다. 게다가 스스로 조립한 가구에 애착을 갖는 'IKEA 효과'처럼, 한번 만들어 둔 코드는 계속 손보고 유지하고 싶어진다.
모달 대화상자를 예로 들어 보자. position:absolute와 z-index로 위치를 잡고, 배경 스크롤을 막으려 body의 overflow를 끄고, 접근성을 안다면 Esc 키 처리와 포커스 트랩, 원래 요소로 포커스 되돌리기까지 직접 구현한다. 누군가에게는 반쪽짜리 결과만 낳는 악몽이지만, 다른 누군가에게는 애니메이션과 테마, 닫기 버튼을 덧붙이며 npm에 올릴 라이브러리로 키워 가는 즐거운 과정이다. 그냥 를 집어 끝내는 것보다 훨씬 재미있다는 것이다. 실제로 같은 API가 없던 시절, 많은 이들은 바로 이렇게 폴리필과 심을 만들며 웹 플랫폼을 배웠다. 지금 "플랫폼을 써라"를 외치는 사람들 상당수가 한때 그 저자였고, 로슨 자신도 IndexedDB·WebSQL 도구를 만들던 경험이 명세에 이슈와 PR을 올릴 만한 전문성으로 이어졌다고 고백한다. 채워야 할 공백이라는 동기가 없었다면 그만한 수준에 이르렀을지 모르겠다는 것이다.
물론 직접 만들기가 늘 좋은 것만은 아니다. 때로는 순전한 무지에서 비롯된다. CSS로 더 잘 풀 수 있는 문제에 자바스크립트 해법이 넘쳐난 데는, 많은 개발자가 CSS의 동작 원리를 깊이 들여다보지 않은 탓이 크다. 사실 CSS는 역사적으로 이해하기 어려웠다. 사이트 이름이 'CSS Tricks'인 데는 이유가 있다. 클리어픽스, 플로트, min-width: 0 같은 기법은 직관적이지 않고, 여러 줄 말줄임이나 스크롤바 숨김 같은 흔한 패턴조차 오랫동안 CSS에 간단한 표현 수단이 없었다. CSS 내부 알고리즘을 파고드느니 원하는 명령형 논리를 자바스크립트로 적는 편이 쉬웠던 것이다.
웹을 넘어선 보편적 현상
로슨은 이 '플랫폼 회피'가 웹에만 국한되지 않는다고 본다. 자신이 분석 데이터를 저장하는 데 쓰는 ClickHouse를 두고 동료와 벌인 일화가 그 예다. 큰 JSON을 컬럼에 저장할 때 동료는 압축 시스템을 따로 만들었고, 그는 데이터를 별도 키-값 저장소에 넣고 키만 ClickHouse에 넣었다. 결과적으로 둘 다 틀렸다. ClickHouse는 데이터를 자동 압축하고, 컬럼형 저장소라 그냥 맡겨 두면 행 전반에 걸쳐 더 나은 압축을 얻는다. 별도 저장소 역시 컬럼형 SELECT가 이미 하는 일을 조악하게 재현한 것에 불과했다. 문서를 제대로 읽고 벤치마크를 돌리고 나서야 플랫폼이 기본 제공하는 것보다 느리고 투박한 물건을 만들었음을 깨달았다는 것이다. iOS든 안드로이드든 게임 엔진이든, 어떤 계층 위에서 일하는 개발자에게나 비슷한 이야기가 있을 것이다. 주니어의 복잡하게 얽힌 코드를 한 줄로 바꿔 놓는 노련한 엔지니어의 전형은, 시스템 전체를 꿰뚫을수록 가장 작은 기여로 문제를 풀고 장기적 유지 부담을 줄일 수 있다는 사실에서 나온다.
한국의 실무자에게 이 글이 주는 함의는 분명하다. 라이브러리를 반사적으로 집기 전에 기반 계층을 한 번 더 읽어 보라는 것, 그리고 팀원이 'npm부터 뒤지는' 습관을 보일 때 그것이 무지인지 익숙함인지 재미인지를 구분해 접근하라는 것이다. 다만 로슨의 논지는 플랫폼 활용이 늘 우월하다는 단순한 결론이 아니다. 그는 공백을 메우려 직접 만드는 과정이 곧 학습이자 전문성의 토대였다는 점, 그래서 그 충동을 이해할 가치가 있다는 점을 나란히 둔다. AI 코딩이 이 양상을 어디로 끌고 갈지에 대해서는 낙관과 비관을 함께 품고 있다고만 밝힐 뿐, 단정하지 않는다. 플랫폼이 존재하는 한 "플랫폼을 써라"는 구호는 계속 들리겠지만, 그 구호가 설득을 필요로 한다는 사실 자체가 개발이라는 일의 성격을 드러낸다.