AI에게 디자인 원칙을 주면, 사용감도 달라질까

“좀 더 자연스럽게 움직이게 해줘.” 화면을 다듬을 때 자주 하는 요청이지만, 자연스럽다는 말만으로는 기준을 전달하기 어렵습니다. 그렇다면 인터랙션 원칙을 담은 파일을 AI에게 주면 어떨까요?

apple-design 스킬로 작은 바텀시트 하나를 진단하고 고쳐 봤습니다. 궁금했던 것은 코드를 만들어 주는지보다, 실제로 만졌을 때 더 편해지는지였습니다.

실험 대상은 바텀시트 하나

실험 대상은 바텀시트(bottom sheet) 하나입니다. 화면 아래에서 위로 올라오는 패널로, 공유 버튼을 눌렀을 때 올라오는 메뉴나 지도 앱에서 장소를 탭했을 때 올라오는 정보창이 모두 바텀시트입니다. 모바일에서 가장 흔히 만지는 화면이라, 손맛의 차이를 보기에 알맞았습니다.

실험은 단순합니다. 기능에 충실한 기본 버전을 먼저 만들어 놓고, 애플 감각이 담긴 파일에게 진단시킨 뒤, 고치고, 마지막에 직접 확인합니다. 아래에 그 순서와 실제로 준 프롬프트까지 그대로 옮겨 둡니다.

기본형 제작부터 개선까지, 네 단계의 요청

아래는 단계마다 AI 개발 도구(Claude Code)에게 실제로 준 요청입니다. 표현은 조금 다듬었지만 의도는 그대로입니다. 여기서 AI 개발 도구는 말로 시키면 코드를 대신 짜고 고쳐 주는 AI를 말합니다. 프로그래밍을 몰라도 됩니다. 핵심은 도구가 아니라 무엇을 어떤 순서로 시켰는가입니다.

1단계 · 기능에 충실한 기본 버전부터. 개선을 체감하려면 비교할 ‘전’이 필요합니다. 화려한 효과 없이, 동작은 제대로 되는 흔한 기본형으로 화면 하나를 만들게 했습니다.

• “Next.js로 아주 간단한 웹앱을 만들어줘. 화면 가운데 ‘열기’ 버튼 하나만 있고, 누르면 아래에서 바텀시트가 올라오는 데모야. 단, 화려한 효과 없이 기본형으로 — (1) 여는 애니메이션은 0.3초 슬라이드만, (2) 손가락으로 드래그해서 닫는 기능 없음, (3) 버튼을 눌러도 시각 반응 없음. 스프링이나 관성 같은 건 넣지 마. 로컬에서 바로 볼 수 있게 해줘.”

Next.js는 제가 고른 것이 아닙니다. 이런 걸 만들고 싶은데 뭐가 좋을지 물었더니 AI가 추천했고, 그대로 따랐습니다. 무엇을 쓸지 모를 때는 이렇게 AI에게 물어 정하는 것도 방법입니다. 웹 화면을 만드는 도구 정도로만 알아도 글을 읽는 데는 지장이 없습니다.

2단계 · apple-design 스킬 설치. 애플의 인터랙션 원칙을 담은 파일을 도구에 붙였습니다. 스킬은 AI에게 “이런 기준으로 일해라”라고 알려 주는 설명서 파일로, SKILL.md라는 이름으로 둡니다. 설치는 명령어 한 줄이면 됩니다.

$ npx skills add https://github.com/emilkowalski/skills --skill apple-design

이때 작은 판단이 하나 더 있었습니다. 애니메이션을 더 정교하게 다듬는 improve-animations라는 스킬도 있었지만 설치하지 않았습니다. 손맛의 차이를 보려는 작은 데모라 apple-design 하나면 충분하다고 봤습니다. 필요한 것만 고르는 것도 판단입니다.

3단계 · 고치지 말고, 진단부터. 첫 번째 요령입니다. 바로 “고쳐줘”가 아니라 “문제만 짚어줘”라고 했습니다. AI가 무엇을 문제로 보는지부터 듣고 싶었습니다.

• “스킬 내용 먼저 확인해줘. 그다음 바로 고치지는 말고, apple-design 스킬 기준으로 지금 이 바텀시트가 어떤 원칙을 어기고 있는지 진단부터 해줘. 문제점을 우선순위 매겨서 목록으로 보여줘. 코드 수정은 아직 하지 마.”

4단계 · 진단을 바탕으로 세 가지 개선 요청. AI가 짚은 11개 항목을 모두 반영하기보다, 이번 실험에서 확인할 동작으로 범위를 좁혔습니다.

• “진단 고마워. 전부 말고, 체감이 가장 큰 3가지만 고쳐줘. (1) CSS 전환을 걷어내고 스프링으로 바꿔서, 닫는 도중에 다시 잡으면 손가락을 따라오게 (2) 손가락으로 끌어서 닫을 수 있게 (1:1로 따라오고, 놓으면 스프링으로 마무리) (3) 버튼을 누르는 즉시 살짝 눌린 반응. 스프링을 위해 motion 라이브러리 설치해도 돼. 나머지 항목은 지금 건드리지 마.”

따라 하실 때 정말 중요한 것은 프롬프트 문장이 아니라 순서와 태도입니다. 진단부터 하고 고치기는 나중으로 나눈 것, 그리고 다 말고 3개만으로 좁힌 것. 이 두 판단이 결과를 갈랐습니다.

진단 항목 11개에서 개선 범위 고르기

진단을 맡겼더니 가장 치명적인 것(P0)부터 마감 디테일(P3)까지 우선순위를 매겨 문제 11개를 짚어 줬습니다. 놀란 것은 개수가 아니라 근거였습니다. 그냥 “고치세요”가 아니라 “이건 ‘제스처로 움직이는 것에는 CSS 트랜지션을 쓰지 말라’는 원칙을 어겼다”는 식으로, 참고한 규칙을 조목조목 대며 짚었습니다. 감각이 파일이 되니 지적도 감이 아니라 근거로 나왔습니다.

진단 항목 11개를 모두 반영하지는 않았습니다. 이번 실험은 바텀시트를 열고 닫을 때의 사용감을 비교하는 데 범위를 한정했습니다.

접근성 검증은 완료하지 않았으며, 타이포그래피와 진동·소리 피드백도 이번 개선 범위에 포함하지 않았습니다. 실제 제품에 적용하려면 별도로 검토해야 합니다.

개선 요청의 수와 진단 항목의 수는 다릅니다. 스프링 전환과 드래그 동작은 인터럽트 불가, 고정 시간 애니메이션, 드래그 없음 등 여러 진단 항목에 걸칩니다.

프롬프트에서는 스프링과 중간에 다시 잡기, 끌어서 닫기, 버튼을 누르는 즉시 반응하기를 요청했습니다. 결과 설명에는 배경 전환도 포함돼 있습니다. 최초 요청과 최종 반영 항목을 구분하면, 세 가지 개선 요청이 진단 항목 다섯 개에 걸친 셈입니다.

11개를 짚어 주는 것과 그중 무엇을 고칠지 정하는 것은 결이 다른 일이었습니다. 앞의 것은 AI가 잘했고, 뒤의 것은 이 실험에서 무엇이 중요한지를 아는 제가 했습니다.

같은 화면에서 비교한 개선 전후

고른 개선을 AI에게 맡겨 적용한 뒤, 같은 화면과 같은 조건에서 ‘개선 전’과 ‘개선 후’를 번갈아 눌러 봤습니다. 아래가 그 장면입니다.

그런데 여기서 솔직해질 필요가 있습니다. “와, 완전 다르다!” 소리가 나오지는 않습니다. 나란히 놓고 자세히 봐야 “아, 이게 더 부드럽네” 정도로 느껴집니다. 이 이야기는 뒤에서 다시 하겠습니다. 사실 이것이 이 실험에서 가장 중요한 발견이었습니다.

닫히는 시트를 다시 잡아 보고 알게 된 것

고치는 과정에서 화면만 봐서는 몰랐고 직접 테스트해 본 뒤에야 알게 된 것들이 있었습니다. 이것이 이 실험의 진짜 수확이었습니다.

• “인터럽트 가능” — 체크는 됐지만 쓸 수가 없었습니다. AI는 닫는 도중에 다시 잡을 수 있게 구현했다고 표시했고, 스펙상 분명히 ‘됨’이었습니다. 그런데 실제로 해 보니 시트가 너무 빨리 닫혀서 다시 잡을 틈 자체가 없었습니다. 기능은 있는데 쓸 수 없는 상태였습니다. 직접 해 보지 않았다면 “인터럽트 됩니다” 하고 넘어갔을 겁니다
• 틈을 만들려고 늦췄더니, 이번엔 너무 느려졌습니다. 닫히는 속도를 늦춰 잡을 틈을 만들어 달라고 하자 AI는 요청대로 정확히 늦췄습니다. 그랬더니 개선 후가 개선 전보다 오히려 느려지는 역효과가 났습니다. AI는 시킨 대로 했지만, 이것은 개선이 아니라 개악에 가까웠습니다

결국 속도를 원래대로 되돌리고 다른 방식으로 풀었습니다. 한 번에 완성되지 않았습니다. 만들고, 확인하고, 방향을 다시 주고, 이 과정을 몇 번 돌고 나서야 쓸 만한 것이 나왔습니다.

이번 실험에서 느낀 차이는 작았습니다

전후를 비교했을 때 차이는 크지 않았습니다. 나란히 놓고 조작해야 움직임이 조금 더 부드럽다는 것을 느낄 수 있었습니다.

이번 실험에서 제가 좋게 느낀 변화는 움직임이 눈에 띄는 것보다 조작할 때 덜 거슬리는 쪽에 가까웠습니다. 버튼의 즉각적인 반응과 손가락을 따라오는 시트가 그런 차이를 만들었습니다.

더 큰 차이를 보여 주려고 튕김을 키우기보다는, 열고 닫는 흐름을 방해하지 않는 수준에서 멈추기로 했습니다. 이는 글쓴이가 직접 사용하며 내린 판단이며, 사용자 테스트로 확인한 결과는 아닙니다.

스킬은 막연한 요청을 구체적인 기준으로 바꾸는 데 도움이 됐습니다. 하지만 기준에 맞게 구현했다는 답이 곧 좋은 사용감을 뜻하지는 않았습니다.

무엇을 고칠지 고르고, 직접 조작하고, 과한 변화는 되돌리는 과정이 필요했습니다. 이번 실험에서 AI는 진단과 구현을 도왔고, 어디까지 다듬을지는 제가 사용해 보며 정했습니다.

자주 묻는 질문