|
| 1 | +# Week 4 최종 보고서 - A4: 제국의 영애들 |
| 2 | + |
| 3 | +## 4주 흐름 한 줄 요약 |
| 4 | + |
| 5 | +'배변 즉시 알림'이라는 편의 기능에서 출발해, 인터뷰를 통해 핵심 가설을 수정하고, '노령견·질병견의 배변 기록을 통한 건강 변화 확인'으로 문제를 재정의한 뒤 센서–Supabase–모바일 앱으로 이어지는 |
| 6 | +기록형 MVP를 구현했다. |
| 7 | + |
| 8 | +--- |
| 9 | + |
| 10 | +## A. 처음 의도 vs 결과 |
| 11 | + |
| 12 | +### 문제 정의의 변천 |
| 13 | + |
| 14 | +| 1주차 | 4주차 | |
| 15 | +|---------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------| |
| 16 | +| 반려견의 배변을 즉시 확인하지 못해 패드 위생 관리, 실내 배변 실수, 병원 상담 과정에서 불편을 겪는다고 정의했다. 따라서 배변을 감지한 뒤 즉시 알림을 제공하는 것을 핵심 해결책으로 설정했다. | 보호자가 느끼는 더 큰 문제는 배변을 즉시 확인하지 못하는 것이 아니라, 배변 횟수/시간/상태 변화를 지속적으로 기록하고 비교하기 어렵다는 것이었다. 이에 자동 감지와 수동 기록을 결합해 배변 데이터를 축적하고, 노령견/질병견의 건강 변화를 확인할 수 있도록 문제를 재정의했다. | |
| 17 | + |
| 18 | +1주차에는 실시간 감지와 알림을 핵심 가치로 보았지만, 2주차 인터뷰에서 보호자들은 배변 청소를 위한 즉시 알림을 필수 기능으로 인식하지 않았다. |
| 19 | +오히려 배변 횟수나 상태 변화가 결석, 노화, 쿠싱증후군 등의 건강 문제를 확인하는 단서가 될 수 있다는 점에 더 큰 가치를 느꼈다. |
| 20 | + |
| 21 | +특히 인터뷰 참여자 5명 중 4명은 즉시 알림보다 건강 확인 및 기록에 더 높은 관심을 보이거나 알림의 부작용(부저 소리/LED 빛에 의해 반려견이 놀람 등)을 우려했다. |
| 22 | + |
| 23 | +### MVP 범위의 변천 |
| 24 | + |
| 25 | +| 1주차 만들 것 | 실제 만든 것 | |
| 26 | +|-------------------|----------------------------------------------------------| |
| 27 | +| LED를 활용한 감지 결과 표시 | 테스트용으로 사용했으나 사용자 가치가 낮다고 판단해 최종 범위에서 제외 | |
| 28 | +| 서버와 기록 저장 기능은 제외 | Supabase 테이블과 이벤트 전달 로직을 구현해 감지 기록을 저장 | |
| 29 | +| 배변패드 위 배변 여부 감지 | 반려견이 패드 위에 올라왔는지를 확인하는 방문 감지 기능까지 추가 | |
| 30 | +| 모바일 앱 알림 | 안드로이드 모바일 앱 알림 구현, 앱에서 배변 기록을 조회하는 기능까지 확장 | |
| 31 | +| 자동 감지 중심 | 패드 밖 배변이나 감지 누락을 보완하기 위한 사용자 수동 기록 기능 추가 | |
| 32 | +| 사용자 계정 구조 미정 | Authentication과 User 테이블은 제외하고, 아두이노 기기 ID를 기준으로 데이터를 구분 | |
| 33 | + |
| 34 | +최종 MVP에서는 아두이노 감지 -> Supabase 저장 -> Compose Multiplatform 앱에서 기록 조회라는 전체 흐름을 구현했다. |
| 35 | + |
| 36 | +초기에는 제외했던 기록 기능이 문제 재정의 이후 핵심 기능이 되었으며, 반대로 초기 핵심이었던 앱 알림은 타겟층이 노령견/질병견이 됨에 따라 구현 후순위로 결정했다. |
| 37 | + |
| 38 | +### 기술 선택 재평가 |
| 39 | + |
| 40 | +#### 다시 한다면 같은 기술을 사용할 것인가? |
| 41 | + |
| 42 | +**전체 구조는 유지하되, 센서 구성과 개발 우선순위는 조정할 것이다.** |
| 43 | + |
| 44 | +- **Arduino** |
| 45 | + - 배우는데 비용이 많이 들지 않고 실시간 감지하는 것에 적합한 기술이기 때문에 다시 선택할 것이다. |
| 46 | + |
| 47 | +- **로드셀/초음파 센서** |
| 48 | + - 1개의 풀브릿지 로드셀에서 비용/납땜문제로 포기했던 하프브릿지 4개짜리 로드셀로 변경할 것이다. |
| 49 | + - 대소변 구분을 위한 센서로 초음파 대신 가스센서를 이용할 것이다. |
| 50 | + |
| 51 | +- **Supabase** |
| 52 | + 별도의 백엔드 서버를 처음부터 구축하지 않고도 테이블, 데이터 저장, 앱 연동을 빠르게 구현할 수 있어 4주 MVP에 적합했다. 다시 진행해도 사용할 것이다. |
| 53 | + |
| 54 | +- **Compose Multiplatform** |
| 55 | + 하나의 코드베이스로 모바일 UI와 데이터 연동을 구현할 수 있다는 장점이 있었다. 다만 4주처럼 기간이 짧다면 Android 시연 환경을 우선 완성하고, 이후 iOS 지원 범위를 확장하는 방식이 더 효율적일 수 |
| 56 | + 있다. |
| 57 | + |
| 58 | +- **Firebase Cloud Messaging** |
| 59 | + - 서버를 구축하지 않고 빠르게 구현했을 때, 알림 기능을 구현하기 가장 적합한 기술이라고 생각되기 때문에 다시 선택할 것이다. |
| 60 | + |
| 61 | +#### 고려했다가 사용하지 않은 선택지와 제외 이유 |
| 62 | + |
| 63 | +- **LED 알림:** 실제 보호자에게 전달하는 가치가 낮아 최종 범위에서 제외했다. |
| 64 | +- **Authentication·User 테이블:** 현재 MVP의 핵심은 계정 관리가 아니라 감지 데이터를 저장하고 보여주는 것이므로 제외했다. 사용자 대신 기기 고유 ID를 기준으로 기록을 구분했다. |
| 65 | +- **정교한 건강 분석 및 커뮤니티 기능:** 사용자 니즈는 확인했지만, 어떤 건강 지표를 제공해야 하는지 충분히 검증하지 못했고 구현 범위도 커 이번 MVP에서는 제외했다. |
| 66 | + - 배변의 횟수와 시간은 불안정하지만 감지가 가능하다. |
| 67 | + - 색이나 양같은 경우는 아두이노 기기로 구현하지 않았고 사용자가 앱 내 메모 기능을 통해 기록할 수 있도록 보완했다. |
| 68 | + |
| 69 | +--- |
| 70 | + |
| 71 | +## B. 가설 검증 종합 |
| 72 | + |
| 73 | +| 주차 | 가설 | 결과 (지지/반박/불명확) | 받아들인 방식 | |
| 74 | +|-----|------------------------------------------------------------------|----------------|----------------------------------------------------------------------------------------------| |
| 75 | +| 1주차 | 보호자는 반려견의 배변을 즉시 확인하지 못해 큰 불편을 느끼며, 실시간 배변 알림이 핵심 해결책이 될 것이다. | 반박 | 기존 가설을 유지하거나 인터뷰 결과를 알림 기능에 맞춰 해석하지 않았다. 문제를 '즉시 확인'에서 '배변 기록을 통한 건강 변화 확인'으로 재정의했다. | |
| 76 | +| 2주차 | 패드 방문 여부와 실제 배변 여부를 함께 기록하면 반려견의 배변 패턴과 건강 상태를 파악하는 데 도움이 될 것이다. | 불명확 | 사용자 니즈와 가능성은 확인했지만 실제 사용 효과는 검증하지 못했다. 따라서 효과가 있다고 단정하지 않고 방문 감지 기능을 MVP에 구현해 다음 검증 단계로 넘겼다. | |
| 77 | +| 3주차 | 센서 감지 데이터를 Supabase에 저장하고 앱에서 조회하는 전체 흐름을 4주 MVP 안에 구현할 수 있다. | 지지 | 아두이노 감지, DB 저장, 앱 조회 흐름을 완성했다. 대신 사용자 인증은 제외하고 감지 정확도와 기록 흐름 검증에 집중했다. | |
| 78 | +| 3주차 | 자동 감지 데이터에 사용자의 수동 입력을 결합하면 누락을 보완하고 더 완전한 배변 기록을 만들 수 있다. | 불명확 | 수동 기록 기능은 구현했지만, 보호자가 실제로 지속해서 입력하는지와 기록 신뢰도가 향상되는지는 사용자 테스트를 통해 확인하지 못했다. | |
| 79 | +| 3주차 | 패드를 교체하지 않은 상태에서 대소변 이벤트가 여러 번 발생했을 때, 각각의 이벤트를 정확히 구분할 수 있다. | 불명확 | 시나리오 테스트 결과, 제한된 센서 범위 내에서 대변+대변 중첩을 제외한 테스트는 성공했으나, 성공한 시나리오 테스트가 실제 사용자 테스트에서도 성공할 수 있을 지 검증하지 못했다. | |
| 80 | + |
| 81 | + |
| 82 | +### 가장 크게 깨진 가설 |
| 83 | + |
| 84 | +- **무엇이었는가:** |
| 85 | + "보호자는 반려견의 배변을 즉시 확인하지 못하는 것을 큰 불편으로 느끼며, 배변 직후 알림을 가장 필요로 할 것이다"라는 가설이었다. |
| 86 | + |
| 87 | +- **어떻게 받아들였는가:** |
| 88 | + 인터뷰 결과, 일부 보호자는 배변을 늦게 확인해 냄새가 나거나 패드 교체가 늦어지는 불편을 경험했지만, 이를 반드시 해결해야 하는 핵심 문제로 보지는 않았다. 일부는 소리 알림 때문에 반려견이 놀라 패드 사용을 |
| 89 | + 꺼릴 수 있다고 우려하기도 했다. |
| 90 | + |
| 91 | + 반면 보호자들은 배변 횟수와 상태 변화가 건강 이상을 확인하는 단서가 될 수 있고, 병원 방문 전에 객관적인 기록이 있으면 도움이 된다는 점에 더 큰 관심을 보였다. |
| 92 | + |
| 93 | + 이에 팀은 기존 아이디어를 방어하기보다 실시간 알림을 부가 기능으로 낮추고, 기록 저장과 건강 변화 확인을 중심으로 MVP를 수정했다. 또한 기록 누락을 보완하기 위해 수동 입력 기능을 추가했다. |
| 94 | + |
| 95 | +### 끝까지 검증하지 못한 가설 |
| 96 | + |
| 97 | +- 실제 반려견과 실제 배변패드를 사용했을 때 방문, 소변, 대변을 충분한 정확도로 구분할 수 있는가. |
| 98 | +- 이미 소변이 묻은 패드 위에서 새로운 소변이 발생하거나, 대변과 소변이 시간차를 두고 발생했을 때 각각을 새로운 이벤트로 구분할 수 있는가. |
| 99 | +- 패드 방문 횟수와 배변 횟수를 함께 기록한 데이터가 보호자에게 실제로 의미 있는 건강 단서를 제공하는가. |
| 100 | +- 노령견/질병견 보호자가 서비스를 장기간 사용하면서 지속적인 가치를 느끼는가. |
| 101 | + |
| 102 | + |
| 103 | +### 다음 단계에서 해야할 일 |
| 104 | + |
| 105 | +- CMP팀도 아두이노 팀에 함류해 두 팀으로 나눠 적절한 센서 후보들을 빠르게 적용 후 테스트를 진행하여 더 적절한 센서를 선정한다. |
| 106 | +- 안정적인 사용자 테스트를 위해 하프브릿지 4개짜리 로드셀로 변경한다git |
0 commit comments