안녕하세요, 오늘의집 프로덕트 디자이너, 디어(Deeer) 입니다.
인테리어를 찾다 검색창 앞에서 멈춰본 적 있으신가요? 원하는 느낌은 분명한데, 어떤 단어를 검색해야 할지조차 모르겠고 무엇부터 눌러봐야 할지도 막막한 순간이요. 저희도 유저 인터뷰에서 비슷한 장면을 자주 마주했습니다. 그리고 이 문제를 제대로 풀려면 Figma 화면만으로는 부족하다는 걸 깨달았습니다. 유저가 실제 데이터를 탐색하는 순간의 반응을 보려면, 진짜로 동작하는 무언가가 필요했거든요. 그래서 PO(Product Owner)·PD(Product Designer)·DA(Data Analyst)가 한 팀이 되어 직접 만들기로 했어요. 그렇게 세 명이 AI 코딩으로 프로토타입을 구축하고, 기획부터 배포·유저 테스트까지 전 과정을 함께 주도하며 100명에게 검증했습니다. 엔지니어 없이, 딱 2주 만에요.
이번 글에서는 '될 것 같다'는 막연한 가설이 '반드시 만들어야 한다'는 확신이 되기까지의 여정을 소개합니다.
“뭘 찾아야 할지 모르겠어요”
오늘의집에는 수천만 개의 인테리어 사진이 있습니다. 그런데 유저 인터뷰를 하다 보면 비슷한 이야기가 반복해서 들립니다.
💬 “레퍼런스를 찾아봐야 하는데, 인테리어 용어를 모르겠어요.”
💬 ”내가 무슨 스타일을 좋아하는지 몰라서 찾아보기가 어려워요.”
검색창과 필터가 있어도, 유저는 탐색의 시작점에서 막막함을 느끼곤 했습니다. 저희가 풀고자 했던 진짜 문제는 ‘검색어를 몰라서 못 찾는 것’이 아니었어요. 무엇을 찾아야 할지조차 모르는 상태가 더 본질적인 문제였죠. 그래서 유저에게 탐색의 방향 자체를 제안해 주는 경험이 필요하다고 판단했고, 그렇게 ‘Context Builder’ 프로젝트를 시작했습니다.
Figma를 넘어 코드를 선택한 이유
처음 Context Builder 프로토타입을 구상할 때 가장 먼저 떠올린 건 Figma Make*였어요. 자연어 프롬프트만으로 인터랙티브한 화면을 빠르게 구성할 수 있으니, 디자이너에게는 가장 자연스러운 선택이었어요.
하지만 Context Builder의 핵심인 '추천 맥락 칩을 선택하거나 자연어를 직접 입력하면 AI가 맥락을 읽어 다음 탐색을 제안하는 인터랙션'을 구현하기엔 한계가 있었습니다. 유저가 어떤 검색어를 입력할지 예측할 수 없는 만큼, 정적인 화면만으로는 그 가치를 충분히 확인하기 어려웠거든요. 특히 이번 검증을 위해 전략적으로 구성한 약 10만 개의 콘텐츠 풀(Pool)을 실시간으로 불러와 LLM과 연동하고, 그 결과를 화면에 안정적으로 보여주기에는 Figma 환경의 메모리와 성능만으로는 무리가 있었습니다.
성능 문제도 결정적인 이유 중 하나였어요. 이미지가 핵심인 인테리어 콘텐츠 특성상, Figma 프로토타입은 스크롤이 길어지면 버벅거리거나 튕기는 경우가 잦았습니다. 고품질 프로토타입이 필요한 이유는 단순히 완성도 때문이 아닙니다. 유저가 완전히 몰입해야만 '진짜 반응'을 얻을 수 있고, 그래야 의미 있는 판단을 내릴 수 있기 때문입니다.
결국 저희는 Google AI Studio에서 초기 컨셉 코드를 생성한 뒤, 이를 Cursor*로 이어받아 수정하는 방식을 선택했어요. 코드가 로컬에 있으니 실제 LLM API와 약 10만 개의 콘텐츠 데이터를 더 유연하게 연결할 수 있었습니다.
*Figma Make : Figma의 AI 프로토타이핑 툴로, 자연어 프롬프트로 인터랙티브한 프로토타입을 빠르게 제작할 수 있어요. 다만 대규모 데이터 핸들링과 이미지 중심의 대량 콘텐츠 렌더링에는 제약이 있어요.
*Cursor : AI가 코드를 함께 작성해 주는 개발 툴이에요. 자연어로 원하는 기능을 설명하면 코드를 생성해 줘요.
팀의 나침반이 된 1-pager와 역할 분담
이렇게 만들어진 PoC(Proof of Concept)를 바탕으로, 엔지니어링 리소스 투입 없이 PO, PD, DA는 각자의 전문성을 발휘해 2주 만에 세 차례의 검증을 완료했습니다.
- PO - 아이디어 발제 및 1-pager 기획, Google AI Studio로 초기 컨셉 코드 생성
- PD - 핵심 화면 설계, Cursor로 프로토타입 이터레이션, UT 설계 및 분석
- DA - 콘텐츠 데이터 가공, AI 검색 구현, 로그 수집 구조 구축
프로젝트의 중심에는 PO 블레이크님이 하루 만에 써 내려간 1-pager가 있었습니다. 워낙 빠르게 진행되다 보니 자칫 방향을 잃기 쉬운 상황이었지만, "우리가 무엇을, 왜 만드는가"라는 본질을 이 문서 하나로 계속 정렬할 수 있었죠.
DA 지니님은 UT용 프로토타입이 만들어지기 전 기술적 가능성을 먼저 검증했습니다. "느낌만 던져도 콘텐츠를 찾아준다"는 것이 실제로 구현 가능한지 팀 안에서 아무도 확신하지 못하던 시점이었어요. 지니님은 10만 개의 인테리어 콘텐츠를 AI가 이해할 수 있는 형태로 가공하고, 검색 결과를 바로 볼 수 있는 데모를 빠르게 만들어 이해관계자 7명에게 직접 써보게 했습니다. 이 과정을 통해 "충분히 정확한 것 같다"는 공감대가 형성되었고, 본격적인 UT용 프로토타입 작업으로 넘어갔습니다.
무엇보다 피드백 루프가 아주 빨랐던 점이 컸어요. GitHub*와 Vercel* 조합 덕분에 코드를 수정하면 팀원들이 실시간으로 결과물을 확인할 수 있었습니다. 지인들에게도 URL 하나만 보내면 바로 써볼 수 있었고요. 앱을 설치하거나 계정을 만들 필요 없이 링크만 열면 됐기 때문에, 팀 외부에서도 자연스럽게 피드백을 모을 수 있었습니다.
*GitHub : 코드를 저장하고 관리하며, 변경 이력을 함께 기록하는 협업 플랫폼
*Vercel : 코드를 올리면 자동으로 웹 서비스로 배포해 주는 플랫폼
도구는 AI가, 판단은 디자이너가
저는 코딩을 업으로 삼는 사람은 아니에요. 그런데도 이번 프로젝트에서 Cursor와 Vercel을 활용해 실제로 동작하는 웹 프로토타입을 직접 완성할 수 있었습니다. AI 툴을 쓸 수 있다는 것과, 그걸 제대로 활용하는 건 전혀 다른 이야기였어요. 어떤 화면을 만들어야 하는지, 무엇을 검증해야 하는지, 그리고 어디까지 만들면 충분한지를 결정하는 주체는 AI가 아니라 결국 디자이너였거든요. 그 판단을 떠받친 건 그동안 쌓아온 실무 경험이었습니다.
디자이너 입장에서 가장 좋았던 점은 화면을 일일이 그리지 않고도 제품의 본질에 더 집중할 수 있었다는 점이었어요. 실시간 데이터가 LLM을 통해 바로 연결되다 보니, 정말 중요한 판단에만 리소스를 쏟을 수 있었거든요.
사실 Figma 화면만으로는 알 수 없는 판단들이 있었어요. 유저가 탐색을 시작할 때 어떤 칩이 먼저 방향을 제안해야 하는지, Placeholder 문구가 자연어 입력의 허들을 얼마나 낮춰줘야 하는지, 맥락이 없는 첫 진입과 이미 탐색 중인 상태에서 Suggestion이 어떻게 달라져야 하는지 같은 것들이요. 이런 일은 단순한 UI 설계라기보다, 유저가 실제로 사용할 때의 경험을 예측하고 기준을 정하는 일에 더 가까웠습니다.
AI 툴이 코드를 만들어주더라도 어떤 경험을 만들어야 하는지를 결정하고, AI가 생성한 결과물이 그 기준에 맞는지 검증하고, 어긋났을 때 다시 정의하는 것. 그게 이 과정에서 디자이너가 맡은 핵심 역할이었습니다. 기술이 아무리 발전해도 “이게 유저에게 정말 필요한 경험인가?”를 묻고 답하는 주체는 결국 사람이니까요.
Claude와 Cursor의 루프
구현 방식은 아주 단순했어요. 자연어로 화면 구조를 설명하면 Cursor가 코드를 만들고, GitHub에 올리면 Vercel이 이를 자동으로 배포해 주는 방식이었죠. 이 과정에서 작업의 성격에 따라 두 툴의 역할도 자연스럽게 나뉘었습니다.
복잡한 인터랙션이나 구조 변경처럼 한 번에 굵직한 단위를 맡겨야 할 때는 Claude(Claude Code)를 활용했어요. Claude에게 먼저 의도를 설명하고 그 내용을 Cursor가 이해하기 좋은 프롬프트로 바꿔 달라고 요청하거나, 작업이 끝난 뒤 Git 푸시(Git Push)까지 한 번에 처리하는 식이었죠. 특히 Claude가 프로토타입 URL에 직접 접속해 현재 화면 상태와 코드 구조를 파악한 뒤 수정 지시를 내리는 ‘AI 툴 간의 연결 루프’는 정확한 구현에 큰 도움이 됐습니다.
반면 Cursor는 화면을 실시간으로 보면서 조금씩 수정하고 바로 확인하는 작업에 더 잘 맞았어요. 특히 간격값이나 텍스트 크기 같은 단순한 수치 조정은 Cursor의 Visual Editor 패널에서 직접 처리했습니다. 요소를 클릭하면 사이드바에 Padding, Dimensions, Font 같은 속성이 나타나고, 슬라이더로 조정한 값이 즉시 화면에 반영되거든요. 복잡한 프롬프트 입력이나 로딩을 거치지 않고도 Figma처럼 바로 손볼 수 있어서 세밀한 디자인 조정에는 오히려 이 방식이 더 빠르고 직관적이었습니다.
세 번의 이터레이션 : 비대면 UT부터 현장 검증, 로그 분석까지
PoC는 한 번으로 끝나지 않았어요. 본격적인 유저 검증에 들어가기 전, 사내 구성원을 대상으로 먼저 프로토타입을 공개해 약 260건의 탐색 데이터를 확보했고 이를 바탕으로 UT 직전 마지막 수정까지 반영했습니다. 이후에는 총 세 단계에 걸쳐 디자인을 다듬고, 각 단계에서 얻은 인사이트를 다음 검증에 다시 반영해 나갔어요.
✔️ 1단계 - 비대면 원격 UT
실제 제품처럼 기민하게 반응하는 프로토타입을 통해, 유저가 얼마나 자연스럽게 몰입하는지 관찰하는 자리였어요. 한 참여자가 칩을 눌러보며 남긴 한마디가 기억에 남습니다.
💬 “이거 너무 좋은 것 같은데요? 되게 편하네요. 머릿속에만 있던 건데, 그게 이렇게 나오니까요.”
수치로 먼저 증명되기 전에, 사용자의 반응으로 먼저 감지되는 신호들이 있어요. 현장에서는 그런 순간이 무엇보다 중요하거든요.
✔️ 2단계 - 오메이커스 설문 + 로그 분석
이후에는 오늘의집이 운영하는 디스코드 기반 유저 리서치 패널 오메이커스(활동 멤버 약 100명)에 URL을 공유하고, 정성적 피드백과 함께 실시간 사용 로그를 확보했어요. 유저가 어떤 검색어를 입력하고 어떤 칩을 클릭하는지 분석하면서, UT만으로는 확인하기 어려운 실제 사용 패턴을 데이터로 볼 수 있었습니다.
✔️ 3단계 — O User Day* 현장 UT
앞선 피드백들이 반영된 화면으로 유저를 직접 만나는 자리였습니다. 가장 가까이에서 유저를 관찰하며 피드백을 수집했고, 이 단계에서 제품의 방향을 바꾸는 결정적인 인사이트가 도출되었습니다.
*O User Day : 오늘의집이 직접 유저를 초대해 제품을 함께 사용해보는 현장 리서치 세션
‘대화’보다 ‘제안’이 필요했던 이유
처음에는 자연어 검색을 유도하는 것이 핵심이라고 생각했어요. 그런데 실제 유저들의 반응은 달랐습니다. 직접 타이핑하는 것보다 ‘미리 제안된 칩’을 누르는 방식을 훨씬 자연스럽게 받아들였어요. 심지어 채팅창 형식의 UI에 거부감을 느끼는 경우도 있었습니다.
생각해 보면 당연한 반응이에요. 인테리어 탐색을 하러 들어온 사람에게 “무엇을 도와드릴까요?”라고 묻는 건, 오히려 또 하나의 허들을 만드는 일이니까요. 뭘 찾아야 할지 모르는 사람에게는 질문보다 제안이 더 필요합니다. O User Day 현장에서 유저의 목소리를 직접 들으며 이 사실을 확신할 수 있었어요.
💬 "그냥 보이는 칩을 누르게 되더라고요. 검색어를 어떻게 써야 잘 나올지 고민하는 게 귀찮았거든요.”
그래서 제품의 방향이 완전히 바뀌었습니다. 자연어 입력 유도에서 칩 기반의 Guided Navigation 강화로요. 실제 데이터가 흐르는 프로토타입이 아니었다면 유저의 진짜 반응을 끌어내지 못했을 것이고, 저희는 잘못된 방향으로 개발을 시작했을지도 모릅니다.
세 단계의 검증을 거쳐 나온 결과는 팀의 기대를 뛰어넘었습니다. 탐색 경험 만족도는 5점 만점에 4.0점, 기존 검색 방식 대비 75%의 유저가 Context Builder를 선호했습니다. 원하는 콘텐츠를 찾기까지 필요한 인터랙션은 평균 2.6번에 불과했고요. 이 구체적인 데이터는 “만들어볼 만하다”는 가설을 “반드시 만들어야 한다”는 확신으로 바꾸는 가장 강력한 근거가 되었습니다.
AI도 놓친 ’첫 번째 칩’의 비밀
물론 과정이 순탄하지만은 않았어요. 칩이 여러 개인데 유독 첫 번째 칩만 터치가 되지 않는 기묘한 버그가 발생했습니다. 프롬프트를 수정하고, 칩을 지웠다가 다시 추가해 봐도 좀처럼 해결되지 않았어요.
결국 프론트엔드 엔지니어에게 도움을 요청했고, 반나절 동안 붙잡고 있던 문제를 단 30분 만에 해결할 수 있었습니다. 원인은 칩 자체가 아니라, 그 위에 겹쳐 있던 탭 영역의 height 값이 과도하게 설정되면서 터치 영역을 덮고 있었던 것이었습니다. 문제는 칩이 아니라 전혀 다른 상위 요소에 있었던 거죠.
AI는 코드를 빠르게 만들어주지만, 화면 전체의 레이아웃 위계까지 완벽하게 파악하지는 못합니다. 이번 사례처럼 문제가 전혀 다른 상위 요소에 있을 경우, 원인을 정확히 짚어내기 어렵고요. 그래서 결정적인 순간에는 도메인 전문가의 개입이 필요하고, 언제 그 도움을 요청해야 하는지를 아는 것 역시 디자이너의 중요한 역량입니다.
완주하며 배운 것들
이번 PoC를 통해 디자이너가 아이디어 검증의 전 과정을 직접 완주할 수 있다는 확신을 얻었습니다. 과거에는 피드백을 받으면 Figma를 다시 그리고 프로토타입을 재연결해야 했지만, 지금은 코드에서 즉시 수정하고 배포하며 다음 검증으로 넘어갈 수 있습니다. 검증 가능한 형태로 만드는 속도가 10배는 빨라진 셈이죠.
AI 코딩 툴은 디자이너의 역할을 대체하는 게 아니에요. 오히려 디자이너가 할 수 있는 영역을 압도적으로 넓혀주는 도구입니다. 무엇을 만들지, 유저의 어떤 반응을 관찰할지에 대한 본질적인 판단은 여전히 디자이너의 몫이고, AI는 그 판단을 실행하는 속도를 폭발적으로 높여줄 뿐입니다.
Context Builder는 이제 더 큰 목표를 향해 나아갑니다. 칩 개인화와 탐색 데이터 축적 등 해결해야 할 과제들도 한층 더 분명해졌어요. '될 것 같다'는 기대감을 '반드시 만들어야 한다'는 확신으로 바꾼 만큼, 앞으로 더욱 밀도 있게 제품을 다듬어 나갈 계획입니다. 조만간 오늘의집에서 만나게 될 Context Builder의 새로운 탐색 경험을 기대해 주세요!
