몽상실현개발주의

수동 콘솔 작업 + CloudFormation YAML로 관리하던 인프라를 AWS CDK로 옮긴 과정, 그리고 그 결과로 뭐가 실제로 나아졌는지에 대한 기록이다. # YAML로는 안 보이던 것들 CDK를 쓰기 전에는 인프라팀이 있긴 했지만 관리 방식은 수동 콘솔 작업 + CloudFormation을 YAML로 작성하는 조합이었다. 인프라팀이 있어도 변경 이력 관리는 여전히 필요했고 "YAML보다 코드로 관리하는 게 효용이 더 높다"는 판단이 CDK로 넘어간 이유였다. YAML로 관리할 때 구체적으로 힘들었던 건 두 가지였다. 환경별 차이가 안 보였다. staging/production/demo 세 환경이 각자 YAML 파일로 따로 존재하다 보니, "이 세 환경이 정확히 뭐가 다른가"를 파악하려면 콘솔에..

관성적으로 레거시한 구조를 답습하며 자라온 인사관리(HR) 모듈을 DDD + CQRS로 다시 설계한 과정을 정리해봤다. 아키텍처 이론 얘기는 최대한 줄이고, 왜 더는 버틸 수 없었는지, 팀을 어떻게 설득했는지, 그리고 실제로 어떤 문제들이 발생했는지 남겨보려 한다. 고객사가 늘어감에 따라 다양한 요구사항을 기능으로 반영하며 동일한 로직의 메서드가 여기저기로 파편화되기 시작했다. 인사발령 하나 처리하는 코드가 요청 의도에 따라 여러 서비스와 배치 잡에 조금씩 다른 버전으로 흩어져 있는 식이었다. 흔히 겪는 그 상황 맞다. 더 골치 아팠던 건 기획 단계에서 미처 정의하지 못한 "불분명한 영역"이었다. 이런 영역은 결국 코드를 짜던 사람이 그때그때 판단해서 채워 넣었고, 그 판단들이 쌓이고 쌓이면서 사이드 ..

SI 프로젝트로 시작한 하나의 거대한 서버가 있었다. 단일 EC2 모놀리스였던 이 서버가 모듈별 MSA 구조로 전환된 과정, 그리고 그 과도기에 겪은 경험에 대한 기록이다.# 콘웨이의 법칙처음의 프로젝트 구성은 SI 구축형 프로젝트의 초기 구조로 인해 인사 / 근무 / 급여 / 시스템 기능이 전부 한 코드베이스, 한 프로세스로 묶여서 단일 EC2 인스턴스 위에 떠 있었다. BU 가 통합되고 조직이 먼저 개편됐다. 인사 / 근무 / 급여 / 시스템 기능별로 스쿼드가 생기고 각 스쿼드가 자기 도메인을 책임지고 개발을 진행하게 됐다. 서버 구성도 그에 맞춰 도메인별 모듈로 나뉘기 시작했다. 여기까지만 보면 흔한 "모놀리스 → MSA 전환" 성공담처럼 보일 수 있는데, 실제로 과도기에 프로덕션 환경에서 여러 이..

트랜잭션(Transaction)은 데이터베이스에서 하나의 논리적 작업 단위를 의미합니다.예를 들어 “A 계좌에서 B 계좌로 1만 원 송금” 같은 작업은 출금과 입금이 함께 이루어져야 하죠.이런 트랜잭션이 지켜야 할 4가지 기본 원칙을 ACID라고 합니다.이는 단순히 DB 이론이 아니라, 안정적인 시스템을 설계하기 위한 최소 조건이기도 합니다.🧩 1️⃣ Atomicity — 원자성"트랜잭션은 전부 성공하거나 전부 실패해야 한다." 원자성은 트랜잭션이 쪼갤 수 없는 하나의 단위로 실행되어야 한다는 의미입니다.즉, 일부만 성공하는 ‘반쪽 성공’은 절대 허용되지 않습니다. 예시A 계좌에서 10,000원 출금B 계좌에 10,000원 입금입금이 실패하면 출금도 롤백되어야 함Spring/JPA에서의 구현@Trans..

스프링 개발을 하다 보면 “커넥션이 열리면 세션이 생성된다”라는 말을 자주 듣습니다.하지만 정확히 무엇이 생성되고, 내부에서 무슨 일이 일어나는지 잘 모르는 경우가 많습니다.이 글에서는 스프링 서버 ↔ DB 서버 구조를 중심으로 커넥션 / 세션 / 세션 컨텍스트 / 스레드의 관계를 정리해 보았습니다.1️⃣ 커넥션(Connection)은 물리적 통신선이다Spring → DB 사이에는 TCP/IP로 맺어진 소켓 연결이 존재합니다.이게 바로 커넥션입니다.클라이언트(Spring 애플리케이션)가 getConnection()을 호출하면DB 서버와 TCP 소켓이 연결됩니다.이건 단순히 데이터를 주고받는 통로이며,자체적으로는 아무런 상태도 저장하지 않습니다.즉, 커넥션은 “전선(통신선)”과 같습니다.2️⃣ 세션(Ses..

Entity의미: 고유 식별자(ID)를 가진 도메인 객체. 특징 데이터베이스 테이블과 매핑되는 경우가 많음 (JPA Entity). equals/hashCode는 식별자 기준으로 비교. 상태 변경 가능 (mutable). 예시@Entitypublic class Employee { @Id private String id; private String name; private String department;}VO (Value Object)의미: 값 그 자체를 표현하는 객체. 값이 같으면 같은 객체로 취급. 특징 불변(Immutable)으로 설계 권장. 별도의 식별자 불필요. 도메인에서 의미 있는 속성을 묶음. 예시public class Address { priva..

MyBatis는 왜 서비스 레이어가 뚱뚱해질 수밖에 없는가?2. 서비스 비대화를 막는 5가지 보완 패턴과 코드 예시MyBatis를 쓰면 서비스가 두꺼워지기 쉽습니다.하지만 아래 5가지 패턴을 적용하면 비대화를 완화할 수 있습니다. 1. Application Service ↔ Domain Service 분리Application Service: 트랜잭션 경계, 순서 제어 Domain Service: 비즈니스 규칙, 검증 ➡️ 서비스에는 오케스트레이션만 남기고, 규칙은 도메인 서비스로 분리 @Service@RequiredArgsConstructorpublic class CreateAppointmentUseCase { private final AppointmentOrchestrator orchestra..

MyBatis는 왜 서비스 레이어가 뚱뚱해질 수밖에 없는가?1. JPA와 비교하며 살펴보는 Transaction Script 패턴의 함정1. 접근 철학의 차이MyBatisSQL Mapper → SQL 직접 작성, VO/DTO 매핑.여러 테이블 조인, 후속 로직을 서비스에서 직접 오케스트레이션.서비스 코드가 절차적 스크립트처럼 길어짐.➡️ 서비스가 뚱뚱해지는 구조적 성향JPAORM → 엔티티와 관계를 선언해두면 findById, findAll로 객체 그래프 조회.서비스는 비즈니스 규칙에만 집중.데이터 조립은 프레임워크가 처리.➡️ 서비스가 얇아짐2. MyBatis 서비스 코드 예시사원 발령 등록을 MyBatis로 작성하면:EmpVo emp = empMapper.findById(empId);if (emp =..