한모금 (Hanmogm)

저희 팀은 Slack, Figma, Jira를 활용하여 정기 회의, 디자인 반영, 태스크 브레이크다운, 개발 일정 산정, 진행상황 및 요청사항 보고 등등의 소통을 진행해왔습니다. 특히, 저는 프론트엔드 개발자로서 기획자분이랑 디자이너분과의 소통이 가장 활발했는데, 각종 컴포넌트나 스크린들이 어떤 화면에서 어떤 형태로 표시되어야 하며, 어떤 상호작용이 발생했을 때 또는 어떤 상태가 변할 때 어떤 변화가 있어야 하는지, 표시할 데이터가 비어있거나 에러가 발생할 경우 어떻게 표시해야 하는지 등등에 대한 논의가 주를 이뤘습니다. 이에 대한 논의가 결정되었을 때, 예상되는 개발 일정을 산정하고 구현을 시작합니다.

혹시나 기획자분과 디자이너분이 미처 명세하지 못한 부분이 있다면, 제가 직접 가장 사용성이 높을 것이라 생각되는 방향으로 초안을 구현해오기도 합니다. 예를 들어, 한모금 앱의 시음기록 폼 중 향 태그를 입력할 때 추천 향을 키보드 위에 표시하는 기능을 구현해야 했을 당시, 이 추천 향들을 표시하는 방법이 명세되지 않았습니다. 그래서 저는, 한 줄에 모든 추천 향 태그를 보여주는 스크롤뷰 방식, 고정 뷰에 추천 향 태그를 10개까지만 보여주는 방식, 이 두 가지를 생각했는데, 그 중 후자가 스크롤뷰 터치로 인한 키보드 블러 이벤트를 복잡하게 통제할 필요도 없었으며 사용자에게도 한 눈에 들어오고 조작 횟수가 최소화된 방식이었기에 실제 프로덕션으로 배포될 수 있었습니다.

빌드 구축 전에는 Expo Go를 활용하였습니다. Expo Go는 개발 중인 앱을 따로 빌드하여 설치하지 않고도 QR 코드를 스캔하거나 exp://로 시작하는 URL에 접속하여 앱의 프리뷰를 볼 수 있게 해주는 앱입니다. 이 앱을 통해, 빌드를 따로 만들지 않고도 팀원들에게 신속하게 프리뷰를 제공할 수 있었습니다.

expo-updates 패키지와 Expo Channel을 활용하여, CI/CD가 가능한 빌드를 구축하였습니다. eas.json의 build.(프로파일명).channel에 원하는 채널을 할당시키면, 그 빌드는 프로파일에 해당되는 채널의 업데이트를 따라갑니다. (참고) 이를 통해 코드만 푸시해도 업데이트가 되는 빌드를 구축함으로써, 무료 플랜에서 iOS와 Android로 각각 15회까지밖에 안 되는 eas build의 사용 횟수를 획기적으로 줄일 수 있었습니다.

React Native는 React의 지식만 가지고 모바일 앱을 제작할 수 있다는 장점이 있지만, 실제로 React Native 프로젝트를 진행할수록 플랫폼별로 필요한 의존성과 실제 수행하는 동작에 차이가 있어, 동일한 경험을 위해 플랫폼별로 로직을 달리해야 할 수도 있다는 점을 느꼈습니다. 대표적으로, 동일한 패키지더라도 iOS에서와 Android에서의 UI 렌더링 방식이나 권한 처리 방식이 다르게 동작한다는 점, 빌드 후 App Store Connect와 Play Store Console에 앱을 제출하는 과정에서도 플랫폼별로 서로 다른 과정이나 대응이 필요하다는 점 등등이 있습니다.

사이드 프로젝트는 소규모 팀으로 진행되기 때문에, 각자의 외부 일정이 프로젝트에 큰 영향을 줄 수 있습니다. 특히 야근, 급한 일정, 기술적 난관 등에 직면했을 때, 최대한 신속 정확하게 팀원에게 상황을 공유해야 팀 전체에 미치는 영향을 줄일 수 있고, 문제 해결을 위한 시간적 여유도 확보된다는 점을 배웠습니다.

어떤 업무를 진행할 땐, "할 것"과 "하지 말아야 할 것"을 명확히 구분하고 진행해야 함을 배웠습니다. 완벽하게 진행하려고 하면, 결국 완벽은 커녕 핵심까지 놓치게 됩니다. 따라서, 핵심과 거리가 먼 것은 일단 백로그로 두어 여유가 있거나 다음 기회를 잡았을 때 진행하는 것이 좋습니다.

외부 패키지를 사용할 때는 단순히 이용하면서 문서만 보는 것이 아니라, GitHub 이슈, 체인지로그, 소스코드 등을 통해 패키지의 동작 방식과 잠재적인 문제를 주기적으로 확인해야 한다는 점도 배웠습니다.