새 화면을 만들 때 개발팀은 먼저 컴포넌트나 라이브러리를 찾곤 한다. 날짜 입력창, 화면 위에 붙어 있는 메뉴, 확인 대화상자처럼 익숙한 기능도 구현 목록에 올라간다. 그런데 브라우저가 이미 처리하는 일을 다시 만들면, 팀은 기능 하나와 함께 그 기능의 오류와 예외까지 떠안는다.
개발자 놀런 로슨은 2026년 10월 3일 글에서 “플랫폼을 활용하라”는 조언이 왜 쉽게 받아들여지지 않는지 돌아봤다. 브라우저나 데이터베이스가 제공하는 기본 기능을 먼저 쓰자는 뜻이다. 그는 이 조언을 지지하면서도, 직접 구현하는 개발자를 무지한 사람으로만 보면 이유를 놓친다고 설명한다. PM과 개발 조직이 가져갈 질문은 새 라이브러리를 금지할지가 아니라, 이번 요구사항 중 어떤 일을 플랫폼에 맡길 수 있는지다.
기본 기능이 있어도 라이브러리를 먼저 찾는 이유
로슨은 과거의 브라우저 지원 격차부터 짚는다. jQuery 같은 라이브러리는 브라우저마다 달랐던 동작과 부족한 기능을 메웠다. 표준 기능이 생겨도 오래된 브라우저를 쓰는 사용자가 남아 있으면 바로 적용할 수 없었다. 직접 구현하거나 라이브러리를 쓰는 선택에는 당시의 사정이 있었다.
그때 익힌 습관은 지원 환경이 바뀐 뒤에도 남는다. React 컴포넌트를 검색하는 데 익숙한 사람은 메뉴 고정 문제를 만나도 npm부터 열 수 있다. 로슨이 드는 예는 CSS의 position: sticky다. 브라우저가 맡을 수 있는 기능이라도, 익숙한 검색 경로에서는 패키지가 먼저 보인다.
설명 방식도 선택에 영향을 준다는 것이 그의 해석이다. 라이브러리 사이트는 예제와 실행 화면으로 바로 할 수 있는 일을 보여 준다. 표준 문서는 API의 개념과 동작을 설명하는 데 더 많은 지면을 쓴다. 원문이 나란히 놓은 Dragula와 MDN 화면에서도, 앞쪽은 요소를 옮기는 예제를 보여 주고 뒤쪽은 드래그 앤드 드롭 인터페이스를 설명한다. 이 화면 비교는 어느 구현이 더 빠른지를 입증하는 자료가 아니라, 개발자가 어디에서 더 쉽게 시작점을 찾는지에 관한 예시다.
로슨은 라이브러리가 표준 기능을 익숙한 형태로 감싸는 역할도 인정한다. 예를 들어 복잡한 DOM 조작을 숨기고 React 개발자가 쓰기 쉬운 인터페이스를 제공할 수 있다. 따라서 기본 API가 있다는 사실만으로 라이브러리의 효용이 사라지지는 않는다. 팀이 줄일 수 있는 것은 불필요한 중복 구현이지, 필요한 사용 편의까지는 아니다.
대화상자를 띄우는 일과 제대로 닫는 일은 다르다
확인 대화상자는 박스를 화면 위에 겹치면 끝나는 기능처럼 보인다. 직접 만들기 시작하면 키보드로 닫기, 창 안으로 포커스 이동, 배경 조작 차단 같은 동작이 뒤따른다. 마우스로 한 번 눌러 본 화면만으로는 이런 누락을 찾기 어렵다.
HTML의 <dialog>를 showModal()로 열면 브라우저는 나머지 페이지를 상호작용할 수 없는 상태로 만들고, 기본 Esc 닫기와 초기 포커스 처리를 제공한다. MDN도 별도 요소로 대화상자를 만들 경우 이런 동작을 다시 구현해야 한다고 설명한다. 대화상자의 제목을 적절히 연결하고, 키보드가 없는 기기에서도 쓸 수 있도록 닫기 버튼을 두는 일은 개발팀의 몫이다. 배경 스크롤을 어떻게 처리할지도 별도로 확인해야 한다.
아래는 이 글을 위해 격리된 Chromium에서 실행한 작은 예제다. 열기 버튼에서 showModal()을 호출하고, 닫기에는 method="dialog" 폼을 썼다. 자체 포커스 가두기나 Esc 이벤트 처리 코드는 넣지 않았다. 창을 열면 닫기 버튼에 포커스가 갔고, Esc로 닫은 뒤에는 열기 버튼으로 돌아왔다. 이 예제의 결과를 모든 브라우저와 보조기기의 동작으로 확대할 수는 없으므로, 실제 제품은 지원 대상에서 같은 흐름을 시험해야 한다.
로슨은 이 과정을 직접 만드는 재미도 인정한다. 그는 PouchDB에서 브라우저 저장 API를 다루며 표준을 깊이 배웠고, 이후 W3C 회의와 IndexedDB 명세 작업에도 참여했다고 회고한다. 학습용으로 직접 만드는 경험과 제품에서 장기간 유지할 구현을 고르는 결정은 구분할 필요가 있다. 팀은 실험에서 배운 내용을 남기되, 배포할 코드에는 어떤 추가 동작이 꼭 필요한지 다시 물을 수 있다.
ClickHouse 압축 사례에서는 두 우회로가 모두 불필요했다
로슨이 겪은 비슷한 문제는 브라우저 밖에도 있었다. 분석용 데이터베이스 ClickHouse에 큰 JSON 데이터를 저장하려고 동료는 저장 전에 압축하는 시스템을 만들었다. 로슨은 데이터를 별도 키-값 저장소에 두고 ClickHouse에는 키만 넣었다. 그는 문서를 읽고 벤치마크를 작성한 뒤, 두 방식 모두 플랫폼이 이미 하는 일을 우회했다는 결론에 도달했다고 썼다.
ClickHouse는 데이터를 압축해 저장한다. 공식 문서는 열 단위로 값을 배치하고, 정렬된 값의 인접한 반복 패턴을 압축에 활용한다고 설명한다. 압축 효과는 정렬 키와 데이터 타입, 코덱 설정에 영향을 받는다. 로슨은 자신의 환경에서 기본 기능을 쓰는 쪽이 직접 만든 방식보다 빠르고 덜 복잡했다고 보고했지만, 글에는 비교 시간이나 압축률 수치를 공개하지 않았다.
이 사례에서 제품팀이 참고할 부분은 ClickHouse를 쓰면 모든 JSON 저장 문제가 해결된다는 결론이 아니다. 저장 기능을 추가하기 전에 현재 데이터베이스의 압축과 조회 방식을 확인해야 한다는 것이다. 별도 저장소를 붙이면 쓰기 실패 시 두 저장소의 일치 여부를 관리하고, 조회 경로와 백업도 함께 운영해야 한다. 분리가 꼭 필요한 요구사항이 있다면 이 비용을 감수할 수 있지만, 압축이 필요하다는 이유만으로 곧바로 추가할 일은 아니다.
구현 승인 전에 무엇을 확인하면 좋을까
PM은 “확인창을 만든다” 대신 사용자가 완료해야 하는 행동을 요구사항으로 적을 수 있다. 개발팀은 그 행동을 기본 기능으로 먼저 시험하고, 지원 브라우저와 접근성 요구에 맞지 않는 부분을 기록한다. 그런 다음 부족한 부분만 직접 구현할지, 검증된 라이브러리로 보완할지 결정한다. 플랫폼을 우선 검토하되 선택을 신념 싸움으로 만들지 않는 방식이다.
코딩 에이전트에도 같은 순서를 요청할 수 있다. 코드를 추가하기 전에 저장소의 기존 헬퍼와 플랫폼 API를 찾고, 작은 예제로 실제 동작을 비교하게 하는 것이다. 로슨은 모델이 적절한 API를 찾아 중복 구현을 줄일 가능성과, 기존 코드를 무시한 채 복잡한 구현을 더 쌓을 가능성을 함께 제시했다. 자신의 사용 경험에서는 두 현상을 모두 봤다는 설명이며, 어느 쪽이 우세해질지는 전망으로 남겼다.
구현 검토 기록에는 채택한 기본 기능, 제품 요구와 맞지 않았던 동작, 추가 코드로 보완한 범위를 남기면 된다. 다음 사람이 같은 기능을 다시 만들거나 라이브러리를 교체할 때, 팀이 무엇을 시험하고 왜 이 선택을 했는지 알 수 있다.
출처: Nolan Lawson, Why don’t more developers “use the platform”? · MDN: dialog · ClickHouse: Compression in ClickHouse