배포 파이프라인
캔버스에서 배포 버튼을 누르면 설계도가 실제 업무 시스템이 됩니다. 이 과정은 DDL 생성 → DDL 실행 → API 생성 → UI 생성 → 메뉴/라우트 → 아티팩트 저장의 6단계로 진행되고, 배포 이력 화면에서 단계별 진행 상황을 볼 수 있습니다. 중간 단계가 실패하면 이미 끝난 단계를 역순으로 되돌려 어중간한 상태가 남지 않게 합니다.
무엇인가
캔버스는 설계도입니다. 테이블 노드에 컬럼을 정의하고 관계선을 그려도, 그 자체로는 데이터를 저장할 수 없습니다. 배포 파이프라인은 이 설계도를 읽어 다음을 자동으로 만듭니다.
| 만들어지는 것 | 설명 |
|---|---|
| 데이터베이스 테이블 | 테넌트 전용 데이터베이스 영역에 테이블·외래키·인덱스가 생성됩니다. |
| API | 테이블마다 조회·생성·수정·삭제를 처리하는 서버 코드가 템플릿으로 생성됩니다. |
| 화면 | 테이블마다 목록·상세·입력 화면과 검색 필터가 생성됩니다. |
| 메뉴와 화면 주소 | 사이드바 메뉴와 각 화면으로 가는 주소가 등록됩니다. |
| 생성 파일 기록 | 생성된 코드와 SQL, 그 시점의 스키마 스냅샷이 배포 기록으로 저장됩니다. |
배포 전 확인 -- 배포 정책
배포 요청은 바로 실행되지 않고 먼저 배포 정책을 통과해야 합니다. 정책은 「차단」과 「경고」 두 가지로 나뉩니다.
| 정책 | 종류 | 내용 |
|---|---|---|
| 동시 배포 수 제한 | 차단 | 구독 플랜별로 동시에 진행할 수 있는 배포 수가 정해져 있습니다. |
| 플랜별 테이블 수 제한 | 차단 | 구독 플랜이 허용하는 테이블 수를 넘으면 배포할 수 없습니다. |
| 데이터 손실 위험 | 차단 | 변경 내용을 분석해 기존 데이터가 사라질 위험이 있으면 배포를 막습니다. |
| 업무시간 외 배포 | 경고 | 운영 환경에 업무시간 밖에 배포하면 경고합니다. |
| 대규모 배포 | 경고 | 영향받는 테이블이 많은 배포는 관리자 승인을 권고합니다. |
6단계 진행 과정
배포 이력 화면에는 아래 6단계가 표시됩니다. 실제로는 단계 사이에 보조 작업이 함께 실행되는데, 어느 단계에 속하는지 함께 적었습니다.
- DDL 생성 -- 캔버스의 테이블·컬럼·관계를 읽어 테이블 생성 SQL(DDL)을 만듭니다. 시스템 사용자·부서를 참조하는 컬럼, 계층형(트리) 테이블의 상위 항목·정렬 순서 컬럼도 이때 함께 만들어집니다.
- DDL 실행 -- 만든 SQL을 테넌트 전용 데이터베이스 영역에서 실행합니다. 이어서 외래키 제약, 자동 채번 규칙, 기본 조직 구조가 준비됩니다. 새로 만든 테이블에는 데이터 변경을 자동으로 기록하는 감사 기능이 함께 연결됩니다.
- API 생성 -- 테이블마다 데이터 모델, 요청·응답 형식, 서비스 로직, 컨트롤러 코드를 템플릿으로 생성합니다.
- UI 생성 -- 테이블마다 목록 화면, 상세 화면, 입력 폼, 검색 필터를 생성합니다.
- 메뉴/라우트 -- 사이드바 메뉴와 화면 주소를 등록합니다. 현장용 POP 메뉴, 역할별 기본 권한, 캔버스에 그린 워크플로우, IoT 노드(데이터 소스·수집기·알람 규칙)도 이 무렵 등록됩니다.
- 아티팩트 저장 -- 생성된 파일과 배포 시점의 스키마 스냅샷을 저장합니다. 마지막으로 새 테이블 구조가 AI 지식 그래프에 반영됩니다.
배포가 끝나면 「모든 배포 단계가 완료되었습니다」 안내와 함께 배포된 화면·메뉴·차트·처리 화면 수가 표시되고, 사이드바에서 곧바로 새 화면을 열 수 있습니다.
새 테이블 구조를 AI 지식 그래프에 반영하는 작업은 배포를 막지 않도록 분리되어 있습니다. 이 작업이 늦어지거나 실패해도 업무 화면은 정상적으로 배포됩니다.
실패하면 어떻게 되나 -- 역순 되돌리기
어느 단계에서든 실패하면, 그 앞에서 이미 끝난 단계를 거꾸로 하나씩 되돌립니다. 예를 들어 UI 생성에서 실패하면 생성된 API를 지우고, 만든 테이블을 되돌리는 식입니다. 이런 방식을 사가(Saga) 패턴이라고 합니다.
| 배포 결과 상태 | 의미 |
|---|---|
| 완료 | 모든 단계가 성공했습니다. |
| 실패 (되돌릴 것 없음) | 첫 단계에서 실패해 바뀐 것이 없습니다. |
| 실패 (정리 완료) | 실패 뒤 앞 단계를 모두 되돌렸습니다. 배포 전과 같은 상태입니다. |
| 실패 (정리 일부 실패) | 되돌리는 중에도 오류가 있었습니다. 관리자 확인이 필요합니다. |
되돌리기는 단계마다 독립적으로 실행되므로, 한 단계의 되돌리기가 실패해도 나머지 단계의 되돌리기는 계속 진행됩니다.
다시 배포할 때 -- 변경분만 반영
이미 배포한 캔버스를 고친 뒤에는 변경사항 재배포를 사용합니다. 처음부터 다시 만들지 않고 바뀐 부분만 반영합니다.
- 마지막 배포 이후 바뀐 내용을 비교합니다. 변경이 없으면 「변경사항이 없습니다」로 끝납니다.
- 컬럼 추가처럼 구조를 바꾸는 SQL을 만들고, 컬럼 형식을 바꾸는 경우에는 기존 데이터가 새 형식으로 변환될 수 있는지 실행 전에 먼저 검사합니다.
- 데이터가 많은 테이블은 운영 중단을 줄이는 방식으로 구조를 변경합니다.
- 바뀐 부분에 해당하는 API와 화면만 다시 생성하고, 새 스키마 스냅샷을 저장합니다.
운영 데이터를 지키기 위해 배포된 테이블은 삭제할 수 없고, 구조 변경은 컬럼 추가만 허용됩니다. 이 규칙을 어기는 변경이 있으면 재배포가 차단됩니다.
왜 이렇게 설계했나
- 단계를 나눈 이유: 단계마다 진행률과 결과가 기록되므로 어디서 멈췄는지 바로 알 수 있고, 실패한 단계만 원인을 찾으면 됩니다.
- 역순 되돌리기를 둔 이유: 테이블은 만들어졌는데 화면은 없는 반쪽짜리 상태가 남으면 사용자가 알아차리기 어렵고 다음 배포도 꼬입니다. 실패하면 깨끗하게 원래대로 돌아가는 편이 안전합니다.
- 정책을 앞에 둔 이유: 데이터 손실처럼 되돌리기 어려운 결과는 실행 후에 고치는 것보다 실행 전에 막는 편이 확실합니다.
- 스냅샷을 남기는 이유: 배포마다 구조를 기록해 두면 무엇이 언제 바뀌었는지 추적할 수 있고, 이전 구조와 비교하는 근거가 됩니다.
실무 팁
캔버스에서 생성될 DDL을 미리 볼 수 있습니다. 미리보기는 캔버스 기준이고, 실제 배포 때는 서버가 정확한 DDL을 다시 생성합니다.
배포 뒤에는 컬럼 추가만 가능하므로, 핵심 테이블의 컬럼 이름과 형식은 첫 배포 전에 충분히 검토하세요.
배포 이력 화면에서 상태, 캔버스, 테이블 수, 소요 시간, 배포자, 생성 파일을 볼 수 있고, 최근 7일 성공률과 평균 소요 시간도 확인할 수 있습니다.