Penple 개발 후기

🚀 배포 성공 

https://play.google.com/store/apps/details?id=com.penple

깃허브 저장소

github(front) : https://github.com/JEONGHWANMIN/PenPle
github(back) : https://github.com/JEONGHWANMIN/penple-server

 

"펜플을 통해서 당신의 하루를 기록하여, 의미 있는 하루를 보내는 방법을 찾아보세요."
penple은 누고자 작성할 수 있는 일기 애플리케이션입니다.

프로젝트를 만든 이유 

최근에 일기를 작성해 볼까? 하는 생각이 들었습니다. 그런데 시중에 있는 일기 어플을 다운로드하여 보니 그냥 일기만 작성할 수 있고,

검색 기능 같은 게 없었습니다.

 

또한 일기가 서버에 저장되는 것이 아닌 핸드폰에 저장되기 때문에 나중에 핸드폰 기기를 바꿔야 하는 상황이 오면 일기를 내보냈다가 다시 불러와야 하는데 이 과정이 복잡하게 느껴졌고, 또한 일기를 까먹고 내보내기를 안 할 경우에는 일기 내용이 다 날아가는 것이기 때문에 마음에 들지 않았습니다.

 

그래서 내가 직접 만들어 보면 좋겠는데?라는 생각이 들었고 회사 끝나고 집에 와서 조금씩 완성시켜 나갔습니다. 

 

ReactNative 

Penple 서비스는 앱으로 만들었는데 그 이유는 일기 같은 경우 자기 전에 누워서 핸드폰으로 작성하는 경우가 많을 거 같다는 상황을 고려했고, 또한 리액트 네이티브를 공부하면서 앱을 만들고자 했던 배움 의지가 있었기에 앱으로 만들게 되었습니다.

 

평소에 react를 사용해서 일을 하기 때문에 프로젝트 만드는데 그렇게 까지 어려움이 있는 건 아니었지만 초기 프로젝트 세팅하는데 시간이 꽤 많이 들었습니다. 

 

리액트 네이티브는 웹이랑 다르게 스타일링 방식이 조금씩 달랐습니다. 

예를 들어서 웹은 flex direction이 기본적으로 row지만 리액트 네이티브에서는 column을 나타내기 때문에 이 방식에 적응하는데 시간이 좀 걸렸습니다. 

리액트 네이티브는 IOS, AOS 둘 다 개발할 수 있는 장점이 있지만 아예 똑같이 개발되는 건 아니었습니다. 

기본적으로 똑같은 스타일링을 적용하더라도 AOS IOS 스타일 차이점이 발생했습니다. 

그렇기에 react-native-paper라는 UI 라이브러리를 사용했고 이 라이브러리 내에 컴포넌트들은 어느 정도 일관된 UI를 가지고 있기 때문에 IOS, AOS 큰 노력을 들이지 않고 일관성을 맞출 수 있었습니다.

리액트를 사용해서 웹 개발을 하는 경우에는 화면 전환을 할 경우 react-router-dom 라이브러리를 사용해서 화면을 바꾼다면 리액트 네이티브는 리액트 내비게이션이라는 라이브러리를 사용해서 화면전환을 하게 되는데 웹은 페이지 하나를 그리게 된다면 리액트 네이티브 같은 앱은 스택구조로 기존 화면은 그대로 있고 새로운 화면이 스택처럼 위에 쌓여서 동작하게 됩니다. 

이렇게 되었을 경우 뒤로 가기를 해도 기존 화면은 그대로 있기 때문에 API 패칭을 새로 하지 않고 그냥 기존 화면을 그대로 보여주게 됩니다. 
그렇기에 react-query의 invalidateQueries를 활용해서 특정 동작 이후에 화면을 리패칭 해서 최신데이터를 유지할 수 있도록 했습니다.

 

UI / UX 고민

개발하면서 UI/UX 적인 부분도 최대한 신경 쓰면서 어떻게 해야 좀 더 좋은 서비스를 제공할 수 있을까 고민하면서 만들었는데 

사용자가 일기를 수정하거나, 작성중일 때는 뒤로 가기 클릭 시 정말 뒤로 갈 건지 확인하는 과정을 거치도록 했습니다. 

예를 들어서 아래와 같이 1번 2번 화면이 있다고 하면 사용자는 어떤 걸 더 선호하게 될까요? 

 

 

1. 버튼 명이 작성유지, 작성 취소

 

 

2. 버튼명이 네, 아니요

두 개의 차이점은 사용자가 버튼만 보고도 의미를 유추할 수 있는지입니다. 

1번 같은 경우 제목을 보지 않고 버튼명만 보더라도 바로 버튼을 누를 수 있지만 
2번 같은 경우 아니요, 네 만 보고서는 버튼을 클릭할 수 없습니다.

어쩔 수 없이 사용자는 일기 제목까지 훑어봐야 버튼을 누를 수 있게 됩니다. 

현재 많은 회원가입 과정이 회원가입 한 이후에 다시 아이디, 비밀번호를 치고 로그인해야 하는데 평소에 이 과정이 불편하다고 느꼈습니다.

그래서 회원가입 이후 로그인 창에서 내가 회원가입 한 아이디가 미리 입력되어 있도록 만들었습니다. 

 

아이디가 입력 되어 있음

 

위에 처럼 좀 더 내 서비스에 대한 많은 고민을 하면서 개발을 할 수 있어서 좋았습니다. 

 

Zustand

penple에서는 전역 상태관리 라이브러리로 zustand를 사용했습니다. 

전역 상태관리 라이브러리는 결국 전역으로 상태관리를 한다는 점에서 zustand, recoil, redux, jotai 등 어떤 것을 사용해서 상관없다고 생각하지만 각각 전역 상태 라이브러리를 사용해서 차이점을 알고 싶었기에 zustand를 선택하게 되었습니다.

zustand 같은 경우 아래와 같은 사용법으로 상태를 만들 수 있습니다.

 

사용법 자체는 간단했지만 아쉬웠던 점은 recoil처럼 reset 기능이 내장되어 있지 않아서 직접 구현해야 하는 것 빼고는 만족스러웠습니다.

Nestjs

백엔드로는 nestjs를 사용했는데 그 이유는 우선 지금 업데이트가 계속 이루어지고 있는 프레임워크이기 때문입니다. 

또한 타입스크립트 기반이기 때문에 다른 언어를 배울 필요 없이 쓸 수 있다는 점이 장점이었습니다. 

 

nestjs는 프레임워크로 개발하는데 많은 도움을 주는 기능들이 내장되어 있는데 예를 들어서 요청이 오기 전에 토큰을 통해서 사용자를 추출한 더 던 지 string으로 넘어오는 id값을 숫자로 바꿔준다든지 하는 편리한 기능들을 제공해 줘서 좋았습니다. 

 

nestjs 자료도 많이 찾아볼 수 있기 때문에 혼자 찾아보면서 개발하기 좋다는 생각이 들었습니다.

 

Prisma

ORM으로는 prisma를 사용했는데 그 이유는 일단 지금 프로젝트 규모가 크고 복잡하지 않기 때문에 orm만 사용하더라도 지금 프로젝트 규모의 데이터 조작은 다 할 수 있기 때문에 사용하게 되었습니다. 

 

이거 외에도 prisma studio를 사용해서 손쉽게 데이터를 관리할 수 있도록 지원하고, model 정의한 것을 타입스크립트로 타입을 뽑아주기 때문에 편하게 개발할 수 있었습니다. 

Tspec

커리어리에서 출근하면서 리디에서 쓴 블로그 글을 하나 봤는데 tspec에 관한 내용이었습니다.

 

원래 nestjs/swagger를 사용해서 각 메서드마다 데코레이터로 계속 달아야 했었는데 이렇게 했을 경우 아래와 같이 가독성이 매우 나빠진다는 단점이 있었습니다. 

 

가독성이 좋지 않다.

tepec을 사용한다면 데코레이터로 컨트롤러나 메서드마다 작성하지 않아도 된다는 점이 있고, 두 번째로는 타입스크립트 기반 그대로 API 문서를 만들 수 있다는 장점이었습니다. 

 

model에 정의된 타입스크립트 스펙은 prisma에서 만들어 주기 때문에 그 타입을 불러다가 문서에 응답값에 넣어주기만 하면 그대로 문서를 만들 수 있다는 점이 좋았습니다. 

 

따로 user.spec.ts 파일을 만들어 준 후 아래와 같이 tspec을 이용해서 만들 수 있습니다.

 

단점으로는 tspec을 사용했을 때 너무 신규 라이브러리이다 보니까 헤더를 명시하는 부분이 없었습니다. 

라이브러리 공식 깃허브를 들어가니 이슈가 하나도 만들어지지 않았습니다. 그래서 최초로 이슈를 남겼습니다.

 

https://github.com/ts-spec/tspec/issues/14

According to the api spec, headers cannot be customized separately?? · Issue #14 · ts-spec/tspec

다행히도 이슈 부분을 파악하고 헤더를 명시할 수 있도록 수정해 줘서 프로젝트에 잘 적용할 수 있었습니다. 

 

여기에서 느낀 건 아무래서 처음 나온 라이브러리를 내 프로젝트에 사용하기는 좀 어려울 수 있겠구나를 느꼈습니다. 

Deploy

DB (Planetscale)

데이터베이스는 클라우드 데이터베이스를 사용하려고 마음먹었는데 처음 비교한 게 supabase, planetscale 두 가지였습니다.

근데 supabase경우 데이터베이스만 지원하는 게 아니라 파이어베이스랑 비슷하게 다양한 기능을 지원하고 planetscale db만 지원했는데 지금 프로젝트 같은 경우 db만 필요하기 때문에 planetscale를 사용하게 되었습니다. 

 

쓰면서 장점으로는 처음부터 과금할 필요 없이 무료 플랜으로도 충분히 개발할 수 있다는 점이 좋았습니다. 

 

프로젝트마다 어떻게 세팅하면 되는지 세팅 예시도 잘 나와 있기 때문에 처음 사용하더라도 바로 연결할 수 있었습니다.

CloudType

백엔드는 클라우드 타입을 이용해서 배포하게 되었습니다. 

그 이유는 클라우드가 무료 플랜을 지원하기 때문에 비용 없이 백엔드 배포를 할 수 있었기 때문입니다. 

 

깃허브랑 연동이 되어서 처음 사용하는 사용자라도 클릭 몇 번으로 배포를 할 수 있었습니다. 

하지만 이렇게 했을 경우 깃허브 메인에 코드를 푸시하더라도 매번 사이트에 와서 배포 버튼을 클릭해야 하기 때문에 불편함이 있었습니다.

그래서 github action을 통해서 클라우드 타입에 자동으로 배포될 수 있도록 적용했습니다. 

 

 

클라우드 타입에 배포될 때마다 프로젝트를 새로 설치하고 시작하는데 이때마다 가끔씩 kill 나는 현상이 발생했습니다. 

그 이유는 npm 새로운 10.2 버전을 설치하라는 문구랑 함께 발생했는데 이 업데이트 문구를 안 나오게 하기 위해서. npmrc 파일을 만들어서 "update-notifier=false" 옵션을 줘서 해결할 수 있었습니다. 

구글 플레이 스토어 배포

처음으로 앱을 만들어서 배포하다 보니 일단 플레이 스토어에 배포하기로 했습니다. 

구글 개발자 가입을 하고 앱을 올리려고 하는데 앱이 수익을 내는지, 개인정보는 무엇을 받는지, 개인정보처리방침은 어떻게 되어있는지 해서 너무 신경 써야 할 부분이 많았습니다. 

 

하나씩 차분이 해결해 나갔고, 개인정보처리방침은 깃허브 페이지로 배포해서 url을 제출했습니다.

 

결국 다 작성해서 앱을 검수까지 올릴 수 있었습니다.

 

 

마무리

기획부터 시작해서 디자인, 앱 개발, 백엔드 개발까지 전체적으로 서비스를 만들어 보면서 경험할 수 있는 좋은 공부가 되었습니다.

 

일하면서 틈틈이 집에 와서 프로젝트를 하다 보니 프로젝트 완성 시간이 나름 길게 늘어졌습니다.

지금 이 프로젝트를 계속해서 유지보수하면서 사용자를 점점 늘어가는 게 목표입니다. 

 

지금은 기능이 다양하지 않지만 앞으로 2차 비밀번호 기능, 일기 작성 시간 알림 기능 등 많은 기능을 추가할 예정입니다.

지금은 code push가 적용되어 있지 않지만 천천히 업데이트 하면서 코드 푸쉬까지 적용하는게 일단 1차적 목표 입니다.