지난 1편에서 내 작업물이 로컬 환경에서 완벽하게 동작하는 것을 확인했고, AI에게도 코드 리뷰를 받아 “이대로 배포해도 된다.”는 자신감 넘치는 답변까지 들었다. 이 정도면 충분하다는 생각에 바로 호스팅을 진행했다. (호스팅은 카페24 매니지드 워드프레스 상품을 선택했다.)
무료 도메인이 개설되자마자 로컬 데이터를 마이그레이션하고 FTP로 테마 파일을 실서버에 업로드했다. 이로서 내 두 번째 웹 포트폴리오가 전 세계 인터넷에 공개되었다. 이제 남은 건 최종 테스트뿐.
- 첫번째 : PC 크롬 브라우저
모든 페이지가 의도한 대로 동작했다. 애니메이션도 부드러웠고, 인터랙션도 만족스러웠다. 합격. - 두 번째 : 구형 안드로이드 기기
간헐적으로 미세한 프레임 드롭이 있었지만 크게 거슬릴 정도는 아니었다. 이쪽도 합격. - 세 번째 : 아이폰 & 아이패드
한 마디로 총체적 난국이었다. 사이트가 열리고 인트로 로딩이 시작되는 순간부터 눈을 의심할 수밖에 없었다. 분명 벡터 이미지인 SVG 로고가 흐릿하게 보였고(이건 기회가 되면 따로 다뤄보려 한다.), 스크롤은 부드럽게 움직이기는커녕 거의 끊기다시피 했다. 애니메이션은 프레임이 뚝뚝 떨어졌고, 일부 레이아웃은 의도와 전혀 다르게 무너지고 있었다.
PC 크롬에서는 60FPS로 유려하게 돌아가던 사이트가 iOS 사파리에서는 완전히 다른 사이트가 되어 있었다.
단순히 조금 느린 수준이 아니었다. 나조차도 바로 뒤로 가기를 누르고 싶어질 만큼… 등골이 서늘해지는 순간이었다.
아, 크로스 브라우징
사실 진작 했어야 했다. 너무 안일했다. 예전부터 iOS 사파리가 까다롭다는 사실은 알고 있었지만, 설마 내 사이트가 이 정도로 영향을 받을 줄은 전혀 예상하지 못했다.
우선 의심되는 것들을 하나씩 정리했다. 가장 먼저 떠오른 것은 position: sticky, 그다음은 iOS에서 트랜지션과 함께 사용할 경우 성능 저하를 일으킨다고 알려진 CSS 속성들, 그리고 내가 며칠에 걸쳐 직접 구현한 커스텀 스크롤 스크립트, 이 모든 것들이 복합적으로 얽혀 있을 거라고 생각했다.
문제를 해결하기 위해 다시 AI의 도움을 받아 꼬박 하루를 씨름했지만 이번만큼은 기대했던 답을 얻지 못했다.
(아니~ 100점 만점에 10,000점짜리 코드라며!!!)
결국 가장 원시적이면서도 가장 확실한 방법을 선택했다.
프로젝트를 통째로 백업한 뒤 의심 가는 기능을 하나씩 제거하면서 테스트하기 시작했다.
트렌지션 애니메이션을 지웠다. 그래도 렉은 그대로였다.
sticky와 fixed를 지웠다. 여전히 버벅거렸다.
JavaScript를 껐다. 달라진 것이 없었다.
이런식으로 하나씩 제거하다보니 결국은 아무것도 없는 빈 페이지만 남은 지경까지 갔다.
그런데도 iOS는 계속 버벅거리고 있었다. (엥?)
그제야 깨달았다. 문제는 내가 가장 의심하지 않았던 곳에 있었다는 것을, 바로 뷰포트 전체를 덮고 있던 노이즈 필터 효과. 설마 이것 때문일까 싶어서 제거해봤더니 거짓말처럼 성능이 살아났다.
허무했다.
정말 허무할 정도였다.
다시, 라이브러리 도입
가장 큰 렉의 원인을 해결하고 나니 남은 건 커스텀 스크롤이었다. 직접 한 줄 한 줄 만들었던 코드였고, 며칠 밤을 붙잡고 다듬었던 나름의 자존심 같은 결과물이기도 했다.
하지만 현실은 냉정했다. iOS에서는 이 스크립트 역시 적지 않은 부담을 주고 있었다.
결국 결심했다. 미련 없이 삭제하기로. 그리고 대신 전 세계 수많은 하이엔드 웹사이트에서 이미 검증된 스무스 스크롤 라이브러리인 Lenis와 웹 애니메이션의 표준이나 다름없는 GSAP의 ScrollTrigger를 도입하기로.
// 며칠 밤의 고생을 단 몇 줄로 해결해 준 Lenis 초기화 코드
const lenis = new Lenis({
duration: 1.2,
easing: (t) => Math.min(1, 1.001 - Math.pow(2, -10 * t)),
direction: 'vertical',
gestureDirection: 'vertical',
smooth: true,
smoothTouch: false,
touchMultiplier: 2,
});
function raf(time) {
lenis.raf(time);
requestAnimationFrame(raf);
}
requestAnimationFrame(raf);코드를 대체한 뒤 다시 아이폰으로 접속했다. 그동안 나를 괴롭히던 스크롤 버벅임은 거짓말처럼 사라졌다. 손가락을 움직이는 대로 화면이 자연스럽게 따라왔고, 애니메이션도 훨씬 안정적으로 동작했다.
순간 허탈하면서도 웃음이 나왔다.
‘처음부터 괜한 오기 부리지 말걸.’
시행착오로 얻은 교훈
이번 프로젝트를 통해 얻은 교훈은 크게 세 가지였다.
첫 번째, 좋은 개발은 모든 것을 처음부터 직접 만드는 것이 아니다.
이미 수많은 서비스에서 검증된 라이브러리와 도구가 있다면, 그것을 상황에 맞게 활용하는 것도 중요한 역량이라는 사실을 다시 한 번 느꼈다. 처음부터 모든 것을 직접 구현하는 것보다, 검증된 기술을 적재적소에 활용하는 것이 더 좋은 결과를 만들어낼 때도 많았다.
두 번째, 브라우저마다 구현 방식의 차이를 고려해야 한다.
브라우저마다 렌더링 방식이 다르다는 사실은 알고 있었지만, 직접 겪어 보니 생각보다 훨씬 민감했다. 특히 ‘CSS는 표준 문법이니까 괜찮겠지.’라는 생각으로 접근해서는 안 된다는 것도 다시 한번 깨달았다. 표준을 지원하더라도 브라우저가 비효율적으로 처리하는 방식이라면, 처음부터 다른 방법을 선택하는 것이 결국 더 빠른 길이었다.
세 번째, AI를 활용하는 방법에 대한 생각이 달라졌다.
AI는 이제 없어서는 안 될 개발 도우미다. 코드를 작성하거나 API를 설명하고, 문법을 찾는 일에서는 놀라울 만큼 뛰어난 능력을 보여준다. 하지만 실제 프로젝트에서 문제가 발생했을 때는 조금 달랐다.
AI는 눈앞의 오류를 해결하는 데는 능숙했지만, 프로젝트 전체의 구조를 이해하고 여러 기능 사이의 의존성을 함께 살펴보며 근본적인 원인을 추적하는 데에는 아직 한계가 있었다. 결국 이번 문제를 해결한 것은 기능 하나를 수정하는 일이 아니라, 프로젝트 전체를 의심하고 하나씩 제거하며 원인을 좁혀 나가는 과정이었다.
한때는 무섭도록 빠르게 발전하는 AI를 보며 ‘이제 새로운 기술을 공부하는 의미가 있을까?’라는 생각을 한 적도 있었다. 어차피 몇 년 뒤면 AI가 대부분 해결해 줄 텐데, 굳이 내가 배울 필요가 있을까 하는 회의감도 들었다.
하지만 이번 프로젝트를 마치고 생각이 조금 달라졌다.
AI 시대에도 변하지 않는 것
AI는 최고의 도구가 될 수 있다. 하지만 어떤 도구를 언제 사용해야 하는지 판단하고, 예상하지 못한 문제를 발견하며, 프로젝트 전체를 완성도 있게 다듬는 일은 여전히 사람의 몫이다.
그래서 앞으로도 새로운 기술을 배우는 일만큼은 멈추지 않으려고 한다.
이번 워드프레스를 이용한 웹 포트폴리오 제작은 단순히 사이트 하나를 완성한 프로젝트가 아니었다. 디자이너이자 개발자로서 문제를 해결하는 방식과 기술을 바라보는 시각을 한 단계 더 성장시켜 준, 오래 기억에 남을 경험이었다.
