프로젝트에서 보기 →

공용 냉장고 관리 앱 | 오름캠프 Flutter 모바일 앱 개발 과정 1기 프로젝트

태그
기술 오름캠프 Flutter 앱만들기
시작일
종료일
수정일

https://www.youtube.com/watch?v=QYjhNn_KxWI

1. 이건 꼭 알아야 한다[^1]

[? 질문] 공용 냉장고에서 “누가 무엇을 넣었고, 언제까지 보관 가능한지”를 직원과 관리자가 쉽게 확인·관리하게 만들려면 앱은 어떤 기능과 UX를 가져야 하는가[^6]
[= 답] 직원은 사진 1번 촬영만으로 음식 등록을 끝내고, 보관기간 임박 시 알림을 받게 하며, 관리자는 냉장고/칸 구성부터 공용 여부, 유통/보관기한 만료(폐기) 목록, 그룹(사용자 권한)까지 한 화면에서 관리할 수 있게 역할별 UI·기능을 분리한다.[^7]

[? 질문] 요구사항이 있는(실사용자가 있는) 앱 프로젝트에서, 무엇을 먼저 하고 어떤 방식으로 기획을 진행해야 하는가[^8]
[= 답] 사용자 요구가 명확히 존재하므로 인터뷰와 현장(사무실) 방문을 통해 니즈/에러(불편) 사항을 파악한 뒤, 국내외 유사 앱 레퍼런스를 비교해 장단점을 흡수하여 기능과 UX를 설계한다.[^9]

[? 질문] 초보 개발자 6명이 Flutter로 프로젝트를 완성하기 위해 개발·협업 측면에서 무엇을 선택했고 어떻게 운영했는가[^10]
[= 답] 데이터는 Firebase, 알림은 Awesome Notifications를 사용하고, 코드 구조는 MVVM + 커스텀 위젯을 목표로 하며, 폰트/사이즈/컬러 등 디자인 시스템을 사전 세팅하고 페이지별 역할분담과 리팩토링을 병행했다. 또한 매일 일정 체크 및 토이(공유)로 지식을 교환했고 결과적으로 465 커밋을 거의 균등하게 만들었다.[^11]

2. 큰 그림[^2]

이 발표는 오름캠프 Flutter 모바일 앱 개발 과정 1기에서 “슈퍼점 팀”이 만든 공용 냉장고 관리 앱 **‘우리빙고’**를 소개하는 프로젝트 발표다.[^3] 앱의 목적은 직원과 관리자가 공용 냉장고의 음식들을 등록-확인-연장-삭제-폐기-권한관리까지 손쉽게 처리하도록 돕는 것이다.[^6] 발표는 팀/앱 소개 → 사용자 조사·레퍼런스 → 직원용 데모 → 관리자용 데모 → 유저 플로우/기능명세 → 기술스택/코드/아키텍처 → 협업 방식과 결과 순으로 진행된다.[^12]

  • 역할 기반 UI/기능 분리: 관리자 여부에 따라 화면과 기능을 달리 제공하고, 데모 영상도 직원/관리자 2개로 나눠 보여준다.[^13]
  • 편의성 중심의 등록 UX: 직원이 이름·날짜를 매번 입력하지 않게 하고, 촬영 한 번으로 등록되도록 핵심 기능을 설계·구현했다.[^14]
  • Firebase + 알림 + 구조화된 코드: Firebase로 데이터/사진 등록을 처리하고, Awesome Notifications로 임박 알림을 주며, MVVM과 커스텀 위젯으로 “클린 코드”를 지향했다.[^15]

3. 하나씩 살펴보기[^4]

3.1 발표 시작: 팀 소개와 네이밍 컨셉[^5]

📸 0:12

발표자는 “슈퍼점 팀”의 팀원 한상인이라고 자신을 소개하며 발표를 시작한다.[^16] 팀은 총 6명으로 구성되어 있고, 팀명 “슈퍼점”은 다소 유머러스한 설정(부모 클래스=강사진, 자식 클래스=팀원)이 깔려 있다.[^17] 즉, 강사진(부모)에게서 Flutter 지식을 “탑재” 받아 멋지고 대단한 팀이 되겠다는 의지를 “클래스” 비유로 설명하며 팀명을 지었다는 맥락이다.[^17]

앱 이름은 **‘우리빙고’**라고 소개한다.[^18] 명칭의 의미는 ‘우리’(순우리말) + 냉장고의 다른 말 ‘빙고(라)’를 결합한 것으로 설명된다.[^19] 즉 “우리(함께 쓰는) 냉장고”라는 공용성/공동체성을 이름에서 드러내려는 의도다.[^19]

3.2 앱 목표와 사용자 가치: 공용 냉장고 관리 문제를 해결[^6]

📸 0:38

발표자는 우리빙고를 공용 냉장고 관리 앱이라고 정의한다.[^20] 목표는 “냉장고 안 음식을 직원과 관리자가 쉽게 확인 및 관리”하도록 만드는 것이다.[^20] 여기서 ‘직원’과 ‘관리자’라는 두 역할이 핵심 이해관계자로 전제된다.[^7]

특히 팀은 앱 설계의 최우선 기준을 사용자 편의성으로 둔다고 강조한다.[^21]

  • 직원 관점: 사진 등록 한 번으로 음식을 손쉽게 등록할 수 있어야 한다.[^22] 또한 보관기간이 임박하면 알림을 받는 흐름을 제공한다.[^22]
  • 관리자 관점: 냉장고 안 음식의 주인이 누구인지, 보관기한이 지난 음식이 무엇인지를 한눈에 파악할 수 있어야 한다.[^7]

[!IMPORTANT] 역할 정의가 곧 기능 설계의 기준
직원은 “등록과 개인 관리의 마찰을 줄이는 사용자”, 관리자는 “공용 자산(냉장고) 관리를 책임지는 사용자”로 기능 요구가 분리된다.[^7]

3.3 요구사항 선행: 인터뷰/현장 방문 + 레퍼런스 분석[^8]

📸 1:01

발표자는 이번 프로젝트가 “유저의 요구 사항이 있었기 때문에” 요구사항의 취합·분석 선행이 필수라고 판단했다고 말한다.[^23] 즉, 단순히 만들고 싶은 앱이 아니라 실제 사용 맥락/요구가 존재하는 문제를 대상으로 했다는 의미다.[^23]

이를 위해 다음의 기획 활동을 진행했다고 설명한다.

  1. 인터뷰 및 사무실 방문을 수행했다.[^24]
  • 목적은 유저의 니즈와 사용 중 겪는 에러/불편 사항을 파악하는 것이었다.[^24]
  • 이를 바탕으로 기획을 진행했다고 연결한다.[^24]
  1. 국내외 공용 냉장고/개인 냉장고 앱을 레퍼런스로 조사했다.[^25]
  • 각 앱의 장단점을 파악하고 참고했다고 밝힌다.[^25]
  • 발표 내에서 특정 앱 이름을 열거하진 않지만, “공용 냉장고”뿐 아니라 “개인 냉장고 앱”도 함께 보며 기능 패턴을 비교한 점이 특징이다.[^25]

3.4 데모 구성 안내: 직원용/관리자용 영상 분리[^12]

📸 1:30

발표자는 “영상으로 먼저 앱을 보여 드리겠다”고 말하며 시연 중심으로 전개한다.[^26] UI와 기능이 “관리자 여부”에 따라 달라지므로, 시연 영상은 **2가지(직원용/관리자용)**로 준비했다고 안내한다.[^13]

3.5 직원용 데모: 실행-로그인-냉장고 구조-음식 등록-내 음식 관리-계정 기능[^27]

📸 1:51

3.5.1 앱 실행과 스플래시(런치 로고) 연출[^28]

직원용 영상은 런치 로고로 시작해 스플래시 화면이 나온다.[^29] 스플래시 화면은 애니메이션 효과를 주기 위해 GIF 이미지를 활용했다고 설명한다.[^30] 즉, 첫 인상 단계에서 정적인 화면이 아니라 움직이는 이미지를 사용해 “앱이 살아있는 느낌”을 주려는 의도다.[^30]

3.5.2 자동 로그인과 메인 진입 흐름[^31]

“지금은 로그인한 상태여서” 자동 로그인으로 바로 메인으로 들어간다고 말한다.[^32] 이는 사용자가 반복적으로 로그인하는 번거로움을 줄이는 전형적인 UX 결정이며, 발표에서는 “로그인되어 있으면 곧바로 메인”이라는 흐름을 보여준다.[^32]

3.5.3 냉장고 리스트와 그룹화 개념[^33]

메인 화면에서 “관리자가 생성해 둔 냉장고”가 보인다고 설명한다.[^34] 그리고 관리자가 냉장고 사용자를 “그룹으로 묶어둔 상태”라고 덧붙인다.[^35] 즉, 냉장고는 단순히 하나가 아니라 복수 생성될 수 있고, 사용자들은 관리자가 설정한 그룹 단위로 냉장고 접근/표시가 조직될 수 있는 구조다.[^35]

3.5.4 냉장고 내부: 공용 음식 + 다른 직원 음식, 냉동실도 동일[^36]

냉장고 “문을 열면” 공용 음식과 다른 직원들의 음식들이 보이고, 냉동실도 마찬가지라고 말한다.[^37] 여기서 직원은 자기 음식만 보는 것이 아니라, 공용 냉장고라는 특성상 다른 사람의 음식도 함께 노출된다.[^37]

3.5.5 핵심 기능: 사진 1회 촬영으로 음식 등록(입력 최소화)[^14]

직원용 시연에서 발표자는 “우리빙고의 주요 기능인 음식 등록 방법”에 대해 특히 고민을 많이 했다고 강조한다.[^38] 문제 정의는 명확하다: 직원이 음식을 넣을 때마다 이름이나 날짜 등을 번거롭게 입력해야 한다면 사용성이 떨어진다.[^39]

따라서 팀은 다음을 목표로 기능을 구현했다고 말한다.

  • “촬영 한 번으로 모든 과정을 생략”할 수 있게 했다.[^40]
  • 즉, 사진 촬영을 트리거로 등록이 진행되어 입력 작업을 최소화한다.[^40]

실제로 시연에서는 사진을 찍어 등록을 수행하고, 등록 후 냉동실 화면으로 가면 방금 등록한 음식을 확인할 수 있다고 보여준다.[^41]

[!TIP] 등록 UX 설계 포인트
사용자가 “냉장고에 넣는 순간” 가장 귀찮아하는 작업(텍스트 입력)을 제거하고, 촬영을 단일 행동으로 만드는 것이 채택된 핵심 전략이다.[^39]

3.5.6 ‘나의 냉장고’: 내 음식 목록과 ‘연장’ 버튼 활성 조건[^42]

직원은 “나의 냉장고”에서 자신이 보관한 내용물을 확인할 수 있다고 말한다.[^43] 중요한 정책/규칙이 하나 제시된다:

  • 남은 기간이 1일 남았을 때 ‘연장하기’ 버튼이 활성화된다.[^44]
  • 시연에서도 “1일”이 되면 버튼이 활성화되는 모습을 보여준다.[^44]

그리고 연장을 누르면, 관리자가 설정한 연장 기간에 따라 보관 기간이 연장된다고 설명한다.[^45] 시연에서는 연장 후 남은 기간이 “2일로 변경”되는 장면을 언급한다.[^46] 또한 삭제 기능도 가능하다고 덧붙인다.[^47]

정리하면 직원의 개인 관리 기능은 다음 흐름이다.

  • 내 음식 확인[^43]
  • 남은 기간 1일 → ‘연장하기’ 버튼 활성[^44]
  • 연장 시 관리자 정책(연장 가능 기간)에 맞춰 기간 증가[^45]
  • 필요 시 삭제[^47]

3.5.7 정보 탭: 회원 탈퇴, 로그아웃, 비밀번호 변경 + 변경 후 자동 로그아웃[^48]

정보 탭(마이페이지 성격)에는 회원(계정) 탈퇴, 로그아웃, 비밀번호 변경 기능이 있다고 소개한다.[^49] 비밀번호 변경은 “현재 비밀번호와 바꿀 비밀번호”를 입력하고 변경 버튼을 누르는 방식이다.[^50]

특이한 UX/보안 흐름으로, 비밀번호 변경을 누르면 자동 로그아웃되어 로그인 화면으로 돌아간다고 설명한다.[^51] 이후 바뀐 비밀번호로 다시 로그인하는 시연을 보여주며, 로그인이 되는 것으로 직원용 데모를 마친다.[^52]

3.6 관리자용 데모: 냉장고 생성/수정, 공용 등록 토글, 폐기 목록, 그룹/권한 관리[^53]

📸 4:50

3.6.1 관리자 전용 UI: 냉장고 추가/수정 버튼 노출[^54]

관리자 영상으로 전환되며, 관리자는 메인에서 ‘냉장고 추가’ 버튼과 ‘수정’ 버튼이 보인다고 설명한다.[^55] 이는 직원 UI와 관리자 UI가 확실히 분기됨을 시각적으로 증명하는 요소다.[^13]

3.6.2 냉장고 추가: 이름, 냉장/냉동 칸 수, 보관 기간/연장 기간 정책[^56]

관리자가 냉장고 추가를 하면 다음을 설정할 수 있다고 발표한다.

  • 냉장고 이름[^57]
  • 냉장칸 수, 냉동칸 수(발표에서는 “한수/국 한수” 등으로 발화되나 문맥상 칸 수 설정)[^57]
  • 보관 기간(“현재 보관 기능은 최대 30일까지 가능”)[^58]
  • 연장 가능 기간(“5일”)을 설정[^59]

즉, 관리자는 단순히 냉장고를 만드는 것뿐 아니라 운영 정책(최대 보관 기간, 연장 가능 기간)을 정의한다.[^58]

3.6.3 냉장고 수정: 이름 제외 나머지 데이터 수정 가능[^60]

수정 버튼으로 들어가면 냉장고 이름을 제외한 나머지 데이터들을 수정 가능하게 해두었다고 말한다.[^61] 방금 설정/입력한 데이터가 화면에 보이는 형태로 나타난다는 설명도 덧붙인다.[^62]

3.6.4 관리자도 음식 등록: 공용 여부 토글로 ‘공용 물품’ 지정[^63]

관리자는 냉동실로 들어가 음식을 등록하는 시연을 한다.[^64] 이때 관리자만의 추가 기능으로, 토글 버튼을 통해 공용 여부를 선택할 수 있다고 말한다.[^65] 공용으로 선택하면 해당 물품이 “공용 물품”이 된다.[^66]

등록을 완료하면 하단에 스낵바가 뜬다고 언급한다.[^67] 이는 사용자에게 “등록 완료” 피드백을 즉각 제공하기 위한 UI 패턴이다.[^67]

마이페이지에서는 공용 음식과 관리자 본인 음식을 등록한 것도 볼 수 있다고 설명한다.[^68] 그리고 직원과 마찬가지로 연장/삭제가 가능하다고 한다.[^69] 시연에서는 실제로 삭제를 수행하는 장면을 보여준다.[^70]

3.6.5 폐기 목록: 보관 기간 지난 음식 확인 및 삭제(폐기 처리)[^71]

관리자는 “특별히 버튼”을 통해 보관 기간이 지난 폐기 목록을 볼 수 있다고 한다.[^72] 폐기될 음식은 삭제할 수 있는 기능이 구현되어 있다고 설명한다.[^73]

여기서 중요한 점은, 앱이 단순히 “기간 표시”에서 끝나는 것이 아니라 관리자에게 만료된 항목을 모아 보여주는 작업 화면(폐기 목록)을 제공한다는 점이다.[^72]

[!IMPORTANT] 공용 냉장고의 운영 기능
공용 냉장고는 “등록”만큼이나 “폐기(정리)”가 핵심 운영 업무이므로, 만료 목록과 삭제 기능을 관리자 워크플로로 제공한다.[^72]

3.6.6 그룹 관리: 사용자 검색, 관리자 권한 부여/변경, 사용자 삭제 및 재추가[^74]

관리자는 또한 그룹 관리가 가능하다고 말한다.[^75] 구체적으로는:

  • 그룹원을 검색할 수 있다.[^76]
  • 관리자가 현재 일반 유저로 되어 있는 아이디를 관리자로 변경할 수 있다.[^77]
  • 관리자 변경을 하면 관리자 기능이 부여된다고 말한다.[^78]
  • 사용자 삭제도 가능하다.[^79]
  • 방금 삭제한 직원을 다시 추가하는 기능도 가능하게 해두었다고 설명한다.[^80]

이 흐름은 조직 내 인원 변동(입퇴사/프로젝트 단위 참여 등)을 반영한 운영 기능으로 읽히며, 발표에서는 “권한 변경/삭제/재추가”까지 제공하는 것을 강조한다.[^80]

3.7 데모 이후 산출물: 유저 플로우와 기능 명세서 소개[^81]

📸 7:56

영상 시연을 모두 보여준 뒤, 발표자는 “사원(직원)과 관리자 유저 플로우”를 만들어 보았다고 말하며 화면(도식)을 보여준다.[^82] 즉, 역할별 사용자 여정을 시각화한 산출물이 있음을 공유한다.[^82]

또한 “페이지 기능 명세서”가 있으며, 기능을 “총 가지로 구분”해 자세한 내용들을 작성해 두었다고 설명한다.[^83] 발표 텍스트가 끊겨 구체적인 ‘총 몇 가지’가 명확히 전달되진 않지만, 기능을 분류하고 문서화했음을 강조한다.[^83]

3.8 기술 구현: Firebase, Awesome Notifications, 주요 코드(전체 노출 화면/사진 등록)[^84]

📸 8:30

기술 스택 설명에서 발표자는 다음을 명시한다.

  • 데이터는 Firebase를 사용했다.[^85]
  • 알림은 Awesome Notifications를 사용하여 보관기간 임박 등 “곧 음식이 있다”는 알림을 받을 수 있게 했다고 말한다.[^86]

또한 “주요 소스 코드”로는 다음을 작성/제시했다고 한다.

  • 등록된 전체 음식 노출 화면[^87]
  • Firebase로 사진을 등록하는 코드[^87]

즉, 앞서 강조한 ‘사진 한 번 등록’ 기능의 구현이 Firebase 업로드/저장 로직과 연결되어 있고, 앱에서는 전체 음식이 모이는 리스트/보드 화면이 존재한다는 점을 시사한다.[^87]

3.9 개발 원칙과 UI 전략: 편의성 최우선 + 애니메이션 라이브러리 + 클린 코드 목표(MVVM/커스텀 위젯)[^88]

📸 0:45

팀은 프로젝트 전반에서 “편의성을 가장 중요하게 고려”했다고 다시 강조한다.[^21] 그리고 다양한 애니메이션 라이브러리로 흥미로운 UI를 제공하려 노력했다고 말한다.[^89]

기능 구현 측면에서는 Firebase 라이브러리를 적극 활용해 주요 기능을 구현했다고 말하고,[^90] 코드 품질 목표로 “클린한 코드 구현”을 내세운다.[^91] 이를 위해:

  • MVVM 패턴을 사용[^91]
  • 커스텀 위젯을 만들었다고 설명한다.[^91]

3.9.1 디자인 시스템 사전 세팅: 폰트/사이즈/컬러 통일[^92]

통일성 있는 UI와 효율적인 작업을 위해, 앱에서 사용할 폰트, 폰트 사이즈, 컬러를 사전에 세팅해 둔 모습을 보여준다고 말한다.[^93] 이는 개발자들이 화면별로 임의 값을 쓰는 것을 방지하고, 공통 스타일을 재사용하는 방식으로 생산성과 일관성을 확보하려는 접근이다.[^93]

3.10 협업 방식과 결과: 페이지별 역할 분담, 초보 6명의 몰입, 465 커밋의 균등 분포[^10]

📸 9:35

팀은 6명이 페이지별로 역할을 분담했으며, 각자 담당 페이지에 필요한 모든 기능 개발과 리팩토링을 담당했다고 말한다.[^94]

구성원 전원이 “개발 경력이 없는 사람들”이라서, 거의 매일 밤 늦게까지 프로젝트 작업을 했던 것 같다고 회고한다.[^95] 프로젝트 종료 후 확인해보니 6명이 거의 동등하게 커밋을 했다고 말하며,[^96] 이를 선생님께 보여드렸더니 놀라셨던 것 같다는 반응도 전한다.[^97]

그리고 구체적 수치로, 총 465개 커밋을 했다는 것을 보여주고 싶었다고 말한다.[^98] 이 수치는 팀의 작업량과 협업 참여도가 고르게 분배되었음을 뒷받침하는 “정량 지표”로 제시된다.[^98]

3.11 그라운드 룰과 팀 문화: 음악, 일정 체크, 토이로 지식 공유[^99]

📸 10:18

발표자는 팀에 “그라운드룰 미션”이 있었다고 말한다.[^100] 그 내용으로:

  • 개발할 때 항상 음악을 틀어놓고 개발했다고 한다.[^101] (방에 음악 들으러 오시는 분들도 있었다는 언급으로, 팀 문화가 공개적으로 인식될 정도였음을 시사)[^101]
  • 프로젝트 자체를 즐기려고 노력했다고 덧붙인다.[^102]
  • 매일 오전 일정을 체크하고, 서로 모르거나 알게 된 기능들을 **토이(공유)**를 통해 적극적으로 의견을 나누었다고 설명한다.[^103]

여기서 토이(toy)는 문맥상 “가볍게 공유/시연/토론하는 시간”으로 사용된 것으로 보이며, 초보 팀에서 학습과 개발을 병행하기 위한 지식 교환 메커니즘이었다고 해석된다.[^103]

3.12 추가 자료 안내와 마무리: Figma/Git 주소 공유, 발표 종료[^104]

📸 10:50

마지막으로 발표자는 “기타 자세한 내용이나 궁금하신 것들은” **피그마(Figma)**나 **깃(깃 주소)**를 통해 확인할 수 있도록 주소를 남긴다고 말한다.[^105] 그리고 이것으로 슈퍼점 팀의 발표를 마치며 감사 인사를 전한다.[^106]

4. 핵심 통찰[^107]

  1. 공용 냉장고 문제는 “보관”이 아니라 운영(등록·추적·폐기·권한) 문제이며, 앱은 이를 역할 기반 워크플로로 쪼개 해결한다.[^7]

    • 실행 시사점: 직원 UI는 입력을 최소화하고, 관리자 UI는 정책(기간/연장)과 정리(폐기 목록), 권한 관리를 한 곳에 모아라.[^58]

  2. 편의성을 실제로 만들려면 “좋은 의도”가 아니라 행동 1회로 끝나는 UX 같은 구체적 설계가 필요하다(촬영 한 번 등록).[^40]

    • 실행 시사점: 사용 빈도가 높은 행위(등록)에 대해 텍스트 입력/단계 수를 극단적으로 줄이는 KPI(예: 등록 완료까지 탭 수)를 잡아라.[^39]

  3. 기간 기반 도메인(음식 보관)은 알림과 결합될 때 가치가 커진다.[^86]

    • 실행 시사점: 보관기간 임박, 1일 남음(연장 버튼 활성) 같은 규칙을 UI 상태와 알림 정책으로 일관되게 연결하라.[^44]

  4. 초보 팀의 생산성은 “개인 실력”보다 표준화(디자인 시스템) + 구조화(MVVM) + 소통 루틴에서 크게 개선된다.[^93]

    • 실행 시사점: 폰트/컬러/사이즈를 초기에 고정하고, 페이지별 오너십을 주되 리팩토링 책임까지 포함시켜 품질을 맞춰라.[^94]

  5. 협업의 건강함은 결과물뿐 아니라 커밋 분포 같은 정량 지표로도 드러난다(465 커밋, 균등 참여).[^^98]

    • 실행 시사점: 팀의 참여 편차를 조기에 발견하려면 주간 커밋/PR 분포와 리뷰 참여도를 함께 트래킹하라.[^96]

참고(콘텐츠 정보)[^108]

  • 제목: 공용 냉장고 관리 앱 | 오름캠프 Flutter 모바일 앱 개발 과정 1기 프로젝트[^108]
  • 채널: 모두의연구소[^108]
  • 길이: 11분 3초[^108]
  • 링크: https://www.youtube.com/watch?v=QYjhNn_KxWI[^108]

[^1]: @[00:00] “저희 발표하도록 하겠습니다” [^2]: @[00:06]~@[00:55] 인사, 팀/앱 소개, 목표 및 편의성 강조 흐름 [^3]: @[00:12] 발표자 소개 및 팀 맥락, @[00:23] 앱 이름 소개 [^4]: @[00:00]~@[11:02] 발표 전체 흐름(소개→데모→기술/협업→마무리) [^5]: @[00:12] “발표 맡은 … 한 상인”, @[00:18] 팀 구성/팀명 설명 [^6]: @[00:38] “공용 냉장고 관리 앱… 쉽게 확인 및 관리… 목표” [^7]: @[01:01] “관리자는 음식 주인이 누구인지… 기한 지난 음식은 무엇인지… 한눈에 체크” [^8]: @[01:01]~@[01:17] “유저의 요구 사항… 요구 사항 취합 분석 선행이 필수” [^9]: @[01:17] 인터뷰/사무실 방문, @[01:24] 국내외 레퍼런스 참고 [^10]: @[09:35]~@[10:12] 역할분담, 비개발 경력, 커밋 균등/465 커밋 [^11]: @[08:30] Firebase, @[08:37] Awesome Notifications, @[09:11] MVVM/커스텀 위젯, @[10:12] 465 커밋 [^12]: @[01:30] “영상으로 먼저…”, @[07:56] 유저 플로우, @[08:30] 기술, @[09:35] 협업, @[10:55] 마무리 [^13]: @[01:42] “관리자 여부를 따라서 UI… 기능이 달라… 영상 두 가지” [^14]: @[02:34]~@[02:50] “음식 등록 방법… 촬영 한 번으로…” [^15]: @[08:30] Firebase, @[08:37] Awesome Notifications, @[09:11] MVVM/커스텀 위젯 [^16]: @[00:12] “팀원 한 상인” [^17]: @[00:18] 팀 6명, 부모/자식 클래스 비유, 팀명 슈퍼점 [^18]: @[00:23] “앱 이름은 우리 빙고” [^19]: @[00:32] “우리… 냉장고의 다른 말인 빙고…” [^20]: @[00:38] “공용 냉장고 관리 앱… 목표” [^21]: @[00:45] “앱 사용자의 편의성을 강조… 중점” [^22]: @[00:52] 사진 등록 한 번, 임박 시 알림 [^23]: @[01:01]~@[01:17] 요구사항 존재 → 취합/분석 선행 필요 [^24]: @[01:17] “인터뷰 및 사무실 방문… 니즈와 에로 사항… 기획” [^25]: @[01:24] “국내외… 앱… 레퍼런스… 장단점” [^26]: @[01:30] “영상으로 먼저 앱…” [^27]: @[01:36]~@[04:16] 직원용 데모 구간 [^28]: @[01:51] 런치 로고/스플래시 [^29]: @[01:51] “런치 로고… 스플래시” [^30]: @[01:56] “스플래시… 애니메이션… GIF” [^31]: @[02:00]~@[02:05] 자동 로그인/메인 진입 [^32]: @[02:00] “로그인한 상태… 자동 로그인… 메인” [^33]: @[02:05]~@[02:14] 냉장고 표시/그룹 [^34]: @[02:05] “관리자가 생성해 둔 냉장고” [^35]: @[02:10] “사용자에 따라서 그룹으로 묶어둔” [^36]: @[02:14]~@[02:19] 냉장고 내부/냉동실 [^37]: @[02:14] “공용 음식… 다른 직원들 음식… 냉동실도” [^38]: @[02:32]~@[02:35] “주요 기능… 고민” [^39]: @[02:40] “이름이나 날짜… 번거롭게 입력…” [^40]: @[02:42]~@[02:50] “촬영 한 번으로… 과정 생략… 구현” [^41]: @[02:55]~@[03:05] 사진 찍어 등록, 냉동실에서 확인 [^42]: @[03:05]~@[03:36] 나의 냉장고/연장 조건/연장 결과 [^43]: @[03:05] “나의 냉장고… 내가 보관한 내용물” [^44]: @[03:10]~@[03:29] “남은 기간 1일… 연장 버튼 활성화” [^45]: @[03:29] “관리자가 설정한 연장 기간… 연장” [^46]: @[03:34] “2일로… 변경” [^47]: @[03:36] “삭제도 가능” [^48]: @[03:43]~@[04:16] 정보 탭/비밀번호 변경/자동 로그아웃/재로그인 [^49]: @[03:43] “회원 탈퇴… 로그아웃… 비밀번호 변경” [^50]: @[04:03] “현재 비밀번호… 바을 비밀 번호… 변경” [^51]: @[04:03] “변경… 자동으로 로그아웃… 로그인 화면” [^52]: @[04:03]~@[04:16] 바뀐 비밀번호로 재로그인 시연 [^53]: @[04:19]~@[07:40] 관리자용 데모 구간 [^54]: @[04:50] 관리자 버튼 노출 [^55]: @[04:50] “냉장고 추가 버튼… 수정 버튼” [^56]: @[04:57]~@[05:15] 냉장고 추가 시 설정값, 최대 30일, 연장 5일 [^57]: @[04:57] “냉장고 이름… 냉장/냉동… 설정” [^58]: @[05:07] “보관 기능은 최대 30일까지” [^59]: @[05:11] “연장 가능 기간도 5일” [^60]: @[05:19]~@[05:28] 수정 가능 범위 [^61]: @[05:19] “이름 제외… 나머지… 수정 가능” [^62]: @[05:28]~@[05:35] “데이터가 이렇게 보이게” [^63]: @[05:44]~@[06:05] 공용 여부 토글, 공용 등록, 스낵바 [^64]: @[05:44]~@[05:50] 냉동실 가서 등록 [^65]: @[05:50] “토글 버튼으로 공용 여부 선택” [^66]: @[05:56] “공용이라고 선택… 공용 물품” [^67]: @[06:05] “등록… 하단 스낵바” [^68]: @[06:05]~@[06:23] 마이페이지에서 공용/본인 음식 확인 [^69]: @[06:23] “연장 삭제도 가능합니다” [^70]: @[06:32]~@[06:40] 삭제 시연 [^71]: @[06:40]~@[06:54] 폐기 목록/삭제 기능 [^72]: @[06:40]~@[06:43] “폐기 목록” [^73]: @[06:43]~@[06:54] “폐기 될 음식… 삭제… 기능” [^74]: @[06:55]~@[07:33] 그룹 관리/권한 변경/삭제/재추가 [^75]: @[06:55] “그룹 관리가능” [^76]: @[06:56]~@[07:04] “그룹원 검색” [^77]: @[07:04]~@[07:11] “유저… 관리자로 변경” [^78]: @[07:11] “관리자 기능 부여” [^79]: @[07:19] “삭제도 가능” [^80]: @[07:19]~@[07:33] 삭제한 직원을 다시 추가 [^81]: @[07:56]~@[08:24] 유저 플로우, 기능 명세서 소개 [^82]: @[07:56] “유저 플로우… 만들어 봤습니다” [^83]: @[08:07]~@[08:24] “페이지 기능 명세서… 기능 구분… 작성” [^84]: @[08:30]~@[08:57] Firebase/알림/주요 소스 코드 언급 [^85]: @[08:30] “데이터는 파이어베이스” [^86]: @[08:30]~@[08:37] “어섬 노티피케이션… 알림” [^87]: @[08:43]~@[08:57] “전체 음식을 노출… 사진 등록 코드” [^88]: @[09:01]~@[09:23] 편의성/애니메이션/Firebase 활용/클린 코드/MVVM [^89]: @[09:01] “다양한 애니메이션 라이브러리… UI” [^90]: @[09:05] “파이어베이스… 적극 활용” [^91]: @[09:11] “클린한 코드… mvvm 패턴… 커스텀 위젯” [^92]: @[09:23]~@[09:35] 폰트/사이즈/컬러 사전 세팅 [^93]: @[09:23]~@[09:35] “폰트… 폰트 사이즈 컬러… 세팅” [^94]: @[09:35]~@[09:46] 페이지별 역할 분담, 기능 개발+리팩토링 [^95]: @[09:46] “개발 경력이 없는… 매일밤 늦게까지” [^96]: @[10:01] “거의 동등하게 커밋” [^97]: @[10:07]~@[10:12] 선생님 반응(놀람) [^98]: @[10:12] “465개 커밋” [^99]: @[10:18]~@[10:46] 그라운드룰/음악/일정 체크/토이 공유 [^100]: @[10:18] “그라운드룰 미션” [^101]: @[10:24]~@[10:30] “항상 음악을 틀어놓고 개발” [^102]: @[10:30]~@[10:36] “프로젝트 자체를 즐기려고” [^103]: @[10:36]~@[10:46] “매 오전 일정 체크… 토이… 의견” [^104]: @[10:50]~@[11:02] 피그마/깃 주소 안내, 발표 종료/감사 [^105]: @[10:50]~@[10:55] “피그 마나 기터 주소… 확인…” [^106]: @[10:55]~@[11:02] “발표… 마치도록… 감사합니다” [^107]: @[00:38]~@[10:46] 목표/UX/기술/협업 전반에서 도출 [^108]: 사용자 제공 메타데이터(제목/채널/길이/링크) 및 영상 정보 전체

← 프로젝트에서 보기