"플랫폼을 활용하라"는 말이 20년째 설득에 실패하는 이유
핵심 요약
<dialog> 태그 하나로 끝날 일을 왜 우리는 300줄짜리 모달 컴포넌트로 만들까요? 브라우저 기본 기능이 직접 만든 JavaScript보다 성능과 사용성 면에서 나을 가능성이 높다는 걸 알면서도, 개발자들은 여전히 직접 구현을 택합니다. 이 글은 그 이유를 세 가지로 짚습니다.
- 역사적 지원 격차: 오랫동안 브라우저가 라이브러리 생태계를 뒤따라갔습니다
- 익숙한 도구와 문서: npm 검색 습관이 플랫폼 API보다 먼저 작동합니다
- 직접 만드는 즐거움: 그리고 자기가 만든 코드에 애착이 생기는 IKEA 효과
그리고 이 현상은 웹에만 국한되지 않습니다. 데이터베이스에서도, 모바일 플랫폼에서도 똑같이 반복됩니다.
브라우저보다 생태계가 앞서갔던 시절
"플랫폼을 활용하라(Use the platform)"는 권고의 핵심 질문은 단순합니다. 브라우저가 이미 제공하는 기능을 JavaScript로 다시 만들 필요가 있을까요?
하지만 이 권고에 회의적인 개발자를 이해하려면, 왜 20년이 지나도 여전히 설득이 필요한지를 봐야 합니다. 답은 역사에 있습니다.
jQuery는 브라우저가 동등한 API를 구현하기 전까지 중요한 공백을 메웠습니다. 더 중요한 건 API가 생긴 이후입니다. IE6처럼 뒤처진 브라우저가 시장에서 사라질 때까지 기다려야 했으니까요. 대략 2020년대에 이르기 전까지 개발자들은 지원이 고르지 않은 웹을 상대해야 했고, 그 환경에서 자체 구현은 합리적인 선택이었습니다.
지금은 대부분의 브라우저가 지속적으로 업데이트됩니다. Safari까지 그렇게 볼지는 논쟁의 여지가 있지만, 연간 약 7회의 릴리스는 적지 않은 편입니다. 전제가 바뀌었는데 습관은 그대로 남은 것이죠.
npm에는 "그냥 CSS 쓰세요" 패키지가 없다
두 번째 이유는 더 미묘합니다. npm에서 React 컴포넌트를 찾는 데 익숙해지면, 문제의 성격과 무관하게 익숙한 경로를 먼저 택하게 됩니다.
npm에서 "sticky positioning"을 검색해 보세요. 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 효과
가장 솔직한 이유는 아마 이것입니다. 어떤 개발자에게는 직접 구현하는 일 자체가 더 재미있습니다.
플랫폼 전반을 속속들이 알지 못한다면, 오히려 자기가 쓴 코드가 더 이해하기 쉽게 느껴집니다. 그리고 한 번 만들고 나면 그 수제 코드를 계속 유지하고 손보고 싶어지는 IKEA 효과가 생깁니다.
모달 대화상자를 직접 만드는 과정이 이 동기를 잘 보여줍니다.
- 화면에 콘텐츠를 띄우고 배경을 가리기 위해
position: absolute와z-index를 씁니다 - 배경이 계속 스크롤되는 걸 발견하고
body의overflow를 비활성화합니다 - 접근성을 고려하기 시작하면서
Esc키로 닫기, 포커스 트랩, 실행 요소로 포커스 돌려주기까지 구현합니다 - 애니메이션과 테마, 선택적 닫기 버튼을 더하다 보면 npm에 배포할 라이브러리가 됩니다
누군가에게 이건 반쯤만 작동하는 결과를 낳을 악몽입니다. 하지만 다른 누군가에게는 배우고 실험하는 즐거운 과정이고, <dialog>를 쓰고 끝내는 것보다 훨씬 재미있는 일입니다.
빈틈을 메우며 쌓이는 전문성
이 즐거움은 낭비가 아닙니다. <dialog> 같은 API가 없던 시절, 직접 구현하는 과정은 웹 플랫폼을 배우는 방법이었습니다. 오늘날 "플랫폼을 활용하라"고 권하는 사람 중에도 과거에 폴리필과 심, 라이브러리를 만들었던 사람이 많습니다. PouchDB 개발 경험처럼, 부족한 플랫폼 기능을 메우는 일이 표준 참여로 이어지기도 합니다.
CSS를 우회하는 진짜 이유
물론 자체 구현이 언제나 좋은 것은 아닙니다. 때로는 플랫폼에 대한 지식 부족에서 비롯됩니다.
CSS로 더 잘 해결할 문제에 JavaScript 구현이 널리 쓰인 이유 중 하나는, CSS의 작동 방식을 깊이 배우는 데 시간을 들이지 않았기 때문입니다. 동시에 CSS는 역사적으로 이해하기 어려웠다는 점도 인정해야 합니다.
- clearfix, float,
min-width: 0같은 기법은 전혀 직관적이지 않습니다 - CSS 내부 알고리듬을 이해하는 것보다, 원하는 명령형 로직을 떠올려 JavaScript로 작성하는 편이 쉬울 때가 많습니다
- 줄 수 제한, textarea 크기 조절, 스크롤바 숨기기 같은 흔한 패턴을 간단하게 표현할 방법도 오랫동안 없었습니다
그래서 개발자는 이미 아는 도구로 직접 구현했습니다. 합리적인 대응이었지만, 그 지식 격차는 그대로 남았습니다.
웹만의 문제가 아니다: ClickHouse 사례
플랫폼을 충분히 이해하지 못해 기본 기능을 우회하는 현상은 브라우저에만 국한되지 않습니다. 분석 데이터를 저장하는 ClickHouse에서 큰 JSON 데이터를 다룰 때 벌어진 일을 보죠.
- 한 개발자는 저장 전에 데이터를 압축하는 시스템을 만들었습니다
- 다른 개발자는 데이터를 별도 키-값 저장소에 넣고, ClickHouse에는 키만 저장했습니다
두 방식 모두 ClickHouse가 이미 제공하는 기능을 제대로 활용하지 못한 것이었습니다.
ClickHouse는 데이터를 자동으로 압축합니다. 더구나 열 기반 저장소이기 때문에 압축을 데이터베이스에 맡기는 편이 행 간 압축 효율도 더 좋습니다. 별도 키-값 저장소 역시 열 기반 SELECT가 이미 하는 일을 더 빈약하게 구현한 셈이었습니다. 문서를 충분히 읽고 가설을 검증할 벤치마크를 작성한 뒤에야, 자체 구현이 기본 기능보다 느리고 번거롭다는 사실이 확인됐습니다.
iOS, Android, 게임 엔진 위에서 개발하는 사람도 비슷한 경험이 있을 겁니다. 숙련된 엔지니어가 복잡하게 얽힌 코드를 한 줄로 대체한다는 전형적인 이미지에는 이유가 있습니다. 시스템 전체에 대한 이해가 깊어질수록 필요한 코드가 줄고, 장기적인 유지보수 부담도 함께 줄어듭니다.
AI 코딩은 어느 쪽으로 기울까
그렇다면 LLM이 코드를 쓰는 시대에 이 긴장은 어떻게 될까요? 두 가지 시나리오가 있습니다.
낙관적 경로
- LLM의 폭넓은 플랫폼 지식이 적절한 API 선택으로 이어질 수 있습니다
- 모호한 자연어 요청에서도 원하는 경험에 정확히 맞는 플랫폼 API를 고를 수 있습니다
- 플랫폼 기반 해결책이 자체 구현보다 빠르고 정확할 가능성이 높으므로, 엄격한 테스트와 벤치마크를 거친 에이전트는 이를 선호할 수 있습니다
- 개발자가 코드를 직접 작성하지 않으면 IKEA 효과 자체가 사라질 수 있습니다
비관적 경로
- LLM은 기존 보조 함수를 무시하고 같은 기능을 다시 만드는 중복 작성 경향을 보입니다
- 개발자가 충분한 테스트나 대안 탐색을 요청하지 않은 채 첫 초안을 커밋할 수 있습니다
- 복잡한 보완책을 계속 덧붙이기 때문에, 처음부터 존재할 필요가 없었던 과도하게 복잡한 해결책을 에이전트가 계속 수정하는 상황이 벌어질 수 있습니다
실제 AI 코딩 사용에서는 두 현상이 모두 나타났습니다. 모델과 코딩 하네스가 개선되면서 낙관적인 결과에 가까워지기를 기대할 수는 있지만, 확신하기는 어렵습니다.
마무리: 두 가지를 동시에 이해하기
"플랫폼을 활용하라"는 원칙은 좋은 통찰을 간결하게 담고 있습니다. 하부 계층을 조금 더 이해하면, 과도하게 복잡한 코드를 훨씬 우아하게 바꿀 수 있다는 것이죠.
동시에 직접 만든 복잡한 코드에서 느끼는 창작의 즐거움도 이해할 필요가 있습니다. 플랫폼을 권하는 사람 역시 과거에 그런 코드를 만들며 즐거움을 느꼈던 개발자일 가능성이 높으니까요.
결국 플랫폼이 존재하는 한, "플랫폼을 활용하라"는 권고도 계속 들리게 될 것입니다. 중요한 건 지금 내가 만들고 있는 것이 배움을 위한 것인지, 아니면 단지 플랫폼을 몰라서 하는 재구현인지 구분하는 일입니다.
다음에 새 유틸리티를 만들기 전에, MDN이나 공식 문서를 5분만 먼저 읽어보세요. 그 5분이 300줄을 아껴줄지도 모릅니다.