2023년 7월 셋째주 주간 회고

1. 크롬의 새로운 scroll 애니메이션 API - Scroll Progress Timeline 아주 사알짝 맛보기

출처 Animate elements on scroll with Scroll-driven animations - Chrome Developers

이전에는 스크롤시 애니메이션을 주려면, 스크롤 이벤트를 활용해서애니메이션을 추가해주어야 했다. 이는 당연히 스크롤 이벤트가 일어날 때마다 특정 함수를 실행해야하므로, 브라우저의 메인쓰레드를 사용하여 성능이 저하될 수 밖에 없었고 이를 해결하기 위해서 이벤트 리스너에 디바운스를 추가한다던지 IntersectionObserver를 사용하게 되며 구현 난이도를 높였다. 이를 해결하기 위해 나온 API라고 한다. (JS 를 사용하지 않아도 되어서 메인쓰레드에서 돌아가지 않고 컴포지터에서 돌아간다고 한다.) + JS 를 사용하지 않아도 되지만 JS를 사용해서 구현도 가능하다.

CSS 예시

@keyframes adjust-progressbar {
  from {
    transform: scaleX(0);
  }
  to {
    transform: scaleX(1);
  }
}

#progressbar {
  animation: adjust-progressbar linear;
  animation-timeline: scroll(block root);
  animation-duration: auto;
}

• 여기서 animation-timeline 은 animation 속성과 함께 사용 되어, 해당 애니메이션이 실행 되기 위해 연결 할 수 있는 타임라인 역할이라고 보면 된다. 즉 기존에 시간단위로 애니메이션이 실행되는게 아니라 지정한 타임라인에 따라 애니메이션이 실행된다.
• 값을 scroll(block root) 로 지정하여 브라우저에게 문서의 루트 스크롤을 추적하여 명시된 애니메이션을 실행해라 라고 말하는 것이다.

animation-timeline 의 값으로는 아래와 같은 값들이 들어가며 scroll 은 이 중에 하나이다.

• none
  • 애니메이션이 timeline 과 연결되어 있지 않음
• scroll
  • 애니메이션이 스크롤과 연결됨
• view
  • 애니메이션을 스크롤 컨테이너 내에 특정 요소의 상대적 위치와 연결 가능

View Scroll Timeline

@keyframes reveal {
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}

img {
  animation: reveal linear;
  animation-timeline: view();
}

위와 같이 정의해놓으면 img 태그를 스크롤 하는동안 reveal 이벤트가 진행된다. 이렇듯 view 함수를 사용하여 가장 가까운 영역의 스크롤을 애니메이션 타임라인으로 사용 할 수 있다.

2. pnpm 에 대해

회사 플젝에선 현재 yarn 을 사용하고 있는데, 그러다보니 빌드 속도가 느려서 개선하고자 pnpm을 도입하자는 의견이 나왔다. pnpm은 뭐가 어떻게 다르길래 빌드 속도가 개선될까.🤔

pnpm의 디스크 사용 방법 - 심볼릭 링크

npm이나 yarn 과 달리 pnpm은 node_modules 폴더의 패키지를 중복으로 저장하지 않는다. 요게 무슨말일까?

만약에 A 프로젝트 B 프로젝트 C 프로젝트 각각이 있고, 각 프로젝트가 패키지-1을 포함해야한다면, npm이나 yarn 은 각 프로젝트별로 node_modules 안에 패키지-1을 포함한다. 이 때 각각 node_modules에는 패키지-1의 용량만큼의 디스크를 차지하게 된다. 즉 패키지의 용량 * 프로젝트 갯수가 전체 차지하는 디스크 크기가 되어버린다.

하지만, pnpm은 별도의 저장소가 있다. (pnpm_store) 그리고 각 프로젝트에 각 패키지를 다 가지고 있는게 아니라, 해당 패키지에 대한 바로가기(symbolic link)를 만든다. 따라서, 중복 저장공간을 효율화 할 수 있다! 즉 프로젝트가 많을 수록 이 pnpm의 장점은 극대화 된다.

심볼릭 링크- Ghost Dependency 제거

위에 설명한 심볼릭 링크 기능은 기존 npm, yarn 의 문제인 ghost dependency 를 해소시켜준다.

👻 Ghost Dependency 란
npm, yarn 은 위에서 말했듯이 모든 패키지를 node_modules에 저장하며, 이를 모두 루트 하에 평평하게 위치시킨다. (Hoisting) 이 때문에 중복된 패키지가 저장되거나, A 패키지를 저장했을 때 A 패키지의 디펜던시인 B 패키지가 설치되거나..할 수 있다. 이 때 A 패키지를 쓸 때 내가 설치한적도 없는 B 패키지가 require() 되는 현상을 Ghost Dependency라고 한다.

심볼릭 링크를 사용하는 pnpm은, node_modules 에 실제 패키지를 설치하는 것이 아니고, pnpm_store에서 명시한 패키지만 참조해 사용하는 것이므로 이러한 Ghost Dependency 를 제거 할 수 있다.

더 읽어볼 만 한 글 피어가 해결되는 방법 | pnpm

3. 도커가 뭔지 알아보기

회사 프로젝트에서도 도커를 사용한다. 근데 도커를 활용한 배포파이프라인이 낯설어서 이해하기 어려웠다. (사실 도커가 뭔지에 대한 개념이 명확하지 않았음) 그래서 아주 사알짝 알아보기로 했다. 도커란 대체 뭘까? 😵‍💫

도커는 컨테이너 기술을 기반으로 한 일종의 가상화 플랫폼이라고 한다.

가상화 플랫폼이란?

• 물리적 자원인 하드웨어를 효율적으로 활용하기 위해 하드웨어 공간 위에 가상 머신을 만드는 기술
• 즉, 하나의 하드웨어를 여러개의 가상 머신(버츄얼 머신)으로 분할해 효율적으로 사용 할 수 있는 기술
• 이렇게 분할 된 가상머신들은 각각 독립적인 환경으로 구동된다.
  • Host OS : 베이스가 되는 기존의 환경
  • Guest OS : 가상 머신으로 분할된 각각의 환경

가상머신을 생성 하기 위해서는, 하이퍼바이저 혹은 가상 머신 모니터라고 불리는 소프트웨어가 이용된다. 요 하이퍼바이저는 호스트 하드웨어에 설치되어서 호스트와 게스트를 나누는 역할을 하고, 각각의 게스트는 하이퍼바이저에 의해 관리되어 시스템 자원을 할당 받는다. (하이퍼바이저에 의해 생성된 게스트는 독립적이다)

하지만 요 하이퍼바이저를 거쳐야해서 속도 저하가 어쩔 수 없이 따라온다. 요 하이퍼바이저의 한계점을 보완하는게 컨테이너다.

컨테이너 기술이란?

• 컨테이너란 컨테이너가 실행되고 있는 호스트의 os 기능을 그대로 사용하면서 프로세스를 격리해 독립된 환경을 만드는 기술

하이퍼바이저랑 다르게 컨테이너는 가상의 OS 를 만들지는 않는다. 컨테이너는 베이스 환경의 OS를 공유하면서 필요한 프로스세스만 격리하는 방식으로, 커널을 공유하여 호스트 OS의 기능을 모두 사용 할 수 있다. (따라서 컨테이너 위에서는 호스트 OS와 다른 OS를 구동 할 수 없다.)

그래서 도커가 왜 필요한가

• 개발 과정에서 다른 라이브러리와 충돌하는 것을 방지하기 위해 격리된 환경이 필요 할 때
• 개발된 서비스를 배포할 때

도커가 필요하다. 근데 프론트엔드에서도 도커가 필요 할까? 우리 회사에선 프론트엔드도 도커를 활용해 배포한다. 왜 그럴까? 도커파일에는 명령어를 입력해놓을 수 있다. Node 설치하고, yarn 설치하고 yarn install 하고, 등등! 프로젝트가 실행되는 환경들을 도커파일에 이러한 도커파일을 설정해놓으면 한번에 설치가능해서 매우 간단해진다. 그럼 배포 파이프라인이 어떻게 될까? 프로젝트 셋팅마다 다르겠지만, 내 추측은 이러하다.

1. 깃헙에 코드가 푸시된다.
2. 젠킨스 웹훅이 돈다.
3. 도커 빌드가 되어 도커 이미지를 생성한다.
4. 요렇게 빌드된 도커 이미지를 서버에 푸시한다.
5. 서버가 돈다.
6. 끗!

요건 더 공부해봐야 할 것 같다. 일단 오늘은 요기까지

참고

• 도커에 대한 어떤 것 : 1. 도커란 무엇인가?
• 초보를 위한 도커 안내서 - 도커란 무엇인가?
• Jenkins를 이용한 Docker 컨테이너 자동 배포하기(Blue Ocean, Bitbucket, NCP) — Bonglog - 기록과 정리의 공간

4. CSS의 캐스캐이딩과 Scoped CSS 에 대한 생각

위의 트윗을 읽고 생각하게 될 수 있었다. 현재 많은 프론트엔드 개발자들이 Scoped CSS 를 사용하고 있고 (나 역시도) 사용하면서도 한계점을 많이 깨닫곤 한다. 과한 반복, 재사용의 어려움, 복잡도 증가..그런 것들이 있다. 그럼 우리가 Scoped CSS를 사용하게 된 이유는 무엇일까? 바로 기본 CSS의 전역적인 관심사에 의한 복잡도 때문이다. 그런데 이게 과연 단점일까? 우리가 제대로 사용 못하고 있는걸지도 모르겠다. 하지만 또 다른 관점에서 보자면 (인용된 트윗의 말 처럼) 이 단점을 Scoped CSS로 해결하여 생산성을 증대시키는 것일 수도 있겠다. 어쩌면 CSS의 전역적인 관심사는 정말 잘 사용하면 좋겠지만, 잘 사용하기는 여전히 어렵기 때문이다. 정답은 때에 따라서 잘 사용하자가 아닐까 🫨

짧은 회고

• 바뿌다 바뻐,,요즘은 일이 정말 많다,,병렬적으로 진행되는 일들이 많아서 일정 관리와 공유를 열심히 하려고 노력 중이다. 나름 잘 되는 중인듯. 생각보다 일정이 갑자기 바뀌는 것에 대한 스트레스는 없다. 기능 빨리빨리 추가해서 제품의 완성도를 조금씩 올려나가는 일들이 재미있다.
• Kent C Dodds 의 Stop Being a Junior 란 글을 읽고 읽는 김에 번역도 후딱했는데, 읽으면서 많이 반성했다. 자발적 주니어가 되지말자! 연차는 주니어일지언정 내 태도(특히 적극성)까지 주니어라는 틀 안에 갇혀있을 필요는 없다.
• 운동 짱많이 함. 필테 안가는 날은 달리기 무조건 하는데, 이제 달리기 페이스 5분대로 접어들었다.
• 여름이라 그런지 식욕이 너무 없어서 강제 1일 1식중이다.