아키텍처
VEXPLOR는 하나의 큰 프로그램이 아니라 역할별로 나뉜 여러 서비스의 묶음입니다. 사용자는 웹 화면 하나만 보지만, 그 뒤에서는 인증·설계·배포·워크플로우·AI·알림·현장 장비 연결을 각각 맡은 서비스가 함께 동작합니다. 모든 요청은 API 게이트웨이라는 하나의 입구를 거쳐 알맞은 서비스로 전달됩니다.
무엇인가
VEXPLOR는 캔버스에서 테이블·관계·화면·업무 흐름을 설계하면 그 설계가 실제로 사용할 수 있는 업무 시스템이 되는 노코드 플랫폼입니다. 이 일을 하나의 프로그램에 모두 넣으면 한 기능의 장애가 전체를 멈추고, 기능 하나를 고쳐도 전체를 다시 배포해야 합니다. 그래서 VEXPLOR는 기능을 역할 단위 서비스로 나누고, 서비스끼리는 정해진 API로만 대화하게 설계했습니다.
이 문서는 처음 보는 사용자가 「화면 뒤에서 무엇이 어떻게 움직이는가」를 이해하도록 구성 요소를 역할 이름으로 설명합니다. 설치·운영 정보는 다루지 않습니다.
구성 요소
1. 화면 (프론트엔드)
| 구성 요소 | 하는 일 |
|---|---|
| 메인 웹 앱 | 캔버스 디자이너, 배포된 업무 화면, AI 화면, 설정 화면을 모두 제공합니다. 사용자가 매일 사용하는 화면입니다. |
| 관리자 포털 | 플랫폼 운영자가 테넌트(고객사 단위 공간)·구독·공지·솔루션 프리셋을 관리하는 별도 화면입니다. |
| 문서 사이트 | 지금 읽고 있는 제품 문서입니다. |
2. 입구 (API 게이트웨이)
모든 화면 요청이 가장 먼저 도착하는 곳입니다. 게이트웨이는 직접 업무를 처리하지 않고, 아래 일을 한 뒤 요청을 담당 서비스로 넘깁니다.
- 보안 헤더와 교차 출처(CORS) 정책을 적용합니다.
- 테넌트별로 요청량을 제한해 한 고객사의 과도한 요청이 다른 고객사에 영향을 주지 않게 합니다.
- 로그인 토큰의 서명을 확인하고, 확인된 경우에만 「어느 테넌트의 누구인가」를 뒤쪽 서비스에 전달합니다.
- 응답하지 않는 서비스로 가는 요청은 오래 기다리지 않고 곧바로 「일시적으로 사용할 수 없음」으로 돌려줍니다.
3. 업무 서비스
| 서비스 (역할 이름) | 맡은 일 |
|---|---|
| 인증 서비스 | 회원가입·로그인·2단계 인증, 사용자·부서·역할·권한, 테넌트 정보 |
| 스키마 디자이너 서비스 | 캔버스 저장, 테이블·관계 정의, 스키마 버전 관리 |
| 코드 생성 서비스 | 캔버스 설계를 데이터베이스 테이블·API·화면·메뉴로 바꾸는 배포 작업, 배포된 테이블의 조회·저장 |
| 워크플로우 서비스 | 결재·승인 같은 업무 흐름의 정의와 실행 |
| 파이프라인 런타임 | 데이터 수집·가공·분석 파이프라인 실행 |
| AI 서비스 | AI 대화, 자연어 질의, 지식 그래프, 이상 감지·예측, 모델 관리 |
| 온톨로지 서비스 | 설비·자재·공정 같은 업무 객체와 그 사이의 인과 관계 관리 |
| 템플릿 서비스 | 템플릿 마켓과 문서 템플릿 |
| 알림 서비스 | 이메일·메신저·웹훅·화면 내 알림·문자 발송과 예약 작업 |
| Edge 게이트웨이 | 현장 설비·센서 연결과 데이터 수집 |
| 그룹웨어 서비스 | 전자결재·게시판·캘린더·근태 같은 협업 기능 |
| 커뮤니티 서비스 | 게시판형 커뮤니티 |
| 과금 서비스 | 구독 플랜과 사용량 |
| 관리자 서비스 | 관리자 포털의 테넌트·공지·프리셋 관리 |
| 시뮬레이션 서비스 | 시나리오 실행과 이벤트 재생 |
| 커맨드 센터 서비스 | AI 에이전트 운영 현황·승인 대기·위험 지표 요약 |
4. 데이터 저장소
| 저장소 (역할) | 담는 것 |
|---|---|
| 관계형 데이터베이스 | 플랫폼 데이터와, 배포로 만들어진 고객사별 업무 테이블 |
| 캐시 | 권한·조회 결과처럼 자주 읽는 값. 캐시가 없어도 기능은 동작하고 속도만 느려집니다. |
| 그래프 데이터베이스 | AI가 사용하는 지식 그래프(데이터 사이의 관계) |
| 벡터 검색 | 문서와 대화를 의미로 찾기 위한 임베딩 |
| 파일 저장소 | 업로드 파일과 문서 |
5. 공유 패키지
화면과 서비스가 함께 사용하는 정의를 한곳에 모아 둔 패키지입니다. 솔루션 템플릿, 배포 정책 규칙, 공통 타입이 여기에 있습니다. 브라우저에서 사용해도 안전한 부분과 서버에서만 사용하는 부분을 나누어 제공하기 때문에, 서버 전용 코드가 화면 쪽으로 섞여 들어가지 않습니다.
요청 하나가 처리되는 순서
사용자가 배포된 「작업지시」 화면에서 새 작업지시를 저장하는 경우를 예로 듭니다.
- 화면이 저장 요청을 보냅니다. 요청에는 로그인 때 받은 토큰이 붙어 있습니다.
- API 게이트웨이가 보안 헤더를 적용하고, 요청량 한도를 확인하고, 토큰 서명을 검증합니다.
- 검증에 성공하면 게이트웨이가 「테넌트 A의 사용자 B」라는 확인된 정보를 붙여 코드 생성 서비스로 요청을 넘깁니다. 화면이 직접 써 넣은 테넌트 정보는 받아들이지 않습니다.
- 코드 생성 서비스가 테넌트 A 전용 영역에 있는 작업지시 테이블에 데이터를 저장합니다. 이때 누가 저장했는지가 함께 기록됩니다.
- 저장과 함께 변경 전후 값이 감사 기록에 남습니다. 계산 필드 갱신이나 상태 전파처럼 테이블에 정의된 자동 처리 규칙이 있으면 같은 요청 안에서 함께 실행됩니다.
- 결과가 게이트웨이를 거쳐 화면으로 돌아옵니다.
AI 대화처럼 답이 조금씩 생성되는 기능은 스트리밍 방식으로 응답이 도착하는 대로 화면에 표시됩니다.
왜 이렇게 설계했나
| 설계 선택 | 이유 |
|---|---|
| 역할별 서비스 분리 | AI 서비스가 바쁘거나 멈춰도 업무 화면 저장과 결재는 계속 동작합니다. 기능 하나를 고칠 때 그 서비스만 다시 배포하면 됩니다. |
| 입구를 하나로 | 인증 확인, 테넌트 확인, 요청량 제한을 서비스마다 따로 구현하지 않고 게이트웨이 한 곳에서 일관되게 적용합니다. |
| AI 서비스는 별도 언어 환경 | AI 서비스는 데이터 분석·머신러닝 생태계가 풍부한 Python으로, 나머지 업무 서비스는 TypeScript로 만들었습니다. 각 영역에 맞는 도구를 사용하기 위해서입니다. |
| 설계 정의를 공유 패키지에 | 솔루션 템플릿과 배포 정책을 화면과 서버가 같은 정의로 읽으므로, 화면에서 보이는 것과 서버가 실제로 만드는 것이 어긋나지 않습니다. |
| 캐시는 보조 수단 | 캐시에 문제가 생겨도 기능이 멈추지 않고 데이터베이스에서 직접 읽습니다. |
실무 팁
서비스가 나뉘어 있으므로 AI 화면만 응답이 없고 업무 화면은 정상인 경우가 있습니다. 이때는 「일시적으로 사용할 수 없음」 안내가 표시됩니다. 잠시 뒤 다시 시도하고, 계속되면 관리자에게 어떤 메뉴에서 발생했는지 알려 주세요.
캔버스 설계(스키마 디자이너 서비스)와 배포 후 쌓이는 업무 데이터(고 객사별 테이블)는 다른 곳에 저장됩니다. 캔버스를 고쳐도 다시 배포하기 전까지 운영 중인 데이터와 화면은 바뀌지 않습니다.