Skip to content

boostcampwm-2024/refactor-web39-OctoDocs

This branch is 236 commits ahead of boostcampwm-2024/web15-OctoDocs:develop.

Folders and files

NameName
Last commit message
Last commit date
Feb 16, 2025
Feb 20, 2025
Feb 18, 2025
Feb 19, 2025
Nov 26, 2024
Dec 3, 2024
Feb 11, 2025
Feb 6, 2025
Jan 13, 2025
Feb 18, 2025
Feb 13, 2025
Feb 16, 2025
Feb 16, 2025
Feb 15, 2025
Jan 11, 2025
Feb 16, 2025
Nov 27, 2024
Feb 17, 2025

Repository files navigation

Sprint 33


Hits Group 112 (1) Group 83 (2)

🐙 서비스 소개
🗜️ 팀의 핵심 경험
⚙️ 프로젝트 구조
🍻 팀원 소개



🐙 Octodocs 서비스 소개


옥토독스,
협업을 위한
연결형 지식관리 툴


Group 117 (2)


🪡 연결형 지식 관리 툴

📢 마크다운, 이미지, 코드 등을 활용해서 간편하게 문서 작성이 가능합니다.
📢 작성한 문서들을 연결하고 배치하면서 새로운 아이디어를 쉽게 떠올릴 수 있습니다.

문서 작성과 연결 gif


👥 실시간 동시 편집 및 협업 툴

📢 에디터에서 간편하게 실시간 동시 편집이 가능합니다.
📢 작성된 문서들도 함께 연결하고 배치해 보며 우리 팀만의 구조를 만들어 볼 수 있습니다.

실시간 동시편집 gif


📮 워크스페이스 초대 가능

📢 우리 팀만의 워크 스페이스를 생성하고 팀원들을 초대할 수 있습니다.
📢 워크 스페이스의 공개 범위를 설정해서 누구나 참여할 수 있는 공간도 생성이 가능합니다.

워크스페이스 초대 gif




🗜️ Octodocs 팀의 핵심 경험

🗣️ 실시간 편집 구현 과정

실시간으로 여러 사용자가 동일한 문서를 편집할 때, 충돌 없이 동기화하는 것은 어려운 문제입니다. Octodocs 팀은 이를 직접 구현하는 대신 YJSSocket.IO를 결합하는 전략을 선택했습니다. 하지만 이 두 라이브러리를 통합하는 과정에서 예상치 못한 문제들을 어떻게 해결했을까요?

🔗 실시간 편집의 비밀, 지금 바로 확인하기


☄️ 데이터 흐름 변경

Octodocs 팀은 기존 RESTful API 기반 상태 관리를 버리고 YDoc 중심의 단일 Truth Source소켓 기반 단방향 흐름으로 전환했습니다. 이로 인해 모든 상태가 YDoc을 통해 일관되게 관리되고, 데이터 흐름도 간소화되었습니다. 기존 방식을 버리고 이 변화를 선택한 이유는 무엇일까요? 또한, 중복 관리와 데이터 충돌을 줄이기 위한 data flow 변화의 핵심은 무엇이었을까요?

🔗 데이터 흐름에 몸을 맡겨보기


🔑 워크스페이스 별 권한 부여

Octodocs 팀은 배포를 끝낸 사이트를 발표에 직접 이용하다가, 발표를 듣는 사용자들이 발표 자료를 멋대로 변경할 수도 있다는 걱정을 마주했고 사용자들이 워크스페이스별 권한을 관리할 수 있어야겠다는 결론을 내렸습니다. 하지만 워크스페이스에 초대를 하면 알림이 가는 시스템을 만들기에는 개발 기간이 얼마 남지 않은 상태였어요. Octodocs 팀은 어떻게 워크스페이스별 권한 관리를 구현하였을까요?

🔗 발표 자료 워크스페이스 접근 금지


🧨 Redis를 활용해 데이터베이스 부하 줄이기

실시간으로 문서를 동시에 편집하면 굉장히 많은 변경 사항이 발생합니다. 누군가 타이핑을 할 때마다 변경 사항들을 모두 데이터베이스에 반영하기에는 부하가 너무 발생했기에, Octodocs 팀은 redis를 도입하기로 결정했습니다. 어떤 지점에서 redis 도입을 결정했고, 어떻게 redis를 활용하고 있을까요?

🔗 Redis 같은 걸 끼얹나?


🐳 개발 환경, 배포 환경 및 CI/CD 개선해나가기

Octodocs 팀은 사용자 경험 향상은 물론, 일관된 코드 품질 유지와 개발자 친화적인 쾌적한 개발 환경 조성을 위해 많은 노력을 기울였습니다. 멀티 레포에서 모노레포로의 전환, GitHub Actions를 활용한 CI/CD 구축, Docker와 Docker Compose의 도입까지—우리는 어떤 변화를 거쳤을까요?

🔗 환경 개선의 여정 따라가기


🔄불필요한 리렌더링 개선

사용자가 자주 이용하는 페이지 리스트 기능이 매번 전체 페이지를 리렌더링하면서 사용자 경험을 저하시키고 성능 문제를 야기했습니다. 이 문제는 어떤 원인에서 비롯되었으며, 우리 팀은 어떤 접근 방식으로 해결할 수 있었을까요?

🔗페이지 리스트 렌더링 시 전체 리렌더링 발생 문제 개선


⚡ FCP, LCP 점수 개선하기

웹 페이지의 첫 인상을 결정짓는 중요한 지표인 FCP와 LCP가 각각 1.1초, 1.3초로 측정되었습니다. 우리 팀은 이 성능 지표를 1초 미만으로 단축시키는 목표를 설정하고, 이를 성공적으로 35% 이상 개선할 수 있었습니다. 이 성과는 어떻게 달성할 수 있었을까요?

🔗FCP(사용하지 않는 자바스크립트 줄이기), 🔗FCP(lazy loading), 🔗LCP(useSuspenseQuery)



⚙️ 프로젝트 구조

System Architecture

image (13)


Tech Stack

Category Stack

Common

Frontend

Backend

Deployment

Collaboration



🍻 팀원 소개

J097_민서진 J100_박경희 J162_유성민 J239_조배경
스크린샷 2024-10-29 오후 11 41 04 스크린샷 2024-10-29 오후 11 41 55 스크린샷 2024-10-29 오후 11 41 00 스크린샷 2024-10-29 오후 11 40 31
BE FE BE FE

About

문서들을 연결하는 순간, 새로운 영감이 태어난다! 🐙

Resources

Stars

Watchers

Forks

Packages

No packages published

Languages

  • TypeScript 93.3%
  • CSS 2.9%
  • JavaScript 2.7%
  • Other 1.1%