6장과 7-1~7-2에서 위니브 랜딩 페이지 하네스를 만들고 팀에 옮기는 흐름을 따라왔습니다. 여기서는 같은 자리(하네스)를 다른 산출물로 옮길 때 무엇이 바뀌고 무엇이 그대로인지, 그리고 위니브가 아닌 다른 회사가 이 하네스를 자기 것으로 바꿔 쓸 때 어디를 갈아 끼우면 되는지를 봅니다.

1. 같은 패턴, 다른 산출물

랜딩 페이지 한 장을 자연어 브리프로 찍어내는 하네스를 만들었습니다. 같은 패턴이 다음 산출물에도 그대로 옮겨집니다.

• 이메일 뉴스레터 한 통
• SNS 카드 (인스타그램 캐러셀, 페이스북 게시물)
• 사내 슬라이드 덱
• 보고서·제안서

각 산출물마다 디자인 시스템·컴포넌트·카피 톤·출력 골격을 한 폴더에 모으는 일은 같습니다. 다른 것은 무엇이 들어가느냐일 뿐입니다.

1.1 이메일 뉴스레터 하네스

위니브가 매주 보내는 강의 소식 뉴스레터를 같은 패턴으로 옮긴다면 이런 모양이 됩니다.

newsletter-실습/
├── CLAUDE.md                          ← 책상 안내판
├── style/                             ← 이메일용 CSS (인라인 스타일 위주)
│   ├── tokens-email.css
│   └── components-email.css
├── components.md                      ← 뉴스레터 섹션 시퀀스
│                                        (헤더, 이번 주 강의, 추천 글,
│                                         이벤트, 푸터)
├── brand.md                           ← 카피 톤 (랜딩과 거의 동일)
├── .claude/skills/newsletter/
│   ├── SKILL.md                       ← 작업 매뉴얼
│   └── template.html                  ← 이메일 표준 골격
└── output/                            ← 발송 전 미리보기 HTML

다른 점 세 가지가 보입니다.

• CSS는 인라인 스타일 위주입니다. 이메일 클라이언트(Gmail, Outlook 등)는 외부 CSS 링크를 제한적으로만 지원하기 때문에 토큰을 인라인으로 풀어줘야 합니다.
• 컴포넌트 카탈로그가 다릅니다. 랜딩의 Hero·CTA 대신, 뉴스레터의 "이번 주 강의 카드", "추천 글 링크 블록", "이벤트 배너" 같은 패턴들이 들어갑니다.
• 출력 골격이 다릅니다. 이메일 표준에 맞는 <table> 기반 레이아웃, 뷰포트 메타 태그, 다크 모드 호환 미디어 쿼리.

같은 것은 다섯 가지입니다.

• 자연어 브리프 한 줄로 호출하는 흐름
• 책상 안내판(CLAUDE.md)의 역할
• 디자인 토큰을 한 자리에 모으는 패턴
• 카피 컨벤션(brand.md)의 구조
• 작업 매뉴얼(SKILL.md)의 6단계 흐름

다섯 개의 같은 자리와 세 개의 다른 자리. 한 번 패턴을 익히면 다음 산출물은 절반 이하의 시간으로 만들어집니다.

1.2 SNS 카드 하네스

인스타그램 캐러셀처럼 한 게시물 안에 여러 장의 카드가 들어가는 산출물도 같은 패턴이 됩니다.

sns-card-실습/
├── CLAUDE.md
├── style/                             ← 1080×1080 카드용 CSS
├── components.md                      ← 카드 시퀀스 (커버, 본문 3~5장, CTA)
├── brand.md
├── .claude/skills/sns-card/
│   ├── SKILL.md
│   └── template.html                  ← 정사각형 1장 골격 (반복 사용)
└── output/                            ← {brief}/card-1.html ~ card-N.html

여기서는 출력이 한 페이지가 아니라 여러 장의 카드라는 점이 가장 다릅니다. SKILL.md의 작업 매뉴얼에 "본문이 들어갈 카드 수를 먼저 결정하고, 카드 단위로 한 장씩 생성한다" 단계가 추가됩니다.

이 외에는 같은 구조입니다. 디자인 토큰, 카피 톤, 책상 안내판은 위니브 랜딩 하네스와 거의 그대로 공유될 수 있습니다.

1.3 한 회사가 여러 하네스를 둘 때

위니브가 랜딩·뉴스레터·SNS 카드를 모두 하네스로 가졌다고 합시다. 그러면 다음 폴더 구조가 됩니다.

weniv-harness/
├── landing/         (6장에서 만든 하네스)
├── newsletter/
├── sns-card/
├── shared/          ← 셋이 공유하는 자산
│   ├── style/         (디자인 시스템 본체)
│   ├── brand.md       (카피 컨벤션, 셋이 거의 같음)
│   └── README.md
└── ...

shared/ 폴더에 디자인 시스템과 카피 컨벤션을 두면, 세 하네스가 같은 자산을 참조합니다. style/tokens.css에 색을 하나 추가하면 랜딩·뉴스레터·SNS 카드에 동시에 반영됩니다.

이게 6장과 7장의 패턴이 회사 전체로 확장되는 자리입니다. 하나의 산출물에서 시작한 자리(하네스)가 회사의 콘텐츠 생산 파이프라인으로 자라납니다.

2. 다른 회사가 이 하네스를 가져갈 때

이 책을 본 다른 회사가 자기 디자인 시스템으로 같은 하네스를 만들고 싶을 때, 무엇을 어떻게 바꾸면 되는지 짚어 둡니다. 정리하면 세 자리만 갈아 끼우면 됩니다.

2.1 갈아 끼울 첫 자리, style 폴더

위니브의 style/ 폴더를 통째로 자기 회사 디자인 시스템으로 교체합니다. 갈아 끼울 때 필요한 최소 항목은 이렇습니다.

• tokens.css: 회사 브랜드 색, 그레이 스케일, 그림자
• fonts.css: 회사가 쓰는 폰트 정의 (위니브는 Pretendard)
• reset.css: 그대로 써도 됨 (브라우저 기본값 초기화)
• base.css: .max-width의 컨테이너 폭, 본문 폰트 사이즈를 회사 디자인에 맞게
• components.css: 회사 컴포넌트의 클래스 정의 (버튼, 카드, 네비 등)

Figma 디자인 시스템이 있으면 6장에서 본 Figma Dev Mode MCP로 토큰을 추출할 수 있습니다. 없으면 디자이너에게 색 팔레트와 폰트 스케일을 한 페이지에 정리해 달라고 부탁하면 됩니다.

2.2 갈아 끼울 두 번째 자리, components.md

회사 랜딩 페이지의 표준 섹션 시퀀스와 각 섹션의 마크업 패턴을 자기 것으로 다시 씁니다. 위니브 패턴이 그대로 맞는 회사는 거의 없습니다. SaaS 회사라면 가격 비교 표 섹션이 핵심이고, 이커머스라면 상품 카드 그리드가 핵심이고, 콘퍼런스 페이지라면 연사 그리드와 일정표가 핵심입니다.

다만 6장에서 본 "매번 결정하지 않게 미리 결정해 두는" 패턴 자체는 그대로 가져갑니다. 어떤 섹션이 있고, 브리프 종류별로 어느 시퀀스를 쓰고, 각 섹션의 마크업을 어떻게 짜는지가 명문화되어 있어야 결과 일관성이 잡힙니다.

2.3 갈아 끼울 세 번째 자리, brand.md

회사 톤·금지 표현·필수 표기를 자기 것으로 다시 씁니다. 위니브의 "친근하면서 차분한 설명체"가 모든 회사에 맞지는 않습니다. 어떤 회사는 격식 있는 비즈니스 톤이 맞고, 어떤 회사는 캐주얼한 친구 톤이 맞습니다.

좋은 톤 가이드의 모양은 비슷합니다. 좋은 예와 금지가 같은 자리에 적혀 있는 것. 좋은 예만 있으면 모델이 자기식으로 해석할 자리가 너무 넓고, 금지만 있으면 무엇을 해도 되는지가 막연합니다.

2.4 갈아 끼우지 않는 자리

다음 자리들은 거의 그대로 가져가도 됩니다.

• CLAUDE.md의 구조 (회사 이름과 폴더 위치만 갱신)
• SKILL.md의 6단계 작업 흐름 (브리프 받기 → 분해 → 시퀀스 결정 → 카피 작성 → HTML 생성 → 저장)
• template.html의 골격 (Top Nav, Hero, Content Blocks, Footer 자리들)

3. 여기까지, 그리고 남은 한 겹

6장과 7장을 따라오면서 우리는 하네스를 한 사람의 폴더에서 팀의 자산으로, 다시 회사의 콘텐츠 파이프라인으로 넓혀 왔습니다. 이제 위니브의 랜딩 페이지는 누가 만들어도 비슷한 품질로 나오고, 흔들린 자리가 보이면 어느 파일 어느 줄을 고쳐야 하는지도 분명합니다.

그런데 이 하네스에는 아직 사람 손이 매번 한 번씩 들어갑니다. 브리프를 던지는 것도 사람이고, 결과를 열어보고 "다시 뽑아줘"라고 말하는 것도 사람이고, 디자인 시스템이 갱신됐을 때 추출 작업을 시작하는 것도 사람입니다. 환경은 다 갖췄는데, 그 환경을 돌리는 버튼은 여전히 사람이 누르고 있습니다.

1장에서 미리 소개했던 네 번째 용어, 루프 엔지니어링이 정확히 이 자리를 다룹니다. 다음 8장에서 그 버튼을 시스템에 넘기는 방법을 봅니다.

이 자리들은 "랜딩 페이지를 자연어 브리프로 만든다"는 일 자체의 흐름이라, 회사가 달라져도 거의 같습니다. 그래서 두 번째, 세 번째 회사가 이 책의 사례를 가져갈 때는 위니브 하네스를 통째로 받아 style/·components.md·brand.md 세 자리만 갈아 끼우는 것이 가장 빠른 길입니다.