Files

rtgs 58ca23b5d9 Initialize RTGS prototype repository

3센터 A-A-A RTGS 실시간총액결제 프로토타입 최초 버전관리 시작.
- backend: Kotlin/Gradle 멀티모듈(sequencer, common, 채널/센터 모듈)
- frontend: Vite + TS
- infra: docker-compose, prometheus/grafana, ELK 네이티브 스크립트
- loadtest(k6), sim(장애/순서/정합성 시나리오), docs(PoC 보고서/복원력방안)

2026-07-15 15:37:32 +09:00

23 KiB

Raw Blame History

RTGS 프로토타입 아키텍처 설계서

항목	내용
문서명	소액 RTGS(실시간총액결제) 프로토타입 아키텍처 설계서
버전	v1.0
작성일	2026-07-10
작성	루비(AI) · 검토 양희정 팀장(한국은행 RTGS시스템팀)
분류	SW 산출물 — 아키텍처 설계
대상 시스템	`C:\ai-dev\workspace\rtgs` (로컬 포터블 프로토타입, 1센터 DC1)
관련 문서	개발일지 · 워크플로우 · 로컬 테스트 시나리오 · 복원력방안(과제⑧ v2.0) · PoC 1~3차 결과보고

1. 개요

1.1 목적

클라우드 PoC(3회차, "접수"까지 검증)의 아키텍처를 로컬에서 업무기능 완결(신청→접수→청산·정산→완결 ACCC) 로 재현하고, 복원력방안(Active-Active-Active)의 미검증 급소를 검증하기 위한 프로토타입의 소프트웨어/배포 아키텍처를 정의한다.

1.2 범위

1센터(DC1) 로컬 구성의 논리·물리(OS-WAS-DB) 아키텍처, SW 스택, 데이터/인터페이스/보안 설계.
다센터(DC2/DC3) A-A-A 확장 설계는 §11에 방향만 제시(구현은 고사양 PC 이관 후).

1.3 용어

약어	의미
RTGS	Real-Time Gross Settlement(실시간총액결제)
A-A-A	Active-Active-Active(3센터 동시 가동)
BMI	Business Message Identifier(거래식별자 22자리)
저널	전역순번이 부여된 처리 명단(Kafka 단일 파티션)
정족수	Quorum(N/2+1). 3센터=2
선저널	Write-ahead journal(잔액연산 전 순번 확정)
WAS	Web Application Server(본 시스템은 Spring Boot 내장 Tomcat)

2. 아키텍처 원칙 (복원력방안 반영)

단일 전역 순번기로 입구에서 전역순번 부여 → 저널 → N센터 결정론적 재생(동일순서·동일업무).
원장 = RDB(PostgreSQL) 강한 일관성 — 잔액 확정의 권위 저장소.
정족수(2/3) + 펜싱으로 split-brain 차단(1센터=자기 과반, 구조 선반영).
선(先)저널(write-ahead) 후 잔액연산 → 노드사(死) 무손실 승계.
완결 규율 — 과반 확정 후 최종(ACCC).
경량 명령문 + 원전문 해시(SHA-256) — 센터 간엔 수백B 구조체만 복제, 원전문은 별도 저장.
순서=Sequencer(상태O) / 분산·관문=Gucci·GSLB(상태X) 역할 분리.
포터블 네이티브 — 모든 런타임을 C:\ai-dev\apps 하위에 무설치 배치(회사 PC 가상화 차단으로 Docker 불가).

3. 논리 아키텍처

그림 3-0. 업무 흐름도(기준) — 3센터 A-A-A 동일 순서·동일 업무 처리

3.1 계층 구조

그림 3-1. 컴포넌트·데이터 흐름 (7개 서비스)

flowchart TD
  EXT["참가기관 / k6"] --> G["Gucci 관문 :8095<br/>인증·유량·재전송·콜백"]
  CON["운영·관리 콘솔<br/>React :5174"] --> C
  CON --> LV["LouisVuitton :8099<br/>시스템관리"]
  G --> C["Chanel :8091<br/>접수·검증·통보"]
  C -->|rtgs.inbound| K
  K["Kafka :9092<br/>저널/결과/통보"] --> S["Sequencer :8090<br/>전역순번"]
  S -->|rtgs.journal| K
  K --> D["Dior :8092<br/>접수동기화"]
  K --> H["Hermes :8093<br/>정산·원장엔진"]
  H -->|rtgs.result| K
  K --> P["Prada :8094<br/>완결"]
  P -->|rtgs.notify| K
  D --> PG[("PostgreSQL :5433<br/>원장")]
  H --> PG
  P --> PG
  C --> PG
  G -->|콜백 송부| EXT

그림 3-2. 계층 구조

 ┌── 표현 계층 ─────────────────────────────────────────────┐
 │  운영/관리 콘솔 (React + Vite, :5174)                       │
 └───────────────┬──────────────────────────────────────────┘
 ┌── 경계/관문 계층 ────────────▼───────────────────────────┐
 │  Gucci(:8095) — 로그인·API인증·유량제어·재전송차단·결과콜백 │
 └───────────────┬──────────────────────────────────────────┘
 ┌── 접속/연계 계층 ────────────▼───────────────────────────┐
 │  Chanel(:8091) — pacs.008 접수·XSD검증·경량화·결과통보     │
 └───────────────┬──────────────────────────────────────────┘
 ┌── 코어(순번/정산) 계층 ──────▼───────────────────────────┐
 │  Sequencer(순번) → [저널] → Dior(접수동기화)              │
 │                             Hermes(정산·원장엔진)         │
 │                             Prada(완결·결과동기화)         │
 └───────────────┬──────────────────────────────────────────┘
 ┌── 데이터/원장 계층 ──────────▼───────────────────────────┐
 │  PostgreSQL(원장·강한 일관성)  ·  Kafka(입구/저널/결과/통보) │
 └───────────────┬──────────────────────────────────────────┘
 ┌── 관리/관측 계층 ────────────▼───────────────────────────┐
 │  LouisVuitton(:8099) 시스템관리  ·  ELK 로그(9200/5000/5601)│
 └──────────────────────────────────────────────────────────┘

3.2 서비스(컴포넌트) 구성 — 7개 (명품 코드네임)

#	서비스	코드네임 의미	유형	논리포트	책임
1	Sequencer	전역 순번기	Headless(JVM)	8090	전역순번·결정론적값 확정 → 저널 발행. 순번 영속화(재기동 시 MAX(global_seq) 복원)
2	Chanel	Contact Hub…Entry Liaison	Web(Tomcat)	8091	pacs.008 접수·XSD검증·경량화·원전문 저장·입구 발행 / 결과통보(pacs.002 생성·아웃박스)
3	Dior	Data Integration…Relay	Headless(JVM)	8092	저널 소비 → 원장 PDNG 기록(접수 동기화)
4	Hermes	…Rapid Memory Execution…Settlement	Headless(JVM)	8093	저널 순차소비(cc=1)·순서교정·선저널·당좌 차/대변(강한 일관성)·ACSP
5	Prada	Persistent Repository…Aggregation	Headless(JVM)	8094	결과 소비·완결 규율(과반)·ACCC 확정·조회사본·결과통보 발행
6	Gucci	Global User Communication Control Interface	Web(Tomcat)	8095	외부 경계 관문: 로그인·JWT·API인증·유량제어·재전송차단·리버스프록시·결과 콜백송부
7	LouisVuitton	Leading Operations Unified Info Systems…	Web(Tomcat)	8099	시스템관리: DB초기화·코드·사용자권한·대사 대시보드

유형 구분: Web 서비스(Chanel·Gucci·LouisVuitton)만 내장 Tomcat으로 HTTP 리슨. 코어 처리 서비스 (Sequencer·Dior·Hermes·Prada)는 Kafka 컨슈머 JVM. 관측성(B4) 도입으로 내장 Tomcat을 활성화해 예약 포트(8090/8092/8093/8094)에 /actuator(health·prometheus)만 노출한다(업무 HTTP 아님).

4. 물리(배포) 아키텍처 — OS · WAS · DB 스택 ★

4.1 배포 토폴로지 (로컬 1센터, 단일 호스트)

 ┌──────────────── 물리 호스트 1대 (개발 PC, Windows 11) ────────────────┐
 │ 포터블 루트: C:\ai-dev\apps (런타임) · C:\ai-dev\home (데이터/상태)      │
 │                                                                        │
 │  [WAS 계층 — JVM 프로세스]                                              │
 │   내장 Tomcat: Chanel:8091 · Gucci:8095 · LouisVuitton:8099            │
 │   Headless JVM: Sequencer · Dior · Hermes · Prada  (전부 JDK 21)        │
 │        │ JDBC(5433)                     │ Kafka(9092)                   │
 │        ▼                                ▼                              │
 │  [DB 계층]  PostgreSQL 16.4 :5433   [MQ] Apache Kafka 3.8.1(KRaft):9092 │
 │   data: home\pgsql-data              data: home\kafka\kraft-logs        │
 │                                                                        │
 │  [프론트]  Node.js 26 + Vite dev server :5174 (개발)                    │
 │  [관측]   Elasticsearch:9200 · Logstash:5000(TCP) · Kibana:5601         │
 │            data: home\es-data                                           │
 └────────────────────────────────────────────────────────────────────────┘

프로토타입은 단일 호스트에 전 구성요소 공존. 운영/BMT는 계층별 물리 분리 + 3센터 배치(§11).

그림 4-1. 배포 스택 (단일 호스트)

flowchart TB
  subgraph HOST["개발 PC · Windows 11 · C:/ai-dev"]
    subgraph WAS["WAS · JDK21 · Spring Boot 내장 Tomcat"]
      W1["Chanel :8091"]
      W2["Gucci :8095"]
      W3["LouisVuitton :8099"]
    end
    subgraph CORE["Headless JVM · Kafka 컨슈머"]
      c1["Sequencer"]
      c2["Dior"]
      c3["Hermes"]
      c4["Prada"]
    end
    DB[("PostgreSQL 16.4 :5433")]
    MQ["Kafka 3.8.1 KRaft :9092"]
    OBS[("ELK 8.15.2<br/>9200/5000/5601")]
    FE["Vite :5174 · Node 26"]
  end
  FE --> W1
  WAS --> DB
  WAS --> MQ
  CORE --> DB
  CORE --> MQ
  WAS -->|로그| OBS
  CORE -->|로그| OBS

4.2 OS-WAS-DB 스택 매트릭스

구분	구성요소	제품/버전	포트	데이터 경로	비고
OS	운영체제	Windows 11 Enterprise 10.0.26100 (x64)	—	—	CPU 가상화 차단 → Docker 미사용, 네이티브 배치
런타임	JVM	Eclipse Temurin JDK 21.0.11 LTS	—	`apps\jdk-21`	빌드·실행 공통(전역 JAVA_HOME은 jdk-26 별도)
WAS	앱서버	Spring Boot 3.3.4 내장 Apache Tomcat	8091/8095/8099	—	Web 3종. 코어 4종은 headless JVM
언어/빌드	언어	Kotlin 2.0.20 / Java 21 toolchain	—	—	—
	빌드	Gradle 8.10.2 (Kotlin DSL, 멀티모듈)	—	`home\gradle`	JDK26 미지원 → JDK21 고정
	DB 마이그레이션	Flyway(Spring Boot 관리 버전)	—	`db/migration/V*.sql`	스키마 형상관리(LouisVuitton 실행)
DB(원장)	RDBMS	PostgreSQL 16.4	5433	`home\pgsql-data`	강한 일관성 원장. acs(5432) 회피
MQ/브로커	이벤트	Apache Kafka 3.8.1 (KRaft, 무 Zookeeper)	9092	`home\kafka\kraft-logs`	입구·저널·결과·통보. 저널은 단일 파티션
로그	검색엔진	Elasticsearch 8.15.2	9200	`home\es-data`	인덱스 `rtgs-logs-*`
	수집	Logstash 8.15.2	5000(TCP)	—	json_lines → ES. encoder 7.4
	시각화	Kibana 8.15.2	5601	—	Discover "RTGS Logs"
메트릭	수집	Prometheus 3.13.0	9090	`home\prometheus-data`	7서비스 `/actuator/prometheus` 스크랩(5s), `infra\start-prometheus.cmd`
	시각화	Grafana 13.1.0 (OSS)	3000	`home\grafana-data`	Prometheus 데이터소스+RTGS Overview 대시보드 자동, `infra\start-grafana.cmd`
프론트	런타임	Node.js 26.3.0	—	—	개발 서버
	프레임워크	React 18.3.1 + Vite 5.4.2 + TS 5.5.4	5174	—	운영/관리 콘솔
부하	테스트	k6 0.56.0	—	—	성능/스파이크
(미사용)	문서DB	MongoDB 7.0.14	(27017)	—	EDR 파일락 크래시 → PostgreSQL로 대체

4.3 프로세스·환경

기동: run-dc1.cmd(인프라 + 7서비스) · infra\start-elk-native.cmd(ELK) · run-frontend.cmd(콘솔). 종료: stop-dc1.cmd.
환경변수: C:\ai-dev\scripts\env.cmd(JDK21_HOME/GRADLE_HOME/PATH). 센터 파라미터 CENTER_ID=DC1, CENTER_COUNT=1.
각 서비스는 java -jar <service>-0.1.0.jar(Spring Boot fat jar)로 독립 실행.

5. 데이터 아키텍처

5.1 저장소 역할 분리

저장소	역할	근거
PostgreSQL	권위 원장(잔액·거래상태·선저널·조회사본·원전문·통보·사용자·콜백)	강한 일관성(이중지급 방지)
Kafka	입구 완충 + 전역순서 저널 전파 + 결과/통보	순서 공유·비동기·완충
(MongoDB)	원전문/조회사본 (클라우드/BMT)	로컬은 EDR 이슈로 PostgreSQL 대체

5.2 PostgreSQL 테이블 (DB: `rtgs`)

테이블	용도	소유(주 기록)
`account`	참가기관 당좌계좌 잔액(19개 기관 시드)	Hermes
`transfer`	거래 원장(BMI PK, 상태·순번·금액)	Dior/Hermes/Prada
`journal_log`	선저널(global_seq PK)	Hermes
`raw_message`	원전문 pacs.008 XML + SHA-256	Chanel
`settlement_view`	조회 전용 사본(완결 확정)	Prada
`notification`	결과통보 아웃박스(pacs.002, delivered/attempts)	Chanel(적재)/Gucci(송부확정)
`app_user`	사용자·권한(ADMIN/ORG_S/ORG_R) + secret	LouisVuitton/Gucci
`institution_endpoint`	기관 콜백 URL 레지스트리	Gucci

컬럼 한글명은 COMMENT ON COLUMN(데이터 사전)으로 관리 → 화면 라벨의 단일 출처.
스키마 형상관리 = Flyway: backend/louisvuitton/src/main/resources/db/migration/V*.sql가 유일 출처. LouisVuitton 기동 시 자동 적용(flyway_schema_history 기록). 기존 DB는 baseline 처리, 신규 DB는 V1부터 생성. 변경은 새 V+1__*.sql 추가(수기 ALTER·기적용 마이그레이션 수정 금지).

5.3 Kafka 토픽

토픽	발행 → 소비	파티션	용도
`rtgs.inbound`	Chanel → Sequencer	1	접수 원시 요청
`rtgs.journal`	Sequencer → Dior·Hermes	1(전역순서)	전역순번 저널
`rtgs.result`	Hermes → Prada	1	결제 결과(ACSP/RJCT)
`rtgs.notify`	Prada → Chanel	1	완결 결과통보 트리거

5.4 상태 전이 (TxSts)

RCVD(접수) → ACTC(순번) → PDNG(원장기록) → ACSP(정산반영) → ACCC(입금처리완료) / 실패 RJCT.

그림 5-1. 상태 전이도

stateDiagram-v2
  [*] --> RCVD: 접수(Chanel)
  RCVD --> ACTC: 순번(Sequencer)
  ACTC --> PDNG: 원장기록(Dior)
  PDNG --> ACSP: 정산(Hermes)
  ACSP --> ACCC: 완결·과반(Prada)
  ACCC --> [*]
  RCVD --> RJCT: 검증실패(XSD/업무규칙)
  ACSP --> RJCT: 잔액부족/미등록기관
  RJCT --> [*]

6. 인터페이스 설계

6.1 전문(ISO 20022, 공식 XSD)

전문	표준/버전	방향	검증
결제의뢰	pacs.008.001.08 (FIToFICstmrCdtTrf)	참가기관 → RTGS	공식 XSD(XXE 차단, DOM 파싱)
결과통보	pacs.002.001.10 (FIToFIPmtStsRpt)	RTGS → 참가기관	정식 네임스페이스 생성
식별자	BMI 22자리 = 영업일(8)+기관(4)+일련(10)	—	멱등키

6.2 주요 API

계층	메서드·경로	인증	설명
관문(Gucci)	`POST /gucci/auth/login`	—	로그인 → JWT 발급
	`POST /gucci/pay/customer`	Bearer+nonce	인증 접수(→Chanel 프록시)
	`GET /gucci/inquiry/{bmi}` · `/accounts`	Bearer	인증 조회
	`GET /gucci/health/centers` · `GET/PUT /gucci/callbacks`	—/ADMIN	헬스·콜백 레지스트리
코어(Chanel)	`POST /pay/customer`, `GET /inquiry/{bmi}`, `/accounts`	(내부)	접수·조회
	`GET /notifications[/{bmi}]`, `/rawmessage/{bmi}`, `/meta/labels`	(내부)	통보·원전문·데이터사전
관리(LouisVuitton)	`POST /admin/reset`, `/admin/institutions	users	status-codes

7. 처리 흐름 (요약)

신청 → [Chanel] RCVD·XSD·경량화 → rtgs.inbound
     → [Sequencer] 전역순번·ACTC → rtgs.journal
        ├ [Dior] PDNG(접수동기화)
        └ [Hermes] 순서교정·선저널·잔액 차/대변(강한 일관성)·ACSP → rtgs.result
             → [Prada] 과반확정·ACCC·조회사본 → (커밋 후) rtgs.notify
                  → [Chanel] pacs.002 생성·아웃박스 → [Gucci] 콜백 송부(재시도/ACK)

그림 7-1. 거래 처리 시퀀스

sequenceDiagram
  participant ORG as 참가기관(ORG_S)
  participant G as Gucci
  participant C as Chanel
  participant S as Sequencer
  participant H as Hermes
  participant P as Prada
  ORG->>G: 로그인 → JWT
  ORG->>G: pacs.008 (Bearer,nonce)
  G->>C: 인증·검사 후 프록시
  C-->>ORG: pacs.002 (RCVD)
  C->>S: rtgs.inbound
  S->>H: rtgs.journal (ACTC, Dior도 소비→PDNG)
  H->>H: 선저널·잔액 차/대변 (ACSP)
  H->>P: rtgs.result
  P->>P: 과반 확정 (ACCC)
  P->>C: rtgs.notify
  C->>G: 결과통보(pacs.002)
  G->>ORG: 콜백 송부 (ACK)

상세는 「RTGS 프로토타입 워크플로우.md」 참조.

8. 비기능 요구 설계

8.1 성능

목표 10,000~20,000 TPS(개요). 저널 단일 파티션이 순서 보장의 대가로 순번기 처리량 상한이 됨 → 성능 급소로 계측(sim).
Gucci 유량제어(기관별 50/10s 기본)로 코어·순번기 보호(백프레셔).

8.2 가용성 (정족수)

3센터 정족수=2: 1센터 다운=서비스 지속 / 2센터 다운=안전 정지(장애). 1센터 로컬은 자기=과반.
Web 서비스는 무상태(세션리스 JWT) → 수평 확장·GSLB 분산 적합.

8.3 복원성 (무손실)

선저널 + Kafka 오프셋 재생: 원장엔진(Hermes) 재기동 시 유실 없이 승계.
순번 영속화: 순번기 재기동 시 MAX(global_seq)에서 이어서 발번.

8.4 데이터 정합성

전역순번 직렬화 + 강한 일관성 트랜잭션 → 이중지급 0 / 총액 보존 불변식. 원장=저널=조회사본 대사.
멱등성: BMI 기준 ON CONFLICT upsert(중복 접수 무해).

8.5 보안

영역	설계
인증	Gucci 로그인 → JWT(HS256). 자격증명=app_user(권한 마스터), 비밀키 BCrypt+솔트 해시 저장(기동 시 평문 자동 승격)
인가	역할(ADMIN/ORG_S/ORG_R) + 기관 바인딩(토큰 org == 전문 송신기관)
관리자 콘솔	LouisVuitton `/admin/` 은 ADMIN JWT 필수**(인터셉터 검증). Gucci 발급 토큰을 동일 서명키로 검증. 초기암호 변경(must_change_password) 지원. 테스트계정 a/1
API 보호	유량제어 · 재전송 차단(nonce+timestamp) · 감사로그(ELK)
전문 무결성	원전문 SHA-256 해시, XSD 검증, XXE 차단(DTD/외부엔티티 비허용)
전달 보장	결과 콜백 at-least-once(재시도+ACK) + 수신측 dedup 전제
(후속)	mTLS·비밀키 해시/회전·펜싱 토큰

8.6 관측성

로그: 전 서비스 Logback(JSON, service/center 필드) → Logstash(:5000) → ES(rtgs-logs-*) → Kibana.
메트릭(B4): 전 서비스 Micrometer → /actuator/prometheus 노출. 업무 메트릭 rtgs.settlements(정산·status), rtgs.settle(정산 지연 Timer), rtgs.finality(완결·status), rtgs.journal.gap(순서 gap), 접수 TPS/지연은 http_server_requests(Chanel /pay), Kafka consumer lag는 Micrometer 자동. Prometheus 3.13.0(:9090) 설치·7타깃 스크랩(5s) + Grafana 13.1.0(:3000) "RTGS Overview" 대시보드(접수 TPS·정산율·완결·Kafka lag·JVM) 완료.
헬스(B5): 전 서비스(헤드리스 포함)가 service_heartbeat에 주기 하트비트 → LouisVuitton /admin/health 및 관리자 대시보드에서 UP/STALE 표시(DB 기반 liveness).
감사 이벤트(AUTH/AUTHZ/RATE/REPLAY/ORGBIND/PAY/DELIVER)와 처리 로그 중앙 수집.

9. 검증 설계 (복원력 급소, sim/)

ID	축	검증	상태
S1	기능성	정합성·총액보존·계층대사	PASS
S2	복원성	Hermes 강제종료·재기동 무손실 승계	PASS
S4	기능성	저널 순번 역전 주입 → 재정렬	PASS
S3/S5	가용성/성능	정족수·펜싱 / 스파이크 완충	다센터(§11)

10. 형상·배포 운영

소스: backend(Gradle 멀티모듈 7+1 common) · frontend · infra · iso20022 · sim · loadtest · docs.
산출물: 서비스별 Spring Boot fat jar(*-0.1.0.jar). 프론트는 Vite 빌드.
스키마: Flyway db/migration/V1__baseline.sql(+ 이후 V2…) — LouisVuitton 기동 시 자동 적용. (구 postgres-init.sql은 legacy)
반영: 백엔드=재빌드+해당 서비스 재기동(무관 서비스 무중단), 프론트=Vite HMR.

11. 확장 아키텍처 (다센터 A-A-A, 향후 · 고사양 PC 이후)

                        ┌── DC1 (7서비스 + PostgreSQL rtgs_dc1)
[단일 Sequencer(리더선출)]─저널(Kafka 공유)─┼── DC2 (동일 + rtgs_dc2)
                        └── DC3 (동일 + rtgs_dc3)
  · 컨슈머 그룹 센터별 분리 · 센터별 DB/포트 오프셋 · 정족수 2/3 자동전환 · 펜싱
  · Gucci 센터별 배치 + 앞단 GSLB(무상태 라우팅) · 3센터 데이터 동일성 대사

순번기: active-standby 리더선출(4번째 사이트 불필요) — GSLB로 순서 결정 금지(무상태라 순서 권위 없음).
헬스체크(Gucci G3): 관측·멤버십 입력용, 실제 페일오버는 정족수+펜싱(단순 ping 페일오버는 split-brain).

12. 제약·전제·미결

제약: 단일 호스트(가상화 차단으로 Docker 불가) · 로컬 1센터 · MongoDB 미사용.
전제: 사전확인(잔액·계좌)은 참가기관(클라이언트) 책임, RTGS 코어는 기관 당좌계좌 간 이체만.
미결/후속: 다센터 S3/S5, 프론트 Gucci 경유 로그인 UI, mTLS·비밀키 해시, Logstash 힙 256m, PC 이관.

부록 A. 포트 일람

Sequencer(논리)8090 · Chanel 8091 · Dior(논리)8092 · Hermes(논리)8093 · Prada(논리)8094 · Gucci 8095 · LouisVuitton 8099 · Frontend 5174 · PostgreSQL 5433 · Kafka 9092 · ES 9200 · Logstash 5000 · Kibana 5601. (acs와 전면 분리: acs 8080/5173/5432)

부록 B. 디렉터리

C:\ai-dev\apps\   포터블 런타임(jdk-21, gradle, kafka, postgresql, elk, k6, nodejs)
C:\ai-dev\home\   데이터·상태(pgsql-data, kafka, es-data, gradle 캐시)
C:\ai-dev\workspace\rtgs\  backend · frontend · infra · iso20022 · sim · loadtest · docs

본 설계서는 개발 진행에 따라 갱신한다.

23 KiB Raw Blame History