2️⃣ 2주차 발표 준비
erDiagram
PAGE {
int id PK
string title
jsonb content
}
NODE {
int id PK
float x
float y
}
EDGE {
int id PK
string fromPoint
string toPoint
string type
string color
}
PAGE ||--|| NODE : "has"
EDGE }o--|| NODE : "fromNode"
EDGE }o--|| NODE : "toNode"
- 데이터 구조의 복잡성
- 관계형 데이터베이스의 한계
week2-demo.mp4
데모 영상 요약
- DB에서 페이지 불러오기 (초기 화면)
- 페이지 수정 시 자동 저장 (우측 상단)
- 페이지 생성 시 노드 생성 (페이지 생성 버튼 클릭 시)
- 페이지 삭제 (페이지 삭제 버튼 클릭 시)
- 노드간 연결 (노드 간 연결 시)
안녕하세요
저는 옥토독스 2주차 발표를 맡게된 유성민입니다.
지금부터 옥토독스 발표를 시작하겠습니다.
우선 저희 프로젝트를 처음보는 분들도 계실테니 간단하게 프로젝트에 대해서 설명을 드리겠습니다.
지금 보고 계시는 화면이 저희 프로젝트에 대한 기능을 표현한 화면이예요
페이지를 여러 개 만들고 페이지끼리 이어서 연관 관계를 표현할 수 있어요
페이지를 클릭하면 해당 페이지의 상세 정보가 나오고 여기서 모두 함께 실시간으로 문서를 편집할 수 있습니다.
즉, 노션과 같은 실시간 협업 문서에 문서 간 관계를 시각화 한 프로젝트라고 보시면 됩니다.
먼저 저희의 협업 환경에 대해 말씀을 드리자면
저희는 기본적으로 git flow 전략을 사용했어요
dev 브랜치를 두고 필요한 기능이 생길 때마다 feature 브랜치를 파서 기능 구현이 끝나면 dev 브랜치로 PR을 날려 merge를 하는 방식입니다.
그리고 저희는 팀원들 간 코드 이해도를 높이기 위해 github rule을 적용해서 적어도 한 명 이상의 approve가 있어야 merge를 할 수 있도록 강제성을 부여했습니다.
그 다음으로 저희가 선택한 기술 스택에 대해 말씀드리겠습니다.
프론트엔드에서는 노드 간 연관 관계를 표현하기 위한 라이ㅏ브러리인 Reac flow, 텍스트 에디터 라이브러리인ㅇ Novel, server state를 관리하기 위한 Tanstack query, 상태 관리 라이브러리인 zustand, CSS 프레임워크인 Tailwind CSS를 선택했습니다.
백엔드에서는 서버 프레임워크인 NestJS, 객체와 테이블을 연결해주는 TypeORM, 관계형 데이터베이스인 PostgreSQL을 선택했습니다.
저희는 이번 주에 어떠한 데이터베이스를 선택하는 것이 좋을지 고민을 많이 했어요
저희 프로젝트 특징에 대해서 회의를 해 본 결과 가장 적절한 데이터베이스는 Postgres라고 판단을 했습니다.
우선 저희는 텍스트 에디터로 Novel을 사용하는데 단순 텍스트가 아닌 다양한 기능들을 제공해주기 때문에 데이터 형태가 JSON 형태였습니다.
데이터베이스에 JSON 형태로 저장할 필요성이 있었고 노드들 간 관계를 표현해줘야 했습니다.
mongoDB는 JSON을 저장하기 적합하지만 관계를 표현하기 어려웠고 mysql은 관계를 표현하기 적절했지만 JSON을 저장하기 적합하지 않았습니다.
그렇다고 graphDB를 사용할만큼 관계가 복잡하지도 않았습니다.
즉 관계를 표현하면서 JSON을 저장할 수 있는 데이터베이스가 필요했는데 그 데이터베이스가 바로 postgres였습니다.
기본적으로 관계형 데이터베이스이지만 JSON을 저장할 수 있어서 postgres를 선택했습니다.
이제 데이터 구조에 대해서 말씀드리겠습니다.
백엔드는 ERD를 통해 데이터베이스 설계를 진행했고 저희 프로젝트의 페이지 저장 방식은 방향성이 없는 그래프 구조를 선택했습니다.
처음에는 linked list 구조를 생각했었는데 저희 프로젝트 특성 상 linked list까지 사용할 필요는 없더라고요.
저희 프로젝트에서 엣지는 단순히 노드 간 연관 관계가 존재한다라는 것을 표현하기 때문에 순서라는 개념자체가 없었어요
이러한 점에서 linked list를 사용하면 데이터 구조만 복잡해지고 linked list의 이점을 챙기지 못한다고 생각을 해서 linked list를 사용하지 않았습니다.
linked list를 사용하지 않는다는 결론을 내리니 데이터 구조가 굉장히 간단해졌는데요.
물론 프로젝트를
EDGE라는 테이블을 따로 두고 여기서 연관 관계를 가지는 노드 정보만 넣어주면 됐습니다.
그리고 이를 UI에서 보여줄 때는 모든 노드를 가져와서 보여주고 모든 엣지를 가져와서 연결해주면 끝입니다.
네 여기까지 저희 팀이 선택한 데이터 구조였고요 이제 배포 환경에 대해 말씀드리겠습니다.
저희 팀의 프론트 배포 환경은 NCloud의 Object Storage를 사용했고 백엔드 배포 환경은 NCloud의 Server를 사용했습니다.
프론트는 리액트를 사용하고 있기 때문에 빌드를 한 뒤 생성된 정적 파일들을 Object Storage에 올리고 Object Storage에서 제공해주는 정적 웹 사이트 호스팅 기능을 사용해서 웹 사이트를 배포했습니다.
서버 구조는 호눅스님께서 마스터 클래스에 설명해주신 내용을 그대로 적용했습니다.
api 서버는 퍼블릭 서버에 올려서 외부 접근이 가능하도록 구성했고
데이터베이스는 private Server에 생성해서 publi server를 제외한 외부 접근을 모두 막았습니다.
그리고 CI/CD도 구현을 했는데요
github action을 통해 main에 push가 발생하면 가장 먼저 리액트를 빌드한 다음 정적 파일들 모두 Object Storage에 업로드를 합니다.
여기서 Objec Storage는 정적 웹 사이트 호스팅을 하고 있기 때문에 Object Storage에 업로드 한 순간 배포가 이루어졌다고 보실 수 있습니다.
그리고 백엔드 api 서버의 경우 쉘 스크립트 파일을 NCloud server로 보낸 뒤 실행하는 방식을 선택했습니다.
쉘 스크립트 파일 안에는 github의 최신 정보를 가져와서 nest 서버를 실행하는 코드가 담겨있습니다.
네 지금까지 백엔드 진행상황이었고요 프론트 진행 상황에 대해 말씀드리겠습니다.
프론트의 경우 핵심적인 요소들의 UI와 기능들을 구현했습니다.
사이드 바, 페이지 노드에 대한 기본 컴포넌트를 정의 했습니다.
그리고 novel을 사용하여 텍스트 에디터를 구현했고 react flow를 사용하여 노드 간 연결을 구현했습니다.
그리고 기본적인 CRUD API를 사용하여 노드 간 연결 관계, 페이지 상세 내용들을 데이터베이스와 연동했습니다.
구체적인 프론트의 작업 내용은 데모 영상을 보는 것으로 마무리 해보겠습니다.
네 지금까지 오토독스 팀이었고요 발표 마무리 해보겠습니다.
질문 있으신 분들은 자유롭게 해주시면 감사하겠습니다.