[바라봄 개발log] 바라봄 V26 업데이트 후기

잡담

바라봄을 오픈한 지는 6년이 지났고(20년 5월), 마지막으로 바라봄을 업데이트한 지 2년이 지났다.

바라봄은 처음에 설계할 때 기획했던 것보다 기능이 많이 들어갔고 복잡해졌다.

주니어 개발자 시절 설계/개발한 바라봄은 새 기능을 추가하기도, 유지보수하기도 너무 어려워졌다.

그래서 제로베이스로 바라봄을 다시 설계 및 개발에 들어갔다. 처음에는 1년이면 될 줄 알았는데 현실적인 이슈(이직, 결혼, 이사)로 2년이나 걸려버렸다.

기술 스택 정리

프론트엔드

사실 레거시 바라봄의 가장 큰 문제 였던 JavaScript 코드베이스를 TypeScript로 변경하여 타입 안정성을 확보했다. JS는 초기 개발은 편하지만 시간이 지나면 확실히 유지보수가 너무 어렵더라.

또한, 바라봄 앱의 프레임워크도 React Native CLI에서 Expo로 전환했다.

기존 앱은 React Native 0.71 기반 bare workflow로 3년 가까이 운영된 레거시였다. 2025년 스토어 정책(안드로이드 API 35 타겟, iOS 18 SDK/Xcode 16 빌드 요구)까지 겹치면서 더 이상 미룰 수 없는 시점이 왔다.

• 업그레이드 비용이 너무 컸다 RN 코어를 올리려 했지만 네이티브 커스터마이징이 누적된 상태라 Podfile, Gradle, Info.plist, AndroidManifest 병합 충돌이 반복됐다.
• 생태계 호환성 한계가 있었다 RN 버전이 낮아 신규 라이브러리 도입이 자주 막혔고, 기능 확장 속도도 함께 떨어졌다.
• 새 프로젝트 + Expo가 더 현실적이었다 기존 프로젝트를 억지로 끌어올리기보다 새 프로젝트로 코드 이전하는 편이 리스크가 낮았고, Expo managed workflow가 장기 유지보수에 유리했다.

CLI를 사용할 때는 써드파티 라이브러리를 붙일 때마다 네이티브 코드를 수동으로 추가해야 하는 경우가 많았다. 네이티브 수정이 누적되면 RN 버전을 올릴 때마다 난이도가 급격히 올라갔고, 라이브러리 업데이트로 네이티브 설정이 바뀌면 다시 문서를 찾아 ios/android 설정을 손봐야 했다. Expo로 넘어온 뒤에는 이런 네이티브 변경을 써드파티 config plugin에서 주입해주는 경우가 많아져서 유지보수 부담이 확실히 줄었다.

EAS Build/Development Build 덕분에 네이티브 확장 유연성은 유지하면서도, 클라우드 빌드와 CI/CD 구성이 단순해졌다.

코드 품질과 개발 환경을 개선한 덕분에, 앞으로는 바라봄의 버그 수정과 기능 추가 속도가 훨씬 빨라질 것 같다.

백엔드

백엔드도 같이 정리했다. 기존 구조를 다듬으면서 Node.js + Express를 Java + Spring Boot로 변경했다. 개발 속도와 운영 안정성을 둘 다 챙기기 위한 선택이었다.

초반에는 시간이 많이 들어갔지만 구조가 잡히면서 강타입 언어의 장점으로 AI 활용도가 올라가 점점 속도가 붙었다.

디자인 시스템 의존성 분리

기존에는 바라봄 앱 내부에 UI 컴포넌트가 섞여 있었는데, 이번에 @0610studio/zs-ui로 디자인 시스템을 독립시켰다.

의존성을 분리하니 디자인이 일관성 있어졌고 바라봄의 비즈니스에 집중하기 훨씬 편해졌다.

FSD 응용 아키텍처

기존에는 Atomic Design을 쓰고 있었는데, 여러 모로 애매한 부분이 많았다.

가장 큰 문제는 역할과 소유권이 모호했다는 거다. atom, molecule, organism으로 나누긴 했지만, 정작 이 컴포넌트가 어디서 쓰이고 누가 관리하는지 명확하지 않았다. 그러다 보니 큰 컴포넌트에는 UI와 비즈니스 로직이 섞이게 됐고, 이게 다시 쪼개기 어려운 덩어리가 되었다.

재사용성도 기대보다 낮았다. side-effect가 생길까 봐 공용 컴포넌트를 수정하기가 두려웠고, 그래서 결국 비슷한 atom이나 hook이 중복으로 생겨나는 상황이 벌어졌다.

store도 문제였다. 중앙에서 관리하니 lifecycle을 추적하기 어려웠고, 쓰지 않는 코드를 삭제하기도 쉽지 않았다.

그래서 FSD(Feature-Sliced Design) 원칙을 응용한 간단한 구조로 바꿨다. pages, widgets, shared 세 개의 레이어로 나눴고, 각 슬라이스 안에서는 model과 ui로 분리했다.

DRY(Don't Repeat Yourself)에 집착하다 보면 결국 컴포넌트의 정체성이 모호해지며 이는 점점 수정하기 어려운 컴포넌트가 된다는거다. 그래서 DRY 정책에 너무 얽매이지 말고, 일단 중복을 허용한뒤 공통 쓰임새가 명확하면 리뷰 후 shared나 widgets로 승격시켰다. (읽어볼만한 글)

페이지별 상태는 가능한 로컬 context나 model로 처리하고, 꼭 필요할 때만 전역 store를 사용했다.

이렇게 정리하니 기능을 찾기도 쉽고, 코드 의존성도 명확해졌다.

그 외

• React Query 적극 도입 바라봄 특성상 한 번 입력하면 잘 수정하지 않기 때문에 같은 데이터를 반복해서 보는 화면이 많다. 유저 경험을 위해 데이터를 캐싱하고 통신 없이 즉각적으로 데이터가 표시되도록 변경했다. 확실히 사용성이 매우 좋아졌다.

• GA4 설정 점점 데이터가 더 중요해지는 시대인 것 같다. GA4를 사용해 이벤트 추적을 강화했다. 데이터가 충분히 쌓이면 바라봄을 개선하는데 많은 도움을 줄 것 같다.

잡담 및 하소연

사실 이번 업데이트 후 마켓에 별점이 1점이 달리기도 하고, 문의로 이전 UI/UX가 더 좋으니 되돌려 달라는 요청이 꽤 많이 왔다.

같은 말이라도 좋게 보내주시는 유저분이 있는가 하면 가시 돋친 말투로 보내시는 분들도 있어서 사실 조금 힘들었다.

6년간 서버 비용만 수백만 원, 실제 수익은 10만 원도 안 될 거다 ㅎㅎ

모든 문의는 다 읽고 조금씩 개선하려고 하니... 6년간 그래왔던 것처럼 앞으로도 잘해볼 테니 조금 지켜봐 주십사... 부탁드린다.

몇년째쓰는데 업데이트하고나서 위치는 왜 켜야하죠? 그리고 왜 바로 입력하는것들 다 없애고 굳이 여러번 누르게바꾼건지 이해가안됩니다

최근 업데이트되고 좀 불펀해졌어요. 첫 앱 접속시 딜레이도 좀 있구요. 앱 무게가 무 거워진거 같네요.

배변기록과 식사기록을 나눠서 표시되던 예전 방식이 배변 이상 파악에 좋았어요. 모아보기 표시도 이전 버전이 직관적이었고요. 수정이 당분간 어려우시다면 이전 UI를 사용할 수 있는 옵션이라도 제공되면 좋겠습니다.

기존 회원이 로그인 하는 곳이 없네요. 신규가입만 가능한겁니까? 기존의 데이터는 어디서 찾을 수 있나요? 중요한 데이터인데 이렇게 싹 엎어버리시면 어쩝니까?