서론 (Introduction)

Claude Code에 "랜딩 페이지를 만들어줘"라고 입력해 본 엔지니어라면 누구나 똑같은 결과물을 받아본 적이 있을 것입니다. Inter 폰트, 보라색과 파란색 사이 어딘가의 그라데이션, 세 개의 플로팅 카드가 있는 히어로 섹션(hero section), 그리고 지난 2년 동안 출시된 그 어떤 SaaS 제품에도 어울릴 법한 기능 그리드(feature grid)까지 말이죠. 모델은 계속해서 발전하고 있지만, 출력물은 계속해서 비슷해 보입니다. 그 근본적인 문제는 모델의 성능(capability)이 아니었기 때문입니다. 바로 프롬프트(prompt)에 취향 신호(taste signal)가 결여되어 있었다는 점입니다.

저는 몇 주 동안 이를 단순한 프롬프팅의 기벽이 아닌 실제 엔지니어링 문제로 다루었습니다. 그 결과 도출된 워크플로우(workflow)는 충분히 견고하여, 이제 저는 제가 출시하는 모든 클라이언트 랜딩 페이지에 이 방식을 사용합니다. 이 글은 해당 워크플로우를 기록합니다. 즉, 생성 과정에 자신만의 미적 판단을 주입하는 참조 시스템(reference system)을 구축하는 방법, 어떤 도구가 실제로 유의미한 변화를 만들어내는지 아니면 단순히 한 가지 기술만 가진 도구인지, 그리고 다섯 가지의 거친 방향성에서 시작하여 수정 가능한 완성된 페이지로 나아가는 프롬프팅 및 반복 루프(iteration loop)에 대해 다룹니다.

이 중 그 어떤 것도 마법 같은 프롬프트에 관한 것이 아닙니다. 오히려 제가 보는 가장 큰 실수는 엔지니어들이 모든 것을 해결해 줄 것이라고 믿는 10,000단어 분량의 design.md 파일을 찾아 헤매는 것입니다. 그런 종류의 프롬프트는 매번 똑같이 좁은 범위의 결과물만을 만들어내며, 이는 여러분이 원하는 것과 정반대의 결과입니다.

문제 정의 (Problem Statement)

"AI 슬롭 (AI slop)"은 기술적 결함이 아닙니다. 그것은 통계적 결함입니다. 공개된 웹 데이터를 통해 학습된 대규모 언어 모델(Large Language Models, LLM)은 학습 데이터 분포에서 흔히 나타나는 평균값으로 회귀하려는 경향이 있습니다. 그리고 현재 웹 디자인에서 흔히 나타나는 것은 상당히 좁은 범위의 선택지들입니다: Inter 폰트 또는 그와 매우 유사한 기하학적 산세리프(geometric sans), 청보라색 그라데이션, 2xl 정도의 둥근 모서리(rounded corners), 부드러운 드롭 섀도(drop shadows), 3열 기능 그리드(three-column feature grids) 같은 것들 말이죠. 이 중 그 어떤 것도 그 자체로 틀린 것은 아닙니다. 문제는 여러분이 무엇을 만들고 있든 상관없이 이것이 기본 출력값(default output)이 된다는 점입니다. 모델은 여러분이 실제로 어떤 모습이기를 원하는지에 대한 정보가 없기 때문입니다.

해결책은 놀랍게도 다른 모든 불명확하게 정의된(underspecified) 생성 문제에 적용할 수 있는 것과 동일합니다. 즉, 모델에게 더 강력한 사전 지식(prior)을 제공하는 것입니다. 이 경우의 사전 지식은 사용자의 디자인 판단력을 나타내는 선별된 레퍼런스 세트로, '모던하다'나 '깔끔하다' 같은 형용사 대신 구체적인 시각적 앵커로 프롬프트에 주입됩니다. 이러한 형용사는 거의 정보를 담고 있지 못하기 때문입니다.

참고로, '모던(Modern)'과 '깔끔하다(clean)'는 디자인 프롬프트에 넣을 수 있는 가장 쓸모없는 단어 두 가지 중 하나입니다. 이들은 모델이 학습한 스타일 공간의 뚜렷한 영역에 해당하지 않기 때문에, 현재 기본값으로 설정된 모습으로 처리되어 버립니다. 레퍼런스 이미지, 스크린샷, 그리고 명명된 디자인 어휘가 토큰당 훨씬 더 많은 역할을 수행합니다.

세 가지 계층 구조 워크플로우

이 워크플로우는 서로 쌓아 올리는 세 개의 계층으로 구성됩니다. 첫 번째 계층은 AI 도구 자체를 벗어나 사용자 자신의 취향 신호(taste signal)를 구축하는 것에 관한 것입니다. 두 번째 계층은 Claude Code가 기본값에 의존하는 대신 그 신호를 바탕으로 작동할 수 있도록 기술과 MCP 서버를 설치하는 것에 관한 것입니다. 세 번째 계층은 실제 빌드 루프, 즉 광범위한 탐색(wide exploration), 좁히기(narrowing), 그리고 미세 조정 반복(fine-grained iteration)입니다.

계층 1: 취향 라이브러리 구축

대부분의 엔지니어가 저지르는 첫 번째 실수는 디자인 생성을 제로 컨텍스트 작업으로 취급하는 것입니다. 주니어 엔지니어에게 기존 아키텍처를 참고할 자료를 제공하지 않고 캐싱 계층을 구현하라고 요청하지 않을 것이며, LLM에게 특정 컨텍스트에서 '좋다'는 의미에 대한 레퍼런스를 제공하지 않고 히어로 섹션을 생성하도록 요청해서도 안 됩니다.

실질적으로 이는 Dribbble, Pinterest, 그리고 X(여전히 최고의 출처입니다. 많은 현직 디자이너들이 포트폴리오 사이트에 올라가지 않는 작업 과정샷이나 컴포넌트 분석 자료를 게시하기 때문)로 가서 레이아웃, 히어로 트릿먼트, 타이포그래피 페어링, 색상 시스템의 스크린샷을 수집하는 것을 의미합니다.

40~50개의 스크린샷이 담긴 폴더가 준비되었다면, 가장 단순한 접근 방식은 그저 폴더에 보관해 두었다가 프롬프트(prompt)를 입력할 때마다 수동으로 몇 개를 선택하는 것입니다. 이 방법도 작동은 하지만, 프로젝트가 몇 개를 넘어가면 확장성(scale)이 떨어집니다. 더 나은 접근 방식이자 제가 결국 구축하게 된 방식은, 스크린샷을 흡수(ingest)하고 이를 스타일 패밀리(style family, 예: "quiet cinematic", "print tech paper", "dither mono" 등)별로 그룹화하며, 각 클러스터에 대해 추출 가능한 프롬프트 조각(prompt fragment)과 함께 짧은 디자인 어휘(design vocabulary) 설명을 생성하는 작은 내부 웹 앱을 만드는 것입니다.

// lib/taste-library/classify.ts
// 스크린샷이 흡수(ingest) 폴더에 드롭된 후 실행됩니다.
// 비전 기능이 있는 모델(vision-capable model)을 사용하여 스타일 패밀리를 태깅하고, 추출합니다...

json|/g, "").trim());
return {
id: crypto.randomUUID(),
imagePath: "", // 업로드 후 호출자에 의해 채워짐
...

이것은 흡수(ingest) UI를 포함하여 약 200줄 정도의 작은 유틸리티에 불과하지만, 여러분이 작성할 모든 미래의 프롬프트 형식을 바꿔 놓습니다. "현대적으로 만들어줘"라고 말하는 대신, "내 라이브러리에서 quiet cinematic 패밀리를 사용해줘"라고 말할 수 있게 되며, Claude Code는 형용사가 아닌 실제 어휘와 참조 세트(reference set)를 바탕으로 작업을 수행하게 됩니다.

## 레이어 2: 설치할 가치가 있는 스킬(Skills)과 MCP

Claude Code의 기본 프론트엔드 출력물은 합리적인 기준점(baseline)이 되지만, 여러분이 의견을 주지 않는 한 결과물의 품질 저하(slop)에 대해서는 아무런 의견을 내지 않습니다. 저에게 일관되게 큰 차이를 만들어낸 세 가지 추가 요소가 있으며, 저는 GitHub에서 유행하는 대부분의 좁은 의미의 "단일 디자인 스타일" 스킬들은 피하라고 권하고 싶습니다. 왜냐하면 그러한 스킬들은 유연한 도구 모음(toolkit)을 제공하기보다 여러분을 단 하나의 룩(look)에 가두는 경향이 있기 때문입니다.

| 도구 | 유형 | 실제 기능 | 최적의 용도 |
|---|---|---|---|
| Impeccable | 스킬, 23개 명령어 | 타이포그래피, 색상, 공간 레이아웃, 반응성, 상호작용, 모션 및 UX 카피에 대해 타겟팅된 비평(critique) 및 수정 단계를 실행합니다. 품질 저하 분류 체계(slop taxonomy, 46개 명명된 패턴)와 컴포넌트 수준의 검토를 위한 라이브 개발 서버(live dev-server) 모드를 제공합니다. | 기존 페이지에 대한 생성 후 다듬기(polish) 및 품질 저하(slop) 탐지 |
| ... | | | |
![](https://static.zenn.studio/user-upload/e163bdfb1c8e-20260727.png)

Impeccable을 특별히 언급할 가치가 있는 이유는 그 명령어 세트가 막연한 "더 좋게 만들어줘"가 아니라 실제 디자인 리뷰 체크리스트에 매핑되기 때문입니다. `bolder`, `overdrive`, `clarify`와 같은 명령어들은 시각적 혼란을 초래하지 않으면서 대비와 스케일을 높이거나, 장황한 UX 카피를 압축하거나, 간격 리듬(spacing rhythm)을 조밀하게 만드는 것과 같이 구체적이고 설명 가능한 변환에 대응합니다. 이러한 구체성 덕분에 일회성 수정이 아닌 CI(지속적 통합)와 유사한 루프 내에서 사용이 가능해집니다.

CLI를 통해 Impeccable을 설치한 후, 컴포넌트 디렉토리에 대해 타겟팅된 패스(pass)를 실행합니다

npx impeccable-cli install
...

경고: Skills와 MCP는 추가적인 요소일 뿐, Layer 1의 취향 라이브러리를 대체할 수 없습니다. Impeccable과 같은 도구는 일반적인 slop(품질 저하) 패턴을 기꺼이 제거하겠지만, 당신이 페이지에서 구체적으로 어떤 느낌을 원하는지는 알지 못합니다. 이미 참조 미학(reference aesthetic)이 고정된 페이지를 입력하면 그 미학을 개선할 것입니다. 하지만 기본 Claude 출력물을 입력하면, 그저 똑같은 기본 외형을 더 다듬어진 버전으로 만들어낼 뿐입니다.

Higgsfield은 실제적인 역량 격차를 해결하기 때문에 별도로 언급할 가치가 있습니다. Claude Code는 네이티브하게 이미지를 생성할 수 없으므로, MCP 브릿지가 없다면 모든 히어로 배경(hero background)은 스톡 소스에서 가져오거나 SVG/CSS 조합으로 구축되어야 합니다. 이 두 방식 모두 현재 "AI slop" 시각적 어휘에서 매우 흔하게 나타나는 방식입니다(3D 그라데이션 블롭(blob)은 거의 식별 표식과 같습니다). 이미지 생성 MCP를 연결한다는 것은 히어로 배경을 당신이 지정한 해상도와 스타일로 새롭게 생성할 수 있으며, 카피를 반복 수정하듯 동일한 방식으로 반복(iterate)할 수 있음을 의미합니다.

## Layer 3: 빌드 루프 (The Build Loop)

이 부분은 대부분의 사람들이 실수하는 지점이며, 이는 도구의 문제가 아니라 워크플로우의 문제입니다. 본능적으로는 매우 구체적인 하나의 긴 프롬프트를 작성하고 단 한 번의 시도(one-shot)로 결과가 나오기를 기대하게 됩니다. 이는 코드 리뷰에서 좋지 않은 전략인 것과 같은 이유로 나쁜 전략입니다. 단일 출력물을 고립된 상태에서 평가하는 것은 여러 출력물을 서로 비교하는 것만큼 잘 해낼 수 없기 때문입니다.

### 4단계 프롬프트

제가 탐색 단계에서 보내는 모든 프롬프트에는 의도적으로 다음 순서로 네 가지 정보가 담겨 있습니다:

- **미학 (Aesthetic).** 취향 라이브러리에서 가져온 이름 지정된 스타일 계열, 예: "조용한 시네마틱(quiet cinematic), 광활한(vast), 미니멀한(minimal), 산맥 이미지". -
- **참고 자료 (Reference).** 설명이 아닌 실제 스크린샷이나 URL. 레이아웃 리듬을 좋아하는 사이트가 있다면 URL을 바로 첨부하세요. Claude Code가 읽을 수 있습니다. -
- **의도 (Intent).** 페이지의 목적, 대상 사용자, 그리고 단일 주요 행동(데모 예약, 가입, 문서 읽기)이 무엇인지. 이것이 미학이 사용성을 압도하는 것을 막아줍니다. -
- **제약 조건 (Guardrails).** 명시적인 제외 목록. 여기에 개인적으로 피하고 싶은 패턴을 직접 지정합니다: 보라색에서 파란색으로의 그라디언트는 안 됨, Inter 폰트 사용 금지, 떠다니는 3D 오브젝트 금지, 자동 재생 캐러셀 금지.

Kestrel이라는 초기 단계 스타트업을 위한 AI 분석 플랫폼 랜딩 페이지를 만들어 주세요.
미학: 제 취향 라이브러리에서 가져온 조용한 시네마틱 계열 (id: qc-04).
...

처음부터 다섯 가지 변형(variants)을 요청하는 것이 이 전체 워크플로우에서 가장 높은 레버리지 효과를 가진 변화입니다. 반복할 때 토큰 비용이 더 들지만, 그렇지 않았다면 네댓 번의 순차적인 "아니요, 다시 시도해 보세요" 과정을 한 비교 과정으로 압축합니다. 방향을 결정한 후에는 같은 패턴이 한 단계 아래에서 반복됩니다: 선택된 미학에 대한 본문 레이아웃 세 가지 변형, 그리고 그게 정해지면 자산 생성 및 세부 작업입니다.

### 이산적인 단계로서의 자산 생성 (Asset generation as a discrete step)

히어로 이미지(hero imagery)를 레이아웃과 같은 요청에서 요구하지 마세요. 레이아웃과 이미지는 분리 가능한 관심사이며, 이를 묶어 처리하면 어느 한 쪽을 독립적으로 반복하기가 더 어려워집니다. 방향이 확정되면 MCP를 통해 네 가지 후보 히어로 이미지를 목표 해상도로 생성하고, 그 이미지들을 서로 비교한 다음 페이지에 하나로 연결하세요.

// Higgsfield MCP가 연결된 상태에서 Claude Code가 발행하는 도구 호출의 예시입니다.
// 실제 백그라운드에서 무슨 일이 일어나는지 명확히 보여주기 위해 여기에 표시했습니다.
...

![](https://static.zenn.studio/user-upload/96ec5794abd2-20260727.png)

처음부터 새로운 프롬프트를 작성하는 대신 참조 이미지 (reference image)를 첨부하여 재생성하는 것은 보기보다 훨씬 중요합니다. 이는 구성을 고정된 상태로 유지하면서 실제로 테스트하고자 하는 파라미터(parameter)만 변경할 수 있게 해주며, 이는 다른 실험에서 변수를 격리할 때 적용하는 방식과 정확히 동일한 원칙입니다.

### 트윅 바 (The tweak bar)

레이아웃과 마음에 드는 히어로 (hero) 이미지가 결정되면, 남은 작업은 폰트 페어링 (font pairing), 강조 색상 (accent color), 간격 리듬 (spacing rhythm), 그리고 모션 타이밍 (motion timing)입니다. 이 작업들은 페이지 전체를 다시 생성하는 방식으로는 전혀 이득을 얻을 수 없습니다. Claude Code에게 서로 다른 폰트를 사용하여 페이지 전체를 열 번 다시 생성하라고 요청하는 것은 느릴 뿐만 아니라, 나란히 비교 (side-by-side comparison)하는 것도 어렵게 만듭니다. 더 나은 방법은 Claude Design이 제공하는 방식과 유사하게, 개발 빌드 (dev build)에 직접 작은 라이브 제어 패널 (live control panel)을 스캐폴딩 (scaffold)하도록 하여, 재빌드 과정 없이 변경 사항이 즉시 적용되도록 하는 것입니다.

```tsx
// components/dev/TweakBar.tsx
// 개발 빌드에서만 주입됩니다. 디자인 토큰 (design tokens)을
// 실시간 편집 가능한 CSS 커스텀 속성 (CSS custom properties)으로 노출합니다.
...

이 기능은 의도적으로 개발 빌드에만 한정되어 있으며, 전체 컴포넌트 트리 (component tree)를 다시 렌더링하는 대신 CSS 커스텀 속성을 통해 변경 사항을 적용하므로, 폰트 페어링이나 강조 색상을 전환하는 것이 즉각적입니다. 적용 범위는 의도적으로 좁게 유지됩니다 (타이포그래피, 강조 색상, 모션 가중치, 노출 거리). 너무 공격적인 트윅 인터페이스는 결국 관리해야 할 또 다른 디자인 도구가 되어버리기 때문입니다.

성능 및 프로덕션 고려 사항 (Performance and Production Considerations)

이 워크플로우를 통해 실제로 배포할 페이지가 제작되면 몇 가지 고려해야 할 사항이 있습니다.

생성된 히어로 이미지는 MCP에서 <img>로 직접 연결되는 경로가 아닌, 실제 에셋 파이프라인 (asset pipeline)이 필요합니다. 모든 것을 이미지 최적화 (AVIF/WebP 및 JPEG 폴백 포함), 반응형 srcset을 통해 처리하십시오.

, 그리고 적절한 캐시 헤더 (cache headers)를 갖춘 CDN)를 거쳐 프로덕션 (production) 근처에 가기 전에 처리해야 합니다. 이미지 모델에서 바로 나온 2K PNG 파일은 쉽게 4-8MB에 달하며, 이는 디자인이 아무리 훌륭하더라도 LCP (Largest Contentful Paint) 점수를 망가뜨릴 것입니다.트윅 바 (tweak bar)는 절대로 프로덕션에 배포되어서는 안 됩니다. 위에서 보여준 것처럼 NODE_ENV 뒤에 숨기거나, 더 나은 방법으로는 명시적인 피처 플래그 (feature flag) 뒤에 숨겨야 합니다. 왜냐하면 공개된 페이지에 라이브 스타일 편집 패널이 노출되는 것은 UX 측면에서 위험 요소일 뿐만 아니라, 미세한 보안 취약점 (anyone can repaint your marketing site and screenshot it, 즉 누구나 마케팅 사이트를 다시 칠하고 스크린샷을 찍을 수 있음)이 될 수 있기 때문입니다.