Java ↔ Nest.js ↔ Blockchain 구조 테스트 및 아키텍처 결정 기록

1. 통신 테스트 결과

Java 기반 백엔드와 Nest.js(Core/블록체인) 서버 간 통신을 간단히 테스트했다.
API 호출 및 응답 흐름에는 큰 문제가 없었다.

• Java → Core API 호출 정상 동작했다.
• Core → Testnet 블록체인 연동 정상 동작했다.
• 트랜잭션 생성 및 응답 반환 과정도 확인했다.

다만 이번 테스트는 Testnet에서 제공하는 테스트용 키를 사용한 환경이었다.
따라서 실제 운영 환경(Mainnet, 실보안 키 관리, 인프라 분리 등)과는 차이가 있을 수 있다고 판단했다.

기술적으로 통신은 가능하다는 것을 확인했다.
그러나 운영 구조로 적절한지에 대한 판단은 별개의 문제라고 보았다.

---

2. 기존 구조의 문제점

초기 구조는 다음과 같이 설계되어 있었다.

[Java Backend] → [Nest.js Core] → [Blockchain]
                     └ User DB

Core 서버가 블록체인 처리와 보안, 그리고 User DB까지 함께 담당하는 구조였다.

이 경우 연구관리 서버(Java 백엔드)는 유저 정보가 필요할 때마다 Core API를 호출해야 하는 구조가 된다.
인증, 권한 확인, 유저 조회 및 수정 로직이 모두 Core를 경유하게 된다.

그 결과 다음과 같은 문제가 발생할 수 있다고 판단했다.

• 서버 간 의존도 증가
• 내부 API 호출 증가로 인한 트래픽 부담
• Core 장애 발생 시 전체 서비스 영향 가능성 증가
• 책임 경계 불명확
• 설계 복잡도 상승

특히 연구관리 서버가 Core 서버에 종속되는 구조가 된다는 점이 가장 큰 문제라고 보았다.

---

3. 구조 재설계 방향

위 문제를 고려해 구조를 단순화하기로 했다.

[Java Backend]  →  DB (User, Service Data)
        ↓
[Nest.js Core]  →  Blockchain

역할 분리

Java 백엔드는 다음을 담당하도록 했다.

• User DB 관리
• 서비스 도메인 로직
• 연구관리 기능 처리
• 인증 및 인가
• 모든 비즈니스 데이터 저장

Core 서버는 다음만 담당하도록 했다.

• 블록체인 트랜잭션 생성
• 서명 처리
• 스마트 컨트랙트 호출
• 체인 연동 전용 기능

Core는 블록체인 전용 서버로 한정했다.

---

4. 설계 변경 이유

1) 의존성 최소화

Java 백엔드가 자체 DB를 가지면 Core에 유저 조회를 요청할 필요가 없다.
서버 간 호출을 최소화할 수 있다.

장애 격리가 가능해지고, 독립 배포 또한 가능해진다.

---

2) 단일 책임 원칙 준수

Core는 블록체인만 담당하도록 했다.
백엔드는 서비스 로직만 담당하도록 했다.

역할이 명확히 분리되었다.

---

3) 확장성 확보

블록체인 트래픽이 증가하면 Core만 확장하면 된다.
사용자 및 서비스 트래픽이 증가하면 백엔드만 확장하면 된다.

수평 확장이 독립적으로 가능해진다.

---

4) 데이터 관리 명확화

블록체인은 별도의 서비스 DB에 저장하지 않는다.
체인 자체가 원장 역할을 한다.

따라서

• 서비스 데이터는 백엔드 DB에 저장했다.
• 트랜잭션 기록은 블록체인에 기록했다.

데이터 저장 책임을 명확히 분리했다.

---

5. 결론

Java ↔ Nest.js 간 통신에는 기술적 문제가 없었다.
그러나 Core에 User DB까지 포함하는 구조는 장기적으로 의존도를 높이고 설계를 복잡하게 만들 가능성이 있다고 판단했다.

따라서 Core 서버는 블록체인 기능만 담당하도록 했다.
유저 DB 및 서비스 로직은 Java 백엔드에서 처리하는 구조로 결정했다.

이번 결정은 다음을 목표로 했다.

• 서버 간 의존성 감소
• 책임 분리 명확화
• 확장성 확보
• 설계 단순화

이 구조가 현재 단계에서 가장 합리적인 선택이라고 판단했다.