Boneyard — 실제 DOM에서 스켈레톤 UI를 자동으로 뽑아주는 도구

스켈레톤 UI, 직접 만들어본 적 있나요?

앱이나 웹사이트에서 데이터를 불러올 때, 회색 네모 상자들이 깜빡거리면서 콘텐츠가 로딩되고 있음을 알려주는 화면을 본 적 있을 거예요. 이걸 스켈레톤 스크린(Skeleton Screen)이라고 하는데요. 유튜브, 페이스북, 링크드인 같은 서비스에서 많이 쓰이는 UI 패턴이에요. 전통적인 로딩 스피너보다 사용자 경험이 훨씬 좋다고 알려져 있어서, 요즘은 거의 표준처럼 쓰이고 있죠.

그런데 문제는 이 스켈레톤 UI를 만드는 게 생각보다 귀찮다는 거예요. 실제 콘텐츠의 레이아웃과 최대한 비슷하게 회색 블록들을 배치해야 하거든요. 컴포넌트 구조가 바뀔 때마다 스켈레톤도 같이 업데이트해야 하고, 결국 "원본과 동기화"하는 게 지속적인 부담이 돼요. 이런 고민을 해결해주겠다고 나온 오픈소스 도구가 바로 Boneyard예요.

Boneyard가 하는 일

Boneyard의 아이디어는 심플해요. 실제 렌더링된 DOM(브라우저가 그린 화면 구조)을 분석해서, 거기에서 자동으로 스켈레톤 스크린을 생성해주는 거예요. 이게 뭐냐면, 여러분이 컴포넌트를 만들고 실제 데이터로 화면을 그리면, Boneyard가 그 화면의 각 요소 위치와 크기를 읽어서 "이 자리에 이 크기의 회색 블록을 놓으면 되겠구나" 하고 스켈레톤을 만들어주는 거예요.

기존 방식에서는 개발자가 스켈레톤 컴포넌트를 따로 만들어야 했어요. 예를 들어 카드 컴포넌트가 있으면 CardSkeleton이라는 별도의 컴포넌트를 만들어서 비슷한 크기의 회색 블록들을 수동으로 배치했죠. 카드 디자인이 바뀌면? CardSkeleton도 같이 수정해야 해요. 컴포넌트가 50개면 스켈레톤도 50개를 관리해야 하는 거죠.

Boneyard는 이 과정을 자동화해요. 실제 DOM에서 직접 스켈레톤을 추출하기 때문에, 원본 컴포넌트가 바뀌면 스켈레톤도 자동으로 바뀌어요. "픽셀 퍼펙트(pixel-perfect)"를 표방하는 만큼, 실제 레이아웃과 정확히 일치하는 스켈레톤을 만들어준다는 게 핵심 장점이에요.

기술적으로 어떻게 동작하는 걸까

DOM을 순회하면서 각 요소의 getBoundingClientRect() 같은 API로 위치와 크기 정보를 가져오고, 텍스트 노드, 이미지, 버튼 같은 요소들을 식별해서 각각을 적절한 스켈레톤 블록으로 변환하는 방식이에요. 텍스트는 텍스트 길이에 맞는 줄 모양 블록으로, 이미지는 이미지 크기에 맞는 사각형 블록으로 바꾸는 식이죠.

사용법도 간단한 편인데요. 프로젝트에 설치한 뒤 스켈레톤을 생성하고 싶은 DOM 요소를 지정해주면 돼요. React, Vue 같은 특정 프레임워크에 종속되지 않고 순수 DOM 기반으로 동작하기 때문에, 어떤 프론트엔드 스택에서든 사용할 수 있다는 것도 장점이에요.

기존 스켈레톤 라이브러리와 뭐가 다를까

프론트엔드 생태계에는 이미 스켈레톤 관련 라이브러리가 꽤 있어요. React Loading Skeleton이나 MUI의 Skeleton 컴포넌트 같은 것들이 대표적인데요. 이런 라이브러리들은 기본적으로 "빌딩 블록"을 제공하는 방식이에요. 원형, 사각형, 텍스트 줄 모양의 스켈레톤 컴포넌트를 제공하고, 개발자가 직접 조합해서 원하는 스켈레톤 레이아웃을 만드는 거죠.

Boneyard의 접근은 완전히 반대예요. 개발자가 조합하는 게 아니라, 이미 완성된 화면에서 자동 추출하는 거예요. 이 방식의 장점은 위에서 말했듯 동기화 문제가 없다는 거고, 단점은 실제 렌더링된 DOM이 필요하다는 거예요. 즉, 서버 사이드 렌더링 환경이나 데이터가 아직 없는 초기 상태에서는 활용이 제한될 수 있어요. 실제 데이터로 한 번은 화면을 그려야 거기서 스켈레톤을 추출할 수 있으니까요.

그래서 Boneyard가 모든 스켈레톤 문제를 해결하는 은탄환은 아니에요. 하지만 "대부분의 컴포넌트에 빠르게 스켈레톤을 적용하고 싶다"는 실용적인 니즈에는 잘 맞는 도구예요.

한국 개발자에게 주는 시사점

한국 스타트업이나 SI 프로젝트에서 스켈레톤 UI는 "있으면 좋지만 우선순위에서 밀리는" 작업인 경우가 많아요. 일정이 빠듯한데 로딩 상태까지 신경 쓸 여유가 없다는 거죠. Boneyard 같은 도구를 쓰면 그 비용을 크게 줄일 수 있어요. 별도의 스켈레톤 컴포넌트를 만들 필요 없이 자동으로 생성하니까요.

또 하나 생각해볼 점은, 이런 "자동화 접근법"의 아이디어 자체예요. 프론트엔드 개발에서 반복적으로 만들어야 하는 것들 — 스켈레톤, 스토리북 스토리, 테스트 코드 등 — 을 실제 DOM이나 컴포넌트에서 자동 추출하는 접근이 점점 늘고 있거든요. 이 트렌드를 눈여겨볼 만해요.

프론트엔드 개발을 하고 계신다면 한번 GitHub에서 코드를 살펴보시는 것도 추천드려요. DOM을 순회하면서 시각적 정보를 추출하는 로직 자체가 배울 점이 많거든요.

정리하자면

스켈레톤 UI를 수동으로 만들고 유지보수하는 건 꽤 번거로운 작업인데, Boneyard는 실제 DOM에서 자동으로 추출하는 역발상으로 이 문제를 풀어요. 모든 상황에 맞는 건 아니지만, 빠르게 스켈레톤을 적용하고 싶을 때 유용한 선택지가 될 수 있어요. 여러분은 스켈레톤 UI를 어떻게 관리하고 계신가요? 자동 생성 방식을 써보신 경험이 있다면 공유해주세요.