1. 위니브가 마주한 문제

지난 1년 동안 위니브에는 새 랜딩 페이지를 만들 일이 빠르게 늘었습니다. AI 콘텐츠 라이브러리, AI 부트캠프, 제주 AI 워크숍, 제주 디지털 전환 행사. 도메인 하나가 한 주 단위로 새로 열렸습니다.

aicontents.weniv.co.kr
aiboot.weniv.co.kr
aid.weniv.co.kr
jejuax.weniv.co.kr
...

빨라야 하는 만큼 흔들리는 것은 퀄리티였습니다. 같은 회사가 만든 페이지인데 어떤 페이지는 톤이 다르고, 어떤 페이지는 같은 의도의 버튼이 조금씩 다르게 생겼고, 또 어떤 페이지는 여백이 어색하게 잡혔습니다. 디자이너 손이 매번 들어갈 수는 없고, 개발자가 매 페이지를 처음부터 짤 수도 없는 상황이었습니다.

오랜 시간 공들여 잘 정리한 페이지도 있었습니다. weniv.co.kr 메인, books.weniv.co.kr, weniversity.co.kr 같은 사이트들은 연단위로 개발이 들어갔기에 디자인 시스템을 충실히 지켰습니다. 톤도, 버튼 모양도, 섹션 간격도 일관됐습니다.

"같은 회사, 같은 디자인 시스템으로 짧은 기간에 이미 있는 자산을 활용해 퀄리티 있는 페이지를 찍어낼 수 있는 방법이 있을까?"

이 질문이 이 장의 출발점입니다.

1.1 흔들린 페이지 vs 잘 지킨 페이지의 공통점

흔들린 페이지들은 모두 "급하게 만들어야 했던" 페이지들이었습니다. 한 사람이 한 페이지를 며칠 안에 끝내야 하는 상황. 잘 지킨 페이지들은 시간이 충분했거나, 디자인팀의 손이 직접 들어간 페이지들이었습니다.

그래서 표면적인 답은 명확합니다. "시간이 부족하면 일관성이 무너진다." 그런데 그 답으로 끝나면 해결책은 "사람을 더 뽑자" 또는 "일정을 더 늘리자"가 됩니다. 두 가지 다 현실적으로 어렵습니다.

문제를 더 자세히 들여다보면 다른 모양이 보입니다. 흔들린 페이지를 만든 사람들이 디자인 시스템을 모르는 것은 아니었습니다. 토큰 파일도, 컴포넌트 라이브러리도, 가이드 문서도 있었습니다. 다만 그것들이 여러 곳에 흩어져 있어서 매번 찾아 쓰기 부담스러웠을 뿐입니다. Figma는 거기, CSS 변수는 저기, 회사 카피 가이드는 또 다른 노션 페이지. 이걸 한 페이지 만들 때마다 다시 모아 쓰는 일이 일이었습니다.

4장에서 본 컨텍스트 엔지니어링의 통증이 그대로입니다. 필요한 정보가 흩어져 있으면 매번 깔리지 못합니다.

1.2 그래서 우리에게 필요한 것

처음 떠오르는 해결책은 "더 잘 정리된 디자인 가이드 문서"입니다. 그런데 위니브에는 이미 가이드 문서가 있었습니다. 가이드가 더 두꺼워진다고 페이지 일관성이 올라가는 건 아닙니다. 페이지를 만드는 사람이 가이드를 매번 읽고 적용해야 하니까요.

다음으로 떠오르는 해결책은 "자동 생성 도구"입니다. 디자이너가 Figma에서 디자인을 잡으면 코드가 자동으로 뽑히는 도구. 다만 위니브의 상황에서는 잘 맞지 않았습니다. 매 페이지마다 디자이너가 Figma를 손대야 하는데, 그 자체가 부족한 시간을 더 잡아먹는 일이었습니다.

이 장에서 우리가 만들 것은 다른 형태입니다. 자연어 브리프 한 줄을 받아, 위니브 디자인 시스템대로 정적 HTML 한 장을 찍어내는 작은 하네스입니다.

사용자: "제주 사계에서 4박 5일 AI 코딩 캠프 모객용 랜딩. 타겟은 30대 비개발 직군. CTA는 무료 신청."

하네스: → output/jeju-camp.html 생성(Top Nav → Hero → 추천 대상 → 커리큘럼
                  → 가격 → FAQ → 디스코드 CTA → Footer)

사용자: 브라우저로 열어보고, 마음에 들면 그대로 배포. 톤이 어색한 줄을 한 번 손보고 끝.

비유로 풀면 이렇습니다. 우리에게 필요한 것은 "더 잘하는 사람"이 아니라, 누가 와도 같은 속도로 퀄리티의 페이지가 나오게 하는 것입니다. 디자인 시스템을 한 번 잘 깔아두고, 카피 가이드를 한 번 잘 정리해두고, 페이지 조립 방법을 한 번 잘 명문화해두면, 그 자리에서 누가 어떤 브리프를 던져도 큰 차이 없는 결과가 나오는 자리.

2장에서 만든 글쓰기 하네스와 정확히 같은 발상입니다. 거기서는 IT 책 한 절을 쓰는 자리(환경)를 만들었습니다. 이번 장에서는 위니브 랜딩 페이지 한 장을 만드는 자리(환경)를 만듭니다.

2. 폴더 한 칸 차려주기

2장 비유를 다시 빌려옵니다. 신입이 출근했을 때 책상 한 칸을 내주는 방식. 이번에는 신입이 "랜딩 페이지를 만드는 사람"이고, 책상 위에는 다음 자료들이 정해진 자리에 깔려 있어야 합니다.

• 책상 위 안내판: 이 자리에서 무슨 일을 하는지, 어떤 요청이 오면 무엇을 먼저 봐야 하는지
• 디자인 시스템 폴더: 색, 폰트, 컴포넌트가 정리된 자체완결 폴더 (위니브가 이미 만들어둠)
• 컴포넌트 카탈로그: 디자인 시스템에는 없는 "랜딩 페이지 조립 방법" 정리본
• 카피 컨벤션: 톤과 금지 표현 정리본
• 작업 매뉴얼 (사수 카드): 어떤 순서로 일하라
• 출력 골격: 페이지 한 장의 기본 뼈대
• 산출물 서랍: 만들어진 페이지가 모이는 곳

이 일곱 가지가 폴더와 파일로 그대로 옮겨지면 이런 모양이 됩니다.

landing-실습/
├── CLAUDE.md                          ← 책상 위 안내판
├── components.md                      ← 랜딩 조립 방법
├── brand.md                           ← 카피 컨벤션
├── style/                             ← 디자인 시스템 자체완결 폴더
│   ├── tokens.css                       (색·그림자 CSS 변수)
│   ├── fonts.css                        (Pretendard 정의)
│   ├── reset.css                        (브라우저 기본값 초기화)
│   ├── base.css                         (.max-width, 유틸 클래스)
│   ├── components.css                   (.btn, .card, .nav-pill ...)
│   └── index.css                        (위 5개를 한 번에 import)
├── .claude/skills/landing/
│   ├── SKILL.md                       ← 작업 매뉴얼
│   └── template.html                  ← 출력 골격
└── output/                            ← 산출물 서랍
    └── {brief-slug}.html

처음 보면 항목이 많아 보이지만, 각 파일이 들어가는 글은 한 페이지를 넘지 않는 짧은 안내문입니다. 이어지는 6-2에서 각 파일에 정확히 무엇을 적었는지 하나씩 펼쳐 봅니다.

3. 위니브의 출발점, 이미 가지고 있던 것들

이 장에서 위니브가 새로 만든 것은 사실 많지 않습니다. 이미 가지고 있던 자산을 한 자리에 모은 일이 핵심입니다. 모으는 자리가 곧 하네스가 됩니다.

위니브가 이미 가지고 있던 것을 정리하면 이렇습니다.

3.1 디자인 시스템 Figma

위니브 메인 도메인의 디자인을 정의한 Figma 파일이 사내에 있었습니다. 색 토큰, 폰트 스케일, 컴포넌트 라이브러리가 페이지 단위로 정리되어 있었습니다.

3.2 디자인 시스템 추출본 weniv_design_generator

위니브는 이미 하네스가 아닌 style 형태로 Figma 디자인 시스템을 별도로 추출하는 작업을 해두었습니다. 토큰, 폰트, 컴포넌트가 자체완결된 CSS 모음으로, 다른 프로젝트로 복사만 하면 그대로 동작합니다. 이건 위니브 내부 사용을 위해 만든 자산이었는데, "다른 프로젝트로 갖다 쓰는 디자인 시스템"의 모양이 이미 잡혀 있었습니다. 이미 있는 폴더이니 그대로 하네스에 깔아두면 됩니다.

3.3 카피 톤 운영 사이트들

회사 메인 페이지, 위니버시티, 위니북스 같이 디자인 시스템을 잘 지킨 사이트들이 톤의 기준이 됩니다. 메인 헤드라인의 길이, 줄바꿈 자리, CTA 문구의 동사형, 푸터의 회사 정보 표기까지. 이 톤을 한 페이지짜리 문서(brand.md)로 정리하면 다음 페이지를 만들 때마다 같이 깔립니다.

3.4 Figma Dev Mode MCP

Figma가 최근 데스크톱 앱에 내장한 MCP 서버를 통해, 우리는 디자인 시스템 파일을 모델이 직접 읽도록 연결할 수 있었습니다. 이 작업은 책 독자가 따라할 필요는 없습니다. 책에서는 결과물 형태로만 제공할 예정입니다.

3.5 독자가 받게 될 것

이 책을 따라 실습하실 분이 직접 만지지 않아도 되는 것과 그대로 받아 쓰는 것이 분명히 나뉩니다. 만약 여러분이 위니브처럼 이미 구축되어 있는 디자인 시스템이 없다면 '독자가 받아서 쓸 것'의 항목을 여러분이 처음부터 만들어야 합니다. 이렇게 하나씩 마음에 들게 구축하는 작업을 SNS에서는 '하네스 깎는다'라고 표현하기도 합니다.

위니브 내부에서 한 일 (독자는 안 해도 됨)

• 위니브 디자인 시스템 Figma 파일 만들기
• Figma 디자인 시스템을 vanilla CSS 폴더로 추출 (weniv_design_generator 작업)
• 운영 사이트들에서 카피 톤 분석
• Figma Dev Mode MCP 연결

독자가 받아서 쓸 것

• style/ 폴더 통째 (위니브가 추출해둔 디자인 시스템)
• components.md (랜딩 조립 방법)
• brand.md (카피 컨벤션)
• CLAUDE.md, .claude/skills/landing/SKILL.md, template.html (하네스 본체)

이 일곱 개를 받아서 자기 폴더에 그대로 두면, 그 폴더에서 Claude Code를 열고 자연어 브리프 한 줄을 던지는 일만 남습니다. 6-3에서 그 흐름을 따라가게 됩니다.

4. 만약 아무것도 없다면

위니브처럼 이미 디자인 시스템이 어느 정도 갖춰져 있는 상황이 아니라면, 이 장에서 다루는 내용은 여러분이 처음부터 만들어야 하는 내용이 됩니다. 디자인 시스템 자체도, 랜딩 페이지 조립 방법도, 카피 톤 가이드도, 작업 매뉴얼도, 출력 골격도. 모두 처음부터 만들어야 합니다. 다만 GitHub에 가보면 다양한 하네스가 이미 공개되어 있습니다. 그중에서 여러분이 가장 마음에 드는 것을 골라서 시작하시면 됩니다.