엔지니어 없이 2주, 디자이너 셋이 100명을 검증한 방법

오늘의집의 디자이너 디어가 풀어 놓은 이야기인데, 좀 무서운 결말이에요. 처음에 잡았던 핵심 가설이 검증 후 통째로 뒤집혔거든요. 자연어 검색이 답인 줄 알았는데 아니었어요.

근데 그게 가능했던 건, 이 프로젝트가 Figma 화면이 아니라 진짜로 동작하는 프로토타입이었기 때문이었어요. 엔지니어 한 명도 안 들어왔고, PO·PD·DA 셋이 2주 만에 100명에게 검증을 끝냈습니다.

검색창 앞에서 멈추는 사람들

오늘의집에는 인테리어 사진이 수천만 장 있어요. 근데 유저 인터뷰에서 반복해서 들리는 말이 이거였대요.

"레퍼런스를 찾아봐야 하는데, 인테리어 용어를 모르겠어요."

"내가 무슨 스타일을 좋아하는지 몰라서 찾아보기가 어려워요."

진짜 문제는 '검색어를 몰라서 못 찾는 것'이 아니었어요. 무엇을 찾아야 할지조차 모르는 상태가 더 본질적이었거든요. 그래서 탐색의 방향 자체를 제안해 주는 경험이 필요하다고 판단해서 'Context Builder' 프로젝트가 시작된 거예요.

Figma를 포기한 이유

처음 떠올린 건 Figma Make였어요. 자연어 프롬프트로 인터랙티브한 화면을 빠르게 짤 수 있으니까. 디자이너에겐 가장 자연스러운 선택.

근데 Context Builder의 핵심이 'AI가 맥락 읽어서 다음 탐색을 제안하는 인터랙션'이었거든요. 유저가 어떤 검색어를 입력할지 예측 못 하니까, 정적인 화면만으론 가치를 확인하기 어려웠어요. 게다가 약 10만 개의 콘텐츠 풀을 실시간으로 LLM과 연동하기엔 Figma 환경의 메모리·성능이 안 됐고요.

성능도 결정적. 이미지가 핵심인 인테리어 콘텐츠 특성상 Figma 프로토타입은 스크롤 길어지면 버벅거리거나 튕겨요. 고품질 프로토타입이 필요한 이유는 완성도가 아니에요. 유저가 완전히 몰입해야 진짜 반응을 얻을 수 있고, 그래야 의미 있는 판단이 나오니까요.

결국 Google AI Studio로 초기 컨셉 코드 만들고, Cursor로 이어받아 수정하는 방식. 코드가 로컬에 있으니 LLM API와 10만 개 콘텐츠를 더 유연하게 연결할 수 있었거든요.

PO·PD·DA 셋이 한 일

엔지니어 없이 2주 만에 세 차례 검증. 역할 분담이 명확했습니다.

• PO 블레이크: 아이디어 발제, 1-pager 기획, Google AI Studio로 초기 컨셉 코드 생성
• PD 디어: 핵심 화면 설계, Cursor로 프로토타입 이터레이션, UT 설계와 분석
• DA 지니: 콘텐츠 데이터 가공, AI 검색 구현, 로그 수집 구조 구축

중심에 1-pager가 있었어요. PO가 하루 만에 써 내려간 한 장. "우리가 무엇을, 왜 만드는가"를 이 문서 하나로 계속 정렬했답니다. 빠르게 굴러가는 프로젝트에서 방향 잃지 않으려면 이런 게 진짜 나침반이 돼요.

DA 지니의 일이 좀 흥미로워요. UT용 프로토타입 만들기 전에 기술적 가능성부터 검증했거든요. "느낌만 던져도 콘텐츠를 찾아준다"는 게 실제로 가능한지, 그 시점엔 팀 내 누구도 확신 못 했어요. 지니가 10만 개 콘텐츠를 AI가 이해할 수 있는 형태로 가공하고, 검색 결과를 바로 볼 수 있는 데모를 빠르게 만들어서 이해관계자 7명에게 직접 써보게 했습니다. "충분히 정확한 것 같다"는 공감대가 생기고 나서야 본격 작업으로 넘어간 거예요.

피드백 루프도 빨랐어요. GitHub과 Vercel 조합 덕분에 코드 수정하면 팀원들이 실시간으로 결과물 확인. 지인들에게도 URL 하나만 보내면 바로 써볼 수 있었고요. 앱 설치나 계정 만들 필요 없이 링크만 열면 됐으니, 팀 외부에서도 자연스럽게 피드백이 모였답니다.

디자이너가 코딩 도구를 쓰는 진짜 의미

디어가 코딩을 업으로 하는 사람은 아니에요. 그런데도 Cursor와 Vercel로 실제 동작하는 웹 프로토타입을 직접 완성했습니다. AI 툴을 쓸 수 있다는 것과 제대로 활용한다는 건 다른 얘기인데요. 어떤 화면을 만들지, 무엇을 검증할지, 어디까지 만들면 충분한지를 결정하는 건 결국 디자이너였거든요. 그 판단을 떠받친 게 그동안 쌓아온 실무 경험이고요.

Figma 화면만으론 알 수 없는 판단들이 있어요.

• 유저가 탐색을 시작할 때 어떤 칩이 먼저 방향을 제안해야 하는지
• Placeholder 문구가 자연어 입력의 허들을 얼마나 낮춰줘야 하는지
• 맥락이 없는 첫 진입과 이미 탐색 중인 상태에서 Suggestion이 어떻게 달라져야 하는지

이런 일은 단순한 UI 설계가 아니에요. 유저가 실제로 사용할 때의 경험을 예측하고 기준을 정하는 일에 가깝죠.

Claude와 Cursor의 역할 분담

자연어로 화면 구조 설명 → Cursor가 코드 생성 → GitHub 푸시 → Vercel 자동 배포. 이게 기본 루프였어요.

작업 성격에 따라 두 툴 역할이 자연스럽게 갈렸습니다. 복잡한 인터랙션이나 구조 변경처럼 한 번에 굵직한 단위는 Claude(Claude Code). Claude한테 의도 설명하고 Cursor가 이해하기 좋은 프롬프트로 바꿔달라거나, 작업 끝나면 Git 푸시까지 한 번에 처리. 특히 Claude가 프로토타입 URL에 직접 접속해 현재 화면 상태와 코드 구조를 파악한 뒤 수정 지시를 내리는 'AI 툴 간의 연결 루프'가 정확한 구현에 큰 도움이 됐대요.

Cursor는 화면을 실시간으로 보면서 조금씩 수정하는 작업에 더 잘 맞았어요. 간격값이나 텍스트 크기 같은 단순 수치는 Cursor의 Visual Editor 패널에서 직접 처리. 요소 클릭하면 사이드바에 Padding, Dimensions, Font가 나오고 슬라이더로 조정한 값이 즉시 화면에 반영되거든요. 복잡한 프롬프트나 로딩 거치지 않고 Figma처럼 바로 손볼 수 있어서, 세밀한 조정엔 오히려 이쪽이 더 빠르고 직관적이었답니다.

세 단계 검증 — 결정적 한마디

PoC는 한 번이 아니었어요. 본격 검증 전에 사내 구성원 대상 프로토타입으로 약 260건 탐색 데이터 확보, UT 직전 마지막 수정까지 반영. 이후 세 단계.

1단계: 비대면 원격 UT. 진짜처럼 동작하는 프로토타입으로 몰입도 관찰. 한 참여자의 반응이 인상적이에요.

"이거 너무 좋은 것 같은데요? 되게 편하네요. 머릿속에만 있던 건데, 그게 이렇게 나오니까요."

수치로 증명되기 전에, 사용자의 반응으로 먼저 감지되는 신호가 있어요.

2단계: 오메이커스 설문 + 로그 분석. 오늘의집이 운영하는 디스코드 기반 유저 리서치 패널 약 100명에게 URL 공유. 정성적 피드백과 함께 실시간 사용 로그 확보. 어떤 검색어를 입력하고 어떤 칩을 클릭하는지 분석하면서, UT만으론 확인 어려운 실제 사용 패턴을 데이터로.

3단계: O User Day 현장 UT. 가장 가까이서 관찰. 여기서 제품 방향을 바꾸는 결정적 인사이트가 나왔어요.

자연어 입력이 답이 아니었어요

처음엔 자연어 검색을 유도하는 것이 핵심이라고 생각했어요. 그런데 실제 유저들 반응이 달랐습니다. 직접 타이핑하는 것보다 미리 제안된 칩을 누르는 방식을 훨씬 자연스럽게 받아들였거든요. 채팅창 형식의 UI에 거부감을 느끼는 경우도 있었고요.

생각해 보면 당연한 반응이에요. 인테리어 탐색을 하러 들어온 사람한테 "무엇을 도와드릴까요?"라고 묻는 건, 또 하나의 허들을 만드는 일이니까요. 뭘 찾아야 할지 모르는 사람에겐 질문보다 제안이 더 필요해요.

O User Day 현장에서 들은 한마디가 결정적이었습니다.

"그냥 보이는 칩을 누르게 되더라고요. 검색어를 어떻게 써야 잘 나올지 고민하는 게 귀찮았거든요."

제품 방향이 완전히 바뀌었어요. 자연어 입력 유도에서 칩 기반의 Guided Navigation 강화로요. 실제 데이터가 흐르는 프로토타입이 아니었다면 진짜 반응을 끌어내지 못했을 거고, 잘못된 방향으로 개발 시작했을지도 몰라요.

세 단계 검증 결과는 팀의 기대를 뛰어넘었어요. 탐색 경험 만족도 5점 만점에 4.0점, 기존 검색 방식 대비 75%의 유저가 Context Builder를 선호. 원하는 콘텐츠를 찾기까지 평균 인터랙션 2.6번. "만들어볼 만하다"는 가설을 "반드시 만들어야 한다"는 확신으로 바꾸는 강력한 근거였습니다.

AI도 못 짚는 버그

물론 순탄하지 않았어요. 칩이 여러 개인데 첫 번째 칩만 터치가 안 되는 기묘한 버그가 발생했거든요. 프롬프트 수정해도, 칩을 지웠다가 다시 추가해 봐도 해결 안 됐답니다.

결국 프론트엔드 엔지니어에게 도움 요청. 반나절 붙잡고 있던 문제를 30분 만에 해결. 원인은 칩 자체가 아니라, 그 위에 겹쳐 있던 탭 영역의 height 값이 과도하게 설정되면서 터치 영역을 덮고 있었던 거예요. 문제는 칩이 아니라 전혀 다른 상위 요소에 있었던 것.

AI는 코드를 빠르게 만들어주지만, 화면 전체의 레이아웃 위계까지 완벽하게 파악하진 못해요. 문제가 전혀 다른 상위 요소에 있을 때, 원인을 정확히 짚어내기 어렵거든요. 결정적인 순간에는 도메인 전문가의 개입이 필요하고, 언제 그 도움을 요청해야 하는지를 아는 것 역시 디자이너의 중요한 역량이에요.

검증 가능한 형태로 만드는 속도가 10배

이번 PoC로 디어가 얻은 확신은 이거예요. 디자이너가 아이디어 검증의 전 과정을 직접 완주할 수 있다는 것. 과거엔 피드백 받으면 Figma 다시 그리고 프로토타입 재연결해야 했는데, 지금은 코드에서 즉시 수정·배포하면서 다음 검증으로 넘어갈 수 있어요.

검증 가능한 형태로 만드는 속도가 10배 빨라진 셈이고요.

AI 코딩 툴이 디자이너의 역할을 대체하는 게 아니에요. 오히려 디자이너가 할 수 있는 영역을 압도적으로 넓혀주는 도구. 무엇을 만들지, 유저의 어떤 반응을 관찰할지에 대한 본질적 판단은 여전히 디자이너 몫이고, AI는 그 판단을 실행하는 속도를 폭발적으로 높여줄 뿐이에요.

Context Builder는 이제 칩 개인화와 탐색 데이터 축적 같은 더 큰 과제를 향해 갑니다. 조만간 오늘의집에서 만나게 될 텐데, 검증 단계에서 통째로 뒤집힌 가설이 어떤 모습으로 정착할지가 궁금해요.