diff --git a/src/components/patterns/ColorwayShell.stylex.ts b/src/components/patterns/ColorwayShell.stylex.ts
index 913db0b..9476d51 100644
--- a/src/components/patterns/ColorwayShell.stylex.ts
+++ b/src/components/patterns/ColorwayShell.stylex.ts
@@ -8,4 +8,15 @@ export const colorwayShellStyles = stylex.create({
backgroundColor: tokens.color.canvas,
color: tokens.color.ink,
},
+ canvas: {},
+ mint: {
+ backgroundColor: tokens.color.mintCanvas,
+ },
+ clay: {
+ backgroundColor: tokens.color.clayCanvas,
+ },
+ ink: {
+ backgroundColor: tokens.color.inkCanvas,
+ color: tokens.color.inkPrimary,
+ },
});
diff --git a/src/content.config.ts b/src/content.config.ts
new file mode 100644
index 0000000..4646406
--- /dev/null
+++ b/src/content.config.ts
@@ -0,0 +1,45 @@
+import { defineCollection } from "astro:content";
+import { glob } from "astro/loaders";
+import { z } from "astro/zod";
+
+const colorwaySchema = z.enum(["canvas", "mint", "clay", "ink"]);
+
+const articleThemeSchema = z.object({
+ colorway: colorwaySchema.default("canvas"),
+ layout: z.enum(["essay", "gallery", "docs"]).default("essay"),
+ density: z.enum(["compact", "comfortable", "spacious"]).default("comfortable"),
+});
+
+const articles = defineCollection({
+ loader: glob({ base: "./src/content/articles", pattern: "**/*.{md,mdx}" }),
+ schema: z.object({
+ title: z.string(),
+ description: z.string(),
+ pubDate: z.coerce.date(),
+ updatedDate: z.coerce.date().optional(),
+ tags: z.array(z.string()).default([]),
+ draft: z.boolean().default(false),
+ theme: articleThemeSchema.default({
+ colorway: "canvas",
+ layout: "essay",
+ density: "comfortable",
+ }),
+ cover: z.url().optional(),
+ }),
+});
+
+const til = defineCollection({
+ loader: glob({ base: "./src/content/til", pattern: "**/*.{md,mdx}" }),
+ schema: z.object({
+ title: z.string(),
+ summary: z.string(),
+ pubDate: z.coerce.date(),
+ updatedDate: z.coerce.date().optional(),
+ tags: z.array(z.string()).default([]),
+ domains: z.array(z.string()).optional(),
+ visibility: z.enum(["public", "private"]).default("public"),
+ quizRefs: z.array(z.string()).optional(),
+ }),
+});
+
+export const collections = { articles, til };
diff --git a/src/content/articles/design-system/01.md b/src/content/articles/design-system/01.md
new file mode 100644
index 0000000..615a839
--- /dev/null
+++ b/src/content/articles/design-system/01.md
@@ -0,0 +1,245 @@
+---
+title: "[FE쥬니어의 Design System] 01. Personal Design System, Storybook, Vite로 환경 설정하기"
+description: "개인 디자인 시스템 GetIt-UI를 Storybook + Vite + Monorepo로 구축한 기록."
+pubDate: 2022-02-03
+tags: ["design-system", "storybook", "vite", "monorepo"]
+theme:
+ colorway: clay
+ layout: docs
+ density: spacious
+---
+
+> _`Storybook` + `React`로 DesignSystem/ComponentLibrary 만드는 튜토리얼은 이미 블로그, Youtube에 널려있다_
+>
+> _Airbnb, GitHub 등 개발팀에서 만든 `Storybook`은 물론이고, GitHub가 공개된 경우도 있다 *(아래 references 참고)*_
+
+[👉 구현 중인 `GetIt-UI` GitHub 보기](https://github.com/gitgitWi/getit-ui)
+
+## Motivation
+
+- 요즘 차트 컴포넌트 구현을 `Storybook` 기반으로 진행중([zum-stock-line-stories](http://zum-stock-line-stories.surge.sh/))인데, 생각보다 엄청난 생산성 향상을 맛보며 재미를 느낌
+
+ - 별도의 페이지를 구성하지 않아도 컴포넌트 구현 결과를 HMR로 볼 수 있음 (_이건 당연한 거!_)
+ - **_개발자 도구 들어가서 ➡️ 메뉴를 클릭하고 ➡️ 뭔가를 조정해야 하는 수고들을 덜어줌!_**
+ - [Measure & Outline](https://storybook.js.org/docs/react/essentials/measure-and-outline): 컴포넌트 사이즈, 아웃라인 등 확인 가능
+ - [Viewport](https://storybook.js.org/docs/react/essentials/viewport): mobile viewport preset 가능
+ - Docs로 한번에 여러 렌더링 상태 확인 가능
+ - addon 생태계가 활성화되어있음
+ - Jest, Cypress 등 다양한 툴과의 통합
+ - `Storybook`을 따로 빌드, 배포 가능
+
+ - 현재까지 개발 진행상황 공유 가능
+ - 색상, 크기, 데이터값 등 **_속성들을 [`controls`](https://storybook.js.org/docs/react/essentials/controls)로 바꿔서 바로 확인 가능_** 👉 디자이너/기획자와의 보다 빠른 소통 가능할 듯?!
+
+ 
+
+
+
+- 거의 1년째 방치 중인 개인 블로그는 물론이고, **_셋팅만 열심히 했던 개인 프로젝트들_** 빠르게 완성도를 높이기 위해 디자인 시스템을 만들어보자
+
+ - 단기적으로 1년 정도는 **컴포넌트 라이브러리** 구축 위주 방향이 될 듯, 아무래도 디자인/UX에 대한 지식이 없기 때문
+ - 장기 프로젝트로 디자인 시스템으로 발전시켜 나가자
+
+
+
+- 회사 업무에 적용하기 전 다양한 테스트를 위한 도구로 사용할 수 있음
+ - 하고 싶은 거 다하자!!
+ - 얼마전 _`당근마켓 프론트엔드 개발자 라이브 QnA 세션`_ 에서 얻은 인사이트
+ - _회사 코드를 포트폴리오로 사용할 수는 없으니 유사한 구현 내용을 개인 GitHub에 올려놓는 것도 방법이다!_
+
+---
+
+## Design Patterns & Techs I Used
+
+- **Atomic Design Pattern & Monorepo**
+
+ - 기본적으로 컴포넌트 라이브러리이기 때문에, atoms, molecules, organisms 정도까지만 하면 될 듯
+ - 이 단계에 따라 각각의 패키지 구성; `atoms/button`, `atoms/text` 등
+ - 디자인 시스템 중 단일 Repo로 구성하는 경우도 많지만, 추후 `Svelte`, `Solid` 등 다양한 프레임워크/라이브러리 및 `rollup`, `esbuild` 등 다양한 빌드 툴 사용해볼 수 있도록 Monorepo로 구성
+ - `Yarn berry` [PnP 모드](https://yarnpkg.com/features/pnp)에서 [workspace 플러그인 사용](https://github.com/yarnpkg/berry/tree/master/packages/plugin-workspace-tools)
+
+ ```bash
+ getit-ui/
+ ┣ atoms/ # atom packages
+ ┃ ┣ button/
+ ┃ ┃ ┣ src/
+ ┃ ┃ ┣ package.json
+ ┃ ┃ ┣ tsconfig.json
+ ┃ ┃ ┣ tsconfig.node.json
+ ┃ ┃ ┗ vite.config.ts
+ ┃ ┗ text/
+ ┃ ┣ src/
+ ┃ ┣ package.json
+ ┃ ┣ tsconfig.json
+ ┃ ┣ tsconfig.node.json
+ ┃ ┗ vite.config.ts
+ ┣ molecules/ # molecules packages
+ ┣ stories/ # storybook package
+ ┃ ┣ .storybook/
+ ┃ ┃ ┣ main.ts
+ ┃ ┃ ┗ preview.ts
+ ┃ ┣ src/
+ ┃ ┃ ┣ Introduction.stories.mdx
+ ┃ ┃ ┣ react-app-env.d.ts
+ ┃ ┃ ┗ setupTests.ts
+ ┃ ┣ .gitignore
+ ┃ ┣ package.json
+ ┃ ┗ tsconfig.json
+ ┃ # root configs
+ ┣ .editorconfig
+ ┣ .eslintignore
+ ┣ .eslintrc.js
+ ┣ .gitignore
+ ┣ .pnp.cjs
+ ┣ .pnp.loader.mjs
+ ┣ .prettierrc
+ ┣ .yarnrc.yml
+ ┣ Dockerfile.dev
+ ┣ README.md
+ ┣ package.json
+ ┣ tsconfig.components.json
+ ┣ tsconfig.json
+ ┗ yarn.lock
+ ```
+
+
+
+- **`Storybook`**
+
+ - 구현된 컴포넌트들 시각 테스트
+ - 회귀, E2E 등 다양한 테스트, 문서화
+ - 별도의 전용 패키지(`stories`)를 만들어서 실행
+
+
+
+- **`Vite` + `React`**
+
+ - 일단은 `React` 컴포넌트 위주 구성
+ - `Vite` [라이브러리 모드](https://vitejs-kr.github.io/guide/build.html#library-mode)로 빌드
+
+
+
+- **`CSS(SCSS) Module`**
+
+ - 개인적으로 `CSS`를 활용할 때 가장 선호하는 방식
+ - `styled-component`/`emotion` 보다 `CSS` 그 자체를 사용하면서, `JS` 방식으로 `className` 적용을 컨트롤 할 수 있음
+ - [Real-world CSS vs. CSS-in-JS performance comparison](https://pustelto.com/blog/css-vs-css-in-js-perf/); 성능 면에서 `CSS-in-JS`가 좋지 않다는 이야기도..
+ - 특히 이번 대선 차트 구현할 때 이점을 크게 맛보게 되었는데, IE에서 `grid(-ms-grid)`가 생각대로 컨트롤 하기 어렵다는 점 때문에, IE 전용 클래스를 따로 만들어 `userAgent`에 따라 분기처리해 적용함
+
+ ```scss
+ // 모던 브라우저 클래스
+ .line {
+ @extend .line-default;
+ display: grid;
+ grid-template-columns: 13px minmax(36px, auto) minmax(46px, auto);
+ }
+
+ // IE 전용 클래스
+ .line-ie {
+ @extend .line-default;
+ display: -ms-flexbox;
+
+ div {
+ margin-right: 5px;
+ }
+
+ p {
+ width: 47px;
+ }
+ }
+ ```
+
+ ```typescript
+ // line 컴포넌트 (VanillaJS)
+ classNames: [IS_IE ? styles["line-ie"] : styles["line"], ...classNames];
+ // ...
+ ```
+
+---
+
+## _Problem & Solutions_
+
+### `Vite` 라이브러리 모드 빌드 -> 모노레포에서 사용시 `CSS`를 가져오지 않는 문제?
+
+**_Problem_**
+
+- HTML 파일을 생성하는 게 아닌, JS로 컴포넌트 렌더링 로직만 만드는 것
+- 일반적인 페이지를 빌드하는 경우, `Webpack` 등 번들러가 `HTML`에 `link` 태그를 자동삽입하고, 렌더링시 스타일을 반영함
+- 그런데 라이브러리 모드에서 빌드시 JS에 `CSS Module` 클래스명만 가져오고, CSS 파일(`import 'styles.css'`)을 가져오지 않음
+- **_다른 패키지에서 사용시 스타일 적용 안됨_**
+
+ 
+
+
+
+**_Solution_**
+
+- [vite-plugin-css-injected-by-js](https://www.npmjs.com/package/vite-plugin-css-injected-by-js?activeTab=readme) 사용
+
+ - `vite.config.ts`에서 플러그인 추가
+
+ ```javascript
+ import cssInject from "vite-plugin-css-injected-by-js";
+
+ export default defineConfig({
+ plugins: [react(), cssInject()],
+
+ /** 기타 설정 */
+ });
+ ```
+
+ - 빌드시 아래와 같이 `style` 태그 생성 로직을 생성, 빌드된 파일 상단에 삽입
+
+ 
+
+ - 동일 컴포넌트를 여러개 호출하더라도 하나의 `style` 태그만 생성함
+
+ 
+
+ - _근데 이렇게 되면 `CSS-in-JS`를 쓰는 방식과 성능면에서 차이가 없어질 수도 있지 않을까하는 의문이.._
+
+
+
+### Storybook 전용 `stories` 패키지에서 Vite 사용시 빌드 오류
+
+**_Problem_**
+
+- 현재 각각의 컴포넌트 패키지 + `Storybook` 전용 패키지가 있는 상황
+- 컴포넌트 패키지들이 이미 `Vite`를 사용하고 있고, (왠만하면) `Webpack` 보다는 `Vite`가 빌드 타임이 짧기 때문에 [Vite 빌더](https://storybook.js.org/blog/storybook-for-vite/)를 써보려고 시도 함
+- 문제는 `Yarn berry` 환경에서 `Vite` 빌더가 의존성 제대로 못 찾고 빌드가 안됨
+ - ; '22.3.2. 현재 아직 해결되지 않은 이슈😭
+
+**_Solution_**
+
+- 아쉽지만 `stories` 패키지만 빌더를 `CRA` + `Webpack5`로 지정해 사용 중
+- 내 생각에 베스트는, `Storybook` 전용 패키지를 별도로 분리하지 않고, 각각의 컴포넌트 패키지에서 `story` 파일를 만들어서 root에서 preview를 실행하도록 하는 것
+ - 다만 Monorepo 구조의 root에서는 뭔가 설정하기가 까다로움
+ - `Storybook` 자체가 빈 프로젝트에서 실행하는 게 아니기 때문인듯
+ > _Storybook needs to be installed into a project that is already set up with a framework. It will not work on an empty project.()_
+ - _좀더 연구해봐야 할 듯..?_
+ - 한편 패키지를 분리했기 때문에, 다른 패키지에서 `import` 했을 때 잘 되는지 확인 할 수 있다는 장점은 있는 듯
+
+
+
+---
+
+### References
+
+#### Design System Overview
+
+- [토스, 에어비앤비로 알아보는 디자인 시스템의 내일](https://dewberry9.github.io/future-of-design-system)
+- [Do you think your component library is your design system? Think again](https://uxdesign.cc/do-you-think-your-component-library-is-your-design-system-think-again-7e2c902b5275)
+
+#### Real-World Cases
+
+- [awesome-storybook](https://project-awesome.org/lauthieb/awesome-storybook)
+- [awesome-design-systems](https://github.com/alexpate/awesome-design-systems)
+- 쿠팡: [이커머스에 최적화된 디자인 시스템, RDS](https://youtu.be/g4f7p0YcVnc) - 주로 UX 디자인에 대한 이야기
+- 토스
+ - [TDS로 UI 쌓기 : 그 많던 코드는 누가 다 치웠을까?](https://youtu.be/pfKuEuufgdc) - 토스 안드로이드
+ - [Do more, with less. - 디자인 시스템, 그다음은?](https://youtu.be/LmLchZ4tCXc) - 토스 FE
+- 배민: [[6월 우아한테크세미나] 디자인시스템이 가져온 변화](https://youtu.be/aVHLcQzcRbA) - 배민 FE
+- LINE: [개발자와 디자이너의 협업을 위한 LINE 디자인 시스템, LDS 소개](https://engineering.linecorp.com/ko/blog/line-design-system/)
+- SOCAR: [[SOCAR FRAME 만들기 #1] 쏘카의 디자인 시스템 맛보기1~5](https://tech.socarcorp.kr/design/2020/06/23/socar-design-system-01.html)
+- 카카오: [FE개발자의 성장 스토리 03 : 카카오 어드민 UI 컴포넌트를 모노레포로 개발하여 얻은 것들](https://tech.kakao.com/2020/12/03/frontend-growth-03/)
+- AirBnB: [Building (And Re-Building) the Airbnb Design System | Maja Wichrowska & Tae Kim](https://youtu.be/fHQ1WSx41CA) - 2016년 이후 AirBnB에서 React 기반 디자인 시스템을 만들게 된 배경
diff --git a/src/content/articles/from-jekyll-to-nextjs/00.mdx b/src/content/articles/from-jekyll-to-nextjs/00.mdx
new file mode 100644
index 0000000..c923f9c
--- /dev/null
+++ b/src/content/articles/from-jekyll-to-nextjs/00.mdx
@@ -0,0 +1,94 @@
+---
+title: "00. 잘 쓰고 있던 걸 굳이 바꾸는 이유"
+description: "GitHub Pages Jekyll 블로그에서 Next.js + MDX로 옮기기로 한 배경과 로드맵."
+pubDate: 2022-03-01
+tags: ["jekyll", "nextjs", "mdx", "migration"]
+theme:
+ colorway: canvas
+ layout: essay
+ density: comfortable
+---
+
+import Heading from "../../../components/ui/Heading.astro";
+
+## GitHub Pages, `Jekyll` 기반에서 `Next.js` + `MDX`로
+
+00. 잘 쓰고 있던 걸 굳이 바꾸는 이유
+
+
+
+### intro.
+
+작년 2월, 본격 개발에 입문한 지 만 2개월 정도 되어서 `GitHub Pages`라는 걸로 블로그를 만들 수 있다는 걸 알게 되었다.
+
+뭣도 모르고 유튜브 따라, 블로그 따라 헤매면서 어찌어찌 `Jekyll` 기반 블로그를 만들게 되었고..
+처음 한두달은 "이런 게 개발자 블로그지!"라며 교육 받은 거, 멘토링 행사 참여한 거, 생애 첫 코딩 테스트 후기 등등 신나게 올렸다.
+
+
+
+### 문제는
+
+- `Ruby` 기반이어서 레퍼런스를 찾기도 어렵고,
+- 그래서 뭔가 커스텀을 하고 싶어도 하기 어려워지고,
+- 무엇보다 포스팅이 많아질수록 **_컴파일하는 시간이 크게 늘어난다_**
+ - 단순히 글만 올리는게 아니라, 태그별 검색도 넣고, 페이지네이션도 들어가는데,
+ - 이걸 전부 `html`로 만들어버리기 때문에 불필요한 중복이 너무 많아지는 느낌
+
+그래서 한동안은 그냥 티스토리, velog를 사용하거나, Notion에 정리하거나, _~~아예 안하게 되었..~~_
+
+
+
+### 블로그 못 잃어..
+
+최근까지 거의 강의 수강이나 독서를 하면서 Notion에 정리하고 있었다
+
+아무래도 `Markdown` 문법을 지원하고 거기에 이런저런 임베딩도 편하고 공유도 편한 편이라 쓰게 되는 것 같다
+
+한편으로는 구글링으로 뭔가를 검색할 때 나오는 블로그 글들의 수준이..
+
+나까지 굳이 소음을 더 만들어야 하나하는 생각에 블로그를 잘 안하게 되기도 했다
+
+그런데 최근 텔레그램에서 재테크 네임드들이 블로그 좀 하라고 강력 권장하는 글을 많이 보게 되기도 했고,
+
+무엇보다 사내 블로그 스터디를 하게 되면서 좀더 반강제적인(!) 동기가 생기게 되었다
+
+
+
+### 왜 `Next.js` + `MDX` 인가
+
+`Next.js`를 선택하게 된 데는 특별한 이유는 없었고,
+
+요즘 FE 개발한다면 십중팔구는 `React`를 하고, `React`를 하다보면 `Next.js`를 하게 되는, 대유행(?) 시대이기 때문에, 나도 언젠가 다음 개인 프로젝트는 `Next.js`로 해야겠다는 막연한 생각이 있었다
+
+지금 회사에서는 `Vue.js`를 쓰기 때문에 `Nuxt.js`를 쓸 수도 있긴 하겠지만, `Vue.js` 레퍼런스도 그리 많지 않은데 `Nuxt.js` 관련해선 더 없을 것 같기도 하고, `VSCode`에서 타입추론이나 자동완성이 잘 안되는게 답답한 맛도 있기도 하고, Udemy에 결제해 논 `React`, `Next.js` 강좌도 살살 들어야해서 `Next.js`로 가기로 했다
+
+그렇다면 `Jekyll`에서 했던 것처럼 `Markdown` 으로 글을 작성할 수 있는게 `Next.js`에선 뭐가 있을까 검색해보니, `Markdown` 관련 플러그인을 설치하기도 하고, MDX를 사용하기도 하는 것 같았다.
+
+`MDX`는 `Markdown`에 `React` 컴포넌트를 그냥 `import`로 가져와서 붙여넣기만 하면 되는 식이어서 글 쓰기도 편하고, 컴포넌트로 뭔가 커스텀하기도 좋아보였다. 다만 코드(?)가 너무 변태 같다는 것이 조금 어색하긴 하다..
+
+```mdx
+import Text from "../component/Text.tsx";
+
+## 이건 마크다운 헤더
+
+
+```
+
+
+
+### 마지막으로, 앞으로의 로드맵
+
+할게 많구만..
+
+- [ ] 아름다운 컴포넌트 구현 (⭐️⭐️)
+- [ ] custom code syntax hightlight (⭐️)
+- [ ] GitHub 댓글 컴포넌트 붙이기
+- [ ] 사이트 맵 -> 구글 검색 다시 등록하기
+- [ ] RSS 생성
+- [ ] 다른 사이트 임베딩; 노션 북마크, 임베딩 효과 참고..
+ - [ ] Gist나 Codepen, Stackblitz 등 웹 IDE
+ - [ ] Youtube
+- [ ] post 마다 OpenGraph 태그 생성
+ - [ ] 썸네일 자동 생성기..?
+- [ ] 사이트 내 검색 -> 서버리스 SQL 사용??
+- [ ] 개인 포트폴리오 연동
diff --git a/src/content/articles/hello.mdx b/src/content/articles/hello.mdx
new file mode 100644
index 0000000..2aed9e0
--- /dev/null
+++ b/src/content/articles/hello.mdx
@@ -0,0 +1,22 @@
+---
+title: "Hello MDX!"
+description: "Astro Content Collections MDX 스모크 테스트 글입니다."
+pubDate: 2022-01-15
+tags: ["astro", "mdx", "migration"]
+draft: true
+theme:
+ colorway: mint
+ layout: gallery
+ density: comfortable
+cover: "https://user-images.githubusercontent.com/57997672/156254919-f4795507-1ecf-4e88-b8ef-a037ab071169.gif"
+---
+
+import Heading from "../../components/ui/Heading.astro";
+
+
+ Hello MDX!
+
+
+```typescript
+const hello = () => `World!`;
+```
diff --git a/src/content/til/refactoring-javascript/01.mdx b/src/content/til/refactoring-javascript/01.mdx
new file mode 100644
index 0000000..12db315
--- /dev/null
+++ b/src/content/til/refactoring-javascript/01.mdx
@@ -0,0 +1,99 @@
+---
+title: "1. 리팩토링이란?"
+summary: "리팩토링의 정의와 품질 균형"
+pubDate: 2023-06-01
+tags: ["refactoring", "javascript", "study"]
+visibility: public
+---
+
+> 리팩토링은 코드를 변경하는 것이 아니다
+
+- 코드 동작을 바꾸면 안 된다는 것
+- 코드 동작이 변하지 않는다는 것을 어떻게 보장?
+- 코드 동작은 변하지 않으면서 코드를 변경한다는 것은 어떤 의미일까?
+
+## 1.1 코드 동작이 변하지 않는다는 것을 어떻게 보장할 수 있을까?
+
+리팩토링할 때 동작의 모든 유형을 다루는 것이 아닌, 다음 내용을 주로 다룬다
+
+- 구현 세부 사항
+- 불특정하고 검증되지 않은 동작
+- 성능
+
+=> 테스트, 버전 관리를 사용
+
+## 1.2 구현 세부 사항에 관심을 두면 어떨까?
+
+예를 들어, 숫자에 2를 곱하는 간단한 함수를 구현할 때
+
+- `return number * 2`
+- `return number << 1`
+
+이런 부분이 구현 세부 사항
+
+이때 `number` 값이 너무 커지면 두번째 경우는 문제가 발생
+
+-> 테스트 케이스는 처음 생각했던 것보다 더 많은 경우를 포함해야 한다는 것을 의미
+
+- 변경한 구현 세부 사항에서 숫자를 두 배로 한 부분이 우리가 신경 써야 할 동작,
+- 세부 사항 테스트는 대부분 불필요
+
+## 1.3 불특정하고 검증되지 않은 동작에 관심을 두면 어떨까?
+
+실행 테스트, 수동 절차, 어떻게 동작하는지 최소한의 설명이 없으면 기본적으로 해당 코드를 검증할 수 없다는 것을 의미
+
+테스트가 부족한 코드 또는 실행시킬 수 있는 최소한의 문서가 없는 코드는 코드를 변경하기 어렵고, 그러면 동작 변경을 검증할 수 없어 리팩토링하기 어렵다
+
+> 테스트를 거치지 않은 코드는 리팩토링할 수 없다
+
+## 1.4 성능에 관심을 두면 어떨까?
+
+사용자는 성능보다는 동작과 기댓값에 더 중점을 둔다
+
+첫번째 구현에서 결과가 충분히 좋다는 것은 적절한 시간 안에 입력으로 기댓값을 산출할 수 있다는 의미; 비기능적 검증 (nonfunctional testing)
+
+## 1.5 동작이 변하지 않는다면 리팩토링의 요점은?
+
+> 리팩토링의 요점은 행동을 유지하면서 품질을 향상하는 것
+
+## 1.6 품질 균형 잡기와 일 끝마치기
+
+기술부채
+
+- 소규모 프로젝트에서 가시적이고 설명 가능한 기술부채는 어느 정도 허용될 수 있지만,
+- 큰 프로젝트에서는 품질을 중요하게 여기며 진행해야
+
+## 1.7 품질이란 무엇이며 리팩토링과 어떤 관련이 있을까?
+
+코드 품질을 좋게 하려는 수많은 노력들
+
+- SOLID; 단일 책임, 개방 폐쇄, 리스코프 치환, 인터페이스 분리, 의존성 역전
+- DRY; 반복 X
+- KISS; 정말 간단해야
+- GRASP; 일반적인 책임 할당 소프트웨어 패턴
+- YAGNI; 나중에 필요 없어질 것을 고려
+
+명확한 기준은 없다, 다만 제대로 작동하고 쉽게 확장될 수 있는 코드를 만드는 것
+
+코드 테스트를 작성하고 쉽게 테스트할 수 있는 코드를 작성하는 것
+
+- 인터페이스 단순화하기 위해 함수와 모듈 추출
+- 테스트를 이용해 코드 동작 확인
+- 가능하면 불순한 기능 피하기
+- 변수 및 함수 이름 잘 짓기
+
+자신만의 `소프트웨어 품질 원칙`을 구성해보라
+
+## 1.8 탐험으로서 리팩토링
+
+리팩토링은 코딩에 자신감을 갖게 하고 작업 중인 내용을 잘 이해하는 데 도움을 준다
+
+## 1.9 어떤 것이 리팩토링이고 어떤 것이 아닐까?
+
+새로운 코드와 기능을 만드는 것은 리팩토링이 아니다
+
+기존 코드에서 인터페이스(동작)에 대한 변경 사항은 테스트를 중단시키거나, 충분하지 않은 테스트를 하게 할 수 있음
+
+반면 구현 세부 사항을 변경할 때는 테스트가 중단되어서는 안된다
+
+## 1.10 마무리
diff --git a/src/content/til/tdd/fullstack-tdd-by-newbie.mdx b/src/content/til/tdd/fullstack-tdd-by-newbie.mdx
new file mode 100644
index 0000000..e1d24d3
--- /dev/null
+++ b/src/content/til/tdd/fullstack-tdd-by-newbie.mdx
@@ -0,0 +1,104 @@
+---
+title: "TDD 뉴비가 느낀 러닝 커브와 재미"
+summary: "주간회고 — Full-stack TDD 경험 회고"
+pubDate: 2022-01-24
+tags: ["tdd", "testing", "career"]
+visibility: public
+---
+
+- 주간회고 02. TDD 뉴비의 Full-stack(?) TDD 1편
+
+#### 3줄 요약
+
+> - 테스트 코드 뉴비로서 어디서부터 뭘 해야될 지 몰라 막막함을 느끼고, 파일럿 프로젝트 때의 안좋은 추억이 되살아났다
+> - 단순히 툴 사용법이 아니라, 테스트 코드를 작성하는 원칙이 뭔지 좀더 공부하고 정리해보고 싶다
+> - 많은 장점들이 있지만, 무엇보다 테스트 패스할 때의 소소한 즐거움이 제일 큰 장점인 듯
+
+
+
+---
+
+## 테스트 코드 앞에만 서면~ 나는 왜 작아지는가~
+
+
+
+> _지금 보니, 약간 망했다는 얘기를 굉장히 구구절절 쓴 것 같다..._
+
+작년 수습기간 파일럿 프로젝트(`investing.com` 클론, [👉 파일럿 프로젝트 회고](https://zuminternet.github.io/zum-front-investing-clone/)) 초반에 여러가지로 시간을 많이 날렸지만, 그중에서도 가장 허탕을 쳤던 것 중 하나는 TDD로 개발을 해본답시고 1주일을 날린 것이다
+
+1년 반이라는 예상보다 길고 힘들었던 커리어 전환 기간을 거치고 취업한 상태여서 너무 신이 났었는지, **_이것도 해보겠다 저것도 해보겠다 너무 욕심이 많았던_** 것 같기도 하다
+
+`Vue.js`도 처음해보는데 `TDD`를 해보겠다하고, 데이터 업데이트를 실시간으로 해보겠다고 `SSE`를 도입하고, 몇번 써보지도 않은 `MongoDB`에 잘 맞지도 않는 `TypeORM`을 억지로 끼워넣느라 많지도 않은 시간을 삽질하는데 써버렸고, 결국 중간발표까지 요구사항 절반도 못하게 되는 대참사가 벌어졌다
+
+그나마 `SSE`, `TypeORM`은 어떻게든 됐고, `아 이렇게 하는거 아니구나` 하는 걸 깨닫기도 했지만, **_`Frontend TDD`는 결국 시간만 쓰고 혼란스러움만 남긴 채 접게 됐다_**
+
+
+
+그렇게 약 5개월의 시간이 지나고, 차트 서버를 담당하게 되면서 모놀리식 구조에서 모노레포 구조로 바꾸고, 프레임워크를 `Koa.js`에서 `Nest.js`로 변경하는 대공사를 벌이게 된다
+
+내가 바꾼 코드들이 제대로 동작하는지에 대해 수작업으로 확인하는 과정들이 반복됐고, 이 **단순 반복 작업들이 너무 귀찮아지면서 자연스럽게 TDD에 대한 관심으로 흘러갔다**
+
+프로젝트 구조를 모노레포로 바꿀 당시에는 줌투자 2차 오픈 일정이 빡빡하게 돌아가던 중이라, 구조 변경하랴 맵차트 개발하랴 테스트 코드를 넣을 시간이 없었지만, 오픈 이후 조금 여유로워진 상황에서는 TDD 방식으로 프레임워크를 `Nest.js`로 변경할 수 있는 시간이 충분했다
+
+리팩토링 관련 책들을 읽으면서 **테스트 없는 리팩토링은 반쪽짜리 리팩토링이라는 걸 깨달았기 때문에**, 이번에는 TDD를 제대로 해보면서 리팩토링을 하고싶다는 마음이 들었다
+
+문제는, 다시 한번 마주한 ***테스트 코드를 어떻게 짜야하는가에 대한 막막함***이었다
+
+
+
+## 지금 당장 TDD 하고 싶은데, 뭘 어떻게 해야 할까..???
+
+TDD는 `요즘 개발자(?)`라면 당연히(?) 하는 거기도 하고, 워낙 많은 테스트 관련 책과 강의, 블로그, 아티클들이 있기 때문에 공부를 한다면 충분히 할 수 있는 분야인 것 같다
+
+하지만 **당장 프로젝트에 적용해보려고 구글링해보면, 생각보다 볼만한 것들이 많지 않았던 것 같다**
+
+물론 JS 테스트 코드를 짜려고 하면 언제나 나오는 `Jest` 사용법 정도는, 정말 너무 많다 싶을 정도로 자료가 많다
+
+> _이런 라이브러리나 툴 사용법은 필요할 때마다 그때그때 공식문서 위주로 찾아보고, StackOverflow 검색해보고, 그래도 뭔가 부족하다 싶으면 `GitHub`이나 [SourceGraph](https://sourcegraph.com/search), [tabnine](https://www.tabnine.com/code) 오픈 소스 코드 검색으로 예제를 찾아보면 꽤 괜찮은 내용들이 많다_
+
+그러나 당장 프로젝트에 적용하기 위해 찾아보고 싶었던 주제는 이런 툴 사용법이 아닌, **_단위 테스트에선 무엇을 어떻게 테스트해야 하는가, Controller를 테스트하는데 MockService는 왜 만들어야하나 등 원리원칙적인 내용들을 찾고 싶었다_**
+
+파일럿 프로젝트 때 TDD에 실패했던 이유 중 하나는, 컴포넌트 단위 테스트에서 이벤트, api 요청 등 단위 테스트 범위를 벗어나는, e2e 테스트에서 해야 될 것들을 자꾸 하려고 했기 때문이다
+
+다른 하나는 테스트를 할 때 테스트 대상이 아닌 나머지 로직과 데이터를 Mock으로 만들어 제공하는 의미를 알지 못했고, 모든 걸 다 Mock으로 만들어서 제공하면 당연히 성공할 수 밖에 없는거 아닌가 하는 의문 때문에, 테스트 코드를 구현하는 게 의미 없다는 생각이 들었기 때문이다
+
+부족한 구글링 실력 탓도 있겠지만 원하는 결과는 찾기 어려웠고, 차라리 내가 좀더 공부하고 정리해서 공유하는게 낫겠다는 생각이 들었다
+
+올해 안으로 가이드라인을 정리해서, GitBook 이나 간단한 웹으로 만들어 공유해 볼 예정이다
+
+
+
+
+
+
+
+하지만 기왕 쓰는 김에.. 회사 팀원들, 블로그, 유튜브, 강의 등 여기저기서 주워들은 내용들, 그리고 직접 테스트 코드를 구현하며 깨닫게 된 **아주 간단한 원칙**은 이렇다
+
+- 모든 테스트는 주어진 상황/컨텍스트(`given`)에 대해 성공 조건(`when`)-성공 결과(`then`), 실패 조건(`when`)-실패 결과(`then`)를 테스트한다
+
+- 단위 테스트는 함수/클래스 내부 동작이 잘 동작하는지를 테스트하기 때문에, 당연히 나머지 외부에 대해서는 정상 동작한다고 가정한다
+ - Mock 함수, 데이터를 잘 만들어야 하는 이유 👉 이 때문에 그다지 효율적이진 않을 수 있다
+ - 새로운 기능 개발하는 경우엔, Mock 함수/데이터를 만들면서 인터페이스나 추상클래스를 만들수 있기 때문에 설계 측면에선 괜찮을 듯
+
+
+
+- e2e/통합 테스트는 내부 동작보다는 함수/클래스 등 전반적인 기능을 테스트할 수 있다
+ - 말그대로 end-to-end, 사용자 input에 따른 output이 어떻게 나오는지를 테스트
+ - 실제 데이터, api를 가지고 테스트할 수 있음; mock 데이터/함수도 당연히 사용 가능
+ - 리팩토링 등 이미 구현된 기능에 대해 코드 변경이 있는 경우
+
+
+
+## 10년 만에 느껴보는 수학 문제집 푸는 맛(?)
+
+
+
+> _VSCode, IntelliJ 등 에디터에서 테스트 관련 설정을 하면, 굳이 테스트 관련 명령을 하지 않아도 알아서 코드 수정을 반영해 테스트를 실행해준다_
+
+테스트 코드의 장점은 누구나 알다시피, 코드 변경을 하더라도 기능이 잘 작동하는지를 빠르게 확인할 수 있다는 점이다
+
+그것말고도 개인적으로 꽤 괜찮은 side-effect를 느낀 부분은 ***개발자로서 자기 효능감을 느낄 수 있다***는 점이다
+
+학창 시절 수학 문제집을 풀고 채점할 때, 동그라미가 하나씩 늘어날때마다 기분이 좋았던 기억이 있는데, 깔끔하게 통과한 테스트 결과를 보면 왠지 상쾌하고 기분이 좋아지는 듯 하다
+
+개발은 공부하면 할수록 스스로 부족하다고 느낄 때도 많지만, 이렇게 사소하게나마 *`내가 만든 코드가 테스트를 통과했구나`*하는 즐거움을 주는 게 가장 큰 장점이 아닐까 생각이 든다
diff --git a/src/content/til/ts/enum-to-template-literal.mdx b/src/content/til/ts/enum-to-template-literal.mdx
new file mode 100644
index 0000000..1c8df5d
--- /dev/null
+++ b/src/content/til/ts/enum-to-template-literal.mdx
@@ -0,0 +1,236 @@
+---
+title: "[TypeScript] enum -> literal 타입 갈아타기"
+summary: "enum 대신 literal + ReadonlyRecord 패턴 정리"
+pubDate: 2022-01-20
+tags: ["typescript", "enum", "class-validator"]
+visibility: public
+---
+
+### 3줄 요약
+
+> - `enum`은 tree-shaking, memory-leak 문제가 있고, 여러 enum을 하나의 enum으로 합칠 수 없다
+> - `class-validator`에서 `IsEnum`을 쓰려면, 타입이 아닌 객체가 필요하다
+> - `literal`과 `Readonly>` 유틸 타입을 활용해 문제를 해결했다
+
+[👉 hashnode에서 보기](https://wiii.hashnode.dev/enum-to-template-literal)
+
+---
+
+## `enum`은 비싸고 불편하다!
+
+다른 언어들과 마찬가지로 `TypeScript`도 열거형 타입으로 [`enum`](https://www.typescriptlang.org/ko/docs/handbook/enums.html)을 제공한다
+
+함수 인자로 특정 string만 들어와야 하는 경우 등 유용하게 쓸 수 있다
+
+
+
+### Tree-shaking, 메모리 문제
+
+그러나 Line 기술 블로그(['TypeScript enum을 사용하지 않는 게 좋은 이유를 Tree-shaking 관점에서 소개합니다.'](https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking/))에서 잘 설명하는 것처럼, 순진한 enum 타입은 tree-shaking이 안되고 메모리 낭비까지 이어질 수 있다.
+
+
+
+### 예상과는 다른 Type Union
+
+무엇보다 개인적으로 가장 불편하게 느껴지는 것은 다른 타입들과는 다르게, **_enum은 `union`으로 여러 enum을 하나로 합칠 수 없다는 점이다_**
+
+아래 예시 코드는 실무에서 구현 중인 API 타입 일부를 조금 수정해서 가져온 것이고, 전형적인 enum을 가져왔다
+
+```typescript
+enum PeriodA {
+ DAILY = "DAILY",
+ MONTHLY = "MONTHLY",
+}
+
+enum PeriodCommon {
+ WEEKLY = "WEEKLY",
+ QUARTERLY = "QUARTERLY",
+ YEARLY = "YEARLY",
+}
+```
+
+[Union Type](https://www.typescriptlang.org/ko/docs/handbook/2/everyday-types.html#%EC%9C%A0%EB%8B%88%EC%96%B8-%ED%83%80%EC%9E%85)을 쓰는 대부분은 아래처럼 A 타입 일수도 있고, B 타입일 수도 있을 때이다
+
+```typescript
+type StringOrNumber = string | number;
+
+const strOrNumberLogger = (what: StringOrNumber) => console.log(what);
+strOrNumberLogger("asdf");
+strOrNumberLogger(123123);
+```
+
+
+
+**_그러나 이 넘의 enum은 그렇지 않다_**
+
+`PeriodA`와 `PeriodCommon`를 합친 `Periods`라는 enum을 만들고 싶지만 그 과정은 쉽지 않다
+
+아래처럼 타입 Union을 하면 당장은 에러가 나진 않지만, 실질적으로는 사용할 수 없는 타입이 된다
+
+```typescript
+type Periods = PeriodA | PeriodCommon;
+
+const periodLogger = (period: Periods) => console.log(period);
+periodLogger("DAILY"); // error
+```
+
+
+
+Intersection은 더더욱 안된다
+
+둘 사이에 공통점이 없기 때문에 **`never`** 타입이 된다
+
+```typescript
+type Periods = PeriodA & PeriodCommon; // -> never
+
+const periodLogger = (period: Periods) => console.log(period);
+periodLogger("DAILY"); // error
+```
+
+
+
+타입 assertion으로 에러를 안낼 수는 있는데..***아무 의미 없는 타입 선언***이 되어 버린다
+
+
+
+
+
+---
+
+## `class-validator`의 `IsEnum`을 쓰려면 객체가 필요하다!
+
+가장 속 편한건 단순히 `literal`'만' 쓰는 거다
+
+토스 기술 블로그 [Template Literal Types로 타입 안전하게 코딩하기](https://toss.tech/article/template-literal-types)에서 소개하는 것처럼,
+
+TypeScript에는 문자열을 가지고 다양한 타입을 만들어 낼 수 있는 재미있는(?) 기능이 있다
+
+
+
+다만 위에서 예시로 가져온 `Periods`는 단순히 함수 인자의 타입만 추론하는데 쓰는 것이 아니라,
+
+아래와 같이 **[`class-validator`](https://github.com/typestack/class-validator)를 활용해 API 요청 유효성 검사**에도 사용될 수 있어야했다
+
+```typescript
+export class GetChartDto {
+ @IsNotEmpty()
+ @IsEnum(Periods)
+ period: PeriodNames;
+}
+```
+
+
+
+당연한 거지만, 아래와 같이 type을 함수 인자로 넣을 수는 없다
+
+
+
+
+
+위 라인 블로그에서 가장 추천하는 방법은 객체를 가지고 Union 타입을 만드는 것이다
+
+enum으로 union 만들 방법을 구글링(`'typescript enum union'`)하면 나에게 가장 먼저 뜨는 글인
+
+정규현님의 [enum type 대신 union type으로 변경하기](https://ajdkfl6445.gitbook.io/study/typescript/enum-type-union-type)에서도 그 방식을 개선하여 사용한 경험을 보여주고 있다
+
+여기서 핵심은 아래와 같다
+
+```typescript
+const READONLY_객체 = 객체 as const;
+type enumLike = keyof READONLY_객체[keyof typeof READONLY_객체];
+```
+
+짧고 유용한 코드지만, 부족한 나에게는 이게 뭘 의미하는지 한번에 파악하기가 조금 어렵다고 느껴졌다
+
+다만 `Readonly` 타입을 사용한다는 점에서 힌트를 얻을 수 있었다
+
+_(이게 꼭 필요한 건지는 아직 테스트를 안해봤다...)_
+
+
+
+## _(적어도 나에게는)_ 좀더 편한 방법!
+
+결론은 아래와 같다
+
+```typescript
+// periods.ts
+type ReadonlyRecord = Readonly>;
+
+export type PeriodANames = "DAILY" | "MONTHLY";
+export const PeriodA: ReadonlyRecord = {
+ DAILY: "DAILY",
+ MONTHLY: "MONTHLY",
+};
+
+type PeriodCommonNames = "WEEKLY" | "QUARTERLY" | "YEARLY";
+const PeriodCommon: ReadonlyRecord = {/** */};
+
+export type PeriodNames = PeriodANames | PeriodCommonNames;
+export const Periods = { ...PeriodA, ...PeriodCommon };
+```
+
+
+
+### 커스텀 유틸 타입 `ReadonlyRecord`
+
+이 부분은 반드시 필요한 부분은 아니고, 개인적으로 객체를 `Reaonly`로 만드는 경우가 많아 따로 선언했다
+
+실무 코드에서는 좀더 편한 코딩을 위해 끼를 부려서 아래와 같이 선언했다
+
+객체 `key`, `value`가 모두 `string`인 경우에는 기본값 덕분에 제네릭을 생략할 수 있고,
+
+`string`은 아니지만 `key`, `value`가 동일한 타입인 경우는 하나만 적어주면 된다
+
+```typescript
+export type ReadonlyRecord
+