지난 글에서 AI 시대의 디자이너에게 더 중요해지는 역량으로 ‘문제 구조화’를 이야기했습니다.

AI는 점점 더 많은 것을 빠르게 만들어냅니다. 

이미지를 만들어 카피를 제안하며, 레퍼런스를 정리해서 화면의 초안을 빠르게 보여주기도 합니다. 이처럼 만드는 속도는 분명 빨라졌습니다. 하지만 실제 디자인 업무를 떠올려보면 속도가 빨라졌다고 해서 일이 곧바로 쉬워지는 것은 아니었습니다. 오히려 선택지는 더 많아졌기에 무엇을 먼저 봐야 하는지, 어떤 기준을 두고 판단해야 하는지, 어디서부터 풀어야 하는지 등 결정해야 하는 순간이 늘어났습니다. 그래서 저는 앞으로의 디자이너에게 중요한 질문이 조금 달라질 수 있다고 생각합니다. 바로 “무엇을 더 빠르게 만들 수 있을까?” 보다 “무엇을 먼저 풀어야 할까?”를 볼 수 있어야 한다는 것입니다.

그렇다면 다시 질문이 생깁니다.

문제 구조화가 중요하다면, 디자이너는 실제 업무에서 무엇부터 해볼 수 있을까요?

문제 구조화는 거창한 전략 문서에서만 시작되지 않습니다

문제 구조화라고 하면 조금 어렵게 들립니다.

큰 프로젝트의 방향을 정리하거나, 복잡한 비즈니스 문제를 분석하며 여러 이해관계자의 요구를 조율하는 장면을 떠올리기 쉽습니다. 물론 그런 일도 문제 구조화에 해당하지만 디자이너의 일상에서 문제 구조화는 훨씬 작은 순간에서 시작될 때가 많습니다.

예를 들어 이런 피드백을 받았을 때입니다.

“더 직관적으로 해주세요.”

“좀 더 깔끔하게 정리해주세요.”

“CTA가 더 잘 보였으면 좋겠어요.”

“사용자가 헷갈릴 것 같아요.”

이런 말들은 실무에서 자주 등장하는데 겉으로 보면 모두 수정 요청처럼 보입니다. 그래서 바로 화면을 열고 버튼을 키우거나, 문구를 바꾸거나, 레이아웃을 정리하고 싶어지지만 이런 피드백일수록 바로 수정하기 전에 먼저 해야 할 일이 있습니다.

이 말이 정확히 어떤 문제를 가리키는지 나누어보는 일입니다.

애매한 피드백 안에는 여러 문제가 섞여 있습니다

“더 직관적으로 해주세요”라는 피드백은 단순해 보이지만, 이 말 안에는 여러 가능성이 섞여 있을 수 있습니다.

사용 흐름의 문제

사용자가 다음 행동을 찾지 못하고 있을 수도 있습니다. CTA 버튼 자체가 작은 것이 아니라, CTA를 누르기 전에 이해해야 할 정보가 충분히 정리되지 않았을 수도 있습니다.

표현 취향의 문제

화면의 구조는 크게 문제 없지만, 문구의 톤이나 시각적 인상이 팀이 기대한 방향과 다를 수 있습니다. 이 경우에는 UX 흐름보다 표현 방식의 조정이 더 중요할 수 있습니다.

정보 구조의 문제

중요한 정보가 뒤에 있거나, 보조 정보가 앞에 나와 있을 수 있습니다. 사용자가 무엇을 먼저 봐야 하는지 정리되지 않은 상태일 수도 있습니다.

전달 리스크

기획자, 개발자, 마케터가 같은 화면을 보고도 서로 다르게 이해하고 있을 수 있습니다. 사용자의 문제가 아니라 팀 내부에서 의도가 충분히 공유되지 않은 문제일 수도 있습니다.

하나의 피드백 안에는 이렇게 여러 문제가 섞일 수 있습니다. 작업을 시작하기 전, 이걸 구분하지 않은 채 바로 수정한다면 손은 빠르게 움직였지만 진짜 문제가 해결됐는지는 알기 어려울 수 밖에 없습니다.

첫 번째로 해볼 수 있는 일은 피드백을 그대로 적는 것입니다

문제를 구조화하기 위해 가장 먼저 해볼 수 있는 일은 의외로 단순합니다.

받은 피드백을 해석하기 전에 그대로 적는 것입니다. 

회의에서 들은 말, 슬랙에 남은 문장, 피그마 코멘트에 달린 표현을 최대한 그대로 옮겨보는 것이 중요한 이유는 피드백을 받는 순간부터 디자이너는 이미 해석을 시작하기 때문입니다. “더 직관적으로 해주세요”라는 말을 듣자마자 버튼을 키워야겠다는 결심을 하거나 “깔끔하게 정리해주세요”라는 말에 곧바로 여백이나 정렬의 문제로 받아들이는 것 처럼 말입니다. 처음 받은 말과 내가 해석한 문제는 다를 수 있기 때문에 먼저 피드백 원문을 남겨두면 좋습니다.

그 다음에야 이 말이 실제로 어떤 문제를 말하는지 볼 수 있습니다. 

피드백을 그대로 적는 일은 단순한 기록이 아닙니다. 문제를 바로 내 방식으로 해석해버리지 않기 위한 첫 번째 안전장치에 가깝습니다.

두 번째는 문제의 종류를 나누어보는 것입니다

피드백을 그대로 적었다면, 다음에는 문제의 종류를 나누어볼 수 있습니다.

이 피드백은 사용 흐름의 문제인가?

표현 취향의 문제인가?

정보 구조의 문제인가?

팀 안에서 의도가 다르게 전달된 문제인가?

비즈니스 우선순위가 달라진 문제인가?

이 질문을 던지는 것만으로도 피드백은 조금 달라집니다.

처음에는 하나의 수정 요청처럼 보였던 말이, 실제로는 여러 갈래의 문제로 나뉘기 시작합니다. 예를 들어 “CTA가 더 잘 보였으면 좋겠어요”라는 피드백을 받았다고 가정 해보겠습니다. 이 말은 버튼을 더 크게 만들라는 뜻일 수도 있지만 꼭 그렇지만은 않습니다. CTA 이전에 사용자가 이해해야 할 가치가 충분히 전달되지 않았을 수도 있고, 화면에서 CTA보다 더 강하게 보이는 요소가 있을 수 있거나 CTA 문구가 행동을 명확하게 설명하지 못하고 있는 문제일 수도 있기 때문입니다.

이렇게 문제를 나누어보면 바로 고쳐야 할 것이 조금 더 분명해집니다. 디자이너가 해야 할 일은 피드백을 그대로 실행하는 것이 아니라, 그 피드백이 어떤 문제를 가리키는지 먼저 구분하는 일일 수 있습니다.

세 번째는 이번 수정의 기준을 한 문장으로 써보는 것입니다

문제의 종류를 나누었다면, 다음에는 이번 수정의 기준을 한 문장으로 써볼 수 있습니다.

이 단계가 빠지면 작업 중에 방향이 쉽게 흔들립니다. 처음에는 사용 흐름을 개선하려고 시작했는데 작업하다 보면 시각 표현을 다듬는 데 더 많은 시간을 쓰게 될 수 있습니다. 정보 구조를 정리하려고 했는데 어느 순간 버튼 색상이나 아이콘 스타일을 고민하고 있을 수도 있습니다. 세부 표현도 중요하지만 이번 수정에서 가장 중요한 기준이 무엇인지 정리되지 않으면, 작업이 쉽게 넓어지는 경우가 태반입니다.

예를 들어 이렇게 써볼 수 있습니다.

“이번 수정의 기준은 CTA를 더 크게 만드는 것이 아니라, CTA 전에 사용자가 이해해야 할 핵심 가치를 먼저 정리하는 것이다.” 또는 이렇게 쓸 수도 있습니다. “이번 수정은 화면을 더 예쁘게 만드는 것이 아니라, 사용자가 다음 행동을 망설이지 않도록 정보 순서를 정리하는 것이다.” 이런 문장은 정답을 보장하지 않지만 작업의 기준을 잡아줍니다.

기준이 있으면 무엇을 고쳐야 하는지뿐 아니라, 무엇은 이번 범위에서 제외해도 되는지도 판단할 수 있습니다.

네 번째는 바로 고칠 일과 먼저 확인할 일을 분리하는 것입니다

모든 피드백이 바로 작업으로 바뀌어야 하는 것은 아닙니다.

어떤 피드백은 바로 수정할 수 있습니다. 오탈자, 간단한 정렬, 명확한 누락, 합의된 문구 변경처럼 범위가 분명한 일은 바로 고쳐도 됩니다. 반대로 어떤 피드백은 먼저 확인이 필요합니다. “사용자가 헷갈릴 것 같아요”라는 말은 실제 사용자 흐름에서 문제가 발견된 것인지, 팀원이 보기엔 낯설게 느껴진 것인지 먼저 확인해야 할 수 있습니다. “좀 더 직관적으로”라는 말도 마찬가지입니다. 어디가 직관적이지 않은지, 누구 기준에서 어려운지, 어떤 행동을 기대했는데 실패했는지를 확인하지 않으면 수정 방향이 흐려지기 때문입니다.

피드백을 받았을 때 바로 할 일과 먼저 확인할 일을 나눠보면 좋습니다.

바로 고칠 수 있는 것은 무엇인가.

먼저 질문해야 할 것은 무엇인가.

추가로 확인해야 할 기준은 무엇인가.

이번 범위에서 제외해도 되는 것은 무엇인가.

이 구분만 해도 작업의 복잡도가 줄어듭니다.

디자이너는 모든 피드백을 한 번에 해결하려는 사람보다, 무엇을 먼저 봐야 하는지 정리하는 사람이 되어야 합니다.

다섯 번째는 팀에 설명할 수 있는 문장으로 바꿔보는 것입니다

문제를 잘 나누었다면, 마지막으로 해볼 수 있는 일은 그것을 팀에 설명할 수 있는 문장으로 바꾸는 것입니다.

디자인은 혼자 결정하고 끝나는 일이 아닙니다.

기획자에게 설명해야 할 때도 있고, 개발자에게 수정 범위를 전달해야 할 때도 있습니다. 마케터나 대표에게 왜 이 방향을 선택했는지 공유해야 하는 경우도 있습니다. 이때 중요한 것은 결과물만 보여주는 것이 아닙니다. 왜 이렇게 봤고 어떤 기준으로 판단했는지, 무엇을 먼저 수정하려는지 내 생각을 설명할 수 있어야 합니다.

문제를 구조화한다는 것은 머릿속으로만 정리하는 일이 아닌 다른 사람이 이해할 수 있는 언어로 바꾸는 일까지 포함하는 개념에 가깝습니다.

문제 구조화는 작은 습관으로 연습할 수 있습니다

문제 구조화는 한 번에 잘하게 되는 능력은 아니라고 생각합니다.

좋은 프레임워크를 안다고 바로 실무에서 자연스럽게 쓰기도 어렵습니다. 프로젝트가 복잡할수록 변수가 많고, 피드백은 늘 모호하게 들어옵니다. 때문에 오히려 작은 피드백에서 반복해서 연습하는 것이 중요할 수 있습니다.

받은 말을 그대로 적어보기.

문제의 종류를 나눠보기.

이번 수정의 기준을 한 문장으로 써보기.

바로 고칠 일과 먼저 확인할 일을 분리하기.

팀에 설명할 수 있는 문장으로 바꿔보기.

이런 과정은 아주 작아 보이지만 반복하다 보면 디자이너의 일하는 방식에 영향을 줍니다. 피드백을 받았을 때 바로 손부터 움직이는 것이 아니라, 먼저 문제의 형태를 살펴보게 됩니다. 수정 요청을 그대로 실행하는 것이 아니라 그 안에 숨어 있는 기준을 찾게 됩니다. 팀과 이야기할 때도 “이렇게 바꿨습니다”에서 끝나지 않고, “이런 문제로 보고 이렇게 바꾸려고 합니다”라고 설명할 수 있게 됩니다.

이 차이는 작지만, 실무에서는 꽤 큰 차이를 만들어냅니다.

AI가 도와야 할 일도 여기서 시작될 수 있습니다

AI가 디자인 업무를 돕는다고 하면, 자연스럽게 결과물을 대신 만들어주는 장면을 먼저 떠올립니다.

시안을 만들고, 문구를 제안하고, 이미지를 생성하는 일은 분명 도움이 되지만 디자이너에게 필요한 도움은 그것만이 아닐 수 있습니다. 애매한 피드백을 그대로 받아 적고, 문제의 종류를 나누고, 판단 기준을 정리하고, 다음 행동으로 이어지게 만드는 일. 이런 과정도 충분히 AI가 도울 수 있는 영역이라고 생각합니다.

중요한 것은 AI가 디자이너의 판단을 온전히 대신하는 것이 아닙니다.

오히려 디자이너가 더 잘 판단할 수 있도록, 흩어진 말을 구조화하고 다음에 무엇을 봐야 하는지 정리해주는 것입니다. AI가 더 많은 결과물을 만들어낼수록, 디자이너에게 필요한 것은 더 많은 결과물을 받는 일이 아닐 수 있습니다. 그 결과물과 피드백을 어떤 기준으로 보고 어떤 순서로 다룰지 정리하는 일이 더 중요해질 수 있습니다.

D:bo를 만들며 보고 있는 것도 이 지점입니다

D:bo를 만들면서도 이 지점을 계속 보고 있습니다.

디자이너의 판단을 온전히 대신하는 AI를 만들고 싶은 것은 아닙니다. 오히려 디자이너가 받은 피드백과 업무 메모를 더 잘 나누고, 기준을 세우고, 다음 행동으로 이어갈 수 있게 돕는 구조를 만들고 싶기에 어떻게 하면 더 개인화 된 판단을 잘 학습시킬 수 있을지에 대한 고민을 합니다.

디자인 업무에는 늘 모호한 말이 섞이는데, 이런 말들은 바로 할 일로 바꾸기 어렵습니다.

“직관적이지 않다.”

“깔끔하지 않다.”

“조금 더 설득력 있었으면 좋겠다.”

“사용자가 헷갈릴 것 같다.”

먼저 어떤 문제인지 나누어야 합니다. 판단 기준을 세워야 합니다. 지금 고칠 일과 더 확인해야 할 일을 구분해야 합니다. 그리고 팀에 설명할 수 있는 언어로 바꾸어야 합니다. D:bo는 이 작은 과정을 더 자연스럽게 이어보고 있습니다. 아직 완성된 답은 아니지만, 디자이너가 문제를 더 잘 구조화할 수 있는 업무 흐름을 계속 만들어보고 있습니다.

문제 구조화는 거창한 전략 문서에서만 시작되지 않습니다.

어쩌면 디자이너가 매일 받는 애매한 피드백을 바로 수정하지 않고, 한 번 더 나누어보는 일에서 시작될 수 있습니다. 

아래의 질문들을 반복해서 던지는 것만으로도 디자이너의 문제 해결 방식은 조금씩 달라질 수 있다고 생각합니다.

이 피드백은 어떤 문제에 가까운가.

이번 수정의 기준은 무엇인가.

바로 고칠 일과 먼저 확인할 일은 무엇인가.

팀에 어떻게 설명할 수 있을까.

AI가 더 많은 것을 만들어내는 시대일수록, 디자이너는 더 잘 만들어내는 사람을 넘어 더 잘 나누고, 더 잘 판단하고, 더 잘 설명하는 사람이 되어야 할지도 모릅니다. 

[D:bo 디보 보러 가기]