왜 더 많은 개발자가 “플랫폼을 활용”하지 않을까?

브라우저의 기본 기능을 쓰면 직접 만든 JavaScript보다 성능과 사용성이 나을 가능성이 높지만, 플랫폼 활용을 꺼리는 이유에는 역사적 지원 격차, 익숙한 도구, 직접 만드는 즐거움이 함께 작용함 라이브러리 생태계는 브라우저의 부족한 기능뿐 아니라 사용 편의성과 문서의 간극도 메워 왔으며, 낯선 플랫폼 API를 개발자가 익숙한 형태로 제공함 직접 구현하는 과정은 불완전한 결과를 낳기도 하지만, 플랫폼을 깊이 배우는 계기가 되며 자신이 만든 코드에 애착을 느끼는 IKEA 효과도 생김 플랫폼을 충분히 이해하지 못하면 이미 있는 기능을 더 느리고 복잡하게 재구현할 수 있으며, ClickHouse의 압축과 열 기반 조회를 따로 구현했던 사례가 이를 보여줌 AI 코딩은 적절한 플랫폼 API 선택을 도울 수도, 불필요한 자체 구현을 늘릴 수도 있음. 실제 사용에서 두 현상 모두 나타났으며 어느 쪽으로 기울지는 확실하지 않음 브라우저보다 생태계가 앞서갔던 역사 “플랫폼을 활용하라”는 권고의 핵심은 브라우저가 제공하는 기능을 JavaScript로 다시 만들 필요가 있느냐는 것임 직접 만든 구현은 브라우저의 기본 기능보다 성능과 사용성이 떨어질 가능성이 높음 다만 이 권고에 회의적인 개발자를 이해하려면, 왜 여전히 설득이 필요한지 살펴볼 필요가 있음 오랫동안 브라우저는 그 위의 라이브러리 생태계를 뒤따라갔음 jQuery는 브라우저가 동등한 API를 구현하기 전까지 중요한 공백을 메웠으며, API가 생겨도 IE6 같은 뒤처진 브라우저가 사라질 때까지 기다려야 했음 지금은 대부분의 브라우저가 지속적으로 업데이트되지만, Safari까지 그렇게 볼지는 논쟁의 여지가 있음. 그래도 연간 약 7회의 릴리스는 적지 않은 편임 대략 2020년대에 이르기 전까지는 지원이 고르지 않은 웹을 상대해야 했으므로, 자체 구현이 합리적인 선택이었음 익숙한 도구와 문서가 만든 선택 npm에서 React 컴포넌트를 찾는 데 익숙하면 문제와 무관하게 익숙한 경로를 먼저 택하기 쉬움 npm에서 “sticky positioning”을 검색해도 CSS position: sticky를 그냥 쓰라고 알려주는 패키지는 없음 표준이 충분히 갖춰져 있어도 라이브러리는 프레임워크의 사용 편의성과 하부 플랫폼 사이의 간극을 메움 React 개발자는 직접 DOM API를 쓰는 것을 꺼리면서도, 내부에서 DOM을 조작하는 저수준 라이브러리는 기꺼이 사용하기도 함 가상 목록 ...