TIL

특화 작업

너는 지금부터 보험 구독형 서비스의 백엔드 데이터 모델러다. 이번 작업의 목표는 “보험업계 정식 전산모델”이 아니라 “포트폴리오용이지만 실제 구현 가능한 MVP ERD”다. 출력은 추상적인 설명보다 테이블 경계와 책임 분리가 드러나게 작성하라. 애매한 부분은 임의로 확정하지 말고, “권장안 / 대안 / 이유” 형태로 정리하라.

프로젝트 맥락

우리 팀은 6인 취준생 팀이고, 개발 기간은 4주다. 포트폴리오 품질은 중요하지만, 과설계보다 실제 구현 가능성이 더 중요하다.

우리는 다음을 만드는 프로젝트를 진행 중이다.

  1. 사용자의 기존 보험을 조회/분석하는 서비스
  2. 보험사 상품 데이터를 기반으로 보험사 Mock 서버 구축
  3. 마이데이터 v2 규격에 맞는 Mock 서버 구축
  4. 구독형 캡슐 보험 및 퀵오더형 단기보험 기능
  5. 감사로그 / 약관동의 / 설명의무 / 디지털 인감 저장

매우 중요한 전제

1. 물리 서버 분리를 전제하지 마라

EC2 1대 + 몇 개의 개인 장비만 있는 상황이다. 따라서 DB 분리는 “물리 서버 분리”가 아니라 “논리적 분리”로 이해해야 한다.

즉 아래는 같은 MySQL 인스턴스 안에서:

  • 같은 schema 내 prefix 분리
  • 혹은 schema 분리 정도로 구현 가능한 수준이어야 한다.

2. 데이터 레이어를 반드시 구분하라

하지만 이 구분은 물리 분리가 아니라 “역할 분리”다. 최소한 아래 4개 층을 개념적으로 구분해서 설계하라.

  • Raw Layer
  • Staging / Canonical Layer
  • Core Domain Layer
  • MyData Mock Response Layer

3. Audit / Compliance 성격의 데이터는 별도 취급하라

감사로그, 동의이력, 설명의무 이행, 디지털 인감 관련 데이터는 Core와 동일한 규칙으로 다루지 마라. append-only 혹은 이력보존 중심으로 설계하라.

데이터 소스와 현재 상황

A. 보험사 상품 Pool용 데이터

우리는 손해보험협회 공시실, 생명보험협회 공시실에서 보험 상품 데이터를 수집했다. 총 20개의 .xls 파일을 다운로드했다.

이 데이터는 7대 핵심 보장 카테고리를 고려하여 선별되었다.

7대 보장 카테고리:

  • 사망
  • 암
  • 뇌/심장
  • 실손
  • 수술
  • 상해
  • 배상

생명보험 11개 .xls, 손해보험 9개 .xls에 대해 각각 합집합 기반 스키마를 만들었다.

생명보험 합집합 스키마 (11개 파일, 총 35컬럼)

  • 회사명
  • 상품명
  • 구분
  • 급부명칭
  • 지급사유
  • 가입금액
  • 보험료_남자
  • 보험료_여자
  • 보험가격지수_남자
  • 보험가격지수_여자
  • 부가보험료지수_남자
  • 부가보험료지수_여자
  • 계약체결비용지수_남자
  • 계약체결비용지수_여자
  • 유니버셜
  • 갱신주기
  • 판매채널
  • 판매일자
  • 특이사항
  • 대표번호
  • 지급금액
  • 해약환급금
  • 확정이율
  • 현재공시이율
  • 최저보증이율
  • 상품특징
  • 최저사망보험금
  • 최저사망보험_부과방식
  • 최저해약보험금
  • 최저해약보험_부과방식
  • 경도치매보장여부
  • 경도치매진단급여금
  • 보장범위지수_암진단
  • 보장범위지수_암입원
  • 유형

손해보험 합집합 스키마 (9개 파일, 총 22컬럼)

  • 선택
  • 회사명
  • 상품명
  • 채널
  • 담보명
  • 지급사유
  • 지급액
  • 보장부분적용이율
  • 적립부분적용이율
  • 보험료_남자
  • 보험료_여자
  • 최저가입보험료
  • 보험가격지수_남자
  • 보험가격지수_여자
  • 계약체결비용지수
  • 부가보험료지수
  • 예상갱신보험료
  • 상품요약서
  • 갱신여부
  • 특이사항
  • 대표번호
  • 보장범위지수

중요: 이 합집합 스키마는 원본 xls를 그대로 저장한 Raw가 아니다. 이미 여러 파일을 통합하고 표준화한 중간층이다. 즉 이 스키마는 Raw가 아니라 Staging / Canonical Layer 후보로 봐야 한다.

B. 마이데이터 API

우리 서비스는 마이데이터 API 규격을 사용해 보험사 Mock 서버와 데이터가 오고가야 한다.

분석 대상 API:

  • 보험-001 보험 목록 조회
  • 보험-002 보험 기본정보 조회
  • 보험-003 보험 특약정보 조회
  • 보험-004 자동차보험 정보 조회
  • 보험-018 물/일반보험 기본정보 조회
  • 보험-012 보험 보장정보 조회

현재 판단: 공시실 상품 Pool 데이터와 마이데이터 API 규격은 거의 1:1로 맞지 않는다.

이유: 공시실 데이터는 상품/보장 Pool 중심이고, 마이데이터 API는 개인 계약 / 증권번호 / 피보험자 / 계약상태 / 담보상태 / 만기 / 체결일자 같은 개인화된 계약 조회 중심이다.

따라서:

  • 보험사 상품 Pool 데이터
  • 마이데이터 응답용 데이터 를 같은 구조로 설계하면 안 된다.

설계 지시

절대 하지 말 것

  1. 보험 테이블 하나에 모든 보험 종류를 몰아넣지 마라.
  2. 외부 API 응답 구조를 내부 운영 DB 테이블에 그대로 복붙하지 마라.
  3. 화면명 기준으로 테이블을 설계하지 마라.
  4. “이상적인 대기업급 아키텍처”를 만들지 마라.
  5. 물리 DB 서버 분리를 전제하지 마라.

반드시 지킬 것

  1. Raw / Staging / Core / MyData Mock / Audit 성격을 구분하라.
  2. 각 테이블이 어느 층에 속하는지 명시하라.
  3. 보험 상품 Pool과 개인 계약 데이터를 구분하라.
  4. 생명보험과 손해보험의 차이를 무시하지 마라.
  5. 7대 핵심 보장 카테고리를 고려하라.
  6. MVP에서 실제 구현 가능한 수준으로 단순화하라.
  7. append-only가 필요한 로그 테이블을 식별하라.
  8. 현재 상태와 예약 상태가 공존하는 구조(예: 구독 변경 예약)를 고려하라.

레이어 정의

1. Raw Layer

역할:

  • 원본 xls 파일 및 파싱 전 row 데이터 보존
  • 재파싱 가능성 확보
  • 원본 출처 추적

예시 성격:

  • 파일 메타데이터
  • 원본 행 dump
  • import batch 정보

2. Staging / Canonical Layer

역할:

  • 여러 공시실 파일을 합쳐 내부 공통 컬럼으로 통합
  • 생명보험 합집합 35컬럼, 손해보험 합집합 22컬럼 같은 표준화 중간층
  • 7대 카테고리 매핑의 출발점

중요: 현재 우리가 만든 생명/손해 합집합 스키마는 이 층으로 간주하라.

3. Core Domain Layer

역할:

  • 서비스가 실제 운영에 사용하는 비즈니스 엔티티
  • 보험상품, 보장구성요소, 캡슐, 퀵오더 상품, 구독, 추천/중복분석 기준 등

4. MyData Mock Response Layer

역할:

  • 마이데이터 표준 응답(JSON)을 만들기 위한 내부 모델
  • 개인 계약, 피보험자, 증권번호, 담보상태, 계약상태, 보험기간 등의 구조
  • 상품 Pool과는 다른 차원의 데이터

5. Audit / Compliance Layer

역할:

  • 감사로그
  • 약관동의 이력
  • 설명의무 이행
  • 디지털 인감 관련 추적 정보
  • 가입/변경/해지 이력

출력 순서

아래 순서를 반드시 지켜라.

[1단계] 도메인 경계 정의

아래 도메인으로 먼저 나눠라.

  • 사용자 / 인증
  • 디지털 인감
  • Raw 공시실 원본 적재
  • 공시실 표준화(Staging)
  • 보험사 상품 Pool(Core)
  • 7대 보장 카테고리
  • 구독 캡슐
  • 퀵오더 단기보험
  • 마이데이터 Mock 계약/보장/피보험자
  • 약관 / 동의 / 설명의무
  • 감사로그 / 컴플라이언스

[2단계] 엔티티 후보표 작성

각 엔티티마다 다음을 표로 정리하라.

  • 엔티티명
  • 소속 레이어
  • 존재 이유
  • 핵심 컬럼
  • 관계 엔티티
  • MVP 필수 여부 (필수 / 선택 / 보류)

[3단계] 최종 ERD 제안

최종 테이블을 제안하되, 다음을 반드시 포함하라.

  1. 테이블 목록
  2. 각 테이블 소속 레이어
  3. 주요 컬럼
  4. PK / FK / Unique / Nullable
  5. 상태값 enum
  6. 1:N / N:M 관계
  7. soft delete 여부
  8. append-only 여부
  9. MVP에서는 생략 가능한 테이블
  10. 확장 포인트

추가 설계 조건

A. 보험 상품 Pool 관련

  • 공시실 데이터는 상품/담보 Pool 데이터이지 개인 계약 데이터가 아니다.
  • 따라서 보험사 Mock 서버용 상품 카탈로그/플랜/보장구성요소 형태로 모델링하라.
  • 생명/손해를 완전히 하나로 뭉개지 말고, 공통화 가능한 부분만 공통화하라.

B. 마이데이터 Mock 관련

  • 마이데이터 응답은 개인 계약 기반이다.
  • 상품 데이터만으로는 부족하므로, 개인 계약 / 피보험자 / 계약상태 / 보험기간 / 담보상태 / 증권번호 등의 엔티티가 별도로 필요하다.
  • 즉 보험사 상품 Pool 테이블과 마이데이터 Mock 응답 테이블은 분리하라.

C. 7대 보장 카테고리 관련

  • 사망 / 암 / 뇌심장 / 실손 / 수술 / 상해 / 배상
  • 이 카테고리는 UI용 문자열이 아니라, 상품/담보/추천/중복체크 기준이 될 수 있는 구조로 설계하라.
  • 다만 지나친 규칙 엔진 수준까지는 가지 마라.

D. 구독 / 퀵오더 관련

  • 현재 활성 상태와 예약 상태를 동시에 표현할 수 있어야 한다.
  • 퀵오더는 활성 전/대기/활성 상태를 가질 수 있다.
  • 구독 캡슐은 현재 적용 상태와 익월 예약 상태를 분리해서 설계하는 방향을 검토하라.

E. 로그 / 컴플라이언스 관련

  • 동의이력, 설명의무 이행, 가입/변경/해지 이력, 디지털 인감 사용기록은 append-only 또는 이력보존 중심으로 설계하라.

최종 산출 형식

반드시 아래 형식으로 출력하라.

A. 전체 설계 원칙 요약
B. 레이어별 역할 정의
C. 도메인 분해 결과
D. 엔티티 후보표
E. 최종 ERD(텍스트 설명)
F. 테이블 명세서
G. 왜 이렇게 나눴는지 설계 근거
H. 과설계 위험 / 애매한 쟁점 / 보류사항

매우 중요

  • SQL부터 쓰지 마라.
  • 먼저 개념 ERD -> 논리 ERD 순서로 설명하라.
  • “현재 우리가 만든 생명/손해 합집합 스키마는 Raw가 아니라 Staging/Canonical에 가깝다”는 점을 반영하라.
  • “공시실 상품 Pool 데이터”와 “마이데이터 개인 계약 응답 데이터”를 구분하라.
  • 테이블 수를 무리하게 늘리지 말고, 4주 MVP 구현 가능성을 기준으로 절제하라.
  • 각 테이블에 대해 반드시 “왜 필요한지”를 한 문장으로 설명하라.

results matching ""

    No results matching ""