Dev.Chan64's Blog

홈으로 가기
Show Cover Slide Show Cover Slide

디자인과 콘텐츠를 분리하고, DX로 운영한다

“저비용, 유연성, 속도 중심의 구조화 전략”

1. 문서 개요

문서의 목적

이 문서는 브랜드 웹사이트를 빠르게 설계, 개발, 운영하기 위한 구축 전략과 협업 기준을 정리한 실전 가이드입니다.

디자인, 콘텐츠, 개발, 배포에 이르는 전체 흐름을 역할 중심으로 구조화하고,

저비용, 고유연성, 빠른 반복 실행이 가능한 환경을 만들기 위한 기준을 제공합니다.

우리 팀은 빠르게 실험하고, 빠르게 개선하며, 사용자와 제품 간의 상호작용을 민첩하게 관리하기 위해

삭제 준비(Expiry-Ready)된 구조, 코드화된 콘텐츠, 자동화된 협업을 지향합니다.

이 문서는 그러한 철학을 기반으로, 실무에 적용 가능한 실행 구조를 정의합니다.

이 문서가 필요한 이유

스타트업의 브랜드 웹사이트는 단순한 소개 페이지를 넘어,

따라서 단순히 보기 좋은 화면을 넘어,

팀 전체가 빠르게 협업할 수 있는 구조와 프로세스를 정립하는 것이 중요합니다.

기존의 워드프레스나 정적 페이지 방식은 다음의 문제를 안고 있습니다:

이 문서는 위 문제를 해결하고, 다음을 가능하게 합니다:

대상 독자 및 활용 방법

이 문서는 아래와 같은 구성원이 함께 활용하는 것을 전제로 작성되었습니다:

대상 역할
디자이너 브랜드 가이드 및 UI 설계, 시각적 QA
개발자 컴포넌트 구축, 자동화 구현, 배포 시스템 관리
콘텐츠 운영자 콘텐츠 작성 및 검수, PR 요청 및 승인 흐름 참여
제품/마케팅 리더 릴리즈 승인, 콘텐츠 우선순위 결정, 구조 개선 피드백

활용 방법:

유지 및 갱신 계획

이 문서는 고정된 규칙이 아닌, 살아 있는 문서입니다.

실제 협업과 자동화 흐름을 적용하고 피드백을 반영하며 다음 항목이 발생하면 갱신됩니다:

2. 운영 전략 개요

선언: 우리는 빠르게 만들고, 빠르게 바꾸며, 기술에 종속되지 않는다.

브랜드 페이지는 우리 제품의 얼굴이며,

동시에 내부 팀의 협업 방식과 기술 문화가 드러나는 대표적 산물입니다.

우리는 브랜드 페이지 운영을 통해 다음을 실현하고자 합니다:

이 구조는 단순한 도구 조합이 아니라,

작고 민첩한 팀이 빠르게 실험하고 검증할 수 있도록 설계된 DX 기반 전략입니다.

핵심 운영 원칙

원칙 설명
삭제 준비(Expiry-Ready)된 구조 우리는 TailwindCSS와 Notion을 사용하지만, 언제든 교체할 수 있는 구조로 설계한다.
분리된 협업 구조 콘텐츠, 디자인, 개발은 서로를 방해하지 않으면서도 잘 연결되도록 구조화된다.
자동화된 반복 실행 PR, Preview, QA, 승인, 배포까지 전 과정은 반복 가능하고 자동화 가능한 흐름으로 구성된다.
디자인 시스템 기반 개발 Figma를 통해 정의된 컴포넌트를 TailwindCSS 기반의 구조화된 UI로 구현한다.
콘텐츠는 코드처럼 다룬다 Notion 기반 작성 → Git PR → 승인 → 배포 흐름으로 콘텐츠 관리의 품질과 기록을 유지한다.
유지보수 가능한 협업 흐름 개발자의 개입 없이도 운영팀이 사이트를 개선하고 유지할 수 있도록 역할을 분리한다.

우리가 워드프레스를 버린 이유

기존의 WordPress 기반 운영은 다음의 문제를 반복적으로 야기했습니다:

우리는 위 문제들을 해결하기 위해 다음 구조를 채택합니다:

이 전략은 DX다

이 구조는 단순한 웹사이트 개발 방법론이 아니라,

우리가 일하는 방식을 구조화하고, 지속 가능하게 만드는 일입니다.

우리는 이 구조를 통해 다음과 같은 문화를 만듭니다:

“개발하지 않아도 바꿀 수 있는 사이트,
바꿔도 무너지지 않는 구조,
무너져도 다시 세울 수 있는 시스템”

3. 전체 시스템 구조 개요

이 장에서는 브랜드 페이지를 구성하는 전체 시스템의 흐름과 구성 요소들을 개괄한다.

핵심은 디자인, 콘텐츠, 개발, 배포가 하나의 파이프라인 내에서 유기적으로 연결되면서도, 각자의 책임을 분리해 유지보수 가능성과 협업 유연성을 높인다는 점이다.

3.1 시스템 구성 흐름

브랜드 페이지 운영은 다음과 같은 단계적 흐름으로 구성된다:

flowchart TD
  subgraph 디자인
    Figma[Figma<br/>브랜드 가이드 & UI 컴포넌트 정의]
  end

  subgraph 개발
    Tailwind[개발자<br/>TailwindCSS + Astro로 UI 구현]
  end

  subgraph 콘텐츠_작성
    Notion[Notion<br/>콘텐츠 작성]
  end

  subgraph 자동화
    Watcher[자동 감시 시스템<br/>Markdown 변환 및 Git 커밋]
    PR[자동 PR 생성 및 Preview 배포]
  end

  subgraph 리뷰_및_배포
    Review[PR 검토 및 승인]
    Merge[main 브랜치 병합 및 정식 배포]
  end

  Figma --> Tailwind --> Merge
  Notion --> Watcher --> PR --> Review --> Merge
  1. 디자이너는 Figma를 통해 브랜드 가이드 및 UI 컴포넌트를 정의한다.
  2. 개발자는 TailwindCSS를 활용하여 해당 디자인을 Astro 기반의 UI 컴포넌트로 구현한다.
  3. 콘텐츠 운영자는 Notion에서 콘텐츠를 작성하고, 이를 자동화된 감시 시스템이 감지해 Markdown으로 변환한다.
  4. 변환된 Markdown은 Git 저장소에 커밋되어 PR이 생성되고, 자동으로 Preview 배포가 이루어진다.
  5. PR은 검토 및 승인 과정을 거쳐 main 브랜치에 병합되며, 배포가 진행된다.

이러한 구조는 디자인 변경, 콘텐츠 업데이트, 배포를 각각 독립적으로 수행할 수 있도록 분리되었으며, 동시에 변경 이력과 승인 기록이 모두 Git 기반으로 관리된다.

3.2 기술 구성 요소

다음은 시스템 구성에 사용되는 핵심 기술 스택이다:

이외에도 향후 확장에 따라 콘텐츠 검증을 위한 테스트 도구, 검색 기능, 번역 시스템 등이 추가될 수 있다.

3.3 콘텐츠·스타일·배포의 구조적 분리

이 시스템은 다음 세 가지 축을 분리함으로써 운영의 유연성을 극대화한다:

  1. 콘텐츠 분리

    콘텐츠는 코드에 내장되지 않는다. 운영자는 Notion에서 콘텐츠를 작성하며, 자동화된 프로세스를 통해 마크다운 파일로 변환되고, Git 기반 변경 이력과 함께 관리된다.

  2. 스타일 분리

    스타일은 TailwindCSS 기반으로 구현되며, 각 컴포넌트는 디자인 시스템에서 정의된 기준을 따르고, 특정 페이지나 콘텐츠에 종속되지 않는다. 향후 Tailwind 외 스타일 시스템으로의 교체도 용이한 구조로 유지된다.

  3. 배포 분리

    배포는 GitHub PR 병합을 기준으로 자동화되어 있으며, Preview 환경에서 콘텐츠와 스타일을 검수한 후 승인 시에만 Production으로 반영된다. 배포 자체는 코드 작성자 혹은 승인자의 동의 없이는 이루어지지 않는다.

이러한 구조는 다음과 같은 효과를 제공한다:

이 구조는 추후 CMS나 스타일 프레임워크가 변경되더라도, 핵심 협업 방식은 그대로 유지될 수 있도록 설계되어 있다.

4. 역할 분담 및 협업 기준

브랜드 페이지 운영의 효율성과 지속 가능성을 높이기 위해, 모든 참여자의 역할은 분리되고 명확히 정의되어야 한다.

각 역할은 고유한 책임을 가지며, 자동화된 협업 흐름을 통해 서로 연결된다. 이 구조는 혼선을 줄이고, 업무의 병렬 처리 및 의사결정의 명확화를 유도한다.

4.1 디자이너

책임

산출물

협업 기준

4.2 개발자

책임

산출물

협업 기준

4.3 콘텐츠 운영자

책임

산출물

협업 기준

4.4 승인자 (리더 또는 검수 담당자)

책임

산출물

협업 기준

4.5 역할 간 상호 연결 요약

역할 주요 협업 대상 연결 지점
디자이너 개발자 UI 명세 → 컴포넌트 구현
개발자 디자이너, 운영자 컴포넌트 구현 / 콘텐츠 자동화 / PR 승인
운영자 개발자, 승인자 콘텐츠 작성 → PR 요청 → 배포 승인 요청
승인자 운영자, 개발자 Preview 확인 → 배포 승인 → 릴리즈 판단

이 구조를 통해 각 구성원은 본인의 영역에 집중할 수 있으며, 변경 이력과 승인 기록은 모두 Git과 Slack을 통해 문서화된다.

이러한 역할 분담은 내부 협업 뿐만 아니라, 외주 디자이너나 프리랜서 콘텐츠 작성자와의 연결에도 유효한 기준이 된다.

5. 콘텐츠 운영 및 배포 프로세스

이 장에서는 콘텐츠가 작성된 이후 배포되기까지의 자동화된 흐름과 각 단계에서 수행되는 작업, 책임 주체를 통합적으로 설명한다.

이 구조는 콘텐츠를 코드처럼 다루는 철학을 기반으로 하며, PR, 리뷰, 승인, 릴리즈라는 협업의 전체 사이클을 자동화된 흐름 속에 구성한다.

5.1 전체 자동화 흐름 개요

콘텐츠 운영은 다음과 같은 자동화 흐름으로 구성된다:

  1. 콘텐츠 운영자가 Notion에서 새 콘텐츠를 작성하거나 기존 콘텐츠를 수정한다.
  2. Notion Observer는 해당 변경을 감지하고, 이를 Markdown 포맷으로 변환한다.
  3. 변환된 Markdown 파일은 Git 저장소에 커밋되며, 별도 브랜치와 함께 Pull Request가 생성된다.
  4. Slack으로 PR 생성 알림 및 Preview 링크가 공유되고, 배포 요청 버튼을 통해 승인 플로우가 시작된다.
  5. 개발자는 PR의 정적 렌더링 결과를 검토하고, 에러나 레이아웃 문제가 없는지 확인한다.
  6. 승인자는 PR을 승인하고 병합하며, 자동으로 Production 환경에 배포된다.

이 과정은 모두 자동화되어 있으며, 반복 가능한 단일 프로세스로 설계되어 있다.

5.2 주요 역할과 책임

단계 책임자 작업 내용
콘텐츠 작성 콘텐츠 운영자 Notion 기반 콘텐츠 입력
변경 감지 및 변환 자동화 시스템 Notion → Markdown 변환, Git 커밋
PR 생성 및 알림 자동화 시스템 브랜치 생성, PR 오픈, Slack 메시지 전송
정적 렌더링 검토 개발자 PR 빌드 확인, 렌더링 정상 여부 확인
승인 및 배포 승인자 PR 승인 및 병합, Production 릴리즈 승인

5.3 시스템 구성 요소 및 기술 스택

5.4 자동화 흐름 상세

1. Notion 변경 감지

2. Markdown 변환 및 PR 생성

3. Slack 알림 및 승인 요청

4. Preview 및 테스트

5. 승인 및 Production 배포

5.5 유지 및 확장 전략

이 구조는 운영자가 콘텐츠를 손쉽게 작성하고, 개발자의 검토를 거쳐 신속히 배포되는 전체 흐름을 표준화한다.

모든 변경은 기록되고, 승인 기반으로 릴리즈되며, 팀의 협업은 자동화된 흐름을 통해 명확히 연결된다.

6. 구축 및 유지 일정보고서

이 장에서는 브랜드 페이지 시스템의 초기 구축을 위한 예상 일정과 인력 투입 계획, 그리고 지속적인 유지 관리를 위한 리소스 구조를 정리한다.

목표는 최소한의 리소스로 최대한의 운영 유연성을 확보하는 구조를 실현하는 것이다.

6.1 초기 구축 일정

아래는 일반적인 브랜드 페이지 MVP를 기준으로 한 예상 일정이다.

각 단계는 병렬 가능성이 있으며, 콘텐츠/디자인/자동화는 독립적으로 일정 조정이 가능하다.

단계 기간 주요 작업
요구사항 정의 및 역할 설정 1일 문서 기반 협업 모델 정의, 책임자 지정
디자인 시스템 수급 2~3일 Figma 기준 UI 컴포넌트 정의
UI 컴포넌트 개발 2~4일 Astro + Tailwind 기반 UI 구성
Notion 자동화 구성 2~3일 Notion 감지 → Markdown 변환 → PR 자동화 스크립트
GitHub Actions 및 Vercel 설정 1~2일 Preview / Production 배포 구성
콘텐츠 템플릿 정의 및 초기 작성 1~2일 Markdown 구조 정의, 초기 콘텐츠 작성
QA 및 구조 정리 1일 Preview 기반 QA, 문제 해결 및 릴리즈 기준 확정

총 예상 기간: 8~14일 (디자인 소스 및 운영 환경에 따라 달라질 수 있음)

6.2 인력 투입 계획

역할 예상 필요 인원 투입 기간 비고
디자이너 1명 ~3일 디자인 시스템 수립 후 QA 중심 전환
개발자 1명 ~7일 UI 구성 + 자동화 구조 설계/구현
콘텐츠 운영자 1명 ~2일 콘텐츠 구조 정의, 작성 테스트
기술 리더 or 승인자 1명 ~1일 승인 기준 수립 및 배포 확정

총 인력 기준: 2~3인 내외의 소규모 팀으로 MVP 수준 구현 가능

6.3 운영 유지 전략

브랜드 페이지는 다음과 같은 기준으로 유지 관리된다:

운영 주기 제안

작업 유형 주기 책임자
콘텐츠 업데이트 수시 (비개발자 중심) 콘텐츠 운영자
스타일/디자인 업데이트 분기별 또는 필요 시 디자이너 + 개발자
자동화 시스템 점검 월 1회 개발자
구조 개선 및 확장 필요 시 기술 리더 또는 팀 논의 후 결정

6.4 예상 비용 구조

항목 도구/서비스 비용 기준 비고
도메인 외부 도메인 등록처 연 10,000~30,000원 일반 도메인 비용
호스팅 Vercel Free 무료 기본 배포 기능, Preview 포함
Notion Free 플랜 무료 협업 계정 수에 따라 유료 가능
GitHub Free 무료 개인/조직 계정 기준
Slack Free 플랜 무료 메시지 제한 있음 (알림용은 무방)

초기 도입 시에는 자동화 구조 설계, 협업 환경 정리, 템플릿 구성 등에 따른 일시적인 개발 리소스 집중이 필요하며,

이로 인해 일반 운영 대비 2~3배의 초기 비용(인건비 기준)이 소요될 수 있다.

그러나 위 테이블에서 확인할 수 있듯, 시스템 유지에 필요한 실질적 비용은 극히 낮고,

정적 배포 구조와 자동화 기반 협업으로 인해 지속적인 유지비용은 매우 안정적으로 관리된다.

따라서 초기 비용 증가가 있더라도, 운영 안정성·유지 효율성·협업 명료성 등을 고려할 때
의사결정에 부정적인 영향을 줄 수준은 아니다.

6.5 유지보수 리소스 요약

7. 온보딩 요약 가이드

브랜드 페이지 시스템은 단순한 정적 웹사이트가 아니라,

콘텐츠 작성, 디자인 구현, 협업 승인, 자동 배포에 이르는 전체 구조를 포함한 협업 프레임워크이다.

이 장에서는 역할별로 시스템을 빠르게 이해하고 실무에 투입될 수 있도록

업무 흐름, 도구 사용법, 체크리스트를 중심으로 요약 정리한다.

7.1 디자이너 온보딩 가이드

목표

필수 이해사항

시작 체크리스트

7.2 개발자 온보딩 가이드

목표

필수 이해사항

시작 체크리스트

7.3 콘텐츠 운영자 온보딩 가이드

목표

필수 이해사항

시작 체크리스트

7.4 승인자 온보딩 가이드

목표

필수 이해사항

시작 체크리스트

7.5 공통 문서/경로 안내

8. 향후 확장 전략

현재 구축된 브랜드 페이지 구조는 최소 비용으로 빠르게 운영이 가능하도록 설계되었으며,

동시에 다음과 같은 미래 변화에도 유연하게 대응할 수 있도록 구조적으로 준비되어 있다.

이 장에서는 예상 가능한 변화 시나리오와 그에 대응하는 전략을 기술하며,

삭제 준비(Expiry-Ready)된 구조와 교체 가능한 기술 스택이 어떤 방식으로 유지될 수 있는지를 정리한다.

8.1 TailwindCSS 교체 전략

TailwindCSS는 빠른 UI 구현에 유리하지만, 커스터마이징 복잡도나 팀 내 스타일 일관성 유지에 어려움이 발생할 수 있다.

이를 고려하여 다음과 같은 조건이 충족될 경우 Tailwind를 제거하거나 다른 스타일 시스템으로 전환할 수 있다:

대체 방안

전환 전략

8.2 CMS 교체 전략 (Notion → Headless CMS)

Notion은 초기 도입이 빠르고 비용이 적지만,

다양한 콘텐츠 타입 관리나 다국어 지원, 워크플로우 자동화 등에서는 한계가 존재할 수 있다.

이 경우 CMS 교체가 필요하며, 이를 위해 아래와 같은 준비가 되어 있어야 한다:

대체 가능 CMS 예시

전환 전략

8.3 콘텐츠 자동화의 고도화

현재는 Notion 기반 Markdown 변환 및 PR 생성이 자동화되어 있으나, 다음과 같은 고도화를 통해 품질과 확장성을 높일 수 있다:

8.4 다국어/다브랜드 대응

복수 브랜드 또는 다국어 페이지를 운영해야 할 경우, 다음과 같은 구조가 필요하다:

이러한 구조는 현재 시스템에서도 무리 없이 적용 가능하며,

폴더 구조와 라우팅 설정만으로 상당 부분 대응 가능하다.

8.5 협업 자동화 확장 (ChatOps 기반)

9. 부록

본 장은 앞서 설명한 시스템 구성과 운영 프로세스를 실제로 적용하는 데 도움이 되는 보조 자료들로 구성되어 있다.

모든 예시는 기본적인 형태로 제공되며, 실제 조직에 맞게 커스터마이징하여 사용할 수 있다.

9.1 폴더 구조 예시

.
├── content
│   ├── posts
│   │   └── 2024-03-dx-principles.md
│   ├── brand
│   │   └── brand-a
│   └── pages
├── components
│   ├── layout
│   ├── ui
│   └── markdown
├── public
├── styles
│   └── tokens.css
├── scripts
│   ├── notion-observer.js
│   └── md-generator.js
└── .github
    └── workflows
        └── deploy.yml

9.2 Markdown 콘텐츠 템플릿

---
title: "브랜드 DX 전략"
slug: "dx-strategy"
date: "2025-04-03"
tags: ["DX", "운영", "브랜드"]
author: "팀 브랜딩"
description: "우리가 운영하는 브랜드 DX 전략과 시스템 구조에 대한 설명입니다."
---

## 개요

이 문서는 우리 팀의 브랜드 운영 전략과 기술 설계를 설명합니다...

9.3 Slack 메시지 구성 예시 (Block Kit)

{
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*신규 콘텐츠 PR이 생성되었습니다.*\n<https://github.com/org/repo/pull/123|PR 보기>"
      }
    },
    {
      "type": "context",
      "elements": [
        {
          "type": "plain_text",
          "text": "변경자: 마케팅팀 | 태그: 브랜드, 운영",
          "emoji": true
        }
      ]
    },
    {
      "type": "actions",
      "elements": [
        {
          "type": "button",
          "text": { "type": "plain_text", "text": "Preview 확인" },
          "url": "https://preview-url.vercel.app"
        },
        {
          "type": "button",
          "style": "primary",
          "text": { "type": "plain_text", "text": "배포 승인" },
          "value": "approve_deploy"
        }
      ]
    }
  ]
}

9.4 커밋 메시지 작성 가이드

9.5 Mermaid 업무 흐름 다이어그램

graph TD
A[Notion 작성] --> B[변경 감지]
B --> C[Markdown 변환]
C --> D[Git 커밋 + PR 생성]
D --> E[Slack 알림 + Preview 배포]
E --> F[PR 검토 및 승인]
F --> G[Production 배포]

9.6 참고 링크 모음

9.7 기술 스택 구성 및 선택 배경

아래는 본 시스템에 도입된 주요 기술 스택의 역할과 선택 배경을 설명한 표이다.

구성 요소 역할 선택 이유
Astro 정적 사이트 생성기 (SSG) 빠른 빌드 속도, 정적 콘텐츠 최적화, Markdown 통합 우수, CSR/SSR 유연한 확장성
TailwindCSS 디자인 시스템 구현 클래스 기반 유틸리티 스타일로 빠른 UI 구성, 디자인 시스템을 코드로 표현 가능, 추상화 및 교체 가능성 확보
Notion API 콘텐츠 작성 인터페이스 비개발자가 접근하기 쉬운 에디터, 구조화된 DB 형태의 콘텐츠 관리 가능, API 기반 자동화 연동
GitHub 협업 및 버전 관리 PR 기반 리뷰 및 승인 흐름, 콘텐츠를 코드처럼 관리, 배포 승인 이력 자동화
Vercel 배포 및 Preview 환경 Git 연동 자동 배포, Preview URL 자동 생성, 설정이 간단하며 정적 사이트에 최적화됨

이들 도구는 각자의 영역에서 독립적으로 동작하지만,

협업 자동화 및 콘텐츠 운영이라는 하나의 흐름 내에서 유기적으로 연결되어 있다.

9.8 시스템 구조 상관도

다음 다이어그램은 각 기술 스택의 위치와 흐름 내 상호작용을 시각적으로 정리한 관계도이다.

flowchart TD
    A[Notion] -->|API 감지 + 변환| B[Markdown 변환기]
    B --> C[GitHub 커밋 + PR 생성]
    C --> D[Vercel Preview 배포]
    D --> E[Slack 알림 + 배포 승인 요청]
    E -->|승인 시| F[Production 배포]
    C --> G[PR 검토: 개발자]
    subgraph 웹사이트 코드베이스
        H[Astro 프로젝트]
        I[Tailwind 컴포넌트]
        B --> H
        I --> H
    end
    H --> D

    style H fill:#f8f9fa,stroke:#ccc
    style I fill:#f1f5f9,stroke:#ccc

9.9 기술 구성 종합 해석

이러한 구조는 각 구성요소가 완전히 탈착 가능한 구조로 설계되어 있으며,

개별 요소의 교체 또는 확장이 전체 흐름을 무너뜨리지 않도록 설계되었다.

이상의 부록은 시스템을 실제로 구현하거나, 팀원에게 온보딩 시 실무 이해를 돕기 위한 자료로 제공된다.

모든 내용은 실제 운영 환경에 따라 커스터마이징되어야 하며, 가능한 범위 내에서 자동화 및 재사용을 고려하여 관리하는 것이 바람직하다.

홈으로 가기
태그: 조직문화 프로젝트