포트폴리오 프로젝트 회고
프롤로그
04.29부터 05.08까지, 포트폴리오 프로젝트를 진행한 회고를 해볼까 한다. 썩 대단하거나, 획기적이라던가, 그렇진 않지만, 이 포트폴리오 프로젝트를 진행하는 데엔 개인적인 도전과 목표가 여럿 있었다.
첫 번째
그 첫 번째는 퍼블리싱 역량에 대한 증명이다.
프런트엔드 엔지니어는 웹에서의 클라이언트 엔지니어라고 생각한다. 클라이언트에서의 통신뿐만 아니라 디자인 감각을 포함한 퍼블리싱 역할도 필요하다고 생각한다.
여태 진행한 개인 프로젝트들은 대개 React 혹은 기반 프레임워크인 NextJS 기반의 프로젝트였다. 이것들이 나쁘다…는 아니지만, 보다 순수한 퍼블리싱의 역량을 보여줄 만한 그런 것은 없다고 스스로 판단했다.
그리고 여러 페이지를 염두에 두어 만들 것도 아니었기 때문에, 굳이 다른 프레임워크가 필요하지도 않았다. 필요하지 않은 기술을 아무튼 좋으니 사용할 이유는 없다고 생각한다. 그것이 곧 기술 부채 아닐까?
그래서 순수한 HTML으로 마크업을 작성하기로 했다.
스타일 시트는 CSS 프레임워크인 Tailwind를 좋아하고, styled-component도 여전히 기억하고 있고, 매력적이다. 요즘은 emotion도 많이 쓴다고 해서 이걸 배워볼 겸 차용해 볼까도 했다. 찾아보니 React 프로젝트가 아니어도 사용할 수 있다고 하더라.
그렇지만 본래 의미가 퇴색되지 않도록 하고 싶었다. 그래서 SASS와 SCSS 둘 중 고민하다 SCSS를 사용하기로 했다. SCSS 파일을 CSS로 컴파일하는 개발 환경을 구성해 보는 것에 대한 기술적 도전 또한 포함되어 있었다.
프레임워크를 사용하지 않은 바닐라 프로젝트였지만, 동적 제어는 자바스크립트보단 타입스크립트를 사용하기로 했다. 이전에 타입 스크립트 개발 환경을 설정하는 글을 작성한 적이 있었는데, 이에 대한 실전 활용이랄까? 그리고 타입을 기술하는 것은 꽤 귀찮은 일이지만, VS Code의 인텔리센스 자동 완성 기능과, 런타임 에러를 미연에 방지하는 것이, 개발하며 겪을 귀찮음보다 가치 있다고 판단된 이유가 있기도 하다.
그리고 uglify.js를 사용해 자바스크립트 파일을 조금 더 압축시키는 것도 포함해, 그렇게 SCSS와 타입스크립트를 모두 컴파일하고 압축하기까지, 한 줄의 커맨드로 빌드 할 수 있는 스크립트를 작성해 보는 것도 이번 프로젝트에 포함된 기술적 도전 중 하나였다.
두 번째
분명 나의 전공은 산업디자인, 그중에서도 패션이다.
하지만, 나라는 사람의 특징과 시공간적 제약, ‘이 일을 질리지 않고 오랫동안 할 수 있을까?’ 같은 고민, 이런 여러 현실적 요인들을 고려하면 아쉬운 부분이 분명 있었다. 절대 해당 분야가 싫은 것은 아니다. 전공 수업을 듣던 시기는 여태 지나온 순간들 중 손꼽히는 정말 열심히 살던 시기이며 관심 또한 여전하다.
아무튼 그래서, 이것을 다 버리기보다 내가 가진 능력을 활용할 교집합을 찾아보고 싶었다.
일단 포토샵과 일러스트레이터는, 막 크리에이티브한 것을 곧잘 만들어낸다곤 말하기 어렵겠지만 자신은 있었다. 어도비 포토샵을 처음 접한 게 7.0 버전이었던 것 같다. 햇수로는 15년 정도 됐다. 일러스트레이터는 대학교 와서야 재미가 붙었지만, 아직도 디자인 툴 중에선 일러스트레이터가 가장 마음에 든다. 학교 과제, 발표한 프레젠테이션, 디자인 시안, 도식화, 작업지시서, 한동안 그리던 일러스트레이션, 처음 작성한 이력서까지, 어도비 일러스트레이터가 함께했다.
나는 이 디자인 툴을 사용하면서도 나는 비트맵의 엇나간 픽셀과 벡터의 잘못 찍힌 앵커 포인트를 잘 캐치해냈다. 또한, 원단 회사에서의 인턴십 기간 중에도 사수인 선배님과 대리님으로부터 꽤 원단의 생산 로트 별 차이를 잘 찾는다는 이야기를 종종 듣곤 했다. 염색의 상태라던가, 직물의 조직이라던가, 원래 광학 현미경을 이용해 찾곤 하지만 맨 눈으로도 어느 정도 찾을 수도 있었고, 얼핏 보기에 이상하다는 감은 대개 적중하곤 했었다.
돌아가서, 누군가 이런 나에 대해서 ‘당신은 어떤 사람입니까?’라고 물어보지 않더라도 어떤 사람인가에 대해 알 수 있을만한 그런 것이 필요했다.
이력서라는 제한된 공간보다 하고 싶은 이야기들을 보다 잘, 나답게, 내가 원하는 방향으로 이끌 수 있는 그런 것. 그것이 이번 프로젝트를 통해 도전하는 목표 중 또 하나였다.
여정
먼저 HTML과 관련된 부분이다.
더 나은 웹 접근성을 위해 WAI-ARIA 속성을 적용해 개발하는 것, 더 나은 SEO를 위한 메타 태그를 활용해 보는 것, 시맨틱 마크업을 최대한 활용하는 것, 웹 페이지 완성도를 올리기 위한 favicon을 적용하는 것 정도였다.
완벽까진 아니지만, Google Lighthouse 검사에서 PWA를 제외한 모든 부분에서 100점을 달성함으로써, 최소한은 달성했다고 생각한다.
그리고 프로젝트 경험에 대한 섹션을 어떻게 할지에 대한 작은 고민이 있었다. 복수의 페이지가 아닌 단일 페이지로 모든 것을 보여줄 계획이었으므로 이중 캐러셀 UI를 구성해 보여주기로 했다. 하나는 하나의 프로젝트 내에서 이미지를 넘기는 것으로, 다른 하나는 프로젝트를 넘기는 것으로 이중 캐러셀을 구성했다.
favicon은 디자인 아이디어가 아직 딱히 좋은 게 떠오르지 않아서, 이전에 그린 일러스트레이션을 사용할까 했었다. 그러다 나를 보다 잘 나타내는 아바타를 발견해서 이걸로 설정했다. 설정하고 보니 생각보다 마음에 든다.
아이디어는 빠르게 얻었으나 구현하는 것은 첫 도전이었기에 쉽지는 않았지만 시각적 구현에 성공했고, 이후 리팩터링으로 구조도 체계적으로 정리하는데 성공했다.
다음은 CSS에 관련된 부분이다.
SCSS의 모든 문법… 을 다 알고 있다고 자부할 수는 없겠지만, 이전에 한 번 사용한 기억으로 빠르게 되새겨서 사용할 수 있었다. 그리고 사실 그렇게 어렵지도 않다. 아무튼 이전에는 node-sass라는 라이브러리를 사용해서 SCSS를 CSS 파일로 컴파일했던 걸로 기억했는데, npmjs.com에 들어가니 deprecated 되었다. (…)
그래서 dart-sass라는 새로운 라이브러리를 차용하게 되었다. 의도치 않은 새로운 기술적인 도전이 되어버렸지만, 대단한 기능이 필요했던 것은 아니고 컴파일 스크립트 작성이 목표였기에 어려운 것은 아니었다.
여담으로 이전에 사용하던 node-sass는 C++로 작성되었었는데, 이 dart-sass는 이름처럼 dart로 작성되었고 자바스크립트 환경에서의 빌드 속도는 node-sass가 보다 빠르다. 아마 언어와 컴파일 환경의 차이로 보인다.
돌아가서, SCSS를 클래스로 하여금 재사용성을 확보하기, 반응형 디자인으로 구현하기, BEM 표기법을 최대한 준수하기, jQuery 없이 괜찮은 인터랙션을 구현하기도 목표였다.
dart-sass, 미디어 쿼리, 클래스 표기법, 전부 해결했지만 개인적으로 인터랙션이 아쉽다. 주관적인 시선에서 ‘최악의 인터랙션은 면했다’ 수준은 된다고 생각하지만, 확실히 jQuery를 사용하는 것이 쉽고 빠르게, 썩 괜찮은 인터랙션을 구현하기 좋은 듯하다.
GSAP라는 타임라인 기반의 자바스크립트 애니메이션 라이브러리도 새로 알게 되었는데 이는 CDN을 이용한 구현을 지원하기도 하고, 조만간 GSAP를 활용한 인터랙션으로 보다 화려하게 전환해 볼 계획이다.
마지막으로 자바스크립트와 타입스크립트에 관련된 부분이다.
이전에 바닐라 자바스크립트로 SPA를 만들어보는 걸 해볼 때, 이상한 욕심이 들어서 바닐라 타입스크립트 프로젝트로 수행해 본 적이 있었다. 그래서 사실 이 부분은 도전이라고 할 정도의 개척할 부분은 없다시피 했다.
그보다 타입스크립트를 컴파일하고, 그 컴파일한 자바스크립트 파일을 uglify.js를 이용해서 minify하는 스크립트 작성이 이 섹션에서의 기술적인 도전이었다. 스크립트 용량을 줄인다면 클라이언트 측에서의 자바스크립트 로드 시간을 줄일 수 있을 것이라고 생각했다.
깃허브 리포지토리의 API 레퍼런스를 참고해서 쉽게 해결할 수 있었다.
그리고 예상 범위 밖의 작은 고민이 하나 생겼었는데, 이미지 포맷에 관한 문제다.
내가 갖고 있는 정적 이미지 파일들은 대개 png 포맷이다. 알파 채널을 포함한 32비트의 무손실 압축 포맷인데… 쉽게 너무 용량이 커서 로드하는 데 시간이 걸린다는 이야기다. 이것을 문제가 아닌 고민으로 정의한 이유가 있다.
이미지 용량이 커서 최적화하기 어렵다는 것은 최초 로딩 시간의 증가를 의미한다. LCP(Largest Contentful Paint) 측면에서 부정적이라는 의미다. 이에 대응하기 위해서 Gulp를 통해 빌드를 자동화하는 동시에 플러그인으로 webp 포맷으로 변환할 생각을 해봤었다.
다른 측면으로는, 나의 포트폴리오이기 때문에 최대한 원본에 가까운 품질의 리소스로 보여주고 싶다는 것이다. 그렇다면, 이미지 리소스는 건들지 않는다는 전제하에 UX를 고려하려면 로딩 컴포넌트를 이용해 로드가 완료되는 타이밍을 예측하고, 인터랙션을 이용해 풀어낸다면 더 나아질 수 있을 것이다. 이 방향이 조금 더 내가 원하는 방향에 가까웠다.
처음엔 이를 몰라서 임의의 로딩 시간을 예측하여 지정해두고, 그 시간 뒤에 로딩 컴포넌트를 해제하는 방식으로 구현해냈다.
하지만 최근에 Image 객체의 onload 혹은 progress 이벤트를 활용하면 손쉽게 리소스 로딩 상태 완료 여부를 확인할 수 있다는 걸 알게 되었고, 구현이 아직 엉성해보이겠지만 그래도 이전보다 UX 친화적으로 리팩터링했다.
이와 동시에 Gulp를 활용한 자동화 파이프라인도 구축할 예정이다. 단발성 프로젝트로 끝내기에는 이 프로젝트가 꽤 마음에 든다.
에필로그
프로젝트 기술 스택이나 규모, 퀄리티는 솔직히 다른 프로젝트들에 비해 보잘것없을 수도 있다. 아니 그렇다. 그렇지만 그에 비해서 배운 건 너무 많았다.
이중 캐러셀 구현이나, dart-sass를 통한 scss의 사용과 컴파일링, jQuery보다 괜찮아 보이는 GSAP의 존재, uglify.js를 이용한 자바스크립트 파일 용량 축소… 그리고 최근의 리소스 로딩에 대해 보다 더 향상된 UX의 로더를 보여주는 방식까지.
이런 작은 프로젝트를 수행하면서도 작은 도전 목표를 두고 진행하는 것이 경험치를 쌓고 성장하는 동력이 되는 것 같다.
