Structuring the Database: Building an AI Task System [Floxis #2]

개요

Floxis는 AI를 활용하여 자연어 입력을 구조화하고 작업을 관리하는 시스템으로, 본 기사는 향후 생산성 분석 확장을 염두에 둔 데이터 모델 설계와 데이터베이스 구조 재구성 과정을 설명한다.

주요 내용

• 코어 구조: Floxis 시스템은 tasks, statuses, categories, projects, task_status_logs의 다섯 가지 테이블로 구성된다.
• 데이터 모델 설계 원칙:
• 현재 상태와 이력을 분리하여 작업 경량화 및 분석 기능을 확보한다.
• statuses는 정의로만 저장하고 자유로운 상태 전환을 허용한다.
• categories와 projects는 독립적인 개념으로 다룬다.
• projects 단위에 categories를 적용하되, 독립적인 tasks도 허용한다.
• status_id를 진실의 단일 출처(single source of truth)로 삼고, completed_at은 보조적인 정보로 활용한다.
• 구조는 최소화하되 확장성을 유지한다.
• 설계 결정:
• 엄격한 상태 전환 미구현: 현실적인 작업 흐름의 비선형성을 고려하여, 엄격한 전환 제약은 순서 제약, 유효하지 않은 전환 처리, UI 복잡성 증가를 야기하므로 현재 상태와 이력 로그만으로 충분하다고 판단했다.
• 워크플로우 제약 미구현: 개인 작업 관리에 있어 워크플로우는 유연성을 저해하고 작업의 세분성에 크게 의존하며, 개인적인 사용에는 과도할 수 있다고 보아 상태 정의만으로 전환은 제약 없이 허용한다.
• 로그 기반 분석: 완벽한 워크플로우 대신 결과 기반 분석을 수행하며, 생성부터 최종 완료까지의 시간, 첫 "진행 중" 상태부터 완료까지의 시간 등을 로그에서 도출한다.
• 카테고리와 프로젝트의 연관성: Category는 작업 유형, Project는 노력의 단위로 구분하며, 프로젝트 내 작업의 카테고리 파편화 및 집계 어려움을 방지하기 위해 프로젝트 레벨 카테고리를 기본으로 한다.
• 카테고리 또는 프로젝트 없는 작업 허용: 모든 작업이 구조화될 필요는 없으므로, project_id와 category_id를 선택 사항으로 하여 구조화되지 않은 입력도 수용한다.
• 주요 규칙:
• projects.category_id는 null일 수 있으며, tasks.category_id는 독립적인 작업에만 사용된다. 프로젝트 ID가 설정되면 카테고리는 프로젝트에서 파생된다.
• tasks.status_id가 유일한 진실의 출처이며, 워크플로우 제약은 없다.
• completed_at은 상태가 'completed'일 때만 설정되며, 상태 변경 시 null로 재설정된다. 이는 현재 완료 상태를 나타내며, 히스토리와는 분리된다. status_id와 completed_at의 일관성은 트리거로 강제된다.
• task_status_logs는 상태 변경 시 새로운 레코드가 삽입되는 append-only 방식이며, 워크플로우 강제 대신 분석에 사용된다.
• 구현: 마이그레이션은 새로운 구조 추가, 기존 데이터 마이그레이션, 레거시 컬럼 제거의 세 단계로 진행되었다.

시사점

Floxis는 엄격한 워크플로우 제약 대신 "로그 우선, 제약 마지막" 접근 방식을 채택하여 유연성을 유지하면서 데이터 무결성을 데이터베이스 레벨에서 보장하는 설계로, 초기 단계 시스템의 적응성을 높이고 개인 생산성 관리에 대한 유연성을 제공한다.