{intro}
<Spacing size="lg" />
## 개발 동기
 
올해 들어 사이드 프로젝트를 하기로 마음먹었습니다. 그런데 본격적으로 프로젝트를 하기에 앞서 사이드 프로젝트용 리액트 UI 라이브러리를 만들어보면 어떨까 싶더라고요. 버튼이나 타이포그래피처럼 공통적으로 사용되는 컴포넌트를 미리 만들어두면 이후 프로젝트에서는 서비스 로직에만 집중할 수 있을 거라고 생각했습니다. 사실 예전이었으면 라이브러리를 만들 생각은 못했을 텐데 작년에 패스트캠퍼스에서 UI 라이브러리 만들기 강의를 들었기 때문에 '꼭 이걸 내 프로젝트에 활용해야겠다'라는 생각을 했고 이번 기회에 직접 저만의 UI 라이브러리를 만들어보게 되었습니다.
 
참고로 패키지 이름은 앞으로 진행할 프로젝트인 독서 기록 플랫폼 chak(책 + check)와 레고 블록을 조립해서 멋진 결과물을 만들듯이 컴포넌트 블록을 조립하여 서비스를 만들 수 있다는 의미에서 chak-blocks라고 지어보았습니다.
 
## 고려할 부분
 
구현 사항은 간단합니다. 리액트 컴포넌트 만들기! 그런데 이걸 패키지로 배포하려면 고려해야 할 부분이 있습니다.
 
- **ESM, CJS 모듈 시스템을 모두 지원할 것**
 이 부분은 강의를 듣지 않았다면 생각하지 못했을 부분이었습니다. 패키지를 사용하는 곳에서 어떤 방식의 모듈 시스템을 사용할지 모르니 범용성 있게 ESM, CJS 모두 지원해 주는 것이 좋다고 합니다.
- **서버 컴포넌트를 지원할 것**
 사이드 프로젝트를 넥스트 앱 라우터로 만들 생각이었기 때문에 서버 컴포넌트를 지원해야 했습니다. 서버 컴포넌트는 브라우저에서 실행되는 자바스크립트 번들의 크기를 줄이기 위해 리액트에서 제공하는 컴포넌트로, 서버에서만 실행되고 자바스크립트 번들에서는 제외되기 때문에 브라우저에서는 실행되지 않습니다. 즉 CSS in JS 방식의 스타일 라이브러리와 브라우저에서 실행되는 리액트 훅 사용에 제약이 걸리게 되는 것이죠. 뒤에서 이야기하겠지만 이것 때문에 꽤 골머리 앓았습니다 🥲
- **사용자는 나**
 작업을 하다 보면 '어디까지 기능을 지원해야 하지?'하는 애매한 부분이 생깁니다. 이때 너무 많은 경우의 수를 고려하여 코드의 복잡성을 높이지 않기 위해 주 사용자를 저 자신으로 설정하고 작업했습니다. 당장 저에게 필요한 컴포넌트, 기능 구현에 집중했고 나중에 필요해지는 것들은 추후 보완하고자 했습니다.
 
## 번들러 설정하기
 
본격적으로 컴포넌트를 만들기에 앞서 번들러 세팅을 해주었습니다. 번들러는 모듈화된 파일들을 하나로 묶어주는 역할을 합니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738672323/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/mklnummqi29scrzpl0ja.png" alt="웹팩 메인 이미지" width={1095*0.7} height={414*0.7} caption="웹팩 메인 화면, 번들러의 역할이 잘 표현되어 있음"/>
 
이번 라이브러리 프로젝트에서 사용한 번들러는 [esbuild](https://esbuild.github.io/)입니다. esbuild는 다음과 같은 특징을 갖습니다.
 
- **번들링 속도가 빠름.**
 esbuild는 메인 화면에서도 빠른 빌드 속도를 강점으로 내세우고 있습니다. 웹팩 같은 기존의 번들러와 비교하면 10-100배 정도 빠르다고 합니다.
- **추가적인 플러그인 없이 자바스크립트, CSS, 타입스크립트, JSX을 번들링할 수 있음**
 (다만 타입 체크는 지원하지 않기 때문에 tsc로 따로 타입 체크를 해주었습니다.)
- **ESM, CJS 번들링 지원** 
 
즉, 제가 고려한 사항들을 모두 충족하면서도 가장 빠른 속도의 번들러이기 때문에 esbuild가 이번 프로젝트에 가장 적합하다고 판단했습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738668086/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/vfng2f9vtwfv0d2aemer.png" alt="번들링" width={1026 *0.7} height={380 *0.7}/>
 
src 폴더에 있는 파일들을 번들링하면 여러 컴포넌트 코드가 index.js 파일 하나에 모두 들어가 있는 것을 확인할 수 있습니다.
 
그런데 컴포넌트 작업을 마무리하고 넥스트 앱 라우터 프로젝트에서 패키지를 사용해보니 에러가 발생하더라고요.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738668086/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/xj4lzbsmlpqumuiko5fn.png" alt="TypeError: (0, react_WEBPACK_IMPORTED_MODULE_® createContext) is not a function" width={943} height={178} caption="TypeError: (0, react_WEBPACK_IMPORTED_MODULE_® createContext) is not a function"/>
 
일부 컴포넌트에서 Context API를 사용하고 있어 발생한 에러였습니다. 타이포그래피나 태그 등 동적 기능이 없는 컴포넌트들도 Context API를 사용하는 컴포넌트들과 한 파일에 번들링되어 있다보니 서버 컴포넌트로 사용하기에 제약이 걸렸습니다. 어떻게 이 문제를 해결할 수 있을까 고민하던 차에 떠오른 방법은 바로...
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738668920/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/cu1jcoayh1yz0wh6b2lu.jpg" alt="깨달음" width={319*0.7} height={360*0.7} />
<HighlightText textColor="red">"코드를 분리해 버리자!"</HighlightText>
 
 
Context API 사용 여부를 기준으로 번들된 결과물을 나누면 문제가 해결될 것이라고 생각했습니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738668086/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/eezclvbgl27xnzofqjvm.png" alt="번들링" width={1010*0.7} height={476*0.7}/>
 
그리고 실제로 적용해 보니 잘 동작하는 것을 알 수 있었습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738673821/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/urxmrzdktwpnhoykoodg.png" alt="plain 컴포넌트 렌더링" width={724} height={248} caption="plain 컴포넌트 렌더링 화면"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738673821/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/jctez3mqpveaungewaln.png" alt="context 컴포넌트 렌더링" width={724} height={361} caption="context 컴포넌트 렌더링 화면"/>

 
다만 사용하는 곳에서 context 컴포넌트와 plain 컴포넌트를 구분해서 import 해야 하기 때문에 사용법이 복잡해진 점은 아쉽습니다.
 
## 컴포넌트 만들기
 
리액트 UI 라이브러리니까 컴포넌트도 만들어줘야 합니다. 모든 프로젝트에서 기본적으로 사용되는 타이포그래피, 버튼, 태그, 아코디언 등을 만들었습니다.
 
### 재사용성 고려하기
 
컴포넌트를 만들 때 중요한 점은 재사용성을 고려해야 한다는 점입니다. 저는 아래와 같은 방법으로 재사용성을 높여보았습니다.
 
- **HTML Element Attributes 모두 지원하기**
 저는 공통 컴포넌트를 만들 때 '스타일이 입혀진 HTML 요소'처럼 쓸 수 있도록 하는 것을 좋아합니다.
컴포넌트는 스타일만 가지고 있고 컴포넌트가 처리할 로직이나 속성 등은 props로 전달받을 수 있게 말이죠. 
 예를 들어 버튼 컴포넌트를 만든다고 했을 때, 스타일이 입혀진 버튼 요소처럼 쓸 수 있도록 버튼 요소가 가진 속성을 모두 지원합니다. 버튼이 처리할 클릭 로직은 onClick prop으로 전달받으며, type, disable, 그리고 data attribute까지 컴포넌트를 사용하는 곳에서 자유롭게 사용할 수 있도록 HTML Element Attributes를 props로 전달받을 수 있게 컴포넌트를 구성했습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738674874/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/orf082znq0hlnb59ouj7.png" alt="버튼 컴포넌트 props" width={922*0.7} height={240*0.7} caption="버튼 요소의 모든 attributes를 props로 지원"/>
 
- **컴파운드 패턴 적용하기**
 아코디언같이 여러 컴포넌트를 조합하여 컴포넌트를 만드는 경우, 부모 컴포넌트 내부에 자식 컴포넌트를 포함하고 있으면 요구사항이 조금 달라졌을 때 대응하기 쉽지 않습니다. props로 분기 처리하는 등 코드가 점점 복잡해지기 마련입니다. 이런 복잡성을 방지하고 유연하게 컴포넌트를 사용하기 위해 컴파운드 패턴으로 컴포넌트를 설계했습니다. 컴파운드 패턴을 사용하면 Context API를 통해 서로 상태는 공유하지만, 컴포넌트 자체는 독립적으로 존재하기 때문에 상황에 맞게 컴포넌트를 조립할 수 있습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738674777/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/uzcjuro058cw2htho8qn.png" alt="컴파운드 패턴으로 구현된 아코디언 컴포넌트" width={1062*0.7} height={988*0.7} caption="컴포넌트가 독립적으로 사용되어 자유롭게 커스텀 가능"/>
 
### 스타일링
 
컴포넌트 스타일링은 [vanilla extract](https://vanilla-extract.style/)를 사용했습니다. vanilla extract는 CSS in TS 방식의 스타일 라이브러리로, 이름처럼 빌드 타임에 순수한 CSS를 추출합니다. 
 
<Callout title="바닐라의 의미">
잠깐 딴 길로 새자면 바닐라 자바스크립트도 그렇고 왜 바닐라가 순수하다는 의미인지 궁금해져서 찾아보았는데 바닐라 아이스크림이 가장 기본적이 맛이라서 그렇다고 하네요 🍦😋
</Callout>
 
순수한 CSS를 제공한다는 것에는 두 가지 장점이 있습니다.
 
- **서버 컴포넌트에서 사용하기에 적합함**
 런타임 환경에서 동적으로 스타일이 결정되는 것이 아니기 때문에 서버 컴포넌트를 스타일링하기 적합하다고 생각했습니다.
- **패키지를 사용하는 곳에서 스타일 라이브러리에 의존성을 갖지 않음**
 빌드된 패키지에는 순수한 CSS만 포함되기 때문에, 패키지를 사용하는 곳에서 CSS 라이브러리에 대한 의존성이 필요하지 않을 것이라 생각했습니다. 그러나 편의성과 동적 스타일링을 위해 vanilla-extract/dynamic과 vanilla-extract/recipes를 추가로 사용하게 되면서, 결국 패키지를 사용하는 곳에서 이 라이브러리들을 설치해주어야 합니다 😞
 
### 스토리북
 
작업 중 컴포넌트 확인은 스토리북을 사용했습니다. 컴포넌트 비주얼 테스트와 동시에 사용자들에게 제공할 문서까지 만들 수 있으니, 일석이조라고 생각했습니다. 그러나 스토리북 개발 서버 구동과 번들링을 위한 vite 설치가 불가피해졌습니다. '하나의 프로젝트에 번들러가 2개여도 되나...?'하는 의문이 생겼지만 일단 스토리북을 사용하기 위해 vite를 추가로 설치해 주었습니다.
 
## package.json 설정하기
 
패키지를 배포하기 위해서 package.json을 설정해 주어야 합니다.
평소에는 스크립트를 추가하거나 의존성 명세서 정도로 사용했는데 패키지로 배포하려고 하니까 여러모로 신경 쓸 게 있더라고요.
 
- **name** & **version** 
 name은 배포될 패키지의 이름이고 version은 패키지의 현재 버전입니다. [npm Docs](https://docs.npmjs.com/cli/v11/configuring-npm/package-json)에 따르면 패키지를 배포할 때 name과 version은 고유해야 한다고 합니다. 때문에 패키지에 변경 사항이 발생하여 새로 배포될 때마다 버전을 업데이트해 주어야 합니다.
- **files**
 패키지를 설치할 때 포함할 항목을 명시하는 필드입니다. 기본값은 ["*"]로 모든 파일을 포함하지만 저는 번들링 된 파일만 내보내기 위해 ['dist']로 명시해 주었습니다.
- **export** 
 패키지 진입점을 정의하는 필드입니다. 
 
```json
 "exports": {
 ".": {
 "types": "./dist/index.d.ts"
 },
 "./plain": {
 "import": "./dist/plain/index.js",
 "require": "./dist/plain/index.cjs",
 "types": "./dist/components/plain/index.d.ts"
 },
 "./context": {
 "import": "./dist/context/index.js",
 "require": "./dist/context/index.cjs",
 "types": "./dist/components/context/index.d.ts"
 },
 "./plain/style.css": "./dist/plain/index.css",
 "./context/style.css": "./dist/context/index.css"
 }
```
 
context 컴포넌트와 plain 컴포넌트의 진입점을 구분하고 ESM과 CJS의 모듈 시스템과 type, style 파일 경로를 명시해 주었습니다. 
 
자세한 내용은 [Node.js 공식 문서](https://nodejs.org/api/packages.html#package-entry-points)에서 확인해 볼 수 있습니다.
 
## 문서화
 
아무래도 npm에 올라갈 패키지다 보니 문서화 작업에도 신경을 쓰게 되었습니다. 설치 방법, 컴포넌트 사용 방법 등을 되도록 상세히 리드미에 작성해 주었습니다. 이때 마크다운 테이블 반복 작업이 상당히 귀찮은데요. 이 부분은 Chat GPT 도움을 많이 받았습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738671670/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/f0djxze7vxohbichjoa5.png" alt="개떡같이 말해도 찰떡같이 알아듣는 Chat GPT" width={719} height={296} caption="개떡같이 말해도 찰떡같이 테이블 만들어주는 Chat GPT"/>
 
[chak-blocks 리드미 보러 가기](https://github.com/ysisys0202/chak-blocks)
 
## publish 하기
 
npm 배포는 간단합니다. npm 사이트에서 회원가입을 한 후, 배포하고자 하는 프로젝트에서 npm publish 명령어를 입력하면 됩니다.
 
[chak-blocks 패키지 보러 가기](https://www.npmjs.com/package/chak-blocks)
 
## 포스트를 마무리하며
 
이렇게 UI 라이브러리를 만들고 npm에 배포까지 해보았습니다. 늘 익숙하게 해왔던 컴포넌트 작업에 더해, 번들러를 직접 세팅해 보며 개발 환경에 대한 이해도를 높이고, 패키지 배포용 package.json을 구성하며 패키지는 만드는 방법에 대해서도 알 수 있었습니다. 여러모로 아쉬움이 남는 부분도 있지만 점차 개선할 수 있으리라 믿고 첫 패키지 배포 후기는 여기서 마치도록 하겠습니다 👋👋

UI 라이브러리 제작기

2024 연말결산

{intro}
<Spacing size="lg" />
## 9월동안 무슨 일이 있었을까
 
### 1.블로그 배포
첫번째로 기념비적인 블로그 배포가 있었습니다. 배포 전에는 이런 저런 고민이 많았지만 막상 배포하고나니 속이 후련했습니다. 다만 배포 후 미뤄둔 공부를 하느라 생각보다 포스트를 많이 작성하지 못해 아쉬운 마음이 듭니다. 10월 달은 포스팅 작성에 힘써보겠습니다💪
 
### 2.테스트 코드 공부, 근데 이제 CI/CD를 곁들인
블로그 배포 후 가장 먼저 테스트코드 공부를 진행했습니다. 요즘 채용공고를 보면 테스트코드가 필수인 것 같습니다. 이전 회사에서는 테스트코드 작성 문화가 없었어서 많이 쓰인다는 걸 알면서도 좀 미뤄뒀었는데 더이상 미룰 수 없을 것 같아 강의를 들었습니다. 이번에 블로그에도 테스트코드를 작성해보려 했는데 블로그 기능이 단순하기도 하고 아직 어떤 부분을 테스트해야 할지 감이 잡히질 않습니다. 이 부분은 시간을 들여 더 공부를 해봐야 할 것 같습니다. 그리고 cypress로 테스트 자동화를 해보며 엉겁결에 github action으로 CI/CD 세팅도 해보았습니다. 처음 해보는 거라 많이 헤맸지만 자동화를 직접 세팅해 볼 수 있어 즐거웠습니다. 본격적으로 공부해서 제대로 된 시나리오를 적용해보고 싶습니다.
 
### 3.리액트 쿼리 (React Query) 공부
리액트 쿼리는 원래 사용하던 라이브러리였지만 늘 사용하는 기능만 반복적으로 사용해왔어서 깊게 공부하고자 예전에 유데미에서 구매해둔 강의를 보며 전체적인 사용법을 익혔습니다. staleTime과 gcTime의 차이, isFetching과 isLoading의 차이 등 개발하며 크게 신경쓰지 못한 개념들에 대해 다시 정리할 수 있어서 좋았습니다. 에러를 한번에 관리하거나 쿼리를 모두 불러왔는지 확인할 수 있는 등 몰랐던 부분에 대해서도 알게 되어 그저 관성적으로 늘 쓰는 것만 사용해왔구나 싶어서 반성하기도 했습니다. 이번에 배운 내용들도 블로그에 잘 정리해두려합니다.
 
### 4.리액트와 넥스트 최적화 공부
요즘 많이 드는 생각이 내가 과연 2년차의 실력을 가지고 있는가? 입니다. 구현은 어떻게든 할 수 있지만 코드의 최적화까지 고려하며 기간 내에 작업을 할 수 있는가? 라고 스스로에게 물어본다면 자신이 없습니다. 물론 좋은 코드를 작성하기 위해 노력하지만 때론 시간이 부족하다는 이유로, 혹은 지식 부족으로 놓치는 부분도 많은 듯 하여 최적화 관련하여 강의를 들었습니다. 트리쉐이킹, 레이아웃 쉬프트 방지, 병목 코드 제거 하는 방법, 대용량 리스트 다루는 방법 등 몰랐던 부분이나 알고 있지만 잘 적용하지 못했던 부분들을 다시 공부하며 블로그에도 적용해 둘 예정입니다. 
 
## 10월에는 무슨 일을 할까
 
### 해야 하는 것
 
- **최적화 공부 마무리** : 지금 듣고 있는 최적화 강의를 모두 듣고 블로그에 적용해두는 것 까지 마무리 해보려합니다.
- **타입스크립트** : 타입스크립트도 늘 사용하는 것만 사용한다는 생각이 들어 시간 여유가 많을 때 다시 한번 정리해보려 합니다.
- **Node.js** : 최근 유튜브에서 요즘 같은 시대에 개발자는 사이트는 처음부터 끝까지 만들 줄 알아야 한다는 내용의 영상을 보았습니다. 최근 블로그를 만들며 했던 포스팅 데이터와 이미지를 어떻게 관리할 것인가에 대한 고민과도 맞물리기도 하고 백엔드 지식이 있어야 백엔드 개발자분들과 소통을 원활히 할 수 있겠다는 생각이 들어 Node.js로 백엔드의 세계에 살짝 발 담가보려 합니다.
 
### 하고 싶은 것
 
- **웹에 3D 모델 렌더링하기** : 어워드 사이트 [awwwards](https://www.awwwards.com/)를 보면 3D 모델로 멋지게 만들어둔 사이트가 많아 언젠간 꼭 해봐야지 싶었습니다. 만약 포트폴리오 사이트를 만든다면 꼭 3D 모델을 활용해서 만들어보고 싶습니다.
- **CI/CD 공부** : 최근에 CI/CD를 잠깐 맛봤는데 이게 참 재밌더라고요. 지금은 그냥 테스트 자동화만 된 수준이여서 제대로 된 시나리오 적용해서 파이프라인을 구축해보고 싶다는 생각이 들었습니다.
 
## 포스팅을 마무리하며
 
9월은 정말 폐관수련하듯 노트북 붙들고 블로그 만들고 배포하고 글 쓰고, 사놓고 안들었던 강의들과 미뤄왔던 공부하며 열심히 달려온 것 같습니다. 정말 한달이 길게 느껴졌습니다. 그럼에도 여전히 배워야 할 것들과 배우고 싶은 것들이 넘쳐나서 벅차기도 하고 즐겁기도 합니다. 다만 이번에는 강의를 듣는 것에 많이 집중했기 때문에 10월 달에는 그 내용들을 다시 정리하고 적용해보는 시간을 주로 가져보려 합니다. 날이 선선해진 만큼 밖에도 좀 돌아다녀보고요. 그럼 10월도 화이팅해보겠습니다💪

9월 회고

{intro}
<Spacing size="lg" />
## 새로운 도전을 앞두고
 
개발 블로그를 해야겠다는 생각은 몇 년 전부터 계속 하고 있었습니다. 다만 생각만 할 뿐 실천은 못하고 있는 상태였습니다. 그러다 작년 Next.js를 공부하며 만든 블로그를 실제로 운영해보기로 결심했지만 내가 개발 블로그를 할 수 있을까 싶은 망설임과 바빠서 시간이 나지 않는다는 핑계로 블로그는 점점 뒷전이 되었습니다. (블로그 : Remember Me🥹)
 
올해 4월 디즈니 애니메이션 '코코'를 보았습니다. 눈물 버튼으로 유명한 영화여서 '절대 안울어야지' 다짐 했지만 결국 눈물을 흘리며 영화관에서 나와버렸습니다.
코코는 음악이 하고 싶은 소년 미구엘(~~기타치는 검은 머리 소년이 코코죠?~~)과 음악을 극도로 싫어하는 가족들과의 갈등을 풀어나가는 내용으로 당연하게도 미구엘과 가족들을 중심으로 이야기가 진행됩니다. 
 
그런데 영화를 보고나서 가장 기억에 남은 인물은 따로 있었습니다.
 
<YoutubePlayer videoId="ZCwXys58lgs" elementId="youtube" start={271}/>
***"내가 너의 첫번째 청중이 될게."***
 
바로 미구엘이 구두를 닦아주던 악사 아저씨입니다. 광장에서 개최되는 음악 페스티벌에 나갈지 말지 고민하던 미구엘에게 기회를 포착하라는 응원과 함께 자신의 기타를 내어주는 장면이 굉장히 인상 깊었습니다. 위 예고편에 나온 분량이 거의 다일 정도록 짧게 스쳐지나가는 조연 캐릭터가 계속 생각 났던 것은 어쩌면 미구엘처럼 새로운 도전을 망설이는 제가 듣고 싶었던 말을 해주었기 때문일지도 모르겠습니다. 그리고 언젠가는 저도 도전을 시작하는 사람에게 용기를 복돋아 주는 사람이 되고 싶다는 생각이 들었습니다. (하지만 모르는 꼬마 개발자한테 맥북 건네주기는 좀 어려울지도요?👩‍🦲)
어쨌든 지금은 망설이기보단 도전할 때라고 생각합니다.
 
## 창피하지만, 일단 배포합니다.
 
블로그를 만들기 시작하면서 정말 여러 고비가 있었습니다. 특히 블로그 디자인이 꽤나 고역이었습니다. 늘 디자인을 받아서 구현하기만 했지 스스로 디자인 했던 경험은 퍼블리싱을 처음 시작하며 포트폴리오를 만들 때 뿐이었습니다. 어찌저찌 완성했지만 기대를 충족하지 못하는 퀄리티에 명색이 프론트엔드 개발자의 블로그인데 이게 맞나..? 싶었습니다. 그 후 두 세번 정도 갈아엎은 결과물이 현재의 화면입니다. (블로그 화면에 대해 피드백 해주신 분들께 정말 무한 감사를 드리고 싶습니다. 피드백을 통해 블로그가 어떻게 발전했는지 과정도 포스팅할 계획에 있습니다😉) 
그리고 디자인만큼 힘들었던 것이 글쓰기였습니다. 블로그를 하기로 마음 먹으면서 생각해둔 포스팅 주제들이 있었고 그 중 제가 가장 잘 알고 있다고 생각한 '변수'에 대한 글부터 쓰기 시작했습니다. 그러나 머리 속에서 알고 있는 것을 글로 풀어내는 것이 생각보다 쉽진 않았습니다. '이 용어가 맞나?', '이 말은 애매모호한데?', '문장이 어색한 것 같아.', '이미지 자료는 어떻게 만들어야하지?' 정말 글을 한줄 한줄 쓸때마다 온갖 고민과 고뇌가 머리속을 스쳤습니다. '내가 안다고 생각했던 게 사실은 아니었나?', '글 하나 쓰는데 이렇게 시간이 오래 걸리는데 어쩌지.', '이런 글이 도움이 될까?', '누가 보고 비웃으면 어떡하지.' 하는 생각이 들어 자신감도 점점 떨어졌습니다. 
그러다 최근 인프런 CTO이신 향로님께서 블로그에 '창피하지만, 일단 해봅니다'라는 책을 소개하신 걸 보고 바로 도서관에서 책을 빌려왔습니다.
책을 읽으면서 창피함을 느낄까봐 망설이며 실천하지 못한 것이 나만의 경험이 아니었구나 싶었습니다. 가끔은 그저 비슷한 경험을 한 사람의 이야기를 듣는 것 만으로도 용기를 얻게 되는 것 같습니다.
 
>실천하기도 전에 "아직 준비가 덜 되어서"라고 말하는 사람이 있다. 우리 인생에서 '준비가 충분히 된 순간'은 영원히 오지 않는다. 시작하기 전에 '준비는 완벽하다'고 생각할지라도 정말 필요한 것은 대부분 나중에 떠오르는 법이다. **해보지 않은 사람의 준비는 당연히 불충분할 수밖에 없다.**

 
특히 위 구절이 인상 깊었는데요. 저도 '블로그의 디자인이 완벽하지 않아서', '기능 구현이 완벽하지 않아서', '다른 사람이 읽을만한 퀄리티의 글이 아니라서' 라며 완벽한 상태가 아니니 아직 배포할 수 없다고 미루고 있었기 때문에 뜨끔하면서도 '그래, 일단 배포하고 보자.'라는 용기가 생겼습니다. 웹은 배포 후에도 언제든지 수정하고 개선할 수 있으니까요. 게다가 다양한 분들의 피드백을 받을 수 있는 기회가 생기는 것이니 '오히려 좋아'입니다.
그렇기에 지금은 완벽하지 않아도, 창피해도 일단 배포해보려 합니다. 
 
## 어떤 이야기를 해나갈까?
 
블로그를 시작하려 마음 먹은 가장 큰 이유는 배운 지식을 다시 정리하기 위함입니다. 포스트를 작성하며 절실히 느끼게 된 것은 강의를 듣거나 문서를 읽는 것 만으로는 온전한 나의 지식이 되지 않는다는 것입니다. 얼렁 뚱땅 알고 있는 부분도 있고 생각을 글로 풀어내려니 막막하게 느껴지기도 합니다. 아마 완전히 제 것으로 소화하는 과정을 거치지 않았기 때문이겠죠. 지식을 정리하기 위해서 혼자만의 공간에 글을 쓰는 것도 좋지만 블로그를 통해 다른 개발자분들과 함께 소통하고 싶은 마음이 컸습니다. (포스트에 오류나 부족한 내용이 있다면 언제든지 피드백 부탁드려요.) 또 지금은 자바스크립트와 관련된 내용을 정리하는데 집중하고 있지만 추후에는 제가 실제로 프로젝트를 진행하며 겪었던 문제점과 해결 방안을 공유할 예정입니다. 제가 개발을 하며 많은 블로그에 도움을 받아왔던 것 처럼 다른 개발자분들께 도움이 된다면 정말 더할나위 없이 기쁠 것 같습니다.🥰 
 
## 쉬엄 쉬엄 그러나 꾸준히
 
회사에서 일을 할 때 가장 크게 느꼈던 것은 배포는 끝이 아니라 시작이라는 것이였습니다. 개발 완료 후 배포까지 마무리되면 후련한 마음이 들기 마련입니다. (아니면 핫픽스로 인한 두근거림?!🫣) 특히 개발하는 과정에서 큰 고통을 겪었던 프로젝트라면 한동안은 쳐다보고 싶지 않기도 합니다. 하지만 사실은 배포 후 서비스가 사용자들에게 선보여진 그 순간부터가 진짜 시작입니다. 실제로 사용하는 과정에서 이슈는 없는지, 우리가 원하는 대로 사용자가 해당 기능을 잘 사용하고 있는지, 배포 이전과 비교하여 불편함을 겪고 있지 않은지 꾸준히 관찰하고 대응해야 하는 것이 필요합니다. 그리고 개발 영역을 떠나서 서비스가 생명력을 가질 수 있도록 꾸준한 컨텐츠 업데이트도 필수겠죠. 컨텐츠가 업데이트 되지 않는다면 사용자들은 서비스에 대한 흥미를 금방 잃을테니까요.
 
지금 배포하려고 하는 블로그 또한 아직 완전하지 않은 상태로 여전히 개선하고 싶은 부분이 많습니다.
현재는 금전적 비용과 시간이 최대한 들지 않는 방향으로 작업하고 있지만 GA를 통해 사용자 추이를 지켜본 후 클라우드 플랫폼 도입도 고려해 볼 예정입니다.
그 외에 멀티 태그 기능, 검색 기능, 포스트를 시리즈 물로 발행하는 기능 등 타 블로그에서 많이 보이는 기능도 구현하고 싶습니다.
그리고 무엇보다 중요한 것은 꾸준히 포스트를 업로드 하는 것일테죠.
지금은 페이지네이션이 필요 없을 정도로 포스트의 수가 적지만 하루 빨리 페이지네이션이 필요할 날이 오면 좋겠네요. 
 
'전진하다'하다 할 때 進 (나아갈 진)자는 辶(쉬엄 쉬엄 갈 착)자와 隹(작은 새 추)자의 조합으로 만들어진 문자입니다. 제멋대로 해석하자면 나아간다는 것은 '작은 새의 발걸음만큼 쉬엄 쉬엄 걸어가는 것'이 아닐까 싶습니다. 제 블로그도 쉬엄 쉬엄 그러나 꾸준히 업데이트 될 예정이니 많은 관심 부탁드립니다.
 
## 포스팅을 마무리하며
 
블로그 배포 기념 회고를 하려 했는데 꽤나 두서없이 이야기를 늘어놓게 되었습니다.😅 요즘 부쩍 생각이 많아져서 그런 것 같습니다. 여기까지 긴 글 읽어주신 분들의 손발을 펴드리며 이만 마치도록 하겠습니다.👋👋

.css-y59011{position:relative;}.css-y59011::after{content:"";position:absolute;right:0;bottom:0;width:0;height:2px;background-color:var(--color-secondary);-webkit-transition:width 200ms ease-in-out;transition:width 200ms ease-in-out;} UI 라이브러리 제작기

2024 연말결산

9월 회고

블로그를 배포하며

UI 라이브러리 제작기