무릇 개발자라면 본인이 만든 서비스를 하나 운영해야 하지 않나 하는 생각이 있었다. 그간 막연히 생각만 해왔지만, 이런저런 동기부여가 생겨 앱 서비스를 개발하게 되었다.
사람은 자신의 가치관이나 철학으로 정의되기도 하지만, 결국 그로부터 말미암은 행동이 그 사람의 아이덴티티가 된다고 생각한다. 그런 의미와 비전을 담아 사람들이 목표와 버킷리스트를 실현하는 데 도움이 되도록, 그리고 내 막연히 갖고 있던 생각과 동기를 실현할 수 있도록 이 앱을 개발하게 되었다.
미션 달성
이 앱은 목표 관리 앱으로, 사용자가 평소에 달성 하고 싶었던 목표나 버킷리스트들을 ‘미션’ 이라는 단위로 생성하고 이를 관리하고 달성해 나갈 수 있도록 구성되어 있다.
각 미션은 하위 작업을 가질 수 있다. 예를 들어, 사용자가 평소 로마 여행에 관한 버킷리스트를 갖고 있어 이를 ‘로마 여행 가보기’ 라는 미션으로 만든다면, 여기에 ‘콜로세움 방문하기’ , ‘젤라또 먹어보기’ , ‘판테온 방문하기’ 같은 것들을 하위 미션으로 만들어 구성할 수 있다.
반복 유형 기능도 개발 하였다. 각 미션은 한번만 달성하면 완료할 수 있는 ‘1회 달성’ , 매일 혹은 요일 지정으로 반복해서 미션을 수행할 수 있는 ‘매일’, ‘요일 지정’ 유형이 있다.
미션을 그룹으로 관리할 수 있는 태그 기능도 개발하였다.
업적 달성
미션의 상위 개념인 ‘업적’ 기능도 개발하였다.
단순 테스크 단위의 미션 뿐만 아니라, 업적이라는 더 큰 단위의 목표를 구성함으로써 사용자가 좀 더 성취감을 느낄 수 있는 요소를 도입 하였다.
업적은 하나 이상의 미션으로 구성된다. 업적 트로피 모아보기, 업적 달성 공유와 같은 컨셉으로 향후 앱을 확장해 나갈 수 있도록 하였다.
업적은 ‘공개 업적’ 과 ‘나만의 업적’ 두 유형으로 구분된다.
공개 업적은 여러 사용자가 함께 달성할 수 있는 업적이다. 참여한 사용자들끼리 같은 목표를 공유하여 함께 달성해 나가는 경험을 할 수 있도록 구성 하였다.
나만의 업적은 개인적인 목표나 루틴 같은 것들을 혼자 설정하고 관리할 수 있도록 구성 하였다.
SNS 기능
이 앱의 핵심 컨셉 중 하나는 ‘함께 도전하고’ , ‘함께 달성하는’ 경험 제공을 위한 SNS 기능이다.
단순 메모장이 사용자가 혼자만의 기록용 앱처럼 미션이나 업적을 관리하는 것이 아니라, 사용자들이 함께 목표를 공유하고 서로가 서로에게 동기부여가 되는 환경을 만드는 것이 이 앱이 지향하는 방향이다.
‘공개 업적’ 에 참여하면 해당 업적과 관련된 미션들이 내 미션/업적 목록에 추가된다. 그리고 참여한 사용자들끼리 함께 진행 상황을 공유하며, 소통하며 동기부여 하는 구조이다.
현재 1차 프로토타입 버전에는 공개 업적에 댓글 기능이 개발되어 있으며, 사용자간에 응원이나 경험 공유가 가능하다.
향후 2차 프로토타입에는, 업적 달성 인증 사진, 경험 공유, 업적 트로피 등 SNS 와 관련된 기능들을 보완해 나갈 계획이다.
단순한 목표 관리 앱이 아닌 도전과 성장의 경험을 나누는 공간으로 발전시켜 가는 것이 이 앱의 비전이다.
소감
1차 프로토타입까지 개발한 후 현재의 소감을 말해보자면…
아무래도 머리속에서는 앱이 뚝딱 만들어지다 보니… 개발 하면서 생각보다 작업량이 많았다.
만들고 싶던 내용들을 마구 기획 하였지만, 작업하는 도중에 개발 속도와 현실적인 리소스를 고려하여, 여러 마일 스톤으로 나누고 핵심 기능부터 우선 완성하는 방식으로 접근하게 되었다.
앱을 만들 때 ‘작은 단위로 먼저 완성하라’는 조언을 적극 수용 하였다. 모든 부분에 욕심을 냈다면 1차 완성이 꽤나 더뎠을 것 같다. 생각보다 할게 많아서 절충의 절충을 하게 되었다…😂.
역시나 기획, 디자인 등을 모두 혼자 하려다보니 버거운 점이 있었다. 그래서 우선 나 자신을 앱 사용자로 타겟팅 하고 내가 사용하고 싶고, 사용하기 좋은 앱을 만들고자 하였다.
앱 구조 상, 개인이 사용하는 영역과, 모두가 함께 보는 플랫폼적인 영역을 모두 다뤄야 하다 보니, 정책이나 데이터 관리에서 고민이 많았다.
또한 플랫폼 앱을 지향하는만큼, 앱이 단순히 유저 로컬에서만 동작하는 게 아니라, 백엔드 서버와 긴밀하게 연동되어야 하는 구조였기에, 이러한 부분에서 기획적인 면도 고민이 많았지만, 개발 과정에서도 고려할 것들이 많이 있었다.
사실 만들면서 소감으로 적고 싶었던 것들이나, 순간 순간 깨달은 것들이 꽤나 있었는데 막상 쓰려니 잘 생각이 안 난다 😅
아무튼 분명한 건, 1인 개발자로서 앱 하나를 직접 기획하고 설계하고 (곧 스토어에 올릴거지만) 출시하는 경험은 내게 개발자로서 아주 좋은 양분이 되었다는 점이다.
아마 스토어 심사 올리기까지는 며칠 정도 더 마무리를 해야 하지 않나 싶다.
작은 단위로 먼저 완성을 시켜야겠다고 하였지만, 쪼금 마무리 작업을 더 하고 싶은 욕심도 있다 🙃
비록 완성 후 사용자가 나 하나 뿐일지라도, 내가 만든 앱이기에 나에게 의미가 있다. 🙂
기술
개발 경험인데 기술 얘기를 빼먹을 뻔 했다.
앱은 React-Native Expo 로 개발하였다. flutter 로 개발할까 했는데 react 를 좀 더 리마인딩 하기 위해 RN 으로 개발 하였다.
이번 프로젝트에 React-Query 도 도입하여 사용해 보았다. 역시 너무도 강력했다 🤩 보통 코딩을 하다 보면, 예를 들어, 어떤 데이터를 수정하는 하는 API 를 요청한 후, 다시 수정된 데이터 목록을 조회하는 등의 API 호출 흐름이 있게 된다.
이건 단순한 예시이지만, 이러한 흐름을 수동으로 관리하면, 비동기 로직과 상태 관리가 뒤섞이면서 컴포넌트나 훅 내부의 함수들이 순수하지 않게 구현되는 경우가 발생하기 쉽다.
React-Query 에서는 아래와 같이, 예를 들어 어떤 미션을 완료/수정 처리한 후 관련된 미션 목록을 새로고침 해야 하는 경우, 모든 관련 쿼리를 명시적으로 invalidate 하여 해당 queryKey 를 기준으로 손쉽게 캐시를 무효화 하고 새 데이터를 가져올 수 있게 된다.
이러한 점과 더불어 React-Query 를 사용하면 개발 도중 마주하는 문제를 손쉽게 핸들링 할 수 있는 경우가 있었다.
export const invalidateMissionRelatedQueries = async (
queryClient: QueryClient
) => {
await Promise.all([
queryClient.invalidateQueries({ queryKey: ["missions"] }),
queryClient.invalidateQueries({ queryKey: ["missions", "active"] }),
queryClient.invalidateQueries({
queryKey: ["missions", "available"],
}),
]);
};빠른 화면 개발을 위해 디자인 시스템 라이브러리로는 Tamagui 를 사용했는데… 아마 앞으론 디자인 시스템 라이브러리는 도입을 아예 안 하던지, tailwind 정도만 사용할 것 같기도 하다. 😂
테마나 token 으로 컬러팔레트와 같은 디자인 시스템을 쉽게 구성할 수 있는 게 tamagui의 장점이긴 했다.
하지만, 학습곡선 없이 라이브러리를 도입해 빠르게 개발하려 했던 계획과는 다르게 라이브러리 기능이나 간단한 문법, props 사용법 같은 걸 익히는 데 시간이 꽤 들었다. 그리고 간단한 컴포넌트를 구현할 때에도 보일러플레이트가 꽤 있어서 작업 시간이 추가되는 점이 있었다.
그 외, 가이드 문서가 최신으로 갱신이 안됨, 사용중 버그가 있어서 최신 버전으로 업데이트 해야 했음 등, 무료 버전이여서 나는 이러한 경험을 했는 지 모르겠지만 빠르고 쉽게 구현하기는 쉽지 않았다.
(라이브러리 중에 공식 홈페이지가 가장 미려한 것으로 고르면, 공식 홈페이지도 라이브러리로 구축 했을테니 좋은 선택일거다… 라고 생각했으나… 그래도 공홈의 오리 아이콘이 귀엽고 깔끔하긴 하다)
백엔드 서버는 이번에도 MSA 구조로 구성했다. OOP 에서 객체 단위로 책임을 나누는 것처럼, MSA에서 각 도메인 개념에 따라 서버를 분리함으로써 역할을 명확하게 구분하여, 필요한 경우 서버간 내부 통신으로 처리하였고 이렇게 명확히 구분된 기능들은 작업하는 코드에도 반영이 되면서 개발 편의성 면에서도 장점이 많았다.
당연히 추후 서비스가 커지면서 얻게 될 확장성과 유연함은 덤이다.
그럼 이제 글을 마무리 해 본다.
추가로… 사이드 프로젝트 서버와 스크레핑 서버, 지금 만든 앱 서비스 서버까지 자꾸만 뭐가 늘어가는데… 서버 비용이 야금야금 나가는 느낌이다. 차라리 미니 PC 하나 장만하는 것도 좋을 것 같다…. 진짜 끝.