디자이너가 시안 대신 앱을 만든 이유

토스 UX 디자이너가 AI를 협력자로 삼아 피그마 시안 대신 실제 SwiftUI 코드로 iOS 앱을 직접 구현한 경험을 다룬다. "데드엔드" 화면(송금·결제 완료 등)을 다음 경험의 시작점으로 전환하는 underlay 컴포넌트를 설계하면서 Metal 셰이더 구현까지 디자이너가 주도했고, 완성된 코드를 개발팀에 전달해 협업 방식 자체를 바꿨다.

핵심 포인트

underlay는 overlay(바텀시트·토스트)와 반대 개념 — 화면 위에 띄우는 게 아니라 아래에 깔려 있다가 드러나는 방식으로 사용자 흐름을 방해하지 않는다
Metal 셰이더로 스캔 시각 효과를 구현했고, AI가 초기 코드를 작성하면 디자이너가 빛의 번짐/틴트/폭/속도 등 픽셀 단위 세부값을 반복 조정했다
디자이너 역할은 "경험 설명 → AI 제안 선택 → 실기기 판단"으로 분담해 코딩 경험 없이도 프로토타입을 완성했다
피그마 시안이 아닌 실제 SwiftUI 레포를 개발팀에 전달하자 초기 구현이 시안과 거의 동일했고 파인튜닝을 실시간으로 진행할 수 있었다
개발 가능한 구조로 설계된 시안은 그 자체가 스펙이 된다 — 디자이너의 초점이 "어떻게 만들지"에서 "뭘 만들까"로 이동했다

상세 정리

과제 배경: 토스의 데드엔드 화면(송금·결제 완료)이 유저 여정을 끊어버리는 문제를 해결하고자 underlay 컴포넌트 프로젝트가 시작됐다
underlay 개념: overlay가 "화면 위에 띄우는 것"이라면 underlay는 "원래 거기 있던 것이 드러나는" 개념. 택배 송장을 떼면 밑에 책 문구가 나타나는 것에서 영감을 받았다
프로토타이핑 도구 선택: 프로토파이·프레이머 경험이 없었기 때문에 직접 SwiftUI로 iOS 앱을 개발하는 방향을 택했다
AI 협업 구조: AI가 코드를 작성하면 디자이너가 실기기에서 결과물을 보며 방향을 결정하는 반복 루프. 디자이너는 구체적인 경험을 언어로 설명하는 역할이었다
Metal 셰이더 구현: 스캔 시각 효과를 Metal 셰이더로 구현했다. AI가 작성한 초기 코드를 바탕으로 빛 번짐/틴트 값/폭/속도 같은 파라미터를 픽셀 단위로 반복 조정했다
개발팀 전달: 완성된 SwiftUI 레포를 공유했고 개발 초기 버전이 시안과 거의 동일하게 구현됐다. 인터랙션 가이드 문서보다 실제 코드가 훨씬 명확한 스펙이었다
파인튜닝 협업: 코드를 공유한 상태에서 개발자 노트북을 함께 보며 실시간으로 feel을 맞출 수 있었다
핵심 통찰: "좋은 시안은 보이는 것뿐 아니라 만들어진 방식까지 괜찮아야 한다" — 개발 가능한 구조로 설계된 시안이 스펙 자체가 된다