Molayo

© 2026 Molayo

Dev.to헤드라인2026. 05. 29. 05:36

AI 웹 빌더가 제대로 된 미디어 쿼리 (Media Queries)를 작성하게 만드는 것을 포기한 이유

요약

AI 웹 빌더 개발 과정에서 프롬프트만으로는 데스크톱 레이아웃의 품질을 높이는 데 한계가 있음을 설명합니다. 모델이 모바일 규칙에만 집중하는 문제를 해결하기 위해, 직접적인 미디어 쿼리 작성 대신 Tailwind CSS를 활용하는 방식으로 전환하여 해결한 사례를 다룹니다.

핵심 포인트

  • 프롬프트만으로는 복잡한 데스크톱 레이아웃 설계 유도가 어려움
  • 모델의 주의력 예산이 모바일 규칙 작성에 집중되는 경향
  • 미디어 쿼리 직접 작성 대신 Tailwind CSS 활용으로 문제 해결
  • 다양한 LLM 모델에서 공통적으로 나타나는 레이아웃 설계 패턴

제가 만든 AI 웹사이트 빌더가 생성하는 모든 사이트는 모바일에서는 멋져 보였지만, 데스크톱에서는 빈약해 보였습니다. 히어로(Hero) 섹션은 단 하나의 힘없는 열(Column)로 화면 끝에서 끝까지 늘어져 있었습니다. 기능 그리드(Features grids)는 27인치 모니터에서도 1열 상태를 유지했습니다. 모바일에서는 넉넉하게 느껴졌던 섹션 패딩(Section padding)은 데스크톱 너비에서는 텅 빈 것처럼 느껴졌습니다.

저는 프롬프트(Prompt) 측면에서 이를 해결하려고 2주 동안 노력했습니다. 하지만 그 어떤 것도 제가 원하는 대로 작동하지 않았습니다. 결국 저는 그 방식을 완전히 포기하고, 생성 방식을 CDN을 통한 Tailwind로 전환했습니다. 그러자 데스크톱 문제는 사라졌습니다.

이 글은 기존 방식이 왜 잘못되었는지, 제가 처음에 무엇을 시도했는지, 그리고 결정적인 차이를 만든 구체적인 변화가 무엇인지에 대한 기록입니다.

증상

시스템 프롬프트(System prompt)는 모델에게 모바일 퍼스트(Mobile-first) CSS를 작성하도록 지시했습니다:

기본 CSS는 모바일(≤480px)을 대상으로 합니다. @media (min-width: 768px) 및 (min-width: 1024px)를 사용하여 레이어를 쌓아 올리세요.

모델들은 지시를 따랐습니다. 그들은 좋은 모바일 규칙을 작성했습니다. 그다음에는 여기저기에 max-width를 넣거나 2열 레이아웃을 위한 미디어 쿼리(Media query)를 넣는 식의 빈약하고 성의 없는 데스크톱 오버라이드(Overrides)를 작성했습니다. 제한된 컨테이너 너비(Bounded container widths), 실제 다중 열 그리드(Multi-column grids), 진정으로 확장되는 타이포그래피(Typography), 의도적인 섹션 패딩 리듬(Section padding rhythm)과 같은 핵심적인 요소들이 누락되었습니다. 데스크톱이 망가진 것이 아니라, 설계가 부족했던(underdesigned) 것이었습니다. 모바일 규칙이 모델의 주의력 예산(Attention budget) 대부분을 흡수해 버렸습니다.

이것은 특정 모델만의 문제가 아니었습니다. 저는 4가지를 테스트했습니다 (Cerebras GPT-OSS 120B, Groq Llama 4 Scout, Cloudflare Qwen3 30B, OpenRouter free auto-router). 네 가지 모두 동일한 패턴을 보였습니다. 가장 강력한 모델이 가장 세련된 모바일 경험을 만들어냈지만, 여전히 데스크톱은 빈약했습니다.

처음에 시도했던 것

1라운드: 프롬프트에 명시적인 데스크톱 규칙 삽입.

데스크톱은 늘어난 모바일 뷰가 아니라 설계된 경험이어야 합니다:
- 모든 주요 섹션은 제한된 컨테이너(Bounded container, max-width 1100–1280px)를 사용합니다.
- 데스크톱에서는 다중 열 그리드(Multi-column grids)를 사용합니다 (1열이 아닌 3열 기능 그리드).
...

도움이 되긴 했지만, 아마 20% 정도 개선되었을 뿐입니다. 충분하지 않았습니다. 모델은 여전히 중단점(Breakpoints)을 하나씩 수동으로 작성했고, 컨테이너(Container)를 자주 잊어버렸으며, 모바일 크기의 패딩(Padding)을 그대로 유지하는 경우가 많았습니다.

2라운드: 안티 패턴(Anti-patterns) 목록.

- 늘려놓은 모바일 뷰처럼 보이는 데스크톱 화면.
- 1440px 화면에서 히어로(Hero) 섹션은 전체 너비(Full-width)인데 콘텐츠는 전화기 컬럼 안에 중앙 정렬된 상태.
- 데스크톱에서 단일 열(Single-column) 기능 그리드.

결과적으로 미미했습니다. 근본적인 문제는 모델이 생성할 때마다 반응형 CSS를 처음부터 다시 발명해야 했다는 점입니다. 제한된 어텐션(Attention) 토큰 내에서, 모델은 가장 먼저 나오고 가장 많이 강화된 것, 즉 모바일에 노력을 할당했습니다.

깨달음

LLM에게 모바일 퍼스트(Mobile-first) 방식의 반응형 CSS를 직접 작성하도록 요청하는 것은 LLM에게 부적절한 작업입니다. 이는 취약하고 반복적이며, 모델은 매번 똑같은 수십 가지의 결정을 내려야 합니다.

하지만 LLM은 Tailwind에 매우 능숙합니다. 모델은 학습 데이터에서 수백만 개의 class="grid grid-cols-1 md:grid-cols-3" 예시를 보았습니다. 반응형 접두사(Responsive prefix) 시스템은 정의상 모바일 퍼스트입니다. 모든 md: 및 lg: 유틸리티는 구문(Syntax)이 강제하기 때문에, 모델이 의도적으로 하나씩 추가하는 데스크톱 기능(Affordance)입니다.

저는 생성 시스템을 Tailwind CDN을 사용하도록 변경했습니다. 데스크톱 문제는 스스로 해결되었습니다.

변화 — 세 가지 요소

1. <head> 내에 CDN 스크립트와 인라인 설정(Inline config)을 의무화합니다:

<script>
  tailwind.config = {
    theme: {
...

순서가 중요합니다. CDN 스크립트가 초기화되기 전에 설정(Config)이 파싱되어야 하며, 그렇지 않으면 커스텀 컬러(Custom colors)가 조용히 적용되지 않습니다.

2. 프롬프트에서 데스크톱을 동일하게 일급 객체(First-class)로 취급합니다:

## RESPONSIVE — MOBILE-FIRST, DESKTOP EQUALLY FIRST-CLASS
Tailwind는 기본적으로 모바일 퍼스트입니다. 반응형 접두사(sm:, md:, lg:)는
데스크톱이 사후 고려 사항이 아니라 의도적으로 설계되는 방식입니다.
...

모든 규칙에 md: 또는 lg: 접두사가 붙어 있는 것에 주목하세요. 프롬프트는 모델에게 중단점(Breakpoint) 로직을 발명하라고 요구하는 것이 아닙니다. 대신, 모델이 이미 알고 있는 유틸리티(Utilities)에 반응형 접두사(Responsive prefixes)를 추가하라고 요구하는 것입니다. 이것은 훨씬 더 작은 작업입니다. 그리고 LLM에게 더 작은 작업은 훨씬 더 일관된 결과물을 만들어냅니다.

3. 프롬프트 끝에 배치하는 최종 확인(Final-check) 블록:

## FINAL CHECK
응답을 출력하기 전에, <head>에 다음 두 가지가 모두 포함되어 있는지 확인하십시오:
  1. <script>tailwind.config = { ... }</script>
...

이 마지막 단계가 중요합니다. 이 단계가 없었을 때, 제가 처음 시도한 Tailwind 출력물에서 모델들은 Tailwind 클래스는 작성했지만 CDN 스크립트는 누락하곤 했습니다. 그 결과 페이지는 스타일이 적용되지 않은 생 HTML로 렌더링되었고, 모든 클래스는 아무런 동작도 하지 않는(no-op) 상태가 되었습니다. 최종 확인(Final-check) 섹션을 추가함으로써 이러한 실패 모드를 거의 제로(0)에 가깝게 줄일 수 있었습니다.

결과

데스크톱 출력물은 반복되는 불만 사항에서 더 이상 문제가 되지 않는 수준으로 개선되었습니다. 이제 단일 페이지 사이트들은 다음과 같은 특징을 갖습니다:

  • 화면 끝까지 퍼지는 형태 대신 제한된 콘텐츠 너비(Bounded content widths)
  • 데스크톱에서는 3열 기능 그리드, 모바일에서는 1열, 태블릿에서는 2열 — 자동 적용
  • 중앙에 배치된 모바일 컬럼 대신 수평 공간을 활용하는 히어로 레이아웃(분할형, 비대칭형, 풀 블리드(Full-bleed) 등)
  • 실제로 크기가 확장되는 타이포그래피(Typography)
  • 데스크톱에서는 실제 수평 네비게이션을 사용하고, 햄버거 메뉴는 모바일용으로 예약

이 중 어느 것도 모델이 "더 열심히 노력해서" 얻은 결과가 아닙니다. 모델이 잘하지 못하는 무언가가 아니라, 잘하는 무언가를 하도록 요청했기 때문에 얻은 결과입니다.

일반화

LLM이 특정 작업에서 평범한(Mediocre) 결과물을 내놓을 때, 가장 먼저 드는 생각은 프롬프트를 수정하는 것입니다. 규칙을 더 추가하고, 예시를 더 넣고, 안티 패턴(Anti-patterns)을 추가하는 식이죠. 각각의 방법은 미미하게 도움이 됩니다.

더 높은 레버리지를 가진 전략은 작업(Task) 자체가 잘못된 것은 아닌지 질문하는 것입니다. 모델이 이미 매우 잘하고 있는 원시 요소(Primitive) 중에 당신의 문제와 매핑될 수 있는 것이 있습니까?

  • Tailwind 유틸리티 클래스(Utility classes)는 반응형 웹 디자인을 위한 그 원시 요소입니다.
  • 마크다운(Markdown)은 구조화된 산문을 위한 그 원시 요소입니다.
  • JSON 스키마(JSON Schema)는 구조화된 데이터 추출을 위한 그 원시 요소입니다.
  • React/JSX는 컴포넌트 출력을 위한 그 원시 요소입니다.

만약 답변이 '예'라면, 이러한 재작성 (rewrite) 방식은 당신이 빠져들고 있던 프롬프트 튜닝 (prompt-tuning)의 늪보다 규모가 작으면서도, 품질의 상한선 (quality ceiling)은 훨씬 더 높습니다.

저는 이 전환을 하기 전까지 2주를 허비했습니다. 프롬프트 측면의 수정은 생산적인 것처럼 느껴졌습니다. 수정할 때마다 조금씩 진전이 있는 것 같았기 때문입니다. 하지만 구조적인 수정은 단 몇 시간 만에 끝났고, 그 효과는 지금까지 했던 모든 프롬프트 수정들을 합친 것보다 더 컸습니다.

직접 체험해 보세요: wiz-craft.vercel.app — GitHub에서 오픈 소스로 공개되어 있습니다. 4개의 무료 오픈 소스 모델을 사용하며, 프롬프트로부터 Tailwind 스타일의 싱글 페이지 사이트를 생성하고, 모델이 작성하는 동안 iframe을 실시간으로 스트리밍합니다. Claude를 사용하여 구축되었습니다.

제가 사용 중인 4개의 제공업체에 대한 자세한 내용은 다음을 참조하세요: 실제 프로덕션 작업을 위해 4개의 무료 70B급 LLM 엔드포인트를 테스트했습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0