본인이 만든 것에 대한 발표, 나의 생각을 녹아내리는 게 중요하다.
다른 사람들에게 설명할 수 없으면 모르는 것이다.

Introduce

• 두번째 시간에는 어떤 서비스를 만들 것인지 기획하고, 어떤 기능을 넣을 것인지, 어떤 라이브러리를 이용할 것인지에 대해 말했다.

Goal

구체적인 목표가 필요하다. 현재 무엇을 어떻게 어디까지 만들 것이냐는 목표가 없다. 목표가 없으므로 무언가를 선택하는 것 자체가 논리가 맞지 않다. 어느 repo 에서도 구체적으로 목표를 설명한 description 이 없다. 목표는 필요하다. 무엇을 어디까지 만들 것인지 알아야 하기 때문이다. 여기서 두가지에서 논점을 꺼내볼 수 있다.

무엇을 만들 것인가? (기술 난제의 파악)

• 여러가지가 나올 수 있다. 회원/비회원, 리소스를 퍼블릭하게? 회원만? 이에 따라 서버나 등의 구성이 달라진다. 따라서 기획적인 요소가 가장 먼저 나와야 한다. 그 이후에 자연스럽게 기술적인 확인사항으로 넘어갈 수 있다.

• 여기서 도출할 수 있는 것은 구현하려고 하는 목표 중에서 해본 적이 없는 기술이 있는지 확인해야 한다. 늘 해봤던 방식으로 하면 발전이 없다. 똑같은 걸 했어도 단점을 개선하려는 것, (어디에나 단점은 있음) 확인할 수 있는 단계로 넘어간다. 그걸 어떻게 확인할까? 그게 플래닝이 되는 것이다. 2가지 방식으로! (POC/프로토타이핑)

오늘 어떤 것들을 POC 하고 프로토 타이핑을 할 것인가?

POC

• 개념 증명은 기존 시장에 없었던 신기술을 도입하기 전에 이를 검증하기 위해 사용하는 것을 뜻한다. 특정 방식이나 아이디어를 실현하여 타당성을 증명하는 것을 뜻한다. 즉 working 이 가능한지가 관권이다.

프로토타이핑

• 프로토 타입은 더 유용한가? 더 깔끔한가? 말로써 텍스트나 목소리로 토론 혹은 이야기로 전달하는 데에는 한계가 있다. 프론트엔드는 더욱 더 그렇다. 설명이 되었다고 해도 서로 다른 이해를 하는 경우가 많다. flow를 실제로 진행하는 것을 보는 것과 화면만 보는게 크게 차이가 난다. 동선이나 컨셉이 정말로 유용한지 빠르게 빌드 업 해야 한다.

Thinking

노션을 만들 것이고, 얼마나 같은 것을 만들 것인가?

What's the big problem?

• 모호 하다고 생각하는 것을 질문하는 것, 그러면 자연스럽게 consensus의 통일을 이룰 수 있다!
• 구체적인 질문을 많이 하자.

유지보수

• 파일이나 코드가 커진다는 것은 규모, 볼륨, 사이즈가 커진다는 것이다. 코드의 구조가 커지면 작은 상태에서 100 이라는 상태로 커질 때 정말로 100이라는 상태로 커지는 것을 감안하고 만든 게 아니라면, 100으로 커지면서 복잡도가 늘어날 수 밖에 없다. 복잡도의 종류도 많다. 이에 중복코드, 패키지의 등의 개념들이 각론으로 들어가 있는 것이다. 따라서 사이즈가 커져도, 볼륨이 커져도 복잡도가 늘어나지 않게 하는 리팩토링이 자연스럽게 요구된다.

• 한달 뒤, 일년뒤에 10배로 커질지 모른다. 10개짜리가 가질 복잡도가 아닌 것이다. 오버 엔지니어링! 적정한 수준의 엔지니어링을 해야 한다. 어느 정도의 엔지니어링은 자연스럽게 😁 볼륨이 커져도 복잡도가 더 커지지 않게, 리팩토링을 하는 것이다.

  → 리팩토링? 무엇을 리팩토링 할 것인가? 무엇이 문제여서 해결책으로 리팩토링을 하는 것인데 왜? 무엇이 문제일까?
  → 관리가 어려워져서? 왜?
  → 중복되는 거 하나로 합쳐서? 왜?
  → 가독성 및 유지보수 때문? 이는 굉장히 추상적인 내용이다. 너무 wide 한 이야기이다.

배포 환경

• 개발 환경, 로컬 환경, 운영 환경 등 환경이 굉장히 많다. 각각의 환경에 따라 다른 설정이 주입되는 경우가 매우 많다. 배포 환경에 따른 주소가 다 다르거나, 각각의 환경에서 다른 빌드 환경이 들어간다거나 등의 문제가 있다.

CRA vs 웹팩

• CRA 와 같은 툴은 간단한 작업을 하려고 해도 리스크가 크다.

서버와 클라이언트의 분리

• 서버에 변경사항이 있으면 서버만 배포, 클라이언트에만 변경사항이 있으면 클라이언트만 배포하면 된다. 브랜치 관리도 힘들다. 따라서 운영관리 측에서도 고려해야 한다.

운영

• 지속적으로 관리되는 라이브러리인지 사용 언어(리액트)에서 호환이 되는지
• 라이브러리에서 지원하고 있는 기능들과 그렇지 못한 기능들을 통합해 어떻게 통합된 인터페이스를 제공할 것이며, 이를 라이브러리 차원에서 어떤 방법으로 적용할 수 있는지?

당위성

• 내가 왜 이걸 선택했어?라는 당위성이 있어야 한다. 핵심이 필요하다. 그 이유를 고민하고 빌드업 하는 훈련, 습관을 들여야 한다. (미니 노션을 만드는 거지 UI editor을 만드는 것이 목적이 아닌 것 같아서 기능이 많은 라이브러리를 사용하고 지원하지 않는 기능을 추가적으로 구현하는 게 좋을 것 같다 등과 같은)
• 예를 들어 이직 면접을 본다고 생각해보자. 전 직장에서 어떤 프로젝트를 했고, 기술을 선택했다. 그 기술은 왜 선택하셨나요?
  → 저한테는 선택권이 없었습니다. 그것으로 개발하기로 결정이 되었다. 그럼 굉장히 아쉬운 측면이 있다. 그랬음에도 불구하고 그 기술에 대한 장단점에 대한 언급, 혹은 상황 상 기존의 시스템에 도입하기에는 어려운 측면이 존재하였고, 그 단점에 대해 이런 저런 시도를 해보았습니다. 와 같은 대답을 하는 게 좋다. 의외로 다 이렇게 이야기 할 것 같지만 흔치 않다. 기술에 대한 생각을 갖고 있으면 경쟁력이 된다.

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

🌟Tip

면접을 많이 들어가는 입장에서 TIP을 주고 싶다. 질문을 받았는데, 그 질문을 충분히 이해하지 않을 때는?..

1. 나름 내가 생각한 것으로 답변한다.
2. 내가 이렇게 들었는데, 이게 맞나? 질문의 논지가 이해가 안되는데, 구체적으로 다시 알려주세요!

2번에서 커뮤니케이션을 하려는 자세 자체가 플러스가 된다. 확인하고 충분히 답해줄 수 있는 답을 얻어낼 수 있는 것이기 때문이다. 100% 이해가 안되고 납득이 안되는데 내 식대로 해석하는 게 굉장히 좋지 않는 습관이다. 적극적인 질문이 매우 중요하다.

SPEC

• 회원 서비스 추가 : 구글 로그인 붙이기
  • 회원 로그인 정보가 필요함. DB 에 저장해야 하고, 서버가 세션을 유지하는 상태가 있어야 로그인이 되어야 한다.
  • oauth 의 핸드쉐이크만이라도 붙여보기라도...
  • 어려우면 관련된 키를 하드코딩해서 뒷단에 붙여서 진행해도 된다.
• 단일 폴더 구조
  • 폴더 구조를 가지고 있지 않은 단일 문서 구조
  • 다만 리스트 UI 정도는 있어야 한다.
• 기획
  • 친구들끼리만 공유하는 일종의 간단한 문서 공유 서비스, 일기장을 쓰든 뭘로 쓰든 ..
• 에디터
  • 어떤 단계까지 할 수 있을까? 커스텀 컴포넌트가 들어가는 기능을 해보고 싶다.
  • 문서 편집기, 맵, 단순 테이블, 넘버 리스트, 드래그앤드랍 등등 어떤 기술 스택?

library's discussion

의견1 (Toast UI)

• 노션을 만드는 것이지 에디터를 만드는 게 아니다. 어디에 중점을 두느냐에 따라서 라이브러리 선택이 달라질 것 같다. 마크다운적인 에디팅을 중심적으로 한다면 toast ui 를 사용하는 게 좋겠지만, 그게 아니라면 미니멀한 다른 마크다운 라이브러리를 사용하는 게 좋을 것 같다.

의견2 (Toast UI)

• toast ui 는 텍스트 editing 기능에 치중되어 있는 형태이다. 단일 문서 형태의 서비스를 구현하는 형태에서 텍스트 editing의 다양한 기능이 필요하다기 보다는 게시판과 유사한, 하나의 페이지에 글을 작성하고 저장할 수 있는 작업이 필요해 보인다. UI 중에서도 한 두가지의 기능정도? 그러기에 toast ui는 다소 무거워 보인다.

김민태님 의견

How to select library

근본적인 목적 : 라이브러리를 선택한다면 이유를 나눠보는 것이다.

• api, 코드 구조에 관한 의견이 많았으면 좋겠다.
• 첫눈에 걸렸던 건 바닐라네?... 바닐라 js , 돔을 다이렉트로 핸들링하는, 이게 기술적으로 매칭이 안되는 부분인 것이다. 그걸 해결하려는 방법들이 있겠지만 이것 또한 비용
• All in one 에디터다 : 모든 것을 다 갖고 있다. 장점일 수도 단점일 수도 있다. 모든 걸 다 원할 경우에는 거저먹을 수 있기 때문에 좋다. 하지만 그게 아니면 거추장 스러워질 수 있겠다. 올인원은 커스터마이징에 대한 부분이 어렵지 않을까? 얼마나 커스터마이징 하는 것에 대해 노출해볼 수 있을까? 그 부분에 대해 확인을 했다.
• 문서가 부실하다? 크게 커스터마이징 할일이 없어서 문서가 부실하다... 커스터마이징 용도로 디자인된게 아니지 않을까?
• 기술 스택이 기본적으로 리액트와 타입스크립트인데, 이건 지금 바닐라 자바스크립트임.
• 커스텀 UI 를 만드는 방법을 찾았으면 되었는데..? Creating Plugin 을 리액트 버전으로 맵핑해서 만들어야 하는데 그걸 제공하고 있는 것 같진 않다. 그런 것도 다 비용으로 느껴진다. 토스트 UI 를 살펴보는 데 시간을 다 쏟지 않을까?
  → 적절하지 않은 것에 도달, 공식적으로 타입스크립트를 제공하지 않는 이유가 가장 크다.

draft.js

Draft.js
→ 아까보다 내용이 많은데, 장점이자 단점, 시간과의 싸움 ㅠ_ㅠ
→ 에디터 자체를 빌드업 하기 위한 것, 마크업까진 아니지만, 이건 리액트 기반임.
→ 꾸준히 업데이트 되기도 하고, 생태계도 나름 볼륨이 있다.

Slate.js

https://www.slatejs.org/examples/richtext

• 어떤 제품이 스스로를 어떻게 정의하는 가 가 중요하다. 실제로 그것에 관한 고민을 굉장히 많다.
• 코어와 특정 라이브러리 디펜던시 분리하는 것 좋은 전략이다 뷰, 리액트, 등
• 굉장히 똑똑한 친구가 전략을 세워서 만들었다는 느낌이 든다. draft 는 only react.js 만 사용할 수 있는데 ....이건 둘다 가능~ 어디까지 보느냐에 따라 다를 것 같다.

State.js

State.js

Focus on

→ 각자 라이브러리의 목표는 다 다르다. 어떤 결론에 도달한 제품이 우리가 하고자하는 것에 fit 이 맞는가? 그게 가장 중요할 것 같다. 무언가 만들면 그것을 어떻게 규정할 것인가. 그것에 대한 고민을 많이 해야 한다.
→ 목표를 두고, 목표를 제대로 만들어서 갈 수 밖에 없다. 방향이! 그 목표가 모든 것을 다 표현해줄 수 있다.
→ 무언가에 대한 원칙을 항상 세운다. 그럼 그걸 보통 코딩 컨벤션이라고도 하고 가이드 라인이라고도 한다. 무언가 선택을 해야 할때 , 선택해야 하는 기준은 항상 목표를 가지고 해야 한다.
→ 이번 개발의 목표? 성능 향상이라면 3개 코드 스타일 중에 성능이 좋은 것을 선택할 것이다. 목표가 리더빌리티, 유지보수성이다. 누가봐도 개발을 이어나갈 수 있다고 하면 그거에 맞는 개발 방법을 선택해야 한다.
→ 그래서 개발, 비전 등등 무언가 결정 선택을 해야 할때는 기준이 필요하고 상위의 기준이 필요하다. 일관성을 유지하는데 도움이 된다. 스스로를 규정하는 가를 찾아보는 게 가장 중요한 것 같다. 그들이 만든 원칙을 숙지하는 게 중요하다. 분명히 그 원칙을 지키기 위해서 그런 모양이 나오는 것이다.

Todo

1. 회원, oauth 로그인 하기 (구글)
   로그인 → 메인 레포 포크 떠서 작업 → pr
   https://github.com/woowalearning/mini-notion

2. 간단하게 slate.js , Draft.js 이용해서 프로토타이핑 만들기
   → 이 2개의 라이브러리가 어떤 느낌인지 알고 있기
   → 기존 레포에 하지 말고 codeSandbox 같은 걸 써서 가볍게
   → slate.js 가지고 에디터가 있고 bullet 정도 나오게까지 구현을 한다거나, draft.js 가지고 그걸 만들어본다거나, 간단한 스펙을 가지고 두 개 다를 활용해서 만들어보고 (기획한 범위 안에서) 어떤 게 더 적합할지 정해봐요. 어떤 느낌이구나 알면 좋을 것 같아요
   → 또는 다른 마크다운 파서를 찾아보고 직접 편집기를 만들어보는 것도 좋음. 파서 위에서 만들면 상대적으로 쉬움

3. 프로토타이핑을 해보았으니, 실제 프론트엔드 개발 환경은 어떻게 해야 할 것인지에 대해 생각해보기

Later

• 1번째 주에는 기획
• 2번째 주에는 직접 코딩
• 3번째 주에는 DB연동
• 4번째 주에는 실제 배포하는 것

TIL

create-react-app란?

• 리액트 프로젝트 개발환경 구축을 바닥부터 설정하는 것은 굉장히 복잡하다.(Webpack 설정의 복잡) 하지만, 페이스북에서 만든 공식적인 React 웹 개발용 Boilerplate인 create-react-app 이 존재한다! 직접 모든 개발환경을 설정하지 않아도 되고 페이스북이라는 거대한 기업에서 지속적으로 업데이트를 해주기에 많은 사람들이 사용하고 있다.

Node.js

• Webpack, Babel 같은 도구들이 자바스크립트 런타임인 Node.js를 기반으로 만들어져 있기에 해당 도구들을 사용하기 위해서 Node.js를 설치한다.
  링크: https://nodejs.org/ko/

Yarn

• npm(노드 패키지 매니저)보다 조금 향상된 도구라고 생각하면 된다. npm은 위의 Node.js.를 설치하게 될 때 같이 받게 되는 패키지 매니저 도구다. 프로젝트에서 사용되는 라이브러리를 설치 및 라이브러리 버전 관리를 하게 될 때 사용된다. 여기서 npm이 아닌 yarn을 사용하는 이유는 조금 더 빠른 속도, 더 나은 캐싱 시스템을 사용하기 위한 것이다.
  링크: https://classic.yarnpkg.com/en/

Webpack이란?

• 웹팩이란 최신 프런트엔드 프레임워크에서 가장 많이 사용되는 모듈 번들러(Module Bundler)이다. 모듈 번들러란 웹 애플리케이션을 구성하는 자원(HTML, CSS, Javscript, Images 등)을 모두 각각의 모듈로 보고 이를 조합해서 병합된 하나의 결과물을 만드는 도구를 의미한다.

---

https://joshua1988.github.io/webpack-guide/webpack/what-is-webpack.html#%EC%9B%B9%ED%8C%A9%EC%9D%B4%EB%9E%80
https://hceaan.tistory.com/41
https://velog.io/@wlsgh46/create-react-app%EC%9C%BC%EB%A1%9C-%EB%A6%AC%EC%95%A1%ED%8A%B8-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EA%B0%9C%EB%B0%9C%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0
https://engineer-mole.tistory.com/35