글 보드의 무거운 시각 효과 제거
목차
포트폴리오의 "오늘의 글" 섹션에 있던 파티클 캔버스 효과를 숨겼다. 작지만 의외로 중요한 결정이었는데, 이 글에서는 왜 이런 일이 생기는지, 어떤 것들을 고려해야 하는지 풀어보자.
파티클 캔버스, 왜 있었나
웹 포트폴리오에서 시각적 임팩트를 주려고 캔버스 기반의 파티클 효과를 자주 쓴다. 떨어지는 별, 움직이는 점들, 선을 그으며 움직이는 노드 같은 것들이 그것인데, 이런 효과들은 페이지를 둘러보는 경험을 풍부하게 해준다. 특히 글의 목록을 보는 "오늘의 글" 같은 섹션에선 차분한 콘텐츠 영역에 움직임을 더해서 시선을 끌 수 있다.
하지만 이런 효과들엔 항상 트레이드오프가 따른다. 캔버스는 JavaScript로 지속적인 렌더링을 해야 하고, 이는 CPU와 GPU를 점유한다. 특히 저사양 기기나 모바일에서는 스크롤 성능 저하, 배터리 소모, 프레임 드롭 같은 문제로 이어진다. 게다가 그 효과가 실제로 사용자 경험에 얼마나 도움 되는지는 또 다른 문제다.
파티클 캔버스를 숨기기로 결정
이번에 파티클 캔버스를 숨긴 것은 이런 비용이 효과보다 크다고 판단했기 때문이다. 가능한 원인들을 생각해보면:
- 성능: 글 목록을 스크롤할 때 파티클이 계속 렌더링되면서 프레임이 떨어진다
- 모바일 경험: 터치 기기에서 스크롤이 끊기거나 부자연스러워 보인다
- 유지보수: 파티클 라이브러리의 버전 업데이트나 디버깅 시 관리 비용 증가
- 목적 불일치: 이 섹션의 핵심은 글을 읽게 하는 것인데, 애니메이션이 오히려 방해가 될 수 있다
HTML 파일을 수정해 파티클 캔버스 요소를 숨기거나 비활성화하는 방식으로 처리했다. 이는 전체 코드를 지우는 대신 필요할 때 다시 활성화할 수 있도록 가역적으로 남겨둔 것이다. CSS의 display: none이나 visibility: hidden으로 간단히 처리하거나, HTML 마크업 자체를 조건부로 렌더링하지 않는 방식을 썼을 것 같다.
영문·한글 동시 대응의 의미
변경 파일이 portfolio/en/index.html과 portfolio/index.html 두 개인 점도 의미가 있다. 다국어 지원 시에는 언어별로 파일을 분리하는 경우가 많은데, 이렇게 되면 한 가지 변경을 여러 파일에 반영해야 한다.
| 파일 | 역할 | 고려사항 |
|---|---|---|
| portfolio/index.html | 한글 버전 | 로컬 사용자 기본 뷰 |
| portfolio/en/index.html | 영문 버전 | 국제 방문자 대응 |
한 가지 버그나 개선사항이 생겼을 때 영문·한글을 동시에 수정해야 한다는 건 관리 비용이 2배라는 뜻이다. 이런 상황은 나중에 파일 추상화(예: 템플릿 엔진, 공유 CSS/JavaScript 모듈) 고려의 신호가 된다. 현재는 정적 HTML이라면 차라리 컴포넌트 기반으로 리팩토링을 검토할 시점이 될 수 있다.
되돌아보기: 시각 효과의 올바른 사용
이번 경험에서 얻은 교훈들:
-
효과는 선택지, 필수가 아니다: 페이지를 예쁘게 만드는 것도 중요하지만, 콘텐츠를 읽히게 하는 게 먼저다. 파티클 캔버스처럼 눈에 띄는 효과일수록 신중해야 한다.
-
성능을 먼저 측정하자: "아마 괜찮겠지" 하고 넣지 말고, 실제 사용자 기기(특히 저사양)에서 성능을 재봐야 한다. DevTools의 Performance 탭, Lighthouse 점수 같은 것들이 도움 된다.
-
가역성 유지: 삭제하는 대신 숨기거나 비활성화하면, 나중에 "역시 필요했다" 할 때 복구가 쉽다. 지금처럼 CSS 클래스나 데이터 속성으로 제어하면, 언제든 다시 활성화할 수 있다.
-
다국어 관리 비용: 영문·한글을 별개 파일로 관리하면 변경 이력이 중복된다. 규모가 커지면 템플릿 엔진이나 i18n 라이브러리 도입을 고려해야 한다.
이번 작업을 통해 "예쁜 것"과 "빠른 것"의 균형을 맞추는 게 얼마나 중요한지 다시 한번 느꼈다. 다음 번엔 파티클이 정말 필요한 곳에만, 그리고 성능 측정 후에 넣기로 다짐한다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.