Study4 블록체인 헬스케어 서비스 ERD설계 및 상세 아키텍쳐 몇 번에 피봇팅이 이어지고, 블록체인 백엔드 테스트 이후, 이대로 가만히 있으면 안될 것 같다는 생각에 백엔드에서 erd를 다시 만들고 이해하기 쉽게 문서를 제작해야겠다는 생각이 들었다(기존에는 기획자가 만든 스키마가 있었다) 기업이 연구를 동적으로 생성할 수 있어야 하고새로운 데이터 필드를 자유롭게 추가할 수 있어야 하며스키마 변경 없이 확장 가능해야 하고민감한 건강 데이터는 안전하게 보호해야 하고블록체인 기반 정산 및 기록 무결성을 보장해야 했다즉, 확장성 · 보안 · 무결성을 동시에 만족하는 구조가 필요했다.이 글에서는 그 설계 과정과, 특히 “방대한 ERD를 이해 가능한 문서로 재구성한 경험”을 정리해본다.1. 처음 마주한 문제: ERD가 너무 방대함초기 ERD는 일단 개발자가 만든 ERD가 아니.. 2026. 2. 19. Java ↔ Nest.js ↔ Blockchain 구조 테스트 및 아키텍처 결정 기록 1. 통신 테스트 결과Java 기반 백엔드와 Nest.js(Core/블록체인) 서버 간 통신을 간단히 테스트했다.API 호출 및 응답 흐름에는 큰 문제가 없었다.Java → Core API 호출 정상 동작했다.Core → Testnet 블록체인 연동 정상 동작했다.트랜잭션 생성 및 응답 반환 과정도 확인했다.다만 이번 테스트는 Testnet에서 제공하는 테스트용 키를 사용한 환경이었다.따라서 실제 운영 환경(Mainnet, 실보안 키 관리, 인프라 분리 등)과는 차이가 있을 수 있다고 판단했다.기술적으로 통신은 가능하다는 것을 확인했다.그러나 운영 구조로 적절한지에 대한 판단은 별개의 문제라고 보았다.2. 기존 구조의 문제점초기 구조는 다음과 같이 설계되어 있었다.[Java Backend] → [Nest.. 2026. 2. 19. XRPL Escrow -> 보상 시스템 XRPL Escrow는 특정 조건이나 시간이 충족될 때까지 XRP를 잠가두고,조건이 만족되면 자동으로 지급되도록 보장하는 XRPL의 조건부 자금 보관 메커니즘이다. XRPL Escrow돈을 블록체인에 예치후, 사람이 아닌 규칙이 언제 풀지 결정하는 금고이다.송금자가 XRP를 에스크로에 예치하면그 자금은 아무도 임의로 건들 수 없다.미리 정한 조건(Condition)혹은 시간(FinishAfter)이 만족되어야EscrowFinish트랜잭션으로 지급된다.신뢰를 사람이나 플랫폼이 아닌 XRPL프로토콜이 강제하는 것. 즉, 자금의 소유권은 유지하되, 사용권한은 조건에 위임하는 매커니즘 XRPL Escrow는 연구 프로젝트 예산을 사전에 잠가두고,데이터 제출이라는 조건이 충족되었을 때만 보상이 지급되도록 보장하는.. 2026. 2. 4. XRPL 지갑 연동 플로우 이해하기 지갑은 사람에게 하나로 고정 됨Passkey는 열쇠 역할서명은 무조건 사용자 기기에서만 일어난다. 왜 XPRL 지갑을 연동하는가.- 내가 개발하는 서버에서 '지갑'은 동의 체제를 확인하고 이 데이터가 이 사람에게 귀속된다. 를 블록체인에 영구 기록하는 신분 도장이다. 중요서버가 대신 서명하면 안됨서버가 시드를 평문으로 들고 있으면 안된다.사용자가 passkey로 직접 승인해야 된다. 서버가 하면 안 되는 것지갑 시드를 평문으로 저장사용자를 대신해서 서명 반드시 이렇게 해야 하는 것서명은 항상 사용자 기기에서서버는 서명 결과만 받음서버는 암호화된 시드만 보관👉 서버는 금고 관리자👉 사용자는 열쇠를 가진 사람 사람 = 지갑.KYC(본인인증)을 하면 그 사람을 대표하는 지갑이 하나 만들어짐같은 사람은 항상.. 2026. 2. 4. 이전 1 다음
