프로덕트 디자이너에서 프로덕트 빌더로

안녕하세요, 오픈패스(OPENPATH)입니다. AI가 분석도, 초안도 알아서 만들어주는 요즘, "그럼 나 혼자 어디까지 할 수 있지?" 하는 생각 한 번쯤 해보셨죠.

이번 인터뷰에서는 그 답을 직접 끝까지 확인해 본 분의 이야기를 들어보려고 해요. 오늘의집에서 '프로덕트 디자이너'에서 '프로덕트 빌더(Product Builder)'로 이름이 바뀐 파트를 이끌면서, 마이페이지 개편을 기획부터 디자인, 분석까지 혼자 완성해 본 이요한 님을 만났습니다.

Q. 먼저 자기소개 부탁드려요. 지금까지 어떤 일을 해오셨나요?

안녕하세요, 오늘의집에서 프로덕트 디자인 파트를 리드하고 있는 이요한입니다. 여러 회사를 거치며 프로덕트 디자이너로 일해왔고, 디자인 시스템을 처음부터 만들어 본 적도 있어요. 디자이너면서 스쿼드 리더를 겸하는 등, 직무 경계를 넘나드는 일을 계속 해왔던 것 같습니다.

그리고 최근, 저희 조직의 직무명이 '프로덕트 디자이너'에서 '프로덕트 빌더(Product Builder)'로 바뀌었습니다. 저는 지금 프로덕트 빌더 파트의 리더이자, 여전히 손을 놓지 않은 실무자로 일하고 있어요. 이 전환 이야기가 아마 이번 세션의 큰 축이 될 것 같습니다.

Q. 최근 조직의 직무명이 '프로덕트 빌더'로 바뀌었다고요. 요즘 팀은 어떤 고민을 하고 있나요?

크게 세 갈래로 고민하고 있어요.

첫째, 디자이너의 본질 역량입니다. 판단력, 문제 해결력, 커뮤니케이션 같은 것들이요. AI 시대에도 놓치면 안 되는 것들인데, "판단력이 중요하다"는 건 다들 알지만 "그래서 어떻게 올리느냐"는 완전히 다른 문제잖아요. 그래서 팀원들과 체크하는 지표(KR) 중 하나가 '유저를 얼마나 많이 만났는가'입니다. 유저를 직접 만나는 건 AI가 대신해 줄 수 없고, 오히려 디자이너의 강점이 더 커지는 영역이라고 보거든요.

둘째, 직무의 확장입니다. 직무명을 '프로덕트 빌더'로 바꾼 것도 이 고민의 결과예요. AI 덕분에 디자이너가 기획과 분석까지 할 수 있는 환경이 됐는데, 그럼 실제로 뭐가 더 필요하고 뭐가 부족한지를 팀원들에게 말로만 전할 게 아니라 리더인 제가 먼저 해보고 보여주는 게 맞다고 생각했습니다.

셋째, 조직 차원의 AI 혁신입니다. 개인이 각자 AI를 잘 쓰는 것과 조직 전체가 굴러가게 만드는 건 완전히 다른 문제더라고요. 그래서 제가 이끌던 디자인 시스템 팀 이름을 '디자인 AI 옵스(Design AI Ops)'로 바꿨습니다. 디자인 시스템의 목적이 일관성과 효율이었다면, AI 시대에는 그 목적을 이루는 도구가 꼭 디자인 시스템일 필요는 없다는 거죠. 시스템에 매몰되지 말고 생각을 넓히자는 일종의 선언이었습니다.

Q. 마이페이지 개편을 혼자 하셨다고 들었어요. 직접 해보니 어떠셨나요?

원래는 프로덕트 오너, 프로덕트 디자이너, 데이터 분석가, 개발자가 다 붙어야 하는 프로젝트였는데 조직 상황상 리소스가 붕 떠 있었어요. 그래서 CPO님께 "디자인도, 기획도, 분석도 제가 다 하겠습니다"라고 했습니다. 한 달에서 한 달 반쯤 걸렸고, 프론트엔드 개발자분 도움을 몇 번 받은 것 말고는 실무도 리서치도 혼자 했어요.

해보니 예전에 비해 현황 파악하고 데이터 분석하는 건 놀랄 만큼 쉬워졌습니다. 이렇게 쉬울 수가 없어요. 그런데 혼자 하니까 결정이 더 어렵더라고요. 의논할 사람이 없으니까요. 그래서 유저에게 빠르게 설문을 돌리고, 동료들한테 계속 물어봤습니다.

문제는 그다음이었어요. 유저 의견도, 팀 안팎 의견도 다 반영하니 페이지가 엄청 길어졌고, 결국 뺄 것을 다시 골라내야 했습니다. 그런데 빼는 결정이 오히려 더 어렵거든요. 막상 덜어내고 나니 임팩트가 더 커진 것들도 나왔고요. 오전에는 PO로, 오후에는 PD로 인격을 나눠서 일했던 것도 재미있는 경험이었습니다.

리텐션이나 광고 쪽 지표도 좋아졌지만, 팀에 공유한 가장 큰 레슨런은 숫자가 아니었어요. "병목은 분석이 아니라 결정이었다." 이 한 문장입니다.

Q. 디자인 시스템 팀 이름을 '디자인 AI 옵스'로 바꾸셨어요. 왜 바꾸신 건가요?

솔직히 말하면 실패담에서 출발했습니다.

처음에는 AI 플러그인이나 스킬 같은 걸 열심히 만들었는데 아무도 안 썼어요. 사실상 'AI 쓰레기'를 찍어내고 있던 거죠. 그래서 제가 전부 그만두자고 했습니다. 각자의 효율을 조금 올려주는 공통 도구는 만들어봐야 남는 게 별로 없더라고요. 각자 손에 맞는 걸 알아서 쓰는 게 더 빠르니까요.

대신 기준을 다시 세웠습니다. 내 결과물이 다른 직무로 넘어가는 '전환 지점'을 도와야 효율이 생긴다. 기획자의 PRD가 디자인으로, 디자인 프로토타입이 개발로 넘어가는 지점이요. 그 기준으로 팀의 비전과 목표를 다시 썼습니다.

그렇게 만든 게 'LOOM(룸)'입니다. 디자인 시스템 페이지가 아니라, 우리 원칙을 바탕으로 비디자이너도 디자인할 수 있게 해주는 환경 세팅 사이트예요. 스크린, 컴포넌트, 시스템, 플로우가 다 모여 있고, 피그마에 있던 내용을 리액트 파일로 마스터 페이지화해서 관리합니다. 어떤 컴포넌트가 어느 화면에 쓰이는지 AI가 매핑해서 일관성을 만들어내고요.

비디자이너한테 시스템만 던져주면 총만 쥐여준 셈이에요. 어떻게 싸워야 하는지는 모르니까요. 그래서 원칙과 맥락까지 같이 정리해 뒀습니다.

여기서도 중간에 방향을 한 번 틀었어요. 1차 타겟은 PO였는데, AI가 디자인의 마지막 20%를 해결해 주지 못해서 결국 디자이너에게 요청이 돌아오더라고요. 디자이너 리소스가 줄지 않으니 실패였죠. 그래서 한 달쯤 전에 타겟을 프론트엔드 개발자로 바꿨고, 디자이너의 결과물을 프론트엔드 개발자에게 넘기는 비용이 두 배 이상 줄어드는 걸 확인했습니다. 지금은 이 사례를 전 조직에 알리면서 비슷한 케이스를 더 찾고 있습니다.

Q. AI를 실무에 어떻게 쓰고 계세요? 실제로 효과를 본 것과 기대에 못 미친 것이 궁금해요.

잘 맞았던 건 현황 파악과 데이터 분석입니다. 예전에 PO 역할을 겸했을 때랑 비교하면 차원이 다르게 쉬워졌어요. 덕분에 디자이너 혼자 기획하고 분석하고 디자인하는 게 현실적으로 가능해졌습니다. 팀 공유용 발표 자료도 AI로 10분 만에 돌려서 만들 정도라, 정리하고 요약하는 일은 거의 다 맡기고 있어요.

기대에 못 미친 건 두 가지입니다. 하나는 앞서 말한 '개인 효율화용 공통 도구'예요. 플러그인이나 스킬을 만들어 배포해도 결국 아무도 안 씁니다. 다른 하나는 디자인 결과물의 완성도예요. AI가 60~80%까지는 만들어 주는데 마지막 20%가 해결이 안 돼요. 그 20% 때문에 결국 디자이너를 다시 찾게 되고, 그러면 예전에 와이어프레임 받아서 디자인하던 거랑 다를 게 없어집니다.

그래서 저는 'AI가 뭘 못 하는가'를 확인하는 일이 도구를 만드는 것만큼 중요하다고 생각하게 됐습니다.

Q. AI 시대에 디자이너가 길러야 할 역량, 딱 하나만 꼽는다면요?

결정력(판단력)입니다. 분석은 이제 AI가 해줍니다. 파악도 쉽고, 만드는 것도 빨라졌어요. 그런데 뭘 넣고 뭘 뺄지, 어느 쪽으로 틀지는 여전히 사람이 정해야 하고, 오히려 혼자 할 수 있는 범위가 넓어질수록 결정할 일은 더 많아집니다. 분석과 제작이 쉬워질수록 결정의 무게만 오롯이 남더라고요.

그래서 요즘도 이 고민을 계속합니다. 결정하는 힘은 어떻게 길러지는가. 특히 주니어들의 판단력을 어떻게 빨리 끌어올릴 수 있는가. 레퍼런스를 많이 보면 되는 건지, 관점의 프레임을 줘서 그 안에서 판단을 훈련시켜야 하는 건지. 정답이 있다기보다 팀원들과 같이 실험하며 찾아가는 중이에요.

그리고 좋은 결정의 재료는 결국 유저를 직접 만나는 데서 나옵니다. AI가 대신해 줄 수 없고, 디자이너가 제일 잘하는 일이기도 하고요.

하나 더 솔직히 말씀드리면, 지금 제 생각이 1년 뒤에는 달라질 수 있다는 긴장감도 늘 갖고 있습니다. 그래서 결론보다는 과정과 의사결정의 기록을 남기려고 해요.

Q. 같은 고민을 하는 주니어 디자이너에게, 내일부터 바로 해볼 수 있는 일 하나를 권한다면요?

작은 거 하나라도 기획부터 분석까지 혼자 끝까지 해보세요. 화면 하나, 기능 하나여도 좋습니다.

남이 써준 요구사항을 받는 대신 직접 문제를 정의하고, AI로 데이터를 분석하고, 만들고, 유저한테 직접 물어보는 것까지요. 해보면 내가 어디가 약한지 정확히 드러나고, '결정의 연습'이 시작됩니다.

저도 리더지만 이걸 먼저 해 보이니 팀의 반응과 신뢰가 달라졌어요. 직무의 확장은 선언이 아니라 한 번의 완성에서 시작된다고 생각합니다.

Q. 마지막으로, OPEN SQUARE에서 어떤 이야기를 풀어주실 예정인가요?

가제는 "프로덕트 디자이너에서 프로덕트 빌더로"입니다. 두 개의 축으로 준비하고 있어요.

하나는 개인이 임팩트를 내는 이야기입니다. 마이페이지 개편을 기획·디자인·분석까지 혼자 완성하며 얻은 레슨런(Lesson & Learn)이요. 뭐가 쉬워졌고 뭐가 여전히 어려운지, 빌더에게 필요한 역량이 뭔지를 구체적인 사례로 말씀드릴 겁니다.

다른 하나는 조직에 임팩트를 내는 이야기입니다. 디자인 시스템 팀을 '디자인 AI 옵스'로 바꾸고 'LOOM'을 만들어 온 과정이요. 성공 사례 자랑이 아니라, AI 도구를 만들었다가 아무도 안 써서 전부 멈췄던 실패, 타겟을 PO에서 프론트엔드 개발자로 확장했던 과정, 그 과정에서 *ROI를 어떻게 높였는지를 이야기로 풀어보려고 합니다.