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

[byunghyunkim0]

Week 4 최종 보고서 - 누렁이

4주 흐름 한 줄 요약

카메라로 위험을 감지하던 AI 안내견에서, 점자블록 기반 지하철 역내 길을 찾아주는 음성 안내 네비게이션으로 변화

---

A. 처음 의도 vs 결과

문제 정의의 변천

1주차	4주차
안내견의 수가 부족하다. → 시각 장애인이 안전한 보행을 보장받기 힘들다	시각장애인들이 처음 가는 또는 익숙하지 않은, 복잡한 지하철 역에서 부대시설을 찾기 어려워한다

MVP 범위의 변천

1주차 만들 것	실제 만든 것
카메라 화면 내 목표 객체(화장실, 출구, 엘리베이터 등) 탐지 후 음성으로 유도	출발지/목적지 선택 후 최적 경로 탐색
목표 탐지 시 직진/좌/우 안내 메시지 음성 출력 (정확도 70~80% 목표)	점형 블록(꺾임, 계단 등) 기준 다음 경로 음성 안내
안내 반응 속도 0.4~1초 이내 실시간 탐지	가상 맵(우아한테크코스 11층 교육장, 서현역)에서 남은 거리·점형 블록 정보 표시
현재 위치 판단 (범위 제외)	고대비/다크모드 UI 적용
	음성 버튼으로 안내 메시지 재청취
	VoiceOver/Talkback 호환
	STT(Speech-To-Text)로 출발지 설정 가능

기술 선택 재평가

다시 한다면 같은 기술? 왜?

• 바드: No, 각각의 Native 앱을 따로 만드는 게 좋을 것 같다. 작업 단위가 작으면 역할을 분담하기 어려워 플랫폼별로 네이티브 개발을 하면 역할 분담이 좀 더 편해질 것
  같다고 생각했다.
• 사무엘: Yes, 시간과 상황을 고려했을 때 최선의 기술이었다. 다만 시간과 상황에 맞는 맥락이 없다면, STT, TTS, VoiceOver/TalkBack 기능을 각각 구현해줘야해서 바드처럼 Native로 각각 구현하는게 나을 것 같다.
• 스마일: 휴대폰으로 다시 결정한다면 동일한 선택을 할 것 같다. 빠르게 MVP를 만드는 게 중요하니까. (지팡이도 고려해봄직 할 것 같다)

고려했다 안 쓴 선택지와 뺀 이유: Flutter, AI (YOLO)

이유: 3주차에 AI, 카메라 기반 객체 탐지 기능이 MVP 범위에서 통째로 빠지면서, TF-Lite 연동을 위해 선택했던 Flutter의 강점(크로스플랫폼 + TF-Lite)이
무의미해짐. 팀이 가장 익숙한 기술(KMP/CMP)로 빠르게 MVP를 만들어 사용자에게 검증받는 것이 더 중요하다고 판단해 전환함.

---

B. 가설 검증 종합

주차	가설	결과 (지지/반박/불명확)	받아들인 방식
1주차	시각 장애인은 택시보다 지하철을 더 많이 이용할 것이다	지지	중증 시각장애인일수록 버스를 기피하고 지하철을 선호한다는 인터뷰 근거를 확인, 지하철 중심 서비스 설계를 유지함
1주차	우리 팀의 능력으로 카메라 기반 실시간 객체 탐지 서비스가 실현 가능할 것이다	반박	2주차에 AI/카메라 기능을 MVP에서 제외하고 점자블록 기반 경로 탐색으로 방향을 전환함
2주차	지하철 부대시설(화장실, 역무실, 개찰구 등)을 찾는 데 어려움을 느낄 것이다	불명확	자주 다니는 길은 기억으로 무리 없이 찾지만 초행길에서는 헤맨다는 답변에 따라, 페르소나를 “모든 시각 장애인”에서 “익숙하지 않거나 복잡한 역을 이용하는 시각 장애인”으로 재정의함
2주차	남/녀 화장실 구분을 쉽게 하지 못할 것이다	반박	점자 표지판, 냄새·소리로 구분 가능하다는 답변에 따라 “구분”이 아니라 “화장실 자체를 찾는” 경로 안내로 문제를 재정의함
2주차	작동하지 않는 음성유도기가 있을 것이다	지지	고장·미설치 사례를 확인하고, 유도기 위치/상태 정보 제공 필요성을 향후 백로그에 반영함
2주차	역무원이 즉각적인 도움을 제공하기 어려운 상황이 있다	지지	역당 인력 부족과 공익근무요원 감소 사례를 확인, 기술적 보조 수단의 필요성을 재확인함
2주차	밝은 색의 잘 구분되는 버튼으로 앱을 구성하는 것이 좋을 것이다	반박	다크모드 선호, 고대비·2~3색 이내 일률적 색상 사용이 더 적합하다는 답변에 따라 UI 디자인 방향을 변경함
3주차	미터(m) 단위 거리 안내가 사용자에게 의미가 있을 것이다	불명확	끝까지 검증하지 못해 다음 인터뷰에서 확인할 항목으로 이연함
3주차	화면 내 미니맵, 깜빡임/애니메이션 효과가 시각장애인(저시력자 포함)에게 의미가 있을 것이다	불명확	저시력자 대상 UI 검증이 더 필요하다고 판단, 4주차 추가 인터뷰 항목으로 이연함

가장 크게 깨진 가설

무엇이었는가: 밝은 색의 잘 구분되는 버튼으로 앱을 구성하는 것이 좋을 것이다

어떻게 받아들였는가: 밝고 대비가 잘 되는 색상이 아닌, 다크모드를 선호하고, 고대비·2~3색 이내 일률적 색상 사용이 더 적합하다는 답변에 따라 UI 디자인 방향을
변경함

테마 변경 기능을 넣을 수도 있을 것 같다고 생각했음

끝까지 검증 못 한 가설 (있다면)

• 미터(m) 단위 거리 안내가 실제로 사용자에게 의미가 있는가
• 화면 미니맵, 현재 위치 표시 방식(색상 변경 vs 깜빡임)이 저시력자에게 의미가 있는가
• 시각 장애인이 가장 이해하기 쉬운 안내 메시지의 형태는 무엇인가

시연 영상

서현역 시연 영상 3번 출구 -> 개찰구

[krrong]

안녕하세요 누렁이들 🐕

4주동안 고생 많으셨습니다.
짧지 않은 기간동안 프로젝트를 진행하시면서 많은 것을 배우고 느꼈을거라고 생각이 드는데요.
좋았던 부분은 발전시키고, 부족한 부분은 개선해서 다음 프로젝트에 잘 적용해보셨으면 좋겠습니다.

제가 도와드린 부분은 많이 없는 것 같지만, 좋은 결과물과 시연 영상을 만들어주셔서 너무 좋았습니다.

좀 더 이야기해보고 싶은 부분에 코멘트를 달아두었으니 가볍게 확인해주시면 좋을 것 같습니다. 🙇

[krrong]

첫주차를 돌아보니 새삼 처음에 만들려고 했던 것과 실제로 만든 것은 정말 많이 달라진 것 같아요.

처음에도 상세히 작성했다고 생각했겠지만, 인터뷰등을 통해 구체화해보면서 모호한 부분도 많았구나 하는 점도 느껴보셨다면 좋겠어요.

[krrong]

기획이 크게 변경되어 실제로 구현하는 것도 많이 달라졌습니다.
좋은 근거로 KMP/CMP 를 접했고, 덕분에 빠르게 MVP를 만들 수 있게 된 것 같습니다.

다만 사용자의 검증도 있었다면 어땠을까 하는 아쉬움이 좀 남네요.

[krrong]

여전히 저에게도 궁금한 부분이네요 😄

[krrong]

여기서 이야기하는 기술은 CMP/KMP가 맞을까요?

작업 단위가 작으면 역할을 분담하기 어려워

작업을 분담하는데 어려움을 겪으신 것 같은데 어떤 어려움이었는지 이러한 부분들도 회고를 통해 이야기를 해보셨을지 궁금하네요.

다만 시간과 상황에 맞는 맥락이 없다면

이 부분은 맥락이 부족한 것 같아서 더 이야기해보면 좋을 것 같아요.

지팡이도 고려해봄직 할 것 같다

는 어떤 지팡이 일까요? 🤔

[Redish03]

여기서 이야기하는 기술은 CMP/KMP가 맞을까요?

-> 맞습니다..! 사실 저희가 선택한 게 해당 기술만 있다고 생각하긴합니다.. 🤔

시간과 상황에 맞는 맥락이 없었다면

-> 이거는 제 개인적인 생각이였는데요, 현재 저희가 레벨 1에서 CMP를 하고 레벨 2에서 안드로이드를 해서 이미 코틀린과 컴포즈에 익숙한 크루가 많아서 2-3주(2주차에 아이디어 변경 이후 시점) 동안엔 빠르게 MVP를 만들고, 검증해야한다고 생각했습니다.
그래서 kmp, cmp로 할 것 같습니다

제 설명이 좀 부족하기는 했네요 ㅎ,,

어떤 지팡이 일까요? 🤔

-> 시각장애인들이 일반적으로 사용하는 흰지팡이인데요,
얼마전에 제이슨이 오셔서 슬쩍 "왜 지팡이는 안되나? 점자 바닥에 비콘 이런 걸 포함시켜서 지팡이를 갖다 대면 "화장실입니다"와 같이 소리가 나거나 지팡이와 아두이노 초음파센서를 달아서 앞에 물체가 있는지 확인해주는 도구 이런것들을 해줄 수 있지 않을까? 라고 하고 가셨습니다.
미처 생각해보지 못한 것들이여서 한번 고려해볼 만한 것이라고 생각했어요! 이미 최종 발표 1주 전 쯤 왔다 가셔서 지금은 빠르게 MVP 만 검증해보자는 생각으로 나중으로 미뤘는데 해볼만한 것 같습니다

[byunghyunkim0]

회고 정리 (최종)

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

• 실제 사용자(시각장애인) 인터뷰를 통해 인사이트 확장
  → 우리 시선이 아닌 시각장애인의 시선으로 문제를 이해할 수 있었음
• AI를 활용해 빠르게 MVP를 만들고 검증
  → 점자블록 기반 경로 탐색이라는 작지만 검증 가능한 범위로 좁히고, 팀이 익숙한 기술(KMP/CMP)을 선택해 학습 비용 없이 구현에 집중
  → 4주 안에 동작하는 결과물 완성
• 문제 정의 → 가설 수립 → 검증의 사이클을 따라간 것
• 인터뷰에서 우리의 가정을 직접 질문으로 던져본 것 (유도성 질문 대신 직접 물어보기)
• 직접 확인, 테스트해보는 태도

---

Problem (아쉬웠던 것)

• 익숙한 기술(KMP/CMP)만 사용 → 새로운 기술적 도전이 없었음
  • 단, 접근성 기능(TalkBack, VoiceOver)은 새롭게 다뤄본 경험
• 지팡이(보행 보조기구) 등 휴대폰 외 대안을 처음부터 고민하지 못함
  → "휴대폰으로 해결해야 한다"는 고정관념이 있었던 것 같음
• 우리가 주 사용자(페르소나)가 아니라서 피드백·검증 속도가 느렸음
  → 가설 검증 때마다 외부 시각장애인을 구해야 했음
• 눈을 감고 직접 테스트해봤지만, 결국 이것도 우리 시선의 시뮬레이션일 뿐
  → 실제 유용성에 대한 확신이 어려움
• 인터뷰 대상자 수(3명)가 너무 적어 대표성이 부족함
• AI가 짜준 역할/PR 단위를 그대로 따라가며 유연성이 떨어짐
  → 실제 진행 상황에 맞춰 조정하기 어려웠고 매끄럽지 않은 지점 발생
• 발표 자료를 직접 구성하지 않아 핵심 내용이 충분히 담기지 않음
• iOS 개발 확인이 어려웠음
• AI 블랙박스 문제
  → AI가 작업한 내용/근거 파악이 어려움

---

Try (다음에 바꿀 것)

• 실제 서비스 배포를 통해 실사용자 경험/데이터 확보
• 하네스 엔지니어링 도입
  → 팀원 간 일정한 규칙(커밋 메시지, 코드 구조 등)을 정하고 AI가 그 규칙을 엄격히 따르도록 강제
• 정식 인터뷰보다 가볍고 표본을 많이 모을 수 있는 방식 도입 (예: 짧은 설문)
  → 정식 인터뷰는 상대 부담이 크고 빈도가 낮음
• 매일 작업 단위를 팀과 함께 재조정하는 체크포인트 두기
  → 미리 짜놓은 큰 계획을 그대로 따르지 않고, 그날 상황에 맞춰 유동적으로 조정
• 발표 자료/발표는 팀이 직접 구성
• AI를 “드라이버”가 아닌 “동업자”로 활용
  → 코드 설명·구조도를 작게 나눠 PR로 올리고 리뷰 요청하는 방식
• 사용자가 우리일 수 있는 더 범용적인 주제로 전환 고려

---

팀이 다음에 가져갈 1가지

• 매일 그날 할 일을 팀과 논의해 작업 단위를 유동적으로 재조정한다.
  → 미리 짜놓은 큰 단위의 계획을 그대로 따르지 않고, 매일 그날의 상황에 맞춰 팀이 함께 작업 단위를 다시 정하는 체크포인트를 둔다.
  → AI가 짜준 역할/PR 단위를 그대로 따라가며 단위가 커지고 유연성이 떨어졌던 문제를 직접 해결하는 액션
  → 매일 짧게라도 “오늘 할 일/단위가 맞는지” 팀과 맞춰보는 시간을 루틴으로 만드는 것이 핵심

---

그 밖에 오간 의견·결정

• 점자블록 근처에서 큰 공사가 진행되면 점자블록이 끊기거나 손상되어 경로 탐색 자체가 막힐 수 있다는 리스크
• 정확도 기준에 대한 시각 차이
  → 우리는 90%만 잘 동작해도 문제없다고 생각하지만, 실제 시각장애인 입장에서는 기준이 다를 수 있음
  → 어느 정도를 기준으로 잡아야 하는지 추가 논의 필요 (결론 미도출)
• MVP 고도화 판단 기준에 대한 고민
  → 시각장애인 100명에게 사용하게 했을 때 어떤 기준으로 “더 고도화해야 한다 / 충분하다”를 판단할 수 있을까?

[krrong]

안녕하세요 누렁이들 🐕

최종발표까지 고생많으셨습니다.
이제 마무리할 때가 온 것 같아요.
이번 미니 프로젝트 기간동안 많은 발전을 이루어내신 것 같고, 이 서비스가 확대되어서 실제로 사용되는 날이 왔으면 좋겠다는 생각이 드네요 😄

앞으로도 계속 응원하겠습니다! 🙇