코어는 이미 들어 있습니다.
자동화는 필요한 것만 골라서 씁니다.
회사마다 시스템을 처음부터 새로 만들고 계신가요?
인증도, 결재도, 청구도, 감사도 매번 다시 만들어야 했습니다.
DADA는 어느 회사에나 똑같이 필요한 이 기능을 코어 하나에 모아 뒀습니다.
그 위에 필요한 자동화 모듈만 골라서 쓰면, 회사마다 다른 시스템이 같은 빌드에서 돌아갑니다.
공통은 코어가 맡고, 회사마다 다른 일은 자동화가 합니다.
공용 클라우드에 여러 고객을 섞지 않습니다.
회사마다 켤 기능만 골라 구성하고, 고객 데이터는 배포 단위로 격리합니다.
토대는 함께 쓰고, 자동화는 필요한 것만 골라서 씁니다.
인증, 권한 관리, 조직, 문서, 결재, 일정, 알림, 청구, 감사, 화면 틀, 배포.
어느 회사에나 똑같이 필요한 이 기능을, 매번 다시 만들고 계시진 않나요?
DADA는 이 공통 기능을 코어에 한 번만 두고, 회사마다 다른 부분만 자동화 모듈로 골라서 씁니다.
쓸 모듈을 토대 위에 올리고, 그중 켤 것만 고르면, 그 자리에서 새 시스템이 완성됩니다.
토대는 코어가 맡고, 그 위에서 자동화가 일합니다.
코어 — 기본으로 들어 있는 토대
인증, 권한 관리, 조직, 문서, 결재, 일정, 알림, 청구, 감사, 화면 틀, 격리 배포. 회계·영업·재고·생산·인사·구매 여섯 개 모듈도 여기 들어 있습니다. 운영에서 검증된 DADAERP 기능을 그대로 토대로 옮겨 왔습니다.
자동화 — 필요한 것만 골라서 쓰는 자동화
문서 정리, 장부 자동 기입, 결재선 자동 지정, 기한 추적, 청구 삭감 방어, 관계도 매칭, 감사 기록, 실시간 알림. 필요한 모듈만 골라서 토대 위에서 씁니다. 사람이 손으로 옮겨 적고, 빠뜨리고, 일일이 챙기던 일을 모듈이 대신합니다.
에디션 — 골라서 켠 결과
토대도 같고, 쓸 수 있는 모듈도 같습니다. 어떤 자동화를 켰느냐가 곧 그 회사의 시스템이 됩니다. 법무·의료·일반 기업은 같은 시스템을 현장에 맞게 다르게 쓰는 사례일 뿐입니다.
토대에 올리고 → 골라서 켜고 → 들어가면 끝.
빌드는 하나만 만들어 둡니다.
그 다음부터는 설정에서 모듈을 켜고 끄기만 하면 됩니다.
일을 빠르게 만드는 건, 코어 위에서 일하는 자동화입니다.
회계·영업·재고·생산·인사·구매 여섯 개 모듈은 코어에 이미 들어 있습니다.
일이 정말 빨라지는 건 그 위에서 자동화 모듈이 일할 때입니다.
사람이 손으로 옮겨 적고 챙기던 일을 모듈이 초안으로 만들어 두면, 확정은 직접 하시면 됩니다.
문서 자동 정리
카톡·녹음·PDF·스캔본을 표처럼 정리된 초안으로 만들어 줍니다.
- Before
- 받은 자료를 담당자가 하나하나 옮겨 적습니다.
- After
- 자료 업로드 시 자동으로 분류되고 초안이 작성되며, 담당자가 최종 작성 합니다.
- Gain
- 옮겨 적는 데 낭비되던 시간을 중요 사안 검토에 쓸 수 있습니다.
장부 자동 기입(분개·전표)
거래가 생기면 장부에 올릴 초안이 자동으로 만들어집니다.
- Before
- 월말마다 전표를 손으로 일일이 끊습니다.
- After
- 거래 내용을 읽고 장부 초안을 자동으로 올려 줍니다.
- Gain
- 며칠씩 걸리던 월말 마감이 검토 한 번으로 끝납니다.
결재선 자동 지정
금액과 조건에 맞춰 누구에게 결재 올릴지 자동으로 정해 줍니다.
- Before
- 건마다 누구에게 올려야 하는지 묻고 다닙니다.
- After
- 정해 둔 규칙대로 결재선을 자동으로 만들어 줍니다.
- Gain
- 승인이 빨라지고, 누구를 빠뜨릴 일도 없습니다.
기한 자동 추적
놓치면 안 되는 기한을 미리 알려 줍니다.
- Before
- 규제·계약 기한을 엑셀에 적어 두고 잊어버립니다.
- After
- 기한이 다가오면 담당자와 관리자에게 함께 알려 줍니다.
- Gain
- 기한을 놓쳐 생기는 사고가 사라집니다.
청구 삭감 방어
삭감될 위험이 있는 청구를 미리 짚어 줍니다.
- Before
- 삭감 통보를 받고 나서야 사유를 찾아 헤맵니다.
- After
- 청구하기 전에 삭감 위험과 누락을 근거와 함께 알려 줍니다.
- Gain
- 놓치던 수익이 눈에 보이고, 미리 막을 수 있습니다.
관계도 자동 매칭
흩어진 인물·기업·돈의 연결을 직관적인 그래프로 보여 줍니다.
- Before
- 관계도 구성에는 수 많은 자료검토와 누락의 여지가 있습니다.
- After
- 첨부 데이터에서 관계를 읽어 근거있는 관계도 초안을 올립니다.
- Gain
- 이해관계와 자금 흐름을 한눈에 파악합니다.
변경 기록 자동 보관(감사)
누가 무엇을 바꿨는지, 모든 기록이 고칠 수 없게 남습니다.
- Before
- 감사 때마다 증빙을 모으느라 업무가 마비됩니다.
- After
- 모든 업무 내용이 암호화되어 고칠 수 없게 기록됩니다.
- Gain
- 감사 준비에 들이던 시간이 크게 줄어듭니다.
실시간 알림
놓치면 안 되는 일만 골라서 바로 알려 줍니다.
- Before
- 메일함에 묻혀 중요한 승인을 놓칩니다.
- After
- 승인해야 할 일과 마감 임박 이슈를 실시간으로 알려 줍니다.
- Gain
- 우선순위 높은 업무를 더이상 놓치지 않습니다.
ERP 여섯 개 모듈은 기본으로 들어 있고, 자동화 모듈은 그 위에서 필요한 것만 골라서 씁니다.
회사마다 처음부터 다시 만들지 않습니다.
회사마다 다시 빌드하고 다시 배포하셨다면, 이제 그럴 일이 없습니다.
켤 기능과 자동화 모듈만 고르면, 그에 맞춰 화면과 메뉴, 권한이 자동으로 열립니다.
같은 토대 위에서 켜는 조합만 바꿔, 회사마다 다른 시스템이 됩니다.
켤 기능 정의
그 회사가 켤 기능과 자동화 모듈을 정해 둡니다. 운영에선 도입할 때 고정합니다.
모듈 켜기
정해 둔 모듈만 켜져 화면·메뉴·권한이 열립니다. 꺼 둔 모듈은 아예 없는 것처럼 동작합니다.
에디션 전환
들어가는 화면에서 에디션을 고르면 그에 맞춰 화면과 메뉴, 데이터가 바뀝니다.
멀티테넌트 라우팅이 아닙니다.
데모에서 에디션을 바꾸는 건 세션 안에서만 일어납니다. 한 배포 안에서 들어가는 화면만 바뀔 뿐입니다.
고객 데이터는 라우팅으로 가르는 게 아니라 배포 단위로 나눠서 지킵니다. 고객 환경 안 컨테이너에 따로 배포합니다.
사이트 하나에 모든 모듈을 올립니다
그때그때 골라서 바꿔 봅니다.
에디션마다 데모용 데이터를 따로 둡니다.
고객마다 따로 격리해 배포하고(K3s), 필요한 모듈만 켭니다
운영에선 켤 모듈을 도입 시 고정합니다.
고객마다 자기 환경에서 독립적으로 돌아갑니다.
데모에서 보시는 그대로가 운영에서도 그대로 돌아갑니다.
코드도 모듈도 똑같습니다.
데모에선 여러 조합을 보여 드리고, 운영에선 필요한 모듈만 격리해서 씁니다.
규칙 없이 붙인 모듈은 결국 무너집니다. 그래서 정해진 규칙을 둡니다.
메뉴가 서로 부딪치고, 권한이 새어 나가고, 한 모듈이 남의 테이블을 건드립니다.
규칙 없이 모듈을 붙이면 이런 대가가 따라옵니다.
DADA의 모듈은 정해진 자리에만 선언하고 구현하면 토대에 붙고, 그 밖의 연결은 아예 막아 둡니다.
이렇게 충돌과 오염을 시스템이 켜질 때 미리 잡아 줍니다.
새로운 프레임워크를 도입하는 게 아닙니다. 이미 있던 경계를 토대와 모듈로 또렷하게 정리했을 뿐입니다.
한 곳에만 선언
모듈은 자기가 무엇인지 한 곳에만 선언합니다. 무엇을 켜고 끌지가 한눈에 정리됩니다.
기능은 모듈 안에만
각 모듈의 기능은 모듈 경계 안에만 둡니다. 켠 모듈만 실제로 동작하고, 끈 모듈은 없는 것처럼 됩니다.
데이터는 분리해서 더한다
모듈마다 자기 데이터만 더하고, 공통 토대 데이터는 건드리지 않습니다. 기능을 늘려도 기존이 흔들리지 않습니다.
권한도 분리
모듈이 자기 권한만 더하면 권한 관리가 합쳐 줍니다. 꺼 둔 모듈의 권한은 아예 보이지 않습니다.
메뉴도 분리
모듈이 자기 메뉴만 더하면 됩니다. 켠 모듈의 메뉴만 화면에 나타납니다.
화면도 분리
화면도 모듈 안에만 둡니다. 에디션은 켠 모듈의 화면만 올립니다.
모듈을 켤 때 이름·경계·의존을 시스템이 먼저 점검하고, 충돌이 보이면 곧바로 켜기를 멈춥니다.
한 DB 안에서, 모듈은 격리
고객마다 데이터베이스 하나로 두어 거래의 무결성을 지키고, 그 안에서 모듈끼리는 데이터와 권한을 서로 침범하지 않게 나눕니다.
기능을 늘려도 기존 데이터가 흔들리지 않습니다.
공용 클라우드에 섞지 않습니다.
민감한 데이터를 다루는 회사가 가장 걱정하는 건 결국 데이터 유출입니다.
한 번 사고가 나면 그동안 쌓은 신뢰가 무너집니다.
그래서 DADA는 처음부터 격리를 답으로 골랐습니다.
고객 환경 안 컨테이너에 따로 배포하니, 민감한 데이터는 밖으로 나가지 않으면서도 기능은 계속 늘어납니다.
보안을 지키면서도 시스템은 안정화 되어갑니다.
Zero-Trust 격리 배포
아무도 그냥 믿지 않습니다. 모든 접근을 검증하고 격리합니다.
컨테이너 격리(K3s)
고객 환경 안 K3s로 배포 단위를 나눕니다. 공용 풀에 데이터를 섞지 않습니다.
한 방향으로만 의존
모듈은 토대를 쓰지만, 토대는 모듈에 기대지 않습니다. 모듈끼리도 정해진 만큼만 연결됩니다. 한 모듈에서 생긴 문제가 옆 모듈로 번지지 않습니다.
전수 감사 로그(해시체인)
민감한 작업은 빠짐없이 남습니다. 로그는 해시체인으로 이어져 손대면 바로 드러납니다.
민감정보는 경계를 넘지 않음
데이터는 고객별 격리 경계 밖으로 나가지 않습니다. 에디션을 바꿔도 그건 세션 안에서 보이는 화면만 바뀌는 것이지, 경계를 넘는 게 아닙니다.
배포 격리
고객마다 따로 배포합니다(K3s). 코드로 가르는 게 아니라 인프라 차원에서 경계를 나눕니다.
의존 격리
코어와 팩은 한 방향으로만 의존하고, DB는 팩 prefix로 나눕니다. 책임 경계를 코드에서 강제합니다.
감사 무결성
모든 작업을 빠짐없이 자동으로 기록하고, 로그는 해시체인으로 이어 둡니다. 누가 언제 무엇을 했는지 발뺌할 수 없습니다.
산출물은 초안·근거일 뿐, 확정은 사람의 승인 게이트를 거칩니다(우회 불가).
새로 만들지 않습니다. 이미 검증된 코어를 그대로 씁니다.
결재, 청구, 일정, 문서, 권한, 감사. 범용 ERP에서 다 만들어 검증한 기능을 그대로 코어로 가져다 씁니다.
그 위에서 필요한 자동화 모듈만 골라서 씁니다.
그래서 새로 만들다 생기는 위험이 가장 작습니다.
이 숫자들은 새로 만든 것이 아니라, 이미 운영 중인 코어에서 가져왔습니다.
이 하나의 코어가 다섯 제품을 똑같이 받칩니다.
LexCore(법무)는 Entity Graph·Doc Intake를, CuraCore(의료)는 Claim Guard·Deadline Radar를, DADAERP(일반)는 Auto-Journal·Approval Flow를, SIEM·CMS도 같은 코어 위에서 동작합니다.
제품마다 다시 만드는 게 아니라, 한 코어 위에 필요한 구성을 얹는 것뿐입니다.
출처: src/lib/site.ts products · automationModules · 플랫폼 아키텍처 P4.
같은 시스템이 현장에 따라 어떻게 달라지는지, 직접 경험해 보세요.
에디션 스위처에서 같은 코어에 자동화를 바꿔 가며 켜 볼 수 있습니다.
같은 토대 위에서 조합만 달라지는 모습을, 한 화면에서 직접 확인하실 수 있습니다.
우리 회사에도 맞을지, 부담 없이 먼저 물어보세요.