오전 9시 26분에 먼저 무너진 건 화면이 아니라 합의였습니다
오전 9시 26분, 저는 피그마 링크 세 개와 메신저 스레드 하나를 번갈아 보다가 버튼 문구를 네 번 다시 적었습니다. 화면은 분명 더 그럴듯해졌는데, 어떤 프레임이 기준안인지 아무도 확신하지 못했습니다. 제 앞에 남은 메모는 내부 원문 자료라는 파일명뿐입니다. 이럴 때 저는 새 디자인 AI를 기능표보다 먼저, 팀이 최종안을 덜 헷갈리게 만드는 도구인지부터 따져야 한다고 생각합니다.
기술을 직접 만드는 사람은 아니지만, 저는 기술 때문에 하루가 덜 쪼개지는지에는 꽤 집요합니다. 비개발자 직장인에게 더 많은 시안보다 먼저 필요한 건, 덜 흔들리는 기준점입니다.
다들 시안을 더 빨리 뽑으면 회의가 짧아질 거라 믿습니다
많은 팀이 생성형 디자인 도구를 보면 먼저 “이제 시안은 금방 나오겠네”라고 말합니다. 저도 작년 가을에 비슷하게 들떴습니다. 피그마 프레임과 프레젠테이션 초안, 작업 문서를 하루 만에 세 벌 뽑았고, 그날 저녁에는 일이 빨라졌다고 착각했습니다.
문제는 다음 날 생겼습니다. 시안이 늘어나자 의견도 같이 늘었습니다. 문구 검토는 한쪽에서, 상태값은 다른 쪽에서, 실제 구현 가능 여부는 또 다른 쪽에서 말했고, 저는 번역 문장을 어디 기준에 맞춰야 하는지 다시 물어야 했습니다. 속도는 올라갔는데 결정은 느려졌습니다.
지금 확인된 공개 맥락에서는 내부 원문 자료라는 제목 외에 출처가 없습니다. 그래서 이 글에서 기능을 아는 척하지는 않겠습니다. 대신 이런 이름의 도구가 팀 안에서 반복해서 불러오는 착각, 즉 “더 빨리 만들면 더 빨리 끝난다”는 통념부터 의심해보려 합니다.
저는 메이크류 도구를 초안 공장이 아니라 결정 비용을 줄이는 장치로 써야 한다고 봅니다
제 주장은 분명합니다. 생성형 디자인 도구의 첫 효용은 시안을 더 많이 뽑는 일이 아니라, 누가 무엇을 언제 확정하는지 빨리 드러내는 데 먼저 써야 합니다. 이 말은 디자이너에게 답답하게 들릴 수 있고, 도구의 창의성을 너무 좁게 본다고 반박할 수도 있습니다. 그래도 실무에서는 이 순서가 더 자주 시간을 살립니다.
지난달 저는 7개 화면짜리 소개 페이지 문구를 정리하면서 피그마 프레임 12개를 받았습니다. 보기에는 좋았습니다. 하지만 “이 중 기준안은 4번 프레임”, “버튼은 회원가입이 아니라 상담 신청”, “모바일에서는 2줄까지 허용” 이 세 문장이 문서에 없어서 저는 같은 CTA를 6번 고쳤고, 개발자는 상태별 길이 때문에 2시간을 다시 썼습니다. 예쁜 초안이 부족했던 게 아닙니다. 기준 문장이 없었습니다.
비개발자 직장인의 언어로 바꾸면 이렇습니다. 일을 잘하는 신입이 세 명 들어와도, 누가 최종 결재자인지 모르면 메신저만 길어집니다. 메이크류 도구도 비슷합니다. 그림을 빨리 뽑아주는 능력보다, 팀의 애매한 질문을 표면으로 끌어내는 쪽이 먼저 쓸모를 만듭니다.
제가 요즘 시안 문서에 꼭 붙이는 확인표는 아래 셋입니다.
| 먼저 적을 질문 | 비어 있으면 생기는 일 | 지난달 실제로 날린 시간 |
|---|---|---|
| 기준안이 어느 프레임인가 | 모두가 다른 화면을 보고 코멘트함 | 18분 |
| 이 화면의 목표 행동이 무엇인가 | 예쁜 문구와 클릭 문구가 갈라짐 | 27분 |
| 최종 승인자는 누구인가 | 댓글만 늘고 결정은 멈춤 | 35분 + 추가 회의 1번 |
숫자가 거창하지는 않습니다. 그런데 이런 18분, 27분이 하루에 두 번만 나와도 오전이 잘립니다. 저는 자동화를 미래 기술이 아니라, 이런 자투리 손실을 회수하는 작은 시스템으로 봅니다. 그래서 디자인 AI를 검토할 때도 “무엇을 그릴 수 있나”보다 “기준안을 더 빨리 고정하게 돕나”를 먼저 묻습니다.
제가 복붙해두는 한 줄도 있습니다.
> 이 시안의 목적은 더 많은 선택지를 만드는 것이 아니라, 오늘 한 가지 결정을 끝내는 것이다.
이 문장 하나가 있으면 회의 톤이 달라집니다. 지난주에는 실제로 메신저 스레드 댓글이 43개에서 11개 선에서 멈췄습니다. 모두가 갑자기 똑똑해져서가 아니라, 같은 그림을 보며 같은 질문을 하기 시작했기 때문입니다.
손이 이미 짧은 팀이나 보안이 빡빡한 조직에서는 오히려 짐이 됩니다
물론 이 기준이 늘 통하지는 않습니다. 하루에 시안을 한두 장만 만들고, 수정권도 한 사람에게 모여 있다면 새 도구를 붙이는 수고가 더 큽니다. 보안 정책이 강한 조직에서는 외부 생성 기능을 검토하는 절차만으로도 한 주가 갑니다.
저도 한 번 데였습니다. 작년 겨울, 외부 도구로 만든 시안을 회의 전에 급히 공유했다가 폰트 치환과 접근 권한 문제로 30분을 허비했습니다. 결국 회의는 캡처 이미지로 했고, 정작 이야기해야 할 사용 흐름은 뒤로 밀렸습니다. 이런 팀에서는 메이크류 도구보다 파일 권한, 프레임 명명 규칙, 승인 순서부터 손보는 편이 낫습니다. 도구가 나빠서가 아니라, 바닥 정리가 안 된 집에 수납함부터 들이는 꼴이 되기 쉽기 때문입니다.
오늘은 시안 하나에 세 줄만 붙이세요, 다음 편에서는 그다음에 무너지는 지점을 보겠습니다
오늘 할 일은 거창하지 않습니다. 최근 피그마 시안 하나만 골라서 아래 ① ② ③을 문서 맨 위에 적어보세요. 저는 이 세 줄이 없는 상태에서 새 기능을 붙이는 일을 이제 거의 하지 않습니다.
① 기준안은 몇 번 프레임인가 ② 이 화면에서 사용자가 해야 할 한 가지 행동은 무엇인가 ③ 오늘 이 안을 끝내는 사람은 누구인가
이 세 줄이 붙으면, 생성형 도구를 써도 회의가 길어질 이유가 줄어듭니다. 오늘의 다음 단계는 새 기능을 더 찾는 일이 아니라, 지금 있는 시안 한 장의 결정 문장을 고정하는 것입니다. 다음 편에서는 이렇게 고정한 시안이 개발 티켓으로 넘어갈 때 왜 다시 흐려지는지, 제가 번역 문구에서 가장 자주 본 붕괴 지점을 이어서 적어보겠습니다.
핵심 정리
- 오전 9시 26분, 저는 피그마 링크 세 개와 메신저 스레드 하나를 번갈아 보다가 버튼 문구를 네 번 다시 적었습니다.
- 기술을 직접 만드는 사람은 아니지만, 저는 기술 때문에 하루가 덜 쪼개지는지에는 꽤 집요합니다.
- 많은 팀이 생성형 디자인 도구를 보면 먼저 “이제 시안은 금방 나오겠네”라고 말합니다.
→ 영어판 보기
