본문으로 건너뛰기

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

· 약 4분
Jeonghun Kim
Jeonghun Kim
Frontend Developer

잡담​

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

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

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

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

기술 스택 정리​

프론트엔드​

이번 V26에서 초반에 먼저 손댄 건 기술 스택 정리였다. 프론트 코드베이스는 JavaScript 중심에서 TypeScript 중심으로 옮기면서 타입 안정성을 확보했고, 화면 단위 수정할 때 런타임에서 늦게 터지던 문제를 컴파일 타임에 더 빨리 잡을 수 있게 만들었다.

또한, 바라봄 앱의 프레임워크도 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가 장기 유지보수에 유리했다.

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로 분리했다.

기존에는 파일이 여기저기 흩어져 있었는데, 이제는 ./src/ 디렉토리를 기준으로 기능별로 명확하게 구분했다. 53개의 페이지 기능을 pages 폴더로 정리했고, 공통 유틸리티는 shared로 모았다.

src/
  pages/      # 53개의 페이지 기능 (예: DiaryWrite/index.tsx)
  shared/     # 공통 API, React Query, hooks, store, UI
  widgets/    # 재사용 가능한 UI 조각과 프로바이더

마이그레이션 정책은 단순하다. 일단 중복을 허용하고, 공통 쓰임새가 명확하면 리뷰 후 shared나 widgets로 승격시킨다. 페이지별 상태는 가능한 로컬 context나 model로 처리하고, 꼭 필요할 때만 전역 store를 쓴다.

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

그 외​

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

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

잡담 및 하소연​

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

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

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

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

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

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

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

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

👨‍💻🤝

바라봄 홈페이지 : https://barabom.me

개발자 인스타그램 : https://www.instagram.com/right_hot