1️⃣ 1주차 발표 준비

https://www.figma.com/proto/FSuuYoDXLww6QG5d628SA2/OctoDocs?page-id=170%3A16&node-id=170-17&node-type=canvas&viewport=-155%2C1361%2C0.6&t=KLeuuKYwgY4ir1M9-1&scaling=contain&content-scaling=fixed&starting-point-node-id=170%3A17&share=1

1p

안녕하세요 캠퍼 여러분, Web15 OctoDocs 기획 발표를 맡게 된 김현준입니다. 저희 문어 귀엽죠? 이따 프로젝트 소개 때 자세히 말씀드리겠지만, 문서를 작성하고 연결한 모양이 문어 같아서 이렇게 마스코트도 준비해봤습니다.

2p

팀원 소개부터 간단히 해보도록 하겠습니다. 저희 팀은 FE 두 명, BE 세 명이고, 발표자인 제가 감자를 맡고 있습니다. TMI를 좀 말씀드리자면 아이콘은 토스페이스에서 따왔는데요, 각자 선호하는 이모지를 골라서 배치해보았어요. 저희 프로젝트 위키 가보시면 각자 깃허브와 MBTI도 있답니다!

3p

다음은 팀 문화인데요, 그라운드 룰 중에서 나름 특색있다고 생각되는 것을 좀 뽑아와봤어요. 리뷰와 머지 같은 경우는 모든 팀원이 모든 PR을 리뷰하기 보단, 필수로는 같은 분야끼리 리뷰하고 그 외는 옵션으로 두었어요. 6주라는 기간이 길지는 않다보니까 개발 속도 측면에서 더뎌질 수 있고, 개개인의 리뷰 할당량이 많아지면 전체적인 코드 리뷰 퀄리티 저하가 있을 수 있다는 생각에 이렇게 결정했습니다. Pn 룰 이라는 것도 활용하기로 했는데요. 슬랙에 공유됐었던 뱅크샐러드 코드리뷰 문화 글을 읽어보신 분들은 아시겠지만, P1 부터 P5까지 단계를 두고 코드리뷰를 진행하는 방식이에요. P1 같은 경우는 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P5 같은 경우는 리뷰이가 리뷰어의 의견을 무시해도 괜찮은 경우로 두고, 각 의견에 단계를 표기하는 방식입니다.

문서 같은 경우는, 깃허브에서 제공해주는 기능들을 적극 활용하기로 했어요. 노션이나 지라 같이 외부 도구를 활용하자는 의견도 있었지만, 프로젝트 레포에서 저희 팀의 모든 것을 확인할 수 있으면 좋겠다는 마음에 이렇게 결정했습니다. 회의 중에는 동시편집이 필요하기 때문에 노션에서 작성하다가, 회의가 끝나면 그 날의 서기가 위키로 옮기는 방식으로 진행하고 있습니다.

Github Project는

• Github Project는 Issue에 대한 칸반보드와 백로그 관리 용도로 사용합니다.
  • 누구든 적극적으로 수정에 나섭니다.

Github Wiki는

• Github Wiki는 프로젝트 관련된 모든 문서를 포함합니다.
  • 일/주 단위로 작성되는 모든 문서를 포함합니다.
  • 기술적인 고민과 해결 과정을 문서화하여 정리합니다.
  • 챌린지와 트러블 슈팅을 따로 문서화해서 기록합니다.

Github Issue는

• Github Issue는 기능 요구사항과 이슈(버그 및 요구사항) 추적에 사용합니다.
  • 적절한 Assignee 와 태그, 우선순위를 지정합니다.
  • 템플릿에 맞게, 일목요연하게 작성합니다.

이제 본격적으로 저희 서비스에 대해 소개를 해볼게요.

4p

이 장표 한 장이 저희가 만들고자 하는 서비스의 거의 모든 것을 보여주는데요. 노트 간의 연결 관계를 쉽게 설정하고 보여줄 수 있는, 실시간 협업 문서 편집기를 만드는 것이 저희 팀의 목표에요.

5p

실시간 데이터 라는 주제로 꾸려진 팀이었지만, 주제를 선정하는게 쉽지만은 않았어요. 여러 후보가 나오고 많은 이야기가 오고갔지만, 팀원 모두의 재미와 관심사에 맞으면서, 스프린트 마다 발전시킬 여지가 많은 확장성 높은 주제를 선택하게 되었어요. 멘토님과 함께하는 킥오프 시간 때 저희는 ‘공동으로 함께할 목표’가 아닌 ‘각자가 이룰 이기적인 목표’ 에 대해 이야기 했었는데, 오히려 이렇게 거꾸로 접근해보니까 주제 선정이 수월해지더라고요. 6주 간의 프로젝트를 통해 서로 얻어가고 싶은 부분이 다르지만, 모두가 재미있고 흥미롭게 수행할 수 있는 주제를 고르고, 짧은 배포 주기를 반복하며 작은 성공을 계속해서 이뤄갈 수 있도록 하면 모두가 만족할 수 있다고 생각했어요.

6p

다시 서비스로 돌아와보면, 핵심 기능 2가지를 최우선으로 구현하자는 목표를 삼았어요. 저희 팀원들이 사용했던 지식 관리 도구들의 단점을 모아보고, 그것을 한 방에 해결하기 위한 방향으로 의견을 모으다 보니 이런 목표가 나온 것 같네요. 아무래도 노션 같은 경우에는 동시 편집 기능과 템플릿, 데이터베이스 등 여러 강력한 기능을 제공하지만, 문서들끼리 관계를 보기엔 어렵죠? 무조건 계층구조로 문서를 배치할 수 밖에 없으니까요. 옵시디언은 자체적으로 그래프 뷰를 제공하지만, 문서끼리 링크하기 불편하게 되어 있고, 협업이 불가능하다는 단점이 있었어요. 그래서 지식 관리 툴로써의 편의성을 제공하고, 문서가 필요한 협업 활동을 강화하자는 목표 하에 2가지 킥을 잡게 되었습니다.

7p

개발 스택 같은 경우는 아직 100% 확정된 사안은 아닌데요, 기획의 크기에 비해 시간적인 압박이 있다고 생각해서 프론트엔드에서는 라이브러리를 적극 활용하기로 했어요. 컴포넌트 간 관계를 시각화 하기 위해 React Flow를 사용하고, 노션과 비슷한 문서 편집 환경을 조성하기 위해 Novel 을 사용하기로 했습니다. 백엔드도 생산성과 코드 관리 측면에서 이점을 살리기 위해 Nest와 TypeORM을 사용하기로 했고, CI/CD 를 용이하게 하기 위해 도커 정도 까지는 사용을 고려하고 있어요.

8p

주제에 대해 이야기 하면서, 팀원 모두가 ‘그래서 이게 진짜 우리가 구현할 수 있는 기능이 맞긴 한거야?’ 하는 의문을 갖고 있었거든요. 관계 시각화를 위한 React Flow가 웹소켓을 지원하여 실시간으로 편집 내용을 반영할 수 있는 부분은 공식 문서와 예시들을 통해 검증했고요, 코드 에디터에서 동시 편집, 피그마 같은 커서 동기화 등 기능이 구현 가능하다는 것은 프로토타입을 만들어서 자체 검증하고, 기획을 이어 나갔습니다.

• 이전

  주제에 대해 이야기 하면서, 팀원 모두가 ‘그래서 이게 진짜 우리가 구현할 수 있는 기능이 맞긴 한거야?’ 하는 의문을 갖고 있었거든요. 그런데 동준님께서 빠르게 라이브러리를 통해 프로토타이핑을 해보셨어요. 정말 대단하시죠? 관계 시각화를 위한 React Flow가 웹소켓을 지원하여 실시간으로 편집 내용을 반영할 수 있는 부분과, 코드 에디터에서 동시 편집, 피그마 같은 커서 동기화 등 기능이 구현 가능하다는 것을 자체 검증하고, 기획을 이어 나갔습니다.

이렇게 하면 어떨까요..? 🥲

9p

앞으로 프로젝트를 진행하면서 여러 난관이 있겠지만, 당장 떠오르면서 극복하기 쉽지 않아 보이는 기술적인 챌린지 2개를 선정해보았어요. 아무래도 노트간 관계를 표현하려면 그래프 형태가 될텐데, 이것을 관계형 데이터베이스로 표현하는게 단순한 작업은 아닐 것 같더라고요. 그래서 GraphDB 같은 NoSQL 사용을 고려해보긴 했었는데, 학습 비용 같은 걸 따져 보았을 때 단순하게 도전할 수 있는 사항은 아닌 것 같아서, 일단 RDB로 최대한 도전해보려고 합니다. 프론트엔드 같은 경우는, 실시간 편집을 지원할 때 서로 다른 해상도에서 커서 위치를 어떻게 표시해주냐에 대한 고민이 있는데요, 이 부분도 더 고민해봐야겠지만, 브라우저 마다, 유저마다 해상도가 다 다르기 때문에 엄격하게 보여주려면 일렉트론 같이 환경 자체를 통제하는 것이 맞다고 생각하고 있어요. 문서 편집 같은 경우는 노션처럼 현재 블록 위치만 보여줘도 사용성 측면에선 괜찮지 않을까 생각도 하고 있습니다.

10p

마지막으로 백로그 작성한 부분을 소개드리고 마치려고 합니다.

<차라리 이 부분에서 깃허브 보여주면서 각각의 용도에 대해 설명하는게 좋을듯>