[4주차 크루 미션 - 최종 발표 & 회고] A4 미션 제출합니다.

[BaekCCI]

코니 벌써 마지막 제출이네여... 너무 아쉽고 감사했습니다 🐈

마지막까지 잘부탁드립니다잇!!!! 🫡

[lee-ji-hoon]

영애들 안녕하세요! 4주차까지 정말 고생 많았습니다 🐈

아두이노 + CMP + 서버까지, 한 번에 이렇게 많은 걸 끌어안고 끝까지 달려온 것만으로도 값진 프로젝트였다고 생각해요.

처음 해보는 게 많았던 만큼 실패처럼 보이는 순간도 많았을 텐데요. 사실 누구나 실패는 많이 합니다. 중요한 건 그 과정에서 다음엔 이 실패를 어떻게 덜 할지, 어떻게 더 빨리 눈치챌지 를 배워서 더 나은 방향으로 가는 거죠. 여러분들은 그걸 잘 하기 위한 솔직한 회고까지 끝까지 남겨두셨네요. 그 점이 가장 보기 좋았습니다.

제가 4주간 많이 도와드린 것도 없는 것 같은데 이렇게 잘 흘러가 주어서 오히려 제가 고맙네요.

고생 많았습니다, 영애들 🫡

내일 최대한 가보려고 노력을 해보았는데 일정을 맞추기가 쉽지 않네요 죄송합니다 ㅠ

그래도 리뷰 반영은 해주셔야해요

[todays-sun-day]

회고 - A4 별터

Keep (좋았던 것 · 계속할 것)

• 계속 웃으면서 프로젝트를 했어서 좋았음
• 부족한 점을 숨기지 않아서 좋았음
• 마지막에 회의 시간을 정해놓고(오전 10시 반 & 오후 5시) 그때에만 회의를 진행했었는데 효율적으로 회의를 하게 되어서 좋았음

Problem (아쉬웠던 것)

• 아두이노 팀과 cmp 팀이 서로 피드백해줬어도 좋았을 듯 (각 잡고 한 회의가 아닌 중간중간 물어보는 형식이었음)
• 테스트 기간을 고려하지 못하고 진행했던 점 (초반에 테스트 기간을 미리 정해두었으면 그만큼 프로젝트를 빨리 끝내고 테스트 기간이 길어졌을 것)
• 발표를 팀장이 혼자 다 하게 된 점 (부담이 될 것)
• 반려견을 키우는 팀원이 없는데 반려견 보호자를 타겟으로 설정하게 된 점

Try (다음에 바꿀 것)

• 마무리 회의 때 서로 어떻게 구현했고, 그래서 어디까지 동작하고 어디부터 동작이 안 되는지 더 자세히 교류하기
• 테스트 기간을 여유있게 잡고, 구현을 더 빠르게 완성하기
• 팀원이 4명이었으니 발표를 한주에 한 명씩 진행
• 정말 우리가 쓸 서비스를 만들어보려고 고려를 해볼 듯

[BaekCCI]

KEEP

• 어떤 주제에 대해 바로 수용하는 것이 아니라 장단점에 대해 서로 토론하며 하나로 의견을 정해나가는 점이 좋았음
• 모르는 걸 솔직하게 얘기하는 점
• 팀원 모두가 적극적으로 참여한 점
• 인터뷰를 통해 문제를 재정의 하는 과정에서 모두 인터뷰 결과를 긍정적으로 받아들인 점

PROBLEM/TRY

• 아두이노가 처음이다 보니 역할분담이 아쉬웠음
  • 각자 구현하는 것이 아닌 각자 이해하는 시간을 가진 후에 역할 분담에 대해 다시 얘기해보는 과정으로 해보면 어떨까 싶음
• 회의 기록을 따로 안함 기억이 잘 안나는 부분이 생긴 것 같음
  • 클로바 노트/노션 을 통해 회의 내용을 정리하자.
• 계속 함께 있다 보니 토론할만한 거리가 생길 때 그때그때 회의함. 각자 맡은 것에 집중하다가 이 내용을 놓치는 경우가 발생하여 결과적으로 구체적인 흐름에 대한 팀원 간 이해가 서로 달라짐
  • 회의할 주제가 생기면 메모해 두고, 정해진 시간에 모아서 회의 진행

[katie0109]

Keep

가설이 깨졌을 때 방어하지 않고 빠르게 방향을 튼 것

2주차 인터뷰에서 즉시 알림이라는 핵심 가설이 반박되었을 때, 기존 아이디어를 지키려고 인터뷰 결과를 재해석하지 않고 문제 정의 자체를 즉시 확인에서 기록을 통한 건강 변화 확인으로 다시 잡았다.

MVP 범위를 상황에 맞게 늘리고 줄인 것

초기에 만들지 않을 것으로 분류했던 Supabase 기반 기록 저장과 수동 입력 기능을 문제 재정의 이후 핵심으로 끌어올렸고, 반대로 LED 알림이나 Authentication/User 테이블처럼 사용자 가치가 낮거나 MVP 검증과 거리가 먼 부분은 과감히 빼냈다. 범위를 지금 검증해야 할 것을 기준으로 다룬 점이 좋았다.

팀원 모두가 적극적으로 참여하고, 모르는 것을 솔직하게 공유한 것

4명 모두 회의와 작업에 적극적으로 참여했고, 이해가 되지 않는 부분을 부끄러워하지 않고 물어볼 수 있는 분위기였다. 그 위에서 토론이 이루어졌기 때문에 짧은 4주 동안 Arduino, Supabase, Compose Multiplatform이라는 새로운 기술 스택을 동시에 다룰 수 있었다.

---

Problem

아두이노 역할 분배를 못했던 것

아두이노와 센서에 대한 사전 지식이 부족한 채로 작업을 나누려다 보니, 누가 무엇을 맡아야 적합한지 판단할 근거가 없었다. 분배 자체가 어려웠고, 결과적으로 진행 속도와 학습 효율 양쪽에서 비용이 있었다.

검증을 끝내지 못한 가설이 많이 남은 것

4주차 보고서에 정리된 것처럼, 다음과 같은 핵심 가설들이 "불명확" 상태로 남았다. 실제 반려견과 실제 배변 패드 환경에서 방문·소변·대변을 구분할 수 있는지, 이미 오염된 패드 위의 새로운 이벤트를 새 이벤트로 구분할 수 있는지, 패드 방문 횟수와 배변 횟수를 결합한 데이터가 보호자에게 실제로 의미 있는 건강 단서가 되는지, 그리고 수동 입력 기능을 보호자가 실제로 지속해서 사용하는지. 시간 제약이 있었지만, 사용자 테스트를 더 일찍 짧게라도 끼워 넣었다면 일부는 검증할 수 있었을 것이다.

리팩토링이 충분히 이루어지지 못한 것

기능 구현을 우선하느라 코드 정리와 리팩토링 시간을 충분히 확보하지 못했다. 특히 아두이노 부분은 처음 접해보는 기술이라서 리팩토링을 진행하지 못했다.

---

Try

남은 시나리오에 대한 아두이노 테스트 진행

개발 중에 떠올랐지만 검증하지 못한 시나리오들(연속 배변, 오염된 패드 위 새 이벤트, 각도별 정확도 등)을 정리해서 짧은 사이클로 테스트한다. 가능하면 실제 사용 환경에 가까운 조건에서 진행해보려고 한다.

센서 구성 재설계

1개의 풀브릿지 로드셀 대신 하프브릿지 4개 구성으로 변경하고, 대소변 구분에는 초음파 센서 대신 가스 센서를 도입해 본다.

부족한 부분 리팩토링

다음 단계 확장을 위해 우선순위가 높은 영역부터 리팩토링한다. 한 번에 전부가 아니라, 다음 검증이나 기능 확장에 직접 연결되는 부분부터 정리한다.

[parkhyomi]

무엇을 돌아보나

4주를 한 줄로: 우리 팀의 이야기는 무엇이었나

가설: 무엇이 깨지고 무엇이 살아남았나

주차	가설	결과 (지지/반박/불명확)	받아들인 방식
1주차	보호자는 반려견의 배변을 즉시 확인하지 못해 큰 불편을 느끼며, 실시간 배변 알림이 핵심 해결책이 될 것이다.	반박	기존 가설을 유지하거나 인터뷰 결과를 알림 기능에 맞춰 해석하지 않았다. 문제를 '즉시 확인'에서 '배변 기록을 통한 건강 변화 확인'으로 재정의했다.
2주차	패드 방문 여부와 실제 배변 여부를 함께 기록하면 반려견의 배변 패턴과 건강 상태를 파악하는 데 도움이 될 것이다.	불명확	사용자 니즈와 가능성은 확인했지만 실제 사용 효과는 검증하지 못했다. 따라서 효과가 있다고 단정하지 않고 방문 감지 기능을 MVP에 구현해 다음 검증 단계로 넘겼다.
3주차	센서 감지 데이터를 Supabase에 저장하고 앱에서 조회하는 전체 흐름을 4주 MVP 안에 구현할 수 있다.	지지	아두이노 감지, DB 저장, 앱 조회 흐름을 완성했다. 대신 사용자 인증은 제외하고 감지 정확도와 기록 흐름 검증에 집중했다.
3주차	자동 감지 데이터에 사용자의 수동 입력을 결합하면 누락을 보완하고 더 완전한 배변 기록을 만들 수 있다.	불명확	수동 기록 기능은 구현했지만, 보호자가 실제로 지속해서 입력하는지와 기록 신뢰도가 향상되는지는 사용자 테스트를 통해 확인하지 못했다.
4주차	패드를 교체하지 않은 상태에서 대소변 이벤트가 여러 번 발생했을 때, 각각의 이벤트를 정확히 구분할 수 있다.	불명확	내부 테스트 결과, 각도에 따른 센서 정확도가 매우 떨어짐을 확인했다. 사용자 테스트에서도 반려견이 사용하지 않아서 테스트하지 못했다.

가장 큰 변화는 1주차의 핵심 가설이 깨졌다는 점이었다.
처음에는 “배변을 즉시 알려주는 것”이 가장 중요한 문제라고 생각했지만, 인터뷰를 통해 보호자들이 더 크게 느끼는 문제는 배변 횟수, 시간, 상태를 기록하고 이를 통해 건강 변화를 파악하는 것에 가깝다는 점을 알게 되었다.

이로 인해 전체적인 타겟층과 서비스 목표가 바뀌었다.
즉시 알림 중심의 서비스에서, 노령견이나 질병이 있는 반려견의 건강 변화를 확인할 수 있는 배변 기록 서비스로 방향이 전환되었다.

결과적으로 여러 사용자 가치 관련 가설은 아직 명확히 검증되지 못했지만, 센서 감지 데이터를 Supabase에 저장하고 앱에서 조회하는 기술적 흐름을 4주 안에 구현할 수 있다는 가설은 명확하게 살아남았다.

학습: 가장 큰 학습 1~2개 (개발 / 사용자 / 팀)

1. Arduino / Supabase / CMP를 직접 경험한 것
   개발 측면에서 가장 큰 학습은 Arduino, Supabase, CMP가 연결되는 전체 흐름을 직접 경험해본 것이었다.
   먼저 Arduino에서는 센서를 활용해 반려견의 패드 방문 여부와 배변 이벤트를 감지하는 과정을 경험할 수 있었다. 단순히 센서 값을 읽는 것에서 끝나는 것이 아니라, 감지값이 어떤 상황에서 정확도가 떨어지는지, 각도나 위치에 따라 결과가 어떻게 달라지는지 확인하면서 하드웨어 데이터는 생각보다 많은 변수가 있다는 것을 알게 되었다.
   Supabase를 사용하면서는 Firebase와는 다른 방식으로 데이터를 저장하고 관리하는 흐름을 경험했다. 관계형 데이터베이스 구조를 기반으로 테이블을 설계하고, Arduino에서 전송한 감지 데이터를 저장한 뒤 앱에서 조회할 수 있도록 연결했다. 이를 통해 단순히 데이터를 저장하는 것뿐만 아니라, 어떤 데이터를 어떤 구조로 남겨야 나중에 기록으로 활용할 수 있는지 고민하는 과정이 중요하다는 것을 느꼈다.
   CMP 구현을 통해서는 기존 Android 개발과는 다른 멀티플랫폼 개발의 특징을 경험할 수 있었다. CMP를 깊게 다루지는 못했지만, 짧게 구현해보는 것만으로도 공통 코드와 플랫폼별 코드의 경계를 어떻게 나눌지, Android와 iOS에서 각각 고려해야 하는 부분이 무엇인지 조금이나마 알 수 있었다.
   이번 프로젝트는 특정 기술 하나를 깊게 파는 경험이라기보다는, 센서 감지 → DB 저장 → 앱 조회로 이어지는 전체 흐름을 직접 연결해본 경험이었다. 하드웨어에서 발생한 데이터가 Supabase를 거쳐 CMP 앱에서 사용자에게 기록으로 보이는 과정을 구현해보며, 각 기술이 어떤 역할을 맡고 어떻게 이어지는지 이해할 수 있었다.

2. 문제 정의와 피봇에 대한 인식이 바뀐 것
   두 번째로 크게 배운 점은 프로젝트를 시작하는 방식과 피봇에 대한 인식이 달라졌다는 것이다.
   이전까지는 내가 흥미를 느끼는 것, 재미있어 보이는 것, 또는 요구받은 기능을 중심으로 사이드 프로젝트나 개발을 진행했던 것 같다. 하지만 이번 프로젝트에서는 단순히 “이런 불편함이 있지 않을까?”에서 끝나는 것이 아니라, 실제 타겟층을 인터뷰하며 우리가 생각한 문제와 사용자가 실제로 느끼는 문제 사이에 차이가 있다는 것을 직접 확인했다.
   특히 처음에 중요하다고 생각했던 실시간 알림 가설이 깨졌을 때, 가설이 틀렸다는 사실 자체보다 그것을 인정하고 방향을 바꾸는 과정이 더 중요하다는 것을 배웠다.
   이번 경험을 통해 개발은 단순히 기능을 만드는 것이 아니라, 정말 해결해야 하는 문제가 무엇인지 계속 확인하고 조정하는 과정이라는 점을 체감할 수 있었다.

협업: 팀으로 일하며 좋았던 것과 아쉬웠던 것

시간상 모든 인원이 아두이노 작업을 끝낸 뒤 CMP 작업을 함께 진행하는 방식은 효율적이지 않다고 판단했다.
그래서 팀을 2명씩 나누어 아두이노와 CMP 파트를 병렬로 진행했다.
이 방식 덕분에 제한된 기간 안에 MVP 구현은 완료할 수 있었고, 각 파트의 작업 속도도 더 효율적으로 가져갈 수 있었다.
다만 아쉬운 점도 있었다.
파트를 나누어 작업하다 보니 팀원 전체가 서로의 코드나 내부 구현 사항을 충분히 이해하지 못하는 부분이 생겼다.
각자 맡은 부분은 잘 진행되었지만, 전체 구조나 세부 구현을 모두가 같은 수준으로 이해하고 있다고 보기는 어려웠다.
또한 함께 모여 작업하다 보니 생각나는 내용을 바로바로 이야기하는 경우가 많았다.
이 점은 빠르게 의견을 나눌 수 있다는 장점도 있었지만, 대화 중에 나온 결정 사항이나 변경 내용이 명확하게 기록되지 않아 나중에 각자가 다르게 이해하는 문제가 있었다.
회의를 따로 한 것이 아니라 자연스럽게 나온 결론일수록 공유가 누락되기 쉬웠고, 그로 인해 반영 사항을 놓치거나 서로 이해한 내용이 달라지는 경우가 있었다.
그리고 명확한 용어 선택의 중요성도 느꼈다.
같은 기능이나 상태를 두고도 팀원마다 다르게 이해하는 경우가 있었고, 명확하지 않은 이름이나 표현 때문에 불필요한 의견 차이가 생기기도 했다.
실제 기능 구현보다 용어 해석에서 오는 토론에 시간이 쓰인 경우도 있었기 때문에, 앞으로는 중요한 개념이나 기능명은 초반에 함께 정의하고 문서화하는 과정이 필요하다고 느꼈다.
그럼에도 이번 협업에서 좋았던 점은, 팀원들이 한 가지 기능을 두고도 다양한 가능성과 문제 상황을 함께 고민했다는 점이다.
지금까지 다른 프로젝트를 하면서 하나의 기능 선택이나 구현 방식에 대해 이렇게 오래 토론해본 적은 많지 않았다. 특히 직접 담당한 파트가 아니면 깊게 참여하지 않았던 경우도 있었는데, 이번 프로젝트에서는 모두가 처음 다뤄보는 기술임에도 불구하고 각자의 의견을 내고, 에러 가능성이나 사용자 상황까지 함께 고려하려고 했다.
물론 토론 시간이 길어질 때도 있었지만, 그 과정 자체가 단순히 의견 충돌이라기보다는 더 좋은 방식을 찾기 위한 노력처럼 느껴졌다.
그래서 이번 협업은 완벽하게 효율적이지만은 않았더라도, 팀이 함께 문제를 바라보고 더 나은 방향을 찾으려 했다는 점에서 좋은 경험이었다.

다음: 각자 다음 활동에 가져갈 1가지

허닛:
별터:
모스:

KPT - Keep(좋았던 것·계속할 것) / Problem(아쉬웠던 것) / Try(다음에 바꿀 것)

Keep — 잘한 점 / 계속 유지할 점

구분	내용
진행 관리	작업 진행 전후로 상황을 확인하며 흐름을 점검함
참여 태도	팀원 모두가 적극적으로 참여함
협업 효율 (CMP팀)	작업 분배가 잘 이루어져 Git 충돌이 적었음
협업 도구	칸반보드 및 Organization을 효과적으로 활용함
소통 문화	모르는 것을 솔직하게 공유하고, 이에 대한 적절한 토론이 이루어짐

Problem — 아쉬웠던 점 / 개선이 필요한 점

역할 분배의 어려움 (아두이노 팀)

• 사전 지식이 부족한 상태에서 시작하다 보니 역할을 나누기 어려웠음

회의 집중도 저하

• 4인 모두 회의에 온전히 집중하지 못함
  • 계속 함께 있다 보니 각자 작업에 몰두하다가 회의 내용을 놓치는 경우가 발생함
  • 그 결과 전체적인 흐름에 대한 팀원 간 이해가 서로 달라짐

파트별 서로의 코드 이해 부족

• 파트을 나눠 작업을 진행했기에 같은 팀에도 불구하고 파트별 서로의 코드 이해가 다소 부족해 보임

검증 부족

• 아누이노: 개발 과정에서 몇가지 시나리오들이 떠올랐는데 이에 대해 아직 테스트하지 못함

기능 정의의 명확화 필요

• 같은 기능이나 상태를 두고도 팀원마다 다르게 이해하는 경우가 있었음
• 명확하지 않은 이름이나 표현 때문에 불필요한 의견 차이가 생기기도 했음
• 실제 기능 구현보다 용어 해석에서 오는 토론에 시간이 쓰인 경우가 있었음

Try — 다음에 시도해 볼 점

구분	개선 시도
회의 운영	회의할 주제가 생기면 메모해 두고, 정해진 시간에 모아서 회의 진행
회의 정리	하교 전에 그날의 회의 내용을 정리하여 공유
협업 방식 (아두이노 팀)	역할 분배 대신 페어 프로그래밍으로 진행
아두이노 테스트	다양한 시나리오 테스트 진행 및 리팩토링
코드 공유	각 파트별 코드를 공유하고 설명하며, 담당자뿐만 아니라 팀 전체의 이해도를 높임
기능 정의의 명확화	기능명은 초반에 팀원들과 함께 정의하고 문서화

[parkhyomi]

최종회고

팀: A4: 제국의 영애들
팀장: @BaekCCI
팀원: @todays-sun-day , @katie0109 , @parkhyomi

Keep

• 팀원들끼리 다양한 의견을 많이 나눌 수 있어서 좋았다.
• 단순히 의견을 무조건 수용하는 것이 아니라, 각자의 생각과 근거를 바탕으로 받아들이는 분위기가 좋았다.
• 모르는 부분을 숨기지 않고 솔직하게 이야기할 수 있는 분위기가 형성되어 있어서 편했다.
• 인터뷰 결과를 빠르게 받아들이고, 기존 가설이 깨졌을 때도 유연하게 방향을 수정할 수 있었다.
• 전체적으로 팀 분위기를 좋게 유지하면서 프로젝트를 진행한 점이 좋았다.

Problem

• 아두이노 파트의 역할 분담이 조금 더 명확했으면 좋았을 것 같다.
• 회의 기록이 따로 남아 있지 않아, 나중에 내용을 다시 확인하기 어려웠고 기능 정의가 명확하지 않아 같은 기능을 두고도 팀원마다 다르게 이해한 부분이 있었다.
• 회의를 그때그때 진행하다 보니 회의 흐름을 따라가기 어려운 순간이 있었고, 팀원 간 이해도 차이가 생기기도 했다.
• 아두이노 파트와 CMP 파트가 서로의 구현 흐름을 충분히 이해하지 못한 점이 아쉬웠다.

Try

• 역할을 나누기 전에 각 파트의 전체 흐름을 먼저 이해한 뒤 역할 분담을 해보면 좋을 것 같다.
• 클로바노트나 노션 등을 활용해 회의 내용을 기록으로 남겨두고 기능 정의를 명확하게 적어 놓으면 좋을 것 같다.
• 즉흥적으로 회의하기보다는 정해진 시간에 회의를 진행해 팀원들이 모두 흐름을 따라갈 수 있도록 하면 좋겠다.
• 각 파트에서 구현한 코드를 주기적으로 설명하는 시간을 가지면, 서로의 작업을 더 잘 이해할 수 있을 것 같다.

팀이 다음에 가져갈 1가지

• 기존보다 좀 더 빠르게 도전하고 빠르게 깨지자!!!

[BaekCCI]

🫡

[lee-ji-hoon]

영애들 안녕하세요!

마지막까지 고생많았습니다.
4주간의 프로젝트를 기획하고 진행을 하면서 4주가 생각보다 길어보이지만 실제로 기획을 하고 그 기획을 검증하고 구현하는 과정 속에서 실제 기획에서의 문제를 파악하고 다시 수정하는 과정들이 어떻게 이뤄지는지 그리고 앞으로는 이런것들을 조금 더 빠르게 처리할 수 있게끔 회고를 진행한 모습도 보이네요!

이번 경험이 여러분들이 앞으로에 있어서 조금이나마 도움이 됐으면 좋겠네요

4주간 고생 많았습니다!