회원가입에 진심인 사람입니다

썸네일

 

나에게는 고질병이 하나 있다. 인터넷 아이디와 이메일을 주기적으로 변경 한다. 당시에 나를 조금 더 표현 할 수 있는 단어로, 또는 추구하는 목표로 키워드를 넣은 새로운 아이디를 사용하기 위해 가입 했던 모든 서비스를 탈퇴 했다가 재가입 하는 무서운 질병이다.

 

해외에서 만든 웹 또는 앱서비스들은 비교적 아이디변경과 이메일변경이 자유롭다. 그런데 유독 우리나라에서 탄생한 서비스들은 한번 만들면 변경을 하지 못하게 하거나, 탈퇴 후 1달, 3개월 등 저마다 정의되지 않은 주기로 회원가입을 다시 하지 못하게 한다.

 

기술 컨퍼런스에서 대용량 트래픽을 어떻게 처리 한다느니 요즘 유행은 이런 기술이라서 개발자들은 서둘러 사용하지 않으면 뒤쳐진다느니 썰을 푸는 사람의 소속회사가 가입 회원을 이메일 변경도 하지 못하는 서비스를 운영 하고 있다면 이 말 부터 해주고 싶었다.

이메일 변경이나 먼저 만드세요!

 

순수 개발자 모드 였던 예전에는 회원가입, 로그인, 로그아웃, 로그인 세션 상태 등 사용자 인증을 위한 일련의 기능들을 백엔드도 모두 손수 개발해야 한다는 강박과 욕심이 있었다. 나이가 조금 들면서 사업을 경험 하기도 하고 투입되는 자원과 시간, 비용에 예민해지며 이런 강박과 욕심은 점점 내려놓게 되었다.

페이스북 타임라인

 

나의 욕심과 예민의 시간 동안 앱서비스 만드는일을 접었다 폈다, 다시 시도했다가 포기 했다가 하는 사이에 아마존웹서비스(AWS), 구글(Google), 마이크로소프트(Microsoft)와 같은 클라우드 서비스 제공자(CSP, Cloud Service Provider)들은 눈부신 발전을 하고 있었다.

파이어베이스(Firebase)

 

사스(SaaS, Software as a Service)와 파스(FaaS, Function as a Service)로 중무장된 이들의 서비스 만큼 만들 자신도 없고, 만들고 싶은 앱이 어떻게 작동해야 하는지를 결정하는 핵심 규칙과 흐름 즉, 비즈니스로직(Business Logic)에 집중 하는것이 옳다고 판단 했다. 그래서 Firebase를 사용하게 됐다. 현재 까지 세이브푸드를 만들며 사용한 서비스는 아래 표와 같다.

Firebase	Type	Description
Authentication	SaaS	이메일로 회원가입 및 UID 생성
Firestore	SaaS	사용자, 보관함, 식자재 정보 저장
Storage	SaaS	사용자 프로필 이미지, 보관함 이미지 관리
Messaging	SaaS	애플 인증키와 연동한 푸쉬 알림 구현
Functions	FaaS	DB에 데이터 적재시 마다 알림 발송 구현

 

바이브코딩(Vibe Coding)을 위해 인공지능에게 첫 프롬프트(Prompt)를 보내기전 코드가이드데브(codeguide.dev)에서 배운대로 여러 산출물을 먼저 작성 하였다.

• App Flow Document (앱 플로우 문서) : 앱의 주요 흐름 설명
• App Flow Chart (앱 플로우 차트) : 앱 화면 전환 흐름 차트
• Backend Struccture Document (백엔드 구조 문서) : Firestore 중심 백엔드 데이터 구조
• Frontend Guidelines Document (프론트엔드 가이드라인 문서) : SwiftUI MVVM 구조 및 개발 규칙
• Implementation Plan (구현 계획 문서) : 단계별 구현 진행상황
• Project Requirements Document (프로젝트 요구사항 문서) : 기능 및 비기능 요구사항 정리
• Tech Stack Document (기술 스택 문서) : 사용 기술 스택 요약

산출물 작성을 해보니 구현하고 싶은바가 명확해 졌다. 예를 들면 아래와 같이 명령 할 수 있었다.

회원가입 할 때 Firestore에 User가 저장 될 때는 UID 필드에 Firebase Authentication 에서 얻어온 UID가 저장 되어야 한다. 데이터가 저장된 이후에는 바로 다시 데이터를 조회하여 Firestore의 문서ID를 User의 did 항목에 업데이트 시켜야 한다. Protocol은 Firebase의 기능별로, FirebaseAuthenticationProtocol, FirebaseFirestoreProtocol, FirebaseStorageProtocol, FirebaseCloudMessagingProtocol 가 모두 작성되어야 하며, 추가 기능이 있을시에는 반드시 추가 기능별로 Protocol이 작성 되어야 한다. Service는 Firebase의 기능별로, FirebaseAuthenticationService, FirebaseFirestoreService, FirebaseStorageService, FirebaseCloudMessagingService 가 모두 작성되어야 하며, 추가 기능이 있을시에는 반드시 추가 기능별로 Service가 작성 되어야 한다. View는 회원기능 처리를 위해서 다음 5개의 뷰가 반드시 작성 되어야 한다. ContentView : 로그인 완료 후 콘텐츠를 확인 할 수 있는 뷰, AuthenticationView : 회원가입과 이메일로그인을 선택 할 수 있는 뷰, LoginView : 실제 이메일과 비밀번호를 입력하여 로그인 할 수 있는 뷰, SignUpView : User모델 정보로 회원가입을 할 수 있는 뷰, SettingView : User의 비밀번호초기화, 이메일변경 기능을 할 수 있는 뷰, 각 뷰에는 코드를 작성 할 때 Preview에 오류가 발생되지 않도록 #Preview 코드에 적절한 코드가 함께 작성되어야 한다.

 

위 내용을 포함해서 11,984자의 프롬프트를 작성해서 바이브 코딩을 시작 했었다. 결국 생각했떤것과 같은 로직으로 개발이 완료 돼었다. 처음에는 파이어베이스의 인증(Authentication)과 파이어스토어(Firestore)만 사용하다가 이미지를 다루면서 스토리지(Storage)를 사용하게 됐고, 푸시알림(Push Notification) 구현을 위해 메세징(Messaging)과 펑션스(Functions)를 추가로 사용하게 됐다.

 

아래 URL주소는 이 서비스들의 조합으로 만들어진 세이브푸드앱 현재 상태이다. 바이브코딩 만으로 (일부 수작업이 병행 됐지만) 이정도 서비스를 만들 수 있다는것도 놀랍고, 목표 했던 서비스에 근접하게 다가가고 있다.

‎SaveFood