블로그 플랫폼을 직접 만들기로 한 이유와 구조 설계

왜 블로그 플랫폼을 직접 만들기로 했을까?

지금 이 글도 티스토리에 작성하고 있지만, 어느 순간부터 생각이 들었습니다.

"내가 직접 글을 쓰는 공간, 내가 원하는 기능을 자유롭게 붙이고 고칠 수 있는 플랫폼을 직접 만들어보면 어떨까?"

기성 플랫폼이 제공하는 템플릿이나 기능이 충분하지 않거나, 특정한 콘텐츠 흐름(예: 개발자 글쓰기, 기술 문서, 나만의 북마크 등)에 맞게 구성하려면 결국 커스터마이징이 필요하다는 한계가 있었어요.

 

그래서 블로그 플랫폼을 직접 만드는 프로젝트를 시작했습니다.

 

기술 스택 구성

 

영역	스택	선택한 이유
🖥 프론트엔드	React (with context API), Webpack	컴포넌트 기반 구조로 UI를 관리하기 쉽고, context API를 통해 전역 상태도 무겁지 않게 다룰 수 있습니다. Webpack을 통해 커스터마이징된 번들링 설정도 유연하게 조정할 수 있습니다.
🗄 백엔드	Koa.js	Express보다 더 미니멀하고 현대적인 구조를 가진 Node.js 프레임워크입니다. 미들웨어 흐름이 명확해 API 설계에 집중하기 좋습니다.
🧬 ORM	Sequelize (MySQL)	SQL 쿼리를 직접 다룰 수 있으면서도 모델 기반으로 직관적인 데이터 관리를 할 수 있어 유지보수와 협업에 유리합니다. 기존 프로젝트에서도 사용한 경험이 있어 안정적으로 선택했습니다.
🧰 기타	Babel, Webpack, Gulp	ES6+ 문법을 트랜스파일하고, 프론트 빌드와 정적 자산 처리에 필요한 자동화를 그대로 가져가기 위해 기존 빌드 환경

 

 

프로젝트 디렉토리 구조 설계

이번 프로젝트는 1패키지(monorepo) 구조로 설계했습니다.
프론트엔드와 백엔드를 하나의 저장소에서 통합 관리하고, 단일 package.json에서 의존성을 다루는 방식입니다.

project-root/
├── client/                # React 기반 프론트엔드
│   ├── pages/
│   ├── components/
│   ├── managers/
│   ├── routes/
│   └── ...
├── server/                # Koa 기반 백엔드
│   ├── controllers/
│   ├── services/
│   ├── models/
│   ├── routes/
│   └── ...
├── public/                # 정적 파일
├── package.json           # 공통 패키지 관리
├── app.js                 # 서버 진입점
└── webpack.config.js      # 프론트 빌드 설정

 

장점

• 프론트/백 공통 의존성 통합 관리
• 서버와 클라이언트 간 협업 흐름이 명확해짐
• 추후 CI/CD 및 배포에 유리

 

주요 목표 기능

• 글 목록 조회 / 상세 보기
• 글 작성 및 수정
• 사용자 인증 (로그인 / 로그아웃)
• 카테고리/태그 기반 글 정리
• 마크다운 기반 작성기
• 검색 기능

 

앞으로의 진행 방향

이 프로젝트는 단순한 CRUD 기능 구현에 그치지 않고,
다음과 같은 핵심 가치를 중심으로 완성도를 높여갈 예정입니다.

• 체계적인 구조 설계
• 실제 사용자 입장에서 고려한 사용성 및 품질
• 장기적인 관점에서의 코드 유지보수성과 확장성
• 검색 노출을 고려한 SEO 최적화

 

다음 글 예고

다음 글에서는 실제로 API와 DB 모델을 어떻게 설계했는지, Koa + Sequelize 조합으로 "블로그 글 작성 API" 를 어떻게 만들었는지를 공유해보겠습니다.