글리터 프로젝트 허브 - Glitter Project Hub

글리터 프로젝트 허브 - Glitter Project Hub입니다.

처음에는 프로젝트를 소개하는 페이지 정도를 생각했습니다. 프로젝트 이름과 설명, 저장소 링크, 현재 상태 정도를 보여주면 충분할 것 같았습니다.

그런데 프로젝트가 하나둘 늘어나고 시간이 지나면서 조금 애매해졌습니다.

지금 무엇이 있는지는 알겠는데, 이 프로젝트가 어떻게 여기까지 왔는지는 잘 남지 않았습니다.

어떤 결정을 했는지, 무엇을 구현했는지, 운영하면서 무엇을 발견했는지 같은 기록은 게시판이나 문서 여기저기에 흩어졌습니다.

프로젝트끼리의 관계도 마찬가지였습니다. 어떤 프로젝트가 다른 프로젝트에 의존하는지, 무엇을 포함하는지, 이전 프로젝트를 무엇이 대체했는지 같은 관계를 단순한 소개 페이지로 표현하기에는 점점 부족했습니다.

그래서 글리터 프로젝트 허브에서는 프로젝트를 하나의 게시물보다는 **하나의 노드(node)**에 가깝게 다루기 시작했습니다.

ProjectNode
 ├─ Showcase
 ├─ Stream Records
 └─ Relationships
      ├─ depends_on
      ├─ contains
      ├─ supersedes
      └─ documents

ProjectNode에는 프로젝트의 이름과 설명뿐 아니라 상태, 공개 여부, 쇼케이스 내용, 저장소 주소, 외부 링크 같은 정보가 들어갑니다.

여기까지는 어떻게 보면 조금 더 구조화된 프로젝트 디렉터리라고 할 수도 있습니다.

그런데 노드만 만들어 놓으니 또 하나가 빠져 있었습니다.

시간이었습니다.

프로젝트의 현재 상태만으로는 부족했습니다

프로젝트는 계속 변합니다.

어떤 구조를 선택하기도 하고, 기능을 구현하기도 하고, 실제로 운영해 본 뒤 예상하지 못했던 현상을 발견하기도 합니다.

그래서 이런 변화의 기록을 ProjectStreamRecord라는 별도의 데이터로 분리했습니다.

예를 들면 이런 것들입니다.

• 어떤 결정을 내렸다.
• 어떤 기능을 구현했다.
• 운영 중 어떤 현상을 관찰했다.
• 프로젝트에 어떤 변화가 생겼다.

일반적인 개발 일지와 비슷해 보이지만 조금 다른 점이 있습니다.

이 기록들을 긴 문서 하나에 계속 덧붙이는 대신 종류와 발생 시점, 공개 여부, 관련 경로를 가진 데이터로 저장합니다.

그러면 프로젝트 상세 화면에서 필요한 기록을 다시 조합할 수도 있고, 최근 활동만 따로 모아 보여줄 수도 있습니다. 시간이 지난 뒤에는 “이 프로젝트가 어떻게 변해 왔는가”라는 흐름도 다시 구성할 수 있습니다.

제가 글리터 프로젝트 허브에서 해보고 싶었던 것 중 하나가 바로 이것입니다.

프로젝트의 결과뿐 아니라 변화 과정도 데이터로 남길 수 없을까?

프로젝트가 늘어나니 관계도 필요했습니다

시간축을 만들고 나니 이번에는 프로젝트 사이의 관계가 눈에 들어왔습니다.

실제로 여러 프로젝트를 만들다 보면 각각이 완전히 독립되어 있지는 않습니다.

어떤 프로젝트는 다른 프로젝트를 포함하고, 어떤 것은 다른 프로젝트에 의존합니다. 이전 프로젝트를 새로운 프로젝트가 대체하기도 하고, 특정 프로젝트가 다른 프로젝트의 문서 역할을 하기도 합니다.

그래서 관련 프로젝트 URL 몇 개를 배열로 넣는 대신 관계 자체에도 의미를 부여하기로 했습니다.

contains, depends_on, supersedes, documents, related_to 같은 관계를 별도의 연결 정보로 저장합니다.

여기서 그래프(graph)라고 표현하고 있지만 그래프 데이터베이스를 사용한다는 뜻은 아닙니다. 관계형 데이터베이스에 프로젝트 사이의 연결을 저장하고, 서비스 계층에서 관계를 검증한 뒤 필요한 형태의 프로젝트 관계 정보를 만들어 사용하는 구조입니다.

이렇게 하다 보니 단순한 프로젝트 목록이 조금씩 프로젝트 생태계에 가까운 형태를 갖게 되었습니다.

이걸 Gnuboard7 위에 올렸습니다

글리터 프로젝트 허브는 Gnuboard7 7을 기반으로 하고 있습니다.

처음부터 Gnuboard7 코어를 직접 수정해서 별도의 시스템으로 만드는 방향은 피했습니다. 대신 Gnuboard7이 제공하는 확장 구조를 이용했습니다.

Gnuboard7 Core
 ├─ Module   : glitter-projects
 ├─ Plugin   : glitter-gdpr
 └─ Template : glitter-project_hub

glitter-projects 모듈은 프로젝트 노드와 운영 기록, 프로젝트 관계와 관련 API를 담당합니다.

glitter_project_hub 템플릿은 이 데이터를 실제 프로젝트 허브 화면으로 구성합니다.

glitter-gdpr 플러그인은 운영 과정에서 필요해진 개인정보 동의와 정책 이력을 별도의 기능으로 분리한 것입니다.

여기서 경계는 분명히 하려고 합니다.

인증, 권한, 게시판, 페이지, 검색, 기본 Layout Engine 같은 기반 기능은 Gnuboard7이 제공합니다.

글리터 프로젝트 허브는 그것들을 다시 만든 프로젝트가 아니라, Gnuboard7이라는 기반 위에 프로젝트라는 도메인과 운영 기록, 관계 구조를 추가한 프로젝트에 가깝습니다.

이렇게 나눈 이유 중 하나는 코어와 서비스 고유 기능의 경계를 유지하고 싶었기 때문입니다.

Gnuboard7이 업데이트되더라도 글리터 프로젝트 허브만의 기능은 module, plugin, template이라는 자기 영역에 남아 있도록 하는 구조를 지향하고 있습니다.

화면 구성도 조금 특이합니다

프론트엔드 쪽은 처음 보면 Laravel 프로젝트치고는 조금 낯설 수 있습니다.

대략 이런 흐름입니다.

Blade
  ↓
Core Template Engine
  ↓
Template Component Bundle
  ↓
JSON Layout
  ↓
API Data Source
  ↓
React Rendering

Blade가 기본적인 틀과 초기 구성을 담당하고, 실제 화면 구성은 JSON Layout과 React 컴포넌트가 맡습니다.

그래서 모든 화면을 Blade 파일에 직접 작성하는 전통적인 Laravel 방식도 아니고, 프론트엔드를 완전히 분리한 SPA 방식도 아닙니다.

서버에서는 Laravel과 Gnuboard7의 API·인증·확장 구조를 그대로 이용하면서, 사용자 화면에서는 JSON으로 레이아웃과 데이터 소스를 연결하는 중간 형태에 가깝습니다.

이 부분은 글리터 프로젝트 허브가 새로 만든 기능이라기보다는 Gnuboard7이 제공하는 Layout Engine을 실제 사용자 템플릿에서 적극적으로 활용한 부분입니다.

현재 glitter_project_hub도 이런 방식으로 홈, 프로젝트 상세, 검색, 게시판, 사용자 화면 등을 구성하고 있습니다.

만들다 보니 운영 문제도 기능이 되었습니다

처음에는 프로젝트를 어떻게 기록할 것인가가 중심이었는데, 실제 서비스를 운영하는 것을 생각하다 보니 다른 문제들도 자연스럽게 들어오기 시작했습니다.

그중 하나가 개인정보 동의였습니다.

처음에는 쿠키 배너 하나를 띄우는 문제처럼 보였습니다.

그런데 조금 더 들어가 보니 사용자가 무엇에 동의했는지만 저장해서는 부족했습니다. 언제 동의를 철회했는지, 어느 정책 버전에 동의했는지, 그 당시 정책 내용은 무엇이었는지도 기록할 필요가 있었습니다.

그래서 glitter-gdpr에서는 단순한 동의 여부만 저장하는 대신 정책 버전과 당시 정책 내용, 동의 변경 이력을 함께 관리하는 방향으로 만들고 있습니다.

물론 이것이 법적인 의미에서 GDPR 준수를 보장한다는 뜻은 아닙니다. 여기서는 운영에 필요한 동의와 정책 이력을 시스템 안에서 어떻게 데이터로 다룰 것인가에 초점을 맞추고 있습니다.

운영 환경도 조금 특이합니다.

글리터 프로젝트 허브는 별도의 개발용 Docker 환경을 두기보다 실제 운영 환경에서 개발과 운영을 이어가고 있습니다.

그러다 보니 확장 기능의 원본 소스와 실제 서비스에 적용되는 영역을 구분하고, 운영 환경에서 개발·디버그 기능이 노출되지 않도록 하거나 프론트엔드 자산과 캐시를 관리하는 문제도 자연스럽게 프로젝트의 일부가 되었습니다.

AI를 이용한 개발도 하고 있습니다.

다만 여기서 관심을 두고 있는 부분은 단순히 “AI에게 코드를 작성시킨다”는 것보다는 AI가 실제 운영 소스를 다룰 때 어디까지 수정할 수 있고, 무엇을 확인해야 하며, 어떤 작업은 해서는 안 되는지를 저장소의 규칙으로 만드는 것에 가깝습니다.

이 부분은 그것만으로도 이야기가 꽤 길어질 것 같아서 나중에 별도로 정리해볼 생각입니다.

아직 만드는 중입니다

글리터 프로젝트 허브는 완성된 제품을 발표하기 위한 프로젝트라기보다, 지금도 계속 만들어 가고 있는 프로젝트입니다.

프로젝트 노드와 운영 기록, 관계 모델, 공개 화면과 확장 구조는 어느 정도 형태를 갖췄지만 아직 계속 손보고 있습니다.

소스와 실제 서비스에 반영되는 프론트엔드 자산의 동기화를 확인해야 하는 부분도 있고, 실제 운영 환경에서 하나씩 검증해야 하는 부분도 남아 있습니다.

그래서 지금 단계에서는

“이런 프로젝트를 완성했습니다.”

보다는

“프로젝트를 이런 방식으로 기록해 보면 어떨까 해서 만들고 있습니다.”

가 더 정확한 설명일 것 같습니다.

처음에는 프로젝트 소개 페이지를 만들려고 했습니다.

그런데 만들다 보니 프로젝트의 현재 상태만큼이나 어떤 결정을 거쳐 지금의 모습이 되었는지, 그리고 다른 프로젝트와 어떤 관계를 맺고 있는지도 중요하다는 생각이 들었습니다.

결과물만 남기는 것이 아니라 그 프로젝트가 지나온 과정까지 하나의 데이터로 남긴다면, 몇 년 뒤에도 프로젝트의 맥락을 다시 따라갈 수 있지 않을까.

글리터 프로젝트 허브에서는 지금 그 방법을 만들어 보고 있습니다.