0jaaack / ppthub-server Goto Github PK

PPTHUB는 다른 PPT 파일을 비교하고 관리할 수 있는 웹 서비스입니다.

두 개의 PPT 파일을 비교해 다른 부분을 찾아내고, 원하는 데이터를 선택해 새로운 PPT 파일을 생성할 수 있습니다.

프로젝트 발표 영상

PPTHub 링크

• 📸 기능
• 🏔 챌린지
  • 🎯 PPT 파일을 어떻게 다룰까? - Parsing
    • Frontend와 Backend 중 어디에서 실행할 지 결정하기
    • PPT에서 View Data를 추출하기
  • 🎯 두 개의 PPT 파일을 어떻게 비교할 수 있을까? - Diffing
    • 변경 된 슬라이드를 감지하기
    • 처리하기 용이한 슬라이드 비교 데이터를 만들기
  • 🎯 어떻게-더-사용자를-편리하게-할-수-있을까
    • 마우스 hover 시 하이라이트 효과
    • 사이드바에서 slide 클릭 시 이동
    • Toast 메시지
• 🔥 이슈
  • ⚡️ 파일 데이터베이스 관리 이슈
  • ⚡️ 상태 관리 라이브러리 도입 이슈
  • ⚡️ 사용자 관리 이슈
• 👋 프로젝트 진행
• 🌐 기술 스택
• 🤝 회고

저희는 PPT 파일을 파싱해주는 라이브러리를 사용하지 않고 자체적인 Parsing 로직을 구현하였습니다.

우선 PPT(.pptx) 파일은 XML파일들이 모여있는 구조입니다. XML 파일 여러 개가 하나의 파일을 이루는데요.

XML은 HTML와 비슷하게 Tag를 열고 닫아 작성하는 Element의 구조입니다. 그래서 XML은 HTML처럼 DOM으로 사용할 수 있다는 장점이 있습니다.

XML을 Web API인 Dom Parser를 이용해서 Dom으로 Parsing하였습니다. 그 다음은 DOM API를 이용해 프로퍼티 및 자식 요소에 접근할 수 있었습니다.

PPT → XML DOM 기술 검증 과정

DOM Parser 등 Web API는 웹 브라우저 환경에서만 사용할 수 있습니다.

Node.js와 같은 환경에서는 별도로 문자열을 DOM으로 Parsing해주는 라이브러리를 설치해야만 했는데요.

단순히 HTML뿐 아니라 XML을 Parsing 해주는 다른 라이브러리를 알아보았지만 기존에 작성했던 Dom Parser로 작성된 코드를 전반적으로 수정해야 했습니다.

Node.js 써드파티 라이브러리 XML Parsing 기술 검증 과정

또 저희가 고려했던 점은, PPT를 Parsing하는 작업은 Client에서 실행되기에 너무 오래걸리는 작업이 아닐까 했던 것인데요.

우려했던 것과 달리 Client에서 Parsing하는 작업은 크게 오래 걸리지 않았습니다.

_{File unzip은 10ms 내, Parsing은 100ms 내로 작업이 진행되었습니다.}

PPT 파일은, PPT 파일의 압축을 해제하고 DOM Parser로 Parsing하는 과정으로 이루어져있습니다.

PPT 파일을 Parsing하는 작업이 오래 걸리지 않았던 이유는 파일 전체의 데이터를 가공하는 방식이 아닌, 특정 요소를 찾아 추출하는 방식으로 로직이 구성되어 있기 때문입니다. PPT 파일을 완전히 재현하는 것이 아니라, View 기능과 Diffing 기능을 위해서 추출하는 것이기 때문에 내부 구성요소의 정보를 담은 정보만 가져옵니다. 따라서 비교적 무거운 작업이 아니라고 판단하였고, Client 상에서 로직을 수행할 경우, 100ms 이하의 시간이 걸리는 것을 확인하였습니다.

파일 압축의 경우에도 파일의 크기에 따라 다를 수 있지만, Client에서 실행할 수 있는 범위 내라고 판단하였습니다. 따라서 PPT File Parsing은 Client에서 진행하게 되었습니다.

_{PPT 파일에서 Text 상자 XML 예시}

PPT 파일에서 보통 하나의 슬라이드마다 하나의 XML 파일을 가지게 됩니다. XML 파일 내부에는 슬라이드의 요소들과 그 정보들을 포함하고 있습니다.

내부 요소들은 각각의 유형에 맞게 Tag가 정의되어 있습니다. 예를 들어, Text의 경우 p:sp을, Image의 경우 p:pic 을 갖습니다.

각 Tag를 통해 어떤 구성요소인지 검사하고, 구성 요소에 맞게 내부 속성들을 추출합니다. 예를 들어 Text는 글자의 크기와 굵기, 색상, italic체와 같은 내부 속성을 가질 수 있습니다.

하지만 짧은 시간 내에 프로젝트를 완성하기 위해서는 모든 PPT의 구성요소를 Parsing 할 수 없었습니다.

하나의 구성 요소와 내부 속성들을 조사하고, 어떤 데이터를 Parsing해야 하는 지 알아보는 작업은 시간이 걸리는 작업입니다.

2주라는 제한된 개발 기간동안 개발을 마치기 위해서 일단 Text와 Image 데이터를 우선 Parsing하기로 결정하였습니다.

PPT 파일 View Data 추출 기술 검증 과정

두 개의 PPT를 비교하기 위해서는, 어떤 슬라이드가 변경되었는 지 감지해야 합니다. 하지만 그 기준을 정하는 것이 어려웠습니다.

하나의 슬라이드는 변경될 수 있고, 순서도 바뀔 수 있습니다. 비슷한 형식의 슬라이드가 여러 개가 반복될 수도 있게 됩니다.

처음에는 최소한의 일치율을 만족하는 경우를 생각했습니다. 그럴 경우 두 슬라이드를 매칭하여 비교할 수 있습니다.

다만 그렇게 되면 하나의 슬라이드가 다른 모든 슬라이드와 비교가 되어야 했고, O(n^2)의 시간복잡도를 갖게 됩니다.

시간복잡도도 높고 지나치게 코드의 복잡성이 높아지는 방향이라고 생각해 다른 방안을 찾게 되었습니다.

다른 방안은 슬라이드가 가진 고유한 값으로 비교를 하는 것입니다.

고유한 값을 가진 두 슬라이드만 비교하면 모든 슬라이드를 비교해줄 필요없이 O(n)의 시간복잡도로 문제를 해결할 수 있습니다.

다만 두 내용이 완전히 같은 슬라이드라도 id만 다르면 다른 슬라이드로 취급되는 단점도 있습니다.

이 경우는 조금 더 특수한 경우라고 생각되어 사용자가 이해할 수 있는 범위 내라고 생각했습니다.

저희가 정한 고유한 값의 조건은

• 기존 슬라이드가 복사되는 경우, 새로 부여되어야 합니다.
• 파일이 복사되는 경우, 그 값은 유지되어야 합니다.

였습니다. 여러 슬라이드 내부 데이터 중, 해당 조건에 부합하는 값(p:creationId)을 찾아내 매칭에 사용하였습니다.

Slide 비교 감지 기술 검증 과정

또, Set 자료구조를 이용해서 id를 비교할 때 O(1)의 시간복잡도로 찾을 수 있도록 작성하였습니다.

// 인자로 Set을 넣어 두 값을 비교하게 됩니다.
const {
  matchedIds,
  deletedIds,
  addedIds,
} = getMatchingIds(
  new Set(originItemsMap.keys()),
  new Set(compareItemsMap.keys()),
);

슬라이드를 비교할 때 가장 고려했던 것은 데이터의 구조입니다. 슬라이드 비교 데이터는

1. Diffing 로직이 진행될 때도 추가/변경하기 쉬운 구조여야하며,
2. 화면에 Rendering 되기에도 용이한 구조여야 합니다.
3. 나중에 Merge 작업이 이루어질 때도 사용하게 됩니다.

type SlideDiffData = {
  diff: "added" | "deleted" | "modified" | "none";
  isChecked: boolean;

  // value는 diff가 "modified"인 경우에만 유효한 property입니다.
  value?: {
    items?: {
      [itemId]?: {
        diff: "added" | "deleted" | "modified" | "none";
        isChecked: boolean;
      }
    }
  },
};

Diffing Data의 구조는 재귀적입니다. PPTDiffData > SlideDiffData > ItemDiffData의 구조로 반복됩니다. 그리고 특정 property는 조건에 따라 유효하게 됩니다.

예를 들어 SlideDiffData의 value 프로퍼티는 Slide 내부의 Diffing Data가 정의되어있는데요.

Slide 자체의 diff가 “added” 혹은 “deleted”, “none”이라면 value라는 property는 유효한 의미가 없습니다. 전체가 변경되었거나, 변경되지 않았기때문이죠.

_{슬라이드가 변경 된 경우, 변경된 item은 “added” 혹은 “deleted”라는 단순한 타입을 갖게 됩니다.}

이런 복잡할 수 있는 데이터 구조를 최대한 단순하게 작성하기 위해 노력하였습니다. 그 중 하나가 diff 라는 프로퍼티를 만든 것입니다.

이전에는 Slide가 “modified”인 경우, 변경 되기 전 item은 “modified-modified-before”와 같은 별도의 타입을 부여하였습니다. 하지만 처리해야하는 분기 수가 많아지고 더욱 복잡한 코드가 만들어지게 되었습니다.

그래서 모든 diff property를 통일해주었습니다. diff는 Slide 그리고 Slide의 구성요소(item) 둘 다에게 적용됩니다.

단순히 대상을 “added”, “modified”, “deleted”, “none”으로 나누었기 때문에 훨씬 효율적으로 처리할 수 있었습니다.

더 이상 “modified-modified-before”와 같은 추가 분기가 없어 단순하게 작업할 수 있기 때문입니다.

Merge 작업을 용이하게 하는 것도 고려하였습니다. Merge 작업은 사용자가 선택한 요소만을 조합해 합치게 됩니다.

처음 고려한 방안은 별도로 Merge Data를 만드는 것이나, 구현 단순화를 위해 Diff Data를 활용하였습니다.

Slide Data 혹은 Item Data 내부에 isChecked라는 boolean 프로퍼티를 만들어 분기처리를 가져가기 편하도록 만들었습니다.

PPT 파일을 보여주거나 편집할 때 사용자가 최대한 직관적으로 기능을 이해하길 원했습니다.

사용자가 Slide 내 구성 요소에 마우스를 올릴 때 다른 PPT에서의 해당 요소가 하이라이트 됩니다. 그리고 사이드바에서도 해당 요소가 하이라이트 되도록 했습니다.

사용자가 직관적으로 어떤 부분을 수정하는 지 시각적으로 전달하기 위해서입니다.

{
  [slideId]: {
    diff: "added" | "deleted" | "modified" | "none";
    isChecked: boolean;

    items: {
      [itemId]: {
        diff: "added" | "deleted" | "modified" | "none";
        isChecked: boolean;
        // isHovered property를 통해 Hover시 하이라이트를 나타냅니다.
        isHovered: boolean,
      },
    },
  },
};

이를 위해서 Rendering 시 데이터 구조를 위와 같이 나타냈습니다. 위의 Diff Data에서 isHovered라는 값이 추가 되었는데요.

같은 Diff Data 두 개의 Slide Viewer와 사이드 바로 모두 렌더링 되기 때문에, isHovered 값을 바꾸면 세 부분 다 렌더링이 바뀌게 됩니다.

사이드바에서 원하는 Item이나 Slide를 클릭하면 해당 위치로 이동하도록 하였습니다.

이를 위해서, 웹 내부에서 특정 리소스로 이동할 수 있는 Fragment 기능을 이용하였습니다.

각 슬라이드 영역 Element id가 지정 된 div 태그를 삽입하였고, 사이드 바에 href를 수정하도록 변경하였습니다.

// Slide Section 상단에 div slideId를 담은 div 태그를 삽입하였습니다.
<React.Fragment key={slideId}>
  <div id={`${slideId}-${fileType}`} />
  <SlideListSlideSection />
</React.Fragment>

// 클릭 시 해당 위치로 이동하게 됩니다.
onChange={() => {
  window.location.href = `#${slideId}-PPT_DATA_TYPES/ORIGINAL_PPT_DATA`;
  dispatch(toggleItemChecked({ itemId: itemData.itemId, slideId }));
}}

사용자에게 프로세스가 진행되면서 생기는 메시지들은 Toast 메시지를 적극 활용하였습니다.

Toast 메시지는 한 곳에서 편하게 유저에게 내용을 전달할 수 있어서 편리하고, 유저도 직관적으로 이를 알 수 있습니다.

저희는 상태관리로 Redux-Toolkit을 사용하였는데요. 다만 Toast는 상태로서 관리되기 보다는 별도의 기능이라고 판단해 Redux를 쓰지 않고 작업하였습니다.

상태 관리 도구에 의존적인 기능을 만들고 싶지 않았기 때문입니다. 그래서 Context API와 Portal을 활용하게 되었습니다.

export function ToastProvider({ children }) {
  const [toastMessage, setToastMessage] = useState("");

  const showToastMessage = useCallback(
    // Toast 메시지는 2초 후에 사라집니다.
    (message) => {
      if (message === toastMessage) {
        return null;
      }
      
      setToastMessage(message);

      setTimeout(() => {
        setToastMessage("");
      }, 2000);
	
      return null;
    },
    [toastMessage],
  };

  const isShowToast = toastMessage !== "";

  return (
    <ToastContext.Provider value={showToastMessage}>
      {children}
      {isShowToast && (
        // Portal을 통해 안정적으로 Toast 메시지를 Rendering합니다.
        <ToastPortal>
          <TostMessageBubble>
            <Message>{message}</Message>
          </TostMessageBubble>
        </ToastPortal>
      )}
    </ToastContext.Provider>
  );
}

• 고화질 사진 등 용량이 큰 PPT의 데이터를 모두 MongoDB에 저장할 수 없는 이슈가 발생하였습니다.
• MongoDB의 정책 상, document 하나의 크기가 최대 16MB로 제한됩니다.
• 만약 16MB가 넘는 파일은 저장할 수 없게 됩니다.

• 데이터를 압축해서 DB에 저장하자는 의견이 논의되었습니다.
• 하지만 데이터를 압축, 해제하는 과정에서 추가적인 시간이 소모될 것이라 판단하였습니다.

• 각각 개별 슬라이드를 저장하여, PPT Data에서는 Slide Id 정보를 관리하는 방안이 논의되었습니다.
• Slide들을 개별적으로 저장하는 방안 역시 많은 양의 Slide들이 들어가면 컬렉션 자체 용량을 초과하는 리스크가 있었습니다.
• 하지만 데이터의 만료시간을 설정해, 효율적으로 용량을 관리하도록 결정하였습니다. CronJob으로 스케쥴 관리를 해서 주기적으로 데이터를 삭제하도록 결정하였습니다.

• 각각 개별 슬라이드를 저장할 수 있는 PPTSlide 컬렉션을 두어 PPT 컬렉션에 해당 슬라이드 document들의 id들을 두는 방안으로 결정하였습니다.
• 각 데이터들은 다대다 관계를 형성하게 됩니다. 이 후 데이터를 불러올 때, populate 메소드를 이용하여 전체 PPT 데이터를 불러오도록 결정하였습니다.

MongoDB 데이터 저장 이슈

• 하나의 Diff data를 슬라이드 뷰어에서도, 우측 Selection Bar에서도 공통적으로 사용하면서 전역 상태 관리 라이브러리 도입의 중요성을 느끼게 되었습니다.

• React-query와 Recoil을 활용하는 방안이 논의되었습니다.
• 서버 상태 관리를 react-query를 사용하여, data를 항상 최신 상태로 관리할 수 있습니다.
• 그리고 PPT 슬라이드 데이터가 지나치게 많은 경우 로딩 시간이 길 수 있으므로 pagination 기능을 활용해 볼 수 있었습니다.
• 클라이언트 상태 관리 라이브러리는, Recoil을 사용하여 비교적 사용법이 간단하고, 무겁지 않은 라이브러리를 사용하는 방안으로 논의가 이루어졌습니다.
• 다만 react-query를 사용할 정도로 항상 최신의 상태를 유지할 데이터가 아니라는 점, pptx 파싱을 클라이언트에서 직접 수행하여 pagination을 사용할 일이 없던 것이 단점이었습니다.
• 현재 문제가 발생한 부분은 DiffData의 전역 상태 관리이므로, 이에 집중한다면 Recoil이 적합한 라이브러리인가에 대한 의문이 있었습니다.

• 그 다음은 Redux를 활용하는 방안이 논의되었습니다.
• Redux의 flux 패턴을 상태관리에 활용해볼 수 있었습니다. 하나의 DiffData는 Slide를 check/uncheck 해주는 액션과 요소를 chekck/uncheck 해주는 액션을 통해, DiffData를 관리할 수 있다고 판단하였습니다.
• 그리고 check 상태 뿐아니라, hover와 같은 추가적인 기능도 액션을 추가하여 용이하게 관리할 수도 있다고 판단하였습니다.
• Redux는 타 상태 관리 라이브러리와 비교해, 불필요한 boilerplate 코드가 있는 편이라 redux-toolkit을 사용하는 부분을 검토하였습니다. reducer들과 액션 생성함수를 번거롭게 만들 필요가 없이 자체 메서드로 간단하게 작성할 수 있었습니다.

• Redux를 이용해 전역 상태를 관리하였습니다.
• redux-toolkit의 사용으로 boilerplate 코드 작성을 줄일 수 있도록 결정하였습니다.

상태관리 라이브러리 필요성 및 선택 이슈

• 프로젝트에 사용자 관리를 어떻게 할 것 인지에 대해 논의가 발생하였습니다.

• 로그인 기능을 추가하여 더 많은 기능을 제공하는 방안이 있습니다.
• 다만 한정적인 시간 내에 더 많은 기능들을 가져가게 되면서, 원래의 핵심 서비스의 완성도가 떨어질 수도 있습니다.
• 그리고 이슈가 논의되었던 시점 당시, 작성이 어느정도 진행되었던 mockup, 유저 플로우, api docs 등을 수정해야 해, 그만큼 프로젝트 진행이 지체될 수 있었습니다.

• 유저 로그인 기능을 넣지 않고, cookie를 발급하여 게스트 유저를 기억하는 방안이 있었습니다.
• 사용자가 접속 시, DB에서 만료시간이 짧은 유저 데이터를 생성해, 그 id값으로 유저를 기억하고 구분하도록 시도하려고 하였습니다.
• 위와 마찬가지로 핵심 서비스에 대해서 완성도가 떨어지게 될 수 있으며, 유저 관리 방안에 대한 조사 및 기술 구현이 충분치 않다는 단점이 있었습니다.

• 로그인 혹은 내 파일보기 기능을 넣지 않고, download page 링크를 따로 가질 수 있게 하는 방안도 제시되었습니다.
• 사용자는 url 정보를 갖고 있으면, 언제든지 파일들을 다시 다운로드 받을 수 있도록 하였습니다.
• 유저 관리에 대한 DB 추가내용 작성 및 부수적인 기능 구현보다, 본 프로젝트 내용에 집중할 수 있게 됩니다.

• 로그인 기능을 제외하는 대신, download page url을 통해 작업한 파일을 기억할 수 있게 하였습니다.
• 유저를 기억하여 작업했던 파일들을 저장해 보여주는 기능을 가져가지 못하였지만, 다른 사용자와 공유하거나 url로 저장할 수 있게 기능을 도입하도록 결정하였습니다.
• ‘작업한 파일을 다시 내려받을 수 있게 한다.’라는 원래의 아이디어 목표를 가져가면서, 기능을 거의 추가하지 않을 수 있었습니다.
• 그에 따라서 부가적인 부분에 대한 기능 수고를 덜 수 있게 되었고, 핵심적인 기능 개발에 집중할 수 있게 되었습니다.

유저 로그인 기능 추가 이슈

• 아이디어 기획, 목업 작성, 애자일 스프린트 플랜 : 1주
• 프로젝트 개발, 배포, 테스트 : 2주

[Mockup][]

• 아이디어 기획
• 기술 스택 검토
• Mockup 설계
• MongoDB를 이용한 데이터베이스 Schema 설계
• Agile Sprint 기반의 테스크 매니지먼트

JavaScript, React, Redux, Redux Toolkit, styled-components

Node.js, Express.js, MongoDB & Mongoose, Amazon S3

Jest, SuperTest, Cypress

Netlify, AWS Elastic Beanstalk