diff --git a/_posts/DesignSystem/ds-2.md b/_posts/DesignSystem/ds-2.md
new file mode 100644
index 0000000..96f2a90
--- /dev/null
+++ b/_posts/DesignSystem/ds-2.md
@@ -0,0 +1,81 @@
+---
+title: "사내 디자인 시스템 구축기 회고: 도입제안부터 사용후기 까지"
+excerpt: "디자인 시스템 구축하면서 들었던 생각과 교훈정리"
+coverImage: "/assets/blog/posts/DesignSystem/ds-2/cover.png"
+date: "2025-12-17T08:35:00"
+ogImage:
+  url: "/assets/blog/posts/DesignSystem/ds-2/cover.png"
+---
+
+> 이 글은 사내 디자인 시스템 도입 제안부터 구축, 그리고 실제 프로젝트 적용까지의 전 과정을 회고한 글입니다.
+
+## 들어가며
+
+안녕하세요! YD-Tech 개발자 김영덕입니다.
+ 
+
+지난 1개월간 달려왔던 사내 디자인 시스템 구축을 마치고, 디자인 시스템의 효용성과 실사용을 측정해보기 위해 새로운 프로젝트는 제가 구축한 UI 라이브러리로 진행했습니다.
+ 
+
+따끈따끈한 생각들이 드는 지금 이 시점에, 어떠한 우여곡절들이 있었는지 회고글을 써보겠습니다.
+
+## 왜 디자인 시스템이 필요했는지
+
+우리 회사는 어느 정도 업력이 된 회사이기 때문에 레거시 프로그램도 많이 쌓여있고, 테크 스택 전환을 점진적으로 진행하고 있는 상황입니다. 그렇기에 앞으로의 상황을 대비하기 위해서는 지지 기반을 견고하게 다지는 것이 중요하다고 생각했습니다.
+ 
+
+마침 사내에서 개발 업무 시간을 최적화하기 위한 임직원 간 회의가 열렸고, 저는 디자인 시스템 도입을 통해 개발팀과 디자인팀 간의 업무 효율을 개선시키겠다고 제안했습니다. 대표님께서 긍정적으로 생각해주셔서 디자인 시스템 도입 PPT발표부터 시작하여 약 1개월 동안 파운데이션과 기존 레퍼런스들을 기반으로 약 30개의 컴포넌트를 주도적으로 만들었습니다.
+ 
+
+그런데 실사용에 들어가니 제가 만든 라이브러리임에도 불구하고 순간순간 학습 곡선이 필요했습니다. 단순하게는 "모달 쓰려면 문법을 어떻게 쓰더라?"부터 "이 컴포넌트로 이 화면을 만들려면 어떻게 조립해야 하지?"라는 고민도 생겼습니다.
+ 
+
+다른 팀원들이 볼 때는 학습 곡선이 더 높겠다고 생각하여, Storybook만으로 문서화를 제공하려 했던 초기 계획을 보완하게 되었습니다.
+
+## 개발자를 위한 저렴한 문서화
+
+개발자들을 위한 문서화가 필요하다는 생각은 들었지만, 실제 문서화를 위해 또 다른 개발을 해야한다면 이것 또한 관리 비용이 되겠다는 생각이 들었습니다. 그래서 저렴한 비용으로 문서화를 할 수 있는 방법이 있지 않을까 생각하여 문서화를 손쉽게 할 수 있는 툴을 찾아보았습니다.
+ 
+
+소스코드는 Vite 기반으로 구축되어 있었기 때문에 호환성이 제일 좋을 것이라 판단하여 큰 고민 없이 VitePress라는 툴을 채택 하게 되었습니다.
+ 
+
+Vitepress 덕분에 마크다운 작성만으로 깔끔한 문서 사이트를 자동으로 제공할 수 있어서, 문서화에만 집중할 수 있었습니다. 실제로 디자인팀이 몰라도 되는 영역들(배포 방법, 개발 가이드, 컨벤션, 코드 관련 주의사항 등)을 자세히 작성해줄 수 있었습니다.
+
+## 이 또한 거시적인 알고리즘
+
+갑자기 뜬금없는 이야긴데요. 알고리즘 문제를 풀다 보면 반복이 나올 경우 DP나 특정 연산 등을 통해 불필요한 연산을 메모이제이션하고 최적화하여 시간 복잡도를 줄이는 방법이 있습니다.
+ 
+
+디자인 시스템 또한 업무 플로우상의 불필요한 반복을 찾아 파편화된 리소스들을 한곳에 집중시켜서 업무 리소스를 줄이고 고도화해가는 과정이라고 생각하니, "이 또한 거시적인 알고리즘이 아닐까?"라는 생각이 들었습니다.
+ 
+
+디자인 시스템을 만들면서 개발자와 사용자 모두를 위한 코어 시스템을 만드는 것에 대한 흥미가 더 생긴 것 같습니다.
+
+## 잘게 쪼개서 조립하자
+
+저는 맨 처음 컴포넌트를 설계할 때 import 하나만으로 모든 것을 해결해보고자 n개의 컴포넌트가 종합적으로 제공되거나 특정 상황을 한번에 해결해주는 컴포넌트를 만들어보려고 했습니다.
+ 
+
+예를 들어, 체크박스 컴포넌트의 경우 무조건 여러 개 중에서 하나를 선택해야 하는 형태로 제작했습니다. 이렇게 만들면 사용자가 한 번의 import로 체크박스 그룹을 쉽게 사용할 수 있을 것이라고 생각했기 때문입니다.
+ 
+
+하지만 실사용에 들어가면서 문제가 발생했습니다. 하나의 체크박스만 필요한 상황에서는 대응할 수 없었고 "전체 선택" 체크박스가 있고 그 아래에 여러 개의 항목 체크박스가 있을 때, 일부만 선택된 상태를 나타내는 intermediate 상태가 필요한데, 제가 만든 컴포넌트로는 이런 상황을 처리할 수 없었습니다.
+ 
+
+이 경험을 통해 유연하게 시스템을 제공하기 위해서는 잘게 쪼개서 조립해야 한다는 깨달음을 얻었습니다. 종합적인 컴포넌트보다는 원자적 컴포넌트를 만들고, 이를 조립하는 방식으로 접근해야 다양한 상황에 대응할 수 있다는 것을 깨달았습니다. ~~UI라이브러리들이 왜 저처럼 개발을 안했는지 깨달았습니다.~~
+ 
+
+이렇게 하니 같은 컴포넌트로도 다양한 화면을 만들 수 있게 되었고, 예상치 못한 요구사항이 들어와도 유연하게 대응할 수 있게 되었습니다.
+
+## CURSOR를 더 똑똑하게 소스코드를 더 유지보수하기 쉽게 만들었다
+
+디자인 시스템기반으로 신규 프로젝트를 만들면서 느꼈던 체감은 CURSOR가 더 똑똑하게 소스코드를 만들어 준다는 것과 소스코드 유지보수가 더 쉬워졌다는 것이었습니다.
+
+CURSOR에게 화면을 만들때 입력하는 요구사항 중 컴포넌트(Dropdown, Table, Checkbox)는 이렇게 구현해야해 같은 요구사항을 덜어낸 채로 중요한 도메인 로직들만 설명하면 되니 CURSOR의 산출물이 더 좋게 나오는 것 같았습니다.
+
+마찬가지로 디자인 시스템의 컴포넌트를 누가 작성하던 동일한 방법으로 사용하게 되므로 유지보수시에 컴포넌트에 대한 구현로직을 자세히 살펴볼 필요가 없게 되었고 획일화된 방식으로 소스코드가 구현되었습니다.
+
+## AI를 결합한 진화 방향
+
+사내에 구축한 디자인 시스템을 운영하면서 앞으로 어떻게 개선 시켜 나갈 수 있을까에 대한 생각을 해보았습니다. 최근에 우아콘에서 들었던 MCP를 탑재한 디자인시스템 이야기처럼 자체적으로 MCP를 구축하여 맥락을 MCP를 통해 전달해 줄 수 있다면 더 높은 수준의 생산성을 기대 해 볼 수 있을것 같습니다.
diff --git a/public/assets/blog/posts/DesignSystem/ds-2/cover.png b/public/assets/blog/posts/DesignSystem/ds-2/cover.png
new file mode 100644
index 0000000..6f1e13d
Binary files /dev/null and b/public/assets/blog/posts/DesignSystem/ds-2/cover.png differ