Stitch 인터페이스와 작업 방식 익히기
Stitch를 처음 열면 많은 사람이 먼저 버튼부터 찾습니다. 어디를 눌러야 생성되는지, 테마는 어디서 바꾸는지, Figma로 보내는 버튼은 어디 있는지부터 확인하죠. 물론 그것도 중요합니다. 하지만 더 중요한 건 따로 있습니다. Stitch는 전통적인 디자인 툴처럼 "내가 하나하나 그리는 공간"이 아니라, AI에게 맥락을 주고 방향을 조정하는 공간이라는 점입니다.
이 차이를 이해하면 인터페이스가 훨씬 덜 복잡하게 보입니다. 반대로 이 차이를 놓치면, 분명 같은 버튼을 눌렀는데도 결과는 들쭉날쭉하게 느껴집니다. 결국 Stitch를 잘 쓰는 사람은 버튼 위치를 많이 외운 사람이 아니라, 이 도구가 어떻게 생각하고 반응하는지 아는 사람입니다.
Stitch는 화면 편집기가 아니라 맥락을 쌓는 캔버스다
Stitch의 최근 흐름에서 가장 중요한 변화는 "AI 네이티브 캔버스"라는 관점입니다. 이제 Stitch는 단순히 프롬프트를 넣고 화면 한 장을 뽑는 생성기가 아니라, 텍스트·이미지·코드·생성된 화면을 한 공간에 놓고 프로젝트 전체 맥락을 따라가는 작업 환경으로 발전하고 있습니다.1
쉽게 말하면, Figma가 "프레임을 정교하게 다듬는 책상"이라면 Stitch는 "아이디어를 펼쳐놓고 방향을 탐색하는 작업실"에 가깝습니다. 그래서 Stitch 안에서는 한 장의 결과물보다도, 지금까지 어떤 화면을 만들었고, 무엇을 고정하고, 무엇을 바꾸려는지가 더 중요합니다.
이 관점을 잡고 나면 인터페이스도 다르게 읽힙니다. 캔버스는 단순히 결과를 보여주는 영역이 아니라, 프로젝트의 기억을 쌓는 장소입니다. 프롬프트 입력창은 명령줄이 아니라 대화 창에 가깝고, 화면 선택은 파일 선택이 아니라 "이 방향으로 더 밀고 갈지"를 정하는 일에 가깝습니다.
프로젝트 구조는 '한 장의 화면'이 아니라 '흐름' 중심으로 본다
Stitch 초보자가 가장 많이 하는 실수는 생성된 첫 화면을 보고 바로 품평회에 들어가는 것입니다. "예쁘다", "안 예쁘다"만 따지면 작업이 금방 막힙니다. Stitch에서는 개별 화면보다 프로젝트 단위의 흐름을 먼저 보는 습관이 필요합니다.
프로젝트를 볼 때는 대체로 이런 순서로 이해하면 편합니다.
프로젝트: 하나의 제품 아이디어 또는 작업 묶음
캔버스: 그 프로젝트 안에서 아이디어와 화면이 펼쳐지는 공간
화면: 실제로 생성된 웹 또는 모바일 UI 단위
변형과 히스토리: 같은 의도를 다른 방향으로 실험한 흔적
이 구조를 이해하면 마음이 편해집니다. 첫 결과가 애매해도 괜찮습니다. 그건 실패작이 아니라, 다음 선택을 위한 재료일 뿐이니까요.
특히 Stitch의 디자인 에이전트는 프로젝트의 진행 맥락을 바탕으로 추론하도록 설계되어 있습니다. 즉, 지금 보고 있는 한 화면만 따로 보는 것이 아니라, 이전에 만든 결과와 선택한 방향을 함께 참고하려는 성격이 있습니다.1 그래서 한 프로젝트 안에서 계속 수정할수록 더 일관된 결과를 얻기 쉬워집니다.
무한 캔버스를 읽는 눈부터 길러야 한다
무한 캔버스라는 말은 멋있어 보이지만, 처음에는 조금 막막합니다. 끝없이 넓은 작업 공간에 화면들이 놓여 있으면, 도대체 어디서부터 봐야 할지 헷갈리거든요.
이때는 캔버스를 "정답 보관함"이 아니라 "비교 실험판"이라고 생각하면 좋습니다. 서로 다른 시안, 다른 분위기, 다른 레이아웃이 한 공간에 놓이기 때문에, Stitch는 자연스럽게 비교와 선택의 리듬으로 작업하게 만듭니다.1
무한 캔버스에서 중요한 것은 세 가지입니다.
첫째, 가까이 보기보다 멀리 보는 습관입니다. 화면 하나를 확대해서 버튼 모서리만 보지 말고, 여러 결과가 어떤 방향으로 갈라지고 있는지 먼저 보세요.
둘째, 결과를 버리지 말고 남겨두는 태도입니다. 지금은 별로여도 나중에 다시 섞어 쓸 수 있습니다. Stitch는 종종 첫 번째 안보다 세 번째 안, 혹은 첫 번째 안의 헤더와 네 번째 안의 카드 스타일을 조합할 때 더 좋아집니다.
셋째, 캔버스 안의 모든 요소를 맥락으로 본다는 점입니다. 텍스트 메모, 참고 이미지, 이전 화면도 모두 다음 생성의 힌트가 될 수 있습니다.1
이쯤 되면 Stitch 인터페이스가 단순한 디자인 툴이 아니라, AI와 함께 생각을 전개하는 보드처럼 느껴지기 시작합니다.
기본 인터페이스는 이렇게 이해하면 된다
버튼 이름을 전부 외울 필요는 없지만, 어떤 영역이 어떤 역할을 하는지는 알아야 합니다. Stitch의 기본 인터페이스는 대략 다음 흐름으로 이해하면 충분합니다.
상단: 작업 모드와 레이아웃, 히스토리처럼 전체 방향을 바꾸는 요소
중앙 캔버스: 생성된 화면과 참고 자료를 놓고 비교하는 작업 공간
프롬프트 입력 영역: 새 화면을 만들거나 기존 화면을 수정하는 대화 창
화면별 액션: 테마 변경, 변형 생성, 코드 보기, 내보내기 같은 후속 작업
초기 Stitch는 자연어 프롬프트와 이미지 입력을 받아 UI를 만들고, 대화형 수정과 테마 선택, Figma 붙여넣기, 프런트엔드 코드 내보내기를 지원하는 흐름으로 소개되었습니다.2 여기에 최근 버전에서는 무한 캔버스와 프로젝트 맥락이 더 강화된 셈입니다.1
또한 인터페이스 탐색에서 자주 만나는 요소로는 모드 전환, 웹/모바일 레이아웃 선택, 히스토리 확인, 테마 선택, 변형 생성이 있습니다.3 여기서 중요한 건 "기능이 많다"가 아니라, 이 모든 기능이 결국 한 가지 목적을 가진다는 점입니다. 더 빨리 비교하고, 더 쉽게 방향을 바꾸고, 더 적은 비용으로 일관성을 유지하는 것 말입니다.
화면 선택은 '가장 예쁜 안'이 아니라 '가장 수정하기 좋은 안'을 고르는 일이다
Stitch가 여러 시안을 보여주면 사람은 본능적으로 제일 화려한 걸 고르고 싶어집니다. 하지만 실무에서는 조금 다르게 접근하는 편이 좋습니다. 좋은 선택은 대개 가장 완성된 안이 아니라, 가장 다듬기 쉬운 안입니다.
화면을 고를 때는 다음 네 가지를 먼저 보세요.
정보 위계가 분명한가
레이아웃이 목적에 맞게 단순한가
다음 화면이나 다음 수정으로 이어지기 쉬운가
스타일보다 구조가 안정적인가
예를 들어 카드 디자인이 조금 심심하더라도, 전체 구조가 명확하고 섹션 배치가 좋다면 그 안이 더 유리합니다. 색상과 분위기는 테마나 후속 수정으로 얼마든지 바꿀 수 있지만, 구조가 꼬인 화면은 계속 손이 갑니다.
Stitch를 잘 쓰는 사람은 처음부터 완벽한 안을 찾지 않습니다. 대신 "이 안을 베이스로 삼으면 다음 수정이 덜 힘들겠다"를 먼저 봅니다. 이게 진짜 작업 감각입니다.
히스토리는 되돌리기 기능이 아니라 사고의 기록이다
히스토리를 그냥 "이전 결과 보기" 정도로만 생각하면 아깝습니다. Stitch에서 히스토리는 내가 어떤 방향을 시도했고, 어느 지점에서 결과가 좋아졌는지를 추적하는 작업 기록에 가깝습니다.3
이 기능이 중요한 이유는 AI 작업이 늘 직선으로 나아가지 않기 때문입니다. 어떤 날은 첫 번째 생성이 제일 좋고, 어떤 날은 다섯 번째 수정이 오히려 퇴보처럼 느껴지기도 합니다. 이럴 때 히스토리가 있으면 마음이 덜 급해집니다. 잘못 왔다 싶으면 돌아갈 수 있고, 잊고 있던 좋은 포인트를 다시 꺼낼 수도 있으니까요.
히스토리를 볼 때는 단순히 "어느 버전이 더 예쁘지?"만 보지 마세요. 오히려 이런 질문이 더 좋습니다.
"어느 시점부터 구조가 좋아졌지?"
"언제부터 과하게 장식되기 시작했지?"
"내가 추가한 조건 중 무엇이 결과를 망쳤지?"
이런 식으로 보면 히스토리는 저장 기능이 아니라 학습 도구가 됩니다.
변형 생성은 새로운 그림 뽑기가 아니라 탐색 반경을 넓히는 기능이다
변형 생성은 Stitch에서 특히 강력한 기능입니다. 같은 의도를 유지한 채 레이아웃, 구성, 스타일을 여러 방향으로 흔들어 볼 수 있기 때문입니다. Google은 초기부터 빠른 반복과 디자인 탐색을 위해 여러 인터페이스 변형을 생성할 수 있다고 설명해 왔습니다.2
여기서 중요한 건 변형 생성의 목적입니다. "더 예쁜 걸 하나 얻는다"가 아니라, "현재 안의 가능성을 주변까지 넓혀 본다"에 가깝습니다.
예를 들어 홈 화면이 이미 어느 정도 괜찮다면, 처음부터 새로 프롬프트를 쓰기보다 변형 생성으로 주변 해를 보는 편이 좋습니다. 그러면 같은 제품 성격을 유지하면서도,
카드가 더 미니멀한 버전
섹션 간격이 더 넓은 버전
같은 구조를 유지하되 색감만 달라진 버전
강조 요소의 위치가 조금 다른 버전
같은 식으로 비교가 쉬워집니다.
이 기능을 쓸 때 요령은 간단합니다. 큰 방향이 맞을 때 변형을 만들고, 큰 방향이 틀렸을 때는 새로 설명하세요. 즉, 변형 생성은 방향 전환보다 방향 확장에 더 잘 맞습니다.
테마는 마지막 장식이 아니라 일관성을 잡는 손잡이다
초보자는 대개 구조를 다 보기 전에 테마부터 바꿉니다. 다크 모드가 멋져 보이고, 색 팔레트도 금방 분위기를 바꿔주기 때문이죠. 하지만 테마는 화장보다 조명에 가깝습니다. 화면의 인상을 크게 바꾸지만, 구조가 나쁘면 그걸 숨겨주지는 못합니다.
Stitch는 테마 선택과 색상 조정으로 결과물의 분위기를 빠르게 바꿀 수 있고,2 최근에는 디자인 시스템을 더 깊게 다루기 위한 흐름도 강화하고 있습니다. URL에서 스타일을 추출하거나 DESIGN.md처럼 디자인 규칙을 불러와 프로젝트에 적용하는 방식이 대표적입니다.1
물론 지금 단계에서는 복잡한 디자인 시스템을 외울 필요는 없습니다. 다만 한 가지만 기억하면 됩니다. 테마는 예쁘게 보이게 하는 기능이 아니라, 여러 화면을 같은 제품처럼 느끼게 만드는 기능이라는 점입니다.
그래서 실제 작업에서는 이런 순서가 안전합니다. 먼저 구조를 고르고, 그다음 테마를 맞춥니다. 구조가 정리되지 않은 상태에서 테마를 계속 바꾸면, 눈은 즐거운데 판단은 흐려집니다.
Stitch와 잘 맞는 수정 방식이 따로 있다
Stitch는 세밀한 좌표 입력보다 의도 중심의 수정에 강합니다. 그래서 수정 요청도 "무엇을 몇 픽셀 옮겨줘"보다 "이 화면이 더 명확하고 편안하게 느껴지게 해줘" 같은 말에서 시작하는 편이 잘 맞습니다. 물론 구체성은 필요합니다. 다만 그 구체성은 수치보다 목적에 가까워야 합니다.
실전에서는 다음처럼 말하면 잘 통합니다.
현재 상태를 짚는다: "카드 간격이 조금 답답해 보여."
바꿀 방향을 말한다: "세로 여백을 늘리고 정보 묶음을 더 분명하게 나눠줘."
고정할 것을 알려준다: "상단 구조와 하단 내비게이션은 유지해줘."
이 세 문장이 있으면 Stitch는 무엇을 건드리고, 무엇을 건드리지 말아야 하는지 훨씬 잘 이해합니다. 이 방식은 프롬프트 작성법의 기술이라기보다, 인터페이스 안에서 Stitch와 협업하는 대화법에 가깝습니다.
초보자가 자주 헤매는 지점
처음 사용할 때 흔히 빠지는 함정도 있습니다.
첫 결과를 최종안처럼 대한다
매번 새로 만들기만 하고 기존 안을 선택해 발전시키지 않는다
예쁜 색과 이미지에 먼저 끌려 구조 판단을 놓친다
수정 요청을 너무 많이 한 번에 넣어 무엇이 바뀌었는지 알 수 없게 만든다
이런 실수는 모두 같은 문제로 이어집니다. 캔버스를 탐색 공간이 아니라 정답 맞히기 시험장처럼 대한다는 점입니다.
Stitch는 정답을 한 번에 내놓는 도구가 아닙니다. 오히려 여러 방향을 빠르게 실험하고, 좋은 조합을 찾아가는 도구에 가깝습니다. 그러니 결과가 조금 흔들려도 이상한 게 아닙니다. 그 흔들림 자체가 작업 방식의 일부입니다.
결국 익혀야 하는 것은 '도구 조작'이 아니라 '작업 리듬'이다
이 챕터의 핵심을 한 문장으로 정리하면 이렇습니다.
Stitch는 버튼을 눌러 결과를 받는 도구가 아니라, 맥락을 쌓고 선택을 반복하면서 점점 좋은 방향으로 몰아가는 도구입니다.
무한 캔버스는 그래서 중요합니다. 한 화면만 보는 습관에서 벗어나게 해주기 때문입니다. 프로젝트 구조를 이해해야 하는 이유도 같습니다. Stitch는 개별 프레임보다 흐름을 더 잘 다루는 도구이기 때문입니다. 히스토리와 변형 생성이 강력한 이유도 분명합니다. 잘못 가는 것을 막아주기보다, 더 넓게 탐색하게 해주기 때문입니다.
이 감각만 익히면 인터페이스는 갑자기 단순해집니다. 어디에 무슨 버튼이 있는지는 금방 익힙니다. 하지만 어떤 순간에 화면을 고르고, 언제 변형을 만들고, 언제 히스토리로 돌아가고, 언제 테마를 만질지는 작업 철학이 있어야 보입니다.
그리고 바로 그 철학이, Stitch를 그냥 신기한 AI 툴이 아니라 실제로 쓸 만한 디자인 파트너로 바꿔 줍니다.
참고
1Introducing "vibe design" with Stitch
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.