직접 그린 디지털 주석 와이어프레임이 바로 프로토타입이 된다면?

이번 비교는 종이 그림이나 사진이 아니라, 빈 캔버스에 도형과 글자를 배치한 실험용 직접 그린 디지털 주석 와이어프레임과 같은 요구의 텍스트 명세를 사용했다. 사람의 손그림이나 초보자의 제작 경험을 시험한 것은 아니다. 이미지 경로도 두 경로의 공통 화면 크기·키보드·확대와 실제 예약·네트워크 요청 없이 화면 안에서만 움직인다는 조건을 텍스트로 받았다. 화면·문구·규칙은 이미지에 담았다.

가상의 공용 작업실 예약 흐름은 첫 화면에서 공간을 고르고, 두 번째 예약 정보 화면에서 시간과 인원을 입력한 뒤, 세 번째 예약 확인 화면에서 선택값을 확인한다. 질문은 “무엇이 더 좋은가”가 아니라 “같은 화면·연결·검증 규칙을 얼마나 구현하고 수정하는가”였다.

공식 설명: 무엇을 할 수 있다고 하나

Google Labs의 UI 생성 도구 Stitch는 자연어와 이미지로 UI 디자인과 프런트엔드 코드를 만들 수 있다고 발표됐다. 이후 이미지·텍스트·코드를 맥락으로 쓰고 자연어로 수정하며 여러 화면을 연결할 수 있다고 설명했다. CSS/HTML과 Figma 전달 방법도 발표됐다. 그러나 기능 설명과 특정 입력의 성공 증거는 다르다. 아래는 2026년 9월 20일의 관찰이다.

직접 관찰: 한 번씩, 재시도 없이

Stitch 웹의 로그인된 비공개 프로젝트에서 기기 유형은 앱, 모델 모드는 Balanced였다. 텍스트를 먼저, 와이어프레임을 다음에 넣었다. 각 경로는 기본 생성 1회와 수정 E1~E3를 각각 1회만 수행했다. 생성·수정 요청은 모두 8회였고 재시도와 반복 실험은 없었다.

이 실험용 한국어 명세에서 두 결과 모두 3개 화면과 6개 버튼·입력 요소, 두 이동 경로를 만들었다. 시간 미선택, 인원 범위 이탈, 마감 시간의 오류와 정상 회복도 정한 범위에서 작동했다. 키보드 조작, 조작 요소와 연결된 이름, 브라우저 200% 확대도 제한적으로 확인했다. 다만 텍스트 결과는 인원 입력을 비우면 즉시 2를 되살려 빈 값 오류를 시험하지 못했고, 와이어프레임 결과에서는 확인했다. 같은 요구도 전자는 선택 상자, 후자는 두 라디오 버튼으로 구현됐다. 경로당 한 번의 결과일 뿐 입력 방식의 점수나 우위가 아니다.

수정 방식도 달랐다. E1의 버튼 문구는 두 경로 모두 해당 요소에 바로 반영됐다. E2의 검증 문구 추가와 E3의 화면 연결 변경은 관련 화면 요소 묶음을 새로 만드는 부분 재생성이었다. 바꾸라고 하지 않은 문구·경로·상태에서는 회귀가 보이지 않았지만, 모든 픽셀이나 숨은 상태를 검사하지는 않았다.

E3는 편집자의 확인 지점을 보여 줬다. 지시는 선택한 시간과 인원을 유지하면서 버튼 목적지만 두 번째 화면으로 바꾸고 문구는 유지하라는 것이었다. 두 결과 모두 기능 조건을 통과했지만 버튼 이름은 계속 공간 목록으로였다. Stitch가 문구 수정을 놓친 것이 아니라, 시험 설계에서 의도적으로 남긴 이름과 이동 위치의 불일치다.

사용량(크레딧) 표시는 실행 전 0 / 400, 마지막 관찰에서 12 / 400이었다. 400은 화면에 표시된 허용량이다. 중간 값이 늦게 갱신돼 요청당 크레딧을 계산하지 않았고, 마지막 수치가 최종 요청까지 반영했는지도 단정하지 않는다. 실행 중 화폐 결제나 구매·체험 안내는 나타나지 않았다.

이미지 업로드 때는 HTML 내보내기를 위해 이미지에 안정적인 공개 URL이 생긴다는 안내가 표시됐다. 비공개 프로젝트도 이 안내를 없애지 않았다. 이번에는 민감한 내용이 없는 합성 와이어프레임 한 장에만 동의하고 업로드했다. 이 관찰만으로 공개 목록 노출, URL 발견 가능성, 보존 기간, 기밀성, 모델 학습·처리 사용 여부를 알 수 없다. 민감하거나 식별 가능한 자료는 조건을 확인하기 전에 올리지 않는 편이 안전하다.

판단: 프로토타입 관찰과 전달 검증은 다르다

이번 한 번씩의 실행에서는 두 입력 모두 연결형 프로토타입과 세 번의 수정을 충족했다. 그러나 E3의 레이블 부채가 남아 쓸 준비가 됐다고 할 수 없다. 반복 실행이 없고 생성된 조작 요소도 달랐으므로 입력 방식의 우열이나 성공률도 말할 수 없다. 키보드·이름·확대 확인 역시 일부 미리보기 항목의 관찰일 뿐, 더 넓은 접근성 준수 판정이 아니다.

내보내기와 다운로드는 실험 설계에서 제외했다. 화면의 내보내기 조작은 누르지 않았고 파일, 프런트엔드 코드, 의존성, 로컬 실행을 확인하지 않았다. 개발 전달은 실패가 아니라 not_tested, 즉 시험하지 않은 상태다. 공식 발표나 버튼만으로 이 공백을 메울 수 없다.

비슷한 도구를 시험할 때의 체크리스트

• 두 입력에 같은 화면, 문구, 경로, 오류 조건을 먼저 고정한다.
• 수정할 대상과 바뀌면 안 되는 대상을 함께 적는다.
• 수정 뒤 버튼 이름과 실제 이동 위치가 맞는지 확인한다.
• 빈 값·범위 밖 값·정상 회복과 키보드·확대 상태를 직접 눌러 본다. 키보드와 확대는 기본 점검이지 접근성 판정이 아니다.
• 수정이 요소 직접 변경인지 부분 재생성인지 구분한다.
• 크레딧 갱신과 이미지 URL·데이터 처리 조건을 입력 전에 확인하고, 확인 전에는 민감정보를 올리지 않는다.
• 미리보기 성공과 파일 전달 검증을 별도 항목으로 남긴다.

이런 UI 생성 도구는 연결된 화면을 미리 움직여 보는 데 유용할 수 있다. 그래도 동작과 레이블이 맞는지, 확인하지 않은 단계가 무엇인지는 따로 기록해야 한다. 이번 실험의 유용한 산출물은 승자표가 아니라 그 경계선이었다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.