통찰력 있는 사람들이 함께하는 젊고 열정적인 IT 기업, 비젠소프트.
A young and passionate technology company,
brought together by people with keen insight—this is Vizensoft.
제미나이 3.7 플래시, 스크린샷으로 웹 UI 만드는 법 정리 - 개발자라면 누구나 한 번쯍 이런 경험이 있을 겁니다. 디자이너가 넘겨준 시안 이미지를 보면서 픽셀 단위로 마진과
개발자라면 누구나 한 번쯍 이런 경험이 있을 겁니다. 디자이너가 넘겨준 시안 이미지를 보면서 픽셀 단위로 마진과 폰트 크기를 맞추고, 컴포넌트 구조를 손으로 하나씩 짜내는 작업 말입니다. 특히 참고할 레퍼런스가 스크린샷 한 장뿐이거나, 클라이언트가 "이런 느낌으로 만들어주세요"라며 캡처 이미지만 던져줬을 때는 막막함이 더 큽니다. 색상 코드를 스포이드로 찍고, 간격을 자로 재듯 추정하고, 폰트를 눈으로 유추하는 과정은 생각보다 많은 시간을 잡아먹습니다.
이런 반복 작업의 상당 부분을 AI가 대신할 수 있는 단계에 이르렀습니다. 구글이 2026년 8월 13일 공식 발표한 '제미나이 3.7 플래시'는 스크린샷이나 이미지, 전체 디자인 시스템을 참조 입력으로 받아 실제 코드로 변환하는 능력을 핵심 특징으로 내세웁니다. 흥미로운 점은 이 모델이 직전 버전인 3.6 플래시가 출시된 지 불과 3주 만에 나온 후속작이라는 사실입니다. 구글은 공식 블로그에서 이 모델이 참조 입력을 기반으로 "높은 디자인 준수도와 동등성"을 보인다고 명시했으며, 웹 개발 영역에서는 더 적은 프롬프트로 더 기능적인 레이아웃과 기능 완결적인 앱을 만들어낸다고 설명했습니다.
이 글에서는 제미나이 3.7 플래시가 실제로 어떤 방식으로 스크린샷을 웹 UI로 변환하는지, 어떤 도구와 플랫폼에서 사용할 수 있는지, 그리고 실무에 적용할 때 어떤 점을 주의해야 하는지를 순서대로 정리합니다.

제미나이 3.7 플래시는 구글이 2026년 8월 13일 공식 발표한 경량형 멀티모달 AI 모델로, 이미지·텍스트를 입력받아 코드와 콘텐츠를 생성하는 데 특화돼 있습니다. 특히 눈에 띄는 대목은 출시 시점입니다. 바로 앞 버전인 3.6 플래시가 2026년 7월 21일 출시됐는데, 그로부터 3주 만에 3.7 플래시가 공개된 것입니다. 구글의 AI 모델 라인업 중에서도 이례적으로 빠른 갱신 주기라는 평가가 나오는 이유입니다.
'플래시' 라인은 구글 제미나이 제품군에서 속도와 비용 효율을 우선한 경량 버전을 지칭합니다. 대형 모델인 '프로' 라인과 달리 응답 속도가 빠르고 API 호출 비용이 낮아, 반복적인 코드 생성이나 실시간 상호작용이 필요한 작업에 적합하도록 설계됐습니다. 3.7 플래시는 이 경량화 기조를 유지하면서도, 이미지 기반 입력을 코드로 옮기는 멀티모달 처리 능력을 한층 강화한 것이 특징입니다.
이 모델이 왜 중요한지는 AI 코딩 트렌드 전반과 맞닿아 있습니다. 최근 몇 년간 AI가 코드를 짜주는 흐름은 텍스트 프롬프트 기반("로그인 페이지를 만들어줘")에서 시각 자료 기반("이 스크린샷과 똑같이 만들어줘")으로 옮겨가고 있습니다. 텍스트로 디자인을 설명하는 데는 한계가 있지만, 이미지는 색상·간격·타이포그래피·레이아웃 정보를 한 번에 전달할 수 있기 때문입니다. 구글이 공식 블로그에서 강조한 "높은 디자인 준수도와 동등성"이라는 표현도 이 지점을 정확히 짚고 있습니다. 즉, 모델이 임의로 재해석하지 않고 참조 이미지에 최대한 근접한 결과물을 만들어낸다는 뜻입니다.
웹앱 제작 관점에서 보면 이는 프로토타이핑 단계의 병목을 줄이는 방향으로 작용합니다. 디자이너가 그린 시안, 경쟁사 서비스의 스크린샷, 심지어 손으로 그린 와이어프레임까지도 입력값으로 활용할 수 있는 가능성이 열리기 때문입니다.

제미나이 3.7 플래시는 이미지를 업로드하면 해당 화면의 레이아웃 구조·색상·타이포그래피를 분석해 그에 상응하는 코드를 생성하는 방식으로 작동합니다. 이 과정은 단순히 이미지를 텍스트로 설명한 뒤 코드를 짜는 것과는 결이 다릅니다. 모델이 이미지 자체를 멀티모달 임베딩으로 처리해, 시각적 요소 간의 상대적 위치·비율·색상 대비까지 함께 고려한다는 점이 특징입니다.
실제 활용 시나리오를 예로 들면 다음과 같습니다.
① 완성된 웹사이트의 스크린샷을 캡처해 업로드하면, 헤더·내비게이션·카드형 콘텐츠·푸터 구조를 인식해 유사한 HTML/CSS 구조로 재현합니다.
② 여러 장의 스크린샷(모바일·태블릿·데스크톱 화면)을 함께 제공하면, 반응형 레이아웃의 브레이크포인트까지 추론해 하나의 코드베이스로 통합하려는 경향을 보입니다.
③ 디자인 시스템 문서(컬러 팔레트, 컴포넌트 가이드) 전체를 입력하면, 개별 화면이 아니라 프로젝트 전반에 일관된 스타일 토큰을 적용하려 시도합니다.
구글이 공식 블로그에서 언급한 "웹 개발에서 더 적은 프롬프트로 더 기능적인 레이아웃과 기능 완결적인 앱을 생성한다"는 설명은 바로 이 지점을 뒷받침합니다. 과거에는 스크린샷을 보여준 뒤에도 "버튼 위치를 조정해줘", "폰트 크기를 키워줘" 같은 후속 프롬프트를 여러 차례 주고받아야 원하는 결과에 도달할 수 있었습니다. 3.7 플래시는 이런 반복 교정의 횟수를 줄이는 방향으로 개선됐다는 것이 핵심 주장입니다.
다만 실무에서 주의할 점도 있습니다. 참조 이미지의 해상도가 낮거나, 화면 일부가 잘려 있거나, 팝업·오버레이가 겹쳐 있는 스크린샷의 경우 인식 정확도가 떨어질 수 있습니다. 가능하면 전체 화면이 온전히 보이는 고해상도 이미지를 사용하고, 필요하다면 스크롤 영역별로 나눠 여러 장을 순차적으로 제공하는 방식이 권장됩니다.

제미나이 3.7 플래시는 구글 AI 스튜디오, 안드로이드 스튜디오, 그리고 에이전트 우선 워크플로용 개발 플랫폼인 '안티그래비티'에서 사용할 수 있습니다. 여기에 제미나이 API를 통한 직접 연동도 가능해, 개발 환경에 따라 접근 경로를 선택할 수 있는 구조입니다.
안티그래비티는 구글이 내세우는 에이전트 우선(agent-first) 개발 플랫폼으로, 사람이 코드를 한 줄씩 작성하기보다 AI 에이전트가 작업 단위를 스스로 계획하고 실행하는 흐름을 지원하는 것을 지향합니다. 이 플랫폼에서 스크린샷을 입력하면, 단순히 코드 스니펫만 반환하는 게 아니라 파일 구조 설계, 컴포넌트 분리, 필요한 라이브러리 제안까지 하나의 작업 단위로 처리하려는 접근을 취합니다. 프로토타입 단계에서 반복적으로 발생하는 잡무성 작업, 예컨대 폴더 구조를 잡거나 초기 스타일시트를 세팅하는 작업의 부담을 줄이는 방향으로 설계된 셈입니다.
구글 AI 스튜디오는 상대적으로 더 가볍고 실험적인 접근에 적합합니다. 웹 브라우저에서 곧바로 이미지를 업로드하고, 생성된 코드를 미리보기 창에서 즉시 확인할 수 있는 구조를 갖추고 있어, 짧은 데모나 아이디어 검증 단계에서 부담 없이 시도해볼 수 있습니다.
안드로이드 스튜디오에 통합된 부분은 모바일 앱 UI 제작에 특화돼 있습니다. 웹 UI가 아닌 네이티브 안드로이드 화면을 스크린샷 기반으로 재현하려는 개발자라면 이 경로가 더 적합합니다.
기업 환경에서는 개별 개발자가 각자 API 키를 발급받아 쓰는 방식보다, '제미나이 엔터프라이즈 에이전트 플랫폼'을 통해 조직 단위로 통합 관리하는 방식이 제공됩니다. 여러 팀이 동시에 모델을 활용할 때 사용량 추적, 권한 관리, 비용 배분 등을 조직 차원에서 통제할 수 있다는 점에서, 개인 개발자의 실험적 사용과는 접근 방식 자체가 다릅니다.
실무에서 어떤 경로를 택할지는 결국 목적에 따라 달라집니다. 빠른 검증이 목적이라면 AI 스튜디오, 프로젝트 전체를 에이전트 기반으로 자동화하고 싶다면 안티그래비티, 기존 코드베이스에 API를 직접 붙이고 싶다면 제미나이 API 연동이 각각의 상황에 맞는 선택지가 됩니다.

제미나이 3.7 플래시는 웹 개발 성능을 측정하는 Arena.ai의 WebDev Arena 벤치마크에서 Elo 1,588점을 기록해, 직전 버전인 3.6 플래시의 1,538점을 앞섰습니다. WebDev Arena는 여러 AI 모델이 동일한 요구사항으로 웹앱을 생성하게 한 뒤, 사람 평가자들이 실제 작동하는 결과물을 비교해 승패를 매기는 방식의 벤치마크입니다. Elo 점수는 체스 랭킹 시스템에서 차용한 방식으로, 상대적 우위를 수치화한 지표입니다.
다만 이 점수를 해석할 때 반드시 짚어야 할 부분이 있습니다. 구글은 3.7 플래시의 WebDev Arena 결과를 'preliminary(예비)'로 표시했으며, 오차 범위가 ±13 Elo에 달한다고 밝혔습니다. 이는 3.7 플래시의 실제 점수가 1,575점에서 1,601점 사이 어딘가일 수 있다는 뜻이며, 이 구간이 인접한 다른 모델들의 점수 구간과 겹칠 가능성이 있습니다. 즉, 50점 차이라는 숫자만 보고 "3.7 플래시가 3.6 플래시보다 압도적으로 우수하다"고 단정하는 것은 성급한 해석입니다. 벤치마크 점수는 참고 지표로 활용하되, 절대적 순위로 받아들이지 않는 태도가 필요합니다.
그럼에도 이 수치가 시사하는 방향성은 있습니다. 문서 처리 능력을 평가하는 GDP.pdf 벤치마크에서 3.7 플래시는 34.0%를 기록해 3.6 플래시의 22.0%를 크게 상회했습니다. 워크플로 자동화 평가인 AutomationBench에서도 3.7 플래시가 30.4%로 3.6 플래시의 17.0%를 넘어섰습니다. 이 두 지표는 단순 코드 생성이 아니라 복잡한 문서를 이해하고 여러 단계의 작업을 자동으로 처리하는 능력을 측정한다는 점에서, 웹앱 제작 이후 단계인 업무 자동화 영역까지 개선이 이어졌다는 근거로 볼 수 있습니다.
정리하면, WebDev Arena 점수 자체는 오차 범위를 감안해 신중하게 봐야 하지만, 문서 처리와 워크플로 자동화 지표는 격차가 뚜렷해 실질적인 개선으로 해석할 여지가 있습니다.

3.6 플래시 출시 3주 만에 3.7 플래시가 나온 것은, 최근 AI 코딩 모델 시장 전반의 갱신 주기가 눈에 띄게 빨라지고 있다는 흐름과 맞닿아 있습니다. 과거 대형 언어 모델은 메이저 버전 업그레이드에 수개월에서 1년 가까운 시간이 걸렸지만, 최근에는 특정 기능 영역(코딩, 문서처리, 멀티모달 등)에 집중한 경량 모델을 빠르게 순환 배포하는 방식이 자리잡고 있습니다.
이런 배경에는 웹앱 제작 수요 자체의 변화가 있습니다. 예전에는 AI에게 코드 생성을 맡기는 것이 개발자의 보조 도구 수준이었지만, 최근에는 비개발자도 아이디어를 이미지나 텍스트로 표현하면 실제 작동하는 웹앱을 만들어내는 '노코드에 가까운 AI 코딩' 흐름이 확산되고 있습니다. 이 흐름 속에서 모델 간 경쟁의 핵심 축이 텍스트 생성 품질에서 시각 자료 해석 정확도로 옮겨가고 있다는 점이 특징입니다.
구글의 이번 발표에서도 이 방향성이 뚜렷합니다. 단순한 코드 생성 능력이 아니라 "참조 입력을 기반으로 한 디자인 준수도"를 핵심 지표로 내세운 것은, 경쟁의 무게 중심이 '얼마나 정교한 코드를 짜는가'에서 '얼마나 원본 디자인에 충실한가'로 이동했음을 보여줍니다. 실제로 GDP.pdf, AutomationBench 같은 벤치마크가 새롭게 강조되는 것도 같은 맥락으로 해석할 수 있습니다. 코드 생성 자체보다, 실제 업무 환경에서 마주치는 복잡한 입력(스크린샷, PDF 문서, 다단계 워크플로)을 얼마나 잘 처리하느냐가 경쟁의 새로운 무대가 되고 있는 것입니다.
이러한 추세는 앞으로도 지속될 가능성이 높습니다. 모델 경량화와 배포 주기 단축이 동시에 진행되는 만큼, 개발자와 기획자 입장에서는 특정 버전에 과도하게 의존하는 워크플로를 설계하기보다, 모델이 교체돼도 유연하게 대응할 수 있는 구조로 프로젝트를 설계하는 태도가 중요해지고 있습니다.

제미나이 3.6 플래시와 3.7 플래시는 성능 지표뿐 아니라 가격 정책에서도 뚜렷한 차이를 보이며, 도입가 기준으로 3.7 플래시가 오히려 더 저렴하게 책정됐습니다. 신형 모델이 구형보다 성능은 높으면서 가격은 낮게 나온 것은 흔한 사례가 아니라는 점에서 주목할 만합니다.
| 구분 | 3.6 플래시 (2026.7.21 출시) | 3.7 플래시 (2026.8.13 출시, 도입가) |
|---|---|---|
| 입력 토큰 100만당 | 1.50달러 | 0.75달러 |
| 출력 토큰 100만당 | 7.50달러 | 3.75달러 |
| WebDev Arena Elo | 1,538점 | 1,588점 (예비, ±13 오차) |
| GDP.pdf 벤치마크 | 22.0% | 34.0% |
| AutomationBench | 17.0% | 30.4% |
이 표에서 가장 눈에 띄는 부분은 가격입니다. 3.7 플래시의 도입가는 3.6 플래시 대비 약 절반 수준입니다. 다만 이 가격은 2026년 12월 31일까지 적용되는 프로모션성 도입가라는 점을 반드시 염두에 둬야 합니다. 구글은 2027년 1월 1일부터 입력 100만 토큰당 1.50달러, 출력 100만 토큰당 7.50달러로 요율이 환원된다고 명시했으며, 흥미롭게도 이 도입 요율을 3.6 플래시에도 동일하게 적용한다고 밝혔습니다. 즉, 두 모델 모두 2026년 말까지는 동일한 할인 요율을 적용받는 구조입니다.
이 글을 읽는 시점이 2026년 12월 31일 이후라면, 실제 청구되는 요율이 이미 1.50달러/7.50달러로 환원됐을 가능성이 높으니 구글 공식 가격 페이지에서 현재 시점의 정확한 요율을 다시 확인하는 것이 안전합니다.
성능 측면에서는 WebDev Arena 점수 차이(1,538 → 1,588)를 절대적 우위로 단정하기보다는, 오차 범위를 감안한 참고 지표로 보되, GDP.pdf와 AutomationBench처럼 격차가 큰 지표는 실질적 개선 신호로 받아들이는 균형 잡힌 해석이 필요합니다.

스크린샷 기반 UI 생성 기능을 실무에 적용할 때 가장 흔한 실수는, AI가 생성한 코드를 검증 없이 바로 배포 단계까지 밀어붙이는 것입니다. AI가 만들어낸 초안은 시각적 유사성은 높을 수 있지만, 접근성(웹 접근성 표준), 시맨틱 마크업, 성능 최적화 측면에서는 별도의 검토가 필요한 경우가 많습니다.
실무 적용 시 판단 기준을 몇 가지로 정리하면 다음과 같습니다.
첫째, 참조 이미지의 품질이 결과물의 품질을 좌우합니다. 저해상도 스크린샷, 압축이 과도한 이미지, 다크모드와 라이트모드가 섞인 캡처는 색상 인식 오류로 이어질 가능성이 있습니다. 가능하면 원본 해상도의 PNG 형식 이미지를 사용하는 편이 안전합니다.
둘째, 생성된 코드의 접근성 검증을 별도로 거쳐야 합니다. 스크린샷은 시각적 정보만 담고 있어, alt 텍스트, ARIA 속성, 키보드 내비게이션 같은 비시각적 요소는 AI가 임의로 채워 넣는 경우가 많습니다. 실제 서비스에 적용하기 전에는 접근성 검사 도구를 통한 재검토가 필요합니다.
셋째, 디자인 시스템 일관성 문제입니다. 여러 화면의 스크린샷을 각각 따로 입력해 생성하면, 화면마다 색상 값이나 간격이 미세하게 달라지는 경우가 있습니다. 프로젝트 전체의 디자인 토큰을 먼저 정의하고, 그 토큰을 참조하도록 별도로 지시하는 방식이 일관성 확보에 도움이 됩니다.
넷째, 벤치마크 수치를 도입 결정의 유일한 근거로 삼지 않는 것입니다. 앞서 살핀 대로 WebDev Arena 점수는 예비 결과이자 오차 범위가 존재하는 지표입니다. 실제 도입 여부는 자신의 프로젝트 환경에서 직접 테스트해본 결과를 우선 근거로 삼는 것이 바람직합니다.
한국지능정보사회진흥원(NIA)이 발표한 AI 활용 실태 관련 자료에서도, AI 생성 결과물을 실무에 적용할 때 검증 절차 없이 바로 채택하는 비율이 높을수록 이후 수정·재작업 비용이 커진다는 경향이 여러 조사에서 공통적으로 언급되고 있습니다. AI가 초안을 빠르게 만들어주는 것과, 그 초안이 실서비스 수준의 품질을 갖췄는지는 별개의 문제라는 점을 항상 구분해야 합니다.

스크린샷 기반 UI 생성을 처음 시도한다면, 아래 단계를 순서대로 따라가는 것이 실패 확률을 줄이는 방법입니다.
1단계, 참조 이미지 준비하기
재현하고 싶은 화면의 고해상도 스크린샷을 확보합니다. 가능하면 팝업이나 오버레이가 없는 깨끗한 상태의 전체 화면을 캡처합니다.
2단계, 사용 플랫폼 선택하기
빠른 검증이 목적이면 구글 AI 스튜디오, 프로젝트 전체를 자동화하고 싶으면 안티그래비티, 기존 시스템에 통합하려면 제미나이 API 중 상황에 맞는 경로를 선택합니다.
3단계, 이미지 업로드와 프롬프트 작성
이미지를 업로드한 뒤, 원하는 프레임워크(예: React, Vue, 순수 HTML/CSS)와 반응형 여부를 함께 명시합니다. 스크린샷만으로 부족한 정보(호버 효과, 애니메이션 등)는 텍스트로 보완합니다.
4단계, 생성 결과 검토하기
색상, 폰트, 레이아웃이 원본과 얼마나 일치하는지 브라우저에서 직접 확인합니다. 이 시점에서 접근성 검사 도구를 함께 돌려보는 것이 좋습니다.
5단계, 반복 교정 및 통합
필요한 부분만 추가 프롬프트로 수정하고, 기존 프로젝트의 디자인 시스템(색상 변수, 컴포넌트 라이브러리)에 맞춰 최종 통합합니다.
이 과정에서 중요한 것은 AI 생성 결과를 '완성품'이 아니라 '고품질 초안'으로 대하는 태도입니다. 초안 생성 속도가 빨라진 만큼, 그만큼 확보된 시간을 검증과 다듬기 단계에 투입하는 것이 전체 프로젝트 품질을 높이는 방향입니다.

제미나이 3.7 플래시를 활용한 스크린샷 기반 UI 생성은, 프로토타이핑 초기 단계의 작업 시간을 줄이는 데 도움이 될 수 있습니다. 다만 이 효과는 참조 이미지의 품질, 프로젝트의 복잡도, 검증 절차를 얼마나 충실히 거치느냐에 따라 달라지는 조건부 결과라는 점을 전제해야 합니다.
디자인 시안을 코드로 옮기는 반복 작업의 부담이 줄어들면, 개발자는 그만큼 확보된 시간을 사용자 경험 개선이나 로직 구현 같은 더 복잡한 작업에 투입할 수 있습니다. 특히 초기 아이디어를 빠르게 검증해야 하는 상황에서는, 완벽한 코드보다 '작동하는 시각적 초안'을 신속히 만들어내는 것 자체가 의사결정 속도를 높이는 요인이 될 수 있습니다.
다만 벤치마크 수치나 가격 경쟁력만으로 도입 효과를 단정하기보다는, 자신의 프로젝트 환경에서 직접 테스트해보고 검증 절차를 병행하는 것이 현실적인 접근입니다.

Q1. 제미나이 3.7 플래시는 무료로 사용할 수 있나요?
구글 AI 스튜디오에서는 일정 범위 내 무료 사용이 제공되는 경우가 있지만, API를 통한 대량 사용은 유료 요율이 적용됩니다. 2026년 12월 31일까지는 입력 100만 토큰당 0.75달러, 출력 100만 토큰당 3.75달러의 도입가가 적용되며, 이후에는 1.50달러/7.50달러로 환원될 예정입니다. 발행 시점에 따라 요율이 이미 바뀌었을 수 있으니 공식 가격 페이지를 확인하는 것이 정확합니다.
Q2. 스크린샷만 있으면 완벽한 웹사이트가 바로 만들어지나요?
레이아웃과 시각적 스타일은 상당히 유사하게 재현되지만, 접근성, 상세한 인터랙션, 백엔드 로직 등은 추가 작업이 필요합니다. 생성 결과는 초안으로 활용하고 검증 절차를 거치는 것이 안전합니다.
Q3. 안티그래비티는 어떤 개발자에게 적합한가요?
프로젝트 전체를 AI 에이전트에게 위임하는 워크플로를 시도해보고 싶은 개발자에게 적합합니다. 단순 코드 스니펫이 아니라 파일 구조 설계부터 라이브러리 제안까지 포괄적으로 처리하려는 접근을 취하는 플랫폼입니다.
Q4. WebDev Arena 점수가 높으면 무조건 더 좋은 모델인가요?
그렇게 단정하기는 어렵습니다. 3.7 플래시의 1,588점은 예비 결과이며 ±13 Elo의 오차 범위가 있어, 인접 모델들과 점수 구간이 겹칠 수 있습니다. 참고 지표로 활용하되 절대적 순위로 받아들이지 않는 것이 바람직합니다.
Q5. 기업에서 여러 팀이 함께 사용하려면 어떻게 해야 하나요?
개별 API 키 발급 방식보다 '제미나이 엔터프라이즈 에이전트 플랫폼'을 통한 조직 단위 관리가 제공됩니다. 사용량 추적과 권한 관리를 통합적으로 운영할 수 있는 구조입니다.
---
제미나이 3.7 플래시가 보여준 스크린샷 기반 UI 생성 능력은, AI 코딩이 텍스트 프롬프트 중심에서 시각 자료 중심으로 옮겨가고 있다는 흐름을 뚜렷하게 보여줍니다. 다만 벤치마크 수치나 가격 경쟁력은 시점에 따라 달라질 수 있는 정보인 만큼, 실제 도입 전에는 최신 공식 자료를 다시 확인하고, 생성된 결과물은 항상 검증 절차를 거쳐 실무에 적용하는 태도가 필요합니다.