Gemini 캔버스에서 손그림으로 화면 시안 만들기: 스케치 사진을 미리보기까지 옮기는 3단계

회의실 화이트보드에 그린 화면 스케치를 개발자에게 설명하느라 시간을 쓰고 나면, 정작 중요한 입력칸 이야기는 뒤로 밀리곤 합니다. 종이에 그린 그림을 사진으로 넘기고 "이 화면을 만들어 줘"라고 말했을 때 시안이 바로 나온다면 회의 시간을 크게 줄일 수 있습니다. 2026년 11월 초 보도에 따르면 Gemini의 캔버스 기능이 손으로 그린 스케치를 읽고 화면을 만드는 흐름을 지원하기 시작했습니다. 이 글에서는 손그림을 올리고, 구조를 확인하고, 미리보기에서 고치는 과정을 세 단계로 나눠 정리합니다.

손그림 시안이 가능해진 배경

보도 내용을 정리하면 이렇습니다. 손으로 그린 스케치 사진을 Gemini 캔버스에 올리고 "이 앱을 코딩해 줘"라고 요청하면, Gemini가 그림을 읽어 코드를 쓰고 미리보기 창에 결과를 보여 줍니다. 미리보기에서 색과 글꼴, 기능을 바꿔 가며 다듬을 수 있고, 저장할 데이터가 필요하면 Firestore 데이터베이스를 자동으로 만든다고 합니다.

다만 요금제와 지역별 제공 여부는 확인한 자료에 나와 있지 않으니, 계정에 메뉴가 보이는지 먼저 확인하세요. 기획 단계에서 화면을 말로만 설명하면 현업과 개발자가 서로 다른 그림을 떠올리기 쉽습니다. 시안이 있으면 같은 화면을 두고 이야기할 수 있어서 수정 횟수 자체가 줄어듭니다. 이 점이 이 기능을 주목해 볼 만한 이유입니다.

시작 전에 준비할 것

스케치는 화면의 뼈대만 그리면 충분합니다. 제목 자리, 입력칸, 버튼, 목록의 위치를 표시하고 글자는 짧게 적습니다. 펜 색은 한 가지로 통일하고, 사진은 밝은 곳에서 위에서 내려다보듯 찍습니다. 선이 흐리면 칸의 개수를 잘못 읽을 수 있습니다.

화면을 누가 쓰는지도 한 문장으로 적어 둡니다. "영업팀이 고객 방문 내용을 하루 한 번 기록하는 화면"처럼 쓰면 Gemini가 버튼 이름이나 목록 항목을 추측할 때 방향을 잡기 쉽습니다. 데이터는 실제 고객 명단 대신 가짜 예시로 시작하세요.

1단계: 그림을 올리고 구조부터 읽히기

사진을 올린 뒤 바로 코드를 쓰게 하지 말고, 화면 구조를 말로 정리하게 합니다. 구조가 잘못 읽힌 부분은 코드가 완성되기 전에 잡아낼 수 있습니다.

첨부한 손그림은 업무용 웹 화면의 설계 스케치입니다. 코드를 쓰기 전에 먼저 아래를 정리해 주세요.
1. 화면의 영역을 위에서 아래 순서로 나열하기
2. 각 영역의 입력칸, 버튼, 목록에 이름 붙이기
3. 그림에서 판단하기 어려운 부분은 질문으로 따로 적기

사용 목적: 영업팀이 고객 방문 내용을 하루 한 번 기록하는 화면

이렇게 나옵니다 (예시):

"화면은 세 영역으로 보입니다. 1) 상단의 제목과 오늘 날짜, 2) 가운데 입력 폼: 고객명 입력칸, 방문 목적 선택 목록, 메모 영역, 3) 하단의 저장 버튼과 최근 기록 목록. 방문 목적 목록의 항목 수는 그림에서 명확하지 않아 질문으로 남깁니다. 항목은 몇 개인가요?"

질문에 답을 적어 준 뒤 다음 단계로 넘어가면 됩니다.

2단계: 구조대로 만들고 첫 미리보기 보기

요구사항은 세 가지 이하로 줄이는 편이 좋습니다. 조건이 많을수록 한두 가지가 빠지거나 엉뚱하게 바뀌는 일이 늘어납니다.

방금 정리한 구조대로 웹 화면을 만들어 주세요.
- 미리보기에서 바로 실행되는 형태로 작성
- 저장 버튼을 누르면 입력 내용이 최근 기록 목록 맨 위에 추가되도록
- 방문 목적 목록은 제가 답한 항목 수를 기준으로 채우기
- 휴대폰 너비에서도 입력칸이 세로로 한 줄씩 보이도록

이렇게 나옵니다 (예시):

"미리보기 창에 입력 폼과 최근 기록 목록이 나타납니다. 고객명과 방문 목적, 메모를 적고 저장을 누르면 목록 맨 위에 기록이 생깁니다. 데이터 저장을 위해 Firestore 데이터베이스를 함께 준비했다는 안내도 표시됩니다."

실제 결과는 요청 문장과 계정 상태에 따라 달라질 수 있습니다. 미리보기가 뜨지 않으면 계정에서 기능이 열려 있는지 먼저 확인하세요.

3단계: 미리보기에서 한 번에 두 가지만 고치기

미리보기를 열면 자잘한 수정이 많이 나옵니다. 그때마다 전체를 다시 쓰게 하면 잘 되던 부분까지 바뀌곤 합니다. 한 번에 두세 가지만 고치고, 바꾸지 말아야 할 부분을 명시하는 것이 안전합니다.

미리보기를 보고 다음 두 가지만 바꿔 주세요. 나머지는 그대로 두세요.
1. 메모 입력칸을 세 줄 높이로 늘리고 글자 크기는 기존과 같게 유지
2. 저장한 뒤에는 고객명과 메모 입력칸만 비워서 다음 고객을 바로 적을 수 있게
바꾼 뒤에는 바뀐 부분만 항목별로 요약해 주세요.

이렇게 나옵니다 (예시):

"변경 사항: 메모 입력칸 높이를 세 줄로 늘렸습니다. 저장 후 고객명과 메모가 비워지며, 방문 목적 선택 값은 그대로 남습니다. 바뀌지 않은 부분: 목록 정렬, 저장 버튼 위치."

요약에 바뀌지 않은 부분이 함께 적혀 있으면 확인이 빠릅니다. 요약과 미리보기 화면이 다르다면 그 차이를 다시 물어보세요.

공유 전 점검: 링크를 받은 사람이 할 수 있는 일

이 부분이 가장 중요합니다. 보도에서는 캔버스 앱을 공유 링크로 보낼 수 있고, 링크를 가진 사람은 공유된 데이터를 볼 뿐 아니라 수정할 수도 있다고 설명했습니다. 팀에 보내기 전에 저장 항목과 공유 범위를 먼저 정리해 달라고 하세요.

이 앱이 저장하는 항목, 저장되는 위치, 공유 링크를 받은 사람이 할 수 있는 일을 목록으로 정리해 주세요. 실제 고객 정보가 들어가면 위험해질 부분도 따로 표시해 주세요.

이렇게 나옵니다 (예시):

"저장 항목은 고객명, 방문 목적, 메모, 기록 시각입니다. 링크를 받은 사람은 기록을 보고 추가하고 수정할 수 있습니다. 메모에 실제 연락처나 민감한 내용이 들어가면 링크가 퍼졌을 때 그대로 노출됩니다."

결과를 보고 권한이 너무 넓다고 판단되면 실제 데이터는 넣지 말고 시안 용도로만 공유하세요. 정식으로 쓸 단계라면 개발팀이나 보안 담당자와 저장 방식을 함께 정하는 편이 안전합니다.

회의 전에 시안으로 합의하는 법

이 흐름의 진짜 가치는 개발 전에 현업과 시안을 맞춰 보는 데 있습니다. 회의 전에 손그림 사진과 미리보기 화면을 함께 보내면 입력칸이나 목록에 대한 질문이 회의 중이 아니라 회의 전에 정리됩니다. 개발자에게 넘길 때는 시안 화면과 함께 1단계의 구조 정리를 붙여 주면 설명 시간을 크게 줄일 수 있습니다.

자주 막히는 지점

가장 흔한 문제는 여러 화면을 한 장에 그린 경우입니다. 칸의 경계가 불분명하면 영역이 합쳐져 읽히므로, 화면 하나당 종이 한 장을 쓰는 편이 정확합니다.

두 번째는 요청을 한 번에 너무 많이 넣는 경우입니다. 수정 요청이 열 가지를 넘으면 어느 것이 빠졌는지 찾기 어렵습니다. 이때는 요청을 나눠서 다시 보내세요.

세 번째는 미리보기가 열리지 않는 경우입니다. 같은 요청을 반복하기보다 기능이 계정에 열려 있는지 확인하고, 스케치 한 화면만 따로 올려 다시 시도하는 쪽이 빠릅니다.

한눈에 정리

손그림 사진을 올리고 구조를 먼저 확인한 뒤, 요구사항을 줄여서 만들고, 미리보기에서 두세 가지씩 고칩니다. 공유 전에는 저장 항목과 링크 권한을 꼭 점검합니다. 이 순서를 지키면 회의 전에 화면 시안을 손에 쥐고 들어갈 수 있습니다. 시안은 완성품이 아니라 질문을 모으는 도구라는 점만 기억하면, 기대치를 맞추는 데도 도움이 됩니다.

자주 묻는 질문

Q. 디자인 감각이 없어도 쓸 수 있나요? A. 네. 스케치는 배치만 그리면 되고, 색이나 글꼴은 미리보기에서 말로 바꿀 수 있습니다. 보도에서 확인된 입력 방식은 손그림 사진이므로, 다른 형식은 직접 시험해 보시기 바랍니다.

Q. 만든 화면을 바로 팀에 보내도 되나요? A. 실제 고객 정보는 넣지 말고 가짜 데이터로 시안만 공유하는 것을 권합니다. 링크를 받은 사람이 데이터를 수정할 수 있다는 점을 먼저 확인하세요.

Q. 기능이 제 계정에 보이지 않으면 어떻게 하나요? A. 요금제와 지역에 따라 아직 열리지 않았을 수 있습니다. Google 도움말에서 캔버스 기능 안내를 찾아보시고, 그동안은 손그림을 종이와 사진으로 정리해 두면 회의 준비에 그대로 쓸 수 있습니다.