David Brain

index

4 min read

ID: key_26_13_03_23_11_09_12_17100 Created date: 3월 23 2026 월요일, 13주 11:09

befw schema kan6

연관 문서

목적

  • 서로 다른 프로그래밍 언어로 개발된 서비스들 간의 메시지 규약 관리 효율화
  • 서비스 기획 및 메시지 스펙 조회 및 업데이트 용이한 구조

Strategy

  • Json Schema Repository를 별도로 구성하여 통합적으로 메시지 스펙을 관리

Architecture

  • Schema Repository (구축 필요)
    • Json 으로 구성된 Schema 저장소
    • 버전 관리, 형상 유지 수행
    • 변경 발생 시, CI/CD 이용하여 Nexus 배포
    • 프로그래밍 언어에 따라 빌드 설정 다르게 구성 → 라이브러리 구성
      • Java / Python / Node
    • Repository 구축

    • github workflow 설정하여 신규 버전 배포 시, Nexus에 자동 등록이 되야함

  • Nexsus (구축 필요)
    • 하위 시스템에서 관련 라이브러리를 참조
    • 프로젝트 상세 구성
    • TAS-BEFW Nexsus 구축
    • 04 Apr 결정사항
      • Nexus 구축 시, 많은 리소스 필요 (4gb memory)
        • 오라클 클라우드 기준 1gb → 진행 불가
      • github packages와 releases 변경 진행
  • 단위 서비스
    • 재 빌드 통해 변경된 스키마 반영

기획자, Schema 설계 방식

  • 목적
  • 방식
    • DB 구성
      • 구성 안함
        • Github page 통해 수행
      • 구성
        • 별도 백엔드 구성 여부
          • 구성
            • 별도 개발 필요
          • 미 구성
            • APP에서 병행 수행
        • 별도 UI 구성 여부
  • 결론
    • FW을 만드는게 목적
    • 별도 UI와 백엔드 구성하는게 맞을 듯
      • app-mdm

추가 문의

  • JPA Entity 같은 model 도 Schema 형식으로 관리가 가능한가?
    • 성격이 서로 다름 → Json Schema 로는 Model에서 필요한 테이블 명이나 컬럼 명에 대한 정의 불가
    • Liquibase / Flyway가 JPA Entity에는 더 적합함
  • JSON Schema 이외 다른 Spec 으로도 가능한가?
    • OpenAPI 3.1이 대안이다.

설계 변경 (29 Mar)

  • OpenAPI 3.1은 JSON Schema 대응하면서 Swagger 장점 존재
    • 장점
      • Response 까지 정의 가능
      • 테스트 손쉽게 됨
      • URI 관리 가능
    • 단점
      • Solace Interface에 대한 대응 애매함
    • 대응
      • 메시지 전문은 별도로 구성
      • Solace 인터페이스 용과 HTTP 인터페이스 용을 분리하여 메시지 전문을 참조하는 방식으로
        • 예시
    • 정리

Schema 관리 프로세스 (정리)

  • 29 Mar
  • 04 Apr
    • nexus 를 서버에 올리기엔 리소스 낭비가 심해서 github package로 변경

정의된 Schema, 서비스에 적용하기

  • Schema 실제 서비스에 적용해서 원하는 방향대로 진행하는지 확인

연관 메일

5 items under this folder.