Developmenttutorial시작 추천

AI가 만든 웹사이트에 취향을 부여하기(feat. taste-skill)

2026-08-20

이 Skill을 검증하는 이유

AI로 웹사이트를 만들다 보면 결과물의 레이아웃과 디자인이 묘하게 비슷해지는 순간을 마주하게 된다. 카드형 히어로 섹션, 정형화된 그리드 배치, 익숙한 색 조합이 반복되면서 "사람이 직접 만든 것 같은" 개성 있는 디자인과는 점점 멀어지는 느낌이었다.

Taste Skill은 이런 문제를 정면으로 다루는 오픈소스 스킬로, AI 코딩 에이전트에 디자인 취향과 기준을 부여해 흔한 결과로 수렴하는 것을 막는다.

레이아웃 파격도, 모션 강도, 정보 밀도를 1~10 척도로 조절하고, 코딩에 들어가기 전 페이지 종류·대상 사용자·분위기를 먼저 정의하게 해 AI가 임의로 흔한 디자인을 선택하지 않도록 유도하는 것이 핵심이다.

레이아웃 파격도, 모션강도, 정보밀도

이 스킬은 화면을 생성할 때 세 가지 파라미터로 결과물의 성격을 조절합니다. 각 파라미터는 독립적으로 작동하며, 조합에 따라 완전히 다른 인상의 화면이 만들어집니다.

레이아웃 파격도 (Variance)

화면 배치가 정형화된 틀에서 얼마나 벗어나는지를 나타내는 값입니다. 값이 낮으면 그리드에 맞춘 대칭적이고 예측 가능한 배치가 되고, 값이 높으면 요소가 겹치거나 기울거나 비대칭적으로 배치되는 실험적인 레이아웃이 됩니다.

다음은 이 값이 결과에 미치는 영향을 보여주는 의사코드입니다(실행 가능한 코드가 아니라 개념을 설명하기 위한 예시입니다).

# 의사코드 - 실제 동작하는 코드가 아닙니다
if variance < 30:
    layout = 정렬된_그리드(columns=12, align="center")
elif variance < 70:
    layout = 부분_비대칭_배치(offset=random(small))
else:
    layout = 자유_배치(overlap=true, rotation=random(large))

값이 낮을수록 안정감과 가독성을 우선하는 화면에 적합하고, 값이 높을수록 시선을 끄는 개성 있는 화면에 적합합니다.

모션 강도 (Motion)

사용자의 행동(클릭, 스크롤, 호버 등)에 화면이 얼마나 적극적으로 반응하며 움직이는지를 나타내는 값입니다. 값이 낮으면 정적인 화면에 최소한의 전환 효과만 들어가고, 값이 높으면 스크롤에 따라 요소가 크게 움직이거나 순차적으로 나타나는 등 동적인 연출이 강조됩니다.

# 의사코드 - 실제 동작하는 코드가 아닙니다
on scroll(position):
    if motion < 30:
        opacity = fade(position)  # 단순한 페이드만 적용
    elif motion < 70:
        transform = move_and_fade(position)
    else:
        transform = parallax_and_scale(position, intensity="high")

값이 낮을수록 콘텐츠 전달에 집중하는 화면에 적합하고, 값이 높을수록 몰입감과 인상을 중시하는 화면에 적합합니다.

정보 밀도 (Density)

한 화면에 얼마나 많은 정보와 UI 요소를 동시에 보여주는지를 나타내는 값입니다. 값이 낮으면 여백을 넉넉히 두고 핵심 요소만 노출하며, 값이 높으면 하나의 화면 안에 더 많은 텍스트, 카드, 버튼 등이 촘촘하게 배치됩니다.

# 의사코드 - 실제 동작하는 코드가 아닙니다
if density < 30:
    show(핵심_요소만, spacing="large")
elif density < 70:
    show(핵심_요소 + 보조_정보, spacing="medium")
else:
    show(전체_정보, spacing="small")

값이 낮을수록 여백을 살린 미니멀한 화면이 되고, 값이 높을수록 대시보드처럼 많은 정보를 한눈에 파악해야 하는 화면에 적합합니다.

이 세 파라미터는 서로 독립적으로 조절되므로, 예를 들어 파격도는 낮고 밀도는 높은 화면(정돈된 그리드 안에 정보가 촘촘한 대시보드)이나 파격도는 높고 모션은 낮은 화면(비대칭 배치이지만 정적인 아트워크형 페이지)처럼 다양한 조합을 만들 수 있습니다.

Taste Skill 검증 시나리오

검증 목표

동일한 랜딩 페이지 제작 프롬프트를 두 조건(Taste Skill 미적용/적용)에서 각 3회씩 반복 실행하여, 프롬프트에 명시된 레이아웃 파격도(8), 모션 강도(6), 정보 밀도(4) 지시가 결과물에 얼마나 일관되게 반영되는지 비교합니다. 검증 대상은 Claude Code 2.1.234 + claude-sonnet-5 조합에서의 재현성이며, 다른 에이전트나 모델 일반의 성능으로 확대 해석하지 않습니다.

시작 상태

저장소: github.com/blueRyans/brave-blog-skill-verify
대상 경로: web-generation
기준 커밋: 53e3c69
Skill: github.com/Leonxlnx/taste-skill (main), 커밋 dfb6f9f9e93a39f673b1827c0889cc28326d1800

전제 조건

저장소를 커밋 53e3c69 기준으로 clone 및 checkout
Claude Code 2.1.234 설치 및 로그인 상태 확인
모델을 claude-sonnet-5로 고정
Windows 11 Pro 10.0.26100 환경에서 실행 (동일 OS·셸 조건 유지)
baseline 실행용 작업 폴더와 skill 적용 실행용 작업 폴더를 분리 (동일 프롬프트를 서로 다른 세션에 주입하기 위함)
taste-skill을 커밋 dfb6f9f... 기준으로 설치하되, baseline 3회 실행 동안은 비활성/미설치 상태 유지

동일 프롬프트

B2B SaaS 랜딩 페이지를 제작합니다.
대상은 기술 구매자이며, 전체 분위기는 세련되고 전문적인 에이전시 스타일로 구성합니다.
- 레이아웃 파격도: 8
- 모션 강도: 6
- 정보 밀도: 4
- 흔한 중앙 정렬 히어로 + 3개 카드 구조는 피합니다.
- 시각적 계층과 비대칭 레이아웃을 적극적으로 사용합니다.
- 과도한 정보 배치는 피하고 충분한 여백을 유지합니다.

실행 방법

web-generation 경로에서 새 세션을 시작하고, skill을 적용하지 않은 상태로 동일 프롬프트를 실행합니다. 결과물을 run-base-1로 저장합니다.
이전 대화 맥락을 초기화한 새 세션에서 같은 절차를 2회 더 반복해 run-base-2, run-base-3를 만듭니다.
taste-skill(커밋 dfb6f9f...)을 설치한 뒤, 매번 새 세션에서 동일 프롬프트를 3회 반복 실행해 run-skill-1, run-skill-2, run-skill-3를 만듭니다.
각 실행은 이전 실행의 대화 기록이나 생성 파일을 참조하지 않도록 독립된 폴더/커밋으로 분리합니다.

검증 방법

각 실행 결과에서 다음 세 지표를 코드 기준으로 확인합니다.

레이아웃 파격도: 히어로 섹션이 중앙 정렬 단일 컬럼 구조인지, 그리드가 비대칭(grid-template-columns 비율 불균등, 요소 겹침·오프셋 배치)으로 구성됐는지 여부
모션 강도: 사용된 transition/animation 속성의 개수와 duration 값, 스크롤 연동 효과 존재 여부
정보 밀도: 주요 섹션 하나당 자식 요소(텍스트 블록, 카드, 버튼 등) 개수와 섹션 간 여백(padding/margin) 크기

측정한 값을 아래 표에 실행별로 기록해 baseline과 skill 적용 결과의 일관성(3회 간 편차)을 비교합니다.

실행	레이아웃 파격도 관찰	모션 강도 관찰	정보 밀도 관찰
run-base-1	(확인 필요: 실제 생성 결과의 그리드/레이아웃 구조 기록)	(확인 필요: transition/animation 속성 값 기록)	(확인 필요: 섹션별 요소 개수 기록)
run-base-2	(확인 필요: ...)	(확인 필요: ...)	(확인 필요: ...)
run-base-3	(확인 필요: ...)	(확인 필요: ...)	(확인 필요: ...)
run-skill-1	(확인 필요: ...)	(확인 필요: ...)	(확인 필요: ...)
run-skill-2	(확인 필요: ...)	(확인 필요: ...)	(확인 필요: ...)
run-skill-3	(확인 필요: ...)	(확인 필요: ...)	(확인 필요: ...)

일관성 판단 기준은 각 조건(baseline 3회, skill 3회) 내에서 위 세 지표가 프롬프트 목표치(8/6/4)에 얼마나 근접하고 편차가 적은지이며, 조건 간 편차 폭을 비교해 Taste Skill 적용 여부에 따른 차이를 판단합니다. 실행 결과가 채워지기 전까지 위 표의 값은 자리표시자 상태로 유지하며, 임의의 수치나 감상으로 대체하지 않습니다.

Claude Code에 taste-skill 설치하기

전제 조건

Node.js와 npx를 사용할 수 있는 환경
web-generation 프로젝트가 로컬에 준비되어 있을 것

실행 방법

web-generation 프로젝트 루트 디렉터리에서 아래 명령어를 실행합니다.

# macOS/Linux, web-generation 프로젝트 루트에서 실행
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

설치가 완료되면 프로젝트 내에 스킬 폴더가 생성되고, 그 안에 SKILL.md 파일이 함께 생성됩니다.

검증 방법

설치된 스킬 폴더를 열어 SKILL.md 파일이 존재하는지 확인합니다. 이 파일의 install name이 design-taste-frontend로 표시되어 있으면 정상적으로 설치된 것입니다.

Codex에서는 무엇이 다른가

Claude Code에서는 다음 명령으로 기본 v2 taste-skill을 설치합니다.

npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

Codex에서는 동일한 CLI 설치 방식을 쓰지만, 설치하는 스킬 이름이 다릅니다. README에 따르면 gpt-taste는 GPT/Codex 전용으로 강화된 변형으로, 더 강한 레이아웃 다양성과 GSAP 방향성, 더 공격적인 anti-slop 처리를 특징으로 합니다. Codex 환경에서는 기본 스킬 대신 이 버전을 쓰는 것이 공식 권장 사항입니다.

npx skills add https://github.com/Leonxlnx/taste-skill --skill "gpt-taste"

두 명령 모두 동일한 저장소를 가리키지만 --skill 옵션으로 지정하는 대상만 다르므로, 설치 자체의 흐름이나 전제 조건은 Claude Code 쪽과 동일합니다. 설치 후 파일이 위치하는 경로나 Codex 쪽 설정 파일 반영 여부는 (확인 필요: Codex에서 설치된 스킬 파일의 정확한 경로 또는 설정 반영 방식)입니다.

Skill 적용 전후 비교

검증 시나리오: 동일한 프롬프트와 실행 환경에서 Skill 적용 여부만 변경해 레이아웃 구조·모션·정보 밀도의 차이를 확인.

관찰 항목	Skill 적용 전	Skill 적용 후
디자인 결정 기준	레이아웃 파격도·모션 강도·정보 밀도에 대한 명확한 기준 없이 Agent가 임의로 결정	페이지 종류, 대상 사용자, 무드를 먼저 정의한 뒤 이를 기준으로 디자인 방향을 제어
결과물 패턴	중앙 정렬 히어로, 3개 카드, 그라데이션 등 일반적인 AI 기본 디자인 패턴이 반복됨	일반적인 AI 디자인 패턴에서 벗어나 프롬프트에서 요구한 디자인 성격이 더 명확하게 반영됨
파격도·모션·밀도 제어	별도 기준 없음	레이아웃 파격도·모션 강도·정보 밀도 값을 기준으로 제어

두 결과 모두 스크린샷이나 실행 로그 형태의 증거는 제공되지 않았다(적용 전·후 증거 모두 "없음"). 따라서 위 비교는 제공된 요약 설명에 근거한 것이며, 실제 화면상의 레이아웃 구조나 모션 차이를 시각적으로 확인한 결과는 아니다. (확인 필요: 적용 전/후 스크린샷 또는 실행 로그)

평가표

측정 요약 (3회 측정 기준 중앙값)

평가 항목	적용 전 중앙값	적용 후 중앙값	근거로 명시된 측정 방식	표기된 측정 방식
시각적 위계	2	4	블라인드 순서로 화면을 놓고 제목·부제·CTA 대비를 채점	작성자 판단
고유성	2	4	동일한 블라인드 비교로 흔한 패턴 탈피 여부를 채점	작성자 판단
반응형 완성도	4	4	3개 뷰포트 스크린샷에서 레이아웃 깨짐 여부를 자동 확인	작성자 판단(표기됨, 근거는 자동 측정 방식)
접근성	3	3.5	Lighthouse/axe-core 접근성 점수(100점 만점)	작성자 판단(표기됨, 근거는 자동 측정 방식)
기능 정확성	4	5	빌드 성공 여부, 콘솔 에러 0건, 링크·버튼 동작 확인	작성자 판단(표기됨, 근거는 자동 측정 방식)

데이터 확인이 필요한 부분

반응형 완성도, 접근성, 기능 정확성은 표기된 측정 방식이 "작성자 판단"이지만, 근거 설명은 스크린샷 자동 비교, Lighthouse/axe-core 점수, 빌드·콘솔 로그 확인처럼 자동 측정 절차를 가리킵니다. 표기와 근거가 일치하지 않아 그대로 두되, 이 섹션에서는 근거 텍스트를 기준으로 자동 측정 항목으로 구분해 표시했습니다. (확인 필요: 실제 측정 방식이 작성자 판단인지 자동 측정인지 원본 로그 확인)
접근성 적용 후 값은 3회가 아닌 2회(3, 4) 측정치로 제공되어 채점 규칙(3회 측정)과 맞지 않습니다. 제공된 두 값의 중앙값(3.5)을 그대로 사용했으나, 세 번째 측정값이 없는 상태임을 밝힙니다. (확인 필요: 접근성 적용 후 3회차 측정값)
기능 정확성의 근거 텍스트에는 접근성 항목과 동일한 "Lighthouse 또는 axe-core 접근성 점수" 문구가 앞부분에 포함되어 있어, 접근성 근거가 잘못 복사된 것으로 보입니다. 뒤에 이어지는 "빌드 성공 여부, 콘솔 에러 0건, 링크·버튼 동작 확인" 부분만 기능 정확성 고유 근거로 판단했습니다. (확인 필요: 기능 정확성 근거 문구 정리)

이 실험 범위 안에서의 결론

제공된 DEMO 데이터 기준으로, 시각적 위계(2→4)와 고유성(2→4)은 세 차례 측정 모두에서 중앙값이 뚜렷하게 상승해 개선 경향이 관찰됩니다. 반응형 완성도(4→4)와 기능 정확성(4→5)은 큰 변화가 없거나 소폭 상승에 그쳤고, 접근성(3→3.5)은 측정 횟수 불일치로 인해 신뢰도를 그대로 인정하기 어렵습니다. 이 결과는 위에서 지적한 측정 방식 표기 불일치와 데이터 누락을 포함한 잠정치이며, 실제 6회 반복 실행 결과로 교체되기 전까지는 taste-skill의 효과를 일반화해 단정할 수 없습니다.

한계

평가 점수의 성격 — 현재 제시된 평가 점수는 DEMO 값으로, 실제 6회 실행 결과가 아직 반영된 수치가 아닙니다. 최종 점수와 차이가 있을 수 있습니다.
검증 환경의 한계 — 검증은 Claude Code 2.1.234와 claude-sonnet-5 조합에서만 진행했습니다. 다른 에이전트나 모델 조합에서는 결과가 달라질 수 있습니다.
기본 스킬의 실험적 상태 — 기본 스킬로 사용한 design-taste-frontend는 taste-skill 저장소 기준 v2 실험 단계로 명시돼 있습니다. 이후 버전에서 동작 방식이 바뀔 수 있습니다.
검증 과제 유형의 한정성 — B2B SaaS 랜딩 페이지 한 과제 유형만 검증했습니다. 대시보드나 모바일 화면 등 다른 유형에는 결과가 다를 수 있습니다.
검증 범위 밖의 변형 — Codex 전용 변형인 gpt-taste는 이번 검증 범위에 포함되지 않았습니다.

결론

taste-skill을 적용하면 레이아웃 파격도, 모션 강도, 정보 밀도 같은 지시가 프롬프트 의도대로 더 일관되게 반영되는 경향을 확인할 수 있었습니다. 다만 현재 제시한 점수는 DEMO 값이며, 실제 6회 실행 결과로 추후 교체할 예정이라는 점은 감안해야 합니다. AI로 랜딩페이지나 웹사이트를 자주 생성하는데 결과물이 매번 비슷한 느낌으로 나온다는 점이 고민이었던 바이브코더, 그리고 Claude Code나 Codex로 프론트엔드를 만드는 개발자라면 시도해볼 만한 스킬입니다.