UI 스크린샷을 Qwen 3.7 Plus에 제공하면 프런트엔드 코드를 생성해 해당 UI를 재구성할 수 있습니다. 모델은 이미지와 코드를 함께 처리하므로 디자인 목업, 경쟁사 페이지, Figma 내보내기 이미지를 React 또는 HTML 컴포넌트로 변환하는 워크플로에 적합합니다.
이 글에서는 기본 API 호출, 프롬프트 작성법, 시각적 피드백 루프, 그리고 생성된 UI를 실제 앱으로 연결하는 방법을 다룹니다. 모델 배경은 Qwen 3.7 Plus 개요를 참고하고, 요청 형식은 Qwen 3.7 Plus API 가이드를 참고하세요. 생성된 UI가 호출할 API와 엔드포인트는 Apidog에서 설계하고 테스트할 수 있습니다.
요약
Qwen 3.7 Plus에 스크린샷과 구체적인 프롬프트를 보내면 원하는 프레임워크의 UI 코드를 생성할 수 있습니다.
실무에서는 다음 흐름이 가장 안정적입니다.
- 스크린샷을 준비합니다.
- 사용할 프레임워크, 스타일링 방식, 접근성 요구사항을 프롬프트에 명시합니다.
- 생성된 컴포넌트를 로컬에서 렌더링합니다.
- 렌더링 결과를 다시 스크린샷으로 찍습니다.
- 원본 이미지와 렌더링 이미지를 함께 보내 차이를 수정하게 합니다.
- API 연동이 필요한 부분은 Apidog에서 먼저 계약과 목업 응답을 준비합니다.
Qwen 3.7 Plus는 시각 인식과 코딩 능력을 함께 제공하고, 큰 디자인을 처리할 수 있는 1M 토큰 컨텍스트를 지원하며, 반복 호출 비용도 낮은 편입니다. 핵심 작업은 API 호출 자체보다 프롬프트 설계와 반복 개선입니다.
이 작업에 Qwen 3.7 Plus를 사용하는 이유
스크린샷을 코드로 바꾸려면 두 가지가 동시에 필요합니다.
- 이미지에서 레이아웃, 색상, 간격, 텍스트 구조를 읽는 능력
- 읽어낸 UI를 실제 프런트엔드 코드로 작성하는 능력
Qwen 3.7 Plus는 SWE-Bench Pro에서 약 60%, Terminal-Bench에서 70.3점을 기록한 코딩 성능을 갖추고 있으며, 밀도 높은 UI 레이아웃도 시각적으로 처리할 수 있습니다. 1M 토큰 컨텍스트는 긴 페이지나 고해상도 디자인을 다룰 때 유용하고, 백만 입력 토큰당 $0.40 수준의 비용은 반복 개선 작업에 적합합니다.
UI를 재구축하는 것이 아니라 실제 UI를 조작하는 에이전트가 필요하다면 컴퓨터 사용 에이전트 가이드를 참고하세요.
기본 호출
이미지는 image_url 입력으로 전달하고, 텍스트 프롬프트에는 원하는 결과물을 명확히 적습니다.
import os
import base64
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DASHSCOPE_API_KEY"],
base_url="https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
)
def screenshot_to_code(png_path, prompt):
with open(png_path, "rb") as f:
b64 = base64.b64encode(f.read()).decode()
resp = client.chat.completions.create(
model="qwen3.7-plus",
messages=[
{
"role": "user",
"content": [
{"type": "text", "text": prompt},
{
"type": "image_url",
"image_url": {
"url": f"data:image/png;base64,{b64}"
},
},
],
}
],
)
return resp.choices[0].message.content
prompt = "Rebuild this UI as a React component."
print(screenshot_to_code("mockup.png", prompt))
배포 전에 Model Studio 문서에서 현재 모델 ID를 확인하세요.
위 코드는 최소 예제입니다. 하지만 "Rebuild this UI as a React component." 같은 한 줄 프롬프트만 사용하면 결과도 대략적인 수준에 머무를 가능성이 큽니다. 실제 프로젝트에서는 스택, 제약 조건, 출력 형식을 더 구체적으로 지정해야 합니다.
배포 가능한 코드를 얻는 프롬프트 작성
모호한 프롬프트는 일반적인 마크업을 생성합니다. 다음처럼 요구사항을 구조화하세요.
Convert this UI screenshot into a single React component using Tailwind CSS.
Requirements:
- Match the layout, spacing, typography, and color palette as closely as possible.
- Make it responsive down to a 375px mobile width.
- Use semantic HTML.
- Add accessible labels for inputs, buttons, and interactive controls.
- Use placeholder data where the screenshot shows dynamic content.
- Do not invent backend APIs.
- Return only the component code. Do not include explanations.
프롬프트에는 최소한 다음을 포함하는 것이 좋습니다.
- 대상 프레임워크: React, Vue, Svelte, HTML 등
- 스타일링 방식: Tailwind CSS, CSS Modules, plain CSS 등
- 반응형 기준: 예를 들어 375px 모바일 폭
- 접근성 요구사항:
label,aria-*, 시맨틱 태그 - 동적 데이터 처리 방식: 실제 API 대신 placeholder 사용
- 출력 형식: 코드만 반환, 설명 제외
예를 들어 Tailwind를 쓴다면 Tailwind CSS 문서를 기준으로 모델이 유틸리티 클래스를 생성하도록 유도할 수 있습니다.
컴포넌트 사양이나 디자인 브리핑을 함께 제공하면 결과가 더 안정적입니다. 서면 사양이 코딩 에이전트 결과에 어떤 영향을 주는지는 design.md가 코딩 에이전트에 어떤 역할을 하는지에 대한 글을 참고하세요.
시각적 피드백 루프로 정확도 높이기
첫 번째 결과물은 구조는 비슷해도 간격, 색상, 폰트 크기, 정렬이 어긋나는 경우가 많습니다. 이때는 생성된 UI를 실제로 렌더링한 뒤 다시 모델에 비교를 요청합니다.
기본 루프는 다음과 같습니다.
- 원본 스크린샷을 모델에 전달합니다.
- React 또는 HTML 코드를 생성합니다.
- 로컬에서 컴포넌트를 렌더링합니다.
- 렌더링 결과를 스크린샷으로 저장합니다.
- 원본 이미지와 현재 렌더링 이미지를 함께 보냅니다.
- 차이점을 분석하고 수정된 코드를 요청합니다.
프롬프트 예시는 다음과 같습니다.
Here is the target design (image 1) and my current render (image 2).
Tasks:
1. List the visual differences between image 1 and image 2.
2. Fix the component code so the render matches image 1 more closely.
3. Preserve the existing React and Tailwind CSS structure unless changes are necessary.
4. Return only the corrected component code.
이 과정을 두세 번 반복하면 원본에 가까운 결과를 얻을 수 있습니다. 원리는 컴퓨터 사용 에이전트의 인식-수정 흐름과 비슷하지만, 클릭 대신 코드 수정에 적용하는 방식입니다.
실제 디자인 처리 방법
프로덕션 디자인은 보통 크고 복잡합니다. 한 번에 전체 페이지를 생성하려고 하면 코드 품질이 떨어질 수 있습니다.
1. 이미지를 줄이고 자르기
전체 페이지 고해상도 이미지는 많은 토큰을 사용합니다. 텍스트를 읽을 수 있는 수준에서 이미지를 줄이고, 실제로 구현할 섹션만 잘라서 보내세요.
예를 들어 다음처럼 나눌 수 있습니다.
- 헤더
- 사이드바
- 필터 영역
- 카드 리스트
- 테이블
- 모달
- 폼
2. 섹션 단위로 생성하기
전체 대시보드를 한 번에 요청하기보다 섹션별 컴포넌트를 생성한 뒤 조합하는 방식이 더 안정적입니다.
Generate only the sidebar component from this screenshot.
Ignore the main content area.
Use React and Tailwind CSS.
Return a reusable component named Sidebar.
섹션 단위로 나누면 다음 장점이 있습니다.
- 프롬프트가 짧아집니다.
- 모델이 UI 범위를 더 정확히 이해합니다.
- 생성된 코드가 재사용 가능한 컴포넌트로 나뉩니다.
- 후속 수정이 쉬워집니다.
1M 컨텍스트는 큰 입력을 처리하는 데 도움이 되지만, 작은 요청이 보통 더 깔끔한 코드를 만듭니다.
더 나은 결과물을 얻는 프롬프트 팁
자주 발생하는 문제는 프롬프트 한두 줄로 줄일 수 있습니다.
잘못된 색상
모델은 색상을 대략적으로 추정할 수 있습니다. 정확도가 중요하다면 디자인에서 헥스 값을 직접 추출해 전달하세요.
Use these exact colors:
- Primary: #2563EB
- Background: #F8FAFC
- Text primary: #111827
- Border: #E5E7EB
임의로 생성된 아이콘
아이콘 모양을 추측하게 두면 실제 디자인과 달라질 수 있습니다. 사용할 아이콘 세트를 지정하세요.
Use lucide-react for icons.
Do not create custom SVG icons unless the icon is not available in lucide-react.
또는 다음처럼 지정할 수 있습니다.
Use Heroicons for all icons.
Match the icon intent shown in the screenshot.
지어낸 콘텐츠
스크린샷에 동적 데이터가 있으면 모델이 실제처럼 보이는 텍스트를 임의로 만들 수 있습니다. placeholder 정책을 명시하세요.
Use clearly marked placeholder data.
Do not invent real company names, emails, IDs, or API responses.
과도한 div 중첩
시맨틱 HTML을 명시하지 않으면 래퍼 div가 과하게 늘어날 수 있습니다.
Use semantic HTML where appropriate:
- header for the top navigation
- nav for navigation links
- main for page content
- section for major content blocks
- button for clickable actions
Avoid unnecessary wrapper divs.
API를 임의로 만들지 않게 하기
프런트엔드 생성 중에 가짜 엔드포인트가 생기는 것을 피하려면 명확히 제한하세요.
Do not invent API endpoints.
Use local placeholder data in the component.
Mark all future API integration points with TODO comments.
UI에서 작동하는 앱으로 연결하기
생성된 프런트엔드 코드는 UI의 절반입니다. 실제 앱으로 만들려면 컴포넌트가 데이터를 가져오고, 폼을 제출하고, 동작하는 API 엔드포인트를 호출해야 합니다.
이 단계에서는 먼저 API 계약을 정의하는 것이 좋습니다.
예를 들어 대시보드 카드 UI를 생성했다면 필요한 API는 다음과 같을 수 있습니다.
GET /dashboard/summary
응답 예시는 다음과 같습니다.
{
"totalUsers": 12840,
"activeUsers": 9321,
"conversionRate": 7.4,
"revenue": 58200
}
폼 UI라면 제출 API가 필요할 수 있습니다.
POST /contacts
Content-Type: application/json
{
"name": "Jane Doe",
"email": "jane@example.com",
"message": "Hello"
}
Apidog를 사용하면 다음 작업을 한 곳에서 진행할 수 있습니다.
- API 계약 정의
- 요청 및 응답 스키마 작성
- 목업 응답 생성
- 프런트엔드가 사용할 테스트 데이터 준비
- 백엔드 구현 전 API 호출 검증
이 흐름은 생성형 AI로 만든 프런트엔드를 실제 기능으로 연결할 때 유용합니다. 자세한 방식은 사양 우선 모드 가이드를 참고하세요. AI로 작성한 프런트엔드와 API 구현을 함께 다룬다면 Cursor에서 구축된 API 흐름도 참고할 수 있습니다.
Qwen 3.7 Plus가 생성한 UI 뒤의 API를 목업하고 테스트하려면 Apidog를 다운로드하세요.
자주 묻는 질문
Qwen 3.7 Plus는 어떤 프레임워크를 대상으로 할 수 있나요?
프롬프트에 명시한 프레임워크를 대상으로 할 수 있습니다. React, Vue, Svelte, 일반 HTML/CSS, Tailwind CSS, 컴포넌트 라이브러리 등을 지정할 수 있습니다. 지정하지 않으면 일반적인 마크업이 생성될 수 있으므로 명확히 적는 것이 좋습니다.
첫 번째 시도는 얼마나 정확한가요?
대체로 구조는 비슷하게 나옵니다. 하지만 정확한 간격, 색상, 정렬은 다를 수 있습니다. 원본 이미지와 렌더링 결과를 함께 보내는 시각적 피드백 루프를 사용하면 더 정확하게 개선할 수 있습니다.
Figma 디자인으로도 사용할 수 있나요?
네. Figma 프레임을 이미지로 내보낸 뒤 모델에 전달하면 됩니다. 모델은 Figma 파일 자체가 아니라 렌더링된 디자인 이미지를 읽습니다.
토큰 비용을 낮추려면 어떻게 해야 하나요?
이미지를 읽을 수 있는 가장 작은 크기로 줄이고, 구현할 섹션만 잘라서 보내세요. 전체 페이지를 한 번에 생성하지 말고 헤더, 사이드바, 테이블, 폼처럼 나눠서 생성하는 것이 좋습니다.
백엔드도 생성하나요?
아니요. Qwen 3.7 Plus는 API를 호출하는 프런트엔드 코드를 만들 수 있지만, 실제 백엔드는 별도로 설계하고 구현해야 합니다. API 계약, 목업, 테스트는 Apidog에서 처리할 수 있습니다.
결론
Qwen 3.7 Plus를 사용한 스크린샷-투-코드 워크플로는 다음 세 가지가 핵심입니다.
- 구체적인 프롬프트 작성
- 멀티모달 호출을 통한 UI 코드 생성
- 원본과 렌더링 결과를 비교하는 짧은 피드백 루프
이 방식으로 작동하는 프런트엔드 컴포넌트를 빠르게 만들 수 있습니다. 다만 실제 기능으로 완성하려면 UI 아래에 API가 필요합니다. Plus로 프런트엔드를 생성한 뒤, Apidog에서 엔드포인트를 설계하고, 목업하고, 테스트해 전체 기능을 연결하세요.

Top comments (0)