💰 BroBean 가계부 앱 프로젝트 시작

이번 프로젝트는 연인이나 부부가 함께 사용할 수 있는 공유 가계부 서비스 BroBean 개발을 목표로 시작했다.

기존에는 개인 단위의 가계부 서비스가 많았지만, 실제 생활에서는 커플이나 부부처럼 두 명 이상의 사용자가 함께 소비 기록을 관리해야 하는 경우가 많다.

BroBean은 이러한 상황을 고려하여:

• 함께 사용하는 가계부
• 소비 기록 공유
• 공동 목표 관리
• 직관적인 모바일 중심 UI

를 목표로 개발하는 프로젝트다.

이번 프로젝트는 처음부터 완성된 서비스를 빠르게 만드는 것보다, 실제 서비스 개발 과정을 경험하는 것을 목표로 진행한다.

전체 개발 순서는 다음과 같이 계획했다.

Frontend 개발

↓

UI / Layout / 기능 설계

↓

Mock Data 기반 기능 구현

↓

Database 및 API 설계

↓

Spring Boot Backend 개발

↓

서비스 배포

이번 첫 번째 단계에서는 프론트엔드 환경 구축과 기술 스택 선정 과정을 기록한다.

🏗️ 프로젝트 개발 방향

BroBean은 모바일 사용성을 가장 중요하게 고려했다.

가계부 서비스 특성상 사용자는 PC보다 모바일 환경에서 소비 내역을 빠르게 기록하는 경우가 많기 때문이다.

따라서 초기 개발 방향은 다음과 같이 설정했다.

Mobile First UI

↓

Responsive Web

↓

Hybrid App 확장 고려

↓

Backend API 연결

처음부터 네이티브 앱으로 개발하기보다, 웹 기반으로 서비스를 제작한 이후 필요하다면 하이브리드 앱 형태로 확장하는 방향을 선택했다.

⚙️ Frontend 기술 스택 선정 과정

후보군 검토

프론트엔드 개발 환경을 결정하기 위해 다음 기술들을 검토했다.

React + Next.js

Vue + Nuxt

Flutter

React Native

모바일 환경까지 고려하면 Flutter나 React Native도 좋은 선택지가 될 수 있었지만, 이번 프로젝트의 방향은 모바일 웹 기반 서비스를 먼저 완성한 뒤 필요하다면 하이브리드 앱으로 확장하는 것이었다.

또한 이전 Brolog 프로젝트를 개발하면서 Nuxt 생태계를 경험했고, SSR 구조와 Nuxt Content 기반 개발 환경을 활용해본 경험이 있었다.

Brolog에서는 Nuxt Docus Theme라는 기존 템플릿 위에서 프로젝트를 확장하는 방식으로 진행했다면, 이번 BroBean에서는 Nuxt 프로젝트를 직접 구성하면서 프레임워크의 구조와 동작 방식을 더 깊게 이해하는 것을 목표로 했다.

이에 따라 최종적으로 Vue 기반 생태계를 활용할 수 있는 Nuxt를 선택했다.

🚀 Nuxt 선택 이유

최종 Frontend 기술 스택은 다음과 같이 결정했다.

Nuxt 4

Vue 3

TypeScript

조합을 선택했다.

기존 경험을 기반으로 한 확장성

Brolog 프로젝트를 진행하면서 Nuxt 기반 개발 경험을 쌓았고, 실제 서비스 형태의 프로젝트에서 Nuxt가 제공하는 구조적인 장점을 확인할 수 있었다.

특히:

• 자동 라우팅 시스템
• Vue 기반 컴포넌트 구조
• SSR / SPA 선택 가능
• Nuxt Module 생태계
• TypeScript 지원

등은 장기적으로 서비스를 확장하는 데 적합하다고 판단했다.

하지만 이번 프로젝트에서는 기존처럼 준비된 템플릿이나 Theme를 활용하는 방식이 아니라, 프로젝트 생성부터 디렉토리 구조 설계, UI 구성, 상태 관리까지 직접 경험하는 것을 목표로 했다.

Vue 기반 개발 경험 활용

Vue 기반 개발 방식은 컴포넌트 구조가 직관적이고, UI 중심 서비스 개발과 잘 맞는다.

가계부 서비스는:

• 거래 내역 목록
• 입력 Form
• Modal
• Chart
• Category 관리
• 사용자별 상태 관리

등 다양한 UI 컴포넌트를 필요로 한다.

Vue의 컴포넌트 기반 구조와 Nuxt의 프로젝트 관리 방식은 이러한 서비스 구조를 설계하는 데 적합하다고 판단했다.

모바일 웹 → 하이브리드 앱 확장 고려

BroBean은 처음부터 모바일 사용성을 고려한 가계부 서비스를 목표로 한다.

따라서:

Mobile First Web

↓

Responsive UI

↓

Hybrid App 확장

방향으로 개발할 예정이다.

Nuxt는 웹 서비스 개발에 최적화되어 있지만, 모바일 환경을 고려한 UI 설계와 API 기반 구조를 구성한다면 추후 앱 형태로 확장하는 것도 충분히 고려할 수 있다.

결과적으로 BroBean은 단순히 익숙한 기술을 선택한 것이 아니라,

Brolog에서 경험한 Nuxt 생태계를 기반으로, 이번에는 프로젝트 초기 구성부터 직접 설계하며 Nuxt를 더 깊게 이해하기 위한 선택으로 결정했다.

SSR과 SPA 모두 지원

Nuxt는 하나의 프로젝트에서 다양한 렌더링 방식을 선택할 수 있다.

예:

Public Page

→ SSR


App Page

→ SPA


Static Content

→ SSG

추후 각 페이지별 성격에 맞춰 유연하게 변경할 수 있다는 점이 장점이다.

자동화된 프로젝트 구조

Nuxt는 기본적으로:

• 라우팅
• 디렉토리 구조
• 서버 API 구조
• 빌드 환경

등을 프레임워크 레벨에서 제공한다.

따라서 초기 설정에 시간을 많이 사용하지 않고 서비스 개발에 집중할 수 있다.

하이브리드 앱 확장 가능성

현재는 모바일 웹 형태로 개발하지만, 추후:

• Capacitor
• WebView 기반 앱
• PWA

등을 활용하여 앱 형태로 확장하는 가능성을 고려했다.

🎨 UI 기술 스택 선정 과정

Frontend UI 개발 방식도 여러 후보를 검토했다.

후보

Bootstrap

Vuetify

Tailwind CSS

Material UI

Bootstrap 검토

Bootstrap은 오랜 기간 사용된 UI Framework이며 빠르게 화면을 구성할 수 있다는 장점이 있다.

하지만 최근 신규 프로젝트에서는 다음과 같은 한계가 있었다.

장점:

• 익숙함
• 빠른 개발 가능

단점:

• 디자인 커스터마이징 제한
• 기존 Bootstrap 스타일 의존성 증가
• 독창적인 UI 구성 어려움

BroBean은 서비스 형태의 앱 UI를 목표로 하기 때문에 다른 선택지를 검토했다.

Tailwind CSS 선택

최종적으로 Tailwind CSS를 선택했다.

선택 이유:

• 최근 프론트 개발 트렌드와 적합
• 반응형 UI 구현 편리
• 디자인 시스템 구축 용이
• 컴포넌트 기반 개발과 궁합 우수

특히 모바일 우선 UI를 제작하는 과정에서 작은 화면부터 확장하는 방식과 잘 맞는다.

🧩 Nuxt UI 선택

Tailwind CSS와 함께:

Nuxt UI

+

Tailwind CSS

조합을 사용하기로 결정했다.

Nuxt UI는 Nuxt 공식 생태계 기반 UI 라이브러리로 기본적인 서비스 UI 구성 요소를 제공한다.

제공 기능:

• Button
• Card
• Input
• Modal
• Form
• Navigation

등 다양한 Vue Component를 바로 활용할 수 있다.

이를 통해 직접 CSS를 작성하는 시간을 줄이고 서비스 기능 개발에 집중할 수 있다.

🔧 Backend 기술 방향

Backend 개발은 Frontend 기반 UI와 기능 설계가 완료된 이후 진행할 예정이다.

Frontend에서 먼저:

UI / UX 설계

↓

Mock Data 기반 기능 구현

↓

API Interface 설계

↓

Backend 개발

순서로 진행하며, 이후 Spring Boot 기반 Backend를 연결하는 방향으로 계획했다.

최종 Backend Stack은 다음과 같이 구성할 예정이다.

Spring Boot

JPA

JWT

...

☕ Spring Boot 선택 이유

Spring Boot를 선택한 가장 큰 이유는 기존 개발 경험과 숙련도 때문이다.

기존에 Java 기반 Backend 개발 경험이 있기 때문에, 다른 Backend Framework를 새롭게 학습하는 것보다 익숙한 기술을 활용하여 서비스 설계와 구현 자체에 집중하는 방향이 더 적합하다고 판단했다.

특히:

• API 설계
• Database 모델링
• 인증 구조
• 서버 아키텍처
• 예외 처리

등 Backend 핵심 영역에서 기존 경험을 그대로 활용할 수 있다는 장점이 있다.

검증된 생태계와 안정성

Spring 생태계는 오랜 기간 다양한 서비스 환경에서 사용되어 왔으며, 안정적인 서버 개발 환경을 제공한다.

BroBean은 단순한 개인 테스트 프로젝트가 아니라:

• 사용자 관리
• 거래 내역 저장
• 카테고리 관리
• 통계 데이터 처리

등 실제 서비스 형태를 고려하고 있기 때문에 안정적인 Backend Framework 선택이 중요했다.

REST API 기반 Frontend 분리 구조

BroBean은 Frontend와 Backend를 분리하는 구조로 개발할 예정이다.

구성:

Nuxt Frontend

↓

REST API

↓

Spring Boot Backend

↓

Database

이러한 구조에서는 명확한 API 설계와 유지보수가 중요하다.

Spring Boot는 REST Controller 기반으로 API 서버를 구성하기 용이하며, Frontend와 독립적인 Backend 환경을 구축하기 적합하다.

JPA 기반 데이터 모델링

가계부 서비스는 다양한 관계형 데이터를 관리해야 한다.

예:

User

↓

Couple / Group

↓

Transaction

↓

Category

↓

Budget

이처럼 사용자와 소비 데이터 사이에는 여러 관계가 존재한다.

Spring Boot와 JPA를 활용하면 객체 중심으로 Entity를 설계하고 데이터 관계를 관리할 수 있어, 서비스 규모가 커졌을 때 유지보수하기 좋은 구조를 만들 수 있다.

결과적으로 BroBean의 Backend는 단순히 유행하는 기술을 선택한 것이 아니라,

기존 Java Backend 개발 경험을 활용하면서 안정성과 확장성을 확보할 수 있는 현실적인 선택으로 Spring Boot를 결정했다.

📦 최종 예상 기술 스택

Frontend

Nuxt 4

Vue 3

TypeScript

Nuxt UI

Tailwind CSS

Pinia

VueUse

Dayjs

Zod

Chart.js

Backend

Spring Boot

JPA

JWT

...

Database

현재 미정이며 Backend 설계 과정에서 결정 예정이다.

🚀 Nuxt 4 프로젝트 생성 시작

Nuxt 4 프로젝트 생성을 진행했다.

생성 과정에서 확인한 CLI 버전:

create-nuxt@3.37.0

처음에는 Nuxt 4 프로젝트인데 왜 create-nuxt 3.x 버전이 표시되는지 의문이 있었지만,

이는 프로젝트 생성 CLI 패키지 버전이며 Nuxt Framework 버전과는 별개이다.

따라서 정상적인 동작이다.

Nuxt Template 선택

생성 과정에서 여러 Template 옵션을 확인했다.

content

minimal

module

ui

v5-nightly

각 Template의 목적은 다음과 같다.

content

Content 기반 사이트 제작용 Template.

적합한 서비스:

Blog

Documentation

CMS Site

Nuxt Content 기반 프로젝트에 적합하지만 BroBean과 같은 서비스 개발에는 필요하지 않았다.

minimal

최종 선택한 Template이다.

특징:

• 가장 기본적인 Nuxt 환경
• 필요한 모듈만 직접 추가 가능
• 프로젝트 구조 이해 용이

서비스 개발 목적에서는 불필요한 기능 없이 시작할 수 있다는 장점이 있다.

module

Nuxt Module 개발 목적이다.

BroBean 서비스 개발과는 방향이 다르기 때문에 선택하지 않았다.

ui

Nuxt UI가 포함된 Template이다.

처음에는 고려했지만:

• 필요한 모듈 직접 관리
• 프로젝트 구조 이해
• 설치 과정 직접 경험

목적으로 minimal Template을 선택했다.

v5-nightly

Nuxt 5 테스트 버전이다.

안정적인 서비스 개발 목적이므로 사용하지 않았다.

📦 초기 패키지 설치 과정

Nuxt 프로젝트 생성 이후 필요한 라이브러리를 추가하는 과정을 진행했다.

처음에는 Nuxt에서 제공하는 Module 설치 방식을 활용하려고 했다.

하지만 현재 일부 네트워크가 제한된 개발 환경으로 인해 일부 Module 설치 과정에서 문제가 발생했다.

⚠️ 프로젝트 생성 과정에서 발생한 네트워크 문제

Nuxt Module 추가 방식 변경

Nuxt에서는 일반적으로 다음과 같은 방식으로 Module을 추가할 수 있다.

npx nuxi module add ui

기존 방식대로 Nuxt UI Module 추가를 시도했다.

하지만 다음과 같은 오류가 발생했다.

Cannot search in the Nuxt Modules database

FetchError:
GET https://api.nuxt.com/modules?version=all

fetch failed


It seems that ui is not a Nuxt module.

처음에는 Nuxt UI Module 자체가 문제가 있는 것으로 보였지만, 원인을 확인한 결과 다른 문제였다.

🔍 문제 원인 확인

오류 메시지를 분석한 결과:

api.nuxt.com 접근 실패

가 핵심 원인이었다.

nuxi module add 명령은 내부적으로 Nuxt Module Registry API를 조회하여 Module 정보를 확인한다.

하지만 현재 개발 환경에서는 외부 API 접근이 제한되어 있었기 때문에 Module 검색 과정에서 실패했다.

즉:

nuxi module add

↓

Nuxt Module Registry 조회

↓

api.nuxt.com 접근

↓

실패

상태였다.

🛠️ npm install 방식으로 변경

문제를 해결하기 위해 Nuxt Module도 일반 npm 패키지처럼 직접 설치하는 방식으로 변경했다.

최종 설치 방식:

Nuxt Module

→ npm install 직접 추가


일반 Library

→ npm install 직접 추가

🎨 Nuxt UI 설치

npm install @nuxt/ui

Nuxt UI를 직접 설치했다.

📌 Pinia 설치

상태 관리를 위해 Pinia를 추가했다.

npm install pinia @pinia/nuxt

추후 관리 예정 상태:

User State

↓

Authentication

↓

Ledger Data

↓

Application State

📚 추가 Library 설치

서비스 개발에 필요한 기본 Library를 추가했다.

npm install @vueuse/core dayjs zod chart.js vue-chartjs

각 Library의 역할:

가계부 서비스 특성상 날짜 처리와 통계 시각화 기능이 중요하기 때문에 초기 단계에서 추가했다.

🎨 Icon Library 추가

UI 아이콘 사용을 위해 Iconify를 추가했다.

npm install @iconify/vue

활용 예정:

Navigation Icon

↓

Category Icon

↓

Action Button Icon

✅ npm install 결과

모든 패키지 설치는 정상적으로 완료되었다.

설치 로그:

added 622 packages

Types generated in .nuxt

Nuxt Type 생성까지 완료되면서 기본 개발 환경 구성이 끝났다.

⚠️ 설치 과정에서 발생한 Warning

설치 과정에서는 몇 가지 Warning이 발생했다.

대부분 직접적인 오류가 아닌 Dependency 또는 개발 환경 관련 메시지였다.

1. Deprecated Dependency Warning

발생 메시지:

npm warn deprecated glob@10.5.0

확인 결과 직접 설치한 패키지가 아닌 내부 Dependency에서 발생한 경고였다.

즉:

BroBean

↓

Nuxt

↓

Internal Dependency

↓

glob

형태로 포함된 패키지였다.

현재 프로젝트 코드에서 직접 사용하는 패키지가 아니기 때문에 우선 무시했다.

2. Nuxt Devtools 초기화 Warning

발생 메시지:

WARN [NUXT_B8014]

Module @nuxt/devtools was slow to set up

Nuxt Devtools 초기화 시간이 오래 걸렸다는 의미다.

빌드 실패나 실행 오류가 아니며 개발 환경에서 발생하는 성능 관련 Warning이다.

현재 단계에서는 문제 없이 진행했다.

3. npm audit Vulnerability Warning

발생 메시지:

11 high severity vulnerabilities

npm 설치 이후 Dependency 취약점 알림이 발생했다.

일반적으로:

npm audit fix --force

명령을 사용할 수 있지만 현재는 실행하지 않았다.

이유:

npm audit fix --force

↓

Dependency Version 변경

↓

Nuxt Package 충돌 가능성

이 있기 때문이다.

초기 프로젝트 단계에서는 안정적인 Dependency 상태 유지가 더 중요하다고 판단했다.

4. allow-scripts Warning

발생 메시지:

npm warn allow-scripts

esbuild

npm의 보안 정책 관련 Warning이다.

일부 패키지는 설치 과정에서 Script 실행이 필요한데, 최근 npm은 보안을 위해 이를 제한한다.

필요한 경우:

npm approve-scripts

를 통해 허용할 수 있다.

⚙️ Nuxt Config 초기 설정

기본적인 Nuxt Module 설정을 추가했다.

현재 구성:

export default defineNuxtConfig({

  modules: [
    '@nuxt/ui',
    '@pinia/nuxt'
  ],

  css: [
    '~/assets/css/main.css'
  ]

})

사용 Module:

@nuxt/ui

↓

UI Component


@pinia/nuxt

↓

State Management

구조로 구성했다.

🎨 CSS 경로 설정 문제 해결

초기 CSS 설정 과정에서 경로 오류가 발생했다.

작성했던 설정:

css: [
  '~/app/assets/css/main.css'
]

실행 결과:

Cannot find module '~/app/assets/css/main.css'

오류가 발생했다.

🔍 원인 분석

Nuxt 4에서는 app 디렉토리를 사용하는 구조가 추가되었지만, Alias 경로에서는 혼동이 있었다.

~ Alias는 프로젝트 Root 기준으로 동작한다.

따라서:

~/app/assets/css/main.css

는:

Root

↓

app

↓

assets

↓

css

구조를 다시 탐색하게 된다.

하지만 CSS 설정에서는 Nuxt 4 권장 구조에 맞춰 다음과 같이 설정한다.

수정:

css: [
  '~/assets/css/main.css'
]

현재 CSS 구조

최종 구조:

app/

├── app.vue

└── assets/

    └── css/

        └── main.css

Nuxt 4에서는 app 디렉토리 내부 구조와 Alias 사용 위치를 정확히 이해하는 것이 중요하다.

🔤 Font 관련 Network Warning

개발 실행 과정에서 Font Provider 관련 Warning도 확인했다.

발생 메시지:

Could not fetch from
https://fonts.google.com/metadata/fonts


Could not fetch from
https://api.fontshare.com/v2/fonts


Could not fetch from
https://fonts.bunny.net/list


Could not fetch from
https://api.fontsource.org/v1/fonts

원인

Nuxt UI 또는 관련 Provider가 외부 Font API 정보를 조회하려고 했지만 현재 개발 환경의 네트워크 제한으로 접근하지 못했다.

구조:

Nuxt UI

↓

Font Provider 조회

↓

External API Request

↓

Network 제한

↓

실패

대응 방향

외부 Font Provider 조회 문제는 단순히 Font 다운로드 실패 문제가 아니라, 개발 환경에서 불필요한 외부 API 요청이 발생하는 문제였다.

따라서 외부 Provider를 그대로 사용하는 방식 대신, 로컬 개발 환경에서는 외부 통신을 차단하고 설치된 패키지와 기본 설정을 활용하는 방향으로 변경했다.

수정한 Nuxt 설정:

// 아이콘 로컬 번들링 강제 지정
icon: {
  serverBundle: 'local',
},

// 외부 Font Provider Metadata 조회 차단
fonts: {
  providers: {
    google: false,
    fontsource: false,
    bunny: false,
    googleicons: false,
    fontshare: false,
    adobe: false,
  },
},

Icon Provider 로컬 번들링 적용

기존에는 Icon Provider가 외부 API를 통해 아이콘 정보를 조회하려고 했다.

구조:

Nuxt UI

↓

Icon Provider

↓

External API 요청

↓

Network 제한으로 실패

이를 해결하기 위해:

icon: {
  serverBundle: 'local',
}

설정을 추가했다.

변경 후:

Nuxt UI

↓

Local Icon Bundle

↓

설치된 Package 사용

형태로 동작하도록 변경했다.

이를 통해 개발 환경에서 외부 Icon API 접근 없이 로컬 패키지만 사용하도록 구성했다.

Font Provider 비활성화

Font 관련 Warning 역시 외부 Provider Metadata 조회 과정에서 발생했다. 이 문제를 해결하기 위해 사용하지 않는 Font Provider를 모두 비활성화했다.

fonts: {
  providers: {
    google: false,
    fontsource: false,
    bunny: false,
    googleicons: false,
    fontshare: false,
    adobe: false,
  },
}

최종 방향

현재 개발 단계에서는 디자인보다 서비스 구조와 기능 개발이 우선이기 때문에 외부 Font 의존성을 제거했다.

최종 방향:

External Font Provider

❌ 사용하지 않음


Local Bundle

✅ 사용


System Font

✅ 사용

추후 서비스 배포 단계에서 필요한 경우:

• 자체 Font 파일 추가
• CDN 기반 Font 적용
• 브랜드 아이덴티티에 맞는 Typography 적용

등을 검토할 예정이다.

현재는 외부 네트워크 환경에 영향을 받지 않는 안정적인 개발 환경 구성을 우선했다.

📁 Nuxt 4 공식 디렉토리 구조 이해

Nuxt 4에서는 기존 Nuxt 3와 다르게 app 디렉토리가 중심 구조가 된다.

기본 구조:

frontend/

├── app/

│   ├── app.vue
│
│   ├── assets/
│
│   ├── components/
│
│   ├── layouts/
│
│   ├── pages/
│
│   ├── composables/
│
│   ├── middleware/
│
│   ├── plugins/
│
│   └── utils/


├── public/

├── server/

├── shared/

├── nuxt.config.ts

└── package.json

🤔 처음 생성 시 폴더가 없는 이유

Nuxt는 처음부터 모든 폴더를 생성하지 않는다.

Nuxt의 철학은:

필요한 기능이 추가될 때 구조를 생성한다.

이다.

예를 들어 처음 생성 상태:

app/

└── app.vue

만 존재해도 정상이다.

이후:

app/pages/index.vue

파일을 생성하면 자동으로 Routing 기능이 활성화된다.

🏗️ BroBean 프로젝트 구조

서비스 개발 방향에 맞춰 다음 구조를 계획했다.

frontend/

├── app/

│   ├── app.vue

│   ├── assets/

│   │   └── css/

│   │       └── main.css

│   │
│   ├── components/

│   ├── layouts/

│   ├── pages/

│   ├── composables/

│   └── utils/


├── stores/

├── services/

├── types/

├── constants/

├── mock/

├── public/

├── server/

├── nuxt.config.ts

📦 추가 폴더 설계 이유

stores

Pinia 상태 관리 영역이다.

예:

auth.ts

user.ts

ledger.ts

관리 대상:

• 로그인 상태
• 사용자 정보
• 가계부 데이터

services

Backend API 통신 영역이다.

Spring Boot 연결 이후 사용한다.

예:

auth.service.ts

ledger.service.ts

types

TypeScript 타입 정의 영역이다.

예:

User

Transaction

Category

mock

Backend 개발 전 테스트 데이터를 관리한다.

예:

transactions.json

users.json

Frontend 기능 검증을 위해 활용할 예정이다.

📍 현재 진행 상태

완료:

✅ Nuxt 4 프로젝트 생성

✅ Vue 3 + TypeScript 구성

✅ Nuxt UI 설치

✅ Pinia 설치

✅ 기본 구조 설계

✅ Frontend 기술 스택 결정

📌 프로젝트 시작을 마치며

이번 글에서는 BroBean 서비스를 개발하기 위한 초기 환경 구성과 기술 스택 선정을 진행했다.

단순히 가계부 기능을 빠르게 구현하는 것보다, 장기적으로 유지 가능한 서비스 구조를 만드는 것을 목표로 프로젝트 방향을 설정했다.

특히 이번 프로젝트에서는 이전 Brolog 개발 경험과 다르게 준비된 템플릿이나 기존 구조에 의존하지 않고, 프로젝트 생성부터 디렉토리 구성, 라이브러리 선택, 개발 환경 설정까지 직접 설계하는 과정을 경험하는 것에 의미를 두었다.

현재까지 결정된 주요 방향은 다음과 같다.

Frontend

→ Nuxt 4 + Vue 3 + TypeScript 기반 구축


UI System

→ Nuxt UI + Tailwind CSS


State Management

→ Pinia 기반 상태 관리


Backend

→ Spring Boot + JPA 기반 API 서버


Database

→ 서비스 설계 이후 결정

앞으로 BroBean은 단순한 가계부 기능 구현을 넘어,

• 모바일 환경을 고려한 UI/UX 설계
• 사용자와 연인이 함께 사용할 수 있는 데이터 구조
• 안정적인 Backend API 설계
• 실제 서비스 운영을 고려한 아키텍처 구성

까지 단계적으로 발전시키는 것을 목표로 한다.

현재는 Frontend 기반을 구축하는 단계이며, 이후 화면 구성과 주요 기능을 구현하면서 서비스의 전체적인 흐름을 구체화해 나갈 예정이다.

다음 개발 과정에서는 Nuxt UI와 Tailwind CSS를 활용한 모바일 중심 Layout 구성부터 시작하여, BroBean의 실제 화면과 사용자 경험을 만들어가는 과정을 기록한다.