buzzvilbuzzvil:tech
← Blog
Nobody Owned the Website. Now Everybody Does.
design-systemaibrandmonorepoproduct-strategy

Nobody Owned the Website. Now Everybody Does.

Maxence Mauduit
Maxence Mauduit

Product Lead - Head of Design

이 글은 영문 원본을 바탕으로 작성되었습니다.

회사 웹사이트, 누가 담당하고 계신가요?

단순한 질문 같지만, 대부분의 회사에서 솔직한 답은 "마케팅팀이 일단은요" 아니면 "글쎄요, 딱히 아무도…" 사이 어딘가일 겁니다. 브랜드를 잘 아는 사람은 웹사이트를 만들지 않고, 만들 수 있는 사람은 제품 개발로 바쁩니다. 웹사이트는 그 사이에 어정쩡하게 놓여서, 마지못해 업데이트되고, 시간이 남는 사람이 간신히 관리합니다.

대기업이라면 이 이야기가 와닿지 않을 수도 있습니다. 브랜드팀이 있고, 웹팀이 있고, CMS 전담 조직이 있을 테니까요. 하지만 50명에서 200명 규모의 회사에서, 모든 직무가 빠듯하고 누구의 JD에도 "웹사이트 담당"이라고 적혀 있지 않다면, 제가 무슨 말을 하는지 정확히 아실 겁니다.

버즈빌도 수년간 이 상태로 지냈습니다. 약 100명 규모의 애드테크 회사에 프로덕트 디자이너는 있지만 브랜드 디자이너는 없고, 마케팅팀은 두 명인데 디자인이나 개발 리소스가 전혀 없습니다. 웹사이트는 늘 다른 누군가의 일이었고, 결과물이 그걸 그대로 보여줬습니다.

우리를 규정했던 제약

"리소스가 없다"는 말이 실제로 어떤 의미였는지 구체적으로 이야기해 보겠습니다.

회사 웹사이트는 공식적으로는 MC(마케팅 커뮤니케이션)팀 소유였습니다. 하지만 MC팀에는 자체 디자인이나 개발 리소스가 없었습니다. 업데이트를 할 때마다 개발팀의 시간을 빌려야 했고, 이는 곧 제품 우선순위와 경쟁한다는 뜻이었습니다. 답은 거의 항상 "지금은 안 돼요"였습니다.

결국 회사는 이 일을 아예 외주로 돌리기로 했습니다. 외부 프리랜서가 디자인과 프론트엔드를 모두 맡게 되었고, 결과는 예상 가능했습니다. 기획부터 배포까지 몇 달이 걸리는 릴리스 일정, 그리고 어딘가 우리답지 않은 결과물.

한편 기술 블로그는 Hugo로 따로 운영되고, 따로 호스팅되며, 메인 사이트의 비주얼 랭귀지와 전혀 연결이 없었습니다. SDK 문서는 Docusaurus에 올라가 있었는데, 역시 별도 운영, 역시 다른 스타일. 그리고 디자인 포털, 디자인 시스템 자체를 문서화하는 곳마저 또 다른 독립 앱이었습니다.

네 개의 웹 프로퍼티. 네 개의 코드베이스. 네 개의 비주얼 랭귀지. 일관성은 제로.

프로덕트 디자이너들은 제품 화면에 전부 투입되어 있었습니다. MC팀은 카피는 쓸 수 있지만 디자인이나 페이지를 만들 수는 없었습니다. 개발팀은 여력이 없었습니다. 프리랜서는 실행할 수는 있어도 오너십을 가질 수는 없었습니다. 아무도 전체 그림을 보고 있지 않았습니다.

그래서 이 간극은 계속됐습니다. 감각이 없어서가 아니라, 손이 부족해서.

무엇이 바뀌었나

2025년 말에 두 가지 변화가 있었습니다.

첫째, 디자인 시스템이 성숙해졌습니다. 그 전 해에 시맨틱 CSS 커스텀 프로퍼티와 런타임 테마를 지원하는 토큰 기반 시스템을 만들었는데, 원래 인터랙션 패턴(광고 경험, 게이미피케이션, 캠페인 UI)을 위해 만든 것이었지만 토큰 레이어 자체는 범용적이었습니다. 어떤 화면이든 이 토큰을 가져다 쓸 수 있었습니다.

둘째, AI 코딩 도구가 디자이너 한 명이 개발팀 속도로 움직일 수 있는 수준에 도달했습니다. "AI가 목업을 만들어 준다" 수준이 아닙니다. 실제 프로덕션 코드 속도입니다. Next.js 앱, 반응형 레이아웃, SEO 설정, 이미지 최적화, CI/CD 파이프라인. 과거에는 전담 프론트엔드 팀이 필요했던 종류의 작업이요.

이 두 가지가 결합되면서 오랫동안 바라던 것이 가능해졌습니다. 브랜드를 이해하는 디자이너가 처음부터 끝까지 직접 만들 수 있게 된 것입니다. 개발 리소스 배정을 기다리지 않고. 비전을 템플릿에 맞춰 단순화하지 않고. 그리고 더 중요한 것은 Figma 없이도 가능하다는 것. 종이 스케치, 토큰 시스템, 그리고 Claude Code면 충분했습니다.

2026년 3월 초에 시작해서, 5주 뒤 세 개의 앱이 프로덕션에 올라갔습니다.

코드로 표현되는 브랜드

아키텍처 이야기에 앞서, 우리가 실제로 하려던 것이 무엇이었는지 먼저 설명하고 싶습니다. 이것은 마이그레이션 프로젝트가 아니었습니다. 브랜드 프로젝트였습니다.

버즈빌의 브랜드 아이덴티티는 늘 문서 안에 정의되어 있었습니다. PDF 가이드라인, Figma 파일, 여기저기 흩어진 참고자료. 존재는 했지만 살아 있지는 않았습니다. 실행되지 않았고, 렌더링되지 않았고, 스스로를 강제하지 않았습니다.

우리는 이걸 바꾸고 싶었습니다. 브랜드가 코드로 표현되기를, 누군가가 확인하는 참고 문서가 아니라 화면을 구성하는 실제 재료가 되기를 원했습니다.

컬러는 시맨틱 CSS 커스텀 프로퍼티에 매핑된 값입니다. --bzv-color-theme-primary는 화면에 실제로 렌더링되는 값이지, 팬톤 견본의 근사치가 아닙니다. 다크 모드와 라이트 모드는 :root 값을 교체하는 것만으로 처리됩니다. 별도의 조건 분기 없이 모든 컴포넌트가 자동으로 적응합니다.

/* packages/tokens/src/tokens.css */

:root {
  /* Primary: Buzzvil red, lightened for dark backgrounds */
  --bzv-color-theme-primary:           oklch(67.7% 0.1804 23.2);
  --bzv-color-theme-primary-content:   oklch(100% 0 0);

  /* Surfaces: Zinc dark palette */
  --bzv-color-theme-base-100:          oklch(21.0% 0.0059 285.9);
  --bzv-color-theme-base-200:          oklch(27.4% 0.0055 286.0);
  --bzv-color-theme-base-300:          oklch(37.0% 0.0119 285.8);
  --bzv-color-theme-background:        oklch(14.1% 0.0044 285.8);

  /* Content: text hierarchy */
  --bzv-color-theme-base-content:      oklch(94.7% 0.0027 286.3);
  --bzv-color-theme-base-content-700:  oklch(77.2% 0.0098 286.2);
  --bzv-color-theme-base-content-600:  oklch(64.9% 0.0146 262.4);
  --bzv-color-theme-base-content-400:  oklch(48.5% 0.0118 267.3);

  /* Stroke */
  --bzv-color-theme-stroke-100:        oklch(100% 0 0 / 0.08);
}

타이포그래피는 웨이트, 사이즈, 행간의 관계가 정의된 스케일을 따릅니다. 단순히 "프리텐다드 쓰세요"가 아닙니다. 산문 스타일, 헤딩 위계, 코드 블록 처리, 읽기 최적화된 행 길이까지 포함하는 완전한 타입 시스템입니다.

스페이싱은 체계적인 스케일을 사용합니다. 임의의 패딩이 아닙니다. 의도된 리듬입니다.

스트로크는 다크 서페이스 위에 불투명도 기반의 미묘한 보더를 사용합니다. 하드코딩하면 쉽게 틀리는 부분인데, 토큰은 이걸 틀리는 것 자체를 불가능하게 만듭니다.

마케팅팀이 buzzvil.com에 새 페이지가 필요할 때, 브랜드는 이미 그곳에 있습니다. 확인해야 할 참고 문서가 아니라, 그 페이지를 구성하는 재료 자체로서.

아키텍처

buzzvil-web/
├── apps/
│   ├── homepage/             # buzzvil.com
│   ├── tech-blog/            # 195+ posts, migrated from Hugo
│   ├── docs/                 # 227 pages, migrated from Docusaurus
│   └── design/               # Design portal
├── packages/
│   ├── tokens/               # colors, spacing, motion, fonts
│   ├── components/           # Shared UI components
│   ├── layouts/              # Page layouts and shells
│   ├── content/              # Shared content utilities
│   └── docs-ui/              # Documentation-specific components

네 개의 앱. 다섯 개의 공유 패키지. 하나의 토큰 시스템. Turborepo가 빌드를 관리하고, 모든 앱에 Next.js 15 App Router가 적용되어 있습니다. Tailwind CSS 4는 @theme 디렉티브를 통해 디자인 토큰을 사용합니다.

토큰의 흐름

토큰 시스템은 세 개의 레이어로 구성됩니다. CSS 변수 파일이 원본 값을 정의하고, Tailwind 프리셋이 이 변수들을 시맨틱 클래스명에 매핑하고, 각 앱이 그 프리셋을 가져다 씁니다. 덕분에 bg-primary가 홈페이지에서든 SDK 문서에서든 동일한 의미를 갖습니다.

// packages/tokens/src/tailwind.ts

const preset: Partial<Config> = {
  theme: {
    extend: {
      colors: {
        background: "var(--bzv-color-theme-background)",
        foreground: "var(--bzv-color-theme-base-content)",
        primary: {
          DEFAULT:    "var(--bzv-color-theme-primary)",
          foreground: "var(--bzv-color-theme-primary-content)",
        },
        muted: {
          DEFAULT:    "var(--bzv-color-theme-base-200)",
          foreground: "var(--bzv-color-theme-base-content-400)",
        },
        border: "var(--bzv-color-theme-stroke-100)",
      },
    },
  },
};

각 앱에서는 프리셋을 가져오기만 하면 됩니다:

// apps/tech-blog/tailwind.config.ts
import preset from '@buzzvil/tokens/tailwind';
export default { presets: [preset] };

하나의 토큰 파일. 하나의 프리셋. 모든 앱이 이걸 소비합니다. 브랜드 레드가 바뀌면 한 줄만 고치고 리빌드하면 됩니다. 모든 화면이 따라옵니다.

앱 간 코드 공유

Turborepo가 의존성 그래프를 관리합니다. 각 앱이 공유 패키지를 선언하면, Turbo가 빌드 순서를 알아서 정합니다.

// apps/tech-blog/next.config.ts
const nextConfig: NextConfig = {
  transpilePackages: [
    '@buzzvil/tokens',
    '@buzzvil/layouts',
    '@buzzvil/content'
  ],
};

packages/layouts에서 한 번 만든 레이아웃 컴포넌트가 기술 블로그, SDK 문서, 홈페이지에 동일하게 나타납니다. 헤더, 푸터, 네비게이션 셸, 모두 공유됩니다. 복사-붙여넣기가 아니라 실제로 공유됩니다.

이동한 것들의 규모

이 프로젝트가 얼마나 많은 것을 흡수했는지 감을 드리자면, Hugo에서 195개의 포스트를 가진 기술 블로그를, Docusaurus에서 Android와 iOS 세 가지 SDK 버전을 다루는 227페이지의 SDK 문서를 마이그레이션했습니다. 둘 다 같은 모노레포 안으로, 같은 토큰 시스템 아래로.

블로그 마이그레이션만 해도 콘텐츠 포맷 변환, 수년간 불일치했던 슬러그 정규화, 수백 개의 깨진 이미지 참조 수정, 페이지네이션과 카테고리 필터링 구축, OG 이미지 시스템 생성, 그리고 기존 링크가 깨지지 않도록 301 리다이렉트 설정이 필요했습니다.

// 하위 호환을 위한 리다이렉트 규칙 예시
{ source: '/blog/2024/:slug*', destination: '/blog/:slug*', permanent: true },
{ source: '/blog/2023/:slug*', destination: '/blog/:slug*', permanent: true },
{ source: '/tags/:path*', destination: '/blog', permanent: true },
{ source: '/index.xml', destination: '/feed.xml', permanent: true },

SDK 문서는 완전한 콘텐츠 동등성, SEO 보존(sitemap, robots, opensearch), 콘텐츠 헤딩에서 추출한 페이지별 메타 태그, 접근성 작업, 그리고 공식적인 마이그레이션 go/no-go 평가가 필요했습니다.

그다음은 이미지였습니다. 원본 미디어 폴더 용량이 1.0 GB였는데, 1,599개 이미지를 325 MB까지 최적화했습니다. 71% 감소, 눈에 보이는 품질 저하 없이.

프로덕트 디자이너가 이미지 최적화와 리다이렉트 매핑에 2주를 쓰는 건 정당화하기 어려웠을 겁니다. AI 도구를 가진 디자이너는 그걸 몇 시간 만에 해냈습니다. 이것이 이전이라면 이 프로젝트를 좌초시켰을 부분입니다. 디자인 사고도, 브랜드 전략도 아닌, 아무도 맡고 싶어하지 않았던 방대한 에디토리얼 인프라 작업이요.

AI 네이티브로 만들기

아마 제가 가장 흥미롭게 느끼는 부분이고, 밖에서 보면 가장 눈에 띄지 않는 부분일 겁니다.

AI로 모노레포를 만드는 것은 한 가지 일이었습니다. 그걸 AI를 통해 회사의 나머지 구성원들도 활용할 수 있게 만드는 것이 진짜 목표였습니다.

아이디어는 간단합니다. 회사의 누구든 전체 아키텍처를 이해하지 않고도 이 화면들에 기여할 수 있어야 합니다. 블로그 글을 업데이트하고 싶은 마케터. SDK 문서의 오타를 고치고 싶은 PM. 리다이렉트를 추가하고 싶은 개발자. 레포를 클론하고, Claude Code를 열고, 원하는 것을 설명하면 프로세스를 안내받을 수 있습니다.

이것을 가능하게 하기 위해 세 가지를 했습니다.

컨텍스트 파일

모든 앱에 CLAUDE.md 파일이 있어서, AI 에이전트에게 해당 앱이 무엇을 하는지, 어떤 규칙을 따라야 하는지, 무엇을 건드리면 안 되는지를 알려줍니다. 일반적인 README가 아닙니다. LLM이 파싱하고 추론할 수 있도록 구조화되어 있습니다.

예를 들어 기술 블로그의 CLAUDE.md는 콘텐츠 디렉토리 구조, 프론트매터 작성법, 이미지 위치, 블로그 포스트에 사용 가능한 컴포넌트, 슬러그 규칙을 설명합니다. 에이전트가 이 파일을 읽으면 사람의 안내 없이도 새 포스트를 올바르게 작성할 수 있습니다.

토큰 패키지에도 변수 명명법, Tailwind 프리셋의 작동 방식, 값을 변경하면 어떤 일이 일어나는지를 설명하는 자체 문서가 있습니다. 에이전트가 이걸 읽으면 색상을 조정할 때 시스템을 깨뜨리지 않을 만큼 충분히 이해하게 됩니다.

스킬

스킬은 Claude Code가 특정 워크플로우를 처리하기 위해 호출하는 구조화된 명령 세트입니다. 모노레포를 위해 여러 개를 만들었습니다:

  • 새 블로그 포스트를 만드는 스킬: 마크다운 파일 스캐폴딩, 이미지 디렉토리 설정, 개발 서버 시작까지 처리합니다.
  • 이미지를 최적화하는 스킬: 이미지가 사용될 위치에 따라 적절한 크기, 포맷, 압축을 자동으로 결정합니다.
  • 배포 상태를 확인하는 스킬: 어떤 앱에 푸시한 후 빌드 성공 여부를 확인합니다.

스킬은 복잡한 다단계 워크플로우를 한 줄 호출로 바꿉니다. 기여하는 사람은 단계를 알 필요가 없습니다. 스킬이 단계를 알고 있으니까요.

훅

훅은 특정 액션 전에 실행되는 자동화된 검사입니다. 가드레일 역할을 합니다.

블로그 포스트가 커밋되기 전에 마크다운 프론트매터를 검증하는 훅이 있고, 하드코딩된 색상 값이 PR에 들어오지 못하도록 하는 훅이 있습니다. 콘텐츠 전용 PR(마크다운, 이미지)은 CI 파이프라인이 자동 승인합니다. 코드 PR은 영향받는 모든 앱에서 타입 체크를 받습니다. CODEOWNERS가 적절한 사람이 적절한 파일을 리뷰하도록 보장합니다.

결과적으로 브랜드는 토큰 시스템과 훅이 보장하기 때문에 일관성을 유지합니다. 하지만 콘텐츠, 카피, 작은 수정들은 PR을 보낼 의지만 있으면 누구에게나 열려 있습니다.

이것은 의도적인 선택이었습니다. 디자이너만의 프로젝트로 남길 수도 있었습니다. 대신 우리는 이것을 플랫폼으로 만들었습니다.

현재 상태

2026년 3월 초에 시작했습니다. 현재 상황은 이렇습니다:

앱상태
Design Portal운영 중 (최초 런칭)
Tech Blog운영 중, 195+ 포스트 마이그레이션 완료
SDK Docs최종 QA 중, 227 페이지 마이그레이션 완료
Homepage진행 중, 시스템 전환 완료, 콘텐츠 마이그레이션 중

기술 블로그 기술 블로그. Hugo에서 마이그레이션한 195+개의 엔지니어링 포스트가 다른 모든 화면과 같은 토큰 시스템을 공유합니다.

SDK 문서 SDK 문서. 세 가지 SDK 버전을 다루는 227페이지를 Docusaurus에서 마이그레이션. 같은 타이포그래피, 같은 스페이싱, 같은 브랜드.

홈페이지 홈페이지 (진행 중). 여러 팀에 걸친 콘텐츠 의존성이 있는 가장 복잡한 화면.

컬처 블로그 컬처 블로그. 홈페이지 앱 안에서 레이아웃과 컴포넌트를 공유하는 콘텐츠 페이지.

디자인 포털이 팀과 가장 가까운 화면이라 첫 번째로 런칭했습니다. 기술 블로그가 가장 큰 콘텐츠 마이그레이션과 함께 뒤를 이었습니다. SDK 문서는 콘텐츠 동등성 검증과 SEO 확인을 마쳤고, 네 명의 리뷰어가 최종 비주얼 QA를 진행하고 있습니다. 홈페이지가 가장 복잡한 화면으로, 여러 팀 간의 콘텐츠 의존성을 새로운 협업 워크플로우를 통해 해결하고 있습니다.

두 개의 앱이 프로덕션에, 하나가 최종 QA 중, 하나가 진행 중. 프리랜서에게 맡겼을 때 페이지 하나 업데이트하는 데 걸리던 몇 달과 비교해 보세요.

배운 것들

토큰 시스템이 곧 제품이다. 비주얼 품질에 대한 모든 대화는 결국 "이거 토큰을 쓰고 있는 거야, 하드코딩된 값이야?"로 귀결됩니다. 시스템이 스스로를 단속합니다. 주변이 모두 체계적이기 때문에 하드코딩된 값은 어색해 보입니다.

속도가 아니라 범위의 문제다. AI가 빠르기 때문에 이 앱들을 만든 게 아닙니다. AI가 이전에는 팀 단위로만 가능했던 수준의 범위로 작업할 수 있게 해줬기 때문에 만들었습니다. 한 사람이 브랜드, 디자인, 개발, 콘텐츠의 전체 맥락을 쥐고 있으면, 전문가들 사이를 릴레이하는 것과는 다른 결과물이 나옵니다.

콘텐츠 마이그레이션은 디자인 작업이다. 블로그 마이그레이션이나 SDK 문서를 "그냥 콘텐츠 옮기기"로 취급했다면 평범한 결과물이 나왔을 겁니다. 타이포그래피, 읽기 경험, 이미지 품질, 이것들은 모두 디자인 결정입니다. 전체 파이프라인을 소유한다는 것은 이 결정들이 우연이 아니라 의도적이라는 뜻입니다.

AI 네이티브 레이어가 지속 가능성을 만든다. AI 덕분에 혼자 만드는 것은 가능했습니다. 하지만 혼자 유지하는 것은 불가능합니다. 컨텍스트 파일, 스킬, 훅이 한 사람의 프로젝트를 조직 전체의 플랫폼으로 바꿔줍니다. 이것들이 없으면 모노레포는 한 사람만 건드릴 수 있는 또 다른 것이 됩니다. 이것들이 있으면 모두가 기여할 수 있는 것이 됩니다.

브랜드에 대한 질문

프로젝트 초기에 선택의 기로에 선 순간이 있었습니다. 먼저 브랜드를 다시 생각하고, 비주얼 톤을 업데이트하고, 철학을 다듬을 것인가? 아니면 앱 전반에 걸쳐 브랜드를 수용하는 시스템을 먼저 만들고, 나중에 그 시스템 안에서 브랜드를 발전시킬 것인가?

저는 브랜드 디자이너가 아닙니다. 제대로 된 브랜드 리프레시에 얼마나 걸릴지, 첫 번째 시도에 잘 해낼 수 있을지 확신이 없었습니다. 하지만 한 가지는 확신했습니다. 시스템이 제대로 만들어지면, 나중에 브랜드를 업데이트하는 것은 간단해진다는 것. 토큰 하나 바꾸고, 리빌드하면 끝. 모든 화면이 따라옵니다.

그래서 이 가정을 일찍 테스트했습니다. 기존 브랜드 가치를 가져와서 하나의 토큰 세트로 분해하고, 공유 프리셋을 통해 모노레포 전체에 연결했습니다. 그런 다음 몇 가지 값을 바꾸고 모든 앱이 한꺼번에 업데이트되는 것을 확인했습니다. 됐습니다. 그것만으로 진행할 충분한 근거가 됐습니다.

지금의 브랜드는 우리 자신입니다. 아마 완벽하지는 않을 겁니다. 다듬어지고, 발전하고, 날카로워질 수 있습니다. 하지만 처음으로 살아 있습니다. 릴리스 전에 누군가가 확인하는 PDF가 아닙니다. 실제 배포물과 점점 달라지는 Figma 파일이 아닙니다. 화면을 구성하는 재료 자체입니다. 그것이 바뀌면, 모든 것이 함께 바뀝니다.

그리고 같은 토큰 시스템은 이미 이 웹 앱들 이상의 것을 구동하고 있습니다. 한국 전역의 퍼블리셔 앱 안에서 구동되는 인터랙션 라이브러리, 게이미피케이션과 캠페인 경험에도 적용되어 있습니다.

앞으로

시스템은 구축되었고, 브랜드는 연결되었고, 기여 모델은 열려 있습니다. 남은 것은 범위를 확장하는 것입니다.

다음은 슬라이드와 문서입니다. 지금 버즈빌에서 누군가 프레젠테이션을 만들거나 제안서를 쓸 때, 살아 있는 브랜드와 전혀 연결이 없는 오래된 템플릿에서 시작합니다. 색상이 작년 것일 수 있고, 폰트가 맞지 않을 수 있고, 톤이 흐트러지는데 이를 강제하는 시스템이 없습니다.

하지만 이제 있습니다. 웹사이트에 적용되는 동일한 토큰이 슬라이드 덱 생성기, 문서 템플릿, 이메일 빌더에도 적용될 수 있습니다. 원칙은 같습니다: 브랜드를 한 곳에서 정의하고, 어디서든 소비한다. 매체는 바뀌지만 소스 오브 트루스는 바뀌지 않습니다.

"웹사이트를 누가 담당하나요?"라는 질문의 진짜 답이 여기 있습니다. 시스템이 일관성을 보장하기 때문에 아무도 소유할 필요가 없습니다. 그리고 도구가 안전하게 만들어주기 때문에 누구나 기여할 수 있습니다.

buzzvil-web: 274 commits, 4 apps, 5 shared packages. 한 명의 디자이너가 Claude Code로 구축하고, 조직 전체가 기여할 수 있는 플랫폼.

Related posts