사이드 프로젝트, '작심친구' 개발
댓글 불러오는 중…
댓글 불러오는 중…
2022년에 사이드 프로젝트로 앱을 하나 만들었다. 아쉽게 배포까지 이어지진 못했지만, React Native와 Recoil을 사용해서 처음으로 전체 개발 사이클을 경험해 본 의미 있는 프로젝트라 회고를 남겨두려 한다.
작심삼일을 방지하는 소셜 목표 달성 앱이었다. 사용자가 목표를 설정하면 친구들과 진행 상황을 공유하고 서로 동기를 부여하는 서비스였다. 기획, 디자인, 개발 그리고 스토어 심사 제출까지 5인 팀(프론트엔드 2·백엔드 1·디자이너 1·기획 1)에서 프론트엔드 리드로 참여했다.
핵심 기능: 목표 생성/관리, 사진 인증, 친구 그룹, 피드백
목표: iOS와 Android 두 마켓에 동시 출시 가능한 앱을 만드는 것.
생산성과 안정성을 모두 잡기 위해 기술 스택을 고민했다.
iOS와 Android를 모두 커버해야 했기 때문에 크로스플랫폼인 React Native는 당연한 선택이었다. 하나의 TypeScript 코드베이스로 두 플랫폼에 대응할 수 있다는 게 가장 큰 장점이었다.
TypeScript를 조합한 이유는 명확하다. JS로만 작업할 때 흔히 겪는 타입 관련 버그를 잡는 시간을 아낄 수 있고, VSCode 자동완성 지원 덕분에 개발 경험도 훨씬 쾌적했다. 특히 API 응답 값이나 컴포넌트 Props의 타입을 명시적으로 관리할 수 있어서 코드 안정성이 크게 올라갔다.
당시 Redux가 거의 표준이었지만, 특유의 보일러플레이트(Actions, Reducers, Dispatch 등)와 복잡한 데이터 흐름이 이 프로젝트에는 과하다고 판단했다. 배우는 데 드는 시간에 비해 얻을 게 적어 보였다.
Recoil은 atom 기반으로 상태를 직관적으로 관리할 수 있고, React hooks와 자연스럽게 통합됐다. useRecoilState 훅을 useState처럼 쓸 수 있다는 게 생각보다 훨씬 편했다.
Styled-Components로 컴포넌트 단위 스타일을 관리했다. CSS 클래스명 충돌 걱정이 없고, props로 동적 스타일링도 편했다. 스타일 로직이 컴포넌트 파일 안에 같이 있으니 코드 응집도도 높아졌다.
유지보수성을 높이기 위해 몇 가지 설계 원칙을 세웠다.
Axios를 사용한 API 호출 함수들은 src/apis 디렉토리에 모아 관리했다.
이렇게 API 레이어를 분리해두니 UI 컴포넌트는 데이터 fetching 로직에 신경 쓸 필요 없이 뷰 렌더링에만 집중할 수 있었다. 나중에 백엔드 API 명세가 바뀌더라도 이 디렉토리만 수정하면 됐다. 여기서 중요한 건 이런 분리가 처음엔 귀찮아 보여도 나중에 얼마나 큰 도움이 되는지를 이 프로젝트에서 직접 체감했다는 것이다.
인증처럼 여러 컴포넌트에서 반복적으로 사용되는 로직은 useAuth 같은 커스텀 훅으로 뽑아냈다. AsyncStorage 토큰 확인, Recoil 상태 업데이트, API 호출을 모두 훅 내부에서 처리했다. 코드 중복이 줄고 비즈니스 로직을 한 곳에서 관리할 수 있어서 유지보수성이 좋아졌다.
앱 개발 A to Z 경험: React Native로 기획부터 스토어 심사까지 전체 사이클을 직접 경험한 게 가장 큰 수확이다. 상태 관리, API 연동, 네이티브 기능 핸들링 등 직접 부딪혀 보니 한 단계 올라간 느낌이었다.
클린 코드의 중요성: API 레이어를 분리하고 커스텀 훅으로 로직을 모듈화하는 게 나중에 얼마나 큰 도움이 되는지 체감했다.
배포 실패: 기술적인 완성도와 별개로, 서비스를 꾸준히 운영하려면 팀이 필수라는 현실적인 교훈을 얻었다. 팀 빌딩에 실패해서 결국 배포를 중단해야 했던 점이 가장 아쉽다.
테스트 코드의 부재: 개발 속도에 치중하느라 테스트 코드를 작성하지 못했다. 만약 프로젝트가 더 커졌다면 테스트 코드의 부재가 발목을 잡았을 거라는 생각이 든다.