전체 글

요새 핫하다는 Antigravity 나도 한 번 찍먹 해보고자 간단한 포트폴리오 사이트를 만들기로 했다. 최근에 프로젝트하면서 어떤 팀원이 Antigravity 칭찬을 엄청 하셨었다. 우리 프젝 레포지토리를 기반으로(프론트가 전혀 없었던) 웹사이트 만든 걸 보여주셨는데, 결과물이 너무 충격적이었다. 이런 퀄리티가 가능하다고..? 그분이 말씀하시기를 "레포지토리 통째로 넘겨서 프롬프트 위주로 만들었다"라고 하셨는데 정말 그게 가능한가 싶어 직접 경험해보기로 했다. 디자인 잡도리Behance나 Dribble 등의 사이트를 통해 내 마음에 드는 느낌의 포트폴리오 웹사이트 디자인을 찾아 이런 느낌과 비슷하게 해달라고 요청했다. 완전 마음에 쏙 들게는 아니지만 50% 정도는 "이 정도면 괜찮군"할 법한 결과물을..

JOIN 전략 (Inner/Outer) 관계형 데이터베이스의 핵심은 데이터를 정규화하여 나누고, 필요할 때 이를 다시 엮어서(JOIN) 조회하는 것이다. JOIN은 두 개 이상의 테이블을 결합하여 데이터를 조회하는 SQL 연산이다. 관계형 데이터베이스에서 데이터는 정규화를 통해 여러 테이블로 분산되어 저장되므로, 의미 있는 정보를 얻기 위해서는 JOIN이 필수적이다.JOIN 전략은 조회 결과뿐 아니라 성능에도 큰 영향을 미기 때문에 상황에 맞게 선택하는 것이 중요하다. 이번 포스팅에서는 실무에서 가장 빈번하게 사용되는 INNER JOIN과 OUTER JOIN의 차이점, 그리고 성능 최적화를 위한 고려사항을 정리해보았다. 대표적인 JOIN 방식은 다음 두 가지다.INNER JOINOUTER JOIN (L..

Layered Architecture란? 소프트웨어가 커질수록 코드는 복잡해지기 마련이다. 이 복잡성을 해결하는 가장 오래되고 검증된 방법은 '관심사의 분리'라는 것이 있는데 레이어드 아키텍처는 시스템을 유사한 관심사끼리 계층화하여 각 계층이 자신의 역할에만 집중하게 함으로써 유지보수성과 확장성을 높이는 방법론이다. Layered Architecture(계층형 아키텍처)는 애플리케이션을 역할별로 계층을 나누어 책임을 분리하는 구조다. Spring 기반 서버에서는 일반적으로 다음 구조를 가진다. Layered Architecture의 목적은 관심사의 분리이다. Controller (아래로)Service (아래로)Repository (아래로)DB각 계층은 자기 역할만 수행해야 하며, 아래 계층에만 ..

이번 포스팅에서는 DDD의 핵심 구성 요소들이 실제 코드 레벨(Spring + JPA)에서 어떻게 구현되고, 어떤 고민을 거쳐 적용되어야 하는지 정리해보았다. DDD의 구성요소Entity고유 식별자(ID)가 존재 (값이 변해도 같은 존재이다)동일성은 ID로 판단생명주기를 가짐상태가 변할 수 있음// id가 같으면 같은 객체로 본다.class Member { private MemberId id; private String name;} Value Object (VO) 식별자가 없음값 자체가 동일성 기준불변(immutable)부작용이 없음// amount + currency가 같으면 같은 객체class Money { private final int amount; private final ..

앞서 DDD의 등장배경과 그 목적, 개념 등을 살펴보았다. 이번 포스팅에서는 DDD가 어떠한 축으로 나누어지는지에 대해 정리해보고자 한다. DDD는 각 전략적, 전술적으로 나뉘게 되는데, DDD가 이 두 단계로 나뉘는 이유는 소프트웨어의 복잡성을 해결하는 층위가 다르기 때문이다. 전략적 설계 (Strategic): 비즈니스 전체의 방향과 구조를 잡는 것 (무엇을 만들고, 어떻게 나눌 것인가?)전술적 설계 (Tactical): 결정된 구조 내부의 구현 상세를 다루는 것 (어떤 코드로 구현할 것인가?) 전략적 DDD - 경계를 나누는 설계시스템을 어떻게 나눌 것인가우리 서비스는 어디까지가 하나의 모델인가?서비스 경계는 어디인가?즉, 큰 그림을 설계하는 단계이다. 전략적 DDD는 코드를 짜기 전, 기획자와 ..

DDD란?DDD는 복잡한 비즈니스 도메인을 효과적으로 모델링하기 위한 설계 방법론이다. DDD(Domain-Driven Design)은 Eric Evans가 2003년에 정리한 소프트웨어 설계 방법론이다. 이는 "도메인 모델링"이 소프트웨어 설계 중심이라는 것에서 출발한다. 개발자와 도메인 전문가가 공통된 언어를 사용하여 문제 영역을 정의하고, 모델을 기반으로 설계와 구현을 긴밀히 연결하는 방법을 탐구한다. 코드와 비즈니스 개념 사이의 간극을 줄여 시스템의 장기적인 유연성을 높이는 것을 핵심적인 목표로 한다. DDD의 등장 배경기존 개발 방식의 한계과거 엔터프라이즈 시스템은 아래와 같은 DB를 중심으로 하는 구조가 일반적이었다.Controller → Service → DAO → DB 그러나 이러한 구조는..

동기와 비동기는 정말 익숙해서 둘이 뭔 차이고 어떻게 동작하느냐고 물어본다면 바로바로 대답할 수 있지만, 블로킹은 부끄럽게도 아직 잘 알지 못한다. 이번 포스팅에서는 동기/비동기와 함께 블로킹에 대해 알아보고자 한다. 동기/비동기동기/비동기는 '결과를 언제 처리하는가(제어권의 흐름)'에 초점을 둔다.동기란?작업의 흐름(제어권)이 호출자 기준으로 순차적으로 진행되는 방식이다. 요청한 작업의 결과가 나올 때까지 기다리거나, 결과가 나오면 즉시 처리하는 방식결과가 와야 다음 작업이 가능하다. 작업의 순서가 보장된다. (요청 -> 응답 -> 다음 작업)단점: 결과 받을 때까지 대기 시간동안 아무것도 못함예시: 마트에서 대기줄 기다리는 상황 // 예시String result = service.call(); // ..

동시성 문제란? 동일한 데이터에 대해 여러 트랜잭션이 동시에 접근하여 수정하려고 할 때, 실행 순서에 따라 결과가 달라져 데이터의 일관성이 깨지는 현상을 말한다. 이를 경쟁 상태(Race Condition)이라고 한다.원인 : 멀티스레드, 프로세스 환경에서 데이터베이스나 메모리의 공유 자원에 대한 동시 접근증상 : 데이터 부정합, 더티 리드, 유령 읽기(Phantom Read) 예시는 아래와 같다.동시성 문제 예시: 재고 관리 현재 재고가 1개 남은 상태사용자 A와 사용자 B가 동시에 '구매하기' 버튼을 누른다.두 스레드 모두 현재 재고를 1로 읽는다.두 스레드 모두 재고 - 1 연산을 수행하여 재고를 0으로 업데이트한다.결과적으로 남은 물건은 1개인데 2명에게 팔리는 사고가 발생한다. (Race Co..