그누보드7 폼 관리 모듈 - Glitter Form Builder

개요

최근 그누보드7용 glitter-form_builder 모듈을 개발하고 있습니다.

처음에는 단순히 폼을 쉽게 만드는 Form Builder를 만들려고 했습니다.

하지만 개발을 진행하면서 중요한 것은 "폼을 만드는 기능"이 아니라
폼이 생성되고, 운영되고, 제출되는 전체 과정이라는 생각이 들었습니다.

운영 중인 신청서를 수정한다고 가정해 보겠습니다.

이미 제출된 데이터까지 함께 바뀌면 안 되고, 공개 페이지와 관리자 화면이 서로 다른 구조를 사용한다면 유지보수도 점점 어려워집니다.

그래서 glitter-form_builder는 처음부터
Form을 하나의 Canonical Schema로 정의하는 방식으로 설계했습니다.

Canonical Schema란?

사용자가 화면에서

• 이름
• 이메일
• 개인정보 수집 동의

같은 필드를 추가하면,

실제로는 화면이 저장되는 것이 아니라
Form을 설명하는 하나의 Canonical Schema가 만들어집니다.

예를 들면 이런 형태입니다.

{
  "key": "email_1",
  "type": "email",
  "provider": "glitter-form_builder",
  "contractVersion": "1.0",
  "label": {
    "ko": "이메일"
  },
  "required": false,
  "sensitive": true
}

각 Field는 모두 같은 구조를 가지며,

새로운 Field를 추가하더라도 동일한 Contract를 따르게 됩니다.

이 Schema는 어디에 사용될까요?

glitter-form_builder에서는 이 Schema 하나가 시스템 전체에서 사용됩니다.

처음에는 관리자에서 이 Schema를 생성합니다.

Designer

↓

Canonical Schema 생성

저장하면 Draft가 만들어집니다.

Designer

↓

Canonical Schema

↓

Draft 저장

게시(Publish)를 실행하면 이 Schema를 검증합니다.

Draft

↓

Schema Validation

↓

Publish

검증을 통과하면 변경할 수 없는 Published Snapshot이 생성됩니다.

그리고 공개 페이지는 이 Snapshot을 읽어 실제 Form을 화면에 그립니다.

Published Snapshot

↓

Public Form Rendering

사용자가 값을 입력하고 제출하면,

같은 Schema를 기준으로 입력값을 검증합니다.

Public Form

↓

Submission Validation

↓

Submission 저장

관리자가 제출 내용을 조회할 때도 다시 같은 Schema를 사용합니다.

예를 들어 데이터베이스에는

text_1 = 홍길동
email_1 = [email protected]
consent_1 = true

처럼 저장되어 있어도,

관리 화면에서는 게시 당시의 Schema를 이용하여

이름
홍길동

이메일
민감 정보로 가려졌습니다.

개인정보 수집 동의
동의

처럼 사람이 이해하기 쉬운 형태로 보여줍니다.

즉,

Designer, Publish, Public Form, Submission, 관리자 화면까지 모두 하나의 Schema를 기준으로 동작합니다.

Draft와 Publish를 분리했습니다.

운영 중인 Form을 바로 수정하면 서비스에 영향을 줄 수 있습니다.

그래서 모든 수정은 Draft에서 이루어지고,

Validate를 통과한 뒤 Publish를 해야만 공개됩니다.

Draft

↓

Validate

↓

Publish

↓

Published Snapshot

↓

Public Form

공개 페이지는 항상 Published Snapshot만 사용하기 때문에,

운영 중에도 안심하고 Form을 수정할 수 있습니다.

이전 Submission은 그대로 유지됩니다.

Form은 게시될 때마다 새로운 Revision이 생성됩니다.

Submission은 자신이 제출된 당시의 Revision을 함께 저장합니다.

따라서 나중에 Form 구조를 변경하더라도

이미 제출된 데이터는 당시 Form 기준으로 그대로 유지됩니다.

운영 환경에서 과거 데이터가 깨지지 않는 이유입니다.

현재 구현된 기능

현재는 다음 기능을 구현했습니다.

• Form Designer
• Draft 저장
• Schema Validation
• Publish
• Public Form
• Submission
• Submission Receipt
• 관리자 Submission 목록
• 관리자 Submission 상세
• Email Redaction
• Immutable Published Snapshot

최근에는 실제 브라우저에서

• Form 생성
• Draft 저장
• Publish
• Public Form
• Submission
• 관리자 Submission 조회

까지 전체 흐름을 검증했습니다.

앞으로

현재는 Form Platform의 기반을 완성한 단계입니다.

앞으로는

• File Upload
• 다양한 Field Provider
• Conditional Logic
• Notification
• Webhook
• 외부 시스템 연동

등을 추가하여 더욱 확장 가능한 플랫폼으로 발전시킬 계획입니다.

결국 glitter-form_builder는

**"폼을 만드는 도구"**보다,

**"폼을 하나의 Canonical Schema로 정의하고, 생성부터 제출까지 하나의 흐름으로 관리하는 플랫폼"**을 목표로 개발하고 있습니다.

기술 스택

• PHP 8.3+
• Laravel 12.x
• MySQL
• Laravel Sanctum
• TypeScript
• Vite

설치 방법

1. GitHub 저장소에서 설치 (권장)

관리자 → 모듈 관리 → 수동 설치 → GitHub

아래의 저장소 URL을 입력합니다.

https://github.com/glitter-node/glitter-form_builder

설치 완료 후 모듈을 활성화하면 반짝이 폼 관리 메뉴가 생성됩니다.

2. ZIP 패키지 설치

• ZIP 패키지를 다운로드 틀릭

Release에서 ZIP 패키지를 다운로드한 후
관리자 → 모듈 관리 → 수동 설치 → 파일 업로드를 통해 설치할 수도 있습니다.

다만 GitHub 저장소를 통한 설치 및 업데이트를 권장합니다.

3. 설치 후 생성된 페이지의 로드 에러 발생 시

관리자 → 환경설정 → 고급 → 캐시 모두 삭제

저장소

GitHub

https://github.com/glitter-node/glitter-form_builder

Release

https://github.com/glitter-node/glitter-form_builder/releases/tag/v0.3.16

최적의 설치

파일 업로드 설치보다 GitHub 저장소 설치를 권합니다.
현재 GnuBoard7 관리자에서 GitHub 저장소 URL만으로 설치 및 업데이트가 가장 편리합니다.
이 방식이 가장 권장되는 설치 방법입니다.

라이선스

MIT License.