- 🔍 Preview
- 🌐 Tech Stacks
- 👋 Introduction
- 🔗 Links
- 📸 Feature
- 🏔 Challenges
- 🔥 Issues
- ⚡️ 사용자 관리 이슈
- ⚡️ 상태 관리 라이브러리 도입 이슈
- ⚡️ 파일 데이터베이스 관리 이슈
- 🎥 Execute
- 🤝 Memoirs
JavaScript, React, Redux, Redux Toolkit, styled-components
JavaScript, Node.js, Express.js, MongoDB & Mongoose, Amazon S3
Jest, SuperTest, Cypress
Netlify, AWS Elastic Beanstalk
- 아이디어 기획, 목업 작성, 애자일 스프린트 플랜 : 1주
- 프로젝트 개발, 배포, 테스트 : 2주
피피티 파일을 만들때 제일 중요한 요소 중 하나는 바로 디자인입니다. 내용을 효과적으로 전달하기 위해서 피피티 제작시에 어떤 디자인, 어떤 구성으로 전달을 해야지에 대해서 많은 시간을 들입니다. 이 디자인에 있어서 어떤 디자인이 마음에 드는지 비교하기 위해서 대부분 이러한 과정을 취할 것입니다.
비교할 슬라이더 내의 내용을 복사하고, 원본 슬라이더 안에 있는 내용을 삭제하고, 삭제할 자리에 비교할 내용을 붙여 놓고, 맘에 들지 않으면 되돌리는 작업.
하나의 내용을 비교하기 위해서 위와 같은 작업을 거의 진행을 해야합니다. 좀 더 좋은 디자인을 위해 피피티를 만드는 사람들은 많은 시간을 써야 합니다.
만약 이러한 작업을 한 화면 안에서 한번에 비교 해줄 수 있으면 피피티 만드는 사람에게 더 편해지지 않을까? 그리고 팀프로젝트에 있어서 서로 다른 피피티 디자인을 제작할 때 어떤 디자인이 더 예쁜지 한번에 확인 가능하지 않을까? 라는 생각을 하게되어 이 프로젝트를 기획하게 되었습니다.
- 아이디어 기획
- 기술 스택 검토
- MockUp 설계
- MongoDb를 이용한 데이터베이스 Schema 설계
- Agile Sprint 기반의 테스크 매니지먼트
- Git Repo를 Client [Frontend]와 Server [Backend]로 각각 구분하여 독립적으로 관리
- 사용자는 사이트에 확장자명이 .pptx인 PPT 원본 파일, 비교본 파일을 등록할 수 있습니다.
- 사용자가 원하지 않은 PPT를 등록했을 경우 되돌리기 버튼을 클릭하여 취소할 수 있습니다.
- 사용자는 원본 비교본에서 어떤 부분이 달라졌는지 한번에 확인이 가능합니다.
- 슬라이드가 추가되거나 삭제된 경우 : 슬라이드 전체에 빗금처리
- 슬라이드 안의 컨텐츠가 추가되거나 삭제 된 경우 : 슬라이드 내용 안에 처리
- 사용자는 자신이 원하는 내용만 PPT에 추가를 할 수 있습니다. EX) 추가 - 녹색, 삭제 - 빨강
- 사용자가 최종 선택 된 내용을 가지고 PPT를 새로 만들 수 있습니다.
- 사용자가 다운로드 페이지로 버튼을 누르게 되면 다운로드 페이지로 이동 및 링크가 클립보드에 저장이 됩니다.
- 다운로드 페이지에서 새로 만들어진 PPT를 다운로드 받을 수 있으며 하루 동안 클립보드에 저장 된 링크로 다운로드 페이지로 이동해 파일을 다운 받을 수 있습니다.
 |
 |
|---|---|
| 메인 페이지 | 준비 화면 |
 |
 |
|---|---|
| 선택 화면 | 다운로드 페이지 |
- .pptx 파일은, 각 xml 파일들이 모인 하나의 디렉토리가 압축된 파일로 구성되어 있습니다.
- xml은, html과 마찬가지로 element로 구성되어 있으며, 자식 - 부모 관계로 이루어져 있습니다.
- xml에 접근하기 위해, xml 데이터를 문자열화해서 그대로 해석해거나 html처럼 DOM으로 데이터에 접근할 수 있는 방안이 있었습니다.
- 하지만 DOM으로 접근하는 것이 조금 더 친숙하면서 용이한 방식으로 생각되어 해당 방식을 사용하였습니다.
- DOM으로 다루기 위해서, 문자열화 된 xml data를 javascript의 DOMParser(parseFromString method)를 이용하여 DOM 객체로 변환하였습니다.
- DOM으로 접근할 시, querySelector 및 querySelectorAll 과 같은 DOM method를 사용하기 용이하였습니다.
- 기존에 존재하는 .pptx 및 XML Parsing 라이브러리 대신, 저희의 자체 parsing을 구현하기 위해서 서버(nodejs)가 아닌 클라이언트(browser) 환경에서 parsing을 구현하게 되었습니다.
- 각 슬라이드마다 하나의 xml 파일을 가지며, 내부의 요소들과 그 정보들을 포함하고 있습니다.
- 내부 요소들은 각각의 tag 이름으로 정의되어 있습니다. 예를 들어, Text Box의 경우
p:sptagName을, 이미지의 경우p:pictagName을 갖습니다. - 각 요소 마다 내부의 속성값이 달라, 공통된 속성값을 제외한 각 개별 속성값을 구분하여 추출하였습니다. Text Box 요소의 경우, Text Box 고유의 속성(text 내용, 굵기, 색상, italic 등)을 가지고 있어 내부 요소를 구분합니다.
- 각 요소에 대해서 원하는 데이터를 추출하는 경우, 각 요소마다 특정 속성들을 파악해 이를 데이터화하여 표현해야합니다.
- 그러나 PPT 파일의 모든 수많은 요소들(텍스트, 이미지, 도형, 그래프 등)에 대해 이와 같은 작업을 진행하기는 시간 문제 상 불가능하다고 판단하였습니다.
- 그리하여 가장 기본적인 요소인, 텍스트와 이미지 요소만을 추출하는 것으로 프로젝트를 진행하게 되었습니다.
- 저희가 diffing에서 가장 고심하였던 부분은, 두 개의 PPT에서 어떤 슬라이드들이 비교가 되어야하는 지 였습니다.
- 완전히 일치하는 슬라이드만이 아닌, 일부 변경사항이 발생한 슬라이드도 비교가 이루어져야하였고, 저희는 ‘어느정도까지의 슬라이드 변경률이, 일치되는 슬라이드라고 봐야할까?’ 라는 고민에 빠지게 되었습니다.
- 슬라이드마다, 기준으로 정한 최소 일치율을 만족하는 경우에 매칭이 되는 슬라이드로 판단하는 방식을 처음으로 생각하였습니다.
- 다만 해당 방식을 사용할 경우, 하나의 슬라이드마다 비교 파일의 슬라이드들을 전부 조회해야하므로 그 과정에서 O(n)의 시간 복잡도를 갖게 되는 것이 고민이었습니다.
- 단순히 슬라이드마다 index를 매겨, 같은 index의 두 슬라이드만을 비교하는 것은, 슬라이드 순서가 뒤바뀌거나 중간에 슬라이드가 추가되는 경우를 대응하지 못하게 됩니다.
- 다른 방안으로, 리액트 내에서 자식 요소들을
mapmethod를 이용해 렌더링 하는 경우에, key 값을 이용해 구분하는 것에 착안해 개별 슬라이드에 부여되는 고유한 값을 추출하는 방안이 있었습니다. - 고유한 값의 경우, 슬라이드가 복사되는 경우 새로 부여되어야하며, 반대로 파일이 복사되는 경우에는 그 값이 유지되어야 합니다.
- 슬라이드에 부여되는 여러 속성 값들 중, 해당 조건에 부합하는 고유한 값(
p:creationId태그 값)을 사용해 동일 슬라이드를 매칭하게 되었습니다. - 해당 방식을 사용할 경우, 일치하는 하나의
slideId값을 가진 data를 조회하면 되므로 시간 복잡도 면에서도 유리하였습니다. Map 자료형을 이용해, 순회 시 시간 복잡도를 O(1)로 가져갈 수 있었습니다.
- 비교 대상이 될 슬라이드를 선택 후, 어떻게 diffing까지 이루어 질 지도 또 하나의 관건이었습니다.
- 단순히 두 대상을 비교하는 것은 두 값이 일치하는 지만 판별하면 되지만, 그걸 가공하기 효율적인 data로 정의하는 것은 생각보다 더 어려운 문제였습니다.
- diffing이 된 결과는, react에서 rendering하여 보여줄 수 있어야하고, merge를 진행할 때에도 활용됩니다. 이 두 가지 작업을 어떻게 용이하게 할 수 있을 지가 관건이었습니다.
- 작업을 용이하게 만들기 위해, 두 개의 PPT 파일에 각각의 의미를 두었습니다. 두 개의 PPT 파일을 기존 PPT / 변경 된 PPT로 구분하였습니다. 단순히 두 PPT를 비교하는 개념보다는, 기존 PPT와 변경 된 PPT를 비교한다는 개념으로 접근하였습니다.
- 그리고 자체적으로
diffType에 관한 종류와 규범을 정의하게 되었습니다. - 기존 PPT 내에서 비교 대상이 될 슬라이드가 없는 슬라이드는 삭제가 된 슬라이드(
deleted)로 판별하였습니다. 변경 된 PPT 내에서 비교 대상이 없을 경우는, 추가 된(added) 슬라이드로 판별하였습니다. - 비교 대상이 있는 경우, 슬라이드 내부 요소가 모두 일치하는 지 판별합니다. 모두 일치하면 변경점이 없는 슬라이드(
none)로 판별합니다. 한 요소라도 달라질 경우는 수정 된 슬라이드(modified)로 판별하게 되었습니다. - 요소의 경우, 슬라이드와 마찬가지로 요소 내 고유값을 추출하여 추가/삭제/변경 요소를 판별합니다. 다만 이 경우, 변경 된 요소를 또 변경 전과 후라는
diffType을 정의해 주게 되어 분기가 되는 부분마다 type을 추가하게 되어 코드의 복잡성이 늘어나게 되었습니다. - 결국 수정 된 요소의 경우 기존 PPT 파일에서는 삭제 된 요소, 변경 된 PPT 파일에서는 추가 된 요소로 판별하여 작업을 단순화하는 방향으로 문제를 해결하였습니다.
- 비교가 된 데이터에서, 사용자가 선택한 항목을 취합해 새로운 PPT 파일로 제공하는 것도 또 하나의 어려웠던 부분입니다.
- 우선 사용자가 어떤 data를 선택하였는 지 알 수 있게하는 값이 필요하여, diffData에서 isChecked 프로퍼티를 추가하였습니다.
- 그리고 코드 복잡성을 줄이기 위해, isChecked의 값으로 단순 boolean 값을 활용하여 merge 되는 data를 체크할 수 있게 하였습니다.
- 변경된 요소의 경우, 두 요소 중 어떤 요소를 합칠 지를 따로 요소의 id 값으로 지정하지 않고,
truefalse값에 따라 기존 PPT / 변경 된 PPT의 data를 취하도록 단순화하여 작업이 조금 더 용이해지도록 정하였습니다.
- 그 다음은, merge data를 바탕으로 새로운 PPT 파일을 사용자에게 제공해주어야 했습니다.
- 기존의 파일을 건드려서 수정된 .pptx 파일을 그대로 제공하는 것이 가장 첫 번째 방안이었습니다.
- 하지만 슬라이드의 정보를 수정하는 것은, 단순히 파일의 일부분만을 변경하는 것이 아니라 슬라이드 내부의 여러 파일 내용들을 바꾸는 경우가 많았습니다.
- 파일을 단순히 내용만 바꾸거나 덮어쓰기를 할 경우, 파일 자체가 깨지는 일이 많았습니다.
- 하나의 .pptx 파일에는 여러 관계로 둘러쌓인 .xml 파일들이 있어서, 한 부분만이 아닌 그와 관계된 data까지 변경해줄 필요가 있었습니다.
- 해당 방식을 사용할 경우, 프로젝트 기간 내에 안정적으로 파일 수정 로직을 작성하기에 힘들 것이라 판단하여, 새로운 파일을 만드는 방안을 도출해냈습니다.
- 값을 입력해 새로운 .pptx 파일을 생성할 수 있는, PptxGenJs 라이브러리를 이용해 새로운 PPT 파일을 만들어 사용자에게 제공해주는 방안을 택하게 되었습니다.
- 기존에 가공했던 merge data를 기반으로, 새로운 PPT 데이터를 입력하여 새로운 PPT 파일을 생성할 수 있는 로직을 작성하게 되었습니다.
- 프로젝트에 사용자 관리를 어떻게 할 것인 지에 대해 논의가 발생하였습니다.
- 유저 로그인 기능을 추가하여 유저 정보를 기억해 다양한 기능을 제공할 수 있고, 또는 추가하지 않고 핵심적인 서비스 내용에 집중할 수도 있었습니다.
- 우선 로그인 기능을 추가하여 더 많은 기능을 제공하는 방안이 있습니다.
- 다만 한정적인 시간 내에 더 많은 기능들을 가져가게 되면서, 원래의 핵심 서비스의 완성도가 떨어질 수도 있다.
- 그리고 이슈가 논의되었던 시점 당시, 작성이 어느정도 진행되었던 mockup, 유저 플로우, api docs 등을 수정해야 해, 그만큼 프로젝트 진행이 지체될 수 있었습니다.
- 유저 로그인 기능을 넣지 않고, cookie를 발급하여 게스트 유저를 기억하는 방안이 있었습니다.
- 사용자가 접속 시, DB에서 만료시간이 짧은 유저 데이터를 생성해, 그 id값으로 유저를 기억하고 구분하도록 시도하려고 하였습니다.
- 위와 마찬가지로 핵심 서비스에 대해서 완성도가 떨어지게 될 수 있으며, 유저 관리 방안에 대한 조사 및 기술 구현이 충분치 않다는 단점이 있었습니다.
- 로그인 혹은 내 파일보기 기능을 넣지 않고, download page 링크를 따로 가질 수 있게 하는 방안도 제시되었습니다.
- 사용자는 url 정보를 갖고 있으면, 언제든지 파일들을 다시 다운로드 받을 수 있도록 하였습니다.
- 유저 관리에 대한 DB 추가내용 작성 및 부수적인 기능 구현보다, 본 프로젝트 내용에 집중할 수 있게 됩니다.
- 로그인 기능을 제외하는 대신, download page url을 통해 작업한 파일을 기억할 수 있게 하였습니다.
- 유저를 기억하여 작업했던 파일들을 저장해 보여주는 기능을 가져가지 못하였지만, 다른 사용자와 공유하거나 url로 저장할 수 있게 기능을 도입하도록 결정하였습니다.
- ‘작업한 파일을 다시 내려받을 수 있게 한다.’라는 원래의 아이디어 목표를 가져가면서, 기능을 거의 추가하지 않을 수 있었습니다.
- 그에 따라서 부가적인 부분에 대한 기능 수고를 덜 수 있게 되었고, 핵심적인 기능 개발에 집중할 수 있게 되었습니다.
- 두 PPT 파일의 차이를 나타낸 Diff data를 시각화하는 과정에서, 해당 이슈가 발생하였습니다.
- 하나의 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 코드 작성을 줄일 수 있도록 결정하였습니다.
- 고화질 사진 등 용량이 큰 PPT의 데이터를 모두 MongoDB에 저장할 수 없는 이슈가 발생하였습니다.
- MongoDB의 정책 상, document 하나의 크기가 최대 16MB로 제한되고 그 이상은 무시하게 되어 해당 이슈가 발생하였습니다.
- 데이터를 압축해서 DB에 저장하자는 의견이 논의되었습니다.
- 하지만 MongoDB에 데이터를 저장하는 이유는 Server에서 PPT들의 데이터를 비교하고, merge하는 작업을 수행하기 위함인데, 데이터를 압축한다면 다시 불러와서 압축 해제하는 추가적인 시간이 소모될 것이라 판단하였습니다.
- 각각 개별 슬라이드를 저장하여, PPT Data에서는 Slide Id 정보를 관리하는 방안이 논의되었습니다.
- Slide들을 개별적으로 저장하는 방안 역시 많은 양의 Slide들이 들어가면 컬렉션 자체 용량을 초과하는 리스크가 있었습니다.
- 하지만 데이터의 만료시간을 설정해, 효율적으로 용량을 관리하도록 결정하였습니다. CronJob으로 스케쥴 관리를 해서 주기적으로 데이터를 삭제하도록 결정하였습니다.
- 각각 개별 슬라이드를 저장할 수 있는 PPTSlide 컬렉션을 두어 PPT 컬렉션에 해당 슬라이드 document들의 id들을 두는 방안으로 결정하였습니다.
- 각 데이터들은 다대다 관계를 형성하게 됩니다. 이 후 데이터를 불러올 때, populate 메소드를 이용하여 전체 PPT 데이터를 불러오도록 결정하였습니다.
-
Frontend Root 디렉토리에
.env파일을 생성하고, 다음 환경변수를 입력하고 실행합니다.REACT_APP_API_SERVER_URL = REACT_APP_CLIENT_URL = REACT_APP_SAMPLE_ORIGINAL_FILE_URL = REACT_APP_SAMPLE_COMPARABLE_FILE_URL =$ git clone https://github.com/Team-threeI/ppthub-client.git $ cd ppthub-client $ npm install $ npm start -
Backend
Root 디렉토리에
.env파일을 생성하고, 다음 환경변수를 입력하고 실행합니다.MONGODB_URL = PORT = AWS_ACCESS_KEY_ID = AWS_SECRET_ACCESS_KEY = AWS_REGION = AWS_BUCKET =git clone https://github.com/Team-threeI/ppthub-server.git cd ppthub-server npm install npm start
공재혁
“팀 프로젝트가 가장 힘들고, 가장 재밌어요“. 누군가가 저한테 팀 프로젝트가 어떤지 알려달라고 했을 때, 이런 말을 해준 적이 있습니다.처음 이 얘기를 들었을 때는 ‘정말 그런가..?’ 하는 생각이었는데, 지금은 엄청 공감하는 말이 되었네요.
처음 프로젝트를 진행할 때, ppt 파일을 어떻게 읽고, 보여주고, 비교하고, 합치기? 하며 막막해 했던 기억이 떠오르게 되네요.
저희 프로젝트가 대단히 새로운 기술이나 어려운 기술 스택을 쓰지는 않았는데요. 다만 저희에게는 ppt 파일을 잘 다루어서, 그걸 사용자에게 보여주는 과정이 저희에게는 하나의 챌린지로 다가왔습니다.
ppt 파일을 해석하는 코드를 짜는 경우가 많지 않다보니, 기존에 있는 라이브러리의 내부 코드들을 많이 참고하였는데요.
아직은 저희에게 생소한 Typescript 코드도 많이 봐야했고, 어떤 라이브러리는 대만 개발자가 작성해서 대만어로 주석이 적혀있어서 번역기를 열심히 참조했던 기억이 있습니다.
PPT 파일의 구성이 적힌 오래된 웹사이트 하나를 발견했을 때는, 정말 기뻤었던 기억이 나네요.
그만큼 이곳 저곳의 코드와 명세를 많이 참조하게 되었고, 덕분에 어느정도의 결과물이 나오게 된 것 같아 뿌듯했었습니다.
그리고 팀으로서 진행하는 프로젝트다보니, 각자 생각이 다 다른 점들을 하나로 모으는 과정이 쉽지 않았습니다.
여기에 버튼을 넣고, 어떤 어떤 식의 플로우를 짜면 될 것 같아요!라고 서로 합의가 되어도, 막상 mock up 화면을 작성할 때는 서로 생각이 달랐음을 확인 한 적도 많고, 회의 중에 서로 척척 합이 잘맞는 구나! 라고 생각해도 알고보니 서로 각자 얘기만을 말하면서도 서로 통했다고 느꼈었던 적도 많았습니다.
그래서 팀 프로젝트는 생각보다 꽤 구체적으로 의견을 일치시켜나가야 한다고 느꼈습니다.
각자가 할 일을 분담하는게 아니라, 결국 모두가 하나의 큰 일의 일부분만을 하는 것이니까요.
사소한 부분 하나하나 서로 확인하고, 안맞는 부분은 의견을 맞추려고 노력해야함을 느끼게 되었습니다.
아무리 작은 부분에서라도, 그냥 넘어가거나 ‘다음에 결정하죠’ 라는 얘기가 되면 결국 나중에는 손 쓰기가 힘들 정도의 상태가 돌아올 수 있다는 것도 잘 알게되었습니다.
개인적으로 가장 힘들었던건, 내가 이 프로젝트를 마무리 할 수 있을까? 하는 부담감이었는데요. 아무리 기술 조사를 열심히하고, POC를 해도 아직 완전하지 않은 부분이 남아있을 수 밖에 없었습니다.
그 상황에서 진행하기로 했던 flow에 서로 생각이 달라, 방향이 완전히 틀어질 뻔한 적이 있었는데요. 정말 기술 조사를 겨우 한 부분에서조차 flow가 틀어져버리니, 그만큼 당황했고 자칫하면 프로젝트를 완성못하겠다는 압박감이 들었습니다.
다행히 프로젝트가 잘 마무리되었고, 곁에서 노력해준 저희 팀원들 덕분에 저도 힘을 내서 코드를 작성했던 것 같습니다.
코드를 손에서 놓고싶은 순간이 와도, 팀원들이 열심히 피드백을 주고받으면서 힘내는 모습을 보면은 저도 모르게 코드를 붙잡게 되었습니다.
그리고 저도 누군가에게 그렇게 힘을 내 줄 수 있으면 좋겠다는 생각을 하기도 했습니다. 내가 힘을 내서 코드를 쓰고, 서로 인정해주고 북돋아주는 것이 많은 힘이 될 수 있겠구나 느끼게 되었습니다!
양선종
개발이라는 하나의 주제를 가지고 시작한 첫 프로젝트였던 만큼 이번 프로젝트가 나에게 주는 의미는 매우 크다.프로세스 관리 방법 중 스크럼 방법을 통해서 프로젝트 계획, 회의, 칸반 작성 등을 진행하였고 이를 통해 프로젝트를 함에 있어서 이러한 행위들이 왜 중요한지를 명확하게 깨닫게 되었다. 이러한 과정들이 없었다면 내가 겪은 3주라는 시간이 계획이 있었음에도 정신이 없었는데 얼마나 더 정신이 없었을까 라는 것을 확연하게 느꼈다.
또한 프로젝트를 시작할 때 가지고 있었던 걱정 반 기대 반으로 가득 차 있었던 감정이 그대로 팀 프로젝트에서 드러났다고 개인적으로 생각하고 있다.
여러 가지 측면에서의 걱정이 존재했는데 첫 번째는 내가 팀원들에게 도움이 될 수 있을까 라는 걱정이 존재했고 팀원분들은 어떻게 생각할지 모르겠지만 나는 매우 아쉬웠다고 주관적으로 평가하고 싶다. 팀플을 하면 할수록 더 도움이 되고 싶다는 생각이 가득했고 노력했다고는 생각하지만, 프로젝트를 진행하면서 내가 작성한 하나의 컴포넌트 하나를 가지고 시간이 딜레이 되는 게 정말 죄송스러웠던 감정이 들었다. 그래도 이러한 과정에서 우리의 프로젝트가 단단해지고 더 완성도가 있게 만들자는 팀원분들의 생각에 정말 감사했고 그 과정에서 내가 몰랐던 방법들을 알 수 있게 되어서 얻어 가는 게 많았다.
두 번째는 커뮤니케이션 관련 해서의 걱정이었다. 앞선 컴포넌트와 관련한 코드 작성과는 별개로 프로젝트에 있어서 아이디어 측면과 서로 생각하는 방면이 완전하게 일치하지 않았기에 이런 문제가 발생했다고 생각한다. 사실 프로젝트라는 것 자체가 완성된 프로젝트를 가지고 작성하는 것이 아닌 없었던 프로젝트를 기획하고 구현하는 것이기 때문에 이러한 문제는 없으면 오히려 이상하다는 것이 맞는다고 생각한다. 그렇기에 아이디어와 관련한 충돌이 자주 일어나 힘들었지만 그럼에도 불구하고 첫 회의 중 하나였던 그날 있었던 감정은 그날에 푸는 것처럼 서로 그날 최대한 이해하고 최대한 감정을 풀어나갔던 부분에 있어서 커뮤니케이션 능력에서의 걱정과 성장을 동시에 이루어 나갔다고 생각하고 있다.
마지막으로는 당연히 기능 구현 및 프로젝트 진행에 대한 걱정이 매우 컸다. 사실 초반에는 이게 될까? 라는 생각이 엄청 많았고 우여곡절 또한 심하게 많았다. 피피티라는 파일 자체가 하나의 xml로 이루어져 있는 것이 아닌 많은 xml들의 집합인 점에서 xml 파일 간의 인과관계를 파악하기 위해서 시간을 쓰게 되었다면 아마.. 프로젝트는 3주가 아니라 3달이 걸려서 끝나지 않았을까 라는 생각을 한다. 그렇기에 당연히 문제가 생길 수 밖에 없었는데 다행히 pptx를 만들어주는 라이브러리를 토대로 파싱한 데이터들을 가지고 pptx를 만들 수 있었지만 라이브러리를 사용했다는 아쉬움이 존재했다. 또한 데이터의 양이 너무 방대하다는 것이 매우 큰 딜레이 요소이다. 하나의 텍스트를 얻기 위해서 xml 파일을 매우 딥하게 들어가기 때문에 pptx를 구성하는 데이터들을 모두 파싱하기 위해서는 시간이 오래걸린다는 시간적인 문제가 더 존재해서 아쉬웠다. 그래도 이러한 걱정들과 다르게 결국은 프로젝트가 만들어진다는 부분에 있어서 뿌듯한 감정을 느꼈다.
프로젝트 기간 2022.10.10 ~ 2022.10.28 인 3주 동안 정말 많이 힘들었고, 많이 배웠고, 많이 정신없었지만, 결과가 나왔을 때는 많이 뿌듯했다. 프로젝트가 얼마나 힘들었는지는 이미 지나간 시간이기 때문에 크게 중요한 요소는 아니다. 하지만 프로젝트가 끝나고 내가 많은 것을 얻었다는 것이 자체는 나에게 있어서 다른 프로젝트를 진행할 때도 매우 큰 도움의 밑거름이 될 수 있기에 정말 정말 뜻깊은 시간이 되었다.
이동현
처음으로 진행하는 협업 프로젝트였습니다. 애자일 방법론 또한 처음이었기에, 3주라는 짧은 시간 동안 매일 스크럼을 진행하면서 프로젝트 진행 상황을 공유하고, 회의와 피드백을 통해 계획에 어긋나더라도 유연하게 대처할 수 있었던 경험 역시 새로웠습니다.이번 프로젝트를 진행하면서 느낀 점은 크게 2가지입니다.
첫 번째, 커뮤니케이션의 중요성입니다.
매일 오전 데일리 스크럼 미팅을 진행하면서 오늘 우리 팀이 해야 할 것, 현재 프로젝트 진행 상황 및 딜레이 여부 등을 이야기하면서 의견을 나누었고, 그 결과 다소 딜레이가 있더라도 유연하게 대처해 프로젝트를 정해진 기한 내에 배포까지 무사히 할 수 있었습니다.
프로젝트 진행 중에 코드 컨벤션부터, 디자인, 기능적인 부분에서 의견이 많이 갈리기도 하였는데, 프로젝트 계획을 할 때 더 많은 의견을 나누어 규칙 및 프로젝트 구조를 자세하게 설계하지 못한 부분은 아쉬움이 남습니다.
이러한 부분이 개발 중에 의견이 나뉘다 보니, 개발 진행 중 딜레이가 되는 원인이 되기도 하였고, 다소 날카롭게 말할 때도, 배려하지 못할 때도 있어서 ‘좀 더 잘 말할 수 있었지 않았을까?’ 하는 아쉬움이 항상 남아있습니다. 그렇지만 이러한 협업 경험을 통해 나의 의견을 잘 표현하고, 그리고 상대방의 의도를 파악하는 데에 있어 다시 한번 생각해 보는 계기가 되었습니다.
두 번째는 기술 도전에 대한 아쉬움입니다.
프로젝트 계획 중에는 새로운 기술적인 챌린지도 고려했었지만, 개발에 들어가니 기능 구현에만 집중하게 되었고, 기한 내 프로젝트를 완성하는 데에 급급하게 되었습니다.
개발이 진행되는 동안 전역 상태 관리의 필요성을 느껴 리덕스를 도입하였습니다.
리덕스가 아닌 다른 방법을 논의하기도 하였지만, 개발 진행 중 기술 조사에 시간을 투자하지 못하여 기존 사용 경험이 있는 리덕스를 사용하게 되었습니다.
더 좋은 방법에 대해 고민을 충분히 하지 못해 다소 아쉬움이 남는 부분입니다.
정신없이 3주가 지났는데, 매일 PR을 진행하면서 활발하게 코드 리뷰를 진행해주는 팀원들 덕분에 다양한 의견을 나누어 프로젝트의 들어오기 전보다 확실히 성장한 자신을 발견할 수 있었습니다.
그렇기 때문에 이번 첫 프로젝트는 여러모로 기억에 남고, 항상 배려와 존중을 생각하면서 성장해 나갈 수 있도록 하겠습니다.