<div id="readability-page-1" class="page"><div>디자인 과정에서 AI를 쓰며 달라진 것 중 하나는, 디자이너가 직접 동작하는 시안을 만들 수 있게 되었다는 점이에요. 예전에는 디자인을 만들고, 문서로 설명하고, 개발자가 다시 구현하는 과정이 필요했어요. 그런데 AI와 함께 코드를 다루기 시작하면서 디자인과 개발 사이의 번역 과정이 크게 줄어들기 시작했죠.이번 글에서는 토스의 underlay 컴포넌트를 만들며 경험했던 변화를 이야기해 보려고 해요.<h2 id="381a360d-33e3-80f7-9861-cca9f57c3588">경험이 끝난 뒤를 설계하기</h2>토스 앱에는 경험이 끝나는 화면들이 있어요.송금을 마치고 나오는 송금 완료 화면, 결제가 끝난 뒤의 결제 완료 화면처럼 사용자가 할 일을 모두 마친 화면들이죠. 대부분은 거기서 앱을 닫고요.이런 화면들을 '데드엔드'라고 불렀어요. 데드엔드를 더 이상 경험의 끝이 아니라, 다음 경험의 시작점으로 만들고 싶었죠. 그렇게 데드엔드 프로젝트가 시작됐어요.목표는 특정 화면 하나를 개선하는 것이 아니었어요. 앱 안 어디에서든 다음 경험으로 자연스럽게 이어질 수 있도록 돕는 공통된 장치가 필요했죠. 그래서 먼저 컴포넌트를 만드는 것부터 시작하기로 했어요.<h2 id="381a360d-33e3-80ad-8951-ded0630662f7">택배 송장이 준 힌트</h2>컴포넌트를 만들기로 하고 가장 먼저 조건을 정리했어요. 기능으로 인지되어야 하고, 기존 사용자 경험을 해치면 안 되고, 앱 안 어디서든 재사용할 수 있어야 했죠.여러 가지 방향을 시도해 봤어요. 전화가 오는 것처럼 등장하는 방식, 화면 한쪽에 나타나는 방식, 채팅창처럼 올라오는 방식… 그런데 전부 사용자의 동작을 방해할 수밖에 없는 구조였어요.바텀시트, 토스트, 푸시처럼 우리가 익숙하게 사용하는 UI는 대부분 화면 위에 올라오는 구조예요. 사용자의 시선을 끌 수는 있지만, 동시에 사용자가 보고 있던 화면이나 하려던 행동을 방해할 수도 있죠.그래서 기존의 알림성 UI와는 다른 방식이 필요했어요.실마리는 예상치 못한 곳에서 왔어요.이사를 하던 중 택배 상자에 붙어 있던 송장을 떼어냈는데, 그 밑에 가려져 있던 책의 문구가 드러난 거예요. 새로운 것이 나타난 게 아니라 원래 거기 있던 것이 모습을 드러낸 거였죠. 그 순간 관점을 바꿔보게 됐어요. “위에 띄우는 것이 아니라 아래에 존재하던 것이 드러난다면 어떨까?”<figure id="381a360d-33e3-809e-a5c3-f2e6b5f5b165"><video muted="" loop="" autoplay="" playsinline=""><source src="https://static.toss.im/ipd-tcs/toss_core/live/933098fc-c1f3-4d3f-8648-9b47c6601712/v1_framed_3600x2400_from4s.mp4"></video></figure>그렇게 화면 위(overlay)가 아니라 아래에 깔린 컴포넌트, underlay를 만들기로 했어요.<h2 id="381a360d-33e3-8039-8030-d8b9ed5dbf01">인터랙션 툴 대신 코드로 디자인하다</h2>디자인을 시작하면서 곧바로 다른 문제가 생겼어요. 처음에는 피그마로 시안을 만들었어요. 이 컴포넌트는 실제 손안의 화면에서 경험하게 되는 인터랙션이잖아요. 그래서 시안을 폰에 띄워두고 밥을 먹을 때도, 이동할 때도 계속 들고 다니면서 봤어요. "이 느낌이 맞나?" 계속 확인하면서요.피그마 시안을 통해 깨달았어요. underlay는 어떻게 생겼는가보다 어떻게 움직이는가가 더 중요한 컴포넌트였거든요. 인터랙션 자체가 디자인이었죠.문제는 제가 인터랙션 툴을 제대로 다뤄본 적이 없다는 거였어요. 프로토파이 경험도 없고, 프레이머 경험도 없었어요. 대신 다른 방법을 선택했어요. 인터랙션이 중요한 작업이라 웹 개발 대신 SwiftUI 기반으로 Xcode에서 iOS 앱을 직접 만들었어요.<figure id="381a360d-33e3-801f-b9a8-ff48cc53f352"><img src="https://static.toss.im/ipd-tcs/toss_core/live/eb5dfb51-c880-4463-8ca1-d7b953c850a9/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2026-06-11_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.19.38.png" alt=""><figcaption>작업 환경</figcaption></figure>물론 저는 SwiftUI를 다뤄본 적이 없었어요. 하지만 AI가 있었죠. Xcode를 열고, 만들려는 걸 AI에게 시켰어요. 문법은 AI가 알고 있었고, 원하는 결과물은 이미 제 머릿속에 있었어요. 제 역할은 세 가지였어요.<ul><li id="381a360d-33e3-8019-8165-d80bc7571a26">어떤 경험을 만들고 싶은지 설명하기</li><li id="381a360d-33e3-80a6-9096-f863fbd79265">AI가 제안한 방향 중 더 좋은 것을 선택하기</li><li id="381a360d-33e3-80b9-9e9d-f36d7daba8ad">실제 기기에서 결과물을 보고 판단하기</li></ul>AI와 함께 디자인하는 과정은 결국 설계하고, 선택하고, 판단하는 일의 연속이었어요.<h2 id="381a360d-33e3-8005-8b81-f0a5fef6ba2c">작업 순서</h2>1. 기본 환경 세팅하기먼저 이것저것 그려보고 지울 수 있는 저만의 플레이그라운드를 만들었어요. 피그마에서 새 파일을 파는 것처럼요. 컴포넌트가 들어갈 화면 구조를 만들고, 기본 디자인을 올렸어요. 이때 피그마로 작업한 시안을 AI에게 예시로 주기도 했고요.2. 실제로 움직여보며 디자인하기그다음 버튼, 텍스트, 레이아웃 같은 디테일을 하나씩 다듬었어요. 중요한 건 정지 화면으로 보지 않았다는 점이에요. underlay는 인터랙션 자체가 디자인인 컴포넌트였기 때문에, 수정할 때마다 실제 기기에서 직접 움직여봤어요. 상상한 것과 실제로 구현돼서 움직이는 건 생각보다 느낌이 많이 달랐거든요. 그래서 진짜 몇백 번씩 수정했어요.3. 원하는 질감이 나올 때까지 다듬기이 컴포넌트는 화면을 읽고 그 맥락에 맞는 정보를 제공하는 역할을 해요. 그래서 "AI가 화면을 읽고 알맞은 정보를 찾아준다"라는 심상을 만들어보고 싶었어요. 여러 표현을 고민하다가, 빛이 화면을 훑고 지나가는 스캔 인터랙션을 만들기로 했어요. 스캔 효과는 Metal 셰이더로 구현했어요. 셰이더는 화면의 픽셀 하나하나를 어떻게 그릴지 직접 계산하는 그래픽 코드인데, 빛이 번지고 퍼지는 질감은 일반적인 UI 코드로는 표현하기 어렵거든요.처음에는 AI가 작성한 코드를 사용했지만, 계속 수정하다 보니 어느 순간부터는 직접 값을 조정하고 있더라고요. 빛의 번짐, 틴트, 폭, 지나가는 속도, 배경이 어두워지는 정도 같은 요소들을 바꿔가며 원하는 질감을 찾았어요.<figure id="381a360d-33e3-8060-821e-f439491bdcf2"><img src="https://static.toss.im/ipd-tcs/toss_core/live/e11d10a0-67ae-4673-a56d-7e18f00e4aab/Frame_74_1.png" alt=""><figcaption>실제 작업한 메탈 코드</figcaption></figure>스캔이 지나갈 때나 컴포넌트가 등장할 때 미세하게 출렁거리는 디테일도 같은 방식으로 다듬었고요.인터랙션 툴을 한 번도 써본 적 없는 사람이 어느새 셰이더 코드의 숫자를 만지고 있었던 거예요.<h2 id="381a360d-33e3-8043-b09d-c2dc9fe44bf1">디자인 가이드 대신 레포를 전달하다</h2>시안이 완성되고 개발을 시작했어요. 이 미세한 인터랙션을 개발자에게 어떻게 전달해야 할지 고민이 됐죠. 보통이라면 등장 타이밍, 이징 커브, 딜레이 값을 정리한 인터랙션 가이드 문서를 만들었을 거예요. 그런데 이번에는 방식을 조금 바꿔봤어요. 인터랙션에 대한 자세한 가이드 없이 간략한 플로우만 정리하고, 제가 디자인하며 만든 레포를 그대로 전달했죠. 솔직히 괜찮을까 싶었어요. 그런데 개발자분들이 레포를 보더니 "일단 이 정도면 될 것 같다"라고 하시더라고요. 그리고 실제로 첫 개발 버전부터 시안의 기본 구조를 거의 그대로 구현해 주셨어요. 제가 예상했던 것보다 디자인 완성도가 훨씬 높았죠.완성도를 끌어올리는 파인튜닝 단계에서는 더 재미있는 일이 생겼어요. UI 디테일을 조정할 때마다 개발자분들이 저한테 노트북을 주시더라고요.opacity 같은 값은 "0.4로 해주세요 → 빌드 → 음, 0.5로요 → 빌드"를 반복하는 것보다, 직접 보면서 수정하는 편이 훨씬 빠르니까요.그러다 등장 인터랙션 차례가 왔을 때는 개발자분 노트북에서 제가 AI에게 직접 명령을 내리기 시작했어요. 머릿속의 모션을 설명하고, 결과를 보고, 다시 수정하고 명령을 내렸죠. 그랬더니 인터랙션 퀄리티가 확 높아졌어요. 옆에서 보던 개발자분이 그러시더라고요.<blockquote id="381a360d-33e3-809b-baa7-debb5c0e2a44">"얘가 민지 님 말을 더 잘 듣네요…"</blockquote>이 과정이 수월했던 이유 중 하나는 동작하는 레퍼런스가 있었기 때문이에요. 시안 단계에서 직접 만들었던 코드가 있었기 때문에, "느낌이 이상해요" 같은 추상적인 표현 대신 어떤 동작을 원하는지 구체적으로 설명할 수 있었어요. AI와도, 개발자분들과도 같은 결과물을 보며 이야기할 수 있었죠.이런 과정을 거쳐 underlay는 실제 서비스에 적용됐어요. 아직 실험이 진행 중이기는 하지만, 예상했던 것보다 좋은 결과가 나오고 있고요.<h2 id="381a360d-33e3-8093-a923-cc3f0f423104">보이는 것을 넘어, 구조까지 디자인하기</h2>이번 프로젝트에서 가장 신기했던 건 실제 개발된 버전의 코드 구조가 제가 디자인했던 레포와 거의 동일했다는 점이었어요(iOS 기준).처음부터 개발을 염두에 둔 건 아니었어요. UT를 하면서 여러 버전을 빠르게 바꿔보고 싶었고, 제가 테스트하기 편한 구조를 만들다 보니 자연스럽게 그렇게 된 거였죠. 그런데 나중에 보니 그 구조가 실제 개발에도 그대로 활용할 수 있는 형태였어요. 그래서 파인튜닝 과정에서도 수정 사항을 말로 설명하기보다 코드로 전달할 수 있었고요.이게 이 프로젝트에서 가장 크게 배운 점이었어요.좋은 시안은 단순히 보기 좋은 화면만을 의미하지는 않는다는 점이요. "보이는 것"만이 아니라 "만들어진 방식"까지 괜찮아야 하죠. 화면은 같아 보여도 일회용 코드 덩어리였다면 개발자분들은 결국 처음부터 다시 만들었을 거예요. 하지만 개발할 수 있는 구조로 만들어진 시안은 그대로 스펙이 될 수 있었어요.이제 디자이너가 코드로 디자인하는 일 자체는 점점 특별한 일이 아니게 될 것 같아요. 오히려 차이를 만드는 건 그다음이에요. "어떻게 만들지"는 AI가 알고 있으니, 디자이너에게 남는 질문은 "뭘 만들까"거든요. 툴의 제약 때문에 포기했던 것들이 사라진 자리에서, 뭘 상상하고 뭘 만들기로 결정하느냐. 그게 디자인의 전부가 되는 것 같아요.
<h2 id="381a360d-33e3-80ab-a9fe-eddd46f525af">적용해 보기</h2></div></div>

토스테크

디자인 과정에서 AI를 쓰며 달라진 것 중 하나는, 디자이너가 직접 동작하는 시안을 만들 수 있게 되었다는 점이에요. 예전에는 디자인을 만들고, 문서로 설명하고, 개발자가 다시 구현하는 과정이 필요했어요. 그런데 AI와 함께 코드를 다루기 시작하면서 디자인과 개발 사이의 번역 과정이 크게 줄어들기 시작했죠.
이번 글에서는 토스의 underlay 컴포넌트를 만들며 경험했던 변화를 이야기해 보려고 해요.
경험이 끝난 뒤를 설계하기
토스 앱에는 경험이 끝나는 화면들이 있어요.
송금을 마치고 나오는 송금 완료 화면, 결제가 끝난 뒤의 결제 완료 화면처럼 사용자가 할 일을 모두 마친 화면들이죠. 대부분은 거기서 앱을 닫고요.
이런 화면들을 '데드엔드'라고 불렀어요. 데드엔드를 더 이상 경험의 끝이 아니라, 다음 경험의 시작점으로 만들고 싶었죠. 그렇게 데드엔드 프로젝트가 시작됐어요.
목표는 특정 화면 하나를 개선하는 것이 아니었어요. 앱 안 어디에서든 다음 경험으로 자연스럽게 이어질 수 있도록 돕는 공통된 장치가 필요했죠. 그래서 먼저 컴포넌트를 만드는 것부터 시작하기로 했어요.
택배 송장이 준 힌트
컴포넌트를 만들기로 하고 가장 먼저 조건을 정리했어요. 기능으로 인지되어야 하고, 기존 사용자 경험을 해치면 안 되고, 앱 안 어디서든 재사용할 수 있어야 했죠.
여러 가지 방향을 시도해 봤어요. 전화가 오는 것처럼 등장하는 방식, 화면 한쪽에 나타나는 방식, 채팅창처럼 올라오는 방식… 그런데 전부 사용자의 동작을 방해할 수밖에 없는 구조였어요.
바텀시트, 토스트, 푸시처럼 우리가 익숙하게 사용하는 UI는 대부분 화면 위에 올라오는 구조예요. 사용자의 시선을 끌 수는 있지만, 동시에 사용자가 보고 있던 화면이나 하려던 행동을 방해할 수도 있죠.
그래서 기존의 알림성 UI와는 다른 방식이 필요했어요.
실마리는 예상치 못한 곳에서 왔어요.
이사를 하던 중 택배 상자에 붙어 있던 송장을 떼어냈는데, 그 밑에 가려져 있던 책의 문구가 드러난 거예요. 새로운 것이 나타난 게 아니라 원래 거기 있던 것이 모습을 드러낸 거였죠. 그 순간 관점을 바꿔보게 됐어요. 
“위에 띄우는 것이 아니라 아래에 존재하던 것이 드러난다면 어떨까?”
그렇게 화면 위(overlay)가 아니라 아래에 깔린 컴포넌트, underlay를 만들기로 했어요.
인터랙션 툴 대신 코드로 디자인하다
디자인을 시작하면서 곧바로 다른 문제가 생겼어요. 
처음에는 피그마로 시안을 만들었어요. 이 컴포넌트는 실제 손안의 화면에서 경험하게 되는 인터랙션이잖아요. 그래서 시안을 폰에 띄워두고 밥을 먹을 때도, 이동할 때도 계속 들고 다니면서 봤어요. "이 느낌이 맞나?" 계속 확인하면서요.
피그마 시안을 통해 깨달았어요. underlay는 어떻게 생겼는가보다 어떻게 움직이는가가 더 중요한 컴포넌트였거든요. 인터랙션 자체가 디자인이었죠.
문제는 제가 인터랙션 툴을 제대로 다뤄본 적이 없다는 거였어요. 프로토파이 경험도 없고, 프레이머 경험도 없었어요. 대신 다른 방법을 선택했어요. 인터랙션이 중요한 작업이라 웹 개발 대신 SwiftUI 기반으로 Xcode에서 iOS 앱을 직접 만들었어요.
물론 저는 SwiftUI를 다뤄본 적이 없었어요. 하지만 AI가 있었죠. Xcode를 열고, 만들려는 걸 AI에게 시켰어요. 문법은 AI가 알고 있었고, 원하는 결과물은 이미 제 머릿속에 있었어요. 
제 역할은 세 가지였어요.
어떤 경험을 만들고 싶은지 설명하기
AI가 제안한 방향 중 더 좋은 것을 선택하기
실제 기기에서 결과물을 보고 판단하기
AI와 함께 디자인하는 과정은 결국 설계하고, 선택하고, 판단하는 일의 연속이었어요.
작업 순서
1. 기본 환경 세팅하기
먼저 이것저것 그려보고 지울 수 있는 저만의 플레이그라운드를 만들었어요. 피그마에서 새 파일을 파는 것처럼요. 컴포넌트가 들어갈 화면 구조를 만들고, 기본 디자인을 올렸어요. 이때 피그마로 작업한 시안을 AI에게 예시로 주기도 했고요.
2. 실제로 움직여보며 디자인하기
그다음 버튼, 텍스트, 레이아웃 같은 디테일을 하나씩 다듬었어요. 중요한 건 정지 화면으로 보지 않았다는 점이에요. underlay는 인터랙션 자체가 디자인인 컴포넌트였기 때문에, 수정할 때마다 실제 기기에서 직접 움직여봤어요. 상상한 것과 실제로 구현돼서 움직이는 건 생각보다 느낌이 많이 달랐거든요. 그래서 진짜 몇백 번씩 수정했어요.
3. 원하는 질감이 나올 때까지 다듬기
이 컴포넌트는 화면을 읽고 그 맥락에 맞는 정보를 제공하는 역할을 해요. 그래서 "AI가 화면을 읽고 알맞은 정보를 찾아준다"라는 심상을 만들어보고 싶었어요. 여러 표현을 고민하다가, 빛이 화면을 훑고 지나가는 스캔 인터랙션을 만들기로 했어요. 스캔 효과는 Metal 셰이더로 구현했어요. 
셰이더는 화면의 픽셀 하나하나를 어떻게 그릴지 직접 계산하는 그래픽 코드인데, 빛이 번지고 퍼지는 질감은 일반적인 UI 코드로는 표현하기 어렵거든요.
처음에는 AI가 작성한 코드를 사용했지만, 계속 수정하다 보니 어느 순간부터는 직접 값을 조정하고 있더라고요. 빛의 번짐, 틴트, 폭, 지나가는 속도, 배경이 어두워지는 정도 같은 요소들을 바꿔가며 원하는 질감을 찾았어요.
스캔이 지나갈 때나 컴포넌트가 등장할 때 미세하게 출렁거리는 디테일도 같은 방식으로 다듬었고요.
인터랙션 툴을 한 번도 써본 적 없는 사람이 어느새 셰이더 코드의 숫자를 만지고 있었던 거예요.
디자인 가이드 대신 레포를 전달하다
시안이 완성되고 개발을 시작했어요. 이 미세한 인터랙션을 개발자에게 어떻게 전달해야 할지 고민이 됐죠. 보통이라면 등장 타이밍, 이징 커브, 딜레이 값을 정리한 인터랙션 가이드 문서를 만들었을 거예요. 
그런데 이번에는 방식을 조금 바꿔봤어요. 인터랙션에 대한 자세한 가이드 없이 간략한 플로우만 정리하고, 제가 디자인하며 만든 레포를 그대로 전달했죠. 
솔직히 괜찮을까 싶었어요. 그런데 개발자분들이 레포를 보더니 "일단 이 정도면 될 것 같다"라고 하시더라고요. 그리고 실제로 첫 개발 버전부터 시안의 기본 구조를 거의 그대로 구현해 주셨어요. 제가 예상했던 것보다 디자인 완성도가 훨씬 높았죠.
완성도를 끌어올리는 파인튜닝 단계에서는 더 재미있는 일이 생겼어요. UI 디테일을 조정할 때마다 개발자분들이 저한테 노트북을 주시더라고요.
opacity 같은 값은 "0.4로 해주세요 → 빌드 → 음, 0.5로요 → 빌드"를 반복하는 것보다, 직접 보면서 수정하는 편이 훨씬 빠르니까요.
그러다 등장 인터랙션 차례가 왔을 때는 개발자분 노트북에서 제가 AI에게 직접 명령을 내리기 시작했어요. 머릿속의 모션을 설명하고, 결과를 보고, 다시 수정하고 명령을 내렸죠. 그랬더니 인터랙션 퀄리티가 확 높아졌어요. 옆에서 보던 개발자분이 그러시더라고요.
"얘가 민지 님 말을 더 잘 듣네요…"
이 과정이 수월했던 이유 중 하나는 동작하는 레퍼런스가 있었기 때문이에요. 
시안 단계에서 직접 만들었던 코드가 있었기 때문에, "느낌이 이상해요" 같은 추상적인 표현 대신 어떤 동작을 원하는지 구체적으로 설명할 수 있었어요. AI와도, 개발자분들과도 같은 결과물을 보며 이야기할 수 있었죠.
이런 과정을 거쳐 underlay는 실제 서비스에 적용됐어요. 아직 실험이 진행 중이기는 하지만, 예상했던 것보다 좋은 결과가 나오고 있고요.
보이는 것을 넘어, 구조까지 디자인하기
이번 프로젝트에서 가장 신기했던 건 실제 개발된 버전의 코드 구조가 제가 디자인했던 레포와 거의 동일했다는 점이었어요(iOS 기준).
처음부터 개발을 염두에 둔 건 아니었어요. UT를 하면서 여러 버전을 빠르게 바꿔보고 싶었고, 제가 테스트하기 편한 구조를 만들다 보니 자연스럽게 그렇게 된 거였죠. 그런데 나중에 보니 그 구조가 실제 개발에도 그대로 활용할 수 있는 형태였어요. 그래서 파인튜닝 과정에서도 수정 사항을 말로 설명하기보다 코드로 전달할 수 있었고요.
이게 이 프로젝트에서 가장 크게 배운 점이었어요.
좋은 시안은 단순히 보기 좋은 화면만을 의미하지는 않는다는 점이요. "보이는 것"만이 아니라 "만들어진 방식"까지 괜찮아야 하죠. 화면은 같아 보여도 일회용 코드 덩어리였다면 개발자분들은 결국 처음부터 다시 만들었을 거예요. 하지만 개발할 수 있는 구조로 만들어진 시안은 그대로 스펙이 될 수 있었어요.
이제 디자이너가 코드로 디자인하는 일 자체는 점점 특별한 일이 아니게 될 것 같아요. 오히려 차이를 만드는 건 그다음이에요. "어떻게 만들지"는 AI가 알고 있으니, 디자이너에게 남는 질문은 "뭘 만들까"거든요. 툴의 제약 때문에 포기했던 것들이 사라진 자리에서, 뭘 상상하고 뭘 만들기로 결정하느냐. 그게 디자인의 전부가 되는 것 같아요.
적용해 보기
underlay의 이야기는 여기까지지만, 이 방식은 어떤 프로젝트에서든 시도해볼 수 있어요. 
1️⃣ 툴의 제약 없이 가장 좋은 디자인부터 생각하기
디자인하고 싶은 게 있다면 더 이상 툴의 제약은 없어요. "만들 수 있는 디자인"이 아니라 "가장 좋은 디자인"부터 그려보세요. 어떻게 만들지는 AI와 풀면 되니까요
2️⃣ 그림이 아니라 실물 만들기
시안을 그림으로 두지 말고, AI와 코드로 실제로 동작하는 걸 만들어보세요. 실물에서만 보이는 디테일이 있고, 툴로는 표현하지 못하던 질감까지 만들 수 있어요.
3️⃣ 가이드 문서 대신 동작하는 코드 전달하기
개발자에게 인터랙션을 넘길 때, 말로 설명한 문서보다 직접 만든 레포 하나가 더 정확하게 전달돼요.

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

댓글