프론트엔드를 위한 다양한 기술들이 나왔고, 이제는 성능 최적화에 초점을 맞추고 있습니다. 여기서 구글은 ‘성능이 저하되면 사용자가 떠나고 매출이 감소한다.’라고 이야기합니다. 즉 성능 최적화를 통해 사용자를 늘리고 매출 또한 증가한다는 것입니다. 구글이 조사한 페이지 로딩 속도와 이탈률 및 전환율의 관계를 살펴보면 확 이해될 것입니다.
페이지 표시 시간 2초 증가 → 사용자 이탈률 32% 증가
페이지 표시 시간 4초 증가 → 사용자 이탈률 90% 증가
페이지 표시 시간 5초 증가 → 사용자 이탈률 106% 증가
페이지 표시 시간 9초 증가 → 사용자 이탈률 123% 증가
더해서 다른 회사들의 사례도 본다면 성능 최적화가 얼마나 중요한지 이해할 수 있습니다.
핀터레스트 로딩 시간 40% 단축 → 검색 유입률과 가입자 수 15% 증가
COOK 페이지 로드 시간 850밀리초 감소 → 세션당 페이지 조회 수 10% 증가/ 이탈률 7% 감소
이러한 성능 최적화는 어떻게 이루어질까?
성능을 결정하는 요소는 크게 두 가지입니다.
로딩 성능
서버에 있는 웹 체이지와 웹 페이지에 필요한 기타 리소스를 다운로드 할 떄의 성능
개선하는 방법 :
다룬로드해야하는 리소스 수를 줄이거나 크기를 줄이기
코드를 분할하여 다운로드 하기
리소스의 우선순위를 매겨 중요한 리소스를 먼저 다운 받기
렌더링 성능
다운로드한 리소스를 가지고 화면을 그릴 때의 성능이며, 자바스크립트 코드에 크게 영향을 받음
개선하는 방법 :
매우 다양하며 서비스 유형에 따라서도 다릅니다. 그렇기에 자신의 서비스에 필요한 최적화 기법을 적용하기 위해선 브라우저의 동작 원리와 사용하는 프레임워크의 라이프 사이클 등 웹 개발의 기본 지식을 이해함으로써 효율적인 코드를 작성해야합니다.
정말 많은 최적화 기법들이 존재하지만 지금은 우리가 제작하고 있는 옷늘날씨 서비스에 적절한 최적화 기법 위주로 정리하겠습니다.
그 전에 성능을 분석할 수 있도록 도움을 주는 개발자 도구에 대해 알아봅시다.
성능 분석을 위해 사용되는 개발자 도구를 알아보자
Network 패널
현재 웹 페이지에서 발생하는 모든 네트워크릐 트래픽을 상세하게 알려주는 도구입니다. 이를 통해서 어떤 리소스가 어느 시점에 로드 되는지, 해당 리소스의 크기 등을 확인할 수 있습니다.
Performance 패널
웹 페이지가 로드될 때 실행되는 모든 작업을 보여 줍니다. Network 패널에서 봤던 리소스가 로드되는 타이밍뿐만 아니라 브라우저의 메인 스레드에서 실행되는 JS를 차트 형태로 볼 수 있습니다. 결론적으로 어떤 JS 코드가 느린지 확인할 수 있습니다.
LightHouse 패널
웹사이트의 SEO 점수, 접근성 점수, 성능 점수 등을 측정해주고 개선 방향까지 제시해주는 자동화 도구입니다. 성능 관점에서 해당 도구를 사용하기 위해선 알아야하는 지표들이 있습니다.
총 6가지이며 각 지표에 가중치를 적용하여 총점을 알려줍니다.
6가지 지표
FCP(First Contentful Paint) | 10%
페이지가 로드될 때 브라우저가 DOM 콘텐츠의 첫 번째 부분을 렌더링 하는 데 걸리는 시간 지표입니다.
SI(Speed Index) | 10%
페이지 로드 중에 콘텐츠가 시각적으로 표시되는 속도 지표입니다. 최대한 빠르게 콘텐츠를 표시하면 높은 점수를 받을 수 있습니다. 즉, 페이지 로딩에 같은 시간이 걸리더라도 콘텐츠를 더 먼저 띄운 페이지의 SI 점수가 더 높습니다.
LCP(Largest Contentful Paint) | 25%
페이지가 로드될 때, 화면 내 가장 큰 이미지나 텍스트 요소가 렌더링 되기까지 걸리는 시간 지표입니다. 즉, 가장 큰 콘텐츠가 나타나는데 걸리는 시간을 기준으로 볼 수 있습니다.
TTI(Time to Interactive) | 10%
페이지과 상호 작용이 가능한 시점까지 걸리는 시간 측정 지표
TBT(Total Blocking Time) | 30%
페이지가 클릭, 키보드 입력 등의 사용자 입력에 응답하지 않도록 차단된 시간 총합 지표 동작 방해 작업을 포함한 FCP → TTI 사이의 시간 동안 측정
CLS(Cumulative Layout Shift) | 15%
페이지 로드 과정에서 발생하는 예기치 못한 레이아웃 이동 측정 지표 ※ 레이아웃 이동 : 화면상에서 요소의 위치나 크기가 순간적으로 변하는 것
Opportunities 섹션과 Diagnostics 섹션 : 문제점과 해결 방안, 얻을 수 있는 이점 설명
Opportunities 섹션 : 페이지를 더욱 빨리 로드할 수 있는데 도움이 되는 제안
Diagnostics 섹션 : 로드 속도와는 관계 없지만 성능 향상에 도움이 되는 제안
그리고 라이트하우스를 이용해 성능을 측정할 때는 기본 네트워크 환경이 아니라 네트워크 속도를 제한하여 어느 정도 고정된 네트워크 환경에서 성능을 측정합니다.
또 맨날 주기적으로 올린다하고 그러지 못했네요...ㅠㅠ 게으른 저 반성합니다. NCP를 사용하시는 분이 많지는 않겠지만, 사용하신다면 도움이 될거 같아서 최근 프로젝트 CI/CD 구축했던 과정을 공유하려고 합니다. 앞으로는 꼭!! 주기적으로 작성할 예정입니다. 사실 블로깅하는 스터디도 하고 있어서 2주에 한 번씩을 포스팅할 예정입니다 잘 부탁드려요 :)
1. Docker 이미지 빌드
먼저 Next.js 프로젝트에 대한 Docker 이미지를 만들어야 합니다.
루트 디렉토리에 Dockerfile을 만들어 도커 이미지를 만드는 코드를 작성해 봅시다.
Dockerfile을 만들기 전에 이미지 빌드에 적용한 것들에 대해서 알아야합니다.
multi-stage 빌드
Next.js의 standalone
a. multi-stage 빌드
Multi-stage 빌드 방식을 이용해 도커 이미지를 만들 예정입니다. 해당 방식은 이미지를 만드는 과정에서는 필요하지만 최종 컨테이너 이미지에는 필요 없는 환경을 제거하여 이미지를 최적화하는 방식입니다.
이를 위해 stage를 나누어 기반 이미지를 생성합니다.
stage는 다음과 같습니다
Base stage (base):
npm install --production: 프로덕션에서만 필요한 의존성을 설치합니다. (예: react, next 등)
이 스테이지에서는 프로덕션에서 실행에 필요한 최소한의 패키지만 설치합니다.
Dependencies stage (deps):
npm install: 개발 의존성까지 포함하여 모든 의존성을 설치합니다. 이 단계는 빌드에 필요한 패키지를 포함하는 것입니다.
이 단계에서 storybook, eslint 등 개발 도구와 관련된 패키지들이 설치됩니다.
Build stage (builder):
npm run build: Next.js 애플리케이션을 빌드하는 단계입니다.
builder는 소스 파일 전체를 복사하고, 빌드를 통해 정적 자원을 생성합니다.
Runtime stage (runner):
최종 런타임 이미지로, builder에서 빌드된 결과물과 프로덕션 의존성만 복사해 옵니다.
이 단계에서는 개발 도구나 빌드에 필요한 패키지들이 포함되지 않으며, 실행에 필요한 것들만 포함된 최소한의 이미지를 생성합니다.
위 과정을 보면 개발 의존성과 프로덕션 의존성을 분리하는데요
두 개념과 왜 분리하는지를 설명하겠습니다.
1. 프로덕션 의존성 (Production Dependencies)
프로덕션 의존성은 실제 애플리케이션이 배포되었을 때, 애플리케이션이 정상적으로 동작하는 데 필요한 라이브러리나 패키지입니다.
이 의존성들은 애플리케이션이 실행될 때 필수적입니다.
주로 애플리케이션의 기능 구현과 실행에 직접적으로 영향을 미치는 패키지입니다.
예시:
React, Next.js, Express 등은 프론트엔드/백엔드 애플리케이션의 핵심 라이브러리입니다. 이들은 애플리케이션이 실제로 배포되었을 때 동작하는 데 필요합니다.
axios와 같은 HTTP 요청 라이브러리도 프로덕션 의존성입니다.
npm install <패키지명>
# or
npm install <패키지명> --production
2. 개발 의존성 (Development Dependencies)
개발 의존성은 애플리케이션이 개발 과정에서만 필요하고, 프로덕션 환경에서는 필요하지 않은 패키지입니다.
주로 코드 품질 개선, 테스트, 빌드 도구 등이 여기에 포함됩니다.
개발 중에만 사용되며, 애플리케이션이 배포될 때는 불필요한 패키지입니다.
예시:
eslint, prettier와 같은 코드 품질 검사 도구는 개발 시에만 필요하고, 애플리케이션 실행에는 필요하지 않습니다.
jest, storybook과 같은 테스트 도구도 개발 중에만 사용됩니다.
webpack과 같은 빌드 도구나 babel도 애플리케이션이 빌드될 때 필요하지만, 배포 후에는 필요하지 않습니다.
npm install <패키지명> --save-dev # 개발 의존성으로 설치
왜 프로덕션과 개발 의존성을 구분할까?
최적화:
개발 의존성까지 모두 배포하면, 애플리케이션의 크기가 커지고, 메모리 및 성능에 영향을 줄 수 있습니다.
프로덕션에서는 실행에 필요한 의존성만 포함시키는 것이 좋습니다.
보안:
개발 의존성에는 개발 도구나 테스트 도구가 포함되며, 이는 프로덕션에서 실행될 때 불필요한 취약성을 만들 수 있습니다.
개발에만 필요한 라이브러리를 포함시키지 않으면, 보안 위험을 줄일 수 있습니다.
간결성:
프로덕션 환경에서는 오직 애플리케이션이 동작하는 데 필요한 최소한의 코드만 포함시켜야 합니다.
개발 과정에서 쓰는 도구는 프로덕션 환경에서는 불필요하므로 간결하고 최적화된 상태로 배포할 수 있습니다.
멀티 스테이지 빌드에서 --production 옵션을 사용하여 프로덕션 의존성만 설치하는 이유는
최종 컨테이너 이미지를 최적화하기 위함입니다.
예를 들어:
Dockerfile
코드 복사
# Base stage: Production dependencies
FROM node:18-alpine AS base
WORKDIR /app
# Install only production dependencies
COPY package*.json ./
RUN npm install --production
위와 같이 npm install --production 명령을 사용하면 devDependencies는 설치되지 않고, 프로덕션 의존성만 포함됩니다.
이렇게 하면 최종 컨테이너 이미지는 필수적인 패키지만을 포함하게 되어 이미지 크기와 성능 면에서 최적화됩니다.
b. Standalone
도커 이미지를 만드는 과정에서 Builder 스테이지에서 구성한 node_modules, package.json 등 필요한 파일을 복사해 와서 이미지에 넣습니다. 이 과정에서 Next.js의 standalone을 사용하면 node_modules의 선택 파일을 포함하여 프로덕션 배포에 필요한 파일만 복사하는 독립 실행형 폴더를 자동으로 생성할 수 있습니다.
# multi-stage 빌드 방식 사용
# 이미지를 만드는 과정에서는 필요하지만 최종 컨테이너 이미지에는 필요 없는 환경을
# 제거하기 위해 단계를 나누어 기반 이미지를 생성하는 방법
FROM node:18-alpine AS base
# 작업 디렉토리를 설정 -> 도커 컨테이너 안에서 어떤 경로에서 실행할 것인지를 명시
WORKDIR /app
# 프로젝트의 의존성을 복사
COPY package*.json ./
# production 패키지만 base에 설치
RUN npm install --production
# 개발용 패키지를 설치하기 위해 단계 구분
FROM base AS deps
WORKDIR /app
# 패키지 설치
RUN npm install
# Build 스테이지
FROM deps AS builder
WORKDIR /app
# 현재 디렉토리를 /app 디렉토리에 복사
COPY . .
# 프리티어 오류 발생으로 빌드 전에 프리티어 규칙 적용
# 빌드된 파일들에는 프리티어가 적용되어 있지 않아서 미리 적용해 줌
# package.json에 script를 추가하고 "prettier": "prettier --write ." 추가
RUN npx prettier --write .
RUN npm run build
# Runtime 스테이지 : 이미지 생성
# 불필요한 의존성을 가져가지 않기 위해 base를 가져오지 않고, node:18-alpine를 사용
FROM node:18-alpine AS runner
WORKDIR /app
RUN addgroup --system --gid 1001 nodejs && adduser --system --uid 1001 nextjs
# next의 standalone을 통해 필요한 파일만 복사하는 도깁 실행형 폴더를 자동 생성
# 아래 설정 next.config.mjs에 설정
# module.exports = {
# output: 'standalone',
# }
# <https://nextjs.org/docs/pages/api-reference/next-config-js/output>
# standalone을 설정해 줬기 때문에 Build 스테이지에서 /app/.next/standalone가 형성
# 이를 COPY해서 사용
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
USER nextjs
EXPOSE 3000
ENV PORT 3000
# 어플리케이션 start
CMD ["node", "server.js"]
# Base stage (base):
# npm install --production: 프로덕션에서만 필요한 의존성을 설치합니다. (예: react, next 등)
# 이 스테이지에서는 프로덕션에서 실행에 필요한 최소한의 패키지만 설치합니다.
# Dependencies stage (deps):
# npm install: 개발 의존성까지 포함하여 모든 의존성을 설치합니다. 이 단계는 빌드에 필요한 패키지를 포함하는 것입니다.
# 이 단계에서 storybook, eslint 등 개발 도구와 관련된 패키지들이 설치됩니다.
# Build stage (builder):
# npm run build: Next.js 애플리케이션을 빌드하는 단계입니다.
# builder는 소스 파일 전체를 복사하고, 빌드를 통해 정적 자원을 생성합니다.
# Runtime stage (runner):
# 최종 런타임 이미지로, builder에서 빌드된 결과물과 프로덕션 의존성만 복사해 옵니다.
# 이 단계에서는 개발 도구나 빌드에 필요한 패키지들이 포함되지 않으며, 실행에 필요한 것들만 포함된 최소한의 이미지를 생성합니다.
컨테이너들 간의 네트워크를 자동으로 설정하여, 서비스들이 서로 통신할 수 있도록 돕습니다.
환경 구성 및 배포의 간소화:
여러 컨테이너의 설정을 하나의 docker-compose.yml 파일에 정의하여, 손쉽게 환경 설정 및 배포를 할 수 있습니다.
즉, Next.js 애플리케이션을 컨테이너화 하여 자동 재시작 및 네트워크 설정 등을 통해 관리할 수 있는 환경을 제공합니다. 확장성을 생각하여 추가했습니다.
/docker-compose.yml
# 도커 컴포즈 -> 여러개의 도커 컨테이너를 듸우기 위해 사용되는 간단한 오케스트레이션 도구
# 참고 : <https://github.com/vercel/next.js/blob/canary/examples/with-docker-compose/docker-compose.prod.yml>
version: '3' # 도커 컴포즈의 버전
services:
next-app:
container_name: next-app
build:
context: . # Dockerfile이 있는 현재 디렉토리
dockerfile: Dockerfile
restart: always
ports:
- '3000:3000' # 호스트 머신의 3000번 포트를 도커 컨테이너 내부의 3000번 포트로 연결
networks: # docker network create my_network로 네트워크를 미리 만들어줘야 한다.
- my_network
networks:
# 네트워크 정의를 통해 여러 컨테이너가 서로 통신할 수 있도록 도와주는 기능
# 각 컨테이너가 같은 네트워크에 속할 때, 컨테이너 이름을 호스트네임으로 사용하여 쉽게 통신할 수 있도록 도와줌
# 현재 하나의 Container Registry를 사용하기 때문에 필요
my_network:
external: true
# 해당 코드를 작성한 뒤
# docker-compose -f docker-compose.yml up -d
# 를 하여 next-app 서비스를 만든다.
# 즉 docker-compose.yml 파일을 통해서 Next.js 애플리케이션을 컨테이너화 하여
# 자동 재시작 및 네트워크 설정 등을 통해 관리할 수 있는 환경을 제공합니다.
3. NCP와 연동하여 CI/CD 구축
NCP에서 도커 컨테이너 이미지를 간편하게 저장, 관리, 배포할 수 있는 서비스 Container Registry를 제공해 주는데 이를 이용할 예정입니다.
GITHUB_SHA 환경 변수를 이용해 특정 커밋에 해당하는 이미지를 가져오거나, 만약 설정되지 않았을 때 최신 이미지를 가져오는 방식입니다. 이전 코드에서는 항상 커밋 해시값을 사용하고 있는데, 이와 같이환경 변수를 체크하여, 필요시 최신 이미지를 사용할 수 있는 옵션을 추가할 수 있습니다.
최종코드입니다.
# 작업 모듈화
name: deploy next to ncloud
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
push_to_registry:
name: Push to mcp container registry
runs-on: ubuntu-latest
steps:
- name: Checkout # GitHub Action은 해당 프로젝트가 만들어진 환경에서 checkout하고 나서 실행
uses: actions/checkout@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: NCP 레지스트리 로그인
uses: docker/login-action@v3
with:
registry: ${{ secrets.NCP_CONTAINER_REGISTRY }}
username: ${{ secrets.NCP_ACCESS_KEY }}
password: ${{ secrets.NCP_SECRET_ACCESS_KEY }}
- name: 도커 이미지 빌드 후 푸시
uses: docker/build-push-action@v3
with:
context: .
file: Dockerfile
push: true
tags: ${{ secrets.NCP_CONTAINER_REGISTRY }}/cnergy-frontend:S{{ github.sha }} #깃허브 커밋 해시값으로 이미지 구분
pull_from_registry:
name: NCP 접속 후 이미지 다운로드 및 배포
needs: push_to_registry
runs-on: ubuntu-latest
steps:
- name: ssh 연결
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.NCP_HOST }}
username: ${{ secrets.NCP_USERNAME }}
password: ${{ secrets.NCP_PASSWORD }}
port: ${{ secrets.NCP_PORT }}
script: |
if [-z "$GITHUB_SHA" ]; then
echo "GITHUB_SHA 환경 변수가 설정되지 않았습니다. 최신 이미지를 사용합니다."
IMAGE_ID=$(docker images --format "{{.ID}}" | head -n 1)
else
echo "GITHUB_SHA: $GITHUB_SHA 이미지를 사용합니다."
IMAGE_ID=${{ secrets.NCP_CONTAINER_REGISTRY }}/cnergy-frontend:${{ github.sha }}
fi
docker stop cnergy-frontend || true
docker rm cnergy-frontend || true
docker run -d -p 80:3000 --name cnergy-frontend $IMAGE_ID
docker image prune -f
프로젝트를 진행하면서 빠르게 버그를 고치거나 예상치 못한 상황에 대한 작업을 하면서 불필요한 커밋이 생기는 경우가 많습니다. 이럴 경우 커밋으로 기존 작업들을 파악하는 데 어려움이 생기는데요 커밋을 가독성 있게 보고자 Git의 Interactive Rebase 기능과 Squash Merge를 이용해 불필요한 커밋들을 합쳐보겠습니다! 맨 마지막에 요약을 해 놓았으니 빠르게 하셔야 하는 분들은 요약을 보면 좋을거 같습니다 :)
1. 원하는 커밋의 기준점 찾기
git log --oneline
위의 명령어를 입력하여 커밋 히스토리를 확인하고, 합치고자 하는 커밋들이 어느 지점부터 시작되는지 그리고 어디서 끝나는지 확인합니다.
제가 위 명령어를 입력하면 아래와 같이 나옵니다.
전 HOTFIX가 정말 많아서 깃허브에서 각 커밋 히스토리를 보면서 각 HOTFIX를 분류했습니다. 부끄럽네요..ㅠ
2. 합치고 싶은 커밋을 rebase 하기
합치고 싶은 목록의 시작 커밋 이전 커밋을 선택합니다.
git rebase -i <base-commit-hash>
제가 수정하고 싶은 부분은
해당 부분에서 f34a762 - 4830ae0 커밋을 합치고 싶습니다.
그래서 그 이전 커밋인 e0c7bf8를 입력합니다.
git rebase -i e0c7bf8
그럼 위와 같이 뜨는데 합칠 커밋들의 pick을 squash로 바꾸어주고 :wq를 입력해 저장하면 됩니다. 저는 vscode에 새로운 파일 창일 열렸는데 이 경우에는 그 창에서 수정하고 Ctrl + S로 저장한 후 파일을 닫으면 됩니다. 자세한 내용은 아래 설명했습니다.
저같은 경우는 해당 과정에서 3가지 문제를 맞닥뜨렸는데 아래와 같이 해결했습니다.
1. 터미널에 파일이 뜨는 것이 아니라 새로운 파일이 생성됨
제가 vs code에서 git rebase -i e0c7bf8 명령어를 입력했을 때는
위와 같은 파일이 생성되어 당황했었습니다.
이럴 경우 switch to text 버튼을 누르고 pick을 s로 바꿔주면 됩니다.
한 가지 방법이 더 있는데 터미널에서 git config --global --list를 입력해 설정을 확인해주고, 기본적인 설정
C언어 관련 전공 과목을 공부하면서 값에 의한 호출 vs 주소에 의한 호출에 대해 정리한 내용을 공유해 봅니당
값에 의한 호출 & 주소에 의한 호출
값에 의한 호출
void swap(int , int);
int main(void){
int i = 3, j = 5;
swap(i, j);
printf("%d %d\\n", i, j);
/* 3 5 is printed */
return 0;
}
void swap(int p, int q){
int tmp;
tmp = p;
p = q;
q = tmp;
}
이렇게 해서 값을 바꿔도 실제 값이 변경되지는 않는다.
void swap으로 간 변수는 함수가 끝나면 메모리 공간이 사라진다 → 즉 실제 원본 값은 변하지 않는다.
주소에 의한 호출
함수의 매개변수를 포인터 형으로 선언한다
함수 몸체에서 역참조 연산자를 사용해 주소가 가리키는 공간의 값에 직접 접근한다.
함수를 호출할 때 주소를 인자로 전달한다.
void swap(int*, int*);
int main(void)
{
int i = 3, j = 5;
swap(&i, &j);
printf("%d %d\\n", i, j);
return 0;
}
void swap(int *p, int *q)
{
int tmp;
int tmp = *p;
*p = *q;
*q = tmp;
}
위에서 swap 함수를 먼저 선언한 후 아래에서 구현
인자를 전달할 때, 변수의 주소를 전달하면서 swap 함수의 인자인 포인터들이 해당 주소값을 할당 받는다
이를 통해 실제 값을 변경한다.
<예제>
int divide_p(int, int, int*, int*);
int main () {
int i, j, q, r;
printf("피제수를 입력하세요 : ");
scanf("%d", &i);
printf("제수를 입력하세요 : ");
scanf("%d", &j);
if (divide_p(i, j, &q, &r)){
printf("0으로 나눌 수 없습니다. \\n");
}
else {
printf("%d / %d : 몫은 %d이고, 나머지는 %d입니다. \\n", i, j, q, r);
}
return 0
}
위를 만족시킬 divide_p 함수를 작성해보자
int divide_p(int i, int j, int *q, int *r){
if (j == 0) {
return -1;
}
*q = i / j;
*r = i % j;
return 0;
}
if문 → 0은 false 0이 아닌 모든 값은 true
true와 false를 사용할려면 stdbool.h을 include해야 한다. //_Bool로 bool의 형을 지정할 수 있다.
