Google Stitch·Pomelli·Mixboard·Opal 활용법: 디자인·마케팅·자동화에 무엇을 써야 할까

Gemini가 있는데 왜 도구를 또 나눌까

범용 챗봇은 빈 입력창에서 시작한다. 사용자는 질문, 자료, 형식, 제약, 후속 지시를 대화 안에서 계속 들고 있어야 한다. 이는 조사와 초안 작성에는 강력하지만, ‘이 화면이 다음 화면으로 어떻게 이어지는가’, ‘브랜드의 색·사진·말투를 다음 캠페인에서도 어떻게 유지할 것인가’, ‘같은 작업을 동료가 같은 품질로 다시 하려면 무엇을 정해 둬야 하는가’ 같은 질문에는 충분한 작업 환경이 아니다.

Google Labs의 네 서비스는 그 빈칸을 서로 다르게 채운다. Stitch는 자연어 설명을 완성도 높은 UI 시안으로 바꾸는 AI 디자인 캔버스다. Pomelli는 사업체의 웹사이트와 자료에서 브랜드 정체성을 읽어 ‘Business DNA’로 만들고, 그 문맥을 캠페인과 소재에 적용한다. Mixboard는 이미지와 텍스트를 한 보드 위에서 확장·조합·수정하며 방향을 찾는 콘셉팅 보드다. Opal은 자연어와 노드 기반 편집으로 AI 미니 앱을 만들고 공유하는 환경이다. Google Labs, Opal 공식 사이트

이것을 ‘Gemini의 대체품’으로 볼 필요는 없다. 같은 생성형 역량이라도 결과물이 놓이는 장소와 다음 행동이 다르다. Stitch의 산출물은 화면과 프로토타입이고, Pomelli의 산출물은 브랜드에 묶인 캠페인 자산이며, Mixboard의 산출물은 합의 가능한 시각 방향이다. Opal의 산출물은 한 번의 답변이 아니라 다시 실행하고 공유할 수 있는 흐름이다. 도구 선택은 모델 이름이 아니라 어떤 결과물을 만들고 다음 단계에서 누가 이어받는지를 기준으로 해야 한다.

그렇다고 네 도구가 하나의 통합 업무 플랫폼으로 설계됐거나 언젠가 합쳐질 것이라고 단정할 근거는 없다. 다만 Google이 공식적으로 각기 다른 실험으로 제공하는 제품을 보면, 범용 대화창에서 하던 일을 디자인·브랜딩·콘셉팅·워크플로로 세분화하는 흐름은 읽을 수 있다. 이는 제품 전략에 대한 해석이지, Google이 공식 선언한 통합 로드맵은 아니다. Google Labs 자체도 초기 단계 제품을 시험하고 피드백을 받는 공간이라고 설명한다. Google Labs 공식 블로그

먼저 ‘무엇을 만들 것인가’로 고르기

기능표부터 보면 네 도구가 모두 이미지와 텍스트를 다루는 비슷한 서비스처럼 보인다. 실무의 질문 순서를 바꾸면 구분이 선명해진다. 지금 필요한 것이 한 장의 정답인가, 여러 후보를 비교할 공간인가, 화면 흐름인가, 여러 단계를 반복할 작은 프로그램인가를 먼저 정한다.

업무가 경계에 있으면 한 도구만 고집할 이유도 없다. 예컨대 신제품 출시 준비는 Mixboard로 톤과 비주얼 방향을 탐색한 뒤, Stitch로 제품 체험 화면을 구체화하고, Pomelli로 브랜드 소재를 생산하며, Opal로 경쟁사 기사·고객 질문·콘텐츠 초안을 일정한 형식으로 처리할 수 있다. 그러나 이 순서는 권장 워크플로일 뿐, 제품 간 자동 연동을 뜻하지 않는다. 파일을 옮기고, 사실을 확인하고, 승인하는 사람의 작업은 남는다.

Stitch: ‘그럴듯한 화면’이 아니라 검증할 수 있는 제품 흐름을 만드는 도구

Stitch가 적합한 순간은 디자인팀이 없는 경우만이 아니다. PM, 기획자, 마케터, 디자이너가 같은 제품 가설을 보고 대화해야 하지만 아직 와이어프레임을 정교하게 만들 시간은 없을 때다. 현재 Stitch는 자연어 설명에서 완성도 높은 UI 시안(high-fidelity UI)을 만들고, 텍스트·음성·기존 코드베이스·디자인 파일을 맥락으로 받아 캔버스에서 반복을 조정하는 방향으로 확장됐다. 화면을 연결해 재생하는 ‘Prototypes’도 제공한다. Stitch 실시간 디자인 업데이트(Google), Stitch 프로토타입 소개(Google)

SaaS 랜딩페이지와 온보딩을 하루 안에 검증하는 시나리오

가령 1인 사업자를 위한 재고 관리 서비스가 있다고 하자. 기획자는 ‘모바일 우선, 오늘의 재고 위험을 한눈에, 바코드 스캔 뒤 수량 조정, 재주문 제안’이라는 목적을 갖고 있다. 이때 Stitch에 “재고가 부족한 상품을 첫 화면에서 우선 경고하고, 사용자가 상품을 누르면 최근 판매량과 재주문 제안으로 이동하는 한국어 모바일 웹 UI”처럼 기능·사용자·우선순위를 함께 준다. 브랜드 색이나 참고 화면이 있으면 캔버스의 맥락으로 함께 넣는다.

첫 결과는 답이 아니라 질문을 구체화하는 장치다. 경고가 너무 커서 정상 업무를 방해하지 않는가, 재주문 버튼이 너무 이른가, 점주가 숫자보다 추세를 먼저 봐야 하는가를 팀이 화면 위에서 논의할 수 있다. 이어 ‘재고 없음’과 ‘권한 없음’, 스캔 실패처럼 평소 빠지기 쉬운 상태를 추가로 생성한다. 마지막에 화면을 연결해 실제 탭 흐름을 재생하면, 문서에 적힌 사용자 여정이 손가락으로 따라갈 수 있는 가설이 된다.

기존 방식에서는 기획 문서, 저해상도 와이어프레임, 시각 시안, 프로토타입이 별도 산출물로 갈라지기 쉽다. Stitch는 기획 의도를 화면으로 옮기는 초기 커뮤니케이션 비용을 줄인다. 특히 수정 요청을 ‘버튼을 예쁘게’가 아니라 ‘처음 방문한 점주는 설정이 끝나지 않았으므로 빈 상태에서 다음 행동 하나만 보게 하라’처럼 사용자 상황으로 표현할수록 결과의 질이 올라간다. ‘왜 이 화면이 필요한가’가 스타일 지시보다 중요한 이유다.

Stitch를 쓸 때 정교하게 고정할 것

Stitch의 AI 네이티브 캔버스는 이미지·텍스트·코드를 맥락으로 받고, 디자인 에이전트와 Agent manager로 프로젝트의 진행 상황을 추적하며 여러 시안을 동시에 탐색하게 해 준다. URL에서 디자인 시스템을 추출하거나, 디자인 규칙을 담는 DESIGN.md를 가져오고 내보낼 수 있다는 설명도 있다. 이는 반복되는 화면에서 색, 글꼴, 간격, 컴포넌트 원칙을 다시 설명하는 일을 줄이는 데 유용하다. Stitch의 AI 네이티브 캔버스·디자인 시스템(Google), DESIGN.md 사양 공개(Google)

실무자는 여기서 ‘브랜드 규칙’과 ‘제품 규칙’을 분리해 넣는 편이 좋다. 브랜드 규칙은 색·타이포그래피·톤이다. 제품 규칙은 로그인 전후 권한, 필수 필드, 오류 상태, 빈 상태, 모바일·데스크톱 우선순위, 접근성 기준이다. 전자는 화면의 일관성을, 후자는 사용성의 일관성을 만든다. 어느 하나가 빠지면 결과는 보기 좋지만 논의하기 어려운 시안이 된다.

개발에 넘기는 흐름도 현실적으로 봐야 한다. Stitch는 Google AI Studio로 공유 링크를 만들고, Google Antigravity로 내보내 백엔드 로직을 연결하거나 Netlify로 웹에 게시하는 경로를 소개한다. 하지만 화면 산출물이 데이터 모델, 인증, 오류 복구, 성능, 보안 검토까지 구현해 준다는 뜻은 아니다. Antigravity는 여기서 시각 결과를 구현 단계로 잇는 보조 접점일 뿐, Stitch가 완성된 서비스나 Figma 기반 운영 디자인 시스템을 자동으로 대체한다고 읽어서는 안 된다. Stitch 공유·내보내기 안내(Google)

Stitch를 피하거나 보류할 상황

이미 수백 개 컴포넌트와 토큰, 승인된 라이브러리를 엄격히 운영하는 조직이라면 Stitch의 첫 역할은 ‘대체’가 아니라 탐색용 샌드박스다. 생성한 화면이 기존 컴포넌트 사양을 위반하지 않는지, 실제 콘텐츠 길이와 번역 문자열에서 깨지지 않는지, 키보드 탐색·명도 대비·스크린리더가 요구 수준을 만족하는지는 전문 검증이 필요하다. 금융·의료·공공처럼 화면 문구와 절차가 규정 대상인 서비스도 생성 결과를 확정 문안으로 쓰지 말아야 한다.

이 도구의 성공 지표는 생성한 화면 수가 아니다. 사용자 인터뷰나 내부 리뷰에서 ‘무엇을 만들지’에 대한 불확실성을 얼마나 빨리 줄였는지, 개발 전 바뀐 요구가 얼마나 일찍 드러났는지로 본다. 그 기준을 두면 아름다운 한 장을 만드는 요청보다, 상충하는 두 흐름을 나란히 비교하는 요청이 더 가치 있을 때가 많다.

Pomelli: 이미지 생성기가 아니라 브랜드 문맥을 먼저 만드는 마케팅 작업대

Pomelli를 단순 이미지 생성 서비스와 구분하는 핵심은 결과 이미지가 아니라 앞단의 ‘Business DNA’다. 사용자가 사업 웹사이트를 넣으면 Pomelli는 그 사이트와 기존 이미지에서 말투, 글꼴, 색상 팔레트 등을 읽어 브랜드 정체성 프로필을 만들고, 이후 캠페인 아이디어와 자산을 그 프로필에 근거해 생성한다. 현재 웹사이트가 없어도 문서·사진을 올리거나 Pomelli Agent와 대화해 Business DNA를 만들 수 있고, Google Business Profile 정보 활용을 선택할 수도 있다. Pomelli 출시 발표(Google), Business DNA 및 Catalog 도움말

브랜드 웹사이트에서 캠페인까지: 소규모 사업자의 현실적 활용법

예를 들어 지역 커피 구독 서비스가 계절 한정 원두를 출시한다고 하자. 기존 방식은 마케터가 웹사이트에서 브랜드 문구와 제품 사진을 찾아 디자이너에게 브리프를 만들고, SNS·광고·랜딩페이지용으로 각 규격의 소재를 요청하는 식이다. Pomelli에서는 먼저 웹사이트를 분석해 생성한 Business DNA를 검토한다. ‘친환경’이라는 표현이 실제 인증을 뜻하는지, 웹사이트의 오래된 색이 여전히 유효한지, 자동 추출한 글꼴과 사진이 현재 브랜드 자산인지 확인하는 단계다. 이 검토가 생략되면 이후 모든 생성물이 틀린 기준을 반복한다.

그다음 ‘산미를 어려운 용어 없이 설명하고, 정기 구독자의 아침 루틴을 강조하며, 선착순이나 가격 할인은 언급하지 않는다’처럼 캠페인 제약을 준다. Pomelli는 맞춤 캠페인 아이디어를 제안하고, 소셜·웹·광고용 자산을 만들며 도구 안에서 텍스트와 이미지를 수정하고 내려받을 수 있다. 제품·서비스 목록(Catalog)을 만들어 특정 상품에서 곧바로 캠페인이나 Photoshoot를 시작할 수도 있다. Pomelli 공식 소개, Pomelli Photoshoots 도움말

여기서 줄어드는 일은 ‘매번 빈 프롬프트에서 브랜드를 다시 설명하는 일’과 ‘하나의 아이디어를 채널별 초안으로 바꾸는 일’이다. 반대로 없어지지 않는 일은 원두 산지, 재고, 배송일, 할인 조건처럼 외부에서 검증 가능한 사실을 원본 데이터로 다시 확인하는 작업이다.

브랜드북과 Photoshoot가 유용한 이유

Business DNA가 갖는 진짜 가치는 한 번의 캠페인보다 팀의 공통 기준이다. Pomelli는 DNA를 바탕으로 이미지·글꼴·색상을 담은 Brand Book을 만들고 PDF로 내려받거나 공개·공유할 수 있다. 외부 협력사나 새 콘텐츠 담당자가 들어왔을 때 ‘이 브랜드처럼 보이게’라는 모호한 지시를 줄이는 출발점이 될 수 있다. 다만 생성된 브랜드북도 승인된 CI 문서가 아니라면 초안으로 다뤄야 한다. Pomelli Brand Book 도움말

Photoshoot는 단일 제품 사진을 스튜디오·생활 장면 이미지로 발전시키는 기능이다. 제품 전체가 잘 보이고, 한 사진에는 제품 하나만 있으며, 조명이 충분하고 추가 그래픽이 없는 입력을 권장한다. 이 조건은 중요한 실무 힌트다. AI가 제품을 ‘이해’한다고 믿기보다, 식별이 쉬운 깨끗한 원본을 주고 실제 로고·색·질감이 보존됐는지를 결과마다 대조해야 한다. Google도 생성 이미지가 제품의 색상·로고·질감 같은 세부를 바꿀 수 있으므로 게시 전 검토를 권고한다. Pomelli 시작하기 도움말, Pomelli Photoshoot 입력 가이드

Pomelli의 접근 조건과 한계

2026년 8월 기준으로 Pomelli 도움말은 18세 이상 사용자를 대상으로 한국을 포함한 지원 국가·지역을 열거하고, 지원 언어를 영어로 안내한다. 기능은 국가에 따라 달라질 수 있다. 현재 실험 단계에서 별도 웹 앱으로 제공되며, Google은 현재 무료로 쓸 수 있고 이미지·영상을 수백 건 규모로 생성할 수 있다고 안내하면서, 한도가 바뀔 수 있다는 점도 함께 밝힌다. 따라서 ‘Google의 무료 도구 4종’처럼 네 제품에 같은 가격·한도를 묶어 말하면 부정확하다. Pomelli 지원 국가와 언어, Pomelli 가격·사용량 안내

또한 웹사이트에 봇 차단이나 캡차가 있으면 분석이 안 될 수 있다. 사내 브랜드 포털, 비공개 가격표, 고객 데이터처럼 공개해도 되는지 불분명한 자료도 무심코 올리지 않는 편이 낫다. Pomelli가 후속 기능으로 Brand books와 웹사이트 생성도 추가했지만, 약관·개인정보 처리방침·결제·접근성·분석 태그까지 갖춘 운영 웹사이트를 자동으로 보증한다는 뜻은 아니다. Pomelli의 새 에이전트 기능 발표(Google)

Mixboard: 정답을 만드는 도구가 아니라 선택지를 비교할 수 있게 만드는 공간

Mixboard는 결과 이미지 한 장을 잘 뽑는 도구로 쓰면 잠재력을 절반만 쓴다. 이 서비스의 본질은 열린 캔버스에서 이미지와 텍스트를 모으고 생성하고 수정하면서 ‘무엇이 더 맞는가’를 눈으로 비교하게 해 주는 콘셉팅 보드다. 텍스트 프롬프트나 미리 채워진 보드에서 시작하고, 이미지를 올리거나 생성하며, 자연어로 작은 수정·이미지 결합을 하고, 재생성·‘more like this’ 같은 방식으로 변형을 넓힐 수 있다. 보드의 이미지 맥락으로 텍스트를 만드는 기능도 있다. Mixboard 출시 발표(Google)

신규 서비스의 비주얼 방향을 찾는 시나리오

여행 예약 서비스가 ‘혼자 가도 외롭지 않은 장기 체류’를 새 콘셉트로 검토한다고 가정해 보자. 이때 바로 로고나 앱 화면을 확정하면, 팀은 스타일 취향을 제품 전략으로 오해하기 쉽다. Mixboard에는 먼저 고객 장면, 체류 공간, 로컬 커뮤니티, 신뢰·안전, 가격대라는 다섯 축을 놓는다. 기존 고객 인터뷰에서 나온 핵심 문장, 합법적으로 사용 가능한 참고 이미지, 경쟁사와 겹치지 않으려는 요소를 함께 올린다.

이후 ‘관광 엽서 같은 화려함은 피하고, 낯선 도시에서의 안심과 동네 감각을 보여 달라’처럼 피해야 할 방향까지 함께 적어 시각 후보를 만든다. 한 방향은 고요한 주거 공간, 다른 방향은 공동 식사와 활동, 또 다른 방향은 실용적 이동 정보를 중심으로 확장한다. 회의의 목표는 가장 예쁜 판을 고르는 것이 아니라, 타깃 고객에게 어떤 가치를 먼저 전달할지 합의하는 일이다. 선택한 보드에서 랜딩페이지의 메인 비주얼, 사진 가이드, 문구 톤의 단서를 뽑아 다음 단계로 넘긴다.

이 과정에서 Mixboard는 Pinterest, Canva, 화이트보드와 비슷해 보일 수 있지만 기능이 같다고 볼 수는 없다. Pinterest는 발견과 저장, 디자인 편집 도구는 제작, 협업 화이트보드는 정리·토론에 각각 강점이 있다. Mixboard의 특성은 보드 안의 맥락을 이용해 후보를 새로 만들고 변형하는 데 있다. 따라서 외부 참고물을 대체한다기보다, 조사 자료와 생성한 아이디어를 한 화면에 놓고 비교하는 용도로 쓰는 편이 맞다.

보드에서 결정을 만들려면 기준을 써 넣어야 한다

‘느낌이 좋다’는 말만 남은 보드는 회의가 끝나면 쓸모가 없다. 보드마다 대상 고객, 전달할 약속, 피해야 할 인상, 적용 매체, 승인자, 참고 이미지의 출처를 짧게 적어 둔다. 예를 들어 ‘신뢰’를 표현한다면 차분한 파란색을 쓰는 것과 실제 후기·보증·정책을 화면에 담는 것은 다른 문제라는 메모도 남긴다. 그래야 이후 Stitch나 Pomelli로 넘길 때 AI가 만든 미학과 사업이 제공하는 사실을 혼동하지 않는다.

최근 Mixboard는 보드 주제에서 발표 자료를 만들고, 셀피 카메라와 PDF 업로드를 지원하며, 이미지 위에 낙서해 수정 영역을 지정하는 기능, 프로젝트당 여러 보드를 두는 방식을 안내했다. 이것은 탐색 보드와 최종 방향 보드를 분리하기에 유용하다. 다만 발표 자료의 문장·수치·이미지 권리는 별도 검증해야 하며, 생성 한도는 실시간 서버 부하와 네트워크 트래픽에 따라 달라질 수 있다고 Google이 고지한다. Mixboard 프레젠테이션·업로드·다중 보드 업데이트(Google)

언제 Mixboard가 과한가

텍스트·색상·규격이 이미 확정된 배너 하나를 납기 안에 수정하는 일이라면 보드 탐색보다 기존 편집 도구가 빠를 수 있다. 법적 승인이 끝난 브랜드 가이드에 맞춰 대량 집행하는 광고라면 Pomelli처럼 브랜드 맥락과 자산 흐름이 있는 도구가 더 직접적일 수 있다. Mixboard는 불확실성이 높고 후보 간 비교가 가치 있는 초기에 특히 유용하다. 결론이 정해진 뒤에도 무한히 후보를 늘리면 결정이 늦어진다.

공개 베타는 처음 미국에서 시작됐지만 이후 180개국 이상으로 확대됐다고 Google이 발표했다. 실제 사용 가능 여부와 기능은 국가별로 달라질 수 있으므로, 팀의 계정·지역에서 확인해야 한다. Mixboard 국가 확대 발표(Google)

Opal: 프롬프트를 ‘누구나 다시 쓰는 업무 도구’로 바꾸는 가장 짧은 길

네 도구 중 Opal이 중요한 이유는 결과물을 만드는 데서 한 걸음 더 나아가, 결과물을 만드는 과정을 제품화하기 때문이다. Opal은 자연어로 AI 미니 앱을 만들고 편집·공유하는 Google Labs 실험이다. 초안은 대화로 만들 수 있고, 이후에는 노드 기반 워크플로에서 논리를 보고 고칠 수 있다. 즉 ‘매주 이 프롬프트를 복사해 붙여넣는 사람’이 아니라, 입력 상자와 출력 형식을 가진 작은 도구를 동료에게 줄 수 있다. Opal 소개(Google)

뉴스 URL을 콘텐츠 브리프로 바꾸는 미니 앱 설계

콘텐츠 팀이 매일 업계 기사에서 블로그 후보를 뽑는다고 하자. 좋은 Opal은 ‘기사 요약해 줘’라는 한 단계 앱이 아니다. 다음처럼 사람이 기존에 하던 판단 순서를 분리해 둔다.

[입력] 기사 URL · 독자군 · 다룰 관점
    ↓
[수집/추출] 원문에서 제목·발행일·주장·인용 후보를 분리
    ↓
[검증 보조] 원문에 없는 추정과 직접 진술을 구분하고, 불확실 항목 표시
    ↓
[해석] 독자 업무에 미치는 변화·반론·추가 확인 질문 정리
    ↓
[생성] 제목 후보, 개요, 사실 확인 목록, 출처 링크 형식화
    ↓
[사람 확인] 원문 대조 → 관점 선택 → 게시 여부 결정

핵심은 중간 결과를 숨기지 않는 것이다. ‘핵심 사실’, ‘해석’, ‘확인이 필요한 주장’을 한 덩어리로 내보내면 편집자가 AI의 문장을 다시 원문과 대조해야 한다. 반대로 각 단계를 노드와 출력으로 나누면 오류가 난 위치와 바꿀 프롬프트가 보인다. 입력도 URL 하나만 받지 말고, 독자군·금지 표현·사실 확인 수준·원하는 출력 형식을 받게 해야 팀마다 다른 기대치를 고정할 수 있다.

Opal은 초기에는 고정된 모델 호출을 연결하는 워크플로 중심이었으나, 현재 ‘generate’ 단계에서 목적에 따라 도구와 모델을 고르는 agent step도 소개했다. 이 에이전트 단계는 웹 검색이나 영상 생성 같은 적합한 경로를 판단할 수 있고, Memory, 조건에 따른 Dynamic routing, 사용자에게 추가 정보를 묻는 Interactive chat을 지원한다고 Google이 설명한다. 고정 단계는 정밀한 형식과 엄격한 로직이 필요할 때, 에이전트 단계는 질문을 보완하거나 경로가 달라질 수 있을 때 선택하는 식이 실용적이다. Opal agent step 발표(Google)

Opal로 만들기 좋은 네 가지 업무

• 영업 전 담당자 브리프: 회사 URL과 미팅 목적을 입력받아 공개 정보 요약, 질문 초안, 위험 신호, 회의록 틀을 만든다. 사실 단정과 개인 정보는 사람 검토 단계로 남긴다.
• 콘텐츠 재활용 도구: 승인된 긴 글을 넣어 뉴스레터 요약, SNS 초안, 영상 대본 개요로 나눈다. 브랜드 보이스와 금지 표현을 고정 입력으로 두면 담당자가 바뀌어도 형식이 흔들리지 않는다.
• 고객 피드백 분류기: CSV나 붙여넣은 응답에서 주제·감정·요청을 분류하고, 각 분류에 원문 예시와 모호한 항목을 함께 낸다. 자동 집계 수치를 보고하는 단계에서는 표본 검증을 붙인다.
• 제품 아이디어 검토기: 문제·대상 사용자·가설을 받으면 반대 가설, 필요한 인터뷰 질문, 낮은 비용의 검증 실험을 만든다. 의사결정 자체를 자동화하지 않고, 회의 전에 논점을 빠뜨리지 않게 하는 역할이다.

여기서 ‘앱을 만든다’는 말은 대형 서비스 개발이 아니라, 코드 없이 작동하는 형태로 아이디어를 검증한다는 뜻이다. Google도 조사 자동화, 데이터 분석, 주간 뉴스레터, 계약서 검토 같은 활용 예를 소개했다. 다만 이는 관찰된 사용 사례일 뿐, 모든 데이터 소스나 업무 시스템을 안전하게 연결한다는 보장은 아니다. Opal 국가 확대와 활용 사례(Google)

n8n·Make와 같지 않은 이유

Opal과 n8n·Make를 ‘자동화 도구’라는 한 단어로 비교하면 잘못 고르기 쉽다. Opal의 강점은 생성형 AI가 중심인 작은 경험을 자연어와 시각적 노드로 빠르게 조립하고, 비개발자도 사용 가능한 인터페이스로 공유하는 데 있다. 프롬프트, 이미지·문서 입력, 모델 생성, 대화형 보완이 작업의 중심일 때 잘 맞는다.

반면 여러 SaaS의 API를 광범위하게 연결하고, 웹훅 이벤트를 지속적으로 받고, 재시도·대기열·세밀한 조건 분기·감사 로그·비밀 관리·권한 분리를 운영해야 한다면 범용 자동화 플랫폼이나 직접 개발한 서비스의 설계가 필요할 수 있다. Google의 공식 소개는 Opal을 자연어 기반 AI 미니 앱 빌더와 노드 워크플로 편집기로 설명한다. 외부 시스템 통합의 폭과 운영 보장을 n8n·Make와 같은 수준이라고 단정할 근거는 없다. Opal 공식 소개

Opal의 데이터 경계도 체크해야 한다. Google의 Gemini Apps 개인정보 안내는 Opal이 Gemini Apps의 일부가 아니며, 생성한 미니 앱·상호작용·업로드한 미디어가 Google Drive의 ‘Opal’ 폴더에 저장된다고 설명한다. 팀은 고객 데이터, 계약서, 비공개 로드맵을 넣기 전 조직의 보안·보존·공유 정책과 계정 권한을 검토해야 한다. Opal 데이터 저장 안내

네 도구를 실제 업무 흐름에 배치하는 법

도구를 네 개 모두 도입할 필요는 없다. 다음 질문에 ‘예’가 많은 하나부터 작은 업무로 시험하는 편이 낫다.

1. 화면이 없어 논의가 공전하는가? 그렇다면 Stitch로 핵심 흐름과 실패 상태까지 포함한 3~5개 화면을 만든다. 회의 끝에는 ‘개발할 화면’이 아니라 ‘인터뷰에서 검증할 가설’을 남긴다.
2. 매번 브랜드 소개서를 복사해 붙이고 채널별 소재를 새로 만드는가? 그렇다면 Pomelli에 승인된 브랜드 자산만으로 Business DNA를 만들고, 한 제품의 작은 캠페인부터 검증한다. 첫 주에는 생성량보다 사실 오류와 수정 시간을 기록한다.
3. 팀이 방향을 정하기 전에 이미지 검색과 슬라이드 정리에 시간을 많이 쓰는가? 그렇다면 Mixboard에서 탐색 보드와 결정 보드를 분리한다. 각 후보에 ‘선택 이유’와 ‘버릴 이유’를 남긴다.
4. 같은 프롬프트를 여러 사람이 반복하고, 결과 형식이 제각각인가? 그렇다면 Opal로 입력·중간 산출물·사람이 최종 확인할 단계를 노드로 고정한다. 자동 발송이나 외부 변경보다 읽기 전용·초안 생성부터 시작한다.

아래의 운영 순서가 안전하다.

작은 업무 하나 선택
    → 승인된 입력 자료와 금지 항목 정의
    → AI 초안과 사람이 승인할 항목을 분리
    → 5~10건의 실제 업무에서 시간·오류·수정량 기록
    → 효과가 확인된 경우에만 공유·외부 연동 확대

여기서 ‘시간 절감’만 재면 실패할 수 있다. Stitch라면 인터뷰 전에 발견한 요구 변경 수, Pomelli라면 브랜드 오류·사실 오류·수정 왕복 수, Mixboard라면 결정까지 걸린 회의 횟수, Opal이라면 재실행 가능한 흐름의 사용률과 예외 처리 수를 함께 본다. 생성물이 많아져도 검토 비용이 같이 늘면 자동화의 이익은 사라진다.

실험 서비스일수록 사람이 확인할 기준을 분명히 정해야 한다

네 서비스는 모두 초기 아이디어와 반복 작업의 병목을 낮추지만, 그만큼 ‘그럴듯한 결과’를 승인된 결과로 오해하기 쉽다. UI는 실제 데이터와 예외 상황을 모르고, 브랜드 생성물은 제품 사양을 보증하지 않으며, 워크플로는 잘못된 입력도 그럴듯한 출력으로 키운다.

그래서 도입 문서에는 최소 네 가지 검토 기준을 정해야 한다. 올려도 되는 자료인가(입력 권한), 가격·효능·일정·정책을 원본 시스템과 대조했는가(사실성), 로고·제품 디테일·인물·상표·저작권 표현을 확인했는가(브랜드와 권리), 외부에 쓰기·발행·발송이 일어난다면 누가 최종 승인하는가(실행 권한)다.

결국 경쟁력은 모델보다 작업 환경에서 나온다

범용 챗봇 하나로 모든 일을 하려 하면 사람은 매번 맥락을 설명하고, 결과를 다른 도구로 옮기고, 다음 담당자에게 다시 설명해야 한다. Stitch·Pomelli·Mixboard·Opal이 보여 주는 변화는 더 강한 모델 하나가 모든 문제를 푼다는 주장보다, 반복되는 맥락과 다음 행동을 제품 안에 남기는 방식에 가깝다.

Stitch는 제품 아이디어를 화면과 흐름으로, Pomelli는 브랜드의 반복 설명을 캠페인 자산으로, Mixboard는 막연한 취향을 비교 가능한 방향으로, Opal은 개인의 프롬프트 습관을 팀이 다시 쓸 수 있는 미니 앱으로 바꾼다. 우열을 가리기보다 각자의 병목에 맞춰 고르면 된다.

첫 시도는 작아야 한다. 다음 분기에 만들 SaaS의 핵심 온보딩 흐름 하나, 이달의 신제품 캠페인 하나, 다음 브랜드 회의의 콘셉트 보드 하나, 매주 반복하는 콘텐츠 브리프 하나면 충분하다. 그 작은 실험에서 사람의 검토 시간까지 포함해 실제로 덜어낸 작업을 측정하면, ‘AI를 쓰고 있다’는 사실보다 훨씬 중요한 답을 얻을 수 있다.

참고 출처

• Design UI using AI with Stitch from Google Labs — AI 네이티브 캔버스·디자인 에이전트·디자인 시스템
• We’re introducing real time design with Google Stitch — 실시간 디자인·음성·AI Studio·Antigravity·Netlify 내보내기
• Stitch’s DESIGN.md format is now open-source — 디자인 규칙 파일 사양 공개
• Google Labs and DeepMind launch AI marketing tool Pomelli — Business DNA 소개
• Pomelli adds new ways to build brand content and design websites — Brand Book·웹사이트 기능
• Get started with Pomelli — 무료 이용과 이미지·영상 생성 안내, 생성 이미지 검토 권고
• Pomelli 지원 국가·언어 — 한국 포함, 현재 영어 지원
• Mixboard is now available in over 180 more countries — 국가 확대
• Create presentations with Nano Banana Pro in Mixboard — 프레젠테이션 생성 등 업데이트
• Google Labs launches agent step in Opal — Agent step·Memory·Dynamic routing·Interactive chat
• Opal is now available in more than 160 countries — 국가 확대와 활용 사례