지난 글에서는 Figma 세션을 보며 디자인 파일 안의 피드백과 판단이 어떻게 업무 흐름으로 이어질 수 있을지 이야기했습니다.

Figma 안에는 많은 것이 남습니다. 화면이 남고, 코멘트가 남고, 프레임과 섹션이 남습니다. 앞으로는 코드, 모션, AI 에이전트가 만든 결과물까지 더 많은 작업의 흔적이 한 공간 안에 쌓일지도 모릅니다. 그런데 글을 쓰고 난 뒤, 한 가지 질문이 더 남았습니다. 디자인 업무의 맥락은 파일 안에만 있을까? 같은 피드백을 받아도 다 다르게 해석합니다. 어떤 사람은 사용자 흐름을 먼저 보고, 어떤 사람은 정보 구조를 먼저 봅니다. 또는 팀의 의사결정 기준을 먼저 떠올리고, 브랜드의 톤이나 표현 방식을 먼저 보기도 합니다.

디자인 업무 맥락은 어떤 기준으로 문제를 보고 어떤 방식으로 판단하며, 팀과 어떻게 소통하는지에도 남아 있습니다. AI가 디자이너의 일을 제대로 도우려면 단순히 파일이나 피드백만 읽어서는 부족하고, 판단 맥락을 이해해야 한다고 생각했습니다.

같은 피드백도 디자이너마다 다르게 해석합니다

예를 들어 “좀 더 직관적으로 해주세요.”와 같은 피드백을 받았다고 해보겠습니다.

매번 강조하지만 이 말은 겉으로 보면 단순한 수정 요청처럼 보이나, 실제 업무에서는 그렇게 간단하지 않습니다. 어떤 디자이너는 이 말을 사용자 흐름의 문제로 볼 수 있고 사용자가 다음 행동을 찾지 못하고 있거나, 화면의 정보 순서가 자연스럽지 않다고 해석할 수 있습니다. 다른 디자이너는 정보 구조의 문제로 볼 수 있습니다. 중요한 정보가 뒤에 있고, 보조 정보가 앞에 나와 있어서 사용자가 핵심을 빠르게 이해하지 못한다고 볼 수도 있겠습니다. 또 다른 디자이너는 전달 방식의 문제로 해석할 수 있습니다. 화면 자체보다 팀 안에서 이 디자인의 의도와 기준이 충분히 공유되지 않았다고 볼 수도 있습니다.

이 차이는 단순한 취향 차이가 아닙니다. 디자이너가 쌓아온 경험, 맡고 있는 역할, 프로젝트의 단계, 팀의 문화, 자주 받는 피드백의 종류가 모두 영향을 줍니다. 같은 문장을 받아도 어떤 문제로 읽는지가 달라지는 것입니다. 그래서 AI가 피드백을 단순히 문장으로만 읽으면 부족합니다. “더 직관적으로”라는 말이 들어왔다는 사실보다 중요한 것은 이 디자이너가 그 말을 어떤 기준으로 해석하는지입니다.

디자이너의 일은 화면을 만드는 것보다 많은 판단을 포함합니다

디자인은 결과물로 보이는 일이 많습니다.

화면이 어떻게 바뀌었는지, 버튼이 이동했는지, 문구가 수정됐는지, 플로우가 정리됐는지는 비교적 쉽게 확인할 수 있습니다. 하지만 그 결과물 뒤에는 더 많은 판단이 있습니다. 무엇을 먼저 고칠지 정해야 합니다. 어떤 피드백을 반영하고, 어떤 피드백은 보류할지 판단해야 합니다. 팀이 말한 요구사항이 실제 사용자 문제인지, 내부 취향인지, 비즈니스 우선순위인지 구분해야 하며 개발 일정 안에서 가능한 범위도 고려해야 하고, 다음 회의에서 어떤 방식으로 설명할지도 생각해야 합니다. 이런 일들은 결과물만 봐서는 잘 드러나지 않습니다.

피드백을 해석하는 일

판단 기준을 세우는 일

결정의 이유를 설명하는 일

회의 내용을 다시 공유하는 일

작업이 끝난 뒤 무엇이 남았는지 기록하는 일

실제로 디자이너의 시간을 많이 쓰는 것은 바로 이 부분입니다. 디자이너가 창작에 집중하기 어려운 이유는 디자인을 못해서가 아닐 때가 많습니다. 오히려 창작 바깥에서 계속 발생하는 해석, 공유, 보고, 회고, 기록의 부담이 크기 때문입니다.

AI가 대신 말해주는 것만으로는 부족합니다

AI는 이미 문장을 잘 씁니다.

회의 내용을 요약할 수 있고, 슬랙에 보낼 문장도 만들고, 리포트 초안 정리나 피드백을 보기 좋은 형태로 바꿀 수도 있습니다. 이 기능들은 분명 유용 하지만 디자이너의 일을 돕는 AI가 단순히 “대신 말해주는 도구”에 머문다면 한계가 생길 수 있습니다. 디자이너에게 필요한 것은 예쁜 공유 문장만이 아닙니다. 왜 이 피드백을 이렇게 해석했는지, 어떤 기준으로 다음 작업을 정했는지, 어떤 부분은 아직 판단이 필요한지까지 함께 이해된 소통이어야 하기 때문입니다.

예를 들어 AI가 이렇게 말해줄 수 있습니다.

“피드백을 반영해 CTA를 더 잘 보이도록 수정하겠습니다.”

겉으로는 그럴듯 하지만 실제 문제는 CTA 크기가 아닐 수도 있습니다. CTA 이전의 정보 흐름이 문제일 수도 있고, 사용자가 행동해야 할 이유를 이해하지 못한 상태일 수도 있습니다. 혹은 팀 내부에서 “직관적”이라는 말의 기준이 서로 달랐을 수도 있습니다. 이런 상황에서 필요한 AI는 문장을 대신 써주는 AI가 아닐 것입니다. 디자이너가 어떤 기준으로 문제를 보고 있는지 이해한 뒤, 그 판단을 바탕으로 소통을 도와주는 AI. 이는 대행이 아니라 맥락을 반영한 보조에 가까워야 합니다.

브리프는 목적지가 아니라 판단 맥락이 정리된 결과물입니다

D:bo를 만들면서 한동안 브리프를 중심으로 생각했습니다.

피드백을 입력하면 브리프가 만들어지고, 이를 바탕으로 실행할 일이 정리되는 흐름을 만들고 싶었습니다. 그런데 다시 생각해보면 그것이 목적지가 아니었습니다. 브리프는 결과물에 가깝습니다. 디자이너가 받은 피드백, 프로젝트의 목표, 팀의 우선순위, 사용자의 문제, 이전에 했던 판단이 잠시 한곳에 정리된 결과물입니다. 지금은 제품 초기라 브리프 생성이 하나의 진입점처럼 보일 수 있었습니다. 사용자가 피드백을 넣고, D:bo가 그것을 브리프로 정리하는 방식이 가장 이해하기 쉬운 첫 경험이기 때문입니다. 하지만 장기적으로는 브리프가 사용자가 매번 따로 요청해서 만드는 문서일 필요는 없다고 생각합니다.

회의 메모를 남기다가 자연스럽게 브리프가 생길 수 있습니다.

Figma 코멘트를 해석하다가도 브리프가 만들어질 수 있습니다.

작업을 진행하는 중간에 판단 기준이 정리되면서 브리프가 갱신될 수도 있습니다.

리포트와 회고를 통해 다음 브리프의 기준이 다시 만들어질 수 있습니다.

즉, 브리프는 시작점일 수 있지만 목적은 아니게 되는 것입니다.

중요한 것은 브리프라는 문서 자체가 아니라, 디자이너의 판단 맥락이 끊기지 않고 다음 행동으로 이어지는 구조입니다.

개인 페르소나는 단순 분류가 아니라 판단 기준을 읽기 위한 장치입니다

최근 D:bo에서 다시 보고 있는 것은 개인 페르소나입니다.

여기서 말하는 페르소나는 성격을 분류하기 위한 것이 아닙니다. 이 디자이너는 꼼꼼한 타입이고, 감각적인 타입이다. 이런 식의 단순한 성향 분석을 만들고 싶은 것은 아닙니다. 오히려 알고 싶은 것은 업무 안에서 반복되는 판단의 기준입니다.

이 디자이너는 피드백을 받을 때 무엇을 먼저 확인하는가

사용자 흐름을 먼저 보는가, 정보 구조를 먼저 보는가, 팀의 의사결정 기준을 먼저 보는가

어떤 상황에서 질문을 더 많이 하는가

어떤 종류의 피드백을 바로 실행으로 옮기고, 어떤 피드백은 먼저 확인하려 하는가

팀에 공유할 때 어떤 방식으로 설명하는가

반복해서 어려워하는 소통은 무엇인가

이런 것들이 쌓이면 그 사람의 업무 맥락이 됩니다. 

AI가 디자이너의 일을 도우려면 이 맥락을 이해해야 한다고 생각합니다. 그래야 같은 피드백을 받아도 그 디자이너에게 맞는 방식으로 정리할 수 있습니다. 어떤 사람에게는 사용자 흐름을 먼저 묻는 것이 도움이 될 수 있고, 어떤 사람에게는 팀 공유 문장을 먼저 정리하는 것이 필요할 수 있습니다. 또 어떤 사람에게는 이전 결정과 지금 피드백의 연결을 보여주는 것이 더 중요할 수 있습니다. 개인 페르소나는 이런 차이를 읽기 위한 장치에 가깝습니다. AI가 모든 디자이너에게 같은 방식으로 답하는 것이 아니라, 각자의 판단 맥락에 맞춰 일을 도울 수 있도록 만드는 기반입니다.

디자이너에게 필요한 것은 범용 비서가 아닐지도 모릅니다

요즘 많은 AI 제품이 비서처럼 소개됩니다.

대신 정리해주고, 써주고, 찾아주고, 실행해주는 방식은 물론 편리합니다. 하지만 디자인 업무에서는 조심해야 할 부분도 있습니다. 디자이너의 소통을 대신하는 AI가 단순한 범용 비서처럼 보이면, 디자인 의사결정의 미묘한 맥락을 놓칠 수 있습니다.

디자인 피드백은 단순 요청이 아닐 때가 많습니다. “깔끔하게 해주세요”라는 말 안에는 브랜드 톤의 문제, 정보 밀도의 문제, 팀 내부 취향의 문제, 사용자의 이해 문제까지 함께 섞일 수 있습니다. “사용자가 헷갈릴 것 같아요”라는 말도 마찬가지입니다. 실제 사용성 문제인지, 설명이 부족한 문제인지, 팀의 기대와 화면이 어긋난 문제인지 구분해야 합니다. 

이 피드백을 어떤 문제로 볼지

어떤 기준으로 판단해야 할지

팀에 어떤 수준으로 설명해야 할지

다음 작업으로 무엇을 넘겨야 할지

디자인 의사결정 맥락을 이해하여 이런 질문을 함께 다룰 수 있어야 합니다.

D:bo가 다시 보고 있는 코어

D:bo의 코어를 다시 생각해보면, 브리프를 잘 만드는 것만이 핵심은 아니었습니다.

브리프는 중요한 결과물이지만, 그것만으로 D:bo를 설명하기에는 부족합니다. D:bo가 풀고 싶은 문제는 조금 더 넓습니다. 디자이너가 창작에 집중할 수 있도록 창작 바깥에서 반복되는 커뮤니케이션 부담을 줄이는 것. 이 과정은 디자인을 더 잘하기 위해 필요하지만, 동시에 디자이너의 시간을 많이 가져갑니다.

단순히 대신 처리하는 비서가 되고 싶은 것은 아닙니다. 디자이너의 판단 맥락을 이해하고, 그 맥락 안에서 정리와 공유, 보고와 회고가 자연스럽게 이어지도록 돕고 싶습니다. 그래서 지금 D:bo에서 보고 있는 개인 페르소나를 통해 이어나갈 방법을 고민하고 있습니다. 디자이너마다 다른 판단 방식과 소통 방식을 이해해야, 진짜로 그 사람의 일을 도울 수 있다고 생각하기 때문입니다.

AI 동료가 되려면 먼저 그 사람의 일하는 방식을 알아야 합니다

AI가 디자이너의 동료처럼 일하려면 무엇이 필요할까요?

좋은 문장을 만들고 파일을 읽는 능력과 피드백을 요약하고, 작업을 나누고, 리포트를 정리하는 능력도 필요합니다. 하지만 그보다 먼저 필요한 것은 그 사람의 일하는 방식을 이해하는 일일 수 있습니다. 어떤 기준으로 판단하고, 어떤 상황에서 막히는지, 또 어떤 피드백을 자주 받고, 그것을 어떤 방식으로 해석하는지 정보를 모른 채 도와주는 AI는 편리할 수는 있어도 깊이 있게 맞춰지기는 어렵습니다.

AI가 진짜로 일을 돕는다는 것은 단순히 요청을 처리하는 것이 아닙니다. 그 사람이 일하는 맥락을 이해하고, 다음 판단과 소통을 더 쉽게 만들 수 있어야 합니다. D:bo가 만들고 싶은 방향도 여기에 가깝습니다. 디자이너의 일을 대신하는 AI가 아니라, 디자이너가 더 잘 판단하고 더 덜 소모되도록 옆에서 맥락을 이어주는 AI입니다.

지금까지 D:bo를 만들며 브리프, 실행보드, 리포트와 회고를 이야기해왔습니다. 다시 생각해보면 중요한 것은 각각의 기능이 아닌 디자이너의 판단 맥락이 끊기지 않고 이어지는 구조였습니다. 같은 피드백도 사람마다 다르게 해석하며 같은 결과물을 공유하더라도 팀에 설명해야 하는 방식은 달라집니다. AI가 디자이너의 일을 제대로 돕기 위해서는 이 차이를 이해해야 합니다. 한동안 개인 페르소나를 통해 이 판단 맥락을 더 잘 읽는 구조를 실험해보려 합니다. 브리프는 그 결과로 자연스럽게 만들어질 수 있고, 공유와 보고, 회고도 그 맥락 위에서 더 정확해질 수 있다고 생각합니다. 아직 완성된 답은 아니지만, 디자이너가 창작에 더 집중할 수 있도록 반복되는 해석과 소통의 부담을 줄이는 방향을 계속 실험해보겠습니다. 그 과정도 계속 기록해보겠습니다.

[D:bo 디보 보러 가기]