왜 더 많은 개발자가 ‘플랫폼을 활용’하지 않을까요?

AI 요약

웹 개발자에게 브라우저가 제공하는 기능을 활용하라는 조언은 익숙합니다. 직접 만든 JavaScript 코드는 브라우저 기본 기능보다 성능이나 사용성이 떨어질 가능성이 큽니다. 그런데도 개발자는 왜 직접 만들거나 라이브러리를 찾을까요? Nolan Lawson은 그 배경에 기술의 역사와 익숙한 도구, 직접 구현하는 즐거움이 있다고 설명합니다.

플랫폼보다 라이브러리를 먼저 찾는 이유

과거 브라우저는 개발 생태계의 요구를 뒤따라갔습니다. jQuery 같은 라이브러리가 브라우저 API의 빈틈을 메웠고, Internet Explorer 6 같은 구형 브라우저가 사라질 때까지 새 기능을 쓰기 어려웠습니다. 브라우저가 상시 업데이트되는 환경은 비교적 최근에 자리 잡았습니다. 이런 시기에는 직접 구현하는 편이 합리적이었습니다.

도구에 익숙해지는 과정도 영향을 줍니다. React 개발자가 npm에서 컴포넌트를 찾는 데 익숙하면, CSS의 position: sticky처럼 이미 플랫폼에 있는 기능도 패키지로 해결하려 할 수 있습니다. 플랫폼 API와 프레임워크 사이의 사용성 간극을 메우는 라이브러리도 유용합니다. 예를 들어 가상 목록 라이브러리는 성능을 위해 내부에서 DOM API를 직접 다루면서, 사용자에게는 React 개발자가 익숙하게 느낄 추상화를 제공합니다.

문서의 차이도 있습니다. 많은 npm 패키지는 예제와 튜토리얼, 스크린샷을 README나 웹사이트에 제공합니다. 반면 웹 플랫폼 문서는 MDN이 주요 참고처로 자리 잡기 전까지 블로그와 Stack Overflow, CSS-Tricks 등 여러 곳에 흩어져 있었습니다. 일부 문서는 jQuery나 GreenSock 같은 라이브러리를 사용하라고 안내하기도 했습니다.

직접 만드는 즐거움과 그 대가

모든 개발자가 손쉬운 완성품만 찾는 것은 아닙니다. 직접 구현하면 작동 원리를 익히고, 자신의 코드에 기능을 더하며 다듬는 재미를 느낍니다. 직접 만든 결과물에 애착을 갖는 ‘IKEA 효과’도 생깁니다. 모달 창을 만든다고 가정하면, 처음에는 위치와 겹침 순서를 조정하고 배경 스크롤을 막습니다. 접근성을 고려하면 Esc 키 처리, 포커스 가두기, 호출한 요소로 포커스 돌려주기도 구현해야 합니다. 어떤 개발자에게는 번거로운 작업이지만, 다른 개발자에게는 배우고 확장하는 과정 자체가 즐겁습니다.

글쓴이는 과거 IndexedDB와 WebSQL 등 브라우저 저장소 API를 다루는 PouchDB 도구를 만들었습니다. 플랫폼에 빠진 기능을 채우려 polyfill과 shim을 개발한 경험이 쌓여, W3C 표준 회의에 참여하고 IndexedDB 명세에 이슈와 변경 요청을 낼 만큼 깊이 이해하게 됐다고 말합니다. 직접 만드는 일이 플랫폼을 배우는 계기가 될 수 있다는 뜻입니다.

다만 직접 구현이 늘 좋은 선택은 아닙니다. 플랫폼을 잘 몰라 더 나은 기능을 놓칠 수 있습니다. CSS는 과거에 동작 원리를 파악하기 어려웠고, clearfix나 float, min-width: 0 같은 기법은 직관적이지 않았습니다. 줄 수 제한, textarea 크기 조정, 스크롤바 숨기기처럼 흔한 문제를 해결하는 CSS 기능도 부족했던 시기가 있어, 개발자가 익숙한 JavaScript로 직접 만들곤 했습니다.

ClickHouse 사례와 AI 코딩의 불확실성

이 문제는 웹에만 국한되지 않습니다. 글쓴이와 동료는 ClickHouse에 큰 JSON 데이터를 저장하는 방식을 두고 각자 별도 해법을 만들었습니다. 한쪽은 저장 전에 압축했고, 글쓴이는 별도 키-값 저장소에 데이터를 넣고 ClickHouse에는 키만 저장했습니다. 나중에 문서를 읽고 벤치마크를 해보니 둘 다 불필요했습니다. ClickHouse가 데이터를 자동으로 압축하며, 열 지향 저장소 특성상 여러 행의 데이터를 함께 처리하면 압축 효율도 높아집니다. 별도 키-값 저장소는 열 지향 SELECT가 이미 하는 일을 어설프게 다시 만든 셈이었습니다.

AI 코딩에는 낙관과 비관 양쪽 가능성이 있습니다. 낙관적으로 보면 LLM이 플랫폼 API를 폭넓게 알고 있어, 요구에 맞는 기본 기능을 선택하고 테스트와 벤치마크로 검증할 수 있습니다. 개발자가 직접 코드를 쓰지 않으니 자기 코드에 애착을 갖는 효과도 줄어듭니다. 반면 AI가 기존 헬퍼를 재사용하지 않고 비슷한 코드를 반복해서 만들거나, 충분히 시험하지 않은 첫 결과물을 그대로 커밋하면 플랫폼 관용 방식과 어긋난 코드가 늘어날 수 있습니다. 글쓴이는 실제 사용에서 두 양상을 모두 봤으며, 어느 쪽이 우세할지는 확신하지 못합니다.

Lobsters 반응

• @adam_d_ruppe — 많은 개발자가 플랫폼의 기능을 정말 모르는 것 같습니다. 다른 사람들이 모두 한 가지 방식으로 일하면 굳이 알아볼 동기도 줄어듭니다. 사소한 일인데도 상사가 “그렇게 할 수는 있지만 나머지 팀은 어떡하죠?”라고 말할 때마다 답답합니다. 얼마 전 Lobsters에서 JavaScript 없이 추천 투표 폼을 만드는 일이 간단하다고 댓글을 달았더니, 몇몇 사람이 그런 일이 가능한지도, 간단한지도 믿지 못해 저를 나무랐습니다. 모두가 하이퍼링크 하나에 TypeScript 100줄을 써야 한다면, 왜 제가 <a href="url">만으로 된다고 말하는 걸 믿겠습니까?
• @ryan-duve — ClickHouse 압축 경험은 잘 모르겠지만, 처음부터 만드는 일은 배우고 성장하는 좋은 방법입니다. 몇 년 전 데이터베이스 담당자가 자리를 비웠을 때, 어느 금요일 오후에 URL-safe Base64로 인코딩하고 패딩을 제거한 UUID를 일반적인 36자 문자열로 바꾸는 SQL 쿼리를 작성했습니다. Presto였던 것 같습니다. 담당자가 월요일에 돌아와 내장 함수 두 개 정도로 다시 만들었던 것으로 기억합니다. 그래도 그날 SQL과 Base64, UUID에 관해 배운 내용은 지금까지 큰 도움이 됩니다.
  • @nolan — 맞습니다. 직접 실험하지 않고 API를 그대로 받아 쓰기만 하는 세상에서는 배우지 못합니다. polyfill과 shim을 만들었던 경험을 글에서 이야기하며 저도 이 문제를 고민했습니다. 실험은 괜찮지만, 자기 코드에 빠져든 건 아닌지 의심하고 벤치마크와 테스트를 해야 한다고 생각합니다.
• @kornel — 플랫폼 기능은 전부 쓰거나 전부 직접 만드는 식으로 선택해야 하는 경우가 많습니다. 내장 동작이 모든 브라우저에서 완벽하지 않으면 개발자는 처음부터 다시 만들어야 합니다. 날짜 선택기는 그중에서도 특히 답이 없습니다. 줄 높이나 작은 터치 영역, 너무 빠르거나 느린 애니메이션, 사용자 정의 요소와 맞지 않는 애니메이션처럼 사소한 문제 때문일 때도 있습니다. 버그가 있거나 세부 설정을 바꿀 수 없는 기능 때문에 실망한 개발자는 다음부터 플랫폼 기능을 시험해보지도 않고, 처음부터 직접 제어하려 할 것 같습니다.
• @alevizio — 문서 문제는 충분히 주목받지 못하는 것 같습니다. 라이브러리 README는 완성된 결과와 데모를 보여주지만, MDN은 작동 원리를 설명하고 나머지는 개발자가 조립해야 합니다. <dialog>는 수년 동안 잘 작동했지만 기본 스타일이 너무 밋밋해서, 사람들은 완성된 모양을 얻으려고 컴포넌트를 가져옵니다.

원문: Nolan Lawson / 번역·요약: Trawling