매일 매일 꾸준히 매일 매일 꾸준히

들어가며 (동기) 대출금 상환 프로젝트는 실제 은행 시스템을 모방하여 설계하고 이 과정에서 신뢰성 , 성능 등의 문제 상황을 가정 , 이를 해결해보는 개인 포트폴리오 입니다. 아키텍처를 설계하기 전 , 아키텍처 스타일에는 어떤 것들이 있으며 , 실제 은행 아키텍처는 어떤지 공부해야할 필요성을 느꼈습니다. 그래서 이 글에서 , 이를 공부하고 글로 남겨보겠습니다. (검수 필요) 아키텍처 스타일 : 모놀리식 vs MSA 서비스를 어떻게 나누고 배포할 것인가는 아키텍처를 설계할 때 가장 먼저 마주하는 질문 입니다.흔히 비교되는 2가지 스타일인 모놀리식과 MSA 를 정리해보겠습니다. 모놀리식 아키텍처 모놀리식은 서비스의 기능들이 하나의 애플리케이션 안에 모두 포함되고 , 하나의 데이터베이스를 공유하는 구조..

들어가며 지금까지 대출금 상환 프로젝트에 대해 개념적 , 논리적 데이터베이스 모델링을 진행했습니다. 회원 , 대출계약 , 대출계좌 , 상환 스케줄 , 연체 이력 등 15 개 테이블과 그 관계를 정의하고 정규화 과정 까지 마쳤습니다. 아래는 그 결과 ERD 입니다. 이번 글에서는 논리적 모델링 결과를 바탕으로 물리적 모델링을 진행하겠습니다. 물리적 모델링은 ERD 를 바탕으로 MySQL 이라는 구체적인 DBMS 에 최적화된 형태로 구현하는 과정 입니다. 진행 순서물리적 모델링은 다음 3단계로 진행 합니다. 테이블과 컬럼 변환: 논리적 모델의 한글 엔티티명/속성명을 명명 규칙(Naming Convention)에 따라 영문으로 변환합니다.데이터 타입 정의: 각 컬럼에 가장 적합한 자료형(VARCHAR,..

개요 데이터베이스를 설계할 때 테이블을 어떻게 나눌지 고민한 경험이 있을 것입니다.감각적으로 "이건 따로 빼야 할 것 같은데"라는 판단을 한 적도 있을 것입니다.정규화는 그 판단을 이론적으로 뒷받침해주는 도구입니다.정규화란 무엇인가정규화(Normalization)는 데이터의 중복을 최소화하고 일관성을 보장하기 위해, 테이블을 정규형(Normal Form)이라는 규칙에 맞게 변환하는 과정입니다.핵심 개념은 **함수 종속성(Functional Dependency)**입니다. X → Y로 표기하며, "X 값이 Y 값을 유일하게 결정한다"는 의미입니다. 정규화는 이 종속 관계를 분석해서 잘못된 구조를 찾아내고 테이블을 올바르게 분리하는 작업입니다.왜 필요한가정규화를 적용하지 않으면 세 가지 이상 현상(Anom..

이전 글에서 대출 도메인의 비즈니스 요구사항을 바탕으로 개념적 모델링을 완성했습니다.이번 글은 논리적 모델링 1편으로, 개념적 모델의 엔티티를 관계형 데이터베이스의 테이블로 변환하는 과정을 다룹니다.논리적 모델링 2편에서는 설계한 테이블의 품질을 높이는 정규화(Normalization)를 다룰 예정입니다. 이번 설계에서 적용할 원칙은 다음과 같습니다.대리키 PK, 자연키 UNIQUE: 비즈니스와 무관한 대리키를 PK로 사용하고, 비즈니스적으로 유일한 값에는 UNIQUE 제약조건을 적용합니다.비식별 관계: 유연성과 확장성을 위해 FK를 PK의 일부로 사용하지 않는 비식별 관계를 선택합니다.1:1 관계의 FK 위치: 보조 테이블에 FK를 두고, 해당 FK에 UNIQUE 제약조건을 추가하여 1:1 관계를 강제..

대출금 상환 프로그램 - 개념적 모델링 데이터베이스 설계는 보통 3단계를 거칩니다. 개념적 모델링 비지니스 요구사항을 보면서 엔티티 , 엔티티의 속성 , 엔티티의 관계를 정의하는 단계 입니다.특정 데이터베이스 기술은 고려하지 않고 , ERD 로 핵심 구조를 표현하는 것이 목표 입니다. 논리적 모델링 ERD 를 관계형 데이터베이스에 맞게 구체화 합니다.테이블 , 컬럼 , 기본키 , 외래키를 정의하고 정규화를 진행 합니다. 물리적 모델링 실제 사용할 데이터베이스(MySQL , Oracle 등)의 특성에 맞게 인덱스 , 데이터 타입 , 파티셔닝 등 성능과 저장 방식을 결정 합니다. 이 글은 그 첫번째 단계인 개념적 모델링을 다룹니다. 대출 실행은 이미 완료된 상태라고 가정하고 , 대출금 상환 과정에서..

5. 중도 상환 수수료 약관해석 중도 상환 수수료란 , 대출 만기 전에 미리 갚을 때 고객이 부담하는 수수료 입니다. 계산 공식은 아래와 같습니다. 중도 상환 수수료 = 중도 상환 대출 금액 X 중도 상환 수수료율(%) X (대출 잔여일수 / 대출 기간) 쉽게 말하면 얼마를 갚느냐 X 수수료율 X 얼마나 일찍 갚느냐의 비율로 계산됩니다.대출 만기에 가까울수록 잔여일수가 줄어들기 때문에 수수료 부담도 줄어드는 구조 입니다. 면제 조건도 있습니다. 최초 대출 취급일로부터 3년이 지나면 수수료가 부과되지 않습니다. 대출 만기 3개월 이내에 상환하는 경우 면제 됩니다. 기존 대출을 해지하고 동일 은행에서 사실상 동일한 계약을 새로 체결한 경우, 두 계약의 유지기간 합산이 3년을 초과하면 면제됩니다...

은행 웹사이트의 금융 상품 페이지에서 대출을 검색하면, 가계대출 상품 설명서를 찾아볼 수 있습니다. 이 설명서는 대출을 처음 접하는 고객도 쉽게 이해할 수 있도록 은행이 직접 검수하고 정제한 문서입니다. 대출 도메인에 익숙하지 않은 개발자 입장에서, 대출금 상환 프로그램을 구현하는 일은 생각보다 낯설고 막막한 작업이었습니다. 그때, 이 상품 설명서가 뜻밖에 훌륭한 기술 명세서 역할을 해줬습니다. 비즈니스 요구사항에 대한 힌트가 잘 정리되어 있었고, 구현에 필요한 핵심 로직의 단서들도 곳곳에 담겨 있었습니다. 이 시리즈는 두 편으로 나뉩니다.1편(이 글)에서는 MVP 기능에 해당하는 요구사항을 먼저 정리합니다. 대출 금리, 상환 방법, 연체 이자율, 연체금 결정, 채무변제충당순서가 그 대상입니다. 이를 ..

DISTINCT 처리 방식 분석 - MySQL 옵티마이저는 무엇을 다르게 하는가 ? SQL을 작성할 때, DISTINCT를 아무 생각 없이 붙이기 쉽습니다. 하지만 MySQL 내부에서는 같은 DISTINCT라도 처리하는 방식이 완전히 달라집니다.DISTINCT의 처리 방식은 옵티마이저가 실행 계획을 수립하는 시점에 결정됩니다. 그리고 옵티마이저는 상황에 따라 전혀 다른 방식으로 중복 제거를 처리합니다. 이 글에서는 MySQL이 DISTINCT를 처리하는 방식을 세 가지로 나눠 다뤄보겠습니다. 주요 내용은 아래와 같습니다.집합 함수가 없는 경우의 DISTINCT 집합 함수 + DISTINCT, 인덱스 X 집합 함수 + DISTINCT, 인덱스 O 예시 테이블 , 데이터 , 인덱스 [ERD] [인덱스 구..