+ );
+}
diff --git a/src/entities/index.ts b/src/entities/index.ts
index e69de29..336abe1 100644
--- a/src/entities/index.ts
+++ b/src/entities/index.ts
@@ -0,0 +1 @@
+export * from './post';
diff --git a/src/entities/post/index.ts b/src/entities/post/index.ts
new file mode 100644
index 0000000..c5cfa70
--- /dev/null
+++ b/src/entities/post/index.ts
@@ -0,0 +1 @@
+export * from './post.type';
diff --git a/src/entities/post/post.type.ts b/src/entities/post/post.type.ts
new file mode 100644
index 0000000..0e3489b
--- /dev/null
+++ b/src/entities/post/post.type.ts
@@ -0,0 +1,21 @@
+// 기본 게시글 정보
+export type PostBase = {
+ category: string;
+ title: string;
+ description: string;
+ date: string;
+ content: string;
+ thumbnail?: string;
+};
+
+// 컨텐츠 섹션에 필요한 정보만
+export type PostContent = Pick;
+
+// 헤더 섹션에 필요한 정보만
+export type PostHeader = Pick<
+ PostBase,
+ 'category' | 'title' | 'description' | 'date'
+>;
+
+// 메타데이터만 (content 제외)
+export type PostMeta = Omit;
diff --git a/src/features/index.ts b/src/features/index.ts
index e69de29..336abe1 100644
--- a/src/features/index.ts
+++ b/src/features/index.ts
@@ -0,0 +1 @@
+export * from './post';
diff --git a/src/features/post/contents/dom-api.mdx b/src/features/post/contents/dom-api.mdx
new file mode 100644
index 0000000..5481a12
--- /dev/null
+++ b/src/features/post/contents/dom-api.mdx
@@ -0,0 +1,127 @@
+---
+title: 'DOM 조작하기'
+category: 'Develop'
+date: '2025-10-12'
+description: 'DOM과 DOM API를 이해하고, 자바스크립트로 웹 요소를 조작하는 방법을 알아보자!'
+---
+
+# 📌 DOM 이란?
+
+DOM이란 Document Object Model 문서 객체 모델로, HTML로 작성된 여러 요소들에 Javascript가 접근할 수 있도록 브라우저가 변환시킨 객체이다.
+
+쉽게 말해 브라우저입장에서 우리가 작성한 HTML을 Javascript가 이해하고 조작할 수 있도록 **객체로 변환**한 것이다.
+
+웹 부라우저는 이 HTML 문서를 불러온 이후, 상하 관계를 한 눈에 볼 수 있는 트리 구조로 나타내는데, 이를 **DOM Tree** 라고 한다.
+
+
+
+# 📌 DOM API 란?
+
+DOM이란 HTML로 작성된 여러 요소들에 Javascript 가 접근할 수 있도록 브라우저가 변환시킨 객체이고, Javascript는 이러한 DOM을 통해 HTML로 짜여진 요소들을 생성, 수정, 삭제할 수 있다.
+
+또한 DOM은 Javascript 가 자신에게 접근하여 DOM을 조작하고 수정할 수 있는 방법인 DOM API를 제공하기 때문에 Javascript 는 이를 활용해 웹 요소들을 생성하고 수정하고 삭제할 수 있다.
+
+DOM 요소를 조작하는 과정은 항상 3단계를 거친다.
+
+1. **찾기(Selection)**: 조작하고 싶은 HTML 요소를 찾는다.
+2. **선택(Targeting)**: 찾은 요소를 변수에 담아 선택한다.
+3. **조작(Manipulation)**: 선택한 요소의 속성, 내용, 스타일 등을 변경한다.
+
+## 🍀 원하는 요소 찾기 및 선택방법
+
+DOM API를 사용해 요소를 찾을 때는, 항상 모든 것의 시작점인 `document` 객체에서부터 시작한다.
+
+### 단일 요소 선택 (하나만 찾기)
+
+- **`document.getElementById('id이름')`**
+ - 가장 빠르고 고전적인 방법. 고유한 `id` 속성 값으로 요소를 찾는다.
+ - `id`는 문서에서 유일해야 하므로, 항상 하나의 요소만 반환한다.
+ ```tsx
+ // id가 "color"인 요소를 찾아서 $color 변수에 담는다.
+ const $color = document.getElementById('color');
+ console.log($color); //
...
+ ```
+- **`document.querySelector('CSS 선택자')`**
+
+ - `id`, `class`, `태그 이름` 등 **CSS 선택자 문법**을 그대로 사용해서 요소를 찾는다.
+ - 조건을 만족하는 요소가 여러 개라도, **가장 첫 번째 요소 하나만** 반환한다.
+
+ ```jsx
+ // class가 "animal-info"인 div 요소를 찾는다.
+ const $animalInfo = document.querySelector('div.animal-info');
+
+ // id가 "age"인 div 요소를 찾는다.
+ const $age = document.querySelector('div#age');
+ ```
+
+### 여러 요소 선택 (조건에 맞는 것 모두 찾기)
+
+**`document.querySelectorAll('CSS 선택자')`**
+
+- `querySelector`와 문법은 같지만, 조건을 만족하는 **모든 요소를 `NodeList`라는 배열과 유사한 객체**에 담아 반환한다.
+
+**`document.getElementsByClassName('클래스이름')`**
+
+- 주어진 `class` 이름을 가진 모든 요소를 `HTMLCollection`에 담아 반환한다.
+
+**`document.getElementsByTagName('태그이름')`**
+
+- 주어진 `태그 이름`(예: 'div', 'p')을 가진 모든 요소를 `HTMLCollection`에 담아 반환한다.
+
+```jsx
+// class가 "info-item"인 모든 div 요소를 찾는다.
+const $infoItems = document.querySelectorAll('div.info-item');
+console.log($infoItems); // NodeList [div, div, div]
+```
+
+### 요소 조작하기: 찾은 요소 변신시키기
+
+원하는 요소를 성공적으로 선택했다면, 이제 그 요소의 다양한 속성을 변경할 수 있다.
+
+**`element.className`** / **`element.id`**
+
+- 선택한 요소의 `class`나 `id` 속성 값을 **통째로 바꾸거나** 읽어온다.
+
+```jsx
+const $name = document.getElementById('name');
+$name.className = 'dog-name'; // class를 'dog-name'으로 변경
+console.log($name.className); // "dog-name"
+```
+
+**`element.classList`**
+
+- `className`보다 더 편리하게 클래스를 조작할 수 있는 메서드를 제공한다.
+ - **.add('클래스')**: 클래스를 추가한다.
+ - **.remove('클래스')**: 클래스를 제거한다.
+ - **.toggle('클래스')**: 클래스가 있으면 제거하고, 없으면 추가한다.
+
+```jsx
+const $color = document.getElementById('color');
+$color.classList.add('dog-color'); // 'dog-color' 클래스 추가
+$color.classList.remove('info-item'); // 'info-item' 클래스 제거
+```
+
+**`element.textContent`**
+
+- 요소 내부의 **텍스트 내용**을 바꾸거나 읽어온다.
+
+```jsx
+const $age = document.getElementById('age');
+$age.textContent = '5살'; // 텍스트를 '5살'로 변경
+```
+
+**`element.style`**
+
+- 요소의 인라인 스타일을 직접 조작할 수 있다. CSS 속성 이름은 카멜 케이스(`camelCase`)로 작성해야 한다. (예: `font-size` → `fontSize`)
+
+```jsx
+const $color = document.getElementById('color');
+$color.style.color = 'blue';
+$color.style.fontSize = '30px';
+```
+
+### 자료 출처
+
+[한 번에 끝내는 자바스크립트: 바닐라 자바스크립트로 SPA 개발까지](https://inf.run/A4YY7)
+
+[DOM과 DOM API](https://velog.io/@hbin12212/DOM-API-1)
diff --git a/src/features/post/contents/next.js-render.mdx b/src/features/post/contents/next.js-render.mdx
new file mode 100644
index 0000000..019b267
--- /dev/null
+++ b/src/features/post/contents/next.js-render.mdx
@@ -0,0 +1,99 @@
+---
+title: 'Next.js 의 렌더링 방식'
+category: 'Develop'
+date: '2025-10-25'
+description:
+ 'Next.js의 다양한 렌더링 방식을 이해하고, 각 방식의 장단점과 사용 사례를
+ 알아보자!'
+thumbnail: '/images/next.js-render.webp'
+---
+
+# SSR의 한계와 SSG의 등장
+
+SSR에서는 브라우저가 접속 요청을 할 때마다 Next.js 서버가 사전 렌더링을 진행하고
+새롭게 생성한 페이지를 브라우저에 전달한다.
+
+## SSR로 동작하는 Next.js의 페이지 렌더링 과정
+
+
+
+접속요청이 들어올 때마다 SSR은 **새 페이지를 생성하므로 최신 데이터를 보장하는
+장점**이 있다. 그러나 사전 렌더링 과정에서 **데이터 페칭이 지연되면 전체
+페이지의 응답 속도가 느려질 수 있다**.
+
+## SSG의 등장
+
+사전 렌더링의 데이터 페칭 과정에서 백엔드 서버의 상태나 네트워크 장애 등으로
+인해 페이지 생성이 지연될 가능성은 언제나 존재한다. 이 문제를 해결하기 위해
+Next.js는 오래 걸릴 수 있는 사전 렌더링을 프로젝트 가동 전, 즉 **빌드 타임에
+미리 수행하도록 설정**하는 또 다른 사전 렌더링 방식을 제공한다. 이 방식을
+**정적사이트 생성(Static Site Generation, SSG)**이라고 한다.
+
+
+
+위 그림처럼 프로젝트의 빌드 타임에 미리 사전 렌더링을 진행한다. 프로젝트가
+가동되고 접속 요청이 발생하면 미리 생성해 둔 페이지로 지연 없이 바로 응답한다.
+
+대신 빌드 타임 이후에는 페이지를 다시 생성하지 않는다. 따라서 나중에 페이지의
+데이터가 업데이트 되어도 이를 반영하지 않는다. 결국 SSG는 페이지를 빌드 타임에
+미리 생성하므로 페이지의 데이터가 다소 정적인 데이터일 때 적합한 방식이다.
+
+# SSG의 한계점과 ISR의 등장
+
+## SSG 방식의 한계점
+
+SSG 방식은 빌드 타임에 사전 렌더링을 미리 진행해 정적 페이지를 생성하고 서버에
+저장한다. 따라서 사용자의 접속 요청일 들어오면 생성한 정적 페이지로 빠르게
+응답하는 식으로 동작한다.
+
+SSG를 이용하면 브라우저의 페이지 요청에 빠르게 응답할 수 있어 사용자의 서비스
+만족도를 크게 높일 수 있다. 반면에 빌드 타임 이후에는 페이지를 다시 생성하지
+않으므로 최신 데이터를 반영하는 데 어려움이 있다.
+
+따라서 **데이터가 빈번하게 변하는 페이지라면 SSG를 사용하기 어렵다**. 빠른 응답
+속도를 포기하는 것이 아쉽지만, 최신 데이터를 반영하는 일이 더 중요하므로 이
+상황에서는 대체로 SSR을 사용한다. 그러나 SSR도 완벽한 해결책이라 보기는 어렵다.
+
+SSR은 요청할 때마다 페이지를 새로 생성하므로 **서버의 부하가 커지고 데이터의
+페칭 속도나 네트워크 상태에 따라 페이지의 응답이 느려질 수 있다**. 결국 SSG와
+SSR 모두 응답 속도와 최신 데이터 반영 중 하나는 포기해야 하는 상황이다.
+
+## ISR의 등장
+
+새로운 사전 렌더링 방식인 **증분 정적 재생성(Incremental Static Regeneration,
+ISR)**을 활용하면 **빠른 응답 속도와 최신 데이터 반영**이라는 두 마리 토끼를
+모두 잡을 수 있다. ISR)**을 활용하면 **빠른 응답 속도와 최신 데이터
+반영\*\*이라는 두 마리 토끼를 모두 잡을 수 있다.
+
+ISR은 SSG로 빌드 타임에 생성한 정적 페이지를 일정 주기마다 다시 생성해 최신
+데이터를 반영하는 방식이다. 특정 시간이 지나기 전까지는 SSG처럼 미리 생성한
+페이지로 빠르게 응답하고 설정 시간이 지나면 Next.js 서버가 백그라운드에서 해당
+페이지를 다시 생성해 최신 데이터를 반영한다.
+
+
+
+여기서 주의할점은 **설정 시간이 지난 다음에 들어온 첫 번째 요청에서 바로
+페이지를 생성해 응답하는 것이 아니라는 점**이다. 대신 이미 생성된 페이지로
+빠르게 응답함과 동시에 한편에서는 백그라운드에서 최신 데이터를 반영해 다시
+페이지를 생성한다. 이렇게 동작하는 까닭은 사용자가 페이지를 아무 때나
+요청하더라도 언제든지 정적 페이지로 빠르게 응답하기 위함이다.
+
+결론적으로 특정 페이지의 데이터 변경이 매우 빈번하게, 예컨대 초 단위로
+이루어지는 특별한 서비스 상황이 아니라면 ISR을 이용하는 편이 좋다. 빠른 응답
+속도와 최신 데이터라는 두 가지 요구를 모두 만족시킬 수 있기 때문이다.
+
+# 사전 렌더링 방식 최종 정리
+
+| 렌더링 방식 | 특징 | 장점 | 단점 | 사용 예시 |
+| ----------- | ------------------- | ------------- | ---------------- | ----------------------- |
+| SSR | 요청 시 생성 | 실시간 데이터 | 느려질 수 있음 | 마이페이지, 결제 페이지 |
+| SSG | 빌드 시 생성 | 압도적인 속도 | 데이터 고정 | 블로그 글, 회사 소개 |
+| ISR | 빌드 후 주기적 생성 | 속도 + 최신성 | 아주 약간의 지연 | 뉴스, 상품 목록, 게시판 |
+
+사전 렌더링 방식마다 고유한 특징과 장단점이 있어 어떤 방식을 선택하는 것이
+옳은지 ‘정답’은 없다. 페이지의 성격, 데이터의 변동성, 성능 요구 사항, 사용자
+경험 등을 종합적으로 고려해 상황에 맞는 방식을 선택하는 것이 중요하다.
+
+### 참고 자료
+
+한 입 크기로 잘라먹는 Next.js 도서
diff --git a/src/features/post/contents/tech-spec.mdx b/src/features/post/contents/tech-spec.mdx
new file mode 100644
index 0000000..896449d
--- /dev/null
+++ b/src/features/post/contents/tech-spec.mdx
@@ -0,0 +1,152 @@
+---
+title: '테크 스펙으로 개발 문서 초안 작성하기'
+category: 'Develop'
+date: '2025-10-25'
+description: '뱅크샐러드에서 제안하는 테크 스펙에 대해서 알아보자!'
+thumbnail: '/images/tech-spec-thumbnail.webp'
+---
+
+# 배경
+
+새로운 프로젝트를 시작하기에 앞서, 어떤 식으로 프로젝트를 이어나가야 할지 방향을
+정하기 위해 문서를 찾아보았다. 그러던 중 뱅크샐러드에서 제안하는 "테크 스펙"
+이라는 문서를 발견하게 되었다.
+
+테크 스펙은 프로젝트의 기능을 어떻게 구현할지에 대해 기술적으로 설명하고,
+팀원들에게 제안하는 문서라고 한다. 이 문서에서는 테크 스펙이 무엇인지, 어떤
+내용이 포함되는지에 대해 정리해보았다.
+
+# 테크 스펙?
+
+## 🤔 테크 스펙이 뭔데?
+
+[뱅크샐러드의 테크스펙](https://blog.banksalad.com/tech/we-work-by-tech-spec/)
+설명하기에 앞서, 뱅크샐러드 블로그에서 작성한 테크스펙 글을 바탕으로 작성함을
+밝힌다!
+
+테크스펙은 이름 그대로 기술(Tech)와 설명서(Spec)을 합친 것이다. 프로젝트에 대해
+설계를 진행할 때, 어떤 기능을 어떻게 구현할건지에 대해 기술적으로 풀어 설명하고,
+다른 팀원들에게 제안하는 문서다. 보통은 기능에 대한 기획을 진행하고, 바로 개발에
+들어가는 방식을 선택한다. 하지만 테크 스펙을 작성하게 될 경우 프로젝트에 사용될
+기능에 대한 룰(rule)을 정해놓고, 룰을 조금 더 자세히 작성하여 개발 과정에서
+발생하는 문제를 최소화 할 수 있다고 한다.
+
+## 🗣️ 커뮤니케이션 비용 절감 도구
+
+테크 스펙은 **커뮤니케이션 비용 절감의 도구**로도 쓰일 수 있다고 한다. 예를들어,
+프로젝트 진행 시 기능개발을 위한 커뮤니케이션 채널이 오프라인, discord,
+Notion(문서) 3가지였다면, O($3^N$) 이었던 커뮤니케이션 복잡도를 N개의 테크스펙
+위에서 커뮤니케이션 한다면 O(N)으로 줄일 수 있다고 한다.
+
+뱅크샐러드 블로그에서는 아래와 같이 설명했다.
+
+> 1. 작업 해야할 내용이 크다.
+> 2. PR을 어떻게 쪼개야 할지 감이 안 온다.
+> 3. 테크 스펙을 쓴다.
+> 4. 마일스톤에 맞춰서 지라(JIRA) 보드에 하위 작업을 나열한다.
+> 5. 큰 작업 다 쪼갰네!
+> 6. PR 설명은 길게 쓸 필요 없다. 테크 스펙 링크로 대부분의 설명을 대체한다.
+
+# 어떤 내용이 들어갈까?
+
+## 요약 (Summary)
+
+가장 먼저 테크 스펙을 세 줄 내외로 정리한다. 테크 스펙의 제안 전체에 대해
+누가/무엇을/언제/어디서/왜를 간략하면서도 명확하게 적는다.
+
+> - Botton Navigation 영역(하단 탭)을 유저가 원하는 순서로 커스텀할 수 있게
+> 한다.
+> - 서버 순서 정렬 및 저장 API를 요청할 수 없으므로, 순서를 로컬에 저장하고
+> 불러온다.
+
+## 배경 (Background)
+
+프로젝트의 Context를 적는다. 왜 이 기능을 만드는지, 동기는 무엇인지, 어떤 사용자
+문제를 해결하려 하는지, 이전에 이런 시도가 있었는지, 있었다면 해결이 되었는지
+등을 포함한다.
+
+> - 다양한 탭을 사용하는 유저는 Segment에 따라 하단 탭의 노출 수와 사용 빈도가
+> 다르다.
+> - 예를 들어, 20대와 30대의 추천 탭 노출 수 사이는 월 n만 정도이다.
+> - 이러한 유저의 Segment에 맞춰 하단 탭 순서를 유저가 직접 커스텀할 수 있다면
+> 뱅크샐러드가 개인화되었다고 인지할 수 있을 것이다.
+
+## 목표 (Goals)
+
+예상 결과들을 Bullet Point 형태로 나열한다. 이 목표들과 측정 가능한 임팩트들을
+이용해 추후 이 프로젝트의 성공 여부를 평가한다.
+
+> - Botton Navigation의 순서를 유저가 편집할 수 있게 한다.
+> - 앱을 껐다 켰을 시에도 유저가 편집한 순서대로 하단 탭을 보이게 한다.
+
+## 목표가 아닌것 (Non-Goals)
+
+목표가 아닌 것은 **프로젝트와 연관되어 있으나 의도적으로 하지 않거나 해결하지
+않으려 하는 것**을 말한다. 목표가 아닌 것을 정하면 **프로젝트 범위를 더
+명확하게** 할 수 있고, 이 기능도 붙이자, 저 기능도 붙이자 하는 것을 막을 수
+있다. 목표처럼 목표가 아닌 것도 Bullet Point 형태로 읽기 쉽게 적어 독자가
+직관적으로 이해할 수 있도록 한다. 목표가 아닌 것을 세부적으로 잘 적으면 프로젝트
+범위를 넓게 보려 하는 독자들의 폭주를 막을 수 있다.
+
+> - 사용하지 않는 탭의 삭제 기능 등 '순서 편집' 외 하단 탭에 관련한 추가적인
+> 기능 개발
+> - 순서 정렬 및 저장 API 개발
+
+## 계획 (Plan)
+
+테크 스펙에서 가장 긴 파트이다. 준비한 모든 리서치, 준비 내용들을 여기에 쓴다.
+
+**어떻게 기술적, 엔지니어링적으로 접근할지 상세히 묘사**한다. 만약 어떤 부분을
+**어떻게 할지 확실히 결정하지 못한 상태라면 어떤 것들을 고려하고 있는지
+목록화해서 적는다.**
+
+그렇게 하면 이 문서 **리뷰어들이 올바른 결정을 내리도록 도움**을 주게 된다.
+얼마나 기술적으로 깊이 써야 하는지는 이 테크 스펙의 목적과 독자들에 따라 정한다.
+작성자는 생산적인 제안을 받을 수 있도록 **충분히 상세하게 계획을 적는다.**
+
+이 섹션은 프로젝트가 다른 시스템들과 어떻게 상호작용하는지 그림이나 다이어그램을
+포함하기 좋은 지점이다. 사용자와 시스템 간의 시퀀스 다이어그램, 서비스와 API
+간의 데이터 흐름 다이어그램, 데이터베이스 ERD 등을 포함하면 독자의 이해를 한층
+높일 수 있다.
+
+또한 이 테크 스펙이 로우 레벨 까지 다뤄야 한다면 HTTP 응답 코드, JSON 요청 /
+응답 포맷, 에러 명세 등까지 모두 다뤄져야 한다.
+
+## 이외 고려 사항들 (Other Considerations)
+
+고려했었으나 하지 않기로 결정된 사항들을 적는다.
+
+이렇게 함으로써 이전에 논의되었던 주제가 다시 나오지 않도록 할 수 있고, 이미
+논의되었던 내용이더라도 리뷰어들이 다시 살표볼 수 있다.
+
+> 앱 데이터 초기화 시에는 사용자가 커스텀했던 리스트를 모두 날리기로 했었으나,
+> 기존 로직에서 앱 데이터 초기화 시에 로컬 관련 추가 핸들링이 없어 이 기능에서도
+> 앱 데이터 초기화 때에 리스트를 날리는 등 추가적인 기능 구현을 하지 않기로 함.
+
+## 마일스톤 (Milestones)
+
+프로젝트를 제 시간에 맞추기 위해 테크 스펙의 내용을 바탕으로 추정한 마일스톤을
+공유한다. 실험 계획, 배포 날짜를 포함해 최대한 자세히 적는다.
+
+> ~ 9/25: BPL 컴포넌트 개발
+>
+> 9/28 ~ 9/29: 실험 변수 추가, 로컬 변수 추가
+>
+> 9/30 ~ 10/4: 추석 연휴!
+>
+> 10/5: 하단 탭 확장 가능한 구조로 리팩토링
+>
+> 10/6 ~ 10/8: 비즈니스 로직 구현
+>
+> 10/12 ~ 10/20: 사용자 이벤트 부착 및 미진한 내용 보충
+>
+> 10/20: 2.45.0 코드 프리즈 (이때까지 내부 기능 테스트, 이벤트 로깅 테스트)
+>
+> 10/21 ~ 10/23: 2.45.0 릴리즈 QA
+>
+> 11/4: 2.45.0 Rollout
+
+### 참고자료
+
+- [뱅크샐러드 - 테크 스펙 문서](https://blog.banksalad.com/tech/we-work-by-tech-spec/)
+- [Stackoverflow - 테크니컬 스펙 작성 가이드](https://stackoverflow.blog/2020/04/06/a-practical-guide-to-writing-technical-specs/)
diff --git a/src/features/post/index.ts b/src/features/post/index.ts
new file mode 100644
index 0000000..5ecdd1f
--- /dev/null
+++ b/src/features/post/index.ts
@@ -0,0 +1 @@
+export * from './ui';
diff --git a/src/features/post/ui/PostContentsSection.tsx b/src/features/post/ui/PostContentsSection.tsx
new file mode 100644
index 0000000..a4c74a2
--- /dev/null
+++ b/src/features/post/ui/PostContentsSection.tsx
@@ -0,0 +1,29 @@
+import { MDXRemote } from 'next-mdx-remote/rsc';
+
+import rehypePrism from 'rehype-prism-plus';
+import remarkGfm from 'remark-gfm';
+
+import { mdxComponents } from '@/shared';
+
+type PostContentsSectionProps = {
+ content: string;
+};
+
+export const PostContentsSection = ({ content }: PostContentsSectionProps) => {
+ return (
+
+