프로젝트에서 보기 →

밴드 커뮤니티 앱 | 오름캠프 Flutter 모바일 앱 개발 과정 1기 프로젝트

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

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

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

[? 질문] 이 프로젝트(밴드 커뮤니티 앱)는 어떤 문제를 해결하려고 만들어졌는가[^4]
[= 답] 밴드(음악) 팀 활동에서 카카오톡 중심 소통의 불편함을 줄이고, 소통과 일정 관리를 더 편하게 해주는 전용 커뮤니티 앱이 필요하다고 판단해 이를 해결하려고 만들었다.[^4]

[? 질문] 앱은 어떤 기술 스택으로 어떤 기능들을 구현했는가[^2]
[= 답] Dart/Flutter로 앱을 만들고, 인증/DB/스토리지 등 백엔드는 Firebase를 사용했으며, 소스 관리는 Git, 디자인은 Figma로 진행했다. 기능은 로그인·비밀번호 재설정·회원가입·프로필 설정·밴드 목록/개설·밴드 상세(초대/일정/합주곡/투표) 흐름으로 구성된다.[^2][^6][^12][^18]

[? 질문] 현재 앱의 개발 상태와 앞으로의 계획은 무엇인가[^21]
[= 답] 아직 남은 기능이 많아 계속 개발 중이며, 코드가 특정 모델에 많이 모여 있어 향후 전체 리팩토링을 통해 클린 아키텍처로 개선할 예정이고, 3월 개발 완료를 목표로 진행한다.[^21][^22]

2. 큰 그림[^1]

이 콘텐츠는 오름캠프 Flutter 모바일 앱 개발 과정 1기 프로젝트로 제작된 “밴드 커뮤니티 앱”의 발표 영상이며, 앱을 만들게 된 배경(문제의식)과 사용 기술, 그리고 화면/기능을 로그인부터 밴드 상세 기능까지 순서대로 시연·설명한다.[^1][^2][^5] 발표자는 밴드 활동에서 느낀 실제 불편을 출발점으로, 기존 커뮤니티 서비스의 실용성 문제까지 언급하며 향후 기능 확장(웹 포함) 가능성도 함께 제시한다.[^4][^5]

  • 이 앱은 밴드 팀 커뮤니케이션과 일정 관리를 더 실용적으로 만들려는 목적에서 출발한다.[^4]
  • 구현은 Flutter + Firebase 조합을 중심으로, 인증(로그인/재설정/회원가입)과 프로필 이미지 업로드(스토리지), 데이터 저장(DB)까지 연결된 흐름을 갖춘다.[^2][^11][^16]
  • 현재는 기능 구현이 진행 중이며, 구조적으로는 리팩토링/클린 아키텍처 전환 계획을 명확히 언급한다.[^21]

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

3.1 발표 시작 및 프로젝트/기술 스택 소개[^1][^2]

📸 0:00

발표자는 프로젝트 발표를 시작한다고 말하며, “밴드 커뮤니티 앱(발표에서 ‘벤다 할레’로 언급)”에 사용된 기술 스택을 먼저 나열한다.[^1][^2] 여기서 기술 스택은 다음처럼 정리된다.[^2][^3]

  • 개발 언어/프레임워크: Dart, Flutter[^2]
  • 백엔드/서비스: Firebase[^2]
  • 협업/형상관리: Git으로 소스 관리[^3]
  • 디자인: Figma로 전체 디자인 제작[^3]

이 구성은 “모바일 클라이언트(Flutter) + 인증/데이터/이미지 저장(Firebase) + 협업(Git) + UI 설계(Figma)”로 이어지는 전형적인 앱 프로젝트 파이프라인을 따른다고 볼 수 있으며, 발표자는 이를 간단히 소개한 뒤 “왜 만들었는가”로 넘어간다.[^3][^4]

3.2 제작 동기: 카톡 소통의 불편, 기존 커뮤니티의 낮은 실용성[^3][^4][^5]

📸 0:16

발표자는 앱 제작 이유를 “첫 번째, 일상생활 속 필요성을 느꼈기 때문”이라고 제시한다.[^3] 구체적으로는 본인이 취미로 밴드 활동을 하면서 팀원들과의 소통을 카카오톡만으로 진행할 때 불편함을 경험했고, 이 불편을 해결하기 위해 “소통과 일정 관리를 더 편하게 하는 앱이 있으면 좋겠다”는 문제의식을 갖게 되었다고 설명한다.[^4]

이어 “두 번째” 이유를 말하며, 현존하는 밴드 커뮤니티들이 실용성이 떨어지고, 관리도 잘 안 되는 상태라고 평가한다.[^5] 그래서 단순히 현재 기능에서 끝나는 것이 아니라, 추후 여러 기능을 추가하여 “더 실용적인 커뮤니티 앱”과 “웹 제작”까지도 염두에 두고 있다고 말한다.[^5]

정리하면 발표자가 세운 문제 정의는 크게 두 갈래다.[^4][^5]

  1. 밴드 팀 운영에서 범용 메신저(카톡)만으로는 소통/일정 관리가 불편하다.[^4]
  2. 기존 밴드 커뮤니티 서비스는 실용성/관리 측면에서 아쉽고, 개선 여지가 크다.[^5]

[!IMPORTANT] 문제의식의 성격[^4][^5]
이 발표에서 문제의식은 “기술적으로 새로움”보다 “현장에서 실제로 겪는 운영 불편(소통/일정)”을 직접 해결하려는 동기에서 출발한다.[^4]

3.3 기능 설명으로 전환: “지금부터는 들어간 기능 설명”[^6]

📸 0:54

발표자는 이제부터 앱에 들어간 기능을 설명하겠다고 선언하고, 화면 단위로 순서대로 소개한다.[^6] 이 전환은 발표 구조상 “동기 → 기능(화면) 나열” 형태로, 데모/시연 중심의 프로젝트 발표에서 흔히 쓰이는 구성을 따른다.[^6][^20]

3.4 로그인 화면: 정규식 검증 + Firebase 에러코드 스낵바 처리[^6][^7][^8]

📸 0:54

첫 번째 기능으로 로그인 화면을 소개한다.[^6][^7] 로그인에서는 다음 처리가 들어가 있다고 설명한다.[^8]

  • 자체적으로 정규식 값 validator(유효성 검사) 기능을 통해 1차적으로 이메일/비밀번호의 “유일성 체크”를 진행한다(발표 표현 그대로 기술).[^^8]
  • 로그인 실패 시 Firebase로부터 받는 에러 코드를 정리하여 **스낵바(snackbar)**로 표시해준다.[^8]

여기서 발표의 포인트는 “로그인 실패를 그냥 실패로 두지 않고, Firebase 인증에서 내려주는 에러 코드를 분류/정리해 사용자에게 스낵바로 보여준다”는 UX 처리에 있다.[^8]

[!TIP] 로그인 UX에서 강조한 구현 포인트[^8]
(1) 클라이언트 단에서 정규식 기반 유효성 검증을 먼저 수행하고, (2) 서버/서비스(Firebase)에서 내려온 오류는 코드 기반으로 정리해 스낵바로 안내한다.[^8]

3.5 비밀번호 재설정: Firebase Authentication의 이메일 재설정 기능 사용[^9][^10]

📸 1:15

다음으로 비밀번호 재설정 화면을 보여준다.[^9] 이 화면은 Firebase Authentication이 제공하는 이메일 재설정 기능을 사용하며, 사용자가 작성(입력)한 이메일로 비밀번호 재설정 메일이 발송된다고 설명한다.[^10]

즉, 앱이 자체적으로 메일 서버를 운영하는 형태가 아니라, Firebase Auth의 표준 기능을 연결해 “사용자 입력 이메일 → 재설정 메일 발송” 플로우를 구현한 것이다.[^10]

3.6 회원가입: 이메일/비밀번호/비밀번호 확인 + 유효성 검증 + 실패 시 스낵바[^11][^12]

📸 1:27

다음 화면은 회원가입이다.[^11] 발표자는 회원가입이 다음 입력/검증 흐름으로 진행된다고 말한다.[^12]

  • 이메일, 비밀번호, 비밀번호 확인을 통해 가입 진행[^12]
  • 세 항목 모두 자체 유효성 검증을 마친 후 회원가입을 시도[^12]
  • 회원가입이 정상 처리되지 않을 경우, 스낵바로 에러 메시지를 표시[^12]

여기서 로그인과 마찬가지로 “검증 → 시도 → 실패 시 스낵바 안내” 패턴을 유지하고 있음을 알 수 있다.[^8][^12]

3.7 가입 완료 후 프로필 설정으로 이동[^13]

📸 1:40

회원가입이 정상 완료되면 프로필 설정 화면으로 넘어간다고 설명한다.[^13] 즉, 계정 생성(인증) 단계와 사용자 프로필(앱 내에서 사용할 표시 정보/사진 등) 입력 단계를 분리한 사용자 온보딩 흐름이다.[^13]

3.8 프로필 설정(이미지 피커 → 크롭): 갤러리/촬영 선택 후 원하는 형식으로 자르기[^14][^15]

📸 1:46

프로필 설정에서는 먼저 프로필 사진을 다룬다.[^14] 발표자는 **image picker(이미지 피커)**를 사용해 사용자의 갤러리에서 선택하거나 촬영을 통해 프로필 사진을 선택할 수 있다고 말한다.[^14]

그리고 이미지 피커로 사진 선택이 완료되면, 다음 단계로 넘어가 **crop(크롭)**을 사용해 원하는 형식으로 사진을 자를 수 있다고 설명한다.[^15] 즉 “선택(또는 촬영) → 크롭”의 2단계 이미지 처리 UX를 구현했다는 의미다.[^14][^15]

3.9 프로필 기본 정보 입력 + 세션 선택, 그리고 Firebase 저장 구조(스토리지 vs DB) 분리[^16][^17]

📸 2:08

프로필 기본 필드에는 다음을 입력할 수 있다고 한다.[^16]

  • 이름[^16]
  • 연락처[^16]
  • 한줄 소개[^16]
  • “세션 선택” 진행(밴드에서 담당 파트/세션으로 해석되는 항목)[^16]

저장 방식은 데이터 유형에 따라 Firebase 내 저장소를 분리한다.[^17]

  • 프로필 사진: Firebase Storage에 저장[^17]
  • 나머지 프로필 텍스트/정보: Firebase Database에 저장[^17]

이 설명은 “바이너리(이미지)는 스토리지, 구조화 데이터는 DB”로 나누는 일반적인 설계를 따르고 있음을 보여준다.[^17]

[!NOTE] 데이터 저장을 분리한 이유로 읽히는 지점[^17]
발표자는 이유를 길게 설명하진 않지만, 사진은 스토리지에, 나머지는 DB에 저장한다고 명시해 데이터 타입에 맞는 저장소 사용을 강조한다.[^17]

3.10 메인 페이지: 소속 밴드 확인 + 밴드 설정 + 프로필 수정[^18][^19]

📸 2:19

다음은 메인 페이지다.[^18] 이 화면에서 사용자는 다음을 할 수 있다고 한다.[^19]

  • 현재 자신이 소속되어 있는 밴드 목록을 확인[^19]
  • 밴드 설정을 진행[^19]
  • 프로필 수정을 진행[^19]

메인 페이지의 역할은 “앱 진입 후 허브”로서, 사용자의 소속 밴드들을 보여주고 계정/밴드 관련 진입점을 제공하는 것이다.[^18][^19]

3.11 밴드 개설: 이미지 피커/크롭 재사용 + 밴드명/소개 입력[^19][^20]

📸 2:32

메인에서 “밴드 개설”을 누르면, 앞서 프로필 사진에서 사용했던 것과 동일하게 이미지 피커와 크롭을 사용하여 밴드 프로필 사진을 선택할 수 있다고 말한다.[^20] 그리고 밴드명과 소개를 입력할 수 있다고 설명한다.[^20]

즉, “프로필 이미지 처리 컴포넌트(피커/크롭)”를 사용자 프로필뿐 아니라 밴드 프로필에도 재사용하고 있음을 발표자가 직접 언급한다.[^20]

3.12 밴드 상세: 공유 링크 초대/가입 + 일정 추가 + 합주곡 등록 + 투표 기능[^20][^21]

📸 2:32

다음은 밴드 상세 페이지 화면이다.[^20] 발표자가 설명한 밴드 상세 기능은 다음과 같이 구성된다.[^21]

  1. 초대/가입
  • 밴드 개설 후 공유 링크를 통해 팀원 초대가 가능[^21]
  • 초대된 사람은 해당 밴드에 가입할 수 있음[^21]
  1. 밴드 일정 추가
  • 장소와 시간을 통해 밴드 일정을 추가할 수 있음[^21]
  1. 합주곡 등록
  • 노래 제목과 이름을 입력하여 합주곡 등록이 가능[^21]
  1. 투표 기능
  • 화면 아래에 투표 기능이 포함[^21]
  • 노래나 장소 등을 등록해 팀원끼리 투표를 진행할 수 있음[^21]

이 파트는 앱의 “밴드 운영” 중심 기능을 한 번에 모아 보여준다. 초대(팀 구성) → 일정(운영) → 합주곡(콘텐츠/리스트) → 투표(의사결정) 순으로, 밴드 활동에서 자주 발생하는 협업 과정을 기능으로 번역한 구성이다.[^21]

3.13 앱 시연 영상 언급[^21]

📸 2:41

발표자는 “다음은 간단한 앱 시연 영상”이라고 말하며 실제 동작 화면을 보여주는 구간으로 넘어간다.[^21] 다만 제공된 텍스트에는 시연에서 어떤 화면이 어떤 순서로 재생되는지의 상세 묘사가 포함되어 있지는 않고, “시연이 있다”는 안내만 확인된다.[^21]

3.14 개발 현황과 개선 계획: 기능 추가 진행 중, 리팩토링/클린 아키텍처 전환, 3월 완료 목표[^22][^23][^24]

📸 3:15

마지막으로 발표자는 현재 개발 상황과 앞으로의 계획을 공유한다.[^22]

  • 아직 기능이 많이 남아 있어 계속 개발(“개화/개발” 진행) 중이라고 말한다.[^22]
  • 기능들이 “너무 모델로 많이 모여” 있어(구조적 응집/분리 문제를 의미하는 표현), 추후 전체 리팩토링을 진행하여 클린 아키텍처로 수정할 예정이라고 한다.[^22]
  • 목표는 3월 개발 완료이며, 계속 진행하겠다고 말하며 발표를 마친다.[^23][^24]

여기서 발표는 단순 기능 나열에서 끝나지 않고, “현재 코드 구조의 문제 인식(모델에 집중)”과 “아키텍처 개선(클린 아키텍처)”이라는 다음 단계의 개발 성숙도를 과제로 제시한다는 점이 특징이다.[^22]

[!WARNING] 유지보수 이슈를 이미 인지하고 있다는 선언[^22]
“기능들이 너무 모델로 많이 모여” 있다는 표현은 기능 추가 과정에서 구조가 한 곳에 집중되며 복잡도가 올라간 상태를 시사하고, 이를 리팩토링과 클린 아키텍처로 해결하겠다고 밝힌다.[^22]

4. 핵심 통찰[^4][^8][^17][^22]

  1. 실사용 맥락에서 출발한 앱 기획은 요구 기능이 명확해진다: 카카오톡 기반 소통의 불편과 일정 관리 니즈가 앱 기능(초대/일정/투표)로 직접 연결된다.[^4][^21]
  2. 인증 플로우에서 “검증 → 실패 피드백(스낵바)”를 일관되게 적용해 사용자 경험을 챙겼다: 로그인/회원가입 모두 정규식 유효성 검증과 에러 안내를 강조한다.[^8][^12]
  3. 데이터 저장을 사진(스토리지)과 텍스트/프로필 정보(DB)로 분리해 Firebase의 역할을 구분했다.[^17]
  4. 개발이 진행되는 동안 구조가 특정 계층(모델)에 몰리는 문제를 인지했고, 이를 리팩토링 + 클린 아키텍처로 해결하겠다는 로드맵을 제시했다.[^22]
  • 실행 시사점(발표자가 예고한 방향을 행동 항목으로 풀어쓰기):[^22][^23]
    • 기능 추가와 병행해 도메인/데이터/프레젠테이션 레이어 분리 등 클린 아키텍처 전환 계획을 구체화한다.[^22]
    • “3월 완료” 목표에 맞춰 남은 기능 리스트를 정리하고, 리팩토링 범위를 단계적으로 쪼개어 진행한다.[^23]

5. 헷갈리는 용어 정리[^2][^8][^10][^17]

  • Dart: Flutter 앱을 작성하는 데 사용하는 프로그래밍 언어로, 본 프로젝트의 개발 언어로 언급된다.[^2]
  • Flutter: Dart 기반 크로스플랫폼 UI 프레임워크로, 앱 개발에 사용했다고 발표자가 명시한다.[^2]
  • Firebase: 구글의 BaaS로, 이 프로젝트에서 인증/DB/스토리지 등 기능에 활용된다.[^2][^10][^17]
  • Firebase Authentication: 비밀번호 재설정 이메일 발송 등 인증 기능을 제공하는 Firebase 구성요소로 언급된다.[^10]
  • Firebase Storage: 프로필 사진을 저장하는 위치로 언급된 Firebase 저장소 서비스다.[^17]
  • Firebase Database: 프로필의 나머지 내용(텍스트 등)을 저장한다고 언급된 데이터베이스다.[^17]
  • 정규식(Regex) validator: 이메일/비밀번호 입력값의 형식 등을 1차로 검증하는 로직으로 소개된다.[^8]
  • 스낵바(Snackbar): 로그인/회원가입 실패 시 에러 메시지를 띄우는 UI 방식으로 언급된다.[^8][^12]
  • 이미지 피커(Image Picker): 갤러리 선택/촬영을 통해 이미지를 가져오는 기능(또는 패키지)로 소개된다.[^14]
  • 크롭(Crop): 선택한 이미지를 원하는 형태로 자르는 처리로 소개된다.[^15]
  • 클린 아키텍처(Clean Architecture): 현재 구조 문제를 해결하기 위해 추후 적용할 아키텍처 스타일로 언급된다.[^22]
  • Figma: 전체 디자인을 제작한 도구로 언급된다.[^3]
  • Git: 소스 관리를 진행한 도구로 언급된다.[^3]

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

  • 제목: 밴드 커뮤니티 앱 | 오름캠프 Flutter 모바일 앱 개발 과정 1기 프로젝트[^1]
  • 채널: 모두의연구소[^1]
  • 길이: 3분 58초[^1]
  • 링크: https://www.youtube.com/watch?v=ZXibtiJ8Vt8[^1]

[^1]: @[00:00] "…프로젝트 발표를 시작하겠습니다" + 사용자 제공 메타데이터(제목/채널/길이/링크). [^2]: @[00:08] "…활용된 기술 스택은 …" [^3]: @[00:16] "…다트 플러터 파이어베이스… 깃… 피그마…" [^4]: @[00:24] "…카카오톡만… 소통에서 불편함… 소통과 일정 관리를 편하게…" [^5]: @[00:42] "…현존하는 밴드 커뮤니티들은 실용성이 떨어지고… 추후… 기능… 커뮤니티 어플리케이션과 웹…" [^6]: @[00:54] "…기능들에 대해 설명…" [^7]: @[00:55] "첫 번째로는 로그인 화면입니다" [^8]: @[01:01] "…정규식… 유일성 체크… 로그인 실패시… 파이어베이스… 에러 코드를… 스바(스낵바)…" [^9]: @[01:15] "…비밀번호 재설정 화면…" [^10]: @[01:21] "…파이어베이스 어센티케이션… 이메일 재설정… 메일…" [^11]: @[01:27] "…회원가입 화면…" [^12]: @[01:33] "…이메일 비밀번호 확인… 유효성 검증… 스낵바…" [^13]: @[01:40] "…정상 완료… 프로필 설정 화면…" [^14]: @[01:46] "…이미지 피커… 갤러리 또는… 촬영…" [^15]: @[01:54] "…사진 선택… 크로(크롭)… 원하는 형식으로…" [^16]: @[02:08] "…이름 연락처 한줄 소개… 세션 선택…" [^17]: @[02:14] "…프로필 사진… 파이어베이스 스토리지… 나머지… 파이어베이스 데이터베이스…" [^18]: @[02:19] "…메인 페이지…" [^19]: @[02:24] "…소속… 밴드… 밴드… 프로필 수정…" [^20]: @[02:32] "…밴드 개설… 이미지 피커… (크롭)… 밴드명 소개…" [^21]: @[02:41] "…밴드 상세… 공유 링크… 초대… 일정… 합주곡… 투표… 시연…" [^22]: @[03:15] "…기능… 남아서… 모델로 많이 모여… 리팩토링… 클린 아키텍처…" [^23]: @[03:22] "목표는 3월 개발 완료 목표로…" [^24]: @[03:55] "…입니다… 이상입니다"

← 프로젝트에서 보기