블록체인 헬스케어 서비스 ERD설계 및 상세 아키텍쳐

 

몇 번에 피봇팅이 이어지고, 

블록체인 백엔드 테스트 이후, 이대로 가만히 있으면 안될 것 같다는 생각에 백엔드에서 erd를 다시 만들고 이해하기 쉽게 문서를 제작해야겠다는 생각이 들었다

(기존에는 기획자가 만든 스키마가 있었다)

 

• 기업이 연구를 동적으로 생성할 수 있어야 하고
• 새로운 데이터 필드를 자유롭게 추가할 수 있어야 하며
• 스키마 변경 없이 확장 가능해야 하고
• 민감한 건강 데이터는 안전하게 보호해야 하고
• 블록체인 기반 정산 및 기록 무결성을 보장해야 했다

즉, 확장성 · 보안 · 무결성을 동시에 만족하는 구조가 필요했다.

이 글에서는 그 설계 과정과, 특히 “방대한 ERD를 이해 가능한 문서로 재구성한 경험”을 정리해본다.

---

1. 처음 마주한 문제: ERD가 너무 방대함

초기 ERD는 일단 개발자가 만든 ERD가 아니며, 이해하기가 매우 어려웠으며, 피봇팅을 많이 했기 때문에 필요없는 테이블도 적잖이 존재했었다.

• users
• enterprises
• projects
• participants
• consents
• data_points
• encrypted_fields
• project_requirements
• data_request_fields
• research_field_definitions
• settlement 관련 테이블
• 블록체인 트랜잭션 로그 테이블

기존 ERD

너무 많음 / 다양한 서비스가 합쳐저 있음(웹/앱..etc)

 

---

2. 접근 방식의 변화: 구조 중심 → 이해 중심

그래서 접근 방식을 바꿨다.

전체 ERD를 한 번에 보여주는 대신,
테이블 단위로 나누어 설명하는 방식으로 문서를 재구성했다.

각 테이블을 다음 질문에 답하는 구조로 정리했다.

1. 왜 존재하는가
2. 어떤 문제를 해결하는가
3. 어떤 테이블과 연결되는가
4. 실제 예시는 무엇인가
5. 운영 시 주의할 점은 무엇인가

예를 들어:

• users → 플랫폼의 주체
• projects → 연구 단위
• project_requirements → 참여 조건 정의
• data_request_fields → 기업 데이터 요청 정의
• research_field_definitions → 플랫폼 데이터 사전
• settlement / transaction → 블록체인 정산 기록

이렇게 개념 단위로 분해하니 이해 속도가 훨씬 빨라졌다.

---

3. 핵심 설계 포인트 

1. research_field_definitions — 데이터 사전의 도입

블록체인 헬스케어 서비스에서는 연구 필드가 계속 추가된다.

처음에는 프로젝트마다 필드를 직접 정의하려 했다.
하지만 그 방식은 확장에 취약했다.

그래서 모든 연구 필드를 메타 테이블로 정의했다.

이 테이블은 다음을 관리한다:

• field_key
• display_name
• data_type
• default_source (Profile / Data_points)
• is_global
• created_by_enterprise
• created_at

이 구조 덕분에:

• 기존 필드는 재사용
• 새로운 필드는 동적 추가
• 스키마 변경 없이 확장 가능

해졌다.

이 테이블은 단순한 컬럼 목록이 아니라,
플랫폼 전체의 데이터 사전(Dictionary) 역할을 한다.

 

2. 조건과 요청의 분리

블록체인 헬스케어 서비스에서는

• 누가 연구에 참여할 수 있는지
• 기업이 어떤 데이터를 받는지

를 명확히 분리해야 했다.

project_requirements

→ 참여 조건 정의

data_request_fields

→ 기업 데이터 요청 정의

이 둘을 분리함으로써:

• 책임 분리 명확화
• 로직 단순화
• 유지보수 용이성 확보

가 가능해졌다.

3. data_points vs encrypted_fields 분리

헬스케어 데이터는 민감도가 매우 높다.

따라서 모든 데이터를 동일 구조로 저장하는 것은 위험하다.

data_points

• 시계열 데이터
• 반복 발생
• 집계 중심
• 대용량 처리 대상

encrypted_fields

• 정적 속성
• 유전자, 병력 등 초민감 정보
• 복호화 최소화

이 분리 덕분에:

• 성능 최적화
• 보안 강화
• 법적 리스크 최소화

가 가능해졌다.

4. 블록체인과 ERD의 연결

이 서비스의 또 다른 특징은 블록체인 기반 정산 구조다.

• 참여자 보상 지급
• 연구 예산 관리
• 트랜잭션 로그 기록
• 위변조 방지

이를 위해:

• settlement_batches
• settlement_items
• xrpl_transactions

등의 테이블을 분리 설계했다.

중요했던 점은:

온체인 데이터는 최소화하고,
오프체인 DB와 해시 기반으로 연결하는 구조를 유지하는 것이었다.

ERD 단계에서부터 블록체인 무결성 모델을 고려해야 했다.

---

5. ERD를 PPT로 만들며 가장 중요했던 것

ERD를 단순히 도식화하는 것은 어렵지 않다.

어려운 것은 “왜 이렇게 설계했는지”를 설명하는 것이다.

그래서 문서를 다음 순서로 구성했다:

1. 블록체인 헬스케어 서비스 목표
2. 데이터 흐름 다이어그램
3. 핵심 엔티티 설명
4. 메타 구조 설명
5. 확장 전략
6. 보안 설계
7. 병목 예상 지점

특히 컬럼 단위 설명과 실제 예시 데이터를 포함해,
설계 의도가 문서 안에 녹아들도록 구성했다.

 

---

6. 이번 경험에서 배운 것

1. ERD는 비즈니스 모델을 반영해야 한다.
2. 확장성을 고려하지 않으면 반드시 다시 설계하게 된다.
3. 메타 테이블은 동적 플랫폼의 핵심이다.
4. 블록체인 연계 구조는 초기 설계 단계에서 고려해야 한다.
5. 정확한 ERD보다 이해 가능한 ERD가 더 중요하다.

 

확장성, 보안, 무결성, 멀티 기업 구조까지 고려한
플랫폼 아키텍처의 핵심 작업이었다.

구조가 아무리 정교해도
팀이 이해하지 못하면 살아있는 설계가 될 수 없다.

 

 

아직 서비스를 완전히 이해하지 못했기 때문에 아마 더 추가 될 듯하다. 

ERD를 만들고 PPT를 작성함으로써 서비스에 대한 이해도가 높아져서 만족한 하루였다.