Home

이미지를 많이 사용하는 단일 페이지 웹 성능 최적화

이미지가 많이 들어가는 소개 페이지의 LightHouse의 성능 개선기를 적어본다. 각 섹션마다 고해상도 배경 이미지가 사용되었는데, 이 이미지들은 용량이 커서 첫 로딩시 LCP에 영향이 가게 되었다. 방법 이미지 최적화 LCP 개선 CLS 개선 접근성 개선 1. 이미지 최적화 (webp 변환) png, jpg 이미지를 webp로 변환해 이미지 용량을 줄이는 것은 웹 성능 최적화에서 매우 효과적인 방법 중 하나다. webp는 구글에서 만든 이미지 포맷으로, 더 작은 용량으로 동일한 품질을 제공하기 때문에, 네트워크 트래픽 절감 및 페이지 로딩 속도 개선에 유리하다 여기에 AVIF를 추가할...

Read more

디자인 시스템 왜 필요할까?

이전 회사에서 ant-design 을 기반으로한 디자인 시스템을 만들었다. 프로젝트 개발과 병행해 공통 컴포넌트로 두면 좋겠다 하는 것은 추가로 같이 개발했다. 이번에는 ant-design 과 같은 UI 라이브러리를 사용하지 않고, 기존 프로젝트에서 재사용할 수 있는 부분들을 컴포넌트로 분리하는 작업에 집중했다. 왜 이런 작업이 필요했을까? 자사 소개 페이지의 디자인이 한 번 바뀌면 다른 소개페이지의 디자인도 대공사로 변경해주는 일이 있었다. 또 우리 회사에는 익스텐션 월렛과 앱 월렛이 있는데 디자인이 톤은 일관되어있는데, 컴포넌트 디자인이 약간씩 달랐다. 그래서 일관성을 위해 내가 맡고 있는 익스텐션 월렛...

Read more

Vite 빌드 후 결과물 자동 압축하기: 날짜·시간 기반 폴더명으로 관리하기

서비스를 운영하다 보면, 빌드 후 생성된 결과물을 전달하거나 관리할 때 헷갈리거나 반복적인 작업이 생기곤 한다. 이번 글에서는 Vite 빌드 과정에서 날짜·시간 기반의 폴더명을 자동으로 생성하고, zip 압축까지 자동화하는 과정을 정리하려고 한다. 왜 이런 작업이 필요했을까? 익스텐션은 보통 웹사이트 개발과는 다른 점이 있다. QA를 할 경우인데, 개발을 마친 후 작업물을 QA 해볼 수 있게 개발 서버를 도입해서 uri 를 전달하는 것이 아닌, 개발자가 빌드파일을 압축해서 QA 진행자에게 전달하고, 받은 파일을 구글 확장프로그램 사이트에 파일을 올려서 테스트 하는 것이다. 이 전달하는 과정에 빌드된 압축파...

Read more

Dockerfile 최적화: Node.js 애플리케이션의 이미지 크기 줄이기

Docker를 활용해 Node.js 애플리케이션을 컨테이너화할 때, 효율적인 Dockerfile을 작성하는 것은 필수이다. 비효율적으로 작성된 Dockerfile은 불필요하게 큰 이미지 크기와 느린 빌드 시간을 초래할 수 있어, 프로젝트 전반에 걸쳐 영향을 미칠 수 있다. 이번 글에서는 Dockerfile을 최적화하여 Node.js 애플리케이션의 이미지 크기를 줄이고 빌드 속도를 높이는 방법을 공유해보려고 한다. 들어가기 앞서 배포를 진행할 때마다 디스크 용량 부족으로 인해 빌드가 실패하는 문제가 발생했다. 디스크 용량을 단순히 늘리는 것도 하나의 해결책이 될 수 있지만, 장기적으로는 최적화를 통해 이 문제를 ...

Read more

멀티 코어 환경에서 싱글 코어 환경으로 배포 시 발생한 문제들

들어가기 앞서 배럴아이를 멀티 코어 환경에서 개발한 후, 싱글 코어 사양의 클라우드 환경으로 배포할 때, 이전에 발생하지 않았거나 드물게 발생했던 여러 기능 장애들이 예기치 않게 많이 발생했다. 원인을 찾기 어려웠던 몇 가지 주요 사례와 그 해결 방법을 공유하려고 한다. 멀티 코어 환경에서 싱글 코어 환경으로 배포 시 발생한 문제들 1. 메시지 덮어쓰기 문제로 인한 블록 분기 여러 인접 노드를 통해 동시에 메시지를 수신할 때, 노드는 먼저 받은 블록을 연결하여 노드 간 블록 분기가 발생하였다. 해결 방법: 비트코인과 유사한 긴 체인을 따르는 방법을 도입하여 문제를 해결했다. 2. 동기화 중단 문제 신규...

Read more

Github Actions 캐시 전략을 통한 빌드 시간 단축

들어가기 앞서 Github Actions을 통해 배럴아이스캔의 CI/CD 파이프라인을 구축했었다(GitHub Actions 배포 자동화). 그 이후, 눈에 띄는(?) 배포 시간 덕분에 좋은 경험을 공유하려고 한다. 배포 시간을 길게 하는 요소로는 Node.js와 Docker를 사용하는 환경에서 매번 모든 의존성을 새로 설치하고 빌드하는 과정이 있었는데, 이러한 문제를 해결하기 위해 GitHub Actions에서 제공하는 캐시 기능을 활용하여 빌드 시간을 단축하는 방법을 시도해 보았다. 구성 배럴아이스캔 프로젝트에서는 다음과 같은 작업들을 거쳐야 최종 화면을 볼 수 있었다. E2E 시나리오 테스트 도...

Read more

GitHub Actions 배포 자동화 (with 맞이한 에러들)

들어가기 앞서 배럴아이스캔은 도커를 사용해 배포하고 있다. 개발이 완료되면 도커 명령어를 통해 빌드와 배포를 하는데, 배포가 끝나면 5분 가량이 지나버린다. 가끔은 이런 환경이 ‘어? 나 명령어 다 기억하네’ 하고 지나가지만, 바로 해결하지 않으면 안 되는 (봇이 우리 자원을 가져간다거나) 급박한 상황에서는 이게 참 곤욕이다. 그래서 남들이 다하는 CI/CD 자동화를 통해 푸시해놓고 다른 일도 볼 수 있는 시간을 만들어보려고 한다. 구성 배럴아이스캔 파이프라인 구성해야 될 것 배럴아이스캔은 세 가지 요소를 거쳐야 개발 완료된 배럴아이스캔 화면을 볼 수 있다. E2E 시나리오 테스트 도커를 통한 빌드...

Read more

메모리 관리

프로세스와 메모리 메모리 관리 메모리 호출: 언제 새로운 프로세스를 메모리에 둘 것인가? 메모리 배치: 다음에 실행될 프로세스를 메모리 내의 어느 곳에 둘 것인가? 메모리 교체: 메모리가 꽉 찬 상태에서 새로운 프로세스를 메모리에 적재해야 한다면 어떤 프로세스를 제거할 것인가? 그 외: 고정/동적 분할, 고정/유동 적재영역 등 단일 프로그래밍 환경 하나의 프로세스만 메모리를 전용으로 사용하는 것 프로세스는 하나의 연속된 블록으로 메모리에 할당 (연속 메모리 할당) 단일 프로그래밍의 문제점 메모리의 용량을 초과하는 프로세스는 실행 못함 메모리 낭비 심함: 지속적으로 사용되지...

Read more