vite-plugin-compression2 사용 방법

vite-plugin-compression2는 번들 에셋을 압축하는 Vite 플러그인이다.

설치하기

npm i -D vite-plugin-compression2

설정하기

vite-plugin-compression2을 사용하려면 vite.config.ts에서 플러그인으로 등록해야 한다.

// vite.config.ts
import { defineConfig } from 'vite'
import { compression } from "vite-plugin-compression2";

export default defineConfig({
    plugins: [
        // 플러그인
    compression(),
  ],
});

아무 인자도 전달하지 않으면 기본 알고리즘(Gzip)이 적용된다.

옵션

vite-plugin-compression2는 html, xml, css, json, js, mjs, svg, yaml, yml, toml 확장자의 에셋 압축을 지원한다.

여러 개의 압축 알고리즘을 제공하는 방법

// vite.config.ts
import { defineComponent } from 'vite'
import { compression } from 'vite-plugin-compression2'

export default defineComponent({
  plugins: [
    // 플러그인
    compression(), // 기본값 gzip
    compression({ algorithm: 'brotliCompress', exclude: [/\.(br)$/, /\.(gz)$/] }),
  ]
})

여러 개의 압축 알고리즘을 제공하는 경우, exclude를 설정하여 중복 압축을 방지해야 한다. 압축 청크는 공유되기 때문에 exclude를 설정하여 이미 압축된 청크를 무시해야 한다.

vite-plugin-compression2은 네 가지 알고리즘을 제공하며, 대표적으로 gzip, brotli을 적용할 수 있다. 가장 일반적인 압축 알고리즘은 gzip, brotli이다. brotli가 gzip에 비해 약 15~20% 더 나은 압축 성능을 보인다. 하지만 brotli는 Internet Explorer에서는 지원되지 않기 때문에 gzip을 기본으로 적용하였다.

적용 결과

설정이 완료되었으니 결과를 살펴보자.

1. 번들 파일 비교

du -sh /dist/assets/index.js

du(disk usage) 명령어를 사용하여 dist 폴더의 파일 크기를 확인할 수 있다. 다음과 같은 결과가 나타난다.

• .js 624K
• .gz 220K
• .br 188K 압축된 파일 크기는 js, gz, br 순으로 크기가 작아지는 것을 볼 수 있다.

2. 빌드 결과

npm run build 명령을 통해 확인한 결과는 다음과 같다.

• gzip 적용(기본값) : 636.77kB → 222.09kB (약 65% 감소) / 5.43초
• brotli 적용 : 646.77kB → 189.88kB (약 70% 감소) / 7.08초
• gzip, brotli 둘 다 적용 : br, gzip 사이즈 동일 / 7.05초

정리

압축 플러그인을 사용한 결과 빌드 시간은 늘었지만 사용자가 다운로드하는 에셋의 용량은 대략 1/3로 줄어들었다. 이러한 결과는 압축을 적용하는 것이 유의미하다고 볼 수 있다. 다만, 빌드 시간을 단축할 수 있는 방법을 모색할 필요가 있다.

레퍼런스 npm/vite-plugin-compression2

프로젝트 빌드 시 가장 큰 에셋의 크기가 500kB가 넘어가는 문제가 있었다. lazy, Suspense를 도입해 동적 로드와 코드 스플리팅을 적용했지만 여전히 500kB를 초과하는 문제가 있었다. 해결 방법 중 하나로 Vite 압축 플러그인을 찾아보게 되었다. 압축 플러그인 소개에 앞서 HTTP 압축과 알고리즘에 대해 알아보겠다.

HTTP 압축이란?

HTTP 압축은 서버와 브라우저 간의 데이터 전송 속도와 대역폭을 개선하기 위한 기술이다. 서버가 브라우저에게 보낼 응답(Response)를 압축하여 브라우저에게 더 작은 사이즈의 압축 파일을 전달함으로써 네트워크 비용을 줄일 수 있다. 압축에 사용될 일반적인 알고리즘은 Gzip, Brotli(br)이다.

압축 알고리즘을 선택하기 위해서는 브라우저와 서버 간 콘텐츠 협상(Content Negotiation)을 ****사용한다. 클라이언트가 보내는 HTTP 헤더를 사용하는 방법은 다음과 같다.

1. 브라우저가 웹 서버로 리소스를 요청할 때 Request Header의 Accept-Encoding에 브라우저가 지원하는 압축 알고리즘과 우선순위를 함께 전달한다.
2. 서버에서는 헤더의 압축 알고리즘에 따라 리소스(Response Body)를 압축한다. 이때 사용한 알고리즘은 Content-Encoding 헤더에 담아 브라우저에게 전달한다.

압축 알고리즘의 종류

압축 알고리즘의 종류 중 많이 언급되는 몇 가지를 알아보려고 한다.

• deflate : 특정 파일을 압축하는 무손실 압축 데이터 알고리즘으로 ZIP, gzip 등에 사용된다.
• Gzip : 1992년 공개된 압축 알고리즘으로 무손실 압축 데이터 알고리즘(DEFLATE)를 사용한다. 최대 70%까지 사이즈를 줄여준다. 파일 중복 코드나 띄어쓰기를 줄여준다. 확장자는 .gzip이다. 많은 CPU 리소스를 사용하지만 압축률이 높기 때문에 자주 사용되지 않는 콜드 데이터에 적합하다.
• Brotli : 구글이 2013에 발표한 압축 알고리즘이다. gzip에 비해 최대 15~20% 더 적은 용량으로 압축핟나. 확장자는 .br이다. 참고로 Brotli는 ie에서는 지원하지 않기 때문에 ie에서는 gzip을 사용해야 한다.
• zstd : 페이스북에서 개발한 오픈소스 무손실 데이터 압축 알고리즘이다. gzip과 비슷한 압축률을 제공하지만 압축 해제 속도는 더 빠르다.
• lzo : Lempel-Ziv-Oberhumer(LZO)의 줄임말로 deflate 압축에 비해 압축/해제 해제 속도가 더 빠르다. gzip보다 더 적은 CPU 리소스를 사용한다. 다른 알고리즘에 비해 압축률이 낮다. 빠른 압축/해제 속도로 실시간 데이터에 특화되었다.

JavaScript를 압축하는 일반적인 방법은 Gzip, Brotli이다. 프로젝트에서도 Gzip과 Brotli를 적용했다.

참고/배포 서비스에 따른 압축 형식

배포 서비스에 따라 압축 형식을 지원한다.

• Vercel은 gzip, brotli 압축 형식을 지원한다.
• AWS CloudFront는 Gzip, Brotli 압축 형식을 지원한다. 두 형식이 모두 있는 경우 Brotli를 선호한다.
• Netlify Edge는 Gzip, Brotli 압축 형식을 지원한다.

내가 이용하고 있는 배포 서비스가 지원하는 압축 형식이 무엇인지 알아두면 좋을 것 같다.

vite-plugin-compression2의 기능

이제 내가 사용했던 vite 압축 플러그인 vite-plugin-compression2에 대해 소개해 보겠다.

vite-plugin-compression2은 Vite 환경에서 빌드 시 생성되는 Assets 파일들을 압축하여 파일 크기를 줄여준다. 지원하는 압축 알고리즘은 deflate, Gzip, Brotli 알고리즘이 있다. vite-plugin-compression2는 클라이언트 측에서 에셋을 압축한다. 만약, 클라우드 서버 제공자가 압축을 지원하는 경우 압축 플러그인이 필요하지 않을 수 있다.

vite-plugin-compression과 vite-plugin-compression2의 차이

npm에서 vite-plugin-compression를 검색하면 두 개가 있다. 이 둘 사이에 무슨 차이가 있는지 알아보자.

npm 검색 결과를 살펴보면, vite-plugin-compresion은 다운로드 수가 높지만 업데이트가 3년 전이다. vite-plugin-compression2는 다운로드 수는 적지만 업데이트가 최근(20일 전)이다. 라이브러리 오른쪽 그래프에 있는 pqm 수치는 p(Popularity) q(Quality), m(Maintenance)를 의미한다. 2버전은 기존 버전보다 q, m 수치가 높다.

vite-plugin-compression2 Q&A에 왜 2버전을 사용해야 하는지에 대한 질문이 있었다. 답변은 vite-plugin-compression이 유지보수가 되지 않고 있어서 2 버전을 새로 만들었다고 한다.

팀원의 의견과 pqm 수치를 보고 판단하여 vite-plugin-compression2를 사용하기로 결정했다. vite-plugin-compression2 사용 방법은 따로 정리해두겠다.

정리

웹사이트 성능을 높이는 HTTP 압축에 대해 알게 되었다. HTTP 압축은 전송 속도와 대역폭을 개선하기 위한 기술이다. 압축 알고리즘을 선택하기 위해 콘텐츠 협상(Content Negotiation)을 사용한다. 콘텐츠 협상의 과정은 다음과 같다. 브라우저가 리소스를 요청할 때 Accept-Encoding 헤더에 브라우저가 지원하는 압축 알고리즘의 종류와 우선순위를 전달한다. 서버는 리소스에 적용한 압축 알고리즘을 Content-Encoding 헤더에 담아 브라우저에게 전달한다.

Gzip보다 Brotli 알고리즘을 둘 다 지원한다면 압축률이 더 좋은 Brotli 알고리즘을 사용하자.

npm 검색 시 나오는 pqm 수치에 대해 알게 되었다. 라이브러리를 선택할 때 업데이트 기간과 함께 pqm수치를 살펴보면 좋겠다.

레퍼런스 GitHub/vite-plugin-compression2 mdn/HTTP 압축 mdn/콘텐츠 협상 [압축 방식 비교] gzip vs snappy vs lz4 vs brotli vs zstd vs lzo

첫 프론트엔드 팀 프로젝트를 완주했다. 정말 많은 성장을 이룬 한 달이라고 생각한다. 강의 듣고 공부할 때와 실전은 느낌이 많이 달랐다. 무엇보다 든든한 팀원분들과 함께하는 프로젝트가 나에게 긍정적인 영향을 미쳤다.

지난 회고에서 "두려워도 나를 믿고, 팀원들을 믿고 앞으로 나아가는 한 달을 만들어 가면 좋겠다"고 마무리했었다. 좋은 팀원분들을 만나 잘 마무리한 것 같아서 마음이 한결 가벼워졌다.

프로젝트 설명

채널이 있는 SNS를 주제로 백엔드 API가 주어지고 1주 정도의 기획 단계를 거쳐 3주 간 개발이 진행되었다. 우리 팀은 커뮤니티보다는 쇼핑에 치중되어 있는 기존 패션 SNS를 보완하여 채팅도 할 수 있는 룩북 SNS로 의견이 모아졌다.

프로젝트 개요

• 프로젝트명 : 루키(looky) 룩북 SNS
• 프로젝트 기간 : 2023.12.22 ~ 2024.01.17
• 프로젝트 인원 : 프론트엔드 개발 4명
• 내 역할 : 공통 컴포넌트, 검색 페이지, 프로필 페이지
• 메인 서비스 주소 : https://looky.kr 도메인 만료 시 서비스 주소 https://looky-working.vercel.app

좋았던 경험들

새로운 기술, 라이브러리

• Redux
• TanstackQuery
• React Hook Form 등

나에게는 많은 기술이 새로웠고 심적인 부담으로 다가왔다. 그래도 물어볼 팀원이 있다는 점이 나에게는 든든했고 마음껏 실수하고 부딪혀봐야 겠다는 생각이었다. 공식문서와 팀원의 코드를 보면서 개발을 했었다. 지나고보니 새로운 기술을 적용해보길 잘 했다고 생각한다. 배워가는 것이 많은 프로젝트였다.

라이브 코딩

프로젝트 초반에 진행되어야 하는 라우팅, API 설정에 대해 라이브코딩을 진행했다. 라이브코딩으로 보니 훨씬 흐름이 이해가 잘 됐다. API는 사용할 일이 많았는데 라이브 코딩 덕분에 쉽게 사용할 수 있었다.

페어 프로그래밍

프로젝트 후반에 하루 날잡아 페어 코딩을 진행했다. 검색 결과 페이지에서 이전 검색어를 검색하면 재렌더링이 되지 않는 문제가 있었다. 캐싱 문제일 것 같다고 생각했지만 혼자 해결하는 것이 어려웠다. 먼저 기능 개발을 마무리한 팀원이 감사하게도 페어 코딩을 진행해서 같이 해결해보자고 제안했다. 문제는 예상했던 캐싱 문제로 useEffect의 의존성 배열을 수정하고 useQuery의 staleTime을 0으로 설정하는 것으로 해결했다.

페어 프로그래밍을 진행하면서 다음과 같은 과정을 겪었다.

1. 내 코드를 잘 설명하고 이해시키기
2. 대화로 문제 해결에 대한 아이디어 얻기
3. 예상되는 원인 파악 후 하나씩 제외하기

내 코드를 상대에게 잘 설명하고 이해시키는 것이 참 어려웠다. 그래도 차근차근 코드의 흐름을 따라 설명해보았다. 내 코드를 설명하는 데에도 연습이 많이 필요하다고 느꼈다. 2, 3번은 문제를 혼자 해결할 때보다 훨씬 빠르게 진행되었다. 혼자 해결할 때는 내 생각에 갇히는 경우가 있는데 대화를 통해 빠르게 사고를 전환할 수 있었다. 이번 프로젝트에서 가장 기억에 남는 경험이라면 페어 프로그래밍을 떠올릴 것이다. 먼저 페어 프로그래밍을 제안한 팀원에게 정말 감사하다.

공통 컴포넌트

공통 컴포넌트를 만들고 팀원들이 만든 공통 컴포넌트를 사용해보는 경험이 신선했다. 내가 컴포넌트를 만들 때의 목표는 "어떻게 해야 팀원들이 쉽게 이해하고 사용할 수 있을까?"에 초점을 맞추었다. 리팩토링하면서 필수 props 1개만 남기고 사이즈도 팀원들의 의견을 듣고 세분화했다. 컴포넌트 리팩토링에서 다음과 같은 사항을 생각했다.

• 가독성 높은 변수명
• 필수 속성 최소화
• 값이 없을 때 예외처리
• 확장성을 위한 경우의 수 생각하기

예외처리, 확장성은 아직 나에게 어려운 부분이다. 다음 프로젝트에서도 위와 같은 생각을 많이 해볼 생각이다. 프로젝트가 마무리될 때 즈음 이곳저곳에 공통 컴포넌트가 쓰이는 것을 보니 뿌듯했다. 기회가 된다면 여러 가지 공통 컴포넌트를 만들어보고 싶다.

팀에게 배운 점

이번 팀은 밸런스가 정말 잘 맞는 팀이었다고 생각한다. 나의 성장에 영향을 주었고 모두 배울 점이 있었다.

1. 리더 : 계획을 수립하고 추진하는 능력이 뛰어났다. 우리 팀은 항상 마감 기한보다 일찍 제출하고 일정에 쫓기지 않았는데 리더의 역할이 컸다.
2. 테크 리더 : 기술적 역량이 뛰어남에도 겸손했다. 내 꼬리 질문에도 적극적으로 답변해주셔서 나의 기술적 성장에 도움을 주었다.
3. 분위기 메이커 : 본인만의 방법으로 좋은 컨디션을 유지했다. 개인적으로 긍정적인 마인드를 유지하는 법을 물어본 적이 있을 정도로 배우고 싶었다.

팀에서의 내 주역할은 디자이너/기획자였다고 생각한다. UX/UI 프로젝트를 경험해 보았기 때문에 팀에 도움이 될 수 있을 것 같았다. 그래서 회의에 적극적으로 참여하고 많은 아이디어를 내려고 노력했다. 이 자세를 끝까지 유지했으면 좋겠다.

팀 프로젝트의 자산, 문서화

리더가 기획 초반부터 "프로젝트는 남는 게 문서다"라고 중요성을 강조했었다. 신경을 쓴 만큼 문서를 다른 팀이 많이 참고했다고 한다. 나도 다시 찾아 참고하고 있을 정도로 잘 작성된 문서라고 생각한다. 다음 팀에서도 문서화에 신경을 쓸 예정이다.

루키 프로젝트 컨벤션 문서

KPT 회고

팀에서 중간 회고, 최종 회고로 KPT를 작성했었다. 아쉬운 점은 기억해두었다가 다음 최종 프로젝트에서 반영해 보면 좋겠다. Keep으로 옮겨지는 과정이 좋아서 KPT를 다시 활용할 것 같다.

중간회고와 최종회고 비교하기

중간 회고 이후 Problem, Try를 하나라도 제대로 실천해보면 좋겠다고 생각했는데 최종 회고와 비교해보니 Keep으로 이동한 항목도 있었다. 계속 Try에 남아 있는 개발 이해도는 프로젝트가 끝나고 공식문서를 읽으면서 채워보려고 한다.

최종회고

Keep

• 공통 컴포넌트, 훅 등 사용 높이기
• 좋은 컨디션과 마인드 유지하기
• 모를 때는 질문하기
• 감사는 아낌없이 전하기

Problem

• 생각했던 리팩토링 해보기
• Redux, React 기술 이해도 높이기
• 나에 대한 강점 강화하기
• 코딩테스트 준비 다시 시작하기

Try

• 리액트 공식 문서 읽어보기 & 놓친 부분 공부하기
• 하드 스킬 성장시키기
• 내 의견을 근거와 함께 잘 설명하기

다음 회고까지

다음 달에는 백엔드와의 프로젝트가 진행된다. 어떤 새로운 경험을 하고 나는 또 얼마나 성장해있을지 기대가 된다. 지난 팀 프로젝트의 경험을 잘 녹여내서 다음 달의 성장의 시간을 잘 이겨냈으면 좋겠다.

주요 활동

첫 모각코

이번 달에 2차 팀이 결성된 후 모여서 각자 코딩 줄여서 모각코 행사가 열렸다. 전에는 참여하지 못했다가 팀원들과 오프라인에서 만나기로 의견을 모았다. 점심, 저녁도 함께 하면서 대화가 한결 편해졌다. 팀 프로젝트가 진행되기 전에 친밀감을 쌓기에 아주 좋은 기회가 되었다. 나는 이전보다 얼굴을 맞대고 이야기를 나누는 자리가 점차 좋아지고 있다. 첫 만남은 늘 설렘과 두려움이 동시에 존재하는데 그것보다 얻는 것이 많은 것 같다. 온라인 수업은 혼자 있는 시간이 많다 보니 에너지가 소모되는 느낌이지만, 오프라인은 직접 사람들이 무언가 몰두해 있는 모습을 보면서 나도 그 에너지를 얻어 간다.

클린코드

특강과 멘토님과의 커피챗에서 클린코드에 대해 들어볼 수 있었다. 클린한 코드를 작성하고 싶은 마음은 있지만 구현에 집중하다 보면 클린 코드에서 멀어지는 경우가 많다. 대체 클린 코드는 무엇이길래 이렇게 회자되는 것일까 궁금증을 가졌었는데 그 의문이 조금은 풀리게 되었다. 결국 코드도 누군가가 보는 문서이다. 코드에는 정답이 없지만 협업을 위한 클린 코드는 있다고 생각한다.

탐구동료

데브코스에는 주마다 4명의 동료에게 질문하는 채널이 있다. 이번 달은 대상이 되기도 하고 좋았던 질문자로 선정되기도 했다. 처음 보는 동료분들의 자기소개서를 정독하면서 이 사람은 어떤 사람일까 어떤 관심을 가지고 있을까 진심으로 질문을 준비했다. 처음 보는 사람에게 그렇게 정성스럽게 질문을 해보는 것은 낯설었지만 좋은 경험이었다. 어떤 사람이든 매력이 있다.

KPT

Keep

• 과제에서 사용해 보고 싶었던 라이브러리를 적용해 보고 있다.
• 팀 프로젝트에서 의견을 적극 제시하고 있다.
• 꺾였던 의지를 다시 되찾고 유지하고 있다.

  Problem

• 첫 프론트엔드 팀 프로젝트 시작에 앞서 두려움이 앞선다. 견디고 극복하자.
• eslint는 적용이 되는데 eslint airbnb style은 적용이 안된다. 프로젝트 기간에는 개발 버전을 유지하는 게 안전하니 나중에 해결해 보려고 한다.

  Try

• 공식문서 스터디에 참여하고 있는데 리액트 공식문서를 많이 읽지 못했다. 일정 시간을 내어서 공식문서를 끝까지 읽어보려는 것이 내 목표이다.
• 프로젝트 진행할 때 팀원들과 소통하자. 소통만큼 효율적인 방법은 없다고 생각한다.
• 오래 고민하지 말고 질문하자.

이번 주부터 프로젝트 기획이 끝나고 본격적인 프로젝트가 시작될 예정이다. 두려워도 나를 믿고, 팀원들을 믿고 앞으로 나아가는 한 달을 만들어 가면 좋겠다.

데브코스 첫날을 맞이한 지 한 달이 지났다. 처음을 마주하는 시작은 설레면서도 두려운 일인 것 같다. 나는 지금껏 수많은 시작을 겪었음에도 여전히 그 느낌은 새롭다. 첫 느낌을 공개된 글로 남기는 것은 어색하지만 뜻깊은 일이 될 수 있을 것 같다는 생각이 들었다. 회고 방법은 4F를 참고했다. 6개월 지난 후 뒤돌아 봤을 때 많은 성장을 느낄 수 있지 않을까 기대해 보면서 첫 회고는 ‘시작’을 주제로 내 생각을 써보려고 한다. 시작해 보자.

첫 시작의 느낌

• 첫 합격
• 첫 코딩 테스트
• 첫 만남
• 첫 과제
• 첫 코드 리뷰
• 첫 회고

리스트로 적어보니 생각보다 많은 시작을 해낸 것 같다. 잊고 있었던 시작에 대한 내 느낌과 생각에 대해 지금부터 떠올려보겠다.

첫 합격

첫 합격의 순간은 초심을 떠올리게 한다. 합격 메일을 열기 전 그 기분 좋은 떨림이 잠시 잊혔던 것 같다. 지금은 벌써 한 달이 지났다는 불안감이 그 자리를 밀어내고 있다. 다시 그 떨림을 회상해 보니 지금 내가 데브코스에서 공부한다는 사실이 감사하게 느껴진다. 초심을 다시 떠올리는 것으로 나에게 마음의 재정비가 필요하다고 인지할 수 있었다.

첫 코딩테스트

코딩테스트 문제를 다 풀지 못해 데브코스에 대한 기대를 내려놓고 있었다. 코딩테스트는 나에게 아직도 어려운 숙제로 남아있다. 처음에는 혼자 풀어보겠다고 굉장히 많은 시간을 투자했었다. 그러나 부족한 공부를 계속 끌고 가는 것이 오히려 필요한 공부를 놓치고 있다는 생각이 들었다. 못 푸는 문제는 쌓여가고 자신감도 잃어갈 때 즈음 팀원 분들께 조언을 구했다. 감사하게도 코딩테스트를 공부했던 경험들을 공유해 주셔서 정말 감사했다.

첫 만남

첫 만남에서 자기소개는 넘어야 할 하나의 관문 같다. 내향형 인간으로 살아와서 그런지 익숙해지지는 않지만 최대한 나를 설명해 보려고 노력하는 편이다. 관문을 잘 이겨내고 좋은 팀원들을 만나 말도 걸어보고 내적 친밀감을 쌓고 있다. 멘토님 첫 온라인 대면 때도 긴장을 많이 했었는데 지금은 매주 하나라도 더 알려주시려는 모습에 질문도 맘껏 해보는 중이다. 입은 열기 직전이 가장 어려운 것 같다.

첫 과제

처음으로 다른 사람들이 있는 레포지토리에 푸시하려니 낯설었다. main 브랜치에 푸시하지는 않을까 버튼 하나하나 긴장하면서 눌렀다. 이런 긴장감도 지금 느껴보길 다행이라고 생각하고 있다. 모든 것을 연습 삼아 많은 시도를 해보는 것이 중요하다고 느낀다.

첫 코드 리뷰

팀원분들과 멘토님에게 첫 코드 리뷰를 받았을 때 코드 중복, 예외 처리, 데이터 관리 등 놓치는 부분이 많다는 것을 느꼈다. 피드백을 통해 코드를 개선해 볼 수 있다는 점에서 조금 더 성장할 수 있는 기회를 얻고 있다. 내 과제의 완성도가 아쉽다고 느껴질 때가 있는데 부담보다는 좀 더 긍정적인 마음을 가져봐야겠다.

첫 회고

시작을 되짚어보고 과정을 회고하는 것이 나에게는 의미가 있었다. 한 달 동안 ‘내가 성장했다고 말할 수 있을까?’ 의문과 불안감이 들었었다. 하지만 첫 시작들을 되돌아보니 ‘내가 한 일들을 지나치고 있었구나. 많은 관문을 지나왔구나.’라는 생각이 들었다. 한 달 지나오면서 힘들다는 생각이 많이 들었는데 충분히 첫 시작을 잘 해낸 것만으로도 칭찬해 줘야겠다는 생각이 들었다.

다음 회고까지의 다짐

시작이라는 주제로 지난 한 달간의 과정을 되짚어보았다. 내가 지금 힘든 이유는 한 번에 잘 해보려는 욕심 때문인 것 같다. 결과는 조금은 내려놓고 성장하는 과정 자체를 즐기면 좋겠다. 멘토님이 해주신 인상적인 말이 떠오른다. ‘길게 보자. 나만의 속도로.’ 다음 회고까지는 부담감을 내려놓고 나만의 속도를 찾아보려고 한다.