Figma Make를 쓰면 디자인 작업이 20% 빨라진다는 무작위 대조 실험 결과가 나왔어요. 다만 이 숫자를 팀의 일정이나 인건비에 그대로 곱하면 안 됩니다. 가져와야 할 것은 20%라는 결론보다, 같은 과제를 AI 사용 여부만 바꿔 비교한 측정 방식이에요.
20% 빨라졌다는 말, 어디까지 믿어도 될까요?
결론부터 말하면 실험에 포함된 세 가지 과제에서는 Figma Make가 시간을 줄였다고 볼 근거가 꽤 탄탄합니다. Figma 데이터 사이언스팀은 제품 디자이너 50명과 프로덕트 매니저 50명, 총 100명을 모집했어요. 참가자를 Make 사용군과 AI를 쓰지 않는 대조군에 무작위로 나누고, 두 집단 모두 같은 소셜 미디어 화면을 수정하게 했습니다.
과제는 라이트 모드를 다크 모드로 바꾸기, 설정 메뉴에 도움말 항목 추가하기, 댓글이 올라오는 인터랙션 만들기였어요. UI 외형 변경부터 새 뷰와 상호작용 구현까지 난이도가 다른 세 유형을 섞었고, 사전 파일럿을 거쳐 과제를 세 번 수정했습니다. 진행자마다 도움 수준이 달라지는 문제를 줄이려고 공통 진행 스크립트와 문제 해결 지침도 사용했고요.
전체 참가자의 누적 완료시간은 20% 줄었고, 과제 용이성 평가는 16%, 체감 사용성은 15% 개선됐습니다. PM만 보면 완료시간이 23% 줄고 과제 용이성은 37% 개선됐어요. 분석에는 가설 검정과 OLS 회귀가 사용됐으며, Figma는 별도 표시가 없는 결과가 통계적으로 유의하다고 설명합니다.
흥미로운 부분은 누가 더 능숙한가보다 어떤 과제를 맡았는가가 효과를 갈랐다는 점이에요. PM은 비교적 쉽고 짧은 두 과제에서 유의한 시간 이득을 얻었지만 가장 어려운 인터랙션 과제에서는 그러지 못했습니다. 반대로 제품 디자이너는 어려운 과제에서만 유의한 개선을 보였어요. 따라서 “디자이너용 도구니까 디자이너에게 먼저 배포한다”거나 “복잡한 일일수록 AI 효과가 크다”는 식의 단순한 도입 원칙은 이 결과와 맞지 않습니다.
이 연구에서 그대로 가져올 것
AI를 자주 쓰는 사람과 안 쓰는 사람의 평소 작업시간을 비교하지 않았어요. 역할과 숙련도 같은 차이를 무작위 배정으로 분산하고, 같은 난이도의 과제를 주고, AI 접근 여부만 바꿨습니다. 사내 파일럿도 이 구조에 가까워질수록 “빠른 사람이 AI도 많이 쓴다”는 착시를 줄일 수 있어요.
과제 속도는 팀 생산성과 같은 숫자가 아닙니다
가장 중요한 한계는 20%가 세 가지 통제 과제의 누적 완료시간이지, 제품팀 전체의 출시 속도나 비용 절감률은 아니라는 것이에요. 공개 블로그 본문에는 과제별 원시시간과 신뢰구간이 제시되지 않았고, 산출물 품질이 주요 결과 지표에 포함되지도 않았습니다. Figma 역시 디자인 품질과 협업 효과는 앞으로 연구할 주제로 남겨뒀어요.
| 연구에서 확인한 것 | 확인하지 않은 것 |
|---|---|
| 정해진 세 과제의 누적 완료시간 | 리서치·회의·승인까지 포함한 프로젝트 리드타임 |
| 과제가 얼마나 쉬웠는지에 대한 평가 | 브랜드 적합성·접근성·사용성 등 최종 품질 |
| 제품 디자이너와 PM 사이의 효과 차이 | 개별 팀의 숙련도·디자인 시스템·업무 구성에 따른 효과 |
| 통제된 환경에서 Make 접근의 인과 효과 | 구독료와 AI 크레딧을 뺀 재무 ROI |
AI 생산성 실험은 도구와 업무 환경이 바뀌면 방향까지 달라질 수 있습니다. Google의 96명 엔지니어 대상 무작위 실험은 복잡한 사내 과제에서 AI 기능이 작업시간을 약 21% 줄였다고 추정했지만 신뢰구간이 넓었고, 연구진도 이 결과를 다른 생태계에 그대로 적용할 수 없다고 밝혔어요. 반면 METR의 연구에서는 익숙한 오픈소스 저장소에서 일한 숙련 개발자 16명이 AI를 허용했을 때 246개 과제를 평균 19% 더 오래 수행했습니다. 참가자 본인은 오히려 20% 빨라졌다고 체감했고요.
체감 절약시간만 묻는 방식도 따로 봐야 합니다. 영국 정부의 AI 코딩 도구 시험에서는 응답자 424명이 하루 평균 56분을 절약했다고 보고했지만, 보고서 자체가 낙관 편향과 과제별 절약시간의 중복 가능성을 한계로 적었습니다. 설문 응답자를 조사 시점별로 연결하지 못해 변화 추적도 어려웠어요. “얼마나 빨라진 것 같나요?”는 만족도 신호이지, 스톱워치로 잰 시간과 같은 증거가 아닙니다.
Figma Make를 실제로 운영할 때는 비용 변수도 생깁니다. 프롬프트를 보낼 때마다 AI 크레딧이 사용되고, 모델·과제 복잡도·처리하는 맥락의 양에 따라 소모량이 달라져요. 긴 대화 기록, 모호한 첫 프롬프트, 필요 이상으로 무거운 모델은 수정 작업과 크레딧을 늘릴 수 있습니다. 반대로 작은 색상·간격 수정은 포인트 앤 에디트나 직접 코드 수정으로 처리하는 편이 더 빠르고 효율적이라고 Figma 문서도 안내합니다.
20% × 연봉으로 절감액을 계산하지 마세요
남은 시간이 실제 인건비 감소로 이어지려면 절약된 시간이 다른 가치 있는 업무에 재배치되거나, 외주비·초과근무·채용 수요를 줄여야 해요. 먼저 통과한 산출물 1개당 총시간을 비교하고, 그다음 회수 가능한 시간만 비용으로 환산하는 편이 안전합니다.
NIST도 AI 측정에서 특정 과제의 평가 결과가 다른 사용 사례나 영역으로 일반화되는지를 별도 질문으로 다뤄야 한다고 지적합니다. 그러니 Figma의 20%는 구매 결론이 아니라 우리 팀에서도 검증해 볼 만한 사전 가설로 쓰는 게 정확해요.
2주 안에 우리 팀의 Figma Make 효과를 측정하는 법
큰 도입 계획보다 먼저, 자주 반복되고 완료 기준이 분명한 작업 세 개를 골라 작은 교차 실험을 해보세요. 소규모 결과를 전사 인과 효과라고 부를 수는 없지만, 좌석 확대와 워크플로우 선택에는 충분히 유용한 증거가 됩니다.
완료 기준이 있는 과제 세 개를 고릅니다
최근 작업에서 다크 모드 변형, 기존 컴포넌트를 이용한 설정 화면 추가, 클릭 가능한 인터랙션 구현처럼 20~90분 안에 끝나는 과제를 고르세요. 과제마다 필수 상태, 사용할 컴포넌트, 접근성 조건, 허용 오류 수를 체크리스트로 고정합니다. “보기 좋음”처럼 채점자마다 달라지는 기준만 두면 속도 비교가 무너져요.
난이도가 비슷한 A·B 버전을 만들고 순서를 섞습니다
같은 사람이 똑같은 화면을 두 번 만들면 두 번째가 학습 효과로 빨라져요. 기능과 난이도는 비슷하지만 내용이 다른 A·B 버전을 만들고, 참가자의 절반은 Make로 A를 먼저, 나머지는 수동으로 B를 먼저 수행하게 하세요. 동일한 기기·라이브러리·제한시간을 쓰고 진행자 개입 문구도 정해둡니다.
시간과 함께 품질·재작업·크레딧을 기록합니다
시작부터 제출까지의 경과시간, 실제 조작시간, 생성 대기시간, 수정 횟수, 사용한 AI 크레딧을 한 행에 적으세요. 결과물은 작업 방식을 모르는 리뷰어가 같은 체크리스트로 채점합니다. 통과하지 못한 결과는 빠르더라도 절약으로 계산하지 말고, 통과할 때까지의 수정시간을 합치세요.
역할×과제별 중앙값으로 배포 범위를 정합니다
(수동 중앙시간 - Make 중앙시간) ÷ 수동 중앙시간으로 절감률을 계산하되, 반드시 품질 통과율과 나란히 보세요. PM의 단순 화면 변경, 디자이너의 복잡한 인터랙션처럼 효과가 난 조합부터 확대합니다. 시간이 줄어도 통과율이 낮거나 크레딧과 재작업이 크게 늘면 해당 과제는 수동 워크플로우로 남겨두세요.
마지막으로 실험 파일과 프롬프트 기록을 보관하세요. Figma Make는 명확한 첫 프롬프트, 구조화된 프레임, 계획 모드, 특정 요소를 지정한 편집처럼 입력 방식에 따라 결과와 크레딧 사용량이 달라집니다. 도구 버전이나 팀의 가이드라인이 바뀌면 같은 과제로 다시 측정해야 이전 결과와 비교할 수 있어요.
