🚀 첫 백엔드 프로젝트 만들기: Expense Tracker API

발행: 1일 전 (2026년 3월 8일 AM 09:36 GMT+9)

5 분 소요

원문: Dev.to

Source: Dev.to

Project Overview

Expense Tracker API는 사용자가 다음을 할 수 있는 RESTful 백엔드 서비스입니다:

비용 카테고리 생성 및 관리
비용 추가 및 추적
카테고리별 비용 정리
API 엔드포인트를 통한 CRUD 작업 수행

모바일 앱, 웹 대시보드 또는 재무 관리 시스템의 백엔드 엔진으로 활용될 수 있습니다.

Tech Stack

Node.js – 런타임 환경
Express.js – API 구축을 위한 웹 프레임워크
PostgreSQL – 관계형 데이터베이스
Sequelize ORM – 데이터베이스 모델링 및 마이그레이션
Docker – 컨테이너화된 개발 환경
TablePlus – 데이터베이스 관리

이 도구들은 현대 백엔드 시스템이 어떻게 구조화되고 배포되는지를 보여주는 데 도움이 됩니다.

Database Design

API는 두 개의 주요 엔터티를 중심으로 구축됩니다:

Expenses

Expenses는 개별 재무 기록을 나타냅니다. 각 expense는 다음을 포함합니다:

id
title
amount
categoryId (foreign key)
createdAt
updatedAt

categoryId는 각 expense를 카테고리와 연결하여 적절한 분류를 보장합니다.

API Endpoints

표준 REST 엔드포인트가 제공됩니다.

Expenses

POST /expenses
GET /expenses
GET /expenses/:id
PUT /expenses/:id
DELETE /expenses/:id

이 엔드포인트들을 통해 재무 데이터를 관리하는 전체 CRUD 기능을 사용할 수 있습니다.

Key Things I Learned

이 프로젝트를 진행하면서 여러 백엔드 개념에 대한 이해가 깊어졌습니다.

Database Migrations

Sequelize 마이그레이션을 사용하면 스키마 변경을 버전 관리할 수 있어 수동으로 테이블을 생성할 필요가 없어졌습니다.

Model Relationships

외래키를 통해 expense를 카테고리와 연결함으로써 관계형 데이터베이스가 데이터 무결성을 어떻게 강제하는지 명확히 알 수 있었습니다.

API Architecture

프로젝트를 다음과 같이 구성했습니다:

Routes
Controllers
Models
Migrations

이러한 분리 구조는 코드베이스를 깔끔하고 유지보수하기 쉽게 만들어 줍니다.

Error Handling

주로 마주친 문제는 다음과 같습니다:

마이그레이션 순서 오류
데이터베이스 연결 문제
잘못된 모델 참조

이러한 디버깅 과정을 통해 백엔드 동작에 대한 이해가 향상되었습니다.

Using Docker for Development

Docker는 개발 환경을 표준화하여 런타임, 의존성 및 설정을 함께 패키징함으로써 애플리케이션이 다양한 시스템에서 일관되게 실행되도록 합니다.

Future Improvements

예정된 개선 사항:

User authentication (JWT) – 이미 구현됨
날짜별 expense 필터링
대용량 데이터셋을 위한 페이지네이션
expense 분석 엔드포인트
Swagger를 이용한 API 문서화

Back to Blog

MERN 프로젝트 설정에 지쳐서 자동화하는 VS Code 확장 프로그램을 만들었습니다

왜 MERN DevBoost를 만들었는가? 나는 많은 MERN 스택 프로젝트를 만들고 있었는데, 초기 설정에 항상 30~40분이 걸렸다. 각 프로젝트마다 다음이 필요했다: - 식별자 생성…

Archify 소개: 아키텍처 아이디어에서 Spring Boot 코드까지

문제 모든 백엔드 개발자는 이 순간을 경험해 본 적이 있다: 새로운 프로젝트를 시작하면서 이미 아키텍처를 염두에 두고—아마도 간단한 REST 서비스와 몇 개의 엔드포인트만을 생각하고—시작한다. 하지만 프로젝트가 진행될수록 요구사항이 늘어나고, 복잡도가 급격히 증가한다. ### 원인 1. **초기 설계 부족** - 프로젝트 초기에 충분한 도메인 모델링과 데이터 흐름 설계를 하지 않으면, 나중에 구조를 바꾸는 데 큰 비용이 든다. 2. **기능 폭발** - 초기에는 “읽기 전용” API만 필요했지만, 곧 쓰기, 인증, 권한, 실시간 알림 등 다양한 기능이 추가된다. 3. **기술 스택 변화** - 새로운 라이브러리나 프레임워크가 등장하면서 기존 코드를 교체하거나 통합해야 하는 상황이 발생한다. ### 해결책 #### 1. 도메인 중심 설계(Domain‑Driven Design) 적용 - **Bounded Context**를 명확히 정의하고, 각 컨텍스트마다 독립적인 모델과 서비스 계층을 만든다. - **Entity**, **Value Object**, **Aggregate** 등을 활용해 비즈니스 로직을 캡슐화한다. #### 2. 레이어드 아키텍처 도입 - **Presentation Layer** (Controller / Handler) – HTTP 요청을 받아 DTO 로 변환하고, 서비스에 위임한다. - **Application Layer** – 트랜잭션 경계와 워크플로우를 정의한다. - **Domain Layer** – 핵심 비즈니스 로직과 도메인 규칙을 구현한다. - **Infrastructure Layer** – DB, 메시지 브로커, 외부 API 등 기술적 세부 사항을 담당한다. #### 3. 인터페이스와 의존성 역전(Dependency Inversion) - 상위 레이어가 하위 레이어에 의존하지 않도록 **Repository Interface**, **Service Interface** 등을 정의하고, 구현은 인프라 레이어에 둔다. - 스프링에서는 `@Autowired` 대신 **Constructor Injection**을 사용하고, 테스트 시에는 **Mock** 구현체를 주입한다. #### 4. 모듈화와 마이크로서비스 전략 - 시스템이 일정 규모를 넘어가면 **Domain‑Driven Microservices** 혹은 **Modular Monolith** 로 전환한다. - 각 모듈(또는 서비스)은 독립적인 데이터베이스 스키마와 배포 파이프라인을 갖는다. #### 5. 자동화된 테스트와 CI/CD 파이프라인 - **Unit Test**, **Integration Test**, **Contract Test**(예: Spring Cloud Contract) 를 레이어별로 작성한다. - GitHub Actions, GitLab CI 등으로 **빌드 → 테스트 → 배포** 흐름을 자동화한다. #### 6. 문서화와 코드 규칙 - OpenAPI/Swagger 로 API 스펙을 정의하고, **API‑First** 접근법을 채택한다. - 코드 스타일은 **Checkstyle**, **Spotless**, **EditorConfig** 로 일관성을 유지한다. ### 예시 코드 (Spring Boot) ```java // Domain Layer @Entity public class Order { @Id @GeneratedValue private Long id; private LocalDateTime orderDate; @Embedded private Money totalAmount; // 비즈니스 메서드 public void addItem(Product product, int quantity) { … } } // Application Layer @Service @RequiredArgsConstructor public class OrderService { private final OrderRepository orderRepo; private final PaymentGateway paymentGateway; @Transactional public OrderDto placeOrder(CreateOrderCommand cmd) { Order order = new Order(); // 도메인 로직 수행 orderRepo.save(order); paymentGateway.charge(order.getTotalAmount()); return OrderMapper.toDto(order); } } // Infrastructure Layer @Repository public interface OrderRepository extends JpaRepository<Order, Long> {} // Presentation Layer @RestController @RequestMapping('/api/orders') @RequiredArgsConstructor public class OrderController { private final OrderService orderService; @PostMapping public ResponseEntity<OrderDto> create(@RequestBody @Valid CreateOrderCommand cmd) { OrderDto result = orderService.placeOrder(cmd); return ResponseEntity.status(HttpStatus.CREATED).body(result); } } ``` ### 마무리 프로젝트 초기에 **아키텍처 설계**와 **도메인 모델링**에 충분한 시간을 투자하면, 이후 기능 추가나 기술 교체가 훨씬 수월해진다. 레이어드 아키텍처와 DDD 원칙을 적용하고, 의존성 역전 및 자동화된 테스트를 기반으로 하면, 복잡도가 증가해도 유지보수 가능한 코드를 유지할 수 있다. **핵심 포인트** - 초기 설계에 투자 → 장기 비용 절감 - 레이어와 인터페이스로 책임 분리 - 테스트와 CI/CD 로 변경 위험 최소화 - 필요 시 마이크로서비스 혹은 모듈형 모노리식으로 확장

올바른 Razorpay 결제 흐름 (간단히 설명)

많은 결제 통합 문제는 개발자들이 Razorpay 결제 라이프사이클이 실제로 어떻게 작동하는지를 오해하기 때문에 발생합니다. 올바른 흐름을 따르는 것은 보안을 보장합니다.

textlens vs text-readability vs natural: 텍스트 분석을 위한 npm 패키지는?

Node.js용 텍스트 분석 패키지 텍스트 분석이 필요한 Node.js 프로젝트라면 npm이 수십 가지 옵션을 제공합니다. 가장 일반적인 사용 사례를 다루는 세 가지 패키지가 있습니다.

🚀 첫 백엔드 프로젝트 만들기: Expense Tracker API

Project Overview

Tech Stack

Database Design

Categories

Expenses

API Endpoints

Categories

Expenses

Key Things I Learned

Database Migrations

Model Relationships

API Architecture

Error Handling

Using Docker for Development

Future Improvements

관련 글

MERN 프로젝트 설정에 지쳐서 자동화하는 VS Code 확장 프로그램을 만들었습니다

Archify 소개: 아키텍처 아이디어에서 Spring Boot 코드까지

올바른 Razorpay 결제 흐름 (간단히 설명)

textlens vs text-readability vs natural: 텍스트 분석을 위한 npm 패키지는?