AI로 어떻게 디자인하나

1. 전체를 본다.

디자인 프로세스는 대략 3단계다:

1. 디자인이 만족시켜야 할 제약을 전부 나열한다.
2. 그 제약을 만족시키는 해를 여러 개 검토한다.
3. 제약을 하나 더해야 하거나 하나 뺄 수 있다는 걸 깨달으면, #1로 돌아간다.

이건 크리스토퍼 알렉산더의 Notes on the Synthesis of Form에서 온 것이다. 디자인 프로세스에 대한 기분 좋게 엄밀한 탐구다.

제약은 여러 형태를 취한다. 폰트·크기 규칙일 수도 있고, 지원해야 하는 워크플로일 수도 있고, 비즈니스 로직 상태일 수도 있다. 중요한 건 당신이 그 제약을 정한다는 것이다.

흔한 문제는 Step 3을 건너뛰고 왁카몰(wackamole) 디자인을 하는 것이다. 사용자가 헷갈리면 바로 해결 모드로 뛰어들고 싶어진다. 우리 팀도 이런 데에 늘 낚인다. 특히 좌측 사이드바 — 좁은 공간에 정보를 잔뜩 욱여넣은 곳이 그렇다. spot-fix로 눌러 잡고 싶은 유혹이 크지만, 그 길은 파멸로 이어진다.

제약 나열을 건너뛰면, 어떤 인터랙션은 우선순위를 얻고 어떤 인터랙션은 밀리는 즉흥적 패치워크가 나온다. AI는 이 왁카몰 디자인 쪽으로 우리를 더 세게 끌어당긴다. "X를 더 눈에 띄게 해줘", "Y를 할 수 있는 어포던스를 추가해줘" 같은 프롬프트를 부추긴다. 결국 더 많은 사용자가 더 헷갈리게 된다.

피드백이 들어오면, 해로 뛰어들기 전에 디자인 제약이 바뀌었는지부터 평가하라. 우리 팀은 자잘한 불편(papercuts)과 짜증거리를 트래킹하는 문서 하나로 이걸 다룬다. 명백한 픽스는 빠르게 처리하되, 자잘한 건 기록해뒀다가 리디자인 시점에 한꺼번에 응집력 있게 고친다. 핵심은 과도하게 반응해서 지저분함을 늘리지 않는 것이다.

2. 뺀다.

에이전트는 뭘 더하는 걸 좋아한다. 당신의 일은 불필요한 부분을 빼는 것이다.

이건 아주 익숙해야 한다. 에이전트는 코드와 계획에서도 똑같이 한다. 바지에 벨트에 멜빵까지 채우고, try/catch를 하나 더 감싸고, 같은 유틸리티를 몇 번씩 다시 구현한다.

UI 디자인에서도 에이전트는 같은 짓을 한다. 카피, 선, 아이콘을 자꾸 얹는다. 결과물은 대부분의 엔지니어가 손으로 만드는 것보다 예뻐 보이지만, 실제로는 좀 나쁘다.

쉬운 방법 하나 — 디자인의 요소 하나하나를 보면서 매번 "이게 진짜 필요한가?"를 묻는다.

3. 디자인 도구에서 반복한다.

제품 안에서 디자인을 반복하지 마라. 세밀한 컨트롤과 빠른 반복을 최소한의 컨텍스트 오버헤드로 가능케 하는 도구를 써라.

프로토타입 중력(prototype gravity)이 조용한 살인자다. 에이전트에게 코드베이스에서 첫 버전을 짓게 하면, 다른 옵션을 탐색하는 것보다 그걸 다듬는 게 쉬워 보인다. 실 코드베이스에서 디자인하면 에이전트도 그 실 코드베이스에 접붙일 수 있는 버전만 만들게 강요된다.

Figma는 여전히 GOAT다. AI 통합이 매주 좋아지고 있다. Cursor Design Mode, Claude Design, 새로 생긴 스타트업 여럿, 심지어 HTML 프로토타입도 좋다. 어쨌든 디자인을 위해 만들어진 도구를 쓰고, AI에게 매번 3~4개 변주를 만들게 하라.

4. 컴포넌트와 라이브러리를 쓴다.

대부분의 엔지니어에게는 이건 뻔한 얘기일 텐데, 아주 중요하니 빠르게 짚고 간다.

뷰와 로직을 분리한다. 재사용 컴포넌트를 만든다.

어려운 일이 아니고, 배당(dividends)을 낸다. 앱이 재구현된 버튼들의 패치워크가 아니라 시각적으로 응집력 있게 된다.

Ref에서는 이걸 위해 /showcase 페이지를 유지한다. 에이전트가 UI 컴포넌트를 거기서 먼저 만들고 갖고 놀아본 뒤에야 본앱에 연결한다.

5. 프리뷰 배포를 쓴다.

디자인을 평가하는 가장 좋은 방법은 실 데이터다. 프리뷰 배포는 새 디자인을 실 백엔드로 시험하게 해준다.

기억해두어야 할 것 — 어쨌든 손봐야 할 게 항상 남는다. 에이전트가 시킨 그대로를 만들었다 해도, 실 데이터로 손에 쥐어 보면 "이게 아닌데"가 나올 수 있다.

프런트엔드와 백엔드가 모두 걸린 큰 기능은 프리뷰 배포가 까다로울 수 있다. Ref에서는 프런트와 백 PR을 분리해 이걸 푼다. 백엔드 변경은 유닛·통합 테스트로 검증한다. 프런트엔드 변경은 사람의 확인이 필요하니, 프리뷰 배포가 있으면 링크 한 줄로 공유하기가 쉽다.

6. 훔친다.

대부분의 UX 문제는 이미 풀렸다 — 조각을 가져와 조립하라. 비슷한 문제를 풀거나 비슷한 아이디어를 전달하는 제품들을 시간을 들여 봐라.

내가 함께 일한 뛰어난(cracked) 디자이너들은 모든 프로젝트를 스크린샷을 잔뜩 모으는 것으로 시작했다. 당신도 그렇게 해라. 그게 에이전트에게 넘길 최고의 컨텍스트가 된다.

7. 취향을 탐구한다.

이건 재밌는 부분이다!

취향(taste)은 자기 반응을 자기가 관찰하는 것이다. 그리고 Kyle Chayka에게는 미안하지만, 자기 경험을 성찰하는 일은 브루클린 로프트 파티에 다니는 사람들만의 전유물이 아니다. 창조하고 슬롭을 만들지 않기 위해서는 필수다.

제품 엔지니어는 디자인이 안 될 때를 알아채는 데에는 아주 능숙하지만, 어떻게 고칠지는 잘 모른다. 엔지니어에게 부족한 건 경험에서 뽑아쓸 해법 라이브러리다. 그걸 짓는 유일한 방법은 반복 — 시도하고, 반사하고.

놀고 탐구하는 건 재밌다. 하지만 좋은 뭔가에 도달할 때까지 비평의 홍수를 맞는 일이라 꽤 잔인하게 느껴질 수도 있다.

Ref에는 전담 디자이너가 없어서, 우리는 탈곡(threshing) 방식으로 취향을 벼린다. 디자인을 가운데에 던져놓고 마음에 들 때까지 몽둥이질(beat with sticks)을 한다.