G7 작업 관리 확장 모듈 - Glitter Tasks

개요

Glitter Tasks 0.13.0

Create → Assign → Track → Complete

쉽게 말하면,

“해야 할 일을 만들고 → 담당자를 정하고 → 진행 상태를 관리하고 → 완료까지 추적한다.”

라는 구조입니다.

왜 만들었나

G7에는 게시판, 페이지, Hook, Queue, Permission 같은 여러 기반 기능이 있습니다.

그런데 실제 사이트를 운영하다 보면 콘텐츠와 자동화만으로는 처리하기 어려운
사람이 직접 수행해야 하는 작업도 계속 생깁니다.

예를 들면,

• 운영자가 처리해야 할 일이 생긴다.
• 특정 회원이나 관리자에게 작업을 맡기고 싶다.
• 작업의 우선순위를 정하고 싶다.
• 언제까지 처리해야 하는지 기록하고 싶다.
• 지금 진행 중인지 완료됐는지 확인하고 싶다.
• 어떤 작업이 누구에게 할당되어 있는지 확인하고 싶다.

이런 요구를 게시판이나 메모 기능에 억지로 섞기보다는,

사람이 수행하는 운영 작업을 별도의 Task 도메인으로 관리하는 계층

을 하나 두는 것이 낫다고 생각했습니다.

그 결과가 Glitter Tasks입니다.

기본 구조

Task 하나는 크게 다음 요소로 구성됩니다.

1. Task

실제로 처리해야 할 작업입니다.

Task에는 기본적으로 다음 정보가 있습니다.

• 제목
• 설명
• 상태
• 우선순위
• 생성자
• 담당자
• 마감일
• 시작 시각
• 완료 시각

현재 상태는 다음 네 가지입니다.

• open
• in_progress
• completed
• cancelled

우선순위는 다음 네 단계입니다.

• low
• normal
• high
• urgent

Task 생성 시 상태는 항상 open, 우선순위는 기본적으로 normal에서 시작합니다.

2. Assignment

Task는 생성 후 특정 사용자에게 할당할 수 있습니다.

현재는 복잡한 팀 단위 할당이나 여러 명의 공동 담당자 구조 대신,

Task 하나당 한 명의 assignee

를 두는 단순한 구조입니다.

지원하는 동작은 다음과 같습니다.

• 할당
• 재할당
• 할당 해제

open 또는 in_progress 상태에서만 변경할 수 있으며, 이미 completed 또는 cancelled 된 Task의 담당자는 변경할 수 없습니다.

동일한 사용자에게 다시 할당하거나, 이미 비어 있는 Task를 다시 해제하는 경우는 정상적인 no-op으로 처리합니다.

3. Lifecycle

Task 상태 변경은 정해진 흐름을 따릅니다.

대략적인 흐름은 다음과 같습니다.

open
 │
 ├── start ──────────────▶ in_progress
 │                           │
 │                           ├── complete ──▶ completed
 │                           │
 │                           └── cancel ────▶ cancelled
 │
 └── cancel ─────────────▶ cancelled

지원하는 lifecycle operation은 다음 세 가지입니다.

• start
• complete
• cancel

반대로 다음 동작은 제공하지 않습니다.

• completed → reopen
• cancelled → reopen
• open → completed 직접 전이

상태 변경은 expected status 조건과 함께 저장하여, 동시에 여러 요청이 들어왔을 때 오래된 상태를 기준으로 덮어쓰는 문제를 줄이도록 했습니다.

관리자 화면

현재 관리자 영역에서는 Task를 직접 관리할 수 있습니다.

Task 목록

Task 목록에서는 다음 기준으로 필터링할 수 있습니다.

• 상태
• 우선순위
• 담당자 ID
• 미할당 여부
• 생성자 ID

목록 정렬은

created_at DESC, id DESC

방식으로 고정해서 결과 순서를 결정적으로 유지합니다.

페이지당 출력 개수도 제한된 범위 안에서 조정할 수 있습니다.

Task 생성

관리자는 새로운 Task를 만들 수 있습니다.

현재 생성 시 직접 입력하는 항목은 다음 정도로 제한했습니다.

• 제목
• 설명
• 마감일

상태, 생성자, lifecycle timestamp, 담당자 등은 생성 API에서 임의로 주입하지 않습니다.

Task 상세 / 수정

Task 상세 화면에서는 현재 상태와 담당자, 우선순위, 마감일 등을 확인할 수 있습니다.

수정 가능한 항목은 다음입니다.

• 제목
• 설명
• 우선순위
• 마감일

이미 completed 또는 cancelled 상태인 Task는 일반적인 상세 수정 대상에서 제외합니다.

Task의 상태나 담당자는 별도의 operation을 통해 변경합니다.

Assignment

상세 화면에서 다음 작업을 할 수 있습니다.

• 담당자 할당
• 담당자 재할당
• 담당자 해제

현재는 별도의 사용자 검색 UI를 붙이지 않고 사용자 ID를 직접 입력하는 구조입니다.

이 부분은 앞으로 사용성을 개선할 수 있는 영역으로 남겨두었습니다.

Lifecycle Operation

상태에 따라 가능한 동작만 노출합니다.

open에서는

• Start
• Cancel

in_progress에서는

• Complete
• Cancel

을 사용할 수 있습니다.

completed, cancelled 상태에서는 추가 lifecycle operation을 제공하지 않습니다.

Permission

Task 관리 기능은 하나의 포괄 권한으로 묶지 않고 역할별로 나누었습니다.

현재 사용하는 권한은 다음과 같습니다.

• glitter-tasks.tasks.read
• glitter-tasks.tasks.create
• glitter-tasks.tasks.update
• glitter-tasks.tasks.assign
• glitter-tasks.tasks.transition

기본적으로 admin, manager 역할에 필요한 권한을 부여합니다.

API와 관리자 화면 모두 이 권한 체계를 사용하며, TaskService 자체는 Permission에 종속되지 않도록 분리했습니다.

Admin API

관리자 화면은 별도의 저장 로직을 갖는 대신 기존 Admin API를 그대로 사용합니다.

현재 제공하는 API는 다음 범위입니다.

• Task 목록
• Task 상세
• Task 생성
• Task 상세 수정
• Task 할당
• Task 할당 해제
• Task 시작
• Task 완료
• Task 취소

모든 API는 G7의 인증과 Permission 경계 안에서 동작합니다.

상태 충돌이나 stale write는 일반 validation 오류와 구분하여 처리합니다.

Task Operation Hook

0.12.0부터는 성공한 Task operation 이후 다른 확장이 반응할 수 있도록 Hook을 제공합니다.

현재 제공하는 Hook은 다음 7개입니다.

glitter-tasks.task.after_create
glitter-tasks.task.after_details_updated
glitter-tasks.task.after_assigned
glitter-tasks.task.after_unassigned
glitter-tasks.task.after_started
glitter-tasks.task.after_completed
glitter-tasks.task.after_cancelled

이 Hook은 Task 동작을 가로채거나 승인하는 용도가 아니라,

성공한 operation 이후 다른 확장이 후속 처리를 할 수 있도록 알리는 extension point

입니다.

예를 들어 다른 모듈에서

• 알림 처리
• 외부 시스템 전달
• Workflow 연결
• 통계 수집
• 별도 기록

같은 기능을 구현할 때 활용할 수 있습니다.

다만 현재 Hook 자체는 durable event store나 outbox가 아닙니다.

Queue 실패, 재시도, 중복 실행 가능성이 있기 때문에 exactly-once delivery를 보장하지 않습니다.

Activity Log

0.13.0에서는 기존 Task operation Hook을 G7 전역 Activity Log에 연결했습니다.

다음 작업이 성공하면 Activity Log에 기록할 수 있습니다.

• Task 생성
• Task 상세 수정
• Task 할당
• Task 할당 해제
• Task 시작
• Task 완료
• Task 취소

별도의 Task History 테이블을 새로 만드는 대신,

G7에 이미 존재하는 Activity Log를 활용하는 방식

을 선택했습니다.

기록에는 필요한 최소한의 scalar metadata만 남기고, 다음과 같은 정보는 의도적으로 복제하지 않습니다.

• Task 전체 payload
• description 전체 내용
• metadata
• source reference
• 민감한 객체 상태

Activity Log는 운영 추적을 위한 best-effort 기록입니다.

영구 보존되는 immutable audit trail이나 Tasks 자체의 authoritative history로 사용하도록 설계한 것은 아닙니다.

G7 기능을 다시 만들지 않는 방향

Glitter Tasks를 만들면서 중요하게 본 원칙 중 하나는

G7에 이미 존재하는 기능을 Tasks 안에서 다시 만들지 않는다

였습니다.

가능하면 기존의

• Module Lifecycle
• Permission
• User
• Hook
• Queue
• Activity Log
• JSON Layout
• Admin Routing
• API Middleware

등을 그대로 사용하고,

Glitter Tasks는

Task라는 도메인과 그 상태 변화를 관리하는 역할

에 집중합니다.

그래서 별도의 Task 전용 인증 시스템이나 Activity Log 시스템을 다시 만들지 않았습니다.

Workflow와의 관계

Glitter Tasks는 Glitter Workflow 없이도 독립적으로 사용할 수 있습니다.

두 모듈의 역할은 다릅니다.

Glitter Workflow는

이벤트가 발생했을 때 조건을 평가하고 Action을 실행하는 자동화 계층

이고,

Glitter Tasks는

사람이 수행해야 하는 작업을 생성하고 담당자와 상태를 관리하는 작업 관리 계층

입니다.

현재 0.13.0에서는 두 모듈이 직접 연동되어 있지 않습니다.

향후 연결할 경우에도 서로의 내부 구현을 직접 참조하기보다는 공개 Hook이나 공식 extension point를 사용하는 방향을 유지하려고 합니다.

일부러 넣지 않은 기능

Task 관리라고 하면 기능을 계속 붙이고 싶어집니다.

하지만 처음부터 프로젝트 관리 시스템 전체를 만들기보다는, 기본 Task 모델과 lifecycle을 먼저 단단하게 만드는 쪽을 선택했습니다.

그래서 현재는 다음 기능을 제공하지 않습니다.

• Task 삭제
• Member/Public Task UI
• 사용자 검색 및 자동완성
• 알림
• Workflow 직접 연동
• Task 전용 durable history
• Comments
• Attachments
• Subtasks
• Recurring Tasks
• Projects
• Teams
• Kanban
• SLA
• Approval Workflow
• 고급 검색
• overdue 전용 실행 로직

구현 방법을 몰라서 제외한 것보다는, 각 기능의 권한과 상태 경계를 먼저 정의해야 한다고 본 경우가 많습니다.

특히 Task 삭제나 durable history는 한번 공개하면 이후 데이터 의미를 바꾸기 어렵기 때문에 초기 버전에는 넣지 않았습니다.

독립적인 Task 도메인

Glitter Tasks는 게시판을 Task 저장소로 사용하지 않습니다.

별도의 glitter_tasks 테이블을 소유하고, Task 상태와 assignment lifecycle을 독립적으로 관리합니다.

다른 확장과 연결할 수 있도록 source reference를 위한 구조는 두되, 외부 모듈 테이블에 Foreign Key를 직접 만들지는 않습니다.

대략적인 구조는 다음과 같습니다.

Task
 │
 ├── Creator
 ├── Assignee
 ├── Priority
 ├── Lifecycle
 ├── Due Date
 │
 ├── Extension Hooks
 │
 └── G7 Activity Log

Glitter Tasks가 Task 상태의 기준을 소유하고, 다른 기능은 필요한 경우 공개된 extension point를 통해 연결하는 구조입니다.

현재 규모

0.13.0 기준 현재 공개 소스는 대략 다음 구성입니다.

• 전체 공개 파일: 53
• Database migrations: 2
• Admin API routes: 9
• Admin layouts: 4
• Task operation hooks: 7
• Permissions: 5

초기 버전이라 기능 수를 크게 늘리기보다는 Task lifecycle, assignment, Admin API/UI, extension hook, Activity Log까지 하나의 기본 흐름으로 연결하는 데 집중했습니다.

G7에 집중한 작업 관리

Glitter Tasks는 Jira나 Asana 같은 범용 프로젝트 관리 플랫폼을 만들려는 모듈은 아닙니다.

대신,

G7이라는 애플리케이션 안에서 운영 중 발생하는 사람의 작업을 예측 가능한 상태와 권한으로 관리하는 것

에 초점을 맞추고 있습니다.

사이트 운영 과정에서 생기는 작은 업무를

Create
  ↓
Assign
  ↓
Track
  ↓
Complete

흐름으로 관리하고,

필요할 경우 Hook을 통해 다른 G7 확장과 연결할 수 있는 가벼운 Task layer를 목표로 하고 있습니다.

0.13.0

이번 0.13.0을 첫 공개 버전으로 배포합니다.

현재 production 환경에서도 동일한 0.13.0을 기준으로 운영 검증했으며, bundled source / installed module의 버전을 일치시킨 상태에서 최종 release baseline을 잡았습니다.

다만 production DB와 격리된 테스트 환경임을 증명할 수 없는 테스트는 운영 데이터를 보호하기 위해 실행하지 않았습니다.

초기 버전인 만큼 아직 부족한 부분도 많습니다.

특히 사용자 검색, 알림, member-facing UI, Workflow 연동 같은 기능은 앞으로 확장할 여지가 있습니다.

기능 수를 빠르게 늘리기보다는 Task의 상태와 assignment, concurrency, permission 경계를 유지하면서 하나씩 추가해 볼 생각입니다.

Glitter Tasks 0.13.0
Task Management for Gnuboard7

작은 할 일을 기록하고,
담당자를 정하고,
끝날 때까지 관리해 보는 모듈입니다.

요구 사항

• GnuBoard7 >= 7.0.11
• PHP >= 8.2
• Laravel 12 compatible environment
• MariaDB

별도의 필수 모듈 또는 플러그인은 없습니다.

관리자 페이지에서 설치

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

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

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

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

설치가 완료된 후 Glitter Tasks 모듈을 활성화하면 관리자 영역에서 작업 관리 기능을 사용할 수 있습니다.

2. ZIP 패키지 설치

GitHub Release에서 ZIP 패키지를 다운로드합니다.

• Glitter Tasks 0.13.0 ZIP 모듈 패키지를 다운로드

ZIP 패키지를 다운로드한 후

관리자 → 모듈 관리 → 수동 설치 → 파일 업로드

방식으로 설치할 수도 있습니다.

3. 설치 후 페이지 로드 오류 발생 시

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

를 실행한 후 다시 확인합니다.

저장소

GitHub

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

Release

https://github.com/glitter-node/glitter-tasks/releases/tag/v0.13.0

라이선스

MIT License.

Copyright (c) 2026 Glitter.kr

최적의 설치

이 버전은 ZIP 설치보다 GitHub 저장소 설치를 권장합니다.

G7 관리자에서 GitHub 저장소 URL을 이용해 설치하면 모듈 업데이트와 버전 관리 흐름을 유지하기 쉽습니다.

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