How it works

코어는 이미 들어 있습니다.
자동화는 필요한 것만 골라서 씁니다.

회사마다 시스템을 처음부터 새로 만들고 계신가요?
인증도, 결재도, 청구도, 감사도 매번 다시 만들어야 했습니다.
DADA는 어느 회사에나 똑같이 필요한 이 기능을 코어 하나에 모아 뒀습니다.
그 위에 필요한 자동화 모듈만 골라서 쓰면, 회사마다 다른 시스템이 같은 빌드에서 돌아갑니다.
공통은 코어가 맡고, 회사마다 다른 일은 자동화가 합니다.

자동화 모듈 보러 가기 →아키텍처 문서 받기
빌드는 하나필요한 것만 골라서고객별 격리 배포

예전 멀티테넌트 라우팅과는 다릅니다.
어떤 모듈을 켤지는 매니페스트 파일에 적고, 고객 데이터는 배포 단위로 격리합니다.

Core + Automation → Edition

토대는 함께 쓰고, 자동화는 필요한 것만 골라서 씁니다.

인증, 권한 관리, 조직, 문서, 결재, 일정, 알림, 청구, 감사, 화면 틀, 배포.
어느 회사에나 똑같이 필요한 이 기능을, 매번 다시 만들고 계시진 않나요?
DADA는 이 공통 기능을 코어에 한 번만 두고, 회사마다 다른 부분만 자동화 모듈로 골라서 씁니다.
쓸 모듈을 코어에 등록하고(register), 그중 켤 것만 고른 뒤(compose), 화면에 들어가면(enter) 새 시스템이 완성됩니다.
토대는 코어가 맡고, 그 위에서 자동화가 일합니다.

①register(core)

Core Kernel — 기본으로 들어 있는 토대

인증, 권한 관리(RBAC), 조직, 문서(DMS), 결재, 일정, 알림, 청구, 감사, 화면 틀, 배포(K3s). 회계·영업·재고·생산·인사·구매 여섯 개 모듈도 여기 들어 있습니다. 운영에서 검증된 DADAERP 기능을 그대로 코어로 옮겨 왔습니다.

②compose(modules)

Automation — 필요한 것만 골라서 쓰는 자동화

Doc Intake, Auto-Journal, Approval Flow, Deadline Radar, Claim Guard, Entity Graph, Audit Trail, Smart Notify. 필요한 모듈만 골라서 코어 위에서 씁니다. 사람이 손으로 옮겨 적고, 빠뜨리고, 일일이 챙기던 일을 모듈이 대신합니다.

③enter(edition)

Editions — 골라서 켠 결과

코어도 같고, 쓸 수 있는 모듈도 같습니다. 어떤 자동화를 켰느냐가 곧 그 회사의 시스템이 됩니다. 법무·의료·일반 기업은 같은 시스템을 현장에 맞게 다르게 쓰는 사례일 뿐입니다.

register(core)→compose(modules)→enter(edition)

빌드는 하나만 만들어 둡니다.
그 다음부터는 설정에서 모듈을 켜고 끄기만 하면 됩니다.

근거: 플랫폼 아키텍처 §1 (3계층 모델).

Automation Layer

일을 빠르게 만드는 건, 코어 위에서 일하는 자동화입니다.

회계·영업·재고·생산·인사·구매 여섯 개 모듈은 코어에 이미 들어 있습니다.
일이 정말 빨라지는 건 그 위에서 자동화 모듈이 일할 때입니다.
사람이 손으로 옮겨 적고 챙기던 일을 모듈이 초안으로 만들어 두면, 확정은 직접 하시면 됩니다.

Core Modules기본으로 들어 있는 토대 ·회계영업재고생산인사구매
Doc Intake

비정형 문서 정형화

카톡·녹취·PDF·스캔을 정리된 데이터 초안으로 만들어 줍니다.

Before
받은 자료를 사람이 하나하나 옮겨 적습니다.
After
분류하고 추출해 초안을 만들어 주고, 확정은 담당자가 합니다.
Gain
옮겨 적는 데 쓰던 시간을 검토에 쓸 수 있습니다.
전 에디션
Auto-Journal

자동 분개·전표

거래가 생기면 전표 초안이 자동으로 만들어집니다.

Before
월말마다 전표를 손으로 일일이 끊습니다.
After
거래 내용을 읽고 분개 초안을 자동으로 올려 줍니다.
Gain
며칠씩 걸리던 마감이 검토 한 번으로 끝납니다.
회계 · ERP 기본
Approval Flow

결재 자동 라우팅

금액과 조건에 맞춰 결재선을 자동으로 잡아 줍니다.

Before
건마다 누구에게 올려야 하는지 묻고 다닙니다.
After
정해 둔 규칙대로 결재선을 자동으로 만들어 줍니다.
Gain
승인이 빨라지고, 누구를 빠뜨릴 일도 없습니다.
전 에디션
Deadline Radar

기한 자동 추적

놓치면 안 되는 기한을 미리 알려 줍니다.

Before
규제·계약 기한을 엑셀에 적어 두고 잊어버립니다.
After
기한이 다가오면 담당자와 관리자에게 함께 알려 줍니다.
Gain
기한을 놓쳐 생기는 사고가 사라집니다.
전 에디션
Claim Guard

청구 삭감 방어

삭감될 위험이 있는 청구를 미리 짚어 줍니다.

Before
삭감 통보를 받고 나서야 사유를 찾아 헤맵니다.
After
청구하기 전에 삭감 위험과 누락을 근거와 함께 알려 줍니다.
Gain
놓치던 수익이 눈에 보이고, 미리 막을 수 있습니다.
의료 · CuraCore
Entity Graph

관계망 자동 구성

흩어진 인물·기업·돈의 연결을 한 장으로 보여 줍니다.

Before
관계도를 손으로 그리다 보면 빠뜨리기 쉽습니다.
After
기록에서 관계를 읽어 그래프로 정리해 줍니다.
Gain
이해관계도 자금 흐름도 한눈에 들어옵니다.
법무 · LexCore
Audit Trail

감사 자동 기록

모든 변경 내역이 위변조 없이 그대로 남습니다.

Before
감사 때마다 증빙을 모으느라 일이 멈춥니다.
After
누가 무엇을 했는지 자동으로, 고칠 수 없게 기록됩니다.
Gain
감사 준비에 들이던 시간이 크게 줄어듭니다.
전 에디션
Smart Notify

실시간 알림

놓치면 안 되는 일만 골라서 바로 알려 줍니다.

Before
메일함에 묻혀 중요한 승인을 놓칩니다.
After
승인해야 할 일과 마감만 실시간으로 띄워 줍니다.
Gain
중요한 일이 더는 묻히지 않습니다.
전 에디션

ERP 여섯 개 모듈은 기본으로 들어 있고, 자동화 모듈은 그 위에서 필요한 것만 골라서 씁니다.

자동화 모듈 카탈로그 보기 →
Runtime Manifest

새 시스템을 만들 때 다시 배포할 필요 없이, 파일 하나만 고치면 됩니다.

회사마다 다시 빌드하고 다시 배포하셨다면, 이제 그럴 일이 없습니다.
켤 코어 기능과 자동화 모듈을 에디션 매니페스트에 적어 두면, 시스템이 켜질 때 코어가 그 내용을 읽습니다.
그에 맞춰 화면과 메뉴, 권한, 경로를 자동으로 엽니다.
코드는 그대로 두고, 켜는 조합만 바꿉니다.

{
  "edition": "general-erp",
  "label": "일반 기업",
  "coreModules": ["auth", "rbac", "org", "approval", "schedule", "billing", "dms", "audit"],
  "automation": ["doc-intake", "auto-journal", "approval-flow", "audit-trail"],
  "packs": ["erp-common"],
  "menus": "from-pack",   // 메뉴는 켠 모듈이 채운다
  "demoDataset": "general-demo"
}

automation 목록만 바꾸면, 같은 빌드가 전혀 다른 회사의 시스템이 됩니다.

Edition Manifest

에디션이 켤 코어 기능과 자동화 모듈을 적어 두는 곳입니다(JSON 또는 DB). 운영에선 배포 설정에 고정합니다.

Module Registry

시스템이 켜질 때 켠 모듈을 등록해 화면·메뉴·권한·경로를 엽니다. 꺼 둔 모듈은 아예 없는 것처럼 동작합니다.

Edition Switcher

들어가는 화면에서 에디션을 고르면 그 매니페스트에 맞춰 화면, 메뉴, 데이터가 바뀝니다.

멀티테넌트 라우팅이 아닙니다.

데모에서 에디션을 바꾸는 건 세션 안에서만 일어납니다. 한 배포 안에서 들어가는 화면만 바뀔 뿐입니다.
고객 데이터는 라우팅으로 가르는 게 아니라 배포 단위로 나눠서 지킵니다. 고객 환경 안 컨테이너에 따로 배포합니다.
예전 CMS의 ServiceContext 라우팅은 되살리지 않습니다.

근거: 플랫폼 아키텍처 §2·§8 (런타임 매니페스트 · 가드레일).

데모

사이트 하나에 모든 모듈을 올립니다

매니페스트와 스위처로 그때그때 바꿔 봅니다.
에디션마다 데모용 데이터를 따로 둡니다.

운영

고객마다 따로 격리해 배포하고(K3s), 필요한 모듈만 켭니다

매니페스트는 배포 설정에 고정합니다.
고객마다 DB 하나로 돌아갑니다.

데모에서 보시는 그대로가 운영에서도 그대로 돌아갑니다.
코드도 모듈도 똑같습니다.
데모에선 여러 조합을 보여 드리고, 운영에선 필요한 모듈만 격리해서 씁니다.

조립 데모로 체험 →
Pack SDK

규칙 없이 붙인 모듈은 결국 무너집니다. 그래서 정해진 규칙을 둡니다.

메뉴가 서로 부딪치고, 권한이 새어 나가고, 한 모듈이 남의 테이블을 건드립니다.
규칙 없이 모듈을 붙이면 결국 이런 대가를 치릅니다.
DADA의 모듈은 정해진 여섯 군데만 선언하고 구현하면 코어에 붙고, 그 밖의 연결은 아예 막아 둡니다.
이렇게 충돌과 오염을 시스템이 켜질 때 미리 잡아 주는 규칙이 바로 Pack SDK입니다.

server/.../erp/
  core/                 # 커널(인증·RBAC·조직·결재·…)
  automation/           # 자동화 모듈(Doc Intake·Auto-Journal·…)
  packs/
    erp-common/         # 거래처·품목·창고 등 공통 마스터
    erp-manufacturing/  # 제조 특화(BOM·작업지시·공정)
    lpms-legal/         # 법무 활용(사건원장·관계망·…)
    med-foundation/     # 의료 활용(청구 무결성·기한)
  platform/             # ModuleRegistry · EditionManifest 로더
packages/
  shared-core-ui/       # 셸·스위처·스캐폴드
  pack-erp-manufacturing/ , pack-lpms-legal/   # 프론트 팩
apps/client/            # 단일 앱(에디션 스위처 진입)

지금 쓰는 pnpm 모노레포를 그대로 이어 갑니다.
새로운 프레임워크가 아니라, 이미 있던 경계를 코어와 모듈로 정리했을 뿐입니다.

①

Pack Manifest

팩이 어떤 모듈인지 한 파일에 선언합니다. 고유 key, label, kind(erp/lpms/med), requiresCore, dependsOn, tablePrefix, menuRoot, permissionNamespace, demoDataset를 적습니다.

②

Backend Module (Spring)

컨트롤러는 상대경로 /erp/<pack>/…, /lpms/<pack>/…, /med/<pack>/…로 두면 /api/v2가 자동으로 붙습니다. 서비스·리포지토리·엔티티·DTO는 팩 안에만 둡니다. 매니페스트가 켠 모듈만 실제로 등록됩니다.

③

DB Migration (Flyway)

마이그레이션 파일은 팩 폴더 안에 두고, 테이블 이름엔 tablePrefix를 반드시 붙입니다(mfg_*·legal_*·med_*). 단일 DB는 그대로 두고 코어 테이블은 건드리지 않습니다. 기능을 늘릴 땐 팩 테이블을 더하고 외래 키로 연결합니다.

④

Permission 기여 (RBAC-003)

모듈이 자기 권한 목록을 permissionNamespace 아래에 올리면 코어의 권한 관리(RBAC)가 합쳐 줍니다. 꺼 둔 모듈의 권한은 아예 보이지 않습니다.

⑤

Menu / Navigation 기여

모듈이 자기 메뉴를 menuRoot 아래에 더하면 코어가 받아 줍니다. 켠 모듈의 메뉴만 화면에 나타납니다.

⑥

Frontend Module (Next.js)

화면과 경로는 팩 프론트 패키지 안에만 둡니다(AdminPageScaffold). 에디션 스위처는 켠 모듈의 화면만 올립니다.

매니페스트를 찾고(discover), 고유 key·prefix·의존을 검사하고(validate), 코어에 등록하고(register), 에디션별로 켭니다(enable).
prefix가 겹치거나 메뉴 루트가 부딪치면 곧바로 켜기를 멈춥니다.

단일 DB + 팩 prefix

DB는 dadaerp_main 하나로 두고(ADR-ERP-SIMPLICITY), 테이블만 팩 prefix로 나눕니다(mfg_*·legal_*·med_*).
거래의 무결성은 한 DB 안에서 지키고, 모듈 사이는 prefix와 권한 이름 공간으로 격리합니다.

근거: ADR-PACK-SDK-001 (6 기여점) · 플랫폼 아키텍처 §4·§5.

Security · Zero-Trust

공용 클라우드에 섞지 않습니다.

민감한 데이터를 다루는 회사가 가장 걱정하는 건 결국 데이터 유출입니다.
한 번 사고가 나면 그동안 쌓은 신뢰가 무너집니다.
그래서 DADA는 처음부터 격리를 답으로 골랐습니다.
고객 환경 안 컨테이너에 따로 배포하니, 민감한 데이터는 밖으로 나가지 않으면서도 기능은 계속 늘릴 수 있습니다.
보안을 지키면서도 시스템을 키울 수 있습니다.

Zero-Trust 격리 배포

아무도 그냥 믿지 않습니다. 모든 접근을 검증하고 격리합니다.

컨테이너 격리(K3s)

고객 환경 안 K3s로 배포 단위를 나눕니다. 공용 풀에 데이터를 섞지 않습니다.

코어→팩 단방향 의존

팩은 코어를 부를 수 있지만, 코어는 팩을 부르지 못합니다. 팩끼리는 dependsOn으로 선언한 만큼만 부릅니다. 한 모듈에서 생긴 문제가 옆 모듈로 번지지 않습니다.

전수 감사 로그(해시체인)

민감한 작업은 빠짐없이 남습니다. 로그는 해시체인으로 이어져 손대면 바로 드러납니다.

민감정보는 경계를 넘지 않음

데이터는 고객별 격리 경계 밖으로 나가지 않습니다. 에디션을 바꿔도 그건 세션 안에서 보이는 화면만 바뀌는 것이지, 경계를 넘는 게 아닙니다.

격리 원칙

배포 격리

고객마다 따로 배포합니다(K3s). 코드로 가르는 게 아니라 인프라 차원에서 경계를 나눕니다.

격리 원칙

의존 격리

코어와 팩은 한 방향으로만 의존하고, DB는 팩 prefix로 나눕니다. 책임 경계를 코드에서 강제합니다.

격리 원칙

감사 무결성

모든 작업을 빠짐없이 자동으로 기록하고, 로그는 해시체인으로 이어 둡니다. 누가 언제 무엇을 했는지 발뺌할 수 없습니다.

순수 B2B IT 인프라 공급입니다. 법률·의료 서비스 광고가 아니며, 어떤 결과도 보장하지 않습니다. 법률·의학적 판단의 주체는 고객(변호사·의료기관)이고, 산출물은 초안·근거일 뿐 확정은 사람의 승인 게이트를 거칩니다(우회 불가).

근거: 플랫폼 아키텍처 §3·§8 (데모↔운영 양립 · 가드레일) · ADR-AUDIT-002 (감사 해시체인).

격리 아키텍처 살펴보기 →아키텍처 문서 받기
Proof

새로 만들지 않습니다. 이미 검증된 코어를 그대로 씁니다.

결재, 청구, 일정, 문서, 권한, 감사. 범용 ERP에서 다 만들어 검증한 기능을 그대로 코어로 가져다 씁니다.
그 위에서 필요한 자동화 모듈만 골라서 씁니다.
그래서 새로 만들다 생기는 위험이 가장 작습니다.

결재 29 클래스
청구(Invoice) 18
일정 16
문서 24
RBAC-003 권한 카탈로그
6개 ERP 모듈
빌드 하나로 여러 에디션
자동화 모듈 8종

이 숫자들은 새로 만든 것이 아니라, 이미 운영 중인 코어에서 가져왔습니다.

같은 코어와 같은 자동화 모듈이 현장에 따라 다르게 쓰입니다.
법무에선 Entity Graph와 Doc Intake를, 의료에선 Claim Guard와 Deadline Radar를, 일반 기업에선 Auto-Journal과 Approval Flow를 주로 켭니다.
사업이 세 개로 나뉜 게 아니라, 같은 시스템을 세 가지로 다르게 쓰는 것뿐입니다.

출처: src/lib/site.ts automationModules · editions · 플랫폼 아키텍처 P4.

같은 시스템이 현장에 따라 어떻게 달라지는지, 직접 눌러 보세요.

에디션 스위처에서 같은 코어에 자동화를 바꿔 가며 켜 볼 수 있습니다.
같은 토대 위에서 조합만 달라지는 모습을, 한 화면에서 직접 확인하실 수 있습니다.
우리 회사에도 맞을지, 부담 없이 먼저 물어보세요.

데모 신청아키텍처 문서 받기
데모 신청