AI에게 디자인을 요청하는 법

저는 프로덕트 디자이너입니다. 이 사이트는 디자인부터 코드까지 제가 만들었지만, 코드를 직접 타이핑하지는 않습니다. 대신 요청을 씁니다.

그렇게 일하다 보면 좀 이상한 순간이 옵니다. 같은 AI한테 비슷한 화면을 맡겼는데 어떤 날은 한 번에 끝나고, 어떤 날은 다섯 번을 되돌리게 되거든요. 처음엔 그냥 운이라고 생각했습니다. 지금은 아닙니다. 결과가 얼마나 좋으냐는 AI의 성능보다 요청이 얼마나 정확했느냐에 훨씬 크게 걸려 있었습니다.

아래는 지난 며칠 이 사이트를 고치면서 실제로 내린 판단들, 그리고 제가 틀렸던 자리들입니다. 원칙을 먼저 세워두고 지킨 게 아니라 대부분 틀리고 나서 알게 된 것들이라, 순서도 그렇게 적었습니다.

1. 눈으로 본 건 확인이 아니더군요

케이스 페이지에 있는 갤러리 진입 카드를 3D 깊이 스택으로 바꾸는 작업이었습니다. 이미지 다섯 장이 안쪽으로 물러나면서, 뒤로 갈수록 흐려지는 형태요.

만들어놓고 화면을 봤는데 뒤쪽 층이 적당히 흐릿하더군요. 블러가 잘 걸렸구나 하고 그냥 넘어갈 뻔했습니다. 그래도 습관이 있어서 계산값을 한번 찍어봤는데, 이렇게 나왔습니다.

d0: filter: none
d1: filter: none
d2: filter: none
d3: filter: none
d4: filter: none

블러가 한 층에도 안 걸려 있었습니다. 제가 흐릿하다고 본 건 뒤 층에 걸어둔 밝기 감소였고요. 생각해보면 당연한 게, 눈은 “왜 흐린지”까지는 구별하지 못하고 그럴듯한 쪽으로 알아서 결론을 내립니다.

원인은 CSS 한 줄이었습니다. max(0px, var(--d) - 1)에서 0px는 길이인데 var(--d) - 1은 그냥 숫자예요. 이렇게 단위가 섞이면 브라우저가 계산식을 통째로 버리고, 그 바람에 filter 속성 전체가 죽습니다. 오류도 경고도 안 뜹니다. 그냥 조용히 아무 일도 안 일어납니다.

더 뼈아픈 건 그다음입니다. 같은 버그가 시안 파일에도 있었어요. 저는 그 시안을 보면서 “역시 블러가 있는 게 낫네” 하고 판단했는데, 정작 그때 제가 본 화면엔 블러가 없었던 겁니다. 없는 걸 보고 좋다고 말한 셈이죠.

그래서 요청하는 방식을 바꿨습니다. “블러 넣어주세요”에서 끝내지 않고 “층별로 filter 계산값도 같이 출력해주세요”를 붙입니다. 눈으로 보지 않고 값으로 받는 거예요.

2. 형용사는 그대로 넘기면 안 됩니다

같은 카드의 모바일 동작을 정할 때였습니다. 손으로 쓰는 화면에는 마우스 호버가 없으니까 카드가 알아서 움직여야 하는데, 제가 이렇게 요청했습니다.

모바일에선 루프로 하면 안 되나, 너무 빠르게는 아니고.

지금 보면 이 문장으로는 아무것도 정해지지 않습니다. “너무 빠르지 않게”는 4.2초일 수도 있고 9초일 수도 있는데, 그 둘은 완전히 다른 느낌이거든요.

그래서 값을 정해달라고 하는 대신 선택지를 만들어달라고 했습니다. 4.2초에 한 장씩 넘어가는 것, 6.5초짜리, 그리고 이미지는 그대로 두고 층 간격만 천천히 벌어졌다 좁아지는 것. 세 개를 실제로 돌아가게 만들어서 나란히 놓고 봤습니다.

보니까 답이 금방 나오더군요. 이 카드가 화면에 머무는 시간이 워낙 짧아서, 6.5초짜리는 스크롤로 지나가는 동안 한 장도 안 바뀝니다. 층만 호흡하는 건 조용해서 좋은데 새 이미지를 끝내 안 보여주고요. 4.2초로 정했습니다.

형용사를 숫자로 바꾸는 건 결국 제 몫입니다. 취향의 영역이니까요. 그런데 형용사를 비교할 수 있는 선택지로 바꿔놓는 일은 맡길 수 있습니다.

3. 제약은 답이 아니라 탐색 범위였습니다

이 카드의 원래 모습은 정사각형 이미지 세 장을 5도씩 돌려서 겹쳐놓은 거였습니다. 좀 바꾸고 싶어서 이렇게 요청했어요.

겹치는 거 말고 다른 방식으로, 유사하지 않게.

세 개가 나왔습니다. 세로로 쪼갠 조각들이 각기 다른 속도로 흐르는 것, 필름 스트립처럼 양옆이 잘려 나가는 것, 잉크 아래 깔린 이미지가 커서를 따라 드러나는 것. 셋 다 겹침은 안 썼습니다.

그런데 셋 다 뭔가 부족했습니다. 특히 세 번째는 가만히 있을 때 그냥 빈 카드처럼 보였어요. 커서를 올리기 전까지는 아무것도 없는 회색 면이고, 마우스가 없는 기기에서는 영영 빈 카드입니다.

이 지점에서 제가 건 제약이 문제였다는 걸 알았습니다. “겹치지 말 것”은 원래 기존이랑 달라 보이게 하려는 수단이었는데, 어느새 그 자체가 목적이 되어 있었거든요. 그래서 풀었습니다.

겹쳐도 되니까 더 다양하게.

여섯 개가 더 나왔습니다. 커서 지나간 자리마다 사진이 떨어져 쌓이는 것, 안쪽으로 줄지어 물러나는 깊이 스택, 모서리가 말려서 밑장이 비치는 것, 손패처럼 부채로 펼쳐지는 것, 전량을 작게 깔아둔 콘택트 시트, 한 장씩 넘어가는 딜링. 결국 고른 건 겹침을 쓰는 안이었습니다.

제약은 탐색 범위를 좁히는 도구입니다. 좁혔는데도 답이 안 나오면 답이 없는 게 아니라 범위를 잘못 잡은 겁니다.

4. 기술적인 우려는 말하되, 결정까지 넘기지는 않습니다

깊이 스택을 만들면서 저는 블러를 뺐습니다. 나름 이유가 있었어요. 다섯 겹 전부에 블러를 걸면 모바일에서 합성 비용이 꽤 크고, 밝기 차이만으로도 깊이는 충분히 읽히니까요.

그런데 시안을 보고 나서 마음이 바뀌었습니다. 블러가 있는 쪽이 확실히 좋더군요.

이럴 때 보통 둘 중 하나를 고르게 됩니다. 성능을 이유로 그냥 밀어붙이거나, 예뻐 보이니까 우려를 못 본 척하거나. 저는 세 번째를 택했습니다. 앞의 두 층은 선명하게 두고 세 번째 층부터만 블러를 겁니다. 이러면 층의 깊이는 그대로 살면서 흐림 연산은 절반 이하로 줄어듭니다.

디자인 엔지니어의 자리가 여기라고 생각합니다. 성능도 절대 조건은 아니고 미감도 마찬가지인데, 둘 다 아는 사람만 이런 절충안을 만들 수 있으니까요.

5. 규칙은 말이 아니라 코드로 남깁니다

푸터에 단어가 흘러가는 띠가 있습니다. 원래는 이랬습니다.

Designer · Typography · Editorial · Grid systems · Identity · Brand

전형적인 그래픽 디자이너 어휘죠. 지금 제가 하는 일이랑 안 맞아서 바꿨습니다.

Design engineer · Prototyping · Interaction · Design systems · Motion · Interface

그런데 며칠 뒤에 다시 보니 이것도 틀렸더군요. Motion, Interface, Interaction 같은 말은 결국 “제가 다룰 줄 아는 표면”의 목록입니다. 직무 이름만 갈아 끼웠지 성격은 앞의 것과 똑같았어요. 세 번째로 고쳤습니다.

Design engineer · Problem framing · First principles · Prototyping · Judgment · End to end

세 번 고치는 동안 매번 테스트가 깨졌습니다. 옛날 목록을 기대하는 테스트가 그걸 붙잡고 있었거든요. 귀찮긴 한데 사실 이게 이득입니다. 무엇이 약속이었는지를 코드가 기억하고 있다는 뜻이니까요.

그래서 마지막에 고칠 때는 금지 목록을 하나 추가했습니다. React나 TypeScript 같은 스택 이름이랑 같이 Motion, Interface, Typography, Grid systems도 넣어뒀어요. 스킬 나열로 되돌아가는 것 자체를 막으려고요. 다음에 제가 무심코 어기면 테스트가 먼저 소리칩니다.

글도 비슷하게 지킵니다. AI가 쓴 한국어에는 티가 좀 납니다. 문장의 61%에 쉼표가 들어가고(사람이 쓰면 26% 정도라고 합니다), 특정 접속 표현이 계속 반복되고, 문장 끝이 한 가지로 쏠립니다. 이걸 매번 눈으로 잡기는 어려워서 검사기를 하나 만들어뒀습니다. 사실 이 글도 쉼표 비율이랑 상투어를 재보고 올리는 중입니다.

6. 요청이 계속 실패하면 층위가 틀린 겁니다

앞의 단어 띠 이야기로 돌아가면, 저는 두 번 요청했고 두 번 다 실패했습니다. 첫 번째는 어휘를 바꿨고 두 번째는 직무 이름을 바꿨는데, 결과는 여전히 “할 줄 아는 것들의 목록”이었어요.

세 번째에 제가 한 말은 이거였습니다.

Motion 이런 것보다는 더 근본적인 문제 해결 이런 걸 강조해. 디자인 스킬보다 원론적인 것.

이때 처음으로 요청의 층위가 바뀌었습니다. 앞의 두 번은 목록 안에서 단어를 갈아 끼우라는 요청이었고, 세 번째는 목록의 성격 자체를 바꾸라는 요청이었으니까요.

같은 실패가 반복될 때는 더 정확한 단어를 찾는 것보다 한 층 위에서 다시 묻는 게 빠릅니다. 무엇을 고칠지가 아니라, 내가 지금 무엇을 고치라고 말하고 있는지를요.

정리하면

여섯 가지가 결국 같은 얘기입니다. AI는 판단을 대신해주지 않습니다. 대신 판단을 빨리 시험해보게 해줍니다.

인터랙션 시안 아홉 개를 하루에 만들어보는 일, 루프 속도 세 개를 나란히 돌려보는 일, 블러 값을 층마다 찍어서 확인하는 일. 예전 같으면 개발자 시간을 빌려야 했고, 그래서 대부분은 그냥 상상으로 결정했습니다. 지금은 만들어보고 결정합니다.

무엇을 만들지 고르는 일, 그게 맞는지 재보는 일, 틀렸을 때 인정하는 일은 여전히 제 몫입니다. 그리고 그 몫은 줄어들지 않았어요. 오히려 시험할 수 있는 횟수가 늘어난 만큼 판단할 일도 같이 늘었습니다.

요청은 명세입니다. 명세가 흐리면 결과도 흐립니다.