- 브라우저의 기본 기능을 쓰면 직접 만든 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을 조작하는 저수준 라이브러리는 기꺼이 사용하기도 함
- 가상 목록 라이브러리는 성능을 위해 DOM API를 직접 사용하면서, 초보 React 개발자에게는 이해하기 쉬운 고수준 기능을 제공할 수 있음
- 이런 생태계에서는 전문성이 높은 개발자가 낯선 플랫폼 API를 익숙한 형태로 포장하는 자연스러운 분업이 생김
- 문서의 접근성도 라이브러리 선택에 영향을 미침
- 많은 npm 패키지는 예제, 튜토리얼, 스크린샷을 갖춘 상세한 README나 웹사이트를 제공함
- MDN이 대표적인 웹 문서로 자리 잡고 Google의 web.dev가 더 미래 지향적인 역할을 맡기 전에는, 문서가 블로그, StackOverflow, CSS Tricks 등에 흩어져 있었음
- 이들 자료도 jQuery나 GreenSock 같은 유명 라이브러리를 사용하라고 안내하는 경우가 많았음
- 그러나 편의성만으로 플랫폼 활용에 대한 반감을 모두 설명할 수는 없음
- 당장 문제를 해결하려는 개발자라면 완성된 해결책이 npm, 브라우저, 임의의 GitHub Gist 중 어디에서 왔는지는 크게 신경 쓰지 않을 수 있음
- 어떤 개발자에게는 직접 구현하는 일 자체가 더 재미있음
- 플랫폼 전반을 속속들이 알지 못한다면 직접 쓴 코드가 오히려 이해하기 쉬울 수 있음
- 한 번 만들고 나면 자신의 수제 코드를 계속 유지하고 손보고 싶어지는 IKEA 효과가 생길 수 있음
- 모달 대화상자를 직접 만드는 과정은 이런 동기를 잘 보여줌
- 화면에 콘텐츠를 띄우고 배경을 일부 가리며, 바깥을 클릭하면 닫히게 하려고 position:absolute와 z-index부터 사용할 수 있음
- 배경이 계속 스크롤되면 body의 overflow를 비활성화하고, 접근성을 고려하면서 Esc로 닫기, 포커스 트랩, 실행 요소로 포커스 돌려주기까지 구현하게 됨
- 누군가에게는 반쯤만 작동하는 결과를 낳을 악몽이지만, 다른 누군가에게는 배우고 실험하는 즐거운 과정임
- 애니메이션, 테마, 선택적 닫기 버튼을 더하다 보면 npm에 배포할 라이브러리가 되며, 이런 개발자에게는 <dialog>를 쓰고 끝내는 것보다 훨씬 재미있음
- <dialog> 같은 API가 없던 시절에는 직접 구현하는 과정이 웹 플랫폼을 배우는 방법이었음
- 오늘날 플랫폼 활용을 권하는 사람 중에도 과거에 폴리필, 심, 라이브러리를 만들었던 사람이 많음
- PouchDB 개발 경험은 부족한 플랫폼 기능을 메우는 일이 표준 참여로 이어질 수 있음을 보여줌
- PouchDB 작업의 일부로 IndexedDB, WebSQL 등 브라우저 저장소 API용 도구를 수년간 개발한 경험이 W3C 표준 회의 참여와 IndexedDB 명세의 이슈 및 풀 리퀘스트 작성으로 이어졌음
- 메워야 할 플랫폼의 공백이 없었다면 그만큼의 전문성을 쌓을 관심이나 동기가 생겼을지는 불확실함
- 자체 구현이 언제나 좋은 것은 아니며, 때로는 플랫폼에 대한 지식 부족에서 비롯됨
- CSS로 더 잘 해결할 문제에 JavaScript 구현이 널리 쓰인 이유 중 하나는 CSS의 작동 방식을 깊이 배우는 데 시간을 들이지 않았기 때문임
- 동시에 CSS는 역사적으로 이해하기 어려웠음
- clearfix, float, min-width: 0 기법은 직관적이지 않음
- CSS 내부 알고리듬을 이해하는 것보다 원하는 명령형 로직을 떠올려 JavaScript로 작성하는 편이 더 쉬울 때가 많음
- 오랫동안 줄 수 제한, textarea 크기 조절, 스크롤바 숨기기 같은 흔한 패턴을 간단하게 표현할 방법도 없었으므로, 개발자는 이미 아는 도구로 직접 구현했음
- 플랫폼을 충분히 이해하지 못해 기본 기능을 우회하는 현상은 웹에만 국한되지 않음
- 분석 데이터를 저장하는 ClickHouse에서 큰 JSON 데이터를 다룰 때, 한 개발자는 저장 전에 압축하는 시스템을 만들고 다른 개발자는 별도 키-값 저장소에 데이터를 넣은 뒤 ClickHouse에는 키만 저장했음
- 두 방식 모두 ClickHouse가 이미 제공하는 기능을 제대로 활용하지 못했음
- ClickHouse는 데이터를 자동 압축하며, 열 기반 저장소이므로 압축을 맡기는 편이 행 간 압축 효율도 더 좋음
- 별도 키-값 저장소 역시 열 기반 SELECT가 이미 하는 일을 더 빈약하게 구현한 셈이었음
- 문서를 충분히 읽고 가설을 검증할 벤치마크를 작성한 뒤에야, 자체 구현이 기본 기능보다 느리고 번거롭다는 사실을 확인했음
- iOS, Android, 게임 엔진 등 다른 플랫폼 위에서 개발하는 사람도 비슷한 경험을 했을 수 있음
- 숙련된 엔지니어가 복잡하게 얽힌 코드를 한 줄로 대체한다는 전형적인 이미지에는 이유가 있음
- 시스템 전체에 대한 이해가 깊어질수록 필요한 코드를 최소화하고 장기적인 유지보수 부담을 줄일 수 있음
- 낙관적 시나리오에서는 LLM의 폭넓은 플랫폼 지식이 적절한 API 선택으로 이어질 수 있음
- 모호한 자연어 요청에서도 원하는 경험에 정확히 맞는 플랫폼 API를 고를 수 있음
- 플랫폼 기반 해결책이 자체 구현보다 빠르고 정확할 가능성이 높으므로, 엄격한 테스트와 벤치마크를 거친 에이전트가 이를 선호할 수 있음
- 개발자가 코드를 직접 작성하지 않으면 IKEA 효과도 사라질 수 있음
- 비관적 시나리오에서는 플랫폼 관례를 따르지 않는 자체 코드가 급증할 수 있음
- LLM은 기존 보조 함수를 무시하고 같은 기능을 다시 만드는 등 코드를 중복 작성하는 경향을 보임
- 개발자가 충분한 테스트나 대안 탐색을 요청하지 않은 채 첫 초안을 커밋할 수 있음
- 복잡한 보완책을 계속 덧붙일 수 있기 때문에, 처음부터 존재할 필요가 없었던 과도하게 복잡한 해결책을 에이전트가 계속 수정할 수 있음
- 실제 AI 코딩 사용에서는 두 현상 모두 나타났음
- 모델과 코딩 하네스가 개선되면서 낙관적인 결과에 가까워지기를 기대할 수는 있지만, 확신할 수는 없음
- “플랫폼을 활용하라”는 원칙은 하부 계층을 조금 더 이해하면 과도하게 복잡한 코드를 더 우아하게 바꿀 수 있다는 생각을 간결하게 담음
- 동시에 직접 만든 복잡한 코드에서 느끼는 창작의 즐거움도 이해할 필요가 있음
- 플랫폼을 권하는 사람 역시 그런 코드를 만들며 즐거움을 느꼈던 개발자일 수 있음
- 플랫폼이 존재하는 한 “플랫폼을 활용하라”는 권고도 계속 들리게 될 것임