사이드 프로젝트, '작심친구' 개발 회고

2022년에 사이드 프로젝트로 앱을 하나 만들었습니다. 아쉽게 배포까지 이어지진 못했지만 React Native와 Recoil을 사용해서 처음으로 전체 개발 사이클을 경험해 본 의미 있는 프로젝트라 회고를 남겨보려고 합니다.

1. 프로젝트 개요: 소셜 목표 달성 앱, 작심친구

작심삼일을 방지하는 소셜 목표 달성 앱이었습니다. 사용자가 목표를 설정하면 친구들과 진행 상황을 공유하고 서로 동기를 부여하는 서비스였습니다. 기획, 디자인, 개발 그리고 스토어 심사 제출까지 4인 팀에서 프론트엔드 리드로 개발을 진행했습니다.

핵심 기능: 목표 생성/관리, 사진 인증, 친구 그룹, 피드백

목표: iOS와 Android 두 마켓에 동시 출시 가능한 앱을 만들어보는 것.

2. 기술 스택 결정과 그 이유

생산성과 안정성을 모두 잡기 위해 다음과 같이 기술 스택을 결정했습니다.

React Native & TypeScript

IOS와 Android를 모두 커버해야 했기 때문에 크로스플랫폼인 React Native는 당연한 선택이었습니다. 하나의 TypeScript 코드 베이스로 두 플랫폼에 대응할 수 있다는 점이 가장 큰 매력이었어요.

여기에 TypeScript를 조합한 이유는 명확합니다. JS로만 작업할 때 흔히 겪는 타입 관련 버그를 잡는 시간을 아낄 수 있었고, VSCode의 자동완성 지원 덕분에 개발 경험도 훨씬 쾌적했습니다. 특히 API 응답 값이나 컴포넌트 Props의 타입을 명시적으로 관리할 수 있어 코드의 안정성이 크게 올라갔습니다.

상태 관리: Redux 대신 Recoil

상태 관리 툴로는 Recoil을 선택했습니다. 당시 Redux가 거의 표준이었지만, 특유의 보일러플레이트(Actions, Reducers, Dispatch 등)와 복잡한 데이터 흐름이 해당 프로젝트에는 과하다고 판단했습니다. Recoil은 atom 기반으로 상태를 직관적으로 관리할 수 있고, React hooks와 자연스럽게 통합되어 쉽게 배울 수 있었습니다. 필요한 컴포넌트에서 useRecoilState 훅을 사용해 useState처럼 상태를 가져와 쓸 수 있다는 점이 매우 편리했습니다.

Styling: Styled-Components

Styled-Components를 사용해 컴포넌트 단위로 스타일을 관리했습니다. CSS 클래스명이 겹치는 문제를 신경 쓸 필요도 없고, props를 활용해 동적인 스타일링을 구현하기도 편했습니다. 스타일 로직이 컴포넌트 파일 내에 함께 있으니 코드의 응집도도 높아졌습니다.

3. 주요 코드 구조와 설계 의도

프로젝트의 유지보수성을 높이기 위해 몇 가지 설계 원칙을 세웠습니다.

API 레이어 분리

Axios를 사용한 API 호출 함수들은 src/apis 디렉토리에 모아 관리했습니다.

이렇게 API 레이어를 분리해두니 UI 컴포넌트는 데이터 fetching 로직에 대해 신경 쓸 필요 없이 뷰 렌더링에만 집중할 수 있었습니다. 향후 백엔드 API 명세가 바뀌더라도 이 디렉토리만 수정하면 되니 훨씬 효율적이였습니다.

커스텀 훅을 통한 로직 재사용

인증처럼 여러 컴포넌트에서 반복적으로 사용되는 로직은 useAuth 같은 커스텀 훅으로 뽑아냈습니다. 커스텀 훅 내부에서 AsyncStorage 토큰 확인, Recoil 상태 업데이트, API 호출 등을 모두 처리하도록 했습니다. 덕분에 코드 중복이 줄고, 비즈니스 로직을 한 곳에서 관리할 수 있어 유지보수성이 좋아졌습니다.

4. 회고: 배운 것과 아쉬운 점

배운 점

앱 개발 A to Z 경험: React Native로 기획부터 스토어 심사까지 전체 사이클을 직접 경험한 게 가장 큰 수확입니다. 상태 관리, API 연동, 네이티브 기능 핸들링 등 직접 부딪혀보니 빠르게 성장할 수 있었습니다.

클린 코드의 중요성: API 레이어를 분리하고, 커스텀 훅으로 로직을 모듈화하는 등의 노력이 나중에 얼마나 큰 도움이 되는지 체감했습니다.

아쉬운 점

배포 실패: 기술적인 완성도와 별개로, 출시 후 서비스를 꾸준히 운영하기 위해선 팀이 필수적이라는 현실적인 교훈을 얻었습니다. 팀 빌딩에 실패하여 결국 배포를 중단해야 했던 점이 가장 아쉽습니다.

테스트 코드의 부재: 개발 속도에 치중하느라 테스트 코드를 작성하지 못했습니다. 만약 프로젝트가 더 커졌다면 테스트 코드의 부재가 발목을 잡았을 거란 생각이 듭니다.

결과적으로 작심친구는 제 개인적인 성장의 발판이 되어준 프로젝트였습니다. 이 경험을 바탕으로 다음 스텝을 밟아나갈 수 있었습니다.