클릭 버튼 하나로만 파일을 올릴 수 있는 인터페이스, 한 번쯤 답답하게 느껴보신 적 있으실 겁니다. 저도 외주 작업에서 똑같은 상황을 겪었습니다. 클릭만 되는 업로드 버튼을 드래그앤드롭 병행 방식으로 바꾼 이후, 주간 업로드 건수가 14건에서 28건으로 두 배가 됐습니다. 그 전환점에 Figma 프로토타입이 있었습니다.
컴포넌트 기반 설계가 왜 필요한가
Figma에서 드래그앤드롭 인터랙션을 만들 때 많은 분들이 단순히 화면 두 개를 연결하는 것으로 충분하다고 생각하시는 경우가 있는데, 저는 그렇게 접근하면 반드시 막히는 지점이 온다고 봅니다.
핵심은 Variants(베리언츠)입니다. 여기서 Variants란 하나의 컴포넌트 안에서 상태별 디자인 변형을 묶어두는 기능입니다. 파일 아이콘 하나에 '기본 상태'와 '선택된 상태' 두 가지를 Variants로 정의해두면, 인터랙션 설정 시 상태 전환을 컴포넌트 레벨에서 깔끔하게 제어할 수 있습니다. 반대로 이걸 별도 프레임으로 분리해두면 중간 상태를 연결하는 과정이 지저분해집니다.
제가 직접 작업하면서 확인한 것은, 컴포넌트를 처음부터 네 가지 상태로 설계하면 나중에 훨씬 유연하다는 점입니다. 저는 업로드 컴포넌트를 다음 네 가지로 정리해두고 있습니다.
- 단일 파일 업로드
- 다중 파일 업로드
- 이미지 인라인 미리보기 포함
- 청크(분할 전송) 방식 50MB 이상
이렇게 라이브러리로 정리해두면 외주 건마다 처음부터 만들 필요가 없습니다. 실제로 저는 이 구조를 외주 4건에서 재사용하고 있습니다.
드롭존(Drop Zone) 컴포넌트도 마찬가지입니다. 드롭존이란 사용자가 파일을 끌어다 놓을 수 있는 지정 영역을 말합니다. 기본(Default), 호버(Hover), 업로드 중, 업로드 완료까지 최소 네 가지 상태가 필요합니다. Figma 프로토타입 수준에서는 호버 상태를 드래그 도중에 실시간으로 반응하게 만드는 데 한계가 있지만, 드래그를 마친 직후 전환은 충분히 구현할 수 있습니다. 이 부분이 아쉽다는 의견도 있는데, 실제로 써보니 스테이크홀더(의사결정권자)에게 흐름을 보여주는 용도로는 충분히 설득력이 있었습니다.
인터랙션 설계의 구조와 실제 한계
Figma Prototype 모드에서 드래그앤드롭을 설계할 때 실무자들이 자주 간과하는 부분이 있습니다. 인터랙션 하나처럼 보이는 동작이 실제로는 세 가지 트리거가 중첩된 구조라는 점입니다.
While Pressing(누르고 있는 동안), On Drag(드래그 중), Mouse Up(마우스를 놓을 때)이 순서대로 연결되어야 합니다. While Pressing이란 마우스를 누른 채 유지하는 동안 트리거되는 인터랙션 타입으로, 파일 아이콘이 클릭된 순간 선택 상태로 전환하는 데 씁니다. 여기서 While Pressing과 On Drag를 같은 프레임에서 처리하려 하면 충돌이 생깁니다. 제가 직접 부딪혔던 문제가 바로 이것입니다. 드래그 중에 하이라이트가 풀렸다가 다시 켜지는 이상한 동작이 나왔습니다.
해결책은 상태 전환을 프레임 단위로 분리하는 것입니다. While Pressing으로 두 번째 프레임으로 이동하고, 두 번째 프레임의 파일 컴포넌트 인스턴스를 선택된 상태(Variant 2)로 고정한 뒤, 그 인스턴스에서 On Drag로 세 번째 프레임으로 이동합니다. 이렇게 하면 드래그 내내 선택 상태가 유지됩니다.
Smart Animate(스마트 애니메이트)도 여기서 핵심 역할을 합니다. Smart Animate란 두 프레임 사이에 같은 이름의 레이어가 있을 때, Figma가 자동으로 위치·크기·색상 변화를 보간해 자연스러운 모션을 만들어주는 기능입니다. 파일 아이콘이 드롭존 쪽으로 이동하는 애니메이션에 Smart Animate를 적용하면 별도로 모션 경로를 그리지 않아도 됩니다.
다만 솔직히 이건 예상 밖의 제약이었는데, Figma의 드래그 인터랙션은 이동 경로를 지정할 수 없습니다. 시작점에서 도착점까지 직선으로만 움직입니다. 실제 서비스에서는 사용자가 어느 방향에서든 드래그해서 올 수 있는데, 프로토타입에서는 그 자유도가 없습니다. 이 점은 프로토타입을 보여줄 때 미리 설명해두는 것이 좋습니다.
진행 상태 표현도 중요합니다. 저는 업로드 진행률을 색·아이콘·텍스트 세 가지 채널로 분리해서 표현합니다. 시각적 접근성(Visual Accessibility) 원칙, 즉 색만으로 상태를 구분하지 않아야 한다는 디자인 가이드라인에 따른 결정입니다. 진행률 바가 채워지는 애니메이션은 After Delay로 연결된 두 상태 사이에 Smart Animate를 적용하면 3초 안팎의 자연스러운 로딩 연출이 가능합니다(출처: Nielsen Norman Group, 파일 업로드 UX 가이드라인).
실전 적용: Figma 이후 개발 연결까지
Figma 프로토타입이 좋은 이유는 개발자에게 말로 설명할 필요가 없어진다는 점입니다. "드래그하면 하이라이트 되고, 놓으면 업로드 진행 표시가 나타나고, 완료되면 체크 아이콘이 뜨는 방식"을 동작으로 바로 보여줄 수 있습니다.
하지만 저는 여기서 한 가지 아쉬운 점을 지적하고 싶습니다. 드래그앤드롭 인터랙션을 다루는 많은 자료들이 데스크톱 마우스 환경에만 집중되어 있다는 것입니다. 한국 사용자는 영수증, 신분증, 통장 사본처럼 촬영이 필요한 파일을 모바일로 즉시 올리는 패턴을 매우 선호합니다. 실제로 제 외주 클라이언트들도 모바일 업로드 비중이 절반을 넘는 경우가 많았습니다.
그래서 저는 업로드 경로를 네 가지로 확장해서 설계하는 것을 기본으로 삼고 있습니다.
- 드래그앤드롭 (데스크톱)
- 클릭하여 파일 선택 (데스크톱·모바일 공통)
- 카메라 직접 촬영 (capture='environment' 속성, 모바일)
- 클립보드 붙여넣기 Ctrl+V (데스크톱)
이 네 가지를 하나의 업로드 컴포넌트 안에서 자연스럽게 분기하는 구조가 실제 서비스에서는 필수입니다.
개발 쪽으로 이어지면, 저는 React 훅 세 종류를 분리해서 관리합니다. useFileUpload는 단일 파일과 MIME Type(파일 형식 식별자) 검증을 처리하고, useChunkedUpload는 50MB 이상 대용량 파일을 분할 전송합니다. 청크 업로드란 큰 파일을 작은 조각으로 나눠 순서대로 전송한 뒤 서버에서 다시 합치는 방식입니다. useRetry는 업로드 실패 시 자동 재시도를 담당합니다. 이 구조를 적용한 이후 업로드 성공률이 88%에서 96%까지 올랐고, 50MB 이상 환경에서는 99%를 유지하고 있습니다. UX Research 측면에서도 업로드 실패는 이탈률에 직결된다는 것이 잘 알려져 있습니다(출처: Baymard Institute, 파일 업로드 UX 연구).
Figma 프로토타입 단계에서 컴포넌트를 잘 설계해두면 개발 단계에서 훅 구조와 자연스럽게 맞아떨어집니다. 진행률 4상태(0%, 처리 중, 완료, 실패)를 디자인 단계에서 명확히 정의해두면 개발자가 상태 관리 로직을 짤 때 훨씬 수월해집니다.
Figma 프로토타이핑 자체에는 분명한 한계가 있습니다. 드래그 경로 자유도, 드래그 중 실시간 호버 반응 등은 현재 툴이 지원하지 않습니다. 하지만 그 한계를 알고 쓰는 것과 모르고 쓰는 것은 결과물의 완성도에서 차이가 납니다. Figma로 먼저 흐름을 정리하고, 실제 동작은 코드로 정교하게 구현하는 이 두 단계 접근이 지금 저에게는 가장 잘 맞는 방식입니다. 업로드 UX를 개선하고 싶다면 Figma Variants 설계부터 시작해보시길 권합니다. 생각보다 빠르게 방향이 잡힙니다.