우아한테크러닝4기 미니노션 만들기의 2차시가 끝났습니다.
이번에는 우리가 한 달 간 어떤 서비스를 만들 것인지 기획을 확정하고, 그 목표를 달성하기 위해 어떤 기능을 넣을 것인지, 어떤 프레임워크를 이용해 개발할 것인지 이야기를 나눠보았습니다.
아래는 제가 정리한 내용입니다!

기술 난제

---

기술 난제 파악

기술 난제를 파악해야 한다!

• 해본 적이 있어서 이렇게 이렇게 하면 된다 그림이 그려지는 것
• 간단할 거 같은데 해본 적은 없어서 얼마나 걸릴 줄도 모르고 어떻게 하는지 그림이 그려지지 않는 것

→ 이 둘을 구분할 것

해본 적이 있지만 다르게 시도해보고 싶은 게 있는지 생각

똑같은 방식으로만 하면 발전이 없다. 그니까 새로운 방법을 생각해볼 것. 이전에 했던 방식에 장점만 있는 건 아니니까 또 어떻게 시도해볼 수 있을까 생각해보면 좋겠다.

기술 난제 해결

기술 난제 해결 방법 —> POC / 프로토타이핑

• POC → Proof of Concept : 내가 이렇게 하려고 했는데 가능한가? 워킹 가능한 모델인지 실험해보는 것! 컨셉 자체가 정말 실현 가능한지 확인하는 걸 POC라고 함.

• 프로토타입 → 토론으로 말로만 전달하기에는 한계가 있다. 말로 뭔가를 설명하는 건 굉장히 어렵고, 설명이 됐다 하더라도 서로 같은 이해를 하고 있다고 장담할 수 없고 사실 되게 어렵다.

  그래서 그려서 무언가를 보여주고 플로우나 컨셉을 그림으로 보여주는 게 필요.

  빠르게 빌드업 해서 비슷하게 만들어보는 것
  

기획과 초기 세팅에서 신경써야 할 것들

---

유지보수

유지보수가 쉽다 → 코드끼리의 결합도를 느슨하게 해서 수정을 쉽게 하는 것

1이 100으로 커졌을 때를 감안한 코드가 아니면 결국 복잡도가 늘어난다 (중복 코드, 패키지 .. 등등)

볼륨이 커져도 복잡도가 늘어나지 않게 하는 리팩토링이 요구된다

CRA vs. 웹팩

CRA 같은 툴은 태생적으로 모든 거를 커버하기 위해 엄청난 규모를 가지고 있다.

뭔가 하나 간단한 거를 하려 해도 엄청난 비용(시간적, 공간적 .. )을 들일 리스크가 있다

configuration을 하나도 안 하고 쓸 수 있어서 너무 좋은데, 대체 내가 하려고 하는 일은 얘한테 어떻게 시켜야 하나 하는 상황이 오게 된다.

이게 CRA를 안 쓰고 웹팩을 쓰는 이유

운영적 확인 사항

운영적 확인 사항 → 어떤 stage까지 갈 것이냐, 언제 배포가 될 것이냐, 개발자 상황 등등

이런 걸 고려해야 프로젝트 세팅이 된다. 이런 걸 생각하고 레포를 구성해야 한다!

레포 관리법

서버 / 프론트 레포를 분리하면 라이프사이클을 따로 관리할 수 있음

서버 수정을 했을 때 서버만 배포하거나, 프론트 버그 잡은 후 프론트만 배포 등

그리고 브랜치 관리도 쉬워지겠지

한 레포 안에 서버/프론트가 모두 있으면 브랜치가 무지하게 많아지고 관리가 어려워질 것

목표기준

사용자 규모 목표, 목표로 하는 UX, 레퍼런스가 있는데 그 레퍼런스에서 어느 정도까지 구현할 거야?, 최소 구현 기능, 마일스톤 이번 주는 어디까지 하자, 이런 거에 대한 목표 기준을 확인하면 좋겠다 이런 걸 확정하고 시작해야 한다.

확정이 되지 않은 상황이라면 질문을 통해 궁금한 것을 모두 해결할 것

팀이 하나의 목표를 바라볼 수 있도록 무던히 많은 노력을 해야 한다

당위성 - 모든 것에는 항상 이유가 필요하다

뜬다고 냅다 선택하면 안 되고 내가 그걸 선택하게 된 이유가 있어야 한다 → 당위성
(면접 보면서 안타까운 분들이 너무 많은 거 같아 드리는 말씀입니다)

항상 이유를 만들어라!
그리고 그 이유를 구체적으로 설명할 수 있어야 한다!

→ 면접 꿀팁. 좋은 회사 갈 수 있는 방법.

확정된 기획과 스펙

---

• 회원 서비스 - 구글 로그인 → API 활용 → OAuth 연동
• 폴더구조를 가지고 있지 않은 선형적인 단일 문서 구조 (리스트 UI 정도는 있어야 함)
• 기획: 친구들끼리만 공유하는 간단한 문서 공유 서비스 (일기장으로 쓰든 뭘로 쓰든)
• 커스텀 컴포넌트 기능 (불릿, 이미지 추가, 코드블럭 등)
• 마지막 쓴 사람 내용으로 overwrite 됨
  
  
• 문서 편집기 > 커스텀 컴포넌트 > 어떤 기술 스택?

민태님의 의견

---

Toast UI

TOAST UI

토스트 ui는 올인원 에디터다 → 커스터마이징에 대한 부분은 약할 수밖에 없다.

→ 얼만큼 커스터마이즈 할 수 있는 인터페이스를 노출해주고 있나? 확인해봤음

→ API 문서가 상당히 빈약 → 커스터마이징을 애초에 타겟팅하고 있지 않았을 수 있다

Draft.js

Draft.js

• Draft.js → 리액트 베이스 rich text editor 프레임워크
• 꾸준히 업데이트 되고 있음
• 이 프레임워크를 이용해 만든 서비스 예시가 많음
• 장점: fully customizable, 단점: 기본 컨셉을 충분히 이해하고 에디터를 구축해야 함 (사용이 어렵다)
• API가 엄청나게 많다 → 좋아보이기도 하는데, 학습해야 할 게 많다는 단점
  
  

SlateJS

SlateJS Introduction

• completely customizable framework for building rich text editors
• 리액트 베이스
• yarn add slate slate-react
  → 이렇게 slate 안에 slate-react를 관리하는 게 상당히 인상적인데, 우리가 중간에 만약 vue로 작업을 바꾸고 싶다면 여기에 드는 비용을 줄일 수 있다는 장점이 있다.
  
  

+) 서비스 설명에 관련해서

내가 서비스를 만들 때는 내가 이 서비스를 어떻게 규정하는가가 중요하고

다른 서비스를 볼 때는 그들이 그 서비스를 어떻게 규정하고 있는가가 중요하다 → 이걸 보고 고르게 되기 때문에

+) 서비스 원칙에 관련해서

어떤 제품을 볼 때 그 제품을 만든 원칙을 숙지하는 게 좋다 (컨벤션 등)

→ 어떤 게 어떤 모양으로 형성돼있다 했을 때 그 원칙을 바탕으로 나왔을 확률이 높다

→ 이유가 설명이 가능한 부분

다음 시간 전까지 과제

---

• 이번 주에 기획이 나왔고, OAuth 회원 연동하는 걸 해보기로 했음
• 프로토타이핑을 해보면 좋을 것 같다 → 기존 레포에 하지 말고 codeSandbox 같은 걸 써서 가볍게
• slate.js 가지고 에디터가 있고 bullet 정도 나오게까지 구현을 한다거나, draft.js 가지고 그걸 만들어본다거나, 간단한 스펙을 가지고 두 개 다를 활용해서 만들어보고 (기획한 범위 안에서) 어떤 게 더 적합할지 정해봐요. 어떤 느낌이구나 알면 좋을 것 같아요
  
  
• 또는 다른 마크다운 파서를 찾아보고 직접 편집기를 만들어보는 것도 좋음. 파서 위에서 만들면 상대적으로 쉬움
  
  
• 로그인 → 메인 레포 포크 떠서 작업 → pr
  https://github.com/woowalearning/mini-notion