디자인 툴 대신 대화로 일하기

요즘은 ‘AI로 무엇을 만드는가’보다 ‘AI로 아낀 시간을 어디에 쓰는가’가 더 중요해졌다고 생각합니다.

저는 리멤버에서 헤드헌터를 위한 AI 에이전트를 만드는 PM이자 디자이너로, 무엇을 만들지 정하는 일부터 화면을 설계하고 프론트엔드 코드를 고쳐 PR을 올리는 일까지 맡고 있습니다. 지난 3개월 동안은 디자인 툴을 거의 열지 않고, Claude(주로 Claude Code)와 대화하며 요구사항을 정리하고 바로 눌러볼 수 있는 시뮬레이션을 만들고 직접 코드를 고쳤습니다.

하지만 툴을 바꾼 것만으로 일하는 방식이 달라지지는 않았습니다. 일이 정말 달라진 건, 그렇게 아낀 시간을 사용자의 문제를 푸는 데 쓰기 시작하면서부터였습니다.

오늘은 이 제품을 만들면서 AI가 모르는 디자이너의 판단을 어떻게 알려주고 쌓아 갔는지, AI 제품을 만드는 사람으로서 AI와 함께 일하며 겪은 시행착오를 공유해 보려 합니다.

손은 AI가, 판단은 제가

예전에는 요구사항을 듣는 것부터 기획서, 디자인 시안까지 제가 만들어서 개발자분께 넘기면, 개발자분이 그것을 해석해서 구현했습니다. 그래서 실제로 어떻게 움직이는지는 QA 단계가 되어서야 알 수 있었습니다.

지금도 거치는 단계는 같지만, ‘누가 손을 움직이고, 누가 판단하느냐’가 달라졌습니다.

정리하고, 안을 여러 개 만들고, 코드를 쓰는 일은 AI가 하지만, 맨 아래 줄의 판단은 끝까지 제가 합니다.

기획서 대신 눌러보는 화면으로

예전에는 말, 기획서, 멈춰 있는 시안으로 이야기했는데, 말과 글은 사람마다 다르게 상상하고, 기획서와 시안은 따로 고쳐야 하고, 실제 동작은 개발이 끝나야 볼 수 있었습니다.

그래서 지금은 기획서와 시안을 따로 만드는 대신 바로 눌러볼 수 있는 시뮬레이션을 만드는데요. 검색하기, 조건 바꾸기, 후보 저장하기 같은 단계가 실제처럼 움직이고 기획 내용이 화면 동작 안에 그대로 들어가 있어서, 개발자분과 논의할 때도 이 화면을 함께 눌러보면서 이야기했습니다.

정보의 해상도로 나눠 보면 차이가 분명해집니다.

해상도가 가장 높은 쪽에서 바로 확인하니, 해석이 갈리는 일이 줄고 확인도 빨라졌습니다.

처음에는 느렸고, 기준이 쌓이자 빨라졌습니다

10월 네 주 동안(11월 1일까지) 디자이너인 제가 직접 올린 PR은 78건이고, 그중 77건이 머지됐고, 한 건은 닫았습니다.

주별로 나눠 보면 변화가 더 잘 보입니다.

첫 주가 느렸던 건 기반을 잡기 위해서였고, 기록과 규칙이 쌓이니 속도가 붙었습니다. 마지막 주에 10건으로 줄어든 건 화면을 고치는 일보다 다음 기능의 기획서를 쓰고 검토하는 데 시간을 더 썼기 때문인데요. 이 주에만 기획서 세 개에 대한 검토를 네 번 정도 돌렸습니다. (기획서 검토 방식은 뒤에서 자세히 풀어볼게요!)

기능 하나에 시간이 얼마나 드는지도 대화 기록으로 계산해 봤는데요. (10분 넘게 비어 있던 구간과 리뷰를 기다린 시간은 뺐어요.) 규모가 컸던 화면 개편 하나를 예로 들면, 시안 고르기부터 바뀐 점 공유까지 제가 맡은 전 과정에 Claude와 대화한 시간은 약 2시간 30분이었습니다.

평균으로 보면, 처음 3주 동안 에이전트 작업으로 대화한 시간이 약 30시간이고 그동안 올린 PR이 71건이니 PR 하나에 25분 정도 쓴 셈이고, PR을 올리고 리뷰를 거쳐 머지되기까지는 중간값으로 2시간이 채 걸리지 않았습니다. (물론 25분에는 PR로 이어지지 않은 대화도 섞여 있어서, 정확한 숫자라기보다는 대략적인 감을 잡는 정도로 봐 주세요!)

덜 하게 된 게 아니라, 시간을 쓰는 곳이 바뀌었습니다

기획이든 디자인이든 덜 하게 된 것은 아닙니다. 같은 시간을 문서를 맞추는 데가 아니라 판단하는 데 쓰게 됐을 뿐입니다.

툴을 바꾸는 것이 AX는 아닙니다

저는 디자인 툴에서 Claude로 툴을 바꾼 것 자체를 AX(AI 전환)라고 생각하지 않습니다. 제가 생각하는 AX는 세 단계로 나눌 수 있습니다.

1. 툴이 바뀝니다. 디자인 툴 대신 대화로 만듭니다. 예: PR 하나에 대화 약 25분.
2. 아낀 시간을 문제 해결에 씁니다. 이 요구가 사용자에게 정말 맞는지부터 고민합니다. 예: 먼저 써 보고 있는 사내 사용자 19명의 의견을 분석하고, 기획서는 넘기기 전에 맥락을 모르는 리뷰어들이 먼저 읽게 합니다.
3. 성과에 집중합니다. 넣은 기능이 정말 효과가 있었는지 데이터로 확인합니다. 예: 기능을 넣을지 뺄지 데이터로 판단하는 스킬.

1단계에서 멈추면 툴만 바뀐 셈입니다. 2단계와 3단계까지 가야 비로소 제대로 된 AX라고 생각합니다.

중요한 건 무엇으로 만드느냐보다, 남은 시간을 어디에 쓰느냐라는 것.

이 글의 나머지는 그 남은 시간을 어디에 썼는지에 대한 이야기입니다.

개발자가 아니기에 걸어둔 안전장치

디자이너가 코드를 고쳐서 PR을 올린다고 하면 가장 먼저 “괜찮을까?”라는 걱정이 나오기 마련인데요. 그래서 처음부터 몇 가지 규칙을 AI에게 걸어뒀습니다.

• 맡은 범위 밖은 건드리지 않습니다. 프론트엔드 폴더 밖이나 서버 코드는 수정하지 않습니다. 서버 작업이 필요하면 따로 정리해서 개발자분께 요청합니다.
• 되돌리기 어려운 일은 제가 확인한 뒤에 합니다. 커밋, 푸시, 메시지 발송은 제가 보고 나서 진행합니다.
• 올리기 전에 직접 봅니다. PR을 올리기 전에 로컬에 띄운 화면에서 제가 먼저 확인하고, PR마다 변경 화면 캡처를 붙입니다.
• 모르면 멈추고 묻습니다. 확실하지 않으면 진행하지 말고 먼저 질문하도록 했습니다.

함께 일하는 방식도 바뀌었습니다. 저는 시안을 넘기는 대신 직접 만들어 보고 PR을 올리고, 개발자분은 제 시안을 해석하는 대신 PR을 리뷰하고 서버 작업에 집중합니다. PR마다 리뷰어가 빠르게 읽을 수 있는 3~5줄 요약도 함께 붙입니다.

누가 무엇을 만드느냐보다, 누가 무엇을 판단하느냐가 더 중요해졌다고 느낍니다.

AI는 화면을 잘 만들지만, 사용자는 모릅니다

이 글에서 가장 나누고 싶은 이야기는 지금부터입니다.

AI는 화면을 정말 빨리, 잘 만들지만, 그 화면이 사용자에게 맞는지는 모릅니다. 그건 디자이너 머릿속에만 있는 판단이라서, 말로 꺼내주고 기록으로 남겨줘야 AI도 쓸 수 있습니다.

‘디자이너의 감’이라고 하면 타고나는 것처럼 들리지만, 지난 대화들을 다시 읽어 보니 제가 화면을 실제로 바꾼 순간마다 비슷한 질문을 던지고 있었습니다. 모아 보니 여섯 가지였고, AI는 이 질문을 먼저 꺼내지 않았습니다.

(아래 그림들은 실제 제품 화면 대신, 무엇이 어떻게 바뀌었는지만 알 수 있도록 구조를 단순화해서 그렸어요.)

① 사용자가 이 화면에서 실제로 무엇을 보는가

사용자는 처음에 대화로 조건을 정하지만, 결과가 나온 뒤로는 대부분의 시간을 결과 목록을 훑어보며 보내는데요. 그래서 검색 전에는 대화를 크게 쓰다가, 결과가 나오면 결과를 가운데로 옮기고 대화는 오른쪽으로 비켜두었습니다.

② 사용자가 어떤 환경에서 일하는가

제 큰 모니터에서는 괜찮았지만, 사용자가 주로 쓰는 노트북에서 보니 스크롤해도 위에 붙어 있는 영역이 너무 커서 후보가 몇 명 보이지 않았습니다. 그래서 이 영역을 291px에서 186px로 줄여 한 화면에 보이는 후보를 늘렸습니다.

③ 무엇을 먼저 봐야 하는가

후보의 구직 상태를 알려주는 두 배지가 똑같이 생겨서, 어떤 후보를 먼저 봐야 할지 알 수 없었습니다. 사용자에게는 지금 이직하려는 사람이 더 중요하기 때문에, ‘지금 구직 중’ 배지만 진한 바탕으로 바꿔 먼저 눈에 띄게 했습니다.

④ 주요 CTA를 누르면 어떤 일이 생기는가

여러 명을 골랐을 때 버튼에 그냥 ‘제안’이라고만 있으면, 누르기 전까지는 몇 명에게 무엇이 적용되는지 알 수 없습니다. 그래서 ‘제안 1명’, ‘저장 해제 1명’처럼 대상과 결과를 버튼에 적었습니다. 후보를 걸러내는 필터도 체크하기 전에 어떤 후보가 빠지는지 먼저 설명하도록 바꿨습니다.

⑤ 불필요한 요소를 왜 빼야 하는가

대화가 끝날 때마다 제목, 설명, 버튼, 큰 입력칸이 있는 피드백 카드가 떠서 정작 봐야 할 대화를 밀어내고 있어서, 설명과 입력칸을 빼고 질문 한 줄과 버튼 두 개로 줄였습니다.

⑥ 같아야 할 요소를 어떻게 일관되게 보이게 하는가

체크박스는 주황, 선택된 칩은 보라였습니다. 둘 다 ‘선택했다’는 뜻인데 색이 다르면 사용자는 무엇이 다른지 헷갈리기 때문에, 선택 표시는 모두 보라로 맞췄습니다. 패널 머리글도 어떤 패널은 아이콘이 없고 어떤 패널은 구분선이 없던 것을, 모두 아이콘·제목·구분선 구조로 통일했습니다.

여섯 가지 질문과 UX 원칙

다시 보니 이 여섯 가지는 익숙한 UX 원칙과 모두 이어져 있었습니다.

• ① 사용자가 이 화면에서 실제로 무엇을 보는가 → 목표에 집중
• ② 사용자가 어떤 환경에서 일하는가 → 맥락에 맞게
• ③ 무엇을 먼저 봐야 하는가 → 가치 먼저
• ④ 주요 CTA를 누르면 어떤 일이 생기는가 → 예측 가능성, 사용자 선택
• ⑤ 불필요한 요소를 왜 빼야 하는가 → 목표에 집중
• ⑥ 같아야 할 요소를 어떻게 일관되게 보이게 하는가 → 예측 가능성

원칙은 다들 알고 있지만, 원칙을 실제 화면에 적용할 때 던지는 질문이 바로 이 여섯 가지였던 것 같습니다.

판단을 AI에게 알려주는 방법

판단을 알려주는 방법은 말하기, 묻기, 남기기 세 가지입니다.

말하기 — 이유까지 함께

같은 요청이라도 이유를 말하느냐에 따라 결과가 꽤 달라집니다.

• ❌ “버튼 위치 고정해줘.”
  → 딱 그 화면만 바뀝니다.
• ✅ “화면이 좁으면 주요 버튼이 어떤 건 오른쪽, 어떤 건 왼쪽으로 밀려나. 버튼 위치는 고정되는 게 좋겠어.”
  → 비슷한 다른 화면을 만들 때도 AI가 그 기준을 알아서 적용합니다.

AI가 다음에 써먹는 건 지시가 아니라 이유였습니다. 그 결과 카드 길이가 달라도 [제안]·[저장] 버튼은 항상 같은 자리에 있게 됐습니다.

묻기 — 고치기 전에, 왜 있는지 먼저

AI가 처음 만든 후보 카드에는 이름 옆에 배지와 태그가 잔뜩 붙어 있었는데, 바로 “빼줘”라고 하지 않고 하나씩 물어봤습니다.

“new 배지는 왜 있는 거야? 설명 먼저 해줘.”
“지금 버전은 복잡도만 높아 보여. 여러 시안을 보고 결정하자.”

설명을 들어 보면 사용자에게 필요한 것인지 아닌지 판단할 수 있고, 그렇게 덜어낸 뒤 시안 네 개를 받아서 하나를 골랐습니다.

가끔 AI가 정리한 답이 결정을 개발자에게 넘기는 식일 때는 “내가 정할 것만 알려줘”라고 했습니다.

설명은 AI가 하고, 결정은 제가 한다는 것.

남기기 — 두 번 말하게 되면 기록으로

같은 말을 두 번 하게 되면 기록으로 남겼습니다. 어디에 남기느냐에 따라 그 기준을 쓸 수 있는 범위가 달라집니다.

오른쪽으로 갈수록 같은 기준을 쓰는 사람과 상황이 늘어납니다. 지금까지 판단 기록(메모리)이 51개, 스킬이 10개 쌓였습니다.

같은 내용이라도 누가 읽느냐에 따라 기준이 달라지는 것도 기록해 둡니다. 예를 들어 이 글처럼 회사 밖에 공개하는 글은 제 블로그 말투로 쓰고 실제 제품 화면 대신 단순화한 그림을 쓰지만, 사내 발표 자료는 해요체로 쓰고 실제 화면에서 설명할 부분만 잘라 넣습니다. 이런 차이도 한 번 정해서 남겨 두면, 같은 이야기를 다른 곳에 옮길 때 다시 설명하지 않아도 됩니다.

메모리를 남길 때는 판단만 적지 않고, 왜 그런지와 언제 쓸지를 함께 적습니다. 실제로 남긴 기록 하나를 읽기 쉽게 조금 다듬어서 공유드려 볼까 합니다.

---
name: verify-local-before-pr
description: 프론트 PR은 올리기 전에 로컬 화면에서 직접 확인한다
type: feedback
---

PR을 올리기 전에 로컬에 띄운 화면에서 작업 내용을 직접 확인한다.
테스트 통과만으로 PR을 올리지 않는다.
**Why:** 단위 테스트로는 화면의 동작이나 모양 문제를 잡지 못한다.
**How to apply:** 구현 → 로컬 실행 → 화면 확인·캡처 → PR 순서로 한다.
로컬에서 확인할 수 없으면 PR을 올리기 전에 먼저 알린다.

이유까지 적어 두니 따로 말하지 않아도 AI가 다른 작업에서도 같은 순서를 지켰고, 앞에서 소개한 ‘올리기 전에 직접 봅니다’라는 안전장치도 이렇게 남겨 둔 기록에서 시작됐습니다. 새 대화를 열면 AI가 이 기록과 작업 인계 문서부터 읽고 시작하니, 같은 말을 반복할 일도 줄었습니다.

다만 기록도 낡습니다. 코드는 매일 바뀌는데 문서는 그보다 늦게 따라오니, 낡은 문서를 믿고 시작하면 이미 바뀐 색이나 이미 머지된 작업을 전제로 시안을 만들게 됩니다. 그래서 새 작업을 시작하기 전에는 AI가 인계 문서와 디자인 기준 문서를 최신 코드와 비교해서, 어긋난 곳만 찾아 알려 주도록 했습니다. 문서를 고칠지 코드를 고칠지는 그 목록을 보고 제가 정합니다.

잔소리를 구조로 바꾸기

지난 30일, AI를 79번 바로잡았습니다

이 루프가 실제로 돌고 있는지 확인해 보고 싶어서, AI에게 지난 30일간의 대화 90개를 다시 읽고 제가 끼어들어 바로잡은 순간을 찾아 달라고 했는데요. 제가 직접 센 게 아니라 AI가 찾아낸 숫자가 79번이었습니다.

같은 말을 반복하고 있다는 건 당부만으로는 해결되지 않는다는 뜻이었고, 그래서 당부로 끝내지 않고 구조로 바꿨습니다.

잔소리가 스킬이 되기까지

자주 나온 잔소리마다 그것을 막는 스킬을 하나씩 만들었습니다. 스킬은 해당하는 작업이 시작되면 AI가 알아서 꺼내 씁니다.

• 실제 화면 기준 시안 — 상상하지 않고 실제 코드와 디자인 시스템부터 읽습니다. (계기: 실제 환경과 다른 가정)
• 서비스 간 교차 확인 — 연결된 여러 서비스가 엮이는 지점을 먼저 찾습니다. (계기: 실제 환경과 다른 가정)
• 보여주기 전 자기 검증 — 여백, 색, 요청하지 않은 장치를 스스로 검사합니다. (계기: “왜 있어?”, 스타일 제각각)
• 내 말투로 공유 문구 — 슬랙·공지를 제 말투로 쓰고 검사합니다. (계기: 공유 문구 다시 고치기)
• 사용성 피드백 정리 — 사내 사용자 제보 중 사용성 이슈만 묶습니다. (계기: 제보를 묶어서 보려고)
• 데이터로 넣고 빼기 — 기능을 넣을지 뺄지 데이터로 판단합니다. (계기: 감 대신 데이터로 판단하려고)
• 바로잡은 순간 회고 — 위의 79번을 찾아낸 스킬로, 2주마다 자동으로 돕니다. (계기: 같은 지적이 반복돼서)

그 뒤로 일주일이 채 안 돼 세 개가 더 늘었습니다.

• 문서와 코드 어긋남 점검 — 작업 전에 기준 문서가 최신 코드와 다른 곳만 찾습니다. (계기: 낡은 문서를 믿고 시작함)
• 맥락 없는 리뷰어 검토 — 기획서를 넘기기 전에, 대화를 모르는 리뷰어들이 문서만 읽고 검토합니다. (계기: 쓴 사람에게는 빈 곳이 안 보여서)
• 발표 자료 스타일 — 색, 여백, 말투, 설명 순서를 처음부터 제 기준으로 만듭니다. (계기: “색이 너무 많아”, “내 말투가 아니야”)

스킬로도 막기 어려운 건 자동 검사로 바꿨습니다. 대표적인 것이 ‘영어로 답함’이었습니다. “한국어로 설명해 줘”라고 여섯 번을 말했는데도 긴 작업 끝에는 다시 영어 요약이 나오곤 했습니다. 그래서 Claude Code의 훅(hook)에 답변이 끝날 때마다 한국어인지 검사하는 스크립트를 걸었습니다.

{
  "hooks": {
    "Stop": [
      { "hooks": [{ "type": "command", "command": "python3 ~/.claude/hooks/korean-check.py" }] }
    ]
  }
}

재미있는 건, 이 글의 바탕이 된 발표 자료를 만드는 중에도 답이 영어로 나가자 이 검사가 바로 막고 한국어로 다시 쓰게 했다는 점입니다.

부탁하는 대신, 같은 실수를 다시는 할 수 없게 만드는 것.

만든 AI 말고, 맥락을 모르는 AI가 검토합니다

요즘 가장 많이 쓰는 방식은 기획서 검토인데요. 기획서를 함께 쓴 AI는 대화 내내 저와 같은 가정을 쌓아 왔기 때문에 문서에 빠진 내용이 있어도 자기 머릿속에서 채워 읽고, 저도 마찬가지입니다. 하지만 개발자분은 그 대화를 본 적이 없습니다.

그래서 개발자에게 넘기기 전에, 대화 기록 없이 문서와 근거 자료만 받은 리뷰어 넷을 동시에 돌립니다.

• 처음 읽는 개발자 — 이 문서만 보고 바로 구현을 시작할 수 있는가
• 줌아웃 — 이 기능이 전체 제품과 목표 안에서 맞는 자리에 있는가
• 비평가 — 숫자와 주장이 근거와 맞는가, 사용자가 오해할 표현은 없는가
• 구현 준비도 — 결정되지 않은 것, 순서, 담당이 빠지지 않았는가

리뷰어 넷의 지적은 하나의 파일로 모이고, 겹친 것은 합쳐서 ‘막힘 · 중요 · 사소’로 나뉩니다.

지난주에는 기획서 세 개에 네 번 돌렸습니다. 앞의 두 기획서는 지적이 각각 51개, 43개 나왔고, 겹친 것을 합치니 각각 27개가 남았습니다. 그중 “이대로면 개발을 시작할 수 없다”는 막힘이 5개, 2개였는데, 예를 들어 “바꾸지 않는다”고 적어 둔 계산식을 다른 장에서는 사실상 바꾸자고 하고 있다는 지적은 네 리뷰어가 모두 짚었습니다. 세 번째 문서는 막힘 2개를 고친 뒤 처음 보는 리뷰어들에게 다시 돌렸는데도 막힘이 또 2개 나와서, 지금은 고친 뒤에도 처음 보는 눈으로 한 번 더 읽게 합니다.

여기서도 결정은 제가 합니다. 항목마다 반영, 보류, 거절 중 하나를 고르고 이유를 적습니다. 리뷰어가 아무리 많이 지적해도, 그 지적이 우리 사용자와 지금 단계에 맞는지는 AI가 판단할 수 없기 때문입니다.

반복되는 일은 예약해 두고 맡깁니다

회고뿐 아니라 매일, 매주 반복되는 일도 예약 작업으로 돌립니다. 지금은 다섯 개가 돌아가고 있습니다.

• 평일 아침 — 저에게 온 멘션, DM, 요청을 모아 ‘오늘 챙길 일’로 보내줍니다
• 매주 — 사내 사용자들이 피드백 채널에 남긴 제보 중 사용성 이슈만 골라, 같은 문제끼리 묶어 처리 상태와 함께 한 장의 표로 정리합니다
• 매주 — 이슈 트래커의 작업 현황을 팀 채널에 맞는 형태로 공유합니다 (2개)
• 2주마다 — 제가 AI를 바로잡은 순간을 모아 스킬·규칙 후보로 정리합니다

맡겨 둔 일이 정말 됐는지도 확인합니다. 메신저 연결이 끊겨 아무것도 보내지 못한 날에도 예약 작업은 ‘성공’으로 기록된 적이 있었는데요. 그래서 새 대화를 열 때마다 실행 기록을 직접 읽어, 실제로 보낸 것이 없거나 정해진 시각에 돌지 않은 작업이 있을 때만 알려 주는 검사를 걸어 두었습니다.

반복 작업이 알아서 돌아가는 만큼, 사용자를 고민하는 데 쓸 시간이 늘었습니다.

솔직히, 잘 안 됐던 것들

물론 모든 과정이 매끄럽진 않았습니다.

• 의미 없는 장치가 계속 붙었습니다. AI는 친절하려고 배지, 배너, 설명 문구를 계속 덧붙였습니다. “화면 안에 설명이 너무 많은 느낌이야”라며 몇 번이나 덜어내야 했습니다. AI는 더하려 하고, 빼는 건 사람이 정해야 했습니다.
• 결정을 떠넘기는 답이 나왔습니다. 정리된 답변이 결정을 개발자에게 넘기는 식일 때가 있었습니다. “솔루션 결정은 내가 해야 해”라고 바로잡았습니다.
• 숫자를 그대로 믿을 뻔했습니다. 요약된 지표를 그대로 근거로 쓰려다가, 원본 데이터와 맞지 않는 것을 발견했습니다. 그 뒤로는 지표마다 원본과 대조해서, 맞는 것만 다시 근거로 쓰고 맞지 않는 것은 원본과 함께 봅니다. 대조할 원본이 없는 지표는 흐름만 참고하고 판단 근거로는 쓰지 않습니다.

이 과정에서 배운 점은 명확했습니다.

AI는 빠르지만, 판단과 확인은 끝까지 사람의 몫이라는 것.

디자이너가 아니어도 해 볼 수 있는 것

디자인 감각을 따로 배울 필요는 없습니다. 이 순서대로 한번 해 보세요.

1. 작은 것 하나로 시작합니다. 결과가 맞는지 내가 판단할 수 있는 화면이나 문서 한 장이면 충분합니다.
2. 만들어 달라고 하기 전에 상황부터 알려줍니다. 누가, 어떤 환경에서, 어떤 순서로 쓰는지 먼저 설명해 주세요. 처음에는 화면 말고 말로 안을 받아 보세요.
3. 결과가 나오면 여섯 가지 질문을 던져 봅니다. 처음에는 ‘사용자가 실제로 무엇을 보는가’와 ‘불필요한 요소를 왜 빼야 하는가’ 두 가지만 해도 충분합니다.
4. 이유를 붙여서 고치고, 두 번 말하게 되면 기억해 달라고 합니다. “○○라서 △△로 하자”처럼 이유를 한 문장 붙여 주세요.

PM이든 개발자든 운영 담당자든, 각자 자기 사용자에 대해 아는 것이 있습니다. 그것도 똑같은 방법으로 AI에게 알려 주세요. 감이 오지 않는다면 AI에게 “디자이너라면 뭘 먼저 볼까?”라고 물어봐도 괜찮습니다. 다만 그것이 우리 사용자에게 맞는지는 고객 문의, 인터뷰, 데이터로 꼭 확인해 주세요.

마치며

이번 경험을 통해 가장 크게 느낀 점은, AI와 함께 일한다는 건 결국 판단을 건네는 일이라는 것이었습니다. 이유까지 말하면 AI는 그 이유를 다음에도 씁니다. 왜 있는지 물으면 설명은 AI가 하고 결정은 제가 할 수 있습니다. 두 번 말하게 되면 남겨 두니 같은 말을 반복하지 않게 됐고, 넘기기 전에는 맥락을 모르는 눈으로 한 번 더 읽게 됐습니다.

그리고 툴을 바꾸는 것만으로는 충분하지 않았습니다. 아낀 시간을 사용자의 문제를 푸는 데 쓸 때 비로소 AX가 된다고 생각합니다.

AI는 우리 사용자를 모르고, 사용자를 아는 건 우리입니다. AI가 화면을 대신 만들어 주는 시대에도, 디자이너는 여전히 ‘사용자를 설명할 수 있는 사람’이라고 믿습니다.

읽어 주셔서 감사합니다.