[2026년 6월 15일] MVP 프로젝트 회고: 오늘의집 - 오!공간상담, 문제 정의만큼 어려웠던 협업 방식 설계

들어가며

이번 MVP 프로젝트에서 우리 팀은 오늘의집 기반의 오!공간상담을 기획했다.

오!공간상담은 사용자가 오늘의집에서 집들이 콘텐츠나 상품을 탐색한 뒤, 자신의 공간에 맞는 가구·소품 조합을 크리에이터에게 추천받고, 추천 결과를 장바구니까지 연결하는 비동기 큐레이션 상담 기능이다.

처음 이 아이디어를 떠올린 계기는 개인적인 경험이었다.

최근 이사를 준비하면서 방을 잘 꾸미고 싶다는 욕구가 있었다. 좋아하는 분위기, 이른바 ‘추구미’는 있었지만, 막상 내 방에서 어떻게 구현해야 할지는 막막했다. 오늘의집에는 예쁜 집들이 콘텐츠와 상품은 많았지만, “그래서 내 방에는 어떻게 적용해야 하지?”라는 질문에는 명확한 답을 얻기 어려웠다.

그 지점에서 아이디어가 시작됐다.

처음에는 단순히 “오늘의집에 상담 기능이 있으면 좋지 않을까?”에 가까웠다. 하지만 프로젝트를 진행하면서 점점 더 중요한 질문은 기능 자체가 아니라 다음이었다.

사용자는 오늘의집 안에서 상품과 콘텐츠를 충분히 탐색하고도, 왜 마지막 구매 결정을 내리지 못할까?

이번 회고는 오!공간상담이라는 MVP를 만들며 배운 두 가지에 대한 기록이다.

하나는 문제를 기능이 아니라 _사용자 흐름으로 다시 정의한 경험_이고,
다른 하나는 _좋은 협업 방식도 팀 안에서 작동하려면 설계와 설득이 필요하다는 경험_이다.

---

1. 처음의 문제: “방을 잘 꾸미고 싶은데, 어떻게 해야 할지 모르겠다”

처음 아이디어는 매우 직관적이었다.

방을 잘 꾸미고 싶다. 내 취향은 있다.
하지만 내 방 크기, 구조, 기존 가구, 예산 안에서 어떤 조합이 맞을지 모르겠다.

오늘의집에는 이미 많은 콘텐츠와 상품이 있다. 집들이 콘텐츠를 보면 영감을 얻을 수 있고, 상품 상세와 리뷰도 볼 수 있다. 3D·AI 인테리어 기능도 있다.

그런데도 사용자는 마지막 선택 앞에서 멈출 수 있다.

• 이 가구가 내 방 크기에 맞을까?
• 기존 가구와 어울릴까?
• 내가 원하는 분위기와 맞을까?
• 여러 후보 중 무엇을 골라야 할까?
• 괜히 샀다가 후회하지 않을까?

처음에는 이 문제를 “인테리어 상담이 필요하다” 정도로 생각했다. 하지만 PRD와 발표 대본을 작성하면서 문제를 더 좁혀야 했다.

사용자는 상품을 못 찾는 것이 아니었다. 이미 콘텐츠를 보고, 상품을 보고, 후보를 고른다.
문제는 그다음이었다.

상품을 찾은 이후, 내 공간에 맞는 선택인지 확신하지 못해 최종 구매 후보를 좁히지 못하는 것.

이렇게 문제를 다시 정의하자 오!공간상담의 역할도 달라졌다.

오!공간상담은 단순히 상담 기능을 추가하는 것이 아니라, 오늘의집 안에서 발생한 콘텐츠 탐색 → 상품 후보 발견 → 구매 직전 고민의 흐름을 크리에이터 상담과 장바구니까지 연결해 구매 후보 확정으로 이어지게 하는 MVP였다.

---

2. 사용자 설문은 기대와 달랐다

프로젝트 중간에 사용자 설문을 진행했다.

결과를 보면 가구·소품 구매를 미루는 문제 자체는 확인됐다. 유효 응답자 28명 전원이 찜하거나 장바구니에 담아둔 상품을 바로 구매하지 않고 미룬 경험이 있었고, 구매 후 자신의 공간에 맞지 않아 후회한 응답자도 많았다.

하지만 오!공간상담이라는 해결책에 대한 반응은 기대보다 낮았다.

특히 1차 타겟으로 설정한 1인 가구의 반응이 약했다. 1인 가구 응답자 9명 중 8명이 현재 형태의 오!공간상담을 신청하지 않았을 것 같다고 답했다.

처음 든 생각은 “망했다”보다는** “표본을 잘못 잡았다”**에 가까웠다.

오!공간상담은 모든 사용자에게 필요한 기능이 아닐 수 있다. 인테리어에 큰 갈증이 없는 평균 사용자에게는 사진과 정보를 입력하면서까지 1:1 상담을 신청하는 일이 필요 이상으로 무겁게 느껴질 수 있다.

즉, 설문 결과는 “수요가 없다”라기보다 다음에 가까웠다.

문제는 있지만, 우리가 물어본 대상이 너무 넓었다.
이 기능은 문제 강도가 높은 사용자를 대상으로 다시 검증해야 한다.

예를 들어 최근 이사했거나, 장바구니에 상품을 담아두고 오래 고민하거나, 가구 구매 후 반품·후회를 경험한 사용자라면 반응이 달랐을 수 있다.

그래서 사용자 설문은 발표와 PRD의 핵심 근거로 사용하지 않았다. 불리한 데이터를 숨기려는 의도가 아니라, 설문이 MVP 수요를 입증하기에는 표본 한계가 있다고 판단했기 때문이다.

대신 발표와 PRD에서는 오늘의집 내부 VOC, 3D·AI 인테리어 관련 이용 증가 데이터, 외부 홈스타일링 시장 사례를 중심 근거로 사용했다.

그리고 사용자 설문은 내부 학습으로 남겼다.

평균 사용자는 상담에 시큰둥했지만, 문제 강도가 높은 세그먼트는 별도로 존재할 수 있다.
따라서 MVP에서는 실제 수요와 크리에이터 상담의 수용도를 추가 검증해야 한다.

이번 경험을 통해 데이터는 무조건 쓰는 것이 아니라, 그 데이터가 무엇을 말할 수 있고 무엇을 말할 수 없는지 구분해야 한다는 것을 배웠다.

---

4. 내가 맡았던 역할

이번 프로젝트에서 팀원들이 기능 명세서를 작성해보고싶다고 하여 나는 자연스럽게 문제 정의와 문서 구조를 잡는 역할을 많이 맡았다.

구체적으로는 다음 일을 했다.

• MVP 방향성 제시
• PRD 작성
• 발표 스크립트 작성
• 발표 진행
• 회의록 작성 방식 도입
• 티켓 관리 방식 도입
• 문제 정의와 발표 흐름 정리
• 사용자 설문 결과의 사용 여부 판단
• 크리에이터 운영 정책 방향 정리

특히 PRD와 발표 스크립트를 짧은 시간 안에 함께 작성하면서, 우리가 해결하고자 하는 문제를 더 선명하게 말하는 과정에 많은 시간을 썼다.

처음에는 발표 자료를 채워야 한다는 마음이 컸다. 하지만 후반으로 갈수록 계속 한 질문으로 돌아왔다.

그래서 이 기능은 오늘의집에서 왜 필요한가?

이 질문에 답하기 위해 문제, 시장, 타겟, 솔루션, KPI, 운영 정책을 계속 다시 연결했다.

힘들었지만, 이 과정에서 PM이 해야 하는 일이 단순히 문서를 만드는 것이 아니라 흩어진 근거와 의견을 하나의 판단 흐름으로 정리하는 일이라는 것을 많이 느꼈다.

---

5. 협업 방식도 설계해야 한다는 것을 배웠다

이번 프로젝트에서 가장 크게 느낀 것은, 실무에서 당연하게 여겼던 협업 방식도 팀에 따라서는 다시 설득해야 하는 대상이 된다는 점이었다.

회사에서는 회의록을 남기고, 티켓을 나누고, 담당자를 지정하고, QA 체크리스트를 상세하게 작성하는 것이 자연스러운 일에 가까웠다. 하지만 이번 프로젝트에서는 이런 방식이 팀의 기본값은 아니었다.

처음에는 회의록을 쓰지 않거나, 각자 논의한 내용을 정리하지 않는 경우가 있었다. (정말 많이~ 자주~) 내 입장에서는 나중에 결정 근거가 흐려지고, 같은 이야기를 반복하게 될 것이 보였다. 그래서 회의록과 티켓을 도입하고 싶었다.

하지만 나는 팀의 상사도 아니고, 공식적으로 프로세스를 강제할 수 있는 위치도 아니었다. 특히 팀원들 사이에 이미 형성된 관계가 있는 상황에서, 내가 협업 방식을 제안하는 것이 상대에게는 강제처럼 느껴질 수도 있겠다고 생각했다.

그래서 이 과정이 생각보다 많이 어려웠다.

결국 처음부터 완벽하게 설득하기보다 “일단 써보자”는 방식으로 회의록과 티켓을 도입했다. 실제로 기록을 남기기 시작하자 회의에서 말이 빙글빙글 돌지 않고, 결정 사항과 다음 액션이 더 명확해졌다.

프로젝트가 끝난 뒤 팀원들이 회의록과 티켓을 통해 배운 점이 있었다고 말해줘서 좋았다. 다만 그 과정이 마냥 뿌듯하지만은 않았다.

좋은 방식이라는 것을 아는 것과, 그 방식이 팀 안에서 자연스럽게 작동하도록 만드는 것은 다른 일이었다.

이번 경험을 통해 PM은 좋은 프로세스를 알고 있는 사람에서 끝나는 것이 아니라, 팀의 상황과 관계를 고려해 그 프로세스가 작동하도록 설계해야 하는 사람이라는 것을 배웠다.

---

6. 친한 팀일수록 역할과 책임은 더 명확해야 했다

이번 프로젝트에서 어려웠던 점 중 하나는 팀의 관계 구조였다.

팀원 6명 중 일부는 이미 친한 관계였고, 나는 그 관계 밖에 있는 사람이었다. 친한 관계는 편하게 의견을 내고 분위기를 부드럽게 만드는 장점이 있다.

하지만 이번 프로젝트에서는 오히려 역할의 긴장감과 책임 기준이 약해지는 순간도 있었다.

회의를 하고 오겠다고 했지만 어떤 결론이 났는지 공유되지 않거나, 회의록을 남겨달라고 여러 번 요청했지만 바로 정리되지 않는 경우가 있었다. 내 입장에서는 다음 의사결정을 위해 필요한 정보였지만, 팀 안에서는 아직 회의록과 공유가 기본값으로 자리 잡지 못한 상태였다.

그래서 나는 일 중심으로 밀고 가려고 했다.

해야 할 일은 해야 하고, 결정한 내용은 남겨야 하며, 다음 액션은 분명해야 한다고 생각했다.

하지만 돌아보면 맞는 말을 하는 것과 그 말이 받아들여지게 만드는 것은 다른 일이었다.

특히 내가 공식 리더나 상사가 아닌 상황에서 회의록, 티켓, QA 기준 같은 협업 방식을 계속 요청하는 일은 생각보다 많은 에너지를 필요로 했다. 상대에게는 내가 일을 더 시키거나 방식을 강제하는 것처럼 느껴질 수도 있었겠다는 생각도 들었다.

이번 경험을 통해 친한 팀일수록 오히려 초반에 역할, 책임자, 공유 방식, 완료 기준을 더 명확히 정해야 한다는 것을 배웠다.

분위기가 좋은 팀과 일이 잘 굴러가는 팀은 다르다.
편한 관계일수록 책임 기준은 더 선명해야 한다.

---

7. 자율적으로 맡기기 전에 기준을 먼저 맞췄어야 했다

이번 프로젝트에서 나는 PRD와 발표 스크립트, 문제 정의와 흐름 정리에 많은 에너지를 썼다. 동시에 회의록, 티켓, QA, 기능명세서 같은 협업 방식도 팀에 도입하려 했다.

돌아보면 아쉬웠던 점은 팀원에게 일을 맡긴 것 자체가 아니라, 맡기기 전에 역량과 완료 기준을 충분히 맞추지 못했다는 점이다.

나는 개발자로 일해본 경험이 있었기 때문에 기능명세서나 QA 체크리스트가 어느 정도 수준까지 구체화되어야 하는지 알고 있었다. 그래서 일부 산출물은 팀원들이 직접 경험해보는 것이 필요하다고 생각했다. 실제로 튜터님 피드백을 받으며 배우는 과정도 중요하다고 봤다.

하지만 결과적으로는 내가 기대한 기준과 팀원들이 이해한 기준 사이에 차이가 있었다.

내가 _“이 정도는 해보면 알겠지”_라고 생각한 부분도, 경험이 적은 팀원에게는 무엇을 어디까지 해야 하는지 모호했을 수 있다. 그 상태에서 자율적으로 맡기면 결과물이 아쉬워지고, 결국 다시 내가 확인해야 하는 일이 생겼다.

이번 경험을 통해 위임은 단순히 일을 넘기는 것이 아니라는 것을 배웠다.

위임하려면 먼저 그 사람이 이해한 목표, 산출물 기준, 중간 점검 시점을 맞춰야 한다.

다음 프로젝트에서는 한 사람이 여러 일을 같이 붙잡고 진행하기보다, 한 사람에게 하나의 책임을 명확히 주고 싶다. 그리고 일을 시작하기 전에 다음 네 가지를 먼저 정할 것이다.

• 이 업무의 목적은 무엇인가
• 최종 산출물은 무엇인가
• 완료 기준은 무엇인가
• 언제 중간 점검할 것인가

자율성은 기준이 있을 때 작동한다.
기준 없이 맡기는 것은 위임이 아니라 방치가 될 수 있다는 것을 배웠다.

---

8. Keep: 계속 가져가고 싶은 것

이번 프로젝트에서 계속 가져가고 싶은 것은 세 가지다.

첫째, 문제를 기능이 아니라 흐름으로 보려는 태도다.

처음에는 상담 기능을 만들자는 생각이었지만, 최종적으로는 오늘의집 안에서 콘텐츠와 상품을 탐색한 사용자가 구매 직전 확신이 부족해 멈추는 흐름을 보게 되었다.

앞으로도 기능을 먼저 떠올리기보다 사용자가 어느 흐름에서 멈추는지를 먼저 보고 싶다.

둘째, 근거가 증명할 수 있는 만큼만 주장하려는 태도다.

3D·AI 검색 증가는 크리에이터 상담 수요를 직접 증명하지 않는다. 외부 홈스타일링 시장이 있다고 해서 오늘의집 크리에이터 상담이 바로 성공한다는 뜻도 아니다. 사용자 설문 역시 표본 한계가 있었다.

이번 프로젝트에서는 근거마다 말할 수 있는 범위를 구분하려고 했다. 이 과정은 힘들었지만, 발표와 PRD의 논리적 비약을 줄이는 데 도움이 되었다.

셋째, 문서와 프로세스로 팀의 생각을 남기려는 태도다.

회의록과 티켓은 단순한 기록이 아니었다. 팀이 무엇을 결정했고, 왜 그렇게 판단했고, 다음에 무엇을 해야 하는지를 남기는 장치였다.

다음 프로젝트에서도 이 방식은 계속 가져가고 싶다.

---

9. Problem: 아쉬웠던 점

가장 아쉬운 점은 초반에 산출물과 완료 기준을 더 명확히 쪼개지 못한 것이다.

발제 문서를 더 꼼꼼히 읽고, 최종 제출물과 평가 기준을 먼저 정리했어야 했다. 하지만 짧은 시간 안에 방향을 잡고 움직이다 보니 일단 기획을 밀고 나가는 데 집중했다.

그 결과 후반에 PRD, 발표, 기능명세서, QA, UT, 운영 정책 등 해야 할 것들이 한꺼번에 밀려오는 느낌이 있었다.

또한 PRD와 발표 스크립트에 집중하느라 기능명세서와 QA 진행 상황을 충분히 체크하지 못했다.

_어느 정도는 의도적인 선택_이었다. 나는 개발 경험이 있었고, 기능명세서와 QA는 팀원들이 직접 경험해보는 것이 필요하다고 생각했다. 그래서 튜터님 피드백을 받으며 배우는 과정도 의미가 있다고 봤다.

하지만 결과물이 아쉬웠던 것도 사실이다.

다음에는 내가 맡은 문서에 몰입하더라도, 일정한 주기로 다른 산출물의 방향과 품질을 확인하는 시간을 따로 두고 싶다.

마지막으로, 팀 KPT 회고에서도 아쉬움이 남았다.

Problem은 많이 나왔지만, Try가 충분히 실행 단위로 내려가지 못했다. “업무 분담이 아쉬웠다”, “시간 관리가 부족했다”에서 끝나면 다음 프로젝트에서도 같은 문제가 반복될 수 있다.

회고는 문제를 말하는 자리에서 끝나면 안 된다.
다음 행동을 정하는 자리여야 한다.

---

10. Try: 다음에는 이렇게 해보고 싶다

다음 프로젝트에서 가장 먼저 바꾸고 싶은 것은 일정 체크와 역할 분담 방식이다.

이번에는 여러 명이 함께 붙잡고 진행한 일이 많았다. 같이 하면 안정적일 것 같지만, 실제로는 책임이 흐려지고 속도가 느려질 수 있다는 것을 느꼈다.

다음에는 “같이 하자”는 방식을 줄이고, 한 업무에는 한 명의 주 담당자를 두고 싶다.

구체적으로는 이렇게 운영해보고 싶다.

1. 산출물을 먼저 모두 나열한다.
2. 각 산출물의 완료 기준을 정한다.
3. 한 업무에는 한 명의 주 담당자를 둔다.
4. 보조 담당자는 리뷰나 자료 보완 역할로 제한한다.
5. 매일 짧게 진행 상황과 막힌 점을 확인한다.
6. 회의록 없이 논의한 내용은 결정으로 보지 않는다.

또한 다음에는 사용자 인터뷰와 UT를 더 제대로 해보고 싶다.

이번 설문은 MVP 방향을 점검하는 데는 도움이 되었지만, 문제 강도가 높은 사용자를 충분히 선별하지는 못했다.

다음에는 “최근 3개월 내 구매를 미룬 사람”, “장바구니에 담아두고 2주 이상 고민한 사람”, “구매 후 후회나 반품을 경험한 사람”처럼 조건을 더 구체적으로 잡고 인터뷰해보고 싶다.

그리고 프로토타입을 만든 뒤에는 실제 UT를 통해 사용자가 어디에서 이해하고, 어디에서 이탈하는지 보고 싶다.

마지막으로 A/B 테스트와 로그 설계도 더 구체적으로 해보고 싶다.

이번 프로젝트에서는 KPI를 답변 확인 대비 장바구니 담기율로 잡았다. 하지만 실제로 이 지표를 보려면 어떤 이벤트를 어디에 심어야 하는지까지 설계해야 한다.

다음에는 CTA 문구, 상담자 유형, 무료/유료 여부, 추천 결과 화면 구성에 따라 사용자의 신청률과 장바구니 담기율이 어떻게 달라지는지까지 고민해보고 싶다.

기획은 화면을 만드는 것에서 끝나는 것이 아니라, 그 화면이 실제로 어떤 행동을 만드는지 측정할 수 있어야 한다고 느꼈다.

---

11. 마치며

이번 MVP 프로젝트를 통해 가장 크게 배운 것은, PM의 일은 기능을 정하는 것이 아니라 문제를 끝까지 선명하게 만드는 일이라는 점이다.

처음에는 “상담 기능을 만들자”였지만, 결국 우리가 말해야 했던 것은 “오늘의집 안에서 탐색 이후 구매 확신이 끊기는 지점”이었다.

문제를 선명하게 정의해야 타겟이 정해지고, 타겟이 정해져야 해결안이 좁혀지고, 해결안이 좁혀져야 KPI가 정해지고, KPI가 정해져야 MVP 범위와 운영 정책도 결정된다.

동시에 이번 프로젝트는 협업 방식에 대해서도 많이 생각하게 했다.

좋은 프로세스를 알고 있는 것과, 그 프로세스가 팀 안에서 작동하게 만드는 것은 다르다. 회의록, 티켓, QA 명세서 같은 실무 방식도 팀의 기본값이 아니라면 설득과 경험을 통해 작동하게 만들어야 한다.

이번 프로젝트는 짧은 기간이었지만, 문제 정의 → 가설 → MVP → KPI → 운영 정책까지 하나의 흐름으로 연결해본 경험이었다.

아쉬운 점도 많았지만, 내가 PM으로서 어떤 역할을 잘할 수 있는지 조금 더 알게 됐다.

나는 기능을 예쁘게 포장하는 것보다, 흩어진 말과 자료를 다시 읽고, 그 안에서 “우리가 진짜 풀어야 할 문제가 무엇인지”를 찾는 과정에 더 몰입하는 사람이라는 것을 느꼈다.

다음 프로젝트에서는 이 강점을 유지하되, 초반 산출물 관리, 역할 분담, 사용자 검증, 로그 설계를 더 실무적으로 해보고 싶다.