개발 기록/회고
Spring Service에서 객체 생성 책임을 분리해야 하는 이유 – 실무에서 Factory 패턴을 도입한 회고
2025.05.29
– 에스크로 서비스 개발 중 도입한 Factory 패턴 회고도입: 기능 구현은 끝났지만, 찝찝했던 코드에스크로 거래를 등록하는 기능을 만들던 중이었다.비즈니스 흐름은 단순했다.거래 등록 요청을 받아 EscrowTransaction 객체를 만들고, 이를 저장소에 저장하면 되는 구조였다.초기 코드는 다음과 같았다.public Long registerTransaction(TransactionRegisterCommand command) { EscrowTransaction transaction = new EscrowTransaction( command.getBuyerId(), command.getSellerId(), command.getItemId(), co..
개발 기록/회고
Spring MVC Controller에서 new를 없애야 하는 진짜 이유
2025.05.28
Spring MVC Controller에서 객체 생성을 지양해야 하는 이유– 에스크로 프로젝트를 진행하며 얻은 실전 교훈에스크로 트랜잭션 상태 변경 기능을 만들면서 겪은 고민Spring Boot 기반으로 에스크로 서비스를 직접 구현하면서, 거래 상태를 변경하는 기능을 만들게 되었다.처음에는 빠르게 동작하는 코드를 만드는 데 집중했고, 자연스럽게 Controller 내부에서 필요한 객체들을 직접 생성하는 방식으로 구현했다.아래는 처음 작성한 코드이다..@PostMapping("/{id}/status")public ResponseEntity updateStatus( @PathVariable Long id, @RequestBody @Valid TransactionStatusUpdate..
개발 기록/회고
Spring Boot 입문기 – @Getter, @Setter, 그리고 Controller 어노테이션을 처음 마주했을 때
2025.05.26
최근 개인 프로젝트를 진행하면서 본격적으로 Spring Boot를 처음 사용하게 되었다.그동안 Node.js 위주로 백엔드를 개발해왔기 때문에 Java 기반의 Spring 생태계는 익숙하지 않았다.그래서 하나하나 개념을 정확하게 정리하고 넘어가는 것이 중요하다고 판단했다.Spring을 사용하면서 가장 먼저 접하게 된 것이 바로 @Getter, @Setter, @RestController 같은 어노테이션들이었다.처음엔 단순히 자동으로 코드를 줄여주는 도구 정도로 생각했지만, "어떤 상황에서 어떤 어노테이션을 써야 하고, 왜 써야 하는지"가 점점 더 중요하게 느껴졌다.이 글은 Spring Boot 입문자가 실무에 적응하는 과정에서 마주치는 핵심 어노테이션들을 정리한 기록이다.Entity와 DTO는 어떤 기준..
개발 기록/회고
TokenService는 왜 static이어야 했을까? 객체지향을 넘나드는 JS 설계 회고
2025.05.12
JavaScript에서 class로 바꾸면서 static을 사용하는 이유최근에 작성한 코드에서 기존 함수 기반 설계를 class 구조로 전환하면서 static 키워드를 사용하게 되었다. 이 과정에서 왜 static을 사용해야 했는지, 언제 static이 유용한지를 직접 느끼고 정리해본다.1. 클래스 기반 구조로 전환한 이유기존에는 다음과 같은 순수 함수 구조로 코드를 구성했었다.function generateToken() { ... }function verifyToken(token) { ... }하지만 점점 기능이 늘어나면서함수가 서로 강하게 연관되고네임스페이스 충돌이 걱정되고유지보수와 테스트가 어려워지면서관련 로직을 하나의 책임 단위(class)로 묶는 구조로 변경하였다.class TokenServic..
개발 기록/회고
Node.js 인증 서비스의 구조적 문제와 개선을 위한 리팩토링 여정
2025.05.08
기존 구조의 문제점지금까지의 auth-service는 기능적으로는 정상 동작했지만, 아키텍처적 관점에서 다음과 같은 구조적 문제를 안고 있었습니다.1. 절차적(Procedural) 서비스 구조registerUser, loginUser 등의 함수가 한 파일에 모여 있고,각 함수는 다음과 같은 다양한 책임을 동시에 수행했습니다:DB 접근 (User, Session, Token)비즈니스 로직 (비밀번호 비교, 토큰 발급 등)인프라 처리 (Redis, 이메일 등)이는 단일 책임 원칙(SRP)을 위반하며, 수정 및 테스트가 어렵고 재사용성이 떨어집니다.2. 책임 분리 미흡비즈니스 로직과 유틸 로직(bcrypt, jwt, redis, email)이 뒤섞여 있었습니다.결과적으로 도메인 규칙과 인프라 구현이 혼재되어 ..